Same problem here. My environment is OpenHab 3.0.1 (docker), installed on intel nuc with aeotec Z-Stick Gen5. With openhab 2.X (docker) works fine. I noticed the problem is related only to fibaro Z-Wave devices. I have three devices (FGS211 Relay Switch 1x3kW) that control lights and after OH upgrade I no longer receive status updates when I switch device manually.
I tried to change some related thing “Configuration Parameters” (ex. Polling Period) with no success. I tried also 3.1.0 milestone and snapshot docker version but situation doesn’t change.
So far I’ve only tested one Z-Wave module. I have several running on a RPi3 with OH2. Now I’d like to see that I can get one working on a RPi4 with OH3, to understand how OH3 works before moving and rebuilding everything. In my old system I fiddled with just about every setting. Now I’d like to avoid that.
My plug is a: TZWP-102 Telldus socket and energy meter (Swedish).
Old system had a controller from UZB – Z-Wave.Me
New system has Z-Stick Gen5 (not the PLUS, but the one needing a USB HUB to work )
It doesn’t sound too promising if a lot of people experience problems.
Hi,
I have the same problem on two different setups, one using openhabian (latest, ie snapshot version of openhab) and one using docker using 3.1.M5. I can update z-wave devices through the ui but when updating devices manually, the ui isn’t updated.
This is really strange and I think it might have something to do with the Z-wave hw. I used to have a zwave.me gpio board, version 2. The board crashed a week ago and I replaced it with the latest model (ZMMERAZ2).
The old board worked fine with (at least) openhabian and M4 but the new board doesn’t (or rather works as above)
Have no clue right now what to try next. Plan for trying out the z-way just for reference.
I add below zwave log with the hope that someone could find out the problem. This log is related to a manual switch (OFF and ON). As you can see item status is sent to the Z-Wave network but the OH can’t update the fibaro switch item status.
My suggestion is to remove the device and re-add it so that it gets properly configured. OH2 at some point changed the way that notifications were configured - this uses the newer system than was used in early OH2 bindings.
I have the same issue of Z-Wave devices not reporting status correctly to Openhab (3.2.0.M3)
Cost me a lot of time yesterday to figure this out while I was adding new Z-Wave devices to my Z-Stick controller.
I have new devices, so re-adding will not be a solution here. Also, I have tried configuring via the UI and via a .items file. Same behaviour inboth cases.
Interestingly, when I switch on/off power outlets using the Basic UI, everything works as expected. But I don’t see the “OFF” updates coming into the openhab log. The “ON” updates are in there.
When I do the same using the default Openhab UI of v3, the “ON” works, but the “OFF” does not. Probably because it still thinks the items is “ON” as the “OFF” update was not received.
Some further testing shows that the same behaviour happens in 3.1.0 and 3.2.0.M4.
Same problem here.
FIBARO switch modules do not update their state when operated manually.
Other modules (eg roller shutter modules and wall plugs) work normally.Everything working OK on OH 2.5.
Using version 3.2.0.M4 installed on RPI4 8GB with openhabian and AOTEC stick Gen5
All installation and creation of items done in Main UI.
As a temporary work around I am using 2nd Group Association (S1 key ON/OFF) to update the controller.
Is updating the Z-Wave binding to any milestone going to help since I am already using 3.2.0 M4?
I doubt there is a binding problem here. What reports are received from the lifeline and group 2? Maybe this is misconfigured in the database, but you will need to look at this in the debug log to see what’s happening.
There must be a problem with the data base configuration
As mentioned earlier when a command is send from main Ui the controller is receiving a STATE UPDATE from the module.
But when the switch operated manually no STATE UPDATE is received or at least what ever is received from the module is not interpreted as a STATE UPDATE.
When the 2nd Association Group is assigned to the controller then a STATE UPDATE is received twice.
Please refer to the log file. https://drive.google.com/file/d/1LKQFmdNd7CnRvLpFKM2rAMvHIflgDj7y/view
The Node in question is number 23.
Using the main UI the switch is turne:d ON at 18:13:19 and OFF at 18:13:43
Locally without Association is ON at 18:15:08 and OFF at 18:15:42.
After Association there are few operations with the last at 18:23
I would be happy to try and correct the database if you can give me a hint of what could be wrong.
The issue is that the device is sending the report from the association (presumably the lifeline gorup) without using the multichannel encapsulation. I don’t know what device this is (I don’t think you said?) so it’s a little hard to be 100% sure here.
I’m also unsure if you have configured these devices in OH3 or only OH2? I suspect possibly you configured everything in OH2 and then moved to OH3? If so, I would suggest to exclude the device and add it back as OH3 uses newer association setting to try and avoid this sort of problem, but it won’t be updated if the associations were already configured in OH2.
Sorry I didn’t mention the name of the device.
This particular module is the Fibaro FGS223 Double Switch 2 but I have thus issue also with other switch modules from Fibaro like the FGS213 Single Switch 2.
Actually I started a new setup from scratch when I moved from OH2 to OH3 back in January.
At the beginning I didn’t mind about this issue because it is very rarely that I used the manual switch. But now I have made some rules that depend on detection of manual switching hence the issue is now important.
All the Zwave devises were excluded (but not factory reset), the controller was factory reset and then all devices were re-included in a new setup.
Also I tried excluding one device (not this particular one) from the controller and adding it again, because I read your earlier comments on this thread, but this did not help.
I can try to do this again tomorrow with this device and see what happens.
Normally I am not using any associations other than lifeline. I only did this now as a work around solution.
Will let you know tomorrow what happens with removal/adding of this particular device.
That’s all that should be needed, but I think that it needs to be configured using the multi-channel association which should happen if it’s reconfigured with OH3. Then reports should be sent correctly from the device (I hope ).
Good news. I have excluded and re-included the module and now everything is working as it should.
I do not know what went wrong the first time since it was done in an identical way as it was done the first time.
The module was excluded by removing the AEON Stick from the RPI and bringing it next to the module. After exclusion the stick was inserted back on the RPI and the module was re-included using network discovery with the controller in place.
The module was discovered without problem and now everything works fine.
Using HO3.2.0.M4 on RPI4 8GB.
I guess now I will have to exclude all Zwave devices and include them again.
Is there any other way to fix this? E.g. delete the thing and rediscover? I have a lot of fibaro switches built into wall switches and I am really not happy to open them all up to do a exclusion / inclusion :-/
With Fibaro modules you do not really need to open up your walls to exclude / include.
If you have a switch connected to S1 then you only need to put your controller to exclusion mode and then quickly triple click S1.
Then for inclusion set your controller to inclusion mode and triple click again.
Works with momentary and togle switches if you do it fast enough.
@chris is there another way to fix the DB? e.g. clearing it in some way? In my setup, I use the discovery mechanism for all Things, but I use an items file for the Items config. So it is relatively easy for me to start fresh.
So for instance, would it help do delete the Z-Ware controller Thing and readd it? Or uninstall the Z-Wave binding and then reinstall it?
It is still not clear to me where the issue occurs, and why it is fixed by the exclude/include workaround.
)
).