MQTT publishing with the ESP8266 + Arduino

This is more or less a follow-up on my previous post about using the ESP8266 to MQTT-enable an Arduino (or a JeeNode in my case). The first time I installed the espduino library there was no publish available yet; one day later it was, so this afternoon I installed the latest version in the Arduino IDE and gave publishing a try.

All I had to do was adding some additional code to the example:

int reportInterval = 10 * 1000;
unsigned long now = 0;
unsigned long nextPub = reportInterval;

void loop() {
  esp.process();

  // will work for 49 days; that's OK.
  now = millis();
  if (now >= nextPub) {
    nextPub += reportInterval;
    String payload = "Payload ";
    payload += now;
    char char_array[payload.length()+1];
    payload.toCharArray(char_array, payload.length()+1);
    esp.publish("topic", char_array, payload.length()+1, 0, 0);
  }
}

The result:

Espduino libaray publishing

I noticed that the keepalive packets are still being sent even though the publishing is done every 10 seconds; I can’t recall seeing that behavior with other MQTT clients – as far as I know keepalive packets are only needed to ping the broker when there hasn’t been any other communication within the keepalive interval, but I might be wrong about that. I’ll have to check that some day.

For now this is not a real issue but it probably will be when the library will be used in a setup that’s battery powered. Another question I have is: what would be an acceptable keepalive interval for a battery operated MQTT client? For some sensors even a value of 3600 seconds would suffice I guess..

Last thing on my mind is a good auto-reconnect feature for this; a closed connection (e.g. because your Wifi AP has been down for a short period) should not be a reason to power cycle all those ESP connected devices in your house..!

MQTT client for Arduino with the ESP8266

A few days ago I saw a new (first commit on GitHub just 5 days ago) library that made it possible to use MQTT on an Arduino-ish board and use the ESP8266 Wifi Serial Transceiver to connect to a MQTT broker. I just had to try it out ūüôā

ESP8266 MQTT JeeNode

I used the same setup as before cause it was still on my desk, installed the library in the Arduino IDE, checked the¬†SERIAL_BUFFER_SIZE in [your program files]ArduinohardwarearduinocoresarduinoHardwareSerial.cpp (OK in Arduino 1.0.6, didn’t check older versions), changed the example regarding MQTT broker address, Wifi SSID & password, client id (JeeNode_on_your_desk), set the debug serial port to pins 6 & 7 and uploaded the sketch to the JeeNode.

And it’s working, as the Mosquitto MQTT broker messages show below:

D:Program Files (x86)mosquitto>mosquitto -c mosquitto.conf
mosquitto version 1.1.2 (build date 30/01/2013 20:46:29.67) starting
Config loaded from mosquitto.conf.
Opening ipv6 listen socket on port 1883.
Opening ipv4 listen socket on port 1883.
New connection from 192.168.10.155.
New client connected from 192.168.10.155 as JeeNode_on_your_desk.
New connection from ::1.
New client connected from ::1 as mosqpub/3228-devbox.

Nice! Let’s try to send an MQTT message to the JeeNode:

mosquitto_pub -h localhost -t /topic -m "Hi there, it's me!"

And the debug port showed this:

[espduino_mqttclient]
RESET ESP done
WIFI: Connected
TCP: Connected
AT+CIPSEND=36
MQTT: Connected
MQTT:Connected
MQTT: subscribe, topic
AT+CIPSEND=13
MQTT: Subscribe successful

MQTT: Send keepalive packet
AT+CIPSEND=2
MQTT: Send keepalive packet
AT+CIPSEND=2
MQTT: Send keepalive packet
AT+CIPSEND=2
Received, topic:/topic, data:Hi there, it's me!
MQTT: Send keepalive packet
AT+CIPSEND=2
MQTT: Send keepalive packet
AT+CIPSEND=2
...

And here’s what the communication between JeeNode & ESP8266 looks like:

AT+RST
ATE0
AT+CWMODE=1
AT+CWJAP="SSID","password"
AT+CIPMUX=0
AT+CIPCLOSE
AT+CIPSTART="TCP","192.168.10.179",1883
AT+CIPSEND=36
 "  MQIsdp     JeeNode_on_your_deskAT+CIPSEND=13
¬ā,    /topic AT+CIPSEND=2
AT+CIPSEND=2
AT+CIPSEND=2
...

Nice; not that I have any immediate use case for it (my Zigbee network based on XBee modules is still working fine), but it’s fun to see this working and good to know it exists.

Next ‘experiment’ will be an MQTT client on the ESP8266 itself (yep, without MCU). I’ve already installed the ESP8266 Windows Eclipse IDE in a VM so that I can flash the ESP8266 with a firmware that includes this MQTT client; that will be even more exciting; stay tuned!

Meet the ESP 8266 WiFi Serial Transceiver

esp8266Look what I found under the Christmas tree about a week ago – ESP8266 modules ūüėČ

A tiny module with a size comparable to a Fibaro Universal Sensor. Basically, the ESP8266 enables you to add wireless connectivity to your hardware – to anything that does serial; for example your Arduino or Raspberry Pi. But there’s more to this module – you can build your own firmware, program it in Lua and do stuff that might make that additional MCU obsolete.

But for now, all I have to tell is about my experiences during the first few hours with the ESP8266.

After unwrapping the modules the first thing I had to find out the purpose of the 8 pins of the ESP8266 board. VCC, GND, RX, TX and found out about those really quick; I also found a small Arduino sketch that would allow me to test some basic functions of the ESP8266 so I set things up on a breadboard and uploaded a sketch to a spare Arduino.

No go.. I had been a bit too hasty, thinking that a single webpage would provide all the information I needed to get things going. After a while I found out that the CH_PD pin had to be pulled up to VCC to set the ESP8266 to ‘normal operation’ mode. Cause when pulled to GND, the ESP8266 will just sit and wait for a new firmware to arrive … OK, got that. Still no go; that’s when I read about the different baud rates – some models work with 9600 bps, others with 57600 bps so maybe the ESP8266 and the Arduino weren’t using the same bps. So I decided to just hook up the 2nd ESP8266 to my PC with a PL2303 serial to USB cable and see if I could get the module to respond to some AT commands.

ESP8266 with PuTTYPuTTY is one of my favorite tools for telnet, ssh and it can also do serial communication, so I used PuTTY to send some AT commands to the ESP8266, but after some time I gave up… I knew I was using the right speed (9600 bps in my case) but the module just didn’t respond after- no OK; nothing.

ESP8266 with TermiteChanged some settings, still no answer. Made PutTTY add an additional LF after a CR but still no luck? Eventually I switched to Termite, cause I found out that I wasn’t the first having problems with the combination PuTTY + ESP8266.

 

Now that I knew it was 9600 instead of 57600 bps I could proceed with the sketch mentioned earlier. Another ‘problem’ was that the Arduino operates @5V and the ESP8266 @ 3.3V, so I had to do something about that too; I saw all kinds of solutions with level shifters, resistors, diodes and decided to go the easy way – a JeeNode which operates @ 3.3V:

ESP8266 on a JeeNode

The result in the PuTTY window that was connected to the ‘debug’ Serial port (pins 6 & 7):

ESP8266 PuTTY screen

Neat. Needless to say that this is just a small example of what this ESP8266 can do; it can do much more than just fetching a small web page – I haven’t even scratched the surface yet! A Wifi Door sensor for the price of an ESP8266, a reed switch + magnet and power supply.. the latter is the only downside of the ESP8266: it consumes too much power to run on batteries. Well, you can’t have ’em all … (yet?) Besides that, I love this little powerful Wifi module.

Adding a smart meter to the Fibaro HC2

This is (sort of) a follow-up on my previous post about the cheap Serial to Ethernet converter. It has kept me busy for a couple of evenings, for several reasons:

  • I wanted to use the Arduino Nano as a web server;
  • Make the Nano return a JSON object containing the smart meter data;
  • Learn more about the Fibaro HC2 on the job;
  • The new sketch was unstable.

It was mostly that last item that kept me busy for some time – well, waiting describes it better actually, cause the sketch I initially wrote was doing what it should, but wasn’t stable – it stopped working after 2 hours, the next time after 20 hours.. totally unpredictable. I also saw the Nano was sometimes missing incoming serial P1 data. And of course, these sort of things never happen while you’re there to witness it: I was always either at work or asleep (or both ūüėČ ).

So for a few days I tried to improve things and had to wait until the next day to see if the changes fixed the issue. It wasn’t lack of free RAM, it wasn’t the USB hub misbehaving, it wasn’t RF interference, nor was it a grounding issue. After I found a solution, the cause was very obvious actually: the Nano doesn’t do multitasking. Somehow taking care of receiving and processing serial data and handling an Ethernet shield interfered with each other – I still don’t know why, but after I denied the web server part of the sketch of servicing HTTP requests while the smart meter data was being received, this problem was solved. Detecting the beginning and end of a P1 packet is easy: it starts with ‘/’ and ends with ‘!’. So now the loop() looks like this:

void loop() {
  c = mySerial.read();
  switch (c) {
    case '/':
      receiving = true;
      ...
      break;
    case '!':
      receiving = false;
      ...
      break;
  }
  ...
  if(!receiving) {
    if (ether.packetLoop(ether.packetReceive())) {
      ...
      ether.httpServerReply(readingsPage());
    }
  }
}

With a P1 packet being about 500 bytes in size and 9600 baud this would ‘stall’ the response for about half a second (max.), which should not be a problem.

After I finally had a sketch that kept working for >48 hours it was time to have a look a the Fibaro HC2 and try to get the smart meter information (visibly) available in there.

Because I’ve spent very little time with the Fibaro HC2, please don’t put too much weight in what I have to say about the HC2, but: there’s one word that’s now associated with the HC2 in my head: impressive.¬†The HC2 case feels solid, looks good, gets warm, the UI looks good, the power consumption is about 13.5 W doing nothing¬†(I had no Z-Wave hardware to add), and the HC2 has something called¬†Virtual Devices. For me, that’s the thing I’m interested in the most – using the HC2 is not my thing, but exploring what I can do to add my own things to it is..

So after I hooked up the HC2 to my LAN, performed some upgrades and changed some settings, I immediately focused on those Virtual Devices. P1 Smart meter in Fibaro HC2I know I’ve just scratched the surface so far, but being able to create a Virtual Device within minutes and being able to get the smart meter data from the Nano web-server into Virtual Device properties and being displayed nicely as well with just a lua script of ~20 lines of code – that’s impressive! Not bad for a beginner ūüėČ And for a price <20 Euro! Add a database solution, charting and I think the HC2 has a great future ahead.

 

Although I liked what I’ve seen so far, I do have some things that might be not so handy.

The lua script I wrote, was only 20 lines or so. Editing the code from within the browser, in a small window is not really as comfortable as editing code can/should be. And more important, everything you need in a script has to be in there (AFAIK) – so suppose you have to calculate a CRC, the CRC code has to be inside the script that needs it – no way of including source code files which will probably be used in more ‘main loops’ than just 1. I’d really like to see some sort of ‘Plugin’-ish way to add support for exotic hardware; a bunch of files with code, UI pages that can be embedded in the HC2 UI (e.g. for configuration stuff), creating Plugin specific triggers etcetera. In other words: really embed your own creations into HC2.

If Fibaro can accomplish that, then the HC2 can become the killer solution for Home Automation for a lot of people; with Z-Wave as the base technology, yet still expandable with support for other popular hardware.

Oh my, almost forgot the lua script, here it is:

--[[
%% properties
%% globals
--]]
fibaro:debug("start")
if (nano == nil) then
  nano = Net.FHttp("192.168.10.191", 80)
end
response, status, errorcode = nano:GET("/")
fibaro:debug(response)
local data
data = json.decode(response)
-- not 0 based!
jso = data[1]
v181  = jso.v181
v182  = jso.v182
v170  = jso.v170 * 1000
v2421 = jso.v2421
-- deviceid 7
fibaro:call(7, "setProperty", "ui.lbl181.value", v181.." kWh")
fibaro:call(7, "setProperty", "ui.lbl182.value", v182.." kWh")
fibaro:call(7, "setProperty", "ui.lbl170.value", v170.." W")
fibaro:call(7, "setProperty", "ui.lbl2421.value", v2421.." m3")
fibaro:sleep(10*1000)

Have fun!

Flexible Serial to Ethernet for less than 20 Euro

Nano v3 with Ethernet Shield

Wired connections have always been my favorite for connecting hardware to my Home Automation System. This week I found a new way of doing that – costing only 17 Euros, purchased at AliExpress.

What you see in the image above is a¬†ENC28J60 based Ethernet shield with a Arduino Nano 3 on top of it. Measuring about¬†70 x 20 x 37 mm (with the lower pins cut to half their length). Very small and programmable ūüėČ

Last Friday 2 sets (of shield & Nano) arrived and I just couldn’t resist giving them a try and since I’ve still got a Raspberry Pi near the smart meter for the sole purpose of collecting the data it produces, it looked like a good idea to see if I could replace the RPi with this Ethernet-Nano.

Finding a library for the¬†ENC28J60 based shield wasn’t hard – I had already worked with Jean-Claude Wipplers Ethercard before and which is still in use as our doorbell controller, so that wouldn’t be any problem. But first I had to solve the problem I had when I connected the Nano to my PC- ‘Device enumeration failed’ is what USBView told me. It took a while before I got the idea to place a powered USB hub in between the two…. problem solved.

This Ethernet shield uses pin 10 for CS (Clock Select) but this was easy to change in the code; instead of

if (ether.begin(sizeof Ethernet::buffer, mymac) == 0)

all I had to do was supply an extra parameter and it all worked instantly:

if (ether.begin(sizeof Ethernet::buffer, mymac, 10) == 0) 

There’s one small problem I still have to fix, which is doing a DNS query on the Nano. It times out and I have no clue why; for now I added a ‘fallback’ IP address in the code until it’s fixed.

EthernetNano test setupI used a 2nd Arduino to play the smart meter ‘role’ by sending a P1 datagram to the Nano over a serial connection with an interval of 10 seconds – that would be as close to reality as it could get. I connected the TX pin of the Arduino Ethernet (the bottom one) ¬†to the RX pin on the EthernetNano and all that was left to do was writing a sketch.

Sometimes it looks like everything has been developed before already, the only thing you have to do is find it or remembering where you saw it – well, that was the case here also. With the Ethercard library come a couple of examples which I could use for the Ethernet part of the sketch. And I knew that Jean-Claude Wippler had blogged about P1 data a couple of times – strip the RF12 code and replace it with Ethernet code and I would be ready to go… and that’s exactly what I did ūüėČ

Here’s the code for my first EthernetNano handling the smart meter data and uploading it (with HTTP) to my HA system! Bye bye RPi…

/// @dir p1scanner
/// Parse P1 data from smart meter and send as compressed packet over RF12.
/// @see http://jeelabs.org/2013/01/02/encoding-p1-data/
// 2012-12-31 <jc@wippler.nl> http://opensource.org/licenses/mit-license.php

// Changed to work with Ethernet shield, 2014-06 Robert Hekkers

#include <SoftwareSerial.h>
#include <EtherCard.h>

#define DEBUG 1   // set to 1 to use fake data instead of SoftwareSerial
#define LED   0   // set to 0 to disable LED blinking

SoftwareSerial mySerial (7,17 /*, true*/); // rx, tx, inverted logic
#define NTYPES (sizeof typeMap / sizeof *typeMap)
// list of codes to be sent out (only compares lower byte!)
const byte typeMap [] = {181, 182, 281, 282, 96140, 170, 270, 2410, 2420, 2440};

byte Ethernet::buffer[700];
static byte mymac[] = { 0x74,0x69,0x69,0x2D,0x00,0x01 };
const char website[] PROGMEM = "devbox.hekkers.lan";
uint8_t hisip[] = { 192,168,10,179 };
Stash stash;

byte type;
uint32_t value;
uint32_t readings[NTYPES+1];

static bool p1_scanner (char c) {
  switch (c) {
    case ':':
      type = 0;
      value = 0;
      break;
    case '(':
      if (type == 0)
        type = value; // truncates to lower byte
      value = 0;
    case '.':
      break;
    case ')':
      if (type)
        return true;
      break;
    default:
      if ('0' <= c && c <= '9')
        value = 10 * value + (c - '0');
  }
  return false;
}

static void collectData (bool empty =false) {
  if (!empty) {
    for (byte i = 0; i < NTYPES; ++i) {
      Serial.print("@ ");
      Serial.print(typeMap[i]);
      Serial.print('=');
      Serial.println(readings[i]);
    }
    byte sd = stash.create();
    stash.print("0,");
    stash.println(millis() / 1000);
    for (byte i = 0; i < NTYPES; ++i) {
      stash.print(typeMap[i]);
      stash.print(",");
      stash.println(readings[i]);
    }
    stash.save();
    // generate the header with payload - note that the stash size is used,
    // and that a "stash descriptor" is passed in as argument using "$H"
    Stash::prepare(PSTR("GET http://$F/p1/ HTTP/1.0" "rn"
                        "Host: $F" "rn"
                        "Content-Length: $D" "rn"
                        "rn"
                        "$H"),
            website, website, stash.size(), sd);
    // send the packet - this also releases all stash buffers once done
    ether.tcpSend();
  }
}

void setup () {
  if (DEBUG) {
    Serial.begin(115200);
    Serial.println("n[p1poster]");
  }
  mySerial.begin(9600);
  // digitalWrite(7, 1); // enable pull-up
  collectData(true); // empty packet on power-up

  delay(2000);
  if (ether.begin(sizeof Ethernet::buffer, mymac, 10) == 0)
    Serial.println( "Failed to access Ethernet controller");
  if (!ether.dhcpSetup())
    Serial.println("DHCP failed");

  ether.printIp("IP:  ", ether.myip);
  ether.printIp("GW:  ", ether.gwip);
  ether.printIp("DNS: ", ether.dnsip);

  if (!ether.dnsLookup(website)) {
    Serial.println("DNS failed");
    ether.copyIp(ether.hisip, hisip);
  }
  ether.hisport = 80;
  ether.printIp("SRV: ", ether.hisip);
}

void serialLoop() {
  byte c;
  while(mySerial.available()){

    c = mySerial.read();
    if (c > 0) {
      //c &= 0x7F;
    }
    switch (c) {
      case '/':
        break;
      case '!':
        collectData();
        memset(readings, 0, sizeof readings);
        break;
      default:
        if (p1_scanner(c)) {
          for (byte i = 0; i < NTYPES; ++i)
            if (type == typeMap[i]) {
              readings[i] = value;
              break;
            }
        }
    }
  }
}

void loop () {
  ether.packetLoop(ether.packetReceive());
  serialLoop();
}

I’m sure I’m going to use this EthernetNano more in the future – the very small size, price, built-in flexibility make this a great solution for a lot of things!

 

 

 

 

 

Arduino with TFT Touch Shield

TFT Touch ShieldAfter the TFT Touch Shield I ordered had arrived and some playing around with the examples that were part of the library that can be found here, it was time to do some testing.

For starters I made a small sketch with just a string, 3 ‘touchable’ areas and an icon. The first challenge was making the drawLine() function from the library working; somehow it had problems with drawing the left side of the roof of the ‘home’ icon. No clue why, but it just didn’t work. Only after I changed the parameter types from unsigned int to int and replaced the algorithm with the simplified version of the Bresenham line algorithm¬†the home was correctly drawn.

Next thing I did was printing some touch related information to the Serial and this is what I saw:

X = 611, Y = 442, P = 575
X = 609, Y = 443, P = 536
X = 606, Y = 444, P = 507
X = 599, Y = 447, P = 457
X = 599, Y = 447, P = 449
X = 600, Y = 440, P = 486
X = 601, Y = 434, P = 522
X = 642, Y = 604, P = 470
X = 634, Y = 609, P = 468

Well, so far so good… on to the next phase!

Extra user interfaces

I’ve been looking for an easy way to add some extra user interfaces to my Domotica system, particularly for upstairs. Now that we have a bunch of Radiator Thermostats and Roller shutters both up- and downstairs, the wish for some extra User Interfaces (bedrooms, office etcetera) increased the last couple of weeks. Yes, the Radiator Thermostats can also be operated manually, but that’s not always that convenient; I want something more flexible and versatile.

Should I buy a tablet and put it on the wall? Neh, too pricy and therefore not expandable enough – we would be bankrupt before I could finish this project ;-).

Or is it better to create a User Interface for the¬†smartphones? Useless for this particular ‘problem’, cause we all have the habit of leaving our smartphones downstairs – no one has the urge to Tweet or call while in bed (yet…). Besides that, guests in our house should also be able to lower a roller shutter without too much hassle.

What I’d like to have is something small & simple, touch-driven, communicating wirelessly, with an easily adjustable User Interface without having to change the code too often and, if possible, suitable to take in your hands.

For that I bought this Touch Shield to tinker with during the next weeks. There are some nice videos that demonstrate what you can do with these Touch shields and they look well enough to give it a try. This particular shield can be used with the Adafruit library, which takes care of the low level stuff and provides functions for stuff like drawing lines, circles, rectangles and text on the screen Рwith an SD card it should even be possible to draw 24-bit BMP files Рwell, let that be be step 2 for now.

While this Touch Shield is on its way, I started thinking of how to make this Touch Shield cooperate with my Domotica system. As I said, I don’t want to change the sketch when I want to add another menu option or button or anything else that comes to my mind; the ‘definition’ of the screens, menus, buttons should not be defined in the sketch, but somewhere else. Preferably somewhere on the network in a file; another good option could be stored on a SD card.

This file should contain everything that can be regarded as being subject to change when multiple Touch Shields are going to be used throughout the house: menu options, shapes, buttons, colors, text, actions; so the basic idea is: 1 sketch which can handle multiple User Interface definitions, designed for a specific location/room.¬†So I definitely need some sort of¬†User Interface Markup language for that, like XAML¬†is. ¬†But the markup language to be used should also be really ultra-light-weight, cause we’re still dealing with an Arduino here, where RAM is limited and every bit of overhead leads to problems, very quickly. I mean, you could define a button like this:

<Button Background="Red" Foreground="Green" Content="Light on" Action="C02 ON"/>

but that will consume more memory than

B;BRED;FGREEN;TLight On;AC02 ON

So maybe I’ll create my own Markup ‘language’; we’ll see.

The way in which an action will be communicated with my Domotica system will be something comparable to how our Ethernet Doorbell communicates with the system; for example, when the touch of a button should result in a light going on or off, I can just let the Arduino send a string (the Action property in the examples above) to my system and it will take care of the rest.

Big plans, which also bring a lot of new challenges – and I’m sure, a lot of fun!

Today the color is…

Orange!! ūüėČ

 

Well, it could just as well have been any other color of the 256*256*256 colors these RGB LEDs can produce, but since today is Koninginnedag, Orange was the most appropriate color I could think of for today.

The last 2 days I started with putting these RGB LEDs in the ground, under the gazebo.

Removing the stones to get the 20 meters of cable under the terrace, grit around the poles and putting everything back in place took me 2 days and I’m still not completely done yet; I think I need another afternoon for the ‘finishing touch’.

 

 

Just for fun I made a small beginning with controlling these LEDs from my system by using scenarios or lighting sequences; here’s what the “random” color scenario looks like:

 

I’m also going to use a remote for these RGB LEDs; I still have an old 433 MHz remote with 8 buttons that can be re-used to select the different scenarios. This remote will be attached to one of the poles of the gazebo so we won’t need to go inside to change the lighting.

With the Arduino acting as web-interface to the hardware, my domotica system and this remote I think we can really enjoy these RGB LEDs during those many upcoming long, hot summer nights!

Broken cables and Ethernet Shield trouble

It’s time for some work outside.. Last summer the play set ¬†in our garden with slide and swings was hardly used, so I guess the kids won’t miss it. The swimming pool has to be filled with water again, the pump has to be put back in its place, the terrace needs some adjustments and of course, the gazebo RGB LED project needs attention cause the¬†crate with the 6 RGB LEDs, DMX decoder & Arduino has been standing in the office since the end of last summer, so it’s time to finally complete this and get those 6 RGB LEDs where they belong – in the garden. I started with the last job ūüėČ

The first thing I did was completing the indoor part of it all, e.g. putting the adapter, DMX decoder, Arduino with 2 shields (DMX & Ethernet) in a enclosure.¬†This whole setup has already been tested with something I developed last summer. It had a Colorwheel control with which it was very easy to pick a color and control the RBG LEDs. But this is not enough; I still needed to integrate those RGB LEDs into my Domotica system. By doing that, my system is now in full control over the RGB LEDs and they can be controlled based on events, from the GUI (touchscreen) in the living room etcetera. This integration involved creating a Device Class for the RGB LEDs and a suitable interface to ‘talk’ to the hardware.

But not all things went as smooth as I had hoped. First, a power adapter cable was broken, which made the whole setup stop working every few minutes or so. It cost me half the afternoon to find out it was just a piece of cable that was bugging me…

I also applied the ‘Ethernet-shield-powered-from-the-adapter-plug’ fix I wrote about before, but it didn’t help enough. Sure, 4 out of 5 times it worked, but not always. And that’s not good enough, so I searched for another solution and I found one here, and this one worked always – well, successfully¬†powering up 30 times in a row convinced me that this works well enough. So now there’s a wire going from the RESET pin to pin 4 (the Ethernet shield is underneath the DMX shield).

Ethernet Shield fix

The code that comes with it is simple but very effective:

void init_ethernet()
{
 pinMode(DO_RESET_ETH_SHIELD, OUTPUT);      // sets the digital pin as output
 digitalWrite(DO_RESET_ETH_SHIELD, LOW);
 delay(1000);  //for ethernet chip to reset
 digitalWrite(DO_RESET_ETH_SHIELD, HIGH);
 delay(1000);  //for ethernet chip to reset
 pinMode(DO_RESET_ETH_SHIELD, INPUT);      // sets the digital pin input
 delay(1000);  //for ethernet chip to reset
 Ethernet.begin(mac,ip,gateway,subnet);
 delay(1000);  //for ethernet chip to reset
 Ethernet.begin(mac,ip,gateway,subnet);
 delay(1000);  //for ethernet chip to reset
}

Calling the init_ethernet() function from the setup() is all that’s needed to get a fully functional Ethernet Shield. Finally this RGB LED project is finished; well, I still have to dig 6 holes and get the RGB cable under the terrace – after that, summer can begin!

 

Got it!

Yes, yes, YES! I love it ūüôā

The rethinking of the OpenTherm bit capturing strategy I did a few days ago really did improve things quite a lot, as can be seen on a screendump of my OT Decoder:

"My" OpenTherm decoder

Below is what the Opentherm Monitor, a tool that belongs to the OpenTherm Gateway (yep, I’ve got one of those too, since a week or so ūüėČ ) is showing in the log:

Gateway Opentherm Monitor

This is great, wonderful result! And the¬†time it took to come this far was well spent, cause I’ve learned a lot in the past days. I’m starting to know the Opentherm Data ID’s by heart, I know some more about the ATMega timers and Manchester decoding has no secrets for me anymore.

You may notice that in my case only the Master (lines with a ‘T’ in them, in both screendumps) frames are decoded and not the Slave response frames (Slave=Boiler, starting with a ‘B’ in the lower screendump), but that’s because I added a delay that causes the sketch to skip the Slave responses.

So the sketch is going to be the next thing I’m going to work on in the next couple of days. But for today, I’m going to relax and and stop thinking about microseconds, timers, prescalers and ISRs; ¬†it’s time for something completely different: a Somfy RS-485 RTS Transmitter for our rolling shutters which will (hopefully)¬†arrive in ¬†a few weeks! That’s why I like Domotica so much – the diversity of things to do and learn.