I recently changed my firmware of my emonPi2 to the one described as “emonPi2 CM single phase, 6 channel firmware. Digital input on analog (e.g for use with DHW sensor). Can be used without an emonVs voltage sensor (current only)” on the admin/update page. I think that refers to the emonPi2_CM_6CT_digital_v1_6_3.ino.hex compiled image on GitHub. I switched to that firmware because I was installing the DHW status sensor so I wanted a digital input from ADC input on the emonPI2.
Since then I haven’t had any readings from the V1 input. It’s now saying that it’s last reading was 4 days ago, which is when I made that firmware change.
Is that expected? Do I need a different image?
I’m quite happy to compile my own if that’s what I need to do.
Hi @markh - you’ve got a version that is current only, with no voltage sensing. See the link to the readme on Github. Due to the limitations of the AVR, there are multiple versions rather than it being configurable at run time.
You need to have one with 1phase in the filename, but I don’t think any of the pre-compiled ones has the analog enabled for DHW. You’ll need to compile your own - I would go for the 6CT firmware. You then need to uncomment #define ENABLE_ANALOG on line 74 in emon_DB_6CT.ino to enable the analog input for DHW.
Adding to Angus’s reply - if you download the source sketch and emonLibDB – the library that does all the work – you aren’t limited to the published sketches. Included in the zip file you download for emonLibDB you’ll find full documentation for the library; and with that and the example sketches provided in there, in combination with the other ‘standard’ ones, you should be able to mix-and-match to your individual requirements. Of course, ask if you are in difficulty. I can’t help you if you have problems with platfomio, I can’t use it as it screwed my system up when I installed it to try it out. I can help with the Arduino IDE.
Thanks Robert and Angus. I’m all set now. I can’t tell you how much I appreciate such a responsive community.
I ended up porting the code for treating the analog input as digital from the emon_CM_6CT_temperature build. I could have synthesized a digital feed from the analog one in EmonCMS but that was very straightforward to do it in the firmware, so why not?
My involvement with emonLibDB ended with the example sketches bundled with the library, so I can’t give a definitive answer, but the library itself is so versatile that it would be very difficult to handle all the possible combinations in one sketch, so this might well have been the reason. From what I remember, memory wasn’t an immediate concern, but it could well have become one.
Is there a reason why there are 3 separate, configurable firmware builds
I had a quick look through, the main difference is in how the messages are packed and transmitted (there’s also some differences in the EEPROM handling). Agree they could probably be merged, but it would take a bit of work and at this point they are quite widely used, so there’s always the risk of breaking existing applications. I’m not sure what the background to it is - the AVRs are compute rather than memory limited in this application.
I was toying with the idea of volunteering to merge them all but you’re right that the risks would be significant. I’d need to find a way of convincing myself that I hadn’t broken anything and I’m not sure how I’d do that. I’ve been spoiled in the non-embedded world.
@markh - you might be interested in contributing to the upcoming emonPi3/emonTx6. I’ve written that as a single firmware image, with the options configurable at run time. It’s a much more capable microcontroller, and a nicer embedded development process (not Arduino!). Don’t feel you need to replace your Tx5, it’s still perfectly functional!
