Im using the esp32dev-ble (v1.6.0), it has discovered the BM2 monitor correctly, and the percentage is always right but the voltage sporadicaly changes between 0v and the actual voltage. Its a bit odd, looking through the MQTT messages, I cannot see it publishing a 0v message:
{
"stat_t": "+/+/BTtoMQTT/50547B22656A",
"dev_cla": "voltage",
"unit_of_meas": "V",
"name": "volt",
"uniq_id": "50547B22656A-volt",
"val_tpl": "{% if value_json.uuid is not defined and value_json.volt is defined -%} {{value_json.volt}} {%- endif %}",
"state_class": "measurement",
"device": {
"identifiers": [
"50547B22656A"
],
"connections": [
[
"mac",
"50547B22656A"
]
],
"manufacturer": "Generic",
"model": "BM2",
"name": "BM2-22656A",
"via_device": "SLKbattmon"
}
}
Here are my settings in case I have something misconfigured:
Iām not sure how you define āall my devices on one platformā. However from my experience with bluetooth on various platforms and configs, I would recommend abstracting the bluetooth ācentralā function away from being on the same box as Home Assistant. While HA folks have done good work to make bluetooth on various versions of Linux more robust, it is just too easy for the bluetooth adapter to get into weird/non-working states. Bluetooth is an amazing platform, however it is a moving target for OS developers to keep all of itās possible configurations running, and wow it has many configurations. The various ESP32 bluetooth ācentralā (aka device that translates some form of Home Assistant API to a conversation with one or more bluetooth devices) are pretty good cost/complexity/functionality path. That said, I still have a very old Raspberry Pi 3 running a frozen in time version of Linux (and bluetooth stack), for one of these ācentralā functions in my mix, because āit just worksā. Good hunting.
On a side note, the BMx family of battery monitoring devices in an interesting thing. The BM2 seems to be the simplest to start with, however from what I can tell all BMx devices are exactly the same hardware as the BM2. For the most part, again from what I can glean, they just changed the bluetooth encryption key in devices after the BM2, after someone did an amazing job of reverse engineering the encryption keys out of an android app. If you are up for a little adventrure, the BM2 and I think BM6 at least can be reflashed with custom firmware that gives you full control over the advertising data, adds access to motions data.
I use ESPHome and bluetooth proxies around my house so where possible Iād rather have something which can send out standard BLE announcements and be handled by ESPHome than needing to add OMG or similar into the mix - thatās nothing against OMG, I just like the āsingle pane of glassā view of my ESP devices that ESPHome provides.
Good to know about reflashing the BM2 - that might be an option.
I am however almost certain somebody came up with an ESPHome config which was able to recieve/decrypt the BM2 packets otherwise I had the weirdest dream (I love tech but not enough to dream about something like this )
I had been attempting to re-purpose an ESP32 dev board that I had initially flashed with ESPHome Bluetooth Proxy. I fought with this on and off for what feels like months and finally it hit me to try and comment out the BT Proxy business:
And both the BM2 as well as another Otodata propane tank monitor I couldnāt get working started reporting data to Home Assistant. I canāt say an ESP32 canāt do both BT Proxy and these other esp32_ble_tracker / ble_client roles, but that seemed to be causing a conflict for me in some way.
Which Battery monitor are you using and which ātypeā do you have it configured as? Iām attempting this path and canāt seem to get it working 100%.
Now I finally see the OMG Wi-Fi. Unfortunately it times out after a while so I only can enter the Wi-Fi password. Once it connected to my Wi-Fi I want to configure the remaining parts (especially MQTT).
But when accessing the web interface, Iām asked to provide a username and password. What are those? Tried everything I could find especially from Wifi and MQTT configuration | OpenMQTTGateway v1.6.0, but no luck.
TBH this is really not the best onboarding experience I have so farā¦ looking forward to finally get things working! Never had such trouble with all my other ESPs, no matter if with ESPHome, Bluetooth Proxy or other custom images like Nuki Hub etc.
And how to change those authentication information? Of course I donāt want to keep those defaults.
Answered that too: needed to long press the reset button. Can only be set on the initial setup screen (a design failure in my eyes).
Obviously you didnāt have the best experience, especially with your initial
(probably for the 15th time)
which Iām not sure what caused this for you, and with which OS, browser and driver.
Or through custom environment builds. But as an open source project we are listening to user suggestions for improvement and are also taking submitted improvement pull request and feature requests into consideration.
The result from your posts is that we are looking into adding changing the WebUI login credentials from within the WebUI in a future update.
Now finally: Iāve setup OMG. It discovered my Mi Scale at first which is shown on the web interface (and being auto-discovered by HA already). Now I relocated OMG next to the BM2. While it is discovered according to console:
N: Send on /BTtoMQTT/XXXXXXXXXXXX msg {"id":"XX:XX:XX:XX:XX:XX","name":"ZX-1689","rssi":-82,"txpower":0}
thereās no auto-discovery, no entities are created in HA - nothing in MQTT. - Can OMG only catch one sensor at a time? - Do I need to configure anything else?
Please note my HA Core version is 2023.3.6.
Also seeing this on the console:
N: Send on /BTtoMQTT/XXXXXXXXXXXX msg {"id":"XX:XX:XX:XX:XX:XX","name":"ZX-1689","rssi":-87,"txpower":0,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"yyyy","uuid":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy","major":-2495,"minor":20865,"volt":10}
You really are having a lucky dip here today with OpenMQTTGatway!
Anything which could and might go not the expected way seems to be coming your way
I have just read up on this new, personally never before heard, name "ZX-1689", which apparently is only being used for BM2 battery monitors being distributed in Germany. Is that where you are located?
Not knowing if it this BM2 variant might also be using differently encoded device information, would you be able to set Advertisement and Advanced Data to true, which is also available as a switch in your HA OpenMQTTGateway settings, and give another sample data again?
If the decoding is the same as all the other BM2 models and only the broadcast name is different we can have a build ready for you in a few hours which also includes this German variant.