The update applies only to the Energy Monitor plugs. The drivers have been updated to correct for a device issue where the device's internal date/time may be incorrect if the device is not bound to the Kasa Cloud.
Update Instructions:
Open driver code.
Use import function to import the new code. Save
Open each affected device's page.
Complete a Save Preferences (which will update the device's time if incorrect).
What is new:
Added processing to compare the devices time to internet time at the location.
If the year, month, and date are not the same: Update the device's time to the current time down to the second level.
Changed method of getting time for energy statistic functions.
Issues. None. However, this is a new capability and not tested on the HS110. Error probability is low.
Brilliant work! The new driver has now updated the device time (HS110), the error messages in the log are gone and I'm now getting power usage reported in the logs Thanks for making this change to the driver!
Back on the question whether or not to have Alexa directly control your TP-Link devices or work via Hubitat--
The biggest reason I disabled the TP-Link skill in Alexa and now expose the devices to Alexa only through through the Alexa - Hubitat integration is to keep the device state in better sync with Hubitat. When I was using the TP-Link skill in Alexa and I'd issue a voice command, Alexa would change the state of a device, but Hubitat wouldn't be aware of the change until it's refresh time rolled around again. Since I don't change the state of these devices by pushing device buttons very often then by always using Hubitat to control the device, the device's state is always correct in Hubitat. As a result I can safely lengthen the times between refreshes or even turn off the periodic refresh for many devices.
Hey Dave, a couple of ideas as you continue to wrestle with the best way to give users granular insight into moment by moment power consumption while keeping the hub load as low as possible:
I think a dynamic polling rate would be very helpful. When the power consumption is below a certain threshold (the vast majority if the time), it isn't very interesting and a low polling frequency works great. However, once power consumption climbs, some of my automation use cases start looking for changes to the power curve that may be too subtle or too shortly lived for a low polling frequency to reliably detect.
While one could allow setting a threshold in the preferences of the driver and let the driver manage it, a solution that I think would create much less support headaches and be easier and probably be more useful would be to simply create a custom command that could change the polling frequency. A similar command (or could be the same command with different arguments) would disengage "fast polling" and return it to the baseline frequency. Ideally, when adjusting the polling frequency a timeout period could be provided (with a suitable default in its absence) after which the polling frequency would automatically be returned to its baseline.
That would allow one to create a rule that detects the circumstances that make higher frequency polling useful and engage them. While increased power consumption is the hallmark of when it gets interesting to me, there are always additional criteria of which I could, for example, make a rule aware and only trigger the faster polling when needed. The rule engine could then also disengage the faster polling as appropriate. If the rule crashes or one forgets, the timeout wouldn't let the high frequency poll continue forever.
You also mentioned that you were thinking about rounding the energy readings to decrease the impact of energy monitoring and that you were interested in feedback from the user base. I think your idea was that by "bucketizing" power, one would increase the frequency with which a reading was the same as the previous reading, thus decreasing how often it is necessary to announce power changes, each of which the hub has to propagate up through the system?
I think rounding the readings is a great idea and I don't see how it would adversely impact my situation at all. Extending the idea, I think it would be great if instead of say, rounding to the nearest 5, the end user could actually declare ranges of readings that could all be put into the same bucket and registered as the same reading (that might be extending the idea to the point of being ridiculous... But I'd use it!).
I was thinking along the same line (expose a command to turn on and off quick polling with a value. Leaving it blank or setting it to zero would turn off the quick polling.
I also want to impose a 5 second minimum for quick polling. Below that, you can get into conflicts with other activities. Comments?
This is a great feature which reduces the load on the hub. Iām using this for monitoring my dishwasher, washing machine and dryer. Since they all run for longer than 1 hour I have set the plugs to only report power usage every 30 minutes. If power usage is detected then RM changes the polling to every 45 seconds instead and when power usage has ceased it sets the fast polling to 0 again. Thanks Dave for implementing this feature!
Any chance you can share your rule for this? I am now finally moving my last rule from ST, and this will be very helpful.
I have moved across my plugs, but don't know what settings I should use to make sure the power changes are picked up quickly - without bogging down the system.
You will need to experiment with the power levels. It all varies from appliance to appliance and how they behave during their cycle. For instance, if the appliance has a period of non-activity somewhere in the middle of the program, you would have to account for that in the rule as well otherwise the rule would potentially declare the cycle finished before it actually has.
If I set the poll frequency to 60 seconds, should this then be reflected in the State Variables section for pollFreq ? For me, after I enter a polling frequency and select Save Preferences, it shows 0 as the value, where I thought it would show 60.
I have done the refresh and it just keeps showing 0 for the value?? I should have stated that the picture used above was just showing where I entered the value.
Thanks for making this change to the driver!
