Oh yeah, nice! I’ve always eyed the Shellys but haven’t ever picked one up. If you give it a shot, let me know if you catch any bugs or have any recommendations for the MQTT implementation.
Ok, took a little longer than I had planned, but I finished the homeassistant integration. It’s a new integration called “emulated_kasa” that works pretty much as I showed earlier: https://github.com/home-assistant/core/pull/39630
PR has been merged in so it looks like that should be in the 0.115 release coming out on the 17th (beta on the 7th)
3 Likes
Nice! Cool to see SenseLink be integrated (in part) into Home Assistant so quickly.
Any good improvements you noticed/developed that could feed back into the “upstream” SenseLink repo? I’m by no means a Python expert, so I’m sure there are things that could be better.
It might be worth noting somewhere in the docs (if not already there) that in order for TP-Link emulation to work, your Home Assistant instance and Sense monitor do need to be on the same subnet (or alternatively have UDP broadcasts echoing across subnets, but that’s less usual). Personally I have Sense on my IoT subnet along with my smart plugs and my HASS instance on my trusted subnet, so I’d need something like SenseLink to broker across regardless. If anything it might reduce some of the “why isn’t this working?!” help requests!
1 Like
I had to split off a lot of the code to get just the essentials. One major change was the PlugInstance now takes an id which the device id and mac are generated from rather than doing it randomly so the device doesn’t change each time.
The changed files are here:
https://github.com/scottbonline/sense/blob/stable/sense_energy/PlugInstance.py
https://github.com/scottbonline/sense/blob/stable/sense_energy/SenseLink.py
1 Like
Very nice! I’m looking forward to folding SenseLink into my Home Assistant install.
I’ve been using this for about a week now and it single-handedly has made Sense actually useful. Appreciate what you’ve done here, and I’m eager to use it to further extend and fill in all the gaps I had with Sense so I can actually have enough data to make an impact on our usage!
As a quick FYI - I came across this after first going down the HS110 route only to find they were getting more and more scarce (And expensive!) - but I had a dozen or so of the Etekcity smart plugs with energy monitoring already within the house that use the VeSync app. Plugs right into Homeassistant, so that integration is super simple. And even better, those plugs are less than $10 each, sometimes as low as $7 on sale.
If you’re looking to do something similar, here are the links - they have a normal and now a slim form factor - I have both and they work flawlessly here:
Normal Size → https://amzn.to/2REJ6YY
Compact Size → https://amzn.to/3iIeMbV
Hope that helps!
3 Likes
Hi folks, I discovered the HS110’s integration to drastically help improve accurate readings that sense was reporting. The problem that I’m running into (as I see everyone else is also, is there are no 240v smart plugs in the market today. So most of my heavy energy consumers are still not reported, reported as “always on”, or “other”, which is useless to me.
This thread spurred my interest… if I were to install the emporia vue energy system with 16 CT sensors, then could I use the “vuegraf” ability to export the readings out to some system that could send the data onto sense as if it were an HS110?
Grasping as straws at this point as I like Sense’s monitoring/functionality, but need drastically more granularity than they currently provide, and even after 3+ years of it in operation, 70+% of my power is STILL “always on” or “other”, which makes it worthless to try and report on
It would be doable, but from a quick look it appears like the Emporia Vue API isn’t a real time API that talks to the actual local device. That is, it seems to focus on pulling history-type data from their servers, but not the active power usage that you’d want to report as an emulated HS110.
That approach works well for exporting to Grafana, but not as well for the HS110 emulation. We can’t “inject” history data into Sense via the emulation - the HS110s (real or fake) are just polled for usage every 2 seconds, and their responses are stored by Sense for display and usage history.
Looks like the API can support data requests at the second-scale at least, but Sense requests an update every 2 seconds…not sure they’d like getting (unofficial) API hits that frequently! Vuegraf defaults to 60 second update intervals, for comparison.
Couple inexpensive ways to do this. Both involve using an esp8266, a couple resistors, a capacitor and a ct sensor. This github repository has a good write-up, diagram and video of how to build the device. The only issue doing it this way is you’re only going to get apparent power, not active power. You can create a simple circuit to measure active power but you’re probably going to need an arduino to do so.
You can then use ESPHome with espsense to send the power info directly to sense or you can use ESPHome to send it to home assistant then emulated kasa to send it to sense.
There are other devices you can buy such as a pzem-004. You can use ESPHome and espsense and and esp8266 with it, as well.
These are not a plug and play like an hs110 but they will give you what you are looking to do at a very reasonable price.
Another option that I’ve been following since its inception is itoawatt. You can monitor all your 240V devices at your power box with it and use HA emulated kasa to send the data to sense.
1 Like
I was trying to set this up with mqtt for my shelly em’s but I’m not having any luck with it. I can see SenseLink is picking up the value, but doesn’t appear to be sending the new power value.
DEBUG:root:Power topic update for Range: 36.14
DEBUG:root:Power updated for Range: 36.14
DEBUG:root:Broadcast received from: xxx.xxx.xx.xx: {'emeter': {'get_realtime': {}}, 'system': {'get_sysinfo': {}}}
DEBUG:root:Sending response: {'emeter': {'get_realtime': {'current': 0.0, 'voltage': 120, 'power': 0.0, 'total': 0, 'err_code': 0}}, 'system': {'get_sysinfo': {'err_code': 0, 'sw_ver': '1.2.5 Build 171206 Rel.085954', 'hw_ver': '1.0', 'type': 'IOT.SMARTPLUGSWITCH', 'model': 'SenseLink', 'mac': 'xxx', 'deviceId': 'xxxx', 'alias': 'Range', 'relay_state': 1, 'on_time': 10.835297107696533}}}Hmm something could be screwed up! You’re on the leading edge of using the MQTT integration, I think - could you provide some of your config details?
From your debug log it looks like it’s getting the data into the ‘data store’, but SenseLink isn’t putting it into the response for whatever reason.
Sure. I did verify the value is numeric, simply my publishing a string to that topic and seeing the error handled by senselink for a string.
sources:
# MQTT
- mqtt:
host: xxx.xxx.xxx.xxx
port: 1883 # Optional
username: xxx
password: xxx
plugs:
# Direct power reporting example
- Range:
mac: 53:75:31:f6:4d:01
alias: "Range"
power_topic: shellies/shellyem-range/power
I also was trying this, since I have the shelly monitoring both power sources at 120, because the range has a built in microwave that only uses 120 on the 240 feed. I needed the voltage from each half to make the shelly reporting correct. I saw the same behavior and simplified it to the above with a joined mqtt topic to see if the aggregate was the cause.
Speaking of which, should we also be specifying the voltage to sense?
sources:
# MQTT
- mqtt:
host:
port: 1883 # Optional
username:
password:
plugs:
# Direct power reporting example
- Range1:
mac: 53:75:31:f6:4d:01
alias: "Range1"
power_topic: shellies/shellyem-range-dryer1/emeter/1/power
# Direct power, with state
- Range2:
alias: "Range2"
mac: 53:75:31:f6:4d:02
power_topic: shellies/shellyem-range-dryer2/emeter/1/power
# Aggregate
- aggregate:
plugs:
- Range:
alias: "Range"
mac: 53:75:31:f6:4d:03
elements:
- Range1
- Range2
MQTT Explorer for Shellies
Found the issue,
Needed to add this to class MQTTSource(DataSource): in DataSource.py
def get_power(self):
# Return internal value
return self.power
Once I did that it started reporting properly
Nice! Thanks, not sure how I managed to miss that. I’ll push a new release with that fix later today.
1 Like
New version is pushed and Docker images are building, thanks again for finding the fix.
On the topic of reporting voltage - I’m not sure if Sense uses it right now (doesn’t seem to in the UI, at least) but on ESPSense I took the approach of if we have a way to measure it, we might as report it like a real HS110 does. SenseLink currently just assumes 120V but since the Shelly EMs report it via MQTT it could be added as another topic to watch.
Pulled the latest, worked as expected. Thanks for the quick fix!
1 Like
Wanted to ask an opinion to validate whether something will work with this solution. Like most people I have a UPS hooked up to my NAS, networking equipment, etc. Many UPS provide real-time load status of the load plugged into the device. I can see these attributes via NUT server running on my NAS. Here is an attribute list. NUT (network UPS tools) servers can also run on RPis too.
So curious if these two solutions could be bundled so Sense could be updated with load of my equipment. These devices are a large majority of my always on bubble.
Yep that would be totally doable - I just recently picked up a UPS too, but haven’t really looked into how to get data out of NUT servers. Essentially SenseLink just needs a way to query a device for power usage or receive incoming data on changes (like with MQTT), and it can turn that around to report to Sense. Looks like there are a few Python libraries for NUT, so I’ll have to check that out using mine.
1 Like
Definitely a few DIY ways to do it, I was leaning towards the Shelly’s that a few folks detailed below, since they can support both 50a and 120a CT’s for a 220 line and are a bit more plug and play → https://amzn.to/34eUFft
But before I pull the trigger on that, I started looking to a raspberry PI option that could give me more than a pair of CT’s so I can hit several of my major 240v circuits that don’t have anything detected on them currently. There are multiple Hat configurations, detailed here → Raspberrypi Current and Temperature Sensor Adaptor - lechacal
That allow as many as 8 CTs to be connected to one PI, and I figure a simple script can dump the data out through MQTT fairly easily.
May be a few weeks until I get to do this, but I’ll definitely pop an update out here once I get it knocked out.
2 Likes
Those RPi boards/hats you linked look nice, they get you a clean prebuilt hardware solution. They could probably be used with ESP32+ESPSense as well since they just communicate over serial, but really the price difference between an ESP32 and an RPi isn’t that much, and it would work out of the box with an RPi. Looking forward to your future update!