GeigerLog Activity
Python program for Geiger counters and Environmental Sensors
Brought to you by:
ullix
Activity for GeigerLog
-
geigermän posted a comment on discussion General Discussion
I tried to, where is this manual?
-
ullix posted a comment on discussion General Discussion
Consider looking into the manual.
-
Hello everyone, I hope you're doing well! I recently downloaded GeigerLog, but I've noticed there isn’t a README file included. I'm a bit unsure how to get it up and running on Windows 10. Could anyone kindly provide some guidance on the installation process or any necessary steps? I'd really appreciate your help! Thank you!
-
I re-did all the wiring, and checked again: VPP was 3.8V. Vmin=-0.2V, Vmax=+3.6V. This is borderline! I then soldered a wire on the tiny output-pad of the GDK101, and with some sweat on my forehead I made the connection. The ESP32 survived. Phewwww! I got some interesting data. My ESP32 is a plain ESP32-D0WD-V3 v3.0. The TASMOTA is the latest generic code (which does not support a GDK101!). All other stuff is my own Berry code, added to the Tasmota. I can now do Geiger Counter by counting pulses,...
-
Adam Szewczyk modified a comment on discussion Feature Request
According to gdk101 datasheet "Internal supply voltage, Vdd is 3.3V by two LDO, for analog and digital part." IN_PUL test point seems directly connected to MCU which is stm32f030k6. It looks like it is PA0 pin which is TTa pin (so not 5V tolerant) and it's absolute maximal rating in that case should be 4.0V. Are you sure about that measurement?
-
According to gdk101 datasheet "Internal supply voltage, Vdd is 3.3V by two LDO, for analog and digital part." and that (IN_PUL) test point is directly connected to MCU which is stm32f030k6. It looks like it is PA0 pin which is TTa pin (so not 5V tolerant) and it's absolute maximal rating in that case should be 4.0V. Are you sure about that measurement?
-
Can't hurt. That pulse output is tiny pad! Just checked it with an osci: VPP is 4.1V! The ESP32 will not like this! It wants 3.3V, and no more than 3.6 V!!!
-
Can't hurt. That pulse output is tiny pad!
-
So maybe we should try also the approach from that guy that wired mcu to counter output of detector.
-
Pascal DEVEAUX posted a comment on ticket #13
Sorry, it's overly complex, I don't want to waste time with your program. A Windows executable program with an ".exe" file would have been simpler for everyone. Thanks again.
-
Look into the GeigerLog manual, chapter "Introduction to GeigerLog, Installing, Starting, and Using GeigerLog", and follow instructions.
-
As I mentioned in the previous message: ** Microsoft Windows [version 10.0.26200.7462] (c) Microsoft Corporation. All rights reserved. C:\Users\Pascal>geigerlog 'geigerlog' is not recognized as an internal or external command, operable program, or batch file.**
-
As I mentioned in the previous message: Microsoft Windows [version 10.0.26200.7462] (c) Microsoft Corporation. All rights reserved. C:\Users\Pascal>geigerlog 'geigerlog' is not recognized as an internal or external command, operable program, or batch file.
-
Ok, is done. Watch for the upcoming pre-release 02 here: https://sourceforge.net/p/geigerlog/discussion/devel2/
-
As I said on the GQ forum: Open a command window, and start GeigerLog. Post every outcome into your ticket.
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from an I2C sensor BME280, and black barometric pressure, all run on the very same ESP32 simultaneously. Bad news: I have loaded the GDK101 with a bag of Uranium beads to give it a bit of a workout. It is responding with µSv data. This is physical bullshit! The calibration of counters - if done at all - refers to Gamma radiation. It is undefined when it receives radiation...
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from an I2C sensor BME280, and black barometric pressure, all run on the very same ESP32 simultaneously.
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from a BME280, and black barometric pressure, all run on the very same ESP32 simultaneously.
-
Attached a pic from running the GDK101 on my latest GeigerLog. Blue the 1min data, Magenta the 10min data, red the Temperature from a BME280, and black barometric pressure, all run on the very same ESP32 simultaneously.
-
wez posted a comment on discussion Feature Request
Hi Ullix, indeed a user config option makes the most sense, that is a very good idea. Auto detection is over rated anyway :)
-
Hello, I'm installing Python 3.14.2 on Windows 11 and Geigerlog. When I run Geigerlog.bat, a window opens and closes very quickly. What could be the cause? My Google searches haven't turned up anything. I should mention that I know nothing about the Python environment. Microsoft Windows [version 10.0.26200.7462] (c) Microsoft Corporation. All rights reserved. C:\Users\Pascal>geigerlog 'geigerlog' is not recognized as an internal or external command, operable program or batch file.
-
I checked the log; looks ok so far. The variables in GeigerLog are strictly numeric-only! Thus strings can never be stored in them. However, I think the values from GDK101 status, vibration, measurement are quite irrelevant to a user. Status changes from 0 to 1 to 2 within 10 min and then stays at 3 forever. Vibration seems to be nailed at 0. I tried hard shaking my device to at least once ge a "1", but failed. Measurement goes up from zero to 10min 59 sec, and then goes back to 10mjin 0 sec, and...
-
English, please.
-
Respect for figuring out what changes are needed for dark mode! I tested it, and it seems to work. I am a bit surprised: is that really all there is needed for dark mode? It seems too easy. I find no way for PyQt6 to auto- detect a dark mode versus a light mode. Is there one? However, a mildly smarter hack could be to put this in the configuration, and allow the user to change it. It still won't be automatic, but is easy to do. Would that work for you?
-
Ne se lance pas
-
I'm adding about 2.5h log. Did you plan also adding MQTT option?
-
I received my first Geiger counter today and having a fun time exploring GeigerLog. Thanks for this great program! Due to light sensitivity I use a dark mode appearance on my desktop environment (Linux, KDE Plasma). Unfortunately this makes some texts, inputs and dialogs unreadable as they override the OS defaults. Attached screenshots demonstrates the issues: GeigerLog_Config.png (device configuration screen) GeigerLog_confirmation.png (Append confirmation) GeigerLog_Graph.png (Note the time min/max...
-
I'm adding about half an hour log. Tomorrow I could provide longer log.
-
I have such kit from aliexpress and a surplus polish geiger tube BOB-33. After placing tube in the kit nothings happens. The tube itself working over a decade ago, but unfortunately i had soldered it back in the days since i don't have popper clamps when start experimenting with it. Now i desoldered the cables so it is not impossible that I broke it, but I tied to do it gentle and not unseal it. Tube itself have similar voltages to STS-5 with which the kit is compatible. I have the printed curve...
-
OK, no problem. I can get a long term log. But first I want to report another bug. Measurement time is a string and can be cast into Humid (or any other variable in giegerlog I think). 28 22:05:23.132 ...396 getTasmotaResponse: response: {"StatusSNS":{"Time":"2025-12-28T22:05:22","GDK101":{"Firmware":0.6,"RadiationAv ... (showing 80 of 171 chars) 28 22:05:23.133 ...397 getValuesWFS #0 GDK101: { "StatusSNS": { "Time": "2025-12-28T22:05:22", "GDK101": { "Firmware": 0.6, "RadiationAvg10Min": 0.12, "RadiationAvg1Min":...
-
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.
-
BTW. There is a project in which someone bypassed MCU in hdk101 and getting the data from the diodes.
-
BTW. There is a project in which someone bypased MCU in hdk101 and getting the data from the diodes.
-
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 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. Please report the outcome. [WiFiServerDevice] WiFiServerActivation = yes WiFiServer = yes, Tasmota, GDK101, 10.0.0.199, 80, CPM3rd, CPS3rd, Temp, Press, Humid # it delivers: RadiationAvg1Min, RadiationAvg10Min, status, vibration, measurement
-
You may be interested in this Tasmota-Geiger-Counter pre-release of GeigerLog: GeigerLog Version 2.2pre01 https://sourceforge.net/p/geigerlog/discussion/devel2/
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
The main new feature in pre-release 2.2pre01 is the introduction of the "GeigerLog - Tasmota Geiger Counter". Tasmota is an Open-Source operating system for ESP32-Microchips (Espressif Systems, China). It is already broadly used by currently 2836 commercially available systems. (https://templates.blakadder.com/). This includes Smart Power Plugs, LED-strips, gas-sensors, and a whole lot more. Now I have added the first Geiger counter to the list! You just need one of the more than dozen variants of...
-
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...
-
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):
-
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): https...
-
Over http you need to use: http://<ip>/cm?cmnd=Status%2010 and 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"}}}
-
Over http you need to use: http://<ip>/cm?cmnd=Status%2010 and respons will lokk like this:</ip> {"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"}}}
-
Over http you need to use: http://<ip>/cm?cmnd=Status%2010 and respons will lokk like this:</ip> {"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"}}}
-
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"}}
-
-
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/STATE" {"Time":"2025-12-21T12:24:40","Uptime":"0T00:00:10","UptimeSec":10,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"vlan13","BSSId":"7A:9A:18:15:C8:40","Channel":1,"Mode":"11n","RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:04"},"Hostname":"tasmota...
-
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/STATE" {"Time":"2025-12-21T12:24:40","Uptime":"0T00:00:10","UptimeSec":10,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"vlan13","BSSId":"7A:9A:18:15:C8:40","Channel":1,"Mode":"11n","RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:04"},"Hostname":"tasmota...
-
For testing purposes you can use such mosquitto.conf: allow_anonymous true listener 1883 0.0.0.0 this will allow you to ignore user/password settings.
-
For testing pourposes you can use such mosquitto.conf: allow_anonymous true listener 1883 0.0.0.0 this will allow you to ignore user/password settings.
-
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...
-
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...
-
Ok, I'm back. I was 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....
-
Ok, I'm back. I was 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....
-
Ok, I'm back. I was 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, I configured it to allow anonymous...
-
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...
-
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...
-
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...
-
stat/tasmota_E496E7/STATUS10 = {"StatusSNS":{"Time":"2025-11-29T21:48:32","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:21"}}} it is published periodically and can be triggered with the command.
-
stat/tasmota_E496E7/STATUS10 = {"StatusSNS":{"Time":"2025-11-29T21:48:32","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:21"}}}
-
stat/tasmota_E496E7/STATUS10 = {"StatusSNS":{"Time":"2025-11-29T21:48:32","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:21"}}}
-
This is the real json from the log console: {"Time":"2025-11-29T21:23:11","GDK101":{"Firmware":0.6,"RadiationAvg10Min":0.00,"RadiationAvg1Min":0.00,"Status":1,"Vibration":0,"Measurement":"0T00:00:09"}} I will setup some mosquito broker in the free time and check topics and full messages.
-
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: {...
-
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: {...
-
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.
-
Also I think that If geiger log handle gdk101 as Tasmota device I can emulate it in the Home Assistant automation and use my esphome device the same way.
-
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: {...
-
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: {...
-
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...
-
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 given period. If some improvements would...
-
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 given period.
-
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.
-
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.
-
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 and wifi either.
-
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.
-
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.
-
This is post is about slightly different setup - no Tasmota but rather Home Assistant automation (a python script) that will recalculate data and send them over MQTT. If this is too close to Tasmota solution and could be handled there sorry for doubling. We can move this discussion there.
-
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.
-
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 (https://www.printables.com/model/1134246-d1-mini-v4-gdk101-case/collections) put somewhere and geigerlog in container on home automation server.
-
This is post is about slightly different setup - no Tasmota but rather Home Assistant automation (a python script) that will recalculate data and send them over MQTT. If this is too close to Tasmota solution and could be handled there sorry for doubling.
-
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.
-
Why did you double post under different topics? This post does not make it any clearer.
-
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...
-
I will want to setup my GDK101 esphome sensor with geigerlog. I will probably need to setup something to pass values from Home Assistant to the MQTT broker, or add additional MQTT client to an esphome device. I will dig into that. But I need some guidance for setting it up on geigerlog, and with data preparation. Will someone could help me with this?
-
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
-
GeigerLog updated /README.md
-
-
-
-
-
Jan posted a comment on ticket #12
By 'I'm running into the same issue' I was referring to trying to contribute by fixing a problem (see other ticket with regards to Linux, RadPro) myself but sourceforge does not allow it.
-
@Jan - Yeah, no pulling on sourceforge :-( To correct either do what @Schuby did, or install the latest Python version. But could you please report the location of this problem?
-
I'm running into the same issue. I would have fixed the error myself with a pull request ullix would only have needed to click on but sourceforge does not seem to allow git versioning at all?
-
Schuby posted a comment on ticket #12
Will do. I generally use GitHub so I wasn't sure how (or if it is possible) to submit a code change to SourceForge. Not sure if you ever thought about using GitHub for this project, but that would allow pull requests and such.
-
Thanks for reporting. The problem was the double-quote use inside double-quotes.; you solved that problem correctly. This was a bug in Python 3.10, and it is corrected in later versions. The trouble for me is that I use Py3.13. So I no longer find the problems, unless I run an older version, AND come across this line :-( If you find more of it, please let me knpw!
1 >
