Hi, is there a option, or will be in the future some automatic node (repeater) update, with the current software version?
2 Likes
I was thinking about the same today, because now we are getting updates every day 
For example all my devices are connected to WiFi, so it can check and download latest version automatically, or just show a popup on the tiny display and I will confirm it.
i‘have 3 routers, if there is a update, and a client see the router, it will be a great thing, the routers update by himself, like a virus, you infect one, and they will update all others …
1 Like
Like Friendface?
Well, this could work with WiFi or BT, but transmit a firmware (currently 1,6 MB) through LoRa would not be possible.
yes, i‘know, but this means, you have to visit all your node‘s i‘was more thing about, there is a image at the node, and what change will be transmitted, not the complett firmware, only changes.
if changes are transmitted and the hash summ is correct, the node make a reboot and activate the new firmware. and wait new changes.
Please keep in mind this project is in very active development.
The developers do make posts regrading the most stable version for people that do not wish to test the software and update all the time.
While I do agree that it would be nice to auto update remote nodes connected to wifi that would likely require testing each version just for that functionality so remote nodes are not left in an unusable state.
If you are running the webserver on your node and it is connected to your wifi I don’t see why you could not connect to the web interface to upload the latest firmware. If your not on the local network maybe try setting up a port forward in the router.
2 Likes
it‘s easy to explain … if you plan to bring a node to a very high Mountain, where it‘s hard to go … you start to think … how i‘will update the device … there is no wifi … only cloud‘s and a very nice view and the node get a very nice working area … if it should run as a public node, and poeple far away would use the node … you need always the current software version …
1 Like
We understand the requirement - that would be nice to have, but LoRa is a slow radio link, suitable for small data packets, like a message, or a sensor reading. You can read more about LoRa data rates, but it is quite technical.
In your example, someone will need to visit the mountain, and update firmware over BLE, WiFi, or USB.
1 Like
i‘know this, for that maybe a other way is possible, if you install a new device, why dont create a master firmeware file. if this file change at some device (new revision) and the node send a brodcast, he have a new version, and send only the changes, step by step, and other nodes modify with this smal changes there masterfile, later a checksum test they will reboot and activate, this will be only a smal data transfer, and this is like a wave … to all nodes what is in range … i‘dont say they must send always the completly firmeware file.
maybe this is a idea how update nodes … i‘means only nodes …
1 Like
How about don’t put alpha/beta software on devices in hard to reach places. That’s what stable versions are for.
While you update idea is nice, it would take limited resources on the nodes, and require its own set of testing. The project is too young and developers don’t have the time to test it in a controlled setting before releasing into the wild.
1 Like
This is a nice idea. Alas, it is impossible given how a C++ application is built. Our app (because even for minor releases) has lots of small changes (because if code moves many branch instructions change). The binary ‘diffs’ for going from 1.2.9 to 1.2.10 would still be quite sizable. And the upload protocol to send those changes over lora (which would take days/weeks / therefore not legal in some regions)? would need to slowly renegotiate lost packets etc and then have enough spare RAM to keep a whole app image (because writing to flash requires disabling the lora interrupt - due to how ESP32s page code from a serial flash).
A mechanism could be built to do this but it would probably be very very slow and hard to write. Unless someone is super excited to write this, I doubt anyone will put it in their work queue for at least a year, possibly two years or never.
I was wondering since we can send commands in a message if it would be possible to turn on WiFi through a message. Then on your remotely placed radio, if you had a yagi WiFi antenna pointed down towards an accessible location, perhaps you would be able to perform a firmware update semi remotely. You would still have to be in range of the device, but it might save you a day getting to it.
4 Likes
Would it be possible to have Meshtastic compiled in a way that the plugins could be updated OTA? That is, if the ‘core’ is reasonably stable/static (and constitutes the bulk of a binary image), maybe just updating individual plugins might be possible. Of course, my guess is that this isn’t feasible - I get the impression that the plugins are like Linux kernel modules and that the Mestastic ‘kernel’ has to know about them at compile time. (Also, I’m sure making the code more modular to make plugins more ‘pluggy’ will consume more RAM/flash/resources that may already be scarce on certain platforms).