Sunday, October 25, 2020

Integrating nodejs-poolController into Hubitat

Now that nodejs-poolController is setup, we can move into adding it into Hubitat.  You can either add it manually use the Hubitat Package Manager to add in the Pool Controller app.

After adding the app code, you can then configure the user app in Hubitat.


Click on 'Start Discovery' and your new nodejs-poolController instance should show up and be selectable.


Click next and you should be able to choose the discovered nodejs-poolController.


Click Next to specify a pool controller name and the "features" that will be imported into Hubitat.


Click done and return to Devices to see all of the identified features of nodejs-poolController that are now available to be added as endpoints or triggered using actions.


You can also add these devices to dashboards to control things like the pool temperature, pool and landscape lighting, and other features directly from the app or your smart assistant.






Setting up and configuring nodejs-poolController

Over the last year, the Hubitat has proven itself more powerful every day and I've looked at integrating more of my devices into it, because... why not?  This will be a two part blog post for setting up and configuring nodejs-poolController and then integrating it into Hubitat.

Since the pool went in a few years back, we've been monitoring and managing it using EasyTouch and ScreenLogic, by extension.  It's served its purpose for being able to turn lights on and off, controlling the heater, and checking the water temperature.  The interface is serviceable, but can be a bit confusing if you don't know that 'Booster Pump' == 'Pool Cleaner' and you have to go to Features to turn on the lights rather than the section that says Lighting.  So, a small learning curve, but still a standalone app that begs to be integrated.


Enter nodeJS-poolController.  This amazing piece of code replicates the existing system and gives you significantly more options than the native controller, plus the ability to integrate it with Hubitat, SmartThings, Vera, or by MQTT. 

In order to interact with my pool controller, a ScreenLogic2, I purchased a RS-485 USB adapter for my Raspberry Pi 3 which will run the nodeJS server.  This one was $7 on Amazon and recommended by the developer and works out of the box with RaspiOS, or whatever they're calling Buster these days.



Pulling up the ScreenLogic2 manual, I was able to identify which two screw terminals I needed to connect to (DT+ and DT-) and I was well on my way.


The process to setup the poolController was not really that daunting.  I had it completed in under an hour.  Generally here's the steps I went through:

root@poolcontroller:~# apt-get update && upgrade

root@poolcontroller:~# apt install npm node


This installs nodeJS 10 (at least with my build) and the author recommends 12) which was installed using nvm in the following steps.


root@poolcontroller:~# curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

root@poolcontroller:~# nvm install 12


Install build-essentials and git to pull down code.


root@poolcontroller:~# apt install git

root@poolcontroller:~# apt install build-essential


Clone both projects down.


nodejs-poolController:

root@poolcontroller:~# git clone https://github.com/tagyoureit/nodejs-poolController.git


nodejs-poolcontroller-webClient:

root@poolcontroller:~# git clone https://github.com/tagyoureit/nodejs-poolController-webClient.git

Install both node packages with npm i.

root@poolcontroller:~/nodejs-poolController#npm i

root@poolcontroller:~/nodejs-poolController-webClient# npm i


Run the nodejs-poolControler. 


root@poolcontroller:~/nodejs-poolController# npm start


After it's running for the first time, you can edit the config.json file with your specifics.


Run the nodejs-poolController-webClient


root@poolcontroller:~/nodejs-poolController-webClient# npm start


Assuming everything went well, you should be able to browse to that IP address on port 8080.



I took the extra step to setup pm2 to allow the services to startup on reboot.


root@poolcontroller:~/nodejs-poolController# npm install -g pm2

root@poolcontroller:~/nodejs-poolController# pm2 start npm --name="poolController" -- start

root@poolcontroller:~/nodejs-poolController# cd ../nodejs-poolController-webClient

root@poolcontroller:~/nodejs-poolController-webClient# pm2 start npm --name="webClient" -- start

After the processes are runnning, you can have pm2 start on boot and run these processes automatically.

root@poolcontroller:~# pm2 startup
root@poolcontroller:~# pm2 save

With this part complete, we can now move on to integrating nodejs-poolController into Hubitat!

Sunday, November 3, 2019

Hubitat Migration Complete! Long Live Hubitat!

It took the better part of two days and excluding and including more times than I can count, but I've successfully* moved over all of my 70 devices to Hubitat.  Yep, that's an asterisk next to successfully, because in the process I seem to have lost two Zigbee devices and my water sensors don't appear to be supported (and no driver to be found).  The remaining devices were relatively easy to move despite my slow start... see previous post.

The two devices that I was surprised were supported were my ZRTSI Interface for my motorized blinds, made by Somfy and my Hampton Bay Universal Ceiling Fan Control (that uses Z-Wave).




The ZRTSI was a bit of a challenge to get unregistered from Wink, but I was able to successfully exclude all of virtual nodes and the base node and included them on Hubitat.  The VNODES show up as Generic Z-Wave Shades, but I can use them as a switch.  So On == Open and Off == Close.  As others have noted, there's no "My" setting which would allow you to stop the blinds somewhere between open and closed. As a bonus though I don't have to go through IFTTT to open and close the blinds using a Robot trigger on Wink.  I can just call it from Hubitat or issue a "Turn on Blinds" to Alexa to open them up.  

The Fan Control device was enabled using the "King of Fans" driver on Hubitat.  I can address each of the functions directly and again I can call it directly from Alexa. Before this also required IFTTT and the trigger command through Alexa to set the fan to a particular speed since Wink was unable to directly address non-switches/buttons through Alexa.  

The devices that didn't work were a couple of CREE Zigbee Bulbs that I can't get to factory reset.  When removing my other bulbs from Wink they would blink indicating they had been reset and I could discover them again on Hubitat.  I have two though that won't reset no matter how many times I go through the 2-sec on 2-sec off x 4 process.  And my water senosrs are the Aeotec ones that worked with Wink, and are discovered by Hubitat, but will only report the battery remaining and not the presence of water even if I change the device type.  **I found another procedure for CREE that was 1 sec on, 2 sec off x 4 that worked!

All in all, I'm happy with the new platform and the new flexibility it provides.  Now that the same functionality I had before is migrated, I'm going to start investigating the new features that I have available now since Hubitat is significantly more flexible and programmable than was available with Wink.

Thanks Wink for providing the platform which really got me into home automation.  I don't think they'll survive the year, but here's hoping I'm wrong.

Re-homing GE/Jasco Z-Wave Switches and Dimmers

The move to a new hub has not started as smoothly as I would have liked.  I'd thought (mistakingly) that a big company like GE would have its stuff together and the process of unregistering and reregistering their device would be easy and straightforward.  If you're scouring the web looking for a reset procedure for the GE 127221 or 12724, here's what I did, though you may want to omit several of these steps:


1. Unregister the "light" from Wink by clicking "Remove this Light" from the edit menu in the Lights panel.
2 Use the "factory reset" procedure I found while also scouring the web.  Pull the air-gap tab, replace the air-gap tab, and press up ten times on the toggle.  Try the other reset procedure I found (toggle up three times followed by down three times) just for good measure.
3. Attempt to discover the "new" switch on Hubitat using Z-Wave Inclusion Mode and toggling the light on.
4. Congratulate yourself after the Hubitat shows the following and assuming the switch will soon be usable on the new platform.


5. Wait an excruciatingly long time for it to initialize.

5. Try exclusion / inclusion several more times only to reenter the "Initializing" loop.

6. Switch browsers. Rediscover.  Keep waiting.

7. Read forum posts and keep waiting.

8. Contact Jasco customer service and discover that community support is only available for Hubitat.

9. Learn there is no way to factory reset the Jasco 127221 and 127224 switches and that general exclusion is the only way to have it forget its previous associations.  Really?  So you can safely skip step 2 if you're still following my procedure... sorry.

10. Upgrade Hubitat from 2.6.112 to 2.6.113

11. Repeat Step 3
I don't know if it was the software update, several reboots, repairing Z-Wave on the hub or Saturn's alignment with Ceres, but after that steps 1 and 3 seem to be working for all of my switches.

Wednesday, October 30, 2019

Winking out and moving to Hubitat

After two years, it looks like it's time to update the ol' blog again.  This time is more a necessity than a general want to.  It appears that Wink is on life support and will probably close its doors (and its cloud) very shortly.  The writing has been on the wall for a while now with product unavailability and outages over the past 6 months, but the thing just works and since I use voice commands for nearly everything, I haven't had to really deal with the archaic, clunky interface on the mobile device.

So it's au revoir to the Wink Hub and a move to a new platform.  We had a good run, but I don't want to have to turn on and off my lights with my hand... like a savage.  Who does that?

I'm not thrilled with any of the alternatives, really, but I've narrowed my future platform to either Hubitat or Home Assistant.  I've purchased the Hubitat from Amazon and I stood up a basic Ubuntu server with docker to run Home Assistant.  I'll probably be using both of them for a while until I figure out which way I'm going to go.  If you have experience with both and have an opinion, please leave a comment below.

Here's how I see each of them:


For reference, I'm using mostly GE/Jasco ZWave switches, CREE Zigbee bulbs, Schlage Zwave locks, Dome Door/Window Contact Sensors (and some Trippers still), Aeotech Zwave water sensors, Honeywell Thermostats, Nest Protect, and a bunch of Somfy motorized blinds with the Zwave to RTS gateway.

Now that I have a general strategy on where I'm going the next the next few posts are going to be the process of moving from one platform to another hopefully with limited disruption.

Next up, deregistering the GE/Jasco switches since I have a ton of those and adding them to Hubitat.



Wednesday, April 5, 2017

Automating Watering of the Garden Using Python

Ultimately the reasons that I choose to add intelligence to the things around my home fit into two buckets, either simplicity or "because it's cool".  There are a few technologies that start out in the "because it's cool" bucket and, through some developments or integrations, end up in the simplicity bucket.  I purchased the indoor/outdoor soil monitors for my garden primarily to provide some insight about some factors that may be contributing to my inability to produce any produce (ugh, that was bad).

The first purchase was the Koubachi nearly 4 years ago.  While expensive, this product worked as advertised and provided some nice data including moisture, light, and temperature.  The product and dashboard have entered a sunset period after the acquisition by Husqvarna.  Our Koubachi fell victim to the elements (or an aggressive weeding session) and needed to be replaced.  At that time, I chose to use the PlantLink system for monitoring of the two planters that house my annual frustration efforts.

After the purchase of the Rach.io Iro for irrigation, the next steps seemed obvious to move the PlantLink from one bucket to the other. 
  1. Get moisture data from PlantLink
  2. Trigger Rachio to water the garden if the sensor says it's dry
  3. ???
  4. Profit
Well, after waiting and waiting for some official integration, spurred on by a mention on PlantLink blog and seeing a forum pop up on the PlantLink support forums (though it has no posts yet), I've come to the conclusion that official support isn't coming.

So, I decided to write my own using a simple script and their official APIs.  
Disclosure: I am a python hack. I take and reuse code from other projects, so I can guarantee it's not the most elegant way of doing it, could be more efficient, and may make programmers physically ill reading it.
I did this in an afternoon reading through the PlantLink and Rachio API docs.  It seems to work OK, but there's probably a better way to do it.  If you have ideas, please comment below.  My general approach was to have a script that runs once a day with a cron job on my ubuntu server at home and queries the PlantLink sensor to see if it needs water... if it does, it triggers Rachio to water a particular zone for a definable amount of time, say 20 mins.

The code is out on github, the most difficult part was finding all of the variables I needed to trigger the Rachio to start a particular zone.  It relies on a auth token for authorization, a person ID to find the  device properties, a device ID to find the zone ID that will be used for the API call.

The PlantLink side is relatively easy.  Their API supports basic HTTP authentication, so it's a matter of using your username and password and parsing the plant health value from the returned JSON. This value is called "Plant_Fuel_Level" and ranges from 0 to 1 based on the amount of detected moisture in relation to how much the configured plant needs.  A support post off the API page mentioned that 0.2 is a good value to trigger the watering of the plant.  Other value that could potentially be used is "predicted_water_needed" which is in epoch time. 



The value is then compared to the defined watering threshold and if it's below, it asks Rachio to kick off a watering job.  

Rachio's API is a little more difficult to navigate.  It first requires that you use the API Auth Token discovered from their web dashboard.


This token is used to discover your person_ID with the following call: 
curl -X GET -H "Content-Type: application/json" -H "Authorization: Bearer [auth_token]" https://api.rach.io/1/public/person/info
This will return your person_ID which you can use to determine information about the devices associated with your account.  You'll need this to find the zones you have configured and their associated zone_ID.
HTTP/1.1 200 OK {
"id" : "[person_ID]"  
 Next, take your discovered person_ID and plug it into another API call to discover your device_ID.
curl -X GET -H "Content-Type: application/json" -H "Authorization: Bearer [auth_token]" https://api.rach.io/1/public/device/[device_id]
Dig through the returned JSON and find the zone that you'd like to trigger if the plant needs to be watered.

HTTP/1.1 200 OK
   {
   "id": "2a5e7d3c-c140-4e2e-91a1-a212a518adc5",
   "status": "ONLINE",
   "zones": [
     {
     "id": "e02de192-5a2b-4669-95c6-34deea3d23cb",
     "zoneNumber": 3,
     "name": "Zone 3",
     "enabled": false,
     "customNozzle": {
     "name": "Fixed Spray Head",
     "imageUrl": "https://s3-us-west-2.amazonaws.com/rachio-api-icons/nozzle/fixed_spray.png",
     "category": "FIXED_SPRAY_HEAD",
     "inchesPerHour": 1.4
     },
     "availableWater": 0.17,
     "rootZoneDepth": 10,
     "managementAllowedDepletion": 0.5,
     "efficiency": 0.6,
     "yardAreaSquareFeet": 1000,
     "irrigationAmount": 0,
     "depthOfWater": 0.85,
     "runtime": 3643
     },
That zone_ID will be required for the API call to trigger the watering job.  If you have more than one PlantLink sensor, each fed by a different watering zone, you can replicate my JSON parse code adjusting the list number for each different sensor.
moisture = parse[0]["last_measurements"][0]["plant_fuel_level"]

Finally, I just setup the script to run once a day to minimize the impact on the APIs. You can make this every other day or once a week depending on what you are monitoring.
$ crontab -e
0 5 * * * ~/PlantLinktoRachio.py 
This can be done in the cloud also as it doesn't need to directly communicate with either your PlantLink or Rachio device, all calls use cloud services, not the devices themselves.

Code: PlantLink_to_Rachio


Thursday, September 29, 2016

The Case for Voice Biometrics in Virtual Assistants

I was reminded again today of the inherently flawed system that enables our virtual assistants to do our bidding. While voice recognition is one thing (not trivial in the slightest), actually identifying the source of that voice is another.  Siri, Alexa, Google, and Cortana are all pretty good at responding to your voice request with an action or an answer to a question.  This is incredibly convenient for allowing me to stay on the couch and ask Alexa to turn the thermostat up a few degrees or to dim the living room lights.  However, she could care less WHO asks her, just that the request was made.

This has been a minor nuisance in the past, even in our house.



Other examples have ranged from humorous to disgusting.. really, who adds "big fart" and "hunk of poo" to their shopping lists?  Oh right.. kids.

This seemingly comical behavior that Alexa or Siri will do whatever you ask her to, becomes less so when you combine it with your physical security systems or home automation which can trigger things like the unlocking of deadbolts, the opening of garage doors, or summoning your fancy Tesla S.

Posted on Reddit, comes the story of a man who automated most of his house including the August door locks and used Siri and HomeKit for voice commands.  This enabled him to unlock the door by asking Siri to do it. Now instead of 'sled dogs' being added to his shopping list by the kids, the locks could be activated by anyone within shouting distance of the iPad.  While Redditors were quick to point out that he should have required a PIN to use HomeKit devices, that would make the virtual assistant pretty useless.  Get up, type in a PIN on the iPad, then issue the voice command?  Sha, right.  As if...

 It's clear that unauthenticated voice commands are problematic.  So what can the developers of these virtual assistants do about it?  Why not look at speaker recognition to identify the individual making the request and authenticate based on voice characteristics?  This is moving forward for other sensitive transactions like voice banking.  There's a great infographic from Nuance that talks about the science and debunks some of the myths. This would reduce or eliminate rogue requests from unauthorized parties and allow you to use voice-triggered HA systems more securely.

In the meantime, if you're on a conference call with a number of people who work from home, I encourage you to ask Alexa to play Jingle Cats or order diamond earrings from Amazon and see how many Echos you can get to respond.