Hallo zusammen,
ich nutze DBlog und ConfigDB schon eine ganze Weile und hatte noch nie Probleme damit. Ich finde es genial! Ich hab tatsächlich auch schon mal den Config Rollback genutzt und auf DBlog greife ich mit Grafana zu, einfach spitze.
Dennoch treibt mich schon seit längerem eine Frage um, auf die ich hier oder sonst wo keine Antwort gefunden habe. Ist vielleicht auch eine doofe Frage... Kann man (ähnlich wie bei der txt Config) die Reihenfolge beim abarbeiten der FHEM Config beim Start beeinflussen?
Ist eher kosmetischer Natur, da ich beim Start eine ganze Reihe Fehlermeldung im Log habe, die u.a. daher rühren, das z.B. bereits Homematic IP Geräte angesprochen werden, noch bevor die HMCCU gestartet wurde.Gleiches gilt für den Zugriff auf Daten einer 2. FHEM Instanz noch bevor FHEM2FHEM gestartet wurde. Das rüttelt sich am Ende zwar alles ein, ich finde es aber trotzdem unglücklich.
Konkret würde ich also gerne alle "Connectoren" (FHEM2FHEM, HMCCU, Alexa, usw) als erstes starten. So hatte ich das auch im TXT File gemacht.
Geht das? oder kann man sonst irgendwie eine Priorität beim Start einstellen?
Zitat von: Borkk am 22 Dezember 2022, 10:49:34
Geht das? oder kann man sonst irgendwie eine Priorität beim Start einstellen?
Nein. Und das ist auch keine Aufgabe, die von der configDB gelöst werden muss.
Wenn Homematic Geräte angesprochen werden, bevor das zugehörige IODev verfügbar ist, dann sollte das von den verantwortlichen Modulautoren in ihren Modulen gelöst werden. Die benötigten Mechanismen, um solche Probleme zu vermeiden, sind inzwischen schon lange in FHEM vorhanden. Sie müssen halt benutzt werden.
Zitat von: betateilchen am 22 Dezember 2022, 11:34:01
Nein. Und das ist auch keine Aufgabe, die von der configDB gelöst werden muss.
Wenn Homematic Geräte angesprochen werden, bevor das zugehörige IODev verfügbar ist, dann sollte das von den verantwortlichen Modulautoren in ihren Modulen gelöst werden. Die benötigten Mechanismen, um solche Probleme zu vermeiden, sind inzwischen schon lange in FHEM vorhanden. Sie müssen halt benutzt werden.
Homematic war ja nur ein Beispiel, betrifft ja alle Module die als "Connector" arbeiten . Aber danke für deine schnelle und klare Antwort.
Es geht, aber da musst du direkt in der DB rumschreiben, das ist wirklich nicht empfehlenswert.
Ein workaround ist folgendes:
Das device das später "kommen soll"...
Dort die raw-definition kopieren... Das device löschen....die raw-definition wieder über den Editor einspielen....
Dann ist es halt das "letzte device"
Zitat von: Borkk am 22 Dezember 2022, 12:01:00
Homematic war ja nur ein Beispiel, betrifft ja alle Module die als "Connector" arbeiten . Aber danke für deine schnelle und klare Antwort.
An sich ist es ja unlogisch, dass ein IODev erst nach den zugehörigen devices, die das IODev brauchen, in FHEM angelegt wird.
Das kann vermutlich nur durch nachträgliches Verschlimmbessern einer bestehenden Installation passiert sein.
Verschlimmbesserung?
Wenn ich mich zum Beispiel entscheide mehrere Jeelink (wegen ec3000 und Lacrosse) durch einen Lacrosse-gateway zu ersetzen, weil ich dann nur ein Gerät habe.
Dann werde ich natürlich nur das Iodev neu anlegen, genau dan ist die Reihenfolge eben falsch. Das gibt Warnung, funktioniert aber trotzdem...
Ich würde fast behaupten, dass hier im Konzept der seriellen Abarbeitung schlicht und einfach nicht bedacht wurde, dass auch grundlegende Geräte Mal kaputt gehen können, abgekündigt werden oder technisch überholt werden. Die Einführung von Nummernkreise für bestimmte Geräte-Hierarchien wäre hier sinnvoll.
Deswegen ein bestehendes system komplett neu in der richtigen Reihenfolge anzulegen kann nicht im Sinne des Erfinders sein.
Gerade bei cobfigdb wäre das nachträgliche ändern der Reihenfolge kinderleicht möglich.
Eigentlich(TM) ist eine Aenderung der Reihenfolge in solchen Faellen nicht notwendig:
- das Framework sucht ein passendes IODev, wenn mehrere existieren, dann das zuletzt definierte.
- falls der Benutzer es besser weiss, dann setzt er das IODev Attribut.
Hallo Rudi,ich hab jetzt keine Lust das zu testen, aber ich bin der Meinung, dass das setzen des iodev-attr nicht reicht.
Weil eben das device beim start nach der Anlegereihenfolge angelegt wird. Hat man später ein völlig anderes Iodev, dann kommt das in der Reihenfolge eben erst später und es gibt eine Warnung. Es funktioniert natürlich trotzdem, die Warnung ist aber unschön.
Die Frage nach der Reihenfolge kommt schon öfter, daher wird vermutlich etwas dran sein, dass die User hier durch ihr - vielleicht auch falsches - Verhalten genau solche Warnungen erzeugen können.
ZitatHallo Rudi,ich hab jetzt keine Lust das zu testen, aber ich bin der Meinung, dass das setzen des iodev-attr nicht reicht.
So kommen wir nicht ins Geschaeft.
Zitat von: bartman121 am 22 Dezember 2022, 13:58:01
Ich würde fast behaupten, dass hier im Konzept der seriellen Abarbeitung schlicht und einfach nicht bedacht wurde, dass auch grundlegende Geräte Mal kaputt gehen können, abgekündigt werden oder technisch überholt werden.
Doch, das Problem wurde schon vor Langem erkannt und in den letzten Jahren wurden dafür auch Lösungen geschaffen.
Das hatte ich weiter oben schon geschrieben und das wurde jetzt auch von Rudi bestätigt.
Zitat von: rudolfkoenig am 22 Dezember 2022, 14:54:43
So kommen wir nicht ins Geschaeft.
Es ist halt schwierig, wenn man mit konstruktiven Lösungsvorschlägen gegen Windmühlen kämpft und Anwender nichtmal bereit sind, einen Vorschlag zu testen, stattdessen aber vermuten, dass der Vorschlag nicht funktioniert.
Dieses Phänomen wird in letzter Zeit hier im Forum immer schlimmer.
Leute, ich wollte hier keine Grundsatzdiskussion auslösen ::)
Wie ich in meiner Frage geschrieben habe, es geht mir nur um Kosmetik. Es gibt keinerlei Probleme wegen der Reihenfolge. Wenn die Startsequenz durch ist, läuft ja alles.
Es geht mir halt um den Müll (nur ein Auszug) im Log, der nur entsteht weil z.B. FHEM2FHEM, echodevice und HMCCU noch nicht geladen sind. Aber wie gesagt, kurz drauf werden die entsprechenden Module geladen und alles ist schick. Aber wenn ich mir was wünschen dürfte (ist ja Weihnachten :)) dann das Module die Connectoren Charakter haben, zuerst geladen werden.
set fl_echo volume 40 : fl_echo is not connected. Aborting...
2022.12.22 10:21:27 3: set fl_echo volume 40 : fl_echo is not connected. Aborting...
2022.12.22 10:21:27 3: set ds_echo info Erzaehle_Witz : ds_echo is not connected. Aborting...
2022.12.22 10:21:27 3: set ds_echo info Erzaehle_Witz : ds_echo is not connected. Aborting...
2022.12.22 10:21:27 3: set fhem2 cmd set tado setZoneOverlay 2 remove : Not connected
2022.12.22 10:21:27 3: ds_act_door return value: Not connected
2022.12.22 10:21:27 3: set ka_switch off : Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_LONG_RELEASE,1.PRESS_LONG_START,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_LONG_RELEASE,2.PRESS_LONG_START,2.PRESS_SHORT,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.PROCESS,5.SECTION,5.SECTION_STATUS,5.STATE,6.PROCESS,6.SECTION,6.SECTION_STATUS,6.STATE,7.CURRENT,7.CURRENT_STATUS,7.ENERGY_COUNTER,7.ENERGY_COUNTER_OVERFLOW,7.FREQUENCY,7.FREQUENCY_STATUS,7.POWER,7.POWER_STATUS,7.VOLTAGE,7.VOLTAGE_STATUS,9.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint
2022.12.22 10:21:27 3: ka_licht return value: Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_LONG_RELEASE,1.PRESS_LONG_START,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_LONG_RELEASE,2.PRESS_LONG_START,2.PRESS_SHORT,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.PROCESS,5.SECTION,5.SECTION_STATUS,5.STATE,6.PROCESS,6.SECTION,6.SECTION_STATUS,6.STATE,7.CURRENT,7.CURRENT_STATUS,7.ENERGY_COUNTER,7.ENERGY_COUNTER_OVERFLOW,7.FREQUENCY,7.FREQUENCY_STATUS,7.POWER,7.POWER_STATUS,7.VOLTAGE,7.VOLTAGE_STATUS,9.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint
2022.12.22 10:21:27 3: set fhem2 cmd set tado setZoneOverlay 5 remove : Not connected
2022.12.22 10:21:27 3: ku_act_window return value: Not connected
2022.12.22 10:21:27 3: set fhem2 cmd set tado setZoneOverlay 1 remove : Not connected
2022.12.22 10:21:27 3: sz_act_door return value: Not connected
2022.12.22 10:21:28 3: set wz_scene scene wz_set1 : Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_LONG_RELEASE,1.PRESS_LONG_START,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_LONG_RELEASE,2.PRESS_LONG_START,2.PRESS_SHORT,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.PROCESS,5.SECTION,5.SECTION_STATUS,5.STATE,6.PROCESS,6.SECTION,6.SECTION_STATUS,6.STATE,7.CURRENT,7.CURRENT_STATUS,7.ENERGY_COUNTER,7.ENERGY_COUNTER_OVERFLOW,7.FREQUENCY,7.FREQUENCY_STATUS,7.POWER,7.POWER_STATUS,7.VOLTAGE,7.VOLTAGE_STATUS,9.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_LONG_RELEASE,1.PRESS_LONG_START,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_LONG_RELEASE,2.PRESS_LONG_START,2.PRESS_SHORT,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.PROCESS,5.SECTION,5.SECTION_STATUS,5.STATE,6.PROCESS,6.SECTION,6.SECTION_STATUS,6.STATE,7.CURRENT,7.CURRENT_STATUS,7.ENERGY_COUNTER,7.ENERGY_COUNTER_OVERFLOW,7.FREQUENCY,7.FREQUENCY_STATUS,7.POWER,7.POWER_STATUS,7.VOLTAGE,7.VOLTAGE_STATUS,9.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PROCESS,1.SECTION,1.SECTION_STATUS,1.STATE,2.PROCESS,2.SECTION,2.SECTION_STATUS,2.STATE,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.CURRENT,5.CURRENT_STATUS,5.ENERGY_COUNTER,5.ENERGY_COUNTER_OVERFLOW,5.FREQUENCY,5.FREQUENCY_STATUS,5.POWER,5.POWER_STATUS,5.VOLTAGE,5.VOLTAGE_STATUS,7.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint
2022.12.22 10:21:28 3: set wz_scene scene wz_set1 : Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_LONG_RELEASE,1.PRESS_LONG_START,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_LONG_RELEASE,2.PRESS_LONG_START,2.PRESS_SHORT,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.PROCESS,5.SECTION,5.SECTION_STATUS,5.STATE,6.PROCESS,6.SECTION,6.SECTION_STATUS,6.STATE,7.CURRENT,7.CURRENT_STATUS,7.ENERGY_COUNTER,7.ENERGY_COUNTER_OVERFLOW,7.FREQUENCY,7.FREQUENCY_STATUS,7.POWER,7.POWER_STATUS,7.VOLTAGE,7.VOLTAGE_STATUS,9.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PRESS_LONG,1.PRESS_LONG_RELEASE,1.PRESS_LONG_START,1.PRESS_SHORT,2.PRESS_LONG,2.PRESS_LONG_RELEASE,2.PRESS_LONG_START,2.PRESS_SHORT,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.PROCESS,5.SECTION,5.SECTION_STATUS,5.STATE,6.PROCESS,6.SECTION,6.SECTION_STATUS,6.STATE,7.CURRENT,7.CURRENT_STATUS,7.ENERGY_COUNTER,7.ENERGY_COUNTER_OVERFLOW,7.FREQUENCY,7.FREQUENCY_STATUS,7.POWER,7.POWER_STATUS,7.VOLTAGE,7.VOLTAGE_STATUS,9.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint Unknown argument off choose one of clear defaults:reset,update,old,forceReset readingFilter:multiple-strict,0.ACTUAL_TEMPERATURE,0.ACTUAL_TEMPERATURE_STATUS,0.CONFIG_PENDING,0.DUTY_CYCLE,0.ERROR_CODE,0.ERROR_OVERHEAT,0.INSTALL_TEST,0.OPERATING_VOLTAGE,0.OPERATING_VOLTAGE_STATUS,0.RSSI_DEVICE,0.RSSI_PEER,0.UNREACH,0.UPDATE_PENDING,1.PROCESS,1.SECTION,1.SECTION_STATUS,1.STATE,2.PROCESS,2.SECTION,2.SECTION_STATUS,2.STATE,3.PROCESS,3.SECTION,3.SECTION_STATUS,3.STATE,4.PROCESS,4.SECTION,4.SECTION_STATUS,4.STATE,5.CURRENT,5.CURRENT_STATUS,5.ENERGY_COUNTER,5.ENERGY_COUNTER_OVERFLOW,5.FREQUENCY,5.FREQUENCY_STATUS,5.POWER,5.POWER_STATUS,5.VOLTAGE,5.VOLTAGE_STATUS,7.WEEK_PROGRAM_CHANNEL_LOCKS config datapoint
2022.12.22 10:21:28 3: set fhem2 cmd set tado setZoneOverlay 3 remove : Not connected
2022.12.22 10:21:28 3: wz_act_door return value: Not connected
Ich hoffe, dass eine Aenderung der Reihenfolge an dieser Fehlermeldungen nichts aendert.
Wenn es doch tut, dann sind die betroffenen Module blockierend, und das sollte man schleunigst vermeiden.
Zitat von: Borkk am 22 Dezember 2022, 16:53:24
Aber wenn ich mir was wünschen dürfte (ist ja Weihnachten :)) dann das Module die Connectoren Charakter haben, zuerst geladen werden.
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?
okay ... hab schnell mal ein System zusammen geknüppert ....
fhem.cfg mit falscher Reihenfolge:
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 63a4b32c-f33f-800d-0462-9155ca08982691f7
attr initialUsbCheck disable 1
define AUSSEN.TEMP LaCrosse 1D
setuuid AUSSEN.TEMP 63a4b36c-f33f-800d-8c6d-0781cca736d931b3
attr AUSSEN.TEMP IODev myLaCrosseGateway
attr AUSSEN.TEMP event-on-change-reading avg_aussen,battery,temperature:0.15
attr AUSSEN.TEMP room Wetter-vorhersage,ZZZ_FOSCA
define myLaCrosseGateway LaCrosseGateway /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@57600
setuuid myLaCrosseGateway 63a4b3ac-f33f-800d-730b-1a63adb3e476e6a5
attr myLaCrosseGateway disable 0
attr myLaCrosseGateway initCommands 17241#1r 8842#2r v
attr myLaCrosseGateway room ZZZ_RXD_TXD
attr myLaCrosseGateway timeout 120,30
attr myLaCrosseGateway usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE] 2>&1
Logfile beim Start:
2022.12.22 19:42:36 0: Server started with 6 defined entities (fhem.pl:26868/2022-12-18 perl:5.034000 os:linux user:fhem pid:1676)
2022.12.22 19:43:40 3: No I/O device found for AUSSEN.TEMP
2022.12.22 19:43:40 1: AUSSEN.TEMP: no I/O device
2022.12.22 19:43:51 1: AUSSEN.TEMP: no I/O device
2022.12.22 19:44:01 1: AUSSEN.TEMP: no I/O device
2022.12.22 19:44:44 1: AUSSEN.TEMP: no I/O device
2022.12.22 19:44:44 3: Opening myLaCrosseGateway device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2022.12.22 19:44:44 1: myLaCrosseGateway: Can't open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0: No such file or directory
2022.12.22 19:44:52 3: AUSSEN.TEMP: I/O device is myLaCrosseGateway
------------------------------------------------------------------------------------------------------------
jetzt fhem.cfg sortiert:
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 63a4b32c-f33f-800d-0462-9155ca08982691f7
attr initialUsbCheck disable 1
define myLaCrosseGateway LaCrosseGateway /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@57600
setuuid myLaCrosseGateway 63a4b3ac-f33f-800d-730b-1a63adb3e476e6a5
attr myLaCrosseGateway disable 0
attr myLaCrosseGateway initCommands 17241#1r 8842#2r v
attr myLaCrosseGateway room ZZZ_RXD_TXD
attr myLaCrosseGateway timeout 120,30
attr myLaCrosseGateway usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE] 2>&1
define AUSSEN.TEMP LaCrosse 1D
setuuid AUSSEN.TEMP 63a4b4fd-f33f-800d-a110-2eef6d80ebaf39b9
attr AUSSEN.TEMP IODev myLaCrosseGateway
attr AUSSEN.TEMP event-on-change-reading avg_aussen,battery,temperature:0.15
attr AUSSEN.TEMP room Wetter-vorhersage,ZZZ_FOSCA
Logfile:
2022.12.22 19:45:49 3: Opening myLaCrosseGateway device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2022.12.22 19:45:49 1: myLaCrosseGateway: Can't open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0: No such file or directory
2022.12.22 19:45:49 0: Featurelevel: 6.1
2022.12.22 19:45:49 0: Server started with 8 defined entities (fhem.pl:26868/2022-12-18 perl:5.034000 os:linux user:fhem pid:1728)
2022.12.22 19:50:21 3: AUSSEN.TEMP: I/O device is myLaCrosseGateway
Es ist mir persönlich herzlich egal ob das ein Problem meines verwendeten Moduls ist, die Reihenfolge kann eine Rolle spielen ...
Ich hab zwar den LaCrosseGateway nicht physisch verbunden gehabt, aber daran sollte es nicht liegen ...
Zitat von: bartman121 am 22 Dezember 2022, 20:54:19
die Reihenfolge kann eine Rolle spielen ...
Das hat niemand hier im Thread bestritten.
Zitat von: bartman121 am 22 Dezember 2022, 20:54:19
Es ist mir persönlich herzlich egal ob das ein Problem meines verwendeten Moduls ist
Mir auch, es ist ursächlich kein Fehler der configDB.
Zitat von: betateilchen am 22 Dezember 2022, 18:37:31
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.
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.
ZitatZitat 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 ;)
@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
Zitat von: fhem-hm-knecht am 23 Dezember 2022, 01:58:58
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)
Zitat von: bartman121 am 23 Dezember 2022, 06:37:45
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
- ...
Zitat von: bartman121 am 23 Dezember 2022, 06:37:45
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.
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).
Zitat von: Beta-User am 23 Dezember 2022, 11:04:16
- 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.
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.
Zitatokay ... 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:
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.
Zitat- 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.
Zitat- 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?
Zitat von: rudolfkoenig am 23 Dezember 2022, 12:01:07
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.
Eigentlich braucht man diese Meldung im Modul gar nicht: wenn das Framework nichts findet, dann wird das schon gemeldet.
Zitat von: rudolfkoenig am 23 Dezember 2022, 12:01:07
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.
Zitat von: rudolfkoenig am 23 Dezember 2022, 12:43:21
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.
Zitat von: Beta-User am 23 Dezember 2022, 13:49:59
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!
Zitat von: rudolfkoenig am 23 Dezember 2022, 12:43:21
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.
Zitat von: CoolTux am 23 Dezember 2022, 16:12:29
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:
Zitat von: fhem-hm-knecht am 23 Dezember 2022, 01:58:58
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...
ZitatEs funktioniert, aber der jeweilige Modul-Maintainer muss eben aktiv werden und die bereitgestellten Mechanismen auch nutzen...
wenn also alles nur "rund" läuft, wenn auch alle module den "rundlauf" unterstützen, wäre es ja vielleicht möglich, dass fhem.pl einen gestörten rundlauf erkennt und ggf eine meldung ausgibt, die dem user explizit nahelegt, sich beim entsprechden maintainer wegen modul xyz zu melden.
spätestens jetzt ist die Zeit (und der Thread) reif für Popcorn...
Trotzdem interessant zu sehen wie sich jetzt die Herren in blau über etwas unterhalten, was anfänglich eine Verschlimmbesserung war und noch schlimmer, man mit den Worten "das ist nicht "Dein" Thread" herausgebeten wird...
Es ist gut, dass die Diskussion geführt wird, leider wird aber dem Nutzer jeglicher Verstand abgesprochen, das dürfte auch der Grund sein warum kaum einer Lust drauf hat etwas an den Modulautor zu melden. Zumal dem Endnutzer gar nicht klar sein kann, ob nun das Modul oder fhem oder ein Fehlverhalten das Problem ist.
Viele Grüße
Zitat von: bartman121 am 23 Dezember 2022, 17:11:14
Trotzdem interessant zu sehen wie sich jetzt die Herren in blau über etwas unterhalten, was anfänglich eine Verschlimmbesserung war und noch schlimmer, man mit den Worten "das ist nicht "Dein" Thread" herausgebeten wird...
Es ist gut, dass die Diskussion geführt wird, leider wird aber dem Nutzer jeglicher Verstand abgesprochen, das dürfte auch der Grund sein warum kaum einer Lust drauf hat etwas an den Modulautor zu melden. Zumal dem Endnutzer gar nicht klar sein kann, ob nun das Modul oder fhem oder ein Fehlverhalten das Problem ist.
Viele Grüße
Bei Gelb wird man mit Cents und Popcorn beworfen ;D ;D ;D
Ist leider eine Unart vereinzelter User.
Moin zusammen,
ihr habt mich schon lange abgehängt 8), ich habe aber verstanden, dass man die Reihenfolge nicht anpassen kann. Das war eigentlich auch nur die Frage die ich am Anfang gestellt hatte.
Als "Enduser" kann ich mich nur bei euch Bedanken, ihr habt mit FHEM und den unzähligen Modulen eine tolle Lösung gebaut, mit der ich bisher jede noch so verrückte Idee realisieren konnte. Manchmal ist der Ton hier im Forum schon etwas ruppig, auch ich habe das schon mal ab bekommen. Das finde ich etwas Schade.
Frohe Weihnachten und ich freu mich auf ein FHEM Jahr 2023 :)
Wobei ich im Vergleich mit anderen Foren (die ich kenne) den Ton hier besser finde. Haben noch nie ein reines "RTFM" gesehen .....
Ansonsten ... Fröhliche und Friedliche Weihnachten
P.S. Wobei ich die Unterscheidung "die in Blau/Gelb" schon krass finde ....