Regelmäßiges neighborUpdate

[rudolfkoenig]

Ja, ich fuerchte sowas brauche ich.

[rudolfkoenig]

Ich habe jetzt eine Version mit dem neuen Attribut useMultiCmd eingecheckt:

Experimental: if a device supports MULTI_CMD and WAKE_UP, then pack
multiple get messages on the SendStack into a single MULTI_CMD to save
radio transmissions.

[ToKa]

Hallo,

ist diese Änderung schon über das normale Update verfügbar? Wie erkenne ich, ob ein Gerät MULTI_CMD unterstützt? Sollen dann beide neuen Attribute gesetzt werden?

Für das Erstellen der log was wäre Dir da lieber
1. Drei getrennte notifys, die jeweils auf wakeup reagieren?
2. Drei getrennte notifys, die auf einander aufbauen, also jeweils auf das event des vorher abgefragen Werts reagieren?
3. Ein notify, in dem alle 3 Werte abgefragt werden?

Gruß

Torsten

[rudolfkoenig]

update ist immer ein Tag verspaetet (warst nicht du, der die update-Doku lesen wollte?)

Sonst sind mir die notifies egal, Hauptsache ich sehe dein Problem.

Und bitte erst ohne das useMultiCmd Attribut, damit ich dein Problem fixen kann.

Das neue Attribut unterstuetzt Geraete, die im classes Attribut MULTI_CMD und WAKE_UP haben.

[ToKa]

Nein, war ich nicht, aber danke für den Wink mit dem Zaunpfahl 

OK, dann werde ich morgen abend oder am WE testen. Die COMET haben kein MULTI_CMD.

Gruß
Torsten

[ToKa]

Anbei eine Datei mit fhem log Auszügen (zwave dongle verbose 5) und den entsprechenden log Auszügen der Geräte bzw. für eines auch ein list, bei dem man wieder erkennt, dass Nachrichten auf dem sendstack hängen. In den aufgezeichneten Fällen sind wieder doppelte / mehrfache Einträge vom gleichen event / reading im Log, teilweise sind auch duplicate Meldungen im fhem log.

ignoreDupMsg ist bei allen Geräten gesetzt und aktuell wird ein notify mit 3 get Befehlen verwendet.

Ich hoffe, die logs reichen schon für eine weitere Anaylse.

Beste Grüße
Torsten

[rudolfkoenig]

Ich habe useMultiCmd mit meinem ZWave.me KFOB getestet, es funktioniert: 3 gets wurden zu eine Funknachricht verpackt, worauf das kfob auch nur einmal geantwortet hat. FHEM packt die Antwort aus, und generiert 3 Events, fuer den Benutzer sollte sich also nichts aendern. Ich musste den Code leicht anpassen, damit auch die nicht per WUN-Notify, sondern die vorher, manuell ausgeloesten Gets zusammengepackt werden. Da noch keine Grenze eingebaut ist, kann das noch bei vielen gets zu einem Problem werden.
Ob das zusammenpacken aktiv ist sieht man in "list kfob": auf dem SendStack ist nur ein laengeres get: vorhanden.

Bemerkenswert: mit einer alten Batterie hat das KFOB zwar einzelne Knopfdruecke gemeldet, eine Antwort auf get kam nur sporadisch an, neu anlernen ging auch nur halb. get battery hat (wenn es geklappt hat) 60% gemeldet. Mit der neuen Batterie gibt es keine Probleme. Die alte CR2032 Batterie war 20 Monate alt, und ich verwende das KFOB nur zum Entwickeln, d.h. seltene, dann aber ueberdurchschnittliche Benutzung. Mit der alten Batterie hat das Druecken von #2 im Management Mode nur ein WUN gesendet, jetzt wird freiwillig 2xWUN + battery geschickt. ignoreDupMsg meldet jetzt brav "kfob: ignore duplicate WUN".

Merke: im Zweifel eine neue Batterie probieren.

@ToKa
- im ersten Abschnitt sieht man ein WUN vom ST.sz.HR.Heizung (0d), daraufhin ein generieren von 3* get, und Versenden des Ersten. Dann kommen noch 2 WUN (in 0.11s und 0.17s Abstand), die jeweils ignoriert werden. Mehr sehe ich nicht, vermutlich kommt auch nix, sonst wuerde dein SendStack anders aussehen.

- im Zweiten sendet E1.wz.HR.Heizung.Wand, da laufen die 3 gets durch, es wird ein duplicate setpointTemp anhand Callback-ID (CB:10) erkannt und ignoriert.

- im Dritten sendet E1.wz.HR.Heizung.Fenster, hier kommen mehrere setpointTemps, die nicht als Duplikate entdeckt werden, weil der Controller diese nicht mit dem gesendeten CB:02 versieht, sondern mit CB:00, als ob das Geraet was spontan gesendet haette. Ich meine das ist ein Controller-Bug, und fuehrt die Idee des Callback-IDs ad-absurdum. Wie man das abfaengt, weis ich im Moment noch nicht.

[ToKa]

Controller-Bug im Gerät oder im RaZBerry2?

event-min-interval mit 60s hat ja eigentlich "geholfen", wenn das mit dem readingsChange nicht wäre. Könnte man nicht über ein weiteres Attribut was ähnliches einstellen?

Etwas versehe ich nicht, am nachfolgenden Beispiel. Im FHEM Log wurde protokolliert, dass doppelte Anworten zu setpointTemp ignoriert wurden, im List des Geräts sieht man dann, dass für setpointTemp aber gar kein aktueller Wert um 21:26:05 Uhr gespeichert wurde. Es stehen aber auch noch Befehle auf dem sendstack... u.a. mal wieder das "sentackget".

Code Auswählen Erweitern

2017.01.29 21:26:05.215 3: ZWave get E2.ku.HR.Heizung smStatus
2017.01.29 21:26:05.220 3: ZWave get E2.ku.HR.Heizung setpoint
2017.01.29 21:26:05.222 3: ZWave get E2.ku.HR.Heizung swmStatus
2017.01.29 21:26:05.224 3: ZWave get E2.ku.HR.Heizung thermostatMode
2017.01.29 21:26:06.241 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.285 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.479 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.725 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.795 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating


Code Auswählen Erweitern

Internals:
   DEF        d14c12e6 31
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     69
   NAME       E2.ku.HR.Heizung
   NR         132
   STATE      <strong>Ist: </strong>21.0 °C<strong> / Soll: </strong>20.5 °C</br><strong>Ventil: </strong>19 %
   STILLDONETIME 0
   TYPE       ZWave
   ZWAVE1_MSGCNT 69
   ZWAVE1_RAWMSG 0004001f063105012200d2
   ZWAVE1_TIME 2017-01-29 21:26:05
   ZWaveSubDevice no
   homeId     d14c12e6
   ignoreDupMsg 1
   isWakeUp   1
   lastMsgSent 1485721565.48161
   nodeIdHex  1f
   Helper:
     Dblog:
       Reportedstate:
         Logdb:
           TIME       1485720659.29974
           VALUE      19
       Setpointtemp:
         Logdb:
           TIME       1485720659.0075
           VALUE      20.5
       Temperature:
         Logdb:
           TIME       1485721565.52128
           VALUE      21.0
       Wakeup:
         Logdb:
           TIME       1485721565.22637
           VALUE      notification
   Readings:
     2017-01-29 13:37:02   SEND_DATA       failed:00
     2017-01-28 08:39:00   UNPARSED        SENSOR_MULTILEVEL 023105
     2017-01-28 04:52:20   battery         100 %
     2017-01-17 07:57:20   desired-new     00
     2017-01-29 08:00:00   desired-temp    20.5
     2016-12-08 12:42:23   model           EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
     2016-12-08 12:42:23   modelConfig     eurotronic/eur_cometz.xml
     2016-12-08 12:42:23   modelId         0148-0002-0001
     2017-01-29 14:53:09   neighborList    EG.ga.SD.Glasbausteine E2.fl.SD.LEDLampe E2.ku.SD.Tischleuchte
     2017-01-29 14:52:31   neighborUpdate  done
     2017-01-29 21:10:59   reportedState   19
     2017-01-29 21:10:58   setpointTemp    20.5
     2017-01-29 21:10:59   state           dim 19
     2017-01-29 21:26:05   temperature     21.0
     2017-01-29 21:10:59   thermostatMode  heating
     2017-01-29 21:26:05   timeToAck       0.139
     2017-01-29 21:26:05   transmit        OK
     2017-01-29 21:26:05   wakeup          notification
   SendStack:
     sentackget:131f03430201258a
     get:131f022602258b
     get:131f024002258c
Attributes:
   DbLogInclude desired-temp,temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
   IODev      ZWAVE1
   alias      Küche
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   event-on-change-reading .*
   event-on-update-reading wakeup,temperature,setpointTemp
   group      Heizung
   icon       sani_heating
   ignoreDupMsg 1
   room       Übersicht
   sortby     3
   stateFormat {"<strong>Ist: </strong>".ReadingsVal('E2.ku.HR.Heizung','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('E2.ku.HR.Heizung','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E2.ku.HR.Heizung','reportedState','')." %"}
   userReadings desired-temp,desired-new
   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     ::

Gruß
Torsten

[rudolfkoenig]

Etwas versehe ich nicht, am nachfolgenden Beispiel. Im FHEM Log wurde protokolliert, dass doppelte Anworten zu setpointTemp ignoriert wurden, im List des Geräts sieht man dann, dass für setpointTemp aber gar kein aktueller Wert um 21:26:05 Uhr gespeichert wurde. Es stehen aber auch noch Befehle auf dem sendstack... u.a. mal wieder das "sentackget".

Ohne "ZWDongle verbose 5" log kann ich nur raten: der Controller hat die Callbackids durcheinandergebracht. 5 setpointTemp Nachrichten ist Novum fuer mich: ich war bisher ueberzeugt, dass es hoechstens 3 werden koennen.

Eine Zeitstempelbasierte Pruefung analog zu event-* in ZWave Modul ist komplizierter/aufwendiger in der Wartung, und ich zoegere noch sie einzubauen. Sie wird benoetigt, wenn:
- Abfragen benoetigt werden
- die Verbindung sehr wackelig ist, und Acks verlorengehen
- der Controller weder Doppelte filtert, noch das richtige CallbackId dem Paket zuordnet.
Wenn jetzt wieder jemand behauptet, nur Protokolle mit ACK seien sinnvoll, den werde ich zum debuggen dieses Falls zwingen.

Ich schlage vor, auf event-* umzustellen und das etwas aufwendigere stateFormat zu verwenden. Oder noch besser: fuer eine fehlerfreie Funkstrecke durch Hardware zu sorgen.

[ToKa]

Guten Abend,

ich würde ja gerne für eine fehlerfreie Funkstrecke sorgen, aber wie? Du hattest geschrieben: Nicht noch mehr Repeater , sondern bessere... aber welche sind besser? Ich habe  schon auf einen RazBerry2 umgestellt, da der ja angeblich mehr Reichweite hat und nutze Fibaro und Greenwave als Zwischenstecker.

Kannst Du mir noch sagen, wie Du das mit dem Controller Bug gemeinst hast? Ich kann auch meinen alten RazBerry noch einmal ausprobieren. Falls der Bug in der COMET Z Hardware liegt, kann ich gerne mal Eurotronic kontaktieren. Ich habe hier auch noch einen COMET Z rumliegen, da ich bei einer Heizung gar keine Verbindung zum Server erhalte und ich nicht noch einen überflüssigen Zwischenstecker kaufen wollte. Den könnte ich Dir schicken, falls es Dir irgenwie helfen würde.

Ansonsten bleibt mir nur Deinen Vorschlag umzusetzen und wieder event-min... zu nutzen. Würde dann wohl entsprechende UserReadings verwenden, um die Werte zu formatieren. Oder spricht etwas gegen UserReadings?

Beste Grüße
Torsten

[rudolfkoenig]

Bei Verbindungsprobemen versuche ich zuerst an der relativen Ausrichtung der Komponenten (bzw. deren Antennen) was zu aendern, oder eine bessere Antenne zu besorgen. Wobei laenger nicht besser, sondern staerker ausgerichtet ist.
Gegen UserReadings spricht nichts.

[ToKa]

Ausrichten bei den Heizungsventilen wird etwas schwierig. Ob die im inneren eine Antenne habe, kann ich nicht sagen - habe noch keinen zerlegt.

Es geht übrigens noch "besser.".. gleich 3 duplicate WUN, 4 duplicate UNPARSED und 14 duplicate temperature Meldungen. Die UNPARSED Meldung wurde nicht ins reeading übernommen.

Die einzige Änderung, die ich gemacht habe, ist nur noch den Temperaturwert im notify abzufragen. Ich wollte wissen, ob die Anzahl der abgefragten Werte eine Rolle für das Verhalten spielt. Das scheint aber nicht der Fall zu sein. Physikalisch hat sich nichts geändert, außer dass hier 2 Personen und 2 Katzen durchs Haus laufen...

Code Auswählen Erweitern

2017.01.30 19:51:07.991 3: ZWave get E2.ku.HR.Heizung smStatus
2017.01.30 19:51:08.633 3: E2.ku.HR.Heizung: ignore duplicate WUN
2017.01.30 19:51:08.706 3: E2.ku.HR.Heizung: ignore duplicate WUN
2017.01.30 19:51:08.907 3: E2.ku.HR.Heizung: ignore duplicate WUN
2017.01.30 19:51:09.333 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:09.723 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:09.917 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:09.992 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:10.526 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:10.754 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:10.897 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:10.940 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.024 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.162 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.325 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.390 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.520 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.660 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.154 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.429 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.495 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.778 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C


Code Auswählen Erweitern

Internals:
   DEF        d14c12e6 31
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     15
   NAME       E2.ku.HR.Heizung
   NR         131
   STATE      <strong>Ist: </strong>21.0 °C<strong> / Soll: </strong>20.5 °C</br><strong>Ventil: </strong>13 %
   STILLDONETIME 0
   TYPE       ZWave
   ZWAVE1_MSGCNT 15
   ZWAVE1_RAWMSG 0004001f063105012200d2
   ZWAVE1_TIME 2017-01-30 19:51:09
   ZWaveSubDevice no
   homeId     d14c12e6
   ignoreDupMsg 1
   isWakeUp   1
   lastMsgSent 1485802269.99647
   nodeIdHex  1f
   Helper:
     Dblog:
       Reportedstate:
         Logdb:
           TIME       1485797737.27128
           VALUE      13
       Setpointtemp:
         Logdb:
           TIME       1485797736.99946
           VALUE      20.5
       Temperature:
         Logdb:
           TIME       1485802269.58896
           VALUE      21.0
       Wakeup:
         Logdb:
           TIME       1485802267.99618
           VALUE      notification
   Readings:
     2017-01-29 13:37:02   SEND_DATA       failed:00
     2017-01-30 06:15:07   UNPARSED        SENSOR_MULTILEVEL 023105
     2017-01-28 04:52:20   battery         100 %
     2017-01-17 07:57:20   desired-new     00
     2017-01-30 15:30:00   desired-temp    20.5
     2016-12-08 12:42:23   model           EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
     2016-12-08 12:42:23   modelConfig     eurotronic/eur_cometz.xml
     2016-12-08 12:42:23   modelId         0148-0002-0001
     2017-01-29 14:53:09   neighborList    EG.ga.SD.Glasbausteine E2.fl.SD.LEDLampe E2.ku.SD.Tischleuchte
     2017-01-29 14:52:31   neighborUpdate  done
     2017-01-30 18:35:37   reportedState   13
     2017-01-30 18:35:36   setpointTemp    20.5
     2017-01-30 18:35:37   state           dim 13
     2017-01-30 19:51:09   temperature     21.0
     2017-01-30 18:35:37   thermostatMode  heating
     2017-01-30 19:51:10   timeToAck       0.577
     2017-01-30 19:51:10   transmit        OK
     2017-01-30 19:51:07   wakeup          notification
Attributes:
   DbLogInclude desired-temp,temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
   IODev      ZWAVE1
   alias      Küche
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   event-on-change-reading .*
   event-on-update-reading wakeup,temperature,setpointTemp
   group      Heizung
   icon       sani_heating
   ignoreDupMsg 1
   room       Übersicht
   sortby     3
   stateFormat {"<strong>Ist: </strong>".ReadingsVal('E2.ku.HR.Heizung','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('E2.ku.HR.Heizung','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E2.ku.HR.Heizung','reportedState','')." %"}
   userReadings desired-temp,desired-new
   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     ::

Gruß
Torsten

[A.Harrenberg]

Hallo Rudi,

wie kann es denn sein das 023105 als UNPARSED erscheint? Da stimmt doch was ganz gewaltig mit der Kommunikation nicht, bzw. ich würde da sogar auf einen Firmwarebug des Geräte tippen...

0x3105 ist der normale MultiSensor Report, die RegExp sieht so aus:

Code Auswählen Erweitern

"..3105(..)(..)(.*)

D.h. wir erwarten da im Normalfall drei oder mehr Bytes als Parameter, der Befehlt wird aber anscheinend OHNE Parameter mit Länge 2 geschickt... Oder die Länge ist durch Übertragungsfehler falsch empfangen UND die CS stimmt wieder?? Eher unwahrscheinlich...

@Torsten: Wie sieht denn deine neighbor map aus? Sind da alle gegenseitig so eingetragen wie es physikalisch auch sinnvoll ist?

Ich bereue es jedenfalls nicht das ich mich bei den Heizungssachen für Homematic entschieden habe.

Gruß,
Andreas.

[ToKa]

Hallo Andreas,

ich nehme an Du meinst die neighbor map, die man beim ZWAVE Dongle (bei mir RazBerry2) in fhem abrufen kann. Ich habe mal einen Screenshot angehängt.

Wie erkenne ich denn, dass die Einträge physikalisch sinnvoll sind?

Gruß
Torsten

[A.Harrenberg]

Hi,
ja, die meine ich.

Ich meine damit mal schauen ob die physikalisch "nah" benachbarten auch in der Map (in beiden Richtungen) Nachbarn sind und ob z.B. ein möglicher Router auf dem Weg dahin auch bei beiden Geräten als Nachbar auftaucht.

Auf den ersten Blick erscheint mir Deine Map aber sehr dicht. Hast Du die Geräte an ihrem Einsatzort angelernt oder auf dem Schreibtisch und dann dorthin gebracht? Im zweiten Fall müsstest Du die Neighbor List mal komplett neu aufbauen, das ist nicht ganz so einfach wie es sich anhört wenn da auch WakeUp Geräte dabei sind. Hier ist es schwierig die in die Neighborlist von einem Router zu kriegen, man muss dann dem potentiellen Router den Befehl zum Updaten der Nachbarn schicken während GLEICHZEITG das WakeUp-Gerät auch wach ist...

@Rudi, Christian: Könnten die mehrfachen Nachrichten evtl. auch durch Routing entstehen? Woran ist denn bei einem Paket zu erkennen das es geroutet wurde?

Gruß,
Andreas.