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:
define Batterie_abfrage at +*12:00 get sensor1,sensor2,sensor3........... battery
sind dann ja eher contra produktiv.
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.
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
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
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:
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