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.