[callidomus] hat sich was an parse_logic geändert?

[heckmannju]

Hi Marcus,

die methode parse item() wurde ja bei deinen letzen umbau durch pere_stage erstzt?

Was sind die Notwendigen Änderungen in für parse_logic?

Viele Grüsse
Jürgen

[callidomus]

Hallo Jürgen,

das parse_logic ist nicht mehr notwendig. Es werden auch die Logiken von core.config.query_nodes geliefert.
Der Aufruf (Logik, Item) ist identisch, da das ja alles harmonisiert wurde.

Bis bald

Marcus

[heckmannju]

Hi Markus,

in welcher Reihenfolge wurde parse_item und parse_logic vorher auf dem itembaum bezugen aufgerufen?

Wie werden logiken in UI/GUI definiert? Gibt es eine Logik.md?

Das beides wird ja jetzt in pre_stage gerufen? Kannst du da ein Beispiel auch in deiner Doku Liefern?

Viele Grüsse
Jürgen

[callidomus]

Hallo Jürgen,

die Reihenfolge spielt keine Rolle.

Man kann bei Plugins eine logic.md anlegen. Siehe z.B. KNX Plugin.

Bei dem pre_stage wird nicht zwischen Item und Logik unterschieden. Es spielt keine Rolle ob das Attribut an einem Item oder an einer Logik hängt.

Bis bald

Marcus

[heckmannju]

Hi,



Es war möglich Dynamisch sachen zu erzeugen und abzulegen und auszuwerten in diesen beiden Routinen.
Wie kann es da sein das die reihenfolge da keine Rolle spielt?

Mann muss jetzt das was in parse_item und parse_logic gemacht wurde in eine Schleife überführen und abhängig was da gemacht wurde spielt es unter umständen doch die Reihenfolge eine Rolle.

Von dem her wäre es einfach gut wenn ich die Reihenfolge weiss wie das agearbeitet wurde.

Viele Grüsse
Jürgen

[callidomus]

Hallo,

Wie kann es da sein das die reihenfolge da keine Rolle spielt?

Weil ich es sage.
Wenn Du mehr wissen möchtest, lese den Source-Code. Ich kann und will Dir nicht jedes Implementierungsdetail erklären.

Von dem her wäre es einfach gut wenn ich die Reihenfolge weiss wie das agearbeitet wurde.

Wie es war, ist doch jetzt egal. Es spielt keine Rolle.

Bis bald

Marcus

[heckmannju]

Hallo Marcus,

Weil du das sagst als begründung finde ich halt zu Wenig. Beim Portieren/Wiederinbetirebnehmen spielt es doch eine Rolle auch wen du jetzt meinst das es keine spielt.

Und so lange die Doku noch lückenhaft ist musst du wohl oder übel mit einigen Fragen zu dem Thema auseinandersetzten. Mir und warscheinlich vielen anderen reichen halt nicht die 5 Zeilen die du in der Doku zu pre_stage geschrieben hast.

Capture.PNG

Wenn man etwas aus eine API rauswirft und inkompatible ändert macht man das eigentlich nicht so. Mann setzt die API auf depricated erklärt weiterhin eine Zeilang wie es war.

Viele Grüsse
Jürgen

[callidomus]

Hallo Jürgen,

Beim Portieren/Wiederinbetirebnehmen spielt es doch eine Rolle auch wen du jetzt meinst das es keine spielt.

wieso spielt das ein Rolle?

Bis bald

Marcus

[heckmannju]

Weil in parse_item irgentwas angelegt wurde was in parse_logic benutzt wird. Geht man erst alle Items in parse_item durch und dann alle Logiken oder erst die Items dann die zugehörigen Logiken?

Viele Grüsse
Jürgen

[callidomus]

"Irgendetwas"

Etwas spezifischer? Hast Du ein Beispiel?

[heckmannju]

z.b. im MQTT Plugin.

[callidomus]

In https://github.com/mknx/smarthome/bl...tt/__init__.py gibt es kein irgendetwas.

[heckmannju]

Hi Marcus,

Martin konnte mein frage beantworten nach der Reihenfolge beantworten. -> https://knx-user-forum.de/forum/supp...84#post1079184

- Plugins laden und worker Thread je Plugin erzeugen

- Items parsen, dabei je Item in allen Plugins 'parse_items' aufrufen

- Logiken initialisieren, dabei je Logik In allen Plugins 'parse_logic' aufrufen

Viele Grüsse
Jürgen

[callidomus]

Hallo Jürgen,

und wieso spielt es nun eine Rolle?

Ich helfe Dir ja gerne, ich muss aber dazu verstehen was Du erreichen möchtest.

Bis bald

Marcus

[heckmannju]

Ich helfe Dir ja gerne, ich muss aber dazu verstehen was Du erreichen möchtest.

ich will "einfach" Plugins die für Smarthome.py und SmarthomeNG entwickelt worden Portieren. Das war bisher ziemlich einfach. Der derzeitige Stand der Dokumentation machen das schwer.