To use this binding for indoor positioning, it is recommended that I have multiple Bluetooth dongles, preferably in each room. This makes sense, but what I don’t understand is how these multiple dongles will communicate back to the OH server.
My OH server is running Windows so I think I need to buy some Bluegiga BLED112 dongles so I plug one of them into the USB port of my OH server, what do I do with the rest of them?
Could someone explain this to me like I’m 5 and maybe I’ll understand and (hopefully) buy the right kit to get it all working!
@vkolotov Thank you for taking the time to help me understand and for your work on what looks to be a really exciting binding.
For my situation, it looks like USB over IP is the best option, but the adaptors are quite expensive. Is it possible to use a Raspberry Pi to bridge the Bluetooth adaptor to the network and back to the OH server? Or maybe an even more low cost solution like an ESP32 with built in Bluetooth? I see some mention of this through google searches but wondered if there were any confirmed reports of this working with your binding and the setup used?
In addition to the indoor positioning, I am interested in the Xiaomi devices, Kettle, Mi Scale 2, Mi Flora, etc. I see some talk about these devices in this thread but it is difficult to know:
If each is compatible with the BlueGiga
The extent of the current support
Is there a quick reference somewhere to check these details for a given device?
Hi @orzechszek, NUT mini is OK to get nearly 100% accuracy with BlueGiga adapter even if you set the “online timeout” to 15-25s.
TinyB transport is very unstable. The online timeout should be set to around 200s in order to make it working properly, but this will introduce 200s of latency to detect when your devices go offline (out of range). This is due to a large number of middle tiers between the binding and actual adapter, e.g. Adapter -> USB -> Bluez -> DBus -> TinyB -> OH
@xrucka has implemented a new dbus transport for generic USB adapters that does not use TinyB at all and talk to adapters directly via DBus interface! Tons of kudos to him! I was dreaming to get rid of TinyB… We will try to release the dbus binding asap.
Lukáš has also contributed quite a bit into the Gatt parser library and TinyB as well.
He is also currently working on adding support for a bluetooth thermostat: here.
I just tried this for the first time, and it… worked, but I think something must have gone wrong since it didn’t seem to work reasonably. Hopefully I just did something silly and someone can steer me in the right direction. I’m just using a standard Pi 3B+ with BlueZ 5.43 etc.
Upon adding everything, it very rapidly discovered over 285 things. The older/other BT binding only finds around 20 or so if I run it, and it takes considerably longer to find most of those. After a while, the inbox cleaned itself up a bit, but remained between 25-65 items for as long as I left discovery enabled. I only know what about 5 of the devices actually are, but I don’t live in a sea of bluetooth-enabled everything so I’m not sure the hundreds of items is valid
I added my phone (Android Pixel, older model, not the 2), but it seems like the binding only reports the phone as being online as long as the phone remains in active discovery mode. Once I closed that, but left BT enabled, it went offline and never seemed to be found again. There was no option to setup pairing etc that I could find.
So I guess I am confused about how this is intended to be used. I don’t want hundreds of spam devices being processed constantly, but I can’t disable discovery if I want to use this for anything. But then I also can’t seem to use it reliably, at least for my phone, unless I keep it in permanent discovery mode, which isn’t possible (or wanted).
I’m currently playing with a couple of Bluegiga dongles connected to your binding:
216 │ Active │ 80 │ 1.2.2 │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth.transport.bluegiga
220 │ Active │ 80 │ 1.1.5 │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth
I’ve just discovered some odd behaviour at startup which seems to block other serial ports (a Zigbee dongle in my case). I’ve already asked the maintainer of the Zigbee binding:
But after a some more tests it looks like the bluetooth binding somehow catches/open other serial port even if not matching the adapter regex. I currently have symlinked the Bluegiga’s to something unique, so that some unintended match should have been avoided:
Yes, this works as it should. When I start the Zigbee binding, let it open it’s serial port and initialize the Zigbee coordinator dongle and the start the Bluetooth binding both are working and can talk to their serial ports.
What does this mean? It’s not my understanding of the port discovery. I thought that the discovery only looked at the system info to check the PIDs - it shouldn’t involve the serial port library (or so I thought). I’m not overly familiar with the discovery though, so I could be wrong.
After installing 2 new BlueGiga Adapters i get this Warning every 10 Minutes:
2018-07-11 16:36:16.369 [WARN ] [tooth.bluegiga.BlueGigaSerialHandler] - Ignoring BlueGigaPassKeyResponse response which has not been requested.
2018-07-11 16:36:26.265 [WARN ] [r.transport.bluegiga.BluegigaHandler] - Timeout has happened while sending a transaction, retry one more time: BlueGigaHelloCommand
2018-07-11 16:44:26.714 [WARN ] [er.transport.bluegiga.BluegigaDevice] - Unexpected exception occurred while handling bluegiga event: bluegiga://88:6B:0F:A2:BA:8A/3F:BF:1F:27:6D:2B : BlueGigaScanResponseEvent [rssi=-71, packetType=NON_CONNECTABLE_ADVERTISEMENT, sender=3F:BF:1F:27:6D:2B, addressType=GAP_ADDRESS_TYPE_RANDOM, bond=255, data=FF 06 00 01 09 20 02 54 E3 32 F9 DF FC EA E0 A8 FF 0E 1C 00 CE B1 E5 F9 ED 3D 71 50 51 7C] : 255
sender is a not installed device. Only seen it in Inbox.
Is there a problem or it’s okay.
Hi @chris, there is nothing special in the port discovery. The binding calls NRSerialPort.getAvailableSerialPorts() (which returns a set of available port names, e.g. a set of strings) and then filters by using a regex that is user defined (in the binding config). That’s it. The binding does not attempt to open any unmatched ports. So not sure what’s happening there.
thanks for reporting this. Those errors can be ignored. The blugiga protocol does not have any error correction so we have to look after some anomalies and try to recover from serial communication errors.
BTW, that bluegiga library we use in the binding (bluegiga transport) here is written by @chris, all kudos to him! Excellent work.
I have changed my adapters to extern bluegiga adapters. What i have seen, is that the refresh rate of the RSSI is much faster. So every 5 seconds i get a new value. The CPU rate is higher too. 1-2%.
But the value jumps. For example from, -82 to -74 without move of the device. How can i set the devices or adapter that the value is not jumping so much?
2018-07-16 18:05:01.194 [vent.ItemStateChangedEvent] - GearS3_RSSI changed from -73 to -80
2018-07-16 18:05:06.214 [vent.ItemStateChangedEvent] - GearS3_RSSI changed from -80 to -82
2018-07-16 18:05:11.231 [vent.ItemStateChangedEvent] - GearS3_RSSI changed from -82 to -74