The plugs with TASMOTA seems to be the way forward. Which plugs are well flashable?
The last comment about the responsibility might be a theoretical one as it might be more than tricky in case you have a damage to get even 1 cent from a company from overseas 
And indeed - most of the smart plugs are actually made out of non-burning material 
(which is very convenient because most fire insurances donât pay in this cases at all because smo(u)ldering isnât a fire - still the damage is often disastrous anyway). 
Device based on this design flaw 
were soled from various white labels (all produced by tuya) and had different maximum ratings including max. 10A and others max 16A. 
Like stated before you can just integrate your power usage over time directly on the plug an save it flash if you have control over your device. The moment your plug is online it can send the latest total energy to your HA server which will update your entity in that moment. As stated before HA doesnât support synchronizing old timestamp/values. 
the ones coming preinstalled with esphom/tasmota are the easiest because they can be directly ota updated 
2 Likes
I am checking these:
Are there pros/cons for the different two esphome/tasmota versions?
Tasmota does not have support for th native api so mqtt is probably mandatory for communication. 
Features of native API (vs. MQTT):
- Much more efficient: ESPHome encodes all messages in a highly optimized format with protocol buffers - for example binary sensor state messages are about 1/10 of the size.
- One-click configuration: ESPHome just needs one click to set up in Home Assistant - no more messing around with retained MQTT discovery messages and alike.
- One less single point of failure: In the ESPHome native API each ESP is its own server. With MQTT, when the broker shuts off nothing can communicate anymore.
- Stability: Since ESPHome has far more control over the protocol than with MQTT, itâs really easy for us to roll out stability improvements.
- Low Latency: The native API is optimized for very low latency, usually this is only a couple of milliseconds and far less than can be noticed by the eye.
The configuration of your esphome node (plug) takes all place in one yaml. To achieve the same (save total energy to flash, check for api (mqtt) availability and send values via webhook if connected to wifi but not to HA, etc.) might be a bit different in tasmota and you probably need to use some configurations in web ui, Other settings can be only found in commands (console) and some things could require (not too intuitve) scripting language. In the worst case scenario it is necessary to manually make changes before building a tasmota binary. 
But if you are new to both best is probably just to test them out 
Hello folks, so let me share my experience.
I bought Athom devices. Both, Tasmota (wall plug) and ESP based (schuko plug).
-
The wall plug turned dead after the first update using the provided link. The Athom support told me to flash TASMOTA directly by serial. Although I can do that, I think as a user, I am not supposed to kill the plug with the provided/preconfigured link during the first few minutes.
-
The schuko plugs were esp based and could be added like charm as told here and as expected, however, the LED cannot be turned off. The button in its configuration does not have an effect.
So, in general, I would like to test some other ESP based devices but those that work as expected out of the box. Which brands do you have a good experience with?
Try the search 
as various topics exist (Hardware and ESPHome category) which ask exactly this question 
ok, so I am writing the final report on whether I was able to achieve what I needed. I donât.
The following graph shows that the ESP based Athom Plug did not save anything in any memory. I kept my dryer going, turned off the wifi and waited. Instead of adding the consumption during the time the wifi was turned off, it just continued from the last known state.
Maybe a graph that resets on daily basis instead of every 15mins is better to demonstrate it.
A correct kWh should never drop to 0, yours does ?
Do you mind sharing your esphome yaml for your device?
Did you add/use a totaly_daily_energy or integration sensor like described in my post?
Or do you make use of the corresponding components (Integration - Riemann sum integral - Home Assistant and Utility Meter - Home Assistant) in HA which obviously canât continue to work if a (remote) device is disconnected? 
I am using the energy sensor provided by ESP but then I use helpers âutility meterâ and it looks like the problem is the helper. This is a graph from the energy sensor, which apparently make the proper jump during the time wifi was off. I am not creating Riemann sum integral in this case.
Ok, so the plug is capable to count continuous consumption when wifi is off but how to transform the effect into utility meters? The ESP provides daily consumption but not monthly, which is crucial for any analysis.
For the third (and last) time the link to the docs for you 
This component can be considered a more-generic version of the Total Daily Energy Sensor.
Probably the default periodically_resetting set to true is the show stopper in your case
Oouch sorry! So does this mean I can create a sensor directly in the yaml file I can edit in the ESPHome addon > particular device instead of using utility meter helper? Sorry, this is the first time I am working with ESP and I value your time and patience to guide me.
The periodically_resetting is not the problem, the utility meter works like a common analog meter, when the energy is not growing step by step it stops incrementally add values. I guess I need an alternative directly within the ESP yaml in order to have a monthly meter comparably to the provided daily meter by the integration.
My current yaml you ask for:
substitutions:
name: plug-drying-machine
friendly_name: PLUG Drying Machine
packages:
Athom_Technology.Smart_Plug_V2: github://athom-tech/athom-configs/athom-smart-plug-v2.yaml
esphome:
name: ${name}
name_add_mac_suffix: false
friendly_name: ${friendly_name}
api:
encryption:
key:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
1 Like
The docs say it quite directly:
periodically_resetting boolean (optional, default: true)
Enable this if the source sensor state is expected to reset to 0, for example, a smart plug that resets on boot. When this option is disabled (for example, if the source sensor is a domestic utility meter that never resets during the deviceâs lifetime), the difference between the new value and the last valid value is added to the utility meter, which avoids the loss of a meter reading after the source sensor becomes available after being unavailable.
So you could probably also keep your (total) energy (integration sensor) on the esphome device and do the daily/weekly/monthly/yearly utility meters you need in HA 
Would you mind to write down an example yaml code for me? I tried to play with it but the docs expect understanding the syntax to the extent that I cannot comprehend it. Thank you.
I think you can keep the esphome node on the default with the athom config (athom-configs/athom-smart-plug-v2.yaml at 600ddf21e308d025fc68e7fd2638d50dcfda417c ¡ athom-tech/athom-configs ¡ GitHub) as this one has a âTotal Energyâ sensor which saves the values to flash inside the esp.
Only thing left would be to use utility meters in HA with periodically_resetting set to false. That way the kWh will just continuously accumulated and never set back to zero like you had it before
With the integration component in esphome you could do the same like with the utility meter in HA but the problem will be a (reliable) time source 
Your device would need to have access to a ntp server so it can do things like daily/weekly etc. energy usage!