In a perfect world, you should not… but that not being the case, that option could be good to have… dont would think ?
1 Like
This library looks perfect for a project I’m starting, but I can’t get homie to compile - I raised an issue on git (https://github.com/marvinroger/homie-esp8266/issues/58) but I suspect it’s something really obvious (just not to me!)
Looking forward to working with it!
Answered on the GitHub issue tracker. 
[EDIT]Fixed, make sure you connected to the config site via http! doh.[/EDIT]
Building great now - having a few issues configuring it though. The configuration site won’t find the device ever (I load the site on home wifi, then switch but it still stays showing waiting for the device…). I can see the device just fine in a different tab via 192.168.1.1 and the dns name, so not sure whats going on there (Its an android phone).
I tried the phonegap app but it’s just telling me that it’s not build: https://build.phonegap.com/apps/1906578/share
I’ll just set the config in the firmware for now:) [EDIT]Actually, doesn’t look like it’s possible to do that?[/EDIT]
I’m working in this now. I have code that controls an IR diode and it works great with my TV. Just hooking it up to homie now. Happy to share code if you are still interested.
2 Likes
I tried to upload the config using the SPIFFS upload (I manually created the json file here: “D:\GitHub\Arduino-Projects\HomieLounge\HomieLounge\data\homie\config.json”, and it appears to upload it, but the device still reboots into config mode.
I can’t use the site because of the error it gives in the issue I logged here: https://github.com/marvinroger/homie-esp8266/issues/60
Any ideas?
My bag of WeMo D1 minis just arrived today so am just tinkering with them now…
First observation, do we need to do anything special to get the LED to work as expected?
According to this: http://www.wemos.cc/Products/d1_mini.html the LED pin is not connected to the serial tx or rx but to GPIO2 (D4 on the board).
So you should be fine. If you have issues read here for disabling the led: https://github.com/marvinroger/homie-esp8266/blob/master/docs/3.-Advanced-usage.md
Isn’t the Wemo using a esp8266-12E pcb ? if so, then yes, the blue led is linked on the GPIO2 (that is a second TX line)
Yes it is connected to the second tx line… would that cause issues?
marvinroger told me that I could have issues in that, ether the led will not work or you will have no serial output.
There is something in the docs to disable on or the other… and then you could put a a external LED on one of the GPIO and set the pin to become the BUILTIN_LED
take a look at this one : Advanced usage
I could be wrong as I think is framework was built with the Wemo in mind… someone please connect me if this is the case.
Wouldn’t the first tx and rx be used instead of the second one? Well, I’ve just bought 3 so hope to find out soon
personally, I can’t say, I only have esp8266-12E and -07 PCB as that is what i’m basing my projects off of.
Also answered on the GitHub issue tracker. Guys, be sure that your ArduinoJson, Bounce2 and PubSubClient match the versions required in the Homie for ESP8266 docs. Otherwise you will be unable to compile, or you will get unexpected behavior like this one.
If the LED is independant (not tied to the serial line), then no, it should work out of the box.
If it is not, then you will need to either disable the LED handling or the serial output.
In the 2.0 I’ll probably disable the internal Serial.begin() so you will be able to use whatever serial line you want.
1 Like
note sure if this error has been identified before …
the only way i can get the ESP8266 to talk to the MQTT broker is as part of the configuration process provide my own Device ID and not leave it blank and use the default …
i did also change the Brand name of the device within the code … this might be part of the issue too …
still can not get the light to go on but i can get a “Light is off” response from the ESP8266
note: i was also able to get “devices/tt23/$uptime” to respond too …
tt23 was the provide device name
Can you open an issue on the GitHub issue tracker? If you don’t have a GitHub account, just let me know and I will do it myself. Otherwise, it gets too complicated to manage all the flow of issues. 
If you have a light is off, this means you sent false. If you send true, it does not say light is on?
Great work @marvinroger !!
I was looking for an MQTT + OTA framework to load on my Itead Sonoff relay boards and landed on your Github page.
I liked a lot your topics convention and the initial board configuration (I used the javascript configurator). Everything worked straightforward for me.
I just added ArduinoOTA to my sketch so I don’t need to set up a webserver, it loads directly from the Arduino IDE as if it was connected to USB.
I also added two external switches tied to the serial port of the Sonoff (GPIO1 & GPIO3) that act as on/off sensors to give input to OpenHAB.
Now I want to code a fallback behaviour when either MQTT or WiFi connection fails: the switches will act directly on the relay so I can use my lights even if for some external reason WiFi or MQTT are not working.
I tried to use your Homie.isReadyToOperate() call but it seems that when there is no WiFi we don’t get to execute the loopHandler. I will try harder (not easy to debug without the serial port).
Anyway, thank you for your great work!
thanks i have added the device ID issue to GitHub
just tested the lights again with a clear copy of the code …
and yes when i send a false via the broker … the code comes back with “Light is off
” and the red LED turns on … and the broker receive a False back
the opposite is true too
i’m not worried about this ,it is a simple logic problem (HIGH/LOW) on the pin
now i’m trying to get OpenHab with the broker 
This is the whole point: the loopHandler is called only when in normal mode and connected to the Wi-Fi and MQTT, so there you will only want to handle the online jobs, like sending a temperature at regular interval.
For every offline task, you will do it in the normal Arduino loop.
Finally someone who has no issues. 
Oh yes, because in the example the PIN_RELAY is set to an arbitraty value, in your case this pin is connected to the onboard LED, so it does trigger the LED. And on some boards, the LED is active-low.
This makes sense. Thank you.
By the way, I tested your IteadSonoff example and it works without modifications.
I just had to reset the board unplugging the power after loading the code: the automatic reset left the board hanging (I think this is more a ESP problem).