Would you mind taking a look at the attached log file?
I’m trying to figure out why some Everspring ST-814 devices are not reporting battery level. I can’t quite follow what’s happening in the logs when nodes 5, 6, and 2 wake up. It seems like the responses don’t correlate with the requests, but I might not be interpreting it correctly.
This is the binding version (note that it’s not the new transaction code): 175 | Active | 80 | 2.0.0.201608310102 | org.openhab.binding.zwave
I agree, this looks strange. It appears too systematic to be a bug as such. It seems every time we request temperature, we get humidity, and when we request humidity we get temperature - it seems this happens every time. I can only guess that this is a bug in the device, but it’s quite strange for sure! We could say that requests are out of synch or something, but the multi_instance request swap the types as well, so we can be sure that this is happening.
I can’t really explain why this is happening. The log viewer independently decodes the frames sent and received and this is logged at a low level in the binding, so I can only assume that this is really happening.
Why it doesn’t respond to battery requests is another question - we seem to get temperatures!
I note that all responses take around 500ms which is quite slow - it might be normal for these devices though.
I would try power cycling one of them to see if anything changes.
Thanks for looking at this. It is very strange, isn’t it? Even node 2, which is reporting battery level, is reporting it out of sync.
I have 4 of these devices, all of which are misbehaving in this manner. Seems odd that all 4 would get into this state. I was thinking there might be something that is triggering it – perhaps the devices’ software is not handling a certain command properly, causing them to get into this state.
I thought of cycling power in one of them as well, but thought I’d get your opinion first. The devices are in another location, and I may not get to them for a week or two.
I’ve never used OH1. I’ve been using OH2 for several months, and this is the first I’ve noticed it. Not sure when the behavior actually started. From the perspective of temp, humidity, etc. on the UI, everything would look normal even though the reports were coming in out of sync with the requests. It was the lack of battery updates that made me look into it more closely.
Oddly, node 5 got a battery report this morning in response to a sensor_multilevel_get. :-o
I shutdown OH2, upgraded to the latest build, and restarted. I doubt the upgrade had anything to do with what follows.
In the first part of this log, the binding requests battery, then requests temp/humidity using multi_instance_encap. The device appears to respond correctly.
In the second part of this log, the binding requests temp/humidity using sensor_multilevel_get, then requests battery, then requests temp/humidity using multi_instance_encap. Here the device responds incorrectly.
This is probably caused by polling, and the polling probably uses the database configuration, so if it’s wrong, then it might request the wrong type on the endpoint. I’d be surprised if this caused the problem, it’s certainly not out of the question.
The other thing is that given the device responds on the main endpoint, we could just remove the channels from the other endpoints as they are duplicated anyway (or the other way around - remove them from the root endpoint if we get them working properly on endpoint 1 and 2).
Can you take a look in your XML and see if it looks like temperature is really endpoint 1 - I suspect it might be humidity.
Well, it’s strange… So the device says (during the device scan) that it supports humidity on endpoint 2, but then when we request humidity on endpoint 2, it responds with temperature, from endpoint 2.
So, currently I think no endpoints respond with their ‘correct’ type (ie I think in all these logs, if we request temperature, we get humidity and vice versa. So, it’s a bit of a case of ‘pick one’ - we could disable the endpoints, or the root, and see what happens.
My vote would be to disable the root. I say that because when the endpoints are used, the battery get seems to work. When the root is used, the battery get returns the temperature!
OTOH, this thing is so whacked up, it’s anyone’s guess what will happen.
As an additional thought… If you have the device set up to auto-report on a given frequency, then the polling for temperature and humidity is a bit redundant.
Yes - polling in OH2 is really there as a device health check. If you only rely on the auto reports, and they stop, then there’s no way to know if that’s because the reports have stopped, or the device is dead.
Another thing to try - change the wakeup period to 10 minutes and see what happens. I’m interested to see what the device sends when there’s no polling.
I tried to set the wake_up interval to 600 seconds. I see this in the log. but when the device wake’s up, I don’t see the new wake_up interval being sent to the device. Oddly, when I change the wake_up interval, HABmin doesn’t show it as pending like it does for the config parameters. Is this change not being placed in the wakeup queue?
I just had a quick look at the code - it’s all implemented, but there must be something fundamentally wrong if that’s all you see in the log. I’ll have to take a look at this, but it won’t be tonight I’m afraid…
It shouldn’t be. This shouldn’t impact the conditional check that you mentioned earlier which is why I said last night that something fundamental appears wrong.
I’ve written a test to test this, and it seems to work ok. I’ll push the test shortly, but I’m not sure what’s happening given that this seems to work .
.