Community
OpenEnergyMonitor

Community

What hardware for remote meter?


(Dave Howorth) #1

Hello, I’m looking to decide what hardware to buy for my situation. My 100A single phase supply is metered at my garage, which is 30-40 m from my house. I want to measure the net supply and there is also a car charging point in the garage that I’d like to be able to monitor. We have solar panels on the roof of the house, with Enphase microinverters, and I’d like to monitor the generation. I also have one of Robin Emley’s diverters and would like to monitor how much energy we divert, as well as general household consumption (which I presume I could deduce from the other readings?). I’d also like to monitor the temperature at various levels in my thermal store (I already have some DS18B20 that I can daisy chain).

My phone says there is a ‘poor’ wifi signal in the garage. What are my options, please?


(Robert Wall) #2

This is quite tricky.

The ‘obvious’ solution is an emonPi in the house, measuring the PV array and diverted energy, and an emonTx in the garage measuring the grid connection and the car charger. Unless there are many or thick walls in the way, or a strong interfering signal, the 433 MHz link should work over 30 - 40 m. This would get around the poor WiFi problem.

I assume you’re using Robin’s own pcb, and not his software on an Arduino/emonTx with an add-on triac switch. Do you have the radio module (RFM12B or RFM69CW) fitted?
The ‘burst’ nature of Robin’s diverter means that the “discrete sample” sketch, the default in both the emonTx and emonPi, won’t read the diverted power particularly accurately, and in turn that’s going to cause inaccuracies all along the line. EmonLibCM will solve that problem, but while it’s on test now in the emonTx, no attempt has yet been made to integrate it into the emonPi. In the short term, the inaccuracy will be significant, but over time, it should even out.
If you have the radio module, then it will send power and the total diverted energy. That will get around the inaccuracy problem at the house end, but it will still be there (but partly swamped by the more constant loads) in the grid connection.

You could run a cable to the garage. Only yesterday, we got a report of a Canadian friend using CAT 5 cable over a longer distance than yours. You could then have an emonTx (2 cable inputs from the garage, PV and immersion from the house) and emonBase all in the house.

In the long term, I’d hope to be able to say that both emonPi and emonTx will have the continuous monitoring software that will remove the problem. It will certainly be available, and hopefully very soon, for the emonTx, but there might be problems with the emonPi.

The temperature monitoring should not pose a problem, both emonTx and emonPi will accept those sensors.


(Bill Thomson) #3

Robin has a diverter configuration that will measure the diverted energy, and if desired, display it on an optional 7-segment readout. (I have one of his prototypes)


(Dave Howorth) #4

Robert, Thanks for your detailed reply. I am using Robin’s PCB, yes. I don’t have the radio module (at the time I was considering customising the unit to divert to a lot of loads so opted for more free IO pins).

I’m tempted by the emonPi emonTx RF combination. I could run a cable but it would mean more faff.

Bill, Thanks. I have a 7-segment readout, but it shows energy rather than power. I’m interested in logging rather than display in any case. I currently log by writing the content of the display in a little book every day and then typing it into a spreadsheet! That’s what I’m trying to improve.


(Bill Thomson) #5

Ya caught me nappin’. I wrote power when I should’ve written energy. :wink:
Post corrected.


(Dave Howorth) #6

It’s been a while and I’ve managed to procrastinate until now, but I started looking at this subject again. On reflection I’m not sure an emonPi is the best solution for the house because it only accepts 2 CTs, IIUC, which will be used immediately by the PV generation and diversion, leaving me nothing spare to monitor anything else. So I looked at alternatives and it seems that a second emonTx would give me extra flexibility and I would need an emonBase as well but the total cost seems to work out similarly. Is that correct and/or sensible?

BTW, has the emonTx software had an upgrade to handle Robin’s bursty power consumption?

One extra question. I will want to connect an optical meter sensor to each emonTx as well as some DS18B20 and I gather I can connect them all to the single RJ45 connector (is the optical sensor 1-wire as well?) but I’m not clear on the exact wiring required, nor on the simplest method of making the connections (i.e. what parts do I need to be able to plug everything together or do I need to cut connectors off a wire up a new RJ45 connector?)

I also saw something that suggested an emonTx can handle six DS18B20. That seems like a strange maximum for a 1-wire string. Is it a software limit or what?


(Robert Wall) #7

Neither. :smile:
Your emonPi will receive data from an emonTx, so no need for the emonBase - unless of course the emonTx and emonPi aren’t able to communicate because the radio signal is attenuated too much.

A “Continuous Monitoring” sketch is being soak tested at present, hopefully it will pass and can be released before too long.

Yes you can, but no it isn’t. The One-wire and pulse inputs are on different pins.

See this:

That’s the pre-programmed size of the array in the sketch. If you need more, you can edit it, but then you’ll need to follow that change through the signal chain into emonHub. Eventually, there’s a limit on the size of the radio packet, imposed by JeeLib.

You can only have one DS18B20 with the 3-phase sketch because there simply isn’t time to receive the data from any more, without losing phase lock.


(Dave Howorth) #8

Sorry, I don’t think I explained myself very well. :disappointed:

My intention is to replace the emonPi with an emonTx plus emonBase combination and it was the wisdom of that I was asking about.

Thanks for the rest of the explanations. :smile:


(Robert Wall) #9

That’s what made me think you didn’t appreciate that the emonPi could receive.

In essence, the emonPi is an emonBase with an LCD display and a 2-channel cut down emonTx all in the same case.

So the various combinations:
EmonPi: 2 current channels, one pulse input and one 1-wire input, LCD display & case.
EmonPi + emonTx: 2 + 4 current channels, 1+1 pulse input and 1+1 1-wire input. Both units cased.
emonTx + emonBase: 4 current channels, one pulse input and one 1-wire input, no LCD display & no case.

If all the places you need to monitor are located close to each other, it’s down to a matter of how many inputs you need. If 2<n≤4, it’s emonBase + emonTx; if 4<n≤6, it’s emonPi + emonTx; and so on – you’re not restricted to one emonTx with either the emonPi or emonBase.


(Dave Howorth) #10

Thanks Robert. So I do think I want 2 off emonTx plus 1 off emonBase (one Tx in the garage with the main incoming meter, the other Tx and Base in the house by the CU and solar meter).

I found the wiki page about the emonTx; that’s very helpful. It leaves me with a question about the DS18B20 connection. I can live with a limit of a string of six on my thermal store, I think, but I gather the standard firmware won’t let me wire more than one to the screw terminals. I also gather I will need the Continuous Monitoring sketch because of the type of diverter but I’m not clear whether that can also handle a string of DS18B20? The wiki page just says ‘this will require changes to the pre-installed emonTx firmware’ but doesn’t give any hint as to how to do this.

Oh, and there’s a broken link warning on the link to http://openenergymonitor.org/emon/pvdiversion/pll


(Robert Wall) #11

Not true. The RJ45 and the screw terminals are in parallel as far as the signal is concerned. They differ in that the terminal block has a switched power supply to the sensors. The terminal block itself can’t accept many wires, but you can easily connect them at another terminal block or whatever. If there’s any distance involved, they’re better daisy-chained. I don’t know the limit on distance - it depends on the cable. If you have a problem, there are specialised ICs available to terminate the 1-wire bus, and those enable more sensors and much greater distances.

The CM sketch should work with many sensors, I’ve only tested it with 3 or 4.

From where?


(Dave Howorth) #12

Sorry the link text is ’ PV energy Diversion’ on the wiki page.

The firmware restriction is ’ The default firmware (discrete sampling) supports auto-detecting one DS18B20 sensor . Multiple DS18B20s can be daisy-chained, but this will require changes to the pre-installed emonTx firmware’. Specifically the second sentence. But if the CM sketch can handle multiple that’s fine.


(Robert Wall) #13

Thanks for pointing those out.

Looking at the source on Github, that’s wrong.

@Gwil It looks as if https://wiki.openenergymonitor.org/index.php/EmonTx_V3.4#Temperature_Monitoring
is wrong:
Extended Operation
Temperature Monitoring
A DS18B20 digital temperature sensor can easily be connected to the emonTx V3 by connecting the sensor to the emonTx V3 screw terminal block or RJ45 connector. The default firmware (discrete sampling) supports auto-detecting one DS18B20 sensor. Multiple DS18B20s can be daisy-chained, but this will require changes to the pre-installed emonTx firmware…
It looks like MaxOnewire=6, not one, from the code.
The a.c. adapter power supply was designed to only support the additional current demanded by one sensor at minimum supply voltage, but that’s not the same as the sketch only supports one sensor.

Also, the dead link is just above the heading:

Standard Operation

CT Energy Monitoring