Probleme bei "set <device> configRequestAll"

[krikan]

Christian/4-Aktoren: Stehe auf dem Schlauch. Kannst du bitte mit "list" pruefen, ob vor dem Senden im SendStack was ist? SendStack sollte eigentlich nur fuer WAKE_UP Geraete sichtbar sein, bei Stationaeren sollte es schnell abgearbeitet und dann geloescht werden. Ich gehe davon aus, dass deine Aktoren kein WAKE_UP haben.

Hier ein list eines FGRM222 mit einem riesigen Sendstack. Der dürfte doch gar nicht existieren. Die anderen lists enthalten so etwas gerade nicht. Frag mich nicht wie ich das geschafft habe..

Das Problem habe ich unter Linux und Window.

Code Auswählen Erweitern

   CHANGED
   DEF        e345c452 27
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     18
   NAME       ZWave_SWITCH_MULTILEVEL_27
   NR         271
   STATE      Blind 0 Slat 0
   TYPE       ZWave
   ZWDongle_0_MSGCNT 18
   ZWDongle_0_RAWMSG 0004001b0a32022144000000000000
   ZWDongle_0_TIME 2015-09-07 22:12:55
   homeId     e345c452
   id         1b
   lastMsgSent 1441648204.46713
   Readings:
     2015-09-07 02:39:29   assocGroup_01   Max 10 Nodes 01
     2015-09-07 02:39:29   assocGroup_02   Max 10 Nodes
     2015-09-07 02:39:30   assocGroup_03   Max 01 Nodes 01
     2015-09-07 02:39:28   assocGroups     3
     2015-09-06 15:18:50   configEnergyReports 10
     2015-09-06 15:18:51   configForcedRollerShutterCalibration Default
     2015-09-06 15:18:51   configInRollerBlindModeOrVenetianBlind17 10
     2015-09-06 15:18:52   configInVenetianBlindModeTheParameter12 150
     2015-09-06 15:18:53   configManagingLamellasInResponseTo35 SetLamellasToTheirExtreme1
     2015-09-06 15:18:53   configMotorOperationDetection 10
     2015-09-06 15:18:54   configMotorOperationTime 240
     2015-09-06 15:18:54   configPeriodicPowerOrEnergyReports 3600
     2015-09-06 15:18:55   configPowerReports 10
     2015-09-06 15:18:55   configReportsType BlindPositionReportsSentToThe1
     2015-09-06 15:18:56   configResponseToFloodingAlarm NoReaction
     2015-09-06 15:18:56   configResponseToGeneralAlarm CloseBlind
     2015-09-06 15:18:57   configResponseToSmokeCOOrCO2Alarm OpenBlind
     2015-09-06 15:18:57   configResponseToTemperatureAlarm OpenBlind
     2015-09-06 15:18:57   configRollerShutterOperatingModes VenetianBlindModeWithPositioning
     2015-09-06 15:18:58   configScenesAssociationsActivation AssociationsActivation
     2015-09-06 15:18:58   configSelfMeasurement SelfMeasurementInactive
     2015-09-06 15:18:58   configSetLamellasBackToPrevious13 LamellasReturnToPreviouslySet1
     2015-09-06 15:18:59   configSwitchType MomentarySwitches
     2015-09-07 22:12:55   energy           0 kWh
     2015-09-06 15:14:06   model           FIBARO System FGRM222 Roller Shutter Controller 2
     2015-09-06 15:14:06   modelConfig     fibaro/fgrm222.xml
     2015-09-06 15:14:06   modelId         010f-0301-1001
     2015-09-06 15:26:33   position        Blind 0 Slat 0
     2015-09-07 21:26:30   power           0.0 W
     2015-09-07 19:50:10   state           configSwitchType request
     2015-09-07 02:40:25   transmit        OK
   SendStack:
     sent:131b0370052b251b
     131b0370051d251b
     131b03700511251b
     131b0370050c251b
     131b03700501251b
     131b03700523251b
     131b03700512251b
     131b03700516251b
     131b0370052a251b
     131b03700528251b
     131b03700502251b
     131b03700503251b
     131b0370051f251b
     131b0370051e251b
     131b03700520251b
     131b03700521251b
     131b0370050a251b
     131b03700532251b
     131b0370052c251b
     131b0370050d251b
     131b0370050e251b
Attributes:
   IODev      ZWDongle_0
   classes    MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY
   event-on-change-reading .*
   room       ZWave
   stateFormat position

[krikan]

Sendstack bei netzbetriebenen, nicht WAKE_UP-Aktoren:
Habe ein "configRequestAll" an einen ausgeschalteten Aktor verschickt. Dann bleiben alle Telegramme nach dem ersten TRANSMIT_NO_ACK im Sendstack stehen und werden nicht gelöscht. Vielleicht ein Hinweis?

[A.Harrenberg]

Hallo Rudi,
ok, soweit verstanden, irgendwas stimmt da aber dennoch nicht. Irgendwie läuft der Sendstack und die ReadAnswerFn da "auseinander".

Ist bei mir wie gesagt mit SECURITY, bedeutet aber erstmal nur das recht viele get-Nonce Befehle erzeugt werden.

(Test mit ConfigRequestAll)
Erste Abfrage für ConfigRequestAll wird von Security abgefangen und es wird ein GET-Nonce erzeugt/gesendet. Dieser erste GET-Nonce läuft durch, Transmit Ok, aber der Sendstack geht in die 0.3 Sekunden verzögerungen. Inzwischen trifft Antwort auf das GET ein. Hierdurch wird ein neuer SET-Befehl  ausgelöst der auf dem Stack landet. Über das ConfigRequestAll wird die nächste Abfrage verschickt, von Security abgefangen und wieder ein Get-Nonce erzeugt.

Hierfür wird nur die ReadAnswerFn aufgerufen die auf das Ergebnis warten will, ProcessSendStack ist aber noch in der 0.3 Sekunden Delay und der Befehl auf dessen Antwort gewartet werden soll wurde noch gar nicht versendet. -> Timeout 3 sekunden.

Während dieser Zeit hätte eigentlich ProcessSendStack über den Timer wieder aufgerufen werden müssen, ist aber NICHT passiert -> die Nachricht der ersten Get-Nonce liegt noch immer mit "sent:" auf dem Stack.

Durch irgendwas wird anscheinend der Timeraufruf der ProcessSendStack gestört.

Ich habe jetzt leider keine Zeit mehr das ohne das Delay nachzustellen ob es sich dann anders verhält.

Gruß,
Andreas.

[krikan]

Christian/PST02-1A: Die Inklusion ist stehengeblieben, weil im Step "ZW_ADD_NODE_TO_NETWORK ID:03" kein Geraet per autocreate erzeugt wurde, weiss nicht genau wieso. Entweder funktioniert delete nicht richtig, oder du hast das Geraet nicht entfernt. Damit wurde das Geraet auch nicht mit WAKE_UP angelegt, usw, usf. Wie gesagt alles nur Theorie. Ich kann ein KFOB ohne Fehler inkludieren, habs jetzt zweimal durchgefuehrt, mit und ohne deleteNode vorher. Wenn jemand hier Ideen hat...

Habe noch mal resetet und inkludiert: Es kommen immer nur WU-N und direkt WU-NMI im Log. Ein set-/get-Befehl landet im WakeUp-Sendstack. Wenn ich WU-N auslöse, steht im list vor dem Rohtelegramm  "sent:" aber es wird nichts per Dongle verschickt. Direkt nach WU-N kommt im log WU-NMI. Im Wakeup-Sendstack bleibt das Rohtelegramm mit "sent:" stehen, bis ich den nächsten Befehl im wakeup-Sendstack lege und 10s zuschlägt. Das Log hilft hier vermutlich wenig, habe es daher nicht beigefügt.

[A.Harrenberg]

Hallo Rudi,

nachdem ich nun die halbe Nacht darüber gegrübelt habe bin ich zu dem Schluß gekommen das die ReadAnswerFn an der jetzigen Stellen bzw. in der jetzigen Form nicht mehr richtig funktionieren kann. Das ist noch eine Funktionalität aus dem Stand ohne Sendstack im "alive" Betrieb. Da wurde der Befehl mit IOWrite verschickt und dann ReadAnswerFn aufgerufen. Das kam immer in der richtigen Reihenfolge und Zuordnung zueinander.

Jetzt werden die Befehle per addToSendStack an den SendStack übergeben und direkt danach wird die ReadAnswerFn aufgerufen. Das kann mit dem neuen System nicht mehr "synchron" laufen. Sobald ein neuer Get-Befehl so ausgelöst wird, aber noch ein anderer Befehl im Stack abgearbeitet wird, wird der ganze Ablauf asynchron und führt mindestens zu den TimeOuts bei der ReadAnswerFn.

Für Krikans Problem dürfte ausschlaggebend, sein das der "erneute" Aufruf durch das "delayNeeded" von processSendStack per InternalTimer irgendwie verlorengeht. Bei mir hätte es in dem einen Fall passieren müssen während (vergeblich) auf eine Antwort gewartet wurde. Ob dies mit ReadAnswerFn zu tun hat oder die Timer durch irgendetwas anderes fehlschlagen kann ich aber nicht sagen. Vielleicht ist das aber schon mal ein Hinweis auf weitere Debug Aktivitäten. Ich würde da heute abend auch noch mal weiter in dieser Richtung testen wenn Du da nicht bereits andere Ideen hast.

@Krikan: Kannst Du das ganze vielleicht mal wiederholen indem Du im Dongledevice das Attribut "delayNeeded" auf 0 setzt (default ist ja 1). Wenn meine Theorie stimmt müsste dann processSendStack abgearbeitet werden und dabei dann auch die "sent:xxx" Message entfernt werden.

Meiner Meinung nach müsste man die RegExp für die Antworten mit in den SendStack oder einen parallelen Stack legen und die ReadAnswerFn dann wieder synchron aufrufen. Damit wären wir dann ja fast schon bei den "Expected Answers" von OZW ,-)
Dann noch die CallBack-Ids zur besseren Unterscheidung und (fast) fertig... B-)

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

noch mal ich (diesmal kein langer Post sonder zwei kürzere) ,-)

Falls Du Dir für Sendstack / ReadAnswerFn was überlegst: für Security bräuchte ich irgendwie die Möglichkeit bei Eintreffen meiner Antwort (z.B. Nonce), den Sendstack "anzuhalten", meine verschlüsselte Nachricht zu erzeugen und OBEN auf dem Sendstack zu platzieren und danach den SendStack wieder zu starten.

Das "Problem" mit Security ist das ich einen Befehl "abfange", daraus dann aber bis zu 5 Befehle gemacht werden müssen.

Wobei ich auch hier bereits Szenarien kenne in denen das schieflaufen kann: Falls ich z.B. auf einen Nonce-Report vom Gerät warte, wird die regExp ja ^000400<id>..98 sein. Falls zu dem Zeitpunkt das Gerät z.B. eine Bewegung melden möchte, schickt es mir einen Get-Nonce Befehl der auf die regExp "passt", aber nicht die erwartete Antwort erhält. Ob man das dann anhand der Callback-ID unterscheiden kann müsste man dann ausprobieren oder noch mal genauer bei OZW abschauen.

Gruß,
Andreas.

[krikan]

Christian/PST02-1A: Die Inklusion ist stehengeblieben, weil im Step "ZW_ADD_NODE_TO_NETWORK ID:03" kein Geraet per autocreate erzeugt wurde, weiss nicht genau wieso. Entweder funktioniert delete nicht richtig, oder du hast das Geraet nicht entfernt. Damit wurde das Geraet auch nicht mit WAKE_UP angelegt, usw, usf. Wie gesagt alles nur Theorie. Ich kann ein KFOB ohne Fehler inkludieren, habs jetzt zweimal durchgefuehrt, mit und ohne deleteNode vorher. Wenn jemand hier Ideen hat...

Hallo Rudi,

Bin jetzt bis 9204 zurückgegangen bis mir eine Merkwürdigkeit aufgefallen ist. Seit gestern habe ich 2 ZWDongle-Device (ZWDongle_0, ZW_Dongle_1). Das Device, für das nicht angeschlossene Gateway, habe ich mit Attribut disable 1 versehen. In den Internals des Fhem-Device für den PST02-1A taucht aber das disable-ZWDongle immer wieder auf (LastInputDev). Darum: Kann es sein, dass es hier Zuordnungsprobleme gibt und das falsche ZWDongle-Device angesprochen wird und deshalb nur WU-N und WU-NMI im Log auftauchen?

Bei 9204 bleiben auch keine "sent:"- Reste im Wakeup-Sendstack.
Werde noch weiterprobieren und Ursache suchen. Heute morgen bin ich nicht zu mehr gekommen, wollte nur falsche Ursachensuche deinerseits verhindern. Wenn Du bestimmte Anlaysewünsche hast, dann gerne. Ansonsten bastel ich weiter.

Gruß, Christian

@Andreas: Bitte auch beachten. Meine SECURITY-Tests gestern mit dem PST02-1A sind daher wohl nicht aussagefähig

[krikan]

@Krikan: Kannst Du das ganze vielleicht mal wiederholen indem Du im Dongledevice das Attribut "delayNeeded" auf 0 setzt (default ist ja 1). Wenn meine Theorie stimmt müsste dann processSendStack abgearbeitet werden und dabei dann auch die "sent:xxx" Message entfernt werden.

Habe ich auf beiden Systemen schon mit probiert, kann bei mir aber keine Auswirkung erkennen. Bitte beachte unbedingt meinen letzten Beitrag zu den Problemen mit dem PST02-1A mit 2 ZWDongle-Devices.

[A.Harrenberg]

Hallo Krikan,

ich habe auf meinem Testsystem nur das eine Dongle definiert, daher denke ich nicht das bei mir das was mit verschiedenen Dongles schief laufen kann, werde heute abend aber mal genauer in das Log schauen.

Gruß,
Andreas.

[krikan]

Christian/PST02-1A: Die Inklusion ist stehengeblieben, weil im Step "ZW_ADD_NODE_TO_NETWORK ID:03" kein Geraet per autocreate erzeugt wurde, weiss nicht genau wieso. Entweder funktioniert delete nicht richtig, oder du hast das Geraet nicht entfernt. Damit wurde das Geraet auch nicht mit WAKE_UP angelegt, usw, usf. Wie gesagt alles nur Theorie. Ich kann ein KFOB ohne Fehler inkludieren, habs jetzt zweimal durchgefuehrt, mit und ohne deleteNode vorher. Wenn jemand hier Ideen hat...

Das Problem ist -nicht zufriedenstellend- geklärt:
Hatte in der Fhem Instanz ein ZWDongle_0 und ZWDongle_1. ZWDongle_0 ist nicht angeschlossen und disabled.
Wenn ich Inklusion mit ZWDongle_1 starte läuft diese nicht komplett durch, sondern bricht ab. In den Internals wird dann das IODEV ZWDongle_0 angezeigt.
WU-I werden von ZWDongle_1 empfangen (LASTInputDev) und die WU-NMI von ZWDongle_1 versandt. Alles was dazwischen an Nachrichten liegt wird scheinbar über ZWDongle_0 versandt/empfangen und landet im Nirwana. Ich kann zwar über Attribut iodev das angeschlossene ZWDongle_1 vorbelegen, dann funktioniert die Kommunikation korrekt. Jedoch stirbt Perl/Fhem nach kurzer Zeit mit "PERL WARNING: Terminating on signal SIGINT(2)" unter Win10, so dass ich die Funktionsfähigkeit nicht genau testen kann. Im Fazit habe ich wohl iodev nicht verstanden. Ich hatte vorausgesetzt, dass Fhem die Nachrichten automatisch dem korrekten ZWDongle zuordnet. In ZWave gibt es ja nur die direkte Zuordnung von Gerät zu einem speziellen Dongle. Habe aber mich dann aber erinnert, dass mit klaus.schauer bei EnOcean ein ähnliches Problem diskutiert wurde http://forum.fhem.de/index.php?topic=35118.0. Daraus schließe ich, dass 2 ZWdongle-Devices in Fhem wohl nicht ideal sind; was mich bei nicht angeschlossenem und disabled Device aber wundert.

Jetzt kann ich mich dem nächsten Problem, das noch besteht (sendstack bei netzbetriebenen Aktoren) widmen.

[krikan]

Christian/4-Aktoren: Stehe auf dem Schlauch. Kannst du bitte mit "list" pruefen, ob vor dem Senden im SendStack was ist? SendStack sollte eigentlich nur fuer WAKE_UP Geraete sichtbar sein, bei Stationaeren sollte es schnell abgearbeitet und dann geloescht werden. Ich gehe davon aus, dass deine Aktoren kein WAKE_UP haben.

3 FGRM222 mit "set ZWave_SWITCH.* configRequestAll" abgefragt. Am Beginn (nach Fhem-Start) waren die Sendstacks bei allen Aktor-Devices leer. Dann habe ich den Befehl 3x hintereinander im Abstand von mehreren Minuten ausgeführt. Bei wechselnden Devices stoppt die Abarbeitung/Versand der Einzel-Config-Befehle, obwohl der letzte Befehle mMn problemlos durchlief. In list stehen die nicht abgearbeiteten Befehle. Ich erkenne derzeit kein System. In der Anlage Log anschließend zugehörige List usw. Beim ersten Mal sind die Lists leider unvollständig. Test auf Win-System; auf Raspi habe ich das auch, aber wohl -geschwindigkeitsbedingt- mit noch extremer Sendstack-Resten.
Ich hatte kein 2. ZWDongle-Fhem-Device im Testsystem

[rudolfkoenig]

ZWDongle_0 ist nicht angeschlossen und disabled.

An sowas habe ich bisher nicht gedacht. Beim Neuanlegen eines Geraetes wird das zuletzt definierte Geraet als IODev angenommen, das kann man mit einem Attribut zwar aendern, das ist aber beim Inclusion natuerlich nicht moeglich. AssignIoPort hat bisher IsDisabled nicht geprueft, das habe ich jetzt eingebaut. Ist aber eigentlich auch nicht die richtige Loesung, da die Suche nach den bekannten homeId gehen sollte, das habe ich jetzt auch eingebaut (war mit FIXME versehen). Alles in allem: dieses Problem war schon "immer" vorhanden, und hat nix mit dem Umbau zu tun.

FHEM geht davon aus, dass Nachrichten von mehreren Geraeten empfangen werden koennen, gesendet werden koennen sie aber nur ueber den per IODev zugewiesenen.

Da eine Nachricht aber nur im Zusammenhang mit homeId eindeutig ist, zieht beim Identifikation des ZWave-Geraetes das ZWave Modul die homeId des Empfaenger-ZWDongle heran. Es sollte kein Problem sein, beliebig viele ZWave Dongles in FHEM einzusetzen, insb. jetzt, da die initial ZWDongle Zuweisung gefixt wurde.

Deinen letzten Log kann ich vmtl. erst uebermorgen analysieren.

[krikan]

An sowas habe ich bisher nicht gedacht.

Ich auch nicht, darum hatte ich erst die aktuellen Änderungen verdächtigt. Sorry.

FHEM geht davon aus, dass Nachrichten von mehreren Geraeten empfangen werden koennen, gesendet werden koennen sie aber nur ueber den per IODev zugewiesenen.

Da eine Nachricht aber nur im Zusammenhang mit homeId eindeutig ist, zieht beim Identifikation des ZWave-Geraetes das ZWave Modul die homeId des Empfaenger-ZWDongle heran. Es sollte kein Problem sein, beliebig viele ZWave Dongles in FHEM einzusetzen, insb. jetzt, da die initial ZWDongle Zuweisung gefixt wurde.

Muss man IODev bei mehreren ZWDongle jetzt noch manuell per Attribut zuweisen oder macht FHEM das nach der Änderung automatisch richtig (nicht nur für Inklusion)?

Deinen letzten Log kann ich vmtl. erst uebermorgen analysieren.

Hat Zeit. Der Test ist recht extrem und ich hoffe, es liegt nicht nur am Nutzer...

[rudolfkoenig]

Muss man IODev bei mehreren ZWDongle jetzt noch manuell per Attribut zuweisen oder macht FHEM das nach der Änderung automatisch richtig (nicht nur für Inklusion)?

Mehrere ZWDongles sollten jetzt automatisch funktionieren. Habe auch FHEM2FHEM eingebaut, aber das ist nach etwas nachdenken Mumpitz: Inkludieren und Secure funktioniert ueber FHEM2FHEM sicher nicht.
Fuer diesen Zweck muss man socat verwenden, ist eh die bessere Loesung.

[rudolfkoenig]

Letzter Fall, SendStack:
  sent:13040370051d2504
  ...
die zu diesem Befehl dazugehoerigen Logs (restliche Meldungen entfernt):

2015.09.08 20:33:24.725 5: ZWDongle_Write 00 13040370051d2504
2015.09.08 20:33:27.491 5: SW: 010a0013040370051d2504a8
2015.09.08 20:33:27.632 4: ZWDongle_Read ZWDongle_0: CAN received
2015.09.08 20:33:28.960 2: ZWDongle_ProcessSendStack: no ACK, resending message
2015.09.08 20:33:28.960 5: SW: 010a0013040370051d2504a8
2015.09.08 20:33:28.977 5: ACK received, removing 010a0013040370051d2504a8 from dongle sendstack
2015.09.08 20:33:28.978 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301

D.h. der Dongle hat das Befehl zwar losgeschickt, hat aber verpennt die Quittung oder dessen Ausbleiben, also  irgendetwas mit 001304xx, weiterzugeben. Bei dem viel Verkehr koennte mir das auch passieren . Da wir im ZWave noch keinen Timer haben, bleibt die Abarbeitung stehen.

Moeglichkeiten (alle erfordern einen Timer):
- Fehlermeldung/event: kann Befehl soundso nicht wegschicken.
- Befehl erneut schicken, dabei Zaehler pflegen, und falls es nach X-mal nicht
  ging, Fehlermeldung/event.
- Timer startet bei 0113xx, der ZWDongle SendStack generiert selbst sowas, falls die Antwort vom Dongle komplett ausbleibt.

Wie lang sollte die Wartezeit sein? Wie hoch soll X sein?
Bei den obigen Log macht muss die Wartezeit 5+ Sekunden sein, was heftig ist. Wenn die Loesung mit X, dann sollte X 3 sein.
Mein Favorit: Timer (10sek) startet bei der Weitergabe der Daten an ZWDongle, falls nix kommt, Fehlermeldung+Event, ohne "X".
Meinungen? Argumente?