Octopus energy : Smart Meter Feed

@Bill.Thomson here’s the photo (it’s a bit blurry) and the text -

[Owner of the photo requested it was deleted - BPO]

Look at the meter security tab you will see a thin wire that has heat shrink over it, if you look further along you will see the start of the shielded coax. This then travels up the wall to a hole in the ceiling and into the roof void and above the insulation on the ceiling. The other end is also exposed by the 17cm. The exposed measurement is what makes sure it received the correct signal.

[The occupier of the premises advises that the 1.5 mm² wires disappearing off to the left are temporary, put there by the Distribution Network Operator and are connected to their voltage monitor. Moderator (RW)]

7 posts were split to a new topic: Dangerous Practice by Supply Authority

Welcome, @newbuilder22 to the OEM forum.

Clearly, no-one here was in a position to know that those wires were a temporary installation by the DNO, even so, I think I had a duty as an electrical engineer by profession to call it out, if only to warn anyone reading this topic of the dangers of something like that.

Thanks for the welcome, my bigger annoyance is with my photo being posted, although I was asked I didn’t authorise it or I would have trimmed it to avoid this ambiguity.

You called it out without getting fact first. May be a question re, normally these wires shouldn’t be in here, I wonder if the photo is taken during DNO testing, otherwise it should be condemned. You jumped straight to condemning an installation you have no information on. All electricians I know would not pass such a scathing comment even on the phone until they had seen the full installation.

Thanks, I think I have said my piece and others have said there’s so happy to be that we have all been grown up and voiced.

For background the small cables are going to a volt recorder that is set up to capture voltage from a very large CT clamp- the large black hoop, the wires are used to power the recorder

Here is a modified version of agile.py which requests the last 10 days and put it into a cumulative feed instead. On first run it will request the last year. Any missing holes in the data should hopefully be filled in before they fall out of the 10 day window. If you’re still having trouble, make this number bigger.

This should work off of the same config file*, and (probably) won’t collide any existing setup you might have. (*I’ve not attempted to fix the bugs in the original, so set the tag and feed names in the script before you run it, on two lines).

If this script warrants any further refinement, I’d suggest:

  • make last N days be user configurable
  • fixing tag and feed config (without breaking it for users of agile.py)
  • add support for multiple meters (2 is not uncommon)

pi@raspberrypi:~/tim_agile $ python3 agile.py
Emoncms feed created: 195676
Number of data points: 100
End: 2022-10-06T23:30:00+01:00 => 16.071000000000005 kWh
Posting data to emoncms

It ran in a few seconds, created the feed OK, but didn’t populate it. Any ideas?

No idea. Should have just worked. Try running it again in a few days?

Please can anyone tell me how to use the original agile.py or this total.py to make the “Time of use version of My Electric” app display the calculated cost?

That app seems to want two inputs (use and use_kwh) and each of these seem only to make one, plus puts them in the feed API so I can’t use input processors to create the other (can I?).

Technically, the Octopus feed is only giving you kWh consumed in each half-hour. Dividing by half-an-hour (or multiplying by 2) will give you average kW for that time interval. So, one option is to run both scripts, modifying agile.py to give kW instead of kWh.

Or, edit total.py to populate both feeds at the same time from the single API request.

If you don’t want to mess with code, then a Virtual feed could be created to take agile:consumption, multiply by 2 and give you average power instead.

Cool. And what is that? The feed called use?

I’m quite happy to mess with code. I’ve just no idea what those apps want as input (what use and use_kwh should be) and am unfamiliar with putting things into the feed API instead of the input API, as well as unfamiliar with the Octopus feed.

Editing total.py seems to result in the feeds being created (once I’d solved the hardcoding of the names in the create commands, which meant it was ignoring agile.conf) but only the last values get populated.

but how then do I generate use_kwh? I don’t seem to be able to apply the kwh process to a virtual feed.

Let me see if I can explain it better.

Option A

agile.py populates a feed called consumption, which is kWh used per half-hour. A virtual feed that multiplies this by 2000 would give you average power in Watts. This is the “use” feed that “My Electric” app is asking for.

image

total.py populates a feed called consumption_total which is the cumulative energy that starts at zero and keeps on going up [great for daily/weekly graphs]. This is the “use_kwh” feed to give to “My Electric”.

So, running both scripts and creating a virtual feed will get you want you need.

Here’s a chart showing consumption_total (from total.py) (aka use_kwh) on the left axis and consumption_watts (virtual feed) (aka use) on the right.


(Plotting the delta of the total on 1800 second interval should perfectly match up with watts)

Option B

Instead of running two python scripts and needing a virtual feed, total.py could do the conversion and populate both feeds at the same time. I can write this up if you think it would be useful, however…

Option C

Had agile.py used the input api to upload the data instead of the feed api, then you could created the two feeds with a standard process list:
x 2000, Log to feed → ‘consumption_watts’, Power to kwh → ‘consumption_total’.

Something like this in place of Step 4 and Step 5 in agile.py:

# Step 4: Process history into data array for emoncms
for dp in data['results']:
   time = int(datetime.timestamp(datetime.strptime(dp['interval_end'],"%Y-%m-%dT%H:%M:%S%z")))
   value = dp['consumption']
   result = requests.post(settings['emoncms']['server']+"/input/post",
               params={'node':'agile','time':time,
                       'fulljson':json.dumps({'consumption':value}),
                       'apikey':settings['emoncms']['apikey']})

You’ll need to change the hard-coded node and input names, making sure the feed has the same name as the input. Once you have it working, empty the feed and run it again so it will download the maximum number of records from Octopus API.

Option C is probably the more typical way of doing things in emoncms, though option B is better for working out-of-the-box. I’ll probably rewrite total.py at some point, and fix the other issues. Hopefully there’s something useful in my ramblings to help you get what you need to get My Electricity app working.

1 Like

@Bill.Thomson - I tried this and it appears to have not helped the situation.

I did leave the inner insulation on - would bare core help?

It occurred to me that, if the antenna is on one side of the Comms Hub, is there another sort of antenna that could be used to stick on the outside of the Comms Hub and perhaps be more effective in ‘boosting’ the antenna? Something like this https://uk.rs-online.com/web/p/gsm-gprs-antennas/2188364

Yes. As with any electrical connection, metal to metal contact is necessary.
Even if connected metal to metal, it may not work. An RF ground is very different than a DC ground.

Once the signal level drops because of cable loss, there’s no way to make it up with a passive device,
i.e. an antenna. An amplifier at the near end of the feedline would be needed to overcome the loss as well as provide some additional signal strength at the far end.

The antenna referenced in your link is meant for operation at 700 MHz and above. It would work
if the transmitter is operating at 915 MHz, but not for a transmitter at 433 MHz.

The bit around the tag is bare.

Oh yes, I knew that wasn’t any use, just wondered if there was something similar that if stuck on the outside close to the existing internal antenna, might help, that I could connect to an external antenna.

Earlier, you said:

So is it still insulated?
If so, the center conductor needs to be bare too.
Take care to keep the shield (outer braid) from contacting the center conductor.

Gotcha.
Given the close proximity between the two antennas, it likely wouldn’t make much difference.

The bit connecting to the tag, bare, the rest, yes, still with the insulator.

But would the one stuck on the outside of the comms hub box then connected by wire to another one outside the house, imporve the ability of the antenna inside the Comms Hub to communicate?

If by that you mean “would a stronger signal be delivered to the comm hub?”
then yes, there could be an improvement.

It’s a case of which is lossier? The feedline or the RF path to the outdoors?*

If that path includes things like thick walls, especially if they are stone or concrete,
or a metallic shield in the form of foil on insulation, or the building itself if it’s metal,
then the cable would likely be the better of the two If it’s the proper cable.

Yes, the house has a thick cozy of foil backed PIR insulation (hence my issues) so the cable is likely to be less bad. It only has to be about 3m long. The garage doors are aluminium/insulation sandwich and it does seem that the hub communicates as long as the garage is opened regulaerly. With the cold snap, that isn’t happening.

From other posts, the comms are over 400MHz old TV frequency - any suggestions for a suitable pad antenna and external antenna?

What is the external antenna “looking at” and how distant is it?

The internal antenna doesn’t have to be a pad (the actual term is “patch”)
it could be a “rubber duck” monopole and groundplane like this:

or a simple wire monopole/groundplane like this:

image

Easy to build from off-the-shelf components.

Ref:

https://openenergymonitor.github.io/forum-archive/node/6238.html

1 Like