The first 2-way driver

Now that I’ve moved all my receive-only drivers to the Raspberry Pi and all 5 drivers are working great, it’s time for the next step: creating the first 2-way driver, i.e. a driver that can publish information received from the hardware as well as receive commands that have to be executed – for example to switch on a light, open the garage door or control the media player.

The problem with this is that most hardware interfaces only allow 1 connection at a time, so it’s hard to test a new Node.JS based driver while the hardware interface is still in use by the current driver. That can be a real problem… on the other hand, everything in our house can still be operated manually as well, so I’ll start with teaching the kids how to manually switch a light bulb – I think they’ve never done that before 😉 But the more I can prevent things from not working, the better of course.

First I need to take care of some things that are common to all the 2-way drivers I’ll be making in the next couple of months, so I needed a first ‘victim’ interface. For that I prepared a 2nd (spare) PLCBUS interface so that I can connect to it from a RaspBerry Pi over Ethernet. For that I used this TTL to Ethernet converter:

USR-TCP232-TThis way I don’t have to ‘do’ RS-232 or USB on the Raspberry Pi. And with a bit of luck (haven’t tried it yet) I’ll be able to squeeze that module inside the PLCBUS interface enclosure so I won’t have any wires coming out – just mains in & Ethernet out.

I had already made a Node.JS module to keep the driver code clean and re-use code for multiple drivers – this module handles the MQTT publishing stuff but it also prevents duplicate values to be published – so that when multiple identical RF packets are received for a temperature, this temperature value will be published only once and only when it has changed. I had to extend this module a bit regarding the MQTT part so that I could also let the driver subscribe to topics so that it could receive commands, like this:

tools.createMQTTClient(function(){
  tools.mqttSubscribe('command/plcbus', function(topic, payload){
  processCommand(payload);
  });
});

The new parameter, which is in fact a function, will be executed after the MQTT client has successfully connected to the broker. The driver subscribes to the topic on which it will receive its commands and will pass the payload it receives to the processCommand() function. Switching on (from Windows, Linux, Arduino, whatever – anything that can ‘talk’ MQTT) an appliance module with address B02  is now as easy as publishing a payload like:

{address:'B02', command:'ON', data1:100}

Works brilliantly! The code for receiving commands by MQTT, sending commands to the PLCBUS interface, receiving the ACK messages which are sent by the PLCBUS modules, processing those and publishing back (“B02 ON”) is all working since a few days, so all the basic functionality is finished. And again, I’m amazed by how fast I could get working code transformed to Javascript. And the code size is really small and compact, just like with the other drivers I made. Less code, less bugs…

There’s some additional functionality I want to add to the driver though; for instance, with PLCBUS it’s possible to query all the PLCBUS modules to check their on/off status. Another thing that can be usefull is that the signal strength can be requested, which can give an insight in how good the PLCBUS network is performing. Both of these things use polling, which means sending a command to the PLCBUS interface and wait for a reply. But I have to make sure that this polling won’t (or the least possible) interfere with commands from us, the users – I don’t want to wait for a light to turn on 5 seconds (or more) later, because the driver has just started its periodic polling process and put some queries in the send queue! So I’ll probably have to implement multiple queues and use some sort of back-off mechanism so that those polling queries will only be executed after a certain amount of time, without any user interaction with PLCBUS devices.

But for now I think it’s OK to say that I have my first 2-way driver working!

Bookmark the permalink.

16 Responses to The first 2-way driver

  1. Arthur van der Peijl says:

    Very interesting concept; building domotica around MQTT using node.js
    However this blog makes me a little confusing, probably because i’m still not mastering the protocols/languages:
    In what way are you using the ttl2eth converters? Do they continuous connect to the node.js-server, or do they connect when receiving ttl-data? (and must the node.js connect when sending commands).
    I’m very interested in the source code you wrote. Can it be shared?

    • Well both MQTT and Node.JS are supported on a lot of platforms, from Arduino to full-blown PC. That, and the amazing speed in which you can create things with those 2 made me decide to gradually move in that direction. I’ve got a homebrew (Delphi based) Domotica system now, which is a single executable doing everything – not flexible and a single exception can bring down the whole system; that’s the reason I wanted something else.

      The ttl2eth converters are used to connect all the hardware interfaces (PLCBUS in this case) to my LAN. Some hardware interfaces are RS485, others have RS232, some TTL level, etcetera – you name it and I’ve got it 😉 For all those hardware interfaces that don’t have their own Ethernet connection, I’ve got a “xyz to eth” converter so that I can connect to the hardware interface from everywhere on my LAN. Most of those hardware interface become a TCP server this way and I can connect to them from my Node scripts with the net module – so the node script acts as a TCP client by setting up a TCP connection to the hardware interface. Some hardware interfaces start sending their information automatically (like RF receivers), some need to be polled, it all depends on the hardware. But it can all be done from a Node script – I have a script running for each hardware interface (that I’ve managed to ‘transform’ to node so far). That same script also connects to my MQTT broker (mosquitto) and everything that needs to be shared with other parts of my system is being published to the broker (e.g. a temperature sensor value that changed).
      That’s about it 😉

      Here’s the code: https://github.com/rhekkers/DDMC_Node

      Just committed it a few minutes ago, still work in progress but I think you’ll get the idea 😉

      • Kevin says:

        I’m the author of an rfxtrx library for Node.js available at npmjs.org if it’s of any use.

        I’d be happy to look at any missing functionality you need…or pull requests with tests accepted 🙂

        • Thanks, but my RFXCOM receivers were bought in 2007 or so, the protocol is different from the current rfxtrx models, at least that’s what I’ve been told. My receivers are still working great, so no need to upgrade 😉
          And the code for the my RFXCOM receivers only supports the hardware I have: Visonic, Oregon, RFXMeter and some ‘old’ KAKU (X10) and not all the later additions. But thanks anyway!
          Robert

  2. Al says:

    Nice writings and very interesting insights. Just was wondering have you done any work or given any thought to using Webrtc for two way connections to your hardware via http?

  3. Thanks for the terrific examples. At the moment I’m building some home automation in my own enviroment. The mobotix wasn’t a great deal. Soon I will start connecting the lutron (which already has a arduino connected to it).

    Small question: do you launch the different scripts sepperately, or do you use special tools for this (cannot find useful things on internet, ‘forever’ doesn’t seem to be the most stable solution).

    • Thanks. And yes, the Mobotix is expensive if you have to buy it new.. I start the scripts separately without any extra tools like Forever. I’ve started with developing my own supervisor script that will monitor the scripts, which will also have the capability of restarting them if needed, reporting these things and more. More about that in a future post. I just came back from holidays and all the scripts were still running fine, so there’s no hurry 😉

  4. Rene says:

    Hi Robert.

    Very interesting article! One question from my side. How did you get working the connection from Rapsberry Pi to the TTL-Ethernet-Converter?

    Thanks, Rene

    • With a LAN switch 😉
      The wires at the right go to the hardware interface and the black cable to the left (Ethernet) goes to a LAN switch.
      The Raspberry Pi is Ethernet connected too, so you’ll need a Raspberry Pi model B (with Ethernet).

      • Rene says:

        This I have done already, but somehow I cannot gain access to the TTL-Ethernet-Converter via Raspberry.

        I tried:
        sudo socat PTY,link=/dev/ttyS3 TCP:192.168.10.251:20108, but I cannot access it..

        With the windows test software I receive data from there, so the converter is working.

      • Rene says:

        Also I can ping the converter (is setup to server mode) from the raspberry.
        And in /dev/ I see ttyS3 -> /dev/pts/1.

        • Well, all you need is a TCP Client on the RPi and connect to the IP/port of the TTL-Eth converter.
          That’s it…no need for a serial device on the RPi.
          I guess a simple telnet client on the RPi will do just fine to confirm that the data is arriving.

  5. Robbert says:

    You may want to take a look at a project I recently discovered called HomA (https://github.com/binarybucks/homA). HomA is doing pretty much the same thing as you are, building a home automation system with node.js and MQTT but it seems a bit further along. Perhaps they have already solved some issues you are working on. In addition, it could make sense to add your work to theirs, or at least make it compatible so that many more people can benefit from your and their work.

Leave a Reply

Your email address will not be published. Required fields are marked *