Communication protocol between Node-RED and Arduinos

General
1

Hello!

This question is a follow-on from an earlier post I made, which was a bit wordy! Also my thoughts have moved on, so here goes.

I've been running my own home automation wall control panels for a few years, based on Arduino Mega, openHAB, and MQTT.

mqtt-mat-smith-in-wall

It can:

  • control dimmers for each light circuit in the room (using rotary knob)
  • change lighting scene (using 5 preset buttons):

It can also control Squeezebox or Sonos, and show what's now playing.

  • Single press = play / pause
  • Double press = next track
  • Triple press = previous track
  • Preset buttons = change to favourite music or radio channels

IMG_8446
IMG_8446.jpg3264Ă—2448 875 KB

Also it's pretty easy to create other modes like weather, heating, etc:

IMG_0779
IMG_0779.jpg3264Ă—2448 885 KB

(Yes, I'm UK based, and this was NOT a recent photo :sunny::sunny::sunny: )

IMG_8447
IMG_8447.jpg3264Ă—2448 820 KB

IMG_8450
IMG_8450.jpg3264Ă—2448 845 KB

QUESTION: I am re-designing it to work with Node-RED. Right now all client/server communications happen by MQTT.

Should I move to

  • serial communication, connecting to a "gateway" Arduino?
  • TCP sockets connecting straight to Node-RED?
  • HTTP / json to Node-RED?
  • something else?

I need rock-solid reliability, potentially not even relying on network switches or servers! (i.e. I am not sure if I should design this system to be able to turn lights on if network switch is unplugged, i.e. bypass Node-RED ... is that over the top?)

If I move to serial connection this seems like a backwards step, however the benefit is that it doesn't rely on a network switch, server, and could potentially communicate directly with my centrally located light dimming (basically these are DMX dimmers like they use in theatres). In the real world, hard-wired control of lighting is far more reliable and will give less hassle over the years. Hopefully.

I have toyed with the idea of Z-Wave for light dimming. DMX dimmers are cheaper, possibly higher quality, and give me granular control over things like dimming curves. I'm not sure yet about the compatibility with LED lighting, as I haven't tested many light fittings yet.

What are your thoughts, all? I know it's not really a Node-RED specific question, but I'm interested in Node-RED flavoured answers!

2

Well for the first part, since NR supports MQTT, why not stick with that?

As for the rest, I'll let others comment on those parts.

Love the panel!

3

Hi. I'm using open source system called Hapcan for about five years now. Communication between modules is based on CAN bus. I have written lib dedicated to Arduino platform called Hapcanuino, that simulates original Hapcan devices and allows Arduino based devices communicate with them. Just mention, You/someone else may be interested in.

I've also wrote Node-RED integration for Hapcan (node-red-contribute-hapcan), so there is a full working environment, easy to setup, available now :).

4

Why do you think a network switch isn't reliable? Maybe you should try to solve your problems in this area, before stepping back to serial communication?

For a multi layer light and shutter system, one possibility is to use homematic where you have min. 3 layers (actor, ccu and node-red or whatever you like).

Nice panel, but to switch lights and music or check the weather forecast, i would prefer not to walk to the wall always...also i cant see how a visitor would easily handle the system.

5

I think you read between the lines too much: I don’t have problems in the area of networking, I am just interested in designing a system that is autonomous from an IP network. Also I mentioned it not relying on a server...

Re your other points: Having to walk to the wall to turn lights on... why would a light switch prevent you from using other forms of control? E.g. I currently set lighting using voice control (Alexa, set living room lights to 5, sets scene 5), Node Red dashboard (mobile phone, tablet, etc) as well as physical / tactile control. Secondly re your point about being visitor friendly... one of my design ideals was that the unit should be granny friendly. There are no menus and submenus, all buttons have soft labels, and it features a scene preset model which most people understand. The bottom 5 buttons are labelled with light scene names. The screen comes on when you approach it. Even if Granny can’t read the screen, she just needs to know: press blue buttons to turn lights on and red button to turn off. [granny is equivalent to visitor, etc]

I’m not familiar with homematic, I’ll look it up

6

Thanks, this is excellent! I’m going to look into this, may come back to you with questions!

7

I’m considering sticking with MQTT, just interested in others’ opinions. I suppose many people won’t be as fascist as I about reducing dependencies, to increase reliability. (I believe we are sleep-walking into a home automation nightmare with regards security, cloud-based dependencies, wireless dependencies, etc... but I don’t want to miss out on a nice control surface and nice lighting and audio for the home, and can’t afford Crestron or Lutron etc)

8

Whatever you go with in the end, you will be relying on it. And nothing out there is perfect. If anything I've found mqtt to be as close as one is going to get. +1 for mqtt :slight_smile:

1 Like