Polling model not ideal

[wbierman]

Hello. Firstly let me say that I appreciate the time you've taken to create, document, and publish this work. I have no experience with development related to home automation, but it seems like this code operates on a polling model to drive events called "rules".

What I have done is installed an HS200 switch in my backyard shed to control the flood light, and another HS200 switch on my house which functions solely to control the shed switch -- no fixture or anything else is wired into it. I have a rule setup to sync state between the two switches. The end result is what I want: a second switch for my shed light.

However because the hubitat is polling at the devices at 60 second intervals, there is a very noticeable delay between the activation by me of one switch and the corresponding automatic activation of the other.

I assume that since it is the only option available, that there is no way to tell the HS200 to report to the hubitat when it is toggled, allowing the rules to run on an event-based system rather than a polling-based one. Is this correct? And what are the implications of lowering the polling frequency to minimize the delay?

I sort of feel like I might be accomplishing my goal with a round-about way. Is there a better solution that what I have done?

[DaveGut]

You are correct in the automatic event response sent by the bulb.
Polling can be increased by a special algorithm. Implications is a increase in the hub processing. Depending on how many devices you want to fast poll and the total number of devices, impact will vary.

I will write a plug/switch driver for you with rapid polling as an option - if you will promise to provide feedback after using a few months. It will provide 5 second polling of SELECTED devices. Instructions to follow.

[DaveGut]

I finished the special polling version. You can create a new driver or replace the existing. Go to the drivers page and open the current (or new) driver window. Select import and input the below: "https://github.com/DaveGut/Hubitat-TP-Link-Integration/blob/master/Special/SpecTPLinkPlug-Switch.groovy" Save. Go to Preferences on the Devices Page and select "Enable special fast polling (Not Recommended)" Save preferences. Note: By default, fast polling is disabled. You will have to enable for each device.

To restore previous version of driver, open driver in Hubitat. Select Import and the link below: "https://github.com/DaveGut/Hubitat-TP-Link-Integration/blob/master/Device%20Drivers/TP-Link%20Plug-Switch%20(Hubitat).groovy"

Again, use for a while and please comment. May add for entire community.

[wbierman]

Just wanted to follow up here. I have been travelling until yesterday, but have updated the driver and will experiment with this. I assume the primary concern here is that the additional CPU demand on the Hubitat. Is that right? Is there some way that I can gather performance data before/after enabling fast polling to give you a comparison?

[DaveGut]

No way to gather performance data. Just see if it is working OK and the hub is not brought to it’s knees. You will need to run for several weeks w/o hang-up. Sometime it is just resources being grabbed and not properly released when done.

Dave

From: Bill Bierman notifications@github.com Sent: Sunday, June 23, 2019 16:05 To: DaveGut/Hubitat-TP-Link-Integration Hubitat-TP-Link-Integration@noreply.github.com Cc: David Gutheinz djgutheinz@outlook.com; Comment comment@noreply.github.com Subject: Re: [DaveGut/Hubitat-TP-Link-Integration] Polling model not ideal (#5)

Just wanted to follow up here. I have been travelling until yesterday, but have updated the driver and will experiment with this. I assume the primary concern here is that the additional CPU demand on the Hubitat. Is that right? Is there some way that I can gather performance data before/after enabling fast polling to give you a comparison?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDaveGut%2FHubitat-TP-Link-Integration%2Fissues%2F5%3Femail_source%3Dnotifications%26email_token%3DAGAI4MYDKSKBQXZAPTBIQOTP37QP5A5CNFSM4HWQXOZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYLHAVA%23issuecomment-504787028&data=02%7C01%7C%7C7cbdea1954164202ba3008d6f81e7581%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636969207028831527&sdata=6BNCbPgnqjzkmla8CHPik42DYFG18VenaoqefTgCUTo%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGAI4M47RJZI4RS7D5EYXQTP37QP5ANCNFSM4HWQXOZQ&data=02%7C01%7C%7C7cbdea1954164202ba3008d6f81e7581%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636969207028841538&sdata=oaczv490G9R2XpprcaOmvWrozJRkeUfIu9lrsjufd4E%3D&reserved=0.

[wbierman]

Okay, thank you. This is basically all I am using this hub for, but I may add more to it in the future. I have done an initial testing and can confirm that the system does respond within five seconds.

I'll plan to post back here after a few weeks.

[DaveGut]

FYI, here is an API document I wrote for the TP-Link Bulbs. This was based on my research and experimentation using node.js scripts and debugging the actual code from TP-Link.

TP-LInk Bulb API.pdf

[DaveGut]

Closing as solution accepted.