MT sensors making poor connection choices, gaps in Dashboard data

sungod
Kind of a big deal

MT sensors making poor connection choices, gaps in Dashboard data

In our lab/demo environment are ten MT sensors (one or more of each type).

 

There are three MRs and two MVs they can connect to, plenty of capacity for the number of sensors.

 

Some MTs are choosing to connect to a device with very poor RSSI far away, rather than one of 2-3 devices a short distance away.

 

The connections do change during the day, sometimes a sensor will switch to use a more sensible MR/MV, sometimes to one with poor signal.

 

I'm assuming that there is some algorithm to get the MTs to spread themselves across all available devices to load balance, but it seems to not pay attention to RSSI.

 

The MT40s seem worst affected, with significant gaps in some metrics on the Dashboard sensor data page. One result being that the energy use graph is often very inaccurate.

 

I'm assuming this is due to poor connection rather than some issue with the MT40s/Dashboard - the effect gets worse as more MT40s are added. With just two the gaps were minor, but with four they all show large gaps in data (gaps of 15-30 minutes).

 

I've got scripts that gather data from all sensors via the API, I'm going to leave things a few days then see if the gaps are also in API data.

 

Snapshot of connection choices, note the two MT40s using an AP that's 20 metres away and through a couple of walls, rather than one of three alternatives within 1-3 metres.

 

ModelRSSIBatteryComment
MT10-55 dBm MV2 Lab97 
MT12-59 dBm MV32 Lab97 
MT20-64 dBm MR42 East side halfway along75 
MT14-53 dBm MV2 Lab100 
MT14-70 dBm MV32 Lab100 
MT30-78 dBm MV2 Lab98 
MT40-77 dBm MR42 Near east entrance doors crazy choice
MT40-64 dBm MV32 Lab  
MT40-60 dBm MV32 Lab  
MT40-85 dBm MR42 Near east entrance doors crazy choice

 

15 Replies 15
PhilipDAth
Kind of a big deal
Kind of a big deal

Interesting finding.  It sounds like the developers need to do some more work ...

Ryan_Miles
Meraki Employee
Meraki Employee

It's important to understand how Sensors communicate with gateways. It's not like a wireless client connecting to an AP in which you typically expect a connection to the nearest AP based on signal strength.

 

The Sensor periodically wakes up and sends an advertisement. That can be intercepted by any gateway in the same  dashboard network and within BLE range. The gateway will reject the connection if heard at less than -85 dBm. We still report these connections in dashboard however which helps to show which gateways are out of usable range for each Sensor.

 

In the table above I assume the gateway is what shows on the Sensor overview page RSSI column? That will report the most recent gateway to hear BLE from the Sensor (even if worse than -85 dBm). That doesn't mean it's the only gateway that heard it nor is it the best RSSI gateway. You can see the entire list of gateways that hear the Sensor by drilling into the Sensor detail page and viewing the Device details tab.

 

Finally, the gaps in the charts. I too see that every now and then specifically for my MT40s. I've also chatted with MT Prod Mgmt about it. Please open a Support case on this one so it can get some visibility.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
sungod
Kind of a big deal

Thanks from the explanation.

 

Yes the figures are from the sensor overview page. I'd assumed the RSSI column reflected the sensor's current uplink, tbh that seems a natural interpretation of the page.

 

Once I've got a few days of data via the API I'm going to see if there's any pattern, I might increase the sample rate too - our demo lab is on the same floor as an office where there can be a lot of people with phones, headsets, laptops etc. all with BLE, it was pretty busy yesterday, maybe things will look different at the weekend.

sungod
Kind of a big deal

Probably much too early to say 'aha!', but...

 

Yesterday the gaps (on 4 different MT40s) were during times when the area was busy, wireless location analytics were showing 50+ long-duration visitors, many of whom are likely to have had multiple Bluetooth devices active.

 

Today, Friday, there're fewer than 10 visitors in location analytics, and there are no visible data gaps on any of the MT40s.

 

cmr
Kind of a big deal
Kind of a big deal

We found that using an MV can be unstable, as can older MRs such as the MR32.  It has improved with newer MT releases so make sure you are on the latest firmware for the MTs, MVs and the MR42s.

sungod
Kind of a big deal

Today the occupancy is back up according to location analytics, and again I'm seeing data gaps on some of the MT40s.

 

All firmware was/is up to date, there are plenty of available gateway devices within close range of the MT40s.

 

No sign of any gaps on MT14 and MT10 sensors in the same area.

 

Time to open a case.

 

Meganati
Here to help

Did you get any results from the case?  We are having the same issues but with our MT12s.

sungod
Kind of a big deal

I got diverted by other things, but more recently the problem was even more apparent, see...

https://community.meraki.com/t5/Sensors/Dashboard-reporting-all-MT40s-as-Dormant-Oh-no-they-re-not/m...

 

I opened a case, eventually they accepted the devices are acting as described.

 I've also supplied a lot of data from our own monitoring (via API) showing the extent of the problem.

 

No sign of any reason/resolution so far.

 

If you are seeing the same sort of problem, please open a case as that'll add more data for support to try and figure out what's wrong.

Meganati
Here to help

Opening a case is looking like our next step.  They are checking in for us but it's constantly in an alert state which leads to alert fatigue.

Meganati
Here to help

This was the response we got:

"In high-density environments with numerous gateways, sensors may frequently switch between them. This is expected behaviour, though future updates are expected to improve it. Unfortunately, there is no way to prevent this behavior at the moment"

 

Our issue isn't gaps in data though, but constant alerts that the sensors aren't connecting to access points far away from them even though they have at least 1 acceptable connection.  We have mt10s and mt12s very close to each other and only have this issue with the MT 12s.

Meganati_0-1729261237010.png

MT 12:

Meganati_1-1729261293449.png

 

MT 10:

 

Meganati_2-1729261317217.png

 

Both are showing yellow connections with not the greatest RSSI but we have only seen the MT12s alert not the MT 10s.

 

Or maybe I'm missing something and just need to move the MT12s.

cmr
Kind of a big deal
Kind of a big deal

Are you using MRs or MVs?

Meganati
Here to help

MR's, and their firmware is up to date, which puts it above the minimum firmware version.  The MT12s are as well.  This just started about a week ago, and our MT10s are not affected despite being within a few feet of the MT12s.

 

cmr
Kind of a big deal
Kind of a big deal

That's interesting, when you say up to date are you on 30.7 or 31.1.4?  Are they current models or older APs?

Meganati
Here to help

30.6 as we are a bit slow on the firmware because of previous issues, they are on an automatic schedule.  All MR33 with one MR36, so older APs.

cmr
Kind of a big deal
Kind of a big deal

They should be okay, it's more the 32s etc. that aren't good.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.