3rd Party Bluetooth Binding. Beta testers needed

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.

1 Like

FYI

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.

1 Like

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)

Scenario 1:

  • 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

Scenario 2

  • 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.

@vkolotov Thanks. :slight_smile:
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.

Alex

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. :slight_smile:

Hey @Celaeno1, you don’t have to enable “simple mode” and to do that awkward thing, you can link “connection control” manually. It is just yet another channel that is available to be linked as per normal.

Maybe there is a missunderstanding? When “Simple Mode” is deactivated, then there will be NO thing to control, because NO items are linked to the channels.

As you can see, "BLUETOOTH DEVICES" is empty!

When “Simple Mode” is activated, then you can see the following:

image

And now, you are able to switch on: “Connection Control”. BTW, it is enabled by DEFAULT.

But this is only running with “Simple Mode”.

In non Simple Mode:

My BLE device is “ready for connecting” only about 30 seconds. This is too short, to create manually an item and link it to channel “Connection Control”.

After the 30 seconds, I have to press the button on iTag again (TURN OFF , TURN ON). Then it has a new MAC-Address. And the same game starts from the beginning…

Hi @Celaeno1, you can manually create links here (when simple mode is enabled):

Click on that blue round dot, you may accept all default values. This is what you will get if you do this for “Connected” and “Connection Control” channels:

Please let me know if it is working for you.

I can confirm that iTag device working just great. I can see that button triggers a change in a characteristic, and also you can trigger a channel (it is hidden in the current version of the binding) to make the device to buzz!

@All, btw there is a limitation/bug of the PaperUI, when channels are dynamically created (like when you connect to a BT device), the PaperUI does not show them unless you manually refresh the page. So I recommend to refresh your browser tab when you connect to a BT device.

Thanks. I will try out this evening. Hopefully I’m fast enough to click and link it.