Z-Wave Statusabfrage (ab IP-Symcon 3.4)

Es gibt mehrere Möglichkeiten, wann Z-Wave Geräte ihren Status aktualisieren:

  1. Periodisch / Ereignisgesteuert

Neue Geräte senden Ihren Status automatisch, sobald eine Änderung stattfindet. Dies kann oft auch über Parameter beeinflusst werden, sodass einstellbar ist, wie oft z.B. eine Temperatur gesendet werden soll. In diesem Fall wird das Gerät seitens IP-Symcon gar nicht abgefragt und diese Funktionalität ist auch losgelöst vom altbekannten WAKEUP Intervall.

  1. WAKEUP Intervall

Fast jedes batteriebetriebene Z-Wave Gerät kann so konfiguriert werden, dass es zyklisch aufwacht und mit IP-Symcon kommuniziert. Dabei kann IP-Symcon seine interne Warteschlange abarbeiten, die für jedes Gerät verwaltet wird. Dort können z.B. neue Sollwerte, Änderungen von Parameter oder einfach nur Schaltbefehle sein. Im Regelfall sendet IP-Symcon dem Gerät nur, dass es schlafen gehen soll, um Energie zu sparen. Seit IP-Symcon 3.4 muss die Abfrage aller Statuswerte in genau diese Warteschlange eingereiht werden, was bis IP-Symcon 3.3 automatisch gemacht wurde. Dadurch ergibt sich der Vorteil, dass nicht immer alle Statuswerte abgefragt werden müssen, was auf lange Sicht die Batterie schont.

Also: Warum dieser Aufwand? IP-Symcon 3.3 war doch toll!

Der Aufwand lohnt sich in dem Moment, in dem ihr einen Stellantrieb besitzt. Dieser soll sich so schnell und so oft wie möglich melden, jedoch in den meisten Fällen direkt wieder schlafen gehen, um Batterieleistung zu sparen. Durch die Einstellmöglichkeit des Aktualisierungintervalls kann der Stellantrieb oft aufwachen und schauen, ob neue Soll-Werte vorliegen, jedoch nur z.B. alle 60 Minuten den restlichen Status abfragen.

Im Normalfall könnt ihr das Aktualisierungsintervall der Abfrage auf den selben Wert wie das WAKEUP Intervall setzen.

paresy

Hallo IPS-Team,
Also ich bin nach wie vor nicht glücklich mit der z-Wave Performance unter IPS 3.4 3778.
Gründe:

  1. Batterievariable der Fibaro Motionsensoren werden nur upgedated, wenn ich das Wake-Up Intervall auf 900-1200 s stelle. Mit der Standardeinstellung (7200s) bekomme ich NIE ein Battery-update (mehrmals getestet)
  2. Ein von 2 NorthQ-Stromsensoren meldet sich nur sporadisch obwohl ich ihn mitlerweile fast zu Tode optimiert habe und die Optimierungen problem- und fehlerlos durchlaufen. Dann habe ich für 3h alle 10 min Werte, ab dann wieder nur mal alle 4-8h obwohl das Wakeup Intervall und das Abfrage-Intervall auf 600 s steht.
  3. Z-Wave in 3.4 scheint sehr anfällig zu sein hinsichtlich CPU-Auslastung. Wenn die CPU Auslastung auf meinem Rechner auf 60% + ansteigt klappt kaum noch eine Abfrage oder ein Wake-Up Response.
    All diese Dinge sind mit 3.3 völlig problemlos gelaufen, weder an der Hardware, noch am Netz (zusätzlich Seonsoren o.ä.) wurde irgend-etwas verändert.
    Könnt Ihr mir Tips geben, wie ich mein System wieder auf die 3.3 Performance bringen kann ?
    Grüße
    hoep

Punkt 1 kann ich bestätigen. Ebenfalls das magische Auge von Fibaro unter IPS 3.4 #3778.

Nachtrag:

Ich bekomme bei den Fehlermeldungen nicht den kleinsten Hinweis, dass irgendwas bei der Abfrage des NorthQ-Sensors schieflaufen würde. Ich erhalte Fehlermeldungen zu diversen Fibaro-MotionSensoren,aber der NorthQ-Sensor scheint völlig ignoriert zu werden.:confused:


Debug Fenster

Moin…

… da auf anderen Post hier von den Entwicklern nicht reagiert wird versuche ich es in diesem Post noch mal.
In mehren anderen Posts im Forum wurde berichtet, das diverse Werte nicht in IPS aktualisiert werden… meistens Batteriebetriebene Nodes.

Leider kann ich das Verhalten bei Schwiegerelterns Z-Wave Installation auch feststellen.
Ich habe kürzlich 3 Rauchmelder von Vision und 2 CO-Melder von POPP installiert. Alle Geräte, egal mit welchem WAKE-UP intervall und egal welcher TIMER-Zeit, werden in IPS nur sporadisch aktualisiert und diese Zeit hat nie etwas mit der WAKE-UP Zeit zu tun.
Komischerweise, und das ist das was mich so stutzig macht, werden so ziemlich alle Geräte in recht kurzem Zeitraum nach einem Neustart von IPS aktualisert.
Ich bin der Meinung, das eure „Warteschlange“ nicht richtig oder massiv zu langsam abgearbeitet wird.

Ich habe diverse Geräte an zwei unterschiedlichen USB-Sicks ( TRICKLESTAR und S2 AeonLabs ) getestet, immer das gleiche Verhalten.Selbst wenn nur ein Node an einem Stick angemeldet ist.
Reichweitenprobleme kann ich ausschliessen, da der manuelle Wakeup sofort von IPS erkannt wird.

Ich verstehe nicht, warum Ihr auf die Hinweise und Probleme nicht wirklich reagiert. Hier habt mit der 3.4 massive Änderungen vorgenommen und seit dem wird von Problemen berichtet.

Ein User schrieb ja bereits, das er mit eurem Gateway keine Problme hat. Ich sehe es aber ehrlich gesagt nicht ein, 150€ zu bezahlen, damit wieder etwas funktioniert, was vor der 3.4 lief.

Ich lasse Euch gerne auf meinen Rechner bzw. den von Schwiegereltern, wenn Ihr was anschauen wollt oder ihr Logs benötigt. Es ist Teamviewer installiert.

Grüße,
Peter

Hallo PeterChrisben,
Ich vermute auch massivste Probleme mit der Abarbeitung der Warteschlange. Hatte ich ja auch schon geschrieben. Die Nicht-Reaktion der Entwickler finde ich offen gesagt sehr fragwürdig, sie wurden direkt angesprochen. Immerhin reden wir von einem DER Standards…Und als Erklärung wird die Verbesserung für den Stellantrieb bemüht, alle anderen Batterie-Sensoren funktionieren dann halt nur mehr eingeschränkt… 3.4 wird ja als Stable geführt. Sehe ich nicht so.
Es reicht halt nicht, nur mit (unterstellten) 3 -5 Nodes zu testen…, vor allem wenn man offensichtlich doch tief ins System eingreift…
That’s my 2 cents
Hoep

Hi Hoep,
das kenne ich so auch nicht vom IPS Team. Denke die Burschen haben gerade viel um die Ohren.
Ich bin ja nun schon ne Weile hier im Forum unterwegs und bis dato waren alle immer sehr bemüht Lösungen für Probleme zu finden.
Warum das ganze Z-Wave System in IPS so massiv verändert wurde (mit der obigen Begründung ) verstehe ich allerdings auch nicht.
Sie werden sich aber was dabei gedacht haben, sicher nicht um uns zu ärgern. :slight_smile:
Zurück zum Thema.
paresy hat mich bereits wegen einem Teamviewer-Date kontaktiert.
Ich werde hier berichten was raus gekommen ist.
Good Nacht,
Peter

Hi,

ich habe bei Win7 V4 auch jetzt hoffentlich jeden Haken bei „Timer aktiviert“ herausgenommen. Bringt bei Netz- und Batterie- gespeisten Geräten immer Fehler im Log.

Nähere Analysen habe ich noch nicht zum Aktualisierungsintervall vorgenommen.

Etwas POSITIVES: Seit einigen Wochen (5-6?) habe ich keinerlei Fehlversuche mehr, wenn ich bei Regen (Nebel…) meine Markisen alle (ca. 15) gleichzeitig hochfahre (zumindest den Befehl sende ich, meistens sind sie ja bei diesem Wetter schon oben).

herbertf

Gibt es eine Möglichkeit Parameter, die an das Gerät übertragen werden sollen, in diese Warteschlange einzureihen?

Wenn ich einen Parameter aus einem Skript heraus für ein batteriebetriebenes Gerät setzen möchte (mit ZW_ConfigurationGetValue), schlägt dies meist fehl, da sich das Gerät ja im Schlafmodus befindet. Der gesetzte Parameter scheint aber auch nicht beim nächsten Wakeup gesendet zu werden. Ein Trigger auf eine der Statusvariablen zu setzten und dann den Befehl auszuführen, wenn diese aktualisiert wird, ist auch nicht zuverlässig, da sich von Gerät zu Gerät die aktualisierten Variablen unterscheiden, bzw. manchmal das Gerät dann schon wieder schläft.

Oder bieten die neuen PHP Module eine Möglichkeit, direkt mitzubekommen, wann ein Gerät gerade wach ist?

Leider für beides nein. Ich finde die Idee aber eigentlich sehr gut. Erinnere mich bitte nach dem 4.0er Release noch einmal daran :slight_smile:

Übrigens ein wenig Feedback von meiner Analyse bei Peter:

  • Die WAKEUPs kommen korrekt in IP-Symcon an.
  • Die Befehle werden korrekt in IP-Symcon in die Warteschlange hinzugefügt.
  • Sobald das WAKEUP kommt, versucht IP-Symcon den ersten Befehl der Warteschlange abzuarbeiten.

Fakt ist jedoch, dass dies in einem Timeout fehlschlägt. Dadurch wird auch der Rest der Warteschlange nicht abgearbeitet. (Insbesondere wird dann die Aktualisierung der Batterievariable vermisst) Da der Befehl jedoch bei einem manuellen „WAKEUP“ funktioniert, bin ich noch etwas ratlos, warum es bei einem zyklischen WAKEUP nicht geht. Ich hatte zuerst vermutet, dass IP-Symcon auf das WAKEUP zu spät reagiert, was aber laut den Logs eigentlich nicht sein kann. Ich bin somit noch dran, warum es passiert. Ich halte es aber für fast bewiesen, dass hier in der Tat ein Bug vorliegt!

Ich bin somit an dem Thema dran. Danke für alle, die mir bereits Infos dazu geliefert haben!

paresy

Moin paresy,
gibt es bereits weitere News bezüglich des Problem mit den Rückmeldungen?
Grüße,
Peter

Leider noch nicht. Ich habe hier noch einmal alle unsere batteriebetriebenen Geräte angelernt (dabei auch die Fibaro Fenstersensoren, welche bei dir Probleme machen). Aber diese melden sich hier einwandfrei im korrekten Intervall. :frowning:

Ich verstehe einfach noch nicht, wann der Fehler auftritt. Ich vermute ja noch immer ein Timing-Problem. Kann das aber noch nicht wirklich nachvollziehen…

Hat eigentlich jemand von euch schon die 4.0er Beta getestet, ob diese auch die selben Probleme hat?

paresy

Naja… melden tun sich die Teile ja auch… es kam ja im Debug was an, nur IPS hat es nicht verarbeitet.
Der Melder im Keller sendet immer noch brav alle 10Min, was im Debug zu sehen ist, aber die Daten werden nicht verarbeitet.
Ich kann Dir gerne ein Melder schicken! Ich habe noch 3 Rauchmelder hier liegen. Auch den 2. Dongle wenn es euch hilft den Fehler zu finden.
Gruß,
Peter

Korrekt. Ich formuliere anders: Sie melden sich und IP-Symcon schafft es immer diese auch korrekt abzufragen :slight_smile:

paresy

Hallo Paresy,

das passiert bei mir auch bei Netzteil-versorgten Fibaro Rauchmeldern. Die verlieren alle 3 Tage den Kontakt, wenn ich sie dann manuell aktualisiere, was ohne Fehler sofort funktioniert (kein Routing-Problem), dann gehts wieder für 3-4 Tage.

Gruß
hoep

Moin… gibt es schon neue Erkenntnisse zum dem „Problem“?

Leider noch überhaupt nicht :frowning:

Hatte jemand von euch mal Zeit zu sehen, ob das Problem auch mit der 4.0 (Beta) auftritt?
Das würde zumindest weiter eingrenzen, wonach ich suchen muss.

paresy

Stürzt die 4.0 für Windows denn auch ab wie auf dem Pi?
Ich würde sonst mal ein Update auf die 4.0 bei Schwiegereltern wagen.
Auf dem Pi ist mir das mit KNX zu riskant. Mein Testsystem läuft zuhause max. 12-24 Stunden stabil und dann verabschiedet sich IPS.

Abstürze im laufenden Betrieb sind eigentlich eher seltener. Dein Problem mit KNX ist bisher leider auch ein Einzelfall. Ich weiß noch nicht so Recht wie wir dem auf die Spur kommen. Falls du Abstürze (also richtige Crashes hast) können wir die recht schnell gemeinsam Debuggen. Somit sollte diesbezüglich das Risiko gering sein.

paresy

Läuft… werde das debugging für Experten heute Nacht starten.
Werde berichten…
Peter