Troubleshooting weird performance issue

🛎️ Get Help
21

Looking at the docs, there doesn't seem to be a UDP socket interface unfortunately. Your experiment + mine leads one to think it would be useful... Based on the above comment from @djgutheinz your experiment would only work for some Kasa devices, not all...

22

Easy path for simple plugs, multi-plugs and emPlugs is below (using my code with the simple modifications provided).

  • Download driver at: https://raw.githubusercontent.com/DaveGut/HubitatActive/master/KasaDevices/DeviceDrivers/Plug-Switch.groovy
    • Rename driver to "xKasa Plug Switch" in metadata - definition section.
    • Modify the lines below per the FROM - TO below.
    • Save
  • Open a plug/switch device of your desire (not dimming switch)
    • In the Device Data section, uses the Type pulldown to change the driver to the USER driver "xKasa Plug Switch"
      • To reverse the change, simply select the original type (Kasa Plug Switch) from the built-in list).
  • You can now play with the TCP (raw socket) version of the driver by switch on/off the preference "Alternate LAN Comms (for comms problems only)"

Note, the design is based on the following Hubitat document: Raw Socket Interface | Hubitat Documentation

FROM

        if (getDataValue("deviceIP") != "CLOUD" && getDataValue("model") == "HS200") {
			input ("altLan", "bool",
			   	title: "Alternate LAN Comms (for comms problems only)",
			   	defaultValue: false)
		}

TO

//        if (getDataValue("deviceIP") != "CLOUD" && getDataValue("model") == "HS200") {
			input ("altLan", "bool",
			   	title: "Alternate LAN Comms (for comms problems only)",
			   	defaultValue: false)
	//	}

PS: I just tested this on my active hub and it works.

2 Likes
23

I'm curious - I had a cursory look at the code and it looks like you call connect() before every command and close() after every response. Any reason you don't do it just once and reuse the socket ? Are exceptions thrown on disconnect and/or connect() failure ?

24

Commands happen actually very seldomly. Closing releases the Hubitat resources as early as possible. (Note that I also use the device API's multi-command function where logical. Example on/off would typically take two commands, but I combine the two to a single command.)

If you want a fast poll, then you can modify to monitor the connect as an attribute (using the return status data from the connection, then check that status before sending the command and if closed, open. This all takes extra processing on each command sent.

2 Likes
25

Also, remember that the driver is considered Alpha version (and has been for years). I would not expect much support from Hubitat for any internal issues.

26

Yes, that has to do with how responses are processed.

There is some built-in throttling, which you're running into.

There isn't at the time. I'll need to think about it.

4 Likes