MT sensors making poor connection choices, gaps in Dashboard data

Head in the Cloud

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.


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


Kind of a big deal
Kind of a big deal

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

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.

Head in the Cloud

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.

Head in the Cloud

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.


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.

Head in the Cloud

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.


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.