Clock Class for Devolo Thermostat (MT02650)

[chris (Chris Jackson)]

I already registered and can edit the database but I need a corrected XML file.

You need to update the database first. Then the XML file can be created and we can update the binding.

Is there anywhere a documentation about the structure and how to update and load the xml files into OpenHab so I can test before uploading?

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.

I have seen the node xml files in the openhab2-userdata/zwave directory.

Are we talking about those files?

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.

[SeeAge (Christian)]

Understood.

I added the clock class (basically copied the settings from the Danfoss version of the thermostat (LC-13)).

But I have further question:

1. What is “NIF” and do I need it? In the Danfoss it is not selected, but in the Devolo it is selected on almost all classes.

2. Clock Time Offset is marked as [deprecated]. Is this an issue?

3. There is an information that “Endpoint 0 has no command class linked to the basic class”. Is this an issue?

Finally, it seems that I also edited the Danfoss Thermostat LC-13 by accident. How can I undo this change?

[chris (Chris Jackson)]

hat is “NIF” and do I need it? In the Danfoss it is not selected, but in the Devolo it is selected on almost all classes.

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.

• Clock Time Offset is marked as [deprecated]. Is this an issue?

No. I will remove this though, but it is just a name issue.

1. There is an information that “Endpoint 0 has no command class linked to the basic class”. Is this an issue?

No. It’s not required and only used on some classes.

How can I undo this change?

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.

[sihui]

I added the clock class

Approved

How can I undo this change?

Fixed.

Clock Time Offset is marked as [deprecated].

Fixed.

[SeeAge (Christian)]

Nice!

How is the procedure for me to test this?

[sihui]

How is the procedure for me to test this?

Wait for the changes to get merged, download the latest zwave snapshot, either upgrade manually or use this script:

Zigbee and Z-Wave manual install script

A number of people have run into trouble performing manual installs of the Zigbee and Z-Wave bindings. A manual install (dropping the jar into addons) is rarely needed, but some people prefer a manual install over apt-get, or want to use a stable OH release with a recent Zigbee or Z-Wave binding. Here is a script that will hopefully make it easier to install, upgrade, and uninstall these bindings, and prevent some of the common issues. Who would benefit from this script: Anyone wanting to tes…

[SeeAge (Christian)]

Wait for the changes to get merged, download the latest zwave snapshot, either upgrade manually or use this script:

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?

openhab/org.openhab.binding.zwave

[chris (Chris Jackson)]

I checked the GitHub ZWave Binding page, but I cannot see any new commit.

No - there is none at this point. Please be patient - I normally do an update once a week on the weekend.

[SeeAge (Christian)]

No - there is none at this point. Please be patient - I normally do an update once a week on the weekend.

Ok, thank you!

[SeeAge (Christian)]

Hello Chris,

I have seen, that you committed the clock class into the ZWave repository.

Now I am considering whether to update the ZWave binding manually or wait for an OpenHab release (maybe milestone release).

Do you know when the change will be integrated into OpenHab?
How much risk is there with manual updating the binding?

Thanks a lot!

[chris (Chris Jackson)]

@SeeAge

I have seen, that you committed the clock class into the ZWave repository.

This was done a long time ago. What device are you interested in? Is it this one (MT02650)?

@SeeAge

Do you know when the change will be integrated into OpenHab?

Sorry, but I’m not exactly sure what change you refer to? Is it the changes to this device? If so, then that will already be in 2.5.3

[SeeAge (Christian)]

I meant the Clock Time Offset added in Database update (#1313) earlier this month.

Database update (#1313)

I was wondering when this will be part of an OpenHab release or if I update only the binding?

[chris (Chris Jackson)]

@SeeAge

I meant the Clock Time Offset added in Database update

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.

@SeeAge

I was wondering when this will be part of an OpenHab release

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.

[SeeAge (Christian)]

@chris

Ok, so to clarify though, you are referring to this device?

Sorry, yes I was referring to this device.

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.

[chris (Chris Jackson)]

@SeeAge

Can I directly see somewhere in OpenHab that the time offset is available for this device.

Yes, that is what the clock offset channel does - it provides the offset of the PCs time to the device time.

@SeeAge

Or even better, can I read the current clock of the device?

No - this is of limited use in general - that’s why we provide the offset. Why do you want to know the time?

@SeeAge

As far as I can see there is no new item or setting.

There is - that’s what we added. Have you deleted and re-added the device?

[SeeAge (Christian)]

@chris

There is - that’s what we added. Have you deleted and re-added the device?

Ah, no, I haven’t. Good that I asked. I will do this tomorrow.

Thank you for the fast feedback. I will report asap.

[SeeAge (Christian)]

@SeeAge

h, no, I haven’t. Good that I asked. I will do this tomorrow.

Thank you for the fast feedback. I will

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.

Maybe you could add some words on how that time offset actually works for my better understanding? Thank you!

[chris (Chris Jackson)]

[quote=“SeeAge, post:20, topic:92836”]
Maybe you could add some words on how that time offset actually works for my better understanding? [/quote]

This is the difference between the time reported by the device, and your local PC time (ie the time on the machine running OH).

The thing to consider is that the offset should not be constant, but the derivative should be (generally) constant. ie the drift on the PC, and the drift on the device should be constant, and therefore rate between them should be constant. Probably your PC is being updated regularly through NTP, so that will have a 0 drift (assuming it’s updated regularly), and therefore the rate you are looking at is the rate of drift of the device.

What the binding does is periodically request this rate, and when it gets above a certain value, it resets it. So if you were to look at every value, say every minute, you would see this regularly increasing until it is reset.

The first plot in your graph has nothing before it, so this looks fine to me without actually seeing the actual data. The others in general are regular although there does look like there might be a low value in there, but that might be a graph artefact.

Anyway, I hope that helps you understand how this works?

[SeeAge (Christian)]

@chris

Anyway, I hope that helps you understand how this works?

My first understanding was that it would be a fixed value constantly displayed in the time offset item, which displays the offset between my raspi and the device (I am not sure if the raspi is synced but my FritzBox acts as a time server so it could be), but if I understand you correct the peaks that can be seen in my chart are the sync events and after the sync event, the offset is and should be zero.

FYI, the value which is not 0 for a longer period is 60 in the chart. The item actually had this value.

My main question was, if the chart looks okay like this and second if the values of the high peaks are okay like this. So you answered this question.

Do you know the unit of the time offset? Since the automatic update is only started when the time differs more than 60 seconds, I cannot explain the 10k-30k values?
In milliseconds it would be 10-30 seconds which is too less and in seconds it would be way to much.

[chris (Chris Jackson)]

@SeeAge

My first understanding was that it would be a fixed value constantly displayed in the time offset item, which displays the offset between my raspi and the device

No - it will not be a fixed value. Clocks drift at different rates. If the clock drifts at 1 minute per day, then if you look after 6 hours, the value will be 15 seconds - look in another 6 hours, it will be 30 seconds.

If there was no update for 2 days, then the value would be 120 seconds, so it is certainly possible to have values higher than expected if there was no communication for some time.

@SeeAge

Do you know the unit of the time offset?

It should be in seconds from looking at the code.

The large one is right at the beginning - maybe the time was this far out (8 or 9 hours) at some point as it hadn’t been controlled for a long time, and it was reset? After that it looks “ok”. That said, this seems to indicate that it’s drifting by 1000 seconds / day, which in itself doesn’t seem ok!

If you can grab a debug log showing the requests I’ll take a quick look.