I also tried OZW Beta 1.6 Z-Wave integration and my Fibaro Roller Blinds worked inverse.
On the old 1.4 standard Z-Wave integration I could Invert these in yaml;
don’t know if you can also do something similar in the openZwave 1.6 beta.
Standard 1.4 Z-Wave integrations works the most stable and got the most Z-Wave devices connected.
Also keymotes like Fibaro & WallMote works if you add scene codes in ZwConfig file.
My chinese unknown PIR sensors are also recognized.
With the OpenZwave & Zwave2MQTT they all sucked. Were not detected, did not work, wrong type of variabels (ex. Boolean for dimmer value of Fibaro Dimmer, …).
I did the test 6 month ago and tried 2 days ago again and these beta Z-Wave integrations still suck big time. I’ll stick to the old default Z-wave 1.4 which is most stable. (works far less than my old FHEM Z-wave integration system).
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.
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.
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.
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?).
