Archived Forum

Where does the solar inverter feed into your electricity distribution system?
And what exactly do you want to monitor, if anything, apart from the solar infeed?

The grid supply enters and goes directly to the main consumer unit in the house.  An MCB feeds the supply to the garage, where there is another consumer unit.  The inverter is connected to an MCB in this subsidiary consumer unit. Other MCBs feed other demands.  It's like type 2 in the sense that consumption cannot be measured separately.

I'd like to monitor (a) generation,  (b) total consumption and (c) nett consumption/contribution from/to the grid.  Ideally I'd like to be in a position to divert surplus generation into another load, but this is a future project.

As I understand it, one potential approach would be to

• measure "(c)" adjacent to the master consumer unit, using an emonTx with an AC/AC converter
• measure "(a)" with another emonTx adjacent to the generation meter
• work out "(b)" from the other measurements in some other computer, e.g., in an EmonLCD or a base station.  It's an open question whether I can site a base station somewhere where the radio signals from the emonTxs can both reach it.

What is a sensible limit to the length of the cable from the current clamp to the emonTx?

Thanks for your help.

From that, I assume that the "other demands" in the garage are significant, If they were not, then the easy solution would have been to measure the garage feed, but you'd clearly thought about that.

I've never tried a 60 m CT cable run, I've done around 10 m, using twin twisted screened pair ("microphone") cable, earthing the screen only at the CT end. I've not done the sums on phase shift due to cable capacitance at around 100 pF/m, but as the system impedance is around 100 Ω, I wasn't going to bother either! Sensitivity doesn't come into consideration (except as a second-order effect) as the CT is a current, not voltage, source. 60 m ought to be do-able if there are no serious sources of interference.

If Paul (pb66) can confirm that a Raspberry Pi and EmonHub can get data from the LAN, what about something like an Ethernet-equipped Arduino and emonTx Shield in the garage to measure generation?

If you're thinking of a diverter, what you're generating doesn't actually matter, all you need to measure is the nett power at the grid connection. (Because the diverter trims the dump load to give nett zero import/export whenever it can.)

Lots of good ideas here.  Thanks.

Looking at the code for EmonHub, there is indeed a facility to receive data over the LAN.  There's an Interfacer called EmonHubSocketInterfacer which can receive standard ASCII representations of packets in the format "NodeID val1 val2 ...\r\n" or "timestamp NodeID val1 val2" over TCP/IP.  I think it should be configured like this

[interfacers]
# This interfacer manages my LAN comms
[[LANcomms]]
    Type = EmonHubSocketInterfacer
    [[[init_settings]]]
        port_nb = 50022
    [[[runtimesettings]]]
        timestamped = false

Then to submit a value (for test purposes for example, or maybe from a script), to submit a reading of one value "440" from node 11 to the emonBase running at address 192.168.0.1, one could use:

% echo -e "11 440\r\n" | nc 192.168.0.1 50022

If using say and Arduino Uno and an EmonTx shield then this would be done in code instead.  A fair degree of trial and error would probably be required. 

Sorry, I managed to miss this thread somehow. 

Yes (as you have now discovered yourself) emonhub can accept data via a socket from the LAN, there are a couple of discusions happening at the moment which inspired me to start the 'emonhub modules "sandbox" thread' it sounds like you are well versed in this area so please feel free to pass comment, 

Also see this thread on creating and using an EmonHubSocketInterfacer thread, I will also link a couple of other example threads.

I hadn't thought of sending values from script as you suggest, that open a whole new avenue of thought thanks for that.

Paul

this echo should do the same as well.. 

echo -e "11 440\r\n" > /dev/tcp/192.168.0.1/50022

Linux - don't know about other OS's

Thanks for the one-liners, tried both and found they both work although the newline isn't needed, just the return.

echo -e "11 440\r" | nc 192.168.0.1 50022

echo -e "11 440\r" > /dev/tcp/192.168.0.1/50022

both work, but only on the local machine (which is all we want here) as do both of these which simplify it further.

echo -e "11 440\r" | nc localhost 50022

echo -e "11 440\r" > /dev/tcp/localhost/50022

This makes life much easier eg it negates the need to initiate a script when using cron to send a value at a set time, the command and values can be added directly to crontab. fantastic!

Paul

EDIT - Not meaning to hijack your thread, but just for the sake of completeness, I tried running directly from a crontab entry and found you need to force "bash" using a complete path rather than let crontab default to "sh" for example to run at midnight every night you would use

00 00 * * * * * * /bin/bash -c 'echo -e "11 440\r" > /dev/tcp/localhost/50022'

Yes, that /dev/tcp stuff is all bash trickery.  They've coded it to make it look like you're redirecting to a device node, but if you check there is no /dev/tcp/...    bash parses all that and manages the network connections internally.   Piping into nc is for real though, and so works with any shell.  For even more flexibility, consider socat rather than nc.

Thanks for the feedback and links! I'll look into them.

General description of my setup

I have a commercial RHI biomass system (a pellet boiler).  To monitor this, I have a RPi in the garage already, receiving radio from an EmonTx dedicated to monitoring the pellet boiler's auger motor. The EmonTx is running a very custom script to accurately measure the auger on-times, and I don't think I can add a current measurement without screwing up the loop timing.  So, I may add another EmonTx there to measure the solar generation (and add a few temperature sensors I'd like to have there too, on the hot water store and maybe on the demand circuits).  That would feed data into the existing Rpi.  The I would add another EmonTx near the consumer unit in the house (measuring overall consumption, and maybe one day doing divert, but see note below, and perhaps measuring some subcircuits like lights and individual ring mains). Then I have to decide what would receive the radio data from that, given that it's too far away for radio to reach the garage (though I could go the Ethernet Arduino + EmonTx shield route). Probably a second Rpi in the house receiving signals from room EmonTHs (or a long string of oneWire temp sensors?). 

The Gararge RPi also runs a script and some software derived from libmbus to read the data from the heat meter and that gets fed into emonCMS.  I'd be happy to share this code if people are interested.

I have two emonCMS servers.  One is in the garage's RPi, and one is on my main Linux server.  I do it this way so that the RPi can run without writing values to the FLASH (having learnt the hard way what happens if you do that) and also because the Linux machine runs nice and fast and provides a slicker response to my browser.

So, given all that, I now think I may not need to use the EmonHubSocketInterfacer, because my existing Garage RPi can receive the generation readings and my Linux machine's emonCMS can do the calculations based on local and remotely generated feeds!

Note on solar diversion in my case

I have a problem coming up with a sensible load to divert power into.  Sure, I have a couple of water tanks with immersion heaters.  The problem is that the pellet boiler commercial RHI is so generous that there is absolutely no economic benefit to me to generate hot water from excess electrical generation. Battery systems don't seem viable as a store-and-use-later approach.  If I had an electric car to charge, that would make sense. So it almost seems best to let that power go back into the grid.

"(or a long string of oneWire temp sensors?). "

Generally, this doesn't seem to be a good idea, unless you use the dedicated driver IC.