I have an Altecnic Procyl that I’d like to monitor. It’s a Heat Interface Unit (HIU) to a heat network, with a built-in hot water cylinder. It has a built-in heat meter with M-Bus, that I’m already monitoring and logging (not using EmonPi/EmonCMS). However I can’t tell the difference between heat used for DHW (hot water) and for heating (CH).
The Procyl has a built-in controller which switches a diverter valve between heating and hot water. I think this runs on 240V. I could monitor this with a relay (230V coil, switching 5V) or opto-isolator. I found a few relays, but haven’t found a good pre-built opto-isolator except this 8 channel universal input which attaches directly to a Pi’s I2C bus (and thus probably not physically compatible with an EmonPi in its case).
To avoid modifying my Pi hardware, I was thinking about using a relay with the single GPIO on the RJ45 port. However I think this is connected to the ATmega328 (A6/D20) so I’d still need to:
Modify the sketch programmed into the ATmega328 (src.ino?), to send the data to the Pi over the JeeLabs link, as an additional field in PayloadTX.
modify EmonHub to understand the modified payload, split out the additional field and post it to MQTT.
modify/configure EmonCMS to understand the new channel being broadcast to MQTT.
Does that all sound reasonable?
I was wondering whether it makes sense to make these changes part of the standard EmonPi firmware, so that the GPIO is usable as a digital input, out of the box?
Maybe I’m over-engineering this, and I should just connect the relay output (5V) to a USB GPIO attached to my existing monitoring system, and poll it using the Python code that I already have for reading the M-Bus meters? But I would also like to monitor the temperature in the hot water cylinder, for which I’d need a one-wire interface, so perhaps an Arduino can do both?
The RJ45 already has the One-wire bus, and the front end processor has the maths to read and report temperature(s), so if that is already in use, extend the bus - maybe add provision for the extra sensor - but changes can be problematical as the front end’s sketch is easily overwritten when you update emonCMS, which could destroy your changes.
I’m not a Pi expert, but I think the generally recommended way to sense the valve position would be to use the Pi’s GPIO, in much the same way as you can add a second pulse count, and the code to make sense of it. This link might help you: Pulse monitoring on a Pi - #3 by pb66
Against that is, the pulse input is already on the RJ45 as you say, and requires the pulse counting code removing and replacing with a straightforward “steady-state” read of the input pin. It might well be preferable to combine the two in a single changed sketch for the front end '328P. The sketch is split across numerous files - not altogether logically split in some instances, so while you’re working on the changes, my advice would be the throw the lot into a single file, even if you split it back into the constituent parts later (but there’s no need - it compiles into one whichever way the source is arranged).
If the valve position is part of the serial data packet from the front end to the Pi and emonHub, it will simply appear in emonCMS (with a minor change to emonhub.conf) as another input from the emonPi.
Point taken about overwriting the 328’s firmware, I’d forgotten about that. I guess that makes it even more valuable for the default image to be flexible (e.g. incorporate the proposed changes).
I could override the pulse counting input, but then it wouldn’t be usable as a normal EmonPi. I was thinking of using the ADC6/D20 line (pin 8) on the RJ45 socket, which is connected to the 328 but not accessible to the Pi at the moment. I think we could make it so without breaking backwards compatibility. What do you think?
I don’t see why not - poll it in the main loop and then write out the position however you see fit as part of the data packet - and of course change emonhub.conf to suit.
You might like to think about what you do if the valve position can change and change back in between reporting the value.
Exactly how you incorporate this depends on whether you have the ‘old’ discrete-sample emonPi or the new CM software, but whichever, the principle remains the same. I wouldn’t worry about the rest of the world, your front-end sketch is going to be particular to you - all you need to worry about is not overwriting it when the emonPi updates.