I have a Seeed Studio XIAO ESP32C3 device (with external antenna) running version 1.8.1 of the OpenMQTTGateway, mainly to pick up data from my BM2 and BM6 car battery monitors. This is working well, apart from the home and away status. In both cases, the tracker status keeps changing between home and away frequently, even though the vehicles are stationary outside. Here are two screenshots, one from the BM2 monitor and the other from the BM6 monitor.
This is likely due to unreliable reception of your BM2 and BM6, timing out with the set tracker timeout when no broadcasts from them have been received.
You can monitor the reception reliability with MQTT Explorer, bu looking at the history of both devices, to see if they are being received every time a scan is done with the interval set.
Some better - higher and closer to the cars- placement of your XIAO ESP32C3 should help.
You can also change the value of of the interval from the default of 55 seconds to 20 seconds, and also increase the tracker timeout from its default of 2 minutes to something higher like 3 or 4 minutes.
In the end you want to adjust these values so that the Away status is only relaibly activated if either car really is away and therefore no more broadcasts are being received.
First of all thanks for taking the time to respond, it is much appreciated.
With regards to the reception stats, I cannot move the device any closer, but as a trial I could park my car differently to see if it improves the situation. I will try that over the weekend.
Based on your recommendation, I changed the interval setting (not intervalacts) to 20 seconds and presenceawaytimer is set to 180 seconds. In MQTT Explorer I see values coming through roughly every 30 seconds. Is that because scanduration is set to 10 seconds, and 20+10 makes 30?
In any case, it hasn’t made a difference. Here’s a screenshot from MQTT Explorer, with the “offline” state in between two good readings. As you can see, the signal strength is pretty decent:
That’s exactly it, after the 20 seconds interval there is a 10 second scan(duration) = you should see broadcasts being received and published to MQTT every 30 seconds
Your signal strength does look fine, so there shouldn’t be any need to place the XIAO ESP32C3 differently at all.
However the two “good” messages with the “offline” message in between are both not quite that good as you can see that both of them do not actually contain correctly decoded BM2/BM6 properties, including the model_id nor the battery level. So if you look further down in the message history, very likely around 3 minutes before the “offline” message was published, you will see a correctly fully decoded message, meaning that this was the last time the BM2/BM6 was fully decoded and registered as such, and all the other non decoded messages do not count as the BM2/BM6 being present at all.
Can you set the BT setttings
onlysensors
to true. This should then hopefully only register and published fully correct BM2/BM6 messages, and not possibly overwrite them every now and then for the every 30 seconds published messages by non-decoded messages you see in your screenshot.
I’m also wondering if this is due to a setting in the native app for the BM2/BM6, which makes it also publish non recognisable broadcasts, but am not sure as I do not have such a device myself.
Let us know how you get on with onlysensors: false, and possibly post another screenshot, also with a properly decoded message.
I’m pleased to report that setting onlysensors to true and extending the presenceawaytimer (currently set to 10 minutes) has helped, for the BM6 device at least. From MQTT Explorer I can see that every so often there are large gaps when there is no data being received from the BM2, which causes the device to be reported as away, however, given the BM6 works properly, I suspect it’s a specific issue with my BM2 hardware.
I have heard this before from some other user, and also with other devices sometimes the broadcast behaviour is different depending on whether the device is linked and paired with the native app or not. So you could try unpairing the BM2 from the app, or pair it if it currently isn;t paired, and also see if there are some settings within the app which might change its broadcast behaviour.
Not having a BM2 myself I don’t really know what it might be, but it definitely is worth trying such options first before getting another BM6
Any idea if / when we might see voltage readings from BM6?
Now that the decryption key for the BM6 is also known it should only be a matter of time before the voltage connection retrieval for the BM6 is also added to OpenMQTTGateway, but I cannot really say when that might be.
And I presume the BM6 MQTT device is not created, you just see the information on the OMG console or MQTT explorer, can you confirm ?
The above is what happens to me, I got 2 BM2 working great, then the BM6 on a third car that does not generate a MQTT device like the BM2s.
Thanks for any clarification.
For me, the BM6 did appear automatically in the MQTT integration in Home Assistant, same as the BM2. Interestingly (still within the MQTT devices section), both devices are shown as connected to an “Unnamed device” rather than the device running OMG.
@jojo01fr Have you tried turning DISCOVERY on again and then restarting the gateway?
This is usually required to auto-discover new divides, as DISCOVERY turns itself off after 30 minutes, and the restart is required when turning it back on again to fully auto-discover new devices, as described at
The BM6 should also be discovered and received and published by MQTT, the only difference being that the BM6 only has the battery level, but no voltage integration implemented so far.
Fine. Are you using OMG version 1.8.1 ? I remember my BM6 was discovered when under 1.7.0, then I deleted the MQTT device and upgraded OMG to 1.8.1 and now it only discovered my other BM2s. BM6 only shows rssi in console, discovery does not create it on MQTT devices as the topic homeassistant/sensor/BM6mac-batt does not appear on MQTT Explorer.
Below, screen capture of the BM6 on MQTT Explorer
Can you monitor if your BM6 does not also send messages with the manufacturerdata starting with
4c0002153ba29cd9a42c894856badaf2606ef777…
as this is the data from which the battery level is being decoded. The manufacturerdata shown in your single message sample above is a different format not known to the decoder. Could it be that you might have changed settings for the BM6 in the native app?
Then decoder itself haven’t changed at all from OMG 1.7.0 to 1.8.1, as it is exactly the same as initially submitted, without any changes whatsoever
Is there any setting in the native app to change the broadcasts to iBeacon format, or possibly the BM6 needs too be removed from the app, or paired with the app, if not already paired … whatever settings make it broadcast in the iBeacon format again so that it can be correctly decoded for the battery level with the decoder.
The only thing I remember is that I use different Android APPs, Battery Monitor for BM2 and Battery Asst for the BM6. I’ll give a try tonight afterwork and let you know.
Its manufacturerdata is indeed different:
“manufacturerdata”:“d605020048000288000000034301640000ab010000c75d476ca696ab19”
as you can see that both of them do not actually contain correctly decoded BM2/BM6 properties, including the 
