hi @druciak, Bluez should not affect your “extension folder”. Could you please share logs? BTW, could you please try your python script first, to make sure that Bluez is working at all.
My scirpt is working. The files are in right place. Logs attached.
bt2.xml (14.1 KB)
Hi @druciak, looks like it is not attempting to connect to your device. Can you please check if you have enabled “connection control” on the thing?
Weird, I just entered to bluetoothctl app to check if I am able to connect to the station and the binding started working.
However no progress comparing to 5.43. The thing has new channels, for the basic ones like RSSI, Manufacturer, etc it shows some data, but not for these additional ones - temperature, humidity, etc
Hey guys, I’m working on adding support for Xiaomi devices (miflora, temp and humid etc). By the look of the android app guts, it turns out that they use their own proprietary authentication mechanism. It is a simple three step process, mostly can be easily reproduced. However, on the step 3 they generate a security token (the way how it is done is clear) and then encrypt it with a native library (JNI, calling a function on token). I tried to make use of that shared library on my test machine (linux x86_64), it looks like android libs are not compatible with any other linux distros.
Is there anyone who can decode a c++ lib? I’ve uploaded that lib here: https://onlinedisassembler.com/odaweb/2HGV9u0L/0. There are three methods we need to know what they do:
I’m not a big expert in ASM, but it does not look very complex… anyone is keen to take up a challenge?
Is this authorization introduced in some recent firmware? According to various projects there is no such thing.
Also nobody reported this “feature” here: Xiaomi Mi Flora Plant Sensor MQTT Client/Daemon
Did you get it running finally? I’m having troubles with my iTag, too. Detection is OK. I can physically switch ON/OFF this iTag by pressing a button. Then BT binding always detects two things:
A “generic bluetooth device” and a “BLE enabled device”.
The “generic bluetooth device” stays online up to 5 minutes. Then it generates a new MAC-Address and a new thing is in inbox.
The “BLE enabled device” stays ONLINE only 30-40 seconds, then it goes OFFLINE and stays there forever. Do I have to CONNECT this thing immediately after detection? But I don’t have “Simple Item Linking” enabled. I don’t want this feature, 'cause having troubles with Alexa (item tagging!)… And in PaperUI --> Control --> Bluetooth Devices took to long to generate the view!
What to do?
Looks like it is. I have updated firmware via their app. It looks like it has introduced that new auth mechanism… Anyway, I’ll create a binding for miflora, it won’t keep connection, it will periodically connect and fetch data from it.
hi @Celaeno1, I’ve got two different iTag devices with me now. I’ll be testing it now. From what your said I can make a guess that your iTag changes its mac address (like iphones, etc). It might also generate a new mac address when you switch it on and off. I’ve got those two tags running for some time now, and they are still online. I’ll keep you posted.
I have this one:
Hi @Celaeno1, please also make sure you have enabled the “connection control” channel like that:
Looks like there is a confusion around that. If this channel is enabled, only then the binding connects to device. This might need some thoughts around usability… Maybe for the “ble” type devices this should be enabled by default. But the thing is that you don’t want to enable connection for all your devices…
BTW, this tag has got a button, and I can see a channel gets updated when I press it (0000ffe1-0000-1000-8000-00805f9b34fb). This is very handy, I’ll add support for that button soon, so we will be able to control something by pressing it.
One concern about the binding and controller thing: why does this thing type has two channels “Discovering” and “Discovering control”.
Usually things have just one channel for such purpose.
@druciak, well that’s the thing. If you enable “discovering” this does not mean that your device will switch in the discovering mode. That’s why there are two channels for a “single” thing. One of them shows a real state, another one controls this state. This is mainly due to mulitenancy of bluetooth stuff, e.g. there might be multiple clients for bluetooth adapters/devices.
Similar to this ^, the “connection control” and “connected” channels work the same way. “Connection control” makes the binding to keep connection (or likewise keep device disconnected) and its counterpart “connected” channel shows real state of a device connection.
Switches can show real state and still allow to change the state to the opposite one. But maybe I missed something.
A switch has only 2 sates: on and off. “Connection” (or discovery) thing has at least 4 states:
- real state (on/off) that reflect if a device currently connected/disconnected
- connection preference (on/off), e.g if you want to connect to device.
Like I said before, this probably needs some tweaks in terms of usability, any suggestions are welcome.
There are no 4 states, just 2, in my opinion. When controller is discovering, it does not make sense to switch its state to ON, since it is already in that state. The only reasonable thing to do is disable discovering, so put the switch to OFF state. In that state the only reasonable thing is to turn discovering ON.
This is true unless “Discovering control” just enables/disables ability while discovering changes somehow automatically. So when I switch “Discovering control” to ON it does nothing, but just enables this ability, so the other factors can turn discovering ON or OFF and this is not related to the fact that I switched it ON.
Initially the binding had only single switch for this similar to what you are saying @druciak, only later another switch was added to cover the following use cases which were driving me crazy:
(giving that you have only one switch)
- add an adapter and see it as a new thing
- enable “discovering” switch assuming that it instantly start discovery, however it does not for some reason.
Result: the discovering is not enabled because of some issues with Bluez or something (another client) disabled discovery.
What you see:
- either the switch goes off automatically right after you triggered it
- or it stays ON but it is not showing the real state of the things
- add an adapter and see it as a new thing
- enable “discovering” switch which in turns correctly enables adapter discovery, you see some new discovered devices
Result: later on, something happens with Bluez or BlueGiga adapter and it turns discovery off by itself, or other BT client turns off discovery
What you see: same as in the first scenario above
This was really driving me crazy, because you never know the real state of the things. That’s why another switch was added to “enable and forget” discovery so that the binding looks after it and if something happens it re-enables discovery.
Yes. I thought about activating “connection control”. But I was not able to see it because I have disabled “Simple Item Linking” (due to problems with Alexa.)
So first I have to enable this again. Then after detection of iTag I have to quickly jump to PaperUI --> Control --> Bluetooth Devices -> iTag --> Switch on “Connection Control”. All within 30 seconds.
I’ll try it tomorow.
I think this is because the switch did not get proper state for some reason. Current state of discovering should be polled periodically (every second or few seconds) and the switch state updated according to polled discovery state.
Anyway this is my suggestion, if it works better with 2 switches, that’s fine.