Batterie? FIBARO System FGFS101 Flood Sensor

[curt]

Frohe und gesegnete Weihnachten!

Mein "Wasser-Ei" habe ich seit gut einem Jahr, seitdem auch in FHEM eingebunden (Definitionen unten). Vorhin habe ich es an schwer zugängliche Stelle verbaut. Und wie es immer so ist: Voller Schreck sah ich danach, dass das Ei mit höchstens nach "get battery" den Ladestand der Batterie sagt.

Schön wäre natürlich, wenn er -sagen wir- etwa einmal pro Woche den Ladezustand sagt. Wie macht man das denn?

Möglicherweise ist meine FHEM-Konfiguration (event-on-*) falsch. Möglicherweise muss aber auch einmalig ein schlauer Befehl an das Wasser-Ei gesendet werden. Ich weiß es nicht.

Meine Konfiguration habe ich mir mit Hilfe von Forenartikeln und Nachfragen vor einem Jahr zusammengebastelt, ohne wirklich zu verstehen, was ich da treibe. Aber es funktioniert, so irgendwie. Aus mir nicht näher bekanntem Grund besteht sie aus zwei Devices für dieses eine Ei. Die zweite Device liefert die Temperatur.

Code Auswählen Erweitern


define Wasser_1 ZWave c7e4058a 5
attr Wasser_1 IODev ZWave
attr Wasser_1 battery_change 2018-07-16
attr Wasser_1 classes SENSOR_BINARY SENSOR_ALARM MULTI_CHANNEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY WAKE_UP
attr Wasser_1 event-on-change-reading .*
attr Wasser_1 extendedAlarmReadings 1
attr Wasser_1 icon 1
attr Wasser_1 room 11 Fenster Tür,Unsorted,ZWave
attr Wasser_1 stateFormat battery state
attr Wasser_1 userReadings state:alarm_type_.* {(ReadingsVal($NAME,"alarm_type_05","")=~/^level 255/)?"Wasser":"Trocken"}
attr Wasser_1 vclasses ASSOCIATION:2 BATTERY:1 CONFIGURATION:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL:3 MULTI_CHANNEL_ASSOCIATION:2 SENSOR_ALARM:1 SENSOR_BINARY:1 VERSION:1 WAKE_UP:1


Code Auswählen Erweitern


define Wasser_1_Temp ZWave c7e4058a 1282
attr Wasser_1_Temp IODev ZWave
attr Wasser_1_Temp event-min-interval 60
attr Wasser_1_Temp event-on-change-reading state,battery,temperature,wakeup
attr Wasser_1_Temp event-on-update-reading battery,temperature,wakeup
attr Wasser_1_Temp extendedAlarmReadings 2
attr Wasser_1_Temp room 11 Fenster Tür
attr Wasser_1_Temp stateFormat temperature


[rudolfkoenig]

Schön wäre natürlich, wenn er -sagen wir- etwa einmal pro Woche den Ladezustand sagt. Wie macht man das denn?

Wenn die Geraete-Konfiguration das nicht hergibt (siehe Beipackzettel oder Internet-Suche), mit

Code Auswählen Erweitern

define Wasser_1_battery at *12:00 { fhem "get Wasser_1 battery" if($wday==0) }

Aus mir nicht näher bekanntem Grund besteht sie aus zwei Devices für dieses eine Ei.

Das Geraet unterstuetzt mehrere Kanaele (MULTI_CHANNEL), und das FHEM ZWave Modul bildet jeden Kanal als eine separate Instanz ab.

[curt]

Wenn die Geraete-Konfiguration das nicht hergibt (siehe Beipackzettel oder Internet-Suche), mit

Code Auswählen Erweitern

define Wasser_1_battery at *12:00 { fhem "get Wasser_1 battery" if($wday==0) }

Prinzip nun verstanden - herzlichen Dank für den Tipp!

[tomspatz]

@Curt
Das Gerät schläft ja falls du es nicht mit 12 Volt extern versorgst, und wird alle 6 Stunden wach.

Code Auswählen Erweitern

wakeupReport interval 21600 target 1

Ich bin mir nicht ganz sicher ob der Sensor den Batterie Status selbständig überträgt. Ich löse das mit einen einfachen DOIF welches auf das "wakeup" der Batteriebetriebenen Geräte triggert.

Code Auswählen Erweitern

defmod BatterieAbfrageSensoren DOIF (["Fenster:wakeup"] or ["tuer:wakeup"] or ["Schalter:wakeup"] or ["Tuer:wakeup"] or ["Sensor:wakeup"]) (get $DEVICE battery)

LG
Tom

[curt]

@tomspatz

Ich habe offen gesagt nicht verstanden, was Du da machst. Bitte erkläre es mir.

Die erste Zeile - wo gehört die genau hin? (Vielleicht bitte ein konkretes Beispiel.)

Die zweite Zeile, also mit DOIF habe ich noch nie etwas gemacht. Ich glaube zu verstehen, dass bei allen (?) Devices ... je länger ich mir die Zeile ansehe, desto klarer wird mir, dass ich die zweite Zeile auch nicht verstehe: Was wird da genau abgefragt? Auch Fenster-234? Und vor allem: Was löst das DOIF denn konkret aus? Und gilt das nur für Z-Wave?

Im neuen Jahr eine gute Tat: Es wäre sehr freundlich, wenn Du mir (und vielleicht auch späteren Lesern) ganz genau erklärst, was Du da machst. Und was es bewirkt. Ich danke Dir.

[MadMax-FHEM]

Die Batteriebetriebenen ZWave Geräte senden (zumindest die die ich habe) nur auf "Anfrage" einen Batteriewert.

Die Anfrage kannst du schicken "wann du willst", beantwortet wird sie, wenn das Gerät das nächste Mal "aufwacht" (wakeupReport interval 21600 target 1 -> alle 21600 Sekunden = 6h).

Dabei wird der "wakeup-Event" erzeugt, auf den "triggert" das DOIF (einzeln für verschiedene Geräte) und löst dann die Anfrage aus, die (meist) sofort beantwortet wird (da das Gerät ja [noch] wach ist).

Ich habe folgendes (etwas "ausladende" [weil auf viele/alle Geräte reagiert wird]) notify im Einsatz (gleiches Prinzip wie das DOIF):

Code Auswählen Erweitern

define nGetZWaveBattery notify .*.wakeup:.notification get $NAME battery


Das "at" von Rudolf König "platziert" (im Stack) einfach mal die Anfrage jeden Tag um 12:00 Uhr bzw. halt nur am Sonntag (oder war 0 jetzt der Montag?   ) und die Antwort kommt dann, wenn das Gerät aufwacht...

Gruß, Joachim

[curt]

Das "at" von Rudolf König "platziert" (im Stack) einfach mal die Anfrage jeden Tag um 12:00 Uhr bzw. halt nur am Sonntag (oder war 0 jetzt der Montag?   ) und die Antwort kommt dann, wenn das Gerät aufwacht...

Für das Wasser-Ei tut das auch recht schön: In diesen Winkel des Spitzbodens klettere ich einmal im Jahr.

Ich habe folgendes (etwas "ausladende" [weil auf viele/alle Geräte reagiert wird]) notify im Einsatz (gleiches Prinzip wie das DOIF):

Code Auswählen Erweitern

define nGetZWaveBattery notify .*.wakeup:.notification get $NAME battery

Auch das habe ich nicht verstanden.
Also alle Devices bekommen das? Die Z-Wave verstehen das, alle anderen Devices werfen das weg? Wie oft bekommen die das denn?

OT:
Ansich will man ja (zusätzlich) etwas ganz anderes noch: Ich habe hier gut 30 Devices mit Batterie, verschiedenste Funkprotokolle. Machen wir uns nichts vor: Nur zufällig merkt man, dass eine Device gestorben ist. Einen Room "hier sind die toten Devices, ist vermutlich leere Batterie" wäre ja schon schön.

[MadMax-FHEM]

Für das Wasser-Ei tut das auch recht schön: In diesen Winkel des Spitzbodens klettere ich einmal im Jahr.

Für nur ein Gerät ist das sicher auch ok...
Aber bei vielen naja...

Auch das DOIF muss für jedes neue Gerät angepasst/erweitert werden...
...außerdem reicht für die "Abfrage/Reaktion" auf EINEN Event auch ein Notify...
(Meine Meinung)

Auch das habe ich nicht verstanden.
Also alle Devices bekommen das? Die Z-Wave verstehen das, alle anderen Devices werfen das weg? Wie oft bekommen die das denn?

Dann mal bei den fhem Basics noch mal nachlesen

Die ZWave-Batterie-Geräte (wie gesagt zumindest die die ich kenne/habe) erzeugen einen Event auf den das Notify von mir "matched/triggert"...
...und zwar automatisch für alle ZWave-Batterie-Geräte (wiederhole: die die ich kenne/habe).

D.h. jedes neue ZWave-Batterie-Gerät (wenn es sich so verhält wie die die ich habe/kenne   ) wird automatisch "abgefragt" und zwar immer wenn es aufwacht (egal was bei Wakeup-Interval eingestellt ist), weil es eben dann den genannten Event gibt auf den das Notify "matched/triggert"

Wenn das dann triggert schickt es an das aufgewachte Gerät die Batterieanfrage und da das Gerät ja gerade (noch) wach ist wird diese (meist) auch gleich beantwortet...


Beim geposteten DOIF genauso, da sind halt alle Geräte einzeln aufgeführt...

Beim 'at' "wartet" die Abfrage halt solange im "Stack" bis das Gerät aufwacht...

OT:
Ansich will man ja (zusätzlich) etwas ganz anderes noch: Ich habe hier gut 30 Devices mit Batterie, verschiedenste Funkprotokolle. Machen wir uns nichts vor: Nur zufällig merkt man, dass eine Device gestorben ist. Einen Room "hier sind die toten Devices, ist vermutlich leere Batterie" wäre ja schon schön.

Dann evtl. mal da vorbei schauen: https://forum.fhem.de/index.php/topic,82637.msg747514.html#msg747514

Aber auch dafür brauchst du Batteriewerte bei den Geräten, also auch entweder: at, notify, DOIF, ...
...zumindest bei den ZWave-Batterie-Geräten.

EDIT: gut einen Raum habe ich nicht aber einen Dummy wo ich eine Übersicht aller Batteriegeräte habe, also bzgl. Batteriestand. Und ich lasse mich (aktueller Stand) rechtzeitig per Telegram benachrichtigen, wenn es Zeit wird Batterien zu kaufen (sofern nicht schon vorhanden) und diese dann zu wechseln... Meist warte ich damit bis die Geräte "tot" gemeldet werden...

Gruß, Joachim

[curt]

Für nur ein Gerät ist das sicher auch ok...
Aber bei vielen naja...

Ich glaube verstanden zu haben.
Dein Konstrukt sagt jedem Z-Wave-Gerät nach dem Aufwachen "Batteriestatus her!". Sehr schön, schon eingebaut. - Rudolfs Konstrukt sagt schon vorab meinem Wasser-Ei "beim Aufwachen hast Du die Aufgabe Batteriestatus".

Rudolfs Konstrukt ist (mir) gleichwohl wichtig: Das Wasserei liegt an einer Stelle mit eher wackliger Funkstrecke.

Dann evtl. mal da vorbei schauen: https://forum.fhem.de/index.php/topic,82637.msg747514.html#msg747514

Ganz vorsichtige Frage, da typisches Forum-Problem: Alle 14 Seiten durchlesen? Oder nur den ersten Beitrag abarbeiten?

Aber auch dafür brauchst du Batteriewerte bei den Geräten, also auch entweder: at, notify, DOIF, ...
...zumindest bei den ZWave-Batterie-Geräten.

Antwort gelöscht, siehe unten - da genauer.

EDIT: gut einen Raum habe ich nicht aber einen Dummy wo ich eine Übersicht aller Batteriegeräte habe, also bzgl. Batteriestand. Und ich lasse mich (aktueller Stand) rechtzeitig per Telegram benachrichtigen, wenn es Zeit wird Batterien zu kaufen (sofern nicht schon vorhanden) und diese dann zu wechseln... Meist warte ich damit bis die Geräte "tot" gemeldet werden...

Ich habe nichts davon. Kein Telegram, kein Signal, kein SMS, kein ... ich habe nur meinen Alu-Hut: FHEM muss der GRU nicht erzählen, welche Batterie wann platt ist. Für mich ist das auch gar nicht zielführend: Ich fahre doch nicht nach Hause, wenn mich die Nachricht ereilt, dass eine Batterie platt ist.

Aus meiner ganz bescheidenen Sicht wäre zielführend wenn ich das irgendwie in FHEM sehen könnte. Das muss gar kein Room sein: Ich spiele ganz offensiv mit FTUI, im Grunde würde es dort reichen. Ich weiß nicht - eine Pseudo-Device, die die verlorenen Devices aufsammelt? Würde sowas denn gehen? Jaja, mit at/doif/notify ...

[MadMax-FHEM]

Ich glaube verstanden zu haben.
Dein Konstrukt sagt jedem Z-Wave-Gerät nach dem Aufwachen "Batteriestatus her!". Sehr schön, schon eingebaut. - Rudolfs Konstrukt sagt schon vorab meinem Wasser-Ei "beim Aufwachen hast Du die Aufgabe Batteriestatus".

Rudolfs Konstrukt ist (mir) gleichwohl wichtig: Das Wasserei liegt an einer Stelle mit eher wackliger Funkstrecke.

Jep so in der Art...

Bin nicht sicher wieviel (Funk)Vorsprung die "at-Version" hat.
Denn es bleibt ja im Sendepuffer bei fhem...
...wenn das Gerät aufwacht wird entweder erst gesendet und dann der Event erzeugt (kleiner Vorteil 'at'   )...
...oder es wird der Event erzeugt und dann der Puffer geleert: Gleichstand

Ganz vorsichtige Frage, da typisches Forum-Problem: Alle 14 Seiten durchlesen? Oder nur den ersten Beitrag abarbeiten?

Keine Ahung, habe noch immer meinen eigenen Code...
...auf dem das mal basiert hat...

Evtl. warten bis es ein Modul geworden ist (falls nicht schon geschehen)...

Aber ich würde mal vermuten, dass im/in den ersten Post die aktuelle Version zu finden ist, die eigentlich funktionieren sollte...

Ich habe nichts davon. Kein Telegram, kein Signal, kein SMS, kein ... ich habe nur meinen Alu-Hut: FHEM muss der GRU nicht erzählen, welche Batterie wann platt ist. Für mich ist das auch gar nicht zielführend: Ich fahre doch nicht nach Hause, wenn mich die Nachricht ereilt, dass eine Batterie platt ist.

Tja dann...

Wobei ich auch nicht nach Hause stürme, wenn die Nachricht kommt.
Habe es ja "zweistufig": Warnung bei "low" bzw. einem niedrigen Prozentwert (da schaue ich dann schon mal, ob passende Batterien da sind oder nehme auf dem Heimweg welche mit   ) und dann bei "dead" (macht Homematic automatisch, für ZWave etc. hab ich mir ein 'at' "gebastelt") wird getauscht (gut manchmal auch schon vorher   ).

Aus meiner ganz bescheidenen Sicht wäre zielführend wenn ich das irgendwie in FHEM sehen könnte. Das muss gar kein Room sein: Ich spiele ganz offensiv mit FTUI, im Grunde würde es dort reichen. Ich weiß nicht - eine Pseudo-Device, die die verlorenen Devices aufsammelt? Würde sowas denn gehen? Jaja, mit at/doif/notify ...

Jep, entweder selbst was mit at, notify, DOIF, ... "basteln" oder einfach da wo die Nachricht geschickt wird ein "setreading MyFTUI-BatteryDummy Gerätename" dann würde dort eben das Gerät drin stehen, welches gerade etwas mit der Batterie schwächelt.
Beim Zurücksetzen (also Batterie wieder voll) halt den Dummy bzw. das Reading löschen/zurücksetzen...

In dem Zuge schreibe ich die Daten auch in einen weiteren Dummy: Haltbarkeit (somit sehe ich auch wie lange die Batterien gehalten haben)

Viel Spaß/Erfolg, Joachim

[curt]

Keine Ahung, habe noch immer meinen eigenen Code...
...
Habe es ja "zweistufig": Warnung bei "low" bzw.
...
und dann bei "dead"

Mal für uns beide alte Betschwestern: Spricht etwas dagegen, dass Du stolz im Forum Deinen Code "so geht das!" zeigst?

Jep, entweder selbst was mit at, notify, DOIF, ... "basteln" oder einfach da wo die Nachricht geschickt wird ein "setreading MyFTUI-BatteryDummy Gerätename" dann würde dort eben das Gerät drin stehen, welches gerade etwas mit der Batterie schwächelt.

Um diesen Code-Vorschlag bitte ich Dich dann später.

Beim Zurücksetzen (also Batterie wieder voll) halt den Dummy bzw. das Reading löschen/zurücksetzen...

Ich weiß nicht mehr, wie ich das machte, ich habe auch das nur abgeschrieben: Es gibt pauschal für alle Devices ein Attribut "wann Batterie neu eingelegt". Wenn ich eine Batterie neu einlege, ändere ich das attr zu "2019-01-04". (Auch damit könnte man was machen.)

Viel Spaß/Erfolg, Joachim

Mit Deiner Hilfe Joachim - um die ich Dich bitte.
Und nicht nur für mich: Aus meiner Sicht krankt das Forum an "ich zeige Dir nicht, wie ich das löste, nimm aber mal meinen Tipp". Ja, kann man machen. Ich will aber nicht wissen, wie viele sich in der Zeit genervt abwendeten.

Bitte hilf mir. Zeige mir einfach, wie Du das gelöst hast. Und wie Du das lösen würdest, wenn Du einen Room ...

[MadMax-FHEM]

Mal für uns beide alte Betschwestern: Spricht etwas dagegen, dass Du stolz im Forum Deinen Code "so geht das!" zeigst?

Habe ich längst getan (indirekt   ), ist im ersten Post des verlinkten Threads verlinkt
Hier noch mal direkt: https://forum.fhem.de/index.php/topic,75571.msg740976.html#msg740976

Aber ich fürchte der wird wohl noch weniger passen (mittlerweile haben sich auch einige von den Readings bzgl. Batterie geändert -> Vereinheitlichung[sversuch]) als der direkt verlinkte Code...

EDIT: ich habe mir den verlinkten Post mal angesehen. Da die "Scripte" von github heruntergeladen werden müssen nehme ich schwer an, dass die zusammen mit der Beschreibung des ersten Posts aktuell sind und (wenn deine Umgebung nicht allzu "exotisch" ist) funktionieren sollte. Noch dazu wo der Threadersteller (Amenophis86) auch weiterhin für die Vereinheitlichung von Batterie-Readings "kämpft"...
Aber nicht vergessen: damit das funktioniert braucht es Aktualisierungen der Batterie-Readings!

Um diesen Code-Vorschlag bitte ich Dich dann später.

Das wird so nicht gehen, weil ich deine Geräte(typen) nicht kenne, deine Benamungsvorgehensweise nicht kenne und FTUI schon gar nicht kenne, also nicht weiß was dort "schick" bzw. geschickt ist...

Ich weiß nicht mehr, wie ich das machte, ich habe auch das nur abgeschrieben: Es gibt pauschal für alle Devices ein Attribut "wann Batterie neu eingelegt". Wenn ich eine Batterie neu einlege, ändere ich das attr zu "2019-01-04". (Auch damit könnte man was machen.)

Ja man kann alles manuell machen: Heizung aufdrehen, Licht an-/aus machen, ...
Aber es heißt (für mich) Hausautomatisierung weil ich eben so wenig wie möglich/nötig manuell erledigen will
Daher: wenn ich schon automatisch überwache/mitkriege, dass die Batterie leer ist (und ich mich benachrichtigen lasse/es mir anzeigen lasse) und ich dann auch erkenne, dass sie wieder voll (also wohl gewechselt wurde) ist, kann ich mir das doch auch einfach "notieren lassen"

setreading in einen Dummy und gut

Mit Deiner Hilfe Joachim - um die ich Dich bitte.
Und nicht nur für mich: Aus meiner Sicht krankt das Forum an "ich zeige Dir nicht, wie ich das löste, nimm aber mal meinen Tipp". Ja, kann man machen. Ich will aber nicht wissen, wie viele sich in der Zeit genervt abwendeten.

Dagegen sprechen einige Dinge:

1. wenn du nie nichts lernst und selber erstellt hast, verstehst du auch nicht/kaum, wenn etwas nicht klappt: warum das (plötzlich) nicht (mehr) klappt...

2. du kommst bei jeder Anpassung und frägst nach fertigem Code bzw. Erweiterungen. Spätestens wenn der Ersteller keine Lust mehr hat oder gar fhem an den Hut gehangen hat stehst du ganz schlecht da... Denn ein Codeschnipsel ist kein Modul.

3. das mag bei einfachen Dingen manchmal "doof" sein. Also warum nicht einfach das fertige Notify posten statt sowas wie: ich würde ein Notify nehmen etc. Oder: schau mal bei Notify... Ja verständlich. Aber auch hier: magst du lieber Notify oder DOIF oder hältst du von beidem nichts. Wenn dann eine fertige Notify-Lösung kommt, du aber lieber oder nur DOIF hast/magst, dann war "meine Mühe" umsonst... (Nur als Beispiel). Auch deine Namensgebung kennen andere nicht. Ebensowenig wie die vorhandenen Events, bereits eingesetzten Module, ... Daher ist konkrete Hilfe schwer.


Auch der Code von mir funktioniert halt unter meiner Umgebung mit meinem Zoo an Geräten und auch mit meinem Stil wie ich Dinge löse.
Ich mache (fast) alles mit Notify und Funktionen/Subs in myUtils...
Ginge genausogut mit DOIF.
Für manches was ich mir "gebastelt" habe gibt es vermutlich mindestens ein Modul was das schon macht und verm. mehr...

Bitte hilf mir. Zeige mir einfach, wie Du das gelöst hast. Und wie Du das lösen würdest, wenn Du einen Room ...

Siehe zuvor...

Hier kann ich nur einen Tipp geben (gilt vermutlich für das direkt verlinkte Codeschnipsel was auf meinem basiert und auch auf meinem "Basis-Code"):

an die Stelle wo ein Aufruf eines Messagedienstes kommt (z.B. set Telegram message Batterie von Gerät $Device ist leer!) einfach ein "setreading myFTUIBattAnzeige $Device" (wobei eben "myFTUIBattAnzeige" ein Dummy wäre).
Ob das für FTUI passt weiß ich nicht...

Damit fallen dann (zumindest bei meinem Code) auch die Aufrufe weg, wo ich mir (in einem Dummy) merke, dass ich die Nachricht bereits verschickt habe (damit die nicht ständig kommt)...
Weil das bei der Anzeige vermutlich "egal" ist...

EDIT2: für den verlinkten Code von Amenophis86 könnte folgendes klappen:
statt:

Code Auswählen Erweitern


# TelegramBot
  my $msg = "set TelegramBot message \@\@User ";


das hier:

Code Auswählen Erweitern


# TelegramBot
  my $msg = "setreading myFTUIBatteryDummy Batteriestatus";


Und wenn die Texte die dann dort im Dummy stehen nicht gefallen/passen, dann diese auch anpassen:

Code Auswählen Erweitern


  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_motorErrValve = "Der Motor kann sich nicht mehr bewegen!"; #Text for motorErr ValveErrorPosition only HM


EDIT3: setzt voraus, dass wenn in dem Dummy "myFTUIBatteryDummy" als Reading "Batteriestatus" der Text bzgl. "Batterieschwäche" vom Gerät ($Device) ein Text steht für deine Zwecke ok ist...

Gruß, Joachim

[rudolfkoenig]

Rudolfs Konstrukt ist (mir) gleichwohl wichtig: Das Wasserei liegt an einer Stelle mit eher wackliger Funkstrecke.

Wie Joachim das schon kommentiert hat: aus dieser Hinsicht ist "mein at" kein Deut besser als sein notify: beide reagieren auf dem gleichen "wakeup:notify" ZWave-Telegramm vom Geraet.

Aber ich fürchte der wird wohl noch weniger passen (mittlerweile haben sich auch einige von den Readings bzgl. Batterie geändert -> Vereinheitlichung[sversuch]) als der direkt verlinkte Code...

Im ZWave Modul habe ich keine bestehende Readings geaendert, nur Neue hinzugefuegt.

[MadMax-FHEM]

Im ZWave Modul habe ich keine bestehende Readings geaendert, nur Neue hinzugefuegt.

Jep stimmt, habe ich gemerkt, daher musste ich bei mir nichts ändern bzgl. ZWave

Gruß, Joachim