I think your argument for not bringing this into the framework is sensible. I am happy to see that you have opened an “issue” on the $uptime property, though, 
I’ll keep my other stuff at the sketch level for now, and will probably later simply disable it compile-time.
I am not a native english speaker (I guess you noticed it), so I am not sure about the meaning of sensible here. Note that this is not a definitive “no”, if deemed necessary later, I’ll reconsider. 
Well, neither am I so you’re in good company, 
Sensible
“having, using, or showing good sense or sound judgment:”
So, I was simply saying that I agree with your arguments and decision to not bring this in (at this point, anyway),
Alright, thanks for the english lesson! 
In french, sensible is the equivalent of the english sensitive, which is why I was confused. 
The v1.3.0 has been released. There are a lot of improvements and fixes, most notably related to SSL. There was a lot of changes, so maybe I’ve introduced some issues, even though I’ve tested it a lot before releasing it. Thanks guys for your great ideas!
The $uptime device property is not yet implemented, it will be part of the v1.4.0.
Good work Marvin! I am looking forward to the 1.4.0 release with the brand new $uptime property,
Meanwhile, I have a question, but I will start with a bit of background:
In my setup I have some temperature and humidity sensors that are polled quite slowly (every 15 seconds or so), but I also have some simple contact sensors (magnetic/reed switches) connected to digital input pins and these I am polling as often as possible (basically once every run of the HOMIE loop handler). This has worked just fine for a long time.
Yesterday I added a light sensor connected to an analog input pin. Without thinking too much about it I set the polling frequency of this sensor to 0, same as the contact sensors.
The result was that the system started, connected and worked fine (all sensors working) for 10-15 seconds and then the Wi-Fi connection was lost. Wi-Fi was reconnected and the whole cycle kept repeating again and again.
I had my suspicions about the analogRead method being the source of the problem. Just to be sure I created a clean sketch with the simplest HOMIE setup possible and added a call to analogRead in the HOMIE loop. Same thing happened. So I added a counter to slow down the polling of analogRead and then everything was fine.
So, the question now is:
This is a known esp8266/Arduino issue (#1634). It seems the ADC is also used internally by the ESP8266 SDK to adjust the output power of the Wi-Fi. Polling every 3ms seems to solve the problem!
Even though this is not an Homie issue, I’ll add a note in the Limitations page in the docs. To answer your question: the golden rule is to never do anything blocking in your code for more than 50ms or so.
Super! I was pretty sure this was not a Homie issue, and it was not a big concern of mine since there is a simple “workaround”, however, my mind is simply wired in the way that I like to understand what is going on,
Thanks for sharing you knowledge beyond the Homie framework!
And you are perfectly right![quote=“KjetilA, post:108, topic:8674”]
Thanks for sharing you knowledge beyond the Homie framework!
[/quote]
You’re welcome, I added a note in the docs about the ADC problem and the golden rule.
I am back with more strangeness,
I just added my 5th sensor, this time a PIR (motion) sensor. It’s connected to digital pin D3 (NodeMCU v1.0) configured as an input.
When uploading and booting the sketch the framework resets to configuration mode. When I configure the device (through the Android app) it connects, but then more or less immediately resets to configuration mode again.
When I recompile the sketch without the code for the motion sensor (basically not configuring D3 as an input) and disconnects the PIR sensor from D3, everything works as expected again.
Ps! I have upgraded to Homie 1.3.0.
This is perfectly normal! D3 on NodeMCU is tied to GPIO0 which is the pin connected to the FLASH button of the board, used by Homie… To reset the device.
See Advanced usage#reset in the docs.
Good to know! I’ll move this from my “strange behavior”-list to my “should have checked the documentation first”-list; the latter one seems to increase for each day that goes by,
I did have some suspicions about this, since I found some mention of the flash button and some GPIO on a NodeMCU site, however, it was not detailed enough about exactly what GPIO pin it was - as should obviously have dug a bit more…
Anyway, based on the suspicion I moved the sensor to the D5 pin, but I got some funny results there as well (although not exactly the same as when using the D3 pin). Now that I know about the D3 pin, I’ll recheck my connections and try a bit more using D5 (or some other “safe” pin).
Me again.
As indicated in a previous post I have since day one of using Homie, experienced infrequent disconnect/reconnect on the MQTT link - typically 2-4 cycles over a 24 hour period.
Lately this has increased dramatically. In the last 24 hour period I have seen 42 disconnect/reconnects! I am not sure if this is related, but the increase seems to coincide with me upgrading to Homie v1.3.0. Note! I am not using SSL.
Anyone else seeing something similar?
Do you have the error log from the MQTT server?
I am using a default installation of Mosquitto, and I honestly don’t know if logging is enabled by or not. I’ll have a look when I get home from work.
I tried a normal DHTtester.ino sketch and it gave the same ‘errors’. I found another website that reported problems with the new DHT library and the nodemcu/esp8266. http://www.makeuseof.com/tag/meet-arduino-killer-esp8266/
Download these MQTT and DHT libraries. Even if you already have them, download these ones anyway, backup what you have, and overwrite with these. The latest DHT11 library from Adafruit uses an automatic algorithm for determining the speed at which data is read from the sensor, but it’s buggy on ESP8266 and 90% of the time results in failed readings.
With the old version 1.0 of the library I’ve included in the download, you can manually change the timing: 11 works best for these ESP2866 boards. I also went through many copies of the MQTT library trying to find one a good callback function, finally landing on the one included. You’ll need to restart the Arduino IDE after replacing these.
With that DHT library (version 1.0.0) it works perfect. Maybe it helps other people with odd sensor readings from DHT sensors.
Has anyone created a MQTT to IR-Transmitter sketch, that uses the ESP8266?
I am stuck at selecting the correct format for my Samsung TV.
(Got no receiver for the original remote)
Would be great if it is possible to turn on my TV from “deep standby” (SamsungTV Binding can only be used if the TV is switched on, which means eth/wifi needs to be connected)
I enabled logging on my Mosquitto broker, and restarted the NodeMCU running Homie. After about 14 minutes of running I was already at 4 MQTT connections. Here is the Mosquitto log:
1459793534: New connection from 192.168.100.10 on port 1883.
1459793534: New client connected from 192.168.100.10 as Homie-12138ee0 (c1, k15).
1459793705: Client Homie-12138ee0 has exceeded timeout, disconnecting.
1459793705: Socket error on client Homie-12138ee0, disconnecting.
1459793753: New connection from 192.168.100.10 on port 1883.
1459793753: New client connected from 192.168.100.10 as Homie-12138ee0 (c1, k15).
1459794645: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1459794826: Client Homie-12138ee0 has exceeded timeout, disconnecting.
1459794826: Socket error on client Homie-12138ee0, disconnecting.
1459794828: New connection from 192.168.100.10 on port 1883.
1459794828: New client connected from 192.168.100.10 as Homie-12138ee0 (c1, k15).
1459794965: Client Homie-12138ee0 has exceeded timeout, disconnecting.
1459794965: Socket error on client Homie-12138ee0, disconnecting.
1459795009: New connection from 192.168.100.10 on port 1883.
I also had the serial port open on the NodeMCU, and the following is shown (for the last MQTT disconnect/connect cycle):
✖ MQTT disconnected
⌔ Attempting to connect to MQTT
Failure
⌔ Attempting to connect to MQTT
Failure
⌔ Attempting to connect to MQTT
Failure
⌔ Attempting to connect to MQTT
Failure
⌔ Attempting to connect to MQTT
Failure
⌔ Attempting to connect to MQTT
Failure
⌔ Attempting to connect to MQTT
✔ Success
Sending initial informations
Subscribing to /set topics
Subscribing to $reset topic
✔ MQTT connected
Before this I had a few “Sending failed” printouts from trying to post messages to the MQTT broker.
Any ideas? Anything else I can enable in terms of logging to help uncover the problem?
I think Homie.loop() is not called regurarly enough. But what’s weird is there are a lot of connection failures… Can you please share your sketch? And maybe try https://github.com/marvinroger/homie-esp8266/archive/f23700aea35f9d17dd722887313ca1dc519fde64.zip which might fix the multiple reconnects failure.
I’ll give your code a try this afternoon when I get home from work. I’ll try to capture the timing of calls to Homie.loop as well to see if this can give anything. BTW; this reminds me of a previous discussion we had on the topic of “loop timing”,
Meanwhile, here is a link to the sketch I am using (as well as a library that it depends on):
I don’t see anything in the program flow that should cause a significant delay, apart from that there could simply be too much code (although I cannot believe that since it is not that much, and the code is simple!).