I'm pretty sure it sends out a multicast to all the plugs on the network every 2 seconds. I don't know the specifics though of what it sends to the plugs or what the plugs send back. I've made a post on the Sense forum asking for some of that information. It does not get the data from the cloud, that would be way to slow for what Sense is using the data for. It allows Sense to collect ground truth for the device plugged in that they can feed into their ML algorithm.
Reading the Sense technical descriptions, they do not get anything directly from the TP-Link devices. Reading their docs, it looks like they determine the electrical signature of different devices and then you can name the device and use the data. I hope this is correct, or it is yet another communicator with TP-Link.
PS - I talk directly to the TP-Link devices and the HS300 begins getting a lot of error below 5 second refresh window.
In general, yes that's how Sense works. But not everything can be detected easily by the electrical signature, and this includes pretty much anything that runs of DC power, which is where the smart plug integrations come into play. It's not to control the device plugged in, but to capture it's energy usage. For example, my desktop computer and my network rack are each plugged into a HS110.
Here's a post I found from a Sense employee talking about how they get the information from the plugs. I had thought they used multicast, but apparently that's not the case.
TPLink has two ways to fetch the current wattage: TCP, UDP unicast and UDP broadcast. UDP broadcast is the best choice for sense because:
- We only care about the wattage when the query is sent, and we don’t backfill from the smart plugs, so a slower protocol like TCP would not help us. Yes, TCP is more reliable, but only because it tries retransmitting unacknowledged packets. By the time those retransmissions have been done, Sense doesn’t care about the data any more.
- Broadcast UDP (which is distinct from multicast, which TPLink does not use) is great, because it means that Sense can send a single broadcast wattage query to the whole network and receive unicast responses from each plug, all in a single packet. This means that the whole network’s load is basically as minimal as possible.
However the post didn't mention how often this happens.
EDIT: Further down that post on the Sense forum, a user posted
Sense sends a broadcast message every 2 seconds to port 9999 with a ‘{“emeter”: {“get_realtime”: {}}, “system”: {“get_sysinfo”: {}}}’ command, and then all the HS110’s respond with UDP packets with the data:
1 Like
If this is really true, he command string they are sending is over-qualified. The "“system”: {“get_sysinfo”: {}}" is not required and is actually slowing down the response.
I separate the commands, but the same commands I use for the HS-110. Curious as to what they use for the HS300 (requires a childId context in my code).
Also, can I get a link to the post????
Sure. This is the post I found.
You can't create an account on the forum unless you have a Sense, but if you're really curious and have any questions I can post for you.
1 Like
You can tell them I am working on a rawSocket interface that shows hope and have aleady done cloud to TP-Link, UDP, and TCP in Hubitat and SmartThings. They can EM me for details and can always visit my GitHub site. I have the power interface access data for the HS300 (not the same as the HS110) plus the Kasa Bulbs that have EM Functions (if you are interested in 10W consumers).
Hmmm, so I had the rule that turns the plug on after 10 seconds fail. Well... the rule ran but the plug didn't turn back on. I went to turn the air purifier back on a little later and I had to manually turn the plug back on. I suspect when the command was received by the plug it was probably processing a query from Sense and just dropped the packet or something. I don't know how those plugs (especially the HS300) handle rapid fire network requests.
But this is never a time critical thing. So I think I will modify the rule to
- Set a boolean variable, lets say isOff to true
- Then if isOff is true, wait 10 seconds, send the command to turn on
- Wait 5 seconds, poll device. Change isOff to false if the plug is on. Else, send the command to turn on
I'm fairly newish to Hubitat though. I'm not sure how to program a loop using Rule Machine. I'll play around with it when I get home (or maybe over the weekend when I have more time).
Thank you for your work on this. I have a couple brand new HS110 's and am wanting to use the power usage features. I see the current version is marked as Deprecated pending your update so I will watch the thread and look for your announcement.
Much appreciated.
First, I strongly recommend using Hubitat Package Manager.
Secondly, see the below link for information on the latest release; including the code. The old site is active for backward compatability with legacy users. I moved location about two months ago to support using Hubitat Package Manager as one of the installation techniques.
3 Likes
I'm sooo confused.
I just installed the Hubitat Package Manager and it found the 'Kasa Intergration' app. But now I see that both that and TP-Link are on my Hubitat and all my devices are using the TP-Link version.
I assume this means you renamed the app and I need to change all my devices to use the Kasa device drivers and then delete the TP-Link version.
Is this correct? Is this what your previous post refers to?
And thanks for all your work. I really love my TP-Link devices!!!
Yes, I am new to the hubitat world and I found the HPM earlier and tried to install it. Install failed but I did notify @dman2306 in that thread and am following up with him.
I will install your app manually for now and thanks.
FYI that I did get it installed but wanted to note that I am getting a lot of entries for a Null pointer error. Looking at the device directly, I can turn it on/off and it also is reading the power level so i'm getting the info I want, but I wanted to point out these errors in the log.
LOG:
dev:82015-01-01 05:28:02.266 am errorjava.lang.NullPointerException: Cannot get property 'energy' on null object on line 229 (setEngrToday)
Thanks
What version were you upgrading from?
While installing HPM, your first option should have been "Match Up" (on the menu). This registers your current installed Apps and Drivers with the HPM app. Then run HPM and update the package.
Get back if that does not work.
Some help. In the driver, turn on debug logging (in preferences). Then run a refresh. I need the debug log along with the error for this. Particularly, the log that includes "setEnergyToday: " with a relatively long string following.
Dave
This was a new install for me. I seem to have had a time setting issue on my HE and I have that straightened out. I then went and updated each app. I don't see an issue now but am going to keep an eye on the logs. I will let you know and thanks. 
Thanks for this app. Should we set a poll frequency for each plug? I have a HS300
Yes, but no more than 2 on a single HS300. Otherwise, you will have some performance issues with the device.
Thanks
Been testing this and really like it so far. I do have a couple questions though...
- When the HS110 switch is on, it shows power as Zero(0). When I turn the switch off, then it shows 53W for power. This seems backwards to me. Is this the intended behavior?
- When I create a tile for the HS110 in a dashboard, I am able to turn it on and off and that's great. However, how can I display the current power level at the bottom of the tile? I would expect a single tile could be touched for on/off and also display the power level.
Thanks and I'll look for your reply. 
ON/OFF behavior. Not the expected behavior; however, code looks correct to me. The attribute may not be updating on the browser (it sometimes lags).
You can readily display individual attributes using dashboard. There are (somewhere in the community) descriptions of creating your own composite tiles. I do not use these, so sadly, I have to leave you to find.
