I am finding the firmware options a bit baffling, I can’t get my emontx4 to work with the temp sensors in the rj45 via the breakout board which the manual suggests should work? It’s not the board as it works fine in an old EmonPi.
I also still can’t seem to get the 12 sensors code to load and report over radio as expected, would you mind linking the latest source is that GitHub or elsewhere?
Hello @whitecitadel the latest firmware examples Im working on are here: GitHub - openenergymonitor/avrdb_firmware: EmonTx4, EmonPi2 & EmonTx5 combined firmware but you may want to hold off using these until I release them properly.
There are three firmwares:
emon_DB_6CT - this uses the newer emonLibDB library and supports both single and 3-phase modes (switchable with a #define setting) and up to 6 CT’s. This firmware is suitable for all three hardware variants, it include energy values saved to EEPROM, and serial configuration. This is the recommended firmware for most applications.
emon_DB_12CT - this uses the newer emonLibDB library and supports both single and 3 phase modes and up to 12 CT’s. Suitable again for all three hardware variants. This does not include energy values saved to EEPROM or serial configuration. Calibration is currently hard coded and require firmware compile and upload using the Arduino IDE.
emon_CM_6CT_temperature. This is primarily for emonTx4 & emonTx5 applications that require temperature sensing . It uses the emonLibCM library that supports temperature sensing (albeit with accuracy caveats). For emonPi2 applications that require temperature sensing, the RaspberryPi itself handles the temperature sensing directly offloading this task from the avrdb microcontroller. This firmware is also useful for applications without voltage sensing: e.g current only or apparent power. The number of temperature sensors can be changed with a #define setting, standard is 3, but I’ve tested up to 6.
Thanks Trystan, I will try loading the latest 12CT code once released, and comprise that the temp sensors cannot be used it seems with 12CT.
Not a big complaint, just a rethink needed as I want to move my EmonPi away from the CU to tidy up the wall in the WC where it’s located.
Thanks Paul, If it’s a 12 CT emonPi2, the RaspberryPi handles the temperature sensing. It’s only the the 12 CT emonTx5 that does not support temperature sensing…
In my case it’s an EmonTX4 but I assume the same restrictions?
I think the sensors work easily with a esp, pi pico or some other low cost solution so I’ll look to take temperatures another way into emonhub
Correct - the poor old 8-bit processor is far too busy to be able to pause its main job of energy monitoring for the ¾ second or so while each sensor transmits its data.
Thanks Robert, it’s confusing as the emontx had all these ports… but it was not immediately clear you can’t use temp sensors.
No real issue I just need to rethink how to get those temp readings once I move my EmonPi
Hopefully not quite so confusing when you know the reason - the pulse inputs take up almost no time at all, and the analogue input is in there as part of the currents scan sequence: it’s really CT12.
As far as I recall, the situation is the board was well advanced or even in manufacture before it became apparent that there wasn’t time to try to interleave reading each temperature sensor one bit at a time in between taking current and voltage samples with the ADC. And I’m not going to try to do that now as it’s obsolete.
Can I ask is the eeprom too small for the CT12 variant? Even if it didn’t store ongoing energy values couldn’t it be used to store configuration ?
Can you explain in a bit more detail what you’re trying to find out/suggest, because what you’ve written doesn’t relate to anything previously written in this topic.
Is there a technical reason the emon_DB_12CT doesn’t use the eeprom for serial config? Is it space constrained or something else? If it didn’t store energy values could it be used? Compiling your own firmware whilst not hugely complex is certainly going to be a challenge for some.
Trystan asked me about writing a sketch to save the configuration etc in EEPROM towards the end of last year, and I asked for a specification for what he wanted saving. I’m still waiting. Meanwhile, the emonTx4 has become obsolescent if not obsolete, so it’s not likely to happen.
This has nothing to do with temperature sensors - the reason those are not supported I explained above.
I understand the technical side, but I have recommended OEM to a lot of people over the years, some just want it to plug and play and not deal with databases and compiling code as I might, for those average users it should probably be made clear in the shop EmonTX4 does not do temperature sensing or has limited capabilities.
As you said its obsolete platform now, so no future concern, but it means I will need to move my temp monitoring once I move my EmonPi away from the house CU (where it was never a good location but necessary)
There is emonTx4, emonPi2 and emonTx5 firmware that supports temperature sensing running on the AVR-DB microcontroller (with up to 6CT sensors and single phase only). The option that supports temperature sensing uses the earlier emonLibCM library. The important thing to note here is that temperature sensing is supported by degrading the performance of the electricity monitoring very slightly and it does seem to be quite a small impact, see my post about this at the time here EmonTx4 DS18B20 Temperature sensing & firmware release 1.5.7 - #3 by TrystanLea
While I’m quite happy with the approach I took there, Robert and other’s who I consulted on this were less happy with the approach I took, I completely accept it’s an imperfect and not entirely satisfactory solution and don’t wish to argue that it is anything else.
So with Robert developing the new emonLibDB library to support up to 12 CT sensors and 3 phase monitoring we decided against trying to apply a similar approach with this library, there is more going on in the new library as well.
In summary, there will be 3 new firmwares available for the emonTx4, emonTx5 and emonPi2
emon_CM_6CT_temperature uses the emonLibCM library and therefore supports temperature sensing with the caveat above.
emon_DB_6CT uses the emonLibDB library and therefore does not support temperature sensing on the microcontroller core.
emon_DB_12CT uses the emonLibDB library and therefore does not support temperature sensing on the microcontroller core.
When emon_DB_6CT and emon_DB_12CT are used in the emonPi2 configuration (with a RaspberryPi inside the case) temperature sensing is supported via the RaspberryPi itself 
I wouldn’t say it’s obsolete, it’s very much in active use, with ongoing development on firmware and continued full support. The emonTx4 has only morphed in shape really to the soon to be available emonTx5. The firmwares and hardware functionality is almost identical
I agree thought that we made the decision not to try and incorporate temperature sensing in the emonLibDB and I think we should keep it that way. For 12 CT or 3phase applications the emonPi2 is the solution that provides both electricity monitoring and temperature sensing given that temperature sensing is offloaded to the Pi.
No technical reason, I am going to look at this soon, I agree it would be nice to be able to do this.
@Robert.Wall When I have a first draft of this working I will send it your way for comment.
Hmm…
I was under the impression that there will not be another batch manufactured? If this is and remains correct, then the emonTx4 IS obsolescent. When the last unit from stock is sold and no more will be manufactured, it becomes obsolete.
Becoming obsolete not mean it becomes unsupported - the emonTx V2 remains supported, emonLibCM will run on it and it will even work with the emonPiCM so long as you don’t require the radio channel to be encrypted.
While I dont want to argue about terminology, the term obsolete as defined here Oxford English Dictionary and here Obsolete Definition & Meaning - Merriam-Webster indicates “no longer in use or no longer useful”, which is certainly not the case for the emonTx4. The main change going from the emonTx4 to the emonPi2 and emonTx5 is the enclosure and board layout in order to make it possible to fit a full RaspberryPi and LCD in the a single enclosure, the firmwares and the important parts of the circuit layouts are all the same.
A heads up, just to say that the new firmware release is in progress. I will post with full details soon, I’m just working my way through the documentation making sure references and wording all match the new firmware’s. I also still need to do pre-compiled JeeLib Classic binaries for those that need backwards compatibility. This is just a simple #define change and compile but I wanted to make sure that everything is working ok with the first batch first before I upload these.
Thanks, I was looking at this again just now and noticed that the repository had been updated.
I will try the 12CT code if its final, I think I am running the JeeLib classic still but need to bite the bullet and change my OG emonPi and 2* EmonTX3 over at some point may as well be now.
@TrystanLea I was looking at the docs again after your comments above on all the generations being derived from the same concept:
https://docs.openenergymonitor.org/emontx4/expansion_boards.html
And I see that EmonTX4 can support a PiZero. It looks like a small board is needed to sit on the headers on the EmonTX4 and connect to the PiZero headers - but I can’t see this in the shop?
To solve my temperature problem, I could add a PiZero, wire to GPIO4 for the temp sensors, but not make it an EmonPi and just have it log locally serial then feed to the main EmonPi?