SH Startup Phasen

[gama]

Hallo zusammen,

vielleicht wurde es schon einmal gepostet, aber ich habe nichts zum Thema gefunden: wann ein Neustart von smarthome abgeschlossen und gibt es trigger Items o.ä. dazu?
Konkret könnte man ja feststellen, wann alle "knx_init" Requests beantwortet wurden und das System "up" ist. Gibt es hierzu Infos bzw. einen Thread?

Grüße
Markus

[Sandman60]

Ich hab bei mir eine Minilogik, welche eine logger.info ins Log schreibt. Diese ist immer die letzte Logik in der logic.conf. Dann weiß ich zumindest das sowohl die Items als auch die Logiken durch sind. Dann kommen die Plugins noch, dort weiß ich dann bspw. das aus dem Squeeze-plugin eine Meldung kommt und dann ist wirklich alles fertig. die Meldung nach den Logiken ist für mich dahingehend wichtig, da ab diesem Zeitpunkt das System konsistent ist, erst ab diesme Zeitpunkt bspw. setze ich einen Trigger der die Abarbeitung von Logiken erst ermöglicht.
knx_init nehme ich nicht /brauche ich nicht, kann dir daher nicht helfen, ich arbeite hier mit knx_cache und cache sowie zyklischen Sends bei wichtigen Dingen wie Wetterstation und irgendwelche REEDs.

[gama]

Hm, eigentlich auch eher ein workaround... Du hast recht, die knx_cache Attribute abzufragen reicht nicht aus.
Habe mal eben einen Blick in die smarthome.py geworfen, da werden die Plugins, Items, Scheduler, etc. der Reihe nach initialisiert. So wie ich den code aktuell verstehe, müsste da nach vollständiger Initialisierung irgendwo das "Startup finished" Signal gefeuert werden.
Momentan verstehe ich den code so, dass die Items in die Baumstruktur geparsed werden, die Abfrage der Werte über den Bus jedoch über das knx plugin läuft. Dort werden unter handle_connect() alle "knx_send" in groupreads abgearbeitet.
So wäre eine mögliche Struktur, dass sich beispielsweise die Plugins zurückmelden, wenn diese mit ihrer Initialisierung fertig sind und im core auf das letzte Plugin gewartet wird. Aber das wäre in Summe schon ein größerer Eingriff.

Was meinen die sh.py Profis dazu? Wurde so etwas schon einmal diskutiert?
Wie handhaben andere Systeme wie z.B. openHAB die Initialisierungsphase?

[Sandman60]

Äh? Wieso ist das ein Workaround? Beim Start ist es wichtig einen konsistenten Ladestand zu haben und das hast Du wenn Die Items und Logiken initialisiert sind.
Das klappt nun seit Jahren stabil und zuverlässig, da hat Marcus seinerzeit sehr gute Arbeit geleistet.

Das andere ist IMHO akademischer Unfug, denn wo hört ein "Startup up" finished auf und wo fängt dann der Run an und v.a. .... was hab ich davon?

Wenn Du unbedingt mit KNX-INIT arbeiten willst und daher die Results brauchst kommst Du in ganz neue Probleme, nämlich bspw. was machst Du wenn sich einzelne Komponenten nicht am Bus melden, bleibt dann das System auf init? Genau deswegen genügt die Sicherstellung eines konstistenten Standes (Item cache und KNX_cache) um dann den Rest individuell in Logiken abzuarbeiten, das geht aber eben nur wenn die Items und ALLE Logiken initialisiert sind.

Andere Systeme machen das bspw. indem sie einfach einen Timer nach dem Startup setzen der bspw. 5 Mins. nach Start dann Ready meldet. Ich habe bei mir auch Plugins auf Komponenten die tw. Aus sind und sich nicht melden, da bringt dann ein Init der nie fertig wird so rein gar nix (bspw. AV-Receiver, HUE, AP usw.).

[gama]

Guten Morgen, ich will ja nicht bezweifeln, dass Deine Lösung bzw. der Code schlecht ist - im Gegenteil. Ich habe eher laut darüber nachgedacht und es geht erst einmal um die Idee... es müssen ja nicht alle Plugins "init fertig" melden...

[gama]

Hi,

ich habe die Logik implementiert, die mittels

crontab=init

aufgerufen wird, einen Logeintrag erstellt und ein Item auf true setzt. Funktioniert soweit, jedoch wird die Logik aufgerufen, obwohl die Items noch abgefragt werden (so zumindest die Analyse über den Busmonitor). Ist der Aufruf über crontab richtig? Ideen?

Danke
Markus

[Sandman60]

Hmm, kann Dir leider nicht ganz folgen. wie werden denn die KNX-Items ausgelesen? Via logik oder via knx_init im Item (was m.W. sich nicht unterbinden lässt). Ansonsten ist das bei mir simple. Alle Startup-kritischen Logiken haben ein Exit wenn START nicht wahr ist und die letzte Logik für START wird via crontab=init getriggert.

[gama]

Hi,

das habe ich so gemacht, dass die letzte Logik per crontab = init aufgerufen wird und dann ein Status-Item auf True setzt. Das funktioniert auch soweit, jedoch läuft im Hintergrund noch die Abfrage diverser Items, die über knx_init ihre Werte beziehen. Was ich bräuchte, wäre ein (zweites) Item, welches mir signalisiert, dass alle knx_inits durch sind...

Grüße
Markus

[Sandman60]

Das wird so m.E. nicht klappen mit der Rückmeldung wenn knx_init aus dem Item fertig ist. da ich bei über 5600 Items gerade mal 6 Items mit knx_init habe kann ich da leider nicht wirklich mitreden.

[gama]

Ok? Und wie machst Du, dass der "Systemzustand" nach einem Restart (mit ggf. längerer Pause) im SH mit der Realität konsistent ist? Übersehe ich da was?
Ich habe gerade mal in den code vom knx plugin gesehen:

- beim Aufruf der handle_connect() Methode wird aus dem cache und alle init-items vom bus gelesen.
- Evtl. kann man hier ein Item übergeben, die mit 1 getriggert wird, nachdem die Routine abgeschlossen wurde.
- Oder macht eine Erweiterung (z.B. "crontab = connected") mehr Sinn? Dann wäre es sinnvoll, auch andere Bus-Treiber mit einzubeziehen und erst nach Abschluss aller Verbindungsroutinen das Ereignis zu generieren...

Dafür, Dagegen, Ideen?

Grüße
Markus

[Sandman60]

Also:
1.Ich verwende meist KNX_Cache da meist nur SHNG down ist, nicht der ganze "Server".
2. Wichtige Werte werden per cache=yes gehalten.
3. (Ist eine grundsätzliche Designfrage Die meisten Statusinformationen werden zyklisch von den Aktoren gesendet. Bedeutet typische Status wie Fenster, Türen, Temperaturen, Jalousien usw. synchronisieren sich automatisch (meist innerhalb eines 10 Minuten Zyklus).

Die Kombination aus 1.-3. vermeidet knx_init, was wiederum bedeutet das keine Abhängigkeit zu den Items existiert und damit erst die Plugins und dann die Logiken angefahren werden, wobei die kritischen Logiken übersprungen werden und dann die letzte Logik ein Logik ist fertig schreibt und dann die kritischen Logiken erst nach dieser Initialisierung getriggert werden können.

Hat sich bei mir bewährt und läuft, sehe hierzu also keinen Handlungsbedarf.

[gama]

Das mit dem Cache mache ich auch so, teilweise auch mit sqllite=init, da dann die Werte in der Datenbank abgelegt werden und nicht im Filesystem.

Jetzt kommt die Frage nach der Messaging Strategie, denn um die Buslast möglichst gering zu halten, empfiehlt sich möglichst nur Werte bei Änderung zu senden. Bei den Fenster-Kontakten ist evtl. ein zyklisches senden von Vorteil, um eine Manipulation auf der Leitung zu erkennen...

Ich habe eine (mittlerweile recht komplexe) State Machine implementiert, die den Haus-Zustand abbilden soll. Ein falscher Zustand aufgrund nicht initialisierter Werte soll vermieden werden. Daher sollte die Init-Phase sauber durchlaufen sein... und da ein Neustart eigentlich kaum vorkommt, würde ich mich generell mit knx_init sehr wohl fühlen, da die Daten nicht redundant gehalten werden.

Ist hier jemand von den SHNG Core Entwicklern? Was meint Ihr? Soll ich da mal eine patch basteln?

[Msinn]

Ich sehe nicht, wie eine Änderung im Core Dein Problem lösen sollte.

Du müsstest Dir eher im KNX Plugin merken welche Items mit knx_init konfiguriert sind und prüfen ob die jeweiligen Kimponenten geantwortet haben.

Ich bin kein großer Freund vom starken Einsatz von knx_init, da die Flut von Anfragen mir den Bus zugefahren hat, was für diesen Zeitraum die Funktion im Bus stark einschränkte/behinderte.

[gama]

Hm, ist es also "gängige Praxis" die Daten auf SH redundant zu halten? Was wäre eine gute Alternative?

[Msinn]

Ich halte in shng keine Daten redundant.

Dort wo ich Werte om KNX Bus zum Startzeitpunkt gerne kennen möchte, nutze ich knx_cache. Ansonsten kann ich damit leben, das nach einem Neustart die Daten einiger Items erst nach 5 oder 10 Minuten wieder aktuell sind.

Ich verstehe nicht wozu Du exakt das "Ende der Initialisierung" ermitteln willst. Ganz davon abgesehen, dass das für ca. 80 Plugins kaum realisierbar ist. Ich habe Plugins im Einsatz, wo der Status nicht aktiv abfragbar ist, sondern auf ein Eintreffen neuer Werte gewartet werden muss.