Regelmäßiges neighborUpdate

Begonnen von ToKa, 27 November 2016, 13:41:36

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatKönnten die mehrfachen Nachrichten evtl. auch durch Routing entstehen?
Ich meine nicht direkt durch Routing, sondern durch nicht angekommene ACKs.
Andererseits kenne ich nur das statische Routing, nicht das mit ExplorerFrames.

ZitatWoran ist denn bei einem Paket zu erkennen das es geroutet wurde?
Ich meine ZWDongle verraet das nicht. Im Funktelegramm / ZWCUL gibt es beim statischen Routing entsprechende Felder/bits.

Siehe auch meine Antwort #18. Es geht hier um Heizungsregler (und ich habe noch nie einen "vernuenftigen" mit ZWave gesehen), die ueber 2 Steckdosen geroutet werden. Wobei das ist nur angenommen, und nicht beobachtet. Bei mir wird ein mAn direkt erreichbares Geraet ueber 2 andere geroutet: der erste "Router" steht total abseits, der andere direkt neben dem eigentlichen Ziel.

krikan

Zitat von: rudolfkoenig am 30 Januar 2017, 09:53:11
5 setpointTemp Nachrichten ist Novum fuer mich: ich war bisher ueberzeugt, dass es hoechstens 3 werden koennen.
Nach dem ZWCul-Log https://forum.fhem.de/index.php/topic,44905.msg369521.html#msg369521 gehe ich von deutlich mehr doppelten Nachrichten aus, wenn der Controller nicht anhand der Sequenznummer irgendetwas ausfiltert. Das Log ist auch nur auf einer Frequenz, so dass Umschaltung 100k auf 40k gar nicht berücksichtigt wird.

rudolfkoenig

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

Achtung: neighborMap ungleich routingMap.

Der Controller speichert fuer jeden der Knoten maximal 4 Nachbarn, und verwendet sie nach einem mir unbekannten Algorithmus beim statischen Routing. MW hat der Kontroller ausser die Eigenschaft "Nachbar" nichts Weiteres, insb. sowas wie Qualitaet der Uebertragung nicht. Wie die neuere Variante mit Explorer Frames funktioniert, weiss ich nicht.

ToKa

Heißt das also, aus der neighborMap kann man nicht wirklich etwas über das zwave Netz sagen? Ich meine beim z-way Server gibt es eine Anzeige über die Verbindungen und die Qualität der Übertragung. Ich werde gleich mal von der zweiten Partition starten, auf der der z-way Server installiert ist und nachschauen, ob ich mich recht erinnere.

Mein Popp / Duwi ZW ZS 3500 Plugin Switch unterstützt soweit ich weiß keine explorer frames (SDK 5x). Laut neigborlist ist er aber so gut wie mit allen anderen Geräten verbunden.

ZWAVE1 ST.fl.SD.WakeUpLight ST.sz.RM.Decke KG.hw.RM.Decke KG.kr.RM.Decke E1.wz.SD.Tischleuchte E3.hk.ZS.unused E2.fl.SD.LEDLampe ST.sz.HR.Heizung E2.ez.HR.Heizung E4.az.HR.Heizung KG.hz.ZS.Zirkulationspumpe E2.ku.SD.Tischleuchte E1.wz.HR.Heizung.Wand EG.fl.HR.Heizung E2.ku.HR.Heizung ST.bz.HR.Heizung


Macht es Sinn beim POPP oder allen Geräten das attribut NoExplorerFrames zu setzen?

Gruß
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

krikan

Zitat von: ToKa am 31 Januar 2017, 19:25:20
Ich meine beim z-way Server gibt es eine Anzeige über die Verbindungen und die Qualität der Übertragung.
Wenn sich das nicht geaendert hat, enthaelt die Routing-Info von z-way nicht mehr Infos als unsere/Rudis Grafikvariante.
http://razberry.z-wave.me/docs/RaZberryEndUserManual20.pdf S. 13f
Ich wüsste auch nicht, wie z-way wirkliche Übertragungsqualitaeten ermitteln kann. Die  Möglichkeit soll erst in einem neuen SDK kommen.

ZitatMacht es Sinn beim POPP oder allen Geräten das attribut NoExplorerFrames zu setzen?
Probiere es aus. Glauben kann ich es nicht. Der Popp ignoriert die ExplorerFrames, weil er nicht damit umgehen kann. Die Geraete nutzen EF nur, wenn sie auf normalen Weg keine Verbindung bekommen. Und dann gab es schon einige Versuche.

Gruß, Christian

rudolfkoenig

ZitatIch werde gleich mal von der zweiten Partition starten, auf der der z-way Server installiert ist und nachschauen, ob ich mich recht erinnere.
Wenn ja, dann hast Du die Ehre per USB-/Sonstwas-Sniffer die Kommunikation zum Stick zu dokumentieren :)

A.Harrenberg

Hi Rudi,
Zitat von: rudolfkoenig am 31 Januar 2017, 08:40:29
Ich meine nicht direkt durch Routing, sondern durch nicht angekommene ACKs.
Andererseits kenne ich nur das statische Routing, nicht das mit ExplorerFrames.
schon klar, meinte das auch so.
Das würde dann aber doch eigentlich so ablaufen:
- Gerät schickt Nachricht, die kommt an, aber das ACK nicht mehr beim Gerät
- Gerät schickt Nachricht nochmal, kommt wahrscheinlich wieder an, ACK wieder nicht mehr beim Geräte
Jetzt meine ich mal gelesen zu haben das der dritte Versuch jetzt geroutet wird falls möglich
- Gerät schickt Nachricht an Router
und jetzt könnte man das weiterspinnen ob der ACK vom Router auch nicht beim Gerät ankommt oder ob dann später erst der ACK vom Controller an den Router nicht mehr ankommt...
In dem Fall müsste man aber eigentlich ab der dritten Nachricht eigentlich das Routing erkennen können, oder?

Zitat von: rudolfkoenig am 31 Januar 2017, 08:40:29
Ich meine ZWDongle verraet das nicht. Im Funktelegramm / ZWCUL gibt es beim statischen Routing entsprechende Felder/bits.
D.h. man müsste sowas noch mal mit einem CUL sniffen um das herauszufinden.

Bei den Explorerframes habe ich irgendwie abgespeichert das die "wild" verschickt werden aber irgendwie Ihren "Pfad" aufzeichnen und der erste der Ankommt hat gewonnen und wird als default route eingetragen, die übrigen werden ignoriert. Das gilt auch für die Router, die sollen nur auf das erste Paket reagieren und weitere ignorieren um das Schneeball->Lawinen Problem zu verhindern.

Könnte es evtl. sein. das hier so eine "Suche" per Explorerframes losgetreten wurde der Dongle aber alle davon empfängt?

Zitat von: rudolfkoenig am 31 Januar 2017, 08:40:29
Siehe auch meine Antwort #18. Es geht hier um Heizungsregler (und ich habe noch nie einen "vernuenftigen" mit ZWave gesehen), die ueber 2 Steckdosen geroutet werden. Wobei das ist nur angenommen, und nicht beobachtet. Bei mir wird ein mAn direkt erreichbares Geraet ueber 2 andere geroutet: der erste "Router" steht total abseits, der andere direkt neben dem eigentlichen Ziel.
Ich bin mit meinen Homematic auch ganz zufrieden, allerdings spinnt der USB-Adapter auch manchmal ganz fürchterlich, dann gibt es diese schönen disappeared / reappeared die nicht mehr aufhören, das log explodieren lassen und nichts geht mehr bis man es merkt und den Stick mal trennt und wieder ansteckt.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatKönnte es evtl. sein. das hier so eine "Suche" per Explorerframes losgetreten wurde der Dongle aber alle davon empfängt?
Finde ich plausibel. Dafuer muesste aber Controller "dumm" sein, und keine Ahnung vom EF haben.
Christian, kannst du bitte nachschauen? :)

ToKa

Zitat von: rudolfkoenig am 31 Januar 2017, 20:53:24
Wenn ja, dann hast Du die Ehre per USB-/Sonstwas-Sniffer die Kommunikation zum Stick zu dokumentieren :)

Wenn Du mir sagst, wie und was ich genau machen soll gerne. Gibt es eine Anleitung dafür? Ist aber kein Stick sondern der GPIO RazBerry2.

Anbei mal die Infos, die ich z-way entlocken konnte.

Gruß
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

krikan

Bin genügsamer als Rudi für den Du wireshark, ZWCul o.ae. benötigst.  ;)
Was sagt das z-way-server Log, wenn Du bei Routing Table auf Update klickst (1 Node genügt)?


rudolfkoenig

Ich sehe in den z-way Screenshots nichts, wofuer sich sniffen lohnen wuerde.
Wenn ueberhaupt, dann ist hier nur ein ZWCUL Mitschnitt interessant.

krikan

Zitat von: rudolfkoenig am 31 Januar 2017, 21:36:34
Finde ich plausibel. Dafuer muesste aber Controller "dumm" sein, und keine Ahnung vom EF haben.
Christian, kannst du bitte nachschauen?
Relativ erfolglos: Keine genaue Info gefunden, außer allgemeine Aussage, dass Duplikate per statemachine ausgefiltert werden müssen. Bei spontanen Nachrichten ohne CallbackId fällt mir kein vernünftiger Weg zur Duplikatserkennung ein. Kann mich auch nicht erinnern jemals konkrete Infos gelesen zu haben.

Was für dumme Controller sprechen könnte:
Die "professionellen" Systeme nutzen EF nur beim Start. Es werden mehrere Wert mit EF-TRANSMIT_OPTION 25 von den einzelnen Geräte abgefragt, die zwangsweise CallbackId enthalten. Nach Erhalt der Antworten wird im laufenden Betrieb nur noch mit TRANSMIT_OPTION 05 verschickt. Damit würde die Gefahr von wiederholenden Nachrichten, die den Controller fluten, verhindert/vermindert.

rudolfkoenig

Eigentlich wollte ich wissen, ob der Controller EF kann, ich gehe von einem JA aus.

ZitatDie "professionellen" Systeme nutzen EF nur beim Start.
Ich ziehe "kommerziell" vor :)
Jungs: koennt ihr bei den problematischen Geraeten "noExplorerFrames" setzen, und berichten?

krikan

Zitat von: rudolfkoenig am 01 Februar 2017, 14:08:03
Eigentlich wollte ich wissen, ob der Controller EF kann, ich gehe von einem JA aus.
Dann verstehe ich Deine Frage und vermutlich das Problem jetzt immer noch nicht.  :-\
Ja, der Controller kann EF verschicken und empfangen.

ToKa

#59
Hallo zusammen,

hatte heute morgen noch schnell für zwei Geräte (E4.az.HR.Heizung und ST.sz.HR.Heizung) noExplorerFrames aktiviert und im ersten Moment, sah es gut aus. Als ich heute Abend aber in die Logs der beiden Geräte geschaut habe, sind wieder viele Einträge bei verschiedenen Werten mehrfach vorhanden.

Im list taucht dann auf dem sendstack wieder mal ein sendackget auf und auch SEND_DATA  failed:00 bzw. UNPARSED Einträge.

Internals:
   DEF        d14c12e6 13
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     472
   NAME       ST.sz.HR.Heizung
   NR         72
   STATE      <strong>Ist: </strong>20.5 °C<strong> / Soll: </strong>19.5 °C</br><strong>Ventil: </strong>10 %
   STILLDONETIME 0
   TYPE       ZWave
   ZWAVE1_MSGCNT 472
   ZWAVE1_RAWMSG 0004000d0326030a
   ZWAVE1_TIME 2017-02-01 19:07:28
   ZWaveSubDevice no
   homeId     d14c12e6
   ignoreDupMsg 1
   isWakeUp   1
   lastMsgSent 1485972444.29546
   nodeIdHex  0d
   Helper:
     Dblog:
       Desired-temp:
         Logdb:
           TIME       1485926100.06054
           VALUE      19.5
       Reportedstate:
         Logdb:
           TIME       1485972448.4222
           VALUE      10
       Setpointtemp:
         Logdb:
           TIME       1485972444.33633
           VALUE      19.5
       Temperature:
         Logdb:
           TIME       1485972444.1936
           VALUE      20.5
       Wakeup:
         Logdb:
           TIME       1485972443.77906
           VALUE      notification
   Readings:
     2017-02-01 09:31:10   SEND_DATA       failed:00
     2017-02-01 17:36:12   UNPARSED        THERMOSTAT_MODE 024003
     2017-02-01 04:43:18   battery         100 %
     2017-01-28 08:15:30   desired-new     00
     2017-02-01 06:15:00   desired-temp    19.5
     2016-07-01 10:19:52   model           EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
     2016-07-01 10:19:52   modelConfig     eurotronic/eur_cometz.xml
     2016-07-01 10:19:52   modelId         0148-0002-0001
     2017-02-01 07:02:12   neighborList    ST.fl.SD.WakeUpLight EG.ga.SD.Glasbausteine E3.hk.ZS.unused
     2017-01-29 14:49:55   neighborUpdate  done
     2017-02-01 19:07:28   reportedState   10
     2017-02-01 19:07:24   setpointTemp    19.5
     2017-02-01 19:07:28   state           dim 10
     2017-02-01 19:07:24   temperature     20.5
     2017-02-01 19:07:23   thermostatMode  heating
     2017-02-01 19:07:24   timeToAck       0.145
     2017-02-01 19:07:24   transmit        OK
     2016-10-22 15:59:02   userCode        id 1 status 2 code 00c3
     2017-02-01 19:07:23   wakeup          notification
     2016-10-08 09:27:21   wakeupReport    interval 600 target 1
   SendStack:
     sentackget:130d02260205ae
     get:130d02400205af
Attributes:
   DbLogInclude desired-temp,temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
   IODev      ZWAVE1
   alias      Schlafzimmer
   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
   group      Heizung
   icon       sani_heating
   ignoreDupMsg 1
   noExplorerFrames 1
   room       Übersicht
   sortby     6
   stateFormat {"<strong>Ist: </strong>".ReadingsVal('ST.sz.HR.Heizung','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('ST.sz.HR.Heizung','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('ST.sz.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     ::


Das FHEM log enthält über den Tag verteilt Einträge wie:
2017.02.01 12:40:23.798 3: ZWave get E4.az.HR.Heizung smStatus
2017.02.01 12:40:23.803 3: ZWave get E4.az.HR.Heizung setpoint
2017.02.01 12:40:23.805 3: ZWave get E4.az.HR.Heizung swmStatus
2017.02.01 12:40:23.807 3: ZWave get E4.az.HR.Heizung thermostatMode
2017.02.01 12:40:25.431 3: E4.az.HR.Heizung: ignore duplicate answer setpointTemp:19.5 C heating
2017.02.01 12:40:25.700 3: E4.az.HR.Heizung: ignore duplicate answer setpointTemp:19.5 C heating
2017.02.01 12:40:26.826 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2017.02.01 12:40:29.639 2: ZWAVE1 transmit NO_ACK for CB ef, target E4.az.HR.Heizung

2017.02.01 12:50:29.692 3: ZWave get E4.az.HR.Heizung smStatus
2017.02.01 12:50:29.694 3: ZWave get E4.az.HR.Heizung setpoint
2017.02.01 12:50:29.695 3: ZWave get E4.az.HR.Heizung swmStatus
2017.02.01 12:50:29.697 3: ZWave get E4.az.HR.Heizung thermostatMode
2017.02.01 12:50:30.268 3: E4.az.HR.Heizung: ignore duplicate WUN
2017.02.01 12:50:31.196 3: E4.az.HR.Heizung: ignore duplicate answer UNPARSED:SWITCH_MULTILEVEL 022603
2017.02.01 12:50:31.235 3: E4.az.HR.Heizung: ignore duplicate answer UNPARSED:SWITCH_MULTILEVEL 022603
2017.02.01 12:50:32.096 3: E4.az.HR.Heizung: ignore duplicate answer UNPARSED:SWITCH_MULTILEVEL 022603
2017.02.01 12:50:32.385 3: E2.ez.HR.Heizung: ignore duplicate answer thermostatMode:heating
2017.02.01 12:50:33.722 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:33.873 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:34.180 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:36.384 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2017.02.01 12:50:38.728 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:38.836 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:39.142 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:39.407 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:41.219 2: ZWAVE1 transmit NO_ACK for CB 16, target E4.az.HR.Heizung

2017.02.01 17:03:25.908 2: ZWAVE1 transmit NO_ACK for CB 38, target E1.wz.HR.Heizung.Fenster
2017.02.01 18:03:39.988 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 10
2017.02.01 17:53:30.166 3: E4.az.HR.Heizung: ignore duplicate WUN
2017.02.01 19:19:18.927 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900131202260225cd39

Das Log vom z-way Server habe ich als Datei angehängt.

Etwas ist mir gerade noch aufgefallen. Warum werden eigentlich die mehrfachen Log Einträge überhaupt erzeugt? Ich habe nämlich bei den Geräten "event-on-change-reading .*" eingestellt.

Gruß
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight