@kevin1, I did get a wireshark capture that shows both how Sense device and the Kasa app communicates with the HS110. I installed the dissector (GitHub - softScheck/tplink-smartplug: TP-Link WiFi SmartPlug Client and Wireshark Dissector), which only worked for TCP packets, and I had to create a copy with some minor modifications to work with UDP packets.
As you mentioned, 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:
(My capture shows 2 broadcast commands from Sense every 2 seconds, but that is an artifact of me mirroring the 2 switch ports that are hardwired to 2 of my 4 wireless access points…the other 2 APs have a wireless back-haul to the 2 that are hard wired. The capture trace only shows responses from 2 of my 5 HS110s, because the other 3 HS110s are connected to the same half of my wireless network as the Sense device, and so their unicast traffic does not need to be sent through my wired switch; I hope to ARP-spoof either the Sense device or those other 3 HS110s, so that I can get their packet communication to flow through my switch to the mirror port to my next set of Wireshark captures.)
The Kasa app, upon loading issues a broadcast UDP to learn what HS110s exist on the network (using ‘{“system”:{“get_sysinfo”:{}}}’ command), but thereafter exclusively uses short/quick TCP sessions (<=50ms of TCP session handshake, command request and response, the ACKs and FIN) for each smart plug discovered for each request. The exact command it uses to request the real time power data is ‘{“context”:{“source”:“bced4ee3-cf54-4767-902a-45bab63136c7”},“emeter”:{get_realtime":{}}}’:
The Kasa app also wants to get energy stats for the current day and last 30 days and so issues the following extra commands to get the energy usage data for all the days of the current month and last month:
‘{“emeter”:{“get_daystat”{“month”:1,“year”:2020}},“context”:{“source”:“”}}’, and
‘{“emeter”:{“get_daystat”{“month”:12,“year”:2019}},“context”:{“source”:“”}}’:
I have not been able yet to capture a period of time when Sense is unable to get HS110 power data but when the Kasa app is. Hope to catch such an event over the weekend. (I also hope to catch my Wemo smart plug giving an erroneously high single power data samples, which I provided an example of what Sense sees at the beginning of this thread.)
My Wireshark capture also shows how the Sense device and the cloud communicate. Everything here is TLS sessions and is thus encrypted, but I can still see the various frequent DNS queries (to several different domain names; with Sense ignoring the DNS servers specified via my router in its DHCP lease, and rather using Cloudshare’s DNS…I’m OK with this…I may switch over to Cloudshare’s DNS rather than Comcast’s anyway) and TCP/TLS sessions, their cadences and durations and bandwidth usages. (BTW, I really hope that if Sense were to every close down or stop their cloud services, that they first create/distribute SW for the PC that can take over many of functions that the cloud services provide today (maybe not the device detection training) and update the Sense firmware to communicate to local network SW, so as to no have the sense device “bricked”.)
I have discovered, that my Asus RT-AC66U router will disconnect/reconnect from the WAN for several minutes roughly every 2 days and reports “Your ISP’s DHCP does not function properly”. I’ve seen some of the occurrences of Sense not being able to communicate with the HS110s as being caused by these events when the WAN connection is briefly down or just after the WAN connection is reestablished, though I’ve seen other occurrences when these WAN disconnects occur and Sense is able to continue to communicate with the HS110s (Sense device buffers the data internally and sends to cloud later when WAN is back up), and yet other cases where Sense is unable to communicate with the HS110s when there has been no WAN disconnects.