Smart plug power data glitches

Couple things: first, if you haven’t already, definitely report this in to the Support team. I just went through all my plug data and am not seeing any dropouts (that I can’t make sense of by comparing to my Unifi data). With that last point in mind, are you totally certain these aren’t broader network issues?

Let me bring this up with the team as well and get back to you.

1 Like

I think Sense and Kasa talk to TP-Link smartplugs via TCP port 9999, but from what I remember from using Wireshark is that the communication is all UDP packets and protocol. Sense sends a UDP multicast broadcast with the following “emeter” request to port 9999:


All the TP-Link devices that have power monitoring respond back to the Sense via a UDP packet containing the status, including the power reading (or not, subject to any temporal networking or device issues). AFAIK, neither TP-Link or Wemo Insight have any local timestamped log of monitored data, but the TP-Link must have some kind of daily and monthly accumulators to support the API commands below:

Get Daily Statistic for given Month

Get Montly Statistic for given Year

Bottom line - As @RyanAtSense suggests, it’s probably best to contact support, since any one of a number of things could be stoppering up the communication. It would be great if the Sense/smartplug communication was end-to-end guaranteed, but the TP-Link protocol really doesn’t support it. I do wish two things:

  1. Sense would mark the data differently so we could tell the difference between a true 0 and NA (not available).
  2. Sense would flag excess NA generation, either from smartplugs for from the CT main/solar measurements, so they could trap any issues with the Sense monitor and I could check my network more quickly for issues.

I kind of alluded to that in this wishlist item here. Like this request to help influence this a new feature.

1 Like

I haven’t vetted the Sense smart plug data. But the raw data from some of my HS110s and the HS300 is glitchy.

I intend to provide a sanitizing feature. Maybe Sense already does that.

I see individual samples well over 10,000 watts. And one sustained (15 min) burst of 283,233 watts.


@duanetiemann, with your experience with the TP-Link smart plug API, is the emeter data retrieved via TCP or UDP, or are both options? Do you see occasional periods of time, seconds to minutes in duration, where you get no samples back from the smart plug, using your utility?

Does the API allow historical emeter samples to be requested, or if a monitoring client (like Sense or your own tool) misses an emeter sample point, the missing data is gone forever?

I have seen my Sense record >10kW power samples from my HS110 (but not for 15 minutes…I’ve only seen a few such >10kW glitches, and each only for a few seconds), so I don’t think Sense implements a “sanitizing” feature. What were you thinking…if emeter sample > 2kW (or some other threshold), then treat it as an error???..clamp it to 2kW???..return the last known “good” sample instead???..return 0W???

I’m curious if you have had any technical collaboration with TP-Link or Sense.

I use TCP. I don’t know of a UDP interface. I have seen periods of no data, but it may have just been problems in my network delaying requests.

There is a daily summary history available from the plug that can be queried with the get_daystat request providing month and year of interest. I don’t think individual past samples are available. BTW, You can also access the smart plugs remotely via their website. I don’t know if the plug gets the daily numbers from the website or stores them locally.

I’m reluctant to sanitize data. I’ve been critical of Sense zapping Other to zero when individual measures add up to more than the total observed. But these seem to be clear measurement errors that are not particularly useful. I expect I’ll provide a sanitization option so users can see where raw measurements went south if they need to, but generally expect that they would use sanitized versions. The threshold should be a setting, IMO. And glitches should be reported as missing data when sanitized.

I would expect that I reported the errors to TP-Link, but I don’t see any record of that. Maybe I didn’t get to it.

I don’t have any formal relationship with Sense or TP-Link, other than being a beta tester for Sense.


TPLink and Wemo work differently on the network.

Wemo uses a separate HTTP transaction to fetch the current wattage. This is slow and generally an extremely inefficient way to get the ~16 bytes of information which we actually need. Having to do this every few seconds contributes to the overall latency of your network and can definitely saturate Sense’s wifi connection with enough plugs.

TPLink has two ways to fetch the current wattage: TCP, UDP unicast and UDP broadcast. UDP broadcast is the best choice for sense because:

  1. 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.
  2. 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.

As for the weird data above, Sense believes the plugs. The plug from the first example was claiming 11188.48 watts, 15 times in a row, and it continued with its weird readings afterwards, as you see in the plot.

For the instances of dropouts, it’s either that the plug was reporting zero watts, or that the plug was not responding to queries for that time period. We see both happen, but not too frequently.

Currently, Sense does not do any scrubbing of high-but-possible numbers from the data (10kW being in the sane range for a plug to report).


Thanks for the explanation Jonah ! This kind of tech info is good for helping the user audience to understand why adding and supporting different smartplugs isn’t a trivial exercise, plus the tradeoffs involved in semi-realtime data acquisition.

I wish that dropped/missed data packets would not be treated as 0W by Sense, but rather as “missing data”. Some of my smart plugs are on devices that are always on (e.g. model/router/switch/NAS), but due to missing packets, Sense currently erroneous thinks these devices briefly consume 0W and thus doesn’t consider these devices as “always on”.

1 Like

I assume perhaps naively that the complication there is that the database is “numbers” so N/A does not compute. How to encode and store it?

@JonahAtSense: “-1”?

Most data science infrastructure (R or python packages) has native encoding for ‘NA’ for all native datatypes plus ‘NaN’ (not a number), ‘Inf’ and ‘-Inf’ for numeric types. And pretty much all core R functions and packages know how to deal with these. How these are encoded underneath is hidden from the user. But since Sense communicates data to users via CSV, external coding is via ASCII/UTF. CSV readers have appropriate conversion options to convert text NA to a data science NA, etc.

I’m assuming that all our monitor data flows into a data science savvy database system. How Jonah would convey NA from the Sense monitor to the mothership is probably more a function of the data protocol of the send packets.

Understood … though what I was getting at was also “how does Sense encode it their end”. The user data (CSV) seems manageable … I’m wondering I suppose if what could/should be “NA” encoded in the sampling is actually “0” at the sample level?

I wish that dropped/missed data packets would not be treated as 0W by Sense, but rather as “missing data”.

We actually do have some hysteresis to prevent occasional dropped packets from producing sudden drops in the wattage graphs. A dropout has to occur for something like 30s before it’ll count as a zero wattage.

I think the request to show offline as “n/a” or some other non “0” representation is reasonable, and I’ll forward that feedback to the product team for consideration as a future improvement.


Thanks @JonahAtSense,

Sounds like the hysteresis can “fix” short dropouts. I already have a wishlist item to optionally expose missing data in the UI and export via something like NA.

@ixu, there’s one more tricky element about dealing with NA. When I added my wishlist item, I suggested it as an option that a user could toggle on and off. Why ? Aggregation operations. When Sense rolls up hourly, daily, monthly and billing cycle level data, there are two ways to do the aggregation math:

  1. Treat the NAs as NAs which means that an hour of power consumption with 59 min and 30 sec of good data and 30 sec of NA, sums to NA. That’s a good thing when you are looking for issues and trying to understand their sources. Not so useful when you want to squeeze out as much info as you can from the data.

  2. Treat the NAs as 0. That’s how Sense currently functions. That kind of hides data loss, especially when aggregated into hours, etc.

There might be a hybrid approach that aggregates an entire hour of NAs to NA, while treating the NAs like zeros if the NAs don’t fill an entire hour. But probably the best option would be to only expose the NAs in the main and smartplug Power Meters - that would pinpoint the exact times of missed data. Then Sense could continue to aggregate with NAs treated as 0, exactly as they do today.

1 Like

@kevin1 … nice explication.

The other method, I think, though potentially complex from a few angles, would be to stick to the NA as 0 and break out the NA event into a separate log.

  • Infrequent (>1hr) NA cycles could be logged without significant processor load (?) or data overhead.

  • Mid-frequency cycling NAs (<1hr) could be logged either in detail (if processor/data allows) or aggregated and characterized in the log.

  • High-frequency cycling NAs (~1s?) could trigger some kind of modal behavior. Methodology open to debate on that.

In any case, the existing method of NA=0 could be adhered to and historical data exports remain valid.

I see some kind of log export of other data as inevitable anyway.


Special handling of missing smart plug data is one thing (keep discussing this in this thread), but I’d like to reduce the occurrences of missing data samples from smart plugs in the first place. I think Sense needs to do a better job of knowing when a smart plug is on the LAN and querying them for their data. My home’s wifi is from a Plume mesh. I think Plume “optimizes” the mesh something like once a day, during which time some or all of the wifi links within the mesh are off for seconds to several minutes. Sometimes this results in Sense not getting the smart plug data briefly while the wifi is down, but occasionally after wifi is back up, Sense won’t get smart plug data for hours or even days. During these long periods of time, the wifi and LAN and WAN are working fine for everything else on the network, and I can even go in to the Wemo and Kasa apps and see the smart plugs and their power, its just that Sense doesn’t know they exist during these hours or days, and so a huge gap in smart plug data results. Sense needs to more quickly see all the smart plugs and restart querying their data after there are wifi disturbances.

Perhaps a new option for users to force Sense to search for smart plugs on a LAN (though ideally Sense would detect them all within a minute of adding one or after wifi disturbances end).

Related to smart plugs, there needs to be a way to “delete” a smart plug device from Sense. That capability seems to be missing. I had a smart plug on my Christmas tree lights last year that I lost, and I can’t get rid of that smart plug device within Sense.

1 Like

Missing smart plug data samples need to be treated differently for the various features Sense provides. My suggestions:

Always On-ness:

  • Should only consider non-missing data samples.

"Ground truth" for aiding detection:
  • Should somehow only consider sets data samples that don't include or are near missing samples.

Merged discovered devices with smart plug:
  • (I'm not familiar with how Sense does this, as I only tried this for the first time yesterday, so I'm not going to suggest anything here.)

Device [smart plug] bubble:
  • Missing data to result in bubble disappearing, though perhaps with a low pass temporal filter so that the bubbles don't appear/disappear rapidly.
  • Don't think the bubble view should attempt to notify the user about the difference between missing smart plug data vs 0W.

Device power meter:
  • (I primarily use the iOS app and not the web app, but I just noticed that the web app doesn't even provide this feature. Is this a bug in the web app?)
  • Somehow clearly convey a difference between smart plug samples that are missing and which are truly 0W. (Maybe when a sample is missing, the plot should not have a red line at 0W; and to have the power value shown in the upper right as "NA" or "" when the vertical grey line is over a time where a missing sample occurred.)

Device [energy] usage:
  • If % of ~1s samples that are missing, within whatever duration {hour, day, month} the energy consumption has summed up, is greater than some threshold (maybe 5%), then somehow clearly convey that some of the energy data is missing. (Perhaps use a slightly lighter shade of green.)

Device [energy usage] data export:
  • Option 1: Add a new field (column) for each smart plug device that provides the % of ~1s samples that are missing, within whatever duration {hour, day, month} the energy consumption has summed up. I like this option, as it provides flexibility to offline processing of the exported data.
  • Option 2: If % of ~1s samples that are missing, within whatever duration {hour, day, month} the energy consumption has summed up, is greater than some threshold (perhaps 5%), rather than report a numeric energy consumption value, report either "NA" or "".

"Other" device:
  • (I'm going to ignore this for now; doesn't make sense to discuss how to handle the Other device when smart plug data is missing, before knowing how to handle the smart plug device itself when data is missing. Plus, the Other device already is weird, I think this thread is not the appropriate place to discuss the weirdness.)
1 Like

There’s a wishlist item for improved device management here, that kind of covers better handling of smart-plugs and their persistent histories.

All good suggestions. I tried to stay away from thoughts on how Sense should deal with NA in their data science / ML analysis, since I really have to trust them to experiment and get it right. That said, I agree that Always On should not consider missing data intervals as 0W !

As for the user viewable representations of the data:

  • I would like both the Device power meter and the main Power meter to show NA periods differently than 0’s, or else at least provide a log as @ixu suggests
  • I like your thoughts on thresholds for all the summary / rollup usage data
  • I like your ideas for Export
  • Agree on the bubble view

Thanks for putting deep thought into this semi-spec !
ps: Yes - The Web App lacks the Device power meters today. The major difference between iOS/Android and Web App.

Sense definitely has a bug in how it communicates to the Wemo and TP-link smart plugs. I have not contacted support about it, though I did start thread about this last month: Smart plug power data glitches

My reasons for calling this a Sense bug is that, just as @ian.heritage states above, that there are periods of time when Sense reports 0W from a smart plug when the smart plug apps (Wemo app or Kasa app) are able to successfully communicate with the smart plugs. While the LAN that Sense and the smart plugs are on may experience issues that cause 1 or 2 seconds of smart plug data to be missed, Sense should not loss contact with the smart plugs for hours.

1 Like