I moved to OpenZwave which works for open/close and a percentage. The only thing that wasn’t working last I checked was the “Stop” button (although I’ve seen some issues/fixes/discussions around this recently so might be fixed now). The stop button wasn’t really a deal breaker for me as I’d just set a percentage or use the on wall control if I wanted to stop it at a certain point.
OpenZwave has worked perfectly for me and closes my windows every night for me.
Ok, and whenever manually changing the percentage at the fibaro - will the value be updated in Home Assistant?
RAZBERRY2 professionals here?
A little late, but I have a similar issue.
I have multiple GE/Jasco dimmers/switches including a 3-speed fan controller. These are all non zwave plus and they aren’t sending a refresh so that when I manually use any of these switches, they don’t send their state back to OZW/HA. These can be controlled with HA without issue including automations. Manual operation is the only issue. Without the devices reporting their state, some of my automations have stopped working.
My newer zwave plus switches/bulbs do not have this issue.
Anything that can be done about this? Is it just me?
Add polling, but it can slow down your network if you poll to aggressively. I only poll devices that are frequently used. I have the same switches and dimmers and have been slowly replacing them throughout the years.
You all see this?
This thread’s title needs to be renamed. Clearly, OZW is not the future of Z-wave in HA.
Maybe good to keep it for historical sake. Haha
Very exciting news! Thanks for sharing!
Well, I guess that’s that then.
A while back I posted on here about how maybe it was better to use a dedicated ZWave hub to separate the ZWave domain. At the time, I changed my mind and chose to implement ozw on a separate HA instance located in a better place (RF-wise).
I love MQTT and use it for a stack of other tasks in the house. It IS my communications platform of choice. Consequently, I have a resilient MQTT infrastructure to cope with the occasional vagaries of the network.
The only problems I have are caused by ozw’s restriction to use qos=0 (which I asked about in a separate thread here.
I’m not convinced that changing the ZWave implementaion again is a good choice for me. The Pros/Cons for changing highlight the single-developer issue that has affected ozw development (no reflection on @Fishwaldo), and there’s no guarantee this won’t re-occur. Given the critical status of ZWave in my house, therefore I am thinking again of swapping to a commercial ZWave hub
The likely hood of this occuring is much lower because the codebase is more widely known. OpenZwave is written in C++ where as Zwave2jsmqtt is written in JS. Pretty much anyone who contributes to HA will be able to contribute to Zwave2jsmqtt because the frontend is written in JS/TS.
I hope you’re right.
We already have 7 collaborators.
HA is using the driver ZwaveJS directly to make their own implementation and not Zwavejs2mqtt. However, zjs2mqtt would be a good alternative to @Guff666 
I’m excited about two things, thats on the roadmap: OTA updates and S2 security (which should speed up communication?).
Yes, I was simplifying it for people who don’t understand the difference. When official name comes out, then we’ll call it that 
Ah, ok, but might also confuse as the HA implementation won’t use MQTT. 
I believe it’s going to be called “Z-Wave JS”
Whatever is good, as long as it works. 
Haha okei, but i guess that’s