ConfigDB Reihenfolge beim Start anpassbar?

[Borkk]

Für mich zeigt Dein Log aber ein anderes Problem als das, wofür Du Dir eine Lösung wünscht.

Deinen Wunsch könnte man auch umdrehen: "die Geräte, die auf einen Connector angewiesen sind, sollten erst aktiv werden, wenn der Connector verfügbar ist."

Und das kann FHEM eigentlich schon.

Was mich interessieren würde: woher kommen die set Befehle zu diesem Zeitpunkt?

Ich will das Thema wirklich nicht noch weiter stressen und da ich kein Entwickler bin, will ich eure Aussagen auch gar nicht anzweifeln. Für mich war es nur logisch, das wenn ein notify beim start getriggert wird (warum muss ich mal rausfinden) und auf ein Reading eines Devices zugreifen will das es noch nicht gibt bzw. noch nicht erreichbar ist, dann greift FHEM ins Leere. Ich dachte es gäbe eine einfache Möglichkeit es beim abarbeiten durch ConfigDB zu beeinflussen, so wie es in der FHEM.cfg eben auch möglich war. Es ist ja so, das es in FHEM oft deutlich mehr Funktion gibt, also die die man auf den ersten Blick sieht. Ich mache ja jetzt auch schon über 10 Jahre mit FHEM rum und ich finde es immer noch genial, weil eben fast alles irgendwie möglich ist. Und nicht zuletzt oft auch mit Hilfe aus diesem Forum. 

Ich werde mir jetzt in Ruhe mal anschauen warum da einige Notify´s beim Start getriggert werden, kann schon sein das ich das u.U. bei manchen Sachen nicht abgefangen habe.

[LuckyDay]

Ich persönlich  konfiguriere
erst alle global attr
fhemweb
dann die ganzen I/0s
dann erst die Device
und jetzt erst die Notifys ....

bei den device wird sofern noch erlaubt die IO hart gesetzt, da manchmal mehrere IOs zur Verfügung stehen.

fhem.save wird generell nicht geladen, da bei mir nur alte Zustände drin stehen, die Ich nicht haben will.

Zitat von: bartman121 am Gestern um 20:54:19

    die Reihenfolge kann eine Rolle spielen ...

Dieses neue Design seit ein paar Jahren, dass es egal sein soll, wie es in der config steht, scheint wohl immer noch nicht zu funktionieren. Schuldige findet man gleich

[bartman121]

@borkk

Ich bin mir sicher, dass deine Meldungen gar nichts mit dem Start von fhem zu tun haben.

@udo und Rudi
Es gibt natürlich keine Fehler und keine Schuldigen, selbst bei falscher Reihenfolge funktioniert das System. Trotzdem ist es kein schönes Verhalten hier auf die Endbenutzer zu zeigen und zu sagen: "... nötige den Modulautor diese verhalten zu ändern..."

Ich hatte lediglich gesagt, dass eine Reihenfolge-Option hier sinnvoll wäre stattdessen kommen gottähnliche Wesen und werfen mir "Verschlimmbesserung" vor und nehmen mich in die Beweispflicht....

Vielen Dank

[betateilchen]

Ich persönlich  konfiguriere
erst alle global attr

Anmerkung am Rande: Die globalen Attribute verarbeitet FHEM von Haus aus beim Systemstart zuerst, unabhängig davon, wo/wann sie in der Konfiguration auftauchen (unabhängig davon, ob fhem.cfg oder configDB im Einsatz ist)

[betateilchen]

Ich hatte lediglich gesagt, dass eine Reihenfolge-Option hier sinnvoll wäre

Stimmt. Aber Du bist nicht der Erste, der auf die Idee kam.
Diskussionen zu dem Thema gab es u.a. schon

• 2013 - https://forum.fhem.de/index.php/topic,11306.0.html
• 2014 - https://forum.fhem.de/index.php/topic,21023.0.html
• 2015 - https://forum.fhem.de/index.php/topic,39345.0.html
• 2016 - https://forum.fhem.de/index.php/topic,62653.0.html
• ...

werfen mir "Verschlimmbesserung" vor und nehmen mich in die Beweispflicht....

Niemand wirft Dir irgendwas vor oder nimmt Dich in irgendeine Pflicht.
Außerdem ist das hier überhaupt nicht "Dein" Thread.

[Beta-User]

Meine 2ct.:

- der Vorschlag, die Reihenfolge beeinflussen zu können, ist m.E. (userseitig gedacht) nachvollziehbar und uU. auch gar nicht so falsch, falls man z.B. ein forkendes Modul hat, das von den neuen Möglichkeiten noch keinen Gebrauch macht, sich nach vorne zu mogeln, und man Speicher sparen will.
- "Fehler" in der Reihenfolge sind nicht zwangsläufig eine Folge von (wirklichen) User-Fehlern, sondern können einfach im Lauf der Zeit entstehen
- Der Hinweis, dass man den Maintainer ansprechen sollte, das auf bessere Weise zu lösen, ist nicht "Nötigung", sondern sinnvoll. Viele Maintainer kennen das Problem uU. schon deswegen nicht, weil sie eben in die Reihenfolge aktiv eingreifen und kein Verständnis dafür haben, dass man das uU. nicht (so einfach) kann, weil man configDB nutzt
- wenn dann 4x in kurzer Folge irgendein Warning auf level 1 geschrieben wird, klingt das danach, als hätte der Maintainer sich mit diesem Zweig nicht besonders lange beschäftigt; auch das sollte ein Anlass sein, nach der Sinnhaftigkeit zu fragen. Ist nicht "wichtig", aber verbesserungsfähig
- Man kann neuerdings einzelne Devices "nach vorne mogeln", aber das ist und bleibt ein workaround, der für sich genommen auch uU. fehleranfällig ist (es gibt neuerdings einen freien ID-Nummernbereich).

[betateilchen]

- Man kann neuerdings einzelne Devices "nach vorne mogeln", aber das ist und bleibt ein workaround, der für sich genommen auch uU. fehleranfällig ist (es gibt neuerdings einen freien ID-Nummernbereich).

Um genau diese neue Möglichkeit zu nutzen, habe ich schon vor einiger Zeit den configdb Befehl "configdb renum <deviceName>" gebaut, der ein bestimmtes Device auf 2 setzt. Diese Änderung ist aber noch nicht eingecheckt, weil ich nach wie vor nicht sicher bin, ob man damit nicht mehr Probleme schafft, als man potenziell löst. Beim Testen der Funktionalität war es problemlos möglich, damit eine komplette FHEM Installation unbrauchbar zu machen.

Grundsätzlich ist und bleibt es m.E. die Aufgabe der Module, das Problem zu lösen.

[Beta-User]

OT: Hart auf 2 zu gehen scheint mir zu einfach, da "priosave" auch "vorne" in diesem Bereich beginnt. Wäre eher von 29 nach vorne gegangen, (falls belegt).
Es ist und bleibt aber ein unschöner workaround, der ggf. Effekte beseitigt, die eigentlich besser woanders gelöst werden sollten.

[rudolfkoenig]

okay ... hab schnell mal ein System zusammen geknüppert ....

Dieses Beispiel zeigt nur, dass mit der "AUSSEN.TEMP: no I/O device" Meldung voreilig Panik verbreitet wird.
Das Framework sucht nach dem Start nach der passenden IO, und weist diese auch zu:

Code Auswählen Erweitern

fhem> l AUSSEN.TEMP
Internals:
   DEF        1D
   FUUID      63a4b36c-f33f-800d-8c6d-0781cca736d931b3
   IODev      myLaCrosseGateway
   NAME       AUSSEN.TEMP
   NR         33
   STATE      ???
   TYPE       LaCrosse
...

Jetzt kann man rumphilosophieren, wer das "Problem" beheben soll: der Benutzer oder der Modulautor.

- der Vorschlag, die Reihenfolge beeinflussen zu können, ist m.E. (userseitig gedacht) nachvollziehbar und uU. auch gar nicht so falsch, falls man z.B. ein forkendes Modul hat, das von den neuen Möglichkeiten noch keinen Gebrauch macht, sich nach vorne zu mogeln, und man Speicher sparen will.

Speicher spart man keinen, es ist nur wg. der Linux-Voreinstellung "overcommit 50%" die Wahrscheinlichkeit geringer, dass das fork abgelehnt wird.

- Man kann neuerdings einzelne Devices "nach vorne mogeln", aber das ist und bleibt ein workaround, der für sich genommen auch uU. fehleranfällig ist (es gibt neuerdings einen freien ID-Nummernbereich).

Was ist mit fehleranfaellig gemeint? Habe ich was verpasst?

[betateilchen]

dass mit der "AUSSEN.TEMP: no I/O device" Meldung voreilig Panik verbreitet wird.
...
Jetzt kann man rumphilosophieren, wer das "Problem" beheben soll: der Benutzer oder der Modulautor.

Naja, da finde ich wenig philosophisches: Die ausgegebene Meldung von "no I/O device" in (beispielsweise) "waiting for I/O device" zu ändern, ist definitiv nicht Aufgabe des Benutzers.

[rudolfkoenig]

Eigentlich braucht man diese Meldung im Modul gar nicht: wenn das Framework nichts findet, dann wird das schon gemeldet.

[Beta-User]

Was ist mit fehleranfaellig gemeint? Habe ich was verpasst?

Du hast eher nichts verpaßt. Fehleranfällig ist es m.E. nur wenn man als User versucht, da selbst in den Device-Hashes rumzumalen (und z.B. versehentlich eine Nummer doppelt vergibt) und/oder dann nicht gleich wieder per save/restart für geordnete Verhältnisse sorgt. Brauchen wir aber auch nicht vertiefen, ich gehe davon aus, dass der in fhem.pl vercodete Teil paßt.

Eigentlich braucht man diese Meldung im Modul gar nicht: wenn das Framework nichts findet, dann wird das schon gemeldet.

Vermutlich ein Grund mehr, warum man dem Maintainer einfach (als User) einen Hinweis geben sollte, dass es "nett" wäre, diesem Thema ein paar Minuten zu widmen... Der Code dürfte eben an der Stelle schon "ewig fertig" sein, so dass der Maintainer ggf. einfach bisher keinen Anlass hatte, auf das geänderte Drumherum zu reagieren.

[betateilchen]

Vermutlich ein Grund mehr, warum man dem Maintainer einfach (als User) einen Hinweis geben sollte, dass es "nett" wäre, diesem Thema ein paar Minuten zu widmen...

Womit wir inhaltlich wieder bei meiner allerersten Antwort hier im Thread angekommen wären.

Frohe Weihnachten!

[CoolTux]

Eigentlich braucht man diese Meldung im Modul gar nicht: wenn das Framework nichts findet, dann wird das schon gemeldet.

Das sind Altlasten aus längst vergangenen Zeiten. Wenn ich mal Zeit finde ändere ich das gerne bei meinen Modulen.

[Beta-User]

Das sind Altlasten aus längst vergangenen Zeiten. Wenn ich mal Zeit finde ändere ich das gerne bei meinen Modulen.

Falls du Zeit und Lust hast, kannst du ja z.B. auch einen patch für Lacrosse machen. Denn diese Annahme hier ist falsch:

Dieses neue Design seit ein paar Jahren, dass es egal sein soll, wie es in der config steht, scheint wohl immer noch nicht zu funktionieren.

Es funktioniert, aber der jeweilige Modul-Maintainer muss eben aktiv werden und die bereitgestellten Mechanismen auch nutzen...