Maintenance mode galore


Coming from Terkin for MicroPython, we would like to manage the FiPy ESP32-based device solely over IP networks, even when in field mode with enabled deep sleep. The workflow would be like:

  • Discover the device.
  • Access the device.
  • Pull it out of field mode and put it into maintenance mode.

This topic is about further investigating how we could manage that.

Device is on the local network

The main problem we see here is finding out about the IP address when the device is connected to the same local network your workstation is running in. The device hostname will be espressif. We will discuss how local discovery might be performed through brute force methods like network scanning [1] and will eventually settle to investigate further into applying more intelligent technologies like mDNS/Bonjour [2] coming from the technology domain of Zero-configuration networking - Wikipedia. This is the baseline method if no other connections are available to get through to the device.

Device is available through the messaging substrate

We will find the discussion will spread into another direction by also giving some ideas about how to implement the workflow outlined above by exchanging appropriate messages between the device and some control pad over the MQTT bus all devices are attached to. That would be the remote controlled way of managing a device in the field without having it on your desktop either attached to your workstation or in your local network at least. This method requires the device to be subscribed to a MQTT broker.

Device is available through other means

Other transports for downlinking messages will be unlocked, we are looking at UDP-over-LTE [3] and LoRaWAN here.

  1. ESP32 network discovery through network scanning ↩︎

  2. ESP32 network discovery through mDNS with MicroPython ↩︎

  3. Dynamische Regelung des Meßintervalls ↩︎

12 posts were merged into an existing topic: ESP32 network discovery through network scanning

if you go to sleep directly after dhtp… like wakeup -> dhcp -> send-mqtt-packet -> sleep, i dont think the device will be awake long enough for you to get a tcp handshake done, or packets answered at all.

what about adding a mqtt-status which gets polled every time it wakes up, and if it doesnt exist or is ‘run’ -> do like before, if the status path is ‘edit’ or ‘maintainance’ it waits for clients to connect for a minute or 10 and then goes to sleep till the next wakeup time?

the ‘state’ could be set/changed by a simple script the user managing the node runs against the same mqtt broker the client connects to… ‘ -p /sensor/mqtt/base-path -m maint’ … and the device stays alive for 10 minutes after the last client disconnects, and ‘ -p /sensor/mqtt/base-path -m run’ to push it back to its configured schedule.

this could be also intregrated into an ‘app’ if something like that would be done by anyone.

also: does micropython have a mdns implementation? maybe local dns is simpler that way for endusers… use nodename.local

1 Like

Dear @roh,

thanks for sharing your thoughts, they resonate well with what we discussed the other day and just today again with @einsiedlerkrebs.

Exactly. I can imagine opening the maintenance window by one of two different events:

  • Seeing a MQTT retained message on the bus at boot time or receiving a respective one at runtime. Without further ado, this will enable the maintainer to open the Wartungsfenster in a software-controlled manner. We will have to recognize this will apply only to the next cycle which might be an hour into the future.
  • Pressing a button. This is crucial for getting the device out of deep sleep immediately and will also put the device into maintenance mode.

Search results for '"maintenance mode"' - Hiveeyes

We discussed this a few hours ago with @einsiedlerkrebs already, so we will be happy about further ideas or what we might have missed.


Feels like a reasonable baseline. Maybe we will add some sugar. [1]

That would be cute. We are looking at integrating this with the GitHub - Hiverize/Webinterface as it has a high priority for all the people conducting the first Workshops - Hiveeyes this summer.

In the end, we would like to trigger that kinds of actions from Grafana itself without Medienbruch.


  1. ↩︎

7 posts were merged into an existing topic: ESP32 network discovery through mDNS with MicroPython

Maintenance mode tools

Dear @roh,

we followed your suggestions but twisted them slightly to apply the idea to the local LAN instead of the MQTT ether first in order to make the first case where the device is not connected to MQTT at all. We will add the second variant as we go.

We verified that and we believe the ARP discovery converges quickly enough to transmit a small UDP beacon in time – at least for a minimal cycle of our current firmware which is a bit heavier than others and takes about five seconds while the device is connected to the local WiFi network. It looks like five seconds is plenty enough time here.



We tried to fold that idea into some commands we added to the repository as an ad hoc tooling. The code will be refactored as we go.


# Device discovery plus "maintenance mode" switchover.
# Wait for device to appear on local network, then enable maintenance mode.
sudo python3 tools/ maintain

# Same as above, but address specific device.
sudo python3 tools/ maintain 80:7d:3a:c2:de:44

Full documentation

Enjoy Basic maintenance mode.

Thanks again!

Naming things

Hi there,

while we believe maintenance mode might already be a reasonable wording choice, we are unsure about field mode here and would like to put both words into a short discussion / asking for feedback.

So, we would be happy to learn better words for that purpose. This is important to us as we all know naming things appropriately [1] is a good thing.


  1. ↩︎

i see… not maintainance mode is no option, so we need to name names now…

how about ‘normal mode’ and ‘maintenance mode’? i like it simple :)

How about “operational Mode”,“autonomous mode” or “employment Mode”.



  • Skip the real mode altogether and call it “maintenance mode” attributed by on vs. off or active vs. inactive. Kind of lame ;] and might have a higher mental load than using distinctive words. On the other hand, … [1]
  • “Normal mode” – why not. Let me also mention “regular” here while I like “normal” more.
  • “Live mode” would also be short and concise.
  • I also like “operational”. Would also make appropriate verbs like “maintain” vs. “operate”.
  • I don’t know if “field mode” would be even a thing or if we should make it a thing. We might consider keeping things like they are (will save on renaming time), but as you can see I will be happy about any refusals – let’s pick one of these alternatives then.

  1. … the implementation also boils down to a boolean flag enabling maintenance mode. An appropriate command would look like

    Why not? ↩︎

Probably not. There is already Field test mode - Wikipedia and this would mean quite the opposite then, which might confuse some people who know.

oh… i see… how about ‘robot mode’ ? i think in russian рабо́та (rabota) means ‘work’ ;)

Not that bad either, I like the sound. However, I would like to point out some things.

Software eats the world.

‘live mode’ as an opposite to ‘maintenance mode’ is fine.

1 Like

Field mode is fine for me! Work mode, measuring mode, but maintain is also working and measures data.

Btw field test mode is not fiend mode so I see no problem.

While I also liked this phrase beforehand, after being half-way through the renaming process, it occurred to me that the semantic meaning of “live” vs. “sleep” will give us a very bad intertwingulation of things. As like one user might ask some day:

You want to tell me that the device will enter into “deep sleep mode” if I will check “live mode” in the user interface? Are you kidding me?

So, let’s suspend the renaming process for now and give this some more thoughts.