Here is the received value:
Maybe these are the strings I need. I don’t know how to form them for the ble stuff. Let me try that.
ok. I put those into that same PR. Try it again.
You shouldn’t have to mess with different esp32s. I think the hardware is working fine, it is the software that isn’t matching.
I haven’t looked at the wire shark, I am still holing out hope that this will be formatted the same way.
I wonder if those IDs can be wildcarded somehow, like anything that starts with 0x1523 is the same, then I could use the same code for both models. I just don’t know enough about BLE.
Still get the same result:
[14:11:40][I][ble_client:085]: Attempting BLE connection to 24:d7:eb:5f:e6:7e
[14:11:40][I][radon_eye_rd200:015]: Connected successfully!
[14:11:42][I][ble_client:166]: Service UUID: 0x1801
[14:11:42][I][ble_client:167]: start_handle: 0x1 end_handle: 0x5
[14:11:42][I][ble_client:378]: characteristic 0x2A05, handle 0x3, properties 0x20
[14:11:42][I][ble_client:166]: Service UUID: 0x1800
[14:11:42][I][ble_client:167]: start_handle: 0x14 end_handle: 0x1c
[14:11:42][I][ble_client:378]: characteristic 0x2A00, handle 0x16, properties 0x2
[14:11:42][I][ble_client:378]: characteristic 0x2A01, handle 0x18, properties 0x2
[14:11:42][I][ble_client:378]: characteristic 0x2AA6, handle 0x1a, properties 0x2
[14:11:42][I][ble_client:166]: Service UUID: 0x1523
[14:11:42][W][radon_eye_rd200:030]: No sensor read characteristic found at service 00000000-0000-0000-0000-000000000000 char 00000000-0000-0000-0000-000000000000
Is there any other information I need to provide to help?
Yaml file hasn’t changed much though not sure whether I implemented your addition correctly:
external_components:
# use esphome from jeffeb3
- source:
type: git
url: https://github.com/jeffeb3/esphome
ref: patch-1
components: [ radon_eye_rd200 ]
esphome:
name: wemosradoneye
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
level: DEBUG # Required for the tracker to show the device
# Enable Home Assistant API
api:
ota:
password: "pwd"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Wemosradoneye Fallback Hotspot"
password: "pwd"
captive_portal:
esp32_ble_tracker:
ble_client:
- mac_address: 24:D7:EB:5F:E6:7E
id: radon_eye_ble_id
sensor:
- platform: radon_eye_rd200
ble_client_id: radon_eye_ble_id
update_interval: 5min # default
radon:
name: "Radon"
radon_long_term:
name: "Radon Long Term"
I need to read more about BLE. Or have someone chime in with some advice. I am not sure why that isn’t working, and I’m not sure why your print is printing nothing but zeros. And without a device, I can’t even fumble through it. I’m at a dead end.
Is it possible for me to copy the Radon Eye files from ESPHome and manipulate them locally in order to see if I can get it to work with some trial and error? Right now it will only upload the files from ESPHome which contain the UUID for the older version. Do you know?
Yes. I did development that way.
You set all that up and then use the command line instructions to compile and upload your code to the ESP32. I use linux and develop C++ daily, so it wasn’t hard for me. I don’t know what issues you’ll encounter. Don’t forget you can log whatever you want if you get that up and running. Don’t guess about the state of something, just log it, and see what it is actually doing. Then figure out why. You can also edit the main ble code to add log statements, in case you’re trying to figure out where those ids are coming from.
I just got a new RadonEye and have loaded the ESPHome integration. Here are the log messages I am getting. Any ideas?
[I][ble_client:085]: Attempting BLE connection to 94:3c:c6:dd:20:02
[D][esp32_ble_tracker:726]: Found device 12:3E:DC:0C:79:78 RSSI=-86
[I][radon_eye_rd200:015]: Connected successfully!
[I][ble_client:166]: Service UUID: 0x1801
[I][ble_client:167]: start_handle: 0x1 end_handle: 0x5
[I][ble_client:378]: characteristic 0x2A05, handle 0x3, properties 0x20
[I][ble_client:166]: Service UUID: 0x1800
[I][ble_client:167]: start_handle: 0x14 end_handle: 0x1c
[I][ble_client:378]: characteristic 0x2A00, handle 0x16, properties 0x2
[I][ble_client:378]: characteristic 0x2A01, handle 0x18, properties 0x2
[I][ble_client:378]: characteristic 0x2AA6, handle 0x1a, properties 0x2
[I][ble_client:166]: Service UUID: 0x1523
[I][ble_client:167]: start_handle: 0x28 end_handle: 0xffff
[I][ble_client:378]: characteristic 0x1524, handle 0x2a, properties 0x6
[I][ble_client:378]: characteristic 0x1525, handle 0x2c, properties 0x12
[I][ble_client:378]: characteristic 0x1526, handle 0x2f, properties 0x12
[W][radon_eye_rd200:030]: No sensor read characteristic found at service 00001523-1212-EFDE-1523-785FEABCD123 char 00001525-1212-EFDE-1523-785FEABCD123
[D][esp32_ble_tracker:217]: Starting scan...
[D][esp32_ble_tracker:726]: Found device FA:CC:08:CB:17:D3 RSSI=-85
[D][esp32_ble_tracker:747]: Address Type: RANDOM
I’m having the same problem as well, here are my logs.
[00:14:33][D][ble_client:047]: Found device at MAC address [24:D7:EB:5E:59:C2]
[00:14:33][I][ble_client:085]: Attempting BLE connection to 24:d7:eb:5e:59:c2
[00:14:34][I][radon_eye_rd200:015]: Connected successfully!
[00:14:35][I][ble_client:166]: Service UUID: 0x1801
[00:14:35][I][ble_client:167]: start_handle: 0x1 end_handle: 0x5
[00:14:35][I][ble_client:378]: characteristic 0x2A05, handle 0x3, properties 0x20
[00:14:35][I][ble_client:166]: Service UUID: 0x1800
[00:14:35][I][ble_client:167]: start_handle: 0x14 end_handle: 0x1c
[00:14:35][I][ble_client:378]: characteristic 0x2A00, handle 0x16, properties 0x2
[00:14:35][I][ble_client:378]: characteristic 0x2A01, handle 0x18, properties 0x2
[00:14:35][I][ble_client:378]: characteristic 0x2AA6, handle 0x1a, properties 0x2
[00:14:35][I][ble_client:166]: Service UUID: 0x1523
[00:14:35][I][ble_client:167]: start_handle: 0x28 end_handle: 0xffff
[00:14:35][I][ble_client:378]: characteristic 0x1524, handle 0x2a, properties 0x6
[00:14:35][I][ble_client:378]: characteristic 0x1525, handle 0x2c, properties 0x12
[00:14:35][I][ble_client:378]: characteristic 0x1526, handle 0x2f, properties 0x12
[00:14:35][W][radon_eye_rd200:030]: No sensor read characteristic found at service 00001523-1212-EFDE-1523-785FEABCD123 char 00001525-1212-EFDE-1523-785FEABCD123
I’ve started today to try to find the new read characteristic of the radon-eye. Trying to sniff the packets using Wireshark if anyone has experience with reverse engineering and have any tips, that would be much appreciated.
Ok think I have a thing
Here are the Service UUID and Characteristic UUID
Update 1
Hello I’ve been continuing work on reverse engineering the new radon eye devices, looks like they may have changed some of the UUIDs
Update 2
The Error is fixed! … Kind of
Using my fork no more write errors show up! esphome/radon_eye_rd200.cpp at dev · AndreCox/esphome · GitHub
However there is no beep and no values appear to be reported to home assistant
I have started trying to figure out what’s going on and writing to address 0x45 then 0x46 appear to make it go beep, not sure what is going on. More research required.
Update 3
Seems like 0x45 and 0x46 just make it crash / restart nice
Ok so I’ve just received the new model of the RD200 also and going through the same issues. Some things I have noticed with the new version:
Model Name: RD200
The serial number is where I think we can identify the different hardware.
RU22204…
Think I saw somewhere the old one was RU20.
Now the most interesting part.
FCC ID: 2AC72-ESP32WROOM32E
Device obviously has a esp32 in the new one. This is probably what enables them to do both ble and wifi with the same hardware. So obviously they have re-designed the communications layer when they did it from the errors everyone is getting.
So these appear to be the new vs old addresses. I was able to utilize them to connect and get a value back but it is always a 0 value for radon by just replacing the old value with the new value. I think they may have implemented a new protocol of BLE where you have to register a notifier or something. I have not been able to get my phone to track the communications as it seems the phone manufacturers removed the ability in their android builds.
NEW: “00001523-0000-1000-8000-00805F9B34FB”
OLD: “00001523-1212-efde-1523-785feabcd123”
NEW: “00001524-0000-1000-8000-00805F9B34FB”
OLD: “00001524-1212-efde-1523-785feabcd123”
NEW: “00001525-0000-1000-8000-00805F9B34FB”
OLD: “00001525-1212-efde-1523-785feabcd123”
Here is a full printout of a sniffer for the ble, but not communicating.
Listing services…
– SERVICE: 00001801-0000-1000-8000-00805f9b34fb [Generic Attribute]
– → CHAR: 00002a05-0000-1000-8000-00805f9b34fb, Handle: 3 (0x0003) - INDICATE - [Service Changed]
– SERVICE: 00001800-0000-1000-8000-00805f9b34fb [Generic Access]
– → CHAR: 00002a00-0000-1000-8000-00805f9b34fb, Handle: 22 (0x0016) - READ - [Device Name]
– → CHAR: 00002a01-0000-1000-8000-00805f9b34fb, Handle: 24 (0x0018) - READ - [Appearance]
– → CHAR: 00002aa6-0000-1000-8000-00805f9b34fb, Handle: 26 (0x001a) - READ - [Central Address Resolution]
– SERVICE: 00001523-0000-1000-8000-00805f9b34fb [1523]
– → CHAR: 00001524-0000-1000-8000-00805f9b34fb, Handle: 42 (0x002a) - READ WRITE NO RESPONSE - [1524]
– → CHAR: 00001525-0000-1000-8000-00805f9b34fb, Handle: 44 (0x002c) - READ NOTIFY - [1525]
– → CHAR: 00001526-0000-1000-8000-00805f9b34fb, Handle: 47 (0x002f) - READ NOTIFY - [1526]
Listing descriptors…
– DESCRIPTORS: 00002800-0000-1000-8000-00805f9b34fb, [Primary Service Declaration], Handle: 1 (0x0001)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 2 (0x0002)
– DESCRIPTORS: 00002a05-0000-1000-8000-00805f9b34fb, [Service Changed], Handle: 3 (0x0003)
– DESCRIPTORS: 00002902-0000-1000-8000-00805f9b34fb, [Client Characteristic Configuration], Handle: 4 (0x0004)
– DESCRIPTORS: 00002800-0000-1000-8000-00805f9b34fb, [Primary Service Declaration], Handle: 20 (0x0014)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 21 (0x0015)
– DESCRIPTORS: 00002a00-0000-1000-8000-00805f9b34fb, [Device Name], Handle: 22 (0x0016)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 23 (0x0017)
– DESCRIPTORS: 00002a01-0000-1000-8000-00805f9b34fb, [Appearance], Handle: 24 (0x0018)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 25 (0x0019)
– DESCRIPTORS: 00002aa6-0000-1000-8000-00805f9b34fb, [Central Address Resolution], Handle: 26 (0x001a)
– DESCRIPTORS: 00002800-0000-1000-8000-00805f9b34fb, [Primary Service Declaration], Handle: 40 (0x0028)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 41 (0x0029)
– DESCRIPTORS: 00001524-0000-1000-8000-00805f9b34fb, [1524], Handle: 42 (0x002a)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 43 (0x002b)
– DESCRIPTORS: 00001525-0000-1000-8000-00805f9b34fb, [1525], Handle: 44 (0x002c)
– DESCRIPTORS: 00002902-0000-1000-8000-00805f9b34fb, [Client Characteristic Configuration], Handle: 45 (0x002d)
– DESCRIPTORS: 00002803-0000-1000-8000-00805f9b34fb, [Characteristic Declaration], Handle: 46 (0x002e)
– DESCRIPTORS: 00001526-0000-1000-8000-00805f9b34fb, [1526], Handle: 47 (0x002f)
– DESCRIPTORS: 00002902-0000-1000-8000-00805f9b34fb, [Client Characteristic Configuration], Handle: 48 (0x0030)
Reading characteristics…
– READ: 00002a05-0000-1000-8000-00805f9b34fb [Service Changed] (0x0003), None, Value:
– READ: 00002a00-0000-1000-8000-00805f9b34fb [Device Name] (0x0016), None, Value: b’FR:RU22204180133’
– READ: 00002a01-0000-1000-8000-00805f9b34fb [Appearance] (0x0018), None, Value: b’\x00\x00’
– READ: 00002aa6-0000-1000-8000-00805f9b34fb [Central Address Resolution] (0x001a), None, Value: b’\x00’
– READ: 00001524-0000-1000-8000-00805f9b34fb [1524] (0x002a), None, Value: b’P’
– READ: 00001525-0000-1000-8000-00805f9b34fb [1525] (0x002c), None, Value: b’\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00’
– READ: 00001526-0000-1000-8000-00805f9b34fb [1526] (0x002f), None, Value: b’\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00’
I see the same thing on my new RD200.
I’m trying to get this to work through a Hubitat HE, probably using a Raspberry Pi to do the BLE, and then I’ll get the data into a dashboard to display on my tablets. I’ll probably have a couple graphs showing the last week and maybe a long-term view.
For now, I have an expect script I can run from a Linux machine that pulls the history data:
#!/usr/bin/expect -f
log_user 0
## That removes the output from STDOUT, except for puts
set device "94:3C:C6:DE:31:7A"
## Change that to your own device ID.
spawn gatttool -b $device -I
expect "> "
sleep 1
send -- "connect\r"
expect "Connection successful"
sleep 1
send -- "mtu 507\r"
expect "MTU was exchanged successfully"
sleep 1
#match_max 10000
## Might need to increase match to receive all the response once it stores more data. Maybe this won't work once a year of data is stored.
send -- "char-write-cmd 0x002a 41\r"
set message1 ""
expect {
-re "Notification handle = 0x002f value: (.+\n)" {
set message1 ${message1}$expect_out(1,string)
exp_continue
}
"^\[.+\]\[LE\]> $" {
send -- "disconnect\r"
}
}
puts "$message1"
That returns the hex values for the Radon history, one line per 250 values. The first 4 bytes contain:
x41 x01-x?? x01-x24? x01-xFA.
The first byte is the same as the write command, the second I think is the total number of responses, the third is the response number, and the fourth is the number of values in this response.
I haven’t messed much with sending 0x40, which should respond with info on the current value. I’m not sure what the values mean. I’m happy just seeing the hourly Radon value history.
I also wrote one using bluetoothctl, but it seemed less robust than the gatttool-based script above.
Here’s what I can do in bluetoothctl:
$ bluetoothctl
[bluetooth]# connect 94:3C:C6:DE:31:7A
[FR:RU22204180363]# menu gatt
[FR:RU22204180363]# select-attribute /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e
[FR:RU22204180363/service0028/char002e]# acquire-notify
[FR:RU22204180363/service0028/char002e]# select-attribute /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char0029
[FR:RU22204180363/service0028/char0029]# write 0x41
That also returns the hex values for the radon history. Obviously the MAC address in the connect command and in the select-attribute commands have to change.
The values I see match the new values you see, as well.
Hopefully this helps. I’m pretty sure I can pull values at will and plot using RPi. Just need the chip shortage to end…
Edit:
I checked again, and the gatttool expect script above now returns 3 lines, and the first 4 bytes definitely represent:
- byte1 = x41: the value of the request (write x41 to get the history)
- byte2 = x01 - x24?: the total number of responses returned. Up to a year of 1 response per hour and 250 values per response, so I think it maxes at x24. Not sure.
- byte3 = x01 - x24?: the number of this response
- byte4 = x01 - xFA: the number of values returned in this response (up to 250 = xFA)
So, with three responses returned, the first 4 bytes of each were:
41 03 01 fa ...
41 03 02 fa ...
41 03 03 04 ...
Here’s my full bluetoothctl session:
$ bluetoothctl
[NEW] Controller 5C:5F:67:28:5C:7F hostname [default]
[NEW] Device 94:3C:C6:DE:31:7A FR:RU22204180363
[NEW] Primary Service
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028
00001523-0000-1000-8000-00805f9b34fb
Unknown
[NEW] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e
00001526-0000-1000-8000-00805f9b34fb
Unknown
[NEW] Descriptor
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e/desc0030
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002b
00001525-0000-1000-8000-00805f9b34fb
Unknown
[NEW] Descriptor
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002b/desc002d
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char0029
00001524-0000-1000-8000-00805f9b34fb
Unknown
[NEW] Primary Service
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0001
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0001/char0002
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
[NEW] Descriptor
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0001/char0002/desc0004
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
Agent registered
[bluetooth]# connect 94:3C:C6:DE:31:7A
Attempting to connect to 94:3C:C6:DE:31:7A
[CHG] Device 94:3C:C6:DE:31:7A Connected: yes
Connection successful
[CHG] Device 94:3C:C6:DE:31:7A ServicesResolved: yes
[FR:RU22204180363]# menu gatt
Menu gatt:
Available commands:
-------------------
list-attributes [dev] List attributes
select-attribute <attribute/UUID> Select attribute
attribute-info [attribute/UUID] Select attribute
read Read attribute value
write <data=xx xx ...> Write attribute value
acquire-write Acquire Write file descriptor
release-write Release Write file descriptor
acquire-notify Acquire Notify file descriptor
release-notify Release Notify file descriptor
notify <on/off> Notify attribute value
register-application [UUID ...] Register profile to connect
unregister-application Unregister profile
register-service <UUID> Register application service.
unregister-service <UUID/object> Unregister application service
register-characteristic <UUID> <Flags=read,write,notify...> Register application characteristic
unregister-characteristic <UUID/object> Unregister application characteristic
register-descriptor <UUID> <Flags=read,write...> Register application descriptor
unregister-descriptor <UUID/object> Unregister application descriptor
back Return to main menu
version Display version
quit Quit program
exit Quit program
help Display help about this program
[FR:RU22204180363]# select-attribute /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e
[FR:RU22204180363:/service0028/char002e]# acquire-notify
[CHG] Attribute /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e NotifyAcquired: yes
AcquireNotify success: fd 7 MTU 517
[FR:RU22204180363:/service0028/char002e]# select-attribute /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char0029
[FR:RU22204180363:/service0028/char0029]# write 0x41
Attempting to write /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char0029
[CHG] /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e Notification:
41 02 01 fa 19 00 30 00 30 00 26 00 2e 00 2e 00 A.....0.0.&.....
2d 00 23 00 20 00 1d 00 2a 00 17 00 17 00 12 00 -.#. ...*.......
1d 00 1d 00 2b 00 34 00 2e 00 37 00 27 00 21 00 ....+.4...7.'.!.
30 00 37 00 3a 00 2d 00 2b 00 1a 00 30 00 16 00 0.7.:.-.+...0...
10 00 13 00 12 00 0f 00 17 00 16 00 24 00 19 00 ............$...
16 00 26 00 1c 00 20 00 34 00 3f 00 26 00 35 00 ..&... .4.?.&.5.
3f 00 30 00 31 00 38 00 3f 00 44 00 38 00 26 00 ?.0.1.8.?.D.8.&.
19 00 24 00 2a 00 2e 00 21 00 20 00 1c 00 24 00 ..$.*...!. ...$.
1c 00 26 00 38 00 2e 00 48 00 34 00 35 00 37 00 ..&.8...H.4.5.7.
38 00 44 00 44 00 31 00 41 00 44 00 3b 00 27 00 8.D.D.1.A.D.;.'.
2b 00 27 00 1d 00 17 00 2d 00 2b 00 27 00 26 00 +.'.....-.+.'.&.
2e 00 3b 00 44 00 44 00 3e 00 45 00 4e 00 37 00 ..;.D.D.>.E.N.7.
34 00 44 00 2e 00 24 00 30 00 24 00 2b 00 2d 00 4.D...$.0.$.+.-.
2a 00 30 00 1c 00 30 00 23 00 23 00 1c 00 23 00 *.0...0.#.#...#.
31 00 20 00 3a 00 3e 00 3f 00 38 00 45 00 55 00 1. .:.>.?.8.E.U.
45 00 3a 00 42 00 2a 00 37 00 42 00 35 00 2e 00 E.:.B.*.7.B.5...
38 00 2a 00 35 00 21 00 21 00 2a 00 26 00 24 00 8.*.5.!.!.*.&.$.
3b 00 31 00 30 00 3e 00 30 00 3a 00 24 00 37 00 ;.1.0.>.0.:.$.7.
3b 00 37 00 26 00 41 00 30 00 1c 00 34 00 21 00 ;.7.&.A.0...4.!.
23 00 34 00 26 00 19 00 23 00 24 00 1d 00 19 00 #.4.&...#.$.....
16 00 2a 00 2e 00 34 00 3e 00 41 00 38 00 30 00 ..*...4.>.A.8.0.
21 00 3a 00 2d 00 2a 00 2b 00 21 00 24 00 24 00 !.:.-.*.+.!.$.$.
30 00 24 00 19 00 1c 00 16 00 1a 00 1a 00 21 00 0.$...........!.
27 00 2b 00 23 00 2b 00 27 00 2b 00 2a 00 3b 00 '.+.#.+.'.+.*.;.
2d 00 2a 00 12 00 17 00 27 00 26 00 24 00 1d 00 -.*.....'.&.$...
27 00 20 00 1a 00 1d 00 20 00 23 00 24 00 31 00 '. ..... .#.$.1.
20 00 2a 00 2a 00 31 00 34 00 3a 00 2d 00 42 00 .*.*.1.4.:.-.B.
34 00 35 00 34 00 3b 00 30 00 37 00 2e 00 27 00 4.5.4.;.0.7...'.
26 00 17 00 2a 00 2b 00 20 00 19 00 26 00 2d 00 &...*.+. ...&.-.
21 00 27 00 2e 00 38 00 37 00 38 00 30 00 27 00 !.'...8.7.8.0.'.
21 00 31 00 24 00 26 00 19 00 2a 00 24 00 1a 00 !.1.$.&...*.$...
1c 00 20 00 13 00 2a 00 .. ...*.
[CHG] /org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e Notification:
41 02 02 95 26 00 26 00 10 00 1a 00 13 00 20 00 A...&.&....... .
2b 00 31 00 3e 00 34 00 19 00 35 00 35 00 2e 00 +.1.>.4...5.5...
30 00 37 00 24 00 2a 00 30 00 21 00 26 00 23 00 0.7.$.*.0.!.&.#.
1c 00 19 00 1d 00 17 00 21 00 20 00 1d 00 2a 00 ........!. ...*.
3b 00 24 00 20 00 26 00 24 00 30 00 2e 00 26 00 ;.$. .&.$.0...&.
38 00 30 00 31 00 2a 00 2d 00 2b 00 2b 00 2b 00 8.0.1.*.-.+.+.+.
26 00 2a 00 1d 00 24 00 1a 00 23 00 2e 00 30 00 &.*...$...#...0.
45 00 41 00 2e 00 2b 00 34 00 38 00 3e 00 45 00 E.A...+.4.8.>.E.
2d 00 42 00 35 00 2d 00 2a 00 26 00 1d 00 34 00 -.B.5.-.*.&...4.
2e 00 20 00 26 00 2e 00 21 00 21 00 1c 00 2d 00 .. .&...!.!...-.
4e 00 41 00 45 00 38 00 31 00 3f 00 3a 00 38 00 N.A.E.8.1.?.:.8.
35 00 23 00 26 00 27 00 24 00 16 00 2d 00 30 00 5.#.&.'.$...-.0.
1c 00 2a 00 10 00 27 00 20 00 20 00 1d 00 26 00 ..*...'. . ...&.
2d 00 31 00 37 00 3e 00 31 00 2e 00 3a 00 2d 00 -.1.7.>.1...:.-.
49 00 4b 00 41 00 37 00 2d 00 3f 00 3b 00 30 00 I.K.A.7.-.?.;.0.
26 00 31 00 27 00 41 00 30 00 3b 00 41 00 5c 00 &.1.'.A.0.;.A.\.
5a 00 45 00 44 00 4b 00 49 00 4c 00 45 00 30 00 Z.E.D.K.I.L.E.0.
48 00 45 00 41 00 38 00 2b 00 3a 00 31 00 37 00 H.E.A.8.+.:.1.7.
24 00 27 00 26 00 17 00 31 00 34 00 23 00 $.'.&...1.4.#.
[FR:RU22204180363:/service0028/char0029]# back
Menu main:
Available commands:
-------------------
advertise Advertise Options Submenu
scan Scan Options Submenu
gatt Generic Attribute Submenu
list List available controllers
show [ctrl] Controller information
select <ctrl> Select default controller
devices List available devices
paired-devices List paired devices
system-alias <name> Set controller alias
reset-alias Reset controller alias
power <on/off> Set controller power
pairable <on/off> Set controller pairable mode
discoverable <on/off> Set controller discoverable mode
agent <on/off/capability> Enable/disable agent with given capability
default-agent Set agent as the default one
advertise <on/off/type> Enable/disable advertising with given type
set-alias <alias> Set device alias
scan <on/off> Scan for devices
info [dev] Device information
pair [dev] Pair with device
trust [dev] Trust device
untrust [dev] Untrust device
block [dev] Block device
unblock [dev] Unblock device
remove <dev> Remove device
connect <dev> Connect device
disconnect [dev] Disconnect device
menu <name> Select submenu
version Display version
quit Quit program
exit Quit program
help Display help about this program
[FR:RU22204180363:/service0028/char0029]# disconnect
Attempting to disconnect from 94:3C:C6:DE:31:7A
Notify closed
[CHG] Device 94:3C:C6:DE:31:7A ServicesResolved: no
Successful disconnected
[CHG] Device 94:3C:C6:DE:31:7A Connected: no
[bluetooth]# exit
Agent unregistered
[DEL] Controller 5C:5F:67:28:5C:7F hostname [default]
[DEL] Primary Service
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028
00001523-0000-1000-8000-00805f9b34fb
Unknown
[DEL] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e
00001526-0000-1000-8000-00805f9b34fb
Unknown
[DEL] Descriptor
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002e/desc0030
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[DEL] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002b
00001525-0000-1000-8000-00805f9b34fb
Unknown
[DEL] Descriptor
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char002b/desc002d
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[DEL] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0028/char0029
00001524-0000-1000-8000-00805f9b34fb
Unknown
[DEL] Primary Service
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0001
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
[DEL] Characteristic
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0001/char0002
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
[DEL] Descriptor
/org/bluez/hci0/dev_94_3C_C6_DE_31_7A/service0001/char0002/desc0004
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
$
And here’s my full gatttool session:
$ gatttool -b 94:3C:C6:DE:31:7A -I
[94:3C:C6:DE:31:7A][LE]> connect
Attempting to connect to 94:3C:C6:DE:31:7A
Connection successful
[94:3C:C6:DE:31:7A][LE]> mtu 507
MTU was exchanged successfully: 507
[94:3C:C6:DE:31:7A][LE]> char-write-cmd 0x002a 41
Notification handle = 0x002f value: 41 02 01 fa 19 00 30 00 30 00 26 00 2e 00 2e 00 2d 00 23 00 20 00 1d 00 2a 00 17 00 17 00 12 00 1d 00 1d 00 2b 00 34 00 2e 00 37 00 27 00 21 00 30 00 37 00 3a 00 2d 00 2b 00 1a 00 30 00 16 00 10 00 13 00 12 00 0f 00 17 00 16 00 24 00 19 00 16 00 26 00 1c 00 20 00 34 00 3f 00 26 00 35 00 3f 00 30 00 31 00 38 00 3f 00 44 00 38 00 26 00 19 00 24 00 2a 00 2e 00 21 00 20 00 1c 00 24 00 1c 00 26 00 38 00 2e 00 48 00 34 00 35 00 37 00 38 00 44 00 44 00 31 00 41 00 44 00 3b 00 27 00 2b 00 27 00 1d 00 17 00 2d 00 2b 00 27 00 26 00 2e 00 3b 00 44 00 44 00 3e 00 45 00 4e 00 37 00 34 00 44 00 2e 00 24 00 30 00 24 00 2b 00 2d 00 2a 00 30 00 1c 00 30 00 23 00 23 00 1c 00 23 00 31 00 20 00 3a 00 3e 00 3f 00 38 00 45 00 55 00 45 00 3a 00 42 00 2a 00 37 00 42 00 35 00 2e 00 38 00 2a 00 35 00 21 00 21 00 2a 00 26 00 24 00 3b 00 31 00 30 00 3e 00 30 00 3a 00 24 00 37 00 3b 00 37 00 26 00 41 00 30 00 1c 00 34 00 21 00 23 00 34 00 26 00 19 00 23 00 24 00 1d 00 19 00 16 00 2a 00 2e 00 34 00 3e 00 41 00 38 00 30 00 21 00 3a 00 2d 00 2a 00 2b 00 21 00 24 00 24 00 30 00 24 00 19 00 1c 00 16 00 1a 00 1a 00 21 00 27 00 2b 00 23 00 2b 00 27 00 2b 00 2a 00 3b 00 2d 00 2a 00 12 00 17 00 27 00 26 00 24 00 1d 00 27 00 20 00 1a 00 1d 00 20 00 23 00 24 00 31 00 20 00 2a 00 2a 00 31 00 34 00 3a 00 2d 00 42 00 34 00 35 00 34 00 3b 00 30 00 37 00 2e 00 27 00 26 00 17 00 2a 00 2b 00 20 00 19 00 26 00 2d 00 21 00 27 00 2e 00 38 00 37 00 38 00 30 00 27 00 21 00 31 00 24 00 26 00 19 00 2a 00 24 00 1a 00 1c 00 20 00 13 00 2a 00
Notification handle = 0x002f value: 41 02 02 95 26 00 26 00 10 00 1a 00 13 00 20 00 2b 00 31 00 3e 00 34 00 19 00 35 00 35 00 2e 00 30 00 37 00 24 00 2a 00 30 00 21 00 26 00 23 00 1c 00 19 00 1d 00 17 00 21 00 20 00 1d 00 2a 00 3b 00 24 00 20 00 26 00 24 00 30 00 2e 00 26 00 38 00 30 00 31 00 2a 00 2d 00 2b 00 2b 00 2b 00 26 00 2a 00 1d 00 24 00 1a 00 23 00 2e 00 30 00 45 00 41 00 2e 00 2b 00 34 00 38 00 3e 00 45 00 2d 00 42 00 35 00 2d 00 2a 00 26 00 1d 00 34 00 2e 00 20 00 26 00 2e 00 21 00 21 00 1c 00 2d 00 4e 00 41 00 45 00 38 00 31 00 3f 00 3a 00 38 00 35 00 23 00 26 00 27 00 24 00 16 00 2d 00 30 00 1c 00 2a 00 10 00 27 00 20 00 20 00 1d 00 26 00 2d 00 31 00 37 00 3e 00 31 00 2e 00 3a 00 2d 00 49 00 4b 00 41 00 37 00 2d 00 3f 00 3b 00 30 00 26 00 31 00 27 00 41 00 30 00 3b 00 41 00 5c 00 5a 00 45 00 44 00 4b 00 49 00 4c 00 45 00 30 00 48 00 45 00 41 00 38 00 2b 00 3a 00 31 00 37 00 24 00 27 00 26 00 17 00 31 00 34 00 23 00
[94:3C:C6:DE:31:7A][LE]> disconnect
(gatttool:15161): GLib-WARNING **: 23:46:27.709: Invalid file descriptor.
[94:3C:C6:DE:31:7A][LE]> exit
$
Ok I have confirmation from Ecosense that the communications protocol changed:
Yes, we updated the Bluetooth chip and protocol last November.
Please let me know if you have any questions.
Thank you,
–
Jaime
You have gotten so much farther then I was. You mentioned about waiting for the prices of chips to come down. I think if we can get the integration back into ESPHome working then you could run it on a ESP board and even use MQTT for notifications.
Oh, I don’t think I mentioned, but the radon history comes out as little-endian short integers (2 bytes per int) as Becquerels/m^3. I converted to pCi/L by dividing by 37, and I get the same values as I see in the app. Here’s a plot I made in LibreOffice Calc:
*Updated to correctly refer to little-endian byte order instead of big-endian:
For example, first and second bytes in my response following the initial 4 bytes are: 19 00, which encodes x0019, or 25 Bq/m^3.
Do you have context to the data your getting? is this the hourly average data? I would like to access the live data as well as potentially the historical data
Yes, these data are for the hourly average historical data. Each data point (2 bytes) contains one hour, starting at data point 1 in response 1, up to the last data point in response x. So far I only get two responses, since I don’t have much data stored. Eventually I’ll get many responses with lots of data points, each one 1 hr before the next.
As for the live data, I don’t know what the response means. Here’s a gatttool session pulling the live data:
$ gatttool -b 94:3C:C6:DE:31:7A -I
[94:3C:C6:DE:31:7A][LE]> connect
Attempting to connect to 94:3C:C6:DE:31:7A
Connection successful
[94:3C:C6:DE:31:7A][LE]> mtu 507
MTU was exchanged successfully: 507
[94:3C:C6:DE:31:7A][LE]> char-write-cmd 0x002a 40
Notification handle = 0x002c value: 40 42 32 32 30 34 31 38 52 55 32 30 33 36 33 06 52 44 32 30 30 4e 56 32 2e 30 2e 32 00 00 94 00 06 2b 00 30 00 00 00 02 00 07 00 da 22 00 00 4f 1f 08 00 60 00 02 00 00 00 a4 01 00 85 eb 51 3f 66 66 86 3f
[94:3C:C6:DE:31:7A][LE]> disconnect
(gatttool:1505): GLib-WARNING **: 21:02:23.433: Invalid file descriptor.
[94:3C:C6:DE:31:7A][LE]> exit
$
I did this a couple times and looked at the values on the app at the same time, but couldn’t quite determine what the returned bytes meant. Some of them seemed to stay the same, but others changed. Each time, the first byte is x40, which is the same as the request. With enough responses along with the app data, I could probably figure it out. For now, I think I’m happy pulling the historical data.
If you can pull many x40 responses and match them with the data in the app at the same time, I’d love to hear what you found. Remember, the Radon levels are probably stored as Bq/m^3, so divide by 37 to get pCi/L. There should be some value for current level, peak level, 1-day average, and measurement time. Maybe measurement time is stored as 3 short ints, or it could be stored as a long int. Would be good to watch that change and follow the results to find the values. I’d guess you could follow for a few hours and see the time change pretty easily. Otherwise the peak value and 1-day average will require longer-term monitoring.