Helferlein/Komfortfunktionen

[scooty]

Hallo zusammen,

ausgehend von diesem Thema möchte ich hier in diesem Thread eine Übersicht von kleinen Helferlein/Komfortfunktionen zur Konfiguration/Verwaltung von ZWave-Devices zusammenstellen. Was genau damit gemeint ist, wird sicherlich aus den unten stehenden Beispielen deutlich.

Ich möchte euch um tatkräftige Unterstützung bitten, ich bin mir sicher, dass bei dem geballten Wissen hier viele sich schon Gedanken gemacht haben und es wäre sehr nett, wenn sich viele beteiligen.
Also postet bitte hier:
- Wünsche nach neuen Komfortfunktionen/Helferlein
- Lösungen für noch offene Wünsche

Im diesem ersten Beitrag werde ich versuchen, alles zusammenzufassen und auf dem aktuellen Stand zu halten (wenn genügend zusammenkommt kann ich diese Infos auch ins Wiki überführen).

Vielen Dank für eure Unterstützung,
Andreas

===============================
1) Automatisches "get configxxxx" nach einem "set configxxx"
Detail:
Um die Readings nach einem "set <device> configxxx" auf den neuen Stand zu bringen ist ein manuelles "get <device> configxxx" nötig.
Lösung:
In  diesem Beitrag beschreibt rudolfkoenig eine Lösung mit notify:

Code Auswählen Erweitern

define configGet notify .*:config[^:]* get $NAME $EVTPART0

2) Versionsabfrage der CommandClasses über alle Classes eines Devices
Detail:
Es ist möglich, mit "get <device> versionClass <Class>" die Version einer einzelnen aber nicht aller CommandClass eines Devices abzufragen.
Lösung:
Mit Implementierung von "set <device> versionClassRequest" für ZWave+ (?) Devices möglich (s. CommandRef/Zwave/Set/Class VERSION/versionClassRequest und dieser Beitrag)

3) Abruf aller Config-Parameter eines Devices
Detail:
Bisher ist es nur möglich, mit "get <device> configxxx" einen einzelnen Konfigurationsparameter abzufragen.
Lösung:
Auf ToDoListe von rudolfkoenig (s. dieser Beitrag) als "get <device> configAll".
Aber vielleicht hat ja jemand schon entsprechenden Code parat (z.B. in seiner 99_myUtils.pm)?

4) Auslösen von Neighborupdate auf Node nach: set <dongle> neighborupdate <Node>
Detail:
Zur vollständigen Erstellung neuer Routen im ZWave-Netzwerk ist das neighborupdate auf Dongle UND Node erforderlich (stimmt das noch so?)
Lösung:
Noch offen.

5) Vergleich/Anpassung der Konfigurationsparameter gleicher ZWave-Devices
Detail:
Manchmal möchte man gleiche Typen von Devices auch mit den gleichen Konfigurationsparametern betreiben. Dazu wäre es hilfreich, ein Helferlein zum Vergleich bzw. Setzen von Konfigurationsparametern auf zwei (oder mehr?) gleichen Devices nutzen zu können.
Lösung:
Noch offen.

6) Erzeugung/Aktualisierung der ZW-Dongle-Readings neighborList_x und nodeInfo_x anhand des Readings nodelist
Detail:
Die Readings neighborList_x und nodeInfo_x eines ZW-Dongles werden bisher nur über entsprechende, einzelne Kommandos aktualisiert. Ein Helferlein könnte z.B. nach dem Inhalt des Reading "nodelist" die Infos zu neighborList  und und nodeInfo für alle Nodes komplett abfragen.
Lösung:
Noch offen.

7) Abruf aller ASSOCIATION-Readings eines Devices
Detail:
Bisher ist es nur möglich, mit "get <device> association <groupId>" eine einzelne Association-Group abzufragen.
Lösung:
Auf ToDoListe von rudolfkoenig (s. dieser Beitrag) als "get <device> associationAll".
Aber vielleicht hat ja jemand schon entsprechenden Code parat (z.B. in seiner 99_myUtils.pm)?

8 ) ...

[krikan]

4) Auslösen von Neighborupdate auf Node nach: set <dongle> neighborupdate <Node>
Detail:
Zur vollständigen Erstellung neuer Routen im ZWave-Netzwerk ist das neighborupdate auf Dongle UND Node erforderlich (stimmt das noch so?)

Hallo Andreas,
bei einem Controller und Geräten mit aktuellem SDK (4.5x und größer 6.x) sollte sich das Problem der zwingenden manuellen neighbourUpdates wegen Nutzung von Explorer Frames in aktuellen Fhem-Versionen abmildern. Die Routen korrigieren sich quasi automatisch. Jedoch wage ich noch nicht zu behaupten, dass neigbourUpdates komplett überflüssig zur Optimierung sind.
Bei Controllern und Geräten mit SDK 5.x, das keine Explorer Frames unterstützt, sind die updates zwingend. Typisches Beispiel für einen betroffenen Controller ist der "alte" Aeotec S2.
Also noch erforderlich, wobei ich bei der notwendigen Wiederholung pro Node keine Vorstellung habe.
Gruß, Christian

[micha80]

6) Erzeugung/Aktualisierung der ZW-Dongle-Readings neighborList_x und nodeInfo_x anhand des Readings nodelist

Für 6. hätte ich eine Lösung als shell script, nicht schön, aber funktionell

Code Auswählen Erweitern


#!/bin/sh

cd /opt/fhem

OLDFILE="/tmp/zwave-neighborLists_old_$(date +%Y-%m-%d_%H-%M).txt"
NEWFILE="/tmp/zwave-neighborLists_new_$(date +%Y-%m-%d_%H-%M).txt"

DEVS=$(./fhem.pl 7072 "get ZWDongle_0 nodeList"|cut -d ">" -f 2 |sed 's/,/ /g')
echo "devs: $DEVS"
echo $(date) |tee -a $OLDFILE

for DEV in $DEVS; do
  echo update $DEV
  ./fhem.pl 7072 "get ZWDongle_0 neighborList $DEV" |tee -a $OLDFILE
  ./fhem.pl 7072 "set ZWDongle_0 neighborUpdate $DEV"
  sleep 1
  ./fhem.pl 7072 "get ZWDongle_0 neighborList $DEV" |tee -a $NEWFILE
  # ./fhem.pl 7072 "get ZWDongle_0 nodeInfo $DEV"
done

echo finish
echo diffing $OLDFILE $NEWFILE
diff $OLDFILE $NEWFILE



[rudolfkoenig]

2. Soweit ich es sehe, ist die Versionabfrage von Klassen Bestandteil aller Geraete, sobald die Klasse VERSION unterstuetzt ist (sonst waere es echt doof, wg. Henne/Ei), insofern sollte versionClassRequest fuer alle Geraete funktionieren.

3) ab sofort (bzw. ab morgen per update) gibt es ein "set device configRequestAll", funktioniert allerdings nur fuer Geraete, deren "model" in der openzwave-Konfigurationsdatenbank bekannt ist.

7) weiterhin gibt es ein "set device associationRequestAll", der zunaechst Anzahl der associationGroups abholt (auch neu), und dann fuer alle sinnvollen Gruppen die association.

@krikan: configRequestAll hat bei einem "always-on" Geraet 19 Befehle ins Stack gesteckt, und das Automat in ZWDongle an das Dongle weitergeschickt. Allerdings kamen ab dem dritten (?) Befehl sofort CANs zurueck, und diese wurden de-facto verworfen, auch wenn das Modul diese 4-mal an das Geraet geschickt hat. Ich habe jetzt nach jedem CAN eine Pause von 0.1 Sekunden eingebaut, damit klappt es bei mir. Mit 0.05 hatte ich eine Erfolgsrate von 80%.

[krikan]

@krikan: configRequestAll hat bei einem "always-on" Geraet 19 Befehle ins Stack gesteckt, und das Automat in ZWDongle an das Dongle weitergeschickt. Allerdings kamen ab dem dritten (?) Befehl sofort CANs zurueck, und diese wurden de-facto verworfen, auch wenn das Modul diese 4-mal an das Geraet geschickt hat. Ich habe jetzt nach jedem CAN eine Pause von 0.1 Sekunden eingebaut, damit klappt es bei mir. Mit 0.05 hatte ich eine Erfolgsrate von 80%.

@rudolfkoenig
Rudi, verstehe den Bezug gerade nicht. Soll ich etwas testen oder willst Du Gemecker von mir vorbeugen oder ...? Gruß Christian

[rudolfkoenig]

Ich wollte nur, dass dir das bekannt ist, wenn irgendwelche neue Probleme auftauchen sollten.