Dosimeter module RadSens I2C support required

[Vladimir-by]

ClimateGuard offers ready-made solutions for environmental monitoring with RadSens and RadSens Mini radiation sensors. Please add this module for I2C operation as part of the ESPEasy firmware.
Links to the ClimateGuard project:
https://climateguard.info/
https://github.com/climateguard/RadSens/
https://climateguard.info/radsens/
https://climateguard.info/radsens_mini/

[TD-er]

And what would be the best way to test these?
Just asking "for a friend" ;)

[Vladimir-by]

Dear friend, we will check it under normal environmental operating conditions. We won’t go to the nuclear power plant :))

[TD-er]

I recently bought one of those things from Ali (not with a tube like this, which is probably more sensitive to alpha radiation)
And I was surprised how few radioactive stuff I have.

I don't have any old (greenish coloured) lenses, no 50's red pottery or any old smoke detector.
The old pieces of kitchen table top with black stripes in them I use as support for my 3D printers also don't emit any measurable radiation.

I did order a few of those "magic amulet" thingy which claim to stop radiation and those are for sure as harmful as you wouldn't dare to think.
The actual radiation is about 4x-5x the base radiation level, so isn't that high.
But it sure is dangerous if you keep it always at the same place on your body or even worse if you break it and inhail some of its dust.

So when adding support for this, I will also add some detailed info on this topic as it for sure needs some warnings on how to use it responsible.

[Vladimir-by]

The RadSens sensor will be included in the weather station for round-the-clock environmental monitoring. At the moment, the ESPEasy firmware with pulse counting is used. A Chinese Geiger counter J305 (similar to M4011) is used. Measurement interval 600 seconds, conversion %value%*100/1510. I wanted to switch to a more modern RadSens module with an I2C bus connection.
The RadSens module will be of interest to many project participants as part of the ESPEasy firmware, as a modern option and a replacement for outdated models.
https://mysku.club/blog/china-stores/78189.html

[TD-er]

Just to get an idea of what this I2C version is doing...
What kind of data does it collect?
I always got the impression such meters are merely a pulse counter.

[Vladimir-by]

The RadSens module has its own microcontroller STМ32, which counts pulses and transmits the finished result via the I2C bus

[Vladimir-by]

It would be better, of course, if the developer participates in the forum (I wrote to the ClimateGuard team). Based on the sources, there should be at least three values from RadSens
https://github.com/climateguard/RadSens/blob/master/examples/I2C_rad_test/I2C_rad_test.ino

1. Returns dynamic radiation intensity (recommended if measurement period T < 123 sec)
2. Returns static radiation intensity (recommended if measurement period T = 500 sec)
3. Returns the accumulated number of pulses registered by the module since the last I2C data reading

[TD-er]

I don't think what they're selling is too expensive, absolutely not as the parts alone will cost you at least 35-ish euro.
But I don't think you will be getting any better or worse readings compared to just counting pulses yourself.
So if someone is considering building a dosimeter, this might be a good option to start. (no idea what shipping of the units will add to the costs)

Only main advantage (apart from the relative small size) is that the counter can continue to count when the ESP is in deep sleep for example.
I don't know how much current you need to run a geiger counter, so no idea if it even makes sense to try running it on batteries for a long time.

[tonhuisman]

I don't know how much current you need to run a geiger counter, so no idea if it even makes sense to try running it on batteries for a long time.

The website claims it uses max. 50 mA, but it doesn't state if that's with the tube included/installed, as it also claims that for the modules without a tube.

[Vladimir-by]

In my case, the rectified voltage will constantly be supplied to the RadSens module and the weather station as a whole. The transition to backup power is carried out from a 18650 lithium battery when the main one is unavailable.

[tonhuisman]

I have reserved P163 as the plugin ID for this sensor.

[chemmex]

The website claims it uses max. 50 mA, but it doesn't state if that's with the tube included/installed, as it also claims that for the modules without a tube.

The tube itself does not add much to the consumption under normal ambient conditions (assuming you are not in Chernobyl forest), so those 50 mA seem quite realistic for the simple mcu controlled HV power stage. However, best example I had consumed just ~20 uA without load, so there's much space for improvement.
Basically, the idea of always on low power pulse counter makes sence, I even have a prototype based on MSP430, it can count pulses from the Geiger tube in LPM3 (RTC clock enabled) mode consuming roughly just ~1 uA and periodically write the data into FRAM. It can then wake up the ESP and send bulk data to the broker, just as the cache reader plugin does.

[Vladimir-by]

Dear developers, I understand how busy you are in developing the project and maintaining the stability of its work. But can I ask about the RadSens plugin, how soon can we expect support in ESPEasy?

[TD-er]

Well the past 2.5 months I have been 100% busy implementing support for ESP-IDF5.1 and adding support for ESP32-C2 and -C6 and IPv6 so we can soon add support for Matter.
I have not even ordered this board for implementing support for it, so there is no ETA of when it will be implemented.

[Vladimir-by]

Thank you, I understand, if necessary, I can test RadSens remotely on the created versions of ESPEasy

[tonhuisman]

@Vladimir-by I've created a new plugin in PR #5104, and a GH Actions run is working on the build.
I don't own such RadSens device, so I hope you're available for testing. At the moment, only available in the ESP32 Collection G builds (4 MB units) and MAX builds (requires 8 MB or 16 MB ESP32, ESP32-s3 or ESP32-c6 unit), but I'm working on a solution to make it available for ESP8266 4MB builds and ESP32 4MB builds too. For ESP8266 builds, a Custom build has to be created, as documented here.

Edit2: Updated GH Actions run.

[tonhuisman]

We decided to not add this plugin in any default build for ESP8266, as that platform is practically feature-frozen for ESPEasy.
For those that need an ESP8266 build, a Custom build can be created, as documented here (start at the top for setting things up properly, and continue until you reach the chapter where a custom build using Custom.h is described).

For ESP32 this plugin is, besides the MAX builds, also available in the Collection G builds.

[TD-er]

And just to explain why we consider ESP8266 as 'feature frozen'...
I have spent many hundreds of hours in the last few years to make ESPEasy fit again on ESP8266 builds.
It just takes too much time which cannot be spent on new features, bugfixes, etc.
Espressif called ESP8266 "End-of-life" years ago and we will still make sure stuff can be built on ESP8266, but just not include it in 'collection' or 'display' builds anymore.

Some features may not be made to work on the ESP8266 anymore, like encryption or other feature which simply take up too much memory the ESP8266 simply does not have.

[chemmex]

Perhaps it's time to announce a strategy for ESP8266, set it aside with current features and move ahead with ESP32 family?

[bubastic]

I do not understand in which assembly to look for plugin 0163?

[tonhuisman]

You can use an ESP32 Collection G build for 4MB Flash units, or an ESP32 MAX build for 8MB and 16 MB Flash units. For ESP8266 you'll need to create a Custom build (compile yourself, from source...).

[TD-er]

Perhaps it's time to announce a strategy for ESP8266, set it aside with current features and move ahead with ESP32 family?

Yep, that's what I was thinking about.
Nearly everything we add causes ESP8266 builds to fail, so we really need to make a final decision on what to do with the ESP8266.

[tonhuisman]

Made some improvements to the plugin, to use the Count-average (when available) for checking the threshold. A GH Actions run is available here.

[bubastic]

Friends, I have a problem when using this plugin.
When I check the Stats checkbox and click Submit, the web interface hangs. F5 doesn't help, the interface still hangs. If I press the back button in the browser and remove the CheckBox, everything starts working fine.

[tonhuisman]

I guess you're using an ESP8266, I haven't tested that (yet), might have memory capacity issues. Can you test on an ESP32?

Edit: To get more detailed info, you can check the log while the page is submitted (extra tab on your browser on the Tools/Log page, or via an USB port on your computer, using some (serial)terminal software).

[bubastic]

I guess you're using an ESP8266, I haven't tested that (yet), might have memory capacity issues. Can you test on an ESP32?

No, I'm not using an ESP8266, I'm using a

ESP Chip Frequency: | 240 [MHz]
ESP Crystal Frequency: | 40 [MHz]
ESP APB Frequency: | 80 [MHz]
ESP Chip Model: | ESP32-D0WDQ5-V3
ESP Chip Features: | Wi-Fi bgn / BLE
ESP Chip Revision: | 3.0
ESP Chip Cores: | 2
ESP Board Name: | Espressif Generic ESP32 4M Flash ESPEasy 1810k Code/OTA 316k FS
Flash Chip ID: | Vendor: 0x68 Device: 0x4017
Flash Chip Real Size: | 8192 [kB]
Flash IDE Size: | 8192 [kB]
Flash Chip Speed: | 80 [MHz]
Flash IDE Speed: | 80 [MHz]

and yes, I also noticed that when setting CheckBox Status, if you wait VERY long, the interface comes to life, but in the dev list the Enable dev is false.

[tonhuisman]

Not sure why you have multiple restarts of the unit.
Maybe the power supply is instable under load or the voltage a bit low (should really be 5V on the 5V pin for an ESP32 Classic, better even 5.1 or 5.2V). Adding an extra 100 to 470 uF electrolytic capacitor close to the 5V and GND of the ESP could help here (watch the polarity!).
When the ESP is on a breadboard, then thicker wires should be used for powering the device, as the regular 'Chinese' patch wires are often very thin, and work more like resistors, instead of conductors, causing all kinds of issues.

[bubastic]

Thank you, I understand, if necessary, I can test RadSens remotely on the created versions of ESPEasy

@Vladimir-by, try to confirm or deny this error please (see my video)

[bubastic]

Not sure why you have multiple restarts of the unit.

@tonhuisman Couldn't attach the video, it's large. I sent taskenable,5 and after that every time ESP went soft reboot

If you don't set the STAT flag, there is no problem and everything works GREAT

1 minute later....
oopssss, I set the STAT flag for Count and no problem, everything works fast.

5 min. latter......,..,
If it's important,
I am using P2P and there on the head ESP32 (Build: ESP_Easy_mega_20240812_max_ESP32_16M1M Aug 12 2024) I am collecting RadSens data. I check the STAT boxes and see no problems, it works fast and graphs.

[TD-er]

Ton already found the issue, new build is pending :)
It was for sure a bug in de code and glad you found it while testing.

[tonhuisman]

I've found a small code issue, that I have now fixed 😅. Build should be ready in ca. 40 minutes from this Actions run

[bubastic]

I'm glad I was able to be helpful.

I have another question, I did not find the data entry field setting “A command for configuring the sensitivity to adjust calibration for a different type of Geiger tube (impulses per microrad).”. Mentioned here https://github.com/letscontrolit/ESPEasy/pull/5104

[tonhuisman]

That command is to be sent via http, serial or Rules, and is documented in this file in the PR. This will be available in the ESPEasy ReadTheDocs once the PR is merged into mega.

Here's a screenshot of how the Commands section will look like in the docs:

[bubastic]

I updated, checked, and the problem disappeared

[bubastic]

Another question has arisen.
Does the documentation state that the Count should be reset when the reading is taken? But I see that it is incriminated before restarting the ESP.

I checked with the manufacturer and he replied in the affirmative, “Unless this software (ESPeasy) accumulates them, but the board itself should not accumulate them.”

:-(

[tonhuisman]

All values are read from the counter using the available library functions, and presented as received, overwriting previous values in ESPEasy. No autonomous counting or addition is done by ESPEasy on the values.
AFAICS, there is no way of resetting the values, at least not via the RadSens library.

The only 'special' handling is calculating the average value of counts for use as the trigger-delta to smoothen the sensitivity, but that's not stored other than in memory, and can also be seen in a graph when re-opening the Device configuration for the active sensor.

[tonhuisman]

On further investigation, the RadSens library does increment it's count value, without ever resetting it.
And as the sources for that library haven't changed in over a year, I would expect that this is the intended behavior 🤔.

If resetting the count after each read is the desired behavior, I can add that to the library, and also make it optional in ESPEasy, to either fetch the accumulated count like it is now, or get and reset the last available count.

[TD-er]

Rather not try to 'write' it to the sensor.
It is easier to just keep track of the latest value and just show the difference.
However it is probably best to have an ever increasing value as it will tell you about the total radiation exposure which is important for health issue.

[bubastic]

I wonder if I'll write to the manufacturers, since they insist it should reset.

[tonhuisman]

I wonder if I'll write to the manufacturers, since they insist it should reset.

Most likely they are talking about the counter, and not the library. So we're both right 😆

I'll fix the library (and make a PR there for my fixes), and add extra options to the plugin, just hang in there for a bit...

[tonhuisman]

@bubastic I've added the requested features to the plugin, a new build is in this Actions run

[bubastic]

Build: [ESP_Easy_mega_20240822_max_ESP32_16M1M Aug 22 2024]

I was sure MAX included it.

[TD-er]

Which build did you try?
This Dosimeter plugin is not yet finished and thus not merged into the main branch.

This build should have it...
https://github.com/letscontrolit/ESPEasy/actions/runs/10523288609

[bubastic]

@bubastic I've added the requested features to the plugin, a new build is in this Actions run

I have received indirect confirmation that the meter does not reset when Count is read, contrary to the technical documentation, and some users confirm this information. I also see that you have made a change to the plugin. Thank you.

[bubastic]

Which build did you try? This Dosimeter plugin is not yet finished and thus not merged into the main branch.

This build should have it... https://github.com/letscontrolit/ESPEasy/actions/runs/10523288609

Was sure it was included in the release 22 aug. :-)

[tonhuisman]

I have received indirect confirmation that the meter does not reset when Count is read, contrary to the technical documentation, and some users confirm this information. I also see that you have made a change to the plugin. Thank you.

Hm, as I don't own such counter, and currently don't intend to order one, I can't test this myself, so have to depend on you (and others if & when available) for actual testing. And you have done a great job so far 😃.
Hope you can confirm that my latest adjustments return the expected results. The main issue, of always incrementing the pulse counter with new pulses, was in the RadSens library, that I corrected and made a PR for at their Github repo.

[bubastic]

after updating the latest firmware,
to display the data correctly, I had to remove and re-add the device, otherwise I saw strange values. iStat was partially duplicated with Count. After deleting/adding it, everything seemed to become normal

[tonhuisman]

I had to remove and re-add the device,

That's the price you pay for living on the edge... 🤣

[tonhuisman]

My fixes have been merged in the RadSens library, so that's sort of a success 😃

[TD-er]

That's extremely quick.
What kind of hyper active maintainers do they have over there?

[bubastic]

My fixes have been merged in the RadSens library, so that's sort of a success 😃

yeah, that's right. And I want to point out that this is after a very long period of silence and the manufacturer's unwillingness to address this problem. Yesterday he wrote that he had made changes to the library

[bubastic]

That's extremely quick.
What kind of hyper active maintainers do they have over there?

It didn't happen quickly, it turned out that everyone didn't like it, everyone wrote a lot about it, but the wagon stood still.
But when the right people are on board, everything is solved. :-)

[Vladimir-by]

Colleagues, I’m joining in testing the plugin [P163] Environment - RadSens I2C radiation counter. There was no opportunity before, I was away.

[Vladimir-by]

Thank you, I read the forum thread, the main errors in the firmware and pulse counting have already been corrected. Testing takes place on the platform ESP32-WROVER-B T18_3.0 + 18650 battery, RadSens Board ver-2v7 + Geiger tube SBM20, firmware ESP_Easy_mega_20240823_collection_G_ESP32_4M316k

[Vladimir-by]

I am steadily receiving data from the RadSens ver-2v7 board; if additional errors are found, I will write.