home-assistant-glow
home-assistant-glow copied to clipboard
klaasnicolaas
Status LED (repeater) misses some blinks
Hi I am using a D1 MINI with a basic red LED. I noticed that the LED doesn't flash everytime there is a pulse detected on the photodiode. It only happens about once every minute or less. I have a powerpal sensor reading from the status LED also. Everything else is working perfectly. I have also had to enable the internal_filter to prevent spikes. My pulse rate is 3200. Here on the graff you can see the powerpal reading (which is done every minute from the online API) and the HA Glow reading are slightly out some/most of the time but not by much. Anyone got any clues on what is causing this ?
Here is my ESPHome config. I have removed the status section as I only want the LED to be used as a powerpal repeater.
---
# Home Assistant Glow
#
# Read your electricity meter by means of the pulse LED on your
# meter, useful if you do not have a serial port (P1).
#
substitutions:
device_name: ha-glow
friendly_name: HA Glow
device_description: "Measure energy consumption with the pulse LED on the smart meter and repeat to PowerPal sensor"
pulse_pin: GPIO14
repeater_led: GPIO5
# imp/kWh rate ⬇ #
pulse_rate: '3200'
dashboard_import:
package_import_url: github://klaasnicolaas/home-assistant-glow/home_assistant_glow.yaml
esphome:
name: '${device_name}'
comment: '${device_description}'
project:
name: "klaasnicolaas.home_assistant_glow"
version: "3.0.0"
esp8266:
board: esp01_1m
framework:
version: latest
# WiFi credentials #
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: '${device_name}'
captive_portal:
# Enable logging
logger:
level: NONE
# Enable improv over serial
improv_serial:
# Enable Home Assistant API
api:
services:
- service: reset_total_energy
then:
- button.press:
id: button_reset_total
ota:
safe_mode: true
reboot_timeout: 10min
num_attempts: 5
web_server:
port: 80
auth:
username: !secret web_username
password: !secret web_password
output:
- platform: gpio
pin: ${repeater_led}
id: output_red
light:
- platform: binary
internal: true
id: led_red
name: Red
output: output_red
button:
- platform: restart
name: "Restart - Glow"
- platform: template
name: "Reset - Total Energy"
id: button_reset_total
on_press:
- pulse_meter.set_total_pulses:
id: sensor_energy_pulse_meter
value: 0
# Sensors for ESP version and WIFI information
text_sensor:
- platform: version
hide_timestamp: true
name: '${friendly_name} - ESPHome Version'
- platform: wifi_info
ip_address:
name: '${friendly_name} - IP Address'
icon: mdi:wifi
ssid:
name: '${friendly_name} - Connected SSID'
icon: mdi:wifi-strength-2
sensor:
# WiFi signal
- platform: wifi_signal
name: "${friendly_name} - WiFi Signal"
update_interval: 120s
# Pulse meter
- platform: pulse_meter
name: '${friendly_name} - Power Consumption'
id: sensor_energy_pulse_meter
unit_of_measurement: 'W'
state_class: measurement
device_class: power
icon: mdi:flash-outline
accuracy_decimals: 0
pin: ${pulse_pin}
internal_filter: 150ms
on_value:
then:
- light.turn_on:
id: led_red
flash_length: 100ms
filters:
# multiply value = (60 / imp value) * 1000
# - multiply: 60
lambda: return x * ((60.0 / ${pulse_rate}) * 1000.0);
total:
name: '${friendly_name} - Total Energy'
id: sensor_total_energy
unit_of_measurement: 'kWh'
icon: mdi:circle-slice-3
state_class: total_increasing
device_class: energy
accuracy_decimals: 3
filters:
# multiply value = 1 / imp value
# - multiply: 0.001
- lambda: return x * (1.0 / ${pulse_rate});
# Total day useage
- platform: total_daily_energy
name: '${friendly_name} - Daily Energy'
id: sensor_total_daily_energy
power_id: sensor_energy_pulse_meter
unit_of_measurement: 'kWh'
icon: mdi:circle-slice-3
state_class: total_increasing
device_class: energy
accuracy_decimals: 3
filters:
# Multiplication factor from W to kW is 0.001
- multiply: 0.001
# Enable time component to reset energy at midnight
time:
- platform: sntp
id: my_time
Did setup my glow today to, my "repeater" misses some blinks to. sensor green led catches the led blinks of the tarrif meter but as you say the "reapeter doesnt blink" i wounder if the glow still register the impulse values ?!?!
Since you are apparently using an ESP8266, I'd suggest trying to comment out the web server definition. To my understanding, the web server is very resource intensive especially for the ESP8266, so it might be, that the repeater is missing some blinks because it's busy running the web server. Refer to the ESPHome documentation: https://esphome.io/components/web_server.html That's just a hunch though.
If that turns out to be the problem, and you absolutely need the web server, then you should maybe consider upgrading to an ESP32 for more resources.
Let us know if that helps!
Using esp32
ti 22. helmik. 2022 klo 17.01 Kimble8650 @.***> kirjoitti:
Since you are apparently using an ESP8266, I'd suggest trying to comment out the web server definition. To my understanding, the web server is very resource intensive especially for the ESP8266, so it might be, that the repeater is missing some blinks because it's busy running the web server. Refer to the ESPHome documentation: https://esphome.io/components/web_server.html That's just a hunch though.
If that turns out to be the problem, and you absolutely need the web server, then you should maybe consider upgrading to an ESP32 for more resources.
Let us know if that helps!
— Reply to this email directly, view it on GitHub https://github.com/klaasnicolaas/home-assistant-glow/issues/135#issuecomment-1047885891, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO47AHO2DB3AA6WV5EECU4LU4OQOFANCNFSM5OR6JFJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
Using esp32 ti 22. helmik. 2022 klo 17.01 Kimble8650 @.***> kirjoitti: …
Well that settles that then :D
If you are REALLY BORED ... I put a video here with it showing missing blinks at 1:22, 1:25, 2:10, 3:49, 5:23, 5:28, 6:48, 6:56 and also a very strange blink from the repeater at 3:07 with no blink from the power meter. I have no idea how that happened unless it picked up some light while i had the door open on the meter box. Am a bit stumped there.
https://www.youtube.com/watch?v=ewfSQRiXS2A
I removed the web server but no difference.
I've noticed the same thing. My pulse rate is 1600 and it missed 1 in every 10-20 pulses. Yet to find a solution.
Hi, I had the same problem, but everything started working good, when I change "safe mode:" to "false" in the OTA section. I don't know why, but it works. Maybe it will help someone?
@andrzejs1972 I don't think there is any connection with that, it is recommended to always use safe_mode.
I tried safe_mode = false and still seeing missed blinks once every minute or so.
I am experiencing the same issue on ESP32. The is no apparent pattern, sometimes every 10th blink is missed, sometimes 3 in a row. Photodiode is flashing DO led without missing a single flash on power meter, so that should eliminate problem with photodiode modul.
i had this problem, i'm currently testing my setup (for 2days) without led repeater because it uses delay function causing the esp to skip pulses and for my 1000ims/kWh i use internal_filter of 60ms, for yous 3200ims you might consider even lower number. so far i don't have any strange counts and looks very good we need to find a way to implement led repeater using timers and not delay function.
with led repeater:
without led repeater:
Anyone got some good pointers?
My energy meter uses 10.000 imp/kwh and from what I can see in HA, it reports less then used.
On the charger for my car, I got a separate Schneider PowerTag that I know is reporting accurate. I've set up the Energy Dashboard in HA so it uses the PowerTag readings as Energy Export so it subtract the usage from the total usage (I got free charging at home, so I don't pay pr kWh)
The only thing I have changed from the standard settings is disabled the web server and the repeater LED.
Would it help to set the internal_filter ? or is the diode simply not fast enough when pulling 10 kW ? :-)
** UPDATE ** Just pulled the data from my energy company. When I compare the data throughout the day, it's only off when the charger it running, so I guess that the diode somehow can't register the fast blinking diode on my energy meter
Anyone got some good pointers?
My energy meter uses 10.000 imp/kwh and from what I can see in HA, it reports less then used.
On the charger for my car, I got a separate Schneider PowerTag that I know is reporting accurate. I've set up the Energy Dashboard in HA so it uses the PowerTag readings as Energy Export so it subtract the usage from the total usage (I got free charging at home, so I don't pay pr kWh)
The only thing I have changed from the standard settings is disabled the web server and the repeater LED.
Would it help to set the internal_filter ? or is the diode simply not fast enough when pulling 10 kW ? :-)
** UPDATE ** Just pulled the data from my energy company. When I compare the data throughout the day, it's only off when the charger it running, so I guess that the diode somehow can't register the fast blinking diode on my energy meter
That's a lot of fast impulses, i don't know if you can record them all and publish them by mqtt + your HA database will grow very fast (consider to filter out the power consumption in your HA records purge settings or even not using power at all, only energy). For the settings of internal_filter i'm currently using pulse mode with 3ms filter (i still had some glitches whit edge mode even with delay and webserver off, now i only have glitches when wifi signal is to low). If you want to use edge mode than do the math for 10kWh load: 10kWh*10.000imp/kWh=100.000imp/h or 100.000/3600=27.77imp/sec which is 27.77Hz or 1/27.77=36ms for one pulse and pause so your pulse width might be 36/2=18ms long if we assume that pulse and pause are equal width.
There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm certainly experiencing the same issues with the same equipment and components (most importantly the ESP32) described in this project. I have observed the diode detection and the ESP32 repeater activity and the repeater skips a number of pulses, especially when there's a higher power draw. As an example, when I have a power draw of about 2800W (my pulse rate is 1000), I more consistently than not observe the repeater skipping two pulses in a row and then detecting two in a row; repeat, repeat, skip, skip, repeat, repeat, skip, skip.... The diode card, on the other hand, catches each and every pulse.
What should we expect in terms of performance when it comes to repeating/reporting to Home Assistant with this setup? Can we improve the repeat/report performance? Today I'm using wifi, as per the guide, but I'm open to trying to connect the ESP32 directly to the machine (through e.g. USB) running Home Assistant if that would increase performance of repeat/report.
If the diode does register every pulse correctly then I have the idea that you are using some filters (internal_filter) so that certain pulses are omitted.
How can I figure out if the diode is registering every pulse? I'm still having the same issue months on, tried lots of different things with no luck
How can I figure out if the diode is registering every pulse? I'm still having the same issue months on, tried lots of different things with no luck
try pulse mode whit 3mS filter. finaly working for me. also disable led output you can add external led whit mosfet on the input pin of the mcu.
On the board of the photodiode there is a green LED which lights up every time it detects a pulse. At the same time, the ESP32 should also have an LED, which will only flash when the ESP32 has processed the signal. So I think you could debug a bit whether the problem is purely the measurement at the photodiode or the processing on the ESP32, for example because you have set an internal_filter.
I've internal_filter commented out in my yaml, I'll have to try diagnose the issue with the LEDs like you've explained
With 10.000 blink/kwh, im using this settings and are within +/- 50-100w when using 10 kWh.
https://github.com/smulle48/home-assistant-glow/blob/main/home_assistant_glow.yaml
Another thing I have done, is that I have done the exact opposite with the sensor, as the guide says.
I've turned it all way down (less sensitive) and then gradually turned it up until it starts registering. Then I turned it a bit more up.
After that, I have never missed blinks or too many blinks
I currently use the default values of https://github.com/klaasnicolaas/home-assistant-glow/blob/main/home_assistant_glow.yaml except for some obvious things like AP and password settings. The contents of the yaml has internal_filter commented out, which mine also has.
The diode doesn't skip a beat, but the ESP32 does (in so far I can tell from the LED repeat), and it starts at about 1500W power draw and gets much worse the higher the load/more power is drawn.
(@smulle48 I can't review your yaml-file, the repo doesn't seem to be accesible/exist)
I currently use the default values of https://github.com/klaasnicolaas/home-assistant-glow/blob/main/home_assistant_glow.yaml except for some obvious things like AP and password settings. The contents of the yaml has
internal_filtercommented out, which mine also has.The diode doesn't skip a beat, but the ESP32 does (in so far I can tell from the LED repeat), and it starts at about 1500W power draw and gets much worse the higher the load/more power is drawn.
(@smulle48 I can't review your yaml-file, the repo doesn't seem to be accesible/exist)
My bad. Should be visible now 😃
I see that you use more filters from an open pull request, would that possibly make a difference in the result?
I see that you use more filters from an open pull request, would that possibly make a difference in the result?
In my case they made a huge difference 😃
Is there anything specific I should test out first of the yaml @smulle48 links to? I'm too unfamiliar with the filtering and I'd rather take an approach of changing one thing at a time and test it out, but if there's anyone who could say "well, [this filter setting] would be my first guess" it'd help me out a lot. Thanks.
Is there anything specific I should test out first of the yaml @smulle48 links to? I'm too unfamiliar with the filtering and I'd rather take an approach of changing one thing at a time and test it out, but if there's anyone who could say "well, [this filter setting] would be my first guess" it'd help me out a lot. Thanks.
If your readings are "spiking" the EDGE filter does a huge difference.
If you got access to data from your electric company, you can try to set the ms to an low value and let it be for a day (or until you can get the readings) and then compare it.
Then gradually turn it up until you hit the sweet spot :-)
In my case, 12ms was enough for 10.000 imp so yours are probably somewhere around 3 times higher
I don't have any issues with spiking readings. My max power consumption reaches somewhere up to 4000-5000W, but those are very rare. I take it the EDGE filter seem like it would not benefit me in my case. It's also stated in https://esphome.io/components/sensor/pulse_meter.html that EDGE is used by default.
I adjusted the internal_filter and set it to 10ms (previously it was commented out which according to https://esphome.io/components/sensor/pulse_meter.html by default is set to 13us) and it made no difference.
I can only conclude that the missed pulses stem from the ESP32 doing something else that make it skip pulses. When I observe the pulses on the diode I get something along 5 pulses a second during my higher/top power draws. And that's more in line with 100-500ms, not 10ms when it comes to filtering.
Filters so far hasn't affected my situation. If anyone has other tips on what other tweaks can be done I'm all ears.
What I have yet to try is
- Switching off the web server on the ESP
- Switching off the LED repeater on the ESP
I'll get back with results on these.
The power draw I have during these tests are around one pulse each second.
Switching off the web server made no difference. The repeater skips pulses when comparing to the diode.
Switching off the repeater LED made no difference. The reported values to Home Assistant reflects skipped values, e.g. by stating "2 seconds ago", "3 seconds ago" in between "Now".
I do note a curious thing in the web server log on the ESP.
- The reported values for "House - Total Energy" are very consistent and seem to match the diode pulses well.
- The reported values for "House - Power Consumption", however, are erratic and seem to correlate to what I observe with the repeater LED skips when that was enabled.
Could there be an issue with the "House - Power Consumption" part of this setup?
You can try to change the pulse_pin to GPIO26.
When I used GPIO12 I also got skipped and sometimes too many blinks.
The ESP32 got touch input and that somehow interfered on my setup.
You can even make it "sense" a blink just by touching the board 🤣
I've also completely disabled the repeater led as I don't got the led installed. The sensor board already got its own led I can use instead.
You can also try to use the throttle_average: 1s and filter_out: NaN (see in my config) to get a more consistent reading on the House - Power Consumption.
Btw. Your pulse length is about 220ms at 5kw load, so you should use a number around the half of that for the filter, not 10ms
You can try to change the pulse_pin to GPIO26.
When I used GPIO12 I also got skipped and sometimes too many blinks.
The ESP32 got touch input and that somehow interfered on my setup.
You can even make it "sense" a blink just by touching the board 🤣
I'm currently using GPIO13 (If I remember correctly, GPIO12 either prevented the ESP from booting, or it registered pulses like you describe by touching it, or both) and it's been pretty solid, but I haven't investigated if 13 does something else suboptimal for measuring so I'll give 26 a go as well, just to rule out any incompatibilities there.
I've also completely disabled the repeater led as I don't got the led installed. The sensor board already got its own led I can use instead.
I would probably disable it myself if I could trust that all the measurements are correct, but that would mean the pulses from the diode and the registered pulses would have to be in sync, which they currently are not.
You can also try to use the throttle_average: 1s and filter_out: NaN (see in my config) to get a more consistent reading on the House - Power Consumption.
I'll test it out and see what I get.
So far, none of the changes seem to make a difference. The modifications to throttle_average and filter_out seem to have made things less responsive if anything, but that could just be up to perception.
The missed pulses are slightly different on each test, but consistent enougt that I chalk those up to something not related to the settings changes at this point.
So far, I haven't been able to improve my "House - Power Consumption" reporting/repeating. I just can't seem to figure out why that specific piece of these measurements don't work as intended, but the "House - Total Energy" (and "House - Daily Energy") catches every single beat or at least is much more on point with the diode pulses...
As soon as I go above 1000-1500W power draw, the Power Consumption report/repeat is getting worse in terms synchronizing with the diode detection. When the draw is less than 1000 everything syncs up just fine.
I'm thinking, is this now (maybe it always was) a question for the ESPHome project rather than the Home Assistant Glow one? I mean, if the issue with reporting/repeating isn't related to how APIs/code is used (such as with Home Assistant Glow) but rather how it's implemented (which, I assume, is done through ESPHome) it makes a bit more sense that I file an issue there instead?
After running into the exact same thing (status led flashes "disappearing" at higher loads) I think I found the problem, there are a couple of things to consider.
First a small summary of things people have commented or tested on before:
-
By the way, I use an LPT-80 phototransistor together with a 100kOhm resistor as the sensor, together with a D1 mini. Since this is not a nice clean pulse I use
internal_filter: 30msand with that it syncs perfectly with the power meter LED. The LPT-80 is a flat "side-looker" so it is easy to stick onto the meter with some tape, I don't even have a case (yet - I want to add some more functions first) and it works perfectly with basement lights on and lights off. -
The
-delayin flashing the LED is not blocking (as per theesphomedocs), the only consideration there is that the pulse time should be low enough. For example, at 1000 pulses/kWh, at a 20 kW load, your pulses are spaced 180ms apart, so the default delay of0.5sis a bit long, but a50msflash is perfectly reasonable. -
The status light should be set to
internal, you don't want a flashing/movinglightswitch updating itself in HA on every pulse. -
At 11kW load (a typical 3-phase 16A load) you have, at 1000 pulses/kWh, over 3 pulses/second. You don't want HA to update that often, spam the logs with that much data over a perhaps not so reliable wifi connection in your basements, etc. However, I did not get a good combination of
throttle_average,filter_out: nanandheartbeatto work yet at low loads, but you can disable some of the logging, especially the led changes, to not overwhelm HA with data. -
For the totals you can consider a threshold to reduce continuously publishing tiny changes.
filters:
- lambda: return x * (1.0 / 1000.0);
- delta: 0.05
- heartbeat: 5s
Now, onto the real problem.
The way the pulse_meter in esphome works is that it installs an interrupt handler which records the current timestamp whenever it triggers (since you don't want to do anything else in an interrupt handler)
esphome calls a loop function on all registered components ~~continuously~~ ideally about 60 times per second. The pulse_counter loop function is thus called much more often than actual pulses happen. The pulse counter code compares the current timestamp to the last timestamp recorded by the interrupt handler, and depending on your settings (internal_filter etc) decides a new pulse has occured and records the pulse width (i.e. the time between pulses).
~~Now keep in mind that this function is called hundreds, if not thousands of times per actual pulse, basically just as fast as the esp can run all of the included components in a loop.~~ The ESPHome scheduler tries to run at about 60 loops per second.
The function therefore has to decide when to publish a new value, and for some reason it does not use the same logic as it did to determine a pulse had happened, but it simply deduplicates the millisecond-rounded value of the calculated recorded pulse-width times.
if (this->pulse_width_dedupe_.next(pulse_width_ms)) {
if (pulse_width_ms == 0) {
// Treat 0 pulse width as 0 pulses/min (normally because we've not detected any pulses for a while)
this->publish_state(0);
} else {
// Calculate pulses/min from the pulse width in ms
this->publish_state((60.0f * 1000.0f) / pulse_width_ms);
}
}
This means that if 2 consecutive valid intervals have the same duration (in milliseconds), something which gets more and more likely at higher loads (shorter intervals), the second value gets ignored.
This deduplication approach has some side effects:
- The instantaneous rate is still correct! The
esphomesends HA "current power is 11293W", but HA doesn't know or care how oftern this is refreshed or make any assumptions about the timing, so deduplication has no effect. - Totals will, I think, be slightly off, as pulses are lost. However, this is not obvious at first but takes time to accumulate, and I didn't look at the internals to see if it perhaps interpolates a missing sample (basically just assuming the load stayed the same which is perfectly reasonable).
- Your status LED will not flash in sync with the power meter LED
In my opinion (but this is my first time opening up esphome) deduplication has no advantages and this can be considered a bug in the pulse_meter component.
Luckily, this can be worked around without needing to install a development version of esphome, by using the my_components folder to provide a custom implementation (a modified version) of the pulse counter, using the following instructions: https://esphome.io/components/external_components.html
You should then have:
./my_components
./my_components/pulse_meter
./my_components/pulse_meter/pulse_meter_sensor.cpp
./my_components/pulse_meter/sensor.py
./my_components/pulse_meter/pulse_meter_sensor.h
./my_components/pulse_meter/automation.h
./my_components/pulse_meter/__init__.py
./<your-project>.yaml
by copying pulse_meter from the esphome repository, and then applying the following diff:
--- /home/dennis/esphome-dev/esphome/esphome/components/pulse_meter/pulse_meter_sensor.cpp 2022-07-29 17:53:26.884213603 +0200
+++ my_components/pulse_meter/pulse_meter_sensor.cpp 2022-07-29 21:30:58.795423475 +0200
@@ -20,6 +20,8 @@
void PulseMeterSensor::loop() {
const uint32_t now = micros();
+ bool hasNextPulse = false;
+
// Check to see if we should filter this edge out
if (this->filter_mode_ == FILTER_EDGE) {
if ((this->last_detected_edge_us_ - this->last_valid_high_edge_us_) >= this->filter_us_) {
@@ -28,6 +30,7 @@
this->pulse_width_us_ = (this->last_detected_edge_us_ - this->last_valid_high_edge_us_);
}
this->total_pulses_++;
+ hasNextPulse = true;
this->last_valid_high_edge_us_ = this->last_detected_edge_us_;
}
} else {
@@ -42,6 +45,7 @@
}
this->sensor_is_high_ = true;
this->total_pulses_++;
+ hasNextPulse = true;
this->last_valid_high_edge_us_ = this->last_detected_edge_us_;
}
// Only consider LOW pulses and "new" edges if sensor state is HIGH
@@ -64,7 +68,7 @@
// We quantize our pulse widths to 1 ms to avoid unnecessary jitter
const uint32_t pulse_width_ms = this->pulse_width_us_ / 1000;
- if (this->pulse_width_dedupe_.next(pulse_width_ms)) {
+ if (hasNextPulse) {
if (pulse_width_ms == 0) {
// Treat 0 pulse width as 0 pulses/min (normally because we've not detected any pulses for a while)
this->publish_state(0);
@@ -76,7 +80,7 @@
if (this->total_sensor_ != nullptr) {
const uint32_t total = this->total_pulses_;
- if (this->total_dedupe_.next(total)) {
+ if (hasNextPulse) {
this->total_sensor_->publish_state(total);
}
}
Don't forget to add
external_components:
- source: my_components
to your yaml! To make sure it is really using this code just add some random word somewhere in the .cpp file and if the compiler complains then everything is set up right (remove the word again).
With this change my status LED flashes in perfect sync with the power meter itself up to 13 kW, whereas before it would start dropping flashes at only a few kW.
As a last thought, the problem therefore also doesn't seem to related to the load on the esphome so much (so perhaps running a webserver, and especially on an esp32, should be just fine), but I don't know how esphome deals with queueing wifi data so reducing log traffic would be the thing to focus on (so just make sure you're not logging per pulse).
Hope this helps someone!
After clarification from an esphome developer in de mentioned report:
- Deduplication is intentional
- While identical consecutive values are not published, pulses do keep being counted in
total_pulses_ - The
totalsensor (i.e. thetotal:block of thepulse_meter) is also deduplicated, but should increase by 1 per pulse
Therefore, the much simpler solution to fix the LED blinking is to blink the LED through the on_value(or on_raw_value) of the total sensor instead.
However, the total_daily_energy sensor in its current from would not work as it relies on each individual (published) pulse.
I don't have time for the next week or so t to experiment with that, perhaps it works if using the total sensor (refer to it by an id) as the power_id and removing the multiply filter as it already gets kWh values.