Proposal: allow reset by multiple consecutive poweroff

[marvinroger]

Some of our devices might be hard to reach once installed, and it would be great if we could reset the devices without pressing a button on it or without sending a MQTT packet (if you change your MQTT broker IP for example).

The idea is pretty simple: we can detect if the device has been electrically powered off multiple times (say 5) within a short interval. If this is the case, then we reset the device.

What do you think of this? Sorry for the slow activity on this project, but I am very busy currently. :confused:

[bertmelis]

I'm not quite following. How do you see the poweron-poweroff cycle when they device is hard to reach?

[marvinroger]

You can do that with your electrical panel, right?

[marvinroger]

Technically, it is feasible:

• On each boot, we increment the counter
• If the device is powered on for more than, say, 5 seconds, we reset the counter
• If the counter reaches 5, we reset the device

[marvinroger]

Okay, I see a potential security breach with this feature. An attacker could simply switch on and off the electricity from the outside of the house to gain access to the devices.

A solution to this would be a "password". Something like this:

5-10 >10 20-30 <2

This would reset the device if all these conditions are verified sequentially:

• The device is powered on for more than 5 seconds and less than 10 seconds before being powered off
• The device is powered on for more than 10 seconds before being powered off
• The device is powered on for more than 20 seconds and less than 30 seconds before being powered off
• The device is powered on for less than 2 seconds before being powered off

Then, on next boot, the device would be resetted.

[amayii0]

But how do you precisely guess actual uptime, excluding boot? Extra : this would require to isolate power supply of each node, might not be practical, especially when connected to an appliance like heater or fan

[jantje]

you could change the process to

On each boot, we try to connect to a service and if we fail increment the counter; if we fail we reset the counter
If the device is powered on for more than, say, 2 minutes , we reset the counter
If the counter reaches 5, we reset the device

[euphi]

I have another proposal similar to this:

• Create a special "OTA" boot mode that does not call the setup() or loop() functions of HomieNode objects and only handles OTA on MQTT.
• If there are 4 resets within a short time boot to this special mode.

This would allow to recover a device if you flash an unstable firmware in most cases.

[jamesmyatt]

I don't like this idea. I think it's pretty complicated and it feels like there should be a simpler solution. I would also like to be able to fix the connection settings without erasing all of configuration parameters.

I see these different situations:

1. Corrupt/invalid/unstable firmware: Can't be fixed OTA. You need to re-program it directly.
2. WiFi changed: No valid IP. Only solution is CONFIGURATION mode.
3. MQTT changed: Valid IP, so can access device directly (e.g. HTTP) but not indirectly (e.g. MQTT).
4. Any other situation: Valid IP and MQTT connection. Use MQTT config/set method.

So the only situations that need solutions are 2 and 3.

For 2, the HTTP JSON API could be enabled once the time without MQTT connection reaches an appropriate value. It would also be good to add specific API calls for setting the MQTT broker settings, just as there already is for the WiFi settings.

For 3, I think a similar solution would be best. After it has been without WiFi for a certain duration, it should switch to configuration mode. Then the HTTP JSON API can be used to send new WiFi settings.

It's probably worth including some optional HTTP authentication for (some) security.

[euphi]

@Nzbuu: For Case 1, OTA can help if the firmware is unstable.

If a crash is caused by anything inside the loop-handler, it helps to not call it and start in a special "OTA-only" mode. This could be triggered by several resets within a short time.

[exxamalte]

Re detecting power cycles: I can't think of a way to do a power cycle in the proposed way for a particular device without impacting lots of other appliances/devices/lights/etc. in the house (if doing this via power distribution board). If I had to power cycle a particular device, I would probably need to go to wherever the device is plugged into a USB charger, but then I would already have a USB cable in my hand and could flash it directly. Or am I missing something here?

@Nzbuu: I like your structured approach to this problem. Re cases 2+3 and your proposal to detect if Wifi or MQTT broker are off for a certain amount of time: Both should consider some sort of maintenance mode. I would not want all my devices to switch to config mode just because my Wifi access point breaks and I need some time to fix/replace it. Same if I need to do some maintenance work on the MQTT broker like upgrading software, fixing configuration, etc.

[marvinroger]

@amayii0 with millis(), we only have to know since how many time the device is powered on You don't need to isolate your nodes. If you change your Wi-Fi/MQTT credentials, you'll want to reset them all, right?

@jantje @Nzbuu i don't feel right with enabling automatically the config mode if we can't connect to the Wi-Fi/MQTT. As @exxamalte said:

I would not want all my devices to switch to config mode just because my Wifi access point breaks and I need some time to fix/replace it. Same if I need to do some maintenance work on the MQTT broker like upgrading software, fixing configuration, etc.

@euphi this does not solve the concern of invalid Wi-Fi/MQTT credentials, right?

@exxamalte It would indeed impact other appliances, but is it really an issue? We are talking about a "last resort" way to reset here, so it would be kind of exceptional. I don't often change my Wi-Fi/local IPs and I don't have many virtually unreachable devices.

Finally, @Nzbuu, it's not complicated: it is very simple to implement, and apply (power distribution board). Okay, the password proposal (5-10 >10 20-30 <2) IS complicated, so let's forget the password concept for now. The consecutive poweroff reset is already used in some commercial products (Yeelight for example) and I find it very reliable.

[exxamalte]

@marvinroger I was thinking that the "last resort" would be to make the effort and physically grab the device. At the moment I also do not have any devices that are hard to reach. Is this maybe a non-issue?

[amayii0]

@marvinroger I agree for the device itself at code level.

I meant for the power supply control. It might be tricky to precisely control the power cycle. @exxamalte comments in the same way, controlling precisely the power supply of a single given device is tricky. About affecting other appliances, I'd be crazy if for some reason 2 devices are powered on the same line. This requires some electrical planning when deploying the devices.

Types of PSU:

1. Battery : You need at some point to reach the device anyway (except solar or the likes, maybe)
2. Power supply over USB : You have a cable readily available, maybe buy an extension cord and you can flash device
3. Power outlet (110-220V) : You have some dedicated transformer in a wall outlet (like HLK PM01). You can control it "precisely" only if you have a switch available or power cord. This might be replaced by USB cord. If this is place in a light or similar, you can't control ONLY that specific device.
4. PoE : Haven't tough about that before, could be proprietary cable to also expose data pins to allow remote flashing. Anyway you don't need ethernet (AFAIK), if you do you don't bother about WiFi

I hardly see how to do that safely / remotely. Also as expressed by @exxamalte , what is exact use case?

Note : "Three Ways to Power an Arduino Off-Grid"

[timpur]

@marvinroger I dont think this would be a good idea. Too risky in the long run since this could cause issues with people running of battery or solar who have power issues tripping this functionality and resetting the device unexpectedly

[tripflex]

I'm with @timpur on this one, I think it would cause more potential problems then it would resolve ... only potential use I could really see for this, would be if the wifi credentials change ... mainly bc if you're using a FQDN for MQTT, updates for MQTT broker should be done by whoever manages the server and should just push the new details if they change them .. for MQTT that is. Mainly because the device should still have wifi connection, so updates can be made through internet.

Now in regards to the wifi connection, maybe could add a configuration like FALLBACK_WIFI_CONFIG that has to be set true (as it would not be enabled by default), to say, boot into config mode for allowing to update wifi creds, if say, after 30 minutes unable to connect to the wifi, or the AP is no longer found.

My thought behind this is that, 99% of the time if the wifi router has power, then more than likely the device will as well, if power does goes out, chances are that will cause the device to lose power as well