Servus zusammen!
Ich hab heut mal einen BME280 an meinen quasi-neuen RasPi3 angesteckt.
Also schnell ein RPII2C-Device angelegt, den BME definiert und schwupps waren die Werte da. Allerdings geht das nur bis zum nächsten Neustart. Dann steht das RPII2C-Device auf "initialized" und der BME auf "defined" => keine Werte.
Lege ich im BME ein attr IODev RPII2C an, sind die Werte sofort wieder da. Nach dem Neustart ist das Attribut allerdings wieder verschwunden und der Sensor "steht".
Bedienerfehler oder Bug?
save nach dem Attribut hinzufügen gemacht?
Wenn es auch dann nicht da ist, dann kannst Du im Log schauen, warum das Attribut beim Laden "weggeworfen" wird
Logo, gesaved wurde.
Im Filelog steht nur
2017.03.16 18:28:20 2: Messages collected while initializing FHEM: configfile: 0 BME280: unknown IODev RPII2C specified
Das sagt mir zwar warum es gestrichen wurde aber nicht warum ;-)
lösche mal Dein Device und definiere es neu ....
es könnte sein, dass das IODev nach Deinem Device erst definiert wird ...
meiner Meinung nach noch KEIN Grund die cfg von Hand zu editieren :-)
Zitat von: tomster am 16 März 2017, 18:27:02
Logo, gesaved wurde.
Im Filelog steht nur
2017.03.16 18:28:20 2: Messages collected while initializing FHEM: configfile: 0 BME280: unknown IODev RPII2C specified
Das sagt mir zwar warum es gestrichen wurde aber nicht warum ;-)
Finde es sagt recht viel aus.
Zum Zeitpunkt der Initialisierung der BME280 Devices war das passende IODev noch nicht vorhanden.
Ein Blick in die fhem.cfg (falls verwendet) sollte zeigen, dass RPII2C hinter dem BME280 steht.
also wie Wuppi schon sagte: das BME280 Device löschen und neu anlegen
oder es mit copy duplizieren und das alte löschen
oder die fhem.cfg händisch ändern ( muss jeder selbst wissen 8) )
So wie du es schreibst, ist es einleuchtend. Mein Fehler war wohl irgendeine Änderung in der RPII2C-Definition, nachdem der BME angelegt wurde.
So gesehen, aber eher ein Bug im Modul, weil man ja die Reihenfolge der fhem.cfg nicht (mehr) wirklich beeinflussen kann/soll...
Zitat von: tomster am 16 März 2017, 22:58:10
So wie du es schreibst, ist es einleuchtend. Mein Fehler war wohl irgendeine Änderung in der RPII2C-Definition, nachdem der BME angelegt wurde.
So gesehen, aber eher ein Bug im Modul, weil man ja die Reihenfolge der fhem.cfg nicht (mehr) wirklich beeinflussen kann/soll...
Solange das RPII2C nicht gelöscht wird ändert sich an der Position nichts. Veränderte oder neue Attribute werden nach dem define angefügt.
Bug?
Funktioniert das denn beim CUL oder ZWave oder MQTT wenn ich das Physikalische Device nach dem Logischen definieren?
Für Vorschläge bin ich immer offen.
Letzteres kann ich nicht beantworten. Ich hab aber gelegentlich das DEF des RPII2C geändert, um zu sehen woran mein BME hängt (0 oder 1). Vermutlich legt das aber das Device neu an, zumindest in der (geforderten) Reihenfolge. Plöd.
Ich hab aber nicht gelöscht, ehrlich! Einigen wir uns auf Unentschieden?
Zitat von: klausw am 16 März 2017, 23:41:38
Bug?
Funktioniert das denn beim CUL oder ZWave oder MQTT wenn ich das Physikalische Device nach dem Logischen definieren?
Für Vorschläge bin ich immer offen.
Antwort wohl: kommt darauf an, wie der Modulentwickler das gelöst hat, siehe hier: https://forum.fhem.de/index.php/topic,62653.msg584897.html#msg584897
Bei CUL_HM jedenfalls scheint es zwischenzeitlich egal zu sein, wo die def in der config steht.
Gruß, Beta-User
Zitat von: tomster am 17 März 2017, 00:21:00
Letzteres kann ich nicht beantworten. Ich hab aber gelegentlich das DEF des RPII2C geändert, um zu sehen woran mein BME hängt (0 oder 1). Vermutlich legt das aber das Device neu an, zumindest in der (geforderten) Reihenfolge. Plöd.
Ich hab aber nicht gelöscht, ehrlich! Einigen wir uns auf Unentschieden?
Wenn das def geändert wird kann das sein, ich habe es jetzt nicht getestet.
Unentschieden? nix gibts 8)
Zitat von: Beta-User am 17 März 2017, 07:40:18
Antwort wohl: kommt darauf an, wie der Modulentwickler das gelöst hat, siehe hier: https://forum.fhem.de/index.php/topic,62653.msg584897.html#msg584897
Bei CUL_HM jedenfalls scheint es zwischenzeitlich egal zu sein, wo die def in der config steht.
Naja, das macht das ganze komfortabler.
Allerdings habe ich das im Define eigentlich schon drin:
if ($main::init_done) {
eval { I2C_BME280_Init( $hash, [ @a[ 2 .. scalar(@a) - 1 ] ] ); };
return I2C_BME280_Catch($@) if $@;
}
Wer findet den Fehler?
Hab's grad probiert. Eine Änderung des DEF im RPII2C ändert goar nix an der Position in der fhem.cfg.
Eine manuelle Änderung der Position - sprich den BME absichtlich VOR das RPII2C-Device zu schreiben - sehr wohl. In diesem Fall wird der BME nicht initialisiert, weil er das zugehörige IODev nicht findet.
Jetzt widersprichst du dir aber [emoji41]
Kommentiere mal die Zeile 123 aus. Eventuell funktioniert es dann auch wenn das IODev erst später initialisiert wird.
Verstehe ich dann zwar immer noch nicht. init_done bedeutet doch, die config ist komplett abgearbeitet, oder?
Nun ja, widersprechen nicht direkt. Ich hab ja nur vermutet, dass durch die DEF-Änderung die Reihenfolge geändert wird. Probiert hatte ich es zu diesem Zeitpunkt noch nicht.
Kein Unterschied bei auskommentierter Zeile 123. Der BME wird mangels RPII2C nicht initialisert, respektive das attr IODev gelöscht.
Ändere ich die Reihenfolge kein Gemosere; Sensor läuft.