No apparent use case in normal operations. It is a carry-over from SmartThings which kept getting out of sync on attributes. However, it is also a kick-restart for quick polling (which uses runIn vice runEvery. If there is ever an error, quick poll stops; however, refresh will restart.
Agree. Will add to the 5.2 driver.
Agree again. Good use case. The next version will have an exposed "preTriggerLevel" using your algorithm.
I will have an advanced copy in a few days and will give you the link. It will have other improvements to reduce processing. Mainly, the Quick Poll command (which are static commands) will be pre-encrypted - taking out the need to encrypt before sending. Overall a small (~5% or so) decrease in processing, but good since these repeat frequently. It is already written and under test on my personal active system.
I am brand new to this. Just got my Hue lights and Kwikset lock tied in. Are there instructions somewhere for getting my tp-link devices onboard. Any help is appreciated.
I am excited to work on this .
Thanks,
Welcome aboard Bryan. If you scroll to the top of this topic and follow the link for the installation instructions you should hopefully find what you need.
A user was having a communications error problem on the 5.2 release (explicitly for dimming switch). The result was that I could not resolve the issue. If anyone else is having significant communications WARNING messages from a Kasa Device, please personal message me.
Stress Test: As a part of the troubleshooting, I set up and ran a quick polling stress test on my active hub (attempting to replicate the problem). I felt these results may be interesting to a wider audience. See below for data on the Stress Test.
Results: No communications error at all on the hub, except, as expected, for the HS300 plugs (very occasionally due to six plugs sharing one interface).
Conclusion: On my C5 hub, the quick polling does not bring the system to a halt nor does it cause undo communications errors (UDP or otherwise). This result does not mean that other devices/apps on your system are not bringing down your communications or there is something on WiFi that is generally causing the issues. Those items I can not solve.
Below is the configuration of the Hub Under Test (HUT):
WiFi Router: ASUS Blue Cave
Hub: C5
Firmware: 2.2.0.128 Kasa Devices (all running 5.2.0 driver versions)
Items below set on quick polling of 5 seconds with debug and information logging:
The entire set has been updated to 5.2.1. Changs are only in the following items: Application:
Led On/Off; Added ability to control device led on/off.
HS300 Devices: Inserted logic and clear warning message to explain HS300 return being incomplete and unparsed if the total length of plug names exceed ~102 characters.
EM Multi Plug Driver:
Update to date handling to avoid using state.currDate.
Inserted logic and warning message to handle HS300 return being incomplete and unparsed if the total length of plug names exceed ~102 characters.
Kasa EM Plug: Update to date handling to avoid using state.currDate.
Thanks. You mentioning the Hubitat Package Manager forced me to look into it, and I'm glad I did. It's a great app, as is your TP-Link integration. Thanks.
Does anyone have TP-Link switches working with Rule Machine 4.0?
I'm trying to get a TP-Link (HS200) switch to trigger other switches (also HS200).
But what I'm finding is that there's some delay or doesn't trigger at all.
Yes I have them working, but due to their implementation over WiFi, they rely of polling to detect a physical press. So you will have to enable quick polling per device. I have mine at every 5 seconds, which results in a delay of up to 5 seconds, assuming no communication errors, on physical presses.
Thanks for the info about the polling. Do you notice any network issue if you have the polling set to a low interval?
The rule I'm trying to implement is just getting one switch to trigger others. So if I turn the switch on in my foyer when I arrive, the hallway switches also turn on.
I'm probably not the best guy to ask about networking issues as Dave can attest, but that is a story for another time, but when it did work well for me, like a month ago, 5 seconds did not seem to have an issue.
I asked about the rule, because what you are trying to do might be easier if you use the built-in app called Motion Lighting. It also contains something called Mode lighting inside that app that allows you to turn lights on and off per mode and have a certain switch act as a trigger, this is the documentation for it and see my rule below:
The traffic for a command stream is relatively low (one sent and on received per poll). This is generally not a problem on WiFi performance. Hubitat performance is another thing. See.
On an average installation, no. The secret is limiting quick polling to as few devices as necessary (one?) and then run for a while.
One hint. The switch attribute has a type of physical or computer. If you only want the other switch to turn on when the device is manually pressed, then the type should be physical in your rule (this came from other users).
Thank you so much for this integration. One question. I'm trying to use the MakerApi and Tasker to be able to toggle the plug from my smartwatch.
It seems like the device only supports on/off and doesn't have a toggle, is that correct? This is what I see when I query the device for supported commands:
Yes. The device is a switch. No toggle capability. To simulate a toggle, I would use rule machine and a virtual toggle device. You would toggle the device, rule machine would determine current state and turn on or off.