emonESP firmware development

14 posts were split to a new topic: ESP8266 > AVR ISP sketch upload over WiFi

I think the split is a great idea. It will be much easier share code or add/remove modules between the OpenEVSE <=> EmonESP versions.

1 Like

@glyn.hudson What are your plans re, merging the mqtt branch?

I have been developing the changes in the mqtt branch using a Adafruit Huzzah, the code has been proven to be stable. Running no problem for the past couple of weeks. However yesterday I uploaded to the HeatPump monitor board that @TrystanLea has been working on and it crashed :frowning: . The HP monitor should be using the same ESP as the Huzzah, I think it could be a power supply issue. Although the HP monitor board has been running the code in the master branch just fine. Maybe the additional complexity has caused an additional power requirement.

I would like to merge soon, I just want to be sure that the new code will be stable since the master branch code is being used for client installations.

I think I may remove the OTA upload (from a server) since I have not got this to work reliably. Update via upload in the web interface seems to work ok, I will keep this.

I wonder if it’s possible to update spiffs via web interface upload?..

Does it crash when starting WiFi? This caught me out yesterday and I was pulling out my hair for a few hours trying to figure out why it was crashing on one device and not another and it turned out to be the UART adapter was not supplying sufficient power.

Mine has been working well.

As long as it fails gracefully, as in does not leave the device in a non-working state, I would leave it in there. Just document it as a known issue so the folks that need a more reliable upload method can avoid it.

Should be able to, it is after all a file system :wink: So worst case you can upload a zip file and decompress it to the SPIFFS, but I am sure a little hacking of the web upload should be able to write directly to the flash.

I have been getting ready for a V1.0.0 release to master by doing a bit of documenting / user guide on the readme.

Please let me know if you think I’ve missed anyting important:

https://github.com/openenergymonitor/EmonESP/blob/mqtt/readme.md

Looks good to me, only thing I could see is the default SSID when initially setting up is emonESP_xxx.

1 Like

Thanks, been fixed

MQTT branch has been merged into master and released with version V2.0.0 tag :slight_smile: . Thanks for your help.

Release V2.0.0 substantial update · openenergymonitor/EmonESP · GitHub

MQTT branch has been removed. Please branch off and direct PR’s to Master branch.

For the release, I have removed the button to apply OTA update via the web interface. Function can still be accessed via URL.

1 Like

Yay, good work.

I was thinking now would probably be a good place to break up the sec.ino file a bit. I can probably look at this within the next day or so if you wish.

1 Like

I’m travelling a bit for the next few weeks so won’t be able to do much dev or testing, but I will do my best to give input. Thanks a lot.

I have done some initial changes to split up the code, have a look at my fork on the code_split_up_cpp branch

https://github.com/jeremypoulter/EmonESP/tree/code_split_up_cpp

Mostly each xxxxx.h file contains the ‘public’ API calls of the format xxxx_yyyyy. Any API intended to be called from setup() is named xxxx_setup() and those to be called from loop() xxxx_loop().

The split up breaks the code up as follows;

  • config - load/save the EmonESP settings
  • emoncms - Code for pushing to EmonCMS
  • http - HTTP/HTTPS helper functions
  • input - read the input from serial/web
  • mqtt - pushing to MQTT
  • ota - handle updating the firmware of the ESP
  • web_server - provides the web interface to the EmonESP
  • wifi - management of the WiFi

Done some cursory testing and it all looks to work, Any feedback would be appreciated.

Nice work, I like how src.ino is now nice and clean :slight_smile: .

I’ve tested compiling using PlatformIO and it compiles fine. I’m getting my head around how all the parts fit together but it all seems very logical splits :thumbsup: . Thanks so much for taking to time to do this, it must have taken a considerable amount of work.

I don’t have an ESP at hand to test for real right now.

Have you tested compiling with Arduino IDE?

I have given you access the the EmonESP repository when you done could you push your branch to OpenEnergyMonitor/EmonESP code_split_up_cpp branch? This will allow us to work on it together and make merging easy when we’re ready.

Interestingly the refactor caused the compile size to increase very slightly (probably negligable), is this what you would expect:

Before refactor:

text       data     bss     dec     hex filename
353494    12700   33240  399434   6184a .pioenvs/emonesp/firmware.elf

After refactor:

text       data     bss     dec     hex filename
354262    12728   33248  400238   61b6e .pioenvs/emonesp/firmware.elf

Have you got any thoughts @TrystanLea?

1 Like

Was actually not that bad, using cpp/h files helped a lot as Platform IO handles them in a much nicer way than .ino files, e.g. it compiles a list of warnings/errors that you can click on and it will take you directly to the file/line with the error.

Yes, worked ok for me so hopefully shouldn’t find any problems there.

Sure no problem, can push this to the branch later today in the current state then I think there is just some tidy up to do, e.g. add some documentation to all the new functions and files.

I would expect a small increase as I split up several functions in to multiple functions, mostly the web server stuff does not directly write to the EEPROM or do any WiFi.

2 Likes

Changes now pushed to the OpenEnergyMonitor/EmonESP code_split_up_cpp branch

1 Like

Nice, thanks. I can see it on github.com

But when I $ git pull then $ git checkout code_split_up_cpp I get the error: `error: pathspec ‘code_split_up_cpp’ did not match any file(s) known to git.

$ git checkout origin/code_split_up_cpp works but then I get the message:

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

does this mean when we merge the split up changes we will need to force push and loose all the previous comimts and git tracking for the repo?

You’ve probably already considered this, but did you;
git fetch origin
before checking out the code_split_up_cpp branch?

Paul

This worked for me from a fresh clone;

jeremy@MOONSHADE:~$ git clone https://github.com/openenergymonitor/EmonESP.git
Cloning into 'EmonESP'...
remote: Counting objects: 1015, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 1015 (delta 0), reused 0 (delta 0), pack-reused 1011
Receiving objects: 100% (1015/1015), 462.41 KiB | 0 bytes/s, done.
Resolving deltas: 100% (494/494), done.
Checking connectivity... done.
jeremy@MOONSHADE:~$ cd EmonESP/
jeremy@MOONSHADE:~/EmonESP$ git fetch origin
jeremy@MOONSHADE:~/EmonESP$ git checkout code_split_up_cpp
Branch code_split_up_cpp set up to track remote branch code_split_up_cpp from origin.
Switched to a new branch 'code_split_up_cpp'
jeremy@MOONSHADE:~/EmonESP$

or I think you can also use git pull origin code_split_up_cpp

1 Like

From a fresh clone, the available branches should already be synced from Github, and immediately available to checkout.
With existing ‘clones’, it’s necessary to refresh the branch list, to pull-in new branches before they can be checked out.

Paul

1 Like

I though only the master was fetched… clearly not :wink: