I have several ZWave Develo Thermostats MT02650 which have the Danfoss living connect Thermostat as hardware basis with a Devolo Firmware.
I switched from FHEM to OpenHab. Now I am missing the clock command class in OpenHab. CCS is also missing, but it is not necessary as it is strange to handle anyway.
I know from my own experience and from the Danfoss support hotline, that you need the clock set correctly on those devices, as the device will perform an automatic calibration procedure after initialization. During this calibration, the device will step by step open its valve in the morning hours and measure how the room is heating up (depending on room and heater size). This can happen for up to a week until the process is finished. You can read about this in the official Danfoss documentation (chapter 1.8):
In FHEM I added a “rule” to automatically update the clock once a day since it was drifting quite heavily on some devices.
If you cannot set the clock, the devices will perform this calibration heating randomly during the day. In my case I have one device which is doing it in the evening at the moment when the child needs to sleep. So I have to remove the battery, to abort this procedure.
**I would like to add the clock command class, to be able to manually set and read the clock. ** How can we do this? Or is Openhab doing this somehow?
This may be connected to an old thread which I found:
Currently this doesn’t seem to be in the database. The command class would need to be added, and the time_offset channel would need to be added to the command class.
Please see the following link for updating the database.
You need to update the database first. Then the XML file can be created and we can update the binding.
No - this isn’t really supported in openHAB. All XML files need to be part of the binding so that the openhab core can read them on binding start.
No - that’s a completely different XML file. These XML files are the binding persistent storage so that it saves information about devices when the binding restarts.
The XML files provided by the database are read by OH to create the thing definitions.
It indicates if the device marks this command class in its NIF (Node Information Frame). Ideally this should reflect the device configuration, but it’s not used by the binding so it does not matter.
No. I will remove this though, but it is just a name issue.
No. It’s not required and only used on some classes.
You can’t. If you’ve added something you want removed, just rename it to “REMOVE ME” or something like that and we should sort this when you click the request review button.
How can I see when the changes are merged? I checked the GitHub ZWave Binding page, but I cannot see any new commit. Which GitHub project are we talking about? This one?
Ok, so to clarify though, you are referring to this device? The reason I ask is that you talked about the fact that I “committed the clock class into the ZWave repository”. This PR doesn’t do that - the clock class was commited a long time ago. This PR adds the time offset channel.
As I said, it is already in 2.5.3. This is the most recent release - there will not be another full release of OH2.5.
My goal is to have the clock of this device set correctly as mentioned above in this topic. That was the reason for the change. At the moment, the clock is set to a random time when you put in the batteries or when device is first turned on. The correct clock is necessary to have a correct initialization procedure which should take place in the morning. At the moment it happens at a random time.
I just installed 2.5.3 so I can check if it is better.
Can I directly see somewhere in OpenHab that the time offset is available for this device. Or even better, can I read the current clock of the device? As far as I can see there is no new item or setting.
Giving the promised feedback, the clock sync is there and I see values in it (time offset). As far as I could see during the colder days, the devices did not heat up during the night anymore (which was the initial problem), but it was only a short monitoring period. I will check again next winter.
What bugs me a bit is that the time offset has some very random numbers in it and they are changing when my Openhabian has restarted. Shouldn’t they stay the same for the same device?
For example the thermostat in my office room has a time offset of zero most of the time and sometimes shows very high values over a short time and sometimes very low values over a longer time.