Maintenance mode galore

Introduction

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ā€¦ ā€˜set_node_mode.py -p /sensor/mqtt/base-path -m maintā€™ ā€¦ and the device stays alive for 10 minutes after the last client disconnects, and ā€˜set_node_mode.py -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.

Sure.

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.

Cheers,
Andreas.


  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.

Recap

Outcome

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.

Introduction

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

# Same as above, but address specific device.
sudo python3 tools/terkin.py 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.

Thanks,
Andreas.


  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ā€.

Thanks.

Thoughts

  • 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 https://robotframework.org/ 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.