Sporadisch werden neue endpointChildren erzeugt

[krikan]

Klasse MULTI_COMMAND gemeint.

Bin überrascht, dass die beim LC-13 schon unterstützt wird. Nachdem, was ich gestern im zwapi gelesen habe  (Multi Command steht nahe bei Multi_channel), könnte die Class zur Batterieschonung beitragen.

[A.Harrenberg]

Hi,

Bin überrascht, dass die beim LC-13 schon unterstützt wird. Nachdem, was ich gestern im zwapi gelesen habe  (Multi Command steht nahe bei Multi_channel), könnte die Class zur Batterieschonung beitragen.

wird sie, siehe listing im Post #1. In Fhem heißt die Klasse allerdings MULIT_CMD ,-)
Die Klasse wird von vielen Sensoren unterstützt, was für mich etwas ärgerlich ist wenn ich mir Rohnachrichten anschaue, dann muss man da immer in die Packete reinschauen und kann nicht einfach nur nach den Klassen schauen... B-)
Gruß,
Andreas.

[krikan]

Habe gestern mal probiert den Wakeup-Sendstack nach WUN in ein MULTI_CMD zu packen; war aber noch nicht erfolgreich. SECURITY habe ich dabei aber überhaupt noch nicht betrachtet und mich irritiert noch das man die WNMI mit in das Command packt, so daß andere Geräte mit direkten Assoziationen, wenn es denn so etwas geben sollte, keine Chance zur Kommunikation haben.

[A.Harrenberg]

Hi,

Habe gestern mal probiert den Wakeup-Sendstack nach WUN in ein MULTI_CMD zu packen; war aber noch nicht erfolgreich. SECURITY habe ich dabei aber überhaupt noch nicht betrachtet und mich irritiert noch das man die WNMI mit in das Command packt, so daß andere Geräte mit direkten Assoziationen, wenn es denn so etwas geben sollte, keine Chance zur Kommunikation haben.

kann Dir hier nicht ganz folgen...

Hast Du versucht die Nachrichten auf dem WU-Stack in eine Multi_CMD zu verpacken damit das dann bei der WU-Notification mit einem Befehl gemacht ist?
Und wer packt das WNMI mit darein? Das wird doch erst "dynamisch" erzeugt nachdem die WUN angekommen ist?

Bin verwirrt...
Andreas.

[krikan]

Hast Du versucht die Nachrichten auf dem WU-Stack in eine Multi_CMD zu verpacken damit das dann bei der WU-Notification mit einem Befehl gemacht ist?

Korrekt. Letztes von mir (angehängtes) Command war WNMI. Habe ich aus dem Beispiel der zwapi.

Das wird doch erst "dynamisch" erzeugt nachdem die WUN angekommen ist?

Ja, das macht FHEM derzeit so und ist eines meiner (vielen) Probleme bei dem Thema. Die dynamische WNMI von FHEM ist durch das Anhängen von WNMI im Multi_cmd überflüssig und landet im NOACK. Das ist aber eigentlich schon Feinheit.
Unklar ist mir, wie ich verhindern kann, dass die Befehle aus triggern von WUN in notify/DOIF abgesetzt werden, im Multi_Cmd nicht berücksichtigt werden.

[A.Harrenberg]

Hi,

ok, "halb" verstanden. Ich würde das WNMI nicht mit in das "vorgefertigte" Paket aufnehmen. Das kriegst Du mit den Notify nicht hin...

WANN genau erzeugst Du den das MultiCMD? Macht das der WU-Stack? So lange "anhängen" bis die maximale Länge erreicht ist?

Security könnte dabei ein Problem darstellen, habe gerade noch mal nachgeschaut, die dürfen nicht in MultiCmd gekapselt werden, nur andersherum ,-)

Gruß,
Andreas.

[krikan]

Ich würde das WNMI nicht mit in das "vorgefertigte" Paket aufnehmen.

Dann hat man aber wieder die unnötige Wachzeit (und es passt nicht zu zwapi-Bsp.  ) Was bringt MULTI_CMD dann tatsächlich noch an Batterieschonung!?

WANN genau erzeugst Du den das MultiCMD? Macht das der WU-Stack? So lange "anhängen" bis die maximale Länge erreicht ist?

Bin doch noch ganz am Anfang des Experimentier- und Überlegungsprozesses und sehr sehr weit vom richtigen Einbau weg: Ich hatte es in der parse-Routine direkt nach Erkennung "28407" vor dem Timerstart eingebastelt. Längenprüfung, Stackanpassung und Co. habe ich nicht gemacht.

[rudolfkoenig]

Ich wuerde in ZWave_processSendStack, zwei Zeilen vor dem IOWrite, eine Funktion ZWave_packMultiCmd() einbauen, der den Stack (falls machbar) zusammenpackt. Ist dann auch relativ einfach zum ein/auskommentieren.

[krikan]

Danke für den Hinweis, werde ich probieren.

[A.Harrenberg]

Hi Christian,

Dann hat man aber wieder die unnötige Wachzeit (und es passt nicht zu zwapi-Bsp.  ) Was bringt MULTI_CMD dann tatsächlich noch an Batterieschonung!?

die Wartezeit kann man ja über WNMI_delay "tunen" und an sein System anpassen, je nachdem ob man Notifies auf der WUN triggert oder nicht. Mulit_CMD verringert ja auf jeden Fall die Anzahl der Nachrichtenpakete und das macht sich auf Dauer schon bemerkbar.

Bin doch noch ganz am Anfang des Experimentier- und Überlegungsprozesses und sehr sehr weit vom richtigen Einbau weg: Ich hatte es in der parse-Routine direkt nach Erkennung "28407" vor dem Timerstart eingebastelt. Längenprüfung, Stackanpassung und Co. habe ich nicht gemacht.

Ah, ok, Du machst es also erst wenn die WUN ankommt. Ich muss mir den Ablauf wohl noch mal anschauen, auch um zu sehen an welcher Stelle Rudis Vorschlag ansetzt.

So langsam gehen wir aber an die Feinheiten der Implementierung ,-)
Gruß,
Andreas.

[krikan]

die Wartezeit kann man ja über WNMI_delay "tunen" und an sein System anpassen, je nachdem ob man Notifies auf der WUN triggert oder nicht.

Ok, das waere dann der manuelle Weg, der mir eigentlich nicht gefaellt.

Mulit_CMD verringert ja auf jeden Fall die Anzahl der Nachrichtenpakete und das macht sich auf Dauer schon bemerkbar.

Irgendwo gab es mal ein Übersicht, wieviel eine Nachricht an Energie verbraucht. Der Erinnerung nach war das nach Chipsaetzen getrennt ausgewiesen. Finde das aber nicht mehr.

[A.Harrenberg]

Hi,

Ok, das waere dann der manuelle Weg, der mir eigentlich nicht gefaellt.

aber wie willst Du denn eventuelle Notify abfangen wenn Du das Gerät sofort wieder schlafen schickst?
Man könnte mal darüber nachdenken die Default-Wartezeit (sind das momentan eigentlich 2 oder 2.5 sekunden??) auf z.B. 0.5 sekunden abzusenken, das sollte im Normalfall eigentlich immer für die Kommunikation reichen. Wer längere Notify hat muss dann die Zeit über WNMI_delay halt wieder hochsetzen.

Das meiste Sparpotenzial dürfte nach wir vor das WU-Intervall darstellen. Ob man alle möglichen Werte wirklich immer alle 15 Minuten benötigt sollte man immer in Frage stellen.

Gruß,
Andreas.

[krikan]

Hi,aber wie willst Du denn eventuelle Notify abfangen wenn Du das Gerät sofort wieder schlafen schickst?

Eines der vielen Probleme. Hatte schon mal darüber nachgedacht 0,5 Sek auf notifys zu warten und erst dann überhaupt Nachrichten per MULTI_CMD zu verschicken. Das dann aber wieder verworfen.
Je mehr ich über das Thema nachdenke, desto mehr Vorbehalte gegen MULTI_CMD bekomme ich.
Grundproblem: Komplexität erhöht sich für mich deutlich für eine unbekannte Batterieschonung und eventuelle Reduzierung der Funktelegramme.

[A.Harrenberg]

Hi,

Eines der vielen Probleme. Hatte schon mal darüber nachgedacht 0,5 Sek auf notifys zu warten und erst dann überhaupt Nachrichten per MULTI_CMD zu verschicken. Das dann aber wieder verworfen.

Ich würde die Probleme ja trennen und die WNMI da nicht mit reinnehmen.

Je mehr ich über das Thema nachdenke, desto mehr Vorbehalte gegen MULTI_CMD bekomme ich.
Grundproblem: Komplexität erhöht sich für mich deutlich für eine unbekannte Batterieschonung und eventuelle Reduzierung der Funktelegramme.

Komplexität erhöht sich definitiv, Hauptersparnis liegt wohl auch eher beim Senden des Sensors. Wenn der z.B. alle 6 Sensorwerte in eine Nachricht reinbekommt das 6 einzelne Nachrichten zu verschicken dann hat das einen großen Einfluß. Im allgemeinen sollte sich bei Batteriegeräte (hoffentlich) nie viel im WU-Stack ansammeln, falls doch stimmt das Konzept nicht...

Aber an die Kapselung CRC16, MULTI_CMD, SECURITY, TRANSPORT_SERVICE müssen wir früher oder später trotzdem mal ran. Aber wie ich schon ganz zu Anfang mal schrieb, das sind mittlerweile echt Feinheiten, insgesamt haben wir hier schon ein recht gut laufendes System hingestellt!

Gruß,
Andreas.

[rudolfkoenig]

Im allgemeinen sollte sich bei Batteriegeräte (hoffentlich) nie viel im WU-Stack ansammeln

Sehe ich anders: alles was der Benutzer absetzt, wenn ein Geraet "schlaeft", sammelt sich da. Auch wenn notifies auf WUN reagieren, landen die Befehle auf dem Stack. Ob eine Zusammenfassung viel bringt, kann ich pauschal nicht beurteilen, und haengt vmtl. auch vom Geraet ab.
Die anderen Kapselungen koennte man auch an dieser Stelle erledigen.

CRC16 sehe ich kritisch: da das CRC nicht auf der unteren Ebene geprueft wird, muss eine Wiederholung (wenn ueberhaupt) auf der oberen Ebene zusaetzlich implementiert werden, und hier gibt es keine Moeglichkeit einer Wiederholungs- oder "Kam falsch an"-Erkennung. Man kann also die Nachricht nur wegschmeissen, dafuer ist der Nutzwert mAn nicht besonders hoch.

Fuer CRC und MULTI_CMD gilt: wie "motiviere" ich die Gegenseite, diese Klassen fuer die gesendeten Nachrichten zu verwenden?