TP-Link HS110 Smart Plug disappears after latest firmware update

Third party integrations
182

Ah ok, so I think the problem you are having with those other units:

Model HS110 - HW Version 4.0 - Firmware Version 1.0.5
Model HS110 - HW Version 2.0 - Firmware Version 1.5.6
Model HS110 - HW Version 2.0 - Firmware Version 1.5.6

Is the same as I was having. It seems to be a bit of an issue with either the itegration, the plugs or both. I had the same issue with 4 of my other plugs (that didn’t need the upgrade/downgrade) and I solved it by:

  1. Assigning each plug a static IP - I use OPNsense, so this was easy - hopefully your router allows this. In fact, every device has a static IP on my LAN. Only guest devices take from a pool on a separate VLAN.
  2. Edit your config yaml to be something like this:
tplink:
  discovery: false
  switch:
    - host: 192.168.1.1
    - host: 192.168.1.2
    - host: 192.168.1.3

Personally, I’d assign static to all your TP-Link plugs, and list as above. Then remove and re-add the integration, that should solve it. :slight_smile:

183

Many have reported good results hard-coding the IP addresses in configuration.yaml.

I’ve had the opposite experience. I’ve had better luck leaving discovery on (the default) and not adding any host: lines.

Thus, all I have is one line, tplink:, in my config file for TP-Link.

YMMV. I’m just offering options.

184

It truly is a YMMV situ. I had nothing but problems with discovery. I found the above mentioned config to specific IPs on another thread (don’t remember which one) and they’ve been solid ever since.

185

@elementoulis any luck? :slight_smile:

186

Hey @ellnic thanks for the interest. I didn’t manage to try out your suggestion. I tried to update the hassOS the other day and my raspberry pi never came back up from that so my whole smart home has been dead for a while…

But… From what I’ve noticed (before my incident) is that while the plugs have an IP assigned and while that IP doesn’t change (due to disconnects or router restarts) then they are accessible through HA. So most likely your input above is valid.

187

@elementoulis I feel for you.

I experienced this several times early on in my HA journey and it gave me such a headache that I scrapped the Pi and moved to a NUC with Proxmox. HA runs as a Proxmox VM and I use the snapshot feature before and after any changes. The entire thing is then backed up to a ZFS array. This makes rolling back, restoration or hardware migration very easy. Whenever I update HA and it fails to come back, I roll back to the snap I just took and leave it until the version after. Hasn’t failed me yet. Obviously the NUC is not as energy efficient as the Pi, but when you have basically your entire house running on HA, downtime is a pretty major issue.

I keep the Hue hub for light bulbs and 90% of the hue dimmers so that I don’t get hung by the family in the event of HA downtime (and ease of lighting effects). Hive also has it’s own hub so we can still heat. But I have a Z2M Zigbee network on a separate channel for everything else. I have found this approach of Proxmox, Backup, and keeping the 2 hubs to be very resilient.

Most routers will routinely give the same IP to a device even if assigned by DHCP. I think the issue is more about the discovery element of the integration, so definitely give the static assignment a crack when you’re back up and running.

I hope you get back up and running again soon!

188

I had no idea the firmware would break my working environment with my HS110 plugs. 1 of them got the new firmware, the other did not. I could not figure out why, not a programmer, so I was very happy when I found this page.

I wrote to [email protected] and they same day wrote back with potential risks using local APIs, but to

"If you agree, please reply “Yes”.

Their commitment is to push the beta firmware to me via Kasa app in 10 working days

189

To be honest, there is almost zero risk unless your LAN is compromised or you unknowingly have some malicious actor at your house. This obviously means there’s a bigger issue than a couple of plugs with the local API. I have smart plugs like these on a separate VLAN, and they are blocked from communication with anything but my phone and Home Assistant. I can’t foresee any issues with this. TP-Link are just covering themselves. The reason one of them got the update and the other did not is probably the HW revision… the one that did is most likely 4.1 and the one that did not is 2.1, I’m betting. You can find this on the label on the back of the plug.

190

FYI-

I’ve recently learned HS110’s need the correct time for today’s kwh usage attribute to work. I broke that when I blocked my HS1xx devices from WAN access via my firewall. They need access to pool.ntp.org servers for setting the time when they boot via NTP.

I didn’t notice it for a number of weeks because none of my devices had rebooted. The other day I had a brief power outage which caused all the devices not on UPS to reboot.

I suppose if I was still using any of the built in timers on the devices I would have figured it out sooner.

All of my HS110’s are hardware 1.0, running 1.2.5 build 171206 so I’m not sure if they are safe from the new firmware issue.

Is there a good place to check for current status of which devices are affected and where things are in terms of the new protocol implementation?

1 Like
191

Good spot!

I think this is the github project you want, unless I’m mistaken: https://github.com/python-kasa/python-kasa

It might be worth contacting TP-Link again and requesting that they add the ability to specify a local NTP server. All my plugs are blocked from WAN too and when you mentioned you would have had an issue with timers as well as the power readings - this reminded me that I was using the timer on one of them before I got it setup with HA again. I noticed one night that it had stopped working but I didn’t think too much of it at the time because I was due to setup with HA again. At that point, I had already blocked from WAN so this ties in with what you’re saying.

It might be worth a few of us contacting TP-Link about it because it also affects the power readings. Bearing in mind that they are concerned about the vulnerability of the local API, I am sure they will appreciate that we have taken proactive steps to secure our local API plugs by restricting them in the firewall.

I will email when I get a moment later :slight_smile:

192

I’m watching the python-kasa repo on github. I’ve submitted issues to document the internet NTP requirement and also suggest a check/warning if the clock isn’t set.

TPLink should probably document the internet access requirement for timers/clock setting. Probably won’t be much of a priority for them as they likely hear about only a small number of cases where people expect to be able to use the timer functionality without internet access.

Does anyone know if the iOS/Android app has any ability to do local communication if the cloud isn’t available? If it does I suppose they could offer an option through the app to set the time,date and timezone if no internet access is available.

Note: My DHCP server advertises NTP servers to clients, but I’ve read this is ignored by most things other than some systemd-based Linux distros.

rytilahti mentioned in a github issue that someone had started work on a PR that didn’t get finished that could set the timezone via local access and could possibly set the clock under some limited conditions. GadgetReactor/pyHS100#55

Another thing to note: He mentioned that there are undetermined cases where the devices energy consumption trackers that are available through the project don’t match the Kasa app, though there isn’t enough info to figure when/why this might be.

Finally I thought I should mention, without setting the clock, energy tracking can still work without the clock being set if you use Home Assistant’s utility_meter integration to define daily, weekly, or monthly sensors:

utility_meter:
  ice_maker_daily_kwh:
    source: sensor.ice_maker_total_kwh
    cycle: daily
  ice_maker_weekly_kwh:
    source: sensor.ice_maker_total_kwh
    cycle: weekly
  ice_maker_monthly_kwh:
    source: sensor.ice_maker_total_kwh
    cycle: monthly

Hope this helps.

1 Like
193

Does anyone know if the iOS/Android app has any ability to do local communication if the cloud isn’t available? If it does I suppose they could offer an option through the app to set the time,date and timezone if no internet access is available.

If a smart plug is blocked from internet access the app still detects it in the network (by MAC address I assume) and reports this as “local only” (I guess, I have a german translation to that sense), it can be turned on and off, but it reports no stats at all.

Aside from that: I would like an ice maker please. :slight_smile:

194

@NamCisum - Thanks for the info. Forgot that I have all I need if I wanted to run some experiments.

The ice maker uses between 1.0-2.5 kWh a day according to the HS110. No idea how accurate that is. Unfortunately, I can’t easily automate it to tell it not to drop ice at night.

195

FYI: For anybody who lands in this thread. TP-LINK have stopped offering the Beta software (ver1.1.1) since Feb 8, 2021 :frowning:

I’ve written to them twice - once to ask for the v1.1.1 firmware - which was declined - and once more to ask if the 2020-02-08 deadline can be extended. Maybe if more people ask as well them might help us out again.

I wouldn’t be hopefully of this new local API they are talking about. It sounds to me like they would want Home-Assistant devs to sign up to some commercial agreement for access to it. It sounds like it would really mean having to use the TP-LINK cloud solutions instead of a true local API. That’s my gut feeling of where this is headed.

see the other thread:

196

Sorry I’m late to this, but thank you for the heads-up. I don’t really look at the total daily usage value for what I’m doing now, but I’ll keep that in mind in the future!

For the record, my devices have been blocked by the firewall for some months, and have been powered off at least once, but the time seems to be accurate. The only way I can tell is the Kasa app shows “Today - Current Runtime” and at 10:30 AM it changed to 10.5 hrs. Since this device hasn’t been turned off, I assume that means it reset at local midnight.

Yes, mine does on Android. And it reports all the stats you’d expect. It looks like I can set up schedules and timers and all that too, although I don’t happen to use those features.

197

Thanks for this, I thought I would have to write a series of automations with counters etc to obtain this information! I will test this out later this week.

I noticed with my TP-Link HS110 that after a power cut last week the sensor for “daily kwh” changed in home assistant to “total kwh” - this may be because the plugs are completely blocked from outside internet and can no longer contact the time server. This suits me fine now that I’ve discovered the utility_meter feature!

198

I’ve got two smart plugs :

  • HS110, hardware 2.1, firmware 1.5.10 -> works well since a long time
  • HS110, hardware 4.1, firmware 1.1.0 -> suddenly stopped working a few days ago

Could someone share the link to the fixed “beta firmware” ?

199

VERIFIED and viable path to workaround found

Head over to this thread on github
https://github.com/plasticrake/homebridge-tplink-smarthome/issues/154

Yes, I know it’s a HomeBridge thead and not Home Assistant, but hear me out.

I can verify that I have regained local control of my HS100 (UK) V4 plug
(with Firmware 1.1.0) using the: python-kasa library .

From terminal on my laptop I can see the plug on my local network,
obtain its state information and most importantly turn it ON and OFF.
All from the command line.

Again, to emphasize, this is ALL on my local network. I’m not using TP-LINK cloud service (or any cloud service). I have these TP-LINK plugs running on a separate wifi network that physically does not have external access to the internet.

So this verifies that we can regain local control of these plugs without port 9999 thanks to the python-kasa lib.
Next step is to integrate it into the home assistance TP-LINK plugin
or maybe spin up a new one.

It’s also possible we could use this regained access to flash the plugs with an older
version of the firmware (or the beta firmware).
But I think the better solution is to look to a future without port 9999 access.

Kudos and thanks to Blake (aka ghostseven) over on the HomeBridge thread and the major kudos to the python-kasa devs at https://github.com/python-kasa/python-kasa

1 Like
200

For those needing a solution now or do not want to rely on TP-Link keeping things steady my tests showed Shelly Plugs to be closest: Can be configured more or less the same way (connect to them as WiFi AP, connect them to your wifi, HA discovers them or you assign a fixed IP and point to it), all local / no cloud needed, support MQTT if you want that and seems to be working reliably. Also way better commitment to integration with HA (actively supported, not just barely tolerated). Price is roughly the same as the HS110, bit more expensive than the HS100.

1 Like
201

@NamCisum - Thanks for the tip. I had not looked at the Shelly plugs yet. I’ve been waiting for the TPLink KP115 to be supported, because I believe the HS110 is discontinued.

How does the Shelly Plug’s power metering compare to the HS110s? (Power metering is main reason I’m using HS110s)