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.
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
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.
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
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.
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.
… the implementation also boils down to a boolean flag enabling maintenance mode. An appropriate command would look like
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.
