I have scoured the forums for an hour and not found any answer -forgive me if I’ve missed something obvious!
We have used OEM for ~ 5 years on our church - huge rooms with UFH (‘Nave’ and 'Link; etc) - plus 2 other buildings with rads - gas boilers - no HPs yet.
It works a treat! and lets us see the temperature result of what our evoHome controller is doing.= - both rooms and pipe temperatures
I’d like to add to our graphs the on/off changes - specifically
when the EvoHome controller’s relay goes ON for each Zone (‘Nave manifold’, ‘Link’ etc)
other things go ON/OFF controlled by Shelly devices
So I was thinking - a hardware box that can detect mains/on/off for say 6 lines?
Maybe an emonTH add on and software tweak? Or emonTX with tweaks? What do other folks use?
We use lots of emonTHs -and for many have the software to handle 2 temp sensors per unit (eg boiler Flow+Return sensors use just one emonTH)
Here’s our Dashboard - (there’s a battery down on our ‘UFH flow after pump’ line this week)
You’ve said they’re large rooms. Are all the devices you want to monitor close to each other, or dispersed around the rooms?
What time resolution do you need?
If they are close to together, you could use an emonTX, but that’s quite an expensive way just to monitor on/off. With that, you can average it over the measurement period (default is just under 10 s) and set a threshold to determine between on and off.
If they are spread out, the emonTH would be more appropriate but doesn’t support it out of the box. You would need to have an external binary current sensor (easy enough), but you would be limited to time resolution of about a minute to conserve battery, and it’s only measured at one time point.
Adding to this, as far as I know, there is no specific way of getting a true binary input into emonCMS - you need to feed it a number and then (for display at least) you do at least have a LED widget, but I’ve never had occasion to use it. As a graph, presumably you’d use values 0 and 1, but the gotcha is you’d need to use the variable interval time series feed with the sending device sending the remembered last state plus the time, then a second or two later the new state and the time - so as to show distinctly the on/off transitions on your graphs. (And you then might be able to use an accumulator and call it running time?)
You can use more if you customise the software. There’s no inherent limit, but more will cost in battery life.
I can only ever remember seeing something like this once before, and it was a long time ago - maybe even on the old forum.
It’s going to be worth looking what OneWire devices are available. The temperature input, both emonTx & emonTH, is One-Wire, interrogating the OneWire bus might be a better starting point than most and needs no hardware changes.
None, as far as I can tell. OneWire is used almost exclusively by Analog Devices (after their acquisition of Dallas Semiconductor). You could design your current sense front end to interface through OneWire, but you’d pay a pretty steep price in current consumption (for the emonTH).
The pulse input could be used for this - if it’s just a simple on/off sensor, rectify a CT output with a diode to get a square wave.
Are all the devices you want to monitor close to each other
YES, close together - in 2 locations
What time resolution do you need?
1 minute is fine.
The pulse input could be used for this - if it’s just a simple on/off sensor, rectify a CT output with a diode to get a square wave.
Is the ‘pulse input’ on an emonTH or something else? That circuit sounds simple - but the voltage will be only a few volts (I’m guessing that number…)
Could I send that rectified CT to the emonTH where the temp sensor is now, (suitable resistor bridge?) - but that’ll only give me 1 sensor per emonTH… too pricey.
I’ve been logging mains on/off with emonCMS for a while now, monitoring various pumps alongside the temperatures around our thermal store - boiler, solar hot water, UFH, etc..
I am using a Raspberry Pi Pico board (with WiFi) and mains voltage sensing modules connecting to my local emonCMS system using MQTT - it’s been working well for months now. In order to be able to see the various on/off states on the graphs (when they can be on top of one another) I ‘adjust’ the values slightly, so the first displays as -0.15/1.15, the second as -0.10/1.10 and the third as -0.05/0.05.
I’m in the process of taking my experimental version and building one that I can install in the wiring centre - it will use modules that are mounted on the DIN rails, bought from Ali Express:
Yes, the pulse input is available on the emonTH, it’s just a GPIO pin and there’s 3V3 available as well. The emonTH would be suitable if they are spread out, but given they are all close together something cheaper and more compact (like @mcockerell’s nice setup) would be better.
Each mains sensor uses a single GPIO input (plus Vcc & Gnd); if the existing kit has enough unused inputs then you could probably do without the Pico by modifying the emonTX code.
Also, although I’m showing a single channel mains sensor I’ve been using a 3-channel unit while experimenting (I could only find single channel DIN-mounted units). A quick search on eBay for ‘mains sensor arduino’ will show you what’s available (1-channel, 3-channel & 8-channel).
One thing to bear in mind - with a pull-up on the input, the sensor reads low for ‘On’, high for ‘Off’!
The difficulty here is unless you have an emonTx V2, spare input pins aren’t brought out to accessible places, so only the inputs shown on the schematics are available in practice.
This is a problem I faced when developing emonLibCM for the emonTx V3, so I actually did most of the work on an emonTx V2, where almost every I/O pin is accessible and I could easily toggle output pins at various points in the code so as to check timings etc with a 'scope.
So if my understanding is right - for hardware all I need is
Raspberry Pi Pico board
‘mains sensor arduino’ - from eBay - eg an 8 channel one
( my hardware right now - is emonPI and many emonTHs. ie no emonTX)
What about handling MQTT - I don’t do that now, and folks say don’; run that on the same Pi as eMonPi: so does your microPython handle that and feed eMonPI with ‘the format it wants’ ?
Yes, that’s correct - you need a Pi Pico W board so that you have WiFi to connect to the emonPi.
I have chosen to use a breakout board which gives me screw terminals to connect to the Pico - you can see that in the DIN module. This is type that I use for experimental work, it also has mounting holes so it can be fitted into a small box:
I’m pretty sure that I got these on Amazon, but you can probably find something similar elsewhere by Googling ‘pico breakout board’. If you choose to do the same you will need a Pico W board with headers to plug it into the breakout board.
If you have 6 mains circuits that you wish to monitor you might prefer to use 2 x 3-channel modules - the 3-channel module also has screw terminals for the GPIO, the 8-channel has a set of pins for the Vcc/Gnd/GPIO connections. I mounted the mains sensor board in a separate box to keep the mains voltage away from the Pico.
I’m running an emonSD image on a Raspberry Pi 2, which I believe is equivalent to an emonPi. It runs an MQTT server as standard, and this is used to route data from the CTs to emonCMS - the Pico code publishes the sensor data to the MQTT server in the same way and it then appears in the list of feeds.
Currently I adjust the on/off values in emonCMS, I’ve just noticed that there’s a typo in my earlier posting - the third sensor uses -0.05/1.05. This adjustment could probably be done in the Pico code instead. My code includes a web server running on the Pico which allows me to see the raw values being collected - I’ll tidy it up a little and hopefully post it here later today.
To clarify, not quite true now, although it was a while ago. I run emonCMS on a Raspberry Pi 2 Model B Rev 1.1 - 1GB (Sony UK) which doesn’t even have Wi-Fi - I use the original Edimax dongle, with no problem, except it’s a bit slow showing a graph covering a long period of time.
The modern emonPi2 comes with either a RaspberryPi Zero 2W (WiFi only, no external USB ports) or a RaspberryPi 4B (with WiFi, Ethernet & external USB ports).
Here you go; I’m currently using Micopython 1.22.2, but newer versions should be OK.
There are 4 files in the attached zip archive, they all need to be present on the Pico filesystem.
You will need to configure a few things near the top of main.py:
Your username, password and topic for the emonCMS MQTT server - the username/password may not need changing.
Below that you will see where you define your sensors (sensor = …) - define as many as you need.
You will also need to define some network details near the top of mqtt_local.py; the sample code that I based this on was set-up this way, I may try to move it into the main file later.
Once you’ve set everything up correctly it should run automatically when power is applied.
I’ve left the web server code in; when it starts up it prints out the address that it’s using.
Do come back to me if you are having problems, I should be able to help. Mains Sensor.zip (15.3 KB)
I have done this for a while using a PiZero-W and some home made opto isolators. The mains powered zone vales and pump have connections to some neon indicators which point at photo diodes inside some heatshrink. I use a simple 4093 comparitor to change the digitals of the PI.
Photo shows it all in my airing cupboard, the compaitor is on the piece of Vero board you can see.
On the PI I have a very simple python script that makes an API call to the main emon over the network. This saves having to set up MQQT etc.
Attached the code. This runs as a Linux service but if you only want to log every minute you could edit to call it as a cron job.
There are probably easier ways, but it was a lockdown project when there were few places to get bits open so I made it from what was available in the garage. I am also always a bit wary of connecting anything from Ebay/Amazon/Ali etc to the mains in my house!
If it’s just the digitals a Microcontroller is perhaps better than a PI, my PI also gets the serial feed from my immersion diverter power meter, calls external API’s etc. I have done similar using the API with £6 ESP32’s from ebay elsewhere in the house to measure temperatures.
I’m doing a lot more than just digital inputs with the Pico that I am running; it is also reading a number of temperatures in and around the thermal store using DS18B20 One-Wire sensors, and processing the logging data from our solar hot water controller which is received over RS-485.
I chose to use a Pico with Micropython as there were a number of standard libraries available that considerably simplified the implementation, including running everything as async tasks. Fortunately I didn’t need the complexity of a full Linux system for this project, but I appreciate that sometimes you have to work with what you have available - as it happens I had a Pico W!
I’ve updated the code so that all of the configuration is now done in main.py and mqtt_local.py is no longer required: Mains Sensor-20250323.zip (14.7 KB)
There’s now also a configuration option to adjust the on/off values before sending them to emonCMS - with doAdjust=True (as supplied) each sensor on/off value is spaced 0.05 away from the previous one so that the lines don’t all merge on a graph (as previously described).
With doAdjust=False all sensors use the values 0 and 1 - the choice is yours. (This is an enhancement, currently I tweak the values individually in emonCMS as I log the feeds.)
I wonder what the internals are…
