Die Funktion AssignIOPort für die Zuweisung eines I/O Device hat eine Eigenart, der man sich bei der Verwendung bewusst sein muss. Vor der Zuweisung eines I/O Device wird nämlich per IsDisabled geprüft, ob das designierte I/O Device enabled ist. Leider gilt ein Device auch als disabled, wenn das Reading state oder das Internal STATE auf "inactive" steht. Die betroffenen Devices werden daher von AssignIOPort nicht akzeptiert.
Wenn man das als Entwickler weiß, kann man dem entgegenwirken und einfach niemals state auf inactive setzen. Jeder Nutzer hat jedoch die Möglichkeit, per Attribut stateFormat das Reading state nach eigenen Wünschen zu gestalten. Im konkreten Fall (HMCCU) hat das nun dazubgeführt, dass kein IO Device zugewiesen werden konnte.
Warum wird bei IsDisabled auf state = inactive geprüft? Da man Modifikationen per stateFormat durch den Nutzer nicht ausschließen kann, habe ich mir nun erstmal so beholfen, dass ich AssignIOPort nicht mehr verwende sondern das I/O Device direkt setze. Das wird aber zu Problemen führen, sobald sich irgendetwas an der Client/Master Device Systrmatik in FHEM ändert. Dann muss ich wieder nachbessern. Alles relativ unschön.
Ich habe es so verstanden: Du findest es falsch, dass ein IODevice vom Framework gemieden wird, wenn der Benutzer es auf inactive gesetzt hat. Warum?
Sagen wir mal so: ich finde es richtig, dass ein Device ignoriert wird, wenn der Benutzer das Attribut disable auf 1 gesetzt hat.
Im konkreten Fall hat der Benutzer das Device nicht absichtlich auf inactive gesetzt. Er hat lediglich das Attribut stateFormat auf ein Reading gesetzt, das zufällig und in völlig anderem Zusammenhang den Wert "inactive" angenommen hat.
Konkret bedeutet das: Wenn ein Reading eines I/O Device irgendwann mal den Wert inactive annehmen kann, darf es niemals in stateFormat verwendet werden, es sei denn, es ist gewollt, dass dieser Fall zur Deaktivierung des Devices führt.
Das aber ist für einen Anwender schwer durchschaubar. Denn woher soll er wissen, ob irgendein angebundenes Gerät nicht zufällig mal inactive liefert.
Ich habe in AssignIoPort die Pruefung auf IsDisabled($propsed) != 1 geaendert.
Damit wird nur auf das "disabled" Attribut reagiert, aber nicht mehr auf inactive im STATE oder auf disabledForIntervals
Zitat von: rudolfkoenig am 19 Juli 2018, 15:13:51
Damit wird nur auf das "disabled" Attribut reagiert, aber nicht mehr auf inactive im STATE oder auf disabledForIntervals
Vielleicht habe ich ja wieder zu wenig geschlafen, aber wenn ein Benutzer ein device nicht mittels Attribut deaktiviert, sondern mittels "set <device> inactive" wird doch das Attribut überhaupt nicht angetastet? Das heißt, im Attribut ist nicht erkennbar, dass das device "disabled" ist, sondern nur in seinen readings.
ZitatDas heißt, im Attribut ist nicht erkennbar, dass das device "disabled" ist, sondern nur in seinen readings.
Stimmt, aber ich meine, in diesem Fall (AssignIoPort) ist das egal. Wenn man ein "physikalisches" Geraet (wie CUL) nicht verwenden will, dann bitte mit Attribut deaktivieren, und nicht mit "set XX inactive". Ich kenne keine Module fuer solche Geraete, die "set XX inactive" unterstuetzen.
Zitat von: rudolfkoenig am 19 Juli 2018, 18:19:54
Ich kenne keine Module fuer solche Geraete, die "set XX inactive" unterstuetzen.
Stimmt - für heute. Aber was morgen ist - wer weiß das schon. Es werden bei der Entwicklung von Modulen ja sehr oft irgendwelche Codeschnipsel aus anderen Modulen zusammengeklaut, und irgendwann wird garantiert auch jemand das disable über set anstatt attr in ein Kommunikationsmodul einbauen. (Murphy's Law)
Zitat von: rudolfkoenig am 19 Juli 2018, 15:13:51
Ich habe in AssignIoPort die Pruefung auf IsDisabled($propsed) != 1 geaendert.
Damit wird nur auf das "disabled" Attribut reagiert, aber nicht mehr auf inactive im STATE oder auf disabledForIntervals
Vielen Dank! Im Wiki zur Development Api stand es eh schon so drin.
Kann es sein, dass die vorgenommene Änderung zu sehr unschönen Effekten führt?
https://forum.fhem.de/index.php/topic,89504.0.html
https://forum.fhem.de/index.php/topic,89495.0.html
Danke fuer den Hinweis, da war mindestens ein Denkfehler dabei, war vermutlich auch nicht ausgeschlafen. :(
Habs geaendert und eingecheckt.