I’ve merged the newest version of the script to the master branch in my repo for anyone that’s interested. Noticeable changes:
Rebaselined the script to use a new version of the underlying API code that seems to work better (borrowed from the guy I reference in the credits).
Did away with the availability topics in all the sensors. This wasn’t accomplishing the goal I had for it which was to monitor connectivity to the API. It was just monitoring connection to the MQTT client the script was running and that’s not a useful metric since it seems to regularly disconnect and reconnect a moment later.
Added a new connectivity sensor that relies on constant updates from the script to confirm that it’s still connected to the API (basically a heartbeat). This sensor goes unavailable if it doesn’t get an update from the script every 15 seconds.
In the background, the script is checking the connection to Ring every 10 seconds and posting an update to the sensor noted in #4. Note, this heartbeat check isn’t polling Ring directly. It’s just looking at the status of the web socket the underlying API connection creates and seems to notice that it’s disconnected about 60 seconds after the script actually loses connectivity to Ring. The connectivity sensor in #4 is looking for these ongoing updates and drives it’s connectivity off the assumption that the script is always pinging it to say “hey, still connected.”
Based on one restart of HA and then restarting the script to recreate the sensors, it looks like the script still has some of the oddball connectivity issues where some some MQTT messages posted by the script (notably the Alarm mode and the connectivity sensor updates) don’t seem to be picked up by HA when you run the alarm script the first time and require a restart of the script to get them synced up. So, it remains a work in progress, but this feels like an improvement over the previous iteration.
I’m open to ideas for additional improvements/alterations that would make this more user-friendly (other than setting it up for HassIO as I use Hassbian and don’t have the inclination to figure out setting up a HassIO plugin).
Actually, hold that thought. I broke a couple of things in the latest push so will have to push another update before it will work without some hard coded values changing.
Okay, the repo is back up. Note for anyone who’s forked the previous repo, I blew away the old version of the repo and started again so it’s not tracking as a fork against another piece of code. It’s now live and working as described above. Still stumped on the issue where the security panel sensor and the connectivity sensor won’t register posts from the MQTT client within the script on the first start but it seems to be working well aside from having to restart the script after you first get it up and running.
Does today’s update with 0.86 affect anything? Not knowing anything about Z-wave vs MQTT (and not having a Dongle that can read those things connected to my Pi), I haven’t a clue if today’s update would discover the Ring alarm sensors. THe update provides Zwave network and node management. Just an FYI.
I haven’t pulled the update yet but I can’t conceive of why it would have any direct impact on my script since that runs entirely over WiFi/the internet.
I don’t see anything specific in the hass.io MQTT plugin docs about the MQTT auto-discovery feature but other posts in the forum seem to indicate that it does work. If that’s the case, it seems like this script should work with hass.io. You would just need to point the MQTT variable in the script to whichever broker your hass.io instance is using. Any hass.io users reading this who have more experience with the MQTT plugins? I don’t know anything about configuring them but seems like there would be a “discovery” parameter that you set in the JSON config file similar to how you do the discovery topic in the Hassbian configuration yaml.
I guess my question is really how does one get this installed on hass.io? It isn’t as simple as just copying your files into place. There are a few steps (i.e. npm install mqtt async ring-alarm) that aren’t obvious how to achieve since hass.io gives a very limited set of commands that can be performed in the terminal.
(I have been waiting for Ring Alarm integration with HA for awhile. It will open up so much automation for me, so I am really excited about this!)
I am a software developer, however I have very little experience with Python (I do work with JS almost daily, though). If there is anyway I can help, let me know.
Is the hass.io MQTT broker inside the docker container? If there’s a way to expose the broker port outside of the container, then all you need to do is run the mqttAlarm.js script from my repo and point it to that IP address and port and at least the MQTT part of the script should work fine.
As far as help otherwise, as noted previously I don’t have the appetite to try and learn docker/hassio plugin development at the moment. Too many other fun projects to work on.
But, if you know JS, maybe you can offer some insight on why the alarm panel doesn’t get the initial status update that gets pushed to it right after the script creates the panel object (line 121 in the mqttAlarm.js file on the repo). You have to restart the script after HA discovers the alarm panel for it to start picking up the MQTT messages from the script. I can’t tell if this is something on the script side or HA. I’m sure I just did something dumb in the setup process.
I’m completely clueless at JS and this has been a lot of trial and error to get working in the current semi-functional state.
I haven’t documented this in the readme for the repo since it’s still very rough but taking a new tack on trying to make this work better (and maybe provide a path to hass.io eventually).
There’s a new script in the repo called yamlGenerator.js. If you run this script, it will pull all of the sensors and alarm panel and spit out a yaml file called mqtt.yaml. Take the contents of this file and paste it into your configuration.yaml and then HA will set up all the sensors. This should more or less circumvent the mqtt discovery process and I’m thinking will eliminate the issue we’ve been seeing where you have to restart the script a couple of times when HA first creates the sensors through the discovery process. Here again, I haven’t tested it extensively but it seems to be working well so far. At a minimum, it eliminates the need to restart the mqttAlarm script (or service as I’ve got it setup in my case) and rerun the discovery process every time you restart Home Assistant. This should open up some additional possibilities for automation that are reliable across restarts since your entity names will be consistent. It sure does make the configuration.yaml look ugly though.
Note, you need npm install js-yaml for this new script to work.
This is working well for me with the exception of the alarm_control_panel component. That’s still requiring me to rerun the script when Home Assistant restarts. All the sensors appear online without needing to re-run, though.
Hi, The sensors appear online but do not reflect their current state upon HA start up. The current state is only updated when a sensor changes states (this is also why the control_panel is not connected at first - it needs a state update).
I added the “retain” option to all of the publish statements and it seems to work without a re-run. I also made all of the devices/panel send their current state during the discovery/start up routine.
Note that the syntax for the retain option i used is:
this is different than the original script that used [retain = true]… i’m not an expert in java and don’t know if that makes a different or not.
Also, to be precise, i don’t use discovery, but I have all the devices/alarm publish their state (with retain : true) during the start up routine of the script.
@OB1 That makes sense actually, though odd that node never bothered to tell me I was passing the options for the “retain” flag incorrectly. Given that older versions of the script always had the sensors showing either unavailable or not a current state when they were being set up by the discovery process, I’m guessing that the status that the script was posting to MQTT during the initial discovery process wasn’t being seen by HA because it was still setting up the sensors and the message had already been broadcast by the MQTT broker before the sensor was ready to receive. Your retain flag solves that. I’ll update the script later today.
I cannot answer 100% if the MQTT broker is inside the docker container. I think it is.
I will take a look at your JS as soon as I am able.
I am not sure, but I am thinking that translating the JS to python might be all that is needed…then it can be placed in the custom_componets folder. There may be a bit more to it. I haven’t had the time to adequately research it. I will work on this when I can. If someone gets there before me, cool. If not, also cool.
I’ve updated the repo with the correct syntax for “retain = true” for the various MQTT status updates and it works like a charm. Thanks to @OB1 for catching that.
I’ve also added a yamlGenerator.sh that will automate the process of generating the yaml configuration needed if you want to put all your Alarm devices in your configuration.yaml.
As far as the MQTT broker in hassIO, just from reading the official hassIO addon docs for MQTT, looks like there is an embedded broker you can use. There’s a section about “listening on insecure ports.” I’m guessing if you leave that port open and point my script to the IP:1883 (or whatever port you specify) of your hassIO install, the script would be able to publish messages to the broker. From there, if I understand it correctly, you can just drop the Alarm Device configuration from the yamlGenerator script into your configuration yaml (using either the Hass Configurator or SSH) and fire up the mqttAlarm script and it’ll work. I’m just guessing though. Not sure if autodiscovery works with HassIO though as I’ve not yet seen it conclusively documented anywhere.
If anybody is able to get this running on hassio on a RPi3 please let me know.
I have tried, but am pretty sure the problem is I don’t know what I’m doing.
I loaded mosquito mqtt via the add-on section. I’ve never used MQTT component before.
I’m not sure if I configured it correctly. I am able to see the MQTT icon on the side bar of the HA menu on the left.
Additionally, I’m not certain if I know what I’m doing when using files from Git-Hub, and then trying to run commands on Node.js.
So basically, if anybody has the time, patience, and knowledge to confirm this is viable on hassio, and is able to write a detailed guide for dummies, I and the community of non-technical users (who strive to continue to learn and understand how this all works) would be very appreciative!
Thanks acolytec3 for your progression and dedication to this project!
Hey thanks so much for this. I had the earlier version working for awhile but I just tried to upgrade to your new one I would love to get my hands on that yaml…I am getting an error now when i try to run mqttAlarm.sh. This is the same machine as it was working on, I put my info in mqttAlarm.sh same as last time and all. I also can not get yamlgenerator to run i just get command not found. IM running it on an ubuntu 16 vm. Please help if you can.
mqttalarm.sh error:
da@unifi:~/ring-alarm-HA-plugin$ sudo ./mqttAlarm.sh
module.js:550
throw err;
^
Error: Cannot find module 'socket.io-client'
at Function.Module._resolveFilename (module.js:548:15)
at Function.Module._load (module.js:475:25)
at Module.require (module.js:597:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/home/da/ring-alarm-HA-plugin/index.js:9:12)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
yamlGenerator.sh error:
da@unifi:~/ring-alarm-HA-plugin$ sudo ./yamlGenerator.sh
module.js:550
throw err;
^
Error: Cannot find module 'socket.io-client'
at Function.Module._resolveFilename (module.js:548:15)
at Function.Module._load (module.js:475:25)
at Module.require (module.js:597:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/home/da/ring-alarm-HA-plugin/index.js:9:12)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
@Darbos Sorry, I missed an edit in the readme on the repo. When I did my rebase of the main script, the guy I borrowed the base Ring API integration from added a new required package socket.io-client. The readme is up to date now but for reference you need to do: npm install socket.io-client
That should solve the dependency issue you’re seeing with the missing module.
If you’re getting “file not found” or something similar for the yamlGenerator.sh, remember to make it executiable: chmod a+x yamlGenerator.sh
