Z-Wave Multichannel Problem

[krikan]

BTW: Benötigt Ihr noch weitere Tests? Ich würde den FGS sonst wieder seiner Besimmung zuführen...

Nein, für mich keine Tests mehr notwendig. Danke für Deine Unterstützung.
Btw. bin definitiv kein Entwickler, sondern nur Anwender und erlaube mir daher die von Dir zitierte Aussage  .
Gruß, Christian

[rudolfkoenig]

Btw. Hattest Du die NO_ACK im Log der Endpoints gesehen?

Nope, uebersehen, danke fuer den Hinweis

Warum die kommen verstehe ich nicht, da ACK doch vorliegt!?

Ist eine nette Demonstration des hier diskutierten Problems:
- im SendStack landet ein get an EP#1.
- damit es mit dem naechsten Befehl aus dem Stack weitergeht (bzw. dieses Befehl vom Stack entfernt wird), muss erst ein 0113 (Stick hat Befehl versendet), ein 0013xx00 (Zielgeraet hat Befehl bekommen) und zum Schluss eine Antwort auf die Frage (get) vom _Empfaenger_ eintreffen.
- hier kam zwar alles, allerdings war die Antwort nicht vom EP#1, sondern vom "Vater"-Instanz, und dass das in diesem Fall das Gleiche ist, hat FHEM nicht geschnallt.

[sandembo]

dieses Problem tritt bei mir erst regelmässig auf, seit ich gestern ein fhem update gemacht habe.
das genannte device frage ich alle 10min ab:
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:20:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022593
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:30:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022594
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:40:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022596
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:50:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022598
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:00:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx02259a
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:10:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx02259c
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:20:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx02259f
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:30:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx0225a1

root@rpiplus:/opt/fhem# ls  restoreDir/
2015-11-22  2016-01-20  2016-06-19

dieses Problem trat mit der Version, die ich vorher hatte (am 20.1.16 eingespielt) nicht auf.

==> ./restoreDir/2016-06-19/FHEM/10_ZWave.pm <==
##############################################
# $Id: 10_ZWave.pm 10509 2016-01-15 08:55:51Z rudolfkoenig $

Vielleicht hilft diese Info ja, um den Fehler einzugrenzen ...

[rudolfkoenig]

Siehe https://forum.fhem.de/index.php?topic=54555

[sandembo]

danke!

bei der Gelegenheit ist mir aufgefallen, dass diese hier loglevel 2 sind - sollten sie nicht 3 sein?
2016.06.19 14:30:00 2: ZWave get DIELE.Deckenlicht swbStatus
2016.06.19 14:30:00 2: ZWave get DIELE.Treppenlicht swbStatus
2016.06.19 14:39:21 2: ZWave set DIELE.Deckenlicht on
2016.06.19 14:39:37 2: ZWave set DIELE.Deckenlicht off
2016.06.19 14:40:00 2: ZWave get DIELE.Deckenlicht swbStatus
2016.06.19 14:40:00 2: ZWave get DIELE.Treppenlicht swbStatus

verbose:
2 Meldungen über die wichtigsten Ereignisse oder Alarme
3 gesendete Befehle werden protokolliert

[rudolfkoenig]

Stimmt, habs geaendert.

[gamauf]

Hallo!

Habe erst gestern entdeckt, daß bei direktem Schalten des ersten Kanals (FIBARO System FGS222 Double Relay Switch 2x1.5kW) sich der Status des Haupt-Device ändert statt dem des Endpoint 1.

Wenn ich das hir in Thread richtig verstanden hab' ist die Lösung statt des Endpoint 1 zum schalten des ersten Kanals das Haupt-Device zu verwenden. Richtig?

Ich konfiguriere also den Bewegungsmelder so um, daß er jetzt nicht mehr Endpoint 1 sondern das Haupt-Device schaltet, dann ist die Anzeige im FHEM wieder konsistent, heißt egal ob der kanal vom lokalen Schalter, oder via FHEM geschaltet wird es ist immer der Status vom selben (Haupt-)Device der sich ändert.
Paßt!

Danke!
Rainer

[rudolfkoenig]

Wenn ich das hir in Thread richtig verstanden hab' ist die Lösung statt des Endpoint 1 zum schalten des ersten Kanals das Haupt-Device zu verwenden.

Das war jedenfalls meine Absicht. Endpoint 1 sollte gar nicht angelegt werden.

[krikan]

Habe erst gestern entdeckt, daß bei direktem Schalten des ersten Kanals (FIBARO System FGS222 Double Relay Switch 2x1.5kW) sich der Status des Haupt-Device ändert statt dem des Endpoint 1.

Wenn ich das hir in Thread richtig verstanden hab' ist die Lösung statt des Endpoint 1 zum schalten des ersten Kanals das Haupt-Device zu verwenden. Richtig?

Ja. Netter "Reklameaufhänger" : Zusammengefasst stehen die Erkenntnisse zum FGS222  hinsichtlich der Endpoints/Devices seit längerem in unserem Wiki unter http://www.fhemwiki.de/wiki/Z-Wave#FGS-222_Relais_Unterputzeinsatz.
Gruß, Christian

PS: Wenn dort etwas fehlt/unverständlich ist, bitte bei mir beschweren. Aktive Wiki-Schreiber können das gerne selbst ergänzen und sind gesucht...

[gamauf]

Danke für den Hinweis aufs Wiki; ist mir bisher nicht aufgefallen, daß dort der FGS222 erwähnt ist!

LG
Rainer

[FunkOdyssey]

Wenn ich in FHEM den Endpoint 1 einschalte, so wird dies nicht autom. im Hauptdevice angezeigt.
Ich muss manuell ein "get xyt swbStatus" hinterherschicken, um den gleichen Zustand zu erkennen.
Eine (ich nenne es mal) "Synchronisation" zwischen Hauptdevice und EP1 gibt es nicht, oder?

(Ich schalte nur über FHEM - nicht über angeschlossene Schalter)

[krikan]

Wenn ich in FHEM den Endpoint 1 einschalte, so wird dies nicht autom. im Hauptdevice angezeigt.
Ich muss manuell ein "get xyt swbStatus" hinterherschicken, um den gleichen Zustand zu erkennen.
Eine (ich nenne es mal) "Synchronisation" zwischen Hauptdevice und EP1 gibt es nicht, oder?

Nein, weil die Funktion von Haupt- und Endpointdevice geräteabhängig ist (mehr steht oben im Thread).

[A.Harrenberg]

Hi Rudi, hi Christian,

ich habe auch noch mal eine Frage bzgl. MultiChannel bzw. MultiChannel_Association...

Ich habe mit dem Z-Uno ein Gerät mit drei Kanälen "gebaut":
Channel 1: Switch_Mulitlevel "Dimmer"
Channel 2: Sensor_Multilevel "Temperature"
Channel 3: Sensor_Multilevel "Humidity"

Die normale Association für Lifeline habe ich gelöscht und ein mca eingerichtet (es gibt nur eine Gruppe).

Wenn ich nun vom Z-Uno aus die Reports verschicke erhalte ich 5! Nachrichten, eine von jedem Endpoint, Channel 1+2 jedoch auch noch mal von Endpoint 0. (Warum da überhaupt was von 0 gesendet wird und wieso dann nicht auch für den dritten Kanal diskutiere ich gerade mit dem Entwickler...)

Die Nachrichten sehen so aus:

Code Auswählen Erweitern

07600d 01 01 260300
07600d 00 01 260300
0a600d 02 01 3105012200e6
0a600d 00 01 3105012200e6
0a600d 03 01 3105052201cc

Was mich nun wundert ist das die beiden Nachrichten vom root-device im Endpoint 1 landen und nicht im root device. D.h. ich habe aktuell keine Readings im root-device, dafür aber State und Temperatur in Endpoint 1.

Ich hatte diese Diskussion hier eigentlich so verstanden das nur ungekapselte Nachrichten an Endpoint 1 weitergeleitet werden, gekapselte aber schon an den "richtigen" Endpoint gelangen. Nach der Logik würde ich erwarten das jeder Endpoint seinen Report bekommt und das Root-Device zusätzlich die beiden Nachrichten mit Endpoint 0.

So ganz habe ich die Logik hinter der Multichannel Association aber auch noch nicht verstanden...

Würde etwas dagegensprechen Nachrichten die Endpoint 0 haben an das root-device zu senden?

@Rudi: Die Devices haben in Ihrem hash doch sicherlich die Information der Eltern-/Kind Beziehung enthalten, oder? Wäre es möglich in den Internals beim root die Kinder aufzulisten (und als Link zur Verfügung zu haben), ebenso bei den Kindern das root device?

Gruß,
Andreas.

[rudolfkoenig]

Bin etwas verwirrt (oder einfach vergesslich?): wo ist das Unterschied zwischen Channel und Endpoint?

Ich war bisher der Ansicht, dass FHEM Endpoint 1 dem Root-Device zuordnet, das ist (nach Code-Check) aber nicht der Fall. Allerdings meldet mein Zwei-Kanal Sensor EZMotion 3-in-1 die Bewegungen per Root-Device (ohne MULTI_CHANNEL Encapsulation), die anderen Daten (Lich und Temperatur) per Endpoint 2 und 3. Endpoint 1 wird bei diesem Geraet nicht verwendet.

Die Zuordnung deiner Nachrichten in FHEM versteht man mit den folgenden Zeilen besser:

Code Auswählen Erweitern

  if($arg =~ /^..600d(..)(..)(.*)/) { # MULTI_CHANNEL CMD_ENCAP, V2
    $ep = ($1 ne "00" ? $1 : $2);

Warum ich das so gemacht habe, weiss ich allerdings nicht mehr.
Danach landen deine Nachrichten #1,#2 und #3 beim Geraet Endpoint 1.

Nach der Logik würde ich erwarten das jeder Endpoint seinen Report bekommt und das Root-Device zusätzlich die beiden Nachrichten mit Endpoint 0.

Verstehe deine Theorie richtig: $1 bedeutet: "melde es an $1", und $2 "verursacht von $2". Wenn ja, dann koennen wir zwar das implementieren, "verursacht von" waere aber zunaechst von FHEM ignoriert. Bin nicht sicher, dass ein Umbau ohne Nebenwirkungen bei anderen Geraeten ist.

Die Devices haben in Ihrem hash doch sicherlich die Information der Eltern-/Kind Beziehung enthalten, oder?

Bisher nur indirekt ueber nodeIdHex. Habe jetzt die Namen unter endpointChildren/endpointRoot eingetragen.

[A.Harrenberg]

Hi Rudi,

Bin etwas verwirrt (oder einfach vergesslich?): wo ist das Unterschied zwischen Channel und Endpoint?

denke das Channel = Endpoint sein sollte... Beim Z-Uno legt man "Channels" an, daher hatte ich das so beschrieben. Aber mit dem ganzen MultiChannel hatte ich bisher nie was zu tun, meine bisherigen Geräte hatten sowas nie... Allerding habe ich jetzt auch noch 2 Wandtaster die das natürlich auch haben, damit habe ich aber noch nicht "gespielt"...

Ich war bisher der Ansicht, dass FHEM Endpoint 1 dem Root-Device zuordnet, das ist (nach Code-Check) aber nicht der Fall. Allerdings meldet mein Zwei-Kanal Sensor EZMotion 3-in-1 die Bewegungen per Root-Device (ohne MULTI_CHANNEL Encapsulation), die anderen Daten (Lich und Temperatur) per Endpoint 2 und 3. Endpoint 1 wird bei diesem Geraet nicht verwendet.

Ich habe mir die Spezifikation und den Code noch nicht so genau angesehen, aber so wie ich das bisher (auch vom Z-Uno) verstanden haben muss Endpoint 1 dem Root Device zugeordnet sein. Wenn Dein EZMotion Endpoint 1 gar nicht nutzt mag das evtl. sogar konform sein, das kann ich aber momentan noch nicht sagen.

Die Zuordnung deiner Nachrichten in FHEM versteht man mit den folgenden Zeilen besser:

Code Auswählen Erweitern

  if($arg =~ /^..600d(..)(..)(.*)/) { # MULTI_CHANNEL CMD_ENCAP, V2
    $ep = ($1 ne "00" ? $1 : $2);

Warum ich das so gemacht habe, weiss ich allerdings nicht mehr.
Danach landen deine Nachrichten #1,#2 und #3 beim Geraet Endpoint 1.

Die Zeile hatte ich mittlerweile auch gefunden, den Grund dafür kann ich Dir aber auch nicht sagen ,-)
Ich denke Du meinst hier aber #1, #2 und #4, oder?

Verstehe deine Theorie richtig: $1 bedeutet: "melde es an $1", und $2 "verursacht von $2". Wenn ja, dann koennen wir zwar das implementieren, "verursacht von" waere aber zunaechst von FHEM ignoriert. Bin nicht sicher, dass ein Umbau ohne Nebenwirkungen bei anderen Geraeten ist.

Jetzt bin ich verwirrt... Habe gerade kurz in die Spec geschaut, $1 ist als "source end point" und $2 als "destination end point" deklariert. Umbauen solltest wir erst mal nichts bis das etwas näher analysiert ist. Und wahrscheinlich hat Christian da auch noch was beizusteuern, er hat das glaube ich ziemlich gut verstanden was da abgeht.
Bei $1 würde ich Dir zustimmen, wobei dann 0=root Device ist. $2 würde ich mir noch mal anschauen, das hängt vielleicht damit zusammen wie man die mca macht?? Das habe ich bisher auch noch nicht so ganz verstanden.

Bisher nur indirekt ueber nodeIdHex. Habe jetzt die Namen unter endpointChildren/endpointRoot eingetragen.

Danke, schaue ich mir gleich mal an!

Gruß,
Andreas.