Is it possible a Retain on/off State Control Widget?

Hi averyone, and Thank you for any help you can offer

This is my issue:

  • I have an ESP8266 dev board (NodeMCU v3) and i’m testing builtin led control, using on/off state widget.
    All is working fine (with thing[“led”] << invertedDigitalPin(LED_BUILTIN) ) , but when the board is reset, the led is always ON, no matter the state of control button in widget.
  • So, is there any way of “retained control” of this widget?, beacause I need the board “remember” the state of the control button.

I apreciate any kindly support



#include <ThingerESP8266.h>
#include “arduino_secrets.h”

#define LED_BUILTIN 2


void setup() {
// open serial for monitoring

// set builtin led as output

// add WiFi credentials
thing.add_wifi(SSID, SSID_PASSWORD);

// digital pin control example (i.e. turning on/off a light, a relay, configuring a parameter, etc)
thing[“Led”] << invertedDigitalPin(LED_BUILTIN);

thing[“Led”] >> outputValue(digitalRead(LED_BUILTIN));

// resource output example (i.e. reading a sensor value)
thing[“millis”] >> outputValue(millis());

// more details at DEVICES - Documentation

void loop() {


I would use the properties → DEVICES ADMINISTRATION - Documentation

I would code the device to update its configuration/state at one property, when it resets or after a cold start, I would code a routine to ask for the last known configuration/state by the property.

You also may store the last configuration at uC eeprom memory, but note tha this memory can be written limited times, so if it is written so often, will be unusable in a short lapse.

Hope this helps.

Dear Ega, thank yoy very much for your interesting and kind suggestion.
I Will try to code this option.
I think a side-to-side test must be carried out to check integrity of command (check state of on/off button against esp board lesd, or any other pin.
Meanwhile, Reading about mqtt control, i think it is a good alternative to API because that protocol have an option: retained messages.
This “retained message” is stored by server (mqtt broker) and when the board, after a cold restart, or network comms failure (mobile or local WiFi nets), reconnect a d subscribe again to the topic, then it receive the Last retained messages, in this case, Last led state.
But during the time between shut down and restart of board, esp board doesnt know previous state of output pin, so, an eeprom backup I think, like you, its a good idea (100.000 erase cycles capabilities is high enough for me, esp8266 is cheap to replace).
Only one more question: is possible API & MQTT to be combined for the same resource?
King regards


As you describe the retained message option, it is pretty similar to work with the device’s property, after a cold start get the last known configuration by the online server, you just need to start into a secure and appropriate condition after the cold start, according the handled process.

It is important to note that the API is compatible exclusively with thinger native devices, by default the MQTT communication does not handle ‘resources’, it is an exchange messages protocol, you need to decode the payload (according the particular codification, thinger uses JSON) and code the device to execute some instruction with the decoded message.

Hope this helps.

Hi Ega
Yes, you are right about API vs MQTT.

Googling about this issue: backup of states or variables, and restore them after cold restart, I found a very good solution: an external micro pseudo UPS and Power failure detector circuit, based in a Capacitor and Optocoupler. When power goes out, capacitor dicharge its energy to ESP32, an ESP’s interrupt detects power have gone, and then ESP store valuable data to be read in the next power up.

micro UPS


NOTE: If Vin=12V, “power_good” pin must be adapted to get 3.3V max, esp8266 compatible voltage.

If maximum nodemcu esp8266’s power consumption should be around 0.240 mA (wifi 215mA + other board consumption), at 3,3V ) after 12V-to-3,3V regulator (AMS1117-3.3 DN811 in my case, its maximum input voltage is 15V), so the maximum power is P=0.240*3.3V = 0,792W. A fast (not real for sure) resistor value assumption would be around 14 ohm.
We need the capacitor be discharged from max 12V (despite board’s lavel is VIN=5V) to 4,8V at the regulator input (at this voltage output will be 3,3V/0,8A, full operating range, Vin-Vout>1,5V).

Using this app:, we should get the capacitor value needed to supply this power.

A 2200uF/50V capacitor would supply power up to 4,8V for 28 ms. I do not know if this time is enough to make an internal backup. If the power consumption is lower than 0,792W, I think there is more time for backup instructions, for sure. Or we can use 2 x 2200uF capacitor and we get minimum 60 ms for backup.

What do you think about it??

Maybe I should go for a cheap power supply like this, and to forget about micro ups circuit.

If we use this kind of power supply + backup, I also think we need to test AC power failure to track failure times or alarms. Maybe, this would not be an IoT solution, because og the big size of hardware needed…

Any comment is welcome

Thank you very much, and I hope this be helpful for the community.


If it is needed some energy autonomy, I would use something like this →{"sku_id"%3A"12000016918510328"}&pdp_npi=2%40dis!COP!1862.03!1498.71!!!219810.5!!%40210318c216642125986497137e02a4!12000016918510328!sea&curPageLogUid=gVtpmHDj0SQp&ad_pvid=202209261016389927580901068320012855851_1&gatewayAdapt=glo2usa4itemAdapt&_randl_shipto=US

And a 18650 Li-Ion Battery, you may detect if there are not power feeding from the source and for sure will have about of hours to take action with the uC before the battery drains.

Hope this helps.