Smart radon sensor

Thanks!

Of course I will share code. I tried to attach the PDF I used for reference but the forum considers me too new and will not allow me. I’ll see what I can come up with to show how it’s connected but for now here’s an excerpt from my RD200 helper class. Some of this is stolen directly from the PDF I wanted to attach and some of it is my own creation. This probably references a couple member variables that I forgot to include but if there’s anything more I can elaborate on let me know and I’ll do my best!

void RD200::Handle() {
  this->ProcessReceivedData();

  if ((millis() - this->lastRequestMillis) > this->pollInterval) {
    this->Request();
  }
}

void RD200::ProcessReceivedData() {
  int recSize = mySerial.available();
  if (recSize < 8) { return; }
  byte recData[8];
  int offset = recSize - 8;
  for (int i = 0; i < recSize; i++) {
    if (i < offset) {
      //skip everything before the final 8 bytes, it's garbage that accumulated in the buffer
      //NOTE: this has never actually happened because we purge the buffer in the request call, it's just paranoia
    } else {
      recData[i - offset] = (byte)this->mySerial.read();
    }
  }
  if (this->CheckSum(recData, 8) == false) {
    return;
  }
  this->lastResponseMillis = millis();
  this->outstandingRequest = false;
  this->currentState = recData[3];
  switch (this->currentState) {
    case 0x00:
      this->lastReading = -1.0f;
      break; // Power On ~ 200sec
    case 0x01:
      this->startupMinutesElapsed = recData[4];
      this->lastReading = -1.0f;
      break; // 200sec to 1hour
    case 0x10:
      // according to the guide this means:
      // Measuring time is within 30min and radon count is over 10
      // not really sure if that means less than 30 minutes or between 30 and 60
      this->startupMinutesElapsed = recData[4];
      this->lastReading = -1.0f;
      break;
    case 0x02:
      this->lastReading = ((recData[5] * 100) + recData[6]);
      break; // After 1hour
    case 0xE0:
      this->lastReading = -1.0f;
      break; // Detect vibrations
  }
}

bool RD200::CheckSum(byte data[], int data_size) {
  int sum = 0;
  for (int i = 1; i < data_size - 1; i++) {
    sum += data[i];
    sum %= 256;
  }
  if (255 - sum == data[data_size - 1]) return true;
  else return false;
}


void RD200::Init() {
  this->mySerial.begin(19200);
  byte period_time = (byte) min(max(this->measurementInterval, 0), 60);
  byte send_data[5] = {0x02, cmdRD200M_SEND_PERIOD_SET, 0x01, period_time, 0xFF - (cmdRD200M_SEND_PERIOD_SET + 0x01 + period_time)};
  this->mySerial.write(send_data, 5);
}

void RD200::ResetSensor() { // don't do this unless you really want to, it clears all measurement data and restarts the 1 hour timeout
  byte send_data[5] = {0x02, cmdRD200M_RESET, 0x00, 0xFF - (cmdRD200M_RESET)};
  this->mySerial.write(send_data, 5);
}

void RD200::SetMeasurementInterval(int intervalMinutes) { // to be called BEFORE Init() only
  this->measurementInterval = min(max(intervalMinutes, 0), 60);
}

void RD200::Request() {
  while (mySerial.available()) { // throw away anything that could be in the buffer
    mySerial.read();
  }
  byte send_data[4] = {0x02, cmdRD200M_RESULT_QUERY, 0x00, 0xFF - cmdRD200M_RESULT_QUERY};
  mySerial.write(send_data, 4);
  this->lastRequestMillis = millis();
  this->outstandingRequest = true;
}

Hi Chris,
Your project looks great, and very similar to what I started to do (also I wanted humidity and temp in my design). I see you kept the same regulator - be sure to add significant surface area for cooling, and also make sure to have the ESP to go into its deepest sleep mode (the one re-started with wup/reset, don’t remember the name of this mode).

Regarding the sticker - that is what happened to my first RD200 when I opened it. So much better to ‘drill’ teh hole through the plastic label (make sure the the screw head is fully open before you start unscrewing it, otherwise it will lift the plastic label, causing the same “effect” :slight_smile:

If I can help more, I’d like to, as I also meant to put my solution into opensource, but I got stuck too many times to be able to finish it properly, and now my devices are working.

Yes, I really got lucky when I had some sessions with some engineer over at FTLabs, but he cleared things up very much for me, since I originally intended to let the FTLabs board as is, just sneaking the serial wires also to my ESP. As I understood, the undocumented mode meant that the microcontroller within the chamber component did e.g. averaging work, so the BT module could concentrate on user interface/BT interface. Not sure why, this solution was selected though.

However, just using the serial protocol is fine, if the BT module is off the board. I actually did not encounter any issues at all with it, but I never managed to have the hardware serial ports on my ESP to work well. I spent sooo much time with this, that I got tired of the hole project. Basically I think I a bug in the ESP firmware or hardware. (Hardware developing has been my profession for about 30yrs, so I’m not totally clueless). In the end, I changed my design and code into using a software UART instead, to get away from the stability issues I saw.
So, if you after some random time looses comm’s with the RD200, you might want to put up your scope onto the rx/tx lines - you might see that the impedance of one of the lines gets into some kind of weird lower drive/higher impedance from the ESP, not giving the proper levels. For some reason the ‘random time’ where slightly different on different individuals.

Let’s see if I can find any of my schematics or code, maybe there’s something that can be useful for someone (it is untidy, but after all, my radon sensors has been running for over a year now, so at least proof of concept) :slight_smile:

I have been thinking about changing them into using homie protocol, but that probably won’t happen for a while, since I anyway have them all working now…

OK, so I found my code snippet;

/*
Radoneye RD200 serial to MQTT by Micael Beronius

Debug output on Mini D1 -> "D4"
The rd200 to be connected on "D7" (incoming from rd200) & "D8" (outgoing to rd200).

I had to use sw serial to RD200 to get long term stability, this was because the 
ESP went into some strange mode after a while on the rx pin. Not sure if this is
a hardware of fw bug in some of the lower layers, but any way a bug outside my scope.
Once this happened the RD200 where not able to emit proper levels to the ESP, since its 
tx drive is not very strong (and it should not need to be strong!).

The WAKE pin ("D0") must be connected to RST for wake up. No other change to the D1.
Remove link between "D0" and "RST" when uploading new firmware. 

Sometimes, a 10K pull-down resistor should be tied to D7, to bring down result from RD200.



*/

#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <SoftwareSerial.h>

#define CH_STX              0x02
#define RD200_REQUEST_DATA  0x01
#define RD200_RESET         0xA0
#define RD200_SET_PERIOD    0xA1
#define RD200_DATA_RESULT   0x10


/**
* Wifi & MQTT Settings
*/
const char* ssid = "xxxxxxxxx";
const char* password = "yyyyy";
const char* mqtt_server = "your broker server";

const unsigned char rd200_reset[4] =         { 0x02, 0xa0, 0x00, 0x5f };
const unsigned char rd200_set_dt_period[5] = { 0x02, 0xa1, 0x01, 0x0a, 0x53 };
const unsigned char rd200_read_all_data[4] = { 0x02, 0x01, 0x00, 0xfe };
const unsigned char rd200_test_result[8] =   { 0x02, 0x10, 0x04, 0x01, 0x1e, 0x02, 0x3a, 0x90 };

WiFiClient espClient;
PubSubClient client(espClient);
char msg[50];
char topic[50];

SoftwareSerial swSer(4, 5, false, 128 );
void rd200_write( void )
{
#if 0
    Serial.write(rd200_test_result, sizeof(rd200_test_result));  // Loop test by connecting tx->rx on mini D1.  This echoes back a proper rd200 result
#else
    swSer.write(rd200_read_all_data, sizeof(rd200_read_all_data));
#endif
}

static void  rd200_tx_rx(void )
{
    char msg[10];
    unsigned char ch_data[10];
    static int ch_count = 0;
    int ch;
    int no_answer, tries = 0;
    char str[24];

    // Send read all data request
    do {
        no_answer = 0;
        Serial1.println("Req data from RD200");        
        while (-1 != swSer.read() )        
            ;
        delay( 10 );
        rd200_write();
    
        // Wait for result ...
        while ( 0 >= swSer.available() && no_answer++ < 10 ) 
            delay(10);
    }
    while ( tries++ < 3 && no_answer >= 10 );

    if (no_answer >= 10 ) // rd200 is not answering. Give up.
    {
        Serial1.println("RD200 did not respond. Giving up!");
        return;
    }

    while (-1 != (ch = swSer.read() ))
    {
        sprintf( str, "rx: %02x count=%d", ch, ch_count );
        Serial1.println( str );
        switch (ch_count)
        {
            case 0:
                if (CH_STX == ch)
                    ch_count++;
                break;
            case 1:
                if (RD200_DATA_RESULT == ch)
                    ch_count++;
                else
                    ch_count = 0;
                break;
            case 2:
                if (0x04 == ch)  // Len is always 4, on result messages
                    ch_count++;
                else
                    ch_count = 0;
                break;
            case 3:
            case 4:
            case 5:
            case 6:
                ch_data[ch_count++-3] = ch;
                break;
            case 7:     // checksum
                if( ch == (0xff - (0x10+0x04+ch_data[0]+ch_data[1]+ch_data[2]+ch_data[3])))
                {
                    snprintf(msg, 10, "%d.%02d",ch_data[2],ch_data[3] );
                    Serial1.print("Got ");
                    Serial1.print(msg);
                    Serial1.println(" pCi/L from RD200");

                    client.publish(topic, msg);
                }
                else
                {
                    Serial1.println("bad checksum");
                }
                ch_count = 0;
                break;

            default:
                ch_count = 0;

        }
    }
    Serial1.println("leaving rd200 scan");
}


void setup()
{
    Serial.begin(19200);
    delay(100);
    Serial1.begin(115200);
    delay(100);
    swSer.begin(19200);
    
    setup_wifi();

    client.setServer(mqtt_server, 1883);
}
/**
* Connect to wifi
*/
void setup_wifi()
{
    WiFi.mode(WIFI_STA);  //set to not broadcast ssid

    delay(10);

    // We start by connecting to a WiFi network
    Serial1.println();
    Serial1.print("Connecting to ");
    Serial1.println(ssid);
    WiFi.begin(ssid, password);
    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial1.print(".");
    }
    Serial1.println("");
    Serial1.println("WiFi connected");
    Serial1.println("IP address: ");
    Serial1.println(WiFi.localIP());
}

void loop()
{
    char mac_string[16];
    unsigned char mac_array[10];
    while (!client.connected()) {
        Serial1.print("Attempting MQTT connection...");
        // Attempt to connect
        if (client.connect("ESP8266Client")) {
            Serial1.println("connected");
            client.loop();
        }else{
            delay(2000);
        }
    }

    WiFi.macAddress(mac_array);

    sprintf( mac_string, "%02x%02x%02x", mac_array[3],mac_array[4],mac_array[5] );
    snprintf( topic, 40, "/house/radon/radoneye%s", mac_string );

    rd200_tx_rx();
    delay(1000);

    client.disconnect();

    while (0) {
        delay(5000);
        Serial1.println( "Not going to sleep ..");
    }

    Serial1.println( "Going to sleep for 10 minutes, yawn!");

    //Sleep for 10 minutes, then wakeup and send data again
    ESP.deepSleep(600 * 1000000, WAKE_RF_DEFAULT);
}

Did not find my schematics, neither hand sketch or cad drawings. (Guess I need have a better filing system :slight_smile: )
But I did find a picture of one of my mini D1 boards; Note that the header needs a jumper when “live” - it is the wake-up.

The BT module is desoldererd along with the display and serial memory. Yellow and orange connects to the serial lines on the FTLabs PCB.

That’s a really bare-bones solution! Very functional but minimal!

I have not had any issues with the serial going weird on me but I am using software serial on pins GPIO 4 and 5 which maybe helps? I don’t recall the pinout of the d1 mini (I think that’s the board you are using?) but quickly googling for one it looks like you are using GPIO 13 and 15? You very likely already know this but GPIO 15 is a special purpose pin and could perhaps be part of what is causing your problem? I’d expect the d1 mini has some onboard passive components relating to that pin that could also complicate using it. Speaking of pinouts, I use 100 ohm resistors on the data lines in case the sender/receiver ever disagree and both try to drive the same line, and I have GPIO4 to pin 1 of the 4-pin sensor connector, GPIO5 to pin 2, then 3 is +12V and 4 is GNS.

Thanks for sharing your work as well! I’d be really curious to hear more about the undocumented serial modes. The thing that interests me the most would be seeing more commands. The documentation I have only gives a couple and I really expected there to be more!

Unfortunately for me I seem to have pushed my luck too far. I’m not sure what exactly I did but it would appear I killed my sensor. I last had it connected to my board about 2 months ago (like I said, this re-write is taking forever!) and last night I discovered my sensor now always returns 99.90 pCi/L. Suspecting the fault is with my code I connected the original unmodified board to it and after the normal 1 hour timeout it only shows “Err.” for the reading which is what I have seen it say when the sensor was over-range. Checking my other radon meter the levels in my house were only about 10-15 pCi/L at the time so I wasn’t actually over-range. My sensor is “working” because it is answering normally over serial but is just giving garbage readings. I suspect this is related to me delidding the sensor, something must have gotten damaged when I did that. I’m not sure if I physically damaged it while using a knife to cut the solder holding the lid on or whether it was EMI/RF/electrostatic damage. I did run it briefly with the lid off to investigate the onboard LED behaviour - perhaps that was my mistake. Well, my loss can be somebody else’s gain, here’s a picture from inside the sensor:

Sorry to hear about your broken unit, at least it did not cause the very troublesome smell/smoke that my second unit made when I destroyed it (also I did not know why it broke, I thought I was careful about it). I haven’t bothered to try to open it up, I suspect it takes some time to heat it enough to get the lid off?

I know about the multiple functions with the hw uart pins, I also tried to move the hw uart to its alternative location, but the same thing happened. Using sw uart solved all issues, I suspect if you are alredy using sw serial, this is why it was working fine for you!

I don’t know why you are interested in the undocumented protocol? It is not needed. I mean what else but the readout would you really want? They would not disclose it to me when i asked, and I could not make out what the undocumented messages meant. (I really tried! :slight_smile: The messages looks like this;

0x02 0x13 0x00 0xEC <- Query from Bluetooth module
0x02 0x13 0x08 0x10 0x00 0x00 0x00 0x02 0x00 0x06 0x00 0xCC <- Reply from RD200M  

This is the response I got regarding this some years ago;

“RD200M has two operation modes, RadonEye and Sensor mode. The RadonEye mode is used for the RD200 only, it is not open for users, sorry.”

The document you refer to, is this AN_RD200M_v1.1.pdf and/or datasheet_RD200M_v1.4.pdf ?

I was referencing the AN_RD200M_v1.1pdf, I did not know of this other datasheet!! I found v1.2 of the datasheet now but cannot locate v1.4. I wonder what the differences are?

As for more information I was hoping to get some identifying information from the sensor itself so I could track measurements per sensor not per ESP device, but also I was just curious what else there was because I like knowing things :slight_smile:

For delidding the sensor, I didn’t use heat as I didn’t know what was inside the can and did not want to risk damaging the internals, so I used a sharp knife to cut the solder in the joint repeatedly until the cover came off cleanly. I never stuck the knife beyond the metal can and in my opinion I was very gentle in doing the work - it took almost 30 minutes to cut through all the solder. I did handle the sensor a bit with the cover removed and I did power it up once to see what was up with the LED that I could just barely see underneath the edge of the metal can (which is what tempted me to open it in the first place). In my opinion I was extremely careful in handling the sensor but I suppose given it’s tenuous mounting to the metal can underneath I may have stressed the board at those mounting points, or perhaps some component on that board is extremely sensitive to ESD. I’m not sure if I will ever know… though, thinking about it now I might as well pull the metal lid off again and see if I can isolate the pulse signals that I see mentioned in the datasheet… maybe that will shed some light on where the failure is.

I do have a second (unmodified) RD200 sensor but since it is now my only one I won’t be opening it to continue this project. Hopefully I can find the failure with this one and carry on. If not, I’ll remove the 2 nuts found inside and see what secrets that unveils! Every failure can at least be a learning opportunity.

Hi, thanks for sharing.this help me a lot to clarify the sensor function.
… but I have only one sensor and now I am afraid to destroy it :wink:
By the way I found the data sheet even the 1.4 for RD200 (you can google datasheet_RD200_v1.4_eng.pdf, it is on the supplier web page and does not give any interesting data)

Following the datasheet it is probably better to connect the ESP directly to the sensor cable and provide a 12V output to the sensor itself why connecting directly the UART to a soft serial I/Os so you can use the ESP hardware serial RX/TX to USB in order to debugg in the PC.
The UART is already 3,3V baude rate 19200 so it seems not too difficult… I have just one sensor and probably it is time to order a RD200M.
What do you think?
Regards
Lorenzo

If you are careful, and you have some experience with soldering, you should be fine. Here’s what you should avoid;
When you runt the unit open, the main issue is that the chamber and screen is metal, and there’s therefore easy to short e.g. power wires/connectors to it, and afaict the chamber is loaded with a high-impedance hi-ish voltage, so you should avoid touching it. Best if you can have the sensor in the housing, maybe just put it in the housing, and securing the two housing parts with tape around it while you are experimenting, and have everything else outside.
In the end, it is worth it, since you’ll have great help getting rid of that radon gas.
If I’m doing this again, I will either finish off my PCB (or if someone else get’s it done before me, I’ll use that :slight_smile: ), or do it as I have done it on my current units. But it can perhaps be a bit more dificult to get rid of the components on the board if you don’t have the proper tools.

Good luck!

Hi guys

I wonder gow this went for those who planned to make this work as a project? Is there anything like instructions+code available on github?

I dont mind reading the data via Bluetooth interface. I do it already with my two Airthings waves but bot sure how to do it with rd200. Any help is appreciated.

/Bortek

@Bortek Thanks for reviving this thread, made me read through it again, and since today is my first day of holiday, I decided to use @ctrowat method to open up my damaged RD200 sensor. I can see that the High Voltage multiplier is the broken one (still smells like shit after 2 years!!). I might try and see if I can fix it - it should not be too difficult, but maybe the chamber is broken, and that is why the HV circuit got damaged. Anyway, for rainy days… :slight_smile:

To answer your question, no, I have not done anything in order to putting together a complete package, but maybe Chris has, after all, he came much further than I, with PCB’s and stuff.

However, the good thing with this, is that I have installed a suction pipe under my house during winter, that is controlled by a EC-fan+0-10V Qubino, so with the help of OH, and these sensors, I now have a very low radon level.

@vespaman and @Bortek thanks for posting back again!

Micael, would you be willing to share pictures of the parts that are broken? I doubt I could add anything useful I’m just curious what the failure mode is. Unfortunately for mine that died I don’t know enough about analog electronics to do much useful debugging and I have moved the sensor portion from my desk to my scrap heap for the next recycling run. It was a painful loss.

My plan to make it work was very ambitious (maybe TOO ambitious) but it went something like this:
I was going to use very high sensitivity differential pressure sensors distributed at 2-3 locations throughout my basement. They would monitor the sub-slab suction levels relative to the air pressure above the slab. I would use one of my modified RD200 sensors to monitor radon levels in my basement and when levels got high they would activate a smart plug which would turn on my radon fan. When turning on the radon fan they would use the differential pressure sensors to assert that the sub-slab suction is effective and that the pressure has been reduced across the slab. Also, during long periods where the radon fan has been operating (perhaps once per day) it would briefly shut off the radon fan and verify that the differential pressure readings return to zero (i.e. recalibrate the sensors to ensure they don’t drift over a long period of time). I was also planning on logging all values to Grafana or similar for integration with a home dashboard.

My intent was to find out whether increasing radon levels were correlated with increased sub-slab pressure (i.e. does the pressure under my slab spike before the radon levels do?), and to validate that the radon fan is being effective in decreasing the pressure across my entire slab. If the fan were not effective I could add an additional suction point or second fan to make sure it was then of course modify the above solution to operate in zones as necessary.

Like I said, it was ambitious… it would have been nice to at least finish the one sensor up though! I have been keeping an eye on the market for other radon sensors to see if I can still complete some of the other phases of the project so this isn’t totally dead yet, but other house renovations have gotten in the way and slowed progress (summer tends to be like that for me).

One more thing I noticed after killing the one radon sensor, is that the OLED display I selected for mine had suffered SIGNIFICANT burn-in over the couple months it was operating. I did buy literally the cheapest all-white ones I could find on AliExpress so maybe that’s my fault. I had some “current page” style indicators at the top which were always visible and those pixels are now about half as bright as the ones around them - the displays are basically ruined. I also see now that the blue/yellow ones in the actual RadonEye units have also suffered moderate burn-in but they have been operating for 2 years so maybe that’s expected.

Thanks for the update Chris!
Yes, it is easy to be carried away in too complicated set-ups :slight_smile: for sure, but also fun. With the renovation I did this winter (pulling the slab, changing water/sewer pipes, isolation), the result is phenomenal, the EC fan needs only to run at very low levels, and while there is a substantial delay before the RD200 above the slab detects increased levels, by keeping the preferred levels low enough the actual level is well within my comfort zone. Typically the EC suction fan are run between 30-40% speed, to sustain about 50bq, and goes up to 400-800bq before I added the fan. I also have a rule that allows higher average if it is really cold outside, but I have yet to see through winter before knowing how that works out.

The part that was the trouble in my broken unit was the little standing PCB, that transforms the 12V into something higher (called ‘HV’) on the board. While it did not rain here yesterday, I was curios enough to try to fix it. In your picture above, it is the one on top.
Unfortunately, I don’t know how high this is supposed to go, and it is very high impedance, so just adding my bench multimeter onto it pulls the voltage down. It starts at around 60V but goes down in a matter of seconds. But I think I read somewhere that it is supposed to be much higher.
If you have the opportunity to measure the ‘HV’ node (same as the two nuts holding the chamber), it would be great, because unfortunately, my unit is still not working - i get ‘ERR’ on the original display after the 10minute sampling, so I’m guessing the readouts are not stable. Best use a scope, if you have one.
I suspect my HV-node is still not good/stable enough, but since I don’t have the values on the caps on the HV board, I can’t continue fault finding.

When I got the errror message I soldered the cover on again, to see if it could be external interference, (which it wasn’t). I’ll take the hat off again, to measure the HV node with my scope to see better the characteristics of it (I don’t know why I didn’t before soldering the hat on again… not too clever!).

Also, there’s a green LED blinking on my board constantly - do you have that when you are powering up your board? I suppose this is to indicate that the mcu is running.

Yes, OLEDS are suffering from burn in, and also I think aging (at least the first OLEDS did, after all, it is organic), so probably using a unknown-quality OLED from aliexpress may have this problem.

Hi guys. Thanks for sharing your experience! Your solutions sound interesting and are quite advanced. I realize now that I have kind of missed the opportunity to install the suction pipe under the slab when I was isolating the house ground and changing drainage system past winter. Going through the digging process again is not a good prospect for me :slight_smile:

My idea was (and still is) to improve the overall ventilation in the house which is basically non existent today. In order to do that I have installed a roof fan that pumps the air out of the house through the bathroom (there are air intakes dining/bedrooms). It has lowered radon level to some extend. I plan to do the same in the basement. Keeping the balance here is critical as it might start sucking the radon thus making things worse.

I have now 4 Airhtings Wave , two on each floor, to monitor the radon levels. They are very easy to poll via BT using python scripts running on Pi. I then send the data to Influx and view them i Grafana.

I wonder if there is a way to find the source where the radon is leaking into the house. Equipped with a sensitive alpha geiger tube it should be possible to find the points where radon is leaking in and seal them off. Just an idea.

Well, it may also be that the materials in the building contributes, so sometimes not so easy, since it might not be one single source. Also, at least in older houses, there are 1 milion places where small doses can enter, all it takes is a invisible crack in the slab. In my case, before I opened up/isolated the slab, I had an old report from early 90s (in which they used geiger counters) of my house, stating one part of the building (built in the 50s) had a material that emitted some, but overall most from ground. I tried to close off the bottom floor (closing doors, taping tight) and put the 3 RD200’s in different location, keeping one on the same spot as a reference, for about a week each ‘test’. While it did not give the full answer, at least it gave me one major source, where the pipes entered/left the building, which had a rinse hatch. I think, if you are venting away the gas, it might be best to have the suction low, as I think radon is heavier than the normal air. You should use a balanced system and be careful like you say, not to suck more radon in, but also not push humid air out. But I’m sure you know all this.

I can fully understand not wanting to rip up the slab :smile: I hear a lot of people has had good luck with a radon suction “hole” beside the house (not sure about the English term) though.

Anyone tried to collect Radon realtime info from RD200 using bluetooth without oficial app?

Like using bluepy to collect data, like on Airthings Wave ?

Or something like:



There’s my python tool to read current radon value from RD200 using Bluetooth LE.

2 Likes

For completness sake, I have worked on a Bluetooth sub binding that supports the RadonEye directly [BLE] Add support for RadonEye (BLE) device by petero-dk · Pull Request #11958 · openhab/openhab-addons · GitHub - it is almost done. I have not gotten the autodetect to work just yet, but adding the RadonEye manually works.

1 Like

Hi @petero

I am struggling to manually add the RD200. Not sure I am getting the right Bluetooth address, I am using the one that appears on the physycal label below the device, although I am afraid that must be the Serial Number (still 12 characters).
On the Android app, when phone connected I do not manage to see any place where to check the bluetotth MAC adress.

Autodiscovery does not seem to find the device, located 20 cms from the rPI

Any help will be much appreciated
Thanks in advance!