Maybe due to your HA version as you seem to be the only one getting this issue
Thanks, I have updated now, will report back if it re-occurs.
Anybody?
I’m happy to try OMG but I’d rather keep all my devices on one platform.
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 used the config posted by sew999. I’ll draw attention to a few points that hung me up:
I’m pretty sure this is the include.h in question.
The arduino part in this section is important otherwise it won’t compile properly:
esp32:
board: esp32-s3-devkitc-1
framework:
type: arduino
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:
#packages:
# esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic.yaml@main
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.
DaBer
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%.
Finally a bit time to follow-up on this. Erased, board information:
Flashed with esp32dev-ble
again (probably for the 15th time):
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.
Hope this helps
Indeed it does, but meanwhile I found it here: OpenMQTTGateway v1.6.0 released : r/esp32 (reddit.com) admin/OTAPASSWORD
.
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.
I will look into this asap. I spent more than enough hours today for this, hope to turn back shortly with the requested information.
For now: “ZX-1689” seems to be (hopefully!) just a variant of the BM2, distributed by PEARL and labeled with Lescars (which I think originally is a French company?) mainly in Germany (Lescars Kfz-Batterie-Wächter mit Bluetooth und App, für 12-Volt-Batterien).
Oh yes, Pearl love re-branding devices
Looking forward to your future sample data with the advertising data turned on, so we can verify if the data encoding is hopefully the same.
Can you work with that output?
N: Send on /BTtoMQTT/XXXXXXXXXXXX msg {"id":"XX:XX:XX:XX:XX:XX","mac_type":0,"adv_type":0,"name":"ZX-1689","manufacturerdata":"4c000215655f83caae16a10a702e31f30d58dd82f641518164","rssi":-83,"txpower":0,"distance":12.61001,"brand":"GENERIC","model":"iBeacon","model_id":"IBEACON","type":"BCON","mfid":"4c00","uuid":"XX5f83caXX16a1XX702eXXf30XX8ddXX","major":-2495,"minor":20865,"volt":10}
I don’t know if uuid
is potentially sensitive too so I masked it partially.
No, all fine, and it looks like it really is only the name which differentiates your BM2 version from all the others. That is if your battery is at 100%
Will you be able to still try out a test build in about 90 minutes tonight?
Just asking as all potential test builds would be overwritten again by the nightly development builds later tonight, so if you cannot install a test build later tonight it might be better to build one for you tomorrow during the day.
The test build will also include the voltage, which is fetched by connection.
Great to hear
- No, I won’t manage to test it today. Probably tomorrow (Friday), very likely on Saturday. Hope that helps to avoid unnecessarily redundant work.
- Great to have the voltage. Looking for percentage + voltage
- Few other questions based on first experiences with OMG (needless to say: awesome platform, will probably solve a few other use-cases for me):
3.a) My MiBand (Xiaomi Smart Band) was discovered (somehow, suddenly, even it should not expose itself and even BT proxy could not find it - plus 1 for OMG ), so I have tracker, activity/bpm and steps sensors. While all of them areunknown
ornot_home
currently, I noticed that for the device_tracker entity thesource_type
attribute in HA is set wrong: it isgps
while it should bebluetooth_le
. Unfortunately it seems you need to fix that somehow in OMG, I can’t “overwrite” this using customize.yaml
3.b) When I disable and re-enable theBT: Publish HASS presence
switch, the entitiesBT: Interval between active scans
,BT: Interval between scans
andBT: Presence detection timer
always return to a default value (my custom set values are overwritten/forgotten). E. g. if I got right how this presence detection works, I don’t want to constantly search (equals the default 0 seconds) so I set it to 60 seconds.
No major work, and I started a test build anyway, which would be available in about 60 minutes now. But if you can’t install it then best to give us a shout here if you can do it Friday or Saturday, so we can start another test build then.
Your Mi Band (which version may I ask?) is being discovered, but the activity heart rate and steps will only have values if these options are activated in the settings for the Mi Band in the Zepp life app.
I’ll have to refer this one to a colleague …
Could you try and set Adaptive Scanning to false in the OpenMQTTGateway settings and see if the behaviour is then still the same, as Adaptive Scanning sets some defaults depending on the devices discovered in your vicinity, but for manually setting the the values Adaptive Scanning should be turned off - something which we could possibly automate when these settings are touched
I’ll do so (likely on Saturday).
It’s a Xiaomi Smart Band 7 series. Not discoverable and activity heart rate not shared. That’s why I’m a bit confused how OMG could see and catch it at all But that’s one of my use-cases: I want to use it for presence detection, if no negative impact on battery life and privacy (no continual exposure).
Update: steps are never received. There’s also no setting in the Xiaomi app, only for discovery and bpm.
That happens automatically once I enable the HASS presence switch. Now I have the HASS presence switch activated and re-activated the adaptive scan switch. This way I only get the presence detection timer
entity and it seems I don’t need to care about the scan intervals. Will check how frequently it will be. Anyway I’d expect to have my custom set values stored and restored once I re-enable the HASS presence
switch.
Last question: what does the BT: Publish only sensors
switch do?