RFXCOM updated

[Max Hadley]

Hi,

I have just published node-red-contrib-rfxcom 1.1.5 to npm. This version improves the status display of firmware version & type in the editor, and adds new doorbell in & out nodes. It now depends on the latest node-rfxcom package 0.11.1.

Max

[Walter Kraembring]

Dear Max,

Thank you!

I have updated using the same approach as you recommended earlier (running 'sudo npm update' in the module directory) and that went ok without problems. It seems however something goes wrong, see picture below, the 'connecting...' is not changing

Kind regards, Walter

pi@raspberrypi://home/pi/.node-red/node_modules/node-red-contrib-rfxcom $ npm version

{ 'node-red-contrib-rfxcom': '1.1.4',

  npm: '2.14.22',

  ares: '1.10.0',

  http_parser: '1.0',

  modules: '11',

  node: '0.10.29',

  openssl: '1.0.1k',

  uv: '0.10.27',

  v8: '3.14.5.8',

  zlib: '1.2.8' }

PS your previous version has been running perfect

[Walter Kraembring]

Just realizing that the update may have failed...looks like I have a version 1.1.4 and not 1.1.5. Besides, I do not see the doorbell out node either.

BR Walter

[Max Hadley]

Walter,

You need to reload the editor to see the new nodes, obviously. All the nodes are now in the 'home automation' palette category. Can you enable debug and post some of the output after startup, please?

Max

[Walter Kraembring]

Hi,

I did restart node-red, I did reboot the pi but no such 'home automation' palette, just still the old one with existing rfxcom nodes and no bell. The debug log below (I notice one missed message but it has most likely no impact). Commands and sensor events are working. One thing I noticed is that initially a lot (maybe all) devices are set to ON. Did you change anything here? I think this worked different in previous version...

BR Walter

pi@raspberrypi:~ $ RED_DEBUG=rfxcom node-red -v

Welcome to Node-RED

===================

3 May 09:29:52 - [info] Node-RED version: v0.13.4

3 May 09:29:52 - [info] Node.js  version: v0.10.29

3 May 09:29:52 - [info] Linux 4.1.18+ arm LE

3 May 09:29:52 - [info] Loading palette nodes

3 May 09:30:44 - [info] Settings file  : /home/pi/.node-red/settings.js

3 May 09:30:44 - [info] User directory : /home/pi/.node-red

3 May 09:30:44 - [info] Flows file : /home/pi/.node-red/flows_raspberrypi.json

3 May 09:30:45 - [info] Server now running at http://127.0.0.1:1880/

3 May 09:30:47 - [info] Starting flows

3 May 09:31:44 - [info] [inject:Show status] repeat = 60000

3 May 09:32:04 - [info] Started flows

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,00,00,45,42,B2,07,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,01,00,45,42,B2,10,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,02,00,45,42,B2,0E,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,03,00,45,42,B2,0D,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,04,00,45,42,B2,04,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,05,00,45,42,B2,08,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,06,00,45,42,B2,0F,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,07,00,46,7A,6E,03,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,08,00,46,7A,6E,07,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,09,00,48,21,9A,04,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0A,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,0B,50,10,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,0C,50,10,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,0D,4F,10,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,0E,4F,10,00,00

3 May 09:32:09 - [info] [exec:1c4fa554.e3b05b] sudo hciconfig hci0 down

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0F,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,10,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,11,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,12,00,45,42,B2,0A,01,0F,00

3 May 09:32:12 - [info] [rfx-lights-out:Carport] connecting to /dev/ttyUSB0

3 May 09:32:12 - [info] [mqtt-broker:9099f2b4.8e3e2] Connection failed to broker: mqtt://192.168.10.248:1883

3 May 09:32:12 - [info] [mqtt-broker:b0587f20.ac192] Connection failed to broker: mqtt://192.168.10.252:1883

3 May 09:32:12 - [info] [mqtt-broker:98094263.86762] Connection failed to broker: mqtt://192.168.10.240:1883

3 May 09:32:12 - [info] [exec:eb00084f.14fff8] sudo hciconfig hci0 up

3 May 09:32:12 - [info] [exec:813c8291.7ec38] sudo setcap cap_net_raw+eip $(eval readlink -f `which node`)

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,13,00,45,42,B2,07,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,14,00,45,42,B2,10,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,15,00,45,42,B2,0E,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,16,00,45,42,B2,0D,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,17,00,45,42,B2,04,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,18,00,45,42,B2,08,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,19,00,45,42,B2,0F,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1A,00,46,7A,6E,03,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1B,00,46,7A,6E,07,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1C,00,48,21,9A,04,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1D,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1E,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1F,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,20,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,21,00,45,42,B2,0A,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,22,00,45,42,B2,07,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,23,00,45,42,B2,10,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,24,00,45,42,B2,0D,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,25,00,45,42,B2,04,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,26,00,45,42,B2,08,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,27,00,45,42,B2,0F,02,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,28,00,46,7A,6E,03,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,29,00,46,7A,6E,07,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2A,00,48,21,9A,04,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2B,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2C,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2D,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2E,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2F,00,45,42,B2,0A,01,0F,00

3 May 09:32:20 - [warn] [feedparse:DI] error - Bad status code 408

[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,30,00,00,00,00,00,00,00,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,31,02,00,00,00,00,00,00,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,17,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,32,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,33,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,34,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,35,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,36,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,37,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,38,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,39,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,3A,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,18,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,19,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1A,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1B,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,3B,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,3C,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,3D,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,3E,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,3F,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,40,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,41,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,42,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,43,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1C,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1D,00

3 May 09:32:27 - [info] [mqtt-broker:9099f2b4.8e3e2] Connected to broker: mqtt://192.168.10.248:1883

3 May 09:32:27 - [info] [mqtt-broker:b0587f20.ac192] Connected to broker: mqtt://192.168.10.252:1883

3 May 09:32:28 - [info] [mqtt-broker:98094263.86762] Connected to broker: mqtt://192.168.10.240:1883

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1E,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,44,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,45,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,46,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,47,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,48,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,49,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,4A,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,4B,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,4C,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 14,01,FF,20,00,53,01,04,00,26,00,01,00,1C,01,00,00,00,00,00,00

[rfxcom] on /dev/ttyUSB0 - Command unknown or not supported

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,28,F7,00,00,DF,25,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,29,07,04,00,5C,39,00,79

3 May 09:32:41 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 993 calls to Prowl api during current hour.

3 May 09:32:48 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 992 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2A,20,02,00,89,2E,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,2B,B7,00,00,93,3A,01,79

3 May 09:33:05 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 991 calls to Prowl api during current hour.

3 May 09:33:14 - [error] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] Error: ETIMEDOUT

3 May 09:33:14 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] null calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2C,07,04,00,5C,39,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2D,07,04,00,5C,39,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,2E,F7,00,00,DF,25,02,79

3 May 09:33:31 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 990 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2F,20,02,00,89,2E,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,30,B7,00,00,93,3B,01,79

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,4D,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,4D,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,4E,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,4E,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,4F,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,4F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,50,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,51,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,50,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,51,00

3 May 09:34:09 - [error] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] Error: ETIMEDOUT

3 May 09:34:09 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] null calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,52,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,52,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,53,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,53,00

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,31,20,02,00,89,2E,00,79

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,54,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,54,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,55,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,55,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,56,00,45,42,B2,0E,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,56,00

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,32,B7,00,00,93,3B,01,79

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,57,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,57,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,58,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,58,00

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,33,07,04,00,5C,39,00,79

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,59,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,59,00

 

[Walter Kraembring]

One thing I noticed is that initially a lot (maybe all) devices are set to ON. Did you change anything here? I think this worked different in previous version...

I think this is my fault, sorry...reviewing my flow... 

[Max Hadley]

There is one issue: the required version of node-rfxcom is >=0.11.0, when it should be >=0.11.1. This version adds the firmware type to the status event, which is now displayed on the node status. If it's missing it cause the status not to be shown. However, it would not explain the missing palette category

Max

[Walter Kraembring]

Should I update differently then with 'sudo npm update' ?

[Max Hadley]

That should be OK. Did you refresh the browser after updating? Just restarting node-RED is not enough. Also I'm worried about all those commands being sent before the RFXtrx is properly connected. It only has a small input buffer, which may be overflowing. I don't see the startup handshake completing properly, though clearly the RFXtrx is responding OK

Max

[Walter Kraembring]

Yes, I have tried everything

I have also logged what the RFXtrx is sending out (with another system) and it looks ok

[Julian Knight]

I also noticed that NR was starting before mosquitto which implies to me that it is starting too early after a reboot? If you are starting it using systemd, you need to add some "after" dependencies so that the hardware is ready before NR starts. I shared my startup file on another thread which shows how.

[Walter Kraembring]

Yes Julian, thanks, I saw and tried it as well (currently commented out) but this is not the problem in this case. Basics is working, i.e the RFXtrx sends commands and receives sensor/remote events as it should, no problems with that. If something needs to be queued up until the RFXtrx has responded with the handshake BEFORE accepting commands is something I think should be handled by the node.

So in my case, what is not working:

1) After the update & multiple reboots & browser refresh I still do not see the expected 'home automation' palette

2) 'sudo npm update' did not update node-rfxcom to 0.11.1 (I still have 0.11.0) and therefore the firmware version is incorrectly displayed

[Max Hadley]

Walter,

As far as the failure to update the status is concerned, this seems to be happening because the RFXtrx is being swamped with too many command messages sent too quickly, so that its internal message buffer is overflowing. This means that some messages got missed completely, and one got corrupted. Among those that were missed completely are the 'reset' and 'get status' commands which form part of the initial handshake: since that didn't complete properly the node status never got set. Message reception from the RFXtrx is now only turned on after the reset command is sent, but it is clear that the command acknowledgement messages (that start with the byte sequence 04,02) are not keeping up with the commands sent. The 4th byte of the response message is the command sequence number: the command being acknowledged will have the same number in its 4th byte. You can see they get a long way out of step before eventually catching up, and that there is a big gap between the the corrupted command (20) and the first properly acknowledged one after that (4D) - the long acknowledgement starting 14,01,FF,20 is a 'message not understood' response which I now cause to print the error message on the next line.

The best way round this is to implement a handshake system, so that messages are held in a queue and not sent to the RFXtrx until the previous message has been acknowledged (possibly with a sliding window of 2 or 3 messages allowed). This ought to be done at the node-rfxcom package level, not node-red-contrib-rfxcom. In fact, sending commands to the RFXtrx ought to be blocked completely until the handshake has finished, as well. I'll work on these issues & keep you advised.

As to the missing 'home automation' category & doorbell nodes, I'm still mystified! You should have node-red-contrib-rfxcom version 1.1.5, and rfxcom version 0.11.1. If either or both of these are wrong, please try an npm update, or if that doesn't fix it, an npm install. Possibly even, it may be necessary to uninstall node-red-contrib-rfxcom & then reinstall it.

Max

[Dave C-J]

Rather than use npm update, use npm install rfx...@0.11.1 to force install of the specified version. 

[Dave C-J]

Though if Max has that set as a pre-req in his package.json, then doing that for Max's package should get then both to the correct level.

[Max Hadley]

As I mentioned, there is a mistake in node-red-contrib-rfxcom package.json, it requires rfxcom >=0.11.0 instead of >=0.11.1

But I thought it would get updated to the most recent version that matches the selector.

This doesn't explain the missing nodes & palette category, though!

[Walter Kraembring]

npm install rfx...@0.11.1 to force install of the specified version. 

Thanks, this worked fine, I do have the 0.11.1 version installed now. Still have to consider re-installation to get the new palette but I am worried to destroy my flow that I spent huge amount of time on (maybe is not a risk?) 

I think my flow, divided into 12 tabs, is really hitting the things very hard. The behavior of Node-RED seems to be that everything in the flow is somehow started "at the same time". I think therefore it would be good if each tab had a setting where you could set the execution order and a tab delay for the startup (default settings could be as it is today). In this way you could create a sequential control in what order the flow is started. You could then split the flow into tabs to better control the execution order. Things that needs to be started first would be put on the first tab etc.

Best regards, Walter

[Walter Kraembring]

 Things that needs to be started first

As example, I have a number of variables (of type context.global....) that needs to be initiated before other parts of my flow will work correctly. To overcome I had to add many function nodes with tailored rules. This would not have been needed if the flow execution could have been controlled like I described above 

[Julian Knight]

Having been bitten by seemingly innocuous upgrades previously, I now take a full copy of my working NR before upgrading. That way, I can either roll back or run different flows side-by-side.

To make sure you don't kill you flows, you should make additional backups of the flow file and put them somewhere safe. NR does make a single backup when it starts but that isn't enough for safety.

[Julian Knight]

I also have globals that need initialising. You can, of course, do this in your settings so they are available before NR even starts up which is OK for static things. That is the best approach if you can.

However, I also initialise some globals from a database or sometimes I just want the data initialised from NR itself as I may manually change it from time to time. For that, you either need to make sure that all of your flows can cope with the data not being there or you need to add suitable delays to everything that relies on the data.

So, for example, my weather lookups that normally run on startup then periodically afterwards are kicked off by an inject node with a delay of 60s since they aren't very time sensitive.

I agree that this can get complex. It would indeed be nice to have a bit more control over startup flows. If only to have a "special" tab that, when used, runs some seconds before everything else.

[Max Hadley]

I have another use case: on a Beaglebone Black, wait for all the GPIO nodes to initialise before dropping back from root to an unprivileged user. I use the inject once + delay technique but it's a bit hit and miss.

[Walter Kraembring]

I have even a distributed solution based on 3 Pi's running: one for Node-RED and two others with dedicated services providing data (like weather) to an MQTT broker in each of them. So when Node-RED subscribes, data will be available. But still, I have some data that is provided by nodes in the Node-RED configuration and for those, you need to select work-a-rounds. But as example, I cannot figure out how on earth I could configure Node-RED so that the RFXtrx initiates calmly BEFORE the rest of the flow overwhelms the poor thing.

Hopefully Dave and/or Nick reads and give feedback and their opinion on this flow-control topic

Best regards, Walter

[Max Hadley]

You could try using a delay node to limit the rate at which messages are sent to the rfx- nodes, but it is only a stopgap. Why do you try to send so many messages each time the system starts? Are you trying to restore settings from a database?

Max

[Walter Kraembring]

Why do you try to send so many messages each time the system starts?

It is not me, it is all other nodes on all my tabs starting to trigger simultaneously when node-RED starts. It seems silly I should have to compensate with more various delays (I have already a lot of them to distribute transmission!) Of course I could add more as a last resort, hoping for tab settings a la suggestion earlier may take some time if ever...   

Wouldn't it be better to have a queue and buffering system in your nodes?

[Julian Knight]

I should have spotted this before actually.

I think that you might want to look at splitting flows out of your single instance of Node-Red and into a couple of instances. That way, you could better control when things start up. If you have an instance that controls the hardware for example using Max's nodes plus whatever other hardware you might interface with, then you could start that and delay startup of your main logic instance for however long you needed to. As long as the logic flows talk via MQTT, everything will be golden.

I've actually been thinking about doing this myself since I've had some serious issues along the way with talking to hardware what with looping serial nodes and the like. Also, the hardware-based nodes generally seem more likely to suffer from update issues so I'd like to update them less than my main flows.

[Mark Setrem]

Out of interest, how many different things are you monitoring / controlling with the RFXCom nodes? 

 My experience with nodejs v0.10.29 was that node-red could get unresponsive, which appeared to be related to use of the serialport .

Since updating to nodejs v4 TLS the same nodes running the same version of nodered has significantly improved performance.

Perhaps upgrading nodejs is something it would be worth you trying?

[Julian Knight]

I have only 1/2 dozen things I'm listening to on the RFX. I also have an Arduino directly connected, another connected via Ciesco 433MHz, a Wi-Fi connected smartplug (which reports power use) and a couple of ESP8266 devices. I have around 1/2 dozen outputs from the RFX too but those are switches so they don't see much traffic. Most of the sensors are updating between 30-60 sec.

I've also considered taking the hardware integrations out of NR altogether given the issues I've had, at the moment things are stable again and I probably don't have time. But I'm really tempted to re-engineer the hardware interactions to a specific node.js microservice that interfaces between the hardware and MQTT.

[Mark Setrem]

Sorry Julian I was asking Walter!

[Walter Kraembring]

The responsiveness is actually impressive considering I am running everything in a Pi 2, commands controlling lights are 'instant' and I do receive all sensor events, never misses them (I know since I am monitoring that they are received with a certain periodicity). So there is no performance issue, my flow works. It is just that it might not be optimized in respect to kicking the RFXtrx too hard. But after startup, it i s working just great.

As example I have a number of tabs as the one below in the picture. That specific one is handling the control of a couple lamps having the same requirements and various time scheduling for various operational modes (as I like to call them). In reality this works in such a way that the lamps are controlled differently depending in the actual situation:

- auto: normal mode

- manual: no scheduling occurs but manual control is allowed

- on: well, simply all on

- off: the same but off

- disabled: disabled

- vacation: spending your vacation at home, you do not like early scheduling going with your guests staying late

- away: as it says, everybody in your family have left home

The operational modes can be controlled through a scheduler, a webpage or external equipment, in my case our home alarm system. What you see in the picture is also Peter Scargill's BigTimers configured for various day types (this is a hacked version since the standard does not support the operational modes I need).

Further more I have added repeaters (since those rf devices need sometimes multiple commands for better reliabilty) and delay nodes to somewhat not pushing it too hard. Sure I could have different settings on those delay nodes but it would not help during startup when all will be triggered anyway.

The remaining stuff is basically nodes to capture and send updates via MQTT (means regardless how you control the devices; via remote, scheduling or by tapping the GUI on the tablet, the status will always be correctly synchronized and presented).

Best regards, Walter

PS For the complete view I could zip my flow and post it here. IF you would import it, you will create 12 new tabs. It will not really work since I have a special version of BigTimer. But it will for sure show the complexity.

[Walter Kraembring]

Dear Mark & Julian

I have for the RFXtrx around 20 rf plugs, some 5 temperature & humidity sensors

I have also some zwave devices handled by a Razberry z-wave controller

Then a OneWire network with some temperature sensors and a light sensor (used in my flow for controlling awnings)

In addition integration with our home alarm system and monitoring of the heatpump

Running everything in 3 Pi's, integration between all of them is done via MQTT

[Dave C-J]

There's multiple things going on in this thread :-)

install - updates - starting etc so let's try to cover a few.

npm update will do different things depending on how and where it is run...

so before you do that it is generally best to run npm outdated in the same way to see what it thinks is needed... so. normally we need to be in the .node-red directory ... running  npm update here will look in a package.json to see what should be updated... by default there isn't a package.json here so it will look in node_modules and check each of them. However if you have a package.json there for some reason it will use that to set the expected package versions.  Likewise if I run  sudo npm -g outdated it will do the same for the globally installed packages (including the core of Node-RED). 

Again normally all extra npm packages should be installed in .node-red without using sudo. Anything else and they may end up in places on the filesystem which makes updating non-obvious. So if nodes were installed with sudo then you may need to be careful.

Anyway - for example on one of my Pi running npm outdated in .node-red I get

node-red-node-sensortag   0.0.12  0.0.14  0.0.14  

The three columns are 1) the currently installed version  2) the version that any package.json (see above) would limit it to and 3) the latest available on npm.  So in this case a simple npm update will do what I want and update it ok... If the middle column was holding it back I could npm install node-red-no...@0.0.14 to force it beyond (but no guarantees it would work etc.. but hey.)

Re startup  As Julian noted a while back setting things in global context in settings.js is the best way for it to be set "first" as that is executed before the flow is scanned. In general after that the flow starts to execute in the order it is read from the flows file - which is typically tab 1 -> n (but... can depend on if during edit or freshly saved etc...) - but obviously these are async and non-blocking so they will all start one right after another. One thing you could do is set a global variable in settings.js and use that as a flag to indicate to other functions (or switch node) where in your start process you are.

A random looking slightly ahead thought - when we release the link node (v0.14.0) that will allow linking between tabs then you can trigger a flow on another tab from an output from a "previous" one so you can ensure a kickoff order if you wanted - though as you use MQTT already you could also do this via MQTT

[Max Hadley]

Walter,

This needs a bit of thought. Inside node-RED, the message passing is guaranteed: each message arrives exactly once at the next node(s). Hence there is no back-channel acknowledgement. When the message leaves the node environment on its way to an RFXtrx there is no such guarantee. It might get lost in transmission along the USB cable (unlikely, but it could be disconnected), as we have seen it can get dropped within the RFXtrx if the buffer overruns, and of course it may never reach the receiver even if it does get transmitted OK. The RFXtrx acknowledges each command after it is transmitted, but the acknowledgements may get lost on the way back up the USB cable. While the rfxcom package can check for an acknowledgement, supposing it never arrives? Should it just enqueue all subsequent messages until it has seen an acknowledgement? Should it time out? If so, after how long? If the acknowledgement times out, should it retransmit the message (which may after all have been transmitted properly the first time)? How many times should it repeat the retransmission before giving up? When it gives up, should it just move on to the next message, or should it reset the RFXtrx first? What should happen if it loses synchronisation with the incoming data packets (as happened with the previous version of threnode in your system)?

For what it's worth, my feeling is that since there is no way of knowing if a radio message was received correctly, even if it was transmitted OK, we can never do better than a 'best effort' message delivery to the remote device. So there is no point in trying to be too clever with the message delivery to the RFXtrx itself. I propose waiting for an acknowledgement for each message from the RFXtrx before sending it the next message; if no acknowledgement is received after (say) 5 seconds, move on to the next message without trying to retransmit the first. If message synchronisation is lost, assume the message has been acknowledged, but the acknowledgement has been garbled, and move on to the next message. (It's worth noting that some messages take much longer to transmit than others)

I also propose that messages sent to the rfxcom package for transmission, which arrive before the handshake is completed, be silently dropped. In theory they could be queued, but the handshake may never complete (if the RFXtrx is not plugged in) and you might end up with a queue of hundreds of no-longer-appropriate messages being sent in rapid succession when it does get plugged in!

All this would be implemented at the rfxcom package level, without changing node-red-contrib-rfxcom.

How does that sound?

P.S. Do you have the latest version of node-red-contrib-rfxcom installed OK now? Do you see the doorbell nodes & the home_automation tab?

On Wednesday, 4 May 2016 16:26:58 UTC+1, Walter Kraembring wrote:

[Walter Kraembring]

1) Re-installed and now I have the new palette !!!

2) Regarding buffering: as you suggest Max. This type of RF communication is by nature unreliable. Therefore I suggest the following:

- at startup, initiate the RFXtrx and wait for handshake like 5 seconds. Buffer messages to the RFXtrx

- if handshake is not received within time period, indicate a communication error and flush buffer. At this point, no sense in buffering more messages

- when handshake has arrived, start processing buffered messages one by one exactly as you suggested (send once, wait shortly for ack, move on to the next message without trying to re-transmit the first (the RFXtrx has a built in re-transmission of commands))

 

3) Regarding flow control:

The linking between tabs sounds as a very good way. As long as I also somehow can delay the trigger from one tab to another. To have flow-control during startup is to me a vital functionality in any system and that should be a requirement of the architecture. As example of this I have included a picture from another system that provides you with full control of the startup. The tree structure is loaded from top to bottom and you can re-arrange the order very easy by just moving items up or down in the tree. You can in addition add delays (wait items) as well as other useful actions (like jump, disable, enable and many others). As example I have added a 5 seconds wait after the initialization of the RFXtrx.

 

 

[Julian Knight]

Is that EventGhost?

[Dave C-J]

looks like it :-)

[Dave C-J]

And Walter - yes you can add any delay node you like before or after a link node.

[Walter Kraembring]

Is that EventGhost?

Yes, you may guess who is the author of the RFXtrx plugin (and others) ;)

  yes you can add any delay node you like

Sounds perfect, really looking forward! Just one Q regarding the delay node (I might have misunderstood the options). Does the node also support delay of the first message that arrives and not only consecutive? Because that is really critical if you want to delay the link triggering.

Kind regards, Walter

[Dave C-J]

yes the delay node has several modes - the default is just to delay each message (including the first) by a fixed amount (so maintaining any separation between messages)... Other options are to rate limit etc which do let through the first then space out subsequent messages.

[Max Hadley]

Walter,

I have just published version 0.12.0 of npm package 'rfxcom' which adds a command message transmit queue. This operates much as you describe below. Any message which arrives after the underlying serialport is successfully opened (i.e. when the status changes to 'connecting...') will be held in a queue, and transmitted after the handshake completes (i.e. when the status shows 'OK' and a version number). The rfxcom package now processes the command acknowledgements from the RFXtrx433, and will allow no more than 3 command messages through to it at any one time. If no acknowledgement is received for a message within 10 seconds, it is assumed missing in action and the next queued message will be sent. Note that since up to 3 messages can be in transit at once, the queue will not stall if one or two acknowledgement messages are lost. if the RFXtrx433 is disconnected, the queue is cleared immediately (and will not accept any more entries until the serialport is once again opened).

Please can you update your Pi to the new version (there are no changes to node-red-contrib-rfxcom) and start it up with debug enabled. There is additional debug which shows when messages are added to the queue as well as sent to the RFX, and the acknowledgements are also decoded. I'd like to see how it copes with your start-up flood of commands!

Max

On Thursday, 5 May 2016 06:15:33 UTC+1, Walter Kraembring wrote:

[Walter Kraembring]

Dear Max
That sounds really good!
I am "out of home" for a few days but on Saturday I will upgrade accordingly. Just to let you know, your last version has been operating 24/7 perfectly, with the 1001 rfxtrx firmware. Controlling lights,receiving sensor events and managing my automated awnings. No defects at all ;)
Kind regards, Walter

[Max Hadley]

Walter,

What are you using to control your awnings? I was thinking about adding support for blinds/curtains/gates and in general things that can be opened & closed in a future version but it needs more thought!

I also see you are repeating commands after a delay. How did you decide this was necessary and what delay are you using? I could add this to my -out nodes as an option which would simplify your flows somewhat.

Max

[Walter Kraembring]

Hello Max, upgraded & working well !

Interesting, the queue in operation, cool ! Is it looking correct and as you expected?

pi@raspberrypi:~/.node-red/node_modules/node-red-contrib-rfxcom $ RED_DEBUG=rfxcom node-red -v

Welcome to Node-RED

===================

14 May 13:58:29 - [info] Node-RED version: v0.13.4

14 May 13:58:29 - [info] Node.js  version: v0.10.29

14 May 13:58:29 - [info] Linux 4.1.18+ arm LE

14 May 13:58:29 - [info] Loading palette nodes

14 May 13:59:19 - [info] Settings file  : /home/pi/.node-red/settings.js

14 May 13:59:19 - [info] User directory : /home/pi/.node-red

14 May 13:59:19 - [info] Flows file : /home/pi/.node-red/flows_raspberrypi.json

14 May 13:59:19 - [info] Server now running at http://127.0.0.1:1880/

14 May 13:59:21 - [info] Starting flows

14 May 14:00:11 - [info] [inject:Show status] repeat = 60000

14 May 14:00:34 - [info] Started flows

14 May 14:00:34 - [info] [exec:1c4fa554.e3b05b] sudo hciconfig hci0 down

14 May 14:00:35 - [info] [exec:eb00084f.14fff8] sudo hciconfig hci0 up

14 May 14:00:38 - [info] [rfx-sensor:10ad99a2.b31826] connecting to /dev/ttyUSB0

14 May 14:00:38 - [info] [mqtt-broker:9099f2b4.8e3e2] Connection failed to broker: mqtt://192.168.10.248:1883

14 May 14:00:38 - [info] [mqtt-broker:b0587f20.ac192] Connection failed to broker: mqtt://192.168.10.252:1883

14 May 14:00:38 - [info] [mqtt-broker:98094263.86762] Connection failed to broker: mqtt://192.168.10.240:1883

14 May 14:00:38 - [info] [exec:813c8291.7ec38] sudo setcap cap_net_raw+eip $(eval readlink -f `which node`)

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,00,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 07,10,01,01,4F,10,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 07,10,01,02,4F,10,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,03,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,04,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,05,00,45,42,B2,0A,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,06,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,07,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,08,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,09,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,0A,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,0B,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,0C,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,0D,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,0E,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,0F,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,10,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,11,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,12,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,13,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,14,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,15,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,16,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,17,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,18,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,19,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,1A,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,1B,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 07,10,01,1C,50,10,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 07,10,01,1D,50,10,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,1E,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,1F,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,20,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,21,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,22,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,23,00,45,42,B2,0A,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,24,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,25,00,45,42,B2,0A,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,26,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,27,00,45,42,B2,0E,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,28,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,29,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,2A,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,2B,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,2C,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,2D,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,2E,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,2F,00,00,00,00,00,00,00,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,30,02,00,00,00,00,00,00,00,00,00

14 May 14:00:50 - [error] [function:b0124259.50bbb] TypeError: Cannot call method 'search' of null

[rfxcom] on /dev/ttyUSB0 - Received: 14,01,00,30,02,53,01,04,00,26,00,01,00,1C,01,52,46,58,43,4F,4D

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,00,B7,00,00,6B,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,01,20,02,00,82,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,31,07,00,00,00,00,00,00,00,00,00

14 May 14:00:50 - [info] [rfx-sensor:10ad99a2.b31826] connected: Serial port /dev/ttyUSB0

[rfxcom] on /dev/ttyUSB0 - Received: 14,01,07,31,07,43,6F,70,79,72,69,67,68,74,20,52,46,58,43,4F,4D

[rfxcom] on /dev/ttyUSB0 - Copyright RFXCOM

[rfxcom] on /dev/ttyUSB0 - Started command message queue

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,00,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,01,4F,10,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,02,4F,10,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,00,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 00, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,03,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,01,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 01, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,04,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,02,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 02, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,05,00,45,42,B2,0A,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,03,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 03, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,06,00,45,42,B2,0D,00,00,00

14 May 14:00:53 - [info] [mqtt-broker:9099f2b4.8e3e2] Connected to broker: mqtt://192.168.10.248:1883

14 May 14:00:53 - [info] [mqtt-broker:98094263.86762] Connected to broker: mqtt://192.168.10.240:1883

14 May 14:00:53 - [info] [mqtt-broker:b0587f20.ac192] Connected to broker: mqtt://192.168.10.252:1883

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,04,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 04, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,07,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,05,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 05, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,08,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,06,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 06, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,09,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,07,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 07, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0A,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,08,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 08, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0B,02,02,EF,FE,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,09,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 09, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0C,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,0A,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 0A, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0D,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,0B,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 0B, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0E,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,0C,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 0C, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,0F,00,45,42,B2,0D,00,00,00

14 May 14:01:00 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 999 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,0D,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 0D, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,0E,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 0E, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 0F, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,10,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,11,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,12,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,10,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 10, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,11,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 11, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,13,00,45,42,B2,10,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,14,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,12,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 12, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,15,00,46,7A,6E,03,00,00,00

14 May 14:01:09 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 998 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,13,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 13, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,16,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,14,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 14, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,17,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,15,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 15, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,18,00,45,42,B2,09,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,16,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 16, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,19,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,17,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 17, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1A,00,45,42,B2,0B,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,18,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 18, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1B,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,19,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 19, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,1C,50,10,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1A,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 1A, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 07,10,01,1D,50,10,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1B,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 1B, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1E,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1C,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 1C, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,1F,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1D,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 1D, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,20,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1E,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 1E, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,21,00,45,42,B2,0C,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,1F,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 1F, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,22,00,45,42,B2,0D,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,20,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 20, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,23,00,45,42,B2,0A,01,0F,00

14 May 14:01:20 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 997 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,21,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 21, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,24,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,22,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 22, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,25,00,45,42,B2,0A,01,0F,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,23,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 23, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,26,00,45,42,B2,08,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,24,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 24, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,27,00,45,42,B2,0E,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,25,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 25, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,28,00,45,42,B2,0F,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,26,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 26, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,29,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,27,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 27, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2A,00,45,42,B2,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,28,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 28, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2B,00,45,42,B2,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,29,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 29, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2C,00,46,7A,6E,07,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,2A,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 2A, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2D,00,46,7A,6E,03,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,2B,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 2B, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,2E,00,48,21,9A,04,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,2C,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 2C, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,2D,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 2D, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,2E,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 2E, ACK - transmit OK

14 May 14:01:31 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 996 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,02,B7,00,00,6A,46,01,79

14 May 14:01:40 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 995 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,03,F7,00,00,D9,1F,02,79

14 May 14:01:51 - [info] [prowl:084f9f0e9dac05ee376461268ffb9e24f462c6cd] 994 calls to Prowl api during current hour.

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,04,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,05,20,02,00,82,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,06,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,32,00,45,42,B2,0A,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,32,00,45,42,B2,0A,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,33,00,45,42,B2,0A,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,33,00,45,42,B2,0A,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,34,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,34,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,32,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 32, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,35,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,35,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,36,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,33,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 33, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,36,00,45,42,B2,09,00,00,00

[rfxcom] on /dev/ttyUSB0 - Queued  : 0B,11,00,37,00,45,42,B2,0A,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,34,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 34, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Sent    : 0B,11,00,37,00,45,42,B2,0A,00,00,00

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,35,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 35, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,36,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 36, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,37,00

[rfxcom] on /dev/ttyUSB0 - Response: Command message 37, ACK - transmit OK

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,07,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,08,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,09,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,0A,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,0B,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,0C,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,0D,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,0E,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,0F,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,10,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,11,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,12,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,13,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,14,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,15,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,16,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,17,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,18,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,19,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,1A,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,1B,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,1C,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,1D,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,1E,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,1F,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,20,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,21,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,22,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,23,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,24,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,25,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,26,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,27,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,28,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,29,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,2A,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2B,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2C,07,04,00,6C,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,2D,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,2E,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,2F,B7,00,00,6A,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,30,07,04,00,6B,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,31,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,32,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,33,F7,00,00,D9,1F,02,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,34,20,02,00,83,2F,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,35,07,04,00,6B,3A,00,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,36,B7,00,00,69,46,01,79

[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,09,37,F7,00,00,D9,1F,02,79

[Walter Kraembring]

What are you using to control your awnings? I was thinking about adding support for blinds/curtains/gates and in general things that can be opened & closed in a future version but it needs more thought!

I also see you are repeating commands after a delay. How did you decide this was necessary and what delay are you using? I could add this to my -out nodes as an option which would simplify your flows somewhat.

My awning engines are made by Elero (a German company) and I have cheated; I made a homebuilt solution out of two wireless relay and an Elero remote control (required some soldering). The relays are operated by the RFXtrx. In all, it is working very well. The RFXtrx supports a number of blind and shutters already. So if you have Somfy, the RFXtrx has built in support for it. 

My experience with those rf devices are that they sometimes are unreliable. Since it is a one-way communication, I am repeating the command as an extra insurance. In addition I have a node responsible for synchronization. In my flow I use a scheduler (BigTimer) and I felt sending out a command every minute to synchronize devices to the wanted state is too frequent. Therefore I added a function node that is counting the minute ticks and when threshold is reached, A synchronization command is sent out (and it will of course also be repeated)

The code (might maybe look a bit tailored to my needs) looks like this:

The Repeater (delivers commands to a delay node that randomizes the delay of each command before passed on to the rfxtrx):

msg.payload =  'Off';

if(msg.method=='dim' ) {

    msg.payload =  'level 15';

}

if(msg.method=='turnoff' ) {

    msg.payload =  'Off';

}

if(msg.method=='turnon' ) {

    msg.payload =  'On';

}

for (i = 0; i < 3; i++) { 

    node.send(msg);

}

The Logic: 

if(!context.global.sunInit){

    return;

}

// initialise the variables if they doesn't exist already

context.i = context.i || 0;    

context.o = context.o || 0;

context.tick = context.tick || 0;

context.mem = context.mem || null; 

var result = null;

var target = 20;

var msg1 = null;

context.o += parseInt(msg.payload);

context.i += 1;

if( context.i==6) {

    if(context.o === 0 || (context.global.sunState && !context.global.sunOffsetOutdoor) ) {

        msg =  {

            method: 'turnoff',

        };

        result = 2;

    }

    if(context.o > 0 && (!context.global.sunState || context.global.sunOffsetOutdoor) ) {

        msg =  {

            method: 'dim',

            dimlevel: 255

        };

        result = 1;

    }

    context.tick += 1;

    context.i = 0;

    context.o = 0;

    if( context.mem !== result ) {

        node.send(msg);

        context.mem = result;

    }

    if( context.tick == target) {

        node.send(msg);

        context.tick = 0;

    }

node.status({

fill : "yellow",

shape : "ring",

text : "Counter: "+context.tick+" Target: "+target

});

}

return;

[Walter Kraembring]

Firmware is now correctly identified and presented !!!

[Julian Knight]

Hi Walter, you could do with updating your code to the new way of working with context/global variables.

[Max Hadley]

Walter,

That log looks to me as if everything is now working OK! Sorry I have taken a while to get back to you: this has been a weekend of Binge Gardening...

I'm a bit puzzled by the number of repeat commands you seem to be sending. For example the 2nd and 3rd messages queued after the start-up are identical, except for the command message sequence number - both turn the same light off. maybe there is something amiss with your flow? I know you are retransmitting messages for more reliable operation, but there doesn't seem to be much point in an immediate repeat like that - surely a minute or so delay would be better?

However, it's probably the number of repeats that triggered the buffer overrun problem - which is now fixed, like the parser issue. Clearly you have been stressing the package more then most other users and this has found two nasty lurking bugs - so many thanks!

Max

[Walter Kraembring]

 

Hi Max, no worries, I know the situation, my garden is also waiting for some attention!

I'm a bit puzzled by the number of repeat commands you seem to be sending

I think I know the reason why this happens; it is not that I wan't it but it is because I have a number of BigTimers controlling the same devices and they are all initiating simultaneously at startup. At startup, I have no idea which one of the BigTimers will be the "active" ones, it is depending on day of week and is self-organized so to say (see screen shot below showing one tab of my flow). Adding further delay nodes would distribute the commands better but would make the flow more complex. Maybe better to leave it as is...now that everything is working so smoothly

Also, thank you, this is a cool application for Node-RED and your nodes! I am very impressed that it all works that well, I'm running the whole automation system in a little Pi

Kind regards, Walter