Comments for OppoverBakke https://www.bakke.online ...that means "uphill" for the rest of us Sat, 22 Jan 2022 09:10:56 +0000 hourly 1 Comment on Adding retained messages to Adafruit's MQTT library by thedarkman https://www.bakke.online/index.php/2017/04/04/adding-persisted-messages-to-adafruits-mqtt-library/#comment-111 Wed, 29 Nov 2017 23:11:49 +0000 http://bakke.online/?p=42#comment-111 In reply to thedarkman.

well, it seems that my mqtt broker (mosquitto) really sends PUBLISH package before sending the SUBACK … So that’s the “TODO” part in Adafruit_MQTT.cpp:185 :(. Do you have an idea how to handle this situation?

Never the less your changes are good and i don’t understand why they aren’t merged already

]]>
Comment on Adding retained messages to Adafruit's MQTT library by thedarkman https://www.bakke.online/index.php/2017/04/04/adding-persisted-messages-to-adafruits-mqtt-library/#comment-110 Wed, 29 Nov 2017 20:32:40 +0000 http://bakke.online/?p=42#comment-110 Great, thanks for sharing. My mqtt clients are now a litte bit userfriendly :).

But, do you need to adapt also the subscribe methods from the adafruits mqtt library? In my first tests i do not receive the message on subscription.

]]>
Comment on Reducing WiFi power consumption on ESP8266, part 3 by Rainer Ochs https://www.bakke.online/index.php/2017/05/22/reducing-wifi-power-consumption-on-esp8266-part-3/#comment-106 Wed, 22 Nov 2017 22:55:47 +0000 http://bakke.online/?p=309#comment-106 Hi ebakke,
I am doing pretty the same, designing a WIFI temperature / humidity sensor to report to a server (another ESP system)
I followed basically your advice and get a wake time of unbelivable 200ms to connect to the server, read out the HTU21 and send the data via UDP. Reading the sensor is done while connecting.

However, I go to deep sleep with WAKE_RFCAL and omit the forceSleep calls.
The 200ms are measured from the begin of setup to the point where I go back to sleep.

The ESP needs another 300ms or so from reset until it enters setup, so I have an overall on-time of about 500ms consuming an average of 70mA -> tis makes 10µAh per measurement.
I also tried your version with going to sleept with WAKE_RF_DISABLED and enabling WIFI again in setup so the first 300ms only consume about 13mA. Then however the connection takes 400ms, so there is no advantage in this.

I have no idea, why my connection is so much faster – probably my router is connecting faster (a AVM fritz!box) or the ESP I am using has some newer firmware or what ever. When sleeping I measure about 18µA including the HTU21 – so I am sure the device is really in deep sleep.

As a board I am using a modified Wemos D1 mini with a split up 3.3V power source so the USB system does not draw any power when not active.

Rainer

]]>
Comment on Reducing WiFi power consumption on ESP8266, part 2 by Tom https://www.bakke.online/index.php/2017/05/21/reducing-wifi-power-consumption-on-esp8266-part-2/#comment-105 Tue, 21 Nov 2017 03:57:33 +0000 http://bakke.online/?p=286#comment-105 If you start temperature conversions on the DS18B20 sensors and DON’T wait; then start up WiFi, you won’t have any “wasted” WiFi time while waiting for the sensors. Connecting to WiFi takes (for me) 2.5 – 5 secs; more than enough for the DS18B20 to finish conversion (750ms worst case). Actually reading the values from the temperature sensors and formatting the MQTT message doesn’t take much time; so there’s not much wasted WiFi time for this process either.

Maybe your other sensors can be similarly multiplexed with WiFi startup.

]]>
Comment on Reducing WiFi power consumption on ESP8266, part 3 by ebakke https://www.bakke.online/index.php/2017/05/22/reducing-wifi-power-consumption-on-esp8266-part-3/#comment-101 Tue, 24 Oct 2017 11:24:14 +0000 http://bakke.online/?p=309#comment-101 In reply to Rudy.

Hi Rudy.
THat should be possible. I have an example sketch here which keeps the WiFi disabled until I need it, then I enable the WiFi, do what needs to be done and then disable it again, without going back to deep sleep. After a minute, the loop repeats, the WiFi is enabled again, and so on.

I’m posting it below, so you can see what I am talking about.

#include "test.h"

#include
#include

#include

const char* WLAN_SSID = "XXXXXXXX";
const char* WLAN_PASSWD = "????????";

int loops = 0;

void setup() {
WiFi.mode( WIFI_OFF );
WiFi.forceSleepBegin();
delay( 1 );

Serial.begin( 115200 );

while ( !Serial );

Serial.println( "Booted, and have disabled WiFi radio" );
}

void loop() {
loops++;
Serial.println ( "Entering loop()" );

Serial.println ( "Enabling WiFi" );
WiFi.forceSleepWake();
delay( 1 );
WiFi.persistent( true );
WiFi.mode( WIFI_STA );

WiFi.begin( WLAN_SSID, WLAN_PASSWD );

int retries = 0;
int wifiStatus = WiFi.status();
while ( wifiStatus != WL_CONNECTED )
{
retries++;
if( retries == 300 )
{
Serial.println( "No connection after 300 steps, powercycling the WiFi radio. I have seen this work when the connection is unstable" );
WiFi.disconnect();
delay( 10 );
WiFi.forceSleepBegin();
delay( 10 );
WiFi.forceSleepWake();
delay( 10 );
WiFi.begin( WLAN_SSID, WLAN_PASSWD );
}
if ( retries == 600 )
{
WiFi.disconnect( true );
delay( 1 );
WiFi.mode( WIFI_OFF );
WiFi.forceSleepBegin();
delay( 10 );

if( loops == 3 )
{
Serial.println( "That was 3 loops, still no connection so let's go to deep sleep for 2 minutes" );
Serial.flush();
ESP.deepSleep( 120000000, WAKE_RF_DISABLED );
}
else
{
Serial.println( "No connection after 600 steps. WiFi connection failed, disabled WiFi and waiting for a minute" );
}

delay( 60000 );
return;
}
delay( 50 );
wifiStatus = WiFi.status();
}
Serial.print( "Connected to " );
Serial.println( WLAN_SSID );
Serial.print( "Assigned IP address: " );
Serial.println( WiFi.localIP() );
Serial.println( "WiFi connection successful, waiting for 10 seconds" );
delay( 10000 );

MQTT_uploadToServer();

WiFi.disconnect( true );
delay( 1 );
WiFi.mode( WIFI_OFF );
WiFi.forceSleepBegin();
delay( 5 );

if( loops == 3 )
{
Serial.println( "That was 3 loops, so let's go to deep sleep for 2 minutes" );
Serial.flush();
ESP.deepSleep( 120000000, WAKE_RF_DISABLED );
}
else
{
Serial.println( "All done, disabled WiFi and will wait for a minute." );
delay( 60000 );
}
}

void MQTT_uploadToServer()
{
WiFiClient client;
float temp = -500; // Use this as a flag, as -500 degrees is physically impossible, it is below absolute zero
int8_t ret;

Adafruit_MQTT_Client mqtt( &client, MQTT_SERVER, MQTT_SERVERPORT, MQTT_USERNAME, MQTT_PASSWD );
Adafruit_MQTT_Publish publish_temp = Adafruit_MQTT_Publish( &mqtt, MQTT_USERNAME "/feeds/" MQTT_NAME "/temp", MQTT_QOS_0, 1 );

Serial.println("Connecting to MQTT... ");

uint8_t retries = 3;
while ((ret = mqtt.connect()) != 0) { // connect will return 0 for connected
Serial.println(mqtt.connectErrorString(ret));
Serial.println("Retrying MQTT connection in 5 seconds...");

mqtt.disconnect();
delay(5000); // wait 5 seconds
retries--;
if (retries == 0) {
// basically just hang around and wait for the watchdog to come and eat us.
while (1);
}
}
Serial.println( "MQTT Connected!" );
Serial.println( "Sending MQTT message" );
publish_temp.publish( temp );

delay( 50 );
mqtt.disconnect();
Serial.println("Disconnected from MQTT");
}

]]>
Comment on Reducing WiFi power consumption on ESP8266, part 3 by Rudy https://www.bakke.online/index.php/2017/05/22/reducing-wifi-power-consumption-on-esp8266-part-3/#comment-100 Mon, 23 Oct 2017 14:57:22 +0000 http://bakke.online/?p=309#comment-100 In reply to ebakke.

Thanks for your informations!
I will try it on my esp, but i don’t know if it’s possible to activate and deactivate the wifi in a loop like a timer during only a period of time like…each 2 minutes between my first action and my last action, i want to use the wifi to retrieve data from a mqtt only during a period of time

]]>
Comment on Self-updating OTA firmware for ESP8266 by Luciano Colin https://www.bakke.online/index.php/2017/06/02/self-updating-ota-firmware-for-esp8266/#comment-99 Fri, 20 Oct 2017 01:06:20 +0000 http://bakke.online/?p=328#comment-99 Indeed, very good work!
Good that I found your post. It will be much more easier for me to implement such structure in a web server.

Thanks,
Luciano Colin

]]>
Comment on Self-updating OTA firmware for ESP8266 by Mike Kranidis https://www.bakke.online/index.php/2017/06/02/self-updating-ota-firmware-for-esp8266/#comment-98 Thu, 19 Oct 2017 12:51:46 +0000 http://bakke.online/?p=328#comment-98 @ebakke
it is all fine now. Again thanks for your very good work regarding the HTTP OTA.

Best Regards,
Mike Kranidis

]]>
Comment on Reducing WiFi power consumption on ESP8266, part 3 by ebakke https://www.bakke.online/index.php/2017/05/22/reducing-wifi-power-consumption-on-esp8266-part-3/#comment-97 Thu, 19 Oct 2017 11:16:32 +0000 http://bakke.online/?p=309#comment-97 In reply to destroyedlolo.

Bonjour.

I’ve compiled your program for one of my own modules here and was able to reproduce exactly the same problem here.
It is easily fixed, though, by adding the following lines to the beginning of your setup() function:

WiFi.mode( WIFI_OFF );
WiFi.forceSleepBegin();
delay( 1 );

It looks like my code does not initialise the WiFi radio properly, otherwise. My process was quite iterative, so each optimisation step was building on what came before, and it looks like the WiFi.forceSleepWake() and WiFi.mode() calls depend on this initialisation to happen first.

One other thing that I usually do is to place a timeout on the WiFi connection, so that if a connection has not been established by a certain number of loops, I will reset the module. (Or send it back to sleep, depending on what is most suitable for the situation)

]]>
Comment on Self-updating OTA firmware for ESP8266 by ebakke https://www.bakke.online/index.php/2017/06/02/self-updating-ota-firmware-for-esp8266/#comment-96 Thu, 19 Oct 2017 10:26:58 +0000 http://bakke.online/?p=328#comment-96 In reply to Mike Kranidis.

Sorry for the delay, work and fun is a fine juggling act at times 🙂

I mostly agree with the use of sprintf(), except I’d use snprintf() instead, to avoid buffer overflows in case of unexpected data.
In this case, there’s a tight control of the input data, as the MAC address is known to be of uint8_t type, so sprintf() should be just as good.

The reason I didn’t think of sprintf()/snprintf() when I wrote this is that this was not supported on the ESP8266 core when I first started writing for it. Old habits are hard to break, but your suggestion is easier to read and understand. I have updated the post accordingly.

I have run it through a couple of update cycles and it appears to work well.

]]>