Thanks. Updated to latest HS3 Custom Component (0.6) …Upgraded HA to v.115.2 and everything is working fine
Same here…all looks good now.
HomeSeer Custom Component 0.6 and pyhs3 0.11 have been tested with HS4 4.1.7.0 and appear to be working fine. DISCLAIMER: I can only test against my Z-Wave network so there could still be something lurking out there.
Please report issues on Github and I’ll do my best to help out.
I am curious if there’s any way to translate/transpose/convert a Z-Wave Switch Multilevel in HS to a ‘cover’ in HA?
Another Homeseer user here since 2014 and just got Home Assistant up and running yesterday. Interested in merging the two using Home Assistant for an interface and also some of its ability to interface to devices and services that Homeseer cannot provide while also doing the same with my Homeseer installation. The custom component looks great is it being expanded to HS4 and can it support more than Z-Wave devices? I’ve got a ton of event logic, custom devices counters timers etc. It seems like this is such an amazing start and almost to the point of what the homebridge-homeseer plugin can do.
Was looking at doing MQTT and about to dive in until I found this discussion! Also still interested in playing around with MQTT to expand my mind a bit and eventually incorporate some of these ESP8266’s I’ve got lying around. I’m a complete newb to this specific subject but pretty versed in the other areas.
Also this is my first post to the community! Looking forward to lots of tinkering over the 2020 winter to keep sane L-O-L. Kideon on discord.
Hi @plotty Welcome to the fun. I assume you are Kideon on the HS forums as well since I saw you recently in the ActionTiles discussion?
I’ve been testing the custom component for a couple of weeks with HS4 and have not found any issues. At this point, there’s no plans to take it beyond Z-Wave but there has been some discussion regarding supporting the parent/child (device/feature) relationships for multi-function HS devices, such as thermostats.
As far as MQTT, I think it’s the way to go if you just want to get data back and forth between HS and HA for a UI display. I use mcsMQTT since it seems to be the most feature complete plugin for HS4. Also, I run a separate MQTT broker (mosquitto) on an Ubuntu Linux box. The package also has command-line tools for pub/sub testing which I find very handy. There’s some good YT videos on MQTT that are worth batching.
I have to warn you, there’s a lot of change going on with HA and with that, things get broken. For a while, every time I turned around an update had broke my UI configuration. Still happens, but not as often as it was a few months back.
Yep that’s me! Figured mqttt was still going to have to be the route to go and this component doesn’t make devices just entities. I’ll DM ya!
Typically entities are what you want for individual functions, such as a switch or a lamp. For a thermostat, you’d want a device with a number of entities associated to it, much like the parent/child relationship (device/feature).
BTW, my post about having good luck with things not breaking must have cursed me. Today, I ran the configuration checker and all was well, but when I updated to 0.117.0, I no longer have a UI and nothing in the logs.
I’m done with using a Raspberry Pi. For me it’s only going to be a virtualenv where at least I have a fighting chance of recovering from situations like this.
Yeah I figured that out. It’s not pulling in motion sensors, leak detector, smoke detector
Motion and leak should work since those are just binary sensors. I’m not sure about smoke since I don’t have any to test out. Can you tell me what the Device Type (String) is for your motion and leak sensors? It’s a little tricky to get this info in HS4. You have to go to http://<ip_address>/deviceutility, find your motion sensor, and then click on it, and finally go to the Advanced tab to see it.
My motion and leak sensors are “Z-Wave Sensor Binary”.
For the motion sensor it’s the DSM-200 plug in the motion sensor device says
Z-Wave Home Security for the motion sensor and the root device says Z-Wave Notification Sensor Root Device
for the leak sensor the root says Z-Wave Notification Sensor Root Device and the water notification says Z-Wave Water Notification
strangely enough it’s picking up root devices like the DSM temperature and luminance, the temp on the leak sensor and the battery on the smoke detectors (first alert)
@plotty - As a test, change the Device Type (String) for one of your motion sensor devices from “Z-Wave Home Security” to “Z-Wave Sensor Binary”. Do the same for “Z-Wave Water Notification” for your leak sensor.
The component doesn’t care about root vs. child devices. It looks at every HS device reference and tries to match against the Device Type (String). Temperature, Humidity, and Luminance are all supported which is why it picked up those HS devices. Battery is also supported.
@kenm thanks so much for your contribution. I have had great success using your HS custom component. Quick question. I have two HS4 instances monitoring two different properties. Is it possible to have two instances of your custom component in the same HASS instance? I would like to create one lovelace UI for two different instances of HS4. Thanks in advance.
Todd
Hi Todd ( @theadlee ) - Welcome to the party. Just to clarify, the custom component is the work of Mark Coombes, @marthocoo . I’m just doing a few enhancements and maintenance. While the low-level “pyhs3” library can support more than one HS instance, the custom component currently cannot. I know for sure it only looks for one set of configuration parameters but that shouldn’t be too hard to fix. I’ll have to review the code to get a more accurate scope. In the meantime, you can look into using MQTT to communicate between the two HS4 instances and then connect to one instance for some form of a UI.
@kenm This should not be too hard to accomplish and wouldn’t require any changes on the pyhs3 side, only with the component. I will try to take a look at the code tomorrow and see if I can make the changes soon.
If a brave soul wants to help me test (not recommended for your production system), I pushed some changes to the custom component that should allow the use of multiple instances of homeseer. To test, checkout the multiple-hometrollers branch on GitHub from inside your homeseer directory:
git checkout multiple-hometrollers
To test, changes are needed to the configuration.yaml parameters. The bridges key must be specified and a list of instances provided, even if using only one homeseer instance:
homeseer:
bridges:
- host: 192.168.1.10
namespace: homeseer
http_port: 80
ascii_port: 11000
username: default
password: default
name_template: '{{ device.name }}'
allow_events: True
- host: 192.168.2.20
namespace: homeseer2
It is absolutely critical that the namespaces for the hosts be different! No checking is done in the test code at present but bad things will happen if they are not different.
This may or may not work as is, please let me know the errors you encounter and I will troubleshoot and fix.
It would also be useful for testers of the multiple bridges/HomeTrollers branch to test with just one entry under bridges as that should also verify if it’s working correctly. Thanks!
I’ll spin up a test instance of HA this afternoon and start to test. One thing I hadn’t thought of but just realized and that is my second HS4 instance doesn’t use any Z-Wave. It’s Philips Hue and MQTT only. I still should be able to test the multi-instance connectivity code.
You could also create a dummy device with a supported test string to see if it gets pulled in…
Great minds think alike. That was my plan.