GDK101 is an I2C based device, and as such it is supported in GeigerLog, and also on a Raspi (in a separate software package, but part of the full GeigerLog package). It works. But in my opinion it is not worth any effort! Sensitivity is way too low.
For reviews look into my Article folder (https://sourceforge.net/projects/geigerlog/files/Articles/) for articles about PIN-Diodes:
* GeigerLog-Review PIN Diode Geiger Counters-v.1.0.pdf
* GeigerLog-Review Smart Geiger Pro (SGP-001)-v.1.0.pdf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm also planning create real geiger tube IOT setup, but since my Chinese kit not working with my surplus tube, and I haven't fond time to trace the issue yet the GDK101 is first choice for me, but definitely I will try to setup geiger tube with esp MCU either.
Last edit: Adam Szewczyk 2025-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will not spend time in putting GDK101 into a Tasmota system. It's an interesting technical thing, but it's not worth using it for serious purposes.
However, since I have the GDK already in GeigerLog, I would put it in as a Tasmota device, if you provide the required info. Which is: the command to send to Tasmta to send data, and Tasmota's answer to this request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is what exactly I'm asking for. The support for the GDK101 is already inside the Tasmota (see provided github link). I worked on that few years ago (there was some old unmerged PR, so I updated it and was able to make it finally merged, then I also contributed that sensor for esphome project). I will check how the communication with that device work in a free time, and get back to you, but as far as I remember it just sending all the measurement every TelePeriod. It also should send the measurements after receiving status 10 cmd. If some improvements would be needed in the Tasmota code I could work on that.
Last edit: Adam Szewczyk 2025-11-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending cmnd/<device-topic>/Status 10 Tasmota will also send data but not to the telemetry topic but to stat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that:
Also I think that If geigerlog handle gdk101 as Tasmota device I can emulate it in the Home Assistant automation and use my esphome device the same way.
Last edit: Adam Szewczyk 2025-11-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If this is the answer to a "status 10" command, it is really easy to implement. Do you actually have a Tasmota device with GDK101 in hand, or is this theoretical planning?
I am very concerned about about using MQTT via free MQTT servers! I got burned myself, because there are scammers out there, who interfere with your commands and insert damaging code into the returns! I advise STRONGLY against such free servers!
So you either need to rent MQTT access, or run your own MQTT servers. This complicates such actions (and makes them costly). I now much prefer the http appraoch on Tasmota. It is simpler and faster and works well as long as you devices are within reach of your home WiFi.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have it. Yesterday I reflashed my device with Tasmota firmware (unfortunately they don't merge it into default tasmota-sensor.bin build so I have to enable the sensor and build it myself). I have also doubts about using public brokers, but setting up a a local broker is not such hard task. You could do it for development purposes on your daily driver. Just install mosquitto and mosquitto-clients using packages manager. And then use simplest config for use it in local network. For me it is a bit harder since my daily driver using NAT for everything, but I just need some time to set it up on some raspi or other temporary server. Unfortunately I wouldn't have much free time for 2-3 weeks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is really behind the use of MQTT? I understand that it is good when you have transkontinental data transfer, But when you have to setup a local mosquitto server, it defeats the need for mqtt, because you are in a local - probably wifi - setting anyway, and there is no need for mqtt!
It can be done without setting up a local server, no matter how easy it might be, by using the http method. Easy to understand, no need for setup, because all you need is a browser.
And it is faster and easier to program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I'm back. I was have finally some free time to setup test environment and answer you.
Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks.
As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine,
You can use this guide as reference.
I configured it to allow anonymous connections and install mosquitto-client. Then I setup tasmota device to connect to this broker. Finally I send the command to a tasmota device from the client from the terminal: mosquitto_pub -h localhost -p 1883 -t "cmnd/tasmota_E496E7/Status" -m "10"
while in other terminal i subscribe to a topic with answers: mosquitto_sub -h localhost -p 1883 -t "stat/tasmota_E496E7/STATUS10"
and i got: {"StatusSNS":{"Time":"2025-12-21T11:50:43","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.08,"RadiationAvg1Min":0.24,"Status":2,"Vibration":0,"Measurement":"0T00:18:05"}}}
Last edit: Adam Szewczyk 2025-12-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The usage of IOT over MQTT, and the setting up of a mosquitto server is well described in the GeigerLog manual, take a look.
However, if the world-wide scale is NOT needed by the user, having to do all this server setup is just an inconvenience to the user. For use within the local WiFi, HTTP and a browser is enough.
You may be interested in a new feature coming up in GeigerLog. GL can convert a regular Tasmota on an ESP32 to a "Tasmota Geiger Counter". See the discussion page (in German): GeigerLog's new Tasmota Geiger Counter
Last edit: ullix 6 days ago
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you have the GDK hardware at hand, you can try it with the latest Devel GeigerLog:
Put this next config into file custom.cfg and replace the IP 10.0.0.199 with that of your ESP32.
I just tested it. There is a bug that stop the geigerlog from connect to a sensor. Code for wifiserver GDK101 not setting success variable. After adding it, it can connect and get the data.
As for the geiger counter with tasmota I will be interested but first I have to find out why my HW not working. Will it be OK for you if I start another topic and ask for help to figure it out?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the bug report. But things are changing quickly here, will let you know.
So, can you do a long(er) term recording with the current GTK101 system?
A different question should go on a different topic.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since there is a GDK101 in Tasmota it will be great if it will be supported as IOT device out of the box. https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xsns_sensor/xsns_106_gdk101.ino
Not sure what exactly you are asking for.
GDK101 is an I2C based device, and as such it is supported in GeigerLog, and also on a Raspi (in a separate software package, but part of the full GeigerLog package). It works. But in my opinion it is not worth any effort! Sensitivity is way too low.
For reviews look into my Article folder (https://sourceforge.net/projects/geigerlog/files/Articles/) for articles about PIN-Diodes:
* GeigerLog-Review PIN Diode Geiger Counters-v.1.0.pdf
* GeigerLog-Review Smart Geiger Pro (SGP-001)-v.1.0.pdf
I'm asking for supporting it over Tasmota. So GDK101 is interfaced by some ESP or other Tasmota supported MCU, and Geigerlog read the data over MQTT.
Device like that that put somewhere and geigerlog in container on home automation server.
Last edit: Adam Szewczyk 2025-11-28
I'm also planning create real geiger tube IOT setup, but since my Chinese kit not working with my surplus tube, and I haven't fond time to trace the issue yet the GDK101 is first choice for me, but definitely I will try to setup geiger tube with esp MCU either.
Last edit: Adam Szewczyk 2025-11-28
I will not spend time in putting GDK101 into a Tasmota system. It's an interesting technical thing, but it's not worth using it for serious purposes.
However, since I have the GDK already in GeigerLog, I would put it in as a Tasmota device, if you provide the required info. Which is: the command to send to Tasmta to send data, and Tasmota's answer to this request.
That is what exactly I'm asking for. The support for the GDK101 is already inside the Tasmota (see provided github link). I worked on that few years ago (there was some old unmerged PR, so I updated it and was able to make it finally merged, then I also contributed that sensor for esphome project). I will check how the communication with that device work in a free time, and get back to you, but as far as I remember it just sending all the measurement every TelePeriod. It also should send the measurements after receiving status 10 cmd. If some improvements would be needed in the Tasmota code I could work on that.
Last edit: Adam Szewczyk 2025-11-29
Ok, I looked into the code and read basics about how Tasmota sends data (before I just add it to the broker and let Home Assistant do the parsing for me). So, measurements are read from the sensor every 10s. Then every TelePeriod they will be send to telemetry topic. After sending
cmnd/<device-topic>/Status 10Tasmota will also send data but not to the telemetry topic but tostat/<device-topic>/STATUS10. Data will be available inside StatusSNS field and according to code should look like that:"Measurement" is the time from the sensor.
Last edit: Adam Szewczyk 2025-11-29
Also I think that If geigerlog handle gdk101 as Tasmota device I can emulate it in the Home Assistant automation and use my esphome device the same way.
Last edit: Adam Szewczyk 2025-11-29
This is the real json from the log console:
I will setup some mosquito broker in the free time and check topics and full messages.
it is published periodically and can be triggered with the command.
Last edit: Adam Szewczyk 2025-11-29
If this is the answer to a "status 10" command, it is really easy to implement. Do you actually have a Tasmota device with GDK101 in hand, or is this theoretical planning?
I am very concerned about about using MQTT via free MQTT servers! I got burned myself, because there are scammers out there, who interfere with your commands and insert damaging code into the returns! I advise STRONGLY against such free servers!
So you either need to rent MQTT access, or run your own MQTT servers. This complicates such actions (and makes them costly). I now much prefer the http appraoch on Tasmota. It is simpler and faster and works well as long as you devices are within reach of your home WiFi.
I have it. Yesterday I reflashed my device with Tasmota firmware (unfortunately they don't merge it into default tasmota-sensor.bin build so I have to enable the sensor and build it myself). I have also doubts about using public brokers, but setting up a a local broker is not such hard task. You could do it for development purposes on your daily driver. Just install mosquitto and mosquitto-clients using packages manager. And then use simplest config for use it in local network. For me it is a bit harder since my daily driver using NAT for everything, but I just need some time to set it up on some raspi or other temporary server. Unfortunately I wouldn't have much free time for 2-3 weeks.
What is really behind the use of MQTT? I understand that it is good when you have transkontinental data transfer, But when you have to setup a local mosquitto server, it defeats the need for mqtt, because you are in a local - probably wifi - setting anyway, and there is no need for mqtt!
It can be done without setting up a local server, no matter how easy it might be, by using the http method. Easy to understand, no need for setup, because all you need is a browser.
And it is faster and easier to program.
Ok, I'm back. I was have finally some free time to setup test environment and answer you.
Why MQTT? It is currently a standard in IOT and Home Automation. It is fast, lightweight, can be secured and is more reliable then http. If someone have some Home Automation server (like Home Assistant or similar) it probably have MQTT broker already installed, or can be setup in few clicks.
As my test setup I deploy a docker container with mosquitto-broker on my daily driver machine,
You can use this guide as reference.
I configured it to allow anonymous connections and install mosquitto-client. Then I setup tasmota device to connect to this broker. Finally I send the command to a tasmota device from the client from the terminal:
mosquitto_pub -h localhost -p 1883 -t "cmnd/tasmota_E496E7/Status" -m "10"while in other terminal i subscribe to a topic with answers:
mosquitto_sub -h localhost -p 1883 -t "stat/tasmota_E496E7/STATUS10"and i got:
{"StatusSNS":{"Time":"2025-12-21T11:50:43","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.08,"RadiationAvg1Min":0.24,"Status":2,"Vibration":0,"Measurement":"0T00:18:05"}}}Last edit: Adam Szewczyk 2025-12-21
For testing purposes you can use such mosquitto.conf:
this will allow you to ignore user/password settings.
Last edit: Adam Szewczyk 2025-12-21
And since for MQTT you don't need to poll for data you can just subscribe to telemetry topic and wait when device itself send them:
mosquitto_sub -h localhost -p 1883 -t "tele/tasmota_E496E7/SENSOR"{"Time":"2025-12-21T13:03:50","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:08"}}Last edit: Adam Szewczyk 7 days ago
Over http you need to use:
http://<ip>/cm?cmnd=Status%2010and respons will lokk like this:{"StatusSNS":{"Time":"2025-12-21T21:57:21","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.09,"RadiationAvg1Min":0.12,"Status":1,"Vibration":0,"Measurement":"0T00:05:31"}}}Last edit: Adam Szewczyk 7 days ago
The usage of IOT over MQTT, and the setting up of a mosquitto server is well described in the GeigerLog manual, take a look.
However, if the world-wide scale is NOT needed by the user, having to do all this server setup is just an inconvenience to the user. For use within the local WiFi, HTTP and a browser is enough.
You may be interested in a new feature coming up in GeigerLog. GL can convert a regular Tasmota on an ESP32 to a "Tasmota Geiger Counter". See the discussion page (in German):
GeigerLog's new Tasmota Geiger Counter
Last edit: ullix 6 days ago
You may be interested in this Tasmota-Geiger-Counter pre-release of GeigerLog:
GeigerLog Version 2.2pre01
https://sourceforge.net/p/geigerlog/discussion/devel2/
If you have the GDK hardware at hand, you can try it with the latest Devel GeigerLog:
Put this next config into file
custom.cfgand replace the IP 10.0.0.199 with that of your ESP32.Please report the outcome.
I just tested it. There is a bug that stop the geigerlog from connect to a sensor. Code for wifiserver GDK101 not setting
successvariable. After adding it, it can connect and get the data.As for the geiger counter with tasmota I will be interested but first I have to find out why my HW not working. Will it be OK for you if I start another topic and ask for help to figure it out?
BTW. There is a project in which someone bypassed MCU in hdk101 and getting the data from the diodes.
Last edit: Adam Szewczyk 2 days ago
Thanks for the bug report. But things are changing quickly here, will let you know.
So, can you do a long(er) term recording with the current GTK101 system?
A different question should go on a different topic.