I see there’s a document saying there’s a limit of about 20 smart plugs for Sense, but right now I’m sitting at 31 total (3 HS300’s, plus half a dozen HS110’s and a single WeMo). Far as I can tell, not having any issues, but I’m curious why, and what issues I’d see if there were problems.
Thanks!
I’m above the limit as well at about 31. I went above because there was originally some vagueness in whether an HS300 counted as one or 6 when fully populated. I started seeing the Sense monitor drop offline for short periods intermittently. The dropouts grew more and more frequent as time went by, basically because the monitor gets overloaded doing all it’s usual stuff plus managing too much smart plug data. If you encounter the same issue, Sense support can apply a workaround that’s not perfect, but works for me.
Good to know, thanks!
Guessing the ~20 is just to be safe. I’m on a unifi setup know and all my IoT stuff (Sense included as well as smart plugs) all live on their own SSID/vlan. I don’t see anything indicating Sense dropping offline, or it being overloaded, but suppose could be happening and I don’t notice.
Glad to know there’s a workaround if needed.
Thanks!
I don’t think you’ll see any indications of the issue from your networking gear. The Sense monitor stays online and continues to transmit and receive data. It just gets backlogged processing and managing data and loses some. It will show up as your usage (and solar production) dropping to zero for a few seconds at the start to many minutes as time goes by.
I discovered the 20 limit after I had deployed 28. 
I currently have 28, 4 HS300s and 4 KP115s. Of note is that 8 ports of the HS300s are not being used. They are powered off with nothing connected. I expect (hope) that this reduces the load they represent.
I’m curious where the Sense 20 limit comes from. Is it processing power? Or network bandwidth? Both?
Unused HS300 plugs are still plugs, unfortunately.
Is there a limit to the number of smart plugs I can connect to Sense?
The number of smart plugs is limited primarily by Wi-Fi network bandwidth. Typical Sense users can use about 20 smart plugs without issue. Note that each plug of the TP-Link HS300 smart strip counts as 1 smart plug, regardless of status.
I believe the limit is processing power / speed in the Sense monitor itself. Regularly querying and responding to responses from all the smartplugs is just one of the Sense monitor’s many tasks. Ask it to process too many smart plug responses every 2 seconds and and eventually it gets backed up, because there’s no way to delay receiving the data - the monitor either processes the response packet or it is lost.
I’m at 34 Kasa plugs, one Wemo insight and 62 hue bulbs integrated with Sense. My sense seems to work quite well.
I just wish there was an expansion hub to monitor more selective circuits, solar, generator, etc. all at the same time.
So, a little packet sniffing sheds some light…
Sense works with the KP115s and the HS300s quite differently.
For the KP115s, Sense sends a single link local broadcast packet (109 bytes) requesting both system info and power measurements. All KP115s respond with their current system and power values. The response packets are surprisingly large (760+ bytes) due to inclusion of complete system information (~85% of the packet).
For the HS300, Sense sends a sends a point-to-point packet (183 bytes) requesting both complete system information and power information for each individual socket on each HS300. Each response packets is quite large (1087+ bytes) because complete system information is included in each response. The repeat of complete system information (937+ bytes) in each request/reply cycle is obviously very inefficient.
As a result, @JustinAtSense, I would like to make two enhancement requests:
Please allow individual plugs on the HS300 to be disabled in Sense. No reason to query plugs that are not being used.
Please optimize queries for the HS300. No reason to ask for six copies of complete system information every two seconds. One copy will do. 
I’ve logged both of these for more investigation on our end, but something tells me there were external limitations from the Kasa/TP-Link side of things that pushed us in this direction. Just speculation on my end, but when I hear more information about particulars here I’ll update this thread.
The limitations are pretty clear. Both the device name and the relay state are buried in the system state. If you want Sense to follow name and relay state changes made in the Kasa app, you have to retrieve the complete system state (all 25 values!) repeatedly. This is just poor data design on TP-Link’s part. Seriously, why do I need a latitude/longitude update from the plug because I asked if the relay is on or off?
With regard to the the HS300 specifically, there’s certainly an additional issue on the Sense side. Asking for the system state over and over when each plug is polled really doesn’t make much sense. If Sense needs the system status every cycle, simply asking for it when polling the last plug would make a lot more sense. [ Please pardon the puns ]
Of course, one could design a much more efficient solution for both the KP115 and the HS300 by polling system state and power separately. This would be particularly beneficial if the user has disabled relay control in Sense. Sense could request power information every cycle, and only request system information every 5-30 cycles (10-60 seconds).
Sense is actually asking for this information from the TP-Link
{"system": {"get_sysinfo": {}}, "emeter": {"get_realtime": {}}, "context": {"child_ids": ["xxxxxx"]}}
Edit: I have a bad habit of posting before looking at the data sometimes or reading an entire thread… The reason for the sysinfo is to see if the devices are on or off look for name changes etc. Got it. Although Sense doesn’t use the lat/lon I’m assuming that other devices that TP-Link has might find that data useful.
I’m not sure it would be more efficient. In order to do that you would have to write the code to support it and you would have to execute it. If you wanted to get near real-time data you would be polling it at the same interval as the emeter data so then you would have to process equal amounts of data but using double the resources on the Sense monitor. What would be nice is if Sense subscribed to info and power events. That would eliminate the need for sysdata and I was able to find a node-red library that does this locally so I assume it’s possible.
As it stands, by my calculation, each HS300 is only using .03 Mbps.
As noted in other threads, the principal limitation does not appear to be network bandwidth, but processing bandwidth in the Sense device.
I figured as much. I just wish they would say that rather than blame the network.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
