solved by Network Settings
org.eclipse.smarthome.network
Primary Address
“my adress”
thanks all working cool for now the two shity things from china are working pretty cool 
for windows users
https://www.aliexpress.com/item/Bluegiga-BLED112-Bluetooth-Smart-Dongle-Bluetooth-Smart-ready-for-Linux-Android-and-Windows-devices/32808005569.html?spm=a2g0s.9042311.0.0.27424c4dIzODIh
this two came pretty quick and working on my OH setup thanks vlad
looking fowwerd to see what i can do with this
Great @Gad_Ofir, please report if the tag you have works as expected (e.g. does not turn off after awhile). There are two types of these tags that look the same but have different internals. One of them is useless.
mmm acttuly i turned it off… i will try later, as my setup is up ,and my downstairs “testing OH” setup is giving me this error when i install IOT
22:49:24.265 [WARN ] [arketplace.internal.MarketplaceProxy] - Failed downloading Marketplace entries: : Received fatal alert: handshake_failure
i will reslove it and resume testing i promise
1 Like
Any takers on this?
Hi,
I am trying to connect a mi flora sensor via this bluetooth binding. The sensor is being discovered, but only the RSSI value appears.
This is probably due to an old firmware. https://github.com/sputnikdev/eclipse-smarthome-bluetooth-binding/blob/master/xiaomi.md#mi-flora-plant-sensor
However in the flower care app there seems to be no newer firmware available.
Am I looking at the wrong place? Has anybody had the same problem?
The problem is that even after hours really only the RSSI Channel is being discovered. Neither protocol version nor productID are displayed.
@vkolotov Hi Vlad, where do you find ProductID and Protocol version with the Miflora sensors? I have only the satndard fpur ones.
On The other hand it is really annoying that the battery status is not published. Maybe you could think about the option to implement the brute force solution.
Thomas
I’m currently trying to add my Paulmann bluetooth lamps into openhab. Actually it is working fine, your bluetooth module is working perfectly. But unfortunately the lamps or better the protocol is a bit special. I’m not an expert in bluetooth things, but well, to make a long story short. First of all before being able to control the lamps I have to provide a password. After that I can control them, currently I do it via pygatt in a simple python script. It looks like this:
#!/usr/bin/python3
import pygatt
import sys
UUID_PWD = "0000ffba-0000-1000-8000-00805f9b34fb"
UUID_ONOFF = "0000ffb7-0000-1000-8000-00805f9b34fb"
UUID_DIMM = "0000ffb8-0000-1000-8000-00805f9b34fb"
DEVICES = {}
DEVICES["WOHNZIMMER_FENSTER"] = "F4:5E:AB:B8:AB:61"
DEVICES["WOHNZIMMER_HINTEN"] = "F4:5E:AB:B8:AD:CE"
DEVICES["WOHNZIMMER_MITTE"] = "F4:5E:AB:B8:9D:3E"
DEVICES["WOHNZIMMER_VORN"] = "F4:5E:AB:B8:9E:DF"
DEVICES["WOHNZIMMER_ESSTISCH"] = "F4:5E:AB:B8:AB:64"
DEVICES["WOHNZIMMER_WAND"] = "F4:5E:AB:B8:9F:E6"
DEVICES["EINGANG"] = "F4:5E:AB:B8:A5:40"
devicename = sys.argv[1]
command = sys.argv[2]
param = sys.argv[3]
def sendPassword (device):
device.char_write (UUID_PWD, bytearray([0x30, 0x30, 0x30, 0x30]))
def sendOnOff (device, on):
print (device.char_read(UUID_ONOFF))
if on == "on":
device.char_write (UUID_ONOFF, bytearray([0x01]))
else:
device.char_write (UUID_ONOFF, bytearray([0x00]))
def sendDimm (device, value):
print (device.char_read(UUID_DIMM))
device.char_write (UUID_DIMM, bytearray([int(value)]))
try:
adapter = pygatt.backends.GATTToolBackend()
adapter.start()
i = 0
connected = False
while i < 5:
try:
device = adapter.connect(DEVICES[devicename])
connected = True
break
except:
pass
i += 1
if connected == False:
print ("unable to connect to "+devicename)
exit(1)
sendPassword(device)
if command == "ONOFF":
sendOnOff(device, param)
if command == "DIMM":
sendDimm(device, param)
finally:
adapter.stop()
Any chance to have such device directly supported by your bluetooth module?
Hi @Andre_Lerche, it looks that it is quite easy to add support for your device.
Are you sure that your python script works for all of your devices. I believe there is a bug in it. It seems to me the only last device in the list gets updated in that script because the logic to control BT device is out of your while loop (not properly indented).
Anyway, we could add GATT specs for you easily. However, there is some work going at the moment that is related to connection management (disconnect after work is done, so connection is released and the released connection can be used for next device). Having said that, you might not be able to control all of your bulbs at the moment, this really depends on how many connections (or home many adapters you have) your adapter can keep open simultaneously.
I’ve created a github ticket for you, please jump on it there: Add support for Paulmann smart lights · Issue #66 · sputnikdev/eclipse-smarthome-bluetooth-binding · GitHub
Hi @Dibbler42, ProductID and Protocol are “system” channels (hence hidden from users on purpose), you will need to set this setting to see them:
You may check the battery status if you enable “connection control” for while, I do not recommend to leave it aways ON as this will generate a lot of disconnections as Xiaomi authentication protocol is not implemented, so your device will drop connections after 5 secs, but the binding should be able to fetch battery status withing this window.
1 Like
Hi @Joeh, looks like you are using wrong binding By the looks of RSSI channel, it is the official binding. Please install 3rd party ones from ESH marketplace as per this guide:
Ok Thanks for the Info. I will think about automatically swicth on the connection control get battery info and then switch ist off again
Thanks for the hint @vkolotov! As embarrassing as it is, you were right and I clicked on the wrong binding (also named Bluetooth Binding).
Also, after having the sensor connect to the official mi flower app for a few days, I was finally offerd to update the firmware by now.
Now openHAB recives the data shown below, but sadly still no temperature, moisture etc.
The Sensor is now connected since approx. 8h and positioned right next to the reciver, so as far as I understand the data should be automatically be received as well, correct? Possibly it is the firmware. Can anybody confirm that 3.1.9 is working with the binding?
@Joeh, you should disable connection control. Please refer this doc: https://github.com/sputnikdev/eclipse-smarthome-bluetooth-binding/blob/master/xiaomi.md#important-note-for-all-xiaomi-devices
Hi Vlad,
do you are aware of any bluetooth blood oximeters which can be connected to the binding?
Hi @curlyel, sorry mate, I’m not aware of any, never tested any. There is an official GATT specification (https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.pulse_oximeter.xml) for Oximeters, so if a device follows that spec, there is a chance that it works with the binding.
I’ve tried a heart rate sensor, the one from Wahoo works fine.
Hi @vkolotov, sorry for my late response, I have been busy irl ™.
I’ve tested with all 3 device settings, but I don’t see any difference. Adapter settings are as in your screenshot.
Also, I have different options available then in your screenshot.
I have 2 BT dongles, 1 in my OH Rpi B3+ (first floor) and 1 in my desktop (livingroom), forwarded with usbip. There is maybe 5m and a concrete floor between the dongle’s.
EDIT: It seems I was running version 1.1.5 from your binding. I would expect OH to automatically update it for me? For now I did it manually from within Karaf:
bundle:update 248 Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog
Same with TinyB, it was also 1 version behind.
I’ll test this version and see how indoor positioning is working.
1 Like