HM-OU-LED16 nicht mehr direkt setzbar.

ckmde · 06 September 2020, 19:32:05

Hallo,

ich (bzw. meine Frau

) habe vorhin bemerkt, dass meine HM-OU-LED16 nach einem Update von FHEM nicht mehr angesteuert werden.
Im Log wird folgendes ausgeworfen.
===
2020.09.06 18:21:50.237 3: set Anzeige.Windfang,Anzeige.Flur_Bad led 5AA5AAFD : param 0:((off|red|green|orange)) => 5AA5AAFD does not match options
led: (off|red|green|orange)
param 0:((off|red|green|orange)) => 5AA5AAFD does not match options
led: (off|red|green|orange)
===
Ich steuere die Displays schon seit Jahren direkt über die Hexwerte für alle LED's direkt am Device an, da sich oft diverse Zustände zeitnah ändern und somit ein Haufen Airtraffic gespart wird. Ein bisschen Suche hat ergeben, dass das seit Rev. 22648 der 10_CUL_HM.pm nicht mehr geht. set <DEVICE> led HEXWERT bringt jetzt den Fehler oben. Da ich in der Diff zur 22648 nichts gefunden habe was auf Anhieb direkt mit dem OU-LED16 zu tun hat vermute ich einen (nicht gewollten) Seiteneffekt, da das direkt setzen aller LED's ja absolut sinnvoll ist.
Wäre schön wenn sich das mal jemand (martinp876 ? ) anschauen könnte.

Danke und Gruß
Carsten

ckmde · 07 September 2020, 21:51:15

Hallo,

ich habe noch ein bisschen geforscht.
Ab Rev. 22648 ist die Prüfung der Command Parameter erheblich geändert. Da kommt jetzt der Fehler. Ich habe jetzt mal in der HMConfig.pm die Parameterdefinition geändert und einen Text zugelassen. Dann geht es wieder. Allerdings fällt dadurch die Listcombobox zur Auswahl weg und man kann nur den Text direkt oder Hex eingeben. Ist also suboptimal. Ich habe noch nicht rausgefunden, wie man eine Combobox mit Eingabemöglichkeit erzeugen kann.
Hier die Diff der HMConfig.pm von mir.
1826c1826
< ,"HM-OU-LED16" =>{ led =>"(off|red|green|orange)"
---
> ,"HM-OU-LED16" =>{ led =>"((off|red|green|orange)|-text-)"

Text ist an der Stelle ok, da später im Code bei der Ausführung eines Commands sowie nochmal geprüft wird ob eine der Farben oder ein Hexstring gesendet werden und zwar Abhängig ob das Gerät oder ein Kanal angesteuert werden.
Kann mir eventuell jemand sagen wie man eine Combobox mit Eingabemöglichkeit erzeugt oder z.B. bei Auswahl eines leeren Eintrags ein Eingabefeld erzeugt welches dann als Parameter mitgesendet wird ?

Gruß
Carsten

ckmde · 12 September 2020, 14:25:42

Hallo,

Zitat von: ckmde am 07 September 2020, 21:51:15
Kann mir eventuell jemand sagen wie man eine Combobox mit Eingabemöglichkeit erzeugt oder z.B. bei Auswahl eines leeren Eintrags ein Eingabefeld erzeugt welches dann als Parameter mitgesendet wird ?

Kennt wirklich keiner eine Möglichkeit eine Combobox mit Eingabefeld zu erzeugen ?

Gruß
Carsten

amenomade · 13 September 2020, 01:22:03

Meines Wissens nach, gibt es kein passendes Widget. Siehe: https://fhem.de/commandref_DE.html#widgetOverride

ckmde · 14 Juni 2021, 22:05:29

Ich wollte mal fragen ob der Fehler mit der nicht funktionierenden HEX Maske gefixt werden kann ? Ich habe eben im Repository nachgesehen und der Fehler scheint noch immer da zu sein. Ich habe seit bald einem Jahr kein Update mehr eingespielt, da Homematic seit dem kaputt ist. Und jedes mal nach einem Update einzelne Dateien zurückzuspielen ist zu nervig.
Gibt es eigentlich eine Liste aller offenen Bug insgesamt bzw. der einzelnen Module wie Homematic ?
Wie behält ein Modul Maintainer den Überblick was womöglich an Fehlern vorhanden ist ?
Muß ich einen Bug ggf. so oft nach oben puschen bis der mal wahrgenommen wird ?

connormcl · 15 Juni 2021, 02:21:28

Zitat von: ckmde am 14 Juni 2021, 22:05:29
Ich wollte mal fragen ob der Fehler mit der nicht funktionierenden HEX Maske gefixt werden kann ? Ich habe eben im Repository nachgesehen und der Fehler scheint noch immer da zu sein. Ich habe seit bald einem Jahr kein Update mehr eingespielt, da Homematic seit dem kaputt ist. Und jedes mal nach einem Update einzelne Dateien zurückzuspielen ist zu nervig.
Gibt es eigentlich eine Liste aller offenen Bug insgesamt bzw. der einzelnen Module wie Homematic ?
Wie behält ein Modul Maintainer den Überblick was womöglich an Fehlern vorhanden ist ?
Muß ich einen Bug ggf. so oft nach oben puschen bis der mal wahrgenommen wird ?

Gutes Thema, dass mich auch schon lange umtreibt und weshalb ich auch seit ca. 2,5 Jahren kein FHEM update gefahren habe.

Bei mir ist es der nicht enden wollende Umbau im Bereich HMCCU mit der Umstellung des RPC Servers. Ich benutze eine Uralt-Version mit integriertem RPC-Server, wo die Dinge, die ich benötige alle einwandfrei laufen.

Bei der neuen Version der HMCCU lese ich natürlich mit. Gefühlt bekommt die aber monatlich Updates wo sich dann herausstellt, dass dies oder das nicht funktioniert. Dann wieder Update und gleiches Spiel. Ich habe somit noch keinen für mich "guten" Zeitpunkt gefunden, das Update zu fahren, weil ich für den Live-Betrieb natürlich ein stabiles und funktionierendes System benötige.

Das ist jetzt keine Kritik am Entwicklungsprozess an sich, da wir ja alle wollen, dass FHEM umfangreicher, stabieler, schneller, besser wird und nicht veraltet.

Nur könnte der Prozess der Entwicklung oder vielmehr der Updates trotzdem besser und transparenter gestaltet werden -wie bei anderen grossen Projekten auch - durch eine Aufteilung in Stable- und Development Releases.

Die Stable-Releases dürfen nach Möglichkeit keine bekannten Bugs haben und die Rahmenbedingungen des Einsatzes sollten klar umrissen sein.
Die Development würde dann einen Entwicklungsstand spiegeln, mit einer Liste der Weiterentwicklungen und bekannten Bugs dazu.
Tagesaktuell könnte man dann wie bisher direkt aus dem SVN updaten, was aber meiner Erfahrung nach "unstable" ist.

Ein normaler Benutzer sollte nie Development oder SVN Updates beziehen können, sondern nur von Stable zu Stable-Release springen können. Sonst ist man ständig mit der Prozedur Update->Test->Rollback bzw. warten auf nächstes Update beschäftigt, was sinnvollerweise nur einem Test bzw. Entwicklungsumgebung möglich ist, wenn man eine täglich funktionierende Hausautomatisierung benötigt.

In der Not habe ich genau das getan, was wahrscheinlich kaum jemand macht: weitere Rasperry Pis beschafft, als FHEM Server und CCU aufgesetzt, dazu weitere IOs wie nanoCUL/RFXCOM/JeeLinks um eine Testumgebung zu haben, wenn ich Betriebsysteme und FHEM aktualisieren muss.
Trotzdem komme ich nicht recht voran, da alles ein Moving-Target ist und wenn ich dann wegen eines gelösten Problems an einer Stelle ein Update fahre, fange ich mir potentiell Probleme an einer anderen Stelle ein, wo auch gerade entwickelt wird...

ckmde · 27 Juni 2021, 19:21:13

Hmmm, leider weiter keine Antwort wegen des Fehlers und wann der gefixt wird. Also wieder nach oben pushen, bevor der Thread wieder auf der zweiten Seite landet.

ckmde · 11 Juli 2021, 13:16:58

Hmmm, leider weiter keine Antwort wegen des Fehlers und wann der gefixt wird. Also wieder nach oben pushen, bevor der Thread wieder auf der zweiten Seite landet. Was muß ich tun das der Bug beseitigt wird ? Kopfstehen oder mit dem Sch... wackeln ?

connormcl · 12 Juli 2021, 00:27:01

Ich bin nur ein FHEM-Benutzer, aber auf jeden Fall finde ich ein halbes Jahr ausbleibende Reaktionen auf solch einen Bug bedenklich. Ob jetzt berechtigt oder nicht, aber eine Analyse hätte ich mir zumindest erhofft.

Bleibt eigentlich nur, dass du mal den Entwickler des Moduls auf den Thread hier direkt hinweist?

Pfriemler · 13 Juli 2021, 20:29:43

Zitat von: connormcl am 12 Juli 2021, 00:27:01
Ich bin nur ein FHEM-Benutzer, aber auf jeden Fall finde ich ein halbes Jahr ausbleibende Reaktionen auf solch einen Bug bedenklich. Ob jetzt berechtigt oder nicht, aber eine Analyse hätte ich mir zumindest erhofft.

Bleibt eigentlich nur, dass du mal den Entwickler des Moduls auf den Thread hier direkt hinweist?

Das ist immer sinnvoll, freundlich und bestimmt. FHEM ist für alle ein Freizeitprojekt.

Achja ... im letzten Jahr gab es erhebliche strukturelle Änderungen in CUL_HM hinter den Kulissen, Martin kann auch offenbar nicht mehr 100% Support leisten, und vieles rutscht einfach aus dem Fokus. Generell gab es so viele Änderungen, Bugs und Bugfixes, dass ich seit Monaten keine Updates mehr gefahren habe aus der (berechtigten) Angst ein laufendes System (temporär) K.O. zu schlagen.

Dazu kommt, dass vielleicht viele Leute dieses Display gar nicht besitzen und insofern der Fehler niemandem dringlich erscheint. Ich könnte mal ein altes Display rausgrabbeln und ein bisschen spielen und versuchen das Problem nachzustellen, vielleicht hakt es ja schon daran ...

martinp876 · 17 Juli 2021, 10:42:28

korrigiert (hoffe ich). Ich habe das Device nicht und kann also auch nciht testen.

- sorry für den Bug - ist durchgerutscht
- sorry für die späte Reaktion - habe es nicht gesehen.

Mein support ist langsamer - liegt auch daran, dass die meisten Themen sich hier auf HMCCU oder allgemeine Themen beziehen.

Ich hoffe, fhem ist dennoch den Preis wert, den die Anwender bezahlen.
Wie stehe ich im Vergleich der Reaktionszeit zu konstenprlichtigen Systemen? Bekommt man da einen Update in 1 Monat? Du hast sicher ein service agreement mit zugesicherten Reaktionszeiten.

Dennoch - sorry für den Bug.

P.S.: das HMConfig muss upgedatet werden. CUL_HM update nicht erforderlich.

connormcl · 10 August 2021, 23:05:59

Zitat von: martinp876 am 17 Juli 2021, 10:42:28
korrigiert (hoffe ich). Ich habe das Device nicht und kann also auch nciht testen.

- sorry für den Bug - ist durchgerutscht
- sorry für die späte Reaktion - habe es nicht gesehen.

Entschuldigung, falls ich oben zu harsch oder fordernd formuliert habe. Zumindest ist der Thread noch nicht mit Beleidigungen oder ähnlichem explodiert, also soweit alles gut, denke ich...

Mir fällt nur zunehmend auf, dass auch erfahrene FHEM Benutzer wegen der andiskutierten Problematik ihr FHEM nicht mehr updaten, wenn es einmal läuft, weil das Risiko von Fehlern und Downtime zu gross ist. Ich habe das einige Zeit mit einer zweiten umfangreichen Testumgebung abgefahren, bis mir der Aufwand zu hoch wurde und update seitdem auch nicht mehr, solange ich nicht zwingend neue Features benötige. Aber so kann das ja nicht Sinn und Zweck sein.

LuckyDay · 11 August 2021, 22:49:49

Das mit "FHEM nicht mehr updaten" , Nein Ich bin relativ aktuell, allerdings das neuste Update von CUL_HM von letzten Sonntag tue ich mir noch nicht an, dazu brauche ich Zeit zum Testen

frank · 12 August 2021, 09:26:47

ZitatMir fällt nur zunehmend auf, dass auch erfahrene FHEM Benutzer wegen der andiskutierten Problematik ihr FHEM nicht mehr updaten, wenn es einmal läuft, weil das Risiko von Fehlern und Downtime zu gross ist. Ich habe das einige Zeit mit einer zweiten umfangreichen Testumgebung abgefahren, bis mir der Aufwand zu hoch wurde und update seitdem auch nicht mehr, solange ich nicht zwingend neue Features benötige. Aber so kann das ja nicht Sinn und Zweck sein.

wer soll den "aufwand" für dich übernehmen?
wenn keiner testet, werden die bugs auch nicht entdeckt.

martinp876 · 14 August 2021, 11:23:57

Ich habe keine Beleidigung gesehen - also alles gut.
Ich war langsam - sorry.
Ich hoffe, es funktioniert jetzt.

FHEM entwickelt sich weiter - es gibt keine Test-bench. Ich teste, was ich habe. Ich habe aber begrenzete Zeit, die Vielfallt ist erheblich und ich habe nicht alle devices.

In der Tat gab es in letzter Zeit ein paar doch grundlegendere Updates intern - welche den Code wartbarer machen, die User-Anzeigen (hoffentlich) besser und die Ausführung streamlinen. Das sind
- Entity-spezifische Attribute
- Attribut Beschreibung Kontext abhängig
- standard Attribut-parsing
- Standard- command parsing
- Command list Anzeige im Frontend
- Peer handling standartisierung
- IO Zuweisung - Anpassung an Rudis Änderung und die Attribut-standards

Professionell gäbe das eine Test-version welche von mehreren Personen durchgetestet wird - auch halbautomatisch.

Sei versichert, dass alles meine Versuche "live" in meinem System sind. Ich leiste mir kein separates Test-system. Alle was ich den Usern zumute läuft bei mir live - bevor ich es abgebe.

Nichts für ungut - eine fhem-test-bench wäre nicht schlecht.