You will need to make sure that the serial connections and supply voltage on the serial to USB adapter match those of the emonTx3 otherwise ‘sparks may fly and the magic smoke may escape’ …
I am assuming that you know what to do as you say that you’ve done it before …
I don’t want you to damage anything, including your self!
Thanks! I did it before via the Arduino IDE, I need to set up the environment again, and my old iMacs aren’t supported any more. Found the cable though
OpenEnergyMonitor.org
emonTH FW: V324
No EEPROM config
Int RFM...
RFM Started
Node: 24 Freq: 433Mhz Network: 210
Int SI7021..
SI7021 Started, ID: 21
SI7021 t: 21.00
SI7021 h: 60.44
No DS18B20
I’m not sure what V324 means (perhaps 3.2.4?), the current options in Admin/Update/Firmware for emonth2 are both 4.1.5, but only for LPL or JeeLib Classic, not JeeLib Native.
But I’d linked to all that way back up the thread!
emonTx V3.4 EmonLibCM Continuous Monitoring V0.10 signifies that it was indeed a development version, I’m reasonably sure that it’s release successor will be this: EmonTxV34CM_rfm69n.zip (71.4 KB)
emonTH V3.2.4 was a prior version of this: EmonTH_V2_rfm69n.zip (54.8 KB)
(It is listed in the “Changes”)
I think I tried to explain this above too. Does nobody read what I’m writing?
where firmware_version = 1.0.0 where this is the first release
.
.
.
Looking at the emonTx3.4 code for JeeLib Classic and discrete sampling, the setup greeting is:
from
where the current version is 3.4, although there were previous versions starting at 1.1
.
.
.
Looking at the emonTx3.4 code for continuous monitoring and a choice of JeeLib Classic, JeeLib Native or LPL (by a #define statement) the setup greeting is:
from
Sorry @Robert.Wall, I did read it and understood that no further development would be done on JeeLib native, which is entirely acceptable. What I find less so is that my (I think) ‘responsibly’ doing updates to emonSD and emonsms leads one (me) into a non-working system and an apparent cul-de-sac .
The emontx3CM V0.10 would indeed have been a development version, which I willingly tested for you. It worked perfectly, without any significant dropouts for - well - ever. I can’t remember the last time I had to reboot a tx3. I am certain that the data format didn’t change for the production version, so I saw no need to update it. It just worked.
But surely it’s not the emontx3 or emonth that’s the problem? The ONLY thing I have essentially changed to a system that has been happily and reliably working for several years is the emonpi firmware. All I would like to do is have the opportunity to get it back.
I understand your point, but it’s not something of my making. All of a sudden, there was an announcement that LPL library would be used. There was no prior discussion with me, no warning that the powers that be would not proceed with RFM69nTxLib, which I thought was not exactly, shall we say, “considerate”. That’s why there won’t be any further work on it, because apart from yourself and maybe one or two others (I have no means of getting numbers), several weeks of work in proving sketches for all the ‘legacy’ devices and writing it up was completely wasted. This doesn’t mean it won’t work again in your emonPi.
In case you missed this too, here’s the write-up that accompanied the release of the emonPiCM sketch.
The link for installing the sketch still “works”, but it’s a new version, not the original document, so I can’t vouch for it’s usefulness or its accuracy.
You can possibly still find the sketch at the address in this write-up, or here: emonPiFrontEndCM.zip (55.6 KB)
Incidentally, it would be almost trivial to convert RFM69nTxLib to have an option to use the LPL format in its transmitted messages, but it would not receive acknowledgements and therefore not re-transmit the message on failure to receive an acknowledgement.
This could be an option for you if you decide to go with LPL but not risk the penalty of reduced battery life when the RFM needs to go into receive mode and wait for the ACK message.
Ideally, the CM JeeLib Native update choice would be available in the setup/admin/upgrade section of emonCMS, but it isn’t.
And the Docs are missing a section on how to do it manually for the emonPi
An alternative might be to:
Install the Arduino Development System on a computer (I would go for the 1.x legacy version rather than the new 2.x version.
Install Roberts’s source code from the zip file plus any library files that are needed.
Compile the source to make the hex file. Then
Although there are no detailed instructions how to do this for the emonPi in the Docs, there are some instructions that might be useful on github for the RFM2Pi (the old emonBase module).
The RFM2Pi is just an atmega328 processor plus a RFM69 RF module. This is similar to the atmega328 measurement board in an emonPi, but without the power measurement circuitry. The github section “Upgrading RFM69Pi Firmware Direct from the Pi” gives a set of commands which you might be able to adapt for the emonPi:
# Install avrdude, and GPIO auto reset
sudo apt-get update
git clone https://github.com/openenergymonitor/avrdude-rpi.git ~/avrdude-rpi && ~/avrdude-rpi/install
# Grab latest firmware for RFM69Pi and perform the upload via serial
git clone https://github.com/openenergymonitor/RFM2Pi.git
cd RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/
sudo service emonhub stop
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:RFM69CW_RF12_Demo_ATmega328.cpp.hex
sudo service emonhub start
The avrdude stuff may already be installed. You’d have to ignore the git clone part, put your hex file in a directory on the emonPi, and point the avrdude command to it instead of RFM69CW_RF12_Demo_ATmega328.cpp.hex
Ignore the parts about flashing the bootloader, as the atmega328 in your emonPi will already have one installed.
I’ve never tried this and I don’t know if it would work - no warranty!