i’m using a fresh installation of version 2.5.9 on a rpi4. The z-wave binding retrieved all necessary data, so it should be up-to-date. I also had the problem with the previous OH version on a different hardware.
i’m using several Fibaro FGT-001 Thermostats. 3 of them are linked to one external temperature sensor (Fibaro FGBRS-001). For 1 of them i created the items to retrieve the temperature and batterylevel for the sensor (Endpoint 2, as the manual says). The temperature value is working, but the batterylevel is always the same as from the thermostat (Endpoint 1).
here are my items:
Number Livingroom_Thermostat_ThermostatMode "Wohnzimmer" <heating> (gHeatingState, gLivingroom) {channel="zwave:device:a43446cf:node56:thermostat_mode1"}
Number Livingroom_Thermostat_SetpointHeating "Wohnzimmer [%.1f °C]" <temperature> (gHeatingTemperature, gLivingroom) {channel="zwave:device:a43446cf:node56:thermostat_setpoint_heating1"}
Number Livingroom_Thermostat_SensorTemperature "Wohnraumsensor [%.1f °C]" <temperature> (gHeatingTemperature) {channel="zwave:device:a43446cf:node56:sensor_temperature2"}
Number Livingroom_Thermostat_BatteryLevel "Wohnzimmer [%.1f %%]" <battery> (gFirstFloorThermostatBatteryLevel, gLivingroom) {channel="zwave:device:a43446cf:node56:battery-level1"}
Number Livingroom_Thermostat_SensorBatteryLevel "Wohnraumsensor [%.1f %%]" <battery> (gFirstFloorThermostatBatteryLevel, gLivingroom) {channel="zwave:device:a43446cf:node56:battery-level2"}
Does someone know if this is a bug in the firmware v.4.x from the fibaro device or if something is wrong in the binding/configuration?
It’s a four-year-old post about openHAB 2.5.9, so I’m guessing not.
I don’t quite get what the OP was trying to do, but it’s strange to me to get the sensor’s battery level from the thermometer. Assuming the sensor is also connected to the main Z-Wave controller, why not just link directly to it?
First it is generally not a good idea to post on a 4-year-old thread.
Generally, your problems can be traced to the ZW DB for that device. Reviewing the manual, I changed the alarm_power to alarm_battery which should pick up the alarms identified in the manual. The battery level should be picked up but should be on the EP1 and/or EP2 channels, not EP0 (from the manual).
A ZW debug log would show any communication that is not getting processed into a channel update. The issue would be that the battery updates are infrequent. You could try Debug, wake device (maybe blue? maybe green - I don’t have the device)
I can start a new thread, if this is helpful. Last post was in Sep. I though that was recent enough
I do not understand how I can do this change on my own setup. Is this something I can also change in my OH? If yes, can you give me some more information?
I have not yet found how to get a ZW debug log. Is it the debug level of the ZWave binding?
If yes where does it log this information? in openhab.log?
I have the device, so If I can get the ZW debug information an help improve the device information, I will.
The ZW DB has been adjusted (for the alarms), but the process is for the developer to review and then merge into the binding in a week or two. Generally, the binding is only modified on a forward basis. This means that the update will be in a OH 5.0 snapshot. If you prefer stable releases this could be June 2025 or so.
An alternative is to use this procedure, but not everyone is comfortable with it, so they prefer to wait. If you are going to try, the file is fgt001_0_0.xml (12.3 KB)
and the folder is /fibaro (not zooz as in the example).
The Debug may help find where the battery updates are going, but first make sure all three battery channels are linked to items and there are no updates.
In OH4, on the UI settings, at the far right the addons are listed, find the Zwave, click and change the debug level
It took a little longer than expected, but I eventually followed the instructions and updated my configuration. I did not yet dig into the alarm things, but I saw that the temperature on endpoints 1 & 2 are not read either.
I have changed your xml, to try getting these, and it seems I am getting this updated and working.
When I am finished updating and checking that all endpoints values are properly ingested and affected to the corresponding channel. Is there a suggested way for sending that back to openHab (like a github & PR), so that my changes do not get deleted on the next update.
Yes, Register for the ZWDB (if you haven’t already) and open a ticket for write access, then make the changes and ask for a review from the developer. Details are in the blog
The changes are not working, or openHab is not handling properly secondary endpoints.
I have updated my xml definition, and manually added the information for the temperature of both endpoint 1 & 2.
However the data, is always the same on all 3 channels (base, Endpoint 1 Endpoint 2).
The alarms do not work either,since the charging state of the device is not reported in OpenHab. I know that the device reports it, as I saw it when I used it before switching to openHab.
Is there a tool in openHab to manully read an display Endpoints Messages & Values, in order to fix the xml definition file.
Are you sure the optional temperature monitor (FGBRS-001) has been paired? I believe that device is the intended source for EP2, (both battery and sensor). Also does parameter 3 show the remote device?
By the ZW spec all available Command Classes need to be in the Root EP (0). Also EP1 will usually be a mirror of the Root. So those should be the same. Only one needs to be linked to an item.
Since I’m not sure of all you have done, the best thing would be to delete the thing (do not exclude, no need to unlink items), set the ZW binding to debug, then scan to pick up the device again. In the interview of the endpoints and parameters, it should show any issues.
I have deleted and rescanned the device, and all came back as before. I looked at the logs, but there are quite a few, and since I do not know what to look for, I did not see anything looking like and error. How can I find the “interview” messages, and see if it shows any issue?
Hi, an update from my side. The problem still exists in OH4!
I moved from the Z-Wave binding to the Z-Wave JS UI with MQTT integration last year. The communication (state changes, updates from battery levels, live charging indicator,…) is more stable than in OH directly (after a few weeks of running the binding no more battery level changes, only a reboot/(un-)plug of the z-wave stick was the solution, after the reboot everytime there was a chance that the binding didn’t initialize the things, then i had to reboot several times).
As i said, with JS UI all these problems are gone and both (OH und JS UI) are running on the same RPI 4.
I understand that, and I followed the procedure to manually update the xml, and have the alarms for EP2 properly reported. I Also tried to get EP2 battery level.
FWIW : I installed ZWave JS UI and a MQTT Broker, and I have my sensors now coming through the MQTT binding. I can see the alarm levels, as well as the EP1/EP2 battery levels. I have now to remap all my things to this source, instead of the zwave binding.
I also need to look into sending orders to the things via MQTT, but I am not to worried about this yet?
If I may make a remark on the MQTT binding, it is weird that the mandatory JSONPATH to decode the mqtt payload is only visible in the advanced mode.
I’m not an expert (or even very knowledgeable on the MQTT binding) but am not sure what you are talking about. Are you using the HA configs or generic things with ZUI? If you are using generic MQTT things you can set the parameters in ZUI gateway to just send values and avoid the JSON altogether.
If I didn’t suggest it in the linked tutorial, using MQTT Explorer is very valuable to copy and paste topics (both commands and read only) from MQTT into the OH generic things.
I have used MQTTExplorer, and it is very useful indeed. copy/paste of topic, debug sending of topics, all this is very usefull for making the clients side work.
I have found the setting in ZJSUI to send only the value, and have changed it, so that values are directly read from OH. Thank you for that hint.
