I have to say, after a few weeks of experience, that I’m quite frustrated with ZWave binding. I’m not sure if the issues I’m experiencing are because I started to used OpenHAB with v 3.0, which I guess is still not stable enough, but it is quite frustrating.
In another thread, Trane XR524 ZWave not updating / OH3 - #7 by flpaoli I detailed my attempts to get 2 Thermostats to report temperature regularly. I concluded it was a problem of the Thermostat operating in Fahrenheit. I conclude that was not true (the decimal precision I believe was, but not the lack of updates).
Well, a few days later both Thermostats stopped updating. Nothing changed, just it all stopped working. The Thermostats could receive commands, but OpenHAB didn’t register temperature sensor updates.
Then I hard reset the controller, removed the Things, re-added the nodes through using the controller on a PC, added the Things in again, this time with everything operating in Celsius including OpenHAB, and, no game. The temperatures don’t update in OpenHAB. So this is a problem in OpenHAB somehow.
Then I go to the Thing UI, update Device Configuration, Polling Period, set it to 3600, Save, exit the Thing and open the Thing again, what do I see? Poling Period is 86400. No update. Every time I try to Save the Thermostat there are 3 parameter which it says are invalid, I fix them, Save, and then next time I enter in they’re at the invalid value. So the UI doesn’t seem to be updating anything.
I want to see all of this work, permanently. I would appreciate suggestions. Should I restart from the sdcard image, re-install from scratch and do everything through config files?
My understanding is the Zwave binding hasn’t changed much between OH 2.5.11 and OH 3.0 so I doubt that is the problem.
If I understand what you are saying correctly then I agree. I suspect that the device has a set precision such that the temp reading needs to change by a certain amount before it reports and that threshold is larger for F than for C, causing it to report less frequently. Often (but not always) there will be a parameter one can set on the device (it’ll be a property on the Thing) to control stuff like that.
Are these mains powered (or powered from the HVAC system) or battery powered?
You’ll need to gather some trace level logs from the binding but I don’t think your conclusion is correct. As I understand it, most of that communication is handled by the controller itself, not the binding. If the device is reporting there will at least be some evidence of that coming from the devices in the logs. If there is no such evidence the logs it means the root source of the problem is the thermostat itself. If there is evidence in the logs then those logs need to be analyzed by someone more knowledgable than me to figure out what is wrong.
If the device is no longer communicating with the controller, changing any configurations won’t take and will end up reverting. Again, debug or trace logs will be required.
It would be informative to know which parameters they are and what you are doing to fix them.
Put the binging into debug or trace level logging. Capture the startup as well as some info from trying to update the properties on the devices. It might be worth while deleting the Things and rediscovering them. Did you do that when you reset the controller and readded the devices?
If after rediscovery the Thing for the thermostats indicate they are unknown devices that would be an indication that the problem is the thermostats themselves are not communicating.
Yes, all my zwave devices are powered from mains, not on battery.
They are
21: Cooling Delta Stage 2 OFF
21
Please select a value that is no more than 8.
24: H/C Delta
24
Please select a value that is no more than 15.
76: Fan OFF Time
0
Please select a value that is no less than 10.
Yes, I had the log files in DEBUG for zwave binding when I plugged the controller back into the Pi’s USB after adding the devices to it, and then started openhab.
Looking at the raw log file I see openhab understands they are new, and starts the process of discovering them:
Looking at the logs at Z-Wave Log Viewer and filtering one zwave Thermostat at a time, it all looks very normal.
I see it moving between Stages, from IDENTIFY_NODE to PING to a bunch of others until DYNAMIC_END and then DONE. That takes about 4 mins in total.
Right now one of my thermostats says it is 22 C, but in Openhab it is still at 24 C, which was the temperature back in Feb 14th. It is like no updates are being retrieved, hence my intention to force some polling every 10 minutes. Look:
openhabian@openHABianDevice:/tmp $ date
Sat 20 Feb 2021 09:15:24 AM EST
openhabian@openHABianDevice:/tmp $ grep -i "MULTILEVEL, value=" /var/log/openhab/openhab.log | grep -i "node 3"
2021-02-14 23:54:04.324 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=24
It does seem the zwave binding is trying to poll, but there is no info on what (isn’t) happening after the poll:
I used Zensys tool on a Windows PC try to poll, and it seems to have worked. I get packets sent, packets received, to both thermostats. Even when I set the polling to extremely quick polling, like every 60s or 45s. So it does seem all OK with my hardware and for some reason my OH3 isn’t taking poll responses in.
I don’t understand what the raw data in the packets send from Thermostat into ZWave hub mean, so I can’t check from the raw data if the report from the Thermostat is accurate.
Does anyone have a spec, or can point me to a page with a spec, of what the raw data in a polling response from a Trane XR524 mean, so I can check? Or point me to where in the source code does this translation from raw data to items happens?
In general, zwave isn’t about polling and you might instead be looking at the autonomous reporting arrangements of the devices.
That’s a UI bug, see here, with apparent workaround
It’s possible this affects other parameters which you had trouble with.
Well, there’s a chain of stuff to look at; Item details, link details, channel details, Thing details. A mess-up or change in any of those is enough to stop the apparent show.
OK. lets start from the beginning…
Did I miss it, what is the zwave stick or controller?
What is the operating system and platform?
This is a new set-up? and OH version please
Setup is relatively new, installed in early Jan. I used to get updates from these Thermostats, then didn’t. The thread I linked to in my original post shows Grafana charts where the Thermostats were reporting.
ZWave binding version (I updated at the start because I was getting no result from the Thermostats, kind of like now): Whoa… this is strange… I was expecting to see 3.1.0 here…
openhab> bundle:list org.openhab.binding.zwave
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
────┼────────┼─────┼─────────┼───────────────────────────────────────────────────────────────────────────────
231 │ Active │ 80 │ 3.0.0 │ openHAB Add-ons :: Bundles :: ZWave Binding
I did not update nor rollback to 3.0.0… is there any way where this might have happened automatically?
Did you install the zwave binding when you installed 3.0.0? Did you then install a snapshot version by dropping a jar file into the addons folder? Did you uninstall the 3.0 version before adding the jar? Just trying to figure out what you have done, seems like you expected this
Yes, I followed what anonymous.one posted at [SOLVED] Zwave devices not updating item states after upgrade to OH 3 - #8 by anonymous.one and updated to 3.1.0 . I can’t recall now but I think I wasn’t able to do the Karaf thing but searched and found another way to update. I am sure I had the 3.1.0 version because I did execute bundle:list -s | grep zwave and saw 3.1.0 there.
So somehow my OH3 brought back to 3.0.0 … strange.
I will try the script linked by Bruce_Osborne to get it back to 3.1.0 again.
So I removed them both with bundle:uninstall org.openhab.binding.zwave then ran openhabian-config and updated to main. After that I went to console and listed the bindings.
At first it lists 3.1.0 only, then, magically, about a minute later I run list again and I see both versions again !?!?:
How do I get rid of this zombie 3.0 version which keeps reappearing? Where does this thing come from?
Anyway, I seemed to have resolved my problem by uninstalling 3.0.2, removing 3.1.0.2021042110336 because it resulted in errors, and then taking the backup of 3.1.0.202103070338 which the zzManualInstaller.sh script created and putting it back into addons.
Copies of my chores below in case someone is facing similar issues with their ZWave in OH3:
Then in the console it is automagically there and Active:
openhab> list -s | grep zwave 235 │ Active │ 80 │ 3.1.0.202103070338 │ org.openhab.binding.zwave openhab> list -s | grep zwave
235 │ Active │ 80 │ 3.1.0.202103070338 │ org.openhab.binding.zwave
But my question remains, because I know that zombie 3.0.x version is hiding somewhere ready to pounce for my brain… where is it hiding and how do I shoot it in the head for good please?
Sure. But if there should happen to be bindings= entry in addons.cfg text file then it will fetch and load the “standard” binding as well as any jar it finds. I suppose it’s not worth looking, though.