FHEM 6.0 Release

[rudolfkoenig]

Ich wuerde etwa Anfang Januar die aktuelle Version als 6.0 veroeffentlichen.

Soweit ich sehe, ist ab featurelevel 6.0
- fhem.pl: Reading- und Attributnamen werden per goodReadingName() auf 64 Zeichen begrenzt.
- 93_DbRep: loescht ReadingNamen > 64
- 98_HTTPMOD: Voreinstellung fuer 5 Attribute wird geaendert
- 98_structure: propagateAttr ist per Voreinstellung leer, und nicht alles.

[DS_Starter]

93_DbRep: loescht ReadingNamen > 64

Schade, dass diese User entmündigende Zwangsmassnahme nicht verworfen wird. Niemand braucht das.
Leider macht ein Datenbankfrontend so keinen Sinn mehr, da die entstehenden Readings ja eine Kombination aus Timestamp, selektierten Device und selektierten Reading sind. Nur so kann man alle Rows aus der DB selektieren und auch anzeigen.
Ich hatte gedacht es hinreichend begründet zu haben.
Mit 128 könnte man wahrscheinlich gut leben. Aber so wird man wohl global featurelevel < 6 einstellen müssen wenn man umfassend damit arbeiten möchte.

Ich bin ehrlich enttäuscht. 

Trotzdem schöne Weihnachten.

Grüße,
Heiko

[rudolfkoenig]

Ich habe die Ausloeser-Diskussion gerade nochmal durchgelesen, und habe mitgenommen, dass etliche Entwickler eine einigermassen menschenlesbare Laenge fuer Attribut und Readingnamen wuenschen. Das DbLog Modul baut Readings, die als "ReadingName+Metadaten" aufgebaut sind, wenn das so bleibt, dann ist in FHEM keine Laengenbegrenzung moeglich.

ZWave generiert automatisch Namen fuer Konfigurationsbefehle aus der Textbeschreibung, begrenzt die Laenge auf 32 Zeichen, und fuegt zusaetzlich eine eindeutige ID hinzu. Waere sowas bei DbLog nicht denkbar?

[DS_Starter]

Danke dass du nochmal gelesen hast Rudi.
Zunächst mal kann ich versichern, dass ich selbst auch im eigenen Interesse stets bemüht bin ganz allgemein Readingnamen etc. kurz zu halten. Und an dem Ziel an sich ist auch nichts verwerfliches. Nur die Mittel dieses Ziel zu erreichen halte ich für fragwürdig. Es ist auch eine Frage des Investitions- bzw. Vertrauensschutzes generell und nicht nur auf das Modul bezogen um welches es gerade geht.

Es ist einfach so, will man eine Zeile aus der Datenbank eindeutig darstellen, braucht man die Infomationen aus dem Timestamp, dem Device und dem Reading welches den entsprechenden Wert enthält. Selbst das reicht noch nicht ganz, falls man mehrfach vorhandene, gleiche Daten darstellen und auswerten will. Wenn man jetzt beispielsweise jeden Bestandteil für sich soweit verkürzt dass in Summe die 64 Zeichen eingehalten würden, geht die Aussagekraft und Eindeutigkeit verloren.  Zum Beispiel die Readings EnergieMittag, EnergieAbend usw. eingekürzt auf die ersten 6 Zeichen ergibt in beiden Fällen nur Energie. Nur konstruiert, aber ich denke du weißt was ich meine.

Der Nutzer verarbeitet üblicherweise die Informationen aus den entstandenen Readings weiter. Er kann über das zusammengesetzte Reading die Informationen aus der DB genau extrahieren und nach seinen Bedürfnissen verwenden. Darüber hinaus ist er natürlich in der Lage, immer einen Blick in seine DB zu werfen und sieht genau wann welches Device/Reading welchen Wert (evtl. auch mehrfach) geschrieben hat.

Das ist quasi das Pendant zur Textanzeige eines Filelogs.
Niemand kommt doch nun plötzlich auf die Idee die Zeilenlänge eines Filelogeintrags zu begrenzen nur weil dieser nicht gut auf einem Smartphone zu lesen ist.

Das ist eigentlich alles. Das man nicht sämtliche Features und Möglichkeiten unbedingt auf einem kleinen Display eines Smartphones nutzen kann, liegt in der Natur der Sache. Dort würde wohl auch niemand ständig Logfile Inhalte lesen wollen behaupte ich.
Aber sollte nicht der Nutzer selbst darüber entscheiden können ? Ich meine ja. Er kann zum Beispiel jetzt schon im Modul mit einem Attr den Namen einkürzen. Nur ist es nicht in jedem Fall sinnvoll zu benutzen.

Wenn ich etwas mit vertretbarem Aufwand abändern kann ohne die Funktionalitäten einzuschränken mache ich das. Aber es muss rückwärtskompatibel sein. Das wäre im Hinblick auf Inverstitionsschutz der Anwender (Zeit) mein Anspruch.
In einem "normalen" Modul stellt sich diese Problematik auch nicht in diesem Umfang weil man dort ja relativ frei ist in der Wahl eines Namens. Aber hier ist es schon eine recht spezielle Anwendung.

Danke und VG,
Heiko

[Christoph Morrison]

Schade, dass diese User entmündigende Zwangsmassnahme nicht verworfen wird. Niemand braucht das.

Ich stimme dir hier absolut zu. Und außer "Ich muss nach rechts scrollen" und "Früher ist man auch mit viel weniger ausgekommen!" gibt es in dem verlinkten Thread von Februar keine "Argumente", die irgendeiner Notwendigkeit folgen - nichts als varchar-Sozialismus . Zumal in der eh unrepräsentativen Abstimmung 64 auch noch die niedrigste Anzahl an Stimmen bekommen hat 

DBLog nutzt bei mir durch die (Daten-)Bank weg z.B. varchar(255) für die Felder - warum auch nicht? Eine xTB-Platte kostet praktisch nichts, Speicher genauso wenig und am Ende habe ich lieber gut lesbare Reading- und Device-Namen (50 ist keine untypische Länge in meinem Setup) als irgendwelche kryptischen Abkürzungen. Es steht ja jedem frei beliebig kurze Namen für seine Devices/Readings zu verwenden und wer mit sowas wie w_t_f_0815 klar kommt, hat bestimmt auch eine keine Sorgen mit 50 Zeichen, selbst bei den chatty MQTT-Modulen oder DbRep nicht, aber es sollte eben jedem frei stehen und nicht in diesem Rahmen und ohne Notwendigkeit hart von FHEM begrenzt werden. Wenn irgendein Modul meint nur 50, 64 oder 5 Zeichen Feldlänge zu erlauben, dann soll es sich bitte auch selbst darum kümmern, dass es mit längeren Namen umgehen kann, z.B. in dem man sowas einfach nicht macht ...

Baut DOIF nicht auch ggf. lange Readingnamen, z.B. im Stil e_$device_$reading?

Alternativ freue mich über ein technisch nachvollziehbares Argument, das a) die Speicher/HDD-Situation 2019/2020 widerspiegelt und b) technisch nachvollziehbar (ich betone das absichtlich doppelt) ist und c) mehr Substanz hat als persönliche Befindlichkeiten wie "640 kB RAM reichen für alle", "Nur weil mein Bildschirm zu klein ist, müssen auch alle anderen mit kurzen Werten leben, weil ist ja egal das andere vielleicht 27"-Bildschirme haben, gar nicht auf die Readings schauen oder es ihnen einfach insgesamt egal ist/Readings gar nicht bewusst wahrnehmen (vermutlich ist letztere Gruppe übrigens die größte)" oder "Ist halt so". Was genau hindert die 50/64-Zeichen-Truppe in einem bspw. 255-Zeichen-Kontext eigentlich daran, kurze Bezeichner zu verwenden und auf Module wie DbRep und (für sie) nervige Features von MQTT zu verzichten?

Ansonsten plädiere ich dafür, dass jeder Name und jeder Wert mit MD5 gehasht wird. Dann sind wir immer bei (nahezu eindeutigen) 32 byte (nicht Zeichen, über Unicode haben wir uns nämlich auch noch nicht unterhalten) und wir müssen immer alle ganz doll viel "denken" (schließlich ist es nur gut, wenn es ordentlich auf den Zeiger geht und niemand darf Freude an einem System haben, das er nicht 100% versteht). Für die 50er- und 64er-Fraktion dürfte das sicher auch akzeptabel sein, naja, wäre da nicht noch DbRep und vllt. das Problem mit DOIF ...

Mit 128 könnte man wahrscheinlich gut leben. Aber so wird man wohl global featurelevel < 6 einstellen müssen wenn man umfassend damit arbeiten möchte.

Da bin ich auch bei dir, auch wenn diese Begrenzung ebenfalls völlig arbiträr ist. Wenigstens ist sie arbiträr und stört nicht. 127 wäre übrigens noch die bessere Wahl, in den meisten DBMS sind das C-Zeichenketten, die noch mit einem Null-Byte terminiert werden. 127+1 passt dann genauso gut in den Speicher wie 63+1 oder eben das allseits beliebte 255+1 (alles Potenzen von 8 ).

(Immerhin ist mir nun mal DbRep ins Bewusstsein gerückt, da hat sich die Aufregung ja schon gelohnt.)

[rudolfkoenig]

Es ist einfach so, will man eine Zeile aus der Datenbank eindeutig darstellen, braucht man die Infomationen aus dem Timestamp, dem Device und dem Reading welches den entsprechenden Wert enthält.

Ich fuerchte ich verstehe immer noch nicht die Motivation, solche Informationen im Namen, und nicht im Wert zu kodieren.

Der Nutzer verarbeitet üblicherweise die Informationen aus den entstandenen Readings weiter.

Koenntest Du mir bitte dafuer einen konkreten Fall nennen?
Und einen Fall, wo das nachtraegliche Kuerzen/Verwerfen von so einem Reading zu einem Problem fuehrt?

Aber sollte nicht der Nutzer selbst darüber entscheiden können ?

Ich sehe das anders: wenn das Framework keine Vorgaben macht, was man als sinnvoll erachtet, dann bemuehen sich manche Modulentwickler auch nicht, und der Benutzer hat am Ende keine Moeglichkeit die Laenge der Bezeichner sinnvoll zu verkuerzen. Ich bin ja nicht mal unbedingt fuer eine Begrenzung der Laenge, aber ich verstehe die Argumente der Befuerworter, und Eure nicht. Es geht ja nicht darum, dass man keinen Platz hat, sondern dass man Informationen da kodiert, wo sie hingehoeren.  Nach meinen aktuellen Stand ist genau dieser Fall eine valide Begruendung der Massnahme.

nichts als varchar-Sozialismus

Bitte solche Kommentare sparen, sie sind kontraproduktiv.

[CoolTux]

Heiko, wenn ich Dich richtig verstehe geht es Dir darum daß Du den Inhalt der DB wieder vernünftig in FHEM darstellen kannst. Un zwar in einem Device. Dabei willst Du als Reading Devicename + Readingname und als Value des Readings dann den Wert von Devicename + Readingname. Ist das so richtig?

Damit kann der User dann also aus der DB Werte rauslesen die er sucht. Ein select also. Aber warum soll er dieses Suchergebnis als Reading bekommen? Geht nicht auch ein HTML Darstellung für den Moment?



Grüße

[KernSani]

Hallo zusammen,
ich habe die Diskussion jetzt nicht komplett verfolgt, aber kurz zusammengefasst sprechen für eine Beschränkung:
* Scrollvermeidung
* Lesbarkeit (wer kann 64 Zeichen lange readings noch unterscheiden?)
Dagegen sprechen:
* Mögliche Einschränkungen beim Anwendungsdesign
* Lesbarkeit (wenn mein Reading auf 64 Zeichen gekürzt wird bringe ich nicht mehr alle Informationen unter)
Grundsätzlich gibt es sicher wichtigere Themen, als dieses. Daher würde ich einen pragmatischen Weg vorschlagen um beide Fraktionen zufrieden zu stellen:
* Länge wird technisch nicht beschränkt
* Über globales Attribut, ggf. pro Modul übersteuerbar kann der User die Ausgabelänge beschränken
Meine 5ct.

Frohes Fest,

Oli


Gesendet von iPhone mit Tapatalk

[DS_Starter]

Ich fuerchte ich verstehe immer noch nicht die Motivation, solche Informationen im Namen, und nicht im Wert zu kodieren.

Das macht doch für eine Darstellung keinen Unterschied.

Eine Filelogzeile stellt sich so dar:

2019-10-23_19:20:13 HM_571DB3 R-pairCentral: 0x322327

Eine Datenbankzeile über DbRep Frontend entspechend:

2019-12-20_23-42-10__1__571DB3__R-pairCentral   0x322327

Hinten dran kommt noch die Zeit der Readingsänderung. Aber wo ist der generelle Unterschied wenn man beides über die FHEM-Möglichkeiten ansehen möchte ?  Dann müsstest du ja konsequenterweise auch die Zeilenlänge eines Filelogeintrags begrenzen, oder nicht ?
Nur weil das eine "Reading" heißt, ist für mich keine Begründung.

Einen konkreten Anwendungsfall findet man gerade aktuell hier:
https://forum.fhem.de/index.php/topic,105787.msg1003234.html#msg1003234

Gibt im Forum sicher noch mehr.

Und hier noch ein Beispiel für eine Kürzung. Der normale Output sieht zum Besipiel so aus:

2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung_WirkP_Verguet_Diff 0.0000
2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung_WirkP_Zaehler_Diff 0
2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung_Wirkleistung 0.0 W
2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler 15184.1681 kWh
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung_WirkP_Verguet_Diff 0.0000
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung_WirkP_Zaehler_Diff 0
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung_Wirkleistung 0.0 W
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler 15184.1681 kWh

Würde man kürzen, käme evtl. so etwas raus:

2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung 0.0000
2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung 0
2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung 0.0 W
2019-12-19_23-40-18__1__SMA_Energymeter__Einspeisung 15184.1681 kWh
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung 0.0000
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung 0
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung 0.0 W
2019-12-19_23-41-19__1__SMA_Energymeter__Einspeisung 15184.1681 kWh

Nicht wirklich hilfreich.

Ich möchte aber auch garnicht weiter diskutieren.

Ein wenig merkwürdig finde ich die generelle Verfahrensweise. Es werden haarkleine Begründungen und Nachweise verlangt um etwas _nicht_ zu tun. Im Umkehrschluss bleibt aber die gleiche Hartnäckigkeit der Beweislast auf Seiten der Befürworter einer solchen Massnahme aus.

Sorry, bei mir entwickelt sich da so ein mulmiges Bauchgefühl. In Süddeutschland würde man wohl sagen, das Ganze hat ein "Gschmäckle".

@Cooltux:

Dabei willst Du als Reading Devicename + Readingname und als Value des Readings dann den Wert von Devicename + Readingname. Ist das so richtig?

Nicht ganz. Der Value ist nur der Wert des Datensatzes, also nur der Inhalt des DB-Feldes VALUE. Obiges Beispiel zeigt das.

Aber warum soll er dieses Suchergebnis als Reading bekommen?

Weil es auswertbar sein soll, das ist der Sinn des Ganzen. Du kennst doch auch zum Beispiel die userExitFn die ich dir letztens bei einem Einsatzfall gezeigt habe und die du so cool fandest ?
Nur um ein Beispiel zu nennen.

@Kersani

Über globales Attribut, ggf. pro Modul übersteuerbar kann der User die Ausgabelänge beschränken

Dem kann ich nur zustimmen, wobei es bereits jetzt im diskutierten Fall ein solches Attribut gibt falls der User eine Verkürzung wünscht und es sinnvoll verwendet werden kann.

LG,
Heiko

[CoolTux]

OK ich denke ich verstehe es.
Ich würde der Idee von Oli zustimmen. Ob man das Attribut nun unbedingt global ansetzen muss oder ob es nicht doch reicht es im Modul ein zu richten und FHEM wertet es aus, kann man ja noch klären.


Grüße

[DS_Starter]

Ich möchte euch allen eine schöne Weihnachtszeit wünschen !
Wir starten jetzt in ein paar freie Tage, werde mich erstmal aus FHEM etwas ausklinken.

Also bleibt alle gesund und genießt die freie Zeit mit euren Angehörigen und Freunden !

Grüße,
Heiko

[justme1968]

so etwas über ein attribut konfigurierbar zu machen ist keine gute idee. es führt vielen leicht unterschiedlichen systemen mite etwas unterschiedlichem verhalten und potentiell viel mehr möglichkeit für probleme.

und es zeigt nur das man sich vor einer entscheidung drückt und am ende alles erlaubt um es jedem recht zu machen.

dann lieber gleich richtig und keine einschränkung. d.h. alle zeichen in beliebiger länge. egal was es für nebenwirkungen hat.

eine db ist dafür da daten zu organisieren. das würde für mich bedeuten device, reading, wert, ... auseinander zu nehmen und in in unterschiedliche felder zu stecken. nicht alles zusammen in ein beliebig großes. erst eine solche organisation erlaub es dir daten auch wirklich auzuwerten. wie soll man denn auf ein solches feld ein select los lassen wenn da device und reading name drin stecken.

die diskussion schaut inzwischen etwas verfahren aus und ein schritt zurück wäre angebracht.

vielleicht ist reading schlicht und einfach nicht die richtige abstraktion und darstellung für dbrep? dazu kann ich nichts sagen. aber man sollte die möglichkeit nicht aus dem auge verlieren.

für den ,normalen' anwendungsfall eines readings (das benennen eines gemessen wertes) ist die beschränkung auf 64 zeichen ganz sicher kein problem da die organisation dieser werte über device, room, group, ... erfolgt und nicht über den reading namen.

[KernSani]

so etwas über ein attribut konfigurierbar zu machen ist keine gute idee. es führt vielen leicht unterschiedlichen systemen mite etwas unterschiedlichem verhalten und potentiell viel mehr möglichkeit für probleme.

und es zeigt nur das man sich vor einer entscheidung drückt und am ende alles erlaubt um es jedem recht zu machen.

dann lieber gleich richtig und keine einschränkung. d.h. alle zeichen in beliebiger länge. egal was es für nebenwirkungen hat.

Der Vorschlag war, ausschließlich die Ausgabelänge konfigurierbar zu machen, das sollte m. E. nicht zu Problemen führen. Wahrscheinlich wäre ein globales Attribut tatsächlich keine gute Idee, aber in FHEMWEB könnte es Sinn machen...



Gesendet von iPhone mit Tapatalk

[justme1968]

die beschränkung der ausgabe länge führt doch genau zu den problem das nicht eindeutige namen angezeigt werden wenn derjenige der sich die langen namen ausdenkt nicht weiss auf welche länge der anwender sein frontend eingestellt hat. das ist genau die art von 'fix' die dann irgendwann probleme macht weil keiner mehr daran denkt das irgendwo etwas eingestellt wurde.

gab es eigentlich schon ein beispiel für einen tatsächlich vorkommenden reading namen der mehr als 64 zeichen hat und direkt einem anwender im frontend so angezeigt werden soll?

ich meine nicht die 'künstlichen' dbrep readings die besser in ihre komponenten aufgeteilt werden sollten.

[Christoph Morrison]

vielleicht ist reading schlicht und einfach nicht die richtige abstraktion und darstellung für dbrep? dazu kann ich nichts sagen. aber man sollte die möglichkeit nicht aus dem auge verlieren.

Ich erinnere noch mal daran, dass wir diese Diskussion (vor allem) deshalb führen weil einer der Meinung ist, dass lange Attributnamen (wie sie z.B. eines der MQTT-Module verwendet) die Leute vom Denken abhalten, ein paar andere sich vor allem daran stören, dass sie zu weit scrollen müssen und ein paar "weil halt".

Ich warte nach wie vor auf ein logisch schlüssiges Argument technischer Notwendigkeit.

für den ,normalen' anwendungsfall eines readings (das benennen eines gemessen wertes) ist die beschränkung auf 64 zeichen ganz sicher kein problem da die organisation dieser werte über device, room, group, ... erfolgt und nicht über den reading namen.

Inwiefern sind die Werte, die DbRep ausspuckt, keine "normalen" Readings (Repräsentation von Daten einer Quelle, wie z.B. bei ... lass mich überlegen ... jedem anderen Modul in FHEM)? Und ich kann auch gerne hier noch mal anmerken: Ich habe Readings, die von DOIF automatisch erzeugt werden, die bereits jetzt länger als 64 Zeichen sind - was bisher auch völlig problemlos war und ich nicht sehe, warum das nun nicht mehr gehen soll, insbesondere in Anbetracht der Nicht-Argumente der Befürworter einer sehr knappen Beschränkung.

Bitte solche Kommentare sparen, sie sind kontraproduktiv.

Nein, sie sind genau angemessen und man muss gegen solche nutzlosen Einschränkungen argumentieren wo es nur geht, insbesondere da es ein bestehendens Verhalten nachträglich ändert (ohne Not, nochmal). Und tut mir leid, aber ich sehe nirgendwo in FHEM Integrationstests, die mir die Zuversicht geben würden, dass es hier nicht zu Problemen in Bestandsinstallationen kommt.

Und nota bene, ich stelle das gesamte Konzept der "Releases" in FHEM in Frage, so lange bis es a) entweder wirklich Releases gibt, die jemand inhaltlich betreut, die einer Roadmap folgen und die dann auch nur mit größeren zeitlichen Abständen kommen (wie üblich mit Ausnahme von Bugfixes) und b) auch nur den Kern von FHEM beinhalten und nicht noch alle Module mit revisionieren. Loredo hat mit dem Installer übrigens bereits tolle Vorarbeit geleistet die aktuell leider ziemlich brach liegt und ich würde mich freuen, lieber dort mehr Unterstützung hingehen zu sehen als in sowas hier.