ZWave @ culfw

[krikan]

Im nodeInfo steht drin, ob das Geraet per Security angebunden ist (oder es nur kann?), ob es routen kann (weil staendig an), ob es FLIRS kann, und ob es 40k kann. Einige Bits sind aber ein Raetsel fuer mich, und die Erklaerung im Aeon-updater-XML kapiere ich auch nicht.

Das baut mich nicht gerade auf. Wenn Du es schon nicht verstehst...

Wenn du den Backup hinkriegst, bitte dokumentieren. Aber selbst mit einem Backup hat man Probleme, man ist naemlich auf dem Hersteller angewiesen, dass er genau dieses Produkt vorraetig haelt. Ist mAn ein Designfehler aller ZWave Sticks.

Das zway-Log für den UZB1 ist dazu komplett schweigsam; im Gegensatz zu den anderen Befehlen, die sauber dokumentiert/geloggt sind. Zudem hat zme das Thema wohl selbst nicht richtig im Griff. Außerdem ist das bei ZME sowieso proprietär; hattest Du mEn auch angefragt und so beantwortet bekommen (zwave.de-Forum?)

Mir ist aber überhaupt nicht klar, wie ich mit dem derzeitigen Stand schon ein Backup/Umzug meines alten Sticks auf den Cul hinbekomme? Ist das überhaupt schon möglich?. Wenn ich nur mit dem Cul arbeite, verstehe ich es ja halbwegs.

[A.Harrenberg]

Hi Rudi,

Naja, bisher habe ich nur die as6 getestet. Ich sende da nur den ACK auf NIF und danach zwaveAssignId @ 9600. sobald die ACK dafuer eintrifft, schalte ich auf 40k, um die init Befehle abzusetzen. Das klappt bisher ohne Aussetzer. Auch die "freiwilligen" Nachrichten kommen auf 40k. In nodeInfo steht zwar drin, ob ein Geraet 40k kann, ich habe aber nicht rausgefunden, wie man die 100k rauskriegt. Und ich erwarte, dass als Controller dem Endgeraet auch mitteilen kann, was man selbst senden kann, das ist aber auch noch Forschung.

meine Theorie dazu ist das es kein Bit für 100k sondern das 40k mit dem "slow" Flag sendet, was ja bedeutet das man mehr kann. Ich habe mir das aber noch nicht richtig angesehen und die Beschreibung war ja eigentlich das es langsamer ist als BEIDE Seiten können, und woher weiß man das (vorher)?

Mit einem parallelen Empfang aller Datenraten mit dem CUL rechne ich nicht.

Ich gebe die Hoffnung da noch nicht (ganz) auf...

Wenn du den Backup hinkriegst, bitte dokumentieren. Aber selbst mit einem Backup hat man Probleme, man ist naemlich auf dem Hersteller angewiesen, dass er genau dieses Produkt vorraetig haelt. Ist mAn ein Designfehler aller ZWave Sticks.

Da mein Testsystem und das Produktivsystem beiden den UZB1 verwenden hätte ich sofortigen Ersatz zur Hand Falls sich das Backup auch auf den RazBerry übertragen lassen sollte stünde sogar noch ein weiteres System zur Verfügung.
Die Frage ist ja eigentlich was in dem Stick eigentlich gespeichert ist was sich nicht auch wieder aufbauen lässt (mit neighborUpdate, ExplorerFrames, etc.). Welche Node-IDs inkludiert ist ja in der FHEM-config leicht zu finden.

Statische Routen kann man im Paket setzen (das kennen wir), und es muss ein Befehle geben, um diese im Endgeraet zu speichern. Es gibt ein ZW_ASSIGN_RETURN_ROUTE, leider weiss ich nicht, wie man es bedient.

Ja, dieses Zuweisen einer Route an einen Node würde mich interessieren, dann könnte ich meinen RFID Leser mal "zwingen" über den Steckdosenschalter zu routen.
(Und meinem anderen Steckdosenschalter mal sagen das er nicht über die Sirene die neben im eingesteckt ist routen muss...)

addNodeId kann man zum bequemeren Austausch eines Geraetes verwenden. Oder wenn man eine bestimmte Systematik bei der Nummernvergabe hat. Und zum Experimentieren

Äh, heisst das jetzt doch das man einem Gerät nachträglich eine andere ID geben kann?

Im nodeInfo steht drin, ob das Geraet per Security angebunden ist (oder es nur kann?), ob es routen kann (weil staendig an), ob es FLIRS kann, und ob es 40k kann. Einige Bits sind aber ein Raetsel fuer mich, und die Erklaerung im Aeon-updater-XML kapiere ich auch nicht.

Den NodeInfoBlock muss ich mir auch noch mal genauer ansehen. Da muss ja eigentlich alles drin stehen was für das Netzwerk interessant ist.

Gruß,
Andreas.

[rudolfkoenig]

Umzug meines alten Sticks auf den Cul

Das empfehle ich noch nicht, da noch ein paar Features fehlen, siehe TODO in 00_ZWCUL.pm. Ich glaube, dass es keine prinzipiellen Huerden sind, nur Fleissarbeit. Beim Umstieg muss man:
- ein ZWCUL mit der alten homeId spezifizieren.
- falls noetig, routing Information fuer bestimmte Knoten setzen (das ist noch nicht implementiert)
- oder (falls wir das auch implementieren) ein "neighborUpdate" starten.

Voraussetzung ist, das alle Geraete auf der gleichen Frequenz senden. Da ist natuerlich nicht lustig, wenn manche Geraete nur 9600 koennen. Und es kann zu Problemen fuehren, falls man manche Geraete von 100k auf 40k oder andersherum umgewoehnen muss. Falls wir dafuer keine Befehle finden, dann kann es doch spannend bleiben

kein Bit für 100k sondern das 40k mit dem "slow" Flag sendet

Kannst du das nochmal langsam erklaeren? Wo ist ein slow flag?

Die Frage ist ja eigentlich was in dem Stick eigentlich gespeichert ist was sich nicht auch wieder aufbauen lässt

Na in der FHEM-Config steht alles drin, der Haken ist nur, dass wir das nicht dem ZWDongle beibringen koennen. Fuer ZWCUL habe ich alle Informationen parat, bis auf Routing, was mAn nicht so tragisch ist.

Äh, heisst das jetzt doch das man einem Gerät nachträglich eine andere ID geben kann?

Nein, das funktioniert nur beim Inkludieren, und da auch nur auf 9600.

[A.Harrenberg]

Hi Rudi,

Kannst du das nochmal langsam erklaeren? Wo ist ein slow flag?

das normale "Speed" flag: ITU-T G.9959 (01/2015)

8.1.3.3.4 Speed modified subfield (Channel configurations 1, 2 only)
The speed modified subfield is 1 bit in length. It shall be set to 1 if an MPDU is sent at a lower speed than supported by the Src and Dst. The field shall not be used for routed and multicast MPDUs. The field shall be set to 0 if the MPDU is sent at the highest speed supported by the source and destination.

Auch noch mal identisch in Kapitel A.4.2.3.4.

Wenn man das in einer 40K Nachricht setzt sollte das ja bedeutet das (beide) schneller können, also 100K. Woher der Controller/Sender allerdings weiss das die andere Seite schneller kann weiß ich auch nicht.

Gruß,
Andreas.

[rudolfkoenig]

Wenn man das in einer 40K Nachricht setzt sollte das ja bedeutet das (beide) schneller können, also 100K.

Das waere eine komische Art der Kommunikation, allerdings habe ich auch nicht verstanden, wozu das 40k Bit selbst gut sein soll, schliesslich ist das nach dem Empfang mAn irrelevant.

[A.Harrenberg]

Hi Rudi,

Das waere eine komische Art der Kommunikation, allerdings habe ich auch nicht verstanden, wozu das 40k Bit selbst gut sein soll, schliesslich ist das nach dem Empfang mAn irrelevant.

ich zitiere nur die G.9959, wobei wir ja auch schon wissen das ZWave sich nicht in allen Punkten daran hält (invertierung bei 9.6k...).

Ich habe mir die Bitfelder (F und f) und den NIF noch nicht genauer angeschaut sondern hatte das nur noch im Kopf, weil ich es auch etwas merkwürdig fand.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,
ich hätte da mal wieder ein Problem... Seit neuestem versucht der ZWCul mein System zu übernehmen...
Sobald ich das Danalock einbinden inkludieren will nimmt FHEM mit meinem mal den ZWCul statt dem ZWDongle, und das obwohl der State von ZWCul "disconnected" ist, das Ding hatte ich nämlich rausgezogen um weiterarbeiten zu können...

Code Auswählen Erweitern


2016.01.25 21:59:11.051 4: ZWDongle set ZWDongle_0 addNode onNwSec
2016.01.25 21:59:11.051 5: ZWDongle_Write 004ac107 ()
2016.01.25 21:59:11.051 5: SW: 0105004ac10776
2016.01.25 21:59:11.258 5: ACK received, removing 0105004ac10776 from dongle sendstack
2016.01.25 21:59:11.282 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a07010000
2016.01.25 21:59:11.282 5: SW: 06
2016.01.25 21:59:11.283 5: ZWDongle_0 dispatch 004a07010000
2016.01.25 21:59:11.283 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2016.01.25 21:59:11.283 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2016.01.25 21:59:18.057 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a0702d80a0440035e72985a807322
2016.01.25 21:59:18.057 5: SW: 06
2016.01.25 21:59:18.058 5: ZWDongle_0 dispatch 004a0702d80a0440035e72985a807322
2016.01.25 21:59:18.058 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:d80a0440035e72985a807322
2016.01.25 21:59:18.058 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2016.01.25 21:59:18.107 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a0703d80a0440035e72985a807322
2016.01.25 21:59:18.107 5: SW: 06
2016.01.25 21:59:18.108 5: ZWDongle_0 dispatch 004a0703d80a0440035e72985a807322
2016.01.25 21:59:18.108 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:d80a0440035e72985a807322
2016.01.25 21:59:18.135 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a0705d80a0440035e72985a807322
2016.01.25 21:59:18.135 5: SW: 06
2016.01.25 21:59:18.136 5: ZWDongle_0 dispatch 004a0705d80a0440035e72985a807322
2016.01.25 21:59:18.136 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:d80a0440035e72985a807322
2016.01.25 21:59:18.136 2: ZWAVE Starting secure init
2016.01.25 21:59:18.136 5: ZWCUL_Write e015dfed 0013d80398040025d8
2016.01.25 21:59:18.136 5: SW: zse015dfed0141040dd898040035
2016.01.25 21:59:28.138 2: ZWave: No ACK from ZWave_ENTRY_CONTROL_216 after 10s for sent:13d80398040025d8

Wenn ich den ZWCul auf "disable" setze ist der Spuk vorbei, aber so ist das doch sicherlich nicht geplant...
Ich bin mir aber auch nicht sicher ob das nicht irgendwie mir meinem Code zusammenhängt, da ich ja teilweise auch direkt in addToSendStack schreibe und auch recht viel mit den hashes herumjongliere... Bei den Tests am WE war aber noch alles "normal", da hab' ich das Danalock zig-Mal inkludiert.

Hast Du eine Idee wo das ganze falsch abbiegt? (Und ob ich schuld bin??)

Gruß,
Andreas.

[rudolfkoenig]

Ich vermute, dass das IODev nicht (mehr?) richtig gesetzt ist.

ZWDongle_Define prueft, dass nur ZWDongle/ZWCUL/FHEM2FHEM mit passenden homeId zugewiesen wird, aber wenn es einmal gesetzt ist, dann wird das Geraet behalten, da ein Attribut erzeugt wird, was nach einem Neustart dem define drankommt.

[A.Harrenberg]

Hi Rudi,

werde ich heute abend mal nachsehen. Mir ist gestern abend noch aufgefallen das ZWCul mir den ZWDongle als Node_01 angelegt hat... ,-)

Finde ich eigentlich merkwürdig, da ich bisher nie eine HomeId für den ZWCul gesetzt habe, und ohne die sollte sowas doch eigentlich nicht möglihc sein, es sei denn die Nachricht vom ZWDongle gerät in die Queue vom ZWCul.

Ich schaue heute abend nach und berichte.

Danke,
Andreas.

[A.Harrenberg]

Hi Rudi,

IoDev ist gesetzt, der Fehler kommt anscheinend durch meinen Umbau mit zwave_parseHook. Irgendwie hantiere ich das anscheinend mit einem falschen Hash, ich finde aber gerade den Fehler nicht...
Ich hab' in den nächsten Tagen nicht so viel Zeit zum debuggen, aber da der Fehler nur auftritt wenn man mehr als ein ZWave-Device hat dürfte sich der "Schaden" hoffentlich im Rahmen halten.

Ich verstehe nur nicht wieso das während der gesamten Umbauphase einwandfrei funktioniert hat und jetzt mit einem Mal schief läuft...

Sorry,
Andreas.

[A.Harrenberg]

Hi Rudi,

kaum geschrieben schon was entdeckt...
Irgendwie hat jetzt mein ZWCul (m)eine homeId bekommen...

Code Auswählen Erweitern

Internals:
   Clients    :ZWave:STACKABLE_CC:
   DEF        /dev/ttyACM2@115200 00000000 01
   DeviceName /dev/ttyACM2@115200
   FD         20
   NAME       zwc
   NR         23
   PARTIAL
   RAWMSG     zR4D
   STATE      Initialized
   TYPE       ZWCUL
   VERSION    V 1.66 CUL868
   baudRate   9600
   homeId     e015dfed
   homeIdSet  00000000
   initString zm1
   monitor    1
   nodeIdHex  01
   removeNode 1
   zwc_MSGCNT 2894
   zwc_TIME   2016-01-26 18:30:22
   Matchlist:
     1:ZWave    .*
     2:STACKABLE_CC ^\*
   Readings:
     2016-01-25 19:35:38   homeId          HomeId:00000000 CtrlNodeId:01
     2016-01-26 18:30:22   state           Initialized
Attributes:
   dataRate   100k
   disable    0
   noDispatch 1
   room       ZWave
   verbose    5
Ich habe die nie gesetzt, wie kommt die da hin?
get homeId liefert mir auch 00000000 zurück...

Wie krieg' ich die homeId wieder weg?
Wieso habe ich da noch ein homeIdSset?

Gruß,
Andreas.

[rudolfkoenig]

homeIdSet ist das, was man in der Definition angibt.

homeId wird vom zuletzt empfangenen Paket gesetzt, damit das Anlegen von Geraeten funktioniert, aber nur, falls noDispatch nicht gesetzt ist. Ich kann deine Ausgabe nur so vorstellen, dass du FHEM gestartet hast, und danach noDispatch gesetzt hast. Sonst waere es ein Bug, und ich weiss noch nicht, wo/was ich aendern muss, um es zu fixen.

[A.Harrenberg]

Hi Rudi,

ich werde den ZWCul nachher mal löschen und neu anlegen und schauen ob der wieder eine homeId bekommt.

Das ganze ist aber dennoch merkwürdig. Ich habe ganz zu Anfang das "noDispatch" noch nicht aktiv gehabt, das ist jetzt aber schon ein paar Wochen her... Und seitdem habe ich unzählige Male FHEM neu gestartet oder die Geräte neu inkludiert.

Und ich an den Code-Änderungen liegt es wahrscheinlich auch nicht, beim alten und neuen Code wird der gleiche Hash verwendet, der allerdings mit Hilfe der homeId ermittelt wird:

Code Auswählen Erweitern

my $dh = $modules{ZWave}{deftptr}{"$homeId $1"}

Mir war ja auch aufgefallen das der mir der ZWCul eine Node angelegt hat...

Na ja, ich werde beobachten und berichten.

Macht es vielleicht Sinn zu verhindern das zwei ZWave-IoDevices mit der gleichen homeId (automatisch) angelegt werden und man die gleiche homeId nur zulässt wenn sie beim define angegeben wurde?

Gruß,
Andreas.

[rudolfkoenig]

Mit gleichen homeIds kann man groessere Bereiche mit abgesetzten (d.h. via LAN angebundenen) CULs abdecken.
Es macht aber vermutlich wenig Sinn, ein ZWCUL im Monitor-Mode ohne noDispatch zusammen mit anderen Empfaenger (ZWDongle/ZWCUL) zu betreiben.

Kannst du bitte pruefen, ob das Problem mit von Anfang an gesetzten noDispatch auch auftritt? Wenn ja, dann muss ich was fixen, ansonsten tendiere ich dazu, dass noDispatch bei monitor-mode zum Standard wird, und das aktuelle Verhalten mit einem neuen Attribut ("intruderMode"?) aktiviert werden muss.

[A.Harrenberg]

Hi Rudi,

Mit gleichen homeIds kann man groessere Bereiche mit abgesetzten (d.h. via LAN angebundenen) CULs abdecken.

Hmm, ich stelle mir das aber "gefährlich" vor wenn je nach Empfangslage der "andere" Dongle auch empfängt und dann evtl antwortet. Das dürfte ein ziemliches durcheinander werden... Als sekundärer Controller mit einer anderen ID könnte das funktionieren...

Es macht aber vermutlich wenig Sinn, ein ZWCUL im Monitor-Mode ohne noDispatch zusammen mit anderen Empfaenger (ZWDongle/ZWCUL) zu betreiben.

Yep, Zustimmung.

Kannst du bitte pruefen, ob das Problem mit von Anfang an gesetzten noDispatch auch auftritt? Wenn ja, dann muss ich was fixen, ansonsten tendiere ich dazu, dass noDispatch bei monitor-mode zum Standard wird, und das aktuelle Verhalten mit einem neuen Attribut ("intruderMode"?) aktiviert werden muss.

Ich habe den ZWCul gestern abend gelöscht und neu angelegt und sofort nach dem Anlegen das noDispatch gesetzt. Bis jetzt ist noch alles in Ordnung.

Ich hab' die Nacht noch etwas darüber gegrübelt, und bin zu dem Schluß gekommen das es evtl. durch (Perl)Syntax-Probleme während meiner Tests ausgelöst worden sein könnte. Wenn man FHEM neu startet bzw. das Modul neu lädt und z.B. eine "}" vergessen hat kommt der Code ganz schön durcheinander, vielleicht habe ich durch soetwas den noDispatch außer Kraft gesetzt...

Ich beobachte mal weiter, wäre aber dafür das im Monitormode das noDispatch der Default ist.

Danke,
Andreas.