I have several emonPi boxes and I’d like to use one of them to collect data from two water meters with pulse outputs. I figured the easiest way (without hardware mods) would be using the 1-wire bus, so I ordered a couple of ersatz DS2423 boards. I know I’ll need to modify the Arduino firmware on the emonPi to recognise and collect data from this device, and probably make other changes to the system to collect the jeelib packets and submit their data to emoncms. I have done some Arduino development but I’m fairly novice and I would really appreciate some help.
I’ve followed the instructions here to install what seemed like the correct subset of libraries (I already had the IDE). I changed the radio format to RFM69_JEELIB_CLASSIC for compatibility with my existing devices (not that it matters in this case) and to resolve a compile error (missing RFM69.h). But now it can’t find LiquidCrystal_I2C.h. This doesn’t seem to be a standard Arduino library and there are several versions floating around on the Internet. Which one should I use, and how come this isn’t documented on the libraries page?
Thanks for the suggestion, but there are several reasons why not to use a pulse interfacer:
Unfortunately it needs to be an ADC pin, or at least have configurable thresholds, as the water meter is already connected to a heat meter with its own pull-ups, which I don’t want to disturb. So the voltage won’t vary between 0V and 5V exactly, more likely between 0.1V and 3.6V.
I think the pulses might be quite short and I don’t really want to have a Python script spinning in a tight loop all time time, polling a pin.
I don’t think the Pi’s GPIOs are exposed anyway, but two are from the Arduino, along with the 1-wire bus. To use the Pi, I’d have to open the case and attach cables directly to its board, which I’d rather not do if I can avoid it.
The last of these also applies to the DS18B20/one-wire interfacer, although that does suit me better than a direct pulse counter.
Since I don’t need the CTs, maybe I could use those as analog inputs for voltage sensing if they can tolerate 3.7V, but I’m not sure if they can, and I suspect that the burden resistor will draw too much current and affect the heat meter’s operation.
I’me quite sure that wouldn’t work with the hardware as it comes - as you point out the burden will present a very heavy load on the wire you’re monitoring, plus the bias voltage will pull it to 1.65 V, and still the input can only tolerate 3.3 V.
But you could use the input, if you stripped away those components (the burden, bias resistors and capacitor), but you’d still need to poll the input as you can’t connect the interrupt to an analogue pin. You’d also need to divide the 3.7 V down, but that’s easy enough with a pair of resistors as a voltage divider.
I had trouble compiling the new continuous monitoring firmware (emonPi_CM) with the RFM69_JEELIB_CLASSIC RadioFormat, which I think is required to communicate with my existing emonTH and emonTx devices. Line 73 says:
which assumes that a template class called RF69 exists. However RF69.h in JeeLib is a namespace, not a class. In the end I found this class in a JeeLabs project called Embello, and I replaced my JeeLib.h, RF69.h and spi.h#includes with references to that project, and it compiled, but I have no idea if that was the right thing to do (I haven’t tested it yet).
@TrystanLea Is this configuration tested or expected to work? Do the docs need updating with different libraries for the CM firmware?
As far as I’m aware, the information in the original emonPiCM release post in this forum (“The emonPiCM”) is accurate. That’s what I have and it used to compile for me (with the Arduino IDE I’m using). If you got your information and downloads from elsewhere, it might not be right.
The emonPi CM will not work reliably with the Classic JeeLib library, you can expect only about 20% of the messages to get through without corruption. This is why the RFM69 Native message format, utilising the properties of the RFM 69, was written, as explained in that release. I have had it working here continuously for about 2 years.
Thanks @borpin, that page is very helpful! I will need to be able to compile the firmware in order to modify it to support the new one-wire device (DS24243 pulse counter), so precompiled firmware may not help me much.
@Robert.Wall is the problem of incompatibility between emonPiCM and the classic format caused by the microcontroller being too busy doing continuous monitoring to read data from the RFM69 character-by-character, fast enough to avoid corruption due to buffer overflow (and thus lost data)? And the new formats (native and LowPowerLabs) help by being compatible with the RFM69’s hardware-supported frame format, so we can offload framing to the RFM69 and read a frame at a time from it, instead of character by character?
I’m completely new to this debate and information, and I may have misunderstood the various information sources I’ve collected this from.
If so, then it’s impossible to reliably use my existing emonTHs with an emonPi running the new emonPiCM firmware?