Thanks for your offer. I think I have to dig a little bit deeper…
But today I unfortunately have no time any more.
Hi @Celaeno1, @Pim_Verschueren, @Fredrik_Andersson and all here. A quick fix for the performance is to unlink “RSSI” and “Estimated Distance” channels if you are not using them. The reason is that the binding generates too much RSSI and Estimated Distance events so that OH can’t handle it. I’ll probably add a “reporting rate” config in the next release to limit RSSI samples.
Here is interesting statistics. I’ve added 10 devices, up to about 9.08pm “RSSI” and “Estimated distance” channels were linked. CPU load was around 25%. When I unlinked “RSSI” and “Estimated distance” channels at around 9.08pm, CPU load drops to around 8%.
1 Like
Hi Vlad,
short question regarding the Elistoop bluetooth tags:
Once the tags are powered on (“double beep”) they start sending. Confirmed this by using some arbitrary beacon scanner app. Few minutes later, the tags issue a single beep and then stop sending (switched off due to a missing connection to the app???)
So I’m slightly confused:
Is it neccessary to get them connected to their original phone app to prevent them from beeing switched off?
Or:
Will the tags remain active when connected to your binding even if not beeing paired with a phone?
Can you shed some light upon this?
Hi @curlyel, here is my observation of how those iTag devices work:
- When you power up one of them, it beeps (double beep). Then it starts broadcasting (just only RSSI and its name).
- From here you’ve got options:
- Disable “Connection control” (leave the “thing” unconnected). This means you can’t use neither the button nor the alarm. You just use it as a standard beacon, e.g. you can only detect presence.
- Enable “Connection control” (make it to be connected). This means:
- the device “remembers” your adapter, once it get out of the range of the adapter, it will beep for a minute (slow beeping). When it gets in the range of the adapter, it gets connected automatically (single beep I think). Also when connected to a new adapter, it forgets previous one (your phone).
- you can use the button to trigger events in OH
- you can trigger an alarm on your iTag
Note for the option #1. Bear in mind that the iTag device always remembers the previous connected adapter (or your phone), this means that if you have never enabled “Connection control” and it has never been connected to the binding, the option #2 applies for your phone.
I personally find it a bit annoying when it starts beeping once it looses its connection. You have to push the button to stop beeping. So I use it mainly as #1. When I loose my keys in my house, I still can enable the “Connection control” and trigger the alarm to find them. This means that most of the time my iTag devices stay disconnected and used as beacons only.
PS. I’ll need to check what happens if a disconnection is triggered by the binding, e.g. will it beep for a min? It might be that if the device detects that the client drops its connection on purpose (not because of link loss), then it might “unlink” itself and forget the client.
@curlyel, is this how it works for you as well? If not, we might have different devices…
I see from your post:
Few minutes later, the tags issue a single beep and then stop sending (switched off due to a missing connection to the app???)
This might be the case… Although this behaviour is quite strange, because normally beacons stay always on. Otherwise there isn’t any use of them to my mind. I can make an assumption, when you saw that it stopped broadcasting, it might have been connected to your phone. Just a general rule for all bluetooth devices: when a device gets connected, the device stops “public” broadcasting (data is exchanged only between connected client and the device).
Cool, thanks. That’s a bug probably.
BTW, what about your kettle? Can you do some samples as well as you did for your scales?
Sorry, I still needed to create a post on github with all the info. For now this is the only thing I can see it broadcasting.
Another question. Is there anyway I can use other Bluetooth adapters? I.e. my server with openHAB is upstairs and some of my Bluetooth devices seem to be out of its reach. I do have a mini pc downstairs with Bluetooth so is there anyway I can use that as a bridge of some sort?
Cheers.
Hi @Pim_Verschueren, this question is beyond the binding responsibilities (it is more question to OH, e.g. how to make a cluster of multiple instances of OH). What you can do is to use a USB extender (passive - 5m max, active +30m max) to add another adapter. The binding supports multiple adapters running in the same time, I’m running 3-4 adapters (bluegiga and generic) in the same time with just 5m usb cables that I put in the attic.
BTW, depending on the building materials in your house, you probably don’t have to lay a cable to the lower level. It might be just enough if you just spread the adapters on your upper level.
Ok, thanks, that makes sense. I have unlinked the RSSI and estimated distance channels and have turned the discovery rate back up to 5 just to check what the impact is.
Do you mean “Bluetooth devices update rate”? The default value is 10s. 5s is too low value.
sorry, yes…have put it to 10 
Hi Vlad,
many thanks for the comprehensive answer sharing your experience with these tags!
It helps me a lot in understanding their behaviour 
I have to admit, that I’m still waiting for the delivery of additional bluetooth dongles to make use of your binding in my openHAB test instance. Have yet received the tags and a MiFlora but still waiting for the Xiaomi thermometer and for the bt dongles of course as said already.
So I’m currently just learning what to expect and how to get it working together…
Oh yes, fully agree. This would be annoying.
The out-of-range-beep seems to be configurable in the tags as well as the flashing LED. Some of the Android apps out there pretend to offer setting the beep and the flashing LED. Fortunately, at least one of them is open source - so might be worth having a look at the source code:
LED setting is not possible with it, but the buzzer config is included as well as setting actions for single-press and double-press of the tag’s buttons. Very likely, you’re already aware of it or similar apps - nevertheless sharing it, just in case
Suppressing the range beep and enabling the single/double-press events would turn these tiny things into ultra cheap one-button key ring remotes 
Hi @curlyel, thanks for your response. I had a quick look at the source code of that app… and played a bit with this app on my android phone. There is indeed a setting to control whether the iTag device beeps when link is lost. However it is not working with my devices that I bought on Aliexpress. When I try to change that config in the app, the app show a error message “Something not right” :). It is indeed something not right. Looks like the app is using/expecting the standard GATT “Link Loss” service on the device, but for some strange reason it is missing from my tags. From what I understand in the documentation for that service, it is possible to control what’s happening when a device looses connection, e.g. to beep or not to beep. Having said that, you might be more lucky than me, and since that service is a standard one, you might find that the binding provides a channel for that service as it does for the button (Immediate Alert). Let me know how it goes for you.
Yes, I had this message too. It seems to me, that this happens always if the tag is not “fully connected” to the app or the tag is not powered on.
But if the app has discovered the tag and connected to it, then the settings checkboxes are working for me without the error message…
It was connected, I could trigger an alarm. And also I can clearly see that the “Link Loss” service is missing in the binding itself and in the Nordic nRF Connect app.
You may try to install “Nordic nRF Connect” app, it is a very useful app to work with bluetooth devices. It can tell you what services a device has.
Thanks for the hint. The app was already on the phone (among the other scanners )
For reference/comparison: That’s what it gathers from my tags:
Good to know. I’m going to report it back once I’ve managed to get it connected to the binding.
Regarding the single/double press:
If the “immediate alert” service provides it, then double-press is just a second alert within a certain time - right?
So it’s implemented in the APP logic (openHAB rule engine in our case) and not in the tag’s firmware.
Yes you are right, you should be able to implement a rule for that.
Re your device, good stuff, your device supports the Link Loss. Could you please let me know where have you bought it from?