skunkiechris Posted January 23, 2019 Posted January 23, 2019 I see this on many wireless devices after performing a network heal - the device wakes up later on and ISY starts to do a heal, but immediately puts the device back to sleep, and thus it obviously times out. Is there another way to get these devices to participate in the heal? @Chris Jahn would it help to turn off the 'automatically put battery devices back to sleep' function for the next 24 hours after the heal in order to try and catch all battery devices and prevent this behavior? (Although that seems like it should be unnecessary, and would also seem to be a battery drain...) Wed 01/23/2019 05:39:58 PM : [ZWAVE-WAKEUP 92] Awake with pending work ZW092_1 Wed 01/23/2019 05:39:59 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : Time allowed=136 seconds Wed 01/23/2019 05:39:59 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : working ... Wed 01/23/2019 05:39:59 PM : [ZWAVE-WAKEUP 92] Awake with no pending work, putting back to sleep ZW092_1 Wed 01/23/2019 05:40:11 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : working ... Wed 01/23/2019 05:40:17 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : working ... Wed 01/23/2019 05:40:37 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : Timed Out Thanks!
Techman Posted January 23, 2019 Posted January 23, 2019 37 minutes ago, skunkiechris said: I see this on many wireless devices after performing a network heal - the device wakes up later on and ISY starts to do a heal, but immediately puts the device back to sleep, and thus it obviously times out. Is there another way to get these devices to participate in the heal? @Chris Jahn would it help to turn off the 'automatically put battery devices back to sleep' function for the next 24 hours after the heal in order to try and catch all battery devices and prevent this behavior? (Although that seems like it should be unnecessary, and would also seem to be a battery drain...) Wed 01/23/2019 05:39:58 PM : [ZWAVE-WAKEUP 92] Awake with pending work ZW092_1 Wed 01/23/2019 05:39:59 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : Time allowed=136 seconds Wed 01/23/2019 05:39:59 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : working ... Wed 01/23/2019 05:39:59 PM : [ZWAVE-WAKEUP 92] Awake with no pending work, putting back to sleep ZW092_1 Wed 01/23/2019 05:40:11 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : working ... Wed 01/23/2019 05:40:17 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : working ... Wed 01/23/2019 05:40:37 PM : [ZWAVE-HEAL 92] Updating Neighbors for 'ZW 092 Notify Sensor' : Timed Out Thanks! The ISY has no control over when the battery operated device goes to sleep. it's possible that the device times out before the heal is completed. What device are you trying to heal? The stay awake time is controlled by the device's firmware
skunkiechris Posted January 24, 2019 Author Posted January 24, 2019 1 hour ago, Techman said: The ISY has no control over when the battery operated device goes to sleep. it's possible that the device times out before the heal is completed. What device are you trying to heal? The stay awake time is controlled by the device's firmware How often the device wakes up and checks in is handled by the device (and is configurable). But the actual process after waking up is handled by the controller. The device sends the wake_up command class, the controller in turn processes what, if anything, is queued for it, and tells the device when it's clear to go back to sleep. If the device doesn't get a response from the controller after initially sending the wake_up class it will go back to sleep on its own after a predetermined amount of time, but in this case the ISY appears to be sending the command to go back to sleep while work is still pending. In this case, the ISY seems to be telling the device to go back to sleep in the midst of the queued work...unless there is some other failure causing ISY to put it back to sleep that isn't in the log. Conversely, here's an identical sensor (same brand and parameter settings) that was handled correctly: Wed 01/23/2019 06:56:24 PM : [ZWAVE-WAKEUP 55] Awake with pending work ZW055_1 Wed 01/23/2019 06:56:24 PM : [ZWAVE-WAKEUP 55] Network Heal awakened device ZW055_1 Wed 01/23/2019 06:56:24 PM : [ZWAVE-HEAL 55] Updating Neighbors for 'Kitchen Cabinet Notify Sensor' : Time allowed=136 seconds Wed 01/23/2019 06:56:25 PM : [ZWAVE-HEAL 55] Updating Neighbors for 'Kitchen Cabinet Notify Sensor' : working ... Wed 01/23/2019 06:56:26 PM : [ZWAVE-HEAL 55] Updating Neighbors for 'Kitchen Cabinet Notify Sensor' : working ... Wed 01/23/2019 06:56:27 PM : [ZWAVE-HEAL 55] Updating Neighbors for 'Kitchen Cabinet Notify Sensor' : working ... Wed 01/23/2019 06:56:38 PM : [ZWAVE-HEAL 55] Updating Neighbors for 'Kitchen Cabinet Notify Sensor' : Success Wed 01/23/2019 06:56:38 PM : [ZWAVE-HEAL 55] Assigning Routes to 'Kitchen Cabinet Notify Sensor' Wed 01/23/2019 06:56:57 PM : [ZWAVE-WAKEUP 55] Put back to sleep ZW055_1 The brand/type of sensor is irrelevant as this seems to occur intermittently across any/all of them. One that is put to sleep too soon in one heal will be successful in the next. It's tough to catch this since the only way to do so is to leave the event log running for hours after the heal is "complete" (or longer as some devices can have very long wakeup intervals, I know at least a few of mine are 24 hours) and then later search the log for "heal" to view the results. Thinking about it, I haven't let the log run at level 3 while this occurs, so I guess that's worthwhile to see if there is something that stands out on these occasions that isn't captured in level 1 that might be responsible, so I'll give that a shot and see what it looks like.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.