ZWave Neighbours - Verständnisfrage

[shady88]

Hallo, ich habe zurzeit folgende Komponenten mit den zugehörigen IDs


Obergeschoß
Fibaro Roller Shutter 2
ID: 10
ZWave Dongle
CtrlNodeId:01

Untergeschoß
2x Everspring SP103 PIR Motion Sensor
ID: 14
ID: 12
4xFIBARO System FGK101 Door Opening Sensor
ID: 0d
ID: 0e
ID: 0f
ID: 13
FIBARO System FGMS001 Motion Sensor
ID: 0a
Sirene
ID: 0b
2x FIBARO System FGS222 Double Relay Switch 2x1.5kW
ID: 07
   0701   0702
ID: 0c
   0c01 0c02
Keller
Fibaro Stecker
ID: 06

Sind die hexadezimal Zahlen in Ordnung?



Alle Komponenten sind erreichbar - Sogar der Stecker im Keller und die Sirene in der Garage, die weit weg vom USB-Stick (ZWave.me USB-Stick, USB-Dongle) ist.
D.h. für mich, das ZWave Meshnetzwerk funktioniert.
Was nicht funktioniert sind die zwei Bewegungsmelder von Everspring. Nur sehr unregelmäßig kommt die erkannte Bewegung bzw. der Manipulationsalarm in FHEM an. Ich vermute mal, es gibt hier ein Reichweitenproblem, obwohl ein Fibaro Schalter gleich daneben ist, welcher im Untergeschoß direkt unter dem im Obergeschoß vorhanden ZWave-Dongle steht (Hier gibt es also keine Probleme, Befehle werden zum Schalter hin quasi verzögerungsfrei gesendet und umgesetzt!)

Ich wollte mir die NeighborList ansehen und hier weiß ich jetzt gerade nicht weiter. Der Dongle sollte doch alle Nodes sehen, die in der Nähe von ihm sind - Ist das richtig? Bei mir wäre das auf jeden Fall Node 07, 08 und 10 - Achtung, das sind die IDs und anscheinend nicht das, was jetzt gleich kommt:
Wenn ich ein

Code Auswählen Erweitern

get ZWDongle_0 neighborList 1
mache, kommt dieses Ergebnis

Code Auswählen Erweitern

ZWDongle_0 neighborList_1 => 2,3,4,5,6,7,8
Keine Ahnung was das alles ist. Anscheinend hängt das auf jeden Fall nicht mit den von mir geposteten IDs zusammen.

Code Auswählen Erweitern


get ZWDongle_0 nodeList
ZWDongle_0 nodeList => 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,18,19,20

Wie ordne ich jetzt diesen Nodes das richtige Gerät zu? Damit ich mal weiß, welcher Nachbar da eigentlich gemeint ist? Ich finde kein Feld, wo diese Werte drin vorkommen :/

Code Auswählen Erweitern

get ZWDongle_0 nodeInfo 14
ZWDongle_0 nodeInfo_14 => ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
get ZWDongle_0 nodeInfo 3
ZWDongle_0 nodeInfo_3 => SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
Viel kann ich hier nicht erkennen :/ Die Sleeping Nodes sind wahrscheinlich die batteriebetriebenen Geräte.


Wenn ich das dann herausgefunden habe - Muss ich einem Gerät mit Netzbetrieb irgendwie mitteilen, dass in seiner Nähe jetzt ein batteriebetriebenes Gerät ist? Bzw. muss ich dem Netzbetrieb Gerät mitteilen, dass es doch bitte die Befehle von anderen Geräten weiterleiten mag?
Mir kommt vor, als würden die Everspring Bewegungsmelder direkt an den Zwave-Dongle senden und deswegen kommt es nur manchmal an. Kann das sein?

Die Bewegungsmelder sind gar nicht soweit weg vom Zwave-Dongle - Ein Stockwerk ist dazwischen, sonst sind die beiden fast übereinander.

Sorry für die vielen Fragen - Aber mir kommt vor, als fehle mir nur noch dieses eine Puzzleteil zum Verständnis. Auch wenn das Teil recht groß ist.

[krikan]

Die ids in den Internals ist hex, während nodeList dez-Werte angibt. Also einfach umrechnen und Du hast die Zuordnung.

Könntest Du bitte einmal für Everspring SP103 PIR die Ausgabe von "get <device> version" posten. In pepper1 steht der mit SDK 4.22 drin. Das kann noch keine Explorer Frames zur automatischen Optimierung der Routen nutzen und man müsste mit "set <device> neigborUpdate" die Routen aktualisieren. Das ist aber sowieso keine schlechte Lösung, es für alle nodeIds mehrfach durchlaufen zu lassen.

Du hast auch jede Menge NodeIds in der nodeList, die keiner id in den Internals entsprechen. Fehlen Geräte oder ist das Gateway gebraucht?

[shady88]

Die ids in den Internals ist hex, während nodeList dez-Werte angibt. Also einfach umrechnen und Du hast die Zuordnung.

Autsch...da hätte ich selbst drauf kommen können. Danke!
Mich wundert aber, dass die Everspring die IDs 12 und 14 haben und einer der Schalter hat 0c (also 12) und ein Türsensor 0e (14) hat. Kann es da ein Problem geben?
Zwei Türsensoren sind auch "gleich": 0d und 13. - Funktionieren aber beide.

Könntest Du bitte einmal für Everspring SP103 PIR die Ausgabe von "get <device> version" posten. In pepper1 steht der mit SDK 4.22 drin. Das kann noch keine Explorer Frames zur automatischen Optimierung der Routen nutzen und man müsste mit "set <device> neigborUpdate" die Routen aktualisieren. Das ist aber sowieso keine schlechte Lösung, es für alle nodeIds mehrfach durchlaufen zu lassen.

Code Auswählen Erweitern

Scheduled for sending after WAKEUP
*Hust* Das versteh ich auch noch nicht. Ein batteriebetriebenes Gerät meldet alle X Zeiteinheiten an den Dongle. Dann kann der Dongle etwas abfragen oder das Gerät "schläft" wieder. Wenn ich, so wie jetzt, etwas von dem Gerät wissen will, dann muss ich warten, bis es wieder erwacht. Ist ein Aufwecken dann auch eine Bewegung, die der Sensor erkennt?
Ich hab jetzt den Sensor neben dem Dongle stehen und die Bewegung wird erkannt und an FHEM gemeldet und dort angezeigt. Der GET Befehl vom Schedule wurde aber anscheinend nicht abgefragt - Ich hab noch keine Version.
Leider weiß ich auch nicht, wie oft das Ding munter wird.
Das fehlt mir auch bei anderen Geräten. Manche bieten an, das WakeUp Interval zu erfragen. Aber es kommt dann nie an. Im Forum habe ich gelesen, dass es immer wieder zu Problemen mit Get-Abfragen kommt, wenn das Gerät schläft. Ist das immer noch so?

Zurück zum Everspring:

Code Auswählen Erweitern


Internals
...
isWakeUp    1
Das seh ich immerhin. Konnte in der Commandref dazu nichts finden. Ich nehm an, dass das bedeutet, dass die Wake Funktion aktiv ist.

Readings:

Code Auswählen Erweitern


alarm_type_01 level 11 2015-09-29 18:48:56
basicSet 00 2015-09-30 20:21:24
model Everspring SP103 PIR Motion Sensor 2015-09-29 18:15:26
modelConfig everspring/sp103.xml 2015-09-29 18:15:26
modelId 0060-0101-0001 2015-09-29 18:15:26
state associationAdd 1 01 2015-09-29 18:15:25
transmit OK 2015-09-29 18:15:28

Ich hab das Ding gestern neu hinzugefügt. Deswegen sind alle Readings, bis auf basicSet (das ist die Bewegung die erkannt wird) von gestern zur selben Zeit. Seit dem ist nichts mehr gekommen. Beim zweiten Sensor sind die letzten Einträge vom 21.9. - Da wurde er hinzugefügt. Gibts da also überhaupt eine Wakeup? Oder hängt das damit nicht zusammen?

Du hast auch jede Menge NodeIds in der nodeList, die keiner id in den Internals entsprechen. Fehlen Geräte oder ist das Gateway gebraucht?

Nein, ist nicht gebraucht (davon gehe ich aus, beim Neukauf). Ich hab versucht alle Geräte abzubilden und glaube keines vergessen zu haben.

[krikan]

Mich wundert aber, dass die Everspring die IDs 12 und 14 haben und einer der Schalter hat 0c (also 12) und ein Türsensor 0e (14) hat. Kann es da ein Problem geben?

Das verwirrt mich auch.
Werfe ich gerade etwas durcheinander? Rudi?

*Hust* Das versteh ich auch noch nicht. Ein batteriebetriebenes Gerät meldet alle X Zeiteinheiten an den Dongle. Dann kann der Dongle etwas abfragen oder das Gerät "schläft" wieder. Wenn ich, so wie jetzt, etwas von dem Gerät wissen will, dann muss ich warten, bis es wieder erwacht. Ist ein Aufwecken dann auch eine Bewegung, die der Sensor erkennt?
Ich hab jetzt den Sensor neben dem Dongle stehen und die Bewegung wird erkannt und an FHEM gemeldet und dort angezeigt. Der GET Befehl vom Schedule wurde aber anscheinend nicht abgefragt - Ich hab noch keine Version.
Leider weiß ich auch nicht, wie oft das Ding munter wird.

Normal.

Das fehlt mir auch bei anderen Geräten. Manche bieten an, das WakeUp Interval zu erfragen. Aber es kommt dann nie an. Im Forum habe ich gelesen, dass es immer wieder zu Problemen mit Get-Abfragen kommt, wenn das Gerät schläft. Ist das immer noch so?

Nein.
http://www.fhemwiki.de/wiki/Z-Wave#batteriebetriebene_Ger.C3.A4te

Schaue wegen id noch mal in den Code....

[krikan]

Das verwirrt mich auch.
Werfe ich gerade etwas durcheinander? Rudi?

Schaue wegen id noch mal in den Code....

Sollte mich nicht verwirren lassen  :
12 hex = 18 dec
14 hex = 20 dec
0c hex = 12 dec
0e hex= 14 dec
-> also keine Überschneidungen

[shady88]

Das verwirrt mich auch.
Werfe ich gerade etwas durcheinander? Rudi?

Sollte mich nicht verwirren lassen  :
12 hex = 18 dec
14 hex = 20 dec
0c hex = 12 dec
0e hex= 14 dec
-> also keine Überschneidungen

Sorry, dass ich dich verwirrt habe. Jetzt wirds ja mal so richtig peinlich für mich Aber ich hoffe, das passt jetzt

Normal.
Nein.
http://www.fhemwiki.de/wiki/Z-Wave#batteriebetriebene_Ger.C3.A4te

Schaue wegen id noch mal in den Code....

Meinst du, du siehst nach?

Ich warte jetzt mal, ob die Version bis morgen Abend zurückkommt. Wenn nicht, dann muss ich irgendwie versuchen, das manuell zu erzwingen bzw. das Interval auf 60 Sekunden zu setzen. Wie ich das mache weiß ich noch nicht so ganz. Mal abwarten.
Derzeit ist noch nichts da.

[krikan]

Jetzt wirds ja mal so richtig peinlich für mich

Oder mich 

Schaue wegen id noch mal in den Code....

Das bezog sich auf unsere id-Verwirrung; ist also erledigt.

Ich warte jetzt mal, ob die Version bis morgen Abend zurückkommt. Wenn nicht, dann muss ich irgendwie versuchen, das manuell zu erzwingen bzw. das Interval auf 60 Sekunden zu setzen.

Die Richtung gibt Dir der oben verlinkte Wiki-Abschnitt vor. Habe den eben noch um einige Deiner Unklarheiten ergänzt; hoffe es ist verständlich. Details für Deinen Sensor musst Du im Handbuch raussuchen.

Würde an Deiner Stelle:
-Sensoren richtig konfigurieren (wakeUpInterval)
-nicht vorhanden Nodes auf der nodeLiszt löschen (removeFailedNode)
-Routen aller Nodes mehrfach optimieren (neigborUpdate)

Das sollte schon mal helfen, ansonsten Fragen stellen  .

[rudolfkoenig]

Dass (gefuehlt) die Haelfte der Funktionen Hex ausgibt, die andere Haelfte Dezimal, nervt mich auch, allerdings habe ich bisher daver zurueckgeschreckt alles auf dezimal umzustellen, weil es dabei leicht zu weiteren Verwirrungen kommen kann.
Wenn ich aber von euch motiviert werde, dann werde ich es auf die TODO Liste setzen.

[krikan]

...allerdings habe ich bisher daver zurueckgeschreckt alles auf dezimal umzustellen, weil es dabei leicht zu weiteren Verwirrungen kommen kann.
Wenn ich aber von euch motiviert werde, dann werde ich es auf die TODO Liste setzen.

-> Motivier!
Halte eine klare Linie für sinnvoll, auch wenn es vorübergehend (eventuell) zu Verwirrungen führt.

Einigung für Zukunft also auf dezimal.

[shady88]

Standardmäßig sollte das Ding alle 4 Stunden wach werden, aber ich hab es jetzt erzwungen, da über nachts nichts gekommen ist.
Beim Everspring SP103 muss man dreimal auf den Tamper-Button drücken, dann wacht er auf.
Hab mir folgende Infos geholt:

Code Auswählen Erweitern

Readings
CMD ZW_APPLICATION_UPDATE 2015-10-01 17:00:57
alarm_type_01 level 11 2015-10-01 16:52:10
basicReport 00 2015-10-01 16:58:48
basicSet 00 2015-10-01 17:00:52
battery 100 % 2015-10-01 16:52:13
model Everspring SP103 PIR Motion Sensor 2015-10-01 16:52:51
modelConfig everspring/sp103.xml 2015-10-01 16:52:51
modelId 0060-0101-0001 2015-10-01 16:52:51
state associationAdd 1 01 2015-09-29 18:15:25
transmit OK 2015-10-01 17:00:57
version Lib 6 Prot 2.9 App 1.0 2015-10-01 16:52:14
wakeupReport interval 14400 target 255 2015-10-01 16:53:11

Die Befehle in der Queue hat er alle sauber verarbeitet im ersten Versuch.
Pepper1 war mir unbekannt. Ganz nette Datenbank, aber die von dir erwähnte Version des SDKs kann ich nirgends finden. http://www.pepper1.net/zwavedb/device/59

Wie bring ich jetzt den Everspring dazu, dass er den Fibaro Switch als seinen nächsten Neighbor ansieht und er über den seine Befehle verschickt? (Ist die Fragestellung richtig oder geht das gar nicht?)

Soweit ich es verstanden habe, kann ich "nur" ein set ZWDongle_0 neighborUpdate 0c (0c ist der Fibaro-Schalter) machen. Aber wie weiß der dann, dass der Everspring sein Nachbar ist bzw. der Everspring, dass der Fibaro sein Nachbar ist (mit set ZWDongle_0 neighborUpdate 14 wäre eine Möglichkeit, aber das klingt eher danach, dass er ein Nachbar vom ZWDongle_0 ist)
Wenn ich 14 (Everspring) und 0c (Fibaro) als Nachbar haben möchte, sollten ja beide davon Bescheid wissen. Zumindest 14 (Everspring)

Dass (gefuehlt) die Haelfte der Funktionen Hex ausgibt, die andere Haelfte Dezimal, nervt mich auch, allerdings habe ich bisher daver zurueckgeschreckt alles auf dezimal umzustellen, weil es dabei leicht zu weiteren Verwirrungen kommen kann.
Wenn ich aber von euch motiviert werde, dann werde ich es auf die TODO Liste setzen.

*motivier*
Wäre wirklich nicht schlecht. Wenn daneben ein "hex" stehen würde wenn du es nicht auf Dezimal ändern möchtest wäre mir auch schon geholfen. Aber einfach auf Dez umstellen wäre am Besten!

[krikan]

wakeupReport interval 14400 target 255 2015-10-01 16:53:11

Bitte auf ControllerNodeId ändern.
Assoziation mit dem Controller kontrollerien.
Details dazu findest Du im Wiki.

aber die von dir erwähnte Version des SDKs kann ich nirgends finden.

Ergibt sich aus im Internet verfügbaren Übersetzungstabellen  ProtId->SDK. Prot 2.9 entspricht dem SDK 4.22 müsste so aus 2006/7 stammen. Also ein wenig älter. Kann definitiv keine Explorer Frames und erklärt ggfs. Problembild-> blöd.

Wie bring ich jetzt den Everspring dazu, dass er den Fibaro Switch als seinen nächsten Neighbor ansieht

Für alle NodeIDs/Geräte  "set ZWDongle_0 neighborUpdate <NodeID>" absetzen. Batteriebetriebene Geräte zur Verarbeitung des Sendstacks aufwecken. (hoffen und nachsehen, dass es an den derzeitigen Positionen der Geräte keine Empfangsprobleme gibt.)

Dann das ganze Spiel noch einmal und noch einmal. So zumindest die Theorie. Dann hast Du hoffentlich schon Erfolg.

Die Aktivierung eines SUC auf dem Controller soll auch hilfreich sein. Ob der an ist, kann man mit "get ZWDongle_0 ctrlCaps" abfragen. Details dazu nur, wenn es mit dem obigen neigborUpdate nicht funktioniert.

[feeeem]

Hallo krikan,

Ergibt sich aus im Internet verfügbaren Übersetzungstabellen  ProtId->SDK. Prot 2.9 entspricht dem SDK 4.22 müsste so aus 2006/7 stammen.

Kannst Du einen Link zu solch einer  Übersetzungstabelle posten?
Ich würde gerne auch mal die SDK Versionen meiner Module kennen.
Habe einen Everspring ST814 mit version "Lib 6 Prot 2.64 App 1.6", klingt auch alt, oder?

[krikan]

Kannst Du einen Link zu solch einer  Übersetzungstabelle posten?

http://wiki.micasaverde.com/index.php/ZWave_Protocol_Version
Oder nach sdkids.xml in der Suchmaschine Deines Vertrauens suchen.
Es gibt kein (für mich) erkennbares logisches System bei der Vergabe.

[rudolfkoenig]

Hex->Dezimal Umbau:

Nach Studium der Quellen bin ich nicht so recht fuendig geworden. Ich habe das Internal id in nodeIdHex umbenannt, die anderen Zahlen sollten aber dezimal eingegeben bzw. dargestellt werden. Koennt ihr mir eine weitere Stellen nennen, die umgebaut werden muessen?

[shady88]

Hex->Dezimal Umbau:

Nach Studium der Quellen bin ich nicht so recht fuendig geworden. Ich habe das Internal id in nodeIdHex umbenannt, die anderen Zahlen sollten aber dezimal eingegeben bzw. dargestellt werden. Koennt ihr mir eine weitere Stellen nennen, die umgebaut werden muessen?

Beim NeighborUpdate muss auf jeden Fall eine DEZ-Zahl angegeben werden. Ich hab es ewig lang mit "0c" probiert und es hat nie funktioniert. Bis ich dann "12" probiert habe und dann hat es gepasst.

Ich hab bei allen Geräten ein NeighborUpdate gemacht und bei den Eversprings erkennt er auch den richtigen Nachbar. Trotzdem hab ich danach immer noch keinen Empfang :/ Der Sensor steht genau vor der Tür und es sind bis auf die Tür keine weiteren Hindernisse dazwischen. Die Luftlinie zwischen Fibaro-Switch und Everspring beträgt vl 4 Meter. Mit einem Fibaro-Motion-Sensor gab es an der gleichen Stelle und weit darüber hinaus keine Empfangs- und Sendeprobleme.
Ich fürchte schön langsam, dass die Everspring Motion-Sensoren das Routing über ein anderes ZWave-Gerät nicht praktizieren können (oder wollen)

[shady88]

Ich hab zurzeit nicht die Möglichkeit es auszuprobieren - Hoffentlich morgen Abend. Aber mir ist gerade etwas eingefallen.

Die Fibaro-Komponenten sind ja in der Assoziationsgruppe 3, wie auch hier zu lesen ist: http://www.fhemwiki.de/wiki/Z-Wave#Assoziation
Die Everspring sind in Gruppe 1.
Hängt das mit der Weiterleitung von Nachrichten zusammen? Werden Nachrichten auch dann weitergeleitet, wenn die Gruppen unterschiedlich sind? Gibt es da einen Zusammenhang?

[krikan]

Hängt damit -zumindest theoretisch- nicht zusammen. Habe Geräte mit Asso 1,  3, 5 und das Routing klappt.

Tippe mittlerweile eher auf uralten Chipsatz mit geringerer Reichweite in den Eversprings. Kannst Du nicht mal den Sensor auf die andere Seite der Tür bringen und testen?

[shady88]

Ja, auf der Innenseite der Tür funktioniert es. Zumindest an der Vordertür, da der Controller direkt einen Stock darüber steht.

Bei der Hintertür funktioniert es nichtmal annähernd, obwohl da zumindest zwei Geräte mit Netzstrom sehr nahe sind.

Ich spiel noch ein bisschen herum, aber wahrscheinlich werde ich sie zurückschicken.

Leider gibt es nicht wirklich eine Alternative für einen Außen-Motion-Sensor :/ Oder kennt jemand einen?

[krikan]

Die neigborUpdate hattest Du mit Kontrolle durchgeführt?
Frage nur, weil Du das am Device und nicht am ZWDongle, wie von mir oben geschrieben, aufrufen musst.

Leider gibt es nicht wirklich eine Alternative für einen Außen-Motion-Sensor :/ Oder kennt jemand einen?

Zwave-Sensoren für geschützten Außeneinsatz gibt es noch als Aeotec Multisensor 5 und Vision VISEZP3102-5. Erfahrung habe ich damit aber nicht; sind aber beide ZWave+.

[shady88]

Die neigborUpdate hattest Du mit Kontrolle durchgeführt?
Frage nur, weil Du das am Device und nicht am ZWDongle, wie von mir oben geschrieben, aufrufen musst.

Was meinst du mit Kontrolle? Ich hab das Update über den ZWDongle durchgeführt (meistens). Da das Update hier aber immer sehr schnell funktionieren muss, da nach gefühlten 10 Sekunden ein Timeout kommt und ich bis dahin den Wakeup nicht immer geschafft habe, hab ich bei manchen das ganze direkt am Gerät gemacht, damit es nach dem Wakeup gleich ein NeighborUpdate macht.
Ich kann das nochmal bei allen machen.

Bezüglich Kontrolle: Jedes Mal nachdem ich ein NeighborUpdate gemacht habe (vom ZWDongle aus), hab ich danach ein get NeighborList <id> gemacht (manuell).

Zwave-Sensoren für geschützten Außeneinsatz gibt es noch als Aeotec Multisensor 5 und Vision VISEZP3102-5. Erfahrung habe ich damit aber nicht; sind aber beide ZWave+.

Der Aeotec Multisensor 5 ist irgendwie schwer zu bekommen und hat sehr "kritische" Bewertungen und beim Vision VISEZP3102-5 find ich kein Manual wo drin steht, dass der wirklich für draußen geeignet ist. Nur auf Amazon steht als Antwort bei der Frage, ob er für draußen geeignet ist, ein "nein". Aber das muss ja nicht immer stimmen.
Im Manual steht auch, "for Indoor Use only" http://www.visionsecurity.com.tw/loadfiles.html?f=161_pro_1_en.pdf

[krikan]

Bezüglich Kontrolle: Jedes Mal nachdem ich ein NeighborUpdate gemacht habe (vom ZWDongle aus), hab ich danach ein get NeighborList <id> gemacht (manuell).

Genau das meinte ich mit Kontrolle.

beim Vision VISEZP3102-5 find ich kein Manual wo drin steht, dass der wirklich für draußen geeignet ist. Nur auf Amazon steht als Antwort bei der Frage, ob er für draußen geeignet ist, ein "nein". Aber das muss ja nicht immer stimmen.
Im Manual steht auch, "for Indoor Use only" http://www.visionsecurity.com.tw/loadfiles.html?f=161_pro_1_en.pdf

Habe das aus einem Webshop, der ihn als IP44 deklariert. Aber da es anders im Manual steht, ist das wohl falsch.

[krikan]

Hex->Dezimal Umbau:

Nach Studium der Quellen bin ich nicht so recht fuendig geworden. Ich habe das Internal id in nodeIdHex umbenannt, die anderen Zahlen sollten aber dezimal eingegeben bzw. dargestellt werden. Koennt ihr mir eine weitere Stellen nennen, die umgebaut werden muessen?

Zeile 328 in ZWave.pm (r9744):   

Code Auswählen Erweitern

parse => { "..8503(..)(..)..(.*)" => '"assocGroup_$1:Max $2 Nodes $3"'
liefert hex-Werte im ReadingsValue.
Verwirrend finde ich, dass $1 per default dez und $2,$3 per default hex ist.
Es gibt noch mehr ReadingsValue, die hex enthalten, bei denen ich aber nicht sicher bin, ob eine Änderung sinnvoll ist (bspw.: basicSet, basicReport)

[rudolfkoenig]

Verwirrend finde ich, dass $1 per default dez und $2,$3 per default hex ist.

Nein, alle drei waren Hex Werte, ich habe sie hiermit auf Dezimal geaendert.

Eigentlich sollten alle Werte, die der Benutzer sieht, dezimal sein, aber an manchen Stellen wird die Umstellung weh tun, wie beim erwaehnten basicReport, das habe ich jetzt auch nicht geaendert.

[krikan]

Nein, alle drei waren Hex Werte, ich habe sie hiermit auf Dezimal geaendert.

Ja, hast recht habe mich verwirren lassen.

Bei den parse von versionClass, Class SCENE_ACTIVATION, SCENE_ACTUATOR_CONF, SCENE_CONTROLLER_CONF, COLOR_CONTROL, MULTI_CHANNEL_ASSOCIATION gibt es auch noch hex/dez-Probleme. Ich kann aber auch mal in Ruhe durchschauen und Dir auch einen Patch liefern. Das sind nur die Classes, die mir heute untergekommen sind. Hoffe auch, dass ich nichts verwechselt habe; zuviel hin- und hergerechnet. 

Gruß, Christian