Which smart outlet (plug) do you use for power monitoring?

I see a number of “smart plug” devices which allow you to remotely switch whatever’s plugged in, and/or monitor how much power it’s using. I would probably be OK without the switching capability, if I could at least see the current draw in HA.

Anyone have any recommendations for a device that’s reliable, relatively inexpensive, and works with HA on ZHA or WiFi out of the box (no third-party hubs, no flashing firmware)?

I’d prefer a simple plug-in, rather than one that’s installed inside the outlet box. Not that I can’t do that, but I’ve noticed some of these things tend to fill the box, which would prevent using it on boxes which already have other connections in them.

1 Like

Using a few BW-SHP2 plugin and a few BW-SHP8 inwall flashed with tasmota then a template from blackadder templates github and could not be happier. Though they do need a bit of calibration. Be aware that this appears to be an oem product and you can find the exact same device with other branding.

I got them relatively cheap from banggood, prices now seem to have increased slightly to 12 and 14 euros respectively.

Intermittent Tech did two videos about the BW-SHP2 I believe.

Edit: sorry only now I see you do not want to flash a device. Shame, but you can always use the original tuya firmware at first and if that is not delivering what you need, you can always consider flashing which could even be done solderless using tuyaconvert 2.0.

1 Like

I use a Sonoff POW r2 but this needs to be Flashed with Tasmota to get the best out of it.

I also use a TP Link HS110 which needs no firmware flashing, and works great with HA. :slight_smile:

1 Like

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.)

2 Likes

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.

1 Like

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.

1 Like

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 :slight_smile:

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:
Pump_Current

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!

1 Like

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.]

2 Likes

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

1 Like

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.

1 Like

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.

1 Like

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. :crossed_fingers: 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

Thanks so much, @CaptTom and @KSC.

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

  1. Elegant
  2. Reliable in my experience (some caveats).
  3. Very expensive.