Command execution failure

[fabnavigator]

I see a bunch of the below message in the log. Never 2/3 or 3/3. Does that mean that the command always worked on the second try?

CNTRLR   Failed to execute controller command after 1/3 attempts. Scheduling next try in 100 ms.

Also, if I want to guage my network traffic, does the controller node generate an event for every bit of traffic?

[marcus-j-davies]

I see a bunch of the below message in the log. Never 2/3 or 3/3. Does that mean that the command always worked on the second try?

Correct - if your seeing a lot of them, it might just be a side affect of the TCP connection being woken up maybe 🤷
other then that, it means exactly what it says - the driver isn't going to wait for eternity to get a response, so if it doesn't Get a response from your controller first time around. it will try again after a few ms - its common to see it, but then if your seeing side affects it might be worth investigating why the controller is taking its time (again it might just be a side affect of using TCP)

Also, if I want to guage my network traffic, does the controller node generate an event for every bit of traffic?

it will log all traffic in debug logs (addressed at the controller) - but wont present anything to the user that is of no functional use.

I use a ZWave Sniffer device, and this logs ALL traffic 'outside' of NR (regardless if its your network or not) if you have a spare Stick (that is compatible) I have the specialised FW for them

Lastley, if you want to get more data.

let Message = {
    payload: {
        mode: "DriverAPI",
        method: "getControllerStatistics",
    }
}
return Message

OR

let Message = {
    payload: {
        mode: "DriverAPI",
        method: "getNodeStatistics",
        params: [...<NodeIDs>] /* Optional */
    }
}
return Message

the above is used for the map performance figures

[fabnavigator]

@marcus-j-davies Thank you. I do have a couple of spare sticks. A Zooz ZST10 700 and an Aeotec Z-Stick Gen5. Is it hard to setup the sniffer?

[marcus-j-davies]

The sniffer FW works in connection with the windows application.

it listens to ALL zwave traffic, and logs them in a windows application (its what I use to ensure things reported in NR are correct).
Let me investigate - I have a few FW files for different regions, but not sure if you need a certain chipset on the stick.

1 - Using the Zwave Stick Programmer, flash the stick with Sniffer FW (I have the app)
2 - Install Silabs Sniffer software (I have)
3 - Connect stick to windows machine
4 - Start recording any traffic it sees

[fabnavigator]

When are the controller and node statistics zeroed out?

[marcus-j-davies]

Ok, sadly - you do need a certain stick to sniff the network traffic

I have the "ACC-UZB3-E-STA" (this is the EU version) as my sniffer - its Silabs own stick
for you, its likely "ACC-UZB3-U-STA"

you flash this stick with the Sniffer FW.

This is my network when triggering motion and entering numbers on my keypad

from the above - I can see Node 2 routes for 7

[fabnavigator]

I ordered the ACC-UZB3-U-STA. I might need some more help when it arrives.

[marcus-j-davies]

When are the controller and node statistics zeroed out?

when you restart NR/or restart the controller node

[fabnavigator]

So, pretty much all of the time. 😄

[fabnavigator]

Do you think there is any point revisiting getting me of the TCP? Maybe something has been updated/fixed? Or... I could think about getting off docker.

[marcus-j-davies]

So, pretty much all of the time

The stats will only reset when the controller node is initialised.
So if you make flow changes and only deploy those specific changes, then the stats will remain, if deploying changes to the flow, that requires the controller node to restart (or restart NR its self) - then naturally they will reset.

I could think about getting off docker.

Thats for you to decide 😅

Personally I have never used it, never needed to, never had the need. - I install anything I need on "bare metal" - directly on the OS (raspberry Pi OS for me)

There is a potential we could get native serial port running on docker BTW.

The initial problem is that Docker uses a VM distro known as Alpine and it uses a different C Library, that is used to compile the serialport package.

However, things have changed in V10 of the serialport package - but we need to clear out any traces of it.

If you want to try this, let me know (will speak tomorrow if so)
Or go bare metal 😄 - but if there is a need to stick with Docker, then stick with it

[fabnavigator]

I'll try to remember to stick to modified nodes. Thanks.

If you are willing, I would like to try native serial port again.

[fabnavigator]

@marcus-j-davies Ready to try to get the serial port working with docker?

[marcus-j-davies]

@fabnavigator

I will explain the methods used in a native NR install (not one that is used by Docker - but it should be relatively the same)
I don't use docker - so any differences I cant help with.

!!!!!! BACK UP YOUR SYSTEM !!!!!!

The npm install routines must be run under the same context/environment that NR docker will run under i.e same node version/ directory etc etc.

1. Stop Node RED
2. Navigate to NR's home directory ~/.node-red (don't ask me what it is for docker)
3. Delete package-lock.json
4. Open package.json
5. Remove any package/line in this file that are for zwave-js, serialport and node-red-contrib-zwave-js
6. Navigate to ~/.node-red/node_modules
7. In this folder delete any folder for zwave-js, @zwave-js, @AlCalzone, serialport, @serialport and node-red-contrib-zwave-js
8. Navigate back to ~/.node-red
9. run npm install (this will recreate the lock)
10. run npm install node-red-contrib-zwave-js@beta < ---- note your on a beta - best to stay here
11. start up Node RED and test native serial port

This complete removes any trace of old installs, and installs fresh. - if it still does not work , I have no idea why docker has problems with serialport, as serialport now supports it.

[marcus-j-davies]

There is a folder zwave-js-cache - that is usually in ~/.node-red, but docker may have altered that.
Since your using V8 BETA - you can import a node name & location map.

Example file.

[
  { "nodeId": 2, "name": "Siren", "location": "Living Room" },
  { "nodeId": 5, "name": "DS KT | 196C859846E3", "location": "Kitchen" },
  { "nodeId": 7, "name": "MS KT | DB521A636D77", "location": "Kitchen" },
  { "nodeId": 16, "name": "MS LR | 5583B8F78DDC", "location": "Living Room" },
  { "nodeId": 19, "name": "DS LR | C27963F2472E", "location": "Living Room" },
  { "nodeId": 31, "name": "Keypad", "location": "Living Room" }
]

Should be a breeze to do, in order to get all your names backs (just create the import file)

[fabnavigator]

Not exactly a breeze, but I did it. Good thing you had just added that feature! I think I'm all set now. No more docker to pick on when I have a problem. Thank you. I'm glad you were around.

[marcus-j-davies]

No more docker to pick on when I have a problem

Means you can blame the project now when something isn't working 😉
V10 BETA of the Driver (as used in V8 BETA of the module) is still a WIP, but once it hits stable release, I'll follow suite.

If you ever need to move the install - include zwave-js-cache in the backup, so it can be replaced, no need to re-interview and lose names that way

[fabnavigator]

@marcus-j-davies ,

Quick question. I don't want to use /home/user/.node-red for my files. I updated /usr/lib/node_modules/node-red/settings.js to change my user directory and that worked, but it is still looking for settings.js in /home/user/.node-red. How do I chnage that?

[marcus-j-davies]

Mmmm I'm not sure....
I always install my own systemd file to start Node RED

Try setting WorkingDirectory=/path/to/user-dir maybe
I don't use their installer - I always install via NPM

[Unit]
Description=Node RED
After=network.target

[Service]
Type=simple
Environment="NODE_ENV=production"
ExecStart=/usr/bin/node /root/node_modules/node-red/red.js --port 1880 --userDir "/root/.node-red" "/root/.node-red/flows.json"
WorkingDirectory=/root
User=root
Group=root
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

See command line args
https://nodered.org/docs/getting-started/local

[AlCalzone]

I see a bunch of the below message in the log. Never 2/3 or 3/3. Does that mean that the command always worked on the second try?

Is that preceded by a CAN in the logs? Then this is normal behavior - both sides of the serial port tried to write at the same time and Z-Wave JS backed off.

[fabnavigator]

I have my log level set to Warn. I don't see that in the log file.

[nioc]

For people running Node-RED in docker on a rpi, the issue is caused by serial port 10.1.0 which is not compatible with ARM architecture serialport/node-serialport#2438 (comment).
Proposed workaround is to run npm rebuild --build-from-source (inside the docker as @marcus-j-davies sayed).

Now my Node-RED 3.0.2 works with node-red-contrib-zwave-js 8.0.0 through Docker on my rpi.

[marcus-j-davies]

Thanks for the tip @nioc,
The serial port package has always been an issue with Alpine.

I'll refer to this post if when it crops up again.