Z-Wave Multichannel Problem

[A.Harrenberg]

Hi Rudi,

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

Einträge sind da, der Eintrag "endpointRoot" ist anklickbar und man landet beim rootdevice, die Einträge "endpointChildren" lassen sich aber nicht anklicken... Wäre es möglich hier auch noch die links zu erzeugen?

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

nach einer ersten Lektüre der MultiChannel Spezifikation bin ich jetzt auch noch nicht viel schlauer, da sind so einige "MAY" und "SHOULD" drin...

Ich habe aber die MultiChannel Assoziation mal neu erstellt und nur 1:0 als Ziel angegeben (set mcaAdd 10 1 0), und keine normale Lifeline Assoziation mehr gemacht. Dadurch bekomme ich jetzt jeden Endpoint in der multichannel Kapselung wie vorher auch, die beiden anderen Messages werden jetzt aber ungekapselt an das root-Device geschickt. Man kann das also durch entsprechende Konfiguration irgendwie hinbekommen...

Trotzdem können solche Nachrichten ja ankommen und bei "0" sollte das root device gemeint sein. Ob das dann auch für endpoint 1 "dupliziert"  werden muss kann ich momentan nicht sagen, würde es aber erwarten.

Gruß,
Andreas.

[rudolfkoenig]

Habe endpointRoot in endpointParent umbenannt, und endpointChildren sind jetzt anklickbar in FHEMWEB
Merke: Trenner fuer solche Listen ist Komma und nicht Leerzeichen.

Wenn ich dich richtig verstehe, bist fuer $1=0: endpointParent, sonst: endpointChild.
Da das eine Aenderung bei notifies/logs der Leute bedeuten kann, wuerde ich gerne noch die Meinung von Christian hoeren.

[A.Harrenberg]

Hi Rudi,

Habe endpointRoot in endpointParent umbenannt, und endpointChildren sind jetzt anklickbar in FHEMWEB
Merke: Trenner fuer solche Listen ist Komma und nicht Leerzeichen.

Danke, werde ich mir gleich mal ansehen

Wenn ich dich richtig verstehe, bist fuer $1=0: endpointParent, sonst: endpointChild.
Da das eine Aenderung bei notifies/logs der Leute bedeuten kann, wuerde ich gerne noch die Meinung von Christian hoeren.

Tendenziell wäre das meine Meinung, ich bin aber auch dafür das noch mal in aller Ruhe zu überlegen und abzuwägen. Ich habe wie gesagt mit dem ganzen Multichannel nichts zu tun gehabt und kann die Folgen von einer Änderungen momentan noch nicht mal ansatzweise abschätzen. Außerdem kommen diese Nachrichten mit $1=0 nicht wenn man die mca "vernünftig" konfiguriert.

Ich denke das hier Christian den besten Überblick hat und am ehesten die Folgen abschätzen kann. Da das Thema nicht dringend ist kann das ja in Ruhe überlegt werden.

Gruß,
Andreas.

[krikan]

Ich denke das hier Christian den besten Überblick hat und am ehesten die Folgen abschätzen kann.

(Leider) zuviel der Ehre. Ich habe ein wenig Probleme Euch zu folgen. Anhand meiner Geraete erkenne ich keinen Fehler/Problem in FHEM und würde erst einmal ungerne Anpassungen befürworten, wenn es nur auf dem uno basiert. Schaue aber auch noch mal in die zwapi und krame in meiner Erinnerung...

Was ich nicht begriffen habe: Existiert das Problem beim uno nur im Zusammenspiel von MultiChannel und MultiChannel_Association oder auch bei MultiChannel alleine?

[A.Harrenberg]

Hi Christian,

also das "Basisproblem" ist das ZWave+ anscheinend zwingend fordert (was aber anscheinend einige Hersteller wieder ignorieren...) das bei Multichannel der Kanal 0 auf das Root-Device gemappt werden soll. Wenn man nun die Associations nun so setzt das man da das Root-Device angibt (ohne Multi-Channel Definition) dann sendet der Zuno Multichannel Nachrichten die von "0" kommen, diese werden in FHEM aber dem ersten Kanal zugeordnet und landen eben nicht im Root-Device, was eigentlich logischer wäre.

Ich habe beim Z-Uno nun die normale Assoziation gelöscht und nur eine MultiChannel-Assoziation gemacht und erhalte dadurch jetzt nur Nachrichten von den einzelnen Kanälen und keine mehr vom Rootdevice.

Ich denke aber das immer mehr Geräte das gleiche Verhalten zeigen werden und es eigentlich logischer ist das alles was vom Rootdevice kommt auch bei FHEM im Rootdevice landet.

Ich werde noch mal eine Versuchsreihe machen bei welchen Kombinationen diese Nachrichten vom Rootdevice ausgelöst werden und bei welchen nicht. Sooo genau kann ich das jetzt auch nicht mehr sagen. Und das Thema ist alles andere als dringend...

Gruß,
Andreas.

[krikan]

also das "Basisproblem" ist das ZWave+ anscheinend zwingend fordert (was aber anscheinend einige Hersteller wieder ignorieren...) das bei Multichannel der Kanal 0 auf das Root-Device gemappt werden soll.

Hallo Andreas,
hast Du das aus den zwapi oder ist das Auskunft von zwave.me?
Gruß, Christian

[A.Harrenberg]

Hi,

das ist Auskunft von Zwave.me
Der Typ dort scheint recht fit zu sein.

Gruß,
Andreas.

[krikan]

Ok, kann es dann einordnen. (https://github.com/PoltoS ?)

[A.Harrenberg]

Hi Christian,

ja, das ist er.

Gruß,
Andreas.

[krikan]

Wenn ich dich richtig verstehe, bist fuer $1=0: endpointParent, sonst: endpointChild.

Habe mir das Thema iZm https://forum.fhem.de/index.php/topic,59026.msg521515.html#msg521515 noch einmal angesehen und bin der Meinung, dass 0 für endpointParent ist.

Diese Codestelle stimmt mMn nicht mit zwapi überein und ich verstehe den Grund nicht:

Code Auswählen Erweitern

$ep = ($1 ne "00" ? $1 : $2);

Nach zwapi:
$1 gibt immer den SourceEndpoint und $2 gibt immer den DestinationEndpoint an, wobei  $1= 0: endpointParent, $1>0: endpointChild bzw. $2= 0: endpointParent, $2>0: endpointChild

$2 ist beim Empfang durch den Controller unerheblich, weil der Controller keine eigenen Endpoints hat.

Da laut zwapi gilt

If a sending device does not implement Multi Channel End Points or if the Root Device of the Multi Channel device is originating a command, the Source End Point MUST be set to 0.

schließe ich für den Versand von MULTICHANNEL-Nachrichten durch den Controller, dass

Code Auswählen Erweitern

$cmdFmt = "0d01$ch$cmdId$cmdFmt";
durch

Code Auswählen Erweitern

$cmdFmt = "0d00$ch$cmdId$cmdFmt";
ersetzt werden sollte.

Ganz sauber ist das so auch noch nicht, da $1 und $2 noch besondere Bits beinhalten.

Problem: Folgen kann ich nicht alle überblicken. Insbesondere befürchte ich Seiteneffekte auf MULTICHANNEL_ASSOCIATION und enormen Aenderungsbedarf bei den notifies/DOIFs...

[rudolfkoenig]

Danke fuer die gruendliche Erklaerung.

Diese Codestelle stimmt mMn nicht mit zwapi überein und ich verstehe den Grund nicht:

Grund: ich wusste es nicht besser. Ich habe zwei Telegramme gehabt mit erwarteten Sinn, und musste daraus was basteln.

Sonst bin etwas verwirrt: die vorgeschlagene Aenderung sollte doch keine Aenderung auf Notifies haben, hoechstens auf die Reaktion der Empfaenger, aber selbst das sehe ich nicht (dem zu schaltenden Kanal sollte egal sein, ob das Befehl vom Parent oder Endpoint 1 kommt). Was mAn gefixt werden muss, ist die erste Codestelle, in $ep=$2, was Auswirkung auf notifies haben kann. Das koennen wir loesen, indem wir ein Attribut einfuehren, oder davor warnen. Bin fuer Letzteres.

[krikan]

Änderungsbedarf sehe ich derzeit theoretisch bei beiden Codestellen.
Korrekt: Die notify-Thematik sollte "nur" die 1. Codestelle ("$ep = ($1 ne "00" ? $1 : $2);") betreffen, deren Entstehung ich nicht verstand.

Ich würde gerne noch ein wenig lesen (dynamische Endpoints,..) und testen, bevor Codeänderungen eingebaut werden. Für mich ist das noch zu unklar. Es sei denn Du/Ihr seid schon sicher oder wir gehen Risiko der mehrfachen Änderung ein.

Das koennen wir loesen, indem wir ein Attribut einfuehren, oder davor warnen. Bin fuer Letzteres.

Ebenso.

Btw.
Bin bei dem Thema wegen sehr langer und kaputter Nachrichten auf CRC-16 und die Reihenfolge der Encapsulation "http://zwavepublic.com/sites/default/files/SDS12657-12%20-%20Z-Wave%20Command%20Class%20Specification%20A-M.pdf S.21ff.  aufmerksam geworden.

[rudolfkoenig]

Ich würde gerne noch ein wenig lesen...

Nur zu, melde Dich dann.

Und danke fuer den Hinweis auf die Tabelle.
Weisst Du, was da mit "Transport Service" gemeint ist?

[krikan]

Weisst Du, was da mit "Transport Service" gemeint ist?

Steht wohl für Transport Service Command Class (Übermittlung von Nachrichten größer als der ZWave-Frame)
http://zwavepublic.com/sites/default/files/SDS12652-13%20-%20Z-Wave%20Command%20Class%20Specification%20N-Z.pdf S. 330
Habe die Command Class noch nicht in Geräten wahrgenommen. Da pepper1 momentan nicht erreichbar ist, kann ich auch nicht nachsehen, ob es schon Geräte gibt. Bei der Alliance kann ich nicht nach CC suchen.