I spent a few days playing with HA, but I need a more reliable solution, so I decided to switch to openHAB.
I always start with a simple test to evaluate a system—integrating a simple Bluetooth temperature sensor.
My environment: Ubuntu 24.04.2 LTS, openHAB version: 4.3.2 as a docker installation
So far, I have:
Added a BlueZ 5.66 adapter
Successfully detected and added my device as a Thing in both Generic and Beacon modes
Viewed a full list of parameters (matching what I see in the nRFConnect application)
Everything looks very promising.
However, I can’t figure out how to pass ManufacturerData to the Items or Channel or something else.
BlueZ logs show that the data has arrived at the adapter:
[DEBUG] [.bluez.internal.BlueZBluetoothDevice] - Received manufacturer data for XX:XX:XX:XX:XX:XX: 00 00 00 XX XX XX XX XX XX 2D 0C 2D 01 33 04 7D EC 01 00
[DEBUG] [ternal.BlueZPropertiesChangedHandler] - PropertiesPath: /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
[DEBUG] [ternal.BlueZPropertiesChangedHandler] - PropertiesChanged: {RSSI => [-58], ManufacturerData => [{16 => [[B@4a04389e]}]}
But I can’t figure out how to pass it further.
Any ideas or useful links? I’ve already googled a lot…
As caution. So I don’t know about your device or binding and only a limited amount of OH. But manufacturer data is generally considered a property. Something not changed or subject to change, so it won’t be a channel and won’t be able to link to an item. If using the discovery it should be on the UI thing page under the Thing properties drop-down. Is that something you need to change?
Again, maybe someone using the binding can help on the Mfg data. Does it ever change from [{16 => [[B@4a04389e]}]}? (I’m thinking that is a reference to a java storage location for a byte array, but not the byte array itself). Possibly the mfg data is simply 2D 0C 2D 01 33 04 7D EC 01 00? or 45-12-45-01-51-04-125-236-01-00? Also sometimes the Byte array needs to be converted to StandardCharsets.UTF_8, although that doesn’t look like the case here. Sorry couldn’t help more
The RSSI makes sense as a channel, since that would be different with every message
I’m not sure the BT binding works the way you think it does. But first let me say that Bluetooth is probably the hardest technology to get working well so choosing that as your first experiment is probably not the best choice.
OH provides generic support for BT Beacons, but it only supports that one RSSI Channel. The binding does not make anything else available to OH. If you don’t see a Channel listed in the docs it’s not supported.
If your device is one of the supported devices (see the list at the top of Bluetooth - Bindings | openHAB) you can additionally install an extension which provides support for that. For example, if it’s a Govee H5071, you’d install the Govee binding. Then the device will be discovered and that Thing will have Channels for things like temperature, battery level, humidity, etc. If it’s built from some other vendor, you may be out of luck unless or until a binding is built for that vendor.
In those cases though often there is an X2mqtt service posted to GitHub that converts the BT to MQTT.
OH does not just give you the raw BT data and let you much around with it on your own. All that stuff is implemented by a binding and exposed to you as an end user through Things and Channels.
The core architecture of OH is built on layers of abstraction. Bindings connect to devices/APIs and represent each individual devices as Thing (there is a one-to-one relationship between a Thing and a device, if you have five identical thermometers you will have five Things in OH). Each sensor and actuator is represented as a Channel on those Things. Channels get linked to Items. Everything else in OH operates with Items.
That one-to-one relationship is why others on this thread are pushing back and saying it doesn’t make sense because the manufacturer is a property that will never change. The MAC address of a BT beacon is never going to change, and each beacon will have its own Thing to represent it. Knowing which manufacturer string each is publishing adds no additional information, the device is already uniquely identified.
To get the manufacturer information from a BT device, that needs to be implemented in the add-on and exposed as a Channel. As an end user of OH that information is not available to you. And in general, that information is not useful for home automation. Whether you are getting the temperature from a Govee sensor or an AirThings sensor or some sensor using some other technology entirely it doesn’t matter who built the device. What matters is the temperature readings and where it’s physically located (though that part is encoded in the Items).
I know that integrating a Bluetooth sensor is always tricky, but that’s the point—understanding how the system behaves in unusual situations. What would be the benefit of integrating well-known and supported devices? From the system’s point of view, of course.
I was experimenting with ManufacturerData (as I always do when exploring a new system) because it’s a simple example of non-standard communication. Many devices transmit sensor data within custom fields, as you know.
The most important part of your explanation for me was the clear breakdown of the abstraction layers (Bindings → Things → Channels → Items) and the idea that “everything else in openHAB operates with Items.” That really helped me see the bigger picture.
So, for the custom device I’d like to use in openHAB, I need to implement an add-on and expose the necessary data as a Channel. I wish I could retrieve data from the existing BlueZ binding (since I can see it in the logs), but I don’t seem to have a way to access it from the higher layers.
Am I correct?
Just in case—would it be possible to define a Channel and add it to a Thing using custom scripting within openHAB? Something like this:
That is not quite true, as more than half of the 120 devices we decode through their BLE advertising data are decoded through the information contained in their changing manufacturerdata including all the Govees, and some BLE advertising servicedata with its UUID.
It does however with random MAC address devices like iPhones, newer Android phones, iPads, Apple Watches, AirPods etc. so a MAC address resolving for such devices will also allow to to their manufacturerdata uniquely identified.
@xmlIgor you can also try our OpenMQTTGateway on an ESP32 or Theengs Gateway on your Ubuntu machine. Both automatically decode the above linked devices from their BLE advertising data, but also allow for broadcasting the raw manufacturerdata and/or servicedata ( with pubadvdata / PUBLISH_ALL) via MQTT.
Then you can just create an MQTT Thing in openHAB with
Seems to me that understanding how it works in normal situations would be an important first step. OH is pretty complicated and in my experience, those who just jump in and flail about often drown.
To get them to work together. That’s the raison d’être for OH. To, for example, get my Zwave wall switch to come on when my Zigbee motion sensor detects motion, and announce a visitor on the smart speakers and send an email with a picture of the person at the door.
Fiddling with details of protocols and technologies is what the binding developers do so users of OH don’t have to.
If messing with that stuff is what you are after, either you are looking to be a binding developer or OH isn’t the best platform for your needs and desires.
Yes, for the most part. You should be able to extract the information from the BT binding from another binding. That’s how the AirThings et al bindings work I think. The BT binding gets the raw packet and passes it to the AirThings binding to parse and extract the data and make it available as Things with Channels.
Only for specif low level bindings like Modbus, MQTT, KNX, HTTP, etc where the Channels are manually created. The vast majority of bindings provide the Channels and those are the Channels you get.
But we as end users don’t care about that. That’s a detail of the binding and how the binding(s) work. There’s no reason to publish that information as a Channel on the Thing because there’s nothing we can do with it and it doesn’t add any useful information.
I want to emphasize, I am strictly talking from an OH end user’s perspective. Not the BT binding nor the Theengs Gateway or anything like that. I know that the manufacture’s ID is vital for the binding. I very well know that phones change their BT MAC address with a lot of frequency. And I know you can get access to everything you may want outside of OH.
I’m not sure what any BT binding would do with those devices. If the specific instance of a device cannot be kept all you can really say is that some iPhone is within range of the BT antenna. These are useless as a beacon.
As it currently stand with the Bluetooth binding I fully agree, why and how the Govees are integrated there I then do not know - hopefully also decoded by their BLE advertising data and not by connection service/chararcteristic retrieval, just for the sake of the battery life of the Govees.
But again, maybe it is about time that the openHAB Bluetooth binding also does evolve a bit and does that BLE advertising manufacturewrdata and servicedata into account to decode well over one hundred additional devices just like the Govves.
What really is the difference to BLE advertising manufacturerdata and servbicedata to any other raw data other bindings are swcosing and displaying?
And possibly also evolve to be able to resolve any such randomly changing MAC address devices, like we do with Theengs Gateway.
Yes, we do that totally controller agnostic, and some controllers have created add-ons and Plug-ins from our implementation, but other controllers - no names here - also do that natively, so maybe for a modern Bluetooth binding in openHAB these functionalities would bring it up to date to a modern standard.
Just a thought, as with the above comments, especially about BLE advertising manufacturerdata, it really appears the Bluetooth in general is treated as very lonely orphan in openHAB.
Interesting discussion. I get now that BT MFG data is not just the device/thing ID, but the device/thing ID PLUS byte-encoded dynamic data (like temperature). Agree that the OH model is that bytes are decoded in the bindings by java developers and presented to the OH user in channels to monitor in something like degrees C.
With the bindings I have worked with there has been decoding documentation (like the Silabs Zwave or Zigbee specifications), is that available here? If the bytes after the MAC address could be extracted, is there a decode key to tell what they mean? Do they vary by maker/protocol/etc? If there are many variations, BT is not going to get much traction (IMO).
Take the Theengs Decoder library I have been contributing a lot to in the last few years, there you will find all the decodings for quite a few devices
Also being used by other projects as seen at the bottom of the repo page.
Or just include the whole Theengs Decoder library into the binding and get the benefit of constant library updates and expansions - that is if you can wrap it into the Java binding
Or just wrap the whole Theengs Gateway into a building and also get the added benefit of random MAC address device resolving, encrypted decoding and remote OMG proxy antennas …
Or … copy all the decodings manually into the Bluetooth binding and maintain any additions and updates yourself.
Anything of the above - to get openHAB Bluetooth a bit more up to date.
Modern IT systems are moving toward a “click-and-run” approach. That’s great—it opens up opportunities for many people who couldn’t have imagined them just a short time ago. I appreciate how we hide complexity from the end-user. Sometimes, though, this complexity reappears in unexpected ways—but that’s another story.
However, when we talk about automation systems—whether for homes, small businesses, or large industries—why do developers hide the data that could help us bring our ideas to life?
The architecture of openHAB is well-designed, and I really like it. But if a good architecture is locked behind a safety cap, it risks losing its appeal.
And while we’re at it also allow to Read and Write from and to any Bluetooth device’s service/characteristic as I’m now doing with OpenMQTTGateway to control my Bluetooth lights and check their battery status once a day.
But again, this would not fit into the end user model, but return and require specific raw data, as with the SwitchBot devices for example.
To be honest, that why I’ve migrated from specific bindings to MQTT for as much as possible quite some time ago. Apart from being controller agnostic it is also always a pretty sure thing that at least the MQTT implementation is up to date, while I’ve seen bindings come and go or be abandoned for a while before being picke up again, possibly with unforeseen changes, or left unmainained.
If you want to work at such a low level, Theengs is a great platform for you or one of the several platforms that are based on Theengs.
Everything is available to you there. And you can still use OH to do those things it does best, which is focus on integrating everything together and building an automation with it all. Very few run only OH and many run third party stuff even for things that OH has pretty good support like Zigbee and Zwave.
The only thing missing is a volunteer to implement it.
You clearly know how to do amazing things with BT and you think the BT binding is insufficient. So, are you gonna step up? Or just point out that an all volunteer project doesn’t have enough volunteers for the stuff you care about?
I know very well, that is what initially brought me to Theengs, finding that the Bluetooth binding could not do anything I wanted to do with Bluetooth - admittedly back in the OH 1 and OH 2 days.
Now I am a bit confused with the added Govee, Ruuvi etc. additions to the binding. And by a Quick look at it the Govees are being polled by connection!?! The worst kind of retrieval for the devices’ battery6 life, while their most important properties could be gotten by just looking at the BLE advertising data. Admittedly not the alarm threshold settings, but aren’t such threshold and alarms not better implemented in openHAB anyway? This active connection retrieval is likely also the limit to getting the Govee’s data only every 5 minutes as not to deplete the batteries too quickly.
I just found the selective addition of these a bit confusing, while a lot of other manufacturer’s devices are being left to implement with Theengs or other similar solutions.
While I have submitted many documentation changes to openHAB in the past and actively logged issue, my only real code submission was a teeny little amendment to the great, then still separate, EspMilightHub Binding. Unfortunately the whole Maven setup was a bit dampening back then, and Java is just unfortunately really not my cup of tea
I do and have stepped up when I find an all volunteer open source project I believe in, as my Theengs submissions might show. With openHAB I have stepped down from all my above mentioned involvement a while back, as I couldn’t, and unfortunately still don’t, see any clear direction it was/is going, and the back then haphazardly handling of logged issues. You might also remember, I am still running openHAB 2 as my production system here, all perfectly fine with the added outside solutions I found and got myself involved in and relying mostly on MQTT. Still evaluating 4.3.2 but more likely postponing any further evaluation to the upcoming OH 5 - so in any case not up to date for any possible submissions.
And if that is me being told to better not comment on any areas which I think could be improved, message received. But then silly comments about BLE manufacturerdata being irrelevant should also not be posted to trigger me
including all the Govees, and some BLE advertising servicedata with its UUID.
