updateTime is not reflected on API-Call, even though it is in Expert UI
Closed this issue · 5 comments
I have discovered an issue which doesn't make any sense and after looking at it for quite some time and I want to report it as an bug:
I have a testwise setup of a Razzberry with Z-Wave Software and successfully connected one device, a smoke sensor in this case. I want to monitor the presence of the sensor by keeping track of the update-time via API-Calls and some monitoring software.
From what I understood: I can change the Wake-Up settings of the device via the Expert-UI and can also keep track of when the device was last seen on the different UIs.
Point is: the numbers seem correct in the Expert-UI but the API then at some point won't reflect the latest wake-Up event. If I intervent manually it works again until it doesn't anymore. Values for update in the Smarthome-UI may also differ, same goes for connected Openhab (which gets called by the installed Openhab-Connector)
It didn't work at all before the latest update to 3.x IIRC but I did want to try it again after I saw the update.
I just reset the WakeupTime of the device to 8 hours and will report what happens. Also will have a look for logs, maybe some calls just get stuck, I am not into the code at that point but wonder how it is even possible that two (or three) different UIs of the same system show different values (given that it really is the same thing: updateTime of a virtual device in an API-Call, "update" Value reported for a device in the Smarthome-Webfrontend, "Updated" Value of a device in the link status of the Expert-UI.
It didn't work at all before the latest update to 3.x IIRC but I did want to try it again after I saw the update.
After looking again I think it's more that this issue is there all the time, it just doesn't reveal at first try. The effect seems to kick in not before several hours / days and most likely didn't change with the update
Could you be more specific. From this description I can not understand how to reproduce it.
Which API call specifically? Can you provide logs of HTTP requests or Z-Way logs?
Thanks for answering on this one.
After thinking again about this issue since 5 days or so I found that maybe there still are some possibilities that could explain the "error". Foremost It could also be that really the Sensor stops waking up and I just misinterpret the numbers in the expert UI (even though 2 days ago when I started this issue it was pretty obvious to me) because even the openhab values were updated properly on the latest wakeup of the sensor.
Could you give short advise:
- by HTTP-log you mean which log file?
- Z-Way log-File is clear: its /var/log/z-way-server.log, right?
The API-Call I do is a simple
http://1.2.3.4:8083/ZAutomation/api/v1/devices
With the latest update I filtered the number of devices on a per user basis, so at this time I only have two devices shown in the API-Call. The value in question then is "UpdateTime" (in Unix-Time Notation of course), which should reflect on the wake-up intervals adjustable via the Expert-UI and which also should reflect on the values I can see under
http://1.2.3.4:8083/expert/#/device/status
and there in the column "sleep" and "time".
Of course this numbers change If i interact with the device manually (for example the sensor has a tamper-Switch, so if I open the sensor the whole thing wakes up and set a new starting point for the wake-up interval).
There is a third point in the "normal" Smarthome-UI that reflects the value (and showed the "wrong" one the last time), but there you can't see a proper value but after some time it turns into "2 days ago" or something which is not very precise then after some time.
Further thinking: if the columns in the expert-UI are not reflecting the "as is" status but a "should be" status (which then is also talked over to openhab) then maybe a simple explanation would be that the sensor really just stopped waking up. But, to be honsest, this is not what I would expect .
Does this make sense so far or is there already an error in my assumptions from what you can tell?
I will try to reproduce and also will try to pin down the point in time. So far and with a wake-up interval of 8 hours everything runs smoothly since approx 2 days or 6 wake-up periods. I will report back if it happens again and I was able to more thoroughly compile the necessary information.
Then also I can get myself some more sensors and see what happens with them.
Thanks
OK, I did start over completely new with the new version, Controller reset too.
Now I also managed to connect another smoke-sensor with temperature correctly, so more data.
Now it seems that wake-up intervals don't reflect in "updateTime" altogether (which is fine at least if this the expected behavior). I can, however, state right from the start, that the temperature is not updating constantly for longer than several intervals (what is definitely not expected), but also I did play around with the wake-up intervals right from the start, which may is a culprit.
So:
Questions on how to monitor or reflect on the proper functioning of a sensor still are there, but I'm afraid I first have to get a more thorough understanding of what is going on in the logs during wake-up intervals and how to manipulate wake-up intervals, etc. - but I will try to get answers in the forum first and then come back later if I still(?) find inconsistencies that can really clearly be identified.
Of course I'm grateful if someone or you can point me in some direction. Anyway.
Regards
updateTime field is individual for each variable in the data tree. you can also look on devices[XX].data.lastReceived and devices[XX].Wakeup.data.lastWakeup.
The temperature is reported by the sensor. It can skip sending it each wakeup if it do not change. But you can request it each wakeup (do request before so it will be executed on wakeup). This is done using devices[XX].SensorMultilevel.Get(1)