I can't seem to update any IPs of already installed Kasa devices. Scanning and Resetting Device Database reports the correct IP addresses, but when I go to the devices individually they have the old IP address. Tried rebooting, still no luck. Didn't want to remove the devices as it breaks the rules. I know I have done this before so I'm sure if I'm doing something differently, or if something has changed. Any ideas?
Replace the app with the latest version (I did a quick one line update this AM.) Can be done in HPM using "Repair".
Also, this would not happen if you follow the instructions and assign a static IP address to your devices. But you are definitely not alone in not doing so.
The repair followed by a scan worked, thanks. Its funny because I'm doing static ips from the router right now, but I took the time to do some organization...that's why I was updating them in the first place 
. Thanks for making this all this possible in the first place, really appreciate it and the quick response.
1 Like
Not sure what changed but recently but one of my plugs keeps showing up on my activity monitor app as inactive. I think it possibly started with the 6.5.2 update. I did an HPM repair as well to make sure I have current code. It is not specific to one device because when I was just away for a week the same thing happened to one of my other plugs that was not being used. It seems that the "Last Activity" no longer updates when you do a refresh / poll. I turned on debug logging and I recall from a while back that if I did a refresh a bunch of reply messages from the device would get logged. Currently when I do the refresh only the outbound command is logged and nothing else. If I change the on/off of the device from the Kasa app, then refresh it will log the new state and the Last Activity Date updates.
I know the Last Activity only updates when the driver sends an event (even if it is not shown/logged). Was there an event previously being sent after getting replies from the refresh that is not being sent anymore? Could maybe just send a commsError: false every time the device replies back to force the activity date to update?
The design has been to preclude sendEvent for most event for over a year. The sendEvent command is within the logging exclusionary if statement in the methods setSysinfo, setPower, and resetCommsError. You could move the statement out of the exclusionary if statement for one of these events.
There are several reasons for this:
- Since I already exclude logging, it cost no processing ticks to exclude sending the event.
This reduces overall hub process (Hub does not have to handle the sendEvent and exclude it). - Historically, the Hub has had periods that it sent an update even when the attribute did not change.
I will run a test on hub resources with / without this exclusion; unprotecting the setSysinfo instance. Maybe the next version. (maybe not).
PS: What is the activity monitor you are using?
Dave
Something must have changed recently, because I only started getting this within the last week and I think the only thing that changed was I updated the Kasa Integration to 6.5.2. Something was causing the Last Activity to update before this version, not sure what.
I just have it set for most of my devices to watch the Last Activity to be less than 24 hours, if not it does a refresh, and if it still does not update I get an alert. Handy to know if a device (Zwave, Zigbee or Wifi) gets knocked offline or locks up for some reason.
Hello @djgutheinz. Thank you so much for this fantastic integration. I have run into an error.
I am running the latest platform and have reinstalled the Kasa drivers.
Temporary Fix: Do a Save Preferences and try again. Please come back if it happens again. See explanation below (for inclusion in the next version).
For my curiosity, what version did you update the app/driver from?
Issue: Transition time null in method checkTransTime.
Affects: all Bulbs, Light Strip, Dimming Switch.
Resolution (future): In method checkTransTime, check for null transition time. If null,
- set the device's value to 0 (so future calls will not require oorrecting),
- set the value transTime to 0
- continue method.
Dave
I did Save Preferences on each bulb, there are 4 in the group.
I always keep up to date with these drivers. So I should have had the latest. I did the update just in case something was wonky.
I updated the code on-line with a temporary fix. If you use Hubitat Package Manager, do a Repair to update this temp fix. Otherwise, complete a manual update (driver only required update).
Test and please respond.
Yes, a Repair fixed the issue. Thank you.
1 Like
Help with Device Type, Drivers, and settings.
Use case:
I have a Sense energy monitor unit and I want it to integrate with the Kasa HS300 and KP125Pw devices. I want the control and reporting to be local. I want the flexibility of using Google Home, Kasa App, and HE to control the devices.
Current State:
I recently jumped aboard the Kasa train and have installed 3 HS-300 multi-outlet units with six KP125P2 smart plugs. I used the Kasa app to get all of the devices working, then I installed and used Hubitat Package Manager to install the Kasa Integration drivers and app. I have noted some strange stuff:
Issues/Questions:
-
Device Type always defaults to Kasa Plug Switch.
The first HS300 I installed was properly identified and shows the Device Type as HE Multi Plug (the second of the two listed). The rest of the HS300 that I installed months later all showed up as Kasa Plug Switch. I changed it to the second Multi Plug entry. I noticed that the two Multi Plug entries say "Deprecated". Am I correct in understanding this means they are undesirable or of lesser functionality? What should the device type be for the HS300? -
The KP125P2 plugs were auto identified as Plug Switch rather then ME Plug. My first plug that I installed months ago was assigned device type ME plug. Why are the new ones being assigned Plug Switch? Does the Plug Switch device type driver support Energy Monitoring and Sense Integration? What should the device type be?
-
Kasa Cloud Binding - This was checked/unchecked seemingly randomly when I installed the new HS300 and KP125 devices. What is this for? What should it be set to for local control through Hubitat or through the Kasa App? I want the flexibility to use either.
-
Sync of Names - My guess was to turn this on so that the Kasa App drives the names into HE. Is this typically how folks are doing this? My concern is that I might end up with different names in Google Home, Kasa App, and HE if I don't identify the master and use it to drive downstream changes.
Let me know if you want to share any other guidance on this use case.
Thanks,
YF 
Code changes combined the Plug-Switch, Multi-Plug, EM-Plug, and EM-Multi-Plug devices into a single driver. For backward compatibility, I have kept the old code (and will for 1 more year), so that updates will work seemlessly. IF you want to change to a common driver, change the device's type on the device's edit page.
See above.
Created when Kasa protected the Local Lan comms on some devices about a year ago. I believe they then abandoned this - but I keep for various reasons.
Cloud Bind will not prevent Local (LAN) communications. It must be true to communicate with the Kasa Cloud (NOT REQUIRED unless you want to control the device when away from home via the Kasa Cloud (or want to control the device through the Kasa Skill on Amazon vice using the Hubitat Skill).
You can sync names either to the Kasa name or the Hubitat name. Just a convenience to allow users to NOT have to manually change names in two devices.
Keep the Kasa Cloud binding TRUE is the only sure way with what you have described will positively work.
- Kasa App: Used to be able to control unbinded devices if the phone was on the Local LAN. Seen some problems with this recently.
- Google Home: If it works the same as the Amazon integration, then no problem with binding.
- HE: I don't know their Kasa device integration. I believe it is LAN, but don't quote me. If so, binding will not matter.
- Binding General: Some newer devices no longer allow Kasa Phone app control if device is unbound. Things are changing!
You can sync names either to the Kasa name or the Hubitat name. Just a convenience to allow users to NOT have to manually change names in two devices.
I have set each device to Kasa Name Master, but neither the device name nor device label have changed to match the Kasa app device name. I performed a Kasa device firmware update, ran repair on the Package Manager. Still no change in device names.
I have Cloud Bind turned on too.
I also noted that the device data shows the wrong plug info on the device plugged into plug 5 on the HS300. It shows plug 1. When installed, the plug was misidentified, but later changed to the correct plug using the reorder function. Apparently, this never flowed from Kasa app to HE.
You did a save preferences after selecting the function?
The functions are one shot. They do a one-time update of the name.
@djgutheinz
Dave,
Yes, preferences saved. I just redid it and still no name change and the plug info is still incorrect.
I even tried deleting the device name and leaving it blank, then saved the device. Went back in and saved preferences. No device name added.
OK. Able to test this AM. There is an error in the code. In the meantime, you can change the device name manually on the device's edit page. Fix will be in next update.
Dave
New Version 6.5.3 now available.
Update Note: After updating the APP and DRIVERS, do one of the following to assure proper operation (especially of the EM Funtion). Either of these actions will configure all devices and the app to new data and updated scheduling.
- Open the App and simply exit OR,
- Open any ONE device's edit page and select the command "configure"
Link to change description: HubitatActive/Changes-6_5_3.pdf at master · DaveGut/HubitatActive (github.com)
4 Likes
Anyone else getting these errors when upgrading via HPM? I am coming from 6.5.1
app:4732022-04-23 03:39:20.221 pm errorError upgrading driver groovyx.net.http.HttpResponseException: status code: 500, reason phrase: Server Error
app:4732022-04-23 03:39:20.048 pm errorError upgrading driver groovyx.net.http.HttpResponseException: status code: 500, reason phrase: Server Error
app:4732022-04-23 03:39:18.567 pm infoFatal error occurred, rolling back
app:4732022-04-23 03:39:18.564 pm errorError upgrading driver groovyx.net.http.HttpResponseException: status code: 500, reason phrase: Server Error
app:4732022-04-23 03:39:18.370 pm infoUpgrading Dimming Switch
app:4732022-04-23 03:39:18.367 pm errorError retrieving driver source: groovyx.net.http.HttpResponseException: status code: 500, reason phrase: Server Error
app:4732022-04-23 03:39:14.708 pm infoUpgrading All Plug-Switches (except Dimmer)
app:4732022-04-23 03:39:11.122 pm infoUpgrading Color Bulb
app:4732022-04-23 03:39:07.743 pm infoUpgrading Kasa Integration
app:4732022-04-23 03:39:07.595 pm infoDownloading Dimming Switch
app:4732022-04-23 03:39:07.461 pm infoDownloading All Plug-Switches (except Dimmer)
app:4732022-04-23 03:39:07.332 pm infoDownloading Color Bulb
app:4732022-04-23 03:39:07.213 pm infoDownloading Kasa Integration
