Archived Forum

I had the same question.   In my case I've shortened my emonTx transmission interval, but my feed still seemed to record every 10 seconds.    I was wondering how I could record the history more finely so that I can pick up the current spikes as some devices turn on.  (With a 10 sec interval it appears the spikes are picked up rarely.)  I was curious about that both academically and to help me better chose a backup power generator.

Here's what I've discovered.

On the "Nodes" page, if you/I configure "log to feed" with the "fixed interval, no averaging FINA", we will have the data logged every n seconds even if the emonTx is feeding more frequently than that.  (Where n is the value you specify in the UI.  I don't yet know where that interval value is stored.)  OTOH, if we feed with "variable interval, no averaging PHPTIMESERIES", the data seems to log at the rate that it comes in, but still apparently not with a resolution finer than 1.0 second.  You can view that by clicking on an eye icon on the Feeds page.   Lower on the graph page, you can click on "Show CSV Output".   You'll also want to set the interval field above to 0, uncheck "Skip missing" and "Limit interval" and click "Resend".

Thanks very much for replying, I had assumed that if I was way out with my assumptions that hopefully someone would put me right, but it's very nice to have a positive reply.

So, having had that confirmed, thanks again, that's it - I'm going to cut my interval down to 5 seconds and try to catch a few more of those spikes and peaks, much the same as yourself, so that it'll spot the kettle going on a bit quicker, etc. And then my thyristor control system can react quicker to limit any power being delivered to my immersion heater - I might save a few pence :-)

Nonetheless, from a recording point of view I have found the recording of my real power usage by the emoncms time series to be staggeringly accurate, when I compare it with my "actual" usage as shown my regular meter readings for my power supply company - and that's with a 10 second interval.

It's all a lovely game!  Cheers, and thanks again for the information.

I've finally got round to doing this. I've shortened my transmission interval from the emonTX v2.2 to around 5 seconds and have also changed the way of calculating the solar power to noting the interval between pulses and calculating the solar power from that, rather than my previous method of using the number of pulses per interval as the basis of the calculation. Also now sending the number of pulses to emoncms as an ever increasing number to be used in the wh accumulator process.

I've had to use long integers in the emonTX sketch for these time intervals, otherwise they overflow very quickly on dull days and also zeroise the total pulse count as it goes negative at 32767.

It's working great. Have fun.

I've just noticed a sentence in your post above, Eric: "And then my thyristor control system can react quicker to limit any power being delivered to my immersion heater"

Just for information, the energy diverters by MartinR and Robin Emley react just a little bit faster than your 5 or 10 s, they react on the next mains cycle, and given a compatible tariff meter, they can trim the immersion heater power so that absolutely no energy is unnecessarily returned to the supply network.

Thanks for your reply Robert, it's really nice to hear from somebody who knows where I'm coming from. I'm afraid I sometimes bore the whatsisname out of some of the guys down the pub.

It's not so much a limitation of the Eurotherm 425A that I'm using that limits my control intervals, it's the way my system is set up really. The emonTX sits by the consumer unit downstairs, as you'd expect, and sends the wireless signal upstairs to a pi with a rfm12pi v2 attached. My immersion heater is powered from the linen cupboard upstairs, so the option of controlling it directly in the downstairs cupboard wasn't available.

So, a bash script looks at the emonhub log on the pi upstairs as each record arrives, and drives a DAC that controls the Eurotherm with 0-5v (actually I only use 0 - 3.3v) as it figures out how much power it can divert, given the amount of "spare" power. The Eurotherm sits in a metal box, in the airing cupboard wired into the immersion heater power supply.

I've been a bit self indulgent with this control script; it's parameters are alterable on the fly so I can "tune" it whilst it's working, and among other things, it sends me emails as it starts up in the morning and shuts down at sunset. It would be lovely if I could communicate with the emonTX so I could alter it's parameters on the fly too.

I could up the frequency until the bash script was fully committed, I reckon every 1 or 2 seconds would be the limit, but I'm aware that if I increase the frequency it'll up my traffic volume to emoncms, and maybe that would be a bit antisocial?

Thanks for your comments Robert, and prompting me think about it again, it's all good fun!

Are you talking about emoncms.org? That would not only be antisocial, but it wouldn't work because Trystan has a rate limiter on it to allow everyone a fair crack of the whip. But surely you can work your script so that it sends commands every second or less, but aggregates the data and sends that to emoncms.org every 10 or 20 s?

And the emonTx can accept input over the radio, it's just not set up to do it. You'd need to look at the emonGLCD code to see how its done, and remove all the "sleep" from the emonTx so that it can stay awake listening to the radio.

But I think the neatest way would be to run a small (3 mm diameter or so) microphone-type cable to your linen cupboard and let the emonTx drive the Eurotherm directly. The restriction there is your ability to find an acceptable route for the cable. Failing that, you could, using possibly a second emonTx, generate the analogue signal to control the Eurotherm independently of the Pi, so your downstairs emonTx would send the standard message to the Pi, but as a different node send (possibly several times a second) a separate very short message - it only needs a single byte of payload, staying below the 1% band occupancy limit - to the emonTx controlling the Eurotherm. You'd need to make sure your Pi ignored those messages so that they didn't get sent to emoncms.org.

Oh boy, now that's made me think again.

I have contemplated running a cable twixt understairs and airing cupboard, but it is awkward, them not being above each other, and not even sharing a wall. But with a short run along a downstairs skirting board it could be done, a long way round - about 11 meters. As you say it is the simplest and most elegant solution. I can't find any thin microphone cable on my favourite online stores, but I do have a reel of telephone cable (2 pair) scudding about somewhere. That might do it, it's certainly quite slim in profile.

See now I've recently been buying lots of cheap Arduino kit and accessories from China and I've also got an rfm12B with a breakout board that I had been intending to use to make a monitor by listening in on the emonTXs transmissions and putting up some sort of display. But, but, I could use that to be the controller of the Eurotherm. Or, as you say, just buy another emonTX, or maybe a shield. Never thought of that.

I haven't looked very closely at all into the libraries used by my emonTX sketch - I've just used the send_rf_data() function having set up the nodeID in the definitions, presumably you can vary this before calling send_rf_data() and send a different packet as a different nodeID. Now that never occurred to me either.

It has struck me lately that I do seem to be doing the equivalent of recording off the radio by sticking a microphone in front of it's speakers, and you've given me quite a few fresh ideas there Robert, excellent thanks very much.

Just when I thought I was running short of things do on my Solar POwer Diversion (I call it spod) I now seem to have lots more to think about, Cheers, I'm off the pub to bore somebody senseless !!

So, just in case anyone is listening, I'll finish this thread off with the stuff that I've now done.

I followed some of Robert's advice above; the long wire didn't ring my bells, if for no other reason than I wanted control of the solar power diversion logic close to hand and not in my under stairs cupboard. So the two node IDs was the path I chose.

My emonTx 2.2 now uses two node ID's one only for emoncms.org (10) and the other (27) for control of the Eurotherm phase angle thyristor controller. I swap the node Id from 27 to 10 every 10th transmission and then back again afterwards. The sketch only calculates the solar power from the solar meter's led flashes for the emon type transmission and leaves it as it is for the others. Transmissions from the rfm12b are now every 0.8 seconds, and 1 in ten of those goes to emoncms.org (with updated solar power), so that's every 8 seconds.

Both transmissions are recorded in emonhub.log and my raspberry pi bash scripts digs them out and uses them both to eventually, after some thought, feed an analog (0 - 3.3v) signal to the Eurotherm.

I have built an Arduino based lcd monitor that displays the transmissions from the Rfm12b and does some rudimentary calculations of solar power generated so far.

I am now working on an Arduino (Nano) based system (Nano, I2C LCD screen and MCP4921) to listen to the rfm12b transmissions and eventually take over control of the Eurotherm phase angle thyristor controller - just for the crack really, as the Pi based one now seems to be doing great.

Having fun!!