As asked on the openHAB forum by TommySharp.

In #45 @marvinroger said something I find is important:

Homie sketches are meant to be portable.

Assuming I have a few ESP8266 sensors which could basically all run the same Homie firmware, most of which have the same sensors / actuators on them, but, say, one or two of them have no relay. I would write the Homie sketch as follows:

HomieNode lightNode("light", "light");
HomieNode relayNode("relay", "relay");
HomieNode tempNode("temperature", "whatever");

When the Homie device without the relay talks to me it would say "I have a relay!" which it doesn't. While this is just a detail, could we add an an element to the JSON configuration which basically says hide these nodes for this device? Something along the lines of

{
  "hide_nodes" : [ "light", "relay" ]
}

I could then deploy the same Homie firmware to all devices and have them report / react to only what they actually have.

This may be overkill and not too easy to implement, so please feel free to quickly close this. 😄

I begun cleaning up my NTP code for Homie. This allows homie to receive the current time from an NTP server and thereby timestamp measurements or schedule future events.

I suggest adding another entry to the config setting the hostname of an NTP server and a new MQTT topic called $tzoffset which lets the server manage the timezone calculation.
(I think this has to be server side to manage DST instead of just storing it as a fixed configuration)

Any other comments on adding time/date handling to Homie?
Is this a bad idea?

Already fixed in f23700a, issue filled for changelog purposes.

To use it with a std MQTT broker it could be nice to make MQTT broker port configurable.

It's straightforward to add such option, however in a "pure" Homie framework it's just an other useless option...

What do you think to add an homie_port option that take the value from the HOMIE_PORT constant if not given in the config JSON ?

I can propose a PR in this sense.

I got a tricky serial issue with a generic ESP module... I eventually figure that for "generic ESP8866 module" the BUILTIN_LED is set to 1 in arduino/esp8266 (https://github.com/esp8266/Arduino/blob/573a0fb47fc0dc6dc25010d50642494dbb069476/variants/generic/pins_arduino.h#L45)
and GPIO 1 is nothing else that serial TX... So on startup serial was not working well.

Not sure how to fix that. We may add a way to configure the led to use ?
Also I'm thinking on how to make "state indicator" much more flexible... I got a lamp with some "NeoPixel" and before Homie I just made one of the pixel to blink to indicate pending wifi connection and so on. (Btw such flexibility can wait a future release !)

The API is quite complete and the overall stability is good (didn't run into any troubles so far, after weeks of continuous use). Docs are up. I guess it's almost time to release a stable version.

But before:

• We need to create a Web UI to configure the device, compatible with the latest API
• Config API: GET /device-info that would expose Homie for ESP8266 version, firmware name and firmware version, and maybe also the nodes it exposes.
• Add a way to reset the device remotely, maybe via a $reset property
• When logging is disabled, it should not call Serial.begin

As the configuration array continues to grow and there is currently very little control validation on the data stored in EEPROM (checksums, lengths etc) would it not be an idea to simply store the json config in the file system?
https://github.com/esp8266/Arduino/blob/master/doc/filesystem.md

It would simplify development as the flashtool today can automatically include the file.

Validation of the config file could then be put in a shared module allowing Homie to drop back into config mode if the data is unusable.

We would also retrain backwards compatibility to some extend as the JSON format would be easier to parse with the already included ArduinoJSON lib

Adding an optional setup call, which would default to
Homie.setConfig("home/config.json");

It would be nice to have a checkbox "show password" where you type in the wifi and mqtt password in the configuration app.

As per the JSON documentation I have uploaded a configuration which configures Homie to use TLS (the artist formerly known as SSL :-) and TLS connections are correctly established to a Mosquitto broker if I don't force the listener to tlsv1.2.

I assumed the fingerprint element of the configuration would be to verify the server's certificate against some known good value. However, if I randomly modify the fingerprint on the device, the connection succeeds anyway. Is fingerprint checking actually implemented, or have I simply misunderstood the name of the element?

{
  "name": "Clever name of device",
  "wifi": {
    "ssid": "yyyy",
    "password": "xxxx"
  },
  "mqtt": {
    "host": "192.168.1.130",
    "port": 9993,
    "ssl": true,
    "fingerprint": "99:07:4A:06:E7:EC:34:36:B7:F4:73:6C:CC:C3:49:60:14:F3:85:F3",
    "auth": false
  },
  "ota": {
    "enabled": true,
    "ssl": false,
    "host": "192.168.1.130",
    "port": 80,
    "path": "/ota"
  }
}

(The real broker's CA certificate fingerprint obtained with openssl x509 -in ca.crt -noout -fingerprint has a 2 at the end of the fingerprint instead of a 3.)

I must say I really enjoy your project. Beautiful work.

I made a little list of ideas and suggests that I think would be a welcome addition.
Please notice that I don't use the HomieServer but instead modified your lib to allow for better usage with my own MQTT server.
My wishes will therefor be a little biased :)
If you wish to keep homie-esp8266 and homie-server linked I would most likely still main a personal fork that keeps homie more "generic"

ToDo:

A proper webinterface for setting SSID and password during config mode is needed for less technical users (Hosted on the device)
Let the developer decide if the HomieServer is configurable or fixed.
There should be an interface for adding extra settings during config mode.
Hooks for clearing user settings when device drops into config mode.
SSL and Authentication for MQTT connection (optional of course)
Device should also report a "devicetype" that indicates what kind of firmware it runs. So you can have "temperaturesensor-1.0.0", "weatherstation-1.2.0"
Device should not report itself as "/devices/[devicename]/" but instead report itself as [prefix]/[devicetype]/[chipid]/$devicename to avoid collision between devices set with same name and allow shared MQTT servers
The framework should not include the ArduinoJson lib or the PubSubClient lib. The compiler should include the latest version. (Not sure how intrusive your changes to the MQTT lib has been)
Implement a few standard MQTT callbacks for debugging of remote devices (Read FS filesystem, EEPROM, Pin status, Wifi parameters)
Offline buffering/caching of data using a database, emdb on github looks interresting.
Make homieserver optional, provide documentation, helper functions and code example that shows how to interface with a HomieServer, but make it optional to use.

In the future I hope to see Homie as being the default solution for starting any project on the ESP8266. Include Homie.h configure the Homie instance and write code as you would for any Arduino.
Behind the curtains Homie ensures:

• The device is easy to configure for an end user
• The device can be recovered/reconfigured by the press of a button.
• That it is registered on the server so you know when it's active
• That you are able to communicate/debug/update no mater where the device is deployed
• That in the simplest form nothing is required beyond a free, paid or self hosted MQTT server
• Dead simple design concepts for anyone wanting to develop a server/client/interface with homie-server being the reference implementation

I can help on the embedded code
Any other ideas plans concepts floating around?

I have been unable to get the Web UI to connect. I now believe it only works from an Android device ( I can't prove this, I don't own one). I tried safari and chrome on iOS and safari on OSX with no luck.

If I'm correct, can you please update the wiki to indicate that the Web UI / app only works from Android?

I love MQTT so Home has about everything I need. Be that as it may, I recently learned of a CoAP-based standard called LWM2M (overview slides).

This screenshot shows Leshaan in operation:

Do you think this would be a good fit for Homie-esp8266 in addition to MQTT? Using, say, Leshaan to control, and Wakaama as the client code, Homie-ESP8266-controlled devices could be managed with the OMA standard.

The 192.168.1.1 net is quite often used by SOHO routers.
Placing a homie device in config mode on that same IP might easily cause conflicts with the user's cable modem/router/Internet gateway.

Maybe something like 192.168.50.1 (or something similarly infrequently used subnet)?

Or provide a way for the developer to define the desired subnet themselves?

As requested by Kjetil Asdal on the openHAB forum.

As first reported in #44 I'm seeing a disconnect when Homie connects via TLS (this does not occur in plain connections). Screenshot:

Server-side, the MQTT broker identifies an SSL handshake error, even after it sees the initial publishes from the device:

1458722417: OpenSSL Error: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
1458722417: Socket error on client Homie-cf3a07e0, disconnecting.

It would appear to me there's something corrupt going over the wire.

After the second connection succeeds, the Homie device carries on happily publishing for hours on end. This behaviour is reproducible.

How about a specific mqtt topic to reset the device remotely?

like:
devices/xXxXxXxX/$reset true
or
devices/15b638e0/$online/set true

Tiny bug in your reconnection routine for MQTT
You reuse
_last_wifi_reconnect_attempt
instead of the correct
_last_mqtt_reconnect_attempt

Fixed in my fork

Homie currently hard-codes the MQTT base topic to "devices". I'd like to propose making this configurable via JSON:

"mqtt" : {
  "port" : 1883,
  "basetopic" : "sensors/homie/",
  ...
}

basetopic would default to what it currently is ("devices"). Making it configurable would enable people to better integrate Homie devices into their MQTT topic tree.

I would give this a stab myself and provide a PR if you think it a good idea.

Hi, first - really great project! Huge congrats!
Question - is there a chance for SSDP or other way for nodes to auto discover server IP address in the local network?

I still don't understand how to setup the ota web server.

I understand how it technically works.
But do I have to develope this myself?

Or is there some kind of index.php file that I can copy to my apache web server in a "ota" subfolder?

I got Homie.sendProperty that returns false (even if some time msg is sent) and some random MQTT reconnection when I get more than 4 Homie.addSubscription.

It seems to be linked to knolleary/pubsubclient#98

Maybe one should add a mqtt.loop call in Homie.addSubscription ?

There's a bug upon connecting to an MQTT server with a username/password.

bool connectResult; if (Config.get().mqtt.auth) { connectResult = this->_shared_interface->mqtt->connect(client_id, Config.get().mqtt.username, Config.get().mqtt.password, topic, 2, true, "false"); } else { connectResult = this->_shared_interface->mqtt->connect(client_id, topic, 2, true, "false"); }
Is the correct way

I don't Homie responding to ANY MQTT messages, which could be cause by

1. Incorrect MQTT topic being used by me. For the demo on https://github.com/marvinroger/homie-esp8266/blob/master/docs/2.-Getting-started.md, I understand the topic should be devices/003/light/on and the message should be true (assuming the device ID was set to 003 in the config).
2. Some issue in Homie, preventing it from getting the MQTT messages
3. Probably lots of other reasons too.

Also, after reporting the system messages to MQTT, the device sends a couple of "devices/003/$signal" messages, then goes offline with a "/devices/003/$online" = false message..

Would be good to rule out option 1. Can someone confirm that topic and message is correct, for the demo code referenced?

Using an ESP201 Sweet peas ESP8266 device, with latest PlatformIO (2.8.6) and Homie (1.3.0).

As @furyfire asked in #8, it would be neat to have an API to add other settings than wifi, mqtt and ota in configuration mode.

Just an idea: It may be very convenient to have a lightweight android app that can set a Homie device config !

I'm not used to that, but I guest that https://github.com/marvinroger/homie-esp8266/tree/gh-pages can easily be pack in an adroid (or iphone) app ? With lib like cordova (https://cordova.apache.org/)

I'm thinking how to control a device made of an ESP8266 that drive some NeoPixel (or WS2801).

For now I got:

• devices/ID/state/set with on, off or toggle
• devices/ID/rgb/set with color eihter in RRGGBB html-like hex format or rrr,ggg,bbb decimal format. This control the color of all leds.

At first I only use hex format (much more easy to parse) but then I implemented decimal&coma one to be compatible with Home Assistant (https://home-assistant.io/components/light.mqtt/).

The missing point here is a way to control each led individually...

Two idea:

• devices/ID/rgb_<led_id>/set with color of the given led ID
• devices/ID/rgb_each/set with one msg giving the color for each led. In a first implementation I used just the concatenation of RRGGBB html-like hex format for each led.

What do you think about all that ?

A other way is to use json in MQTT msg... but I'm not sure about performances.

It could be nice to have a script that push MQTT msg to get effects as here : https://www.youtube.com/watch?v=OLxM9p5o2us

I just test the configuration app (both as a webpage/or "native" app) with a pretty old android phone. It didn't work :( I guess there is a issue "homie.local" with mdns resolution...

Anyway, in the configuration tool it may be preferable to use the default ip ?

I have to fix my phone screen before to test on a more recent android device :/

Hi,

I'm testing it with a nodeMCU 0.9, I got the following log:

Boot in config mode, ok. Then I send json config and :

Received config request
✔ Configured

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)


 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset

I reflash the FW, it boot in normal mode.
Then when I manually ask for a reboot in config mode:

** Booting in normal mode **
Attempting to connect to WiFi
Attempting to connect to MQTT
Sending initial informations
Temperature: 22.00 °C
Resetting
↻ Rebooting in config mode

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)


 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset

I use mosquito as MQTT broker.

Maybe some delay() should be added to handle wifi processing ? or mqtt.loop() ?

Right now, a sample sketch looks like that:

#include <Homie.h>

const int PIN_RELAY = D1;

void inputHandler(String node, String property, String message) {
  if (node != "light" || property != "on") {
    return;
  }

  if (message == "true") {
    digitalWrite(PIN_RELAY, HIGH);
    Homie.sendProperty("light", "on", "true"); // update property, act as a feedback
  } else if (message == "false") {
    digitalWrite(PIN_RELAY, LOW);
    Homie.sendProperty("light", "on", "false");
  }
}

void setup() {
  pinMode(PIN_RELAY, OUTPUT);
  digitalWrite(PIN_RELAY, LOW);
  Homie.setFirmware("awesome-relay" ,"1.0.0");
  Homie.addNode("light", "light");
  Homie.addSubscription("light", "on");
  Homie.setInputHandler(inputHandler);
  Homie.setup();
}

void loop() {
  Homie.loop();
}

I think addNode, addSubscription and setInputHandler are kind of messy. I would see something like that instead:

#include <Homie.h>

const int PIN_RELAY = D1;

HomieNode light("light", "light");

void lightOnHandler(String message) {
  if (message == "true") {
    digitalWrite(PIN_RELAY, HIGH);
    Homie.sendProperty(light, "on", "true");
  } else if (message == "false") {
    digitalWrite(PIN_RELAY, LOW);
    Homie.sendProperty(light, "on", "false");
  }
}

void setup() {
  pinMode(PIN_RELAY, OUTPUT);
  digitalWrite(PIN_RELAY, LOW);
  Homie.setFirmware("awesome-relay" ,"1.0.0");
  light.subscribe("on", lightOnHandler);
  Homie.registerNode(light);
  Homie.setup();
}

void loop() {
  Homie.loop();
}

There are several benefits:

• Feels cleaner
• You only have to define your node ID on the HomieNode object
• We can add three types of input handlers:
  • As shown above, directly on a property of a node (void lightOnHandler(String message))
  • On a node, with a third parameter to HomieNode (void lightHandler(String property, String message))
  • Like we already have for now, a global input handler (void globalHandler(String node, String property, String message))

What do you think? @enavarro222 @furyfire

First of all, thank you for building Homie-ESP8266; this is grand.

Assuming I want to add a property to a node to indicate the unit, I tried doing

Homie.setNodeProperty(tempnode, "unit", "C", true);

in setup(), just before registerNode(), just after, and after Homie.setup(), none of which works. The only place I seem to succeed in seeing this property is if I add it to a loop handler, which is a shame, as it's a one-time only constant property.

Am I holding it incorrectly? :-)

I'm getting the error "mqtt.auth is not a boolean" via serial when I send the config with "Use MQTT authentication" ticked (and my credentials entered).

As a newbie I don't know what SPIFFS is and how to upload a file to it. :(

I guess this might be the point to start:
https://github.com/esp8266/Arduino/blob/master/doc/filesystem.md#uploading-files-to-file-system

I would suggest to elaborate a little more about this in the wiki.
Or point to a good tutorial. :)

I'm using the following:

Arduino IDE 1.6.6
ESP8266 board 2.1.0
ArduinoJson 5.0.7
Bounce2 0.2.0
PubSubClient 2.4.0
Homie 1.3.0

My board is a NodeMCU V0.9

I can flash other programs to the board fine using the above.

I have tried the following

#include <Homie.h>
void setup() {
  Homie.setup();
}

void loop() {
  Homie.loop();
}

I also tried adding the following includes at the top as I didn't know if they were required

#include <ArduinoJson.h>
#include <PubSubClient.h>
#include <Bounce2.h>

I get the following error when I try and compile the app

C:\Users\live\Documents\Arduino\libraries\homie-esp8266\src\Homie\MqttClient.cpp: In member function 'void HomieInternals::MqttClientClass::initMqtt(bool)':

C:\Users\live\Documents\Arduino\libraries\homie-esp8266\src\Homie\MqttClient.cpp:27:148: error: no matching function for call to 'PubSubClient::setCallback(std::_Bind_helper<false, void (HomieInternals::MqttClientClass::*)(char*, unsigned char*, unsigned int), HomieInternals::MqttClientClass* const, const std::_Placeholder<1>&, const std::_Placeholder<2>&, const std::_Placeholder<3>&>::type)'

   this->_pubSubClient.setCallback(std::bind(&MqttClientClass::_callback, this, std::placeholders::_1, std::placeholders::_2, std::placeholders::_3));

                                                                                                                                                    ^

C:\Users\live\Documents\Arduino\libraries\homie-esp8266\src\Homie\MqttClient.cpp:27:148: note: candidate is:

In file included from C:\Users\live\Documents\Arduino\libraries\homie-esp8266\src\Homie\MqttClient.hpp:4:0,

                 from C:\Users\live\Documents\Arduino\libraries\homie-esp8266\src\Homie\MqttClient.cpp:1:

C:\Users\live\Documents\Arduino\libraries\PubSubClient\src/PubSubClient.h:108:18: note: PubSubClient& PubSubClient::setCallback(void (*)(char*, uint8_t*, unsigned int))

    PubSubClient& setCallback(MQTT_CALLBACK_SIGNATURE);

                  ^

C:\Users\live\Documents\Arduino\libraries\PubSubClient\src/PubSubClient.h:108:18: note:   no known conversion for argument 1 from 'std::_Bind_helper<false, void (HomieInternals::MqttClientClass::*)(char*, unsigned char*, unsigned int), HomieInternals::MqttClientClass* const, const std::_Placeholder<1>&, const std::_Placeholder<2>&, const std::_Placeholder<3>&>::type {aka std::_Bind<std::_Mem_fn<void (HomieInternals::MqttClientClass::*)(char*, unsigned char*, unsigned int)>(HomieInternals::MqttClientClass*, std::_Placeholder<1>, std::_Placeholder<2>, std::_Placeholder<3>)>}' to 'void (*)(char*, uint8_t*, unsigned int) {aka void (*)(char*, unsigned char*, unsigned int)}'

exit status 1
Error compiling.

Sorry it's probably something really obvious, I just can't figure it out!

When you change your configuration or restart http://www.openhab.org/ the current states of your device might get lost (Yes, you can prevent this).

But it would be nice to send a mqtt message to let the device resend the initial messages.

devices/15b638e0/$*

An alternative workaround would be to reset the device remotely (#33)

As asked by @rschaten on #35

As asked on the openHAB forum by TommySharp.

What I mean is, send the state of the items at a interval.

I'm seeing some weird actions with buttons on openHAB as, I would click them and they would revert back but the sensor would be in the asked state. so, by sending the states at a interval, the server would know the states.. (hope that i'm clear enough) :) # # @

The Device ID is an 8-char hexadecimal string. The chance of collision is 1/4 294 967 296, so this is a good compromise between safety and length.

The problem is the ESP8266 chip ID is not sufficient to generate this 8-char string without padding it with 0s. The solution is to merge the ESP8266 chip ID with the Flash chip ID.

Hi there,

I think it would be great if Homie could optionally publish its MQTT messages under devices/name instead of devices/device id. That way, multiple ESP8266s would be easier to distinguish, as one could simply name them -- for example -- "kitchen", "living room" and so on in configuration mode and then access them by that name via MQTT.
I guess that the current approach was chosen mainly to avoid naming conflicts, therefore I suggest using an optional statement in the setup() block à la:

Homie.useNameForPublish(true);

What do you think? :-)

As suggested by @furyfire, it would be good to remove the dependencies from the library. It was impossible before because of PubSubClient that would not accept a method as its callback function, so I had to modify the library. It is now possible since knolleary/pubsubclient@98a9c29 , and released in version 2.5.

So, to work, Homie would require PubSubClient >= 2.5, Bounce2 >= 2.0 and ArduinoJson >= 5.0.8 to be installed. The problem is there is no way to declare dependencies for Arduino libraries. Users would have to download 4 libraries, instead of just one. But they would benefit from the library manager of the Arduino IDE, enabling Homie to use latest versions of the dependencies without us maintaining.

Maybe just provide in the installation guide, the links to the 3 .zip of the 3rd party libraries? This is an overhead, but this is definitely cleaner than just embedding the libs.

What do you think? @enavarro222

After including Homie.h any code that uses the min() function will fail to compile unless you give it a namespace. This is unlike other Arduino libs and causes confusion.

include <Arduino.h>

include <Homie.h>

void setup() {
std::min(2,3);
}

void loop() {
}

I'm thinking on how to make the reset (to config mode) more flexible.

At first step a method resetConfig that can be call from main code could be a nice step. It will allows any user defined reset (why not a konamicode on the device keypad ;)).

However the current reset (GPIO0==D3 low for 5sec) might be problematic if this pin is used for other something else. It could generate undesired reset...

An radical solution would be to let entirely the user defined (and code) the reset trigger... Not satisfying as with NodeMCU D3 is already bind to push btn (flash) and is a very good candidate for a default reset method !

One other solution may be to have tho other methods:

• setResetTrigger(D4, HIGH, 6000): configure that config reset will be trigger if D4 is high for 6sec (with level and timing as option);
• unableResetTrigger(): disable "homie-managed" reset

Other ideas ?

It would be nice to change some/all parameters via mqtt in normal mode.

This should be easy for $name, $fwname and $fwversion.

Maybe this would even be possible for wifi (ssid, passphrase, ip, ..) and mqtt settings.
Yes, one could argue that this is dangerous, because the device might become unreachable in case the new configuration is incorrect.

I have been unable to upload a configuration with the Web UI / app and I don't own an android device.

I believe I should have been able to upload a configuration using curl, but so far I haven't had success.

An example for doing this in the wiki would be appreciated. Then I could reduce the scope of what I am doing wrong.

I tried:
curl --upload-file config.json http://homie.config/config

which gives me {"success":false}, with a 400 error code.

github doesn't like me attaching the config file. I tried your complete example, simplified ones etc.

It would be great if Homie would support wired networks, too.

Like the ENC28J60 chip.
https://www.microchip.com/wwwproducts/en/en022889

This might be usefull for cases where the wifi signal is to weak.

There is a limitation, from the Wiki

The whole Homie for ESP8266 code is designed to be non-blocking, so that you can do other tasks in the main loop(). However, the connection to the MQTT broker is blocking during ~5 seconds in case the server is unreachable. This is an Arduino for ESP8266 limitation, and we can't do anything on our side to solve this issue, not even a timeout.

This is not really true, it is possible to avoid connecting / reconnecting to the MQTT if a critical operation is happening. Let's say you are controlling shutters with a relay, you want your loop to be executed without the 5 seconds delay mentionned above, because else you will loose the current state of your shutters. Before moving the shutters, you could do:

Homie.enableSafeMode(true);

If the MQTT connection is lost while in safe mode, it does not try to reconnect. When the shutters is done moving, we call back:

Homie.enableSafeMode(false);

It would then reconnect if previously disconnected.