neu in Version 4.4.0

[jemu75]

Hallo,

nachdem über den Sommer nicht viel passiert ist, habe ich nun wieder eine Release veröffentlicht.

In diesem gibt es ein neues Level Element (textfield), welches ich ausnahmsweise als "experimentelles Feature" bereitstelle.
Es handelt sich um ein Eingabefeld. In dieses können jegliche Werte eingegeben werden, welche dann als FHEM Befehle gesendet werden.
Ich hatte dieses Element erstellt, um beispielsweise neue Szenen mit einem bestimmten Name in FHEM abzuspeichern.
Es gibt hier sicher noch eine Menge anderer usecases, die ich aktuell nicht auf dem Schirm habe.
Deshalb würde ich mich über eure Ideen und Anregungen freuen, damit diese Level Element offiziell zum Einsatz kommen kann.

Weiterhin in dem Release 4.4.0 enthalten ist, die Möglichkeit die Sichtbarkeit der Ebenen abhängig vom Zustand des Panels (also ob ausgeklappt oder eingeklappt) zu steuern.

Ebenfalls gibt es zwei neue Ersetzungen. Zum einen einen klassischen "replacer" mit dem man Strings austauschen kann. Ich verwende diese Ersetzung hauptsächlich, um "underlines" aus FHEM Lightscenes zu entfernen. Weiterhin gibt es eine nützliche Ersetzung für Zeitstempel um Zeitdifferenzen anzuzeigen, die sekundengenau aktualisiert werden.

In diesem Sinne viel Freude mit dem neuen Release! 

Jens

[marvin78]

Gute Neuerungen. Danke dafür.

Kannst du für diff mal ein Beispiel geben? Das habe ich nicht verstanden. Für was stehen die ...?


Edit: Ach sorry. Ich habe mal wieder nicht weit genug gelesen. Alles klar. Danke.

[marvin78]

Könnte man diff noch so umbauen, dass die Tage bei true nur dann angezeigt werden, wenn sie größer 0 sind?

[Himbi777]

Hallo,

Sehr schöne Erweiterungen 👍🏼

In der Beschreibung für die "Differenz zur FHEM Serverzeit" hat sich noch ein kleiner Fehler eingeschlichen, am Ende ist ein geschweifte Klammer } zuviel.

Des weiteren wird ein Text der vor der Ersetzung eingegeben wird, nicht mit angezeigt:
z.B: seit\: %d({ "diff"\: {...} })

Gerhard

[marvin78]

Was mir zum diff noch einfällt: Man müsste irgendwie die Möglichkeit haben, das reading für den Vergleich im value heranzuziehen und nicht das Timestamp. Man möchte den Diff bspw. anzeigen, wenn eine Tür geöffnet ist, wenn sie geschlossen ist aber nicht. Ich weiß nicht, ob das in dem vorhandenen Konzept mmöglich ist.

[jemu75]

Was mir zum diff noch einfällt: Man müsste irgendwie die Möglichkeit haben, das reading für den Vergleich im value heranzuziehen und nicht das Timestamp. Man möchte den Diff bspw. anzeigen, wenn eine Tür geöffnet ist, wenn sie geschlossen ist aber nicht. Ich weiß nicht, ob das in dem vorhandenen Konzept mmöglich ist.

Dazu gab es vor einiger Zeit schon einen Wunsch von @Benni (siehe issue #61)
Bisher ist das Konzept so ausgelegt, dass nur das eine Reading verarbeitet wird. Meine Überlegung geht dahin, dass man in den Definitionen generell zwischen "Bedingung" und "auszugebenden Werten" unterscheidet. Damit könnte man in den Definitionen einen (oder sogar mehrere) Werte (Readings) verarbeiten und die Bedingung separat (optional) festlegen.

Für den Teil, der die Bedingung enthält würde sich im Vergleich zum aktuellen Konzept eigentlich nichts verändern. Sprich die Bedingung enthält 2 Parameter (reading:value)
Der interessantere Teil betrifft die auszugebenden bzw. zu verarbeitenden Readings. Die ganzen Ersetzungen müssten umgebaut werden. Hier hatte ich schon mal grob den Gedanke, das Konzept von FHEM -> ReadingsVal() aufzugreifen.

Könnte dann z.B. so in der Definiton aussehen fhemVal(switch-state, %s) oder fhemVal(switch-state, %n, 2) oder fhemVal(switch-state, %n, 2, 1.5)
Der erste Parameter von fhemVal() wäre immer das Reading/Attribute/Internal, der zweite Parameter (optional) die Formatierung und alle weiteren Parameter dann wieder die Formatierung betreffende Optionen. Wie im genannten Beispiel dann eben die Nachkommastellen, der Offset-Wert, oder, oder, oder...

Gebt gern mal eure Meinung in die Runde, ob das in die richtige Richtung geht. Auch ob das heutige und das vorgeschlagene Konzept parallel existieren sollten oder ob man dieses Konzept durch das heutige Konzept mit einer Möglichkeit zur Migration der aktuellen Definitionen ersetzt.

Jens 

[jemu75]

Und zu den o.g. Rückmeldungen folgt kurzfristig ein Fix (v4.4.1)

1. Doku wird korrigiert
2. "Tag(e)" werden erst ab 1+ angezeigt
3. Die "Diff-Ersetzung" löscht den restlichen Text nicht mehr

Jens

[marvin78]

Gebt gern mal eure Meinung in die Runde, ob das in die richtige Richtung geht. Auch ob das heutige und das vorgeschlagene Konzept parallel existieren sollten oder ob man dieses Konzept durch das heutige Konzept mit einer Möglichkeit zur Migration der aktuellen Definitionen ersetzt.

Jens 

Kurz und knapp: ich bin dafür. Wenn eine zuverlässtige Migration der bestehenden Definitionen gewährleistet ist, kann es auch gerne eine Ablösung geben. Ich habe sehr sehr sehr viele Definitionen und hätte sehr sehr sehr viel zu ändern

[marvin78]

Und zu den o.g. Rückmeldungen folgt kurzfristig ein Fix (v4.4.1)

1. Doku wird korrigiert
2. "Tag(e)" werden erst ab 1+ angezeigt
3. Die "Diff-Ersetzung" löscht den restlichen Text nicht mehr

Jens

Hierzu: Stunden ggf. auch mit führender 0 anzeigbar machen. Vielleicht nicht nur die Tage ausblenden, wenn 0, sondern die Stunden auch. Das kann man zwar ggf. auch selbst regeln (über userReading und entsprechende Definition) aber das ist sehr komplex. Ggf. sollte das Ausblenden auch irgendwie optional sein. Eine einheutliche Länge hat ja auch Vorteile, je nach Anwendungsfall.

[jemu75]

Hallo,

mit der heute veröffentlichten Version 4.5.0 sind die gewünschten Optionen für die "Diff-Ersetzung" eingebaut.

Mit dem Wert "true" wird die Zeitwerte (Stunden, Minuten, Sekunden) als 2-stellige Werte angezeigt
Mit dem Wert "nozero" werden die Tages bzw. Zeitwerte erst ab 1 angezeigt
Mit dem Wert "numeric" werden die Zeitwerte ohne führende Nullen angezeigt

Hoffe das passt jetzt 

Grüße
Jens