FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: rudolfkoenig am 20 Dezember 2019, 18:06:35

Titel: FHEM 6.0 Release
Beitrag von: rudolfkoenig am 20 Dezember 2019, 18:06:35
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.
Titel: Antw:FHEM 6.0 Release
Beitrag von: DS_Starter am 20 Dezember 2019, 20:05:29
Zitat
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
Titel: Antw:FHEM 6.0 Release
Beitrag von: rudolfkoenig am 20 Dezember 2019, 21:52:28
Ich habe die Ausloeser-Diskussion (https://forum.fhem.de/index.php/topic,97493.25.html) 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?
Titel: Antw:FHEM 6.0 Release
Beitrag von: DS_Starter am 20 Dezember 2019, 22:46:51
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



Titel: Antw:FHEM 6.0 Release
Beitrag von: Christoph Morrison am 20 Dezember 2019, 23:42:47
Zitat von: DS_Starter am 20 Dezember 2019, 20:05:29
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 ...

ZitatMit 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.)
Titel: Antw:FHEM 6.0 Release
Beitrag von: rudolfkoenig am 21 Dezember 2019, 09:06:44
ZitatEs 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.

ZitatDer 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?

ZitatAber 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.

Zitatnichts als varchar-Sozialismus
Bitte solche Kommentare sparen, sie sind kontraproduktiv.
Titel: Antw:FHEM 6.0 Release
Beitrag von: CoolTux am 21 Dezember 2019, 09:37:06
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
Titel: Antw:FHEM 6.0 Release
Beitrag von: KernSani am 21 Dezember 2019, 09:51:21
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
Titel: Antw:FHEM 6.0 Release
Beitrag von: DS_Starter am 21 Dezember 2019, 09:56:46
ZitatIch 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:
Zitat
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.

Zitat
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
Zitat
Ü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
Titel: Antw:FHEM 6.0 Release
Beitrag von: CoolTux am 21 Dezember 2019, 10:19:43
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
Titel: Antw:FHEM 6.0 Release
Beitrag von: DS_Starter am 21 Dezember 2019, 10:45:54
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
Titel: Antw:FHEM 6.0 Release
Beitrag von: justme1968 am 21 Dezember 2019, 12:47:45
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.
Titel: Antw:FHEM 6.0 Release
Beitrag von: KernSani am 21 Dezember 2019, 13:03:39
Zitat von: justme1968 am 21 Dezember 2019, 12:47:45
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
Titel: Antw:FHEM 6.0 Release
Beitrag von: justme1968 am 21 Dezember 2019, 13:12:17
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.
Titel: Antw:FHEM 6.0 Release
Beitrag von: Christoph Morrison am 21 Dezember 2019, 13:45:49
Zitat von: justme1968 am 21 Dezember 2019, 12:47:45
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.

Zitat von: justme1968 am 21 Dezember 2019, 12:47:45
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.

Zitat von: rudolfkoenig am 21 Dezember 2019, 09:06:44
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.
Titel: Antw:FHEM 6.0 Release
Beitrag von: KölnSolar am 21 Dezember 2019, 15:25:34
Ich nutze weder DBLog noch DOIF(deshalb kann ich die Aussage zur "automatischen Generierung von Readings bei DOIF" auch nicht interpretieren). Das nur zur Info.

ZitatIch warte nach wie vor auf ein logisch schlüssiges Argument technischer Notwendigkeit.
Die Antwort ergibt sich meines Erachtens doch schon sehr allgemein. Kurz ist doch generell besser als lang(übersichtlich, nachvollziehbar, schneller zu lesen/schreiben ....)
Es verbraucht auch nun mal alles Ressourcen, also Rechenzeit, Speicherplatz.

Da finde ich es schon sinnvoll Beschränkungen zu machen. Umgekehrt soll natürlich alles offen und flexibel sein. Ist für mich also mehr die Diskussion wie groß die Beschränkung sein sollte.

Ich frage mich, welchen Sinn die Länge im folgenden Reading-Beispiel hat(ganz abgesehen von den Punkten  ::)) Ist es da nicht sinnvoll eine Beschränkung zu machen, damit Modulentwickler das berücksichtigen und eben erst gar nicht solch (in meinen Augen) völlig sinnfreien Readingnamen in ihren Modulen generieren ?

Zitatgab 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?

Das Reading
2019-12-14 14:53:00   Refrigeration.FridgeFreezer.Event.DoorAlarmRefrigerator BSH.Common.EnumType.EventPresentState.Off
stammt aus diesem Thread (https://forum.fhem.de/index.php/topic,106538.0.html) und wird scheinbar von einem Modul "generiert".

Grüße Markus
Titel: FHEM 6.0 Release
Beitrag von: justme1968 am 21 Dezember 2019, 15:29:21
und das ist doch das perfekte beispiel das hier die in fhem vorgesehene hierarchie von raum device und reading zur organisation von daten nicht genutzt wird. statt dessen wird ,freitext' als label/name verwendet. das ist weder gut lesbar noch vernünftig maschinell weiter zu verarbeiten. ganz zu schweigen von der redundanz.

wenn ein api so etwas verwendet ist das ok. aber zur darstellung in fhem sollte so etwas aufgearbeitet werden.
Titel: Antw:FHEM 6.0 Release
Beitrag von: PatrickR am 21 Dezember 2019, 15:57:43
Hi!

Zitat von: justme1968 am 21 Dezember 2019, 15:29:21
und das ist doch das perfekte beispiel das hier die in fhem vorgesehene hierarchie von raum device und reading zur organisation von daten nicht genutzt wird.
Naja, spätestens der Raum ist doch Usersache, der sollte nicht von Modulautoren vorgegeben werden.

Zitat von: justme1968 am 21 Dezember 2019, 15:29:21
statt dessen wird ,freitext' als label/name verwendet. das ist weder gut lesbar noch vernünftig maschinell weiter zu verarbeiten. ganz zu schweigen von der redundanz.
Ich glaube, gerade die maschinelle Verarbeitbarkeit und die Stabilität der Readings spricht für eine 1:1-Abbildung von API in Readings. FHEM bietet schon jetzt ein reichhaltiges Sortiment an Möglichkeiten, Readings nach dem persönlichen Geschmack darzustellen.

Zitat von: justme1968 am 21 Dezember 2019, 15:29:21
wenn ein api so etwas verwendet ist das ok. aber zur darstellung in fhem sollte so etwas aufgearbeitet werden.
Das würde aber bedeuten, dass der Modulautor jedes mögliche Reading (und gerade bei HomeConnect kann man sich davor kaum retten) mappen müsste. Das ist nicht nur Aufwand sondern auch fehlerträchtig und führt dann zu Situationen, wo Typos entstehen, die man dann entweder bis zum Ende aller Tage mitschleppen muss oder riskiert, dass Notifys u. Dgl. nach einem Fix nicht mehr funktionieren. Im Übrigen sollte man bedenken, dass eine Längenbeschränkung die 1:1-Umsetzung von API-Labels nur dann verhindert, wenn diese lang sind, d. h. bei HMCCUDEV könnten Readings weiterhin wie "zugeliefert" verwendet werden, bei HomeConnect nicht.

Wenn man kurze/schöne Readings haben wollte, müsste man dann glaube ich Nägel mit Köpfen machen und einen Mappingmechanismus bauen, der modulunabhängig gemeinsam durch Modulautor und Anwender pflegbar ist, ähnlich wie bei den HMCCU-Defaults.

Patrick
Titel: Antw:FHEM 6.0 Release
Beitrag von: Christoph Morrison am 21 Dezember 2019, 16:21:16
Zitat von: KölnSolar am 21 Dezember 2019, 15:25:34
Ich nutze weder DBLog noch DOIF(deshalb kann ich die Aussage zur "automatischen Generierung von Readings bei DOIF" auch nicht interpretieren). Das nur zur Info.

DOIF generiert Readings im Format e_$device_$reading für Readings, auf die ein DOIF triggert. D.h. wenn man lange Device-Namen hat (wie ich) und auch mal auf was anderes als state triggert, können durchaus lange Komposita entstehen. Es gibt übrigens aktuell keine Beschränkung wie lange ein Devicename sein darf (oder ich habe sie bisher nicht bemerkt), als würde durch einen "goodReadingName" sehr wohl eine Beschränkung hintenrum eingeführt.

Ein kleiner Test ergib, dass das Device mit dem äußerst sprechenden Namen


Internals:
   CFGFN     
   FUUID      5dfe3667-f33f-68bf-d0e0-fe152420cbc9106d
   NAME       xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   NR         25242
   STATE      ???
   TYPE       dummy
Attributes:


probemlos angelegt werden konnte. Das sind 128 x. 256 x hat auch funktioniert.

ZitatDie Antwort ergibt sich meines Erachtens doch schon sehr allgemein. Kurz ist doch generell besser als lang(übersichtlich, nachvollziehbar, schneller zu lesen/schreiben ....)
Es verbraucht auch nun mal alles Ressourcen, also Rechenzeit, Speicherplatz.

Die Speicherung des Strings "aaa" braucht in einer varchar(255)-Spalte genausoviel Speicherplatz wie in einer varchar(3)-Spalte, nämlich 5 byte (3 byte Zeichen + 1 byte für den string terminator (NULL-Byte) + 1 byte Längenindex), nur mal zum Hintergrund. var(iable) char heißt eben genau, dass im Gegensatz zum char-Typ kein fixer Speicher reserviert wird. D.h. jeder der meint, er müsse wirklich in einem DBMS, das mit Petabyte Daten umgehen kann, ein paar Bytes sparen, kann das einfach erreichen, in dem er wtf_0815 statt what_the_f..._0815 benutzt. Das Problem ist, dass die Zeichenbeschränkungsfraktion gerne anderen vorschreiben möchte, wie sie mit ihren Bytes haushalten sollen, und das unter nach wie vor bornierten / fadenscheinigen Gründen. Lies bitte mal den Thread vom Februar, den Rudolf verlinkt hat.

ZitatDa finde ich es schon sinnvoll Beschränkungen zu machen. Umgekehrt soll natürlich alles offen und flexibel sein. Ist für mich also mehr die Diskussion wie groß die Beschränkung sein sollte.

Es muss rein technisch Beschränkungen geben, da Spaltentypen im Regelfall irgendwie begrenzt sein müssen. Aber: Wir reden hier von einem Spaltentyp, der problemlos (exemplarisch in MySQL/MariaDB, woanders sind das durchaus auch Gigabyte) folgende hat:

Zitat
0 ⇐ n ⇐ 65535/charsize
0 ⇐ n ⇐ 21844 for UTF-8   
65,535 bytes shared by all columns

Das sind sehr viele Bytes.

Zitat von: KölnSolar am 21 Dezember 2019, 15:25:34
Ich frage mich, welchen Sinn die Länge im folgenden Reading-Beispiel hat(ganz abgesehen von den Punkten  ::)) Ist es da nicht sinnvoll eine Beschränkung zu machen, damit Modulentwickler das berücksichtigen und eben erst gar nicht solch (in meinen Augen) völlig sinnfreien Readingnamen in ihren Modulen generieren ?

Das Reading
2019-12-14 14:53:00   Refrigeration.FridgeFreezer.Event.DoorAlarmRefrigerator BSH.Common.EnumType.EventPresentState.Off
stammt aus diesem Thread (https://forum.fhem.de/index.php/topic,106538.0.html) und wird scheinbar von einem Modul "generiert".

YMMV, aber ich finde das ist genau was es ist: Ein lesbares Reading. Ich wusste zumindest sofort worum es geht und ich habe kein Home connect oder was das ist, im Einsatz.
Titel: Antw:FHEM 6.0 Release
Beitrag von: justme1968 am 21 Dezember 2019, 16:36:31
ZitatNaja, spätestens der Raum ist doch Usersache, der sollte nicht von Modulautoren vorgegeben werden.
ich habe nirgendwo geschrieben das ein etwas vom modul autor vorgegeben werden soll.

aber dieser rattenschwanz aus dem beispiel enthält:
- einiges an reddundanz (mehrfach event)
- einiges an dingen die den endanwender bei einer darstellung nicht interessieren
  (common, bsh, enum type, ...)
- dinge die eindeutig zum gerät oder raum gehören und nicht in jedem reading wiederholg
  werden sollten.

diese bandwurm reading namen sind für den endanwender einfach schlecht und unübersichtlich.

ich sage ja nicht das es einfach ist das ganze sinnvoll zu kürzen und auf die fhem konzepte abzubilden. aber das heisst doch nicht das man es dann lieber sein lässt.

es geht hier um software. die ist ideal genau dafür. redundante schlecht formatierte information so aufbereiten das sie für einen menschlichen anwender optimal lesbar ist.


eine 1:1 umsetzung ist im übrigen kein gutes vorgehen. es ist zwar einfach aber verhindert z.b. bei hmccu jede kompatibilität zu anderen fhem devices. die diskussion um standard reading namen kommt leider nicht wirklich voran weil sie am gleichen problem krankt. jedem alles recht machen wollen. das führt leider dazu das es unmöglich ist automatisch dinge zu machen wie einheiten umzurechnen, sprach assistenten automatisch semantisch richtige rückmeldungen geben zu lassen, ...

das argument das ein modul das readings anderer devices weiterverarbeiten soll und dadurch aneinanderhängen von reading und device dann namen erzeugt die implizit länger sind als ein vorgegebenes limit verstehe ich. aber es darf nicht zum totschlag argument werden das alle sinnvollen regelungen bezüglich lesbarkeit untergräbt.

und nein, speicher optimierung sollte nicht das haupt ziel sein. speicherplatz ist billig. sowohl hauptspeicher als auch plattenplatz. darum geht es zumindest mir nicht.
zumal bei einer 'vernünftigen' db die interne represenation von feldern bestimmter länge und varchar durchaus identisch sein kann.
Titel: Antw:FHEM 6.0 Release
Beitrag von: PatrickR am 21 Dezember 2019, 19:04:31
Zitat von: justme1968 am 21 Dezember 2019, 16:36:31
ich habe nirgendwo geschrieben das ein etwas vom modul autor vorgegeben werden soll.
Ich habe Dich so verstanden, dass Du die Readings dadurch kürzen möchtest, indem Teile der Hierarchie rausgezogen werden.


Von unterwegs gesendet.
Titel: Antw:FHEM 6.0 Release
Beitrag von: KölnSolar am 21 Dezember 2019, 19:08:00
ZitatYMMV, aber ich finde das ist genau was es ist: Ein lesbares Reading. Ich wusste zumindest sofort worum es geht und ich habe kein Home connect oder was das ist, im Einsatz.
Ich auch nicht, aber mitDoorAlarmRefrigerator weiß ich das auch. Nur schneller.

Und wenn Du mir erzählen willst, dass eine z.B doppelte Länge keinen Einfluss auf performance z.B. eines "select" hat, dann muss ich mich grundsätzlich damit beschäftigen, was sich in den letzten Jahrzehnten an der grundlegenden Funktionsweise (CPU, Register, Memory) eines Computers verändert hat.(dass sie schneller geworden sind, weiß ich sehr wohl  ;D)
Titel: Antw:FHEM 6.0 Release
Beitrag von: rudolfkoenig am 21 Dezember 2019, 19:12:54
Bisher habe ich nur Beispiele fuer lange Readingsnamen gesehen, die entweder ohne Probleme gekuerzt werden koennen (wie Refrigerator...), oder wie bei DbRep/DOIF, wo etwas im Namen gespeichert wird, was ins Wert gehoert.

Bei der aktuellen Reaktionen gehe ich davon aus, dass die Modulautoren nicht in der Lage sind, diese Methoden bis zum Release von 6.0 umzubauen (ich habe sogar das Gefuehl, dass nichtmal ein Verstaendnis fuer das Problem vorliegt), deswegen schlage ich vor die erzwungene Begrenzung zu verschieben. Ich wuerde mich freuen, wenn das Problem bis zum uebernaechsten Release angegangen wird.
Titel: Antw:FHEM 6.0 Release
Beitrag von: Christoph Morrison am 21 Dezember 2019, 19:24:43
Zitat von: KölnSolar am 21 Dezember 2019, 19:08:00
Ich auch nicht, aber mitDoorAlarmRefrigerator weiß ich das auch. Nur schneller.

Und du musstest nicht mal scrollen1!1!

Zitat von: KölnSolar am 21 Dezember 2019, 19:08:00
Und wenn Du mir erzählen willst, dass eine z.B doppelte Länge keinen Einfluss auf performance z.B. eines "select" hat, dann muss ich mich grundsätzlich damit beschäftigen, was sich in den letzten Jahrzehnten an der grundlegenden Funktionsweise (CPU, Register, Memory) eines Computers verändert hat.(dass sie schneller geworden sind, weiß ich sehr wohl  ;D)

Gut. Wenn du weißt, dass sich die Rechenkapazitäten vervielfacht und Speicher irre günstige wurde, warum diskutieren wir dann darüber, ob varchar(128) "zu lang" ist? Gegenfrage: Wie viel Performance sparen wir denn, wenn wir die Änderung durchführen, die hier gewünscht wurde und deren Fraktion keinerlei stichhaltigen Argumente liefern kann, obwohl sie in der Bringschuld dafür sind? Ich würde mich ja irre freuen wenn mal jemand mit einem Benchmark oder so kommen würde und zeigt: Hier, Christoph, guck mal, wenn wir auf 64 Zeichen begrenzen, dann läuft fhem.pl 5% schneller/hat nun endlich mal seit 2017 oder so keine Speicherlecks mehr/braucht insgesamt weniger Speicher und läuft deshalb auch auf deinem alten Casio-Taschenrechner!.

Warum nur werde ich vergebens darauf warten?

Und auch bei dir noch mal die Frage: Warum nutzen die ganzen Zeichenknauserer (varchar-Sozialisten ist ja "nicht produktiv", aber zutreffend) nicht einfach kurze Bezeichner und lassen alle anderen in Ruhe? Es war überhaupt kein Problem, DbLog auf varchar(255) umzustellen als ich das wollte - so soll das sein, nicht andersrum.
Titel: Antw:FHEM 6.0 Release
Beitrag von: Christoph Morrison am 21 Dezember 2019, 19:32:26
Zitat von: rudolfkoenig am 21 Dezember 2019, 19:12:54
Bisher habe ich nur Beispiele fuer lange Readingsnamen gesehen, die entweder ohne Probleme gekuerzt werden koennen (wie Refrigerator...), oder wie bei DbRep/DOIF, wo etwas im Namen gespeichert wird, was ins Wert gehoert.

Wo genau sollte e_$device_$reading denn falsch gesetzt sein, wenn das der Schlüssel zu einem Wert ist (nämlich der von $device:$reading)? Welche Datenstruktur wäre denn für sowas angebracht? Damian freut sich sicher über einen Hinweis.

Ansonsten finde ich es gut, dass du die Einführung verschiebst.
Titel: Antw:FHEM 6.0 Release
Beitrag von: KölnSolar am 21 Dezember 2019, 19:41:31
ZitatWenn du weißt, dass sich die Rechenkapazitäten vervielfacht und Speicher irre günstige wurde, warum diskutieren wir dann darüber, ob varchar(128) "zu lang" ist?
weil doppelt so viel immer noch ca. doppelt so teuer ist. Ich liebe meine niedliche 8GB-SD im Rpi. Alleine das regelmäßige Image dauert bei 16/32...GB entsprechend länger.
ZitatWie viel Performance sparen wir denn, wenn wir die Änderung durchführen, die hier gewünscht wurde und deren Fraktion keinerlei stichhaltigen Argumente liefern kann, obwohl sie in der Bringschuld dafür sind? Ich würde mich ja irre freuen wenn mal jemand mit einem Benchmark oder so kommen würde und zeigt:
Wird doch. Du willst es nur nicht einsehen.
ZitatHier, Christoph, guck mal, wenn wir auf 64 Zeichen begrenzen, dann läuft fhem.pl 5% schneller/hat nun endlich mal seit 2017 oder so keine Speicherlecks mehr/braucht insgesamt weniger Speicher und läuft deshalb auch auf deinem alten Casio-Taschenrechner!.
Wer redet vom "normalen Betrieb ? Ich sprach von z.B. einem "select". Wann braucht man den wohl per regexp ?  ::)
Titel: Antw:FHEM 6.0 Release
Beitrag von: PatrickR am 21 Dezember 2019, 20:17:06
Zitat von: KölnSolar am 21 Dezember 2019, 19:08:00
Ich auch nicht, aber mitDoorAlarmRefrigerator weiß ich das auch. Nur schneller.
Bitte bedenke, dass man den vollen API-String auch bei dokumentierten APIs wie HomeConnect in der Referenz findet und nicht auf die Doku des Modulautors oder - falls die hinterherhängt - auf den Modulcode angewiesen ist. Das wäre dann tatsächlich schneller.



Von unterwegs gesendet.
Titel: Antw:FHEM 6.0 Release
Beitrag von: KölnSolar am 21 Dezember 2019, 20:37:07
Versteh ich nicht so ganz. Bei Erstnutzung eines Moduls mache ich mich zu readings des devices schlau, also einmalig. Im laufenden Betrieb lese ich mir bekannte readings. Da will ich weder scrollen, noch nach der Hälfte evtl. vergessen haben, wie der Anfang aussah.

Aber was ganz anderes.

ZitatAnsonsten finde ich es gut, dass du die Einführung verschiebst
Finde ich in der Situation auch. Ich hab mir jetzt auch mal den Ausgangsthread aus dem FEBRUAR angesehen. Als nicht Betroffener: Warum ist das nicht zu Ende diskutiert/entschieden worden, um dann 10 Monate später bei Einführung die Gemüter zu erhitzen und Ankündigung/Abkündigung zu machen ?  Wäre es da nicht besser konkrete bedeutsame (Vor-)Entscheidungen in z.B. "Ankündigungen" oder einem Subforum hier zu veröffentlichen(Vorabinfo einer Absicht) :-\
Titel: Antw:FHEM 6.0 Release
Beitrag von: Christoph Morrison am 21 Dezember 2019, 21:14:38
Zitat von: KölnSolar am 21 Dezember 2019, 19:41:31
weil doppelt so viel immer noch ca. doppelt so teuer ist. Ich liebe meine niedliche 8GB-SD im Rpi. Alleine das regelmäßige Image dauert bei 16/32...GB entsprechend länger.

Willst du mich veräppeln? Wir reden hier nicht von 100% deiner Daten, sondern von einem Bruchteil. Wenn man nun 1% deiner Daten verdoppelt, hast du nicht 200%, sondern 101%.

Übrigens gibt es 16GB-SD-Karten im Fünferpack für 23€, d.h. eine kostet 4,60, während eine 8GB-Karte fast einen Euro mehr kostet. Eine 32GB-Karte kostet 9€ (jeweils Sandisk Ultra). Herzlichen Glückwunsch, du bist mit deiner 8GB-Karte einen Euro ärmer geworden und hast dich ärmer gespart, vom Frust einer kleinen SD-Karte ganz zu schweigen. Ich kaufe gar keine mehr unter 128GB (14,99€, ebenfalls Sandisk). Übrigens belegt das meinen Punkt, denn vor knapp zwei-drei Jahren haben 16GB noch 15€ gekostet, d.h. die Speicherpreise haben sich geachtelt.

Zitat von: KölnSolar am 21 Dezember 2019, 19:41:31
Wird doch. Du willst es nur nicht einsehen.

Dies liegt vor allem an der Kwalität der Argumente hier, von dir und im Februar-Thread.

Zitat von: KölnSolar am 21 Dezember 2019, 19:41:31
Wer redet vom "normalen Betrieb ? Ich sprach von z.B. einem "select". Wann braucht man den wohl per regexp ?  ::)

Versuch mein Posting bitte noch einmal sinnentnehmend zu lesen.

Übrigens hast auch du mir noch nicht nahebringen können, was dich davon abhält einfach kurze Bezeichner zu wählen um wertvollen Platz auf deinen Speicherkarten zu sparen, ohne es anderen vorschreiben zu müssen. Wie ich oben schon dargelegt habe, kosten kurze Bezeichner in varchar-Spalten mit unter 256 Zeichen Länge genausoviel Speicher und RAM wie kurze Bezeichner in Spalten mit aggressiver Begrenzung - und deine Selects werden auch nicht langsamer, wenn du einfach keine langen Zeichenketten verwendest. Immerhin kannst du in der gesparten Zeit mindestens einen viertel Atemzug nehmen, das sollte es dir doch wert sein.
Titel: Antw:FHEM 6.0 Release
Beitrag von: KölnSolar am 21 Dezember 2019, 21:48:04
Zitatwenn du einfach keine langen Zeichenketten verwendest.
Ist das nicht das Thema  ::)
Deine Art empfinde ich als sehr unsachlich. Du schreibst viel unwesentliches und ignorierst wesentliches, reisst Dinge aus dem Zusammenhang. Nur von mir:
ZitatKurz ist doch generell besser als lang(übersichtlich, nachvollziehbar, schneller zu lesen/schreiben ....)
Es verbraucht auch nun mal alles Ressourcen, also Rechenzeit, Speicherplatz.
ZitatIst für mich also mehr die Diskussion wie groß die Beschränkung sein sollte.
ZitatNur schneller.
Zitatweil doppelt so viel immer noch ca. doppelt so teuer ist.
ZitatAlleine das regelmäßige Image dauert bei 16/32...GB entsprechend länger.
ZitatDa will ich weder scrollen, noch nach der Hälfte evtl. vergessen haben, wie der Anfang aussah.
Wenn an diesen Aussagen etwas grundsätzlich falsch ist, nehme ich das gerne zur Kenntnis.  Wie teuer aber z.B. eine SD-Karte ist, ist dabei sowas von uninteressant .. :-X
Titel: Antw:FHEM 6.0 Release
Beitrag von: KölnSolar am 21 Dezember 2019, 22:15:08
Ließe sich die Problematik von einer Längenbeschränkung der reading-names in Modulen wie z.B. HomeConnect nicht durch ein Attribut readingList wie im MQTT2_Device-Modul lösen ? Relation technischer "reading"-name zu human-readable-FHEM-reading-name ?
Titel: Antw:FHEM 6.0 Release
Beitrag von: justme1968 am 29 Dezember 2019, 14:54:13
ich weiss ... ungelegte eier und so ... aber vielleicht ist es ein feature das noch für fhem 6.0 interessant wäre. oder will es eine größere umstellung ist doch erst für fhem 6.1 ?


ich habe gerade eine ergänzung/überarbeitung der commandref/modul doku und den diversen tools die sie bauen und auswerten am wickel. die ideen kommen aus diversen threads die es in den letzten jahren hierzu gab. anlass war eigentlich nur das taggen der modul doku auf mehreren achsen und das interaktive filtern danach.

herausgekommen ist die zusammenfassung der 3 kommandozeilen tools (_join, _modular, _static) zum erstellen der commandref varianten sowie der beiden module (help und Meta bzw. search). das ergebnis ist dann eine einzige software version die die 4 andere ersetzt und für alle 5 anwendungsfälle mit den gleichen routinen exakt die gleiche ausgabe erzeugt.

das ganze ist noch nicht ganz fertig, wie es aktuell ausschaut sieht man in den angehängten screenshots:
- einstieg in die commandref, oben sind die filter und deren aktuelle auswahl zu sehen
- der index zeigt nur noch die gefilterten daten an
- statt dem index kann auch die liste der modul summary angezeigt werden
- mit einem klink springt wie bisher zum eintrag für das device
- der link aus der detail ansicht zeigt die information auf die gleiche art an

die commandref kann wie bisher aus einem stück, mit aus fhem nachgeladenen teilen oder mit auf platte erzeugten teilen bestehen. sowohl in diesen commandref versionen wie auch in den einzeln verwendeten teilen (detail ansicht/help) schaut alles gleich aus. inklusive sprach umschaltung.

ich würde in 1-2 wochen eine genauere beschreibung und den code posten.

Titel: Antw:FHEM 6.0 Release
Beitrag von: betateilchen am 29 Dezember 2019, 19:44:26
die Anzeige aus "help" funktioniert dann auch mit telnet?

Und wie wird die Generierung aufgerufen? Die Frage stellt sich, weil die commandref auch beim Bauen der Pakete aus dem Makefile erzeugt und in das Paket integriert wird.
Titel: Antw:FHEM 6.0 Release
Beitrag von: justme1968 am 29 Dezember 2019, 19:50:27
ja. beides funktioniert wie bisher weiter. nur der name des anzurufenden kommandos ändert sich jeweils in commandref wenn man die neuen features nutzen möchte.

d.h. man kann sogar erst mal die alten kommandos weiter verwenden so lange sie noch da sind und man nicht die neuen features nutzen möchte.
Titel: Antw:FHEM 6.0 Release
Beitrag von: Loredo am 31 Dezember 2019, 13:45:27
"Yet another XYZ"... warum wird das nicht mit FHEM Meta und dem Installer verheiratet?
Titel: FHEM 6.0 Release
Beitrag von: justme1968 am 31 Dezember 2019, 14:13:19
nicht schimpfen bevor du mehr weißt :)

am anfang ging es nur um das interaktive filtern der  commandref. also frontend.

dabei ist mir dann aber schnell aufgefallen das es aktuell 5 unabhängige stellen gibt die die modul doku parsen und aufbereiten. alle zumindest minimal unterschiedlich. das ist natürlich blöd wenn das ui überall eingebaut werden muss.

von den 5 stellen war Meta die einzige die wiederverwendbar war. aber nicht stand-alone ohne fhem.pl. andererseits hat Meta bisher nichts mit dem erzeugen der commandref zu tun gehabt.

deshalb habe ich die anderen vier zusammengefasst, Meta etwas erweitert damit es auch ohne fhem.pl läuft und alles alles zusammen in einem einzigen neuen modul verwendet das stand alone zum generieren der offline versionen und als fhem kommando für den online teil verwendet wird. d.h. es gibt nur noch eine einzige stelle mit der die ausgabe für alle anwendungsfälle erzeugt wird. sowohl online wie offline commandref, monolithisch, modular und stand-alone sowie hilfe per web und telnet. es werden sowohl die tags zum filtern überall wo sinnvoll eingebaut, als auch die links auf forum und wiki aus Meta, und demnächst auch links auf die weiterführenden dinge in search bzw. dem installer.

wenn ich demnächst alles poste und das ganze angenommen wird kann man es direkt und kompatibel verwenden. für die neuen features müssten wir uns dann noch auf die tags einigen und sie einbauen und die fhemweb styles außer dark anpassen.

Meta ist (nur) ein teil des ganzen.
Titel: Antw:FHEM 6.0 Release
Beitrag von: betateilchen am 31 Dezember 2019, 15:00:54
Zitat von: justme1968 am 29 Dezember 2019, 19:50:27
ja. beides funktioniert wie bisher weiter. nur der name des anzurufenden kommandos ändert sich jeweils in commandref wenn man die neuen features nutzen möchte.

Klingt nach einem guten Plan, danke!
Titel: Antw:FHEM 6.0 Release
Beitrag von: Loredo am 31 Dezember 2019, 16:46:15
Das klingt ja mal sehr vielversprechend, ich bin ganz leise und gespannt :)
Titel: Antw:FHEM 6.0 Release
Beitrag von: justme1968 am 12 Januar 2020, 22:34:00
kurz ein paar strichpunkte zum aktuellen stand:

- commandref.pl erzeugt monolithisch und static, jeweils kompatibel zur bisherigen version
- commandref.js zum filtern in allen versionen und zum nachladen der nicht integrierten teile
- FHEMWEB kann auch die statische version ausliefern.
- commandref.pl liefert auch html oder text wie help auch als fhem commando.
- es gibt ein neues attribut in fhem mit dem man einstellen kann welche der drei versionen lokal nach einem update erzeugt wird.


- das erzeugen der modularer version die per help nachläd ist gerade in arbeit.

- das search aus Meta möchte ich noch integrieren

dann poste ich alles.
Titel: Antw:FHEM 6.0 Release
Beitrag von: rudolfkoenig am 24 Januar 2020, 17:13:11
Ich habe die Laengenbegrenzung von 64 entfernt.
Ich hoffe weiterhin auf einsichtige Entwickler, die Readings- und Attributnamen auf eine von Benutzer handhabbare Laenge beschraenken.
Titel: Antw:FHEM 6.0 Release
Beitrag von: M.Schulze am 26 Januar 2020, 13:38:21
Zitat von: rudolfkoenig am 20 Dezember 2019, 18:06:35
Ich wuerde etwa Anfang Januar die aktuelle Version als 6.0 veroeffentlichen.


Hallo,

müsste man dann nicht eher den Abschluß der Entwicklung an Version 5.9 hervorheben / kommunizieren ?

Diverse Threads suggerieren das 6.0 fertig ist. Ist aber wohl eher so, das wenn es denn normale Anwender geben würde, diese jetzt die fertige, besonders fehlerfreie 5.9 bekommen könnten und nur die Entwicklung 6.0 startet.


MFG
Titel: Antw:FHEM 6.0 Release
Beitrag von: CoolTux am 26 Januar 2020, 13:53:14
Das verstehst Du falsch. Bei FHEM gibt es im eigentlichen Sinn keine fertige Version.
Irgendwann wird die aktuelle Entwicklung genommen und in ein fertiges Packet gesteckt und als Version deklariert. Das einzige an diesen Versionen ist das sie sogenannte Feature Releases sind. Also Funktionen oder Features welche mit > 5.9 deklariert sind dann als Default mit 6.0 gelten.
Titel: Antw:FHEM 6.0 Release
Beitrag von: RichardCZ am 17 April 2020, 18:21:17
So ... Alter Schwede. Jetzt habe ich mir das hier durchgelesen wegen

https://forum.fhem.de/index.php/topic,109740.msg1043564.html#msg1043564 ff

Ok, 64 ist zu wenig. DS_Starter hat gemeint man könnte mit 128 leben.
Ob man scrollen muss oder nicht ist mir eigentlich egal, aber unbegrenzt -> nukleare Option.

Wie anderweitig angemerkt kann ich also auch Tolstois Krieg und Frieden in einen Readingname verwandeln und FHEM unterschieben.
Irgendwann ist das keine Frage der Ergonomie, sondern der Sicherheit.

Und ja, das betrifft auch andere Sachen wie Devicenamen etc.

Ich gehe also davon aus, dass 256 Zeichen reichen und werde bei mir die Regexen entsprechend beschränken.
Vielleicht kann man ja so eine Konstante zur Feier der ersten Marskolonie ja auch konfigurierbar halten (mit Default: 256)

Danke für die Diskussion und Ihre Aufmerksamkeit.  ;)