All switches stopped working last night #324
Comments
|
It is quite possible if your firmware auto-updated that TPLink is blocking local control now. That has happened in the past with some units in the UK. |
|
Based on the log output, basically the plugin sees the device connected, tries to get a current status update from the device and the device never responds, which is giving that |
|
correct I have validated all the IPs are correct and it still works from the Kasa AP. Could it be a firmware change on the devices ?
|
|
It could be possible. What hardware model device and what firmware version? This is an old thread in regard to when it happened before, it didn't only effect this plugin but larger projects like Home Assistant, home-assistant/core#43088. |
|
These are the devices and firmware that are impacted hs103 V2.1 FIRMWARE 1.1.4 For testing I added another swithc which was attached to a kasa power strip, that didn't work either.
|
|
My power strip is still working for sure, running firmware version 1.0.19. I just tested adding a HS103 hardware version 3.0 firmware version 1.0.3 and it's still working as well. |
What is your Power strip model and firmware ? Mine is KP303 V1 firmware 1.0.11 |
|
Ah, slightly different. My strip is HS300 hardware V1.0 firmware version 1.0.19. |
|
so I added two more devices to the instance, one is the strip and a new one .229, the .229 device works, and is the save version and firmware v3, 1.04. I am puzzled... `[2022-12-08 21:28:38,278] DEBUG: Could not connect to 192.168.1.228. [2022-12-08 21:29:01,179] DEBUG: TIM |
|
Are there commands I can run to query at the command line in Python ? can you provide an example so I can troubleshoot somre more? Looks like 3 out of 6 switches work and some working/non are on the same firmware and same version. |
|
The original communication was pulled from here. You would probably have to utilize one of the forks though for strip control, this one here seems to include that. Looks like there might be a possible new handshake protocol too, not sure if that might be related to your issue. That fork is found here. |
|
Thank you so much. The mystery deepens, from the pi, I run the exact command that you used to query to a switch that returns an error and it work fine!! this is just annoying at this point.... in fact it is working on every one of the switches i have except the not through the plugin interface.
|
|
do you have any errors in octoprint.log? |
|
|
might be easiest if you could share the whole file. you can drag the file into the comment window to attach. |
|
Checking in on this, as well. I have the switch icons in my top bar and they've just been spinning for a while now. I can turn things off, but not on. This is the HS300 model and I've attached octolog, and the plugin's debugging log. Let me know if you need anything else |
|
Can you share your hardware and firmware versions listed in the kasa app please? |
|
Hardware: 2.0 |
|
Just checked your octoprint.log and seems there is an error related to the sqllite database used for power monitoring. @kevman28 do you see a similar error in your octoprint.log? |
|
There are two ways we can try to resolve this error @MatchstickWorks. Either manually deleting the database over SSH and restarting OctoPrint, or clearing the settings from Plugin Manager completely using the eraser icon on the line item for this plugin, restarting OctoPrint and then re-entering all your plug info again. Since the SSH one doesn't lose settings these are the commands (assuming octopi image, adjust paths accordingly for manual install). |
|
I'll try that! Currently in a print, so I probably shouldn't restart the OP service just yet :) |
yes- it was in reference to the same script init.py EDIT: tried the suggesstion it didn't work unfortunately. |
|
i did some testing with the original communication script, looks like port 9999 no longer works.... `pi@octopi3:~/tplink-smartplug $ ./tplink_smartplug.py -t 192.168.1.238 -c info pi@octopi3:~/tplink-smartplug $ sudo ./tplink_smartplug.py -t 192.168.1.238 -c info |
That seemed to do it for me! Thanks for the help! |
That's unfortunate. Seems maybe your plug updated with the new connection protocol. Found a similar post with additional links here.
Great to hear. |
|
Curious if you get the same thing with the python-kasa library @kevman28? If you run the following does it return anything? This module is what Home Assistant uses and I could potentially re-program my plugin around that library (would take a while to complete this task). |
|
I think it still tries port 9999, but also seeing some script errors `(oprint) pi@octopi2:~ $ kasa --host 192.168.1.238 During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
Yeah, looks like you're right. It's the 9999 port not accepting connections still. Just curious, have you verified your IP address? Unplugged the device from the wall and plugged it back in to reboot it? |
|
so I did some more troubleshooting....it looks like this might be an issue in my network, I have one Pi that is able to connect and run those queries to the switches, but three others that can't. I am stumped at this point, may consider rebuilding those octopi systems...its basically unable to ping those devices on the the systems that are not working... |
|
i think I finally figured out this problem it is not related to the script or plugin at all. My asus router has a setting called "Target Wake Time" , I disabled it and all the devices started working again. Also as per TP link, my HS103 devices still have the open API, they did not update those to block port 9999. Hope this is helpful for anyone else here. Thank you jneilliii for all the help and support. Many thanks !! |
|
Thanks for the tip. I've actually seen that setting before relative to octopi devices going offline. |
I have 4 printers with four Kasa devices ( DCHP static assignment) and none of them work today, here is an example log output , I have verified the IP of the Kasa device and this is occurring on 4 instances. Did something change on the TPlink side ??
022-12-08 01:16:11,667] INFO: Turning off 192.168.1.220 at 2022-12-08 01:16:11.667036
[2022-12-08 07:46:51,626] INFO: Turning off 192.168.1.220 at 2022-12-08 07:46:51.626499
[2022-12-08 08:40:17,885] INFO: Turning off 192.168.1.220 at 2022-12-08 08:40:17.885450
[2022-12-08 09:22:52,346] INFO: Turning off 192.168.1.220 at 2022-12-08 09:22:52.346403
[2022-12-08 10:39:03,985] INFO: Turning off 192.168.1.220 at 2022-12-08 10:39:03.985014
[2022-12-08 13:04:53,988] DEBUG: ImmutableMultiDict([('checkStatus', '192.168.1.220')])
[2022-12-08 13:04:53,988] DEBUG: Checking status of 192.168.1.220.
[2022-12-08 13:04:53,988] DEBUG: {'system': {'get_sysinfo': {}}}
[2022-12-08 13:04:53,989] DEBUG: IP 192.168.1.220 is valid.
[2022-12-08 13:04:53,989] DEBUG: Sending command {'system': {'get_sysinfo': {}}} to 192.168.1.220
[2022-12-08 13:04:57,084] DEBUG: Could not connect to 192.168.1.220.
[2022-12-08 13:04:57,085] DEBUG:
[2022-12-08 13:04:57,085] DEBUG: {'system': {'get_sysinfo': {'relay_state': 3}}, 'emeter': {'err_code': True}}
[2022-12-08 13:04:57,116] DEBUG: Checking status of 192.168.1.220.
[2022-12-08 13:04:57,117] DEBUG: {'system': {'get_sysinfo': {}}}
[2022-12-08 13:04:57,117] DEBUG: IP 192.168.1.220 is valid.
[2022-12-08 13:04:57,117] DEBUG: Sending command {'system': {'get_sysinfo': {}}} to 192.168.1.220
[2022-12-08 13:05:00,204] DEBUG: Could not connect to 192.168.1.220.
[2022-12-08 13:05:00,205] DEBUG:
[2022-12-08 13:05:00,207] DEBUG: {'system': {'get_sysinfo': {'relay_state': 3}}, 'emeter': {'err_code': True}}
The text was updated successfully, but these errors were encountered: