I’m also being told by support that my upload speed doesn’t meet the minimum requirements. This led me to wonder:
Is the number that they are monitoring the available bandwidth or is there only x-kb worth of data that actually needs to be uploaded? If I was bandwidth constrained, I would expect the chart to be consistently pinned t the top, with the sense trying to pump every byte over a slow connection
I’ve been actively monitoring my wi-fi connection quality and consistently shows as Excellent with a signal strength of -58db yet, I never see more than 50kb/sec of uploads
First off, if Sense doesn’t get the bandwidth it needs and/or data gets lost, for a variety of reasons, you won’t always see an immediate drop-off in the charts. Sense does things to fill missed, dropped or problematic data. The monitor also has about a 6 hour recording capability so even when you have network outage, data gets stored and saved for later upload.
But there might be other modes of issues caused by upload bandwidth. Some processes in the Sense monitor work on tight real-time deadlines since the data is continuously coming in. If there are issues getting the needed bandwidth in the moment when Sense has a window to upload, that might have a knock-on effect into other more time critical processes. So it’s probably not a max bandwidth thing but a consistent available bandwidth thing.
Here’s a view into the range of data needs between my two Senses. My Main Sense has a lot more activity - Sense plus Solar plus lots of integrations (a bunch of smartplugs, Hue, etc.) - 76 active devices in all.
You might want to try getting physically close to your Sense monitor, then running the Network test a few times when you have a bunch of other Up traffic. You might catch a situation where Sense isn’t seeing enough bandwidth (what is your ISP plan ?)
I think I finally got to the bottom of the issue, although it really disturbs me. As a security and convenience measure, I block access of all of my clients to public DNS Servers. I only allow them to use my internal DNS Server which in my case is running Adguard Home. This is to avoid tracking, malware, etc.
From what I can Sense is directly hard-coded to use 1.1.1.1 as its DNS Server. I have a few other devices that use Cloudflare or Google that use the same tactics but don’t exhibit the same issues.
The behavior that I would expect would be once Sense realizes it can’t get to 1.1.1.1 is to fall back to the DNS Server assigned during the DHCP request.
Unfortunately, it would seem that it times out waiting for a response before trying my local server, resulting in a delay and impacting data uploads. In the case of UDP Packets, I would assume that they have the potential to get lost.
So, my lesson here is that if Sense support is saying that upload speeds are too low, instead of trying to fix a wireless problem, instead:
Provide Wifi stats, e.g. Signal Strength and bandwidth metrics
Don’t assume slow upload speeds only because of a poor wifi signal.
I would certainly hope that Sense re-evaluates its DNS process so that it works in an environment where everything isn’t assumed to be open.
This posting from Sense is relatively old, but I don’t think things have changed based on other recent community discussions. It gives a little more insight in to Sense DNS behaviors, and offers an option of using your own home DNS server as the primary as an option (bullet 2).
I’m going to pull your experience out into its own thread so we can highlight technical question / problem and solution, separate from the Wishlist item. Hopefully you have “Liked”, the original post that requests better speed and other WiFi metrics.
Thanks for that info! I didn’t specifically research that as the problem and was simply trying to eliminate anything that might contribute to the issue. I will contact support and request that configuration be suppressed.
I am a big supporter of providing all information available, so will always support requests like this,
Let us know if that option is still available, now that you have more specifics for steering the support team. It might also take a little perseverance with support.
We’re they saying saying your upload speeds (to internet) or saying your sense was uploading too slow because you WiFi signal strength was too low?
I’m not sure I follow the dns explanation. Support can change your dns settings to what ever you want. I haven’t hear anyone complaining about cloudflair. Think everyone knows google collects all the data they can get. If your dealing with a super locked down firewall… sense is cloud locked with AES 128-bit encryption and TLS/SSL. Create a host and route to wan only.
We’re they saying saying your upload speeds (to internet) or saying your sense was uploading too slow because you WiFi signal strength was too low?
Yes, that’s precisely what they were saying. Even provided me a Grafana screenshot of my upload speed. Fortunately, with my Unifi setup, I was able to discount that by looking at the signal strength on the access point.
I’m not sure I follow the dns explanation.
What I am saying is that since upload speeds are reported to be slow, I suspect that the DNS queries are timing out because I had blocked access to 1.1.1.1 (and all public DNS Servers) as a general rule on my network. This forces all clients to use my DNS Servers on my local LAN.
From what I read in the support posting referenced above, this is an appropriate way to insure that the sense monitor is using my local DNS servers.
I believe though that since my upload speed improved “greatly” after unblocking 1.1.1.1 to the monitor that something in the software is causing the delay. I suspect that they try to resolve a host at 1.1.1.1 and then wait for a response that is never coming and eventually time out before querying the local DNS Server.
Just to add a clarifying point, I also validated that my DNS Response times were acceptable 14-42ms for monitorapi.sense.com
As for routing the sense to WAN only, then I would lose my TP-Link & Ecobee integrations.
When you contact support (anywhere) the odds of you getting someone that could set up more than netgear router thru the wizard isn’t very likely. Im sure everyone’s first level of support are those that can talk someone thru attaching the device to wifi… and at that, those support members probably stay busy. I did know that Tp-link/ Kasa used mDNS… I was unaware that eccobee also did.
I assume you are running a UDMpro… and maybe a Pi_hole server ? If so, in the udmp you can have your WAN DNS server pointed at your internal server then have a failover public DNS server (such as 1.1.1.1) if the address isnt being resolved in your local server or in the Pi Hole list a public DNS server as the secondary.
Hi Guys,
I don’t know if you recall but I was also told by Sense support that my upload speeds were too slow but the person would provide me with details, a grafana screenshot, etc.
I plugged my Sense Pro into a Cat5e ethernet cable.
I am still seeing dropped data in my power quality graphs that is not effecting the power meter or other screens.
So this is exactly the problem that I brought to sense’s attention. Their attempt to use CloudFlare (1.1.1.1) first, regardless of what DHCP told it is the root of this problem. As you correctly surmised, it won’t proceed to fall back on your ownDNS until a timeout occurs, causing all manner of problems.
They keep insisting it is the right way, so it probably won’t go anywhere. Yet, if they did it the other way around (DHCP DNS first, fall back to 1.1.1.1 if that times out), 99% of users would not have any problems. They also offer to change your sense’s settings for you to no longer contact 1.1.1.1. This has to be done by their customer support. This may also solve your issue, but you then give up the fallback in case you make an error in your DNS (or your ISP does).
As far as your specific situation, here is what I have done. (a) not only block outbound DNS requests (not just to 1.1.1.1), but also implement a firewall NAT rule to redirect this traffic to my internal DNS server. This way, sense thinks it is contacting 1.1.1.1, but behind its back the answer will come (pretty quickly) from your own server. It won’t be able to tell the difference and you end up getting what you want, but with this solution too, the fallback disappears. However, since there is no permanent change from sense’s side, you can change your DNS blocking/redirecting and get back the original behavior easily.
@g2d0, thanks for the chart, BTW. Good to see that Sense has a view into more details on each monitor for debug. At the same time, as we have discovered, the real challenge is in the interpretation.
It would not be a problem for something like AdGuard. Such products are designed to produce a DNS reply for blocked web site (1.1.1.1 is not a web site anyway), but it is generally 0.0.0.0 for blocked sites. So there would be no timeout issues.
Pi-Hole can do the same thing (and again that part would not be a problem), but it can also block outbound DNS access. That is subject to the possibly timeout issues if there is not also a redirect to the internal server.
BTW: The explanation for upload speed increasing after unblocking: The way sense uses 1.1.1.1 does indeed lead to timeouts, and while waiting it will not communicate. That other issue is that upon 1.1.1.1 timeout it uses internal DNS (successfully) once, and it doesn’t back-off from trying to use 1.1.1.1 and keeps trying at the exact same interval (which is frequent), instead of staying with internal DNS until a background process has successfully established 1.1.1.1 responses).
“Only a fool repeats the same failing steps over and over, expecting a different result each time”. This is not strictly what is happening here, because in theory you can change settings at any time, but the key would be to no longer rely on 1.1.1.1 after the initial failure until some independent process has re-established access to 1.1.1.1. That said, taking the better, and in my opinion correct, approach avoids this issue altogether.
That was exactly what I was thinking. I haven’t had time to validate or sniff the traffic to validate, but it is consistent with the behavior I am seeing
That is exactly what I observed in my firewall: frequent and continuing requests to 1.1.1.1. For me this happens about once a minute (see below), but sometimes in as little as 30 seconds.
I also observe that the TTL (Time To Live) of DNS responses for api.sense.com is 60 seconds. This forces any DNS request to re-issue a request, bypassing cached results, after one minute. Often times such short TTL is used during an expected service change-over, but generally in stable production, the interval should be significantly longer for efficiency reasons. Please note that successful setup of an internal DNS server does not change these intervals: it will be forced to reach out to external DNS for a “new” answer after 60 seconds, but if properly configured, that answer will come quickly and not timeout.
My typical scenario (I did this for a living for years): Run in production with 3600 seconds. About 1.5 hours before a planned change, change DNS setup to go to 60 or 30 seconds. This guarantees that all well behaved clients are not checking every 30 or 60 seconds… Make the changes in IP addresses (clients may attempt to contact the “old” server(s) for no longer than 30-60 seconds. When change-over is complete, change DNS TTL back to 3600 causing all clients to become efficient again.
I also notice that DNS for api.sense.com returns two addresses, which then suggests they are load balancing API requests between two (Amazon EC2) cloud servers. In theory a short TTL can cause clients to switch servers frequently, which may appear attractive, but in practice, well behaved clients will randomly choose from the set of DNS answers any time they do a local lookup, so this again is not necessary.
Sense Pro is an upgraded sensor that is only available to Sense resellers https://pro-sense.com One of the advantages of this is that it includes an ethernet port (as well as “revenue grade” sensors).
Ah… I had seen the sensors, but hadn’t read read further. My bad.
Ethernet would have been of great interest to me at the beginning. Now, it wouldn’t be worth it due to the pain of replacing the unit with the resulting data loss.
