Liebe FHEM community,
ich habe ein kleines Python2 Programm auf GitHub (https://github.com/ccgruber/geiger) gestellt, das sich per serieller Schnittstelle (Gerät hat einen USB Anschluss) mit meinem Geigerzähler verbindet und die Daten als JSON in ein Textfile ablegt oder per Python FHEM Modul an ein Dummy device sendet.
Momentan sollte es mit den meisten Geräten von GQ Electronics LLC funktionieren. Ich betriebe es mit dem Modell GQ GMC-320+ (https://www.gqelectronicsllc.com/comersus/store/comersus_viewItem.asp?idProduct=4579 (https://www.gqelectronicsllc.com/comersus/store/comersus_viewItem.asp?idProduct=4579)).
Die Umrechnung von Counts Per Minute (CPM) in nSv/h ist ähnlich wie es der Hersteller selbst in seiner Firmware macht (einfach CPM x 5 oder 6.5). Das ist natürlich so nicht richtig, funktioniert aber bis 1000 CPM recht gut.
git clone https://github.com/ccgruber/geiger.git
LG
Christian
P.S.: Ein "echtes" FHEM Modul wäre natürlich auch nett, dann muss aber FHEM auch auf dem Gerät laufen, an dem der Geigerzähler hängt (was bei mir nicht der Fall ist).
Nein, ich habe kein Treadausgrabgerät, sondern einen Geigerzähler GQ GMC-320+ V4. :D
An dieser Stelle großen Dank an Christian für den Code. Falls noch jemand diesen Geigerzähler ans FHEM stricken möchte, hier eine kurze Beschreibung, wie ich das mit Christians Python-Script gemacht habe.
Ausgangslage: Haupt-FHEM auf Maschine 1 (192.168.0.10), zusätzlich Maschine 2, ein Raspberry Pi (192.168.0.11), auf dem noch ein HMUART, ein zweiter CUL (fhem2fhem) und eben der Geigerzähler angeschlossen sind. Das Ganze funktioniert natürlich auch lokal auf einem Rechner.
Auf Maschine 2 (Debian Stretch) python-pip und python-fhem installiert:
sudo apt-get install python
sudo apt-get install python-pip
sudo apt-get install python-serial
sudo pip install fhem
Den Anschluss des GMC-320+ herausfinden:
lsusb
Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial Adapter
ls -la /dev/serial/by-id/
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
Christians Python-Script auf Maschine 2 kopieren (hier einfach mal gleich nach /home/pi/geiger_gmc320.py)
Ändere in /home/pi/geiger_gmc320.py
json_data_log = False
port = "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0"
dT = 300 # CPM read interval (in s) hier 5 Minuten
FHEM_server = "192.168.0.10"
Und dann kann man schon mal testen:
sudo python /home/pi/geiger_gmc320.py
Nun taucht das Device unter dem Namen GQ_GMC_320E_plus von allein in der FHEM-Umgebung auf Maschine 1 auf und die readings kommen an.
Nun noch schnell auf Maschine 2 ein Restart-script geiger_restart.sh gebastelt:
#!/bin/sh
sudo pkill -f geiger_gmc320.py
sleep 2
sudo python /home/pi/geiger_gmc320.py
Damit das Script beim Start des Raspi ausgeführt wird, habe ich es hier einfach in die crontab geschrieben:
sudo nano /etc/crontab
@reboot root sh /home/pi/geiger_restart.sh >/dev/null 2>&1
Prinzipiell war es das schon. Man kann auch in der Haupt-FHEM-Umgebung (Maschine 1) den dummy GQ_GMC_320E_plus definieren. Vorsicht, wenn dort lokal ein eigenes attr stateFormat definiert werden soll. Dann entweder diese Definition in das Python-Script auf Maschine 2 schreiben oder dort Zeile 209 auskommentieren. Sonst würde das Attribut bei jedem Datenempfang wieder überschrieben.
Eine Besonderheit habe ich noch bemerkt: Startet man das Haupt-FHEM auf Maschine 1 neu, dann kommen keine readings mehr an, obwohl das Script auf Maschine 2 noch läuft. Ich habe das einfach dadurch umgangen, dass ich hier in einem weiteren cronjob das Script jede Stunde neu starte. Dann kommen die Readings wieder. Ich habe dadurch nichts negatives bemerkt. Schlimmstenfalls fehlen dann 55 Minuten Readings. Aber bei einem Geigerzähler ist das nicht sooo wichtig.
Hier mal ein Listing des Device.
Internals:
CHANGED
FUUID 5d59334c-f46f-9ab8-568b-88ed76558491bba
NAME GQ_GMC_320E_plus
NR 3218
STATE ☢22
TYPE dummy
READINGS:
2019-08-18 21:45:05 all Radiation: 22 CPM (0.143 µSv/h +27.3 °C 4.1 V)
2019-08-18 21:45:05 datetime 2019-08-18 21:44:34
2019-08-18 21:30:04 device GQ_GMC_320E_plus
2019-08-18 21:45:05 rad_cpm 22
2019-08-18 21:45:05 rad_nsvh 143.0
2019-08-18 21:30:04 serial F48555555551E4
2019-08-18 21:30:04 settings_FHEM_port 7072
2019-08-18 21:30:04 settings_FHEM_server 192.168.0.10
2019-08-18 21:30:04 settings_baud 115200
2019-08-18 21:30:04 settings_dT 300
2019-08-18 21:30:04 settings_fhem_data_log True
2019-08-18 21:30:04 settings_json_data_log False
2019-08-18 21:30:04 settings_json_data_logdir /var/data
2019-08-18 21:30:04 settings_json_log_file /var/data/geiger_GQ_GMC_320E_plus.json
2019-08-18 21:30:04 settings_port /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2019-08-18 21:45:05 temperature_C +27.3
2019-08-18 21:30:04 version GMC-320Re 4.26
2019-08-18 21:45:05 voltage_V 4.1
Attributes:
event-on-change-reading rad_nsvh.*:32.5,rad_cpm.*:5,voltage.*:0.2
stateFormat { sprintf('☢%s', ReadingsVal('GQ_GMC_320E_plus','rad_cpm',''))}
userReadings all { sprintf('Radiation: %s CPM (%s µSv/h %s °C %s V)', ReadingsVal('GQ_GMC_320E_plus','rad_cpm',''), ReadingsVal('GQ_GMC_320E_plus','rad_nsvh','')*0.001, ReadingsVal('GQ_GMC_320E_plus','temperature_C',''), ReadingsVal('GQ_GMC_320E_plus','voltage_V',''), )}
Die ganze Geschichte verursacht auf beiden Maschinen keine signifikante Last oder Blockaden. In dieser Hinsicht ist das Modul von https://forum.fhem.de/index.php?topic=80993.0 (https://forum.fhem.de/index.php?topic=80993.0)offensichtlich noch kritisch. Außerdem nehmen die Daten da den Umweg über den Server des Herstellers und man muss deine eigenen Werte wieder aus dem Netz holen. das ist irgenwie nicht meins. Diese lokale Lösung hier gefällt mir besser.
Ist für viele vielleicht banal, aber ich habe es trotzdem mal aufgeschrieben. Vielleicht spart ja jemand dadurch ein wenig Zeit.