ESP8266 Community Forum

I have been pondering the feasibility of being able to roll out live ESP_Basic script updates to ESP nodes, and I would appreciate any suggestions and comments.

I'm assuming more than one esp device, else there wouldn't be much benefit to be gained. But when you consider having several esp wifi nodes, especially if they are connectively related in any way, then it might be very useful when doing any program changes if you could roll out any or all of those program updates automatically in a controlled manner.

To put things into perspective with an easy-to-understand example, consider a relay 'alarm' node that can be triggered by several PIR sensor nodes. Say things already work fine, but you wish to update your little alarm 'system' so that all the sensors periodically report their presence to the alarm node, which then needs a capability for flagging up any offline sensors.

This would require program modifications to all nodes, but manually re-programming them takes time and causes system downtime. So I am trying to think of a better way.

In principle, it would probably be a matter of doing any relevent program changes on a local 'dev' node, then copying all program updates to sit on what would effectively be a central 'rollout' node, which might perhaps be the alarm node. Then it would just be a matter of all nodes (including the rollout node itself), to periodically 'check-in' to the rollout node to see if there was a new program update sat there for it, in which case it could download it to itself and reboot back online with its updated program.

So for instance, node PIR3 would have a small and simple bit of code causing it to periodically look for (or ask the rollout server for) any updated program, which it would download if and when available.

Another possibility is that the rollout server could notify any relevent nodes of any corresponding updates available for them, which they could then download when ready.

It would be a straightforward matter to include relevent checking/download commands into the EasyNet list of recognised local commands which could be controlled remotely.

And in the case of EasyNet nodes, all nodes would have unique specific node names available for naming the appropriate updated programs, but it should also work using nodes IP addresses for the appropriate updated program names.


The main problem is... how best to store and download the updates?

A couple of possible mechanisms that I can think of are...

1. O.T.A. - but I think that requires a special server, and I believe it requires splitting available memory into 2 alternative memory spaces which can be switched one for the other, therefore always wasting half.

2. Sending updated .bas files to the appropriate remote nodes spiffs, then triggereing the node to reboot - but I don't know if it's possible to 'send' files to spiffs on remote nodes, or trigger remote reboots (although I have included the remote udp reboot facility into EasyNet).

3. Using just a small header program for each node, which 'chains' in and runs an appropriate main program from local SPIFFs - but I'm not sure if 'chaining' works, or if it is possible to upload to local spiffs from a remote (rollout) node.


Perhaps it's not yet possible, but it could offer some good advantage if it was, so I welcome any comments and suggestions...

It may not require a reset once bas is updated a simple invoking of run should likely do the trick providing it is your default.bas getting updated.

I did read on a github somewhere about this with esp8266 arduino not specifically this but it was a thread with igrr actually just don't recall the link just read the thing yesterday too when I was getting my OTA server to work. But essentially people were updating via OTA with code before they were doing firmware it appeared so the code may already be in place to accomplish this.

I do have a question about UDP and easy net when you invoke it does it basically just change your server port from port 80 to port 5001 or does it just open up another port to the server or is it strictly communications? The way I understand it is the server still runs on port 80 while udp allows for communications and such still should be useful to trigger the action if need be.

Hrmmmm I believe you will need an update routine of your own though to carry out the operation unless mike crafts something into basic to allow this specifically. But in your case you will be updating master as normal and all clients will be upgraded with the same framework update or client file if I am understanding this correctly right?

Anyhow best of luck if I come across info during my self education and trial and error I'll will attempt to help fill in the blanks here. Only problem with self education the more you learn the more you learn you really don't know!

Enjoy and take care EG

Ta for that. UDP needs a seperate port opened for it's UDP communications irrespective of whatever other ports have been opened for other things like browser. 5001 was chosen as an arbitrary number by Cicciocb but it can be changed for any other port number if preferred.

I guess I'll be putting that on the back burner for a while now though, cos I've decided to get my finger out and do an EasyNet Voice Announcer node to accompany the Relay/Thermost/PIRsensor node.

Thanks Forlotto, I know you were doing good stuff with ESP_Basic long before I'd even heard of it.