Data Gaps in Timeline/Meter


Just wanted to point out this is also in another thread with the same problems. Might want to combine the two if that is even possible.



WAN or LAN? Sounds like a lot of retries to me. While I agree Sense may need to be more ‘user friendly’ with their data, you’re also dealing with a real time device with a lot of data exchanged.

BTW, with 0 retries Sense uses about 100Mb/day up and down combined consistantly.



Interesting you mention about 100mb/day up and down. My numbers aren’t quite as symmetrical as yours. Over the last 30 days I’m seeing 3.11 GB (↓840.5 MB, ↑2.29 GB).

1 Like


Per day, up and down combined.

30 days @ 100Mb/day = your monthly numbers = we’re on the same page :slight_smile:



Your right. Helps if I read it correctly. Funny what one word (combined) can mean… :grin:



My sense used more than 10 gigs in the last 30 days for uploads. Is this way outside the norm of what others are seeing? Could it be related to the failures?



Just a back of the napkin on data rates:

  • If the Sense monitor was merely uploading raw samples to the mothership at Sense’s rated acquisition speed of 4M samples / sec (14 bit / 2 byte samples), we would see just shy of 7GB up per DAY. So lots of local processing and compression on the monitor.
  • What is down traffic ? New firmware, new models, directives, requests for other data ?
  • Not included in your measurements (I think) is all the local broadcast activity Sense does to discover, manage and acquire data from smart plugs and Hue.

I think our Sense monitors stay very busy…



Are you seeing close to 10GB also? I have about 150 hue lights, and maybe 10 of the smart plugs. Still can’t link in but one Hue bridge though, so maybe 50 lights are connected.



I don’t have a smart enough network to isolate a single wireless device’s bandwidth usage. I actually took my whole house network down for two days trying to install an ORBI and new Netgear switch, but ran into a host of unanticipated issues. Turns out the ORBI doesn’t have said capability either, and the switch, despite doing a good job of port monitoring, had lots of “advanced” features that shut down other devices in my house.

Based on what I’ve heard in seen from Sense users and others, that my next network will be based on Ubiquiti, since their systems do offer better traffic analytics and integrated control. Still waiting for one of my friends to get the wrinkles out of their new Ubiquiti system before I follow.



Meraki at home… nice!



How are you measuring this? 10GB traffic to the WAN is different than through the LAN.



Google WiFi lets you name/identify any devices that connect to your network, and then provides measurements for up and down data. I can’t image they are trying to capture local only traffic. I would assume this is to the WAN. Screen shot attached…



I would actually think that it is capturing all activity, whether LAN or WAN.

Speaking for Unifi AP’s and Ruckus AP’s. The controllers track activity by device for all data that passes an AP. It doesn’t “know” where that traffic is headed. With UniFi because they also have routers within the same control system as their AP’s you are able to get some WAN specific usage data, but I don’t actually think you can get it by device.

I sort of assume Google works the same way because if its only tracking data that egress’s the network, that means that any device on your network that doesn’t go to the internet would show no activity. So a NAS that is used only as an in house media server would show no activity.

I could very well be wrong. I have zero experience with the google products, but it just seems like a big break from what I would say is industry norm.



Found a help document online which says its only capturing WAN traffic. Which I think makes a lot more sense for a consumer product at home. They pitch it as a way to track your usage vs your ISP’s data caps.

1 Like


Good to know! Thanks.



I’m not sure if this is related, but I also get gaps in the real-time meter, but I believe the root cause is a custom node socket integration I’ve been running thats always reading in my data. If I kill the node server, the mobile app real-time view returns to normal.

I used to be able to open the Sense mobile app while the node server was running, and everything was fine (although closing the Sense app would also kill the node server’s connection, triggering a re-auth action). But now, the mobile app seems to really not like it if I already have the node server running and reading my data.

1 Like


I have found that the real-time display on the Sense iOS app stops updating if I log into the Sense Web app at the same time. The moment I log out of the Web App, the iOS real-time display resumes. The Watt values continue to update.

It appears that no data is lost, but just a real-time display interruption.

I’ve had other iOS display interruptions where the real-time display fades for a second and then a gap appears. The data appears to be affected when this event happens. I haven’t been able to determine a cause.



This seems to further confirm there’s a hard limit on number of real-time socket connections allowed per user. If you’re already pulling real-time data through one method (app, web, or API), the others don’t work. I’m still wondering if something has changed in the last month or two that has made this limit more strict. I get that Sense would want to avoid everyone having a bunch of open connections, but only 1 at a time is kind of bummer.



I have the same issue sometimes and it’s always internet.
I too will have strong wifi and the access point (DSL modem)
will also show connected. Although the modem is connected with
a strong signal, it has lost its’s IP address. If the service provider
has the settings to renew IP daily and you having this happen once
a day, this might be the cause. The dropout can be from the time
the ISP says its time to renew the lease and it picks back up when there
is device traffic to request a new lease.
This would not apply if you’ve checked these dropout times on your access
point (not WiFi) and verified that was ingoing/outgoing traffic of some kind.



Remember, if you’re experiencing an issue like this, please submit to Support with as much detail as possible! We’re working on it, but are having trouble reproducing on our end.