At last the rfxcom nodes!

[Max Hadley]

I have finally managed to win enough free time to pick up on my rfxcom nodes again, which interface the RFXCOM rfxtrx433 transceiver with node-RED. Currently, these let you send commands to 'lighting' devices (including remote control mains sockets) of almost all supported types, and receive the corresponding commands from their remote control receivers; and to receive messages from 'weather' type sensors (temperature, barometric pressure, humidity, wind speed, etc.)

This is still very much a work in progress, but if anyone wants to play with it, especially if you have hardware to try out, please pull from the rfxcom branch of my github repository at https://github.com/maxwellhadley/node-red-nodes/tree/rfxcom/io/rfxcom, or alternatively just download the two files 43-rfxcom.html and 43-rfxcom.js. This is still an 'old style' non-npm-packagable node as I haven't got my head round that change yet.

To use these nodes, currently you will need to install my fork of the node-rfxcom package from https://github.com/maxwellhadley/node-rfxcom. I have submitted a pull request for this to Kevin McDermott, so hopefully it will become official one day.

I'm probably going to start work on (gas, electric, etc) meters, relays, doorbells, and doors & blinds next.

Comments, criticism, suggestions, and contributions all welcome.

Max

[Mark Setrem]

Max, Firstly, thanks for doing this and sharing it! It's definitely beyond my javascript abilities, which was doubly confirmed when I looked at the code ;-)

I have some temperature sensors and a Nexa Motion Sensor linked to a Nexa doorbell chime.

The temperature sensors are detected by the sensor node and it works correctly.

The Nexa kit uses the AC protocol which is actioned by the lighting node, even though theres not a light in sight.

I also had a look at the rfx-lights-out node and I must admit I initially struggled with the terminology/format.
the info suggests "type/device address/unit address" , but until I turned the debug node to display the complete msg object of the rfx-lights-in node I was struggling!

I couldn't see how to determine what the unit address would be in my example, the rfxcom npm package appears to use the term unitcode rather that unit address.

(Motion sensor triggered- added console.log lines to npm package to print out)
Received: 0B,11,00,00,00,7C,B5,7A,0A,01,0F,50
PacketTypeHex:17
subtype:AC
seqnbr:0
id: 0x007CB57A
unitcode:10
commandNumber:1
command:On
level:15
0

I also couldn't see how the actual command is given, as the node info doesn't appear to define that its passed by the msg.payload.

However by copying the rfx-lights-in msg format I can now trigger actions when someone approaches my front door,
and also ring my door bell whenever I want ;-)

roll on halloween!

Many thanks!

[Martin Jarvis]

My RFXComm node-red node has been working fine for me for a few months now. https://github.com/freakent/freakent-nodes

Regards

Martin

[Max Hadley]

Mark,

Good to hear you managed to get it going OK! It's interesting that the Nexa motion sensor & doorbell use 'lighting' commands rather than specific motion detection or 'chime' commands. From your console.log output it looks like the motion sensor is sending an 'on' command. I assume this is 'supposed' to turn a light on when motion is detected, which makes sense. Does it send an 'Off' command after some delay as well? Choosing names for these nodes was difficult - the 'lights' nodes also handle the plug-in switches made by HomeEasy & LightwaveRF, which can be used to switch anything, not just lights.

The nomenclature is also a problem with the various components of the address. In my nodes, the address, whether it is derived from the message topic or fixed in the node settings, is a string containing a '/'-delimited list of parts. This is the same format as an MQTT Topic identifier. The first component is a string representation of what the rfxcom documentation calls the 'subtype', where the string is usually one of the supported products, like 'LIGHTWAVE_RF', or 'AC', but sometimes arbitrary, like 'TH1'. I have chosen strings which are unique, so the 'packet type' can be inferred from the subtype. The remaining parts are the different components of the 'address' part of the rfxcom command packet. There are one, two, or three of these, depending on the subtype, and they have names (in the rfxcom documentation) which vary between subtypes. As a result I may have been a bit inconsistent in how I refer to them. Sorry! In almost all cases, the last part of the address is a number, which may be called a 'channel number', or a 'unit number' or a 'unit code' - they all mean the same thing. These numbers start from 1 and go to some maximum value (depending on the subtype). A channel number of 0 is interpreted as a 'group' address, generally switching all channels/units together, where this is supported by the device. To keep the MQTT compatibility, a channel number of '+' means the same as 0 (but only for the channel number).

Using the debug node to look at the output of the rfx-light-in node is exactly right. The 'in' nodes will always generate messages that are compatible with the corresponding 'out' nodes, although the out rfx-lights-out node tries to interpret a variety of different command representations. I have explained that the message payload is the command in the node help, but it obviously isn't clear enough if you missed it. I'll work on this - even for a single node type, there are so many variants to describe!

Thanks for trying it out, and for the feedback. Hopefully I'll be adding some additional nodes, as well as enhancements and bug fixes, in the future.
Out of interest, what type of temperature sensor you using?

Cheers,

Max

[Mark Setrem]

Yes the motion sensor sends an "Off" a minute later, so I've build a switch into my flow and publish to MQTT to be used in other flows.

I've also now created a "virtual" device address and linked it to the door chime so that I can ring a different sounding bell as an alert from node-red.

The cheap temperature sensors I'm using are ESIC WT450H bought when they were on special offer in my local Clas Ohlson shop. They are reported to have a very low range, which I saw with only 1 of 4 I bought. I took it back to the shop and they swapped it without any problems.

Rgds

Mark

[Max Hadley]

I have just pushed a commit which adds an 'rfx-meter' node to receive messages from Owl current sensors, and the Revolt energy monitors. Once again, this requires my fork of the node-rfxcom package.

I don't have any of these devices myself, so I am particularly keen to hear from anyone who does & can give it a whirl for me!

Thanks,

Max

[Mark Setrem]

Max,  

Having upgraded to v0.9.0 I'm having problems with the rfxcom nodes.

The debug window shows nothing and the console.loglooks like this:

9 Oct 11:49:58 - [serial] serial port /dev/ttyUSB0 opened at 57600 baud 8N1

Sent    : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00

9 Oct 11:49:59 - [mqtt] [5c1a53eb.a3e5ac] connected to broker tcp://192.168.0.22:1883

Sent    : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00

Device initialised

Sending ["0B","11","00","02","00","7C","B5","7A","0A","01","0F","00"]

nothing actually works.

More frustratingly, after a pi reboot sometimes the rfxlights-out node will work once and then stop working.

The rfxlights-in and rfx-sensor-in nodes also appear to be affected. 

Any ideas?  I've reinstalled both the node and you version of the library without any change.

[Max Hadley]

I've not yet updated to version 0.9 - I'll have a look over the weekend. There's always something!

Max

[Mark Setrem]

Ta! I've also found an uncaught exception.  If you enter a serial port that does not exist in rfxcon-lights ( e.g /tty/USB1 ) deploy and then kill node-red.

On restarting node-red it hangs 

[Max Hadley]

Mark,

I found an obvious problem in my working version, which caused all the rfxcom nodes to fail to register, but fortunately it looks like it never got pushed to Github. Basically finger trouble on my part!

I've updated Node-RED to 0.9.1 from Github, and I cannot duplicate the problems you reported. Can you try pulling the latest commit and try again, please?

Max

P.S. I'm on Mac OS X 10.9.5, if that makes a difference

[Mark Setrem]

Will do in the next couple of days. 

Over the weekend I reinstalled v0.8.1 and the rfxcom nodes were working again.

I'll do a new install of V0.9.1 and see if I get the same again.  I'm running NodeRed on a couple of RaspberryPi's.

[Mark Setrem]

Happy to say did a new clean install and this time its working!   Not sure what went wrong last time.

Many thanks

Mark

[Mark Setrem]

I did some more work trying to determine what was causing it to fail and I now have something I can replicate.  Posting here as it might be useful to someone else sometime.

In playing around I had created a serial node that was also pointing at the the same port /dev/ttyUSB0.  

The presence of this node interferes with the rfxcom nodes.  Deleting the node and redeploying isn't enough of the rfxcom node to start working, but after a restart of nodered.  The rfxcom nodes are back working correctly

[Max Hadley]

I have just pushed an update which should be more robust against this sort of thing. It allows the RFXtrx433 to be disconnected and reconnected from the USB port while node-RED is running without ill effect (other than not being able to send & receive, of course!). It takes 6 - 12 seconds to recover after reconnection, and I have added 'live' connection status display to the nodes. I have only tested this on Mac OS X so far, but it should be OK on Linux: I'm not sure about Windows, though.

As before, you will need my fork of the node-rfxcom package, although I'm in conversation with Kevin McDermott about pulling my changes to his original.

Max

[Julian Knight]

This is great work Max, many thanks for making this available & helping us all improve our home automation projects.

One minor issue and I'm not sure if it is in the node or upstream in node-rfxcom.

When I press the buttons on my Siemens (Lightwave) remote, I should see the "Command" that is issued just as I do when my HomeEasy PIR triggers. But I don't. I don't get any msg.payload at all.

So I cannot see whether the remote has turned on or off or indeed what command was issued from the 2 group buttons

Here is the -v output from Node-Red:
Received: 0A,14,00,12,F2,D8,D7,01,00,00,70
Received: 0A,14,00,13,F2,D8,D7,01,01,00,70
and from the two group buttons
Received: 0A,14,00,17,F2,D8,D7,10,02,00,70
Received: 0A,14,00,18,F2,D8,D7,10,03,00,70

So clearly the data is there. But it isn't being reported from your rfx-sensor node. (Guess I just answered my own question about where the issue is!).

If I get time, I'll try to debug your code.

Julian.

[Max Hadley]

Julian,

You should be using an rfx-lights-in node to receive messages from the remote control unit. Can you check with that, please?

Max

[Julian Knight]

Hi Max, quick response!

I've tried with the lights node but this is the same. Here is the debug output (full msg):
    { "topic": "LIGHTWAVERF/0xF2D8D7/1" }

I put some debugging into your node and got this from a console.dir(evt) at line 342:
{ subtype: 'LIGHTWAVERF',
  seqnbr: 1,
  id: '0xF2D8D7',
  unitcode: 1,
  commandNumber: 0,
  command: 'Off',
  level: 0,
  rssi: 7 }

I think the problem is that the line:
   switch (evt.subtype) {
has cases that are numeric but the evt.subtype is actually text?

[Julian Knight]

I added a new case underneath the case 0 at line 343:

      case 'LIGHTWAVERF': // Lightwave RF

Now it works. I guess this may be needed for the other cases too? I don't have any of the other devices though.

[Julian Knight]

Oops, not quite there.

The group commands are not being recognised. These always come in as unit 16, command "Group off" and "Group Mood 1". Not sure of the numbers. Need sleep now so I'll work it out tomorrow :)

[Max Hadley]

I saw this issue a while back but I didn't realise it was on Github. In the original node-rfxcom sometimes the subtype was being returned as a string and sometimes as an integer. I standardised on a string but after discussion with Kevin we are switching to integer. This code is slightly ahead of its time! A case of gitfingers on my part. I'll try and sort it out this weekend.

Cheers

Max

[Julian Knight]

No worries Max, actually, thanks to your nice clean code, I've been able to not only fix the issue but also to enhance the Lighting5 processing.

By the way, it looks like your code may be somewhat more than needed as node-rfxcom seems to pass back the command name anyway - or is that part of the transition of code as well?

I've copied the evt data to msg.info as it includes the RSSI (signal level) which can be useful when positioning units around a building.

Anyway, for what it is worth, here are my amendments. Starting from Line 341 which is the last line where I've not made a change:

if (node.topicSource === "all" || checkTopic(msg.topic, node.topic)) {
    // 2015-01-23 Added by Julian Knight (TotallyInformation) Extra verbose output to decode LWRF lighting codes
    // This shows up in the debug output of the admin i/f so only turn on if really needed
    //node.warn("Lighting5: LightwaveRF: Cmd: '" + evt.command +
    //          "' (" + evt.commandNumber + "), Unit: " + evt.unitcode + ", Level: " + evt.level +
    //          ", RSSI: " + evt.rssi + ", ID: " + evt.id + ", Sub Type: " + evt.subtype);
    // 2015-01-23 Added by Julian Knight (TotallyInformation) Add event details to msg so everything is available in UI (esp. RSSI)
    msg.info = evt;
    switch (evt.subtype) {
        case 0: // Lightwave RF
        case 'LIGHTWAVERF': // 2015-01-23 Added by Julian Knight (TotallyInformation) Siemens/LRWF generates text subtype from rfxcom not numeric
            switch (evt.commandNumber) {
                // 2015-01-23 Added by Julian Knight (TotallyInformation)
                // Split cmd 0 (off) and 2 (group off)
                case 0:
                    msg.payload = "Off";
                    break;
                case 2:
                    msg.payload = "Group Off";
                    break;

                case 1:
                    msg.payload = "On";
                    break;

                case 3:
                case 4:
                case 5:
                case 6:
                case 7:
                    // 2015-01-23 Changed by Julian Knight (TotallyInformation) - missing brackets around calc
                    msg.payload = "Mood" + (evt.commandNumber - 2);
                    break;

                // 2015-01-23 Added by Julian Knight (TotallyInformation)
                // Added cmd 10 (Unlock) & 11 (Lock) & 12 (All Lock)
                case 10:
                    msg.payload = "Unlock";
                    break;
                case 11:
                    msg.payload = "Lock";
                    break;
                case 12:
                    msg.payload = "All Lock";
                    break;

                // 2015-01-23 Added by Julian Knight (TotallyInformation)
                // Added cmd 13 (Close) & 14 (Stop) & 15 (Open) for Inline Relay commands
                case 13:
                    msg.payload = "Close";
                    break;
                case 14:
                    msg.payload = "Stop";
                    break;
                case 15:
                    msg.payload = "Open";
                    break;

                case 16:
                    msg.payload = "Dim " + evt.level/31*100 + "%";
                    break;

                case 17:
                case 18:
                case 19:
                    node.warn("Lighting5: LightwaveRF colour commands not implemented");
                    break;

                default:
                    // 2015-01-23 Added by Julian Knight (TotallyInformation) for debugging unknown codes
                    node.warn("rfx-lights-in: unrecognised Lighting5 command " + evt.commandNumber.toString());
                    return;
            }
            break;

It would be nice if this were in it's own NLM module :)
I could have done a pull request on it then. It would also let you get rid of all the old nodes which are generally out of date from the master library from nodered.

Anyway, I have it working for myself at present and I can do everthing I need at present I think.

[Max Hadley]

I have just pushed an update to github that handles dynamic connection & disconnection of the RFXtrx433 without disrupting a running node-RED flow. The connection status of each node is now shown if status display is enabled. I have tested this using node.js 0.10.35 and node-RED 0.9.1 on Windows 7, Mac OS X 10.9.5, and Debian 7.8 (on a Beaglebone Black). This update requires serialport 1.4.10 to work properly, and the dependency in my fork of node-rfxcom is updated accordingly.

Under the hood, my fork of node-rfxcom has switched back to using numeric subtypes, following discussion with Kevin McDermott. This has fixed the minor bug encountered by Julian Knight.

[Niall Mc Andrew]

Hi Max,

Trying to use your node-rfxcom for lighting4.

I can receive the codes from my remote:

$ sudo node ./rfxrest.js

Lighting4 listening at http://0.0.0.0:8080

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

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

[rfxcom] on /dev/ttyUSB0 - Received: 0D,01,00,01,02,53,F8,08,00,00,00,01,03,1C

[rfxcom] on /dev/ttyUSB0 - Received: 09,13,00,0C,CB,11,2A,01,7C,70

But,I'm not sure of the syntax for lighting4.

I've tried with a modified version of LightwaveRF (in the REST example on Kevin's wiki)

[extract]

var rfxcom = require('rfxcom'),

    restify = require('restify'),

    rfxtrx = new rfxcom.RfxCom('/dev/ttyUSB0', {debug: true}),

    rfxsubtype = 'PT2262';

    myLighting4 = new rfxcom.Lighting4(rfxtrx,rfxsubtype),

    server = restify.createServer({

    name: 'Lighting4',

      version: '0.0.1'

    });

server.use(restify.acceptParser(server.acceptable));

server.use(restify.queryParser());

server.use(restify.bodyParser());

server.get('/light/:device/:code/:option/', function (req, res, next) {

  //var deviceId = req.params.device + '/' + req.params.code,

  var deviceId = req.params.device,  // ignoring the other parameters (Niall)

      statusCode = 200;

  switch (req.params.option) {

    case 'on':

      console.log('Turning on light %s', deviceId);

      myLighting4.switchOn(deviceId);

      break;

[here's the URL I use ... the other parameters are ignored)

http://192.168.1.103:8080/light/0x0913000CCB112A017C70/1/on

Turning on light 0x0913000CCB112A017C70

But not working unfortunately.

Would appreciate any tips

(or a working example of lighting4).

Thanks.

Best regards,

Niall.

[Max Hadley]

Niall,

The 'lighting4' packet type is handled by the nodes PT2262-in and PT2262 out, as it is so different from the other lighting control packets, and the chips themselves can be used for many other things, such as wireless PIR sensors and of course doorbells (delve into the 'Front door Fun' thread on this group if you have a while to spare...)

The lighting4/PT2262 chips send a data code comprising an address part and a command part, but there is no consistency between manufacturers about how they are used. The PT2262 nodes use a config node called a PT2262-device-list to hold a dictionary converting these data codes to a (hopefully) more meaningful 'Topic' and 'Payload' combination. If you connect a PT2262-in node to a debug node in 'show all msg properties' mode, you should see a property called 'raw' with fields 'data' and 'pulseWidth', when a message arrives from the remote control transmitter. Use this data code and pulseWidth to create a new device-list entry with a topic/payload combination you pick. Then sending a message to a PT2262-out node with the topic and payload set accordingly will transmit a radio message using the value of data code and pulseWidth from the RFX. This should match what the remote control originally sent, hopefully turning your light on or off, as appropriate.

However, the RFX can unfortunately only receive lighting4 messages with a restricted range of pulseWidths, although it can transmit a much wider range. It is possible you may not receive anything from the remote control via the RFX.

I've not touched this stuff for a while, and I know there are issues arising from a change to the firmware of the RFXtrx433(E) that may affect operation. If I get a chance before the end of the holidays I'll take a look., as there are a few other things to do.

There's lots more (!) information buried in the front Door Fun thread...

Good luck,

Max