I figured it out. I removed the mqtt integration from my Configuration - Integration, then I rentered my MQTT info under ‘Set up a new integration’ - MQTT. Removed the configuration.yaml entry and restarted making sure Enable Discovery was ticked. Upon restart, the Ring devices appeared in the MQTT section in Configuration - Integration. After a few moments, they also appeared in Unused entities.
It does seem that after a restart of hass.io I have to manually restart the Ring integration add on before the devices show again.
I think it’s because you used the GUI to setup MQTT rather than just deleting it and manually adding the required MQTT lines to the configuration.yaml file. The GUI settings for MQTT don’t provide an option for configuring the MQTT birth message, and without the MQTT birth message the script has no way to know that it needs to resend the data.
I suppose I could do something hackish like send the data twice on initial startup, once immediately and again after 60 seconds, but, without the birth message configuration, it would still lose the devices if you restart Home Assistant without rebooting.
What I did in my example above was simply not use the “Setup a new integration” setting at all, but rather left it unconfigured there, and manually added the mqtt lines to configuration.yaml. This seemed to work just fine and devices will show up on restart because birth messages are configured. I do wonder if you can add “additional” options to configuraiton.yaml as long as you don’t try to duplicate existing options.
I’ll try to play more with Hass.io when I get a chance, I just don’t use it so it’s hard for me to understand.
I removed the GUI integration, and added directly to configuration.yaml, and that does not work at all for me. None of my mqtt devices are seen, including Ring. The logs for the Ring add on indicate it’s working, and has discovered the devices, but they do not show in HA. Also, this error message in the logs:
homeassistant.exceptions.HomeAssistantError: Error talking to MQTT: The client is not currently connected.
I also tried just adding the birth message section in configuration.yaml, but that also broke it.
It seems hass.io needs to have that integration…I really don’t know why that worked for you. I copied what you did exactly.
Odd.
Like I said, I’ll play around with it. I literally just stood up Hass.io and performed the steps as outlined above, that’s it. As a guy that’s been using Unix/Linux systems for a few decades, I find Hass.io to be confusing because, instead of having a single place to do things (configuration.yaml), you end up with two places to do everything (web ui and configuraiton.yaml for stuff you can’t do in the web UI). I really don’t understand the interaction between the two configs right now, but I’m sure it’s not that complex. It’s just difficult for me to assist as I only understand the operation of my script, which seems to be working just fine.
I understand. I was just giving you an update. I am playing around with it as well. I don’t understand the reasoning for the gui vs. yaml config. I assume to make it simpler for the less technical to use.
I am attempting what this thread suggests, and it’s still not working correctly. I will continue to investigate as well.
Disregard. It does seem to work without using the GUI, and only via configuration.yaml. Not sure what I did earlier, but all’s good in the neighborhood now it seems.
Thank you, both, for all the work on this.
Hopefully, if we keep poking at it, we’ll eventually understand the interaction and be able to get this working solidly for Hass.io users as I think that would be really valuable for those users. I appreciate your efforts in trying to figure it out.
2 Likes
Hopefully, but that won’t be this project for sure.
1 Like
I received my Smoke/CO Listener and the Flood/Freeze Sensor today. I was able to quickly code up support for the Flood/Freeze Sensor and test both of these devices successfully. I also fixed a few small reported bugs, nothing that impact major functionality, but handles a few error cases correctly (like wrong MQTT auth, etc). This also includes support for battery/tamper status as attributes/
Since I was able to test these with my own devices I’ve gone ahead and merged the dev branch to master as the 0.8.0 release.
This pretty much wraps up the initial goals of this project so I’ll probably take a break from changes for a while. I do plan to do a refactor of the code to make it less horrible to look at and easier to support/add devices in the future with less risk to breaking existing ones. I’ll split each device into it’s own file and abstract support for them there. Feel free to continue providing feedback on any additional features.
1 Like
I can’t seem to get this working in hassio, i installed mosquitto mqtt not inside the docker since the docker wasn’t working right, i folled this guide, https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-the-mosquitto-mqtt-messaging-broker-on-ubuntu-16-04 and i can successfully test communication back and forth
this is what my config.json file looks like, i am at a loss why its not sending mqtt messages across to home-assistant, i do not have a username and pw setup in mqtt server
working concept for mosquitto, what does my config need to look like?
debug mode:
im at complete loss as to what to do next…
Thanks again for your hard work!
Awesome thanks so much!
What did you do in order to get this working? I’m having the same issue after restarting.
For hass.io you have to follow the steps exactly as outlined in this post.
If you do this, it should work even on restart, at least, it works fine with my instance. Note that it may take up to 60 seconds for the devices to show up after a reboot.
If you have configured MQTT outside of manually editing the configuration.yaml file, then the easiest thing to do is to remove the MQTT configuration via the GUI, and manually add it to the configuration.yaml. Note also that the ring-alarm-mqtt configuration must use your actual ethernet IP address, but the MQTT setup in configuration.yaml needs only 127.0.0.1.
If you are having difficulty getting this working with hass.io please include, at a mininum, your configuration.yaml and you ring-alarm-mqtt configuraiton file and, ideally, your mosquitto configuraiton from the mosquitto MQTT addon as well. Without this all we can do is guess, but the settings in the post above are the only three things that are needed for this to work. Almost every problem I’ve seen so far has been not properly performing the MQTT portion of the configuration.yaml setup but instead trying to use the configure option in the GUI, which will not enable all required options.
If you run from the command line with debug mode it will display all the topics and their output, but here’s an example:
{
"battery_level":100,
"tamper_status":"ok"
}
It seems that some devices do not report actual battery level in percent, but rather just “full, ok, low”, so the code translates this into 100%, 50%, 20%, although so far all of my devices support actual level.
Tamper status will change from “ok” to “tamper” if the device is in tampered state.
These should just show up in the GUI automatically if you select the individual device.
BTW, I think my future plan for battery/tamper status is to create two separate MQTT sensors, one for tamper and another for low battery. The sensor will have a default value of “None” if no devices are in tamper/low battery state, but, when any device has an alert state, the value will be the name of any entities that are in that state. Then you can just add these two entities to the Lovelace UI and it should be easy to build notification automation off of the value.
Anyone see any problems with that or can think of a better way? I’m somewhat limited with the components supported by MQTT and the limitations of MQTT discovery. Obviously you can build this very thing today with value templates on the existing device attributes, but I think this will lower the barrier to consume this data.