Readings, values und Units

[martinp876]

Hallo Boris,

ich verstehe, dass du damit etwas spielen willst - ist auch korrekt. Und es muss jeder selbst wissen, wie er ein Gefühl dafür entwickelt.
fhemWeb ist sicher ein wichtiges Frontend - ich denke es "gehört" Rudi, nicht dir.

Prinzipiell hat Udo sicher recht, das Frontend ist das letzte, was gemacht wird. FHEM-WEB ist im Übrigen nur ein Kunde. Es kann mehrere Frontends geben. Scripting interfaces haben mindestens den gleichen Stellenwert (also aktuell ReadingsVal, Num, Timestamp u.ä.)
Der ganze Aufwand wird ausschließlich dafür betrieben.

Noch einmal will ich meine Bitte loswerden:
Für die Backends darf es nicht zu einem Monster werden. Im Gegensatz zu Produktentwicklungen für eine Familie (eQ3 für HM...), die starre Strukturen vorgeben ist FHEM bisher flexibel. Es lebt geradezu davon. Die Nutzung der Objekte vom Backend muss diesem Luft zum Atmen lassen. Das betrifft das Anlegen und Befüllen der Objekte.

Ich erwähne, weil Teile der Diskussion über das Ableiten von Klassen (worauf einige Diskussionen Inhaltlich hinauslaufen) eine recht aufwendige und damit starre und schwerfällige Handhabung implizieren. Die Probleme sehe ich bereits und insbesondere beim Backend.

Darüber hinaus muss die Nutzung - sowohl vom Frontend (web UND script)  vom Backend Performance-optimiert ablaufen. Perl ist nun einmal von Natur aus ein sehr langsames Vehikel. Das Nutzen der Readings ist eine extrem häufig genutzte Funktion - Performance-fresser werden sich hier multiplizieren.

Bin auf den Ansatz gespannt.

Gruss Martin

[papa]

Würde nicht gerade das Entfallen von Regular Expressions in der Eventverarbeitung erheblich zur Performancesteigerung führen ? Oder sind die RegEx in Perl so schenll ?

[betateilchen]

Oder sind die RegEx in Perl so schenll ?

kommt drauf an, welche

[martinp876]

Es kommt auf das Gesamtkonzept an.
Wenn man erst aus vielen datenfeldern einen String basteln muss... muss man die Datenfelder suchen oder sind sie vorhanden - wie schnell wird zugegriffen...
dann: Wieviele Felder müssen "normal" geschrieben werden (nur VAL?..) und welche werden bei Bedarf zusammengebaut?
Im Webinterface werden alle einer Entity dargestellt (oder auch nicht?)

Die Frage der Häufigkeit ist (nicht unbedingt einfach) entscheidend.

Gruss Martin

[martinp876]

Hi,

wo wir schon dabei sind, readings zu "erneuern" - das Problem mit den Units hätte ich auch einfacher lösbar gesehen...
was aber nicht einfach zu machen geht ist, Ordnung in die Readings zu bekommen. Wenn man diese strukturieren könnte wäre das hilfreich. Man kann zumindest operationale Zustände (licht an, licht an für x sec,... ) und Maintenance Zustände (battery low,...) unterscheiden. Evtl noch Alarme (sabotage-kontakt,...) oder Dev-Infos (serial Number)
Für HM hätte ich noch mehr, da die Device Konfiguration (register) in mehreren Gruppen.
Aktuell ist die Darstellung nur eine Krücke, da es hierfür keine Handhabe in FHEM gibt.

Ich sehe auf Anhieb 2 Methoden, etwas Ordnung hier zu bekommen:
- ein Attribut "group" in dem man - mehrstufig - die Gruppe des Readings klassifizieren kann (group="alarm", group="konfig:reg:peer1")
- in READINGS weitere Strukturen erlauben, die in die Tiefen gehen.

Ich denke die erste Variante ist einfacher zu implementieren.
Im User-Interface könnte man dann Gruppen auf und zu falten, per Klick

Wenn man hier eine ordentliche Gruppierung und ein Handling  aufsetzen würde könnte ich auch einige aktuellen Internals nach Readings verschieben - diese Trennung ist in einigen Fällen eh nicht Eindeutig und nur aufgezwungen.

Nächste Stufe wäre noch, einen visibility-level einzuführen - das brauch ich in HM (aber sonst wahrscheinlich niemand...). Die aktuelle Implementierung mit '.' und global showInternalValues ist ein Anfang, aber eigentlich viel zu sperrig und kostet mich jede Menge Code.

Damit bin ich im Prinzip wieder bei einem Antrag, eine bessere (oder überhaupt eine) Struktur in Parameter zu bekommen.

Gruss Martin

[klaus.schauer]

Gibt es zwischenzeitlich Weiterentwicklungen oder Zwischenstände?

[Dr. Boris Neubert]

Hallo,

kein neuer Ansatz, keine neue Diskussion, lediglich der Versuch, zumindest etwas kleines zu schaffen, was erweiterbar ist mit all den Ideen, die wir hier gesammelt haben:

Es wurde ja kürzlich der Wunsch geäußert, bei bestimmten berechneten Readings die Anzahl der Nachkommastellen zu begrenzen. Angenommen, es gäbe die Möglichkeit zu konfigurieren, dass für Gerät X das Reading Y im Format %5.2f angezeigt wird (wie auch immer das geht, über Interfaces, Konfigurationsdateien, am Gerät definiert, ...). Dann bezieht sich dieses Anzeigen auf FHEMWEB bzw. ein API, das dem Aufrufer den formatierten Anzeigewert des Readings liefert, nicht wahr? Und FHEMWEB (und jedes andere Frontend) würde dann in FW_devState() statt ReadingsVal(X, Y, "") die API-Funktion nutzen. Seht Ihr das genauso?

Viele Grüße
Boris

[rudolfkoenig]

Da selbst triviale Sachen ueber die unterschiedlichen Frontends kaum eingehalten werden, wuerde ich beim readings*Update die Werte gleich mit der gewuenschten Genauigkeit speichern. Haette den Vorteil, dass es in jedem Frontend sofort klappt und den Nachteil, dass es keine "interne" hoehere Genauigkeit gibt. Was wiederum in vielen Faellen die Erklaerungen vereinfacht.

[Dr. Boris Neubert]

Hallo,

meinem Post ging eine ähnliche Diskussion an anderen Stellen voraus, in unterschiedlich allgemeingültiger Art  die Genauigkeit direkt ins Reading zu schreiben - wie Du es auch vorschlägst.

Ich sträube mich (noch) dagegen, weil es das Eingeständnis ist, dass wir es nie mehr schaffen werden, in FHEM Content und Darstellung voneinander zu trennen.

Das Forum sieht hier im Quartalstakt Aufstieg und Fall neuer Frontend-Initiativen. Aber kein einziges scheint sich mit der Schichtung von Anzeige, Transport und Content zu beschäftigen, sonst wäre das API längst implementiert.

Viele Grüße
Boris

[immi]

Hallo,
kein neuer Ansatz, keine neue Diskussion, lediglich der Versuch, zumindest etwas kleines zu schaffen, was erweiterbar ist mit all den Ideen, die wir hier gesammelt haben:

Hi Boris
Das Wahlergebnis waren in 2014 klar und eindeutig ... trotz geringe Teilnahme (Stimmen insgesamt: 11)
Leider die Developers die gewhelt haben, sind nicht die Owner der Kern-Modulen von FHEM und/oder sind Hobby-Programmierer wie ich

Aber kein einziges scheint sich mit der Schichtung von Anzeige, Transport und Content zu beschäftigen, sonst wäre das API längst implementiert.

Ich begruße jeden Versuch hier weiterzugehen
immi