MT sensors making poor connection choices, gaps in Dashboard data

[sungod]

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.

Model	RSSI	Battery	Comment
MT10	-55 dBm MV2 Lab	97
MT12	-59 dBm MV32 Lab	97
MT20	-64 dBm MR42 East side halfway along	75
MT14	-53 dBm MV2 Lab	100
MT14	-70 dBm MV32 Lab	100
MT30	-78 dBm MV2 Lab	98
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

[PhilipDAth]

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

[Ryan_Miles]

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.

[sungod]

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]

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]

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]

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]

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

[sungod]

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]

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]

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.

MT 12:

MT 10:

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]

Are you using MRs or MVs?

[Meganati]

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]

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]

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]

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

[JAH101]

we have a similar issue with MR46, ALL of our MT sensors MT10, 20, 40 went offline and stayed offline, at the exact time firmware was upgraded on the AP's to 31.1.5.1 (latest stable), the AP's report that they are now detecting poor RSSIm -87dBmm cutoff -85dBm, even though they were perfectly fine for weeks before the firmware upgrade!

nb. we are trialling these sensors currently, but obvs won't be using them if they are this unstable!

[sungod]

I suggest open a support case with Meraki as the MT issues were resolved ok for us.

[JAH101]

Thanks we have a case currently outstanding with Meraki Support, will check with my engineer on current status.

[Meganati]

The result of our case was we unplugged for 30 seconds and then replugged into power and power cycled them and for 2 sensors it worked the first time, for our other 2 it worked the 2nd time.  No problems since.