Neues Modul: 32_gmc320.pm - Messung von Radioaktivität

[MarkusRobertAllen]

Wer möchte die radioaktive Belastung mit in die Hausautomation aufnehmen? Hierzu habe ich ein neues Modul geschrieben, welches auf den GMC320 Geigerzählern der Firma GQ aufbaut.
Ich besitze einen GMC-320 V5 (mit Wifi) welches die lokalen Ergebnisse der radioaktiven Belastung (in CPM) auf einer InternetSeite, genauer http://www.gmcmap.com meldet.

Diese Seite wird von dem Modul auslesen. Da diese Seite von allen Besitzern von Geigerzählern weltweit befüttert wird, kann man also auch Daten abfragen, wenn man keinen eigenen Geigerzähler besitzt.

Das Modul ist zum Testen angehängt. Folgendes wird benötigt (Debian):

cpan LWP::Simple
cpan HTML::TreeBuilder
cpan LWP::UserAgent

Das Device wird wie folgt angelegt:

define gmc320 gmc320 [ID] [Intervall]
attr gmc320 room gmc320

Die ID bezeichnet die sog. Geiger Counter ID, welches auf ein Hardware Device verweist, welches Ihr
a) entweder besitzt, wenn Ihr die Hardware erworben habt und Daten auf die Seite meldet
b) oder ein beliebige ID, welche Teil der gq Community ist.

Wie ermittelt Ihr diese ID?
a) Falls Ihr ein GQ Geiger Counter besitzt, ist das vermutlich klar. Es handelt sich um die "Geiger Counter Id", die Ihr von Eurer Hardware herauslesen könnt.
b) Falls nicht, könnt Ihr über die Seite http://www.gmcmap.com einen Standort auswählen. Danach einen Klick auf den Standort und "History Data" auswählen. Die URL ändert sich danach auf http://www.gmcmap.com/historyData.asp?Param_ID=<hier steht eine ID>. Diese ID wird in den Device-Aufruf eingetragen.

Welcher Intervall ist empfehlenswert?
Ich habe experimentiert und eine Zahl <60 ist nicht empfehlenswert, insbesondere wenn History Data bei diesem Device vorhanden ist, da dann Last auf dem System erzeugt wird. Intervall bedeutet einfach, dass die Internetseite im Intervall von 60 Sekunden abgefragt wird, wenn Ihr den Wert 60 als Frequenz hinterlegt. Geht am Anfang einen Intervall von 3600 an und überprüft die Last auf dem System.

Es gibt nach der Definition zwei Readings für das Device:
cpm
datetimereceived

cpm gibt die radioaktive Belastung in CPM (welche sich auch in uSievert umrechnen lässt) und datetimereceived den Timestamp an.

Es handelt sich um mein erstes Modul, ich bin für Hinweise dankbar, ebenso wie Ergebnisse von Tests.

[helmut]

Hallo Markus,

weil ich das Thema ganz interessant finde, habe ich Dein Modul ausprobiert und das Intervall zum Testen 
entgegen Deiner Empfehlung auf 60 Sekunden eingestellt.

Code Auswählen Erweitern


"fhem45"> l gmc320
Internals:
   CFGFN     
   DEF        10838115609 60
   NAME       gmc320
   NR         17501
   NTFY_ORDER 50-gmc320
   STATE      Active
   TYPE       gmc320
   id         10838115609
   refresh    60
   READINGS:
     2017-12-13 10:13:49   cpm             14
     2017-12-13 10:13:49   datetimereceived 2016-10-12 20:23:45
   helper:
     bm:
       gmc320_Attr:
         cnt        2
         dmx        0
         mAr       
         mTS       
         max        0
         tot        0
       gmc320_Define:
         cnt        1
         dmx        0
         mTS        13.12. 09:33:24
         max        2
         tot        2
         mAr:
           HASH(gmc320)
           gmc320 gmc320 10838115609 60
       gmc320_Get:
         cnt        8
         dmx        0
         mAr       
         mTS       
         max        0
         tot        0
       gmc320_Notify:
         cnt        730
         dmx        0
         mAr       
         mTS       
         max        0
         tot        0
Attributes:
   DbLogInclude cpm



Da ich apptime seit gestern aus einem anderen Grund geladen hatte, habe ich auch gleich mal kontrolliert.
"tmr-gmc320_GetHttpResponse" hat sich innerhalb kurzer Zeit zur Nummer eins gemacht:

Code Auswählen Erweitern


"fhem45"> app total
tmr-gmc320_GetHttpResponse               HASH(0x882bbb8)                      27354     34   601170 17681.47     10 13.12. 09:54:19 HASH(gmc320)
CUL1                                     TSCUL_Read                             885   8002   500509    62.55      0 13.12. 09:47:40 HASH(CUL1)


Nur der Vollstaendigkeit halber zwei Warnungen im Log:

Code Auswählen Erweitern


2017.12.13 09:25:49.022 1: PERL WARNING: Prototype mismatch: sub main::from_json ($) vs ($@) at ./FHEM/32_gmc320.pm line 22.
2017.12.13 09:25:49.025 1: PERL WARNING: Prototype mismatch: sub main::to_json ($) vs ($@) at ./FHEM/32_gmc320.pm line 22.


Gruss Helmut

[herrmannj]

Hallo MarkusRobertAllen,

Herzlichen Glückwunsch zum ersten Modul !

Es handelt sich um mein erstes Modul, ich bin für Hinweise dankbar, ebenso wie Ergebnisse von Tests.

Ich bin so frei erste Empfehlungen zu formulieren:

auf den Einsatz der LWP Module sowie den HTML::TreeBuilder solltest Du generell verzichten.

Für erstere (LWP) bietet FHEM eine eigene API (https://wiki.fhem.de/wiki/HttpUtils). Innerhalb von FHEM addieren sich Latenzen aller (FHEM) module. Daher ist es enorm wichtig das die (FHEM) module asynchron (non-blocking) implementiert werden. CPAN Module wie LWP sind dafür nicht ausgelegt. Für Anwender ist es dazu unschön zusätzliche (Non perl core) Module installieren zu müssen. Es ist ja auch unnötig, FHEM hat eine asynchrone API (für http requests).

Den TreeBuilder kannst Du ebenfalls sparen (inklusive der Kosten beim parsen). Im Quelltext der gmcmap Seite sehe ich folgenden Schnittstelle:
http://www.gmcmap.com/GQDownloadHistoryInCSV.asp?param_ID=72332423710

Dort werden die Daten direkt als CSV geliefert, können also ohne Umwege (TreeBuilder) weiter verarbeitet werden.

Insgesamt: Gute Arbeit!

Noch ein Hinweiß: innerhalb FHEM gibt es ein Mentoren Programm für neue Autoren. Wenn Du Dich dort bewirbst kannst Du direkt vom Erfahrungswissen eines "alten Hasen" profitieren.

vg
Joerg

[KölnSolar]

schau mal hier. Könnte für Dich ganz interessant sein, da Markus damals die Seite in sein Modul eingebunden hat. Möglicherweise kannst Du daher aus dem Modul lernen und/oder aus den ganzen Diskussionen, ob man die Infos einer (speziellen) Website einfach automatisiert abrufen darf bzw. Programme(-teile) der Öffentlichkeit für automatisierte Abrufe zur Verfügung stellen darf. Wenn ich es richtig verstanden hatte, war das letztendlich der Grund, warum das Modul nie ins offizielle Release kam und Markus die Entwicklung eingestellt hat 
Grüße Markus

[MarkusRobertAllen]

Hallo,
danke für die freundlichen Hinweise. Ich werde diesen nachgehen, um insbesondere die Last zu verringern.

Neue Readings habe ich in die neue Version bereits eingebaut:
acpm
location (Ort der abgefragten Hardware)
usvh (MicroSievert pro Stunde)

Gruss,
Markus

[Pfriemler]

Ich war überrascht zu sehen, dass sich jemand schon die Mühe gemacht hat, ein Modul für die GMCMAP zu erstellen. Schade, dass das bereits nach zwei Tagen eingeschlafen ist.
Im zitierten airquality-Modul von Markus M. finde ich mitnichten die Möglichkeit, die GMCMap anzuzapfen - was mir viel besser gefällt als den eigenen GMC anzuzapfen, nicht zuletzt weil FHEM und der Counter hier zu Hause in zwei getrennten Netzen arbeiten ...
Bevor ich mich (als Besitzer eines GMC-500+) auf eigene Experimente begebe: Ist das Projekt schon eingeschlafen oder wurde die Aufgabe letztlich auf gänzlich andere Weise gelöst?

[MarkusRobertAllen]

Hi,
es ist in der Tat eingeschlafen, aber eigentlich weil es meinen eigenen Ansprüchen genügt und auch kein weiteres Feedback aus dem Community kam.

Ich habe mein eigenes Modul eingebunden mit:

Code Auswählen Erweitern


define gmc320 gmc320 <hier die id einsetzen> 3600
attr gmc320 room gmc320
attr gmc320 verbose 0


und damit gibt es auch keine Lastprobleme oder ähnliches.

Wenn Du Fragen oder Wünsche hast...

[Pfriemler]

Danke für die Rückmeldung. Inzwischen nutze ich aber eine HTTPMOD-Abfrage, ausführlich in diesem Post dargestellt.

edit: Ich könnte aber noch einen Versuch wagen ... Im ersten Post war nur die Fassung mit den erweiterten Readings - was ist mit den Verbesserungen die Du in Aussicht gestellt hattest?