Is it possible to OTA a moteino with an ESP8266 or other Arduino variant rather than needing a linux / Windows PC?
Thanks
Not really.
Right now you need a PC to run the program which takes your serial HEX stream and talks to a programmer, which then relays that HEX stream to the target.
The supported program is a windows program, there was an older python script that did the same but it's not up to date. So even if the python script was updated, you'd need a machine which can run that or the windows program.
Doing all this with an ESP seems not worth it in terms of what you gain.
Thanks for the response. If I was creating a hub as a product, the ESP8266 is easier to code (Arduino world), cheap, and easier to create a circuit board compared to a Linux embedded
I've been working a lot with the esp8266 as gateway. It's great for that purpose and in my opinion much more reliable than a Pi. I'm using it for OTA also but I use a different scheme than Felix. Someburner has a native esp8266 gateway on GitHub that supports Felix style OTA.
Joe
Joe, have you published your code yet on OTA? I was trying to follow the posts you had with ~ 2.5s OTA.
Here is a github of someone doing something similar to you using the xBee modules, OTA not needing an external EEPROM
https://github.com/davidsainty/xbeeboot
QuoteJoe, have you published your code yet on OTA? I was trying to follow the posts you had with ~ 2.5s OTA.
I haven't. I sent a beta test version to three people and found the response underwhelming. So my enthusiasm about releasing it kind of waned.
QuoteI haven't. I sent a beta test version to three people and found the response underwhelming. So my enthusiasm about releasing it kind of waned.
BTW, there is one more reason I'm on the fence with the bootloader: it works great for normal installations, even supporting multiple bitrates and coin cells.
But I've recently implemented frequency hopping and would like to do TDMA in the future (all my new motes get 32.7k clock crystals). There's no way all that code would fit into a bootloader of 4kb size. There's a solution for that, too: sharing the radio library between bootloader and application and being able to update both independently, which has many advantages of its own. But I just haven't gotten to that part nor do I know if I ever will.
Joe
Ok ....... so the answer still stands at not really.
Not without extensive extra coding at the very least.
I'm not sure what the OP meant by "OTA to a moteino," but depending on what he meant, the answer may be "yes": https://lowpowerlab.com/forum/wireless-programming-(aka-ota)/windows-program-for-wireless-programming/msg12478/#msg12478
And it works quite well.
If that's what you meant, I've reduced that prototype mess to a very simple PCB shield for a Wemos D1 Mini. You'd still need to plug a Moteino into it, but it would give you a portable (i.e. totally wireless) gateway through which you could do OTA updates to other moteinos (not plugged into it) using msjfb's windows app. That was proven out over a year ago.
In the first post, it's apparent to me the question is about doing Wireless Programming of a target Moteino, using an ESP8266
only, no PC:
Quote from: brolly759 on December 14, 2016, 01:33:56 AM
Is it possible to OTA a moteino with an ESP8266 or other Arduino variant >>>>> rather than needing a linux / Windows PC? <<<<<<<<
OTA = "Over the air", mostly used in relation to wireless programming. Not really obvious but ... seems to fly just like "IoT".
Quote from: joelucid on December 16, 2016, 03:07:40 AM
BTW, there is one more reason I'm on the fence with the bootloader: it works great for normal installations, even supporting multiple bitrates and coin cells.
Hi Joe,
It's been almost a year since the last time I've bugged you about the bootloader code and kept hitting refresh daily on this forum waiting for your published bootloader.
I'm running now with some HC-05 BT modules hooked up to be able to program some nodes, unfortunately it messes up my ATSHA204 signing somehow, a RFM69 OTA bootloader without external flash would be priceless.
So could you please share this beta "works great for normal installations" version?
Thank you.
Quote from: Felix on December 16, 2016, 01:23:26 PM
In the first post, it's apparent to me the question is about doing Wireless Programming of a target Moteino, using an ESP8266 only, no PC:
OTA = "Over the air", mostly used in relation to wireless programming. Not really obvious but ... seems to fly just like "IoT".
One could read that as meaning he doesn't want to have a PC dedicated to being connected to a Moteino. For instance, maybe he only owns a laptop, and he wants to take that with him out of the house--not have it tethered to a moteino. It's a slippery slope. I mean, are we to assume that he doesn't compile his sketches on a PC either? Because it's that step which generally immediately precedes an OTA update.
Good evening everyone. To clarify, here is my ideal situation:
ESP8266 is the Gateway / Hub and talks over MQTT to a broker somewhere in the Ether. The ESP8266 can OTA, upload sketches to motes using RF69 modules without external EEPROM. Using an ESP8266 or variant would reduce the cost of a Gateway significantly by not needing a Linux/Windows system.
QuoteESP8266 is the Gateway / Hub and talks over MQTT to a broker somewhere in the Ether. The ESP8266 can OTA, upload sketches to motes using RF69 modules without external EEPROM. Using an ESP8266 or variant would reduce the cost of a Gateway significantly by not needing a Linux/Windows system.
Exactly my setup. It's not only the cost that's the issue. Raspberry's are pretty noisy and I got a big boost in radio sensitivity when I switched. Plus Raspberries aren't exactly reliable for some people. I've never had these issues but people I've helped with their projects have had frequent flash drive corruption or reboots for example.
Would love to know your setup or how to do it! :)
Something I had an issue with on Raspberry Pi3, I had to dumb down the CPU core clock speed to 250 because the UART is tied to the Core speed, and baud rates will fluctuate, so any xBee modules would read or send garbage data :(
QuoteSo could you please share this beta "works great for normal installations" version?
I've put together another preview for executiveul. If anybody else is interested in testing the bootloader let me know. The caveat is there is very little UI. I currently just upload configuration files and images to the esp8266 using curl - just as I like it. But it's fully functional and will deploy any sketch reliably in a couple of seconds without external flash. ISP programmer required for the initial install of the bootloader.
Joe
Just as a matter of interest, is any of this OTA bootloader stuff based on avrdude? There's plenty of support for that on linux and Windows PC. You'd need to set a virtual serial link up but there are serial bootloaders out there that could be tweeked relatively easily to do that, even add xmodem support.
Mark.
QuoteJust as a matter of interest, is any of this OTA bootloader stuff based on avrdude?
In my case it isn't. I use a esp8266 as gateway and it talks a custom protocol to the installing node. You use a http post to copy hex files and the config file to the esp8266. Not sure how avrdude would help here.
I have been looking at this for a while, and I can't understand why this is not possible.
First, I want to outline a few criteria, and then ask a few questions, and propose how this *could* be done. I too am anxious to complete this and have this work for myself.
My scenario is:
- Sensors built using the Moteino boards, with the flash memory necessary.
- A gateway, with a ESP8266 connected using TTL serial to a "local" Moteino
When I look at the OTA code, it appears that the "PC" or "Python code" is simply sending the .HEX file to a Moteino using a specific protocol format.
- There is an initial "handshake" that must be done (e.g. FLX? / FLX?OK)
- There is a "target set" that indicates the target address for the Moteino to be updated (e.g. TO:{address} / TO:{address}:OK)
- The HEX file is then sent, using a line-by-line record format with sequence numbers (e.g. FLX:{sequence}:10042000FF4FA591B4912FB7F894662321F48C91D6 / FLX:{sequence}:OK)
- There is some retry logic that has to be written, in case the FLX:{sequence}:OK is not received, or out of sequence, or timeout.
- There is a "EOF" handshake that indicates it's done (e.g. FLX?EOF / FLX?OK)
This is a quick - first look - at the code, but it all seems possible to write this protocol to run on the ESP8266.
In my scenario, I would see this working like:
- ESP8266 makes a GET request to a web server, passing the remote Moteino node address and current firmware version (it got this from the remote Moteino)
- The web server will pass back a response indicating if no firmware update is required (some short "NAK" string)
- If the web server finds that an update IS required, it will begin to return an "ACK" header, and then the contents of the HEX file
- The ESP8266 will read from the GET response and look for the "NAK"
- If the response is NOT the "NAK" string, and is the "ACK" header, then there is a firmware update for the remote node
- The ESP8266 will begin the handshake with the remote Moteino, over the TTL serial connected local Moteino
- The ESP8266 will read the HEX file being sent by the web server and update the remote Moteino using the protocol above
I do understand there will be timing issues that have to be looked at, and how to read the incoming file stream from the webserver and push these to the remote Moteino, but I can not see any reason that this could all be done without using a PC at all.
Thoughts?
What are the critical issues that I have missed, or that I am not thinking of?
Quote from: brolly759 on December 16, 2016, 11:57:50 PM
Good evening everyone. To clarify, here is my ideal situation:
ESP8266 is the Gateway / Hub and talks over MQTT to a broker somewhere in the Ether. The ESP8266 can OTA, upload sketches to motes using RF69 modules without external EEPROM. Using an ESP8266 or variant would reduce the cost of a Gateway significantly by not needing a Linux/Windows system.
The code I released assumes a Moteino "programmer" (which takes the HEX and relays it to your listening "re-programmed" node).
However everything is handled over serial so the GUI doesn't care what your programmer is as long as it follows the protocol.
Not to say this will definitely work because I haven't tried it but I think it should be very similar, you may have to change pin defs etc.
Only the target has to be in RX mode (listen) and have a FLASH MEM chip on it.
One day WP (OTA) will work in true listen mode ::)
Quote from: Humancell on January 23, 2017, 01:12:21 PM
- A gateway, with a ESP8266 connected using TTL serial to a "local" Moteino
There exists a simple interstitial board that will do that part for you. You can download it free from here: https://www.openhardware.io/view/273/ESP-LINK-ESP8266-WeMos-D1-Mini-Adapter-Board
and get it fabbed at your favorite fab.
The photos show it connected to a pro mini, but it could just as easily be connected to a Moteino. It then doesn't matter whether what's feeding it in a PC or an ESP8266 or a server or whatever. The proof of concept was initially done with a PC feeding it over a wireless "virtual" serial link (which is what ESP-LINK provides) using an earlier prototype and msjfb's software here: https://lowpowerlab.com/forum/wireless-programming-(aka-ota)/windows-program-for-wireless-programming/ The combo of D1 Mini and Interstitial board and Moteino simply boils it all down to something that's easier for people to make.
For what it does, it works very well. You may want to leverage it.
[/list]
Quote from: Humancell on January 23, 2017, 01:12:21 PM
In my scenario, I would see this working like:
- ESP8266 makes a GET request to a web server, passing the remote Moteino node address and current firmware version (it got this from the remote Moteino)
- The web server will pass back a response indicating if no firmware update is required (some short "NAK" string)
- If the web server finds that an update IS required, it will begin to return an "ACK" header, and then the contents of the HEX file
- The ESP8266 will read from the GET response and look for the "NAK"
- If the response is NOT the "NAK" string, and is the "ACK" header, then there is a firmware update for the remote node
- The ESP8266 will begin the handshake with the remote Moteino, over the TTL serial connected local Moteino
- The ESP8266 will read the HEX file being sent by the web server and update the remote Moteino using the protocol above
...
Thoughts?
By the way, there is a swiss guy who has put together something similar to what you described (http://iotappstory.com/how-to/get-started). It's free, and it's cloud based, but it presently just works with ESP8266. I'm not sure, but maybe it would not be hard to extend it to include Moteino's.
Then, of course, there's Joe Lucid's wireless bootloader, which works great but isn't GUI oriented. If you're good at making GUI's, I'm sure you'd find a fit there. In fact, that may be your shortest path.