Probleme bei "set <device> configRequestAll"

krikan · 06 September 2015, 10:06:30

netzbetriebene Geräte auf meinem "langsamen" Produktivsystem:
Bei "set <device> configRequestAll" endet das erste versandte Telegramm bei allen meinen ZWave-Geräten reproduzierbar mit "ZWDongle_ProcessSendStack: no ACK, resending message". In der Anlage Log mit 2x configRequestAll hintereinander. Beim 1. configRequestAll wird nach meinem Verständnis nach 8xCan der Sendstack für das Gerät komplett abgebrochen und anschließend geleert. Das dürfte doch eigentlichen nicht so sein!? Kann man nach x CANs die Pause nicht ggfs. erhöhen?
Das waren -wie immer- die Negativbeispiele, ansonsten habe ich den Eindruck, das die Probleme deutlich weniger geworden sind. Danke.

krikan · 06 September 2015, 10:49:46

Wakeup-Geräte auf "schnellem" Testsystem:
Hier habe ich leider mehr Probleme. Während der Inklusion laufen die Komfortfunktionen "set-associationAdd" und "get-model" nicht mehr korrekt durch. Beide Befehle landen im WakeUp-Sendstack und müssen durch manuelles Aufwecken abgearbeitet werden. Das verursacht evtl. auch die Probleme bei SECURITY. Zudem häufen sich im Log die NO_ACK - Meldungen im laufenden Betrieb über die Zeit, was ich nicht nachvollziehen kann.

A.Harrenberg · 06 September 2015, 10:52:51

Hi Krikan,

das Log sieht wirklich merkwürdig aus, da ist ja noch gar nichts "los" und es gibt ein NO_ACK? Was passiert denn wenn Du den ersten Befehl aus der Kette "set ZWave_SWITCH_MULTILEVEL_4 configEnergyReports request" manuel einzeln aufrufst?

Code Auswählen

2015.09.06 09:49:07.845 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configEnergyReports request
2015.09.06 09:49:07.849 5: ZWDongle_Write 00 13040370052b2504
2015.09.06 09:49:07.853 5: SW: 010a0013040370052b25049e
2015.09.06 09:49:08.139 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configForcedRollerShutterCalibration request
...
2015.09.06 09:49:12.754 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configSwitchType request
2015.09.06 09:49:12.993 2: ZWDongle_ProcessSendStack: no ACK, resending message
2015.09.06 09:49:12.995 5: SW: 010a0013040370052b25049e
2015.09.06 09:49:13.444 5: ACK received, removing 010a0013040370052b25049e from dongle sendstack
2015.09.06 09:49:13.450 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.06 09:49:13.452 5: SW: 06
2015.09.06 09:49:13.458 5: ZWDongle_0 dispatch 011301
2015.09.06 09:49:13.463 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.06 09:49:13.466 5: SW: 06
2015.09.06 09:49:13.473 5: ZWDongle_0 dispatch 011301
2015.09.06 09:49:13.479 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.06 09:49:13.482 5: SW: 06
2015.09.06 09:49:13.487 5: ZWDongle_0 dispatch 011301
2015.09.06 09:49:13.494 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.06 09:49:13.496 5: SW: 06
2015.09.06 09:49:13.502 5: ZWDongle_0 dispatch 011301
2015.09.06 09:49:13.508 4: ZWDongle_Read ZWDongle_0: CAN received

Ich habe diese ganzen 0013, 0113 ja immer noch nicht verstanden, aber mir ist nicht klar wie nach 1x senden, 1xNO_ACK und 1x Re-send da 4x 011301 ankommen kann.

Ansonsten muss ich Dir zustimmen, die SendStacks scheinen gut zu funktionieren. Habe händisch ein paar "Stresstests" gemacht und bisher keine (CAN-) Fehler provozieren können!
@Rudi: Chapeau!

Gruß,
Andreas.

A.Harrenberg · 06 September 2015, 11:00:42

Hi Krikan,

Zitat von: krikan am 06 September 2015, 10:49:46
Wakeup-Geräte auf "schnellem" Testsystem:
Hier habe ich leider mehr Probleme. Während der Inklusion laufen die Komfortfunktionen "set-associationAdd" und "get-model" nicht mehr korrekt durch. Beide Befehle landen im WakeUp-Sendstack und müssen durch manuelles Aufwecken abgearbeitet werden. Das verursacht evtl. auch die Probleme bei SECURITY. Zudem häufen sich im Log die NO_ACK - Meldungen im laufenden Betrieb über die Zeit, was ich nicht nachvollziehen kann.

es scheint ein Problem mit der ReadAnswerFn zu geben, wodurch teilweise 3 Sekunden gewartet wird, in der Zeit schlägt dann wahrscheinlich der WakeUp-TImeout zu...

Du könntest übergangsweise den ganzen Block mal deaktivieren (in der Funktion ZWave_Cmd, Zeile 707)

Code Auswählen

  my $val;
  if($type eq "get_disabled") {
    no strict "refs";

und mal sehen ob dann die set-associatoinAdd und get-model wieder laufen.

Bei NO_ACK habe ich aber auch so gar keine Idee...

Gruß,
Andreas.

rudolfkoenig · 06 September 2015, 11:38:25

ZitatIch habe diese ganzen 0013, 0113 ja immer noch nicht verstanden,

0113XX kommt, wenn der Dongle die Nachwirch versendet hat. 01 heisst erfolgreich, sonst wohl nicht.
Z.Zt. wird bei XX != 01 der SendStack weiter abgearbeitet, sonst passiert nix.

0013idXXYYYY kommt, falls der Dongle vom Geraet per Funk ein ACK bekommen hat (XX==00), oder falls es nach Timeout keins bekommen hat (XX!=00). Bei XX==00 wird die naechste Nachricht aus dem Stack geschickt (das sollte normallfall sein), bei XX!=00 wird erstmal nichts gemacht, was nach 10s vermutlich zum wegwerfen des Stacks fuehrt.

ZitatconfigRequestAll_9205

Da ist vieles merkwuerdig:
- der Ack vom Dongle kommt 450ms(!) nach Schreiben der Nachricht.
- danach komme 011301 3x
- das 0013id00 kommt erst 1040ms nach senden. Da hat der WU_NMI-Timer schon zugeschlagen, und hat das Geraet fuer schlafend erklaert (delete $hash->{wakeupAlive}).

Der erste Punkt ist mAn Dongle-Fehler, weiss noch nicht wie ich darauf reagieren soll. Der zweite Punkt ist vmtl. noch ein Verstaendnisproblem bei mir. Der dritte Punkt wird vermutlich durch Meshing verursacht, und wir sollten den Timer erhoehen. Christian: kannst du bitte in ZWave_wakeupTimer die Zeitdifferenz mit 2 oder 3 statt 1 vergleichen? Vermutlich waere es sinnvoll rauszufinden, ob ein Geraet schnell oder langsam antwortet, und diesen Timeout dementsprechend setzen (Attribut?).

Die CAN's werden ab sofort anders behandelt, siehe den E5/Danfoss-Thread.

Die anderen Probleme wuerde ich erst nach klaeren dieser angehen, sonst aendern wir zuviel auf einmal, und die Verwirrung ist gross.

A.Harrenberg · 06 September 2015, 12:01:06

Hallo Rudi,

noch was: je nach Konfiguration verschickt das Gerät von Krikan ZWEI WU-Notifications kurz hintereinander. Das war der ursprünglichste Grund für meine "presumed_State" Variable, damit hatte ich auf "awake" getestet und diese 2.te WU-Notification weggeworfen. Im Log von Krikan taucht das aktuell auch wieder auf. Bei meiner Lösung hat das dann einen zweiten Timer zur Abarbeitung des Stacks gestartet, was wieder zu Kollisionen geführt hat.

Im aktuellen Code wird ja hier auch ähnlich ein ZWave_processSendStack angestossen, der dann "parallel" zu dem ersten läuft, oder?

Code Auswählen

  if($arg =~ m/^028407/) { # wakeup:notification
    ZWave_wakeupTimer($hash);
    ZWave_processSendStack($hash, undef, 0);
  }

Gruß,
Andreas.

krikan · 06 September 2015, 15:44:17

Mein derzeitiges Produktivsystem werde ich zukünftig bis zum Umzug auf leistungsfähigere Hardware nicht mehr zum Testen einsetzen. Insgesamt scheint es Limit zu sein (6 Gateways, Sonos, mehrere HTTOMOD) und verfälscht evtl. Tests. Mit der heutigen SVN-Version geht es zwar besser, aber erst nachdem ich verbose 3, mscelog 0 und EnOcean-Gateway disabled gesetzt ist, wird das Log deutlich besser aber nicht optimal.

Demnächst also alles vom Testsystem, komme aber zu weiteren Tests vermutlich heute nicht mehr.

krikan · 06 September 2015, 20:51:07

Auf Testsystem i7 mit Win10, UZB1, PST02-1A meine ich folgende Merkwürdigkeit zu erkennen:

Nach einem WU-NMI wird noch eine WU-NMI-Nachricht an den PST02-1A verschickt, die logischerweise in NO_ACK endet.
Hängt das damit zusammen, dass der Sensor beim manuellen Wakeup -so wie Andreas schrieb- 2x WU-N schickt? Log und list anbei.
Zudem akzeptiert Fhem nach meinem Eindruck auch manuelle get-/set-Abfragen innerhalb des Timer-Zeitraums und verschickt sie sofort mit NO_ACK-Ergebnis, obwohl WU-NMI-Nachricht bereits versandt wurde. Kann das sein?

ZitatZWave_wakeupTimer die Zeitdifferenz mit 2 oder 3 statt 1

Habe ich testweise gemacht, aber keine wirkliche Änderung feststellen können. In diesem Testsetup reichen mMn die 1 Sek reproduzierbar aus.

rudolfkoenig · 06 September 2015, 22:04:53

Angepasst:
- ZWDongle hat jetzt wieder ein "set timeouts". Muss wohl gepennt haben, waehrend ich das zu den gets geschoben habe.
- CAN wird waehrend der init Phase wieder so behandelt wie frueher: vor init_done funktioniert InternalTimer nicht.
- ZWave_wakeupTimer sollte ab sofort den doppelten Aufruf (wg. 2x wakeup:notification oder aehnliches) mitkriegen, und nur einen Timer starten
- Bei der Inclusion wird wakeupTimer auch gestartet

-> FHEM-Start ist jetzt ohne Fehlermeldungen, 3s Startupzeit ist wieder 1s, Inclusion mit KFOB2 funktioniert.

krikan · 07 September 2015, 19:39:29

Mache gerade einige Stresstests, in dem ich 4 Aktoren mit insgesamt über 60 configXY-Werten mit folgendem Befehl abfrage:

Code Auswählen

set ZWave_SWITCH.* configRequestAll
Der Befehl läuft grds. komplett durch. Eine Merkwürdigkeit gibt es, die ich mir nicht erklären kann. Wenn der erste "set configXY"-Befehle auf den Sendstack für einen Aktor gelegt wird, kommt häufig im Anschluß die Meldung "ERROR: ZWave_XY: cleaning commands without ack after 10s". Teilweise, aber nicht immer, wird das configX-Reading vor der Meldung dann nicht aktualisiert. Im nachfolgenden Log tritt die Meldung zwar gehäuft auf, aber ich kann keine fehlenden configXY-Readings feststellen. Unbestätigte Nachrichten auf dem Sendstack von vor der Befehlsabsetzung kann ich mir nicht vorstellen.
Wie kann ich am Besten vorgehen, um die Ursache zu finden?

Code Auswählen

2015.09.07 19:22:18.172 2: ZWave set ZWave_SWITCH_BINARY_6 configPartnerID request
2015.09.07 19:22:18.177 2: ZWave set ZWave_SWITCH_BINARY_6 configResetDefaultConfiguration request
2015.09.07 19:22:18.182 2: ZWave set ZWave_SWITCH_BINARY_6 configSendNotifications request
2015.09.07 19:22:18.186 2: ZWave set ZWave_SWITCH_BINARY_6 configSirenSoundAndVolume request
2015.09.07 19:22:18.194 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configEnergyReports request
2015.09.07 19:22:18.194 2: ERROR: ZWave_SWITCH_MULTILEVEL_26: cleaning commands without ack after 10s
2015.09.07 19:22:18.195 5: ZWDongle_Write 00 131a0370052b251a
2015.09.07 19:22:18.201 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configForcedRollerShutterCalibration request
2015.09.07 19:22:18.207 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configInRollerBlindModeOrVenetianBlind17 request
2015.09.07 19:22:18.215 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configInVenetianBlindModeTheParameter12 request
2015.09.07 19:22:18.223 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configLocalProtection request
2015.09.07 19:22:18.230 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configManagingLamellasInResponseTo35 request
2015.09.07 19:22:18.235 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configMotorOperationDetection request
2015.09.07 19:22:18.241 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configMotorOperationTime request
2015.09.07 19:22:18.247 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configPeriodicPowerOrEnergyReports request
2015.09.07 19:22:18.253 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configPowerReports request
2015.09.07 19:22:18.259 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configRFProtectionRadioProtection request
2015.09.07 19:22:18.265 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configReportsType request
2015.09.07 19:22:18.271 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configResponseToFloodingAlarm request
2015.09.07 19:22:18.278 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configResponseToGeneralAlarm request
2015.09.07 19:22:18.284 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configResponseToSmokeCOOrCO2Alarm request
2015.09.07 19:22:18.289 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configResponseToTemperatureAlarm request
2015.09.07 19:22:18.296 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configRollerShutterOperatingModes request
2015.09.07 19:22:18.302 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configScenesAssociationsActivation request
2015.09.07 19:22:18.309 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configSelfMeasurement request
2015.09.07 19:22:18.314 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configSetLamellasBackToPrevious13 request
2015.09.07 19:22:18.320 2: ZWave set ZWave_SWITCH_MULTILEVEL_26 configSwitchType request
2015.09.07 19:22:18.328 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configEnergyReports request
2015.09.07 19:22:18.328 2: ERROR: ZWave_SWITCH_MULTILEVEL_27: cleaning commands without ack after 10s
2015.09.07 19:22:18.329 5: ZWDongle_Write 00 131b0370052b251b
2015.09.07 19:22:18.334 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configForcedRollerShutterCalibration request
2015.09.07 19:22:18.340 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configInRollerBlindModeOrVenetianBlind17 request
2015.09.07 19:22:18.348 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configInVenetianBlindModeTheParameter12 request
2015.09.07 19:22:18.356 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configLocalProtection request
2015.09.07 19:22:18.363 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configManagingLamellasInResponseTo35 request
2015.09.07 19:22:18.368 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configMotorOperationDetection request
2015.09.07 19:22:18.375 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configMotorOperationTime request
2015.09.07 19:22:18.382 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configPeriodicPowerOrEnergyReports request
2015.09.07 19:22:18.388 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configPowerReports request
2015.09.07 19:22:18.393 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configRFProtectionRadioProtection request
2015.09.07 19:22:18.399 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configReportsType request
2015.09.07 19:22:18.405 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configResponseToFloodingAlarm request
2015.09.07 19:22:18.411 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configResponseToGeneralAlarm request
2015.09.07 19:22:18.417 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configResponseToSmokeCOOrCO2Alarm request
2015.09.07 19:22:18.422 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configResponseToTemperatureAlarm request
2015.09.07 19:22:18.428 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configRollerShutterOperatingModes request
2015.09.07 19:22:18.434 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configScenesAssociationsActivation request
2015.09.07 19:22:18.440 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configSelfMeasurement request
2015.09.07 19:22:18.445 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configSetLamellasBackToPrevious13 request
2015.09.07 19:22:18.451 2: ZWave set ZWave_SWITCH_MULTILEVEL_27 configSwitchType request
2015.09.07 19:22:18.458 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configEnergyReports request
2015.09.07 19:22:18.458 2: ERROR: ZWave_SWITCH_MULTILEVEL_4: cleaning commands without ack after 10s
2015.09.07 19:22:18.458 5: ZWDongle_Write 00 13040370052b2504
2015.09.07 19:22:18.465 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configForcedRollerShutterCalibration request
2015.09.07 19:22:18.470 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configInRollerBlindModeOrVenetianBlind17 request
2015.09.07 19:22:18.476 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configInVenetianBlindModeTheParameter12 request
2015.09.07 19:22:18.482 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configLocalProtection request
2015.09.07 19:22:18.488 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configManagingLamellasInResponseTo35 request
2015.09.07 19:22:18.493 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configMotorOperationDetection request
2015.09.07 19:22:18.500 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configMotorOperationTime request
2015.09.07 19:22:18.505 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configPeriodicPowerOrEnergyReports request
2015.09.07 19:22:18.512 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configPowerReports request
2015.09.07 19:22:18.517 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configRFProtectionRadioProtection request
2015.09.07 19:22:18.522 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configReportsType request
2015.09.07 19:22:18.530 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configResponseToFloodingAlarm request
2015.09.07 19:22:18.535 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configResponseToGeneralAlarm request
2015.09.07 19:22:18.541 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configResponseToSmokeCOOrCO2Alarm request
2015.09.07 19:22:18.548 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configResponseToTemperatureAlarm request
2015.09.07 19:22:18.553 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configRollerShutterOperatingModes request
2015.09.07 19:22:18.559 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configScenesAssociationsActivation request
2015.09.07 19:22:18.565 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configSelfMeasurement request
2015.09.07 19:22:18.570 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configSetLamellasBackToPrevious13 request
2015.09.07 19:22:18.576 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 configSwitchType request

A.Harrenberg · 07 September 2015, 21:10:45

Hallo Rudi,

steige noch nicht so ganz durch Deinen Code, aber müsste es am Ende ZWave_addToSendStack nicht ein >=1 sein, anstatt ein ==1??

Code Auswählen

ZWave_processSendStack($hash, $now, 0) if(@{$ss} >= 1);

Mit ==1 wird bei mir der Stack immer "länger", es wird nichts gesendet und irgendwann werden dann alte Nachrichten (>10 sekunden) weggeworfen.

Gruß,
Andreas.

krikan · 07 September 2015, 21:25:33

batteriebetriebener Sensor PST02-1A:
Mit der aktuellen SVN-Version bekomme ich den Sensor nicht mehr vernünftig in FHEM eingebunden. Die Inklusion stockt bei den Komfortfunktionen und schlimmer noch, es kommen keine Werte vom Sensor mehr an. Es sieht so aus, als ob unmittelbar nach WU-N die WU-NMI verschickt wird, ohne den Sendstack abzuarbeiten.
Ich habe jetzt mehrfach Sensor und Gateway resetet. Das Ergebnis ist immer gleich. List und Log anbei.

A.Harrenberg · 07 September 2015, 21:50:28

Hi,

Nachtrag: die Probleme treten unter SECURITY auf, mit >=1 wird es aber dann doch nicht wirklich besser, dort wird dann zwar mehr gesendet, dafür häufen sich dann die CAN und NO_ACK.

Aber der "Normal"-Betrieb sollte erst Mal vorrang haben bei der Problemlösung. Also wenn das mit der >=1 Blödsinn war bitte einfach ignorieren.

Gruß,
Andreas.

rudolfkoenig · 07 September 2015, 22:02:04

Andreas: nein. Die Nachricht soll nur dann raus (bzw. auf dem Dongle-Stack), falls die gerade hinzugefuegte der Einzige auf dem Stack ist, d.h. alle vorherigen wurden bestaetigt.
Man beachte: nach dem Senden bleibt de Nachricht als "sent:XXX" noch auf dem SendStack, bis der ACK eintrifft.

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.

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...

krikan · 07 September 2015, 22:11:53

ZitatChristian/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.

Keine WAKE_UP-Geräte, sondern normale netzbetriebene Aktoren. Deshalb verstehe ich es nicht. Schaue ich mir mit "list" noch mal an systematisch an.

ZitatChristian/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 ist das Gerät mit 2x WU-N hintereinander. Vielleicht liegt es daran. Ich habe es jetzt so oft mit Controller/Aktor-Reset und anderen Experimenten probiert, dass mir die Ideen ausgehen. In der Fassung vor den Änderungen aus Deiner Antowort #23 ging es noch; vielleicht sollte ich mit der Vorversion noch mal testen, damit ich hier Probleme ausschließen kann.