Jalee Temperature and Humidity Sensor detected as Ibeacon Tracker

Hello Together,

I bought some Jalee Temperature & Humidity Sensors from Aliexpress after I read there that they were supportet by Xiaomi BLE Protocol.
I activated one of the Sensors. Surprisingly it is detected as “Ibeacon tracker” and it seems that HA keeps detecting it as new device every time it sends a value. Below some screenshots. In the Yalee App I can see the temperature and humidity values.
After some time, the Ibeacon Tracker Integration removes all entries.
Is there any chance to get this working in HA?




Come on, people, I found traces that these devices are already supported by HA:
https://github.com/custom-components/ble_monitor/pull/1106
https://github.com/commento/gong-python/blob/42f733f80690a585c9aa58725b0e5108ba858d95/custom_components/binary_sensor/jaalee.py

So it must be possible to get this thing working in HA. Only I’m to stupid to do it. please help.

Are you trying to use them as iBeacons, or do you actually want to grab the temperature and humidity data from them?

From your iBeacon-4 screenshot, it looks like they are broadcasting iBeacon format for the UUID (the first string of numbers/letters starting with “ebef” and ending with “f525”), with fixed data (each line is the same), but then the last four numbers ("_2238" on the first line) are changing, which is weird.

Since you say this in only one of the Jalees, my guess is that the Jalee is using the major and minor data locations to carry the live temperature and the humidity data. So, just a guess, “2238” is the live temperature.

Another total guess: the temp might be being shown in hex. So 22 means “34 degrees C” and 38 means “.56 degrees C”. In other words, the temp is 34.56 degrees. The second line shows the temp went up to hex “2263” which would convert to 34.99 degrees C. (Use an online hex to dec converter for this)

Try putting it in the freezer to see how the numbers change.

So…if any of my above speculation is correct, it is acting like a beacon and broadcasting a fixed UUID (that’s correct beacon behavior), but it is changing the major and minor numbers (that’s not correct beacon behavior). That might be why the integration is getting angry and eventually deleting this device, i.e. “this thing was acting like a beacon for a little while, but now it is not acting like a proper beacon, so imma delete it!”

But the way, it’s also weird that under the “device” column on your screenshot, it is showing the UUID of the beacon, instead of the broadcast name of the beacon. On my HA, on this integration device page, it lists the names of all beacons in this column, not the UUID. I don’t think this should matter, since I assume it is actually broadcasting this UUID. But it’s a bit strange and makes me wonder what else they are doing oddly.

Warning: All of the above was 100% speculation. Lol

Thank you for the effort you put in your answer. I made some research of myself and I found that the JHT devices are supported in the custom integration “passive BLE monitor”, not in the official supported Xiaomii BLE integration, which I currently use. I installed the “passive BLE monitor” integration, but with no success. So I opned a bug report. The owner of the code, Ernst79, was very helpful. We made some debugging of Bluetootth and BLE Monitor, and it turns out, that due to incompatibilities between Xiaomi BLE and passive BLE monitor it is not possible to integrate the JHT in my HA environment. It has to do with active and passive scanning if I have understood this correct. So I can either wait for an official integration or use yet another Bluetooth device configured as BLE monitor (currently I have Bluetooth Proxies).

I’m still kinda curious if my guess about the major minor is correct. Can you put one in the freezer or refrigerator for 10 minutes and see how those major minor numbers change?

Re active versus passive scan: Yes, there is often confusion about this. Everyone sees the choice and immediately assumes that active is better than passive (active does sound better!). For beacons, active is usually just a waste of scanner energy and time, so only passive is needed for beacon scanning 95% of the time. This issue pops up a lot when people are talking about ESPresence and ESPHome here.

For things like this Jalee beacon that also measures temp and humidity, you typically would need active scanning. Why? Because passive scanning will only get you the standard broadcast data from the beacon, e.g. if it is broadcasting iBeacon protocol, then passive scan would give you the UUID, Major, and Minor. To get more than that basic data, you need to send a scan request to the beacon and wait for the scan response from the beacon. The scan response will have the special extra data, in this case, the temp and humidity data. Scan request and response is “active scanning”.

But, if my guess is correct, Jalee also decided to embed this temp and humidity data in the major minor of the standard iBeacon protocol. This makes it easier for some users to grab this data without the hassle of active scanning. Of course, it also screws up scanners/apps that are expecting unchanging uuid/major/minor. :disappointed:

Hi @muellthos,

Just out of curiosity, we have the Jaalee F525 (the blueish-greenish one) included in Theengs Decoder/Theengs Gateway Add-on. So you could try installing the Home Assistant add-on and see if it decodes your Jaalee for you As far as I know others are using it successfully with the Jaalee.

@BlueCharmBeacons, and yes, the encoding uses the major and minor for temperature and humidity, plus an extra octet to the usual iBeacon protocol for the battery level.

1 Like

So does it mean if I have some Xiaomi BLE devices I cannot integrate JAALEE BLE devices? Or what is exactly the problem? Sorry if that is stupid question. Have links to GH issue would help too