Battery Powered devices marked as DEAD #11
Comments
|
I managed to get most things working aside from battery level and the very annoying issues with switches, linking these to homekit using node-red is causing mayham due to the multiple conflicting state changes, I backed this config so I can quickly go back to the state I am at now. But I did revert to OpenHAB for my current flow as now so I have a working setup Overall zwave2mqtt has a lot of potential but it has a few rought corners, I'm happy to help you get them fixed. If there is any extra info you need, I'll try to provide it. |
|
Did you try to set the |
|
I thank you for your feedbacks and I will try to fix them all but some bugs related with the protocols most times are related to node-openzwave and Openzwave library, maybe you can find your issues there too |
|
Well thats the thing, the device is not awake at startup because it sleeps for ~20min and then sends an update. (Unless there is movement, then it sends it imediatly) Wouldn't assume awake make it worse? I think the table should alteast load the type/product info from the zcfg.zml file in that case. I can see this getting very confusing if there are multiple battery devices. Also the type/product does not get update once the devices checks it, the node state is properly set to 'Sleep' after the first update though. --- that was a bit confusing, let me try in a few bullets
|
|
I can try to fetch the type/product from zwcfg_...xml file on init but I don't know how to detect devices as sleeping on start Try to send If so I could make an automatic function that sends the testNode to each dead device on init |
|
Does send a NIF request to the sleeping nodes on init would fix the problem? |
|
That didn't help, as the node deos not respond to a NIF command while it is sleeping. Here is the log from the startup I tried with both |
|
Node 2 being the battery powered node that is asleep, it also does not respond to test node request. The node does get the correct state after the first checkin, maybe we can just load the type/product for all nodes if it is in the config? That way I can atleast identify the really dead nodes from the ones that are marked dead but should be battery powered. Remebering which node id are the battery powered ones is a pain, but the product should make that easier. |
|
I could fetch the type/product on init but I would prefer a way to detect battery powered devices, can you find something in openzwave docs about this? Maybe by sending a wakeup command if your device supports it? I think that mark a node as dead if it doesn't respond to the initial scan is correct here and If I change this I could create errors in the case the node is really missing in my network. SO I think the best fix to this is to manually weak someway the node on init |
|
They seem to have the following command class: If is this one is present in the cached configuration, one can make a safe assumption that it is a battery powered device? But is probably better to use the WAKE_UP class to find and keep track internally if a node is overdue (dead?) or still OK. So this node checks in once every 1200 seconds, and sleeps in between. These appear to be standard command classes, so I think it is safe to assume if we have a WAKE_UP class we can mark it as 'Asleep' until the interval ~10% margin has passed and then mark it dead. Or reset the counter if it has checked in? I think the WAKE_UP class is probably better than the battery class as there might be devices that have a battery but are always on? Both devices I had for testing were the same product so there config is the same. Edit: From observation this also seems to be more or less what OpenHAB did. The device was Awake or Asleep until I removed the batteries and it missed a check in. |
|
So in brief: I should check if a 'dead' device has Are you sure there is no way that openzwave can send a request to this node to manually trigger that 'check in' ? I think this would be lot easier and more correct |
|
I have found this issue: OpenZWave/node-openzwave-shared#249 check it |
Sounds about right
Not on the once I have atleast, testNode, Send NIF, all the commands just fail.
Sounds different, after the first wake up of the node the table gets type/product update and all values start to come through. |
|
@sjorge try this commit, I have added an event Wait for your feedback |
There is a trigger fro the ndoe that is sleeping. |
|
@sjorge Check my last commit and tell me if everything works now |
|
Works fine now! |
|
Let me know if you find other bugs. Thank you @sjorge |
|
Hi @robertsLando is there any chance of getting the docker image pushed up to 3.03 that includes this. Have same issue. I can only see ARM3.03 in there. I am very new to zwave2mqtt so apologies if i have missed something |
|
@jamesarbrown I don't understand what you mean |
|
At the time the docker did not seem to have 3.03 x64, so i cleaned and docker pull again and now its running on 3.03 But, it did not fix this issue for me on a Trisensor zwa005. My device still says dead immediately after restarting zwave2mqtt and even after waiting 2 days
In the device table earlier today, also confirmed comms were active, by having an last active time of 5 hours ago. Then I looked at the logs by creating a motion event and I can see the controller communicating with it... but still shows dead
Are there any logs / tests I can provide? The only way I can get it to fix is to press the internal button for 5 sec until the little red LED comes, at which point the tables update and I get a "Sleep" status. |
|
@robertsLando would it be possible to re-open this issue? or do you think its something different and I can open a new issue? |
|
@jamesarbrown If you have refreshNodeInfo option enabled in Zwave settings please disable it |
|
I have tried the refreshnodeinfo and still the device is marked as dead after some days. I am not sure about the operating details of zwave what it needs to get out of a dead state, but as you can see from this screenshot it has woken up in the past hours and connected in. Is there anything that can be done to force a full wake up on check in, whilst the device has its zwave radio active?
|
|
@jamesarbrown Did you try to enable the option in zwave settings called Also let's see what @Fishwaldo says about this. Please @jamesarbrown add your OZW log file here |
|
Assume Awake was off.... as I thought it should assume they are asleep Then I turned it on and currently see no difference. OZWLogStartup.txt Will try to remember to do another log post after a considerable uptime |
|
Node 16 seems to be busy but still flagged as dead
1526 Log Full Log |
|
@Fishwaldo COuld you check the logs please? |
|
@robertsLando @Fishwaldo So, please find attached a node that is "DEAD" and wakes up, but sadly remains dead. Ozw2mqtt 3.2.1 |
|
I was trying to investigate and i found this It fixed my issue |
|
Looks like that option was removed #603 I wonder what the fix is now to make battery devices alive again after reboot without setting the physical to inclusion. Am I missing something? I've read thru this issue and others but there doesn't seem to be a solid conclusion... |
|
@onedr0p Just send |
|
@robertsLando so by default refreshnodeinfo is OFF and does not occur on start? |
Yes. It was making too much confusion and there was peoples that was leaving that option on and that is not good. |
|
I tried running all the commands last night and it would not come back alive. Now I woke up and I see it's working. Time heals all wounds 😅 |
|
@onedr0p Patience is the key 😆 |
|
I just restarted zwave2mqtt again and the device is dead. I am trying to run refreshnodeinfo but the device does not wake up. I know in time it will heal itself somehow but it's not ideal to wait :/ |
|
Unfortunately I have no idea how to help you with this, sorry
…---
Daniel
On 14 Jul 2020, at 21:49, Devin Buhl ***@***.***> wrote:
I just restarted zwave2mqtt again and the device is dead. I am trying to run refreshnodeinfo but the device does not wake up. I know in time it will heal itself somehow but it's not ideal to wait :/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
No worries, here are the logs and if anyone is curious the device that is problematic is the Ecolink Zwave Plus Door & Window Sensor (DWZWAVE2.5-ECO) The device is Node008. |
Some battery powered devices like
ZW100 MultiSensor 6 (AEON Labs)are detected as DEAD after stratup and do not have the type/product fields loaded. (zwcfg has the device with all the info)Under settings -> zwave I have
Assume Awaketoggled disabled.The only way for the device to show online is by manually waking it (physically) and sending a NIF request to the device. After that it will be correctly marked as sleeping
The text was updated successfully, but these errors were encountered: