[callidomus] Startup-Verhalten

[mumpf]

Hi Marcus,

ich versuche derzeit das Startup-Verhalten in callidomus zu analysieren, da ich in meinem Test nicht "Restartfähig" bin: Bei jedem callidomus.core restart sind einige Items nicht so, wie ich es erwartet hätte - sie wechseln sporadisch die Werte. Ich glaube nicht, dass es das Problem von callidomus ist, derzeit vermute ich eine Kombi aus nicht-deterministich eintreffenden REPLY-Protokollen und dadurch unerwartet aufgerufenen Logiken. Dennoch will ich das Problem in den Griff bekommen.

Dazu hätte ich gerne für die folgende Liste von Dir ein einfaches Ja/Nein pro Punkt, wobei bei einem Nein das richtige Verhalten nett wäre... Du kannst das dann auch gerne in dieser oder abgewandelter Form in die Doku aufnehmen, ich habe nichts dagegen

Ich gehe von folgender Item-Grundstruktur aus:

[Test]
    type = num
    [Child]
        type = num
        trigger = Test
        code = value

Jetzt wird Test variiert, wie verhält sich das beim Startup bzw. was habe ich nach dem Startup:

1. value = 7
   -> Test = 7, Child wird nicht getriggert und ist 0.
2. cache = true, letzter Wert war 8
   -> Test = 8, Child wird nicht getriggert und ist 0.
3. value = 7, cache = true, letzter Wert war 8.
   -> Test = 8, Child wird nicht getriggert und ist 0.
4. trace = true, letzter Wert war 9.
   -> Test = 9, Child wird nicht getriggert und ist 0.
5. value = 7, trace = true, letzter Wert war 9.
   -> Test = 9, Child = 0
6. value = 7, cache = true, trace = true, letzter Wert war 9.
   -> Test = 9, Child = 0
7. enforce_updates = true bei irgendeiner der obigen Kombis
   -> Test bleibt gleich, Child = 0
8. value = 7, knx_init liefert 10
   -> Zuerst Test = 7, Child = 0, nach dem REPLY Test = 10, Child = 10
9. value = 7, knx_init liefert 7
   -> Zuerst Test = 7, Child = 0, nach dem REPLY Test = 7, Child = 0
10. value = 7, enforce_updates = true, knx_init liefert 7
    -> Zuerst Test = 7, Child = 0, nach dem REPLY Test = 7, Child = 7
11. Die Punkte 8-10 verhalten sich entsprechend, wenn ich statt value passend cache bzw. trace habe (die jeweils 7 liefern)?
12. Jetzt kommt der meiner Meinung nach "nicht-deterministische" Fall:
    Test hat knx_init von GA A, Child hat knx_init von GA B, REPLY A kommt vor REPLY B
    -> Test = Wert von A, Child = Wert von B
13. Wie 12, nur REPLY B kommt vor REPLY A
    -> Test = Wert von A, Child = Wert von A

Ich glaube, dass ich bei mir mit 12 und 13 kämpfe. Natürlich nicht in einem so simplen Item-Zusammenhang wie hier dargestellt, sondern indem von verschiedenen Items Logiken getriggert werden, die diese Item-Werte aber verarbeiten und die im Startup in einer Reihenfolge aufgerufen werden, die ich nicht beeinflussen kann (aufgrund von "unsortierten" REPLY-Protokollen), sie aber sonst im laufenden Betrieb nicht vorkommt. Mir würde es helfen, wenn ich mir sicher sein kann, dass es sich so wie beschrieben verhält, dann kann ich nach Lösungen suchen.

Gruß, Waldemar

[callidomus]

Hallo Waldemar,

1-13 ja, alles soweit richtig.

Bei 6) fehlt noch: letzter Wert war 9.

Bis bald

Marcus

[mumpf]

Danke Marcus,

den fehlenden Text habe ich noch nachgetragen. Ich habe in der Zwischenzeit ein paar Unstimmigkeiten auf meinem Bus gefunden (mehrfache REPLY-Protokolle mit unterschiedlichen Werten auf einen READ), die fixe ich gerade, dann untersuche ich weiter, ob ich in die 12/13-Falle tappe.

Dies ist übrigens aus meiner Sicht ein weiterer Grund für eine knx_cache-Realisierung. sh.py war komplett restart-fähig, ohne jeglichen Seiteneffekt (trotz einiger Logiken und vielen State-Engines), weil es die Item-Werte beim restart aus dem eibd-cache bekommen hat. Es konnte nicht passieren, dass mal ein REPLY früher und mal später kommt. Das habe ich bei callidomus schon beobachten können, allerdings weiß ich nicht, ob es wirklich bei meinen Logiken solche Auswirkungen wie bei 12/13 hat. Und selbst dann kann ich sie sicherlich anders (reihenfolgeunabhängig) implementieren.

Ich berichte, falls ich weitere Erkenntnisse gewinne...

Gruß, Waldemar