Überlastung des wakeUp Sendstack vermeiden

[tomspatz]

Wie es sich langsam, zumindest für mich auskristallisiert, ist es scheinbar NICHT von Vorteil irgendwelche Befehle für wakeUp devices sofort abzusetzen, somit auf den Sendstack zu legen und warten bis diese devices aufwachen und die etwaigen get's oder set's "abholen" oder eher "aufgedrückt" bekommen.
Das das so mal funktioniert ist auch wahrscheinlich in Ordnung, doch regelmäßige Abfragen, wies sie oft irgendwo stehen:

Code Auswählen Erweitern

define Batterie_abfrage at +*12:00 get sensor1,sensor2,sensor3........... battery
sind dann ja eher contra produktiv.

[krikan]

Woran machst Du das fest?
Ich behaupte, dass das nur in wenigen Sonderfaellen bei bestimmten Geraeten und unter bestimmten Randbedingungen zutrifft. -> "kaputte" Netze bzw. Geraete. Generell ist das gaenzlich unproblematisch.

Die Minimierung der aktiven Abfragen ist bei Wakeup-Geraeten aber grundsaetzlich zur Batterieschonung immer sinnvoll.

[ToKa]

Hallo zusammen,

ich hatte ja ähnliche Effekte wie tomspatz bei der Abfrage meiner COMET Z, so lange ich im notify mehrere Werte abgefragt habe. Es haben sich viele gets/sets auf dem sendstack angesammelt. Dies führt m.E. auch dazu, dass durch die fehlerhafte / unterbrochene Kommunikation zwischen Controller und Gerät dann "empfindliche" Geräte ganz aussteigen. Im Forum gibt es ja auch aktuell Beiträge, wo es darum geht, dass Geräte nach ein paar Stunden / Tagen nicht mehr ansprechbar sind.

Erst nach einem Neustart von fhem bzw. dem Herausnehmen/Wiedereinsezten der Batterien in den Geräten lief alles wieder für eine Zeit. Durch den Tipp von krikan aus dem einen notify für jeden abzufragenden Wert ein eigenes notify, die aufeinander aufbauen, zu machen, hat sich die Sache bei mehr stabilisiert. Bislang treten keine Komplettausfälle auf.

Die Abfrage verschiedener Geräte in einem at habe ich ohne Probleme im Einsatz. Hier kommt es zu keinem Chaos, da m.E. ja jedes Gerät einen eigenen sendstack hat. Ist dieser natürlich durch vorherige Abfrage bereits gefüllt, kann es bestimmt wieder zu den beschriebenen Ausfällen / Fehlermeldungen kommen.

Beste Grüße
Torsten

[tomspatz]

Ich hänge mal hier noch ein Paar Erfahrungen dran.
Vorab ich habe nichts peinlichst analysiert, einfach nur Beobachtungen.
Das Netzwerk "hier" besteht auf ca. 85 m² aus 26 230V betriebenen devices, Fibaro UP Aktoren, Fibaro Zwischenstecker, Aeon Heavy duty Switch.
Dazu kommen noch einige Batterie Betriebene Geräte. Danfoss LC-13, Fibaro Fenster Sensoren samt Temperatur Fühler, Fibaro Flood sensoren, Fibaro Motion Sensor und zwei Aeon Multisensoren.
Ergänzt durch einen Fibaro Button und eine Aeon Minimote. Ich behaupte einfach das das schon "eng" vernetzt ist.

Die Fehler die ich meine möchte ich nicht auf Ausfall beziehen, eher als Störung klassifizieren, die allerdings scheinbar die fhem Abläufe ggf. durcheinanderbringt.

In letzter Zeit habe ich mich tüchtig mit den Batteriebetriebenen beschäftigt um auf Ursachen der immer wieder entstehenden "ZWDongle_0 transmit NO_ACK" oder "ZWDongle_ProcessSendStack: no ACK, resending message" oder "ERROR: cannot SEND_DATA to device: transmit queue overflow".

Testweise habe ich alle set/get der Batteriebetriebenen bis auf die Thermostate abgestellt.
Die nötigen set/get habe ich statt den notyfis die ich bis dahin verwendet hatt in doifs umgebaut, diese dann allerdings immer auf "wakeup" Triggern.
Die Aeon Multisensoren bringen beim wakeup auch den Batterie Status mit. Die anderen Geräte scheinbar nicht, (oder ggf. erst bei einer Änderung des Batteriezustandes).
In diesen ca. 14 Tagen stellte ich diese o.g. "Fehler" fast ausschließlich bei den Thermostaten. Immer sporadisch, auch mehrfach nacheinander allerdings OHNE eine Beeinträchtigung der Funktion. Alle Temperaturänderungen wurden immer ausgeführt.
Der Magische wakup Wert ist übrigens 300 bei den LC-13, alle niedrigeren interwalle machen Vieeeel mehr der o.g. Fehler.
Jetzt wieder die Batterie Abfrage für die "anderen" devices eingeschaltet. Diese triggert auch auf wakup.
Interessant das die Fenster Sensoren alle einwandfrei funktionieren und auch die Temperaturen der angeschlossenen Sensoren übertragen.
Kaum fragt man sie nach den Batterien ab werden bei den mit den "schlappen" Batterien ca. weniger wie 20% NO_ACK produziert.

Alles meine Beobachtungen.
LG
Tom

[ToKa]

Hallo Tom,

wow, also bei dem Netzwerk kann man m.E. wirklich nicht davon ausgehen, dass es per se an der Kommunikation liegt. Hast Du es mal mit mehreren notifys bei den Abfragen probiert? Ich frage den Batteriestatus nur noch einmal am Tag ab (COMET Z Thermostate und Fibaro Rauchmelder).

Eine meiner Beobachtungen war noch, dass sobald ein defektes Gerät (einmal ein POPP Zwischenstecker und einmal ein COMET Z) im Netz waren, auch alle anderen Geräte mit den von uns beiden festgestellten Fehlermeldungen behaftet waren. Nachdem die defekten Geräte ersetzt waren, gab es schon weniger Fehler und wie bereits beschrieben, seit der Umstellung auf 3 notifys ist fast Ruhe.

Seit zwei Tagen habe aber nun den 3. COMET Z, der sich komplett aufgehängt hat und nur durch Batterie raus / rein, wieder zum Leben zu erwecken ist. Im letzten List des Gerätes fällt dann auf dem sendstack wieder ein sentackget auf:

Code Auswählen Erweitern

Internals:
   DEF        d14c12e6 18
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     272
   NAME       E1.wz.HR.Heizung.Fenster
   NR         83
   STATE      <strong>Ist: </strong>20.5 °C<strong> / Soll: </strong>19.5 °C</br><strong>Ventil: </strong>6 %
   TYPE       ZWave
   ZWAVE1_MSGCNT 272
   ZWAVE1_RAWMSG 00040012064303012200c3
   ZWAVE1_TIME 2016-12-20 11:48:43
   ZWaveSubDevice no
   homeId     d14c12e6
   isWakeUp   1
   lastMsgSent 1482230923.34393
   nodeIdHex  12
   Helper:
     Dblog:
       Battery:
         Logdb:
           TIME       1482205537.77427
           VALUE      100 %
       Reportedstate:
         Logdb:
           TIME       1482230017.39225
           VALUE      6
       Setpointtemp:
         Logdb:
           TIME       1482230923.38658
           VALUE      19.5
       Temperature:
         Logdb:
           TIME       1482230017.13436
           VALUE      20.5
       Wakeup:
         Logdb:
           TIME       1482230923.2531
           VALUE      notification
   Readings:
     2016-12-15 01:20:46   SEND_DATA       failed:00
     2016-12-01 06:05:28   UNPARSED        SWITCH_MULTILEVEL 022603
     2016-12-17 17:56:23   WunschTemp      00
     2016-12-20 04:45:37   battery         100 %
     2016-10-21 18:31:35   model           EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
     2016-10-21 18:31:35   modelConfig     eurotronic/eur_cometz.xml
     2016-10-21 18:31:35   modelId         0148-0002-0001
     2016-11-29 19:02:24   neighborList    EG.ga.ZS.Glasbausteine E1.wz.ZS.Tischleuchte E3.hk.ZS.Subwoofer
     2016-11-28 20:09:23   neighborUpdate  done
     2016-12-20 11:33:37   reportedState   6
     2016-12-20 11:48:43   setpointTemp    19.5
     2016-12-20 11:33:37   state           dim 6
     2016-12-20 11:33:37   temperature     20.5
     2016-11-10 19:48:59   thermostatMode  heating
     2016-12-20 11:48:43   timeToAck       0.105
     2016-12-20 11:48:43   transmit        OK
     2016-11-19 05:21:02   userCode        id 1 status 22 code 00c3
     2016-10-21 19:19:34   version         Lib 3 Prot 3.67 App 0.5
     2016-12-20 11:48:43   wakeup          notification
     2016-10-21 19:01:56   wakeupReport    interval 900 target 1
   SendStack:
     sentackget:13120231042538
     get:13120226022539
     set:1312064301012200dc250f
Attributes:
   DbLogInclude temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
   IODev      ZWAVE1
   alias      Wohnzimmer (Fenster)
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   group      Heizung
   icon       sani_heating
   room       Übersicht
   sortby     4
   stateFormat {"<strong>Ist: </strong>".ReadingsVal('E1.wz.HR.Heizung.Fenster','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('E1.wz.HR.Heizung.Fenster','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E1.wz.HR.Heizung.Fenster','reportedState','')." %"}
   vclasses   BASIC:1 BATTERY:1 MANUFACTURER_SPECIFIC:1 NODE_NAMING:1 SENSOR_MULTILEVEL:4 SWITCH_MULTILEVEL:3 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 VERSION:1 WAKE_UP:2
   webCmd     ::

Auch bei mir reine Beobachtungen und keine tieferen Analyse, zumal ich nicht permanent verbose 5 eingeschaltet habe.

Beste Grüße

Torsten