IP-Symcon 5.1 //Z-Wave Upgrades

Ich möchte hier ein Thema erstellen, welches als Sammelbecken für die aktuelle Z-Wave Überarbeitung dienen soll.

Generelle Verbesserungen:

[ul]
[li]Wir lesen beim Laden fast alle Informationen aus dem Gerät auf einmal aus. (Insbesondere auch Assoziationen, Beschreibungen für Assoziationen, WakeUp Intervalle…)[/li][li]Ein Nachladen ist nur noch für Parameter erforderlich. Diese werden aber nach dem Auslesen ebenfalls gecached, sodass beim erneuten Öffnen diese sofort zu sehen sind.[/li][li]Die Konsole wartet bei batteriebetriebeben Geräte nicht mehr darauf, dass das Gerät aufgeweckt wird. Die Befehle werden immer in die Queue gelegt und entsprechend auch in der Konfiguration als „noch in Bearbeitung“ markiert. Dadurch können mehrere Änderungen vorgenommen werden, die dann auf einmal Übertragen werden. Sobald die Queue abgearbeitet wurde, wird dies ebenfalls direkt angezeigt.[/li][li]Wir zeigen in einem Dialog alle Unterstützten Kommando-Klassen an (je nach Secure/Insecure und welche Version das Gerät bzw. IP-Symcon unterstützt)[/li][li]Parameter können unabhängig der ZWDB hinzugefügt werden und werden auch gespeichert. Alle Parameter Werte werden nach dem Auslesen von IP-Symcon gecached.[/li][li]Das Routing Fenster bietet Optionen um batteriebetriebene oder nicht erreichbare Knoten zu filtern[/li][li]Der Konfigurator hat Optionen für NWI (Network Wide Inklusion) und Sendeleistung beim Inkludieren[/li][li]Im Gateway können Einstellungen für Wiederholversuche angegeben werden. Eine Nachricht wird somit X mal versucht zuzustellen mit Y Sek Pause zwischen den Versuchen[/li][li]Im Gateway kann ein Schwellwert eingestellt werden, ab wie viel aufeinanderfolgenden fehlgeschlagenen Nachrichten die Instanz rot markiert und deaktiviert werden soll. Diese Instanz darf dann nicht mehr Senden, bis diese reaktiviert wird.[/li][li]In der Instanzkonfiguration gibt es Statistiken zu versendeten, empfangenen und fehlgeschlagenen Nachrichten.[/li][/ul]

Verbesserungen bei Kommando-Klassen:

[ul]
[li]DEVICE_RESET_LOCALLY (V1)[/li][LIST]
[li]Wenn das Gerät zurückgesetzt wird, meldet es sich und wir setzen die Instanz auf „Defekt“[/li][/ul]

[li]BINARY_SENSOR (V2)[/li][li]METER (V5)[/li][li]VERSION (V2)[/li][li]APPLICATION STATUS (V1)[/li][li]ASSOCIATION_GRP_INFO (V3)[/li][ul]
[li]Bei den Assoziationsgruppen werden nun Klartextnamen wie z.B. Lifeline angezeigt[/li][/ul]

[li]SENSOR_MULTILEVEL (V11)[/li][ul]
[li]Wir lesen beim Laden alle vorhandenen Sensoren aus und erstellen dafür direkt Variablen (Die alte „Multilevel“ Variable ist obsolet und wird nur aus legacy Gründen beschrieben sofern vorhanden. Könnt ihr löschen!)[/li][/ul]

[li]MANUFACTURER_SPECIFIC (V2)[/li][ul]
[li]Mehr Daten zum Gerät im Debug-Fenster (z.B. Seriennummer) beim Laden[/li][li](Dies scheint bei vielen Geräte falsch implementiert zu sein!)[/li][/ul]

[li]PROTECTION (V2)[/li][ul]
[li]Zusätzlich zur lokalen Sperre kann eine Empfangssperre auf der Funk-Seite aktiviert werden[/li][/ul]

[li]MULTI_INSTANCE (V4)[/li][li]ZWAVEPLUS_INFO (V2)[/li][ul]
[li]Liefert nicht wirklich spannende Informationen. Man kann sich die Infos (Version, RoleType, NodeType, InstallerIconType, UserIconType) aber über ZW_GetInformation($id) rausholen.[/li][/ul]

[li]NOTIFICATION (V8)[/li][ul]
[li]Es wird pro Typ nur noch eine Variable jedoch mit einem passenden Variablenprofil zum Zustand angezeigt. Ältere Geräte setzen den Zustand nicht auf OK zurück, ab V8 ist dies jedoch Pflicht, sodass diese Variante die zukunftssichere ist und für ältere Geräte keinen Nachteil bietet.[/li][/ul]

[li]MULTI_CHANNEL_ASSOCIATION (V3)[/li][ul]
[li]Sofern das Gerät die Klasse unterstützt, wird diese vorrangig gegenüber der normalen ASSOCIATION Klasse verwendet. Insbesondere ist dies nützlich, sofern V3 unterstützt wird und IP-Symcon sich dadurch als Gateway auf alle Channels gleichzeitig registrieren kann.[/li][/ul]
[/LIST]

Bitte erstellt ein Backup. Ein zurückgehen ist nur mit zurückspielen der settings.json möglich.

(Aktuell ist eine Konfiguration nur über die Legacy Konsole möglich.)

zwavenwi.png

Konsole Z-Wave.PNG

Hi Paresy,

schön, dass ihr an Z-Wave arbeitet !!! (Am Wochenende hatte ich doch keine Zeit für einen Test - Sorry)

Die Konsole startet bei mir nicht…

Ciao
HerbertF

Stimmt. Das sollte nicht sein. Habe eine neue Version hochgeladen. Diese funktioniert trotzdem ausschließlich mit der neusten Z-Wave IP-Symcon Version. Die kommt in den nächsten Stunden noch im Ninja Kanal.

paresy

Leider verschiebt sich die Z-Wave Version auf Morgen… Ich habe noch einen doofen Fehler gefunden, den ich korrigieren will.

paresy

Hallo
Mit der aktuellen (neuen) Version kann ich keine meiner
Z-Wave Module (Instanzen) oeffnen.
Bei allen kommt sofort die Fehlermeldung:
„Eigenschaft MultiInstanceCount nicht gefunden“

Gesendet von iPad mit Tapatalk

Hast du die Konsole aus dem 1. Beitrag genommen? Dort ist ein spezieller Anhang zwischen den Bildern versteckt :smiley:

paresy

Werden Updates der Testing Version auch zeitgleich in der Ninja Version bereitgestellt? Also könnte man ohne Nachteile wechseln?

Gruß

Burkhard

Ja. Die Versionen kommen immer zeitgleich (bzw. kurz hintereinander ;)).
Es sind hier also immer alle Fixes der „Testing“ Version mit drin.

paresy

OK, das wars.

Gesendet von iPad mit Tapatalk

Servus,
nachdem ich anch der Ankündigen gesetern stundenlang mit dem Finger am „Update“ Knopf gesessen bin hab ichs mir es dann heute gleich gezogen. :loveips:

Hier die ersten Eindrücke:

  • Die Grundfunktionen scheinen zu laufen.

  • mir scheint ihr habt einige Timeouts deutlich enger gesetzt. Bei vielen Geräten bekomme ich bei „Gerätekonfiguratioen laden“ und bei „Aktualisierungsanfrage“ eine Timeout Meldung. Das Gerät hat aber geantwortet, da Variablen aktualisert werden.
    Das passiert quer durch durch den Gerätepark, vorher hatte ich nur bei Flirs Geräten

  • Die NeoCoolCam Plugs werden nun scheinbar vollständig unterstützt. es wird nun Meter(1), Meter(4) und Meter (5) angelegt und befüllt. Der alte Workaround kann weg.
    Allerdrings nicht zuferlässig, denn bei manchen gibt es Timeouts und dann werden die Variablen nicht angelegt.

  • Verstehe ich es richtig das man entweder die Parametertabelle aus der Datenbank, verwnden kann, ODER ALLE selbst definieren muß ? Wenn Haken bei „Load data from …“ rausmache ist die Tabelle nämlich leer.

  • das die Parameter nun gecached werden ist super - most wanted feature -

Ah ja, und das die Legacy Konsole doch noch mit Neuigkeiten unterstützt wird gibt extra Pluspunkte :slight_smile:

Am Abend mache ich weitere Tests, muß jetzt mal kurz weg.

gruß und vielen vielen Dank
bb

Uuups, gab grad Schimpf meiner Frau: " Ich kann kein licht mehr einschalten, da kommt eien komische Meldung"

Ursache (Fabaro Dimmer): Ich hab im Webfront die Variabe „Status“ verlinkt. Vorher konnte man die übers WF schalten.
Das geht nun nimmer, es kommt „Keine Aktion für VariablenIdent " StatusVariable“ gefunden.

Wenn ich die Varaibel "Daten (Boolean) verkinke geht es wieder.

Bug oder Feature ?

Ja, und wie schon geschrieben ist das LOG voll mit unendlich vielen roten Timeout Meldungen. Werde später schauen was da los ist.

bb

Timeout brim Laden: Die Anzahl der Nachrichten haben sich verdoppelt/verdreifacht. Somit ist die Wahrscheinlichkeit höher dass etwas schief geht. Das wird besser sobald ich die Retries drin habe.

Status Keine Aktion: Bug

Timeouts im Log: Könnten Bugs in IPS sein. Freue mich über Details.

Parameter: du kannst beides hin und her schalten nach Belieben. Deine Parameter bleiben im Hintergrund immer gespeichert.

paresy

Hi Paresy,

bei einem Fibaro 2-fach Aktor:

Nach erneutem Laden ändern sich die falschen Assoziationen (die oberste von 171 in 176 …)

asso.PNG

Hmm, so möchte ich aber nicht so stehenlassen.
Retries sollten doch die Ausnahme sein und nicht die Regel, oder ? Sowohl Laden als auch Aktualisierungsanfrage klappt nur sehr selten.
Im überwiegenden Fall gibt es ein Timeout. An der Variablenanzahl hat sich nichts geändert.
Auch die Parameterabfrage geht kaum ohne Timeout.

Beim Löschen von Geräten gibt es diese Meldung:
Unbenannt.JPG

JA / NEIN hmm was soll man nehmen. Denke der Dialog bräuchte nur ein „OK“

Ja und die roten Zeilen im Log kommen auch von Timeouts. Ich polle dieSpirit Thermostate, bei denen geht keine einzige Aktualisierungsanfrage ohne Timeout.

Dann hab ich noch:
„Objekt mit Ident Meter4Variable wurde nicht gefunden“ und „Objekt mit Ident Meter5Variable wurde nicht gefunden“
Das kommt von den NeoCoolcam Plugs. Die entsprechednen Variablen fehlen.
Bei manchen wurden aber die zugehörigen Variablen angelegt- dann kommt keine Meldung. Interesannterweise auch keine Timeouts.
Gepollt werden die Plugs nicht.

gruß
bb

Nachwas:

Mir scheint die Intervalldauer für die Aktualisierung ist beim Update verlorengegangen. Hatte das konfiguriert, nun steht da aber „0“ drin.
Unbenannt.JPG

und noch eins:

Im Routing Fenster blendest du wenn „Only Show Repeating Nodes“ angehckt ist auch den „Static Controller“ aus.
Ok, sachlich istd as zwar richtig, dessen Anzeige würde ich mir aber trotzdem erwarten damit man sieht ob das Gerät geroutet wird oder direkt mit dem Controller spricht.

bb

@herbertf: Ich müsste mir das Problem bei dir ansehen. Ich befürchte aber eher, dass dies ein Bug im Z-Wave Stack deines Gateways sein wird… Aber wir schauen.
@bbernhard:

  • Wenn wir 50 Nachrichten hintereinander senden, dann ist die Wahrscheinlichkeit einfach höher, dass etwas fehl schlägt. Das ist somit nicht die Regel, aber mit mehr Nachrichten steigt eben die Wahrscheinlichkeit dass es fehl schlägt. Wir haben das Retry Handling zum nächsten Update eingebaut. Ich bin gespannt auf dein Feedback.

  • Yes/No -> Korrigiert

  • Objekt mit Ident Meter4Variable wurde nicht gefunden <- An den Geräte ist bestimmt das „Laden“ noch nicht vollständig durchgegangen, oder?

  • Aktualisierungsintervall -> Nur falsch angezeigt. Fixed im nächsten Update.

  • Routing -> Ist direkt eine Funktion der Serial API. Da habe ich leider keinen Einfluss drauf.

Update ist am Bauen… :wink:

paresy

Servus

Zum Thema Retry: Ich befürchte halt das damit nur andere substantielle Schwächen zugedeckt weren. Ich programiere beruflich auch immer wieder diverses Kommunikationszeug. Ein „uuups Fehlgeschlagen, probier ma halt naochmals“ ist da ziemlich sehr verpönt und wird nur im absoluten Notfall verwendet.
Ich kenne jetzte die Untiefen des zWave Protokolls nicht, rein aus Anwendersicht würde ich mri aber erwarten das es im Normalfall ohne repeats klappen sollte.
Das war gestern aber nicht der Fall, würde mal sagen das es in mindestens 90% der Fälle ein Timeout gab. Und das bei perfekt vermeshten Geräten im unmittelbaren Nahbereich des Gateways.

Zur ccfdf29a2737:
Das mit den Timeouts ist nun wesetlich besser. Bei Geräten welche direkten Gateway tritt es nicht mehr auf.
Bei gerouteten Geräten aber immer noch regelmäßig.
Ebenfalls bei allen FLIRS Geräten (Spririt Thermostat) welche nicht im Nahbereich des Gateways sind ( das Gateway ist aber in der Routing Liste)
Die Retry Settings sind noch alle auf Standardeinstellung. -> soll ich etwas rumprobieren ?

Zu:
BB: „Im Routing Fenster blendest du wenn „Only Show Repeating Nodes“ angehakt ist auch den „Static Controller“ aus.“
Paresy: Routing -> Ist direkt eine Funktion der Serial API. Da habe ich leider keinen Einfluss drauf.
Klar, die Routingtabelle kommt from Controller.
Aber stelle dir mal das richtige Leben vor: Wenn ich nach am Routing eines Gerätes interessier bin klicke ich mal obiges an. Denn no repeating Nodes interessieren mich da nicht. dadurch sehe ich aber auch nicht das der Node auch direkt mit dem Gateway kommuniziert.
Du mußt ja nicht skalvisch das zugegeben fachlich richtige anzeigen. Meinetwegen packe das Gateway in ein extra Anzeigefeld.

Funktional ist seit gestern Abend Tag im produktiven Betrieb noch nichts Negatives aufgefallen.-

Ein kleiner Funktionswunsch: Kann die Geräteliste im Konfigurator per Klick auf die Spaltenheader sortierbar gemacht werden? Dann wäre es viel leichter das jeweils gesuchte Gerät schnell zu finden.

gruß
bb

Ich denke an den Einstellungen macht es nicht viel sinn zu spielen. 3 Wiederholungen sind definitiv genug meiner Meinung nach. Die Ursache muss also eher eine andere sein.

Magst du mal auf einem der betroffenen Geräte folgendes ausführen:


echo (int)IPS_GetProperty($id, "EnforceAcknowledge");

Falls dort 0 zurück kommst, kannst du versuchen dies explizit zu aktiveren mit IPS_SetProperty($id, „EnforceAcknowledge“, true) und IPS_ApplyChanges($id). Normalerweise sollte IPS automatisch erkennen, dass dies ein FLIRS Gerät ist, und diese Property auf true setzen, wodurch explizit auf ein ACK gewartet wird. Vielleicht wurde dies nicht korrekt erkannt?

paresy

Nö, da kommt überall ein „1“ zurück.
Ich möchte aber nicht euch alleine die Schuld geben. Die Spirits waren vorher auch anfällig für Kommunikationsprobleme. Setzen der Zieltemperatur und Aktualisierungsabfrage ging auch dann und wann daneben (allerdings selten genug um nicht zu stören).
Wenn ihr nun also mehr Daten abfrägt - auf welcher Grundlage eigntlich, denn Laden klappt ja auch nicht - dann geht auch öftre was schief wie du ja schon erwähnt hast.

Habe übrigens auch noch ein Danalock mit FLIRS. Da läuft bis dato alles sauber. Es ist aber auch näher beim Gateway :rolleyes:

bb