Hi @Baltazar72, thanks for that. Interesting… Are your miflora sensors roughly located within the same distance from your two adapters?
I can see that your RSSI jumps quite significantly. e.g. ±15. We could possibly come up with another option for the Kalman filter specially for stationary devices, e.g. very very slow with some significant latency.
If you think about that more, if you have two adapters and a device and the distance is more or less equal between adapters and the device, then what else can you do? As I said before, bluetooth radio signal is quite unstable by its nature. First thing that comes to my mind… in order to fix this, you would probably need to get another adapter and put it in your kitchen OR have an ability to define location for each your device so that it does not get updated by the binding. It is really and “edge” case…
I see your point in having “approx equal” rssi values from 2 adapters, that represents a challenge.
I also see that the rssi values “drift” , making the challenge even harder.
Also as you state it may be an edge case, but I really see some benefits here… eg I noticed that my UE MegaBoom Bluetooth speaker is quite “chatty”, and it would be great to have it “located” by the binding… hall / livingroom / office, or second floor … The speaker also show the same “jumping”, but not nearly quite as frequently
I actually have 5 miflora devices, (and more coming in from ebay eventually)
I have 3 adapters, and enclosing eventlog in case if it is of any interest (cat /opt/openhab2/userdata/logs/events.log | grep “Flower[12345]_[rLu]\|MegaBoom_[Lru]”) here : https://drive.google.com/open?id=1JG8tD6DSXQNgck7IRg6p3i8mar90aFo1
Flower1 is really close to and have line of sight to adapter “Stue”
Flower2 is “closer” to adapter “kott”, but a concrete wall is inbetween…
Flower3 is really close to adapter “2.etg”
Flower4 is in same room and has line of sight to adapter “Stue”
Flower5 is outside and only reachable to adapter “2.etg”
MegaBoom has been really close to “2.etg”
I really would not know how to achieve it, but the “positioning” could benefit from some “virtual” positions that could be calculated form multiple adapters rssi values / ranges … then I could say that 50/50 more or less equal rssi’s from kott and Stue would mean Kitchen, and 60/40 could mean hall …
I guess this also could be achieved by a openhab rule of some sort (I’ll have to ponder upon that)
I’m also thinking maybe there is a problem with usbip (currently all 3 adapters is connected via usbip), and me loosing contact with adapters (just a tought)…
Is there a way to see which adapters that picks up the signal in the eventlogs ?
I would like to thank you again for this fantastic binding … I’m loving it more and more every day !
Torstein
It seems to me, that once your Bluetooth binding is activated, other bindings which are using serial usb adapters are suffering from it. I’ve observed it in combination with the Zigbee binding (which you are already aware of) and the ZWave binding.
For example ZWave controller thing
If no Bluetooth binding is installed, the ZWave controller thing let me choose out of the full list of existing serial ports:
When I now check for the available serial ports for the other bindings, the list is limited to just “/dev/bluegigattyACM1”
For example again the Zigbee:
This prevents the other bindings from working (at least if not started and initialized before the Bluetooth binding). It seems that the Bluetooth binding is somehow “stealing” the serial ports from the other bindings.
Chris has suggested to stop the USB serial discovery bundles on Linux ESH/openHAB which seemed to help in a couple of attempts (restart openhab/reboot system). But after some tries, the issue re-occured…
You’ve already answered, that you are not touching any “foreign” port by intention. Though: May I ask you again looking into it?
Hi @curlyel, thank you for providing your comprehensive report, I’ve created a ticket for you. It is on my list now. It is definitely not right and needs to be fixed.
If you enable TRACE level for the bluetooth manager, then you will see these lines:
Updating RSSI: <bluetoth url> : <rssi value>
where bluetooth url is: /<adapter mac>/<device mac>
Unfortunately that issue is not very easy to resolve. I suggest we tackle this in the following way:
Add ability for user to set location for a device, e.g. prevent the binding to update device location. So that users can assign locations for stationary devices. This probably will resolve 90% of the issue.
Hi Vlad,
trying to send commands via a binary channel but the commands in never sent, it just reads never writes. Am i missing something? Should it be possible to send/write commands to a binary channel?
Do i need to create my own custom definitions for it to work?
thanks to Vlad for the bindings. It’s working great with a cheap iTag I have.
I’ve just bought a FlowerCare sensor, and have updated via the app to the most recent firmware. I’ve then disconnected from the app.
It’s then detected by OH and connects OK, but only gives just-one of the actual plant sensors. If I delete the thing and then auto-detect it again it will still only give one of the plant channels although it might be a different one.
Does anyone have any ideas please?
EDIT: the channels have now appeared, around 20 hours since I last checked and around 30 hours from first installing. More patience required.
Hi to Everyone,
A couple of weeks ago I’ve started to use Vlad’s bluetooth binding to detect my presence with the help of a Gigaset G-Tag BLE device. From the Openhab perspective everything worked fine in my setup which is made out of three Raspberry Pi Zero W which I’ve positioned around my house. Every ZeroW is running Openhabian with the bluetooth binding and is scanning for the G-Tag.
What I noticed after two days of running this setup… my 2.4GHz Wifi network was suddenly useless because of indifferences. So I did a couple of tests with IPerf and a laptop and I came to realize that as soon as I start to run the binding to scan for my G-Tag it breaks my 2.4GHz Wifi. I mean completly. Even Zigbee (which also works in the 2.4GHz zone) devices like Hue bulbs and Xiaomi devices are unresponsive and a lot of status updates get lost.
Now my question:
Has anybody seen the same issue when using the combination of Pi ZeroWs + Vlad’s Bluetooth Binding + 2.4GHz networks (Wifi/Zigbee)?
I tried to switch the Wifi and Zigbee channels but since I live downtown in the city with tons of other 2.4GHz networks around me it did not help to fix the behaviour.
Hi @Lemmy, this is the very first time who reports interference with wi-fi network. There was an issue with serial port detection for ZigBee, are you sure it is not the case (pls read several posts above)? I’m running 4-5 adapters simultaneously (although not on the rpi zero) and do not feel that it somehow makes wi-fi link worse.
i have similar problems with the RPi3, but only if I use the on board Wifi and BLE device.
With an ethernet connection and the on board BLE device everything works fine.
I think it could be possible this is a problem on RPi side ???
But I have no idea how to find the cause of the problem.
Primary use case here is presence detection I believe? I usually keep my BT off to save battery. BT is dying tech, they are somewhere between ultra low power mesh capable NRF/Zwave and FAT Wifi. BT will die soon.
I wouldn’t like keeping it on just for presence detection.
The wifi HW on smartphones is anyway on and it goes to low power when no network in range. The IFTT app can trigger a command event on OH item when you enter home wifi range.
Hi @stfn82, could you please make sure you can use ‘bluetoothctl’ utility (see your adapter there) from command line? This might be something to do with user permissions in OS.
Hi @curlyel, I’ll try to squeeze this into the current release which I plan to roll out this week. I can’t be 100% sure as I even have not started to look into it yet. Too busy at the moment, sorry.
