First of all, thank you so much for the amazing work on this application and the drivers!
The problem I'm trying to solve is that I'd like to set timers that start with some of my HS200 switches, but since there's no real-time or near-real-time triggers, the timers only start once a refresh updates the state. I've set all my refreshes to 5 minutes (1 minute refreshes gave too many errors), but that means a 5-minute timer may turn into a 10-minute timer if the switch was turned on right after the last 5-minute refresh.
I have a timer to automatically turn the pantry light off after 5 minutes.
I have timers to automatically turn the closet lights, garage lights, and toilet fans off after 15 minutes.
I have timers to automatically turn the bathroom fans off after 60 minutes.
I can probably live with this up-to-5-minute delay, but it would be much easier on my OCD to have close to real-time event triggers.
Is there a way to incorporate device polling for events? I'm grasping at straws here, but I think the API exposes a plug.startPolling command and device.on events that may be useful for this instead of relying on obtaining device states during the refreshes. (I've been looking at the API examples at tplink-smarthome-api/events.js at master · plasticrake/tplink-smarthome-api · GitHub)
I'm more than happy to spend time on the code to try figure this out, but my coding skills with these languages are novice at best and I don't really know where to begin looking for this and how to add/enable/modify it. I'm up for the challenge though, if only I can get some pointers.
I am confused on what you are asking. Are you using another solution (Kasa) to control lights outside of HE? If you are then I can understand you dilemma. If not HE should give you that triggered event which then you can use RM to do an action with.
I personally only use the Kasa app to connect new lights/outlets to my home and then all control happens through HE and @djgutheinz app/driver locally. I don’t even use the cloud connectivity option for this.
I think you are discussing a manual switch on of the device. The event that is triggered when this is detected is the attribute "switch".
Refresh does the polling you are discussing (it is the same function for these devices). It gets the current state of the bulb and triggers an event.
The code allows refresh rates down to 1 minute. This would be an average latency of 30 seconds and for OFF timers (I think) would be quite acceptable. You could even adjust downward the timer duration by 30 seconds making the average your original values.
More frequent refresh is possible; however, it causes a significant impact on hub resources to execute. I can provide some code for this; however, I do not recommend this polling frequencies.
@djgutheinz Correct, I'm discussing manually switching on the devices. (@aaron Sorry for the confusion!) For example, the kids would turn on the bathroom fan and leave it on all day while everyone's out, or someone would leave a closet light on all day, or leave the garage/pantry light on all night.
Anyway, I've decided that the 5 minute refresh is just fine, and told my OCD to take a chill-pill and let it be.
Yeah if the kiddos/wifey hit the buttons manually then you are kinda SOL. I tend to hide the plug behind an object like furniture. If they really want it off they can use Siri or Alexa to ask for it to turn off. We are an iOS home so all phones and tablets have access through Siri to HE using HomeBridge. Even the 4yo can use her tablet to turn on/off lights which she often does in her own room or the play room.
Change refresh to once per minute. Your hub should work OK unless you have a LOT of devices. And the wife will see an improvement - so you are a hero slaying those energy dragons.
I will update the instructions to be clearer. Note that the (Hubitat) is there to differentiate from my Smart Things integration within my system. Understand the confusion.
Not necessarily the Hubitat vs. SmartThings designation (which I would have loved to have known about this app when I was using SmartThings as my primary..) Thank you!
Instructions had an error. Just corrected to HS110: TP-Link Engr Mon Plug (Hubitat).groovy
I added the energy monitor plug later since the UDP version of the driver had some problems with the energy monitor status return (message length). I did a work-around.
Yeah I have been experiencing TP-Link communication failures a lot over the past 2-3 weeks and Hub slow downs. Not sure what is contributing to all of this so I began investigating. Since I cannot force the IP address of the devices anymore I am unsure if the app works 100% of the time. We have had outages for internet in the past 2-3 weeks but that shouldn't cause issues...at least I hope not. Anyways, the COMMs errors I am experiencing seem to go away after a hub reboot and not with a wait of 5-30 minutes. At least no after initializing the app in HE.
My setup:
all TP-Link devices have reserved IP addresses
all TP-Link devices can be controlled remotely through Kasa App if needed
I am the only one who has the Kasa app and access to the lights outside of HE
I see no errors...the DNI is updating when the app runs and every so often. But when the hub slowness is experienced I do not see any new logs from TP-Link. Hence my suspicions.
Comms Errors. Comms errors are automatically generated when a device does not respond to a command within 2 seconds. Do not know why these are occurring. The comms are relatively straignt forward. Several possibilities:
The UPD polling is interfering (see below fix and fixed in later versions).
A device is itself powered-off.
Some design notes that may help. See below. You are using an older version of the integration (Newer does not have auto polling.) DO NOT UPGRADE. I am working on an update for this month that will include a Application method to update (will automatically update data structures to latest version.) I apologize for these changes, but the UDP has been a learning curve.
Fixes based on App Version at top of file. def appVersion() { return "4.0.01" }
Go to method initialize() and comment out the line "runEvery30Minutes(discoverDevices)"
run the application.
def appVersion() { return "4.0.05" }
Go to the method checkIp and comment out the instructions so the code looks like:
def checkIp() {
// if (state.allowDiscovery == false) { return }
// state.allowDiscovery = false
// runIn(600, resetAllowDiscovery)
// discoverDevices()
}
run the application.
Design Notes: The original integration was designed to automatically poll for devices if there was a comms error. This was throttled to a maximum of once every 5 minutes.
Errors are automatically created when the device does not respond within 2 seconds.
A common cause of a never-ending loop is to have a device powered off (unplugged, switch off). This will drive an every 5 minute polling.
Next version out this month. The next version will address this issue by eliminating the automatic polling function. The comms error message will indicate that the corrective action is to run the Application. The new version will also contain a user-selected method to UPDATE from previous version. This method will update the data elements so the upgrade will work. My plan is to test/validate against all hubitat versions; including the old cloud and hub based integrations.
Update to version 4.2: The drivers and application have been updated to version 4.2. Changes
Application only does device search when run manually. (Note: If an IP address changes, the user runs the app to update. To preclude this, set your IP addresses to STATIC in your wifi router.)
Application automatically updates the device data for older versions, assuring upgrade is as smooth as possible. You must run the application during the upgrade process.
Bulbs now support capability "change level". This allows pressing an up/down button then stopping to gradually change the bulb brightness.
All devices added a user command to synchronize the Kasa App device name with the set Hubitat label.
Cleaned up error messages for comms error with explicit recommendations to resolve.
Compatibility. When installed per the instructions, the upgrade will work when upgrading from any earlier Hubitat version.
Upgrade: You MUST follow the upgrade instructions in the README.md file on the main GitHub page.
The new drivers are not compatible with version 3.x and earlier Application (and no guaranteed with version 4.0 / 4.1).
The new Application must be run to update the device data to assure that earlier versions run.
Upgrade instructions
Replace the contents of the existing driver and application.
Run the application (this will update the required data elements.
Anyways, the COMMs errors I am experiencing seem to go away after a hub reboot and not with a wait of 5-30 minutes. At least no after initializing the app in HE.
