Smart plug power data glitches

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.

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

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

@james_reilley,
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.

@james_reilley, not to be snippy, but Kasa communicating perfectly with smart plugs is NOT validation that your network is not the culprit in Sense to TP-110/300 communication. Sense and Kasa use different protocols. I have a multi-access point house where I recently trialed replacing my Apple network with an Orbi mesh. The Orbi network broke a bunch of things in my house, including the Sense to smart plug communications because its default was to block broadcasts between access points that Sense relies upon. My Kasa app was unphased by the change. Kasa also makes use of different calls to a the plugs. Instead of continuous sampling, it asks the plugs for their daily history instead of continuous measurement. Bottom line is that there are many possible reasons for the data dropouts but just because the Kasa app is working fine, it does NOT mean the Sense software / monitor is at fault.

ps: On the flip side, I do think Sense should do a better job flagging and diagnosing data dropouts, so the answer doesn’t have to be “contact support” as frequently.

1 Like

Agreed, though it is a strong indication that Sense could do the communication differently (e.g. do it however the Kasa app does it, which seems to be more robust) to result in fewer dropouts (and hopefully no minute/hour/day long dropouts at all). Maybe “bug” is not the correct term, but I do believe Sense firmware could be updated to more robustly communicate with the smart plugs.

From the Kasa app, while it doesn’t support automatically polling the smart plug once every second or two, I can force it to give me a new power sample every second or two if I rapidly selected “energy” and then the back arrow and then “energy” again and so on; and the Kasa app can successfully do this when Sense is not reporting any smart plug data.

One of these days, I’ll hook wireshark up to my switch with port mirroring to see the network traffic to/from the smart plugs when:

  1. Sense is successfully communicating with the smart plug
  2. Sense is unsuccessful at communicating with the smart plug
  3. Kasa is communicating with the smart plug
I'd also want to see if there is any network shenanigans occurring right when Sense first starts to lose contact with the smart plugs.
1 Like

I would be really interested in seeing your Wireshark results. I did a little bit of playing around when I first experienced some dropouts. The Sense monitor broadcasts this TP-Link command every 2 seconds or so:

{“system”:{“get_sysinfo”:null},“emeter”:
{“get_realtime”:null}}

I can’t find my Wireshark info for the response, but I seem to remember each device broadcasting back.

So the failures can come in few forms:

  1. The Sense monitor stops broadcasting or slows down the rate of broadcast
  2. The smartplugs fail to respond
    • The initiating broadcast got lost on the way
    • The smart plug fails to respond
    • The response gets lost on the return
  3. The Sense monitor fails to register the response
    • The response arrives too late
    • The monitor is busy with something else

BTW - here’s the repertoire of TP-Link commands.