[gelöst) Falsches IODEV wird benutzt

[Medel]

Hallo,

ich habe momentan das Problem dass obwohl owx als IODEV eingetragen ist, owserver benutzt wird. Owx ist verfügbar und zeigt auch alle devices an. Es ist auch bei nicht allen Devices falsch, manche stimmen. Ich kann leider nicht sagen seit wann das nicht richtig funktioniert.

Gruß
Mario

[Medel]

Hallo,
soweit ich feststellen konnte wurde hier aufgrund einer Änderung (https://forum.fhem.de/index.php/topic,120603.0.html) etwas gemacht, so dass jetzt bei bestehenden Devices automatisch ein Reading angelegt wird dessen Wert dann immer statt des Attribut Wertes verwendet wird. Man kann jetzt durch erneutem Abspeichern des Attribut Wertes das Reading auf diesen Wert setzen. Ich verstehe nicht warum das jetzt irgend wie Automatisch erfolgen soll. Wenn ich doch als Benutzer sage dass ein bestimmtes IODEV verwendet werden soll dann sollte das auch so sein. Wenn ich keine Vorgaben mache muss es ja automatisch funktionieren. Mann muss so alles durch schauen ob auch, bei mehreren in frage kommenden IODEV , das richtige übernommen wurde.

Gruß
Mario

[rudolfkoenig]

so dass jetzt bei bestehenden Devices automatisch ein Reading angelegt wird dessen Wert dann immer statt des Attribut Wertes verwendet wird.

Das ist falsch.
Bei der automatischen IODev Zuweisung wird statt Attribut ein Reading gesetzt, das Attribut wird aber weiterhin beachtet, und beim Setzen des Attributes wird das Reading auch gesetzt.
Ich weiss zwar nicht, wie das Problem im Alltag auftauchen kann (und waere dankbar, wenn jemand mir das verraet), ich habe jetzt aber versucht weitere Bedingungen zu pruefen, so dass auch bei einer nachtraeglichen, manuellen, und unterschiedlichen Aenderung der fhem.cfg und/oder fhem.state Dateien das Attribut bestimmend ist.

[Medel]

Hallo,
ich habe am 13.05. ein Update gemacht, allerdings, glaube ich seit her nicht mehr die Seite mit den OWDevices angeschaut . Danach hatte ich bei einigen das IODEV das in dem Attribut steht, bei den meisten war aber das falsche eingetragen

Gruß
Mario

[Medel]

Hallo,

habe mal ein bisschen getestet, wenn ich das Reading IODev lösche und einen Neustart mache wird das falsche IODev neu als Reading angelegt und nach einem weiteren Neustart auch übernommen. Also müsste der Fehler mit dem  Update das ich 09.05. gemacht habe gekommen sein und sich mit dem Update am 13.05. dann ausgewirkt haben.

Gruß
Mario

[Medel]

Hallo,
habe gerade festgestellt dass nach dem testweisen löschen des IODev Readings eines Devices und 2 maligem Neustart wieder alle omx device auf das Owserver device geändert wurden.

Ergänzung: Es muss vorher kein IODev Reading gelöscht werden. Ein Neustart reicht aus um die IODev zu ändern. Werde mal das OWServer device deaktivieren damit ich nicht bei jedem Neustart die Konfiguration wieder zurecht biegen muss.

Gruß
Mario

[Medel]

Hallo,

deaktivieren des OWserver Devise geht nicht, wenn es fehlt bringen alle devices einen Fehler und werden nicht geladen. Fehler: no 1-Wire I/O device found

Habe eine andere Lösung gefunden:
Ich habe in der fhem.cfg die Definition des OWX vor die definition des OWServers kopiert jetzt wird dieses als erstes geladen. Ich vermute es hängt damit zusammen dass das OWX Device hinter den OW Devices in der Config stand.  Bei einem Device das dahinter war hat es nämlich immer funktioniert.

Gruß
Mario

[Medel]

Hallo,

hier eine Beispieldatei zum testen:
Dem Device vor der OWX definition wird immer OWServer zugewiesen, dem danach OWX. Ist also ein Reihenfolge Problem.

Gruß
Mario

[Prof. Dr. Peter Henning]

Es ist sonnenklar (und eigentlich schon immer so), dass die Interfaces (egal ob OWX oder OWServer) _vor_ der Definition der daran angeschlossenen 1-Wire-Devices vorhanden sein müssen.  Allerdings sollte die Reihenfolge der Interface-Definitionen definitv keine Rolle spielen, wenn die IODev-Attribute richtig gesetzt sind.

Ich habe derzeit noch kein Gefühl dafür, was durch die Änderung von Rudi jetzt passiert ist - und meine 5 Busmaster laufen alle noch problemlos.

LG

pah

[Beta-User]

Es ist sonnenklar (und eigentlich schon immer so), dass die Interfaces (egal ob OWX oder OWServer) _vor_ der Definition der daran angeschlossenen [...]

Da scheinen aber dann die 1Wire-Client-Module zwischenzeitlich die Ausnahme zu sein. Es gab vor ca. 3-4 Jahren eine größere Aktion, in der ziemlich viele zweistufige Module auf "reihenfolge-unabhängige" Initialisierung umgestellt wurden - soweit ich mich entsinne, hat Rudi  dazu eine InternalTimer-Lösung empfohlen, wenn man sonst keine NotifyFn benötigt (sonst kann man damit auf $init_done warten).
Müßte aber den Thread suchen, falls es von Interesse ist.

[Prof. Dr. Peter Henning]

Die Device-Module machen nichts von sich aus, insofern sollte es auch keinen Fehler geben. Das habe ich bei der damaligen Änderung auch überprüft.

Ändert aber nichts daran, dass meine Logik etwas anders ist.

Womit sich die Frage stellt, was beim TE denn nun schief geht? Möglicherweise hat er seine fhem.cfg nicht gespeichert.

LG

pah

[Medel]

Hallo,

habe mal eine Sicherung vom Dezember 20 angeschaut, auch da war das OWX device an der Position die es bis jetzt hatte (nach den meisten OW devices) und es lief richtig. ich glaube auch nicht wenn jemand es neu anlegt dass es davor eingereiht wird. Es wird dann einfach hinten angehängt. Die Konfig soll ja im Normalfall nicht von Hand geändert werden. Sollte also gehen.

Gruß
Mario

[rudolfkoenig]

hier eine Beispieldatei zum testen:

Danke, ich meine damit das Problem gesehen und gefixt zu haben. Bitte testen.

[Medel]

Hallo,

jetzt geht es. Danke

Gruß
Mario