PART 1:
Sometimes on restarting z-way-server, SOME (not all) battery devices will switch into a dead state (isFailed.value=true). Not sure the cause of this, unlikely as my wake up intervals are 86400 but maybe this is because right as z-way-server is restarting its expecting the wake up interval to hit... And it doesn't? Not sure.
PART 2:
The problem with this is as follows:
When a device is isFailed.value=true, and this device sends out an unsolicited report (eg: temperature sensor, humidty sensor, etc), z-way-server will try to send out NOP packets right after to get a reply and flip it back into isFailed.value=false. I have verified this via zsniffer as well as "red" text in the timing info panel in /expert.
The problem with this is that for high frequency reporting devices (eg: 5 minutes, but any really) that have a high wakeup interval (eg: 86400 seconds)... Every unsolicited report will result in quite a few NOP packets being sent out and no reply coming back until the wakeup interval really does hit and the device is flipped back into isFailed.value=false.
Solution (Real):
Find out whats causing the devices to flip into isFailed.value=true and maybe adjust the NOP sending logic a little to send out those packets only on wake up notification?
Solution (Temp):
This is what I am running at startup to fake set each device to isFailed.value=false... Yeah, this will set all my battery devices to isFailed.value=false even if they really are failed... But I'm ok with that. Oh, this also fixes the "blinking blue light" / "starts up in inclusion mode" in 5.36 on UZB. The timeout is there to give it some time to settle, possibly not needed but better safe than sorry.
Code: Select all
setTimeout(function(){
zway.AddNodeToNetwork(0);
Object.keys(zway.devices).forEach(function(zwaveid){
try{
var device=zway.devices[zwaveid];
if(!device.data.isListening.value&&device.data.isFailed.value){
zway.devices[zwaveid].data.isFailed.value=false;
}
}
catch(e){}
});
},60000);