TP-Link HS303 Driver Powercut Restore Problem Reconnecting Driver

iancarp

New Member
View Badges
Joined
Mar 29, 2022
Messages
9
Reaction score
7
Location
Faversham
Rating - 0%
0   0   0
Hi Has anyone using the hs303 driver experienced problems when recovering from a powercut (simulated)?

I've got a KP303 3 port extension with a static IP address and it works great I have control over the device no problem. When I simulate a power outage... The TP-Link is reinstated to it's previous state and the reef-pi UI is reporting the same status as before the reboot.

However when I try to control the outlet I get the error:-

{"error":"Failed to update. Error: can't update outlet Kasa #1-2 driver lookup failure: driver by id 3 not available - can't get output pin"} | HTTP 500

Reloading reef-pi resolves the problem however if I'm away and this were to happen my heaters etc may not come back on if the system calls it (control via app works fine).

Is anyone else experiencing the same issue?

Ian
 

robsworld78

Well-Known Member
View Badges
Joined
Feb 14, 2020
Messages
952
Reaction score
1,280
Location
Edmonton, Canada
Rating - 0%
0   0   0
Hi, I think that's because reef-pi is starting before the Kasa connects to your network. Try the steps below, this will stop reef-pi from starting until the Pi is connected to the network, if that doesn't happen in 90 seconds it'll timeout and reef-pi will startup without it.
  • Run the command sudo nano /lib/systemd/system/reef-pi.service to edit the file
  • At the bottom add the following two lines.
    • After=network-online.target
      Wants=network-online.target
  • Press CTRL + S to save
  • Press CTRL + X to exit
  • Run the command sudo reboot to reboot
Hopefully that works.
 
OP
OP
iancarp

iancarp

New Member
View Badges
Joined
Mar 29, 2022
Messages
9
Reaction score
7
Location
Faversham
Rating - 0%
0   0   0
I have applied this configuration and it sort of worked but not completely...

If I reboot the reef-pi and restart the kasa everything is OK. However if simulate a real powercut which also includes restarting the router the same error occurs... I did a ping while resetting everything the devices come up in the following order [Router, Pi, Kasa] but there's only a second or so between the pi and kasa coming online a reload fix's the issue again...

I tried the config under the [Unit] and [Install] in reef-pi.service
 
OP
OP
iancarp

iancarp

New Member
View Badges
Joined
Mar 29, 2022
Messages
9
Reaction score
7
Location
Faversham
Rating - 0%
0   0   0
Could it be that the reef-pi tries to connect to the kasa but as the kasa is not online (yet) it fails and doesn't retry?
 

robsworld78

Well-Known Member
View Badges
Joined
Feb 14, 2020
Messages
952
Reaction score
1,280
Location
Edmonton, Canada
Rating - 0%
0   0   0
Could it be that the reef-pi tries to connect to the kasa but as the kasa is not online (yet) it fails and doesn't retry?
Yeah that's likely what's happening. Maybe try adding a delay to the boot of the Pi, this might allow the Kasa to connect first. Do note that the controller will be down during this period.

Edit the /boot/config.txt file and add the following line. The 60 is number of seconds to delay it.

boot_delay=60
 

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
i am unsure about the boot delay thing. a power cut will reboot everything, in that case kasa should come online before pi (since kasa is a micro controller). i prefer to just proof guard against pi rebooting. whole house power cut is rare, but generally does not impact my setup. If kasa reboots that should not cause any issue, unless pi is also rebooting at the same time and coming online before kasa. The connection failure will impact the driver loading only during the startup phase. During run time, even if kasa communication fails intermittently it should not be a persistent issue.
 
OP
OP
iancarp

iancarp

New Member
View Badges
Joined
Mar 29, 2022
Messages
9
Reaction score
7
Location
Faversham
Rating - 0%
0   0   0
Yeah that's likely what's happening. Maybe try adding a delay to the boot of the Pi, this might allow the Kasa to connect first. Do note that the controller will be down during this period.

Edit the /boot/config.txt file and add the following line. The 60 is number of seconds to delay it.

boot_delay=60
Nice one @robsworld78... That's got it! a boot delay of 25 was needed. I tried at 15 seconds but this was to short... It worked OK at 20 seconds but airing on the side of caution I settled for 25 Secs... Many Thx :)
 
OP
OP
iancarp

iancarp

New Member
View Badges
Joined
Mar 29, 2022
Messages
9
Reaction score
7
Location
Faversham
Rating - 0%
0   0   0
i am unsure about the boot delay thing. a power cut will reboot everything, in that case kasa should come online before pi (since kasa is a micro controller). i prefer to just proof guard against pi rebooting. whole house power cut is rare, but generally does not impact my setup. If kasa reboots that should not cause any issue, unless pi is also rebooting at the same time and coming online before kasa. The connection failure will impact the driver loading only during the startup phase. During run time, even if kasa communication fails intermittently it should not be a persistent issue.
Thanks @Ranjib It's definitely persistent and repeatable - so to summarise my WiFi connectivity order was 1) Router > 2) Reef-Pi > 3) Kasa and I was recieving the error:

{"error":"Failed to update. Error: can't update outlet Kasa #1-2 driver lookup failure: driver by id 3 not available - can't get output pin"} | HTTP 500

I added the following lines to /lib/systemd/system/reef-pi.service

After=network-online.target
Wants=network-online.target


I also added the following /boot/config.txt

boot_delay=25

My WiFi connectivity order is now 1) Router > 2) Kasa > 3) Reef-Pi and the Kasa connects every time.
 
Last edited:

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
Wow. I’m glad it worked out. Thank you for sharing the specifics I bet others will hit this and we can share this learning
Thanks @robsworld78 , I can see how that boot Param is critical in this context
 

robsworld78

Well-Known Member
View Badges
Joined
Feb 14, 2020
Messages
952
Reaction score
1,280
Location
Edmonton, Canada
Rating - 0%
0   0   0
Nice one @robsworld78... That's got it! a boot delay of 25 was needed. I tried at 15 seconds but this was to short... It worked OK at 20 seconds but airing on the side of caution I settled for 25 Secs... Many Thx :)
Right on, got lucky on that one. Thanks for letting us know.
 

the register

Community Member
View Badges
Joined
Apr 16, 2009
Messages
49
Reaction score
45
Rating - 0%
0   0   0
FYI I have a GitHub issue tracking this same problem. My personal take is I think right now, as currently setup, it's not safe to use reef pi in combination with the kasa power strips. As you also saw the kasa strip connectivity isn't robust currently.

In the issue we're discussing solutions, but IMO that's a bit of a landmine in using it. It'll work fine in the happy path cases, but then this issue arises and leaves the system in a broken state until you realize it. I'm not even sure if that'd trigger a health check failure/notification. Hopefully we can work out a fix soon, but beware.

The kasa single power plugs don't however have this problem. While the single plugs can become unavailable, but will self recover.
 

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
FYI I have a GitHub issue tracking this same problem. My personal take is I think right now, as currently setup, it's not safe to use reef pi in combination with the kasa power strips. As you also saw the kasa strip connectivity isn't robust currently.

In the issue we're discussing solutions, but IMO that's a bit of a landmine in using it. It'll work fine in the happy path cases, but then this issue arises and leaves the system in a broken state until you realize it. I'm not even sure if that'd trigger a health check failure/notification. Hopefully we can work out a fix soon, but beware.

The kasa single power plugs don't however have this problem. While the single plugs can become unavailable, but will self recover.
I agree with your experience, but i wont call kasa itself is not robust :)

i am using kasa hs303 for over 2 years now without any issue. I run 4+ tanks on it and i would recommend using it. More on this...

What you mentioned (connectivity issues) is what i had experienced early on (late 2017), soon after shelly installation) , that my wifi router was not able to keep up with the iot devices. I switched to google mesh (I think any good mesh or wired or even a good router should do, as long as connection drop is not a systemic issue) which solved this and many more (including security camera and other sensor based deployments).

The reason I'm calling out is that what you mentioned is important, that a wifi based driver reliability is critically reliant on your home wifi (not internet connectivity, but the local network) reliability. If that's (home wifi network) not very reliable I don't think even after we improve the driver it will make a reliable setup. Use DJI power strip or similar wired setup in those cases.

On the improvements of the existing driver, you are absolutely correct @the register , we can change the current driver loading behavior to not be dependent on network. That will prevent reef-pi driver failure in the case where reef-pi reload/reboot and Kasa connectivity impairment both happening at the same time. Because of this second aspect, while i am happy to make that improvement, i am unsure if it will make whole lotta difference. What are the chances of that (reef-pi reload and kasa connectivity impairement) happening to a stable home network or if that's happening a lot, what are the chances kasa or any wifi based control system can be reliable in such setup? Even if the driver loads, the outlets might not work reliably in such cases.

The thing I am most concerned about is about the notification system. I want that to work as long as internet connectivity is there (like equipment control failure leading to temperature or ato induced risks). I'd like to test out that end to end (i.e. kasa driver load failure leading to temperature or ato failures).

Again, thank you for bringing this up @the register , its a very important topic and every bit of progress towards reliability adds up the benefits for all reef-pi users. Even if its not my problem (now :)) , we want reef-pi to work in unreliable network to its best ability. I'll share the details on how to bypass the network call on driver load in github.

cheers
 

the register

Community Member
View Badges
Joined
Apr 16, 2009
Messages
49
Reaction score
45
Rating - 0%
0   0   0
I agree with your experience, but i wont call kasa itself is not robust :)

i am using kasa hs303 for over 2 years now without any issue. I run 4+ tanks on it and i would recommend using it. More on this...

What you mentioned (connectivity issues) is what i had experienced early on (late 2017), soon after shelly installation) , that my wifi router was not able to keep up with the iot devices. I switched to google mesh (I think any good mesh or wired or even a good router should do, as long as connection drop is not a systemic issue) which solved this and many more (including security camera and other sensor based deployments).

The reason I'm calling out is that what you mentioned is important, that a wifi based driver reliability is critically reliant on your home wifi (not internet connectivity, but the local network) reliability. If that's (home wifi network) not very reliable I don't think even after we improve the driver it will make a reliable setup. Use DJI power strip or similar wired setup in those cases.

On the improvements of the existing driver, you are absolutely correct @the register , we can change the current driver loading behavior to not be dependent on network. That will prevent reef-pi driver failure in the case where reef-pi reload/reboot and Kasa connectivity impairment both happening at the same time. Because of this second aspect, while i am happy to make that improvement, i am unsure if it will make whole lotta difference. What are the chances of that (reef-pi reload and kasa connectivity impairement) happening to a stable home network or if that's happening a lot, what are the chances kasa or any wifi based control system can be reliable in such setup? Even if the driver loads, the outlets might not work reliably in such cases.

The thing I am most concerned about is about the notification system. I want that to work as long as internet connectivity is there (like equipment control failure leading to temperature or ato induced risks). I'd like to test out that end to end (i.e. kasa driver load failure leading to temperature or ato failures).

Again, thank you for bringing this up @the register , its a very important topic and every bit of progress towards reliability adds up the benefits for all reef-pi users. Even if its not my problem (now :)) , we want reef-pi to work in unreliable network to its best ability. I'll share the details on how to bypass the network call on driver load in github.

cheers
As much as people these days tend to hate data being reported back to a central place, this is the sort of thing that'd be wonderful to have reported back to a central reef pi system. How often, and how many users, are running into these various issues. Without that it's anecdotal or just a theoretical analysis.

That being said, my anecdotal issue was this was recurringly happening to me, and this thread is another anecdote :). I can't say why exactly I was having this repeatedly, but shrug.

On the theoretical side, I think again this is a much more egregious failure mode than the other failures. Connectivity issues certainly can manifest, and in other situations they are self correcting, but in this one you enter a terminally broken state until the device is restarted. That is worse than normal because it's not self recovering, but also because you're going to be lulled into a sense of safety because generally it is self recovering.

As an example, which is what actually happened to me, I had a reef pi controlling my heater via a kasa strip. I'd convinced myself that was safe because it was all over the local network, and if I had a power blip everything would eventually come back up and the heater would get flipped on as it should. It'd be eventually consistent.

What actually happened was the reef pi came back up and couldn't connect, which then meant it'd never connect, so the heater never could be powered on, and the next morning I woke up with a bunch of temp alerts and my tank down to 72°F.

I actually had that happen a couple times before I figured out what the heck was going on. I think at least once the problem actually came from me having messed with my wifi and somehow having power cycled the pi while doing so. I didn't notice because reef pi was up afterwards, so I just assumed it was all working properly.

Anyway, that's why I think right now people should be very leery of using the kasa strip. It can work totally fine in normal usage, but in what I'd argue is a very normal failure mode, it'll completely fail on you.

Fixable for sure, as we're discussing in GitHub, but I believe it is a "user beware" feature currently.
 

robsworld78

Well-Known Member
View Badges
Joined
Feb 14, 2020
Messages
952
Reaction score
1,280
Location
Edmonton, Canada
Rating - 0%
0   0   0
As much as people these days tend to hate data being reported back to a central place, this is the sort of thing that'd be wonderful to have reported back to a central reef pi system. How often, and how many users, are running into these various issues. Without that it's anecdotal or just a theoretical analysis.
I agree this kind of info is very useful. Over time I have had a few people give up on the Kasa and go with hardwired as they were struggling with connection issues as well. My personal thought is nothing should be wireless when it's critical but I'm old school. :)
 

A worm with high fashion and practical utility: Have you ever kept feather dusters in your reef aquarium?

  • I currently have feather dusters in my tank.

    Votes: 73 37.6%
  • Not currently, but I have had feather dusters in my tank in the past.

    Votes: 66 34.0%
  • I have not had feather dusters, but I hope to in the future.

    Votes: 25 12.9%
  • I have no plans to have feather dusters in my tank.

    Votes: 28 14.4%
  • Other.

    Votes: 2 1.0%
Back
Top