Battery powered devices fail to complete interview #1364
Comments
|
This PR was included #1307 |
|
possibly related to #900 |
This might be a UI issue, Node 23 seems to be interviewed just fine once it wakes up. Node 24 shows a weird interaction of sleeping devices with restarting interviews. Here, the interview finally starts: but somehow a message from an earlier interview attempt is stuck in the wake up queue and jeopardizes the attempt that was just started. |
|
Is there some way that Smartthings and similar controllers acts differently? Is there a way to tell a node 'do not go to sleep until i say it is okay', to allow completion of the interview stage? Or, does the smartthings just rely more on old data / stored results from the initial interview? |
|
just for completeness, here's how the two devices appear in the ui |
|
As a note, before I loaded the no sleep timer branch, node 23 never got beyond the blank / nodeinfo phase, so i think that is still worthy of inclusion |
No. The device is likely sleeping already when the driver attempts to interview it. |
|
Regarding what we discussed on Slack: This does look like a message prioritization issue. All pings go through until Node 22. The query for Node 23 seems to be deprioritized in comparison with the pings. And Node 24's ping is also only done around the same time that Node 23 is quried. Can you tell me which of your devices are battery-powered? |
|
Battery powered is 23 and 24. |
That's about 15 seconds after startup. The node status should have been updated there, but it seems that doesn't happen until later: |
|
Right. And the time from Node 004's The node is alive to Node 005's The node is alive is... a full minute, give or take? Again, these times aren't that bad, I'm just wanting to make sure what's happening is what should be happening. |
|
If I don't mix anything up right now, these are the times where both nodes should have been detected as alive. 1 second apart, 17 seconds after startup: So most likely something isn't working as intended. |
|
Everything seems to be working and responding, quite a bit earlier than it was. I'm going to review the whole log once it finishes to make sure nothing seems totally out of place |
|
Looking back at this issue, the tweaks both in #1397 and in a few others do seem to have improved startup time a bit, and I see that my motion sensor now reports properly after a while (and presumably after a wakeup), however the fibaro door/window sensor still never appears to finish interviewing (and also now says unknown manufacturer/unknown, as reported elsewhere) |
|
With 6.1.1, the interview of my failed battery powered Fibaro window sensor now succeeds! Thank you! |
Describe the bug
I have two battery powered devices, a Fibaro FGK-101 door/window sensor and a few Zooz ZSE29 outdoor motion sensors.
The Fibaro device will only complete an interview on the initial deployment if I constantly push the tamper button during the interview. On a restart, it won't complete the interview even if I do that. I've tried sending the refreshinfo command while poking the buttons, no dice.
The ZSE29 seems to work a little better, but never gets past the RestartFromCache stage.
Device information
Which device(s) is/are affected (make/model)?
What are the node IDs?
node id 23 is the ZSE29
node id 24 is the FGK-101
Last Known Working Configuration
New device
Previously working device (node-zwave-js)
Previously working device (other platform)
Installation information
How did you install
node-zwave-js?node-zwave-js? disable-awake-timeout @ https://github.com/jcam/node-zwave-js/tree/disable-awake-timeoutzwavejs2mqtt? master @bfbda11cf737bd2619dd68f3c207a527e839b25cgit clone-yarn install-yarn run build:full)Logfile:
zwavejs_1.log
The text was updated successfully, but these errors were encountered: