I think you can use .ino, but .cpp works just as well even in Arduino IDE and is much better for use in other IDEs. Just need to #include <Arduino.h> and write actual C++ ;-), but on the plus side when you get a compile error it will give you the actual line number of the error.
That is an excellent way to construct it as It would be very useful for some of us to be able to swap out the emoncms code for an emonhub alternative.
I am very interested in the development of wifi connected nodes with ota updating but where I want to use them I cannot connect them to the existing wifi and my monitoring equipment can only have one externally exposed device per site. So to be able to connect multiple emonTx to a single emonbase/emonhub configured as an wifi AP would work very well for me as it offers greater security (only one device connected to the WAN), multiple targets (html & mqtt) and will also offer buffering of data undelivered due to network issues or server maint’.
Not to mention it making the site a closed system that can continue to operate independently of an outside connection which is essential as we move into control. In time I would like each emonbase/emonhub to run a mqtt broker for all local activity and bridge to a main broker.
This single link between hub and main server paves the way for using either a single tunnel or gsm device if faced with networks behind proxies, tough firewalls.or just remote locations.
I know that many average users will have no interest in much of this but just by making the code modular and being aware of the possible options makes the project much more flexible and suitable for easy adaptation by those of us that want something different but do not want to have to totally rewrite or create more versions instead of building on whats there.
I do find the openTRV code (actual c++) quite hard to follow. I guess it’s what I’m used to: Arduino c++ etc. Unless there is a compelling reason to do so I would be keen to keep using the nice Arduino SDK wrappers instead of raw c++. IMO it makes the code much easier to follow and reduces a barrier to entry since most people involved in the project are more familiar with Arduino than raw C++.
I quite like the firmware layout I used for the emonPi, however, I would be happy to entertain other options. You have more experience than I do with software development
Yeah, I guess that is true my ‘actual C++’ was referring to doing all the magic that the Arduino pre-processor does (sometimes badly) for you, eg, function prototypes, etc, but that being said I am not dead set on using cpp/h files.
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 . 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 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 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.
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 .
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 . 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
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.
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?