When the thermostat is heating I can see that the value is increasing, so in general reading that value seems ok.
But it sometimes happens that the thermostat has no power for a few seconds. When this happens, the Electric Meter Value is back to 0 and starts increasing again. According to heatit the value should remain as before the power loss.
I had a long conversation with heatit, first they said it’s a device failure and I should replace it.
Now I have a new device and i still have the same issue. Now they say it’s a problem with openhab.
Can someone help me verify if this is a device problem or a z-wave binding problem?
You must have not enabled any persistence in openHAB. Without any persistence OH sets ant values & states to NULL since the framework keeps no value history.
Number GF_Bathroom_Heating_kWh "Heizung kWh" <energy> (GF_Bathroom) ["Meter"] {channel="zwave:device:d44bd02d:node66:meter_kwh"}
Number GF_Bathroom_Heating_kWh1 "Heizung kWh1" <energy> (GF_Bathroom) ["Meter"] {channel="zwave:device:d44bd02d:node66:meter_kwh1"}
This is my persistence-File: GF_Bathroom_Heating_kWh, Notifications_Active: strategy = everyChange GF_Bathroom_Heating_kWh1, Notifications_Active: strategy = everyChange
I don’t think we have a persistence issue here. If I understand it correctly, the device has a power loss, although it is not a battery driven device. OH shows the power counter of the device and this is set back to “0” due to the power loss. Persistence would offer a workaround as the previous value could be retrieved and taken as a new starting point, but the real issue is not solved that way.
Is there a wiring problem, maybe? Why does the device has a power loss. Do you have a way to determine whether the device is correctly powered but suffers from an internal issue?
The reason is technically. I have a continuous-flow water heater that needs a lot of power. When I turn on hot water it automatically disconnects power to all the floor heatings (by a load shedding relay). So unfortunately the device will lose power sometimes during the day for a few seconds/minutes.
In my opinion it’s a problem by the device itself, but the manufacturer says that it must be a problem by openhab, because it works in their test environments.
I see. The next question is: can the device store data so it survives a power outage? The device needs to be constructed for that purpose. I suspect this is not the case as this needs some kind of persistent memory. Most likely they did not incorporate something like this and see a stable power connection as the normal state/prerequisite. I do not know the device, maybe you can clarify that from the documentation available to you or by asking the vendor. Or there is some sort of shutdown procedure involved to store the data and the load shedding does not trigger that.
Another option would need re-wiring your installation in a way that the load shedding is done “after” the thermostat and the thermostat itself stays continously powered.
I don’t think so. Especially because the value is read-only. The binding (which is the software that “connects” the Z-Wave part of the device with OH) is - simplified - just a transport layer for data. The logic is implemented in OH, e.g. by rules that you implement or by sitemaps where you can change data. A value that is read-only cannot be manipulated from the outside. So even if the Z-Wwave binding or OH wanted to change the value, they could not do that.
Is there a way to display the value in question on the device itself? If so, I assume you see the value being reset to zero there as well?
You can even test more: By excluding the device and observing what happens when the power is shut down for the device. OH in that situation is completely out of the picture. Does the value survive a power outage? That may be a way to show the vendor that the device does not match the description/promises as far as the data persistence is concerned.
In case the vendor does not help and you do not want to change the device for another brand, there is still the option to work around the issue with logic implemented in OH.
