Neues (altes) Modul: Homematic CCU mit XML-RPC an FHEM, HMRPC reborn

[henryk]

Moin,

für die Koppelung einer Homematic CCU an FHEM per XML-RPC (die mitgelieferte API) habe ich basierend auf den existierenden Codestücken in contrib/HMRPC ein funktionierendes Modul gebaut. Der existierende Code in contrib funktionierte aus mehreren Gründen nicht (unter anderem weil einkommende XML-RPC-Requests FHEM für mindestens 20 Sekunden blockieren, eher länger, wenn es mehrere Updates von der CCU gibt), und ich habe diese Aspekte erst einmal repariert. Es fühlt sich zwar immernoch wie ein Fremdkörper an, tut aber zumindest erstmal ein bisschen.

Vorteile:

• Keine Zusatzinstallation auf der CCU erforderlich
• Callbacks von der CCU bei jeder Änderung: Instantane Updates in FHEM

Code hier: https://github.com/henryk/fhem-HMRPC

Dokumentation habe ich noch keine, es gilt der größte Teil von contrib/HMRPC/HMRPC.txt weiterhin.

Technisch habe ich das so verbessert dass die Callbacks der CCU nicht mehr über einen eigenen Socket reinkommen (was durch die Inflexibilität von RPC::XML::Server dann notwendigerweise dazu führt, dass ein timeout abgewartet wird) sondern von FHEMWEB angenommen werden. Dazu waren zwei Patches an FHEMWEB nötig, die Rudolf bereits eingespielt hat, also dann irgendwann auftauchen wenn man ein Entwicklungszweig-FHEM hat. Andernfalls kann man sie aus http://forum.fhem.de/index.php/topic,41030.msg332339.html#msg332339 und http://forum.fhem.de/index.php/topic,41034.msg332383.html#msg332383 direkt beziehen.

Installation:

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/henryk/fhem-HMRPC/master/controls_HMRPC.txt
shutdown restart

CCU definieren:

Code Auswählen Erweitern

define hmrf HMRPC I.P.der.CCU 2001

Zur Zeit ist der Port unter der FHEMWEB zu erreichen ist auf 8083 hartkodiert, kann aber über ein Attribut geändert werden:

Code Auswählen Erweitern

attr hmrf callback_base http://I.P.von.FHEMWEB:port/fhem (Es muss der gesamte Basis-URL der FHEMWEB-Instanz inklusive Port und "/fhem" angegeben werden.)

Danach meldet die CCU jede Attributänderung selbsttätig an FHEM. Wenn autocreate aktiv ist, werden entsprechende HMDEV-Devices angelegt. Obacht: Ich weiss nicht warum, aber das funktioniert nur, wenn bereits ein HMDEV-Device existiert. Daher muss man nach der Installation einmalig

Code Auswählen Erweitern

define foo HMDEV foo
delete foo machen.


Grade akute Fragen an erfahrenere FHEM-Entwickler:

• Das beschriebene autocreate-Problem, wie löst man das? Symptom: hmrf: Unknown code HMDEV KEQ...:0 LOWBAT 1, help me! im FHEM-Log. Sobald das erste HMDEV-Device definiert wurde wird stattdessen ein neues Device HMDEV_KEQ... angelegt.
• Ich möchte gerne ein Attribut bereits direkt zum Beginn der Funktionalität verwenden. Aber wenn FHEM startet und Definitionen aus fhem.cfg liest, dann kommt ja erst das define und dann das attr (oder auch nicht, wenn das Attribut nicht gesetzt ist). Zur Zeit warte ich einfach 10 Sekunden, aber das kann's ja nicht sein. Ich weiss, dass ich prinzipiell auf global:INITIALIZED lauschen kann und dann die Arbeit aufnehmen, aber was ist dann, wenn der Benutzer das Device interaktiv definiert, also nicht aus dem fhem.cfg. Muss ich da eine Fallunterscheidung einbauen?
• Ich habe Port 8083 und Basis "/fhem" hartgecoded (kann man halt mit dem Attribut überschreiben). Kann ich irgendwie dynamisch die Kontaktdaten einer aktiven FHEMWEB-Instanz rausfinden und benutzen?

[Ralli]

Danke für Deine Weiterentwicklung.

Vor Installation ist ein

Code Auswählen Erweitern


cpan -i RPC::XML::Server


notwendig.

[zap]

Ich habe einige Fragen / Anmerkungen zur neuen Version:

- Die alte Version von HMRPC hat keine Bestätigungen für die Callbacks an die CCU geschickt. Das hat zu massiven Fehlermeldungen im Systemlog der CCU geführt. Geht das jetzt?
- Das mit den Timeouts verstehe ich nicht. Ich habe zum Testen einen simplen RPC Server mit Prozess-Forks für das Connection-Handling in C++ geschrieben. Das funktioniert bestens. Nur eben in FHEM nicht.

Habe mein Modul HMCCU "aus der Not heraus" geschrieben, weil ich HMRPC nicht stabil zum Laufen bekommen habe. Grundsätzlich ist RPC die bessere Variante, weil die Info von der CCU kommt. Wenn das ganze stabil ist und ohne FHEM Patch auskommt, werde ich es nochmal testen.

Wobei für meinen persönlichen Usecase eigentlich die Richtung FHEM -> CCU ausreicht.

[Ralli]

Ich hätte noch gaaaanz kleine Kleinigkeiten:

Für die definierte CCU(2) könnten folgende Readings noch von Interesse sein, die irgendwo bei einem list ... auch mitkommen:

FIRMWARE   2.15.2
INTERFACE  LEQ ......
RF_ADDRESS 11343442

wobei INTERFACE ja Seriennummer ist und RF_ADDRESS hexadezimal als HMID der Zentrale dargestellt werden sollte.

Ansonsten werde ich das Modul mal in meiner Produktivumgebung aufnehmen und erst mal zwei-drei Devices "umziehen".

[zap]

Ich habe Port 8083 und Basis "/fhem" hartgecoded (kann man halt mit dem Attribut überschreiben). Kann ich irgendwie dynamisch die Kontaktdaten einer aktiven FHEMWEB-Instanz rausfinden und benutzen?[/li][/list]

Man kann doch mit AttrVal() auf Attribut-Werte zugreifen ...

[henryk]

Moin,

- Die alte Version von HMRPC hat keine Bestätigungen für die Callbacks an die CCU geschickt. Das hat zu massiven Fehlermeldungen im Systemlog der CCU geführt. Geht das jetzt?

Das hast du anderswo schonmal geschrieben, ich kann das nicht nachvollziehen. Ich habe mittlerweile die komplette Spezifikation zur HomeMatic-XML-RPC-Schnittstelle durchgelesen und kann nichts derartiges finden. Events werden über ein Callback an eine Methode event() geliefert, deren Rückgabetyp void ist. Es gibt keine Bestätigung (also, ausser dass halt die Funktion zurückkehren muss). Ich habe mit dem neuen Modul auch keine Fehlermeldungen im CCU-Log.

- Das mit den Timeouts verstehe ich nicht. Ich habe zum Testen einen simplen RPC Server mit Prozess-Forks für das Connection-Handling in C++ geschrieben. Das funktioniert bestens. Nur eben in FHEM nicht.

Ja, eben. FHEM ist im wesentlichen eine große Event-Loop in einem Thread in einem Prozess. Wenn du forkst, kannst du nicht mehr auf die Attribute im originalen Prozess zugreifen, um die Ereignisse, von denen du per Callback gelernt hast, weiterzugeben. Das Modul Blocking.pm verwendet einen kruden Trick: Es forkt, und meldet dann das Ergebnis der Ausführung über die (dafür aktiviert sein müssende) Telnet-Schnittstelle zurück. Einen ähnlichen Trick könnte man auch verwenden, um Ereignisse aus einem XML-RPC-Server in einem eigenen Prozess in FHEM zu kriegen, aber ... Holy complexity, batman.
FHEM ist auch überhaupt nicht multi-thread-sicher, d.h. der Ansatz, einen blockierenden XML-RPC-Server in einem eigenen Thread zu haben, scheidet auch weitgehend aus.

Und wie gesagt, XML::RPC::Server ist nicht event-loop-kompatibel, das blockiert einfach mal so x Sekunden während es auf neue Requests wartet.

Für die definierte CCU(2) könnten folgende Readings noch von Interesse sein, die irgendwo bei einem list ... auch mitkommen:

FIRMWARE   2.15.2
INTERFACE  LEQ ......
RF_ADDRESS 11343442

Ja, ich muss mal gucken. Zur Zeit wird einfach nur als Reading verzeichnet, was in einem Event kam und daher relativ garantierten Aktualitätswert hat. Diese Dinge die du zitierst muss man initiativ bei der CCU abfragen, ich schau' mal, ob ich das zufriedenstellend einpflegen kann. (Dieses Designschema, was bei HM in FHEM generell vorhanden zu sein scheint, dass Dinge angezeigt werden, die keine Relation zur Wirklichkeit haben, sondern ein set getConfig o.ä. erfordern, kann ich nicht ausstehen.)

Ansonsten werde ich das Modul mal in meiner Produktivumgebung aufnehmen und erst mal zwei-drei Devices "umziehen".

Ich hab' bei mir zu Hause seit 'ner knappen Woche einen Fenstersensor und ein HM-CC-TC per HMRPC in FHEM, soweit ohne klagen. Seit letzter Nacht geht auch das passende set SETPOINT_2. Ein HM-TC-IT-WM-W-EU hab' ich auch noch, aber das ist eine Komplexitätsstufe für sich: In der CCU ist das Heizungsteam als virtuelles Gerät INT0...01 repräsentiert, das wird aber über Port 2001 nicht exportiert. Ich hab' gelernt, dass es auf Port 9292 unter /groups noch einen XML-RPC-Endpunkt gibt, der dann diese internen Gruppen darstellt, daran fummele ich derzeit noch.

Man kann doch mit AttrVal() auf Attribut-Werte zugreifen ...

Ja, wenn man den Namen der Instanz kennt. Ich wollte nicht "WEB" hartcoden, weil das genauso schlimm wäre. Ich bin es halt aus anderen Projekten eher gewöhnt, dass es eine ordentliche API für solche Fragen gibt. Mittlerweile habe ich aber gelernt, dass es wohl Usus zu sein scheint, einfach selber in $defs herumzusuchen bis man ein FHEMWEB findet, grusel. Aber ok, mach' ich demnächst.

--
Henryk Plötz
Grüße aus Berlin

[Ralli]

Hallo Henryk,

in meiner Produktivumgebung scheitert's zunächst daran, dass ich mein Standard-Webfrontend auf 8083 (ohne SSL) mit Nutzer/Passwort "abgesichert" habe. So kann das Modul bzw. die CCU2 offensichtlich kein RPC-Callback etablieren.

Edit:

Und das führt dazu, dass die CCU2 in ihrem Webfrontend nicht mehr wirklich funktioniert - zumindest dann, wenn man zB die Geräteübersicht aufruft.

Edit2:

Es wäre sinnvoll, die definierte CCU disablen zu können mit attr CCU2 disable 1.

[zap]

Das mit dem Beantworten der Events steht so nicht in der Spezifikation. Allerdings habe ich es an verschiedenen Stellen und in diversen Beispielprogrammen schon gesehen. Die CCU erwartet (so das Gerücht) ein Leermeldung zurück:

Code Auswählen Erweitern

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param><value></value></param>
   </params>
</methodResponse>

Hier steht schon mal was darüber (im 1. Post):

http://homematic-forum.de/forum/viewtopic.php?t=4827

Oder hier ein Zitat: "I have read about this issue/function on the CCU2. After 10 messages from the CCU2 without a right answer from the client, the CCU stop sending messages to the client and delete the client from the list.
A workaround to fix this problem is re-init after 10 messages."

Ich such nochmal weiter ... aber andererseits: wenn es mit dem neuen Modul keine Fehler mehr in /var/log/messages gibt ist ja alles gut.

[henryk]

Moin,

Das mit dem Beantworten der Events steht so nicht in der Spezifikation. Allerdings habe ich es an verschiedenen Stellen und in diversen Beispielprogrammen schon gesehen. Die CCU erwartet (so das Gerücht) ein Leermeldung zurück

Achso, ja, natürlich. Das ist einfach Teil des XML-RPC-Aufrufs, es muss (mit void) zurückkehren. Das kann man aber auch gar nicht falsch machen, wenn man sich die XML-RPC-Implementierung nicht selber bastelt (und dabei schludert), und das hat der Perl-Code auch von Anfang an richtig gemacht. Genauer gesagt, richtig machen gewollt. Es kehrt grade immer mit dem aktuellen Timestamp zurück, weil Perl implizit den letzten Ausdruck als Return-Wert verwendet (grr). Das ignoriert die CCU zum Glück, sie erwartet ja sogar nur void.

in meiner Produktivumgebung scheitert's zunächst daran, dass ich mein Standard-Webfrontend auf 8083 (ohne SSL) mit Nutzer/Passwort "abgesichert" habe. So kann das Modul bzw. die CCU2 offensichtlich kein RPC-Callback etablieren.

Hast du mal ausprobiert, ob

Code Auswählen Erweitern

attr hmrf callback_base http://username:password@I.P.von.FHEMWEB:port/fhem funktioniert?

Und das führt dazu, dass die CCU2 in ihrem Webfrontend nicht mehr wirklich funktioniert - zumindest dann, wenn man zB die Geräteübersicht aufruft.

Huch, wait, what? Das sollte in keinem Fall passieren. Mal gucken, ob ich das replizieren kann.

Perspektivisch bin ich aber jetzt so weit, wahrscheinlich doch einen eigenen Port aufzumachen. Ich hatte gehofft, durch Verwendung von FHEMWEB auf unkomplizierte Weise einen soliden existierenden HTTP-Server zu kriegen. *hust* Das kann ich glaub' ich besser, wenn ich's von Hand mache.

--
Henryk Plötz
Grüße aus Berlin

[Ralli]

Hast du mal ausprobiert, ob

Code Auswählen Erweitern

attr hmrf callback_base http://username:password@I.P.von.FHEMWEB:port/fhem funktioniert?

hätte ich ja auch selbst mal drauf kommen sollen. Das klappt. Ist nur etwas unschön, da dadurch User/Pass im Klartext in der Config (und im Log) stehen.

Huch, wait, what? Das sollte in keinem Fall passieren. Mal gucken, ob ich das replizieren kann.

Ist bei mir zuverlässig jedes mal so gewesen.

Nach Umzug in meine Produktivumgebung lediglich folgende Informationen entgegen allem möglichen in der Testumgebung:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        10.0.0.64 2001
   NAME       CCU2
   NR         1260
   STATE      Registered
   TYPE       HMRPC
   callbackpath /HMRPC_CCU2
   callbackurl http://x:y@10.0.0.30:8083/fhem/HMRPC_CCU2/request
   serveraddr 10.0.0.64
   serverport 2001
   Helper:
Attributes:
   callback_base http://x:y@10.0.0.30:8083/fhem
   group      Schnittstellen
   icon       hm_ccu
   room       System


... und keine Events kommen an, damit auch kein Autocreate usw.

Btw noch eine Frage: Macht Dein Modul beim Restart von fhem eigentlich eine Status-Abfrage aller HMDEV bei der definierten CCU2?

Und ebenfalls btw: Respekt für http://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ !

[zap]

Ja, eben. FHEM ist im wesentlichen eine große Event-Loop in einem Thread in einem Prozess. Wenn du forkst, kannst du nicht mehr auf die Attribute im originalen Prozess zugreifen, um die Ereignisse, von denen du per Callback gelernt hast, weiterzugeben. Das Modul Blocking.pm verwendet einen kruden Trick: Es forkt, und meldet dann das Ergebnis der Ausführung über die (dafür aktiviert sein müssende) Telnet-Schnittstelle zurück. Einen ähnlichen Trick könnte man auch verwenden, um Ereignisse aus einem XML-RPC-Server in einem eigenen Prozess in FHEM zu kriegen, aber ... Holy complexity, batman.
FHEM ist auch überhaupt nicht multi-thread-sicher, d.h. der Ansatz, einen blockierenden XML-RPC-Server in einem eigenen Thread zu haben, scheidet auch weitgehend aus.

Ich habe in den vergangenen Tagen mal ein bisschen rumprobiert in Richtung generischer TCP Server in FHEM implementieren. Inzwischen habe ich aufgegeben. Wenn ich einen separaten Prozess für jede Verbindung forke, hab ich das von Dir beschriebene Problem mit dem Zugriff auf die FHEM Daten. Wenn ich einen iterativen Ansatz verwende, steht FHEM logischerweise während eine Anfrage bearbeitet wird.
Eine Lösung wäre m.E. nur möglich, wenn sich die Architektur von FHEM in Richtung Multi-Processing ändern würde. Daran glaube ich nicht (enormer Aufwand).
Alternative: Solche Schnittstellen wie z.B. RPC-Server werden in einem externen Programm implementiert und kommunizieren mit FHEM. Das halte ich schon eher für realisierbar. Habe speziell für die RPC Geschichte auch schon mal überlegt, einfach einen Apache mit XML-RPC zu installieren.

[trilu]

Hi Henryk,
klasse Sache mit dem RPC Modul. Ich hatte das alte Modul vor einem halben Jahr mal getestet und bin kläglich gescheitert.
Diesmal läuft es definitiv besser. Testraum mit MAX Wandthermostat, Heizungsregler und 2 Fenstersensoren über Homegear an FHEM läuft soweit ganz gut.
Beim HMDEV vermisse ich ein paar Sachen wie z.B. stateFormat, dass lässt sich aber über das Modul Readingsgroup lösen.
Allerdings ist mir ein Fehler im Zusammenhang mit dem Wochenprogramm des Wandthermostaten aufgefallen. Wenn ich das Wochenprogramm über Homegear oder den hm-manager ändere, wird nach einer Error Routine bei FHEM über Port 8083 gesucht...

Code Auswählen Erweitern

09/27/15 10:29:33.093 Module MAX: Info: Parameter ENDTIME_FRIDAY_1 of peer 12 and channel 0 was set to 0x56.
09/27/15 10:29:33.108 Info: Calling RPC method "system.multicall" on server 127.0.0.1.
09/27/15 10:29:33.110 Info: Connecting to host 127.0.0.1 on port 2015...
09/27/15 10:29:33.119 Info: Connected to host 127.0.0.1 on port 2015. Client number is: 29409
09/27/15 10:29:33.131 Info: Calling RPC method "system.multicall" on server 127.0.0.1.
09/27/15 10:29:33.143 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.160 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29410
09/27/15 10:29:33.255 Module MAX: CUL "My-MAX-CUL": Info: Sending (My-MAX-CUL, WOR: yes): 1916001006A62303178D00064456546B44CC5514452045204520
09/27/15 10:29:33.295 Info: Calling RPC method "updateDevice" on server 127.0.0.1.
09/27/15 10:29:33.296 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.299 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29411
09/27/15 10:29:33.347 RPC Server (Port 2001): Info: Connection from 127.0.0.1:44174 accepted. Client number: 29412
09/27/15 10:29:33.360 RPC Server (Port 2001): Info: Client number 29412 is calling RPC method: getServiceMessages Parameters:
09/27/15 10:29:33.366 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: updateDevice' on server
09/27/15 10:29:33.372 Info: Calling RPC method "error" on server 127.0.0.1.
09/27/15 10:29:33.375 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.386 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29413
09/27/15 10:29:33.419 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: error' on server
09/27/15 10:29:33.420 Info: Calling RPC method "error" on server 127.0.0.1.
09/27/15 10:29:33.421 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.423 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29414
09/27/15 10:29:33.485 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: error' on server


Sagt Dir das was?

Viele Grüße
Horst

[henryk]

Moin,

Beim HMDEV vermisse ich ein paar Sachen wie z.B. stateFormat, dass lässt sich aber über das Modul Readingsgroup lösen.

Ich nehme auch pull-requests auf github an

Code Auswählen Erweitern


09/27/15 10:29:33.295 Info: Calling RPC method "updateDevice" on server 127.0.0.1.
09/27/15 10:29:33.296 Info: Connecting to host 127.0.0.1 on port 8083...
...snip...
09/27/15 10:29:33.366 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: updateDevice' on server
09/27/15 10:29:33.372 Info: Calling RPC method "error" on server 127.0.0.1.
09/27/15 10:29:33.375 Info: Connecting to host 127.0.0.1 on port 8083...
...snip...
09/27/15 10:29:33.419 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: error' on server


Das ist ein Bug in Homegear. Die "Spezifikation" für das XML-RPC-Interface von eQ-3 spezifiziert das zwar leider nicht, aber sowohl die defacto-Implementierung der Original-CCU als auch Homegear's eigene Dokumentation (https://www.homegear.eu/index.php/XML_RPC_Method_Reference#XML_RPC_Client_Functions) stimmen überein: Ein XML-RPC-Client muss nicht alle Callbacks implementieren, stattdessen wird bei Registrierung über system.listMethods() abgefragt, welche existieren, und dann nur diese verwendet. Das HMRPC-Modul hat zur Zeit nur newDevices() (Callback das Informationen über neue Geräte bekommt) und event() (Callback über das alle Events eingekippt werden), sowie einen Dummy für listDevices() der immer behauptet, wir würden gar keine Geräte kennen.

In deinen Logs versucht Homegear updateDevice() (eine Gerätekonfiguration wurde geändert) aufzurufen. Da das nicht klappt, kommt es zu einem Fehler, und einem doppelten: Homegear versucht jetzt den Fehler über error() (ein Fehler in Homegear ist aufgetreten, das ist übrigens gar nicht Teil der eQ-3-XML-RPC-Spezifikation) zu melden.

Kannst du den Bug bei Homegear melden? https://github.com/Homegear/Homegear/issues

--
Henryk Plötz
Grüße aus Berlin

[Ralli]

Nach Umzug in meine Produktivumgebung lediglich folgende Informationen entgegen allem möglichen in der Testumgebung:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        10.0.0.64 2001
   NAME       CCU2
   NR         1260
   STATE      Registered
   TYPE       HMRPC
   callbackpath /HMRPC_CCU2
   callbackurl http://x:y@10.0.0.30:8083/fhem/HMRPC_CCU2/request
   serveraddr 10.0.0.64
   serverport 2001
   Helper:
Attributes:
   callback_base http://x:y@10.0.0.30:8083/fhem
   group      Schnittstellen
   icon       hm_ccu
   room       System


... und keine Events kommen an, damit auch kein Autocreate usw.

Btw noch eine Frage: Macht Dein Modul beim Restart von fhem eigentlich eine Status-Abfrage aller HMDEV bei der definierten CCU2?

Und ebenfalls btw: Respekt für http://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ !

Hallo Henryk,

hast Du hier eine Idee? Ich komme nicht weiter.

[trilu]

Vielen Dank!
Bug ist gemeldet...

Ich habe die 61_HMDEV.pm mal um die FN Attribute erweitert. Lässt sich auch alles schön auswählen, aber bei den Events werden die FN Attribute nicht immer berücksichtigt.

Code Auswählen Erweitern

sub
HMDEV_Initialize($)
{
  my ($hash) = @_;

  $hash->{Match}     = "^HMDEV .* .* .*";
  $hash->{DefFn}     = "HMDEV_Define";
  $hash->{ParseFn}   = "HMDEV_Parse";
  $hash->{SetFn}     = "HMDEV_Set";
  $hash->{GetFn}     = "HMDEV_Get";
  $hash->{AttrList}  = "IODev do_not_notify:0,1".
                        $readingFnAttributes;
}