Crash "Failed to send the command after 3 attempts (Status NoAck)"

[cthierman]

Plugin Version: 2.0.0

Platform: Linux

Problem description: sent following message to node

msg.payload ={node:10, class: "Unmanaged", operation: "SetValue", params: [{commandClass:98,endpoint:0,property:"targetMode"}, 0] // Config Param, Config Value, Value Size }

to an Assa Abloy (Yale YRD240-ZW. Caused the following crash: (note zwave2-mqtt is my hostname, i'm not using zwave-js2mqtt)

Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: ZWaveError: Failed to send the command after 3 attempts (Status NoAck) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at Object.sendDataErrorToZWaveError (/home/pi/.node-red/node_modules/zwave-js/src/lib/driver/StateMachineShared.ts:112:12) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at /home/pi/.node-red/node_modules/zwave-js/src/lib/driver/SendThreadMachine.ts:441:4 Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at /home/pi/.node-red/node_modules/xstate/lib/utils.js:410:33 Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at Array.reduce () Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at Object.updateContext (/home/pi/.node-red/node_modules/xstate/lib/utils.js:400:25) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at Object.resolveActions (/home/pi/.node-red/node_modules/xstate/lib/actions.js:409:19) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at StateNode.resolveTransition (/home/pi/.node-red/node_modules/xstate/lib/StateNode.js:787:35) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at StateNode.transition (/home/pi/.node-red/node_modules/xstate/lib/StateNode.js:733:21) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at StateNode.resolveRaisedTransition (/home/pi/.node-red/node_modules/xstate/lib/StateNode.js:738:22) Mar 19 15:27:37 zwave2-mqtt Node-RED[5633]: at StateNode.resolveTransition (/home/pi/.node-red/node_modules/xstate/lib/StateNode.js:873:39) Mar 19 15:27:43 zwave2-mqtt systemd[1]: nodered.service: Main process exited, code=exited, status=1/FAILURE Mar 19 15:27:43 zwave2-mqtt systemd[1]: nodered.service: Failed with result 'exit-code'.

Steps to reproduce: I have not been able to reliably reproduce this... It is intermittent.

[marcus-j-davies]

If this is intermittent, it sounds as if this is a network issue. have you tried healing the network?

[cthierman]

Well, yes, but a network issue should never cause nodered to crash. I.e there is a code violation that is causing node-red to crash and restart. Which in turn creates all sorts of issues. Thought it would help to send the info, as it might help to resolve the problem. I’m guessing a series of things have to align before it dies. This isn’t the first crash but it was the first with a bit of a trace back. I’ve not had this problem till I moved to zwave-js.

Hope that helps.

Sent from my iPad

On Mar 19, 2021, at 5:58 PM, Marcus Davies @.***> wrote:

 If this is intermittent, it sounds as if this is a network work issue. have you tried healing the network?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[marcus-j-davies]

Ok,

Have tracked down a very similar (if not exact) same report, but in a different host environment. See https://github.com/zwave-js/node-zwave-js/issues/1101

I thought I was catching these - obviously not.

Will be fixed in 3.0

Thanks

[marcus-j-davies]

Fixed with https://github.com/zwave-js/node-red-contrib-zwave-js/commit/0c988919d01686aacb500e57005cca3f02e21436

[cthierman]

No problem. Anyway I can help.

Im always unsure where to report stuff when there are multiple authors. You never know who’s code may be responsible. Ie Zwave-js project vs the node author.

Aside from submitting them as issues. Do you guys have a preferred way?

Sent from my iPhone

On Mar 20, 2021, at 4:22 AM, Marcus Davies @.***> wrote:

 Fixed with 0c98891

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[marcus-j-davies]

Anyway I can help.

Feel free to give the dev branch a run through (3.0) - which includes the fix 😅
A few changes that may be worth reading through.

You never know who’s code may be responsible

In this instance, the node-red module its-self, I was not awaiting on the promise setValue method of the zwave-js driver, causing it to freak out, when it failed. Now that I await, any error (i.e. a timeout) is passed to the user through the node red module, and more importantly, doesn't kill the process.

Aside from submitting them as issues. Do you guys have a preferred way?

The zwave-js project has issue templates for most things, so raising issues via the normal means, is probably preferred. though we do require logs if submitting issues specific to the zwave driver (3.0 of this repo supports logging options)

This repo (part of the zwave js umbrella) - has issue templates to use also.

👍

[cthierman]

Good to know.

It looked like most of the big reports were submitted using logs for Zwave-js2mqtt. Is that the case.

I’ll give the dev track a try.

I may try using Zwave-js2mqtt to report an issue I’m seeing with my Yale lock being reported as dead. I noticed it has the same problem with Zwave-js2mqtt. And it’s only four feet line of sight from the aeotec Zwave stick.

It always works fine if someone touches the lock. So it only effects my ability to send commands to the lock when it thinks it’s dead.

Must have some issue with sleeping I’m guessing.

Anyway. Thanks for the help. Will let you know the results.

Sent from my iPhone

On Mar 20, 2021, at 1:54 PM, Marcus Davies @.***> wrote:

 Anyway I can help.

Feel free to give the dev branch a run through (3.0) - which includes the fix 😅 A few changes that may be worth reading through.

You never know who’s code may be responsible

In this instance, the node-red module its-self, I was not awaiting on the promise setValue method of the zwave-js driver, causing it to freak out, when it failed. Now that I await, any error (i.e. a timeout) is passed to the user through the node red module, and more importantly, doesn't kill the process.

Aside from submitting them as issues. Do you guys have a preferred way?

The zwave-js project has issue templates for most things, so raising issues via the normal means, is probably preferred. though we do require logs if submitting issues specific to the zwave driver (3.0 of this repo supports logging options)

This repo (part of the zwave js umbrella) - has issue templates to use also.

👍

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[marcus-j-davies]

Yup, Zwavejs2mqtt is a popular front end to zwave-js, so you will see, a lot of logs generated from it

the zwave-js org comprises of: zwave-js (The main zwave stack) Zwavejs2mqtt (MQTT Front End) node-red-contrib-zwave-js (Node-Red support) zwave-js-server (Home Assistant Daemon)

All expose the logging provided by the main stack.

[cthierman]

Yup, just installed node-redcontrib-zwave-js#dev ... Nice I see you added logging... Awesome!

Thanks... Will keep you posted to what I find.. I'll try and be as helpful as possible. I know what it can be like...

Thanks again.. BTW. Love what you've done so far.. I've been porting over my zwave interface from openzwave to zwave-js...

Had to back out because zwave-js had some issues with the likes of my battery Door/Window devices.. It could never learn them when I had my other 20 odd nodes running. They came up fine on openzwave. I concluded it had something to do with all the CommandClass 50 traffic being generated from my power bars etc..

So, broke it into two networks for now. One with my Door locks and a couple of Aeotec ZW096's ... And my other zwave network, with all the different Window sensors, etc.. Both are using two different Raspberry Pi's. One PI 3, and one pi 4. Both using Aeotec zwave sticks...

It's been interesting seeing some of the differences.. Like my zooz power bars.. openzwave uses and index of 1 to report the total power being used by the bar, also if you send CommandClass 37 to the index 1, it turns off the master for the bar... But zwave-js, seems to get confused.. index one seems to still report the power for the whole bar, but the commandclass 37 seems to just turn on and off the first switch... They seem to align when you get to index two. Meaning you loose visibility to the first channel on the power bar.

I decided to just move back to openzwave for those, instead of trying to figure out where the problem is... Didn't try that under zwave-js2mqtt... Also didn't bother to report it until I had more details.. so, pretend I didn't mention it.. more just an observation at this time... When I feel up to it, I'll try moving one of the power bars back to zwave-js and collect some logging info.... but right now my focus is getting my door locks stable and moving them off the Vera.

Anyway, really awesome stuff. -Chris

On Sat, Mar 20, 2021 at 3:26 PM Marcus Davies @.***> wrote:

Yup, Zwavejs2mqtt is a popular front end to zwave-js, so you will see, a lot of logs generated from it)

the zwave-js org comprises of: zwave-js (The main zwave stack) Zwavejs2mqtt (MQTT Front End) node-red-contrib-zwave-js (Node-Red support) zwave-js-server (Home Assistant Daemon)

All expose the logging provided by the main stack.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-803465570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HGYE6FW6E72YN6QYMLTEUHGRANCNFSM4ZPUO74A .

[marcus-j-davies]

If you're getting funny things going on, open an issue on the main repo - it will get reacted too pretty quickly.

OR - if your on slack. https://join.slack.com/t/zwave2mqtt/shared_invite/zt-8ns655f6-d407vtI~KjU~1z11jyaQ9Q

another valuable source, is our supported device DB https://devices.zwave-js.io/

[cthierman]

Going to see what happens... So far since I installed this latest version, the Yale Doorlock has not reported as Dead.. This is good.... :-) -Chris

On Sat, Mar 20, 2021 at 4:28 PM Marcus Davies @.***> wrote:

If you're getting funny things going on, open an issue on the main repo - it will get reacted too pretty quickly.

OR - if your on slack.

https://join.slack.com/t/zwave2mqtt/shared_invite/zt-8ns655f6-d407vtI~KjU~1z11jyaQ9Q

another valuable source, is our supported device DB https://devices.zwave-js.io/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-803472571, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HBN57AZUGVT3WXEN4LTEUOPNANCNFSM4ZPUO74A .

[cthierman]

Hey Marcus,

Quick question for you... I notice now, whenever I do a commit, my lock goes from UNKNOWN to DEAD... It stays dead till I go and do somthing with it.. Like a sleeping node, but I don't think Yale Locks follow the typical node sleep. since they have to receive lock codes, unlike a sensor that just reports..

In anycase, looking at the log, it looks like it tries to ping the lock and gets no reply, hence the DEAD status... Is this something that should be opened with the zwave-js group, or is this something I bring to yourself.

Here is the output from the LOG. The Yale lock is node 10... And, other than this, it's working great!

2021-03-22T01:54:24.812Z SERIAL « 0x0110000400060a3202217400000208000088 (18 bytes) 2021-03-22T01:54:24.814Z CNTRLR [Node 006] [~] [Meter] value[66049]: 0 => 0.52 [Endpoint 0] 2021-03-22T01:54:24.815Z SERIAL » [ACK] (0x06) 2021-03-22T01:54:31.909Z SERIAL « 0x0107001304010a7c98 (9 bytes) 2021-03-22T01:54:31.910Z SERIAL » [ACK] (0x06) 2021-03-22T01:54:31.916Z DRIVER « [REQ] [SendData] callback id: 4 transmit status: NoAck 2021-03-22T01:54:31.926Z CNTRLR [Node 010] Node 10 did not respond after 1 attempts, it is presumed dead 2021-03-22T01:54:31.927Z CNTRLR [Node 010] The node is dead. 2021-03-22T01:54:31.928Z CNTRLR All nodes are ready to be used 2021-03-22T01:54:31.933Z CNTRLR [Node 010] ping failed: Failed to send the command after 1 attempts (Status No Ack) 2021-03-22T01:54:32.998Z SERIAL « 0x0110000400060a3202217400000000000082 (18 bytes) 2021-03-22T01:54:33.000Z CNTRLR [Node 006] [~] [Meter] value[66049]: 0.52 => 0 [Endpoint 0]

On Sat, Mar 20, 2021 at 7:27 PM Chris Thierman @.***> wrote:

Going to see what happens... So far since I installed this latest version, the Yale Doorlock has not reported as Dead.. This is good.... :-) -Chris

On Sat, Mar 20, 2021 at 4:28 PM Marcus Davies @.***> wrote:

If you're getting funny things going on, open an issue on the main repo - it will get reacted too pretty quickly.

OR - if your on slack.

https://join.slack.com/t/zwave2mqtt/shared_invite/zt-8ns655f6-d407vtI~KjU~1z11jyaQ9Q

another valuable source, is our supported device DB https://devices.zwave-js.io/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-803472571, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HBN57AZUGVT3WXEN4LTEUOPNANCNFSM4ZPUO74A .

[marcus-j-davies]

Hey!

So, Battery operated nodes that need to stay a wake, work on a protocol called FLiRS. FLiRS devices go into a very low powered state, then spring back to life, when a message has been received by them. FLiRS devices, are very much supported by ZWave JS, I have 2 battery operated alarm keypads, that work perfectly.

With that in mind, Zwave JS 7 went through some major re-work, to speed up things even further. Before submitting a bug to ZWave JS, I want to know if the network cache file from (V6) is still in use (since you migrated to V7).

Lets investigate.... Send the following, to get a footprint of all your nodes. attach the output to the debug node, and copy /paste the result here.

{
  payload: {
    class: "Controller",
    operation: "GetNodes"
  }
}

[cthierman]

Here are the results: {"payload":{"node":"Controller","event":"NODE_LIST","timestamp":"2021-03-22T12:53:46.795Z","object":[{"nodeId":1,"status":"Alive","ready":true,"interviewStage":"Complete","isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":false,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x0086/zw090.json","manufacturer":"AEON Labs","manufacturerId":134,"label":"ZW090","description":"Z‐Stick Gen5 USB Controller","devices":[{"productType":1,"productId":90},{"productType":257,"productId":90},{"productType":513,"productId":90}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}},"metadata":{"reset":"Use this procedure only in the event that the primary controller is missing or otherwise inoperable.\n\nPress and hold the Action Button on Z-Stick for 20 seconds and then release","manual":" https://products.z-wavealliance.org/ProductManual/File?folder=&filename=MarketCertificationFiles/1355/Z%20Stick%20Gen5%20manual%201.pdf"}},"isControllerNode":true},{"nodeId":5,"status":"Alive","ready":true,"interviewStage":"Complete","zwavePlusVersion":1,"zwavePlusNodeType":0,"zwavePlusRoleType":5,"isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":true,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x0086/zw096.json","manufacturer":"AEON Labs","manufacturerId":134,"label":"ZW096","description":"Smart Switch 6","devices":[{"productType":3,"productId":96},{"productType":259,"productId":96},{"productType":515,"productId":96},{"productType":7427,"productId":96}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}}},"isControllerNode":false},{"nodeId":6,"status":"Alive","ready":true,"interviewStage":"Complete","zwavePlusVersion":1,"zwavePlusNodeType":0,"zwavePlusRoleType":5,"isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":true,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x0086/zw096.json","manufacturer":"AEON Labs","manufacturerId":134,"label":"ZW096","description":"Smart Switch 6","devices":[{"productType":3,"productId":96},{"productType":259,"productId":96},{"productType":515,"productId":96},{"productType":7427,"productId":96}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}}},"isControllerNode":false},{"nodeId":7,"status":"Alive","ready":true,"interviewStage":"Complete","zwavePlusVersion":1,"zwavePlusNodeType":0,"zwavePlusRoleType":5,"isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":true,"supportedDataRates":[40000,100000],"maxDataRate":100000,"supportsSecurity":false,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x027a/zen25.json","manufacturer":"Zooz","manufacturerId":634,"label":"ZEN25","description":"Double Plug","devices":[{"productType":40960,"productId":40963}],"firmwareVersion":{"min":"0.0","max":"255.255"},"paramInformation":{"_map":{}}},"isControllerNode":false},{"nodeId":10,"status":"Dead","ready":false,"interviewStage":"Complete","isListening":false,"isFrequentListening":"1000ms","canSleep":false,"isRouting":true,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":true,"protocolVersion":"4.5x / @.***/config/config/devices/0x0129/yrd220.json","manufacturer":"Yale","manufacturerId":297,"label":"YRD220 / YRD240","description":"Real Living Touchscreen Deadbolt","devices":[{"productType":2,"productId":0},{"productType":2,"productId":521},{"productType":2,"productId":43520},{"productType":2,"productId":65535},{"productType":8226,"productId":521}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}}},"isControllerNode":false}]},"_msgid":"a0fddc01.81415"}

On Mon, Mar 22, 2021 at 1:53 AM Marcus Davies @.***> wrote:

Hey!

So, Battery operated nodes that need to stay a wake, work on a protocol called FLiRS. FLiRS devices go into a very low powered state, then spring back to life, when a message has been received by them. FLiRS devices, are very much supported by ZWave JS, I have 2 battery operated alarm keypads, that work perfectly.

With that in mind, Zwave JS 7 went through some major re-work, to speed up things even further. Before submitting a bug to ZWave JS, I want to know if the network cache file from (V6) is still in use (since you migrated to V7).

Lets investigate.... Send the following, to get a footprint of all your nodes. attach the output to the debug node, and copy /paste the result here.

{ payload: { class: "Controller", operation: "GetNodes" } }

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-803846452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HC3J7FT3TSTND6L2Z3TE3ZP3ANCNFSM4ZPUO74A .

[cthierman]

Thought it might be easier to deal with a formatted json file.. so here is the same result in a file.

On Mon, Mar 22, 2021 at 6:56 AM Chris Thierman @.***> wrote:

Here are the results: {"payload":{"node":"Controller","event":"NODE_LIST","timestamp":"2021-03-22T12:53:46.795Z","object":[{"nodeId":1,"status":"Alive","ready":true,"interviewStage":"Complete","isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":false,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x0086/zw090.json","manufacturer":"AEON Labs","manufacturerId":134,"label":"ZW090","description":"Z‐Stick Gen5 USB Controller","devices":[{"productType":1,"productId":90},{"productType":257,"productId":90},{"productType":513,"productId":90}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}},"metadata":{"reset":"Use this procedure only in the event that the primary controller is missing or otherwise inoperable.\n\nPress and hold the Action Button on Z-Stick for 20 seconds and then release","manual":" https://products.z-wavealliance.org/ProductManual/File?folder=&filename=MarketCertificationFiles/1355/Z%20Stick%20Gen5%20manual%201.pdf"}},"isControllerNode":true},{"nodeId":5,"status":"Alive","ready":true,"interviewStage":"Complete","zwavePlusVersion":1,"zwavePlusNodeType":0,"zwavePlusRoleType":5,"isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":true,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x0086/zw096.json","manufacturer":"AEON Labs","manufacturerId":134,"label":"ZW096","description":"Smart Switch 6","devices":[{"productType":3,"productId":96},{"productType":259,"productId":96},{"productType":515,"productId":96},{"productType":7427,"productId":96}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}}},"isControllerNode":false},{"nodeId":6,"status":"Alive","ready":true,"interviewStage":"Complete","zwavePlusVersion":1,"zwavePlusNodeType":0,"zwavePlusRoleType":5,"isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":true,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x0086/zw096.json","manufacturer":"AEON Labs","manufacturerId":134,"label":"ZW096","description":"Smart Switch 6","devices":[{"productType":3,"productId":96},{"productType":259,"productId":96},{"productType":515,"productId":96},{"productType":7427,"productId":96}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}}},"isControllerNode":false},{"nodeId":7,"status":"Alive","ready":true,"interviewStage":"Complete","zwavePlusVersion":1,"zwavePlusNodeType":0,"zwavePlusRoleType":5,"isListening":true,"isFrequentListening":false,"canSleep":false,"isRouting":true,"supportedDataRates":[40000,100000],"maxDataRate":100000,"supportsSecurity":false,"isSecure":false,"protocolVersion":"4.5x / @./config/config/devices/0x027a/zen25.json","manufacturer":"Zooz","manufacturerId":634,"label":"ZEN25","description":"Double Plug","devices":[{"productType":40960,"productId":40963}],"firmwareVersion":{"min":"0.0","max":"255.255"},"paramInformation":{"_map":{}}},"isControllerNode":false},{"nodeId":10,"status":"Dead","ready":false,"interviewStage":"Complete","isListening":false,"isFrequentListening":"1000ms","canSleep":false,"isRouting":true,"supportedDataRates":[40000],"maxDataRate":40000,"isSecure":true,"protocolVersion":"4.5x / @.***/config/config/devices/0x0129/yrd220.json","manufacturer":"Yale","manufacturerId":297,"label":"YRD220 / YRD240","description":"Real Living Touchscreen Deadbolt","devices":[{"productType":2,"productId":0},{"productType":2,"productId":521},{"productType":2,"productId":43520},{"productType":2,"productId":65535},{"productType":8226,"productId":521}],"firmwareVersion":{"min":"0.0","max":"255.255"},"associations":{},"paramInformation":{"_map":{}}},"isControllerNode":false}]},"_msgid":"a0fddc01.81415"}

On Mon, Mar 22, 2021 at 1:53 AM Marcus Davies @.***> wrote:

Hey!

So, Battery operated nodes that need to stay a wake, work on a protocol called FLiRS. FLiRS devices go into a very low powered state, then spring back to life, when a message has been received by them. FLiRS devices, are very much supported by ZWave JS, I have 2 battery operated alarm keypads, that work perfectly.

With that in mind, Zwave JS 7 went through some major re-work, to speed up things even further. Before submitting a bug to ZWave JS, I want to know if the network cache file from (V6) is still in use (since you migrated to V7).

Lets investigate.... Send the following, to get a footprint of all your nodes. attach the output to the debug node, and copy /paste the result here.

{ payload: { class: "Controller", operation: "GetNodes" } }

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-803846452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HC3J7FT3TSTND6L2Z3TE3ZP3ANCNFSM4ZPUO74A .

[marcus-j-davies]

So, the bits I wanted to check where.

"interviewStage": "Complete",
"isFrequentListening": "1000ms"

This tells us that, ZWave JS, knows it's a FLiRS device (1000ms wake up frequency) This really leaves only 2 possibilities.

• Network issues, but then you mentioned you can interact with it, and send it commands - so that doesn't make sense.
• The device does not follow specification - this is a real possibility. Z Wave JS has been built to follow spec, but some devices do not follow specification (when they should be). ZWave JS does support providing compatibility flags for non compliance devices

One last thing we can try (which will retrigger an interview on your network)

• Kill node-red (therefore the driver).
• Delete the folder /%home%/.node-red/zwave-j-cache
• Start node-red
• Allow ~4-5 minutes for your devices to be interviewed (providing they are not sleeping)
• Check if all devices have been interviewed (GetNodes to check the status)
• Heal Network (connect output to debug), as it will tell you when its complete

{
  payload: {
    class: "Controller",
    operation: "StartHealNetwork"
  }
}

Once healed, see if anything is different (or now behaving correctly), if not, and it is still being reported as dead - then it may be worth reporting it as a bug.

[cthierman]

Well.. So far so good. I did all of that at 8am my time today. And it's 3:27pm and it has not reported the node as DEAD. Though the interview process was painful as it kept reporting the node as dead, so I would go and unlock or lock the lock manually which would cause it to continue the interview process till it got through all 100 User codes, and then everything was good.

Thanks for your help. -Chris

On Mon, Mar 22, 2021 at 7:35 AM Marcus Davies @.***> wrote:

So, the bits I wanted to check where.

"interviewStage": "Complete", "isFrequentListening": "1000ms"

This tells us that, ZWave JS, knows it's a FLiRS device (1000ms wake up frequency) This really leaves only 2 possibilities.

• Network issues, but then you mentioned you can interact with it, and send it commands - so that doesn't make sense.
• The device does not follow specification - this is a real possibility. Z Wave JS has been built to follow spec, but some devices do not follow specification (when they should be). ZWave JS does support providing compatibility flags for non compliance devices

One last thing we can try (which will retrigger an interview on your network)

• Kill node-red (therefore the driver).
• Delete the folder /%home%/.node-red/zwave-j-cache
• Start node-red
• Allow ~4-5 minutes for your devices to be interviewed (providing they are not sleeping)
• Check if all devices have been interviewed (GetNodes to check the status)
• Heal Network (connect output to debug), as it will tell you when its complete

{ payload: { class: "Controller", operation: "StartHealNetwork" } }

Once healed, see if anything is different (or now behaving correctly), if not, and it is still being reported as dead - then it may be worth reporting it as a bug.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-804065959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HBE4MUFOL5CZCGSCQLTE5BS3ANCNFSM4ZPUO74A .

[cthierman]

Nuts. I shouldn't have sent that... As soon as I did, I did a deploy in node red. And as soon as I did, it went to status UNKNOWN, and then DEAD.

Is there a way for me to force the zwave controller to treat the node as awake? ie, allow we to send a command to it.. cause, it seems to respond fine if I don't do a deploy.

I can live with it as is, till someone else reports the problem. Since I know exactly what I need to do to fix, since I just have to get the device to send something to the zwave controller to make it think it's ALIVE again. Then it seems stable till the next deploy.

On Mon, Mar 22, 2021 at 3:29 PM Chris Thierman @.***> wrote:

Well.. So far so good. I did all of that at 8am my time today. And it's 3:27pm and it has not reported the node as DEAD. Though the interview process was painful as it kept reporting the node as dead, so I would go and unlock or lock the lock manually which would cause it to continue the interview process till it got through all 100 User codes, and then everything was good.

Thanks for your help. -Chris

On Mon, Mar 22, 2021 at 7:35 AM Marcus Davies @.***> wrote:

So, the bits I wanted to check where.

"interviewStage": "Complete", "isFrequentListening": "1000ms"

This tells us that, ZWave JS, knows it's a FLiRS device (1000ms wake up frequency) This really leaves only 2 possibilities.

• Network issues, but then you mentioned you can interact with it, and send it commands - so that doesn't make sense.
• The device does not follow specification - this is a real possibility. Z Wave JS has been built to follow spec, but some devices do not follow specification (when they should be). ZWave JS does support providing compatibility flags for non compliance devices

One last thing we can try (which will retrigger an interview on your network)

• Kill node-red (therefore the driver).
• Delete the folder /%home%/.node-red/zwave-j-cache
• Start node-red
• Allow ~4-5 minutes for your devices to be interviewed (providing they are not sleeping)
• Check if all devices have been interviewed (GetNodes to check the status)
• Heal Network (connect output to debug), as it will tell you when its complete

{ payload: { class: "Controller", operation: "StartHealNetwork" } }

Once healed, see if anything is different (or now behaving correctly), if not, and it is still being reported as dead - then it may be worth reporting it as a bug.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-804065959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HBE4MUFOL5CZCGSCQLTE5BS3ANCNFSM4ZPUO74A .

[marcus-j-davies]

Then it seems stable till the next deploy.

This makes sense, as during driver start up, it will ping FLiRS devices, to ensure they are not dead (my alarm keypad LED flickers during deploy) as it has a setting to show activity on the panel

This does sound like the device does not respond to pings however (which is a breach in zwave specification).

I'm not aware of being able to force its status to alive within the driver. One way potentially, is get the device to send something (so it becomes alive).

THEN

See if there is a config parameter to change the battery report interval, and set it to a shorter time. check the database to see if there is a param OR the user manual, if one does exist (but isn't in the database, we can add it).

https://devices.zwave-js.io/

As for the device, its self it may be a firmware bug (might be worth checking if there is an update).

EIDT Are you using custom timeouts in the node config - i generally leave them as default

EDIT 2: What model is it

[marcus-j-davies]

Another thought.

You could change the deploy mode, to only deploy changed nodes - so if the zwave node its self, doesn't change, it will hold its state (and not be restarted).

[cthierman]

Gosh.... I hadn't noticed that change.... And it looks like that was as long ago as 1.0.0... Guess I just never look at the menus anymore... sigh.. Thanks.. I'll give that a try moving forward.

So, looked for new firmware, sadly Yale/ASSA Abloy doesn't appear to have released any new firmware for the YRD220/YRD240 at any time that I can find.... Looked through the website db, and looked at ASSA ABLOYs Z-wave Plus System integrators Guide and doesn't look like there are any published settings to effect anything that looks like it might effectively change it's behaviour... With respect to checking in..

Interestingly though, I had this lock paired with my VERAPLUS system, and it never had this problem... So makes me wonder if they had info that maybe isn't published with respect to a way to ping the device that it responds to... Or a setting to make the device check in once in a while.

In anycase, I'll just live with it for now... Not the worst thing, since I know how to work around it...

I have another lock I plan to migrate, a schlage lock, but I first have to port some of my logic off the vera to node-red. Most of it all was ported when I migrated the Yale lock to node-red using your zwave-js module, but there are a few things left to move.

Thanks for the help. Had moved most of my zwave devices off the Vera to openzwave, but found the locks just didn't port well, especially as a security device. So I moved them back to theVeraPlus till I had another solution.

Then with the work being done on zwave-js and how much faster/more reliable it is... I'm slowly moving what I can to zwave-js. But I found the chatty nature of all these power devices, appears to leave them hogging all the zwave bandwidth.

But maybe that all got fixed with 7.0...I have all the zwave interaction being managed by their own Raspberry Pi's which use the MQTT bus to send reports and receive commands from the central node-red brain running on an intel NUC.. Moving things is reasonably easy once I've written the basic handlers to get the messages into a standardized MQTT message....

It's been fun.. I've integrated ISY Devices, HUE devices, my Vista Alarm panel, Lutron devices, zwave of course, and Energy Curb power reports, plus some weather station data. Each technology has it's own Raspberry PI dedicated to it, running Node-red, which posts data onto the MQTT bus allowing anything else to subscribe, and action. But 98% of the actions are all on the central brain...

anyway.. This is great stuff again.. Love what you guys have done... And thanks again for the help... I'll try and help out where I can... -Chris

On Mon, Mar 22, 2021 at 4:40 PM Marcus Davies @.***> wrote:

Another thought.

You could change the deploy mode, to only deploy changed nodes - so if the zwave node its self, doesn't change, it will hold its state (and not be restarted).

[image: image] https://user-images.githubusercontent.com/55892693/112067154-81c11200-8b5f-11eb-9be9-b320e94ef0cd.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-804442845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HAMFF4E3HHYDM26EBLTE7BNZANCNFSM4ZPUO74A .

[cthierman]

OMG, I am so embarrassed... I'm pretty sure that has been there since before node-red 1.0.0. I think I tried to use it once, but didn't realize you had to hit deploy after... So, I've been doing a full deploy ever since... I have so many nodes talking to so many different devices on my main node, each time doing a reload before.. This makes life so much easier... Again, I'm so embarrassed that I didn't see that... Thanks again... Guess it pays to ask questions.. lol -Chris

On Mon, Mar 22, 2021 at 4:40 PM Marcus Davies @.***> wrote:

Another thought.

You could change the deploy mode, to only deploy changed nodes - so if the zwave node its self, doesn't change, it will hold its state (and not be restarted).

[image: image] https://user-images.githubusercontent.com/55892693/112067154-81c11200-8b5f-11eb-9be9-b320e94ef0cd.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-red-contrib-zwave-js/issues/29#issuecomment-804442845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHZ2HAMFF4E3HHYDM26EBLTE7BNZANCNFSM4ZPUO74A .

[marcus-j-davies]

3.0 released