FYI - the basic statestream component just went live in 0.54. I’m working on publishing attributes and should be able to get a PR in soon. After that, I’ll see what I can do with autoconfig…
Sorry I’m a total noob but I’m running Hass.IO so was just wondering what the easiest way (if any) to control my zigbee light switches and show the state that it’s in (whether pressed physically or turned on via HA).
Or is there a simple solution that I’m missing?
I guess long story short what’s the easiest method in order to use zigbee light swithces with Hass.io?
What is the correct device (/dev) path for configuration.yaml?
That depends on the device, but it will be the same using usbip as it would be if the device was connected locally.
@luma, yep you’re right.
I just had to install python-openzwave manually, then found out I was missing apt packages.
I managed to also do this with sernet and socat by doing this:
zwave stick -> pi -> socat -> network -> 2nd pi -> ser2net -> serial device
Also works with a Vera
Put this in cron and run it every few minutes to keep socat connection up
And settings for ser2net (in /etc/ser2net.conf)
7676:raw:0:/dev/ttyS):115200 8DATABITS NONE 1STOPBIT
Last piece I need is how to detect ping zwave chip from home assistant and restart it when connection is broken.
Hey @luma - just wanted to say thank you for this! I have it up and running and it’s working great!! I love the flexibility of my HA instance as a VM, but have been using Vera for the z-wave interface and it’s…less than stable. This is incredible to have the z-wave dongle shared from the pi. I even attempted VirtualHere but it didn’t work at all (wouldn’t connect). Thanks again!
I agree with @danodemano - @luma this is definitely a great writeup. You should think about contributing it to the cookbook section on the HA website - we can’t be the only ones who want to have our HA virtualized.
Hello, can you look at
p.s. Love your component! Can i gift you a beer or something?
Hi, @quasar66…I’ve been looking at that one - there has to be some component that is publishing an attribute that is a weird data type, and the MQTT library doesn’t like it. Nothing on my system triggers it (even my ZWave stuff).
I saw that tinloaf on Github submitted a PR to always serialize the payload with JSON, which should work with any data type: https://github.com/home-assistant/home-assistant/pull/9872
It’s been accepted and will be in the next release, so hopefully that fixes the issue. Unfortunately, it looks like it’s a breaking change, so the outputs will be a bit different.
Thanks for the offer of the beer, but it’s not necessary. Glad you found it useful!
Good to know of the change ahead of time. I’m using the statestream quite heavily right now.
Thank you again!
I’ve been following this thread because Home Assistant runs really fast on my unRAID server, but my Z-Wave USB stick needs to be in the center of the house for my Z-Wave network to work reliably.
As I can’t get the whole USB over IP thing working with unRAID (can’t add kernel modules, as far as I know) I’m really tempted to have 2 instances of HA, 1 on my unRAID server with everything in the config, and 1 on a raspberry pi 3 (Hassio) with only Z-Wave enabled and have that forward everything via MQTT to my main HA instance on the server.
So just for clarification, what is the best / most reliable way to get this up and running?
From this thread it seems that I have 2 options:
Using mqtt_eventstream, this would link everything, meaning every event would be synced accross both instances.
Using the new mqtt_statestream by @mw-white, I’d need to publish everything to MQTT that I’m interrested in on the Z-Wave HA instance. Then on my main HA instance I’d configure various MQTT components for every Z-Wave component on the Z-Wave Instance.
I’m tempted to go with option 2, since this way I can actually offload the raspberry pi from all non-zwave stuff, right?
EDIT: wait, I get how this works for 1-way communication. But when I want to change the state of a z-wave switch from my main HA instance, how does that work, initially I thought publishing the state to the correct mqtt topic would work. But then how does my Z-Wave HA instance know what to do?
EDIT2: I’ve now stepped away from the mqtt_statestream component for above reasons. If there’s anyone who can explain how to accomplish what I want with it I’m totally onboard, because it seems more elegant then just syncing everything between the 2 instances. Which is what I’m now doing with mqtt_eventstream.
EDIT3: Another disadvantage of mqtt_eventstream is that my entities only show up in my main HA instance after something happens with them on the Z-Wave HA instance, if I understand the mqtt_statestream component correctly this shouldn’t happen with that component?
EDIT4: coming back to the topic of this thread, as I’m running HA in a container. The default way to get HA to see the z-wave USB stick is to pass through the device to the docker container with /dev/acm0:/dev/acm0, while I can’t (not sure if it is impossible on unRAID or if I just can’t get it to work) get the kernel module (vhci-hcd) on my docker host, is it possible to do this in the Home-Assistant container only?
you can do this with Aeotec zwave usb stick?
you went this route?
I haven’t personally done so but I see no reason why it wouldn’t work.
will I be able to use the pi3 for a HASSIO instance too?
- HASSIO on pi3 with zwave stivk, and also zwave over IP
- HASSIO on a NUC on same LAN that “reads” the data from the pi3 with the stick
I don’t work with Hass.io at all so I’m not sure how that will work out. The usbip driver is a kernel module, which will need to be loaded outside of your container as docker containers don’t support loading kernel modules.
if I use HASSBIAN?
The guide above presumes you are running raspbian, which is what hassbian uses. So yes, that will work as directed in the OP.
maybe find a zwave HUB, like we all do with ZIgbee (Xiaomi and Hue) and WiFi (the router)?