If you’ve been following the blog you’ll note I’ve spent a lot of time getting to grips with the Raspberry Pi, Node-Red, the ESP chips using C and of course my earlier home control attempts with NETIO, the NRF24L01 boards and Arduino clones (all of which are working 24/7 – I’m just getting more ambitious).
Well, it’s all starting to come together now. This morning I just put together all the pieces I’ve discussed earlier. On my workbench I have an ESP-01 based board controlling a mains light, I have the Pi with a couple of LEDs on it and I have an ESP-12 based board with some RGB LEDs and a MOSFET driving a PWM channel.
Now, I have to tell you that I’ve discovered something I’d rather not have… the PWM output is , it would seem, driven by software, NOT by hardware. I say that as I’ve realised that if I turn on the PWM output and then start fading RGB LEDs – there is some temporary interference to the PWM – and it is visible. It goes away when the RGB LEDs stop changing however. This does suggest that it would be better not to run both at once – or indeed palm off the PWM to a serially-driven Arduino-Micro or similar from the serial output of the ESP.. I turn off the interrupts when handling RGB and this no doubt is the cause. It’s not a big deal, it’s just slightly annoying.
However I’ve now put NETIO in charge of this lot and I have to say it’s working a treat. Here is my current test screen on the Samsung S4. I was going to use the NETIO text input box but the author doesn’t seem to have finished this off as it looks awful (it works, it just looks awful) so I’ve missed that off for now.
You can see the S4 screen over on the right. The RGB wheel works a treat, the slider controls the PWM, the LEFT on-off buttons control the LEDs on the Pi, and one of the rightmost pairs controls the mains light on another board. Node-Red acts as the arbitrator for this lot. TCP in from the NETIO app on the phone is sent through a function block in Node-Red in which I parse the incoming data and make sure I sent back the appropriate response. It’s trivial actually once you get familiar with Node-Red. For now I’m storing the Pi Pin states in a database but ultimately I’ll store the lot. By and large I’m just sending a message back to NetIO and then sending off an MQTT message to the relevant device as dictated to by the NETIO message.
var newMsg = { payload: msg.payload.trim() };
var myMsg=newMsg.payload.split("|");if (myMsg[0]=="gpio") { newMsg.payload=myMsg[2];
switch (myMsg[1]) {
case "0":newMsg.topic="Update pins set gpio0=" + myMsg[2];
context.global.gpio0=myMsg[2];
return [newMsg,null,null,null,msg,null];
case "1":
newMsg.topic="Update pins set gpio1=" + myMsg[2];
context.global.gpio1=myMsg[2];
return [null,newMsg,null,null,msg,null];
case "2":
newMsg.topic="Update pins set gpio2=" + myMsg[2];
context.global.gpio2=myMsg[2];
return [null,null,newMsg,null,msg,null];
case "3":
newMsg.topic="Update pins set gpio3=" + myMsg[2];
context.global.gpio3=myMsg[2];
return [null,null,null,newMsg,msg,null];
default:
return [null,null,null,null,msg,null];
}
}
else if (myMsg[0]=="gpio?")
{
switch (myMsg[1]) {
case "0":
msg.payload=context.global.gpio0+"\n";
return [null,null,null,null,msg,null];
case "1":
msg.payload=context.global.gpio1+"\n";
return [null,null,null,null,msg,null];
case "2":
msg.payload=context.global.gpio2+"\n";
return [null,null,null,null,msg,null];
case "3":
msg.payload=context.global.gpio3+"\n";
return [null,null,null,null,msg,null];
default:
return [null,null,null,null,msg,null];
}
}else if (myMsg[0]=="mqtt") // message and topic passed
{
msg.topic=myMsg[1];
msg.payload=myMsg[2]+"\n";
return [null,null,null,null,msg,msg];
}return [null,null,null,null,msg,null];
So I see you’re using node red with the ESP8266. I’ve used it a lot for my home automation stuff using mostly XBee based sensor boards, an XBee on a Raspi and python code to gather the serial data from all the XBees and send it to a TCP socket on node red. It’s beautiful. Once I get it into node red, anything goes; data logging, Graphite charting, actuation, even connecting to old X10 lighting, etc.
Now I want to send the sensor data through an ESP8266 and cannot for the life of me figure out the AT commands I need to just send to a TCP socket (like the listener on node red) to a specific port.
The ideal would be to have the ESP8266 sending data as fast as it can from all it’s sensor data to the Node Red TCP listener and occasionally it could receive some data to flip a relay turn on an LED, etc.
Do you have any samples or references where sending data from an ESP8266 to a TCP socket is described. Maybe some sample arduino code?
Thanks for any advice,
Chris.
Hi Chris – can’t help you with the AT code as I long ago abandoned it in favour of programming up the ESP chips to use MQTT. So I simply send MQTT messages from Node-Red to the boards and back.
Thanks. I’ll look into using MQTT directly.
Pete,
Have you seen “mqttwarn”, yet? Seems like it might be another piece of the overall puzzle. It’s basically a notification service, taking an MQTT message and transforming the payload to suit the target recipient service. Its strength is in the number of recipient services it can handle (and the fact that you can write your own plug-ins for custom services).
https://github.com/jpmens/mqttwarn.git
Not a Node Red replacement, but something that could be useful for those messages that really, really need to get delivered (“Smoke alarm activated, kitchen, Bellingham”).
-John-
Hi John
That does indeed look useful if it will run on the Pi.. But actually it seems to do nothing more than Node-Red does already. With 2 boxes or 3 if I wanted to alter the message I can send an incoming mqtt message to any combination of email, Twitter, Pushbox, instagram, flicker, mqtt, serial and other services and outputs. Still… Worth a look