Thanks! I’m not afraid of soldering, just not set up to start a new project like that right now.
Now this sounds like a great starting point, thanks!
Edit: Does it work directly with HA or do you need their app?
Thanks! I’m not afraid of soldering, just not set up to start a new project like that right now.
Now this sounds like a great starting point, thanks!
Edit: Does it work directly with HA or do you need their app?
TP Link has it’s own integration here, but in order to set up the sockets in the first place you need their app. Once they’re set up, you can work away with ha. I keep the app on my phone because since ha v0.90 (I think) one or more of the switches will occasionally drop out. The app is handy in those instances when you want to make sure that the switch is actually still working. (In regards to that problem, it seems that a restart is the cause of and solution to, the occasional drop out issue.)
Does it work directly with HA or do you need their app?
Just echoing what @Sidioussam said above - I still kept the TPlink app on my phone as it allows remote access to the switches. But even with the App removed, HA works OK with the switches for me.
My TP Link HS110 is on it’s way, thank you Codec303 and Sidioussam!
I may be back to ask specifics about how to get HA to recognize and use it, if I can’t figure it out on my own. And I’m not against having a dedicated app for this device. I just don’t want that to be the ONLY way to access it.
In regards to setting up, it’s been quite a while since I’ve done it, but if I recall, all you have to do now is the initial setup with their app (Kasa) and then install the integration on HA.
If I recall correctly, the name on HA for each socket is the one you named it when setting up on the app. I’m open to correction on that point. As for setting up on the app, it’s about as straight forward as it can get. Plug in the socket, wait for it’s status light to start blinking, confirm on the app that it is indeed blinking (green I think) and then the app does the rest.
My TPLink HS110 is installed and fully functional. Thanks to all who helped!!
I downloaded the “Kasa for Mobile” app (Android) and followed the directions. TIP: It requires you to choose to set up an account, or exit. If you choose to set up an account, but scroll down to the bottom instead, there’s a link to let you continue without setting one up. It shows a nag screen of all the things you can’t do. Which of course you can do with HA anyway
After that, the setup is straightforward. It scans for and finds the device, prompts you to give it a name, and your WiFi password so it can join your local network.
Once there, the TPLink integration documentation takes over. I set up a DHCP reservation on my router so the address doesn’t change (not sure if this is required, maybe it’ll auto-detect each time.) You can get the host name, IP address and MAC address right from the app, or from your router.
The integration will detect the device, but not all the energy monitoring “stuff.” For that you need to edit configuration.yaml.
The example in the documentation is wrong! I used it and got an error validating the configuration file. The documentation indicates a period “.” in the name. This is not accepted. For example, Use “switch_my_hs110_amps” instead of “switch.my_hs110_amps”.
Once I got the YAML syntax corrected, the data started flowing. My test case is a sump pump in my cellar. I have a fieldstone foundation and we had a rainy day, so the pump ran a lot, but in short bursts. I added a history graph card to Lovelace to show the current draw, in Amps. I could also have used Watts. Basically, each spike is one time the pump came on and back off:
For the sump pump, a problem would show up as a prolonged spike. Either the motor was locked and the pump not turning, or there was so much water the pump couldn’t keep up. Presumably, I could set up a notification for that. Alternatively, if the pump never came on, that might also indicate a problem, such as a stuck float switch. This is exactly the data I was looking for!
Hey Tom - This is fantastic information, and happens to be almost exactly the problem I want to solve (I want to know when my ejector pump locks up). Thanks so much for sharing the info back here!
One question for you before I get my own HS110: has your solution held up since you posted here last?
Thanks again,
Ben
This solution has been reliable. It’s already warned me about a couple of “pump stuck on” conditions, as well as allowed me to see that one pump wasn’t coming on at all for too long, so I knew to lubricate the switch (never buying that style pump again!)
My only beef is that these are WiFi devices. The network coverage down in my fieldstone basement isn’t that great. They occasionally drop off the network for a few seconds longer than HA likes, and I get warnings in the log. It doesn’t seem to affect the functionality, however.
There’s been a lot of work lately on the HA integration and this problem is much less severe than it was originally. You can read a lot of it by searching old posts in this forum. But the bottom line is you want DHCP reservations for the IP addresses of these devices, and you want a good, solid IP connection.
I can share the automations which notify me of a stuck pump if it would help.
Nice—this is all encouraging news. Should be able to address the wifi problem over here with careful placement of my mesh network nodes. Yes, please—I’d love to see the stuck-pump automations!
Here’s one of the automations:
- id: WestPumpStuck
alias: Pump Stuck On - West
description: Notify if West pump runs > 90 seconds
trigger:
- above: '2'
entity_id: sensor.switch_West_sump_pump_amps
for: 00:01:30
platform: numeric_state
action:
- data_template:
message: West Pump Running for over 90 Seconds. Current is {{ states('sensor.switch_west_sump_pump_amps')
}} Amps
title: West Pump Current Warning
service: notify.user1_sms
- service: switch.turn_off
data: {}
entity_id: switch.east_sump_pump
mode: single
It sends me a message, then turns off the switch, if it detects the pump pulling over 2 Amps for 90 seconds.
The user1_sms for the notify service is defined in configuration.yaml as follows:
notify:
- platform: smtp
name: user1_sms
server: smtp.gmail.com
port: 587
sender: [email protected]
encryption: starttls
username: [email protected]
password: MyPassword
recipient: [email protected]
1235551212 replaced my Google Fi phone number.
You’d need to look up how your cellular provider specifies email to SMS.
You’d also need to look up your email provider’s SMTP server, port and encryption parameters.
[Edit: I was looking at this automation, and noticed that the action to turn off the switch was somehow twisted and would never work. I’m not even sure how it got that way, but this was one of my earliest automations so it could have been corrupted by some interim change. At any rate, I fixed it, above.]
Sweet. The outlet is due to arrive in a couple of weeks. I’ll report back on how I do. Thanks again, Tom!
PSA: TP-Link has discontinued the HS-110 (I just found out when I wanted to order another one). They have replaced it with a KP-115. It has a much better form factor. I ordered a couple that arrive at the end of the week. I’ll report back once they are set up and tested.
The Amazon link is: TP-Link KP115 Energy Monitoring Smart Plug, White - - AmazonSmile
Thanks, Kirby–that could save me a lot of trouble down the road. I had a hard time tracking down the HS-110 and now I understand why.
I’m using Shelly Plug US to monitor the kitchen kettle power consumption and notify when it’s done boiling. It works over wifi, no hub necessary. Works great with the Shelly HA integration. Recommended.
Success! Using the automation below, I got this working. Or at least, when I lowered the trigger time to 5 seconds and ran my power drill on the switch, the thing turned off and sent me a text. that if/when the pump locks up, this will trigger as planned.
Only notable change is that I had the switch turn off via the “switch” domain, which I picked via the GUI, because I noticed that doing this caused the switch’s history to reflect that it was the automation that turned it off (whereas the original approach you suggested, while working fine, didn’t indicate what/who turned it off). Here’s what the switch’s history looks like now, right after the action was triggered and then I turned it back on:
- id: EjectorPumpStuck
alias: Ejector pump stuck on
description: Notify if ejector pump runs > 90 seconds
trigger:
- above: '2'
entity_id: sensor.ejector_pump_amps
for: 00:01:30
platform: numeric_state
action:
- data_template:
message: Ejector pump running for over 90 Seconds. Current is {{ states('sensor.ejector_pump_amps')
}} Amps
title: Ejector pump current warning
service: notify.ben_sms
- type: turn_off
device_id: [A LONG DEVICE ID APPEARED HERE]
entity_id: switch.ejector_pump
domain: switch
mode: single
Interesting, thanks!! I never knew you could do that. All the examples I’ve seen use the service. Good to know there’s a better way!
I use LightWaveRF Gen 2 which is
Just reporting back on the KP115. They arrived (I bought two). Plugged them in, set them up using the Kasa app (which means it just connects it to your home WiFi), and then reloaded the TP-Link Integration within HA (click on the three vertical dots to get the reload option). It added the two new switches. That was it. I created a sensor that reports the power level like this:
smart_plug_vaporizor_main:
friendly_name_template: "{{ state_attr('switch.main_floor_vaporizer','friendly_name')}} Current Consumption"
value_template: "{{ state_attr('switch.main_floor_vaporizer','current_power_w') | float | round(1) }}"
unit_of_measurement: 'W'
Then added the sensor to the front end, along with a switch and timer to to make sure the vaporizer comes up to power within 2 minutes (otherwise it’s low on water). I trigger the switch off once the power level drops below a threshold of 160 W - that’s when the water is low:
I just ordered a Zooz ZEN25 double plug. It works over the Zwave network. I’m going to set that up to see how it works in the couple of days - it is supposed to have two controllable outlets on each side (and even includes a couple of USB ports that I don’t need). It’s form factor is similar to the KP115, which means you can plug two of them into a standard outlet.
More on this one in a couple of days!
I tend to always use the domain name in all my service calls if I can. I figure otherwise, HA has to figure out if it’s working with a light, a switch, a media player or something else. That seems a little less efficient to me - and now you may have found that not all the domain information is available otherwise. Thanks for figuring that out!
I did receive this plug, and it was as advertised. It is a double plug and both plugs are controllable. Setup was very easy - put the zwave network in ADD NODE
mode, plug in the plug, it blinks for a couple of moments and then poof - it’s part of HA.
Pros:
Cons:
When I need another smart plug, and it’s for something under 10 amps, I’ll order this one again.