[APP][Pro] RadonEye - Real-time radon detection

Apps
, ,
1

Placeholder for information regarding the RadonEye app.

Source can be found here: GitHub - petero-dk/org.radoneye

The test version can be installed from here: RadonEye | Homey

1 Like
[LIST] NEW published App in Homey App store :rocket: - Get 'em while they're hot
2

I know there is an issue with version 3 (and maybe version 2) firmware, but I don’t have that version so I am not able to directly test it.

If anyone has experience in Homey apps development and have a Radon Eye version 2 or 3 I would be happy to guide and co-develop

3

I have two v3.0.1, I could send one to you :see_no_evil_monkey::joy: really

or you tell me what to do…

Cheers

Marc

Supportfile

6803425f-d06e-41bf-9178-35dd3e27bdba

4

Does this help?

RD200 Overview

The RadonEye RD200 is a smart radon detector using a pulsed ionization chamber for real-time monitoring, with Bluetooth LE (BLE) connectivity for data access via apps or custom Python scripts. It provides radon levels in Bq/m³ or pCi/L, updated every 10 minutes (60-minute moving average), with high sensitivity (30 cph per pCi/L) and accuracy <±10% at 10 pCi/L. Data logging stores up to 1 year of hourly readings; power via 12V DC adapter, operating range 0-40°C, RH<80%.

Version Differences

Versions (V1, V2, V3.0.1) differ mainly in BLE packet structure and data fields, identified by serial number prefix (e.g., FR:R2 for V1, FR:RU/RE/GI for V2). All share core radon metrics but V2/V3 add pulse counters and detailed uptime for better validation in Python integrations like rd200v2 GitHub repo. V3.0.1 is a firmware update improving stability without new fields.

Common BLE Data Fields

All versions transmit via packets like 0x40 (status) and 0x51 (details), parsed as Little-Endian in Python (e.g., struct.unpack). Core fields are available across versions; extended ones only in V2+.

Detailed Data Fields Table

Field Name Type/Format Unit Value Range/Notes Field Size (Bytes) Versions Remarks
Radon Current uint16 Bq/m³ 1-3700 (10-min update) 2 V1/V2/V3 ​ Real-time, offset-corrected
Radon 24h Average uint16 Bq/m³ Hourly rolling average 2 V1/V2/V3 ​ Short-term trend
Radon 1-Month Average uint16 Bq/m³ Long-term (up to 1 year storage) 2 V1/V2/V3 ​ Compliance monitoring
Peak Radon uint16 Bq/m³ Maximum since start/reset 2 V1/V2/V3 ​ App-resettable
Uptime Hours uint16 Hours Total runtime​ 2 V1/V2/V3 ​ Basic longevity
Pulse Counter Current uint32 Counts Current pulses for validation 4 V2/V3 ​ Accuracy check (missing in V1)
Pulse 10min Interval uint32 Counts/10min Interval pulses 4 V2/V3 Real-time integrity
Uptime Minutes uint8 Minutes Detailed time 1 V2/V3 ​ Supplements hours
Uptime Seconds uint8 Seconds Precise runtime 1 V2/V3 ​ Full uptime precision
Firmware Version uint16/String - e.g., V3.0.1 (major/minor) 2-4 V2/V3 Device identification
Battery Level uint8 % 0-100 (if applicable) 1 All?​ Not always in BLE
Packet Type uint8 - 0x40/0x51 headers 1 All ​ Parsing key
MAC Address uint48 - Device ID for scanning 6 All Static, required for Python

Python Integration Notes

Use libraries like bleak for BLE scanning; rd200v2 repo handles parsing (V1 partial, V2/V3 full support). Recommend ESP32 proxy for stability on Raspberry Pi; poll every 10 min, validate via pulses > threshold. Packets: V1 ~20 bytes, V2/V3 ~30+ bytes. Compatible with Home Assistant/ESPHOME.

5

maybe this also…

BLE Connection Overview

All Radoneye RD200 versions (V1, V2, V3.0.1) use standard Bluetooth Low Energy (BLE) with no fundamental differences in connection setup, such as advertising, scanning, or GATT services. Devices advertise continuously with a static MAC address (e.g., identifiable as “FR:R2:SNxxxx” for V1), scanned via tools like bleak in Python or ESPHome; connection is connectionless for notifications after pairing (no complex handshake beyond standard BLE pairing). Data is pushed via notifications on characteristics (e.g., 0x40/0x51 packet types), polled every 10 minutes; no authentication or bonding required for community tools.

Differences in BLE Structure

No significant variations in BLE connection type (all BLE 4.2+), advertising interval (~1s), or MTU (default 20-23 bytes). Differences lie in payload content and size: V1 packets shorter (~20 bytes, basic fields), V2/V3 extended (~30+ bytes with pulse/uptime details); parsing uses same Little-Endian struct.unpack but offsets shift for V2+. V3.0.1 adds minor protocol stability (e.g., fewer dropped packets at high radon), but identical service/characteristic UUIDs across versions.

Handshake and Stability

  • Handshake: Identical—scan > connect > enable notifications on data characteristic; no custom handshake or keys; ESP32 proxy recommended for all to avoid Raspberry Pi BLE hangs.

  • V1: Prone to timeouts on long polls due to simpler firmware; partial rd200v2 support.

  • V2: Improved reliability, full notifications; handles concurrent app connections better.​

  • V3.0.1: Firmware optimizations reduce reconnects (e.g., bugfixes in high-load), but same procedure.

Comparison Table: BLE Aspects

Aspect V1 V2 V3.0.1
Advertising Name FR:R2:SNxxxx ​ FR:RU/RE/GI:SNxxxx ​ Same as V2 ​
Packet Size ~20 bytes ​ ~30+ bytes ​ ~30+ bytes ​
Connection Type BLE Notifications ​ BLE Notifications ​ BLE Notifications ​
Handshake Standard (no auth) ​ Standard ​ Standard ​
Stability/Proxy Need High (ESP32 req.) ​ Medium ​ Medium (optimized) ​
Python Parsing Offsets Basic (shifted) ​ Full ​ Full ​