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.
[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?
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.
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.
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.