FHEM 6.0 Release

[KölnSolar]

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.

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

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?

Das Reading

Code Auswählen Erweitern

2019-12-14 14:53:00   Refrigeration.FridgeFreezer.Event.DoorAlarmRefrigerator BSH.Common.EnumType.EventPresentState.Off
stammt aus diesem Thread und wird scheinbar von einem Modul "generiert".

Grüße Markus

[justme1968]

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.

[PatrickR]

Hi!

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.

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.

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

[Christoph Morrison]

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

Code Auswählen Erweitern


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.

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.

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.

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.

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:

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

Das sind sehr viele Bytes.

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

Code Auswählen Erweitern

2019-12-14 14:53:00   Refrigeration.FridgeFreezer.Event.DoorAlarmRefrigerator BSH.Common.EnumType.EventPresentState.Off
stammt aus diesem Thread 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.

[justme1968]

Naja, 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.

[PatrickR]

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.

[KölnSolar]

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.

Ich auch nicht, aber mit

Code Auswählen Erweitern

DoorAlarmRefrigerator 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  )

[rudolfkoenig]

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.

[Christoph Morrison]

Ich auch nicht, aber mit

Code Auswählen Erweitern

DoorAlarmRefrigerator weiß ich das auch. Nur schneller.

Und du musstest nicht mal scrollen1!1!

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  )

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.

[Christoph Morrison]

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.

[KölnSolar]

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?

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.

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:

Wird doch. Du willst es nur nicht einsehen.

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

Wer redet vom "normalen Betrieb ? Ich sprach von z.B. einem "select". Wann braucht man den wohl per regexp ? 

[PatrickR]

Ich auch nicht, aber mit

Code Auswählen Erweitern

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

[KölnSolar]

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.

Ansonsten 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)

[Christoph Morrison]

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.

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.

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.

[KölnSolar]

wenn 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:

Kurz ist doch generell besser als lang(übersichtlich, nachvollziehbar, schneller zu lesen/schreiben ....)
Es verbraucht auch nun mal alles Ressourcen, also Rechenzeit, Speicherplatz.

Ist für mich also mehr die Diskussion wie groß die Beschränkung sein sollte.

Nur schneller.

weil doppelt so viel immer noch ca. doppelt so teuer ist.

Alleine das regelmäßige Image dauert bei 16/32...GB entsprechend länger.

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