i pick up your approach to switch on the connection control to pick up battery status und firmware version. every 30 minutes (could be reduced i think) i swicthed on connection control for 30 seconds. Bwlow is the rule
// Rule: Forced query of battery status
//
// Timer based the connection control for blutooth is enables. Because of the unknown authorisation scheme of the Mi flora devices, the connection approach
// is canceled after approx. 5 seconds, but the system will be able to get the battery as well as the firmware information
//
rule "Forced query of battery status"
when
Time cron "0 */30 * ? * *" //every 30 Minutes
then
val String ruleIdentifier = "Forced query of battery status"
val timeoutSeconds = 30
if (gPlantConnectionCtl.state === OFF) {
gPlantConnectionCtl.sendCommand(ON)
logInfo(ruleIdentifier, "Forced read initiated - Will be stopped in {} Seconds!", timeoutSeconds)
ForcedReadTimer?.cancel()
ForcedReadTimer = createTimer(now.plusSeconds(timeoutSeconds)) [ |
ForcedReadTimer = null
gPlantConnectionCtl.sendCommand(OFF)
logInfo(ruleIdentifier, "Forced read stopped!")
]
}
end
i just bought a new deleonghi coffemachine (Primadonna Class) and it has bluetooth and there is an app to control the machine. My question is now how to start to automate it with the bluetooth binding.
It would be great if i was able to switch it from standby to on while staying in my bed
Thomas
Hi @vkolotov,
I’ve updated my test setup to 2.4-M5 and:
openhab> bundle:list | grep blue
256 x Active x 80 x 1.2.3 x org.sputnikdev:org.eclipse.smarthome.binding.bluetooth.transport.bluegiga
257 x Active x 80 x 1.1.6 x org.sputnikdev:org.eclipse.smarthome.binding.bluetooth
Meanwhile I’ve managed getting three Bluegiga adapters active at the same time in addition to another serial adapter for Zigbee. (just in case you’ve seen my withdrawn post from yesterday: There have been a flaw in the JAVA_EXTRA_OPTS preventing the third Bluegiga been discovered. This is now fixed ;-))
But one of the Bluegiga’s get’s disconnected after an hour of run time:
2018-11-02 07:54:19.443 [vent.ItemStateChangedEvent] - bluetooth_adapter_886B0FA2A91E_discovering changed from ON to OFF
==> /var/log/openhab2/openhab.log <==
2018-11-02 07:54:19.445 [WARN ] [impl.AbstractBluetoothObjectGovernor] - Error occurred while updating governor: /88:6B:0F:A2:A9:1E/C4:7C:8D:66:20:1F / 23d41c51 : Error occurred while interacting (isPowered) with native object: /88:6B:0F:A2:A9:1E : BlueGiga handler is dead.
The adapter is still connected and the serial port exists:
# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 0451:16a8 Texas Instruments, Inc.
Bus 001 Device 006: ID 2458:0001
Bus 001 Device 005: ID 2458:0001
Bus 001 Device 004: ID 2458:0001
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
# ls /dev/blue*
/dev/bluegigattyACM0 /dev/bluegigattyACM1 /dev/bluegigattyACM2
How to investigate further what’s causing the Bluegiga getting lost?
UPDATE: It’s not always the same Bluegiga dongle which is going offline. It lasts between 30 and 60 minutes to “loose” one of the dongles. All the dongles are currently plugged into to same USB hub without any cables/extentions/etc…
Hello!
After a while of testing it seems that Ble devices are working properly, but generic bluetooth devices are going off and online every few seconds.
What could be the reason?
Thanks
Hi Vlad.
I have updated openhab to milestone M5. After this i have problems by changing the update intervall of bluetooth items. If i change from 10 to 15 seconds, all adapters and devices goes to uninitialised.
A restart gives the fix.
But the bigger problem is the cpu load, which goes up from 2% to 6-8%. When i deinstall all bindings, not the bluetooth binding, nothing changes. If i deinstall the bluetooth binding, the cpu load goes directly down.
Thanks for help and greetings,
Markus
Hi @curlyel, very interesting, how many bluegiga dongles you have? What’s your set up? I see
“VMWare” thingy in the logs, do you run it in a virtualisation container?
Hi @haesslo, it should work now. Sorry I have not updated documentation for this feature as I wanted to develop/test it more. However you can try it now and help me with testing this feature.
Give a unique name in your iphone (device or bluetooth properties), e.g. something like “haesslo iphone 123”.
Go to “Advertiser” tab, tap on “+” button to add a new service (advertising packet). Set a name to it (does not matter what). Add an advertising record “Complete Local Name”. Add a scan response data “Complete Local Name”, tick “Scannable” checkbox. Like that:
Then enable that advertiser rule (a switch) in the app.
Wait until you see your phone in OH inbox, then add this device from the inbox.
In your OH inbox, do you should see your iphone recognised as “beacon device”? For example:
To everyone here, if you are interested in presence detection using your phone, please jump into testing of this feature as I posted above.
Please note, as you may notice, the binding will use your device name instead of MAC address, this means that it is not secure by any means ;).
There are some thoughts/plans to use an advertised service value instead of device name. This would make it a bit harder to spoof, however still won’t be secure enough to use it as something that controls your entrance door. However, we could come up with an app that would encode and change the value dynamically and the bind would read it and check/verify, but this is a different story that requires app development and some changes in the binding.
Well, currently I have five BLED112, but just three of them are currently connected for testing. For now, they are connected to the same (powered) USB hub. For the later deployment I hope for general Serial-over-IP availability to have all my serial stuff (bluetooth, zigbee, zwave, …) distributed via network:
UPDATE: I’ve just read again through the linked thread. Seems to be available yet in the latest snapshots, but bindings have to be adopted to deal with possible connection drops/reconnects. Are you aware of that already for the Bluegiga-transport?
Yes. It’s a virtual machine on ESXi 6.5 which get’s the USB ports passed through.
Operating system is Debian 9 with manual openHABian script-install (2.4-M5 as said above…)
I tried your App on my Android (A moto G5 running Android7) and it seems to be missing the “scannable” option.
I had a bit hard times to idntify my phone as quite some devices around here usually.
But if I change the name it shortly shows up as beacon even under its correct name, but has problem connecting as you can see here:
Hi @curlyel, this sounds interesting. The binding should recover connection drops, that was the main idea of this binding to recover from disasters. Looking forward to seeing some test results in using that new serial-over-ip binding, that would be very helpful.
Hey @haesslo, this might indicate that you’ve got some symbols that are not allowed by binding (yet). Could you please try to use something simple, e.g. “Moto G 5 c” (without parentheses)?
Hey @curlyel, it is quite difficult to debug/troubleshoot your issues with stolen serial ports I’m just thinking would that be sufficient for your case if I added a new config that effectively stops discovery process for bluegiga adapters? You will be able to disable adapter discovery once you have added them.
Already jumping at the next features…Estimated distance seems to work somehow, is it normal to your experience, that this has quite a latency (I moved it from right next to my Raspberry a couple of meters away and it took around 4-5 minutes to slowly step up to the final distance) ?
Thanks for quick response. … I will see how it goes in “real life” and keep you posted.
Due to your question I decided to quickly setup some test system on bare metal instead of a VM just to check if VMWare/ESXi causing some oddity. Operating system is different architecture (Armbian Stretch instead of stock x64 Debian because of the ARM board I’ve used).
Java runtime, OpenHAB and Bluetooth binding are the same like in the VM.
Have to admit: It works now for quite some hours (over night) without loosing any of the Bluegiga’s
Maybe the VMWare USB passtrough introduced some issues here?
The tiny ARM board is doing well so far but is considerably burdened already while just having the Bluetooth and the Zigbee binding active. It runs with 10 to 20 percent CPU (it’s an ARM A7 quad core, 1.5 GHz, 2GB ram).
Currently discovered (and permanently updated) are:
3 Bluegiga dongles
2 Xiaomi FlowerCare
2 Xiaomi thermometer
1 beacon
1 Zigbee dongle
2 zigbee sensors
This will need some time to test this too. Does the binding accept
