I’ve been watching Open Energy Monitor from the sidelines ever since seeing one of your boards at CAT a couple of years ago ; since then I’ve installed a CTC GSHP and have been contemplating installing some further monitoring.
Sadly I never installed a heat meter at install time and because this is a dual hp system and it’s particular configuration, adding one in won’t be trivial so I think initially im discounting that which is a shame. What I really want to do though is to monitor temperatures everywhere (pumps, buffer, DHW tank, 3x manifolds…) to see how my systems working and where heat losses in the system as a whole are i.e. quite a few more locations than a typical system, Id estimate maybe 15 locations total as well as current monitoring for both pumps (maybe long term adding in my grid / solar / AC battery too)
So questions are :
Can one even achieve this with open energy monitor as it stands?
Im trying to work out what hardware I need to start with and am scratching my head trying to work out the relationship between emonbase, emontx, emonpi etc.
the three manifolds (1x ufh, 2x whr) are in different physical locations to the heat pump - is the model that one should use multiple open energy monitor hardware wirelessly from these locations, or run cat5 back to the plant room?
One of the hats I wear is embedded systems engineering so comfortable & happy to get my hands dirty making changes & contributing back with firmware (and hardware potentially)
I’ll try to fill you in on this, but it’s all-change at present, provoked by the chip shortage of a year or two ago.
First there was the emonTx V2 - a through-hole DIY kit that sent data by radio to another through-hole DIY kit - a NanodeRF which was the base station and connected to a ‘cloud’ emonCMS by Ethernet. You could also have a local liquid crystal display, the emonGLCD - receiving its data directly from the emonTx.
Then came the emonTx V3, factory assembled, with 4 current and one voltage input (so 4 powers measurable) and the base station became a radio receiver attached to a Raspberry Pi. Then came a stripped down 2-channel emonTx and Raspberry Pi all in one box - the emonPi. Then the chip shortage and the emonPi and emonTx V3 ceased production and the emonTx4 was born. So the present state is:
The emonTx4 is a 6 or 12 channel power measuring ‘node’ which sends data somewhere. ‘Somewhere’ can be by UHF radio to an emonBase (still the RPi + radio receiver), or by USB to a RPi, or with a Wi-Fi add-on directly into your LAN and to the emonBase that way or to the ‘cloud’ emonCMS.
The obsolete (for now) emonPi is as I described - a cut-down everything in one box.
You didn’t mention the emonTH - a battery-powered temperature sensor that transmits by UHF radio to the emonPi or emonBase.
Thanks for that & the perspective - that sounds like it might be a good idea in the first instance to have a play. I think ideally longer term I don’t want to stray too far from what’s standard as I’d like to build upon what’s there already - and longer term I’d like to add power and potentially heat-monitor too. Was there any reason you used the Wemos board over a standard ESP or something else or was it just what you had to hand?
WEMOS is a pretty standard ESP (that is just the chip). It is cheap and just works (get a genuine one).
As I said, the OEM kit is not really designed for multiple temperature sensors; a couple yes, but more than that it will get unhappy. WEMOS/Tasmota combo will read a maximum of 8 quite happily at 10s intervals. I do though process the data in Node-RED for simplicity (for me). I could probably do it on the board in Tasmota but never needed to
I connect everything up via plugs and sockets, so if you need to swap something you can. Desoldering is a PITA.
Thanks for the info & breakdown, much appreciated. So I guess that for my purposes initially there’s no particular reason to use the pre-built hardware initially as Brian suggests for now? Moving forwards I can see that there’s an emonpi2 mentioned as in development - is that likely to be the future replacement for emonbase and then using the tx / th as remote sensors to it? I had a look but I couldnt see any work in progress specs or schematics for the emonpi2?
WRT the devices reading temps - given that it’s 1-wire I assume there are no (hardware) limitations to using more sensors on the bus and that 6x is just an arbirtrary software limit in the firmware build? I was reading about your problems with 1-wire timing due to bit-banging elsewhere, I imagine one could just use something like a DS2484 to solve that?
Ah, OK - that’s good then as I’ve got about 10 different ESP32 variants kicking around on my hardware shelf doing nothing so would be good to put to use! Ive not looked at Tasmota so will have to have a look…
Not a replacement, but an addition to the range - the advantage being it will, like its predecessor, include power measurement capability in addition to being its own “base” as well as being a base (running emonCMS of course) for any thing else that can talk to it.
The intention is to migrate the 1-wire temperature measurement to the RPi, hence I ignored temperature measurement completely when I was writing emonLibDB for the emonTx4 - it’s just not possible to do precise energy measurement and hang around processing a relatively snails pace serial pulse train that requires precise timing in the same processor.
If you dedicate a processor to the 1-wire bus, you can have lots of sensors, even more with their proper line drivers like you say.
The intention is to migrate the 1-wire temperature measurement to the RPi, hence I ignored temperature measurement completely when I was writing emonLibDB for the emonTx4 - it’s just not possible to do precise energy measurement and hang around processing a relatively snails pace serial pulse train that requires precise timing in the same processor.
If you dedicate a processor to the 1-wire bus, you can have lots of sensors, even more with their proper line drivers like you say.
I think you’re misunderstanding my suggestion as the DS2484 isn’t a line driver and would solve this for you - Ill reply on the 1.5.7 thread where I saw the original analysis as it would make more sense to reply there.
@pev - when quoting, please select the text to quote, then click the little popup that appears. It will then correctly attribute the quoted text to the poster and alert them that you have quoted something of yours. You can start a post, select more text from any thread, and click quote.
e.g.
It looks like you just copied and pasted and it looks as if you are replying to me, when in fact you are replying to @Robert.Wall
Ah sorry, that’s odd, I just hit reply pasted the text, selected and pressed the quote button - not quite sure how it decided to connect to you? In the ascii it purely added a “>” to the text rather than any attribution…
The two “Reply” buttons are different. The one inside the post attaches the reply to the post, the one at the bottom of the page isn’t really a reply, but a general post on the topic.
Without touching a “Reply” button, when you highlight the text you want to quote and then click “Quote”, it will open the reply text, paste the quote and attribute it. Viz:
I think it’s universal within Discourse - the software we use.
As it looks as if you wanted to reply to me - I ignored it as you’d responded to Brian - I regard the DS2484 as more suited to driving the bus than a processor’s DIO pin - because it controls the pull-up etc.
If you want the attention of @glyn.hudson & @TrystanLea, who are in charge of development (and everything), this is how to do it.
