Some of you may have noticed a link to this on the SenseLink thread, but I wanted to wait to post here until we had some confirmed and calibrated smart plugs.
ESPSense is similar to SenseLink in that it emulates the TP-Link Kasa energy monitoring smart plugs to report usage. However unlike SenseLink, which acts as an “intermediary” to help devices talk to Sense, ESPSense run on devices and reports power usage directly to Sense.
We/I have already identified 4 commercially available plug models that can be flashed “over the air” and will then report usage just like TP-Link Kasa plugs. Example configurations are provided for each.
ESPSense is a “custom component” for the ESPHome platform, which is a firmware system for the Arduino-like ESP8266/ESP32 chip commonly used in a lot of IoT devices and plugs. ESPHome gives you flexibility and control over the hardware, uses a fairly straightforward YAML configuration, and can integrate seamlessly with Home Assistant. It’s awesome for quick, homemade IoT devices as well - I used a $5 ESP8266 board and ESPHome to make a “Music E-stop” button to quickly pause my HomePods when I get a call while working from home!
Now for the “little extra effort” part:
As noted above, you do have to re-flash the firmware of any device you want to run ESPHome and ESPSense. I’ve tried to provide guides and links on how to do that over the air, which is certainly the easiest way. It takes a little bit of familiarity with Linux and software configuration.
The appropriate calibration for the power monitor chip does need to be determined for each device model - for example, here are the values that have to be determined on one of the confirmed plugs. That’s done by either using something like a Kill-a-Watt and/or a known load like a 90W lightbulb. That said, the idea is to keep track of nominal calibrations for plug models that are identified, so that others can benefit!
Keep in mind that re-flashing: (1) this voids any warranty on the destination hardware, and (2) has a risk of “bricking” the device if performed incorrectly!
Like SenseLink, ESPSense is not an official solution and Sense is not responsible to provide support for it! Also keep in mind there is a ~20 plug practical limit for your Sense monitor.
And as a side note - while most of the interest would probably be regarding Kasa alternatives, ESPSense can also be used with development ESP boards and things like CT clamps or other power monitoring hardware to monitor things that simple plugs can’t. Similarly to SenseLink, you can configure it to measure and report more than one “plug” per device as well!
@cbpowell, it would be interesting to see your calibration “results” over a range of loads and load types, even if you are only looking a statistical sample of size 1 for each smartplug type. Plus not clear if any of them represents the “golden” measurement, especially since they all probably also have different sample intervals.
@kevin1 Yeah agree - internally all the plugs I’ve “confirmed” use the HLW8012 power sensor chip. In doing the base calibration, I’ve been trying to find the approximate/nominal values for the current_resistor (shunt resistor) and the voltage_divider. These would presumably be the same across all plugs of a given model, but individual plugs will definitely have a tolerance around that nominal, like within 5-10% - or whatever resistor tolerance the manufacturer decided to source.
A user on reddit (maybe on here here too) mentioned grabbing some more load values with a Kill-a-Watt, and I’ll probably try to do the same. ESPHome would let us use that data to do a “detail” linear calibration on top of the base values, where you map measured values to truth values on as many points as you want. If there’s a common non-linear trend to some models, that detail calibration would be how it could be corrected.
I bought 2- and 3-packs of the UL listed compatible plugs (to use for my own home), so I’ll eventually get around to comparing values across individual instances and see how they look as well.
Not sure the the Kill-A-Watt should be the golden measure. But glad you are getting a broader sample space. Ultimately the shunt and CT tolerances and any calibration feedback play a bigger role in accuracy than the actual underlying measurement chip.
I have posted in a few places, but FYI - the HS110 uses this chip for measurements.
STPM33 - ASSP for metering applications with up to four independent 24-bit 2nd order sigma-delta ADCs, 4 MHz OSF and 2 embedded PGLNA, STPM33TR, STMicroelectronics
I think Maxim is phased out their part - that may be the reason the HS110 has been discontinued.
@cbpowell, I’m trying to get ESPSense working on an ESPHome config for https://circuitsetup.us/product/expandable-6-channel-esp32-energy-meter/, but I’m getting a compile issue where perhaps ESPAsyncUDP has a version compatibility with wifi_component. Any assistance to work through this issue would be appreciated…I hope to add CT monitoring for the 240V devices that Sense is incapable of learning.
…
Compiling /data/espsense-main/.pioenvs/espsense-main/src/main.cpp.o
Generating partitions /data/espsense-main/.pioenvs/espsense-main/partitions.bin
In file included from src/espsense.h:3:0,
from src/main.cpp:41:
/data/espsense-main/.piolibdeps/espsense-main/ESPAsyncUDP/src/ESPAsyncUDP.h:19:25: error: conflicting declaration ‘typedef struct ip4_addr ip_addr_t’
typedef struct ip4_addr ip_addr_t;
^
In file included from /root/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/tcpip_adapter/tcpip_adapter.h:24:0,
from /root/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp32/esp_event_legacy.h:23,
from /root/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_event/esp_event.h:26,
from /root/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp32/esp_wifi.h:64,
from src/esphome/components/wifi/wifi_component.h:11,
from src/esphome.h:30,
from src/main.cpp:3:
/root/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/lwip/lwip/ip_addr.h:76:3: note: previous declaration as ‘typedef struct ip_addr ip_addr_t’
} ip_addr_t;
^
Compiling /data/espsense-main/.pioenvs/espsense-main/lib0f4/AsyncTCP-esphome/AsyncTCP.cpp.o
*** [/data/espsense-main/.pioenvs/espsense-main/src/main.cpp.o] Error 1
========================= [FAILED] Took 24.36 seconds =========================
I think @james_reilley’s usage is the first attempt at running it on an ESP32 board, whereas most cases were probably on the ESP8266-based converted smart plugs, and it required a few tweaks to support it. Looking forward to hearing about his project in the future!
I was reading in the Finding Electric Vehicles - Fail thread about all the trouble that Sense is having detecting EVs and now that I am having such good luck with my TesSense.py app (thanks Charles), I wonder if there isn’t a 240v power meter that could be used to plug into the NEMA 14-50 in the garage and then plug the EVSE into it and use this software to report the results to Sense. Sure, it won’t help with detection, but not much is, there are so many EVs and so many EVSEs, there is a lot standing in the way of detecting an EV.
My app shows all the AC charging data for the car at home in the Sense app, and I can go back and look at when I charged and how much for as far back as I care to scroll in the app. Actually not sure how far back Sense data goes, but I have never hit the end.
I think ESPSense would be a great solution for people who can’t use the recommended Flex Sensors as they already use their second port on their Sense for Solar or a second 240v input.
I recently replaced my 120v dryer with a 240v heat pump, so my KP115 doesn’t work anymore. I did a quick google search and don’t see any 240v kill-a-watt type device or even energy monitor, at least a plug-in one. If someone does know of one, let me know!
There are cheaper DIY options like CircuitSetup, which can run ESPHome and therefore ESPSense, but they’re certainly less plug and play. Also you need to measure the legs individually so it’s not as well suited to being used at a wall plug.
