More Home Control 2016 Updates

As of version 1.5.61 of the Home Control 2016 code,  I’ve now expanded the {debug} command considerably, added new Hitachi display commands and introduced a new MQTT topic called “otacomplete”. Here incidentally is the Bitbucket repository for all of this.

The Hitachi commands are documented in the manual.  As for the new MQTT topic, this is so that, should you choose to OTA update a unit remotely, you have some means to know asap that it is working.  In the event of an OTA update, the unit will send out the following MQTT message:

topic : otacomplete
payload: [the ID of the unit]

Typical serial on-demand debug output at the time of writing – for a test unit with ID “freddy” - with passwords changed to protect the innocent:

Time: 09:07:05 11/08/2016
Time Code: 1470906425
Dusk: 21:08 Dawn: 07:22
On1: 08:00 Off1: 12:00 On2: 15:00 Off2: 23:00 Peak: 23c Off-peak: 19c Frost: 14c
IP: 192:168:1:25
Internal ID: ARPS_00A68508
ID: freddy
DESC: empty
SSID: wififorus (Active)  Pass: xxxxxxxx
SSID2: wififorus  Pass2: xxxxxxxxx
MQTT Host: Port: 1883 User: admin
OTA Host:  Port: 80
Code Version: 1.5.61
SDK Version: 2.0.0(656edbf)
RSSI: -48
Out0: 0
Out4: 0
Out5: 1
Out12: 0
Out15: 0
Out16: 0
Sensor Type: DHT22
Temperature Port: GPIO2
GPIO13 available for general use: No
GPIO2 is an input
Sonoff setting=0
WiFi button=2
Invert settings=HEX( 1)
Serial2 settings=0
RGB Indicator=1
No LED clock
CPU frequency: 80Mhz
Free Heap: 16680 bytes
Up Time: 0:05:04


21 thoughts on “More Home Control 2016 Updates

    1. i think you have to subscribe for topic DEVICE-ID/fromesp/otacomplete
      and you get the output there... right Peter?
      Peter, we are new to this stuff, not entirely "in topic" yet, forgive us for this questions... it's not always simple understand the underlying functionality and/or terminology, or the workflows...

      anyway, the sooner one start digging this stuff, the better he understand it and the awesome work Peter did... without firmwares as his one, we should upload every sketch every time a little mod is needed in code... his way, it'is just connecting stuff in node-red...

      sure, without node-red they do nothing, but the purpose of this work is to centralize "development", leaving devices around and getting/pushing values and VALUE around... really enjoying spending some hours a day studying all these 🙂

      on my own, i'm trying to integrate a sim800l gsm/gprs module to have notifications even when connectivity is lost...

      and, Peter, will it be possible to integrate some battery voltage polling, for devices like the wemos d1 mini or other, that can be powered via a nano-shield with a lipo-charger, useful as small UPS... i'd like to leave some devices outdoor, to have external temperature, so no fixed power supply, just a small lipo battery and maybe a solar charger...

      here some info on how to read battery voltage, it's just a pair of lines:
      int batteryVoltage = ESP.getVcc();

      1. I thought about having to subscribe to each unit - and figured a better way was for the unit to be in the payload so you only have one subscription.

        Battery voltage done - on our board we have a pair of dividers (see schematic) and there's a command {voltage} which goes up to 20 I think - I use it to monitor constantly the state of my camping battery which is on solar charge - to make sure that light duration is reduced during winter. That's been there for ages - see manual - currently page 67.

  1. Hi Pete,

    Misunderstanding. I am monitoring otacomplete, works a treat. I was hoping to be able to check the software version on running esps using mqtt. {debug} is great if using serial but is not available on mqtt.



      1. Pete,
        I think this is an undocumented command. At least, I couldn't find it in the Hackett & Bodget document.

        I couldn't find otacomplete either.

        Am I looking in the wrong place?

  2. Peter, may I ask you how do you implement all of this? I mean, a guide for an initial setup of everything... i think it would be a nice addition to the manual, too...

    you are very skilled and maybe some assumption are done due to your many years of practice in this new "iot world"... but, just to say, if i have to start a domotic project, i need:
    a central controller, ok, let's use node-red
    many remote boards with sensors and actuators, they can be esp8266 as are cheap and reliable and have you great firmware

    but now, i added these boards to node-red, how to manage them? This is what is confusing me... let's take the otacomplete: how do you read it? have it connected to some display, or app, or what? have you a flow that sends them somewhere? i don't think you look at the node-red dashboard debug screen... same for other stuff, how do you deal with the outputs of all your boards around 2 countries? Imperihome or blynk or ifttt? how do you monitor them? what do you subscribe to, at the beginning?

    i mean, could you take us on a tour of a real life implementation of this incredibly vast and new world? how do you start, if you need to do it from scratch? i know i'm asking a lot, but i think it would be a very helpful guide... everybody has his needs, but the initial setup i think is common...

    thanks in advance 🙂

    1. I should say one thing in advance, I am not an educator. I do this for fun and the challenge.

      So Domotics I can't comment on - not of interest. For a central controller, the Raspberry Pi is good not because it is powerful but because of support. FriendlyArm boards seem reasonably supported and they do generally will run Debian and Node-Red without issue.

      ESP8266 are proving reliable - they are cheap and are indeed a one-stop solution for MQTT over WIFI communication. Sadly not all of the sensor software out there for, say Arduino will readily run on ESP8266. I've now tried 2 libraries which simply have not to date worked for me so I tend to find out how the chips work and do my own thing if I can't get existing software to work.

      Node Red is a tool, not an end solution - you need to write flows to do whatever it is you want. Node-Red takes the grunt out of it. For example if you want to monitor a movement sensor and send yourself an email when something changes, the ESP board can do the sensing and report that to MQTT. Node-Red can subscribe to that and hence pick up the incoming signal. There are existing nodes for email, Twitter etc and hence sending an email is a no-brainer.

      OTA in my case - When I compile the code, I send the ROMS to the root of my webserver with a simple piece of Python. By sending a serial or MQTT command to the ESP board {otaupdate} the board goes off looking for the ROMS (well, just the one actually for OTA) and grabs the info - putting it in part of the FLASH that is currently not in use. The board then reboots and uses the new code - all of this is done without any user effort other than invoking the command.

      Distance is irrelevant - any of my boards can talk to any other board by MQTT - I have an MQTT broker in each country and one can talk to the other - I simply have a node subscribing to a topic in the other country - and vice-versa - hence any actions I define in flows here in Spain I can easily send an MQTT message back to the UK - and vice-versa. The only difference is a different broker (server) address.

      The easiest way to get started is simply to get MQTT running on a Pi or on your PC, get a couple of board talking, read whatever inputs - make flows for whatever outputs.... but of course it all depends what you want to do. In the most trivial example you might look for a change of state of an input on a board - i.e. a button press - and use that to start a timer, for example {out0:6,30} which would turn on the output on whatever board you were talking to (via the topic) for 30 minutes and then automatically turn it off when done. That could be a button and a light - or with a shorter interval it might be a smoke detector and a buzzer, or a movement sensor and a floodlight. Where it gets clever is where you join up umpteen input changes with global variables to have a variety of actions taken.

      As usual the simplest and most rewarding is a simple input action leading to a simple output action. The function nodes in Node-Red are empty boxes which accept input and control 1 or more outputs - with any logic you care to put into the box.

      1. thanks 🙂
        it's time to study, at least javascript and many other things...
        you're right, there no a "solution for everything", one has to build his own...

        oh, i didn't talk about Domotics as a product (never used...), but about domotic as a concept of interaction with what we're living in 🙂

        about how do you check things which needs some interaction or tell you something? Imperihome, or have you a flow with relevant info published there?

        it's just to have ideas to develop, from who already has made a lot of things (and fun... yeah, nerdism, but i think this stuff is funny 😀 )

        1. Elsewhere on the blog you'll find Imperihome and I how hooked it into Node-Red with some database help from my friend Peter Oakes. I used to use a variety of packages but now mainly Imperihome - despite my wish that they'd concentrate on the basic features instead of trying to be everything to everyone. Node-Red can form an interface between whatever other packages and Imperihome.

  3. Hi

    Please help me
    Nextion to node red communication it ok.
    Now I have a problem node red to nexton display communication.
    I tried the serial communication terminal works.
    I do not know what is wrong.


  4. Hi

    Actually as you bring it to my attention - I would like devices to update - but it is actually quite a lot simpler than this.... right now I can send the message "{otaupdate}" to a device (either individually or collectively) via serial or MQTT and they will go off and update - what I do not do as yet is check for updated versions.

    Right now I keep the updates on - with a simple python script (I would not want devices to update every time I recompile automatically because I might be experimenting.

    So here's a thought - an additional {autoupdate} command that could be set to work or be ignored. Assuming it was left it on, my script that generates the bin files could easily generate a small file in the same area with the version number. The autoupdate command would simply go check the text file for the version number, compare with it's own and if different, would autoupdate... if that failed, it would of course try again the next time until it got there. Or to save having to do any file parsing. As you say - something to consider for future updates.

Leave a Reply

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