RFLink errors resolved
To recap, RFLink is the software that runs on an Arduino that has been equipped with the Nodo 433.92 MHz Transceiver kit, which allows sending and receiving of 433.92MHz wireless control sequences, as used in doorbells, car security, heating thermostats and so on.
I've been noticing the Node-RED debug output showing that RFLink is occasionally returning the "20;xx;CMD UNKNOWN" response to one or other of the commands I've been sending to control lights around the house on timers. In addition, the lights sometimes mysteriously go off for a period, and then switch themselves back on, all the while that the status is shown as ON. Weird. My entire career was based on "if it smells bad, it probably is", so if I want a reliable system, maybe I'd better see if I can fix this. Let's face it, if I send a message I think is correct, and it's ignored, something I want to happen won't be, and we can't have that can we?
So, what could it be? RFlink is connected by the equivalent of a serial link, with bit patterns sent down a wire, with a processor at the other end taking bits off, assembling bytes and interpreting them. In the past I've seen problems with bits being dropped while the processor "isn't looking" i.e. actually processing the previous message.
Firstly, I had been sending each message twice, on the basis of my initial investigations which seemed to indicate that the wireless transmission/reception was a bit unreliable. Since the current operations are idempotent, performing each one twice isn't a problem. However, there are 3 lights on timers (Scargill's Big Timer node), and they are sent a "refresh current state" message every minute, and the timers all do it at the same time. Thus there are some 6 messages going out in quick succession every minute in the same 1 second period or less! It also seems that it's proving more reliable than I originally thought, maybe I could reduce it to one per operation... Did that. Still getting errors occasionally, although the lights appear to be working on demand, so generally messages aren't being lost "in the ether".
What next? Well, I'd considered a more deterministic approach initially, rather than the "free-running" "fire a message, ignore the response" approach currently used. At least I'm putting all the message through a single Serial node, so they're actually being sent one at a time! Anyway, I started experimenting with a "RFLink Controller" node in parallel to the existing setup, something that's easy to do without disturbing the existing operation. Basically, collect all incoming and outgoing messages, only sending an outgoing message when there isn't an unacknowledged one previously sent. Unsent messages are buffered and sent out when the slot comes free due to a received ack. Non-ack messages i.e. unsolicited receptions from doorbells etc. are just forwarded to the current processing. Here's some code - it uses the node Context to store the various state variables in-between invocations on received messages.:
I've been noticing the Node-RED debug output showing that RFLink is occasionally returning the "20;xx;CMD UNKNOWN" response to one or other of the commands I've been sending to control lights around the house on timers. In addition, the lights sometimes mysteriously go off for a period, and then switch themselves back on, all the while that the status is shown as ON. Weird. My entire career was based on "if it smells bad, it probably is", so if I want a reliable system, maybe I'd better see if I can fix this. Let's face it, if I send a message I think is correct, and it's ignored, something I want to happen won't be, and we can't have that can we?
So, what could it be? RFlink is connected by the equivalent of a serial link, with bit patterns sent down a wire, with a processor at the other end taking bits off, assembling bytes and interpreting them. In the past I've seen problems with bits being dropped while the processor "isn't looking" i.e. actually processing the previous message.
Firstly, I had been sending each message twice, on the basis of my initial investigations which seemed to indicate that the wireless transmission/reception was a bit unreliable. Since the current operations are idempotent, performing each one twice isn't a problem. However, there are 3 lights on timers (Scargill's Big Timer node), and they are sent a "refresh current state" message every minute, and the timers all do it at the same time. Thus there are some 6 messages going out in quick succession every minute in the same 1 second period or less! It also seems that it's proving more reliable than I originally thought, maybe I could reduce it to one per operation... Did that. Still getting errors occasionally, although the lights appear to be working on demand, so generally messages aren't being lost "in the ether".
What next? Well, I'd considered a more deterministic approach initially, rather than the "free-running" "fire a message, ignore the response" approach currently used. At least I'm putting all the message through a single Serial node, so they're actually being sent one at a time! Anyway, I started experimenting with a "RFLink Controller" node in parallel to the existing setup, something that's easy to do without disturbing the existing operation. Basically, collect all incoming and outgoing messages, only sending an outgoing message when there isn't an unacknowledged one previously sent. Unsent messages are buffered and sent out when the slot comes free due to a received ack. Non-ack messages i.e. unsolicited receptions from doorbells etc. are just forwarded to the current processing. Here's some code - it uses the node Context to store the various state variables in-between invocations on received messages.:
 |
| Settings for new node in Node-RED |
 |
| Complete RFLink processing flow |
- Incoming messages from Serial come in through RFLink Input
- Outbound messages arrive from various sources via the inter-tab link just above that
- All messages come into RFLink Message Controller
- Incoming go out through the top output
- Outbound go out through the middle output
- A buffer dump comes out through the bottom output
- The Controller node status message shows the current stats:
- Out: 2595
- In: 3336
- OK: 2595
- Bad: 0
- Q(ueue): 0
- T(ransmitting): false
So far, since I completed this, I haven't seen any bad ("CMD UNKNOWN") messages flagged. This is in contrast to running this in parallel, in which maybe 5-10% of messages triggered this response. It's also interesting to watch it for a few minutes - the Node-RED desktop is sufficiently responsive to see it in action i.e. Q >0, T = true, Out > OK and so on, rapidly getting back to the depicted stable idle state. Excellent!
I've clanged off a note about this to the Let’s Control It Forum, let's see if anyone responds.
Addendum
Of course, I’ve ended up adding more processing, mainly of different control responses in order to handle debug commands and so on. No reaction on the forum yet, I expect everyone uses an existing interface, or sees this as self evident!
Comments
Post a Comment