Agreed - better to fix the source if the issue. I won’t be the only person with this problem…
1 Like
I have the same problem, just realised that.
My CAD is at 0 at midnight but HA shows electricity data from the day before until 1AM.
Not sure what’s going on.
Edit: Checking MQTT I could see on STATE that the time there is incorrect (1 hour behind) and probably that’s why it’s writing into MQTT with that timestamp causing the cumulative (or import day) being reset at 1AM. I checked my meter and the time there is correct.
Just started using this template and during the day I am seeing a negative current power and zero values in “Smart Meter Electricity: Export”. I have solar panels and they are often pushing power into the grid, so while the negative current power might technically be correct I would prefer it if it actually showed up as an export instead. Has anyone else got solar panels and one of these CADs? I’d like to know if my CAD has a problem or if I need to come up with a workaroud to catch the negative values.
Hi @mogons,
Although I don’t have solar panels I did suffer from occasional massive negative spikes - for more details see entry #15 above. Robert (@robertalexa) suggested an excellent ‘cure’ which avoids any negative values by substituting with the previous reading. I have added this additional coding into my config and it works perfectly.
However if you are using the Glow IHD integration created by James (@megakid) I suspect that it doesn’t include any filter to avoid negative readings as most users haven’t reported that they were experiencing such problems. Perhaps a ‘negative value filter’ could be incorporated in a future update of the Glow IHD integration?
@JohnWH, I don’t think this is a glitch in the system. I just found the MQTT listening debugger and looking at the messages form the CAD I am getting:
{
"electricitymeter": {
"timestamp": "2022-06-23T14:36:59Z",
"energy": {
"export": {
"cumulative": 0,
"units": "kWh"
},
"import": {
"cumulative": 3625.742,
"day": 2.236,
"week": 14.057,
"month": 105.876,
"units": "kWh",
"mpan": "REDACTED",
"supplier": "REDACTED",
"price": {
"unitrate": 0.2729,
"standingcharge": 0.4105
}
}
},
"power": {
"value": -2.244,
"units": "kW"
}
}
}
You can see the current power is showing as -2.244kW (as my solar panels are working nicely), but the export is showing 0 kWh and I know my meter is exporting. Assuming the broker is seeing the raw data then it looks like the CAD is not reporting properly 
More likely you’re meter / supplier hasn’t enable the export registers on the meter.
Works fine for me, I’m on Octopus
I’m now looking at using the lifetime cumulative registers from the meters and doing the day totals within HA, as I then have much more control. I’ve just added raw points in a graph to see how those behave over a few days. @JaneatGlow has suggested it’s a limitation of the data from the meters.
Like others, I’m with Octopus, but I’m not sure that’s relevant.
1 Like
There is an outlier filter (one of many) available in HA which is very good. It will process the last n samples and exclude any data more than x% away from the median. I can see that being very handy to filter out negative / zero glitches.
I’m using it here to filter out glitches from my Dallas sensor…
- platform: filter
name: "Filtered return temp"
unique_id: "return_temp"
entity_id: sensor.temperature_sensor_28_be2a_7791_0402
filters:
- filter: outlier
window_size: 4
radius: 10.0
1 Like
I presume that if I move across to this local MQTT from the cloud MQTT, and use your sensor naming, then I will lose all my previous Energy stats?
Would I need to rename “smart_meter_electricity_import” to the sensor name I currently have setup in the Energy panel? Is there a way to leave all the sensor names the same and then just set my old name to the new name via something like a template sensor, ie sensor.daily_home_electricity == sensor.smart_meter_electricity_import ?
I really don’t want to lose 6 months worth of Energy stats.
1 Like
I have tried out the update to capture 0 responses provided by @robertalexa and that worked well for any issues during the day. However, as he pointed out, that still gave me the issue with my gas meter re-providing the previous days value for the first 30 minutes. As such I have modified the code to cover a that cross over and the delay with the gas meter updating
I created a debug entity in order to prove it and this is the code:
- name: "Smart Meter Gas Debug Calc: Import (Today)"
unique_id: "smart_meter_gas_import_day_debugcalc"
state_topic: "glow/REDACTED/SENSOR/gasmeter"
device_class: "energy"
unit_of_measurement: "kWh"
state_class: "measurement"
value_template: >
{% if value_json['gasmeter']['energy']['import']['day'] == 0 %}
{% if now() > now().replace(hour=0).replace(minute=40).replace(second=0).replace(microsecond=0) %}
{{ states('sensor.smart_meter_gas_debug_calc_import_today') }}
{% else %}
{{ value_json['gasmeter']['energy']['import']['day'] }}
{% endif %}
{% else %}
{% if now() < now().replace(hour=0).replace(minute=40).replace(second=0).replace(microsecond=0) %}
{{ 0 }}
{% else %}
{{ value_json['gasmeter']['energy']['import']['day'] }}
{% endif %}
{% endif %}
icon: "mdi:fire"
I changed the threshold from being a minute passed midnight, to being 40 minutes. This gives the gas meter plenty of time to reset and feed the real data through to the IHD. I then added code to force a zero value in the first 40 minutes so you don’t carry the previous day’s peak value through to the new day. I’ve been using it for a couple of weeks and seems to work.
I’m testing the equivalent on electric aswell, as I’m seeing the same thing on the 00:00:00 entry. Whilst it doesn’t appear to feed into the Energy stats, if you have other reporting of the peak value for the day, it does impact it, so I wanted to ensure the day is zero from the first entry. It will have its first run tonight and I’ll feed back at some point. Note, I have set “40” back to “1” on the electric as it is generally correct and want to have as much accurate data as possible.
3 Likes
@duffjp So I replaced my template for yours last night, as I was getting the previous days gas total being added into the current days total. All works perfectly in the Energy dashboard, but this is what I am getting in the history now for that sensor:
I’m getting blanks up until the first actual gas reading of the day comes through via mqtt (gas comes on at 07:30, but it take half an hour to show up, so first reading via mqtt is 08:00).
Hi,
I am looking at your calculation for charge including standing charge as the Energy dashboard doesn’t handle that
I am trying to understand why your calculation of “Total kWh imported today” * “Current unit rate” + “standing charge”. It seems to me that this only works if you have a fixed unit rate per kWh, and that if you have a variable rate (E7 Octopus Go etc) then it would treat your unit rate as fixed to whatever it is when it calculates it
Can you walk me through it if thats not the case. I am getting desperate to get my standing charges represented in the dashboard without resorting to crazy things like creating an additional meter or something
1 Like
if you are on octopus go or E7 with a peak and off peak tariff, you will need to install the ocotpus API integration which has a live tariff entity for electricity which pulls data from ocotpus not from your meter. SMETS2 meters dont really work (or dont get configured) for peak and off peak so it usually only displays one rate.
If you install the API integration and replace the ‘current unit rate’ in your template sensor with the octopus live tariff entity, it should show the accurate and current cost.
1 Like
Thanks for that. Its at least an alternative. I was hoping for something that wouldn’t require Cloud interaction.
Hi i have put the code into mqtt.yaml uploaded that to my include directory.
Everything seems to be working but when i go to the energy section i get the following error.
Something about last reset missing?
Last reset missing
The following entities have state class 'measurement' but 'last_reset' is missing:
* sensor.smart_meter_electricity_import_today
What code do i need to put in to retifcy this ?
I put this into my configuration.yaml and seems to have gone away?
customize_glob:
sensor.smart_meter_electricity_import_today:
unit_of_measurement: "kWh"
device_class: energy
state_class: measurement
last_reset: "1970-01-01T00:00:00+00:00"
Does anyone have an example of adding the energy-devices-graph to the provided dashboard yaml that will make the graph go full-width. I’m not familiar with layout-card and despite trying various things I’ve not managed to make the card to full page width like the other components/panels. Currently it looks like the attached.
Appreciate any sample yaml from someone who knows layout card.
Thanks for sharing your hard work.
One minor improvement suggestion is to say “Please make sure to use the correct device ID, using capital letters, and replace the word REDACTED with it.” I typed mine in and wondered if it was case sensitive so knew what to tweak when it didn’t work using lower case letters.
thanks for the hard work on this. One question, where can I get the custom grid-layout element so I can add the same lovelace dash as you’ve used?
Hi all - is there anything I need to add to the HACS integration? Someone mentioned above negative values but it already filters out zeros on some fields. Perhaps I missed it but what are the negative values?
Hi James (@megakid),
I am the user who initially requested assistance in templating the local MQTT data and also the person who’s electricity readings experience random extremely negative ‘spikes’. I detailed the problem - see entry #16 within this thread. Unfortunately once or twice per day I am still seeing massive negative spikes on the Bright App (as this data isn’t filtered)
In order to avoid logging these within HA I subsequently followed the excellent suggestion from @robertalexa (see entry #17) so if the value is less than 0 it uses the previous value instead.
I would be able to use the HACS integration instead of the manual lines of template code if it could incorporate a similar means of avoiding negative spikes.