ConfigDB Reihenfolge beim Start anpassbar?

[Borkk]

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?

[betateilchen]

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.

[Borkk]

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.

[bartman121]

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"

[betateilchen]

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.

[bartman121]

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.

[rudolfkoenig]

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.

[bartman121]

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.

[rudolfkoenig]

Hallo 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.

[betateilchen]

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.

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.

[Borkk]

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.

Code Auswählen Erweitern

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

[rudolfkoenig]

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.

[betateilchen]

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?

[bartman121]

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

fhem.cfg mit falscher Reihenfolge:

Code Auswählen Erweitern

# 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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


# 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:

Code Auswählen Erweitern

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 ...

[betateilchen]

die Reihenfolge kann eine Rolle spielen ...

Das hat niemand hier im Thread bestritten.

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.