Wie bereits angekündigt, ist der Prototyp der neuen svg-Funktion fertiggestellt.
Mit folgender Definition wird das angehängte Layout erzeugt. Die Besonderheit ist ein neues Argument col<Anzahl Stunden> bei der Angabe des Readings. Dadurch werden Daten des Readings gesammelt und für die Erzeugung eines Plots zur Verfügung gestellt - es sind keine weiteren Definitionen erforderlich. Dabei wird besonders sparsam mit der Datensammlung umgegangen, es werden maximal 60 Werte (in Timeslots) gespeichert, unabhängig davon wie lange die Zeitspanne ist und wie oft die Daten ankommen.
Im Beispiel wird 12 Stunden gesammelt, ebenso können größere Zeitintervalle angegeben werden z. B. 24 Stunden
defmod di_Wetter DOIF ##
attr di_Wetter uiTable {package ui_Table;;}\
## card ($collect,$header,$icon,$min,$max,$minColor,$maxColor,$unit,$colorRef,$decfont,$size,$model,$lightness)\
\
card([Wetter:TemperaturC:col12],undef,"temp_outside",-10,30,undef,undef,"°C",\&temp_hue)|\
card([Wetter:Feuchtigkeit:col12],undef,"temperature_humidity",0,100,undef,undef,"%",\&hum_hue)|\
card([Wetter:WindKm:col12],undef,[Wetter:WindKm] > 0 ? "wind".",1,0,0,".[Wetter:WindrichtungGrad]:"no_wind",0,30,120,0,"km/h",undef,1)\
card([Wetter:RegenMm:col12],undef,"weather_rain_gauge",0,10,180,270,"mm/h")|\
card([Wetter:UV:col12],undef,"sani_solar",,0,7,200,0,"UV",undef,0)|\
card([Wetter:LuftdruckHpa:col12],undef,"weather_barometric_pressure",980,1047,undef,undef,"hPa",[(1008.5,0,1018.5,270,1047,190)],0,undef,'0,1,1,6',",40,45,45,,45")
Wenn ich meine Tests abgeschlossen habe, werde ich die neue Version hier zum Ausprobieren hochladen.
Vorschläge zum Design oder zu weiteren Infos der "Infokarte" können hier gemacht werden - noch ist nichts in Blei gegossen.
PS Es ist kein Ersatz für SVG-Plots, die Daten werden lediglich temporär im Modul gespeichert.
Edit: aktuelle Version wurde eingecheckt
aktuelle Doku siehe: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Nice. Hänge mich mal mit rein...
Version 0.1
Syntax:
card ($collected_reading,$title,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$model,$lightness)
Parameter entsprechen weitgehend den Parametern der bisherigen svg-Funktionen (siehe wiki)
Bsp:
defmod di_collect DOIF ##
attr di_collect uiTable {package ui_Table;;}\
card([ESPEasy_Eingang_CO2:PPM:col24],"Schlafzimmer","air",400,1200,120,0,"ppm",undef,0)|\
card([Aussensensor:temperature:col24],"Außen","temp_outside",-10,45,undef,undef,"°C",\&temp_hue)
Geplant sind ebenfalls Plots im Ring siehe: https://forum.fhem.de/index.php/topic,118329.msg1143877.html#msg1143877
oder card2 für zwei Werte in einer Karte.
Edit: aktuelle Version im ersten Post
Das Bessere ist des Guten Feind: Und schon ist meine schöne Luftdruckstatistik mit den Cylinders "Gechichte".
Tolle Erweiterung des DOIF-Kosmos!
Eine Anregung: Wäre es denkbar, wenn ich $title und $icon "undef" setze, dass die leere Zeile dann ausgeblendet wird? Und was hältst Du davon, Maximum und Minimum durch Max und Min oder durch ▼ und ▲ abzukürzen und auf diese Weise daraus eine Zeile zu machen? Damit könnte man Höhe gewinnen.
Christian
Jetzt etwas kompakter, siehe Version 0.2 im ersten Post.
Beispiele mit/ohne Titel, mit/ohne icon in Kombination:
defmod di_collect DOIF ##
attr di_collect uiTable {package ui_Table;;}\
card([ESPEasy_Eingang_CO2:PPM:col1],"Schlafzimmer",undef,400,1200,120,0,"ppm",undef,0)|\
card([Aussensensor:temperature:col1],"Außen","temp_outside",-10,45,undef,undef,"°C",\&temp_hue)\
card([ESPEasy_Eingang_CO2:PPM:col1],undef,undef,400,1200,120,0,"ppm",undef,0)|\
card([Aussensensor:temperature:col1],undef,"temp_outside",-10,45,undef,undef,"°C",\&temp_hue)
Ich werde elektrisch! Kaum ist die Idee aufgeschrieben, schon kann ich sie anwenden. Super und vielen Dank. Eine dritte Anregung habe ich noch: In vielen Deiner DOIF-Features ist es so, dass wenn ein Begriff (hier wäre es im $title, bei Cylinders nennst Du es $header) mit einem Device-Namen matched, dass FHEM ihn dann als Link zur Detail-Seite des Device auszeichnet. Wäre hier auch praktisch, um direkt ins Device zu springen.
Bei Mischung der verschiedenen Elemente mit einer Card in einer Zeile habe ich jetzt für Ringe 155 px Höhe, für Cylinders 87
Christian
Zitat von: cwagner am 05 April 2021, 11:58:05
Ich werde elektrisch! Kaum ist die Idee aufgeschrieben, schon kann ich sie anwenden. Super und vielen Dank. Eine dritte Anregung habe ich noch: In vielen Deiner DOIF-Features ist es so, dass wenn ein Begriff (hier wäre es im $title, bei Cylinders nennst Du es $header) mit einem Device-Namen matched, dass FHEM ihn dann als Link zur Detail-Seite des Device auszeichnet. Wäre hier auch praktisch, um direkt ins Device zu springen.
Bei Mischung der verschiedenen Elemente mit einer Card in einer Zeile habe ich jetzt für Ringe 155 px Höhe, für Cylinders 87
Christian
Intern heißt der Parameter nicht title, sondern header, ich werde es im Wiki Eintrag einheitlich mit header benennen.
An der Stelle klappt es mit den Links nicht gut, weil es ein Text innerhalb der SVG-Elemente ist.
Ich habe noch einen Parameter $size wie bei anderen svg-Funktionen eingebaut (siehe Ver. 0.3 im ersten Post).
defmod di_collect DOIF ##
attr di_collect uiTable {package ui_Table;;}\
card([ESPEasy_Eingang_CO2:PPM:col1],"Schlafzimmer",undef,400,1200,120,0,"ppm",undef,0,80)|\
card([Aussensensor:temperature:col1],"Aussenssensor","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef,80)\
card([ESPEasy_Eingang_CO2:PPM:col1],undef,undef,400,1200,120,0,"ppm",undef,0,150)|\
card([Aussensensor:temperature:col1],undef,"temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef,150)\
Version 0.4 unterstützt jetzt konsequent die neuen Features der ring-Funktionen: colorRef, model, lightness
card([ESPEasy_Eingang_CO2:PPM:col24],undef,"air",400,1200,120,0,"ppm",[(600,120,1000,60,1200,0)],0,100,'0,1,1',"50,35,45,35,50,35")
:)Das wäre mein vierter Wunsch gewesen, aber hier sagt, dreimal ist Bremer Recht .-)
Funktioniert klasse.
Christian
siehe: https://forum.fhem.de/index.php/topic,119612.msg1145903.html#msg1145903
Ein schönes Ostergeschenk. Funktioniert super. Vielen Dank!
Habe folgendes festgestellt. Im Graphen besteht links ein kleines gap, da vermutlich nur die Daten zwischen 17:43 und 18:43 (Beispiel-1) verwendet werden. Vergleichbar addlog müsste der letzte Eintrag vor 17:43 mit verwendet werden.
Zitat von: jkriegl am 05 April 2021, 18:59:29
Ein schönes Ostergeschenk. Funktioniert super. Vielen Dank!
Habe folgendes festgestellt. Im Graphen besteht links ein kleines gap, da vermutlich nur die Daten zwischen 17:43 und 18:43 (Beispiel-1) verwendet werden. Vergleichbar addlog müsste der letzte Eintrag vor 17:43 mit verwendet werden.
Es werden nur Daten dargestellt, die seit der Definition oder Änderung der DOIF-Definition im Modul gesammelt wurden, wenn du noch etwas wartest, dann wird der Graph vollständig dargestellt.
Edit: Wenn es sich nicht füllt, dann liegt es daran, dass die Auflösung des Plots höher ist, als das Sendeintervall, damit werden bestimmte Timeslots nicht belegt. Hier macht es Sinn ein längeres Zeitintervall zu nehmen, damit die Auflösung des Plots voll ausgeschöpft wird.
Habe lange genug gewartet. s. 2. Beispiel (2 Stunden).
An der Zeit des min/max-Wertes sehe ich welche frühesten Werte verwendet werden. Das gap wird mal grösser, mal kleiner. Mein Intervall im Beispiel ist 900 sec. (Habe zum Testen rereads gemacht, um Daten zu erhalten)
Noch etwas, jetzt sind die Graphen linear. Man bräuchte ev. steps z. B. für die Spritpreisanzeige.
Zitat von: jkriegl am 05 April 2021, 19:36:32
Habe lange genug gewartet. s. 2. Beispiel (2 Stunden).
An der Zeit des min/max-Wertes sehe ich welche frühesten Werte verwendet werden. Das gap wird mal grösser, mal kleiner. Mein Intervall im Beispiel ist 900 sec. (Habe zum Testen rereads gemacht, um Daten zu erhalten)
Noch etwas, jetzt sind die Graphen linear. Man bräuchte ev. steps z. B. für die Spritpreisanzeige.
ja, man muss wissen, dass je nach Intervallgröße auch Werte unterschlagen werden.
Beispiel:
bei 1h ist ein Timeslot eine Minute,
bei 6h ist ein Timeslot 6 Minuten,
bei 24h ist ein Timeslot 24 Minuten usw.
In einem Timeslot wird immer nur ein Wert gespeichert. Wenn z. B. der Sprit bei einem 24h-Intervall innerhalb von 24 Minuten zwei Mal geändert wird, dann wird man das im Plot nicht sehen - es wird immer der letzte Wert des Timeslots genommen. Alternativ könnte man auch einen Durchschnitt der Werte nehmen oder den maximalen oder minimalen eines Timeslots - es werden in jedem Fall Daten unterschlagen.
Das festgehaltene Minimum bzw. Maximum mit der dazugehörigen Zeit ist dagegen immer korrekt.
Für eine grobe Darstellung reicht es alle Male, wer Daten statistisch auswerten will oder noch genauer untersuchen möchte, der muss sie halt loggen und per Plot darstellen.
Es ist und bleibt immer ein Kompromiss. Hier geht es um hohe Darstellungsgeschwindigkeit und geringen Speicherbedarf im Modul.
Zitat von: jkriegl am 05 April 2021, 19:36:32
Habe lange genug gewartet. s. 2. Beispiel (2 Stunden).
An der Zeit des min/max-Wertes sehe ich welche frühesten Werte verwendet werden. Das gap wird mal grösser, mal kleiner. Mein Intervall im Beispiel ist 900 sec. (Habe zum Testen rereads gemacht, um Daten zu erhalten)
Version 0.6 im ersten Post behebt dieses Verhalten.
Version 0.7 behebt das Problem, dass nach einem Neustart des Systems card nicht dargestellt wurde.
Eincheck-Kandidat Ver. 0.8. Ringgrößen wurden vereinheitlicht, Überschrift mit Icon ausgerichtet. Die Collector-Angabe col ohne Zahl ist auf 24h voreingestellt.
Es sind keine Warnung mehr bei mir gekommen. Wenn keine Probleme oder Verbesserungsvorschläge mehr gemeldet werden, dann werde ich diese Version bald einchecken.
Hier der aktuelle Layoutvergleich ohne und mit Header.
Sieht sehr gut aus!
Was sich mir noch nicht ganz erschließt ist der Mechanismus der Datensammlung. Was triggert denn das Speichern eines neuen Wertes im Ringspeicher? Reicht es dafür, die Funktion card irgendwo (z.B. in der myUtils) eingebaut zu haben? Muss man sie regelmäßig aufrufen? Oder muss sie in einem DOIF mit uiTable stehen?
Was wird in der unteren Zeile dargestellt?
Ich vermute min-max, aber da wären entweder die Dreiecke vertauscht oder die Werte.
Zitat von: xenos1984 am 07 April 2021, 14:34:47
Sieht sehr gut aus!
Was sich mir noch nicht ganz erschließt ist der Mechanismus der Datensammlung. Was triggert denn das Speichern eines neuen Wertes im Ringspeicher? Reicht es dafür, die Funktion card irgendwo (z.B. in der myUtils) eingebaut zu haben? Muss man sie regelmäßig aufrufen? Oder muss sie in einem DOIF mit uiTable stehen?
Es ist etwas tricky. Die Angabe [<device>:<reading>:col<zahl>] muss irgendwo im DOIF stehen, damit entsprechende Triggermechanismen vom Modul aufgesetzt werden können. Das Ergebnis der Angabe ist aber kein Wert, sondern eine Referenz auf einen Hash mit den gesammelten Daten.
Die card-Funktion erwartet als ersten Parameter diese Referenz, um auf die erforderlichen Informationen, die dort abgelegt sind, zuzugreifen.
Da card eine Perlfunktion ist, kann man sie natürlich auslagern. Wichtig ist, dass in uiTable die Angabe mit [dev:reading:col] angegeben wird, damit das Modul entsprechende Triggermechanismen aufsetzen kann.
Im Gegensatz zu anderen SVG-Funktionen würde card z. B. in devIcon nicht funktionieren, weil der entsprechende Hash mit den gesammelten Daten fehlen würde.
Was aber funktioniert ist so etwas:
defmod di_collect_test DOIF ##
attr di_collect_test uiTable {package ui_Table;;\
sub test {\
my ($value)=@_;;\
card($value,undef,"weather_rain_gauge",0,100,undef,undef,"unit")\
}\
}\
test([test:state:col1])\
## entspricht card([test:state:col1],undef,"weather_rain_gauge",0,100,undef,undef,"unit")
Man kann natürlich auch auf die internen Daten über die Referenz zugreifen, wenn man den Aufbau kennt:
z. B.
${[test:state:col1]}{value}
liefert den aktuellen Wert, hinter [test:state:col1] verbirgt sich auch nur eine Perlfunktion.
Auf diese Weise hat man alle Möglichkeiten, die es in Perl gibt, für den Anwender bleibt dagegen die Definition überschaubar, ohne dass man ihm die internen Mechanismen erklären muss.
Zitat von: rabehd am 07 April 2021, 15:34:08
Was wird in der unteren Zeile dargestellt?
Ich vermute min-max, aber da wären entweder die Dreiecke vertauscht oder die Werte.
ja, wenn Pfeil nach oben das Maximum anzeigen soll und nicht dass es heraufgeht, weil es ein Minimum ist, dann muss ich die noch tauschen. :)
Zitat von: Damian am 07 April 2021, 15:51:59
ja, wenn Pfeil nach oben das Maximum anzeigen soll und nicht dass es heraufgeht, weil es ein Minimum ist, dann muss ich die noch tauschen. :)
Ich würde es so sehen.
Neue Version wurde eingecheckt.
siehe: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM?order=date&desc=1
Man kann jetzt beim Headertext auch Style-Attribute angeben.
Doku kommt wie immer ins Wiki.
card ($collected_reading,$title,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$model,$lightness)
Ich spiele mit $minColor und $maxColor herum. Ohne sichtbae Veränderung.
Welche Anzeige sollte sich da eigentlich ändern?
Zitat von: rabehd am 07 April 2021, 20:15:15
card ($collected_reading,$title,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$model,$lightness)
Ich spiele mit $minColor und $maxColor herum. Ohne sichtbae Veränderung.
Welche Anzeige sollte sich da eigentlich ändern?
Vom Ring und Plot, es sei denn du hast eine colorFunction angegeben
Zu den Farbverläufen im Plot muss man sagen, dass sie sich immer am höchsten dargestellten Punkt des Plots orientieren, die Werte dazwischen werden dann von Javascript berechnet und stimmen nicht mit den errechneten Farben der jeweiligen Werte, so wie auch beim Ringfarbenverlauf, überein.
Der erste Wiki-Eintrag ist auch schon da: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Ich werde noch schönere Verläufe über 24 Stunden abbilden, aber so viel Zeit hatte ich für die Erstellung noch nicht gehabt :)
Unter "Anwendungensbeispiele" werde ich später eine Wetterstation von hier https://forum.fhem.de/index.php/topic,119612.msg1140489.html#msg1140489 mit card-Funktionen visualisieren.
Moin,
habe heute morgen das Update gemacht, und wollte direkt die neue "Card"-Funktion testen.
Die läuft bei mir nicht, und im Log sehe ich folgenden Eintrag:
2021.04.08 09:19:14.803 3: di_WetterCard:Warning in DOIF_RegisterEvalAll:'error Undefined subroutine &main::card called at (eval 5877) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','rain','','col6'),undef,"weather_rain_gauge",0,10,180,270,"mm/h")'
Das Device "WeatherScreenPro" nutze ich mit den Readings fehlerfrei im ui-Table. Wo liegt der Fehler den ich hier nicht sehe ?
Hier noch das List: (Device ist jetzt deaktiviert damit es mir nicht das Log zumüllt bis ich den Fehler gefunden hab)
Internals:
DEF ##
FUUID 606e8af0-f33f-7539-bb2c-733e53a8c56f6d1e
MODEL FHEM
NAME di_WetterCard
NOTIFYDEV global
NR 1567
NTFY_ORDER 50-di_WetterCard
STATE deactivated
TYPE DOIF
VERSION 24173 2021-04-07 17:28:37
READINGS:
2021-04-08 09:18:54 mode deactivated
2021-04-08 09:18:54 state deactivated
Regex:
condition:
do:
0:
helper:
DEVFILTER ^global$
NOTIFYDEV global
uiTable:
dev WeatherScreenPro
package
reading pressureAbs
table:
0:
0:
0:
0 'error Undefined subroutine &main::card called at (eval 5874) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','temperature','','col6'),undef,"temp_outside",-10,30,undef,undef,"°C",\&temp_hue)'
1:
0:
0 'error Undefined subroutine &main::card called at (eval 5875) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','humidity','','col6'),undef,"temperature_humidity",0,100,undef,undef,"%",\&hum_hue)'
2:
0:
0 'error Undefined subroutine &main::card called at (eval 5876) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','wind_speed','','col6'),undef,::ReadingValDoIf($hash,'WeatherScreenPro','wind_speed') > 0 ? "wind".",1,0,0,".::ReadingValDoIf($hash,'WeatherScreenPro','wind_direction'):"no_wind",0,50,120,0,"km/h",undef,1)'
1:
0:
0:
0 'error Undefined subroutine &main::card called at (eval 5877) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','rain','','col6'),undef,"weather_rain_gauge",0,10,180,270,"mm/h")'
1:
0:
0 'error Undefined subroutine &main::card called at (eval 5878) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','UV','','col6'),undef,"sani_solar",,0,10,200,0,"UV",undef,0)'
2:
0:
0 'error Undefined subroutine &main::card called at (eval 5879) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','luminosity','','col6'),undef,"sani_solar",,0,10,200,0,"UV",undef,0)'
3:
0:
0 'error Undefined subroutine &main::card called at (eval 5880) line 1.
in expression: card(::ReadingValDoIf($hash,'WeatherScreenPro','pressureAbs','','col6'),undef,"weather_barometric_pressure",980,1047,undef,undef,"hPa",[(1008.5,0,1018.5,270,1047,190)],0,undef,'0,1,1,6',",40,45,45,,45")'
tc:
td:
0:
1:
tr:
Attributes:
disable 1
room 00_Wetter
uiTable ##card ($collect,$header,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$size,$model,$lightness)|
card([WeatherScreenPro:temperature:col6],undef,"temp_outside",-10,30,undef,undef,"°C",\&temp_hue)|
card([WeatherScreenPro:humidity:col6],undef,"temperature_humidity",0,100,undef,undef,"%",\&hum_hue)|
card([WeatherScreenPro:wind_speed:col6],undef,[WeatherScreenPro:wind_speed] > 0 ? "wind".",1,0,0,".[WeatherScreenPro:wind_direction]:"no_wind",0,50,120,0,"km/h",undef,1)
card([WeatherScreenPro:rain:col6],undef,"weather_rain_gauge",0,10,180,270,"mm/h")|
card([WeatherScreenPro:UV:col6],undef,"sani_solar",,0,10,200,0,"UV",undef,0)|
card([WeatherScreenPro:luminosity:col6],undef,"sani_solar",,0,10,200,0,"UV",undef,0)|
card([WeatherScreenPro:pressureAbs:col6],undef,"weather_barometric_pressure",980,1047,undef,undef,"hPa",[(1008.5,0,1018.5,270,1047,190)],0,undef,'0,1,1,6',",40,45,45,,45")
Du hast das Package nicht definiert. Siehe Bespiele im Wiki.
Danke.... wer lesen kann.... ::)
Ich habe noch ein nettes Feature eingebaut.
Der maximale, der minimale und der aktuelle Wert werden jetzt im Graphen als Punkt markiert.
Edit: etwas transparent dargestellt
Jetzt wird der aktuelle Punkt mit einer dezenten Animation dargestellt :)
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM?order=date&desc=1
Bekomme seit dem heutigen update (9.4.) log-Eintragungen
2021.04.09 17:33:00 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'Sprit','Allg-e10','','col3'),undef,"fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,"Allg",undef,"3,font-weight:big,font-size:70%;fill:white",100),"")
2021.04.09 17:33:00 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_1_0_0',card(::ReadingValDoIf($hash,'Sprit','HEM-e10','','col3'),"HEM","fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,::ReadingValDoIf($hash,'Sprit','HEM-e5'),undef,3,80),"")
2021.04.09 17:33:51 1: ERROR: Another HttpUtils_NonblockingGet with the same hash is in progress
2021.04.09 17:33:51 1: stacktrace:
2021.04.09 17:33:51 1: main::HttpUtils_NonblockingGet called by FHEM/HttpUtils.pm (889)
2021.04.09 17:33:51 1: main::HttpUtils_ParseAnswer called by FHEM/HttpUtils.pm (642)
2021.04.09 17:33:51 1: main::__ANON__ called by fhem.pl (770)
2021.04.09 17:33:51 2: LuftdatenInfo (zehnfeldstr) - error while request: Another HttpUtils_NonblockingGet with the same hash is in progress
Hatte davor ordentlich funktioniert
Hast du das System nach dem Update durchgestartet?
fhem shutdown restart ja oder soll alles neustarten?
Zitat von: jkriegl am 09 April 2021, 18:26:59
fhem shutdown restart ja oder soll alles neustarten?
Das sollte ausreichen, aber die Warnung aus dem DOIF hat aber nichts mit dem HTTP-Problem zu tun, die kommt 51 Sekunden später.
Irgendwie streiten sich das device LuftdatenInfo und di_collect_tanke
Aus di_collect_tanke habe ich card für LuftdatenInfo gelöscht, keine Änderung.
Ich werde di_collect_tanke löschen und schauen, ob LuftdatenInfo wieder läuft.
Hat natürlich nichts gebracht. Muss wohl LuftdatenInfo neu anlegen.
Habe leider keine Ahnung, wie man die hash-Leiche die durch das Löschen des Devices auch nicht freigegeben wurde, los wird.
Anbei das Log nach update und fhem shutdown restart.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/98_DOIF.pm line 4603.
2021.04.09 13:37:21 3: di_collect:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'muc','temperature','','col6'),undef,"temp_outside",-5,15,undef,undef,"°C",\&temp_hue,1,100)
2021.04.09 13:37:21 3: di_collect:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'muc','pressure','','col6'),undef,"weather_barometric_pressure\@".(::ReadingValDoIf($hash,'muc','press-trend')eq"+"?"#00f700":(::ReadingValDoIf($hash,'muc','press-trend')eq"-"?"Darkorange":"white")),990,1040,0,120,::ReadingValDoIf($hash,'muc','press-trend'),undef,0,100)
2021.04.09 13:37:21 3: di_collect:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'muc','windSpeed','','col6'),undef,"weather_wind_directions_".::ReadingValDoIf($hash,'muc','windDirIcon'),0,50,120,0,::ReadingValDoIf($hash,'muc','windDirText'),undef,1,100)
2021.04.09 13:37:21 3: di_collect_sonne:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'Astro','SunAlt','','col12'),undef,"weather_sun\@".(::ReadingValDoIf($hash,'Astro','SunAlt')>0?"yellow":"Gray"),0,90,110,20,::ReadingValDoIf($hash,'Astro','SunRise').::ReadingValDoIf($hash,'Astro','SunSet'),undef,"0,font-weight:big,font-size:70%;fill:white",100)
2021.04.09 13:37:21 3: di_collect_sonne:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'muc','solar','','col12'),undef,"message_light_intensity\@".(::ReadingValDoIf($hash,'Astro','SunAlt')>10?"yellow":"Gray"),0,1000,120,0,"W/m²",undef,0,100)
2021.04.09 13:37:21 3: di_collect_sonne:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'Astro','MoonAlt','','col12'),undef,"weather_moon_phases_".::ReadingValDoIf($hash,'di_collect_sonne','m_phase')."\@".(::ReadingValDoIf($hash,'Astro','MoonAlt')>0?"White":"Gray"),0,90,110,20,::ReadingValDoIf($hash,'Astro','MoonRise').::ReadingValDoIf($hash,'Astro','MoonSet'),undef,"0,font-weight:big,font-size:70%;fill:white",100)
2021.04.09 13:37:21 3: di_collect_tanke:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'Sprit','Allg-e10','','col3'),undef,"fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,"Allg",undef,"3,font-weight:big,font-size:70%;fill:white",100)
2021.04.09 13:37:21 3: di_collect_tanke:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'Sprit','HEM-e10','','col3'),"HEM","fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,::ReadingValDoIf($hash,'Sprit','HEM-e5'),undef,3,80)
2021.04.09 13:37:21 3: di_collect_tanke:Warning in DOIF_RegisterCell:package ui_Table;.card(::ReadingValDoIf($hash,'zehnfeldstr','PM10','','col6'),undef,"feinstaub_pm10",0,40,110,10,::ReadingValDoIf($hash,'zehnfeldstr','PM10_avg_day'),undef,1,100)
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/98_DOIF.pm line 4410.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/98_SVG.pm line 238.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $_ in substitution (s///) at FHEM/HttpUtils.pm line 51.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_SVG.pm line 583.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_CSRF in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2674.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2678.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2678.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/98_SVG.pm line 259.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $pm in string eq at ./FHEM/98_SVG.pm line 261.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $pm in string eq at ./FHEM/98_SVG.pm line 285.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $pm in string eq at ./FHEM/98_SVG.pm line 287.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2644.
2021.04.09 13:37:21 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 2644.
2021.04.09 13:37:21 3: di_ui_t4:Warning in DOIF_RegisterCell:.my $pH = {}; SVG_FwFn("WEB","SVG_luft","",$pH);
2021.04.09 13:37:21 0: Featurelevel: 6
2021.04.09 13:37:21 0: Server started with 107 defined entities (fhem.pl:23904/2021-03-07 perl:5.028001 os:linux user:fhem pid:18406)
2021.04.09 13:37:21 1: devStateIcon di_new_func: Undefined subroutine &ui_Table::iconlabel called at (eval 419) line 1.
2021.04.09 13:37:21 3: di_collect:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'muc','temperature','','col6'),undef,"temp_outside",-5,15,undef,undef,"°C",\&temp_hue,1,100),"")
2021.04.09 13:37:21 3: di_collect:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_uiTable_c_0_1_0_0',card(::ReadingValDoIf($hash,'muc','pressure','','col6'),undef,"weather_barometric_pressure\@".(::ReadingValDoIf($hash,'muc','press-trend')eq"+"?"#00f700":(::ReadingValDoIf($hash,'muc','press-trend')eq"-"?"Darkorange":"white")),990,1040,0,120,::ReadingValDoIf($hash,'muc','press-trend'),undef,0,100),"")
2021.04.09 13:37:21 3: di_collect:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_uiTable_c_0_2_0_0',card(::ReadingValDoIf($hash,'muc','windSpeed','','col6'),undef,"weather_wind_directions_".::ReadingValDoIf($hash,'muc','windDirIcon'),0,50,120,0,::ReadingValDoIf($hash,'muc','windDirText'),undef,1,100),"")
2021.04.09 13:37:21 3: di_collect_sonne:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_sonne_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'Astro','SunAlt','','col12'),undef,"weather_sun\@".(::ReadingValDoIf($hash,'Astro','SunAlt')>0?"yellow":"Gray"),0,90,110,20,::ReadingValDoIf($hash,'Astro','SunRise').::ReadingValDoIf($hash,'Astro','SunSet'),undef,"0,font-weight:big,font-size:70%;fill:white",100),"")
2021.04.09 13:37:21 3: di_collect_sonne:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_sonne_uiTable_c_0_1_0_0',card(::ReadingValDoIf($hash,'muc','solar','','col12'),undef,"message_light_intensity\@".(::ReadingValDoIf($hash,'Astro','SunAlt')>10?"yellow":"Gray"),0,1000,120,0,"W/m²",undef,0,100),"")
2021.04.09 13:37:22 3: di_collect_sonne:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_sonne_uiTable_c_0_2_0_0',card(::ReadingValDoIf($hash,'Astro','MoonAlt','','col12'),undef,"weather_moon_phases_".::ReadingValDoIf($hash,'di_collect_sonne','m_phase')."\@".(::ReadingValDoIf($hash,'Astro','MoonAlt')>0?"White":"Gray"),0,90,110,20,::ReadingValDoIf($hash,'Astro','MoonRise').::ReadingValDoIf($hash,'Astro','MoonSet'),undef,"0,font-weight:big,font-size:70%;fill:white",100),"")
2021.04.09 13:37:22 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'Sprit','Allg-e10','','col3'),undef,"fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,"Allg",undef,"3,font-weight:big,font-size:70%;fill:white",100),"")
2021.04.09 13:37:22 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_1_0_0',card(::ReadingValDoIf($hash,'Sprit','HEM-e10','','col3'),"HEM","fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,::ReadingValDoIf($hash,'Sprit','HEM-e5'),undef,3,80),"")
2021.04.09 13:37:22 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_2_0_0',card(::ReadingValDoIf($hash,'zehnfeldstr','PM10','','col6'),undef,"feinstaub_pm10",0,40,110,10,::ReadingValDoIf($hash,'zehnfeldstr','PM10_avg_day'),undef,1,100),"")
2021.04.09 13:37:22 1: PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at ./FHEM/98_DOIF.pm line 237.
2021.04.09 13:37:22 1: PERL WARNING: Use of uninitialized value $reading in concatenation (.) or string at ./FHEM/98_DOIF.pm line 237.
2021.04.09 13:37:22 1: PERL WARNING: Use of uninitialized value $dev in concatenation (.) or string at ./FHEM/98_DOIF.pm line 237.
2021.04.09 13:37:22 1: ERROR: Another HttpUtils_NonblockingGet with the same hash is in progress
2021.04.09 13:37:22 1: stacktrace:
2021.04.09 13:37:22 1: main::HttpUtils_NonblockingGet called by FHEM/HttpUtils.pm (889)
2021.04.09 13:37:22 1: main::HttpUtils_ParseAnswer called by FHEM/HttpUtils.pm (642)
2021.04.09 13:37:22 1: main::__ANON__ called by fhem.pl (770)
2021.04.09 13:37:22 1: devStateIcon di_new_func: Undefined subroutine &ui_Table::iconlabel called at (eval 585) line 1.
2021.04.09 13:37:28 1: Mi_Gw: connect> Ping to 192.168.178.99 failed
2021.04.09 13:42:28 1: ERROR: Another HttpUtils_NonblockingGet with the same hash is in progress
2021.04.09 13:42:28 1: stacktrace:
2021.04.09 13:42:28 1: main::HttpUtils_NonblockingGet called by FHEM/HttpUtils.pm (889)
2021.04.09 13:42:28 1: main::HttpUtils_ParseAnswer called by FHEM/HttpUtils.pm (642)
2021.04.09 13:42:28 1: main::__ANON__ called by fhem.pl (770)
2021.04.09 13:44:28 2: AttrTemplates: got 237 entries
2021.04.09 13:44:28 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE K.*$/ at ./FHEM/33_readingsGroup.pm line 1076.
2021.04.09 13:44:28 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE K.*$/ at ./FHEM/33_readingsGroup.pm line 1081.
2021.04.09 14:42:20 1: ERROR: Another HttpUtils_NonblockingGet with the same hash is in progress
2021.04.09 14:42:20 1: stacktrace:
2021.04.09 14:42:20 1: main::HttpUtils_NonblockingGet called by FHEM/HttpUtils.pm (889)
2021.04.09 14:42:20 1: main::HttpUtils_ParseAnswer called by FHEM/HttpUtils.pm (642)
2021.04.09 14:42:20 1: main::__ANON__ called by fhem.pl (770)
2021.04.09 15:16:12 1: devStateIcon di_new_func: Undefined subroutine &ui_Table::iconlabel called at (eval 6803) line 1.
2021.04.09 15:16:12 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'Sprit','Allg-e10','','col3'),undef,"fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,"Allg",undef,"3,font-weight:big,font-size:70%;fill:white",100),"")
2021.04.09 15:16:12 3: di_collect_tanke:Warning in DOIF_RegisterEvalAll:package ui_Table;::DOIF_Widget($hash,$reg,'di_collect_tanke_uiTable_c_0_1_0_0',card(::ReadingValDoIf($hash,'Sprit','HEM-e10','','col3'),"HEM","fuel",::ReadingValDoIf($hash,'Sprit','e10min'),::ReadingValDoIf($hash,'Sprit','e10min')+0.1,110,20,::ReadingValDoIf($hash,'Sprit','HEM-e5'),undef,3,80),"")
Poste mal deine aktive DOIF-Version.
98_DOIF.pm 24195 2021-04-08 21:50:20Z Damian
doif.js 15546 2017-12-03 09:57:42Z Ellert
f18.js 24045 2021-03-21 19:03:30Z rudolfkoenig
fhemweb.js 23979 2021-03-15 14:00:33Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Zitat von: jkriegl am 09 April 2021, 20:39:19
98_DOIF.pm 24195 2021-04-08 21:50:20Z Damian
doif.js 15546 2017-12-03 09:57:42Z Ellert
f18.js 24045 2021-03-21 19:03:30Z rudolfkoenig
fhemweb.js 23979 2021-03-15 14:00:33Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
OK. Das ist die aktuelle. Keine Ahnung, da ist wohl einiges bei dir im Argen. Am besten alle card-Definitionen raus nehmen, schauen, ob alle Meldungen weg sind und dann langsam in kleinen Schritten einzelne cards definieren.
Alle card-Definitionen gelöscht. (Diese hatten übrigens noch funktioniert.) Nur LuftdatenInfo hat das Problem.
Leider keine Änderung.
LuftdatenInfo hatte ich auch im devStateIcon. Leider kann ich dieses device zwar neu anlegen, bekopmme aber den Fehler.
Da hilft wohl nur ein restore und LuftdatenInfo aus devStateIcon entfernen.
Neue Version wurde eingecheckt: Der Farbverlauf passt jetzt besser zu der Farbe der jeweiligen Werte.
Und hier ein Wiki-Beitrag zur Anwendung: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Visualisierung:_Wetterstation
Hi Damian,
die Cards sind klasse. Einziger Schönheitsfehler (aus meiner Sicht): Ich verwende ein "bright" Farbschema, d.h. heller Hintergrund. Da wirken die Cards nicht soooo gut... Wäre es möglich ein paar Farben, insbesondere den Hintergrund und die Schriften einstellbar machen? Auf die schnelle würde mir schon reichen, den Hintergrund transparent und die Schrift schwarz zu machen...
Danke,
Oli
Zitat von: KernSani am 12 April 2021, 23:48:35
Hi Damian,
die Cards sind klasse. Einziger Schönheitsfehler (aus meiner Sicht): Ich verwende ein "bright" Farbschema, d.h. heller Hintergrund. Da wirken die Cards nicht soooo gut... Wäre es möglich ein paar Farben, insbesondere den Hintergrund und die Schriften einstellbar machen? Auf die schnelle würde mir schon reichen, den Hintergrund transparent und die Schrift schwarz zu machen...
Danke,
Oli
Das Thema hatten wir schon öfters bei den ring-Funktionen. Ich habe immer wieder damit experimentiert und habe mich bewusst dagegen entschieden. Das Problem ist die dynamische Farbgebung, die dazu führt, dass bestimmte Farben auf hellen Hintergründen nicht gut sichtbar sind. Ich habe die Deckung des Hintergrunds bei card auf 90 % eingestellt, dabei wird bereits rot/lila beim hellen Style schon kritisch . Man könnte die Farben zwar abdunkeln, aber dann kann man sie auch nicht mehr gut unterscheiden.
Ich finde die dunklen cards auf hellen Hintergründen wirken sogar besser, als die in der Luft hängend wirkenden dunklen Ringe.
Hi Damian,
sehr schön geworden! Habe es meinem CO2 Sensor spendiert und da passt es auch gut.
2 kleine Sachen würde ich anders darstellen, vielleicht hast Du ja Lust, da noch zu optimieren:
- die Zeile für min/max ganz unten. Zuerst musste ich eine Weile überlegen, was denn da eigentlich angezeigt wird, dann wurde es klar. Es würde vermutlich besser aussehen, wenn die Teile, die zusammen gehören, auch zusammen stehen.
aktuell:
▲20:51 670 ▼16:11 440
besser:
▲20:51 670 ▼16:11 440
oder sogar:
▼16:11 440 670 20:51▲
oder
16:11▼ 440 670 ▲20:51
oder, oder.. auf jeden Fall sollten die Zeit und der Wert beieinander stehen.
- die Zeitskala: die Farbe ist ja nicht anpassbar (oder ich habs übersehen?), aber das helle weiss ist mMn zu hell. Bei einem dunklen, mit dezenten Farben gestaltetem UI "leuchten" die Beschriftungen sehr hell und machen sich dadurch wichtiger, als sie sind. #CCCCCC sollte da genügen.
Wie gesagt, ist nur Kosmetik.
Vielen Dank fürs drüber Nachdenken ;)
Sany
Zitat von: Damian am 13 April 2021, 07:54:47
Das Thema hatten wir schon öfters bei den ring-Funktionen. Ich habe immer wieder damit experimentiert und habe mich bewusst dagegen entschieden. Das Problem ist die dynamische Farbgebung, die dazu führt, dass bestimmte Farben auf hellen Hintergründen nicht gut sichtbar sind. Ich habe die Deckung des Hintergrunds bei card auf 90 % eingestellt, dabei wird bereits rot/lila beim hellen Style schon kritisch . Man könnte die Farben zwar abdunkeln, aber dann kann man sie auch nicht mehr gut unterscheiden.
Die Erkennbarkeit mancher Farben ist in der Tat ein Problem, wie man ja auch an meinem Screenshot erkennen kann. Vielleicht experimentiere ich mal noch ein bisschen weiter...
Zitat
Ich finde die dunklen cards auf hellen Hintergründen wirken sogar besser, als die in der Luft hängend wirkenden dunklen Ringe.
Ich mag meine in der Luft hängenden Kugeln :-)
Für die Timerangaben werde ich bestimmt noch SVG-Attribute einbauen, wie jetzt schon beim Header. Ich habe einen Trenner dazwischen geklemmt, damit sollte die Zuordnung besser erkennbar sein.
So sieht es mit lightgray statt white als Default aus.
Neue Version eingecheckt. Jetzt wird der Bereich unter oder oberhalb der x-Achse ausgeblendet, wenn dort keine Daten vorkommen. Das ist insbesondere bei Temperaturen interessant, die sowohl im positiven als auch im negativen Bereich vorkommen können. Damit wird die y-Skalierung besser ausgenutzt.
Und so sieht es aus. Die gleiche Definition (-10 bis 30) mit positiven und negativen Werten und nur mit positiven Werten.
Bei mir vor/nach update so. Benutze F8 unverändert.
Der negative Sonnen/Mond-Stand war doch nicht so schlecht.
Bei Tanke, etwas das ein/ausgeschaltet wird, wäre statt Linie Step deutlich besser, da so etwas nicht linear abfällt oder anhebt
Zitat von: jkriegl am 14 April 2021, 12:23:40
Bei mir vor/nach update so. Benutze F8 unverändert.
Der negative Sonnen/Mond-Stand war doch nicht so schlecht.
Bei Tanke, etwas das ein/ausgeschaltet wird, wäre statt Linie Step deutlich besser, da so etwas nicht linear abfällt oder anhebt
Du hast keine negativen Werte, daher wird der negative Bereich nicht angezeigt. Wenn du welche hast, dann wirst du den auch sehen, so wie vorhin.
Für Step braucht man doppelt so viele Punkte, ich weiß nicht ob das nötig ist.
Warum ist die Schrift bei dir Schwarz?
negative Werte: dann habe ich die Änderungsbeschreibung nicht verstanden - abwarten.
Steps: wenn man bei einem neuen Wert alte Werte in den nicht gefüllten slots weiterführt? s. Tanke-Beispiel
schwarze Schrift?? keine Ahnung: f18, anbei mystyle
Die Schriftattribute für die Zeiten werden intern vergeben und haben nichts mit dem Style zu tun. Schau mal, ob es evtl. mit dem Browser zusammen hängt.
Browser: - Firefox aktuell, Themes Standard
- MS Edge gleiches Bild
- android firefox gleiches Bild
edit: Windows Internet Explorer gleiches Bild
Zitat von: Damian am 13 April 2021, 17:56:49
Neue Version eingecheckt. Jetzt wird der Bereich unter oder oberhalb der x-Achse ausgeblendet, wenn dort keine Daten vorkommen. Das ist insbesondere bei Temperaturen interessant, die sowohl im positiven als auch im negativen Bereich vorkommen können. Damit wird die y-Skalierung besser ausgenutzt.
Finde ich nicht optimal. Das reine Ausblenden des positiven oder negativen Bereiches ist für mich eine Krücke.
Schöner fände ich die Skalierung der y-Achse anhand der min/max Werte.
Da mir eine y-Achse bei Temperaturen von -20 bis 40 nicht gefällt, habe ich erstmal die min/max Werte der letzten 7 Tage genommen. Später soll da noch eine Funktion schönere Werte bilden.
Zitat von: rabehd am 14 April 2021, 16:22:30
Finde ich nicht optimal. Das reine Ausblenden des positiven oder negativen Bereiches ist für mich eine Krücke.
Schöner fände ich die Skalierung der y-Achse anhand der min/max Werte.
Da mir eine y-Achse bei Temperaturen von -20 bis 40 nicht gefällt, habe ich erstmal die min/max Werte der letzten 7 Tage genommen. Später soll da noch eine Funktion schönere Werte bilden.
Eine dynamisch Anpassung mit (min/max) habe ich schon programmiert. Das wird wahrscheinlich optional kommen.
Zitat von: jkriegl am 14 April 2021, 16:00:15
Browser: - Firefox aktuell, Themes Standard
- MS Edge gleiches Bild
- android firefox gleiches Bild
edit: Windows Internet Explorer gleiches Bild
Merkwürdig, dann bin ich gespannt, ob das Problem noch bei anderen auftritt.
Das mit einem dynamischen min/max Wert funktioniert bei svg-plot sehr gut. (Bei den Spritpreisen verschiebt sich die Bandbreite häufiger.)
Hier verwende ich [device:min-Wert], also keinen absoluten Wert. Soweit ich gesehen habe muss man neu initialisieren, falls sich der min-Wert geändert hat. Habe noch nicht getestet, ob mit einem event auf min-Wert aktualisiert wird.
Zitat von: jkriegl am 14 April 2021, 17:13:09
Das mit einem dynamischen min/max Wert funktioniert bei svg-plot sehr gut. (Bei den Spritpreisen verschiebt sich die Bandbreite häufiger.)
Hier verwende ich [device:min-Wert], also keinen absoluten Wert. Soweit ich gesehen habe muss man neu initialisieren, falls sich der min-Wert geändert hat. Habe noch nicht getestet, ob mit einem event auf min-Wert aktualisiert wird.
Das würde wahrscheinlich sogar funktionieren, aber dann würdest du auch die Farbzuordnung verändern - also auch nur eine Krücke.
Ich muss mir noch überlegen, in welchem Argument ich weitere Eigenschaften von card unterbringe - da werden bestimmt noch einige kommen :)
Der eine mag es so, der andere so. Ich habe auch eine Zeit lang dynamische svg-plots benutzt, man kann besser kleine Änderungen erkennen, der Nachteil ist wieder, dass man nicht intuitiv die Größenordnung wahrnimmt - man muss genau auf die Skalenbeschreibung achten.
Ein weiterer Nachteil bei SVG-Plots ist, dass bei mehrfarbigen Plots, der höchste Punkt immer die gleiche Farbe annimmt, damit kann man sich nicht an den Farben orientieren. Bei card hat der gleiche Wert immer die gleiche Farbe, egal wie die Grafik skaliert ist.
ja es funktioniert.
card([Sprit:HEM-e10:col3],"HEM","fuel",[Sprit:e10min],
[Sprit:e10min]+.1,100,15,[Sprit:HEM-e5],undef,3,80)
zur Farbverschiebung: wenn ich Spritpreise vergleiche ist eine Farbverschiebung egal, grün ist günstig, gelb geht, rot ist zu vermeiden.
bei Temperaturen wäre eine Farbfestlegung z.B. -10 bis 40 fix, Anzeigebereich (dynamisch) min-Wert bis max-Wert, da man dabei mehr Details sieht.
Nachtrag: wenn ich im Sommer 10 - 40 anzeige macht bei 12°C eine kalte Farbe viel Sinn, weil ich es so empfinde, ist also die Farbe relativ zum Anzeigebereich nicht besser?
Zu meiner Antwort #50 und update gestern:
Nach restore 98_DOIF.pm auf die Version
98_DOIF.pm 24210 2021-04-10 18:05:36Z Damian
sind die Farben ok.
Aktuell ist bei mir die Beschriftung in Schwarz. Außer dem normalen Update gibt es aber keine Änderung.
Zitat von: rabehd am 15 April 2021, 13:11:58
Aktuell ist bei mir die Beschriftung in Schwarz. Außer dem normalen Update gibt es aber keine Änderung.
Also bei mir Windows/Chrome funktioniert die Farbe. Entweder ist die Farbe in eurer Betriebssystem/Browser-Kombination unbekannt oder es gibt Probleme mit der Farbe bei den SVG-Gruppen-Attributen.
Betriebssystem/Browser-Kombination ist eher unwahrscheinlich, da gleiches Verhalten auch auf android besteht (bzw. edge) oder es funktioniert nur bei windows/chrome.
Wie können wir bei svg-Gruppen-Attributen testen?
Zitat von: jkriegl am 15 April 2021, 14:42:40
Betriebssystem/Browser-Kombination ist eher unwahrscheinlich, da gleiches Verhalten auch auf android besteht (bzw. edge) oder es funktioniert nur bei windows/chrome.
Wie können wir bei svg-Gruppen-Attributen testen?
erster Versuch: lightgray gegen #CCCCCC getauscht
Bitte testen.
Leider negativ, Problem ist wieder da.
Zitat von: jkriegl am 15 April 2021, 18:41:01
Leider negativ, Problem ist wieder da.
Das sollte jetzt aber klappen.
Zitat von: rabehd am 16 April 2021, 09:03:50
tut es, danke
Korrigierte Version eingecheckt.
neue Features:
- Steps werden automatisch erkannt
- automatische Skalierung, zum Parameter size kann jetzt eine Plot-Eigenschaften angegeben werden "<size>,<Standardskalierung>", default: 0 oder keine Angabe für automatische Skalierung, 1 für Standardskalierung
- Skalenbeschriftung
- diverse Größenoptimierung, Standargröße ist jetzt 130
Edit: Ich habe mir die Plots über Nacht angeschaut und habe festgestellt, dass automatische Skalierung informativer ist, durch die feste Farbenzuordnung kann zusätzlich die Größenordnung eingeschätzt werden. Ich habe es zu default-Einstellung gemacht, siehe Paramerter <Standardskalierung>.
Eincheckkanditat:
Jetzt noch mit genauerer Zeitskalierung und automatischer Y-Skalierung, Features siehe Post zuvor.
Echt super - Danke.
Die Nachkommastellen der Skalierung entspricht scheinbar den Nachkommastellen des Ringwertes. Das ist bei Spritpreisen (3) ungünstig (bei card mit Überschrift).
Könnte man da nicht die Nachkommestellen des min/max nehmen? (sowohl, als auch bei Autoskalierung)
Habe noch die vorletzte Version
Zitat von: jkriegl am 18 April 2021, 13:34:07
Echt super - Danke.
Die Nachkommastellen der Skalierung entspricht scheinbar den Nachkommastellen des Ringwertes. Das ist bei Spritpreisen (3) ungünstig (bei card mit Überschrift).
Könnte man da nicht die Nachkommestellen des min/max nehmen? (sowohl, als auch bei Autoskalierung)
Habe noch die vorletzte Version
Wieso ist das ungünstig? Die Anzahl der angezeigten Nachkommastellen vom Ring wird ja vom Benutzer bewusst so gewählt, wie es die Genauigkeit erfordert. Beim Spritpreis eben zwei Nachkommastellen. Min/Max-Angaben haben keine Formatierungsangaben.
Bei den Zeiten fiel mir auf, dass bei kurzen Intervallen z. B. eine Stunde, die Minutenangaben wichtiger sind als die Stunden. Ich befürchte ich muss doch beides Anzeigen - dann aber ziemlich klein.
ungünstig, weil beim Sprit 3-Nachkommastellen (z.B. 1.468) nicht reinpassen.
Und wenn jemand von 0 - 60 anzeigen will und im Ring eine Nachkommastelle angegeben ist, ist die Skalierung 0.0 15.0 .. 60.0
Zitat von: jkriegl am 18 April 2021, 14:43:20
ungünstig, weil beim Sprit 3-Nachkommastellen (z.B. 1.468) nicht reinpassen.
Und wenn jemand von 0 - 60 anzeigen will und im Ring eine Nachkommastelle angegeben ist, ist die Skalierung 0.0 15.0 .. 60.0
Es passen ungefähr so viele Stellen wie in den Ring hineinpassen und umgekehrt. Selbst für Sprit würden drei Nachkommastellen passen, auch wenn die dritte Stelle mit 9 keine zusätzliche Information darstellt.
Ich will nur sagen, dass ich keine neue Syntax für die Formatierung der Achsen einführen möchte - die Attribute platzen langsam aus allen Nähten.
Neue Version eingecheckt.
Ich habe den Graphen etwas nach rechts verschoben, damit passen auch fünfstellige Skalenbeschriftungen, das sollte ausreichen.
Was mir noch aufgefallen ist. Nach dem Update nicht wundern. Am Anfang wird die vollständige y-Skalierung (min-max) angezeigt, erst wenn ein Minimum und ein Maximum mit Minimum ungleich Maximum feststeht, greift die automatische Skalierung.
Habe ein Problem mit den min-Werten. Fällt bei unterschiedlichem colx (1, 2, 12, col) auf.
Es handelt sich um eine Pumpe, mal standby mal running. Vermutlich müssten weitere events erzeugt werden, weil die running-Zeit zu kurz ist und der min-Wert verloren geht.
Anmerkungen:
Die Zeitskalierung ist jetzt schlechter lesbar, besser war s. #71
Die zusätzliche Zeitangabe unter dem ring hat zusätzlich nur Sek. Könnte da man nicht auch etwas anderes unterbringen.
Wenn ein user in der y-Beschreibung z.B. 0 bis 60 haben möchte, dann sollte dort nicht 0.0 bis 60.0 angezeigt werden. (Klar == Nachkommastellen aus ring-Wert)
Zitat von: jkriegl am 19 April 2021, 13:56:24
Habe ein Problem mit den min-Werten. Fällt bei unterschiedlichem colx (1, 2, 12, col) auf.
Es handelt sich um eine Pumpe, mal standby mal running. Vermutlich müssten weitere events erzeugt werden, weil die running-Zeit zu kurz ist und der min-Wert verloren geht.
Anmerkungen:
Die Zeitskalierung ist jetzt schlechter lesbar, besser war s. #71
Die zusätzliche Zeitangabe unter dem ring hat zusätzlich nur Sek. Könnte da man nicht auch etwas anderes unterbringen.
Wenn ein user in der y-Beschreibung z.B. 0 bis 60 haben möchte, dann sollte dort nicht 0.0 bis 60.0 angezeigt werden. (Klar == Nachkommastellen aus ring-Wert)
An der Zeitskalierung arbeite ich noch, weil mir die nicht gefällt.
Die Auflösung des Graphen ist halt nicht hoch, deswegen können je nach Zeitintervall nicht alle Details angezeigt werden - das ist klar. Die automatische Skalierung soll immer funktionieren, daher braucht man eine bestimmte Genauigkeit, beim Luftdruck wird bei kleinen Schwankungen mehrfach die gleiche Zahl auf der Y-Achse angezeigt, weil ich dort keine Nachkommastellen definiert habe - das ist das andere Extremum.
In der Tat, durch mehr events (event-min-interval:120, erste Versuche mit 10 Min) wird auch der min-Wert gespeichert.
Man sieht das am Weiterschieben der Zeitachse.
Der aktuelle Wert müsste auch gespeichert werden, insbesondere falls kein event kommt. (im nächsten slot?)
Edit: inzwischen haben auch die andern cards korrekte min-Werte.
Zitat von: jkriegl am 19 April 2021, 20:17:48
In der Tat, durch mehr events (event-min-interval:120, erste Versuche mit 10 Min) wird auch der min-Wert gespeichert.
Man sieht das am Weiterschieben der Zeitachse.
Der aktuelle Wert müsste auch gespeichert werden, insbesondere falls kein event kommt. (im nächsten slot?)
Edit: inzwischen haben auch die andern cards korrekte min-Werte.
In der aktuellen Version hatte ich eingebaut, dass im Slot der höchste positive Wert bzw. der niedrigste negative Wert des Slots gespeichert wird. Das hat aber den Nachteil, (im Gegensatz vom vorherigen Verfahren, wo der letzte Wert gespeichert wurde), dass die Werte, die sich stochastisch betrachtet am längsten halten, nämlich die letzten des Slots, untergehen. Das erklärt deine Beobachtung. Ich werde das vorherige Verhalten wieder einbauen.
Ich teste gerade Zeitachsen. Bei Stundenangaben, die sich durch 6 teilen lassen (6,12,18,24..) wird die Skalierung mit vollen Stunden, die mitwandern, angezeigt, sonst mit festen Zeitangaben mit größeren Abständen.
Neue Version eingecheckt:
-neue Zeitskalierung, wie bereits beschrieben
-Nachkommastellen auf der Y-Achse nur bei automatischer Skalierung
-steps auch explizit definierbar, siehe Parameter $prop: insb. Definition des Sprit-Preises der Beispieldefinition
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Bei negativen collect-Wert und attr <device> uiTable bekommt man
2021.04.21 12:29:25 1: PERL WARNING: Bareword found where operator expected at (eval 4882) line 2, near "'error Illegal division by zero at ./FHEM/98_DOIF.pm line 4383.
in expression: card(::ReadingValDoIf($hash,'Astro"
(Might be a runaway multi-line '' string starting on line 1)
card([Astro:MoonAlt:col12],undef,"weather_moon_phases_4",0,90,110,20,undef,undef,0,100)
Mit setreading MoonAlt positiv gesetzt dann ok.
Edit: Früheres Beispiel aus #50
Edit-2: MoonAlt ist jetzt 0 - es klappt.
Neue Version eingecheckt:
- diverse Sonderfälle werden berücksichtigt
- Layout etwas verfeinert.
So langsam kann ich keine Plots mehr sehen :)
Aktuelles Layout, siehe Anhang.
Als nächstes sollen die gesammelten Werte einen Neustart des Systems überleben.
Anwendung Spritpreise: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Visualisierung%3A_aktueller_Spritpreis
Anwendungsbeispiel Heiztherme: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Visualisierung_und_Steuerung:_Heiztherme
Auf die echten Daten muss ich noch 24 Stunden warten - "Ergebnis der Beispieldefinition in der Webansicht" wird noch aktualisiert ;)
Corona-Anwendung siehe: https://forum.fhem.de/index.php/topic,113798.msg1152222.html#msg1152222
Beim kurzen Lauf der Pumpe werden sehr viele Werte verschluckt. (col1, 2, 3, 6) Längere Zeiträume machen keinen Sinn.
Auch bei der zusätzlichen card mit Pumpenstatus 0,1,2. (col1, col2)
Ich denke, dass das Abspeichern des max-Wertes, den min-Wert merken und in den nächsten slot einstellen, falls für diesen kein event kommt, besser wäre.
2021-04-26_16:07:41 shelly_s usr: E: 14.195 P: 14.11 1 40:03
2021-04-26_16:08:10 shelly_s usr: E: 14.195 P: 4.25 0 0:29
2021-04-26_16:54:05 shelly_s usr: E: 14.196 P: 13.46 1 45:55
2021-04-26_16:54:38 shelly_s usr: E: 14.196 P: 1.46 0 0:33
2021-04-26_17:10:40 shelly_s usr: E: 14.196 P: 13.07 1 16:02
2021-04-26_17:11:02 shelly_s usr: E: 14.197 P: 3.73 0 0:22
2021-04-26_17:22:02 shelly_s usr: E: 14.197 P: 13.75 1 11:00
2021-04-26_17:22:25 shelly_s usr: E: 14.197 P: 4.34 0 0:23
2021-04-26_17:24:55 shelly_s usr: E: 14.197 P: 8.97 1 2:30
2021-04-26_17:24:56 shelly_s usr: E: 14.197 P: 62.18 2 0:01
2021-04-26_17:25:10 shelly_s usr: E: 14.197 P: 5.61 0 0:14
2021-04-26_17:38:59 shelly_s usr: E: 14.197 P: 15.03 1 13:49
2021-04-26_17:39:34 shelly_s usr: E: 14.197 P: 3.72 0 0:35
2021-04-26_18:19:53 shelly_s usr: E: 14.198 P: 10.67 1 40:19
2021-04-26_18:20:25 shelly_s usr: E: 14.198 P: 2.39 0 0:32
Klar, vorhin wurden mittlere Werte verschluckt, jetzt werden kurzfristige Werte geschluckt. Ich muss mal schauen, evtl. Extremwert speichern und den letzten des Slots in den nächsten Slot übernehmen. Wahrscheinlich kommt noch doppelte Genauigkeit mit 120 Slots.
Würde das auch als defStateIcon funktionieren? Meine Versuche sind am Syntax Error gescheitert.
{ui_Table::card([CO2:CO2:col24],undef,"air",400,1500,120,0,"ppm")}
siehe: https://forum.fhem.de/index.php/topic,120661.0.html
neue Features in Entwicklung:
-es werden jetzt 20 % mehr Punkte gespeichert, das Diagramm ist breiter - die Größe der Karte ist geblieben
-Daten werden jetzt im Modul mitgespeichert und überleben einen Neustart, dadurch können auch längere Zeiträume mit geringer Auflösung sinnvoll visualisiert werden
-neuer Algorithmus zur Speicherung der Daten, es werden Spitzenwerte (sowohl nach unten als auch nach oben) gespeichert, der letzte aktuelle Wert wird in den folgenden Zeitslot gerettet, falls dieser nicht belegt wird
-Beim Ring sind die Proportionen zwischen Schrift und Icon angepasst worden, die Farben von Icon, Unit und schmalen Ring sind im Default-Fall etwas dunkler, damit sich die Zahl besser abheben kann.
Die aktuelle Version wird noch getestet.
Im Anhang der gleiche Sensor in verschiedenen Zeitskalierungen.
Hallo,
wenn ich bei der neuen Funktion "card" ein Reading auslesen möchte, was nicht rein numerisch ist, z.B. "1 W", so bekomme ich im Log eine Fehlermeldung, aber der Wert wird dennoch angezeigt.
In einem DOIF würde ich das eingrenzen über [Device:reading:d]. Hier funktioniert das aber nicht, und ich müsste jetzt im DOIF-Card ein entsprechend gefiltertes Userreadiing anlegen.
Geht das auch "einfacher", bzw. habe ich hier irgendwas übersehen ?
LG
Zitat von: Bartimaus am 06 Mai 2021, 15:02:52
Hallo,
wenn ich bei der neuen Funktion "card" ein Reading auslesen möchte, was nicht rein numerisch ist, z.B. "1 W", so bekomme ich im Log eine Fehlermeldung, aber der Wert wird dennoch angezeigt.
In einem DOIF würde ich das eingrenzen über [Device:reading:d]. Hier funktioniert das aber nicht, und ich müsste jetzt im DOIF-Card ein entsprechend gefiltertes Userreadiing anlegen.
Geht das auch "einfacher", bzw. habe ich hier irgendwas übersehen ?
LG
Es wird ohnehin schon nach Zahlen gefiltert, ich werde in der kommenden Version die Warnung ausbauen.
Noch eine Idee zur Datensammlung und Darstellung: könnte man für jeden Slot Minimum, Maximum und Mittelwert speichern und das als Hüllkurve darstellen?
Hier ist es mit verschiedenen Farben gemacht, aber man könnte z.B. alle 3 Kurven mit der bereits implementierten Farbgebung darstellen und den Bereich zwischen den Extremen schraffieren (vielleicht sogar als Verlauf zwischen Minimum-Farbe und Maximum-Farbe), statt wie bisher den Bereich bis zur Plot-Untergrenze.
Zitat von: xenos1984 am 07 Mai 2021, 08:06:28
Noch eine Idee zur Datensammlung und Darstellung: könnte man für jeden Slot Minimum, Maximum und Mittelwert speichern und das als Hüllkurve darstellen?
Hier ist es mit verschiedenen Farben gemacht, aber man könnte z.B. alle 3 Kurven mit der bereits implementierten Farbgebung darstellen und den Bereich zwischen den Extremen schraffieren (vielleicht sogar als Verlauf zwischen Minimum-Farbe und Maximum-Farbe), statt wie bisher den Bereich bis zur Plot-Untergrenze.
Klar, kann man alles machen, dann hat man aber fast drei mal so viel Daten im Speicher. Ich versuche aber genau das Gegenteil zu erreichen, um für die "Piktogramme" nicht zu viel Speicher pro Grafik zu verbrauchen. Zur Zeit ist die Darstellung rasend schnell und kommt ohne jegliche Fork-Experimente. Auch das Volumen des Diagramms ist kleiner als das der meisten SVG-Bildchen.
Neue Version zum Ausprobieren.
Man kann jetzt beliebige Zeiträume angeben.
Syntax:
col<number><time>
mit <time>: d für days oder w für weeks
Die Skalierung auf der Zeitachse wird automatisch angepasst.
Wird <time> nicht angegeben, dann handelt es sich um Stunden - wie bisher
typische Beispiele
col1d, col2d, col3d, col4d, col5d, col6d
col1w, col2w, col3w usw.
auch col52w für ein Jahr ist z. B. möglich.
Mit "save" werden die gesammelten Daten in versteckten Readings (beginnend mit Punkt) im jeweiligen DOIF-Modul gespeichert und nach dem Booten wiederhergestellt.
Hallo,
ist oder wär es möglich 2 Werte in der card anzuzeigen?
Habe in jedem Raum diese MobileAlerts Temperatur/Luftfeuchte Sensoren welche alle 7min messen.
Würde die gern (komplett) in jeweils einer card darstellen.
Das rechts der tempHumRing mit beiden Werten wäre, und in der selben Farbe der Werte das Diagramm.
Aktuell hab ich für jeden Sensor eine card für Temp und eine für die feuchte.
Zitat von: hankyzoolander am 08 Mai 2021, 09:51:46
Hallo,
ist oder wär es möglich 2 Werte in der card anzuzeigen?
Habe in jedem Raum diese MobileAlerts Temperatur/Luftfeuchte Sensoren welche alle 7min messen.
Würde die gern (komplett) in jeweils einer card darstellen.
Das rechts der tempHumRing mit beiden Werten wäre, und in der selben Farbe der Werte das Diagramm.
Aktuell hab ich für jeden Sensor eine card für Temp und eine für die feuchte.
Das wird das nächste Vorhaben sein :)
Hallo,
sehr geil :D
Aber eine frage (Anliegen) hätt ich noch,
aktuell ist es doch so das im Dashboard nur das State(format) vom doif angezeigt wird.
Es wär echt der Knaller, wenn man das doif im Dashboard so anzeigen könnte wie in den normalen Räumen.
Ist da was zu machen?
Mit den card devstateicons bin ich noch nicht so einig. Da ich gerne die "normale" Ansicht der jeweiligen Geräte gerne behalten würde.
Somit, müsste ich mir für alle Geräte einen zwilling bauen mit der card als devStateIcon :o
Zitat von: hankyzoolander am 08 Mai 2021, 10:32:41
Hallo,
sehr geil :D
Aber eine frage (Anliegen) hätt ich noch,
aktuell ist es doch so das im Dashboard nur das State(format) vom doif angezeigt wird.
Es wär echt der Knaller, wenn man das doif im Dashboard so anzeigen könnte wie in den normalen Räumen.
Ist da was zu machen?
Mit den card devstateicons bin ich noch nicht so einig. Da ich gerne die "normale" Ansicht der jeweiligen Geräte gerne behalten würde.
Somit, müsste ich mir für alle Geräte einen zwilling bauen mit der card als devStateIcon :o
Dashboard ist nicht meine Baustelle, da habe ich keine Karten im Spiel. Die ganze uiTable in Status eines DOIFs zu packen hat nicht richtig funktioniert.
Neue Version wurde eingecheckt:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM?order=date&desc=1
Mit der neuen eingecheckten Version wird $lightness bei den ring2(icon_ring2)-Funktionen für: Ring, Einheit, Wert und Icon wie bereits bei ring-Funktionen unterstützt. Per Default ist Icon und Einheit mit 40 etwas abgedunkelt, Werte und Ringe dagegen mit 50, siehe $lightness-Parameter hier: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Farbskalierte_Anzeige_von_zwei_Zahlenwerten_mit_einem_Icon_mit_Hilfe_der_universellen_SVG-Funktion_icon_ring2
Im Anhang Standard-Layout mit Default-Helligkeit
Man kann jetzt beim Parameter $prop angeben, dass man keine Fußzeile haben möchte. Durch die kompakte Darstellung lassen sich mehr Karten auf den Bildschirm bringen.
Zitat von: Damian am 08 Mai 2021, 18:34:00
Man kann jetzt beim Parameter $prop angeben, dass man keine Fußzeile haben möchte.
Hi, Damian,
magst du da mal ein uitable-Beispiel posten, ich hab' den Durchblick verloren :-)
Vielen Dank im Voraus
Christian
Zitatcard([Aussensensor:temperature:col],undef,"temp_outside",-10,30,undef,undef,"°C",\&temp_hue,undef,",,,1")|
card([Aussensensor:humidity:col],undef,"temperature_humidity",30,100,undef,undef,"%",\&hum_hue,0,",,,1")
card([Tankstelle:Diesel:col1w],undef,"fuel","1.00","1.40",120,0,"Diesel €",undef,"2","130,,1,1")|
card([RKI7:Duren:col1w],undef,"coronavirus",0,200,120,0,"Fälle",undef,undef,"130,,,1")
card([di_vaillant:diff_h:col1w],undef,"sani_floor_heating_neutral",0,200,120,0,"kWh",undef,1,"130,,,1")|
card([zaehler:Produktion:col1w],undef,"sani_solar",0,30,0,120,"kWh",undef,1,"130,,,1")
card([Wasserverbrauch:heute:col1w],undef,"measure_water_meter",0,600,120,0,"l/d",undef,0,"130,,,1")|
card([Wetter:RegenGesamtMm:col1w],undef,"weather_rain_gauge",0,50,180,270,"mm",undef,"1","130,,1,1")
siehe $prop-Parameter hier: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
und so sieht es dann in der Übersicht aus:
Etwas weniger bunt und nur noch cards - passt auch
Zitat von: Damian am 08 Mai 2021, 20:22:06
siehe $prop-Parameter hier: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Ah, danke, da hatte ich mich mit der Position offenbar verzählt.
Christian
Neuer Wiki-Beitrag siehe: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Visualisierung:_aktuelle_Corona-7-Tage-Inzidenz
Wenn man seine kostbar gesammelten Daten über die Collect-Angabe col nicht verlieren will, sollte man regelmäßig seine Readings sichern:
defmod di_save DOIF {[+:30];; fhem"save"}
Dazu muss im global-Device Attribut autosave auf eins stehen.
Zitat von: Damian am 09 Mai 2021, 20:29:45
Neuer Wiki-Beitrag siehe: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Visualisierung:_aktuelle_Corona-7-Tage-Inzidenz
Moin,
cool. Jedoch habe ich Probleme die Städte Düsseldorf oder Köln auszulesen. Zu Passau oder Regensburg bekomme ich Werte angezeigt....
Die Schreibweise im DOIF stimmt mit denen von der RKI-Webseite zumindest überein.. muss aber mit Umlauten zu tun haben... denn alle Orte mit Umlauten werden mir nicht angezeigt
Ne Idee was hier falsch ist:
Internals:
API_LAST_RES 1620626001.388
API__LAST_MSG 200
CFGFN
DEF https://services7.arcgis.com/mOBPykOjAyBO2ZKk/arcgis/rest/services/RKI_Landkreisdaten/FeatureServer/0/query?where=1%3D1&outFields=last_update,cases7_per_100k,BEZ,BEM,GEN,BL,county&returnGeometry=false&outSR=4326&f=json
FUUID 60984323-f33f-7539-8102-b4f46260eee31722
NAME RKI7
NEXT 2021-05-10 08:00:00
NR 52385
SOURCE https://services7.arcgis.com/mOBPykOjAyBO2ZKk/arcgis/rest/services/RKI_Landkreisdaten/FeatureServer/0/query?where=1%3D1&outFields=last_update,cases7_per_100k,BEZ,BEM,GEN,BL,county&returnGeometry=false&outSR=4326&f=json (200)
STATE ???
SVN 24360 2021-04-29 21:17:23 UTC
TYPE JsonMod
CONFIG:
IN_REQUEST 0
SOURCE https://services7.arcgis.com/mOBPykOjAyBO2ZKk/arcgis/rest/services/RKI_Landkreisdaten/FeatureServer/0/query?where=1%3D1&outFields=last_update,cases7_per_100k,BEZ,BEM,GEN,BL,county&returnGeometry=false&outSR=4326&f=json
SECRET:
OLDREADINGS:
READINGS:
2021-05-10 07:53:21 Dresden 122.3
2021-05-10 07:53:21 Dresden_avg_day 122.3
2021-05-10 07:53:21 Dresden_avg_month 122.3
2021-05-10 07:53:21 Dresden_cum_day 3473442.3
2021-05-10 07:53:21 Dresden_cum_month 109140642.3
2021-05-10 06:30:29 Dresden_max_day 122.3
2021-05-10 06:30:29 Dresden_max_month 122.3
2021-05-10 06:30:29 Dresden_min_day 122.3
2021-05-10 06:30:29 Dresden_min_month 122.3
2021-05-10 07:53:21 Passau 111.1
2021-05-10 07:53:21 Passau_avg_day 110.7
2021-05-10 07:53:21 Passau_avg_month 110.0
2021-05-10 07:53:21 Passau_cum_day 3143462.3
2021-05-10 07:53:21 Passau_cum_month 98183462.3
2021-05-10 04:00:08 Passau_max_day 111.1
2021-05-10 04:00:08 Passau_max_month 111.1
2021-05-10 01:00:07 Passau_min_day 110.0
2021-05-09 22:26:46 Passau_min_month 110.0
2021-05-10 07:53:21 Regensburg 111.8
2021-05-10 07:53:21 Regensburg_avg_day 110.6
2021-05-10 07:53:21 Regensburg_avg_month 108.8
2021-05-10 07:53:21 Regensburg_cum_day 3141727
2021-05-10 07:53:21 Regensburg_cum_month 97058527
2021-05-10 04:00:08 Regensburg_max_day 111.8
2021-05-10 04:00:08 Regensburg_max_month 111.8
2021-05-10 01:00:07 Regensburg_min_day 108.7
2021-05-09 22:26:46 Regensburg_min_month 108.7
2021-05-10 07:53:21 Viersen 94.4
2021-05-10 07:53:21 Viersen_avg_day 91.3
2021-05-10 07:53:21 Viersen_avg_month 86.5
2021-05-10 07:53:21 Viersen_cum_day 2593509.6
2021-05-10 07:53:21 Viersen_cum_month 77156709.6
2021-05-10 04:00:08 Viersen_max_day 94.4
2021-05-10 04:00:08 Viersen_max_month 94.4
2021-05-10 01:00:07 Viersen_min_day 86.3
2021-05-09 22:25:36 Viersen_min_month 86.3
Attributes:
readingList multi(jsonPath("\$.features[?(\@.attributes.GEN in ['Mönchengladbach', 'Düsseldorf', 'Köln', 'Viersen', 'Passau', 'Regensburg', 'Neuss', 'Dresden'])]"), property('attributes.GEN'), sprintf('%.1f', property('attributes.cases7_per_100k')));
room Allgemein
Es gibt bei JsonMod Probleme mit Umlauten. Suche daher nach OBJECTID.
Es wird bei county z.B. SK MAnchen, SK MAnchengladbach. LK MeiAsen angezeigt.
Hallo,
stehe da gerade etwas auf dem Schlauch.
ZitatMit "save" werden die gesammelten Daten in versteckten Readings (beginnend mit Punkt) im jeweiligen DOIF-Modul gespeichert und nach dem Booten wiederhergestellt.
Welches save ist damit gemeint?
save config?
Hilf mir mal bitte auf die sprünge ::) :o
Zitat von: hankyzoolander am 10 Mai 2021, 16:59:12
Hallo,
stehe da gerade etwas auf dem Schlauch.
Welches save ist damit gemeint?
save config?
Hilf mir mal bitte auf die sprünge ::) :o
ja, save (entspricht save config) speichert das save-File als auch die config-Datei, vermutlich damit sie nicht auseinander laufen, daher würde ich es nicht im Sekundentakt machen.
Ich habe mir gerade den Code von save angeschaut, mit
{my $restoreDir;; $restoreDir = restoreDir_init("save");;restoreDir_saveFile($restoreDir, $attr{global}{statefile});;WriteStatefile()}
könnte man nur die fhem.save-Datei sichern, wenn man weiß, dass sich die Config-Datei nicht geändert hat.
Wenn das System sehr stabil läuft, dann reicht vor dem Neustart ein save.
Noch ein wichtiger Hinweis zum Thema Datenspeicherung in versteckten Readings.
Möchte man seine uiTable mit col-Angaben anpassen, dann sollte man zuvor auf "save config" drücken, damit die internen Daten in den versteckten Readings aktualisiert werden und in der save Datei gespeichert werden. Diese Daten werden dann unmittelbar wieder eingelesen. Wenn sie nicht gespeichert wurden, dann fehlen sie im Diagramm.
Ändert man den Zeitraum, der bei col angegeben wird, so werden neue Readings zur Datenspeicherung erzeugt. Die bis dahin genutzten Readings werden nicht automatisch gelöscht. Über RAW-Definition kann man sehen, welche Readings mit welchen Daten im Modul abgelegt worden sind. Möchte man nicht mehr genutzte Readings aus einem DOIF-Device entfernen, so muss man das, wie üblich, über deletereading tun.
Mit
deletereading <DOIF-Device(s)> \..*
werden alle verstecken Readings eines oder mehrerer DOIF-Devices gelöscht.
Hallo,
hab danach gesucht, aber es nicht gefunden.
@Damian,würdest du dein Coronavirus icon mit uns teilen??? ::)
Zitat von: hankyzoolander am 11 Mai 2021, 17:53:34
Hallo,
hab danach gesucht, aber es nicht gefunden.
@Damian,würdest du dein Coronavirus icon mit uns teilen??? ::)
https://www.flaticon.com/de/kostenlose-icons/virus (https://www.flaticon.com/de/kostenlose-icons/virus)
dankeschön.
Sieht dann doch besser aus. Darf man das hier bei Icons hochladen???
Noch eine andere Frage: Lässt sich eigentlich das Seitenverhältnis einstellen, bzw. Breite und Höhe? Ich habe einen 480x272 Pixel Monitor, auf dem ich Wetterdaten als PNG mit dem RSS-Modul schicke - da wäre es ideal, wenn man eine SVG in der passenden Größe hätte.
Zitat von: xenos1984 am 12 Mai 2021, 07:31:17
Noch eine andere Frage: Lässt sich eigentlich das Seitenverhältnis einstellen, bzw. Breite und Höhe? Ich habe einen 480x272 Pixel Monitor, auf dem ich Wetterdaten als PNG mit dem RSS-Modul schicke - da wäre es ideal, wenn man eine SVG in der passenden Größe hätte.
Die Positionen der einzelnen Elemente sind fest codiert, daher kann man nur die Größe insgesamt verändern. Die Proportionen verändern sich natürlich abhängig davon, ob Kopfzeile bzw. Fußzeile eingeblendet wird oder nicht.
Ich habe jetzt ein paar Tage die CO2-Messung laufen lassen. Bis zu einer Woche lassen sich die Verläufe gut ablesen, vielleicht auch bis zu einem Monat (ist hier nicht definiert). Das letzte Diagramm ist mit col12w definiert, also ca. 3 Monate, dafür ist die Auflösung zu gering, um einen sinnvollen Verlauf zu erkennen.
Edit: Man kann erkennen, dass der neue Algorithmus zur Speicherung der Daten gut funktioniert, weil wichtige Details auch bei geringer Auflösung gut erkennbar sind.
@Damian - ist aus #94 "neue Features in Entwicklung" Folgendes bereits implementiert?
Zitat-neuer Algorithmus zur Speicherung der Daten, es werden Spitzenwerte (sowohl nach unten als auch nach oben) gespeichert, der letzte aktuelle Wert wird in den folgenden Zeitslot gerettet, falls dieser nicht belegt wird
Tritt bei einer Pumpe mit Stufe 0, 1, 2 und kurzer Laufzeit auf. Es werden events verschluckt.
Gibt es eine Möglichkeit die gespeicherten Daten anzuzeigen. (raw zeigt nur alte Daten an, falls bei colx etwas geändert wurde)
Zitat von: jkriegl am 13 Mai 2021, 15:44:52
@Damian - ist aus #94 "neue Features in Entwicklung" Folgendes bereits implementiert?
Tritt bei einer Pumpe mit Stufe 0, 1, 2 und kurzer Laufzeit auf. Es werden events verschluckt.
Gibt es eine Möglichkeit die gespeicherten Daten anzuzeigen. (raw zeigt nur alte Daten an, falls bei colx etwas geändert wurde)
ja, es ist alles, was sinnvoll ist, implementiert. Wenn in einem Timeslot 50 Events kommen und man nur eins behalten kann, dann werden 49 verschluckt - das ist richtig.
Was verschluckt wird und was nicht musst du separat loggen.
Status ist 0, nach ca. 9 Min kommt 1 läuft 0:55 dann 0. usw
Momentan bei col1 ok. Bei col2 wird gelegentlich eine 1 verschluckt. Bei col gösser 2 häufiger.
Zitat von: jkriegl am 13 Mai 2021, 16:06:44
Status ist 0, nach ca. 9 Min kommt 1 läuft 0:55 dann 0. usw
Momentan bei col1 ok. Bei col2 wird gelegentlich eine 1 verschluckt. Bei col gösser 2 häufiger.
Es wird der Extremwert genommen > (max-min)/2 bzw. < (max-min)/2, der letzte Wert wird in folgenden Slot übernommen, wenn er nicht schon durch einen folgenden Wert belegt ist.
Falls ich das richtig verstehe: wir haben max=1, min=0, (max-min)/2 -> 0,5=X.
Extremwert > X bzw. < X.
Es müsste 1 übernommen und 0 fortgeschrieben werden, falls alles in einem slot passiert.
Da wir bei einer Laufzeit um 0:54 sind treffen wir beil col1 meistens 2 Slots, bei col2 aber nicht immer.
Edit: max kann auch 2 sein, trifft aber bei col2 im B. nicht zu.
Zitat von: jkriegl am 13 Mai 2021, 17:19:05
Falls ich das richtig verstehe: wir haben max=1, min=0, (max-min)/2 -> 0,5=X.
Extremwert > X bzw. < X.
Es müsste 1 übernommen und 0 fortgeschrieben werden, falls alles in einem slot passiert.
Da wir bei einer Laufzeit um 0:54 sind treffen wir beil col1 meistens 2 Slots, bei col2 aber nicht immer.
Edit: max kann auch 2 sein, trifft aber bei col2 im B. nicht zu.
max und min unterscheiden sich aber je nach Zeitdauer bei col2 ist max=2 gar nicht mehr dabei.
Leider gehen event-Daten nach wie vor verlohren. (nicht mehrfache in einem slot)
Aus dem Log
Zitat2021-05-15_12:36:00 shelly_s usr: E: 15.572 P: 5.57 0 0:41
2021-05-15_12:52:46 shelly_s usr: E: 15.572 P: 11.98 1 16:46
2021-05-15_12:53:25 shelly_s usr: E: 15.572 P: 3.21 0 0:39
2021-05-15_13:07:25 shelly_s usr: E: 15.573 P: 14.31 1 14:00
2021-05-15_13:08:04 shelly_s usr: E: 15.573 P: 1.20 0 0:39
2021-05-15_13:22:39 shelly_s usr: E: 15.573 P: 7.63 1 14:35
2021-05-15_13:23:19 shelly_s usr: E: 15.573 P: 1.97 0 0:40
2021-05-15_13:36:49 shelly_s usr: E: 15.573 P: 13.73 1 13:30
2021-05-15_13:37:25 shelly_s usr: E: 15.574 P: 1.79 0 0:36
2021-05-15_13:49:31 shelly_s usr: E: 15.574 P: 13.09 1 12:06
2021-05-15_13:50:09 shelly_s usr: E: 15.574 P: 2.81 0 0:38
Es fehlt 13:22 und 13:36 (vorletzte Spalte 0 oder 1). Pro slot sind nur 2 Werte vorhanden (0 oder 1). Es wir der Wert tempörär angezeigt und verschwindet aber dann, wird also nicht korrekt gespeichert.
Zitat von: jkriegl am 15 Mai 2021, 14:08:05
Leider gehen event-Daten nach wie vor verlohren. (nicht mehrfache in einem slot)
Aus dem Log
Es fehlt 13:22 und 13:36 (vorletzte Spalte 0 oder 1). Pro slot sind nur 2 Werte vorhanden (0 oder 1). Es wir der Wert tempörär angezeigt und verschwindet aber dann, wird also nicht korrekt gespeichert.
An der Grafik kann man Events mit 0 nicht sehen, dazu musst du auch die passenden gespeicherten Werte im DOIF posten.
Ich kann aber jetzt schon sehen, dass alles so funktioniert wie programmiert:
Bei einer Stunde hat ein Timeslot 50 Sekunden,
Der Timeslot beginnt um 13:22:30 und endet um 13:23:20, damit hat Event um 13:23:19 mit 0 gewonnen
Um 13:36:40 beginnt ein Slot und endet um 13:37:30, damit hat Event um 13:27: 25 mit 0 ebenfalls gewonnen.
ok dann habe ich das ganze doch nicht verstanden.
Läuft etwas kürzer als eine slot-Dauer können Informationen verlohren gehen.
(bei card5 immerhin 5 Min) Für so einen Fall ist daher card leider nicht geeignet.
Zitat von: jkriegl am 15 Mai 2021, 17:00:39
ok dann habe ich das ganze doch nicht verstanden.
Läuft etwas kürzer als eine slot-Dauer können Informationen verlohren gehen.
(bei card5 immerhin 5 Min) Für so einen Fall ist daher card leider nicht geeignet.
ja, so ist es.
Beispiel:
Max=100, Min=0
=>avg=50
1. Event im Slot 60 -> 60, wird übernommen, weil größer als avg und größter im Slot
2. Event im Slot 70 -> 70, wird übernommen, weil größer als avg und größter im Slot
3. Event im Slot 50 -> 70, wird nicht übernommen, weil größer als avg und nicht größter im Slot
4. Event im Slot 30 -> 30, wird übernommen, weil kleiner als avg und kleinster im Slot
5. Event im Slot 20 -> 20, wird übernommen, weil kleiner als avg und kleinster im Slot
6. Event im Slot 30 -> 20, wird nicht übernommen, weil kleiner als avg und nicht kleiner im Slot
7. Event im Slot 40 -> 20, wird nicht übernommen, weil kleiner als avg und nicht kleiner im Slot
neuer Slot:
40 als letzter Wert wird in den nächsten Slot gerettet (da 20 gewonnen hat), wenn im nächsten Slot kein Event stattgefunden hat
Damit wird erreicht, dass Extrema gewinnen, aber der letzte Wert im Slot noch eine Chance bekommt, gerettet zu werden, wenn im nächsten Slot kein Event vorkommt.
Für ein Piktogramm mit 72-Plätzen muss es reichen, für genaue Analysen muss man jeden Wert loggen und über SVG-Plots plotten.
Im Anhang sieht man Cards mit 7 Tagen Laufzeit (Barometer war nicht immer aktiv).
Sowohl Sprit mit seinen Spitzen (nach oben und unten), alle kontinuierlich ansteigenden Verbräuche, die um Mitternacht auf Null gesetzt werden, als auch 24-Stundenmessungen für Temperatur oder Feuchtigkeit sind ebenso unkritisch.
Einen kurzen Aussetzer irgendwo wird man nicht erkennen, das ist aber auch nicht die Intention dieser Anzeige.
wie wird avg berechnet?
Vorgängerslot = 0, wird propagiert
1. event im slot = 1, avg = .5 wird übernommen
2. event im slot = 0, avg = .33, wird nicht übernommen, wird propagiert
avg ist immer der Mittelwert des aktuellen Maximums und Minimums über den definierten Zeitraum.
ok bin draussen
Zeitraum ? col?
Warum ist im Beispiel:
1. event = 1, 2. event =0, Ergebnis: mal Null mal EINS - rein zufällig
edit: die 1 gewinnt nur, falls sie alleine im slot ist.
Zitat von: jkriegl am 15 Mai 2021, 18:39:53
ok bin draussen
Zeitraum ? col?
Warum ist im Beispiel:
1. event = 1, 2. event =0, Ergebnis: mal Null mal EINS - rein zufällig
edit: die 1 gewinnt nur, falls sie alleine im slot ist.
Zeitraum von col.
Es ist nichts zufällig, sondern nach dem programmierten Algorithmus, beides sind Extrema, das letzte Extremum des Slots gewinnt, das kann 0 oder 1 sein - wie schon beschrieben.
Zufall: Beispiel col1 hat weinger Treffer als col3
oder man müsste den Algorithmus anschauen.
Falls es jemandem zu bunt ist, ich habe bei $prop einen weiteren Parameter für graue Y-Achsenbeschriftung eingebaut:
Zitat von: Damian am 17 Mai 2021, 10:59:24
Falls es jemandem zu bunt ist, ich habe bei $prop einen weiteren Parameter für graue Y-Achsenbeschriftung eingebaut:
neue Version eingecheckt, Doku zu $prop aktualisiert: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Zitat von: Damian am 10 Mai 2021, 17:54:53
ja, save (entspricht save config) speichert das save-File als auch die config-Datei, vermutlich damit sie nicht auseinander laufen, daher würde ich es nicht im Sekundentakt machen.
Ich hatte irgendwie angenommen, das Readings generell bei einen ,,shutdown restart" gesichert werden, egal ob sie z.B. durch einen . versteckt sind oder nicht. Weshalb ist es dann notwendig, vorher ein save config auszulösen?
Oder liegt es an der besonderen Art und Weise der Datenhaltung, weshalb das notwendig ist? Kann man diese Daten vielleicht auch in ,,normale" Readings stecken, deren Inhalt ein Shutdown restart überleben würde?
shutdown macht kein save, deswegen solltest du vor jedem shutdown save machen, sonst hast du nach dem Hochfahren einen alten Stand. Das hat nichts mit card zu tun.
ich sehe gerade, dass offenbar Readings gesichert werden, offenbar gibt es aber beim shutdown kein save-Event.
Genau. Die config wird nicht gesichert, was auch gut ist, die readings aber schon (eben nochmal getestet). Wenn du deine Daten also irgendwo als verstecktes Reading sichern würdest und dieses Reading dann beim Init laden würdest, dann wären die Card collector Daten ganz ohne Zutun des Anwenders gesichert.
Man könnte dann übrigens die gesammelten Daten auch noch in Textform im RAW Output sehen...
Ich habe das Problem schon gelöst. Jetzt werden nicht nur beim SAVE-Event sondern auch beim Shutdown-Event, die internen gesammelten Daten in Readings geschrieben, die dann ja gesichert werden - es funktioniert.
Neue Version eingecheckt.
Ich habe noch ein paar Optimierungen eingebaut.
Solange das System nicht abstürzt, werden alle Daten sauber gespeichert. Man braucht zu keinem Zeitpunkt manuell etwas zu sichern. Auch verwaiste Readings werden jetzt aufgeräumt.
Habe mich mal ein wenig mit der neuen card Funktion auseinander gesetzt.
Danke erstmal dafür.
Besteht die Möglichkeit, wie bei ring2 2 Ringe in einer Darstellung, eine 2. Kurve mit in einem Diagramm einzufügen ?
Gruß
Sascha
Zitat von: sash.sc am 23 Mai 2021, 12:46:46
Habe mich mal ein wenig mit der neuen card Funktion auseinander gesetzt.
Danke erstmal dafür.
Besteht die Möglichkeit, wie bei ring2 2 Ringe in einer Darstellung, eine 2. Kurve mit in einem Diagramm einzufügen ?
Gruß
Sascha
Befindet sich in der Entwicklung.
neue Features sollen sein:
-Skalierbarkeit der Grafik, breite der Karte einstellbar
-Anzahl der Messpunkte wählbar
-mehrere Sensoren in einem Diagramm
-platzsparende Anzeige mehrerer Werte mit Halbringen
mal schauen, was geht :)
Danke für deine Mühe
Komme doch noch einmal auf den Algorithmus zurück.
Im Datenbenspiel (identisches device - Unterschied col1, col3) sieht man, dass bei col3 fast nur niedrige Werte gespeichert bzw. höhere durch niedrige ersetzt werden. Beispiel am Ende 16.46,1.77 zu ,1.77
Auch bei col1 fehlen höhere Werte bei 162117793620
setstate di_collect_tw_2 2021-05-23 20:37:26 .col_72_shelly_s_power_1_times ,,,,,,1621791297,1621791325,,,,,,,,,,,,,,,,,,,,1621792348,1621792377,,,,,,,,,,,,,,,,,,,,,1621793446,1621793470,,,1621793620,1621793651,,,,,,,,,,,,,,,,1621794495,1621794514
setstate di_collect_tw_2 2021-05-23 20:37:26 .col_72_shelly_s_power_1_values ,,,,,,13.21,1.39,,,,,,,,,,,,,,,,,,,,15.38,1.35,,,,,,,,,,,,,,,,,,,,,16.28,1.25,,,1.26,1.27,,,,,,,,,,,,,,,,16.46,1.77
setstate di_collect_tw_2 2021-05-23 20:37:26 .col_72_shelly_s_power_3_times ,,,1621784391,1621784422,,,,,,1621785373,,,,1621785937,1621786087,,,,1621786752,,,,1621787394,,,,1621787919,,,1621788447,,,,1621788979,,,,1621789558,,,,,1621790379,,,,,,1621791295,1621791325,,,,,,1621792347,1621792377,,,,,,,1621793470,1621793620,97307622000,,,,,1621794514
setstate di_collect_tw_2 2021-05-23 20:37:26 .col_72_shelly_s_power_3_values ,,,12.97,1.57,,,,,,2.05,,,,1.04,1.23,,,,1.20,,,,1.30,,,,1.71,,,1.36,,,,1.56,,,,1.48,,,,,1.33,,,,,,4.67,1.39,,,,,,2.93,1.35,,,,,,,1.25,1.26,1.27,,,,,1.77
Wie kann ich die Daten anzeigen, dann mache ich ein Beispiel mit events 1, 0
Was wird gespeichert bei Ausgang 0
im slot: 1 (erst nächst. slot 0)
im slot: 1,0
im slot: 1,0,1
edit: es fehlt manchmal die 1
setstate di_collect_tw 2021-05-23 20:37:26 .col_72_shelly_s_running_1_times ,,,,,,1621791297,1621791325,,,,,,,,,,,,,,,,,,,,1621792348,1621792375,,,,,,,,,,,,,,,,,,,,,1621793440,1621793469,,,,,,,,,,,,,,,,,,,,1621794486,1621794514
setstate di_collect_tw 2021-05-23 20:37:26 .col_72_shelly_s_running_1_values ,,,,,,1,0,,,,,,,,,,,,,,,,,,,,1,0,,,,,,,,,,,,,,,,,,,,,1,0,,,,,,,,,,,,,,,,,,,,1,0
setstate di_collect_tw 2021-05-23 20:37:26 .col_72_shelly_s_running_3_times ,,,1621784389,1621784422,,,,,,1621785373,,,,,1621786086,,,,1621786750,,,,1621787394,,,,1621787919,,,1621788445,,,,1621788979,,,,1621789558,,,,,1621790377,,,,,,1621791297,1621791325,,,,,,1621792348,1621792375,,,,,,,1621793469,,,,,,,1621794514
setstate di_collect_tw 2021-05-23 20:37:26 .col_72_shelly_s_running_3_values ,,,1,0,,,,,,0,,,,,0,,,,0,,,,0,,,,0,,,0,,,,0,,,,0,,,,,0,,,,,,1,0,,,,,,1,0,,,,,,,0,,,,,,,0
Das kann ja alles sein, denn bei unterschiedlichen col-Angabe, sind die jeweils aktuellen Min-, Max-Werte anders und damit kann die Trend zu kleineren Zahlen sein, wenn sie unterhalb des Durchschnitts aus Min, Max liegen.
Zitat von: Damian am 23 Mai 2021, 12:55:51
Befindet sich in der Entwicklung.
neue Features sollen sein:
-Skalierbarkeit der Grafik, Breite der Karte einstellbar
-Anzahl der Messpunkte wählbar
-mehrere Sensoren in einem Diagramm
-platzsparende Anzeige mehrerer Werte mit Halbringen
mal schauen, was geht :)
Folgendes habe ich inzwischen umgesetzt:
-Skalierbarkeit der Grafik, Breite der Karte einstellbar
-platzsparende Anzeige mit einem Halbring
Die gleichen Daten in drei verschiedenen Darstellungen:
Oder vergleichbare Diagrammgröße, wie bisher, allerdings kompakter dargestellt mit Halbring
Zitat-Anzahl der Messpunkte wählbar
Die Auflösung ist jetzt entkoppelt von der Darstellung des Diagramms.
Standardmäßig werden 72 Messpunkte (Timeslots) benutzt.
Man kann die Anzahl jetzt auch selbst definieren:
z. B.
[aussen:temperature:168col1w]
hierbei werden 168 Timeslots für eine Woche genutzt, damit ergibt sich eine Auflösung von einer Stunde pro Timeslot: 24*7
Die Anzahl ist beliebig wählbar, allerdings brauchen mehr Daten auch mehr Platz und mehr Performance bei der Darstellung, das sollte man immer im Hinterkopf behalten.
Testversion im Anhang.
Der Parameter $prop wurde erweitert:
$size,$plot,$steps,$noFooter,$noColor,$hring,$bwidth
Beispiel:
defmod di_cardnew DOIF {}
attr di_cardnew uiTable {package ui_Table;;\
##$TABLE='text-align:center';;\
}\
"Standard"|card([Aussensensor:temperature:col],undef,"temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130")\
"mit Halbring"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130,,,,,1")\
"mir Halbring,Breite 110"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1,110")\
"Breite 200"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130,,,,,,200")\
ZitatDas kann ja alles sein, denn bei unterschiedlichen col-Angabe, sind die jeweils aktuellen Min-, Max-Werte anders und damit kann die Trend zu kleineren Zahlen sein, wenn sie unterhalb des Durchschnitts aus Min, Max liegen.
Nein: Wenn ich nur den Zustand 0 oder 1 habe, also ausgeschaltet - eingeschaltet usw. ist min=0 und max=1.
Es wird nicht der Durschnitt von 0 und 1 dargestellt, sondern 0 und 1, wobei manchmal 1 verschluckt wird. Die Datenfolge müsste ,,,,1,0,,,,1,0,, sein
Auch das ist normal, dafür ist diese Zeile verantwortlich:
if (!defined ${$va}[$dim-1] or $r >= ${$collect}{avg} and $r > ${$va}[$dim-1] or $r < ${$collect}{avg} and $r < ${$va}[$dim-1]) {
${$va}[$dim-1]=$r;
${$ta}[$dim-1]=$seconds;
}
die Eins überschreibt die Null und die Null überschreibt die Eins in einem Slot, avg ist hier 0.5.
Es sind beides Extrema, das letzte gewinnt - alles so beabsichtigt.
Du musst dich damit abfinden, dass bei diesem Verfahren Werte verloren gehen.
nach Antwort #129 müsste der Extremwert (=1) übernommen und die 0 in den nächsten slot rutschen.
Zitat von: jkriegl am 25 Mai 2021, 13:06:52
nach Antwort #129 müsste der Extremwert (=1) übernommen und die 0 in den nächsten slot rutschen.
Auch das hast du nicht richtig verstanden. 0 ist hier ein Extremwert - ein Minimum, wie man in der Schule lernt.
Es ist auch völlig egal, ob zwei Werte (wie in deinem Beispiel) im Abstand von 29 Sekunden gespeichert werden oder nicht, bei drei Stunden reden wir hier von einer Auflösung von 180 Sekunden pro Pixel - du würdest die Schwankung im Diagramm ohnehin nicht sehen.
Wenn schon Schule, wir haben zwei Extremwerte und würfeln welcher gewinnt.
Ist auch weniger als eine Stunde möglich?
Zitat von: jkriegl am 25 Mai 2021, 13:43:28
Wenn schon Schule, wir haben zwei Extremwerte und würfeln welcher gewinnt.
Ist auch weniger als eine Stunde möglich?
Wir würfeln nicht, wir nehmen den letzten :)
Du kannst dir die neue Testversion nehmen und die Anzahl der Timeslots erhöhen, dann sinkt die Wahrscheinlichkeit, dass etwas verloren geht, ob du es im Diagramm sehen wirst, ist eine andere Frage.
Weniger als eine Stunde ist nicht vorgesehen.
Neue Version eingecheckt: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Habe col2 auf col1 geändert und sehe in list <device> von beiden Daten. Wie kann man die überflüssigen (alten) löschen?
collect:
shelly_s power:
1:
avg 11.96
dim 72
hours 1
max_value 22.68
max_value_slot 48
max_value_time 1622211145
min_value 1.24
min_value_slot 9
min_value_time 1622209195
time 1622212270
value 1.29
times:
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622209195
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622209897
1622209915
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622211145
1622211165
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622212230
1622212270
values:
undef
undef
undef
undef
undef
undef
undef
undef
undef
1.24
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
21.70
1.36
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
22.68
1.58
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
17.53
1.29
2:
avg 11.415
dim 72
hours 2
last_value 1.79
max_value 21.70
max_value_slot 47
max_value_time 1622209897
min_value 1.13
min_value_slot 1
min_value_time 1622205261
time 1622212270
value 1.29
times:
undef
1622205261
undef
undef
undef
undef
undef
1622205897
1622205937
undef
undef
undef
undef
undef
1622206594
1622206629
undef
undef
undef
undef
undef
1622207295
1622207337
1622207499
1622207596
1622207694
1622207797
1622207886
1622207988
1622208091
1622208175
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622209897
1622209915
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622211165
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1622212270
values:
undef
1.13
undef
undef
undef
undef
undef
14.82
1.73
undef
undef
undef
undef
undef
17.34
1.48
undef
undef
undef
undef
undef
14.95
1.47
9.61
10.26
1.39
9.47
9.36
2.00
1.55
1.41
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
21.70
1.36
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1.58
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1.29
condition:
Edit: deletereading <device> \..* - hilft nicht.
VERSION 24519 2021-05-27 17:06:34
DEF und modify
Hallo Damian,
danke für Dein tolles Modul.
Ich habe da noch eine Anregung. Durch Aussetzer meiner Wetterstation identifiziert das FHEM-Modul 10_WS980.pm einen Fehler und liefert für bestimmte Wetterwerte "n/a" zurück. In der Folgeverarbeitung visualisiere ich die Wetterdaten mit DOIF-SVG-Diagrammen. Perl interpretiert nicht numerische Werte wie "n/a" aber als 0. Das führt dann zu lückenhaften Darstellungen, wie im Anhang zu sehen ist.
Da vermutlich nur numerische Werte in den DOIF-SVG-Funktionen dargestellt werden, ist mein Vorschlag nicht-numerische Werte auszusteuern bzw. zu ignorieren.
Was hältst Du davon?
Viele Grüße
Ich habe jetzt eingebaut, dass Werte, die sich nicht als Zahl filtern lassen, nicht gesammelt werden.
Kaum habe ich einen Wunsch geäußert, ist er 90 Minuten später von Dir schon umgesetzt. Besser geht es nicht!
Danke Damian.
Viele Grüße
Hallo Damian.
Schon einen Zeitplan, wann es möglich sein wird, eine 2. Kurve mit im card einzubauen ?
Gruß
Sascha
Es ist der aufwändigste Punkt meiner todo-Liste. Die Sensoren sollen als Liste übergeben werden können, dazu muss ich aber noch den Parser umbauen, weil er zur Zeit die Syntax nicht erkennt. Mal schauen vielleicht bis zum Wochenende.
Danke für die Info
Zitat von: Damian am 25 Mai 2021, 09:55:08
Testversion im Anhang.
Der Parameter $prop wurde erweitert:
$size,$plot,$steps,$noFooter,$noColor,$hring,$bwidth
Beispiel:
defmod di_cardnew DOIF {}
attr di_cardnew uiTable {package ui_Table;;\
##$TABLE='text-align:center';;\
}\
"Standard"|card([Aussensensor:temperature:col],undef,"temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130")\
"mit Halbring"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130,,,,,1")\
"mir Halbring,Breite 110"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1,110")\
"Breite 200"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,30,undef,undef,"°C",\&temp_hue,"1","130,,,,,,200")\
Ich mach meine ersten Versuche mit der card-Funktion und habe das Beispiel kopiert.
Wie bekomme ich es hin, daß meine Darstellung auch so in Grün gehalten ist wie in dem Screenshot des Beitrages #159 ?
Bei mir sind zB die Achsfarben von grün bis rot, die Line mehr gelb...
###############################################################
UPDATE: Heute morgen sieht es so aus wie erhofft....
Zitat von: kumue am 01 Juni 2021, 23:51:42
Ich mach meine ersten Versuche mit der card-Funktion und habe das Beispiel kopiert.
Wie bekomme ich es hin, daß meine Darstellung auch so in Grün gehalten ist wie in dem Screenshot des Beitrages #159 ?
Bei mir sind zB die Achsfarben von grün bis rot, die Line mehr gelb...
###############################################################
UPDATE: Heute morgen sieht es so aus wie erhofft....
Die Farbe orientiert sich am Wert, wie beim Ring.
Ein kleiner Vorgeschmack, siehe Anhang
sehr cool.
freue mich schon.
das pünktchen auf i wäre, wenn man in der card funktion, die daten aus nem log holen kann. ;-)
gruß
sascha
Neue Version zum Ausprobieren.
card wurde um optionale Parameter für einen zweiten Wert erweitert.
Syntax:
card ($col,$header,$icon,$min,$max,$minColor,$maxColor,$unit,$func,$decfont,$prop,$model,$lightness,$collect2,$min2,$max2,$minColor2,$maxColor2,$unit2,$func2,$decfont2)
Die Standardbreite wurde von 160 auf 180 erweitert, damit es bei allen card-Funktionen einheitlich ist.
col-Zeitangabe muss logischerweise bei beiden Werten gleich sein.
Beispieldefinition:
defmod di_cards DOIF {}
attr di_cards uiTable {package ui_Table;;\
}\
"Standard"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Header"|card([Aussensensor:temperature:col],undef,"temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Header","ohne Fußzeile"|card([Aussensensor:temperature:col],undef,"temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,1,",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"Als Halbring"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,,,1",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")\
"ohne Fußzeile"|card([Aussensensor:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",\&temp_hue,"1","130,,,1,,1",undef,undef,[outsensor:humidity:col],0,100,undef,undef,"%",\&hum_hue,"0")
Meine aktuelle todo-Liste ist erst mal abgearbeitet. :)
Es gibt jetzt auch die Möglichkeit mehrere Werte mit gleicher Einheit darzustellen. Hierbei wird die Skalierung über alle Werte errechnet. Dadurch ist die Vergleichbarkeit der Wertverläufe gegeben.
Syntax:
card (<Array von Sensoren>,$header,$icon,$min,$max,$minColor,$maxColor,<Array der Einheiten>,$func,$decfont,$prop,$model,$lightness)
Es können auch mehr als zwei Sensoren angegeben werden (sinnvoll mit Halbringen) oder in Kombination mit einem weiteren Wert über collect2.
Beispiel:
defmod Sprit DOIF ##
attr Sprit uiTable {package ui_Table;;}\
"Standard"|card([[Tankstelle:SuperE5:col24],[Tankstelle:Diesel:col24]],"Sprit","fuel","1.20","1.60",120,0,["E5","Diesel"],undef,"2",",,1",undef,undef)\
"ohne Skalierung"|card([[Tankstelle:SuperE5:col24],[Tankstelle:Diesel:col24]],"Sprit","fuel","1.20","1.60",120,0,["E5","Diesel"],undef,"2",",1,1",undef,undef)\
"mit Halbringen"|card([[Tankstelle:SuperE5:col24],[Tankstelle:Diesel:col24]],"Sprit","fuel","1.20","1.60",120,0,["E5","Diesel"],undef,"2",",,1,,,1",undef,undef)
Natürlich können ebenso alle anderen Dinge mit gleicher Einheit auf diese Weise sinnvoll gegenübergestellt werden, wie z. B. Temperaturen, Energie usw.
Hier ein Beispiel mit drei Werten. Die Daten müssen noch gesammelt werden.
defmod PV DOIF {}
attr PV DOIF_Readings l_Eigenv: [zaehler:l-Produktion]-[zaehler:l-Lieferung],\
Eigenv:[zaehler:Produktion]-[zaehler:Lieferung],\
l_Verbrauch: [zaehler:l-Bezug,0]+[$SELF:l_Eigenv,0],\
Verbrauch:[zaehler:Bezug]+[$SELF:Eigenv],\
l_Bezug:-[zaehler:l-Bezug]
attr PV event-on-change-reading .*
attr PV uiTable {\
package ui_Table;;\
$SHOWNOSTATE=1;;\
$TC{0..1}="align='center'";;\
}\
\
cylinder("Leistung ",-2,3.6,"kW",145,undef,undef,1,-[zaehler:l-Bezug:d1],0,"Bezug",[zaehler:l-Produktion:d1],60,"Produktion",[$SELF:l_Eigenv:d1],30,"Eigenverb.")|\
cylinder("Energie",-20,30,"kWh",145,undef,undef,1,-[zaehler:Bezug:d1],0,"Bezug",[zaehler:Produktion:d1],60,"Produktion",[$SELF:Eigenv:d1],30,"Eigenverb.")<\
\
card([[zaehler:l-Produktion:col],[$SELF:l_Eigenv:col],[$SELF:l_Bezug:col]],undef,"fa_bolt\@silver",-2,3.6,0,90,["Solar","Eigenv.","Bezug"],undef,"2","157,1,1,,,1,190")
Super Arbeit. Danke und Daumen hoch !
##############################
Eine Frage noch...
Die Werte für den zweiten Sensor $min2,$max2,$minColor2,$maxColor2 (siehe #179) kann ich wohl in der aktuellen Version nicht definieren...oder ?
Zitat von: kumue am 06 Juni 2021, 10:25:25
Super Arbeit. Danke und Daumen hoch !
##############################
Eine Frage noch...
Die Werte für den zweiten Sensor $min2,$max2,$minColor2,$maxColor2 (siehe #179) kann ich wohl in der aktuellen Version nicht definieren...oder ?
Doch:
ZitatEs können auch mehr als zwei Sensoren angegeben werden (sinnvoll mit Halbringen) oder in Kombination mit einem weiteren Wert über collect2.
Das heißt, die letzte Version beinhaltet alles, was bisher hier gepostet wurde. Wenn ich meine Tests beendet habe, werde ich sie einchecken.
Die Energieanzeige sieht jetzt so aus:
Zitat von: Damian am 24 Mai 2021, 22:16:01
-Skalierbarkeit der Grafik, Breite der Karte einstellbar
Danke, damit hast du meinen Wunsch nach Breite / Höhe erfüllt :)
Die neue Version hat meine Tests bestanden. Sie wurde eingecheckt. Doku wurde angepasst:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Es sind zwei drei weitere Beispiele hinzugekommen.
Die Möglichkeiten mit DOIF/uiTable (hier card) sind inzwischen sehr umfangreich und komplex.
Z. B. kann man in einem svg von mehreren Tankstellen den aktuellen Preis, das Minimum, das Maximum und wann am Preis geschraubt wurde darstellen (als Folge, wann droht eine Preisänderung).
Schön wäre es, wenn man die einzelnen Graphen der jeweiligen Tanke zuordnen könnte.
Mit $colorRef kann man noch Anpassungen bei den Farben vornehmen. Wenn ich das Beispiel PV richtig verstehe funktioniert diese Anpassung innerhalb eines Bereiches. Alle Tanken haben in etwa die gleiche Spanne.
Weitere Beispiele könnten Raumtemperauren, Heizkörpereinstellungen usw. sein.
Edit: die Definition dazu ist mehr als einfach.
So würde die card-Funktion mit Farbzuordnung aussehen:
neue Version zum Ausprobieren:
-Algorithmus zum Speichern der Werte wurde verbessert
-Bei Halbringen können einfarbige Graphen gezeichnet werden
Bei der Einheit-Beschriftung kann jetzt kommagetrennt eine Farbe als Text oder als Hex-Angabe angegeben werden.
Beispiele:
card([[zaehler:l-Produktion:col],[$SELF:l_Eigenv:col],[$SELF:l_Bezug:col]],"kW","fa_bolt\@silver",-3.6,3.6,0,90,["Solar,yellow","Eigen.,lime","Bezug,red"],[(-1,0,0,30,1,60,3.6,90)],"2","167,,1,,1,1",",,1,6")
oder
card([[zaehler:l-Produktion:col],[$SELF:l_Eigenv:col],[$SELF:l_Bezug:col]],"kW","fa_bolt\@silver",-3.6,3.6,0,90,["Solar,white","Eigen.,silver","Bezug,gray"],[(-1,0,0,30,1,60,3.6,90)],"2","167,,1,,1,1",",,1,6")
Wie gut der neue Algorithmus funktioniert, sieht man an der Gegenüberstellung einer Normalauflösung 72 Slots und einer doppelt so hohen mit 144. Alle Nuancen sind zu erkennen.
@jkriegl
habe versucht, deine Ansicht der Spritpreise nachzubauen..soo einfach ist das für mich nicht. Wäre schön, wenn Du deine Konfiguration posten würdest.
Beste Grüße
Jürgen K.
@Jürgen
card([[Sprit:Allg-e10:col6], [Sprit:HEM-e10:col6], [Sprit:JET-e10:col6], [Sprit:V-M-e10:col6]],"E10","fuel",[Sprit:e10min],[Sprit:e10min]+.1,120,0,["Allg","HEM","JET","V-M"],undef,"3","165,1,1,,,1,233")
min/max (Sprit:e10min) kannst Du auch card überlassen, ist ein userReading min((ReadingsVal($name,"Allg-e10",0), ReadingsVal...), abgerundet. Die Preise stammen von Tankerkönig.
Super! DANKE!!
Jetzt geht auch card mit ring2 mit festen Farben:
Umwelzpumpe -> Umwälzpumpe (glaube ich zumindest...)
Neue Version eingecheckt. Neue Funktionalität siehe letztes Beispiel:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Diesmal ohne Rechtschreibfehler.
ich habe auf einem komplett neuen Fhem welches nur Temperaturfühler beinhaltet mal diese Funktion Card ausprobiert, da ich gar nchts bekomme ausser einem initialized
Habe ich etwas übersehen oder braucht mein fhem noch etwas..?
DOIF ist aktuell das habe ich gerade per Update gemacht
Internals:
DEF {} attr di_cards uiTable {package ui_Table;\
}\
"Außen"|card([Temperatur_Norden:temperature:col],"Außen","temp_outside",-10,60,undef,undef,"°C",&temp_hue,"1","130,,,,",undef,undef,Temperatur_Norden:humidity:col],0,100,undef,undef,"%",&hum_hue,"0")
setuuid di_cards 60ca2e27-f33f-b063-4add-4a35eb028b274744
FUUID 60ca2eb4-f33f-b063-8f4d-c028b7a8cd872b40
MODEL Perl
NAME di_cards
NOTIFYDEV global
NR 700
NTFY_ORDER 50-di_cards
STATE initialized
TYPE DOIF
VERSION 24643 2021-06-16 07:26:15
READINGS:
2021-06-17 13:11:47 mode enabled
2021-06-17 13:11:47 state initialized
Regex:
accu:
collect:
condition:
0
helper:
DEVFILTER ^global$
NOTIFYDEV global
globalinit 1
last_timer 0
sleeptimer -1
perlblock:
0 block_01
uiState:
uiTable:
Attributes:
room DOIF,Temperaturen
Du hast offenbar die ganze Definition im DEF-Bereich vorgenommen.
Im DEF-Bereich soll hier aber nur {} stehen. Der Rest gehört in das Attribut ui_Table
Die Beispiele sind alle über Raw-Definition ins System zu übernehmen.
OK, dass hatte ich so gar nicht gesehen probiere ich mal sofort, dann klappt das sicher auch...! Danke
liegt wohl an der Hitze ;) :-\
An welcher Stelle setze ich z.B. bei dieser Ansicht die Größe ein ich habe dieses Beispiel aus dem Wiki angepaßt für mich.
Ich hatte nach etlichen Kommas hinter dem letzten Wert die Länge erweitern können, aber die Größe habe ich nicht gefunden.
defmod di_sprit DOIF ##
attr di_sprit alias Übersicht - 24 Stunden Kaufland
attr di_sprit room Spritpreise
attr di_sprit uiTable {package ui_Table;;}\
card([Kaufland:Diesel:col24],"Diesel","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,1")\
card([Kaufland:SuperE5:col24],"Super E5","fuel","1.10","1.60",120,0,"Super €",undef,"2",",,1")
Zitat von: moonsorrox am 17 Juni 2021, 17:56:25
An welcher Stelle setze ich z.B. bei dieser Ansicht die Größe ein ich habe dieses Beispiel aus dem Wiki angepaßt für mich.
Ich hatte nach etlichen Kommas hinter dem letzten Wert die Länge erweitern können, aber die Größe habe ich nicht gefunden.
defmod di_sprit DOIF ##
attr di_sprit alias Übersicht - 24 Stunden Kaufland
attr di_sprit room Spritpreise
attr di_sprit uiTable {package ui_Table;;}\
card([Kaufland:Diesel:col24],"Diesel","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,1")\
card([Kaufland:SuperE5:col24],"Super E5","fuel","1.10","1.60",120,0,"Super €",undef,"2",",,1")
In der Doku zu card ist der $prop-Parameter wie folgt beschrieben:
Zitat$prop # "<size>,<y-scaling>,<steps>,<noFooter>,<noColor>,<hring>,<width>", optional, <size>: Größe der der Karte, default = 130, <y-scaling>: feste Y-Skalierung: 1, sonst automatische Skalierung, <steps>: 1 für Stufen, <noFooter>: 1 für keine Fußzeile, <noColor>: 1 für graue y-Achsenbeschriftung, <hring>: 1 für Halbringdarstellung, <width>: Breite der Karte, default: 160
Jetzt musst du nur noch die Angabe in deinem Beispiel: ",,1" entsprechend anpassen.
In der Doku steht
Zitat$prop # "<size>,<y-scaling>,<steps>,<noFooter>,<noColor>,<hring>,<width>"
also 6 Kommata, wenn Du die Breite meinst oder meinst Du die size?
Alles klar jetzt habe ich es geschnallt... ja ich wollte die <size> haben
Zitat von: moonsorrox am 17 Juni 2021, 18:31:46
Alles klar jetzt habe ich es geschnallt... ja ich wollte die <size> haben
Dann die erste Zahl.
Es handelt sich um Perlfunktionen, daher muss man mit den Übergabeparametern in Perl leben. Attribute, die man setzen könnte, sind hier leider nicht möglich.
Zitat von: Damian am 17 Juni 2021, 18:54:23
Dann die erste Zahl.
Es handelt sich um Perlfunktionen, daher muss man mit den Übergabeparametern in Perl leben. Attribute, die man setzen könnte, sind hier leider nicht möglich.
Danke Damian, dass habe ich alles hinbekommen, sehr sehr schicke Ansichten die du da gebaut hast...
Was ich jetzt nochmal schauen muss ob ich auch zwei oder evtl. 3 nebeneinander hinbekomme, ist jetzt aber nicht so wichtig.
Ich hatte ja im Wiki schon einige nebeneinader oder auch untereinander gesehen, aber die sind evtl. nur so für die Ansicht dargestellt.
Zitat von: moonsorrox am 18 Juni 2021, 00:11:56
Danke Damian, dass habe ich alles hinbekommen, sehr sehr schicke Ansichten die du da gebaut hast...
Was ich jetzt nochmal schauen muss ob ich auch zwei oder evtl. 3 nebeneinander hinbekomme, ist jetzt aber nicht so wichtig.
Ich hatte ja im Wiki schon einige nebeneinader oder auch untereinander gesehen, aber die sind evtl. nur so für die Ansicht dargestellt.
siehe vorletztes Beispiel bei der card-Funktion (PV-Anlage)
EDIT:// ich glaube jetzt habe ich gefunden das ich erst einmal eine Tabelle mit dem Layout erstellen muss, ist das richtig.?
Im Wiki ganz oben ist das wohl beschrieben..!! :-\
Dann muss ich da wohl die Cards einfügen.?
also was ich überhaupt nicht hinbekomme ist diese Ansicht aus dem Bild
https://forum.fhem.de/index.php?action=dlattach;topic=120088.0;attach=151523;image (https://forum.fhem.de/index.php?action=dlattach;topic=120088.0;attach=151523;image)
das man nebeneinander zwei Card bekommt, ich habe in dem Beitrag die rote 1 gesehen, aber bei mir ändert das nichts. Oder muss das anders gemacht werden.?
defmod di_sprit DOIF ##
attr di_sprit alias Übersicht - 24 Stunden Kaufland
attr di_sprit room Spritpreise
attr di_sprit uiTable {package ui_Table;;}\
card([Kaufland:Diesel:col24],"Diesel","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,,1")\
card([Kaufland:SuperE5:col24],"Super E5","fuel","1.10","1.60",120,0,"Super €",undef,"2",",,,1")
Zitat von: moonsorrox am 21 Juni 2021, 17:34:34
EDIT:// ich glaube jetzt habe ich gefunden das ich erst einmal eine Tabelle mit dem Layout erstellen muss, ist das richtig.?
Im Wiki ganz oben ist das wohl beschrieben..!! :-\
Dann muss ich da wohl die Cards einfügen.?
also was ich überhaupt nicht hinbekomme ist diese Ansicht aus dem Bild
https://forum.fhem.de/index.php?action=dlattach;topic=120088.0;attach=151523;image (https://forum.fhem.de/index.php?action=dlattach;topic=120088.0;attach=151523;image)
das man nebeneinander zwei Card bekommt, ich habe in dem Beitrag die rote 1 gesehen, aber bei mir ändert das nichts. Oder muss das anders gemacht werden.?
defmod di_sprit DOIF ##
attr di_sprit alias Übersicht - 24 Stunden Kaufland
attr di_sprit room Spritpreise
attr di_sprit uiTable {package ui_Table;;}\
card([Kaufland:Diesel:col24],"Diesel","fuel","1.00","1.40",120,0,"Diesel €",undef,"2",",,,1")\
card([Kaufland:SuperE5:col24],"Super E5","fuel","1.10","1.60",120,0,"Super €",undef,"2",",,,1")
Das Trennzeichen zwischen zwei Zellen ist: |
siehe: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Einfache_Tabellendefinition_ohne_Funktionen
OK, vielen Dank...! ;)
Hat ein wenig gedauert bis ich es gebacken bekommen habe, aber jetzt siehts schick aus.
Muss noch die beiden unteren Werte der x-Achse formatieren, dann ist es gut
Ich denke, dass die Farbangabe nicht stimmt, denn die Y-Achse zeigt hier Regenbogenfarben (zu viele Farbwechsel)
Zitat von: Damian am 22 Juni 2021, 17:48:58
Ich denke, dass die Farbangabe nicht stimmt, denn die Y-Achse zeigt hier Regenbogenfarben (zu viele Farbwechsel)
ja genau muss ich noch optimieren, bin froh das ich es erstmal halbwegs hinbekommen habe, das er überhaupt was zeigt
Es ist zwar noch nicht dokumentiert, aber in der aktuellen Version lässt sich die Auflösung erhöhen. Eine Verdoppelung der Default-Auflösung von 72 auf 144 Messpunkte, kann bei langen Zeiträumen und breiter Grafik durchaus sinnvoll sein. Die Angabe der Messpunkte wird vor dem Schlüsselwort
col gemacht.
Bsp.:
Zitatcard([[zaehler:l-Produktion:144col1w],[zaehler:l-Eigenverbrauch:144col1w],[zaehler:l-Bezug_neg:144col1w]],"kW","fa_bolt\@silver",-3.6,3.6,0,90,["Solar","Eigen.","Bezug"],[(-1,0,-0.01,30,1,60,3.6,90)],"2","130,,1,1,,1","1,,1,0,1")
Gibt es einen Grund ein Vielfaches von 72 zu verwenden?
Bei meinem shelly führt es erst ab shelly_s:power:650col1 zu keinen Falschdarstellungen.
Zitat von: jkriegl am 29 Juli 2021, 17:31:35
Gibt es einen Grund ein Vielfaches von 72 zu verwenden?
Bei meinem shelly führt es erst ab shelly_s:power:650col1 zu keinen Falschdarstellungen.
nein, es gibt keinen Grund.
Bei 650 pro Stunde hast du eine Auflösung von ca. 5 Sekunden pro Messpunkt. Bei 160 Pixeln pro Grafik werden 650/160 ca. 4 Messpunkte pro Pixel berechnet - es ist deine Entscheidung.
Ich habe meine Übersicht etwas komprimiert, indem ich mehrere Cards mit zwei oder drei Sensoren bestückt habe. Es könnte für den einen oder anderen als Vorlage nützlich sein.
Die aktuelle Definition mit Output im Anhang:
defmod Aktuell DOIF ##
attr Aktuell alias Übersicht
attr Aktuell uiTable {package ui_Table;;\
$TC{0..1} = "style='vertical-align:top'"\
$TABLE='text-align:center;;';;\
$SHOWNOSTATE=1;;\
}\
## $prop: "<size>,<y-scaling>,<steps>,<noFooter>,<noColor>,<hring>,<width>"\
"<div class='doifclock'style='font-size:25pt;;color:silver'>wait</div>"<\
\
card([Aussensensor:temperature:col3d],undef,"temp_outside\@silver",-10,50,undef,undef,"°C",\&temp_hue,"1","130,,,0,,,",undef,undef,[outsensor:humidity:col3d],0,100,undef,undef,"%",\&hum_hue,"0")|\
card([Wetter:RegenGesamtMm:col3d],undef,"weather_rain_gauge\@silver",0,50,180,270,"mm",undef,"1","130,,1,0,1",undef,undef,[di_Regen:state:col3d],0,1,180,290,"Regen",undef,"1")\
\
card([ESPEasy_Eingang_CO2:PPM:col3d],undef,"air",400,1200,120,0,"ppm",[(600,120,1000,60,1200,0)],0,"130,,1,0",'0,,1')|\
card([Wetter:WindboeenKm:col3d],undef,"weather_wind\@silver",0,30,120,0,"km/h",undef,"1","130,,,0,1")\
\
\
card([[Tankstelle:SuperE5:col3d],[Tankstelle:Diesel:col3d]],undef,"fuel\@silver","1.20","1.60",120,0,["E5","Diesel"],undef,"2","130,,1,0",undef,undef)|\
card([Wasserverbrauch:heute:col1w],undef,"measure_water_meter\@silver",0,600,120,0,"l/d",undef,"0","130,1,1,0,",undef,undef,[Wasserzisterne:Stand:col1w],0,100,240,180,"%",undef,"0")\
\
card([RKI7:Dueren:col1w],undef,"coronavirus",0,200,120,0,"Fälle",undef,"0","130,,1,0,1")|\
card([di_vaillant:diff_h:col1w],undef,"sani_buffer_temp_down\@white",0,200,120,0,"kWh",undef,"1","130,,1,0,1")\
\
card([[zaehler:l-Produktion:144col3d],[zaehler:l-Eigenverbrauch:144col3d],[zaehler:l-Bezug_neg:144col3d]],"kW","fa_bolt\@silver",-3.6,3.6,0,90,["Solar,yellow","Eigen.,lime","Bezug,red"],[(-1,0,-0.01,30,1,60,3.6,90)],"2","130,,1,0,,1","1,,1,0,1")|\
\
card([[zaehler:Produktion:col1w],[zaehler:Bezug_neg:col1w]],"kWh","fa_bolt\@silver",-30,30,0,90,["Ertrag","Bezug"],undef,"1","130,,1,0,1","0,0,0,0,2")
DOIF-Update: card-Funktion
fixed: bei zwei verschiedenen Reading, die zu unterschiedlichen Zeiten triggerten, konnten die Plots in einer Card zeitlich auseinander laufen
feature: Y-Skalierung wurde von vier auf fünf Linien erhöht
feature: Zeiten in der Fußzeile sind jetzt ausgerichtet
Hallo Damian,
könntest Du bitte das Air Icon zur Verfügung stellen, finde es nirgends :-)
Danke und Gruß
Alex
Zitat von: Nighthawk am 04 Dezember 2021, 20:45:37
Hallo Damian,
könntest Du bitte das Air Icon zur Verfügung stellen, finde es nirgends :-)
Danke und Gruß
Alex
Danke Dir!
Hi Damian,
Ich würde die schicken Karten gerne wie bei SVG plots per Messenger verschicken.
Sowohl Signalbot als auch Telegrambot unterstützen ja, dass man folgende Funktion aufruft:
{plotAsPng('SVG_Aussentemperatur')}
Die liefert dann einen Stream mit dem png zurück, den der Messenger in eine Datei speichert und verschickt.
Geht sowas auch für die DOIF cards - oder wäre das als Erweiterung machbar?
Beispielanwendung: Ich chatte mein Zuhause per Signal mit dem Schlüsselwort "Benzin" an - und bekomme den aktuellen Benzinpreis meiner Lieblingstankstelle mit einer kurzen Historienkurve um die Preis einschätzen zu können.
Gruß,
Jörg
xenos1984 benutzt offenbar das RSS-Modul, um die Grafik weiterzuleiten:
https://forum.fhem.de/index.php/topic,118329.msg1135113.html#msg1135113
Zitat von: Damian am 17 Januar 2022, 19:20:27
xenos1984 benutzt offenbar das RSS-Modul, um die Grafik weiterzuleiten:
https://forum.fhem.de/index.php/topic,118329.msg1135113.html#msg1135113
Das waren allerdings die ring, bar etc. Funktionen. Mit card ist es mir bisher noch nicht gelungen. Letztlich muss man ja irgendwie die fertige Grafik als SVG haben und diese in PNG konvertieren. In meinem Fall geht das recht einfach, indem ich im RSS-Layout die entsprechende ui_Table::ring Funktion aufrufe, die mir ein SVG liefert. Bei card hat man aber den Trigger-Ausdruck [device:reading:XcolY], der innerhalb von DOIF ausgewertet wird, aber nicht in beliebigem Perl-Code außerhalb des Moduls. Man muss also dafür sorgen, dass dieser Code in DOIF ausgewertet wird. Wie man das am besten anstellt, ist mir aber nicht wirklich klar...
Zitat von: xenos1984 am 17 Januar 2022, 22:42:48
Das waren allerdings die ring, bar etc. Funktionen. Mit card ist es mir bisher noch nicht gelungen. Letztlich muss man ja irgendwie die fertige Grafik als SVG haben und diese in PNG konvertieren. In meinem Fall geht das recht einfach, indem ich im RSS-Layout die entsprechende ui_Table::ring Funktion aufrufe, die mir ein SVG liefert. Bei card hat man aber den Trigger-Ausdruck [device:reading:XcolY], der innerhalb von DOIF ausgewertet wird, aber nicht in beliebigem Perl-Code außerhalb des Moduls. Man muss also dafür sorgen, dass dieser Code in DOIF ausgewertet wird. Wie man das am besten anstellt, ist mir aber nicht wirklich klar...
Das müsste über das uiState-Attribut gehen. Diejenigen, die z. B. Dashboard nutzen, definieren ihre Cardfunktion im uiState eines DOIF-Devices und greifen dann auf den Status des DOIF-Devices mit der Grafik: https://forum.fhem.de/index.php/topic,121004.msg1161405.html#msg1161405
Zitat von: Damian am 17 Januar 2022, 22:57:43
...und greifen dann auf den Status des DOIF-Devices mit der Grafik:
Wie würde man denn daraus die SVG-Grafik extrahieren, um sie zu konvertieren?
In RSS habe ich es mal testweise so eingebunden:
define di_test DOIF {}
attr di_test DOIF_Readings test:[device:reading:144col6]
RSS Layout:
img 1 1 1 svg data {ui_Table::card(ReadingsVal("di_test","test",0),"Temperature","temp_temperature",-35,35,240,0,"°C",undef,1,"240,,,,,,200")}
Zitat von: xenos1984 am 17 Januar 2022, 23:03:50
Wie würde man denn daraus die SVG-Grafik extrahieren, um sie zu konvertieren?
In RSS habe ich es mal testweise so eingebunden:
define di_test DOIF {}
attr di_test DOIF_Readings test:[device:reading:144col6]
RSS Layout:
img 1 1 1 svg data {ui_Table::card(ReadingsVal("di_test","test",0),"Temperature","temp_temperature",-35,35,240,0,"°C",undef,1,"240,,,,,,200")}
Man müsste schauen, wie die Programme auf die Statuszeile eines Devices zugreifen. Ich habe es damals mit Floorplan erfolgreich getestet, was auch über die Statuszeile eines Devices funktioniert.
Das DOIF-Device selbst sieht ja so aus:
defmod di_cardtest DOIF {}
attr di_cardtest uiState {package ui_Table}\
card([mydevice:reading:col],...)
Sie rufen offenbar intern auch die summaryFn-Funktion des jeweiligen Moduls auf. Das ist ja die Funktion, die für die Darstellung des Status im jeweiligen Modul zuständig ist. Wenn es nur um eine Card-Darstellung geht und nicht um eine ganze ui-Tabelle, dann kann man auch deinen Vorschlag gut nutzen.
Also den HTML-Code der ganzen Tabelle (hier in di_mytable-DOF-Device) kann man erhalten durch den Aufruf:
DOIF_detailFn(undef,"di_mytable",undef,undef)
und falls sie im Status ist mit
DOIF_summaryFn(undef,"di_mytable",undef,undef)
RSS wäre dann z. B.
img 1 1 1 svg data {DOIF_summaryFn(undef,"di_mytable",undef,undef)}
Damit hatte ich keinen Erfolg (wobei das überhaupt meine ersten Gehversuche mit dem RSS Modul waren).
Beim rumprobieren habe ich es sogar geschafft mein FHEM aufzuhängen.
Selbst wenn das so funktioniert, ist es ja doch recht aufwändig. Wenn ich mir den Code für plotAsPng im SVG Modul anschaue, dann sieht das erstmal gar nicht kompliziert aus. Macht ja weitgehend eine Library die einfach die SVG Daten braucht. Die sollten ja jeweils bereits vorliegen?
@Damian: Wäre es nicht analog denkbar ein "uitableAsPng" zu bauen?
Aufruf z.B. uitableAsPng("DI_uitable","card",2) , wobei "card" und 2 optional wäre und ggf. den ganzen uitable (ganz ohne) oder alle Objekte vom Typ "card" - oder eben die zweite Card (oder alternativ über einen Namen) als Stream zurückgibt.
Wäre halt ziemlich Klasse und würde es ermöglichen die Elemente flexibel einzusetzen.
Zitat von: Adimarantis am 18 Januar 2022, 22:53:56
Damit hatte ich keinen Erfolg (wobei das überhaupt meine ersten Gehversuche mit dem RSS Modul waren).
Beim rumprobieren habe ich es sogar geschafft mein FHEM aufzuhängen.
Selbst wenn das so funktioniert, ist es ja doch recht aufwändig. Wenn ich mir den Code für plotAsPng im SVG Modul anschaue, dann sieht das erstmal gar nicht kompliziert aus. Macht ja weitgehend eine Library die einfach die SVG Daten braucht. Die sollten ja jeweils bereits vorliegen?
@Damian: Wäre es nicht analog denkbar ein "uitableAsPng" zu bauen?
Aufruf z.B. uitableAsPng("DI_uitable","card",2) , wobei "card" und 2 optional wäre und ggf. den ganzen uitable (ganz ohne) oder alle Objekte vom Typ "card" - oder eben die zweite Card (oder alternativ über einen Namen) als Stream zurückgibt.
Wäre halt ziemlich Klasse und würde es ermöglichen die Elemente flexibel einzusetzen.
Was soll "DI_uitable" sein? Was soll das Ergebnis sein? HTML-Code, jpeg, png ...
Bei Card und Co. handelt es sich um reine Perl-Funktionen, daher weiß das Modul nicht, was es da aufruft, deswegen gib es auch keine Typen als Unterscheidungskriterium.
Man muss wissen, dass Card, im Gegensatz zu anderen SVG-Funktionen, wie z. B. ring, ein DOIF-Device zum Sammeln von Daten benötigt. Daher ist ein einfacher Funktionsaufruf der Perl-Funktion immer an ein Objekt, welches in einem DOIF-Device definiert werden muss [<device>:<reading>:col] gebunden.
Ich finde, dass man mit HTML-Code schon ziemlich flexibel, effizient und speicherplatzschonend in der Ausgabe ist, wenn man es als reines png haben will, dann sollte man entsprechende Tools zur Wandlung benutzen
Ich habe jetzt weiter rumexperimentiert und hinbekommen, was ich wollte - nur mache ich da sehr viele Annahmen darüber wie DOIF intern funktioniert und jede Änderung könnte das ganze wieder schmeissen. Ist also eher ein Proof of Concept.
Ich kann mir jetzt per
set SignalBot send @Joerg &({uiAsPng(\"DI_collect\",3)})
zum Beispiel ein Bild der vierten "card" die im DOIF "DI_collect" als uiTable definiert ist aufs Handy schicken.
Zum Umwandeln des SVG in PNG verwende ich die selbe Library die auch plotAsPng vom SVG Modul verwendet.
Die verträgt allerdings einige HTML Konstrukte nicht, daher rufe ich die "card" Funktion direkt auf (und hole mir die mit Parametern aus den internen Readings) und selbst da muss ich noch was per regexp entfernen.
Mein (verpäteter) Weihnachtswunsch wäre jetzt eine öffentliche API die mir das pure SVG (oder gleich das PNG) liefert. Ich verwende jetzt als Argument den Index, schöner wäre wahrscheinlich der Name der Überschrift oder des Readings. Ich matche jetzt explizit auf "card" - sollte aber dann wohl für beliebige Widgets funktionieren.
Dazu hab ich mir in myUitls folgendes definiert:
sub
uiAsPng($$)
{
my ($DoifName,$id) = @_;
my (@webs, $mimetype, $svgdata, $rsvg, $pngImg);
my $hash = $defs{$DoifName};
if (!defined $hash) {
return "$DoifName not found";
}
if (!defined $hash->{'uiTable'}{table} ) {
return "DOIF has not uiTable defined";
}
my $table=$hash->{'uiTable'}{table}{0}{$id}{0}{0};
if (!defined $table) {
return "uiTable with ID $id not found";
}
$table =~ /.*(card\(.*\)),""\)/;
my $card="package ui_Table;"."$1".";";
if (defined $card && $card ne "") {
$svgdata=eval($card);
print $@;
} else {
return "uiTable format error (no card)";
}
if (! defined $svgdata) {
return "Error getting data from card";
}
$svgdata='<?xml version="1.0" encoding="UTF-8"?> <svg>'.$svgdata.'</svg>';
eval {
require Image::LibRSVG;
$rsvg = new Image::LibRSVG();
$rsvg->loadImageFromString($svgdata);
$pngImg = $rsvg->getImageBitmap();
};
if (defined $pngImg && $pngImg ne "") {
return $pngImg if $pngImg;
}
return "Error retrieving PNG";
}
OK. Benutzt du denn bei dir in FHEM DOIFs mit uiTable mit mehreren Elementen?
Meine (bisher einzige) Definition schaut so aus:
{package ui_Table;}
card([out_temp:temperature:col24],"Außen","out_temp",-10,30,undef,undef,"°C",\&temp_hue,undef)|
card([WS4500_WIND_1:wind_speed:col3d],"Wind",[WS4500_WIND_1:wind_avspeed] > 0 ? "wind".",1,0,0,".[WS4500_WIND_1:degree]:"no_wind",0,30,90,30,"km/h",undef,1)|
card([Tankstelle:Diesel:col7d],"Diesel,fill:darkorange","fuel","1.30","1.60",120,0,"Diesel €",undef,"2",",,1")|
card([Tankstelle:SuperE10:col7d],"Super E10,fill:darkorange","fuel","1.40","1.70",120,0,"E10 €",undef,"2",",,1")
und mir ist klar, dass die Indexe in deiner internen Tabelle nur genau für die Variante funktionieren - ich habe mich jetzt nicht damit beschäftigt wie die ganzen Ebenen verschachtelt sind. Daher wäre ja auch statt Index ein Namensmatching besser (z.B. dann eben "Super E10") - mir ging es aber erstmal nur darum das überhaupt irgendwie hinzukriegen.
Ich würde einen anderen Ansatz wählen. Wenn man weiß, dass man irgendwo außerhalb des DOIF Moduls zusätzlich den HTML-Code bestimmter Card-Funktion benötigt, dann würde ich folgende Vorgehensweise empfehlen - hier am Beispiel deiner Definition für die Darstellung des Sprits:
aus:
{package ui_Table;}
...
card([Tankstelle:Diesel:col7d],"Diesel,fill:darkorange","fuel","1.30","1.60",120,0,"Diesel €",undef,"2",",,1")|
card([Tankstelle:SuperE10:col7d],"Super E10,fill:darkorange","fuel","1.40","1.70",120,0,"E10 €",undef,"2",",,1")
...
definiert man passende Readings für die benötigten Daten:
attr DOIF_Readings Diesel:[Tankstelle:Diesel:col7d], SuperE10:[Tankstelle:SuperE10:col7d]
die Tabelle wird dann auf die eigenen Readings angepasst:
{package ui_Table;}
...
card([$SELF:Diesel],"Diesel,fill:darkorange","fuel","1.30","1.60",120,0,"Diesel €",undef,"2",",,1")|
card([$SELF:SuperE10],"Super E10,fill:darkorange","fuel","1.40","1.70",120,0,"E10 €",undef,"2",",,1")
...
jetzt kann man an einer beliebigen Stelle in FHEM die gewünschte Card-Funktion aufrufen, hier z. B. mit:
ui_Table::card(ReadingsVal("<Name des DOIFs>","Diesel",0),"Diesel,fill:darkorange","fuel","1.30","1.60",120,0,"Diesel €",undef,"2",",,1")
Der zusätzliche Vorteil ist, dass man z. B. die Größe der Grafik oder sonstige Parameter für den eigenen Output ändern kann, trotzdem werden die benötigten Daten nur einmal im DOIF gesammelt und verbleiben auch dort. Das ursprüngliche Layout der eigenen Tabelle im DOIF bleibt dabei unverändert.
Hallo Damian,
danke. Ich hab versucht dein Beispiel nachzubauen, aber irgendwie scheitere ich dann dabei die card Funktion aufzurufen
Can't use string ("0") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 4808.
Ich habe es allerdings zum Testen einfach in die Eingabezeile eingebettet {....;;} - vielleicht wird da was komisch escaped.
Grundsätzlich stimmt es schon, dass diese Variante zumindest schon mal nicht mehr von internen Datenstrukturen abhängig ist und eine abweichende Darstellung zulässt.
Mich persönlich stört dabei allerdings, dass man eben zweimal "die selbe" Konfigration braucht und diese noch dazu "hardcoded" z.B. in myUtils oder entsprechenden Perl Code in ein DOIF muss. Auch finde ich es ja gerade gut, dass mir das DOIF quasi einen Preview zeigt. Eine Zoomfunktion hätte libsvg, das liesse sich leicht als optionalen Parameter einflechten.
In a nutshell: Eine Funktion in DOIF mit der ich aus einem anderen Modul (würde ich dann z.B. in den SignalBot einbauen) einfach pure SVG (oder sogar PNG) Daten holen kann, fände ich benutzerfreundlicher und wäre auch für nicht so versierte Anwender eine machbare Option.
Die entsprechende Funktion sollte am Besten als Parameter einfach den Namen des DOIFs und den Namen des Readings nehmen.
Ich denke so eine Funktion würde auch ganz andere Anwendungsfälle erleichtern, z.B. die DOIF Widgets einfacher in FTUI einzubinden.
Aber wie gesagt ist nur ein Wunsch und ich bedanke mich auf jeden Fall schon mal für alle Hilfestellungen. Wahrscheinlich bleibe ich vorerst bei meiner Lösung (evtl. etwas verfeinert, z.B. könnte ich ja den Hash durchiterieren und eben auf den Readingsnamen matchen statt Annahmen über den Index zu machen).
Gruß,
Jörg
Zitat von: Adimarantis am 23 Januar 2022, 11:16:36
Can't use string ("0") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 4808.
Vermutlich hast du ein ReadingsVal angegeben, für ein nicht vorhandenes Reading mit dem Defaultwert 0, 0 ist dann keine Hash-Referenz, die sonst in dem Reading erwartet wird.
ZitatMich persönlich stört dabei allerdings, dass man eben zweimal "die selbe" Konfigration braucht und diese noch dazu "hardcoded" z.B. in myUtils oder entsprechenden Perl Code in ein DOIF muss.
Die interne Struktur ist eben nicht dafür ausgelegt nach bestimmten Datenstrukturen zu suchen, intern wird allerdings aufgrund eines triggernden Devices und Readings eine Zuordnung zu einzelnen Zellen gemacht, aber das ist ja wieder etwas anders.
Auch den gleichen Code kann man minimieren, in dem man eine Perlfunktion definiert, die genau den card-Aufruf tätigt, dann braucht man nur diese in der Tabelle, wie auch beim externen Aufruf nutzen. Klar, man muss in diesen Fällen im Vorfeld aktiv werden.
Edit: Deswegen ist auch die Suche nach "card" nicht zielführend, da sie in einer anderen Perlfunktion stecken kann.
Zitat von: Damian am 23 Januar 2022, 12:40:07
Vermutlich hast du ein ReadingsVal angegeben, für ein nicht vorhandenes Reading mit dem Defaultwert 0, 0 ist dann keine Hash-Referenz, die sonst in dem Reading erwartet wird.
Ja, richtig, da hatte ich mich wohl vertippt. Kaum macht man es richtig, geht es auch.
ZitatEdit: Deswegen ist auch die Suche nach "card" nicht zielführend, da sie in einer anderen Perlfunktion stecken kann.
Ja, meine "card" regexp war jetzt beim reverse engineering einfach quick&dirty um den DOIF_Widget Teil (der ja noch das <div> hinzufügt) wegzufiltern.
Das könnte man sicher sauberer machen, bis hin zur Verwendung einer XML Library mit der man aus dem Ergebnis einfach die störenden Tags entfernt und den gewünschten Abschnitt rausfiltert.
Wie gesagt. Mir reichts das erstmal so und wenn künftige DOIFs was ändern, muss ichs halt anpassen.
Vielleicht packt dich aber ja doch irgendwann mal Lust&Laune eine einfache und stabile Methode zur Verfügung zu stellen :)
Ich habe meinen Code noch etwas verfeinert, so dass er jetzt hoffentlich relativ robust gegen DOIF Änderungen sein sollte und mal in eine Testversion meines Signalbot Moduls eingebaut:
https://forum.fhem.de/index.php/topic,118370.msg1204008.html#msg1204008
Ist jetzt flexibel über (hoffentlich alle) verschiedenen Widgets und über Index, Device und/oder Reading adressierbar.
Bei Interesse - die Funktion heisst: Signalbot_DOIFAsPng
Jörg
Hier mal Card für Raumtemperaturen: https://forum.fhem.de/index.php/topic,125829.msg1204293.html#msg1204293
Ich bin auf der Suche nach einer Erläuterung der Funktion colorRef. Im Wiki, in der commandref und in Google finde ich aber nix. Kann mir jemand helfen?
Zitat von: andies am 29 Januar 2022, 21:36:12
Ich bin auf der Suche nach einer Erläuterung der Funktion colorRef. Im Wiki, in der commandref und in Google finde ich aber nix. Kann mir jemand helfen?
Die Funktion muss zu einem beliebigen Zahlenwert einen hue-Wert zwischen 0 und 360 zurückliefern.
Ich brauchte gerade eine, die mir beim Zahlenwert 0 blau (hue 240) liefert, sonst immer rot (hue 0):
attr uiTable {
package ui_Table;
sub onoff_hue {
my($redblue)=@_;
return ($redblue == 0 ? 240 : 0);
}
## Tabellendefinition
...
}
angegeben wird dann \&onoff_hue als colorRef-Parameter
Ich habe bei meiner Raumübersicht (vorheriger Link) jetzt statt Feuchte, das Thermostatrelais mit der obigen Funktion realisiert, damit kann ich sehen, ob gerade bzw. wann geheizt wurde.
Noch eine Frage. Kann ich anpassen, was bei card innerhalb des Rings angezeigt wird? Ich sehe dort aktuelle Werte, würde aber gern zB Summen oder Minima/Maxima dort stehen haben. Geht das?
Zitat von: andies am 30 Januar 2022, 20:50:31
Noch eine Frage. Kann ich anpassen, was bei card innerhalb des Rings angezeigt wird? Ich sehe dort aktuelle Werte, würde aber gern zB Summen oder Minima/Maxima dort stehen haben. Geht das?
schnelle Antwort: nein
Kapiert. Und ein anderes Reading? Wäre das leichter umsetzbar?
Zitat von: andies am 30 Januar 2022, 20:58:36
Kapiert. Und ein anderes Reading? Wäre das leichter umsetzbar?
Man kann mehrere Readings angeben, aber aller Werte die irgendwo im Ring oder in mehreren Halbringen dargestellt werden, werden auch geplottet.
Zitat von: Damian am 30 Januar 2022, 21:13:23
Man kann mehrere Readings angeben, aber aller Werte die irgendwo im Ring oder in mehreren Halbringen dargestellt werden, werden auch geplottet.
Man kann natürlich beliebige Daten in der Kopfzeile innerhalb der Karte in Textform einblenden, also auch beliebige Werte aus irgendwelchen Readings.
card-Anwendung für Raumthermostate: https://wiki.fhem.de/wiki/DOIF/Automatisierung#Steuerung_von_Raumthermostaten_f.C3.BCr_mehrere_R.C3.A4ume_mit_GUI
Zum Thema Strom: https://forum.fhem.de/index.php/topic,126005.msg1205980.html#msg1205980
Ich probiere gerade das neue global encoding=unicode aus (siehe https://forum.fhem.de/index.php/topic,126088.0.html ) und habe da Probleme mit den Cards
Wenn ich versuche eine uiTable Definition zu speichern (ohne Sonderzeichen!) kommt:
PERL WARNING: Bareword found where operator expected at (eval 1222) line 2, near "'error Unrecognized character \x{2424}; marked by <-- HERE after ui_Table;<-- HERE near column 18 at (eval 1221) line 1.
in expression: card(::ReadingValDoIf($hash,'HMIP_PSM_XXX"
(Might be a runaway multi-line '' string starting on line 1)
2022.02.19 12:41:43.367 1: stacktrace:
2022.02.19 12:41:43.367 1: main::__ANON__ called by (eval 1222) (2)
2022.02.19 12:41:43.367 1: (eval) called by ./FHEM/98_DOIF.pm (706)
2022.02.19 12:41:43.368 1: main::DOIF_RegisterEvalAll called by ./FHEM/98_DOIF.pm (757)
2022.02.19 12:41:43.368 1: main::DOIF_detailFn called by ./FHEM/01_FHEMWEB.pm (1560)
2022.02.19 12:41:43.368 1: main::FW_doDetail called by ./FHEM/01_FHEMWEB.pm (1194)
2022.02.19 12:41:43.368 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (604)
2022.02.19 12:41:43.368 1: main::FW_Read called by fhem.pl (3929)
2022.02.19 12:41:43.369 1: main::CallFn called by fhem.pl (780)
2022.02.19 12:41:43.369 1: PERL WARNING: (Missing operator before HMIP_PSM_XXX?)
2022.02.19 12:41:43.369 1: stacktrace:
2022.02.19 12:41:43.369 1: main::__ANON__ called by (eval 1222) (2)
2022.02.19 12:41:43.369 1: (eval) called by ./FHEM/98_DOIF.pm (706)
2022.02.19 12:41:43.370 1: main::DOIF_RegisterEvalAll called by ./FHEM/98_DOIF.pm (757)
2022.02.19 12:41:43.370 1: main::DOIF_detailFn called by ./FHEM/01_FHEMWEB.pm (1560)
2022.02.19 12:41:43.370 1: main::FW_doDetail called by ./FHEM/01_FHEMWEB.pm (1194)
2022.02.19 12:41:43.370 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (604)
2022.02.19 12:41:43.370 1: main::FW_Read called by fhem.pl (3929)
2022.02.19 12:41:43.371 1: main::CallFn called by fhem.pl (780)
Wide character in subroutine entry at ./FHEM/93_DbLog.pm line 2406.
Danach friert FHEM ein und startet sich nach einer Weile neu (ob das jetzt an DOIF oder DbLog liegt ist scher zu sagen)
Außerdem werden die "Pfeile" falsch kodiert (siehe Bild). Um DOIF fit für Unicode zu machen, sind wahrscheinlich noch Anpassungen nötig.
Sonderzeichen (Umlaute, € scheinen aber grundsätzlich zu gehen)
Zitat von: Adimarantis am 19 Februar 2022, 12:50:04
Ich probiere gerade das neue global encoding=unicode aus (siehe https://forum.fhem.de/index.php/topic,126088.0.html ) und habe da Probleme mit den Cards
Wenn ich versuche eine uiTable Definition zu speichern (ohne Sonderzeichen!) kommt:
PERL WARNING: Bareword found where operator expected at (eval 1222) line 2, near "'error Unrecognized character \x{2424}; marked by <-- HERE after ui_Table;<-- HERE near column 18 at (eval 1221) line 1.
in expression: card(::ReadingValDoIf($hash,'HMIP_PSM_XXX"
(Might be a runaway multi-line '' string starting on line 1)
2022.02.19 12:41:43.367 1: stacktrace:
2022.02.19 12:41:43.367 1: main::__ANON__ called by (eval 1222) (2)
2022.02.19 12:41:43.367 1: (eval) called by ./FHEM/98_DOIF.pm (706)
2022.02.19 12:41:43.368 1: main::DOIF_RegisterEvalAll called by ./FHEM/98_DOIF.pm (757)
2022.02.19 12:41:43.368 1: main::DOIF_detailFn called by ./FHEM/01_FHEMWEB.pm (1560)
2022.02.19 12:41:43.368 1: main::FW_doDetail called by ./FHEM/01_FHEMWEB.pm (1194)
2022.02.19 12:41:43.368 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (604)
2022.02.19 12:41:43.368 1: main::FW_Read called by fhem.pl (3929)
2022.02.19 12:41:43.369 1: main::CallFn called by fhem.pl (780)
2022.02.19 12:41:43.369 1: PERL WARNING: (Missing operator before HMIP_PSM_XXX?)
2022.02.19 12:41:43.369 1: stacktrace:
2022.02.19 12:41:43.369 1: main::__ANON__ called by (eval 1222) (2)
2022.02.19 12:41:43.369 1: (eval) called by ./FHEM/98_DOIF.pm (706)
2022.02.19 12:41:43.370 1: main::DOIF_RegisterEvalAll called by ./FHEM/98_DOIF.pm (757)
2022.02.19 12:41:43.370 1: main::DOIF_detailFn called by ./FHEM/01_FHEMWEB.pm (1560)
2022.02.19 12:41:43.370 1: main::FW_doDetail called by ./FHEM/01_FHEMWEB.pm (1194)
2022.02.19 12:41:43.370 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (604)
2022.02.19 12:41:43.370 1: main::FW_Read called by fhem.pl (3929)
2022.02.19 12:41:43.371 1: main::CallFn called by fhem.pl (780)
Wide character in subroutine entry at ./FHEM/93_DbLog.pm line 2406.
Danach friert FHEM ein und startet sich nach einer Weile neu (ob das jetzt an DOIF oder DbLog liegt ist scher zu sagen)
Außerdem werden die "Pfeile" falsch kodiert (siehe Bild). Um DOIF fit für Unicode zu machen, sind wahrscheinlich noch Anpassungen nötig.
Sonderzeichen (Umlaute, € scheinen aber grundsätzlich zu gehen)
DOIF reicht alle Zeichen durch, ohne Behandlung. Das Zeichen \x{2424} scheint beim Perlinterpreter Probleme zu bereiten.
\x{2424} ist das newline welches im neuen Modus von FHEMWEB wohl so geliefert wird und womit Perl tatsächlich Probleme hat. Das lässt sich mit einem einfachen stateFormat mit Perl code und Zeilenumbruch auch nachstellen (allerdings friert dann FHEM nicht ein). Das melde ich mal im anderen Thread an Rudi - wird langsam doch komplex die Sache.
Wenn ich alle Zeilenumbrüche rausnehme, geht es bis auf die Pfeile. Da wäre im neuen Modus evtl. ein decode_utf8 oder encode_utf8 nötig.
Zitat von: Adimarantis am 19 Februar 2022, 14:50:23
\x{2424} ist das newline welches im neuen Modus von FHEMWEB wohl so geliefert wird und womit Perl tatsächlich Probleme hat. Das lässt sich mit einem einfachen stateFormat mit Perl code und Zeilenumbruch auch nachstellen (allerdings friert dann FHEM nicht ein). Das melde ich mal im anderen Thread an Rudi - wird langsam doch komplex die Sache.
Wenn ich alle Zeilenumbrüche rausnehme, geht es bis auf die Pfeile. Da wäre im neuen Modus evtl. ein decode_utf8 oder encode_utf8 nötig.
solange die Sache mit dem neuen Modus nicht ausgereift ist, möchte ich nichts ändern.
Die Pfeile könnte man auch als &xUUUU; angeben - dann hat man reines ASCII und das Encoding ist egal.
Ich möchte gern die Y-Achse fixieren. D.h. alle Werte > y-max und < y-min sollen ignoriert werden. Derzeit übernimmt offenbar die automatische Skalierung, wenn z.B. y-max überschritten wird. Meine Lösung ist ein entsprechendes Userreading, aber könntest Du es nicht als Variante in card einbauen?
Zitat von: hajo23 am 20 Februar 2022, 16:14:08
Ich möchte gern die Y-Achse fixieren. D.h. alle Werte > y-max und < y-min sollen ignoriert werden. Derzeit übernimmt offenbar die automatische Skalierung, wenn z.B. y-max überschritten wird. Meine Lösung ist ein entsprechendes Userreading, aber könntest Du es nicht als Variante in card einbauen?
Leider sind die Parametrisierungsoptionen inzwischen sehr überladen. Ich würde die spezielle Anforderung über DOIF_Readings lösen, dann werden noch nicht mal zusätzliche Events produziert.
Zitat von: xenos1984 am 19 Februar 2022, 16:36:45
Die Pfeile könnte man auch als &xUUUU; angeben - dann hat man reines ASCII und das Encoding ist egal.
neue Version eingecheckt: card ist jetzt unicode kompatibel
Danke. Nachdem auch Rudi jetzt das "newline" Problem gefixed hat funktioniert bei mir jetzt soweit alles auch mit encoding=unicode
Neue DOIF-Version eingecheckt: Problembehebung: Anzeige wurde nicht automatisch aktualisiert, wenn mehrere collect-Angaben als Array angegeben wurden.
Bei collect-Angaben kann nun der anzuzeigende Wert des Readings vor seiner Darstellung verändert werden.
Dazu kann die Angabe um <output> erweitert werden.
Syntax: [<Device>:<Reading>:col<Anzahl><Zeitformat>:<output>]
Beispiel: Für die Darstellung soll der Wert on auf 1, sonst auf 0 abgebildet werden:
[Stellantrieb:state:col1d:$_ eq "on" ? 1 : 0]
$_ ist der Wert des Readings, <output> wird über eval ausgewertet.
Anwendungsbeispiel siehe: https://wiki.fhem.de/wiki/DOIF/Automatisierung#Steuerung_von_Raumthermostaten_f.C3.BCr_mehrere_R.C3.A4ume_mit_GUI
Moin,
weil es so schön ist, habe ich eine Menge "cards" eingerichtet. Funktioniert super, sieht toll aus.
Aaaaber:
Rufe ich in FHEM einen Raum mit vielen Cards auf, steigt die CPU-Last sowie der Speicherverbrauch sprunghaft (8-10x) an.
In HTOP sehe ich dann 16 Perl/FHEM PIDs. Diese bauen sich nach ca. 2min wieder ab, aber FHEM ist für diese Zeit blockiert.
Meine Hardware ist in der Signatur. Braucht Ihr noch weitere Infos über die Perlversion etc ? Das System halte ich wöchentlich ziemlich aktuell.
Oder habe ich bei den Cards was falsch gemacht.... (obwohl sie tadellos funktionieren)
Mist, bei editieren wird die "Code-Funktion" zerschossen, will heissen, wahrscheinlich aufgrund der Länge wird "[/code]" immer abgeschnitten.
Hier das List eines Cards
Internals:
DEF ##
FUUID 6093ad60-f33f-7539-95ec-f7859aec691b464f
MODEL FHEM
NAME di_Energy
NOTIFYDEV MQTT2_DVES_657752,Licht.Marius,Licht.Treppe,MQTT2_shellyplug_s_F02BB3,1wire_Strom_Gesamt,Licht.Terasse,Licht.Kino,MQTT2_shellyplug_s_BBA348,Licht.Flur,Tasmota.Oelradiator,Zwave_Plug1,Strom.Dachboden,MQTT2_DVES_462F4B,Tasmota.Koogeek4,Tasmota.Frei_1.1,Licht.Gaeste,Licht.SaunaRuheRaum,MQTT2_DVES_4519BA,Licht.Stehlampe.Gaeste,Licht.Kueche,Licht.Stehlampe,Shelly.DachbodenPV,Licht.Gartenhaus,Tasmota.Trockner,MQTT2_shellyplug_s_1C121B,powerday,Licht.Terasse2,global,sysmon,Waschmaschine,MQTT2_DVES_45B635,Licht.Moritz,Zwave.KinoHifi,Tasmota.Koogeek2,Licht.TV
NR 1497
NTFY_ORDER 50-di_Energy
STATE initialized
TYPE DOIF
VERSION 25720 2022-02-20 21:38:26
READINGS:
2021-05-06 10:48:32 mode enabled
2021-05-06 10:48:32 state initialized
Regex:
accu:
collect:
1wire_Strom_Gesamt:
collect:
E-Energy ^1wire_Strom_Gesamt$:^E-Energy:
E-Power ^1wire_Strom_Gesamt$:^E-Power:
Hz-Power ^1wire_Strom_Gesamt$:^Hz-Power:
Licht.Flur:
collect:
power ^Licht.Flur$:^power:
Licht.Gaeste:
collect:
power ^Licht.Gaeste$:^power:
Licht.Gartenhaus:
collect:
power ^Licht.Gartenhaus$:^power:
Licht.Kino:
collect:
power ^Licht.Kino$:^power:
Licht.Kueche:
collect:
power ^Licht.Kueche$:^power:
Licht.Marius:
collect:
power ^Licht.Marius$:^power:
Licht.Moritz:
collect:
power ^Licht.Moritz$:^power:
Licht.SaunaRuheRaum:
collect:
power ^Licht.SaunaRuheRaum$:^power:
Licht.Stehlampe:
collect:
power ^Licht.Stehlampe$:^power:
Licht.Stehlampe.Gaeste:
collect:
power ^Licht.Stehlampe.Gaeste$:^power:
Licht.TV:
collect:
power ^Licht.TV$:^power:
Licht.Terasse:
collect:
relay_0_power ^Licht.Terasse$:^relay_0_power:
Licht.Terasse2:
collect:
relay_1_power ^Licht.Terasse2$:^relay_1_power:
Licht.Treppe:
collect:
power ^Licht.Treppe$:^power:
MQTT2_DVES_4519BA:
collect:
ENERGY_Power ^MQTT2_DVES_4519BA$:^ENERGY_Power:
MQTT2_DVES_45B635:
collect:
ENERGY_Power ^MQTT2_DVES_45B635$:^ENERGY_Power:
MQTT2_DVES_462F4B:
collect:
ENERGY_Power ^MQTT2_DVES_462F4B$:^ENERGY_Power:
MQTT2_DVES_657752:
collect:
ENERGY_Power ^MQTT2_DVES_657752$:^ENERGY_Power:
ENERGY_Today ^MQTT2_DVES_657752$:^ENERGY_Today:
MQTT2_shellyplug_s_1C121B:
collect:
relay_0_power ^MQTT2_shellyplug_s_1C121B$:^relay_0_power:
MQTT2_shellyplug_s_BBA348:
collect:
relay_0_power ^MQTT2_shellyplug_s_BBA348$:^relay_0_power:
MQTT2_shellyplug_s_F02BB3:
collect:
relay_0_power ^MQTT2_shellyplug_s_F02BB3$:^relay_0_power:
Shelly.DachbodenPV:
collect:
SunAlt ^Shelly.DachbodenPV$:^SunAlt:
SunAz ^Shelly.DachbodenPV$:^SunAz:
power_0 ^Shelly.DachbodenPV$:^power_0:
power_1 ^Shelly.DachbodenPV$:^power_1:
Strom.Dachboden:
collect:
Dachboden ^Strom.Dachboden$:^Dachboden:
Tasmota.Frei_1.1:
collect:
ENERGY_POower ^Tasmota.Frei_1.1$:^ENERGY_POower:
ENERGY_Power ^Tasmota.Frei_1.1$:^ENERGY_Power:
Tasmota.Koogeek2:
collect:
ENERGY_Power ^Tasmota.Koogeek2$:^ENERGY_Power:
Tasmota.Koogeek4:
collect:
ENERGY_Power ^Tasmota.Koogeek4$:^ENERGY_Power:
Tasmota.Oelradiator:
collect:
ENERGY_Power ^Tasmota.Oelradiator$:^ENERGY_Power:
Tasmota.Trockner:
collect:
ENERGY_Power ^Tasmota.Trockner$:^ENERGY_Power:
Waschmaschine:
collect:
ENERGY_Power ^Waschmaschine$:^ENERGY_Power:
Zwave.KinoHifi:
collect:
power ^Zwave.KinoHifi$:^power:
Zwave_Plug1:
collect:
power ^Zwave_Plug1$:^power:
powerday:
collect:
TagesErtrag ^powerday$:^TagesErtrag:
sysmon:
collect:
cpu_temp ^sysmon$:^cpu_temp:
uiTable:
1wire_Strom_Gesamt:
di_Energy_uiTable_c_0_0_0_0:
E-Power ^1wire_Strom_Gesamt$:^E-Power:
di_Energy_uiTable_c_0_1_0_0:
Hz-Power ^1wire_Strom_Gesamt$:^Hz-Power:
di_Energy_uiTable_c_0_2_0_0:
E-Energy ^1wire_Strom_Gesamt$:^E-Energy:
Licht.Flur:
di_Energy_uiTable_c_5_1_0_0:
power ^Licht.Flur$:^power:
Licht.Gaeste:
di_Energy_uiTable_c_5_2_0_0:
power ^Licht.Gaeste$:^power:
Licht.Gartenhaus:
di_Energy_uiTable_c_5_4_0_0:
power ^Licht.Gartenhaus$:^power:
Licht.Kino:
di_Energy_uiTable_c_4_2_0_0:
power ^Licht.Kino$:^power:
Licht.Kueche:
di_Energy_uiTable_c_4_3_0_0:
power ^Licht.Kueche$:^power:
Licht.Marius:
di_Energy_uiTable_c_5_0_0_0:
power ^Licht.Marius$:^power:
Licht.Moritz:
di_Energy_uiTable_c_4_4_0_0:
power ^Licht.Moritz$:^power:
Licht.SaunaRuheRaum:
di_Energy_uiTable_c_3_4_0_0:
power ^Licht.SaunaRuheRaum$:^power:
Licht.Stehlampe:
di_Energy_uiTable_c_4_0_0_0:
power ^Licht.Stehlampe$:^power:
Licht.Stehlampe.Gaeste:
di_Energy_uiTable_c_6_2_0_0:
power ^Licht.Stehlampe.Gaeste$:^power:
Licht.TV:
di_Energy_uiTable_c_4_1_0_0:
power ^Licht.TV$:^power:
Licht.Terasse:
di_Energy_uiTable_c_6_0_0_0:
relay_0_power ^Licht.Terasse$:^relay_0_power:
Licht.Terasse2:
di_Energy_uiTable_c_6_1_0_0:
relay_1_power ^Licht.Terasse2$:^relay_1_power:
Licht.Treppe:
di_Energy_uiTable_c_5_3_0_0:
power ^Licht.Treppe$:^power:
MQTT2_DVES_4519BA:
di_Energy_uiTable_c_2_0_0_0:
ENERGY_Power ^MQTT2_DVES_4519BA$:^ENERGY_Power:
MQTT2_DVES_45B635:
di_Energy_uiTable_c_2_2_0_0:
ENERGY_Power ^MQTT2_DVES_45B635$:^ENERGY_Power:
MQTT2_DVES_462F4B:
di_Energy_uiTable_c_1_4_0_0:
ENERGY_Power ^MQTT2_DVES_462F4B$:^ENERGY_Power:
MQTT2_DVES_657752:
di_Energy_uiTable_c_6_4_0_0:
ENERGY_Power ^MQTT2_DVES_657752$:^ENERGY_Power:
di_Energy_uiTable_c_7_0_0_0:
ENERGY_Today ^MQTT2_DVES_657752$:^ENERGY_Today:
MQTT2_shellyplug_s_1C121B:
di_Energy_uiTable_c_7_3_0_0:
relay_0_power ^MQTT2_shellyplug_s_1C121B$:^relay_0_power:
MQTT2_shellyplug_s_BBA348:
di_Energy_uiTable_c_7_2_0_0:
relay_0_power ^MQTT2_shellyplug_s_BBA348$:^relay_0_power:
MQTT2_shellyplug_s_F02BB3:
di_Energy_uiTable_c_2_1_0_0:
relay_0_power ^MQTT2_shellyplug_s_F02BB3$:^relay_0_power:
Shelly.DachbodenPV:
di_Energy_uiTable_c_0_3_0_0:
power_1 ^Shelly.DachbodenPV$:^power_1:
di_Energy_uiTable_c_1_0_0_0:
SunAlt ^Shelly.DachbodenPV$:^SunAlt:
di_Energy_uiTable_c_1_1_0_0:
SunAz ^Shelly.DachbodenPV$:^SunAz:
di_Energy_uiTable_c_2_4_0_0:
power_0 ^Shelly.DachbodenPV$:^power_0:
Strom.Dachboden:
di_Energy_uiTable_c_2_3_0_0:
Dachboden ^Strom.Dachboden$:^Dachboden:
Tasmota.Frei_1.1:
di_Energy_uiTable_c_7_4_0_0:
ENERGY_Power ^Tasmota.Frei_1.1$:^ENERGY_Power:
Tasmota.Koogeek2:
di_Energy_uiTable_c_1_3_0_0:
ENERGY_Power ^Tasmota.Koogeek2$:^ENERGY_Power:
Tasmota.Koogeek4:
di_Energy_uiTable_c_3_1_0_0:
ENERGY_Power ^Tasmota.Koogeek4$:^ENERGY_Power:
Tasmota.Oelradiator:
di_Energy_uiTable_c_3_3_0_0:
ENERGY_Power ^Tasmota.Oelradiator$:^ENERGY_Power:
Tasmota.Trockner:
di_Energy_uiTable_c_3_0_0_0:
ENERGY_Power ^Tasmota.Trockner$:^ENERGY_Power:
Waschmaschine:
di_Energy_uiTable_c_3_2_0_0:
ENERGY_Power ^Waschmaschine$:^ENERGY_Power:
Zwave.KinoHifi:
di_Energy_uiTable_c_1_2_0_0:
power ^Zwave.KinoHifi$:^power:
Zwave_Plug1:
di_Energy_uiTable_c_6_3_0_0:
power ^Zwave_Plug1$:^power:
powerday:
di_Energy_uiTable_c_0_4_0_0:
TagesErtrag ^powerday$:^TagesErtrag:
sysmon:
di_Energy_uiTable_c_7_1_0_0:
cpu_temp ^sysmon$:^cpu_temp:
collect:
1wire_Strom_Gesamt E-Energy:
48:
dim 72
hours 48
last
last_v 1.842
last_value 2.121
max_value 11.688
max_value_slot 58
max_value_time 1647297468
min_value 0.009
min_value_slot 23
min_value_time 1647212674
name 1wire_Strom_Gesamt
reading E-Energy
time 1647327626
value 2.066
times:
1647158341
1647160742
1647163141
1647165543
1647167943
1647170343
1647172743
1647175143
1647177243
1647179958
1647182356
1647184758
1647187160
1647189563
1647191964
1647194363
1647196763
1647199167
1647201570
1647203969
1647206373
1647208774
1647211174
1647212674
1647215975
1647218376
1647220775
1647223176
1647225580
1647227982
1647230381
1647232787
1647235189
1647237593
1647239996
1647242395
1647244501
1647246904
1647249307
1647251710
1647254109
1647256510
1647258910
1647261310
1647263710
1647266110
1647268660
1647271069
1647273474
1647275860
1647278270
1647280671
1647283069
1647285475
1647287872
1647290277
1647292667
1647295066
1647297468
1647298969
1647302270
1647304669
1647307069
1647309471
1647311869
1647314270
1647316669
1647319070
1647321471
1647323871
1647326273
1647327626
values:
2.286
2.614
3.527
3.791
3.939
4.102
4.172
4.265
4.336
5.881
5.986
7.029
7.419
7.608
7.91
8.182
8.685
9.239
9.881
10.446
10.682
10.917
11.078
0.009
0.156
0.268
0.413
0.555
0.666
0.803
0.934
1.116
1.334
1.59
1.984
2.257
2.527
2.905
3.258
3.46
3.593
3.74
3.929
5.091
5.444
5.649
6.369
8.538
9.201
9.269
9.442
9.724
10.118
10.628
10.842
11.074
11.294
11.519
11.688
0.011
0.153
0.255
0.382
0.539
0.656
0.796
0.935
1.13
1.366
1.621
1.842
2.066
1wire_Strom_Gesamt E-Power:
48:
dim 72
hours 48
last 0.3857
last_v 0.2033
last_value 0.18
max_value 6.3061
max_value_slot 46
max_value_time 1647268660
min_value 0
min_value_slot 59
min_value_time 1647298969
name 1wire_Strom_Gesamt
reading E-Power
time 1647327626
value 0.3857
times:
1647156230
1647159241
1647161942
1647164941
1647167943
1647169742
1647172743
1647173342
1647176344
1647178156
1647180857
1647183557
1647185959
1647187459
1647191663
1647193763
1647196763
1647198565
1647200668
1647203670
1647205470
1647208473
1647209674
1647212674
1647214775
1647218076
1647219875
1647221675
1647223776
1647227982
1647230081
1647231885
1647233988
1647237593
1647238495
1647241796
1647243899
1647246303
1647249307
1647250809
1647253509
1647255309
1647256810
1647260409
1647263710
1647264610
1647268660
1647271069
1647273474
1647274061
1647278270
1647280671
1647281877
1647284582
1647287872
1647289671
1647292366
1647294768
1647296867
1647298969
1647301968
1647304669
1647307069
1647307970
1647310971
1647314270
1647315770
1647318770
1647319372
1647323871
1647324773
1647326574
values:
0.456
1.224
3.2138
0.313
0.0843
0.3853
0.0957
0.228
0.0837
4.7318
0.084
3.4676
0.3251
0.4575
0.672
0.3251
1.8542
0.7344
1.3967
0.6983
0.312
0.4214
0.2288
0
0.1674
0.1914
0.2528
0.204
0.144
0.4618
0.1455
0.4696
0.252
0.586
1.296
0.3099
0.624
0.8852
0.24
0.4575
0.1087
0.324
0.216
2.664
0.2408
0.468
6.3061
1.7333
0.0932
0.1212
0.3986
0.668
0.4306
1.5283
0.2851
0.5107
0.312
0.3835
0.2167
0
0.1686
0.1435
0.2631
0.2146
0.1435
0.4214
0.145
0.4455
0.2146
0.528
0.2033
1.6027
1wire_Strom_Gesamt Hz-Power:
48:
dim 72
hours 48
last 0.0321
last_v 0.0359
last_value 0.0356
max_value 0.3612
max_value_slot 5
max_value_time 1647169742
min_value 0
min_value_slot 59
min_value_time 1647298969
name 1wire_Strom_Gesamt
reading Hz-Power
time 1647327626
value 0.0321
times:
1647156230
1647158642
1647161341
1647164340
1647167042
1647169742
1647172442
1647173342
1647176344
1647177857
1647182356
1647183557
1647187160
1647188059
1647191663
1647192864
1647194665
1647197365
0.0715
0.336
0.0359
0.2392
Licht.Flur power:
48:
dim 72
hours 48
last
last_v 0
last_value 0
max_value 20.9
max_value_slot 17
max_value_time 1647197810
min_value 0
min_value_slot 71
min_value_time 1647326842
name Licht.Flur
reading power
time 1647327585
value 0
times:
1647157312
0
undef
0
Licht.Gaeste power:
48:
dim 72
hours 48
last
last_v 0
last_value 0
max_value 0
max_value_slot 71
max_value_time 1647326842
min_value 0
min_value_slot 71
min_value_time 1647326842
name Licht.Gaeste
reading power
time 1647327585
value 0
times:
1647157312
1647159009
1647163073
undef
1647166673
1647170273
undef
1647173873
1647177434
undef
1647181073
1647184673
undef
1647187555
1647191154
undef
1647194754
1647198354
undef
1647201954
1647205554
undef
1647209154
1647212754
undef
1647216354
1647219954
undef
1647223554
1647227154
undef
1647230755
1647234354
undef
1647237954
1647241554
undef
1647245154
1647248754
1647251135
1647252354
1647255954
1647258740
1647259554
1647263154
undef
1647266754
1647270354
undef
1647273954
1647277554
undef
1647281154
1647284755
undef
1647288354
1647291954
undef
1647295554
1647299154
undef
1647302754
1647306354
undef
1647309954
1647313555
undef
1647317154
undef
undef
1647324354
1647326842
values:
0
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
0
0
0
0
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
0
undef
0
undef
undef
0
0
Licht.Gartenhaus power:
48:
dim 72
hours 48
last
last_v 0
last_value 0
max_value 0
max_value_slot 71
max_value_time 1647326842
min_value 0
min_value_slot 71
min_value_time 1647326842
name Licht.Gartenhaus
reading power
time 1647327585
value 0
times:
1647157312
1647159009
undef
1647165541
undef
undef
undef
undef
1647177434
undef
undef
1647183540
1647187141
1647187561
undef
undef
1647195918
undef
undef
1647203747
undef
undef
undef
undef
1647214546
undef
undef
1647221747
undef
undef
1647228946
undef
undef
1647236147
1647239746
undef
undef
1647246947
undef
1647250546
undef
undef
1647258740
undef
undef
undef
1647268127
undef
1647272147
1647275747
undef
undef
1647282946
undef
1647286547
1647290147
undef
1647293746
1647297346
undef
undef
1647304546
undef
undef
1647311747
undef
1647315346
1647318946
undef
1647322547
1647326146
1647326842
values:
0
0
undef
0
undef
undef
undef
undef
0
undef
undef
0
0
0
undef
undef
0
undef
undef
0
undef
undef
undef
undef
0
undef
undef
0
undef
undef
0
undef
undef
0
0
undef
undef
0
undef
0
undef
undef
0
undef
undef
undef
0
undef
0
0
undef
undef
0
undef
0
0
undef
0
0
undef
undef
0
undef
undef
0
undef
0
0
undef
0
0
0
Licht.Kino power:
48:
dim 72
hours 48
last
last_v 30.0
last_value 0.0
max_value 30.6
max_value_slot 52
max_value_time 1647281638
m
Ich kann es bei mir gerade nicht nachstellen. Hast du mehrere FHEMWEB-Instanzen, die aktuell den Bildinhalt visualisieren?
Was passiert, wenn du die Hälfte der Cards auskommentiertst?
Bei mir (Raspi4 4GB) dauert der Aufbau von einigen Cards (ca. 10) Bruchteile einer Sekunde, also dürften 40 cards auch nicht viel länger als eine Sekunde dauern.
Die Aufbereitung der Grafiken findet im DOIF statt und das läuft nur in einem Thread. Vermutlich ist das ein Problem auf der WEB-Seite.
Wenn ich zuhause bin, werde ich es mal mit 40 cards testen.
Hi,
ich habe insgesamt 4 Webinstanzen (web,Phone,Tablet,Weatherstation), aber immer nur eine die es gerade visualisiert.
Die Seite baut sich recht schnell auf, aber das verlassen der Seite des Raums/Seite dauert meist sehr lange.
So habe ich die WEB-Seite definiert:
Internals:
BYTES_READ 5488912
BYTES_WRITTEN 2831747493
CONNECTS 10649
DEF 8083 global
FD 9
FUUID 5c724473-f33f-dcb4-d927-e8670b5f3d0114f7
NAME WEB
NR 18
NTFY_ORDER 50-WEB
PORT 8083
STATE Initialized
TYPE FHEMWEB
READINGS:
2022-02-28 09:47:08 state Initialized
Attributes:
JavaScripts codemirror/fhem_codemirror.js
SVGcache 1
closeConn 1
codemirrorParam { "theme":"blackboard","lineNumbers":true, "lineWrapping":true }
confirmDelete 0
confirmJSError 0
csrfToken none
defaultRoom Allgemein
editConfig 1
endPlotNow 0
iconPath default:fhemSVG:openautomation
longpoll websocket
menuEntries CodeImport,/fhem?detail=Import#,updatecheck,cmd=update+check,update,cmd=update,restart,cmd=shutdown+1,Befehlsreferenz,/fhem/docs/commandref_DE.html
plotEmbed 2
plotfork 1
sortRooms Allgemein 1wire 1wire_Plot Energie Beleuchtung Bewaesserung DOIF Heizung Jalousien Pool HiFi Strom Schwellenwerte
sslVersion TLSv12:!SSLv3
stylesheetPrefix dark
verbose 0
Vielleicht liegt da der Hase begraben in den Multitaskingeinstellungen ?
Ich deaktiviere nachher mal ein paar Grafiken, und berichte...
Ich muss mich korrigieren, ich nutze dieses Widget https://forum.fhem.de/index.php/topic,45328.0.html welches auf die Webinstanz 8084 eingestellt ist.
Ich habe jetzt mal eine Menge Cards deaktiviert, und das Widget auf Port 8083 umgestellt, leider ohne Erfolg. Beim betreten des Raums mit den Cards schnellt die CPU/RAM-Auslastung auf meinem RPi4 in die Höhe, mit mind. 20 FHEM-PIDS
Es sieht mir nicht nach einem Problem von card selbst aus.
Ich habe bei mir jetzt 40 cards definiert. Beim Aufbau der Seite geht die CPU-Last, wie erwartet, für eine Sekunde auf ca. 50 % und dann fällt sie sofort. Ich sehe bei mir nur einen FHEM-Prozess.
Das Hinzufügen von 30 cards hat ca. 1MB weiteren Speicherplatz verbraucht.
Also alles im grünen Bereich.
Wie hast Du Plotfork/plotembed in Deinen FHEM-Instanzen definiert ?
Bei mir dauert die CPU-Last ca. 60s und mehr
aaaah, ich habe jetzt die Attribute plotfork+plotEmbed aus allen Webinstanzen <> 8083 gelöscht, FHEM neu gestartet, und jetzt ist es bei meinem System auch so, das ich die Card-gefüllten Räume betreten und verlassen kann, ohne das die CPU-Last für so lange hochschnellt.... ::)
Zitat von: Bartimaus am 15 März 2022, 15:36:20
aaaah, ich habe jetzt die Attribute plotfork+plotEmbed aus allen Webinstanzen <> 8083 gelöscht, FHEM neu gestartet, und jetzt ist es bei meinem System auch so, das ich die Card-gefüllten Räume betreten und verlassen kann, ohne das die CPU-Last für so lange hochschnellt.... ::)
Das Forken ist hier wohl für svg-plots gedacht. DOIF-svg-Funktionen nutzen diesen Mechanismus nicht.
::)
Dann verstehe ich nicht wieso die CPU/RAM-Last jetzt so drastisch sinkt. Plots bauen sich nun nämlich auch schneller auf. Und ich habe keine Disconnects mehr aus meinem Widget bekommen
Zitat von: Bartimaus am 15 März 2022, 15:47:56
::)
Dann verstehe ich nicht wieso die CPU/RAM-Last jetzt so drastisch sinkt. Plots bauen sich nun nämlich auch schneller auf. Und ich habe keine Disconnects mehr aus meinem Widget bekommen
So viel ich weiß, hat Rudi das Forken eingebaut, um SVG-Plots mit vielen Daten im Hintergrund aufzubereiten - was sicherlich sinnvoll ist. Das hat aber nichts mit den DOIF-SVG-Funktionen zu tun.
Moin,
nach 5 Tagen bekomme ich wieder Timeouts. Heisst, ich sehe wieder viele FHEM-Instanzen(PIDs) in HTOP, die sich wirklich nur sehr langsam wieder abbauen. Das Problem lässt sich temporär über einen FHEM-Neustart beheben.
Komisch alles. Habe in "WEB" nun das Attribut "plotEmbed" auf 1 gesetzt, leider auch ohne Auswirkung. Vielleicht kann Rudi dazu was sagen...
LG
Zitat von: Bartimaus am 21 März 2022, 09:45:06
Moin,
nach 5 Tagen bekomme ich wieder Timeouts. Heisst, ich sehe wieder viele FHEM-Instanzen(PIDs) in HTOP, die sich wirklich nur sehr langsam wieder abbauen. Das Problem lässt sich temporär über einen FHEM-Neustart beheben.
Komisch alles. Habe in "WEB" nun das Attribut "plotEmbed" auf 1 gesetzt, leider auch ohne Auswirkung. Vielleicht kann Rudi dazu was sagen...
LG
Dann musst du im entsprechenden Board das Problem schildern. Ich gehe davon aus, dass es nicht mit card zusammenhängt.
cards ohne Animation
Leider frisst die Animation des aktuellen Wertes als blinkender Punkt in der Grafik recht viel Performance im Browser. Bei vielen cards in einer Tabelle läuft der Browser "heiß".
In der kommenden Version wird die Animation per default ausgeschaltet sein. Falls man sie in einem DOIF-Device weiterhin haben möchte, so muss sie in der Tabellendefinition des jeweiligen DOIF-Devices freigeschaltet werden:
attr uiTable {
package ui_Table;
$ANIMATE=1;
}
...
Zitat von: Damian am 03 April 2022, 12:12:13
cards ohne Animation
Leider frisst die Animation des aktuellen Wertes als blinkender Punkt in der Grafik recht viel Performance im Browser. Bei vielen cards in einer Tabelle läuft der Browser "heiß".
In der kommenden Version wird die Animation per default ausgeschaltet sein. Falls man sie in einem DOIF-Device weiterhin haben möchte, so muss sie in der Tabellendefinition des jeweiligen DOIF-Devices freigeschaltet werden:
attr uiTable {
package ui_Table;
$ANIMATE=1;
}
...
Neue Version ohne Animation eingecheckt. Min-, Max-Punkte werden jetzt zur Unterscheidung mit Dreieckssymbolen dargestellt.
Hi,
ich nutze die Card funktion analog dem Wiki Beispiel für PV. (https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-.2C_Monats-_und_Jahresstatistik_f.C3.BCr_Strom-.2C_Gas-.2C_Wasserz.C3.A4hler_und_andere_Z.C3.A4hler)
U.a. möchte ich den den täglichen (der letzten 10 Tage) und monatlichen Ertrag (letzte 12 Monate) anzeigen. Ein Reading für die Aggregate day, month, year habe ich schon erzeugt.
Mit dem standard card aus dem Beispiel funktioniert alles bestens. Bekomme ich aber für die tägliche und monatliche Statitsik anstatt einer Linie auch cylinder hin? Gibt es da ev. einen schalter der im Wiki noch nicht beschrieben ist?
Die widgets cylinder und cylinder_bars passen nicht.
Zitat von: Tobias am 04 Mai 2022, 16:43:45
Hi,
ich nutze die Card funktion analog dem Wiki Beispiel für PV. (https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-.2C_Monats-_und_Jahresstatistik_f.C3.BCr_Strom-.2C_Gas-.2C_Wasserz.C3.A4hler_und_andere_Z.C3.A4hler)
U.a. möchte ich den den täglichen (der letzten 10 Tage) und monatlichen Ertrag (letzte 12 Monate) anzeigen. Ein Reading für die Aggregate day, month, year habe ich schon erzeugt.
Mit dem standard card aus dem Beispiel funktioniert alles bestens. Bekomme ich aber für die tägliche und monatliche Statitsik anstatt einer Linie auch cylinder hin? Gibt es da ev. einen schalter der im Wiki noch nicht beschrieben ist?
Die widgets cylinder und cylinder_bars passen nicht.
Nein, geht z. Zt. leider nicht.
Hi,
ich nutze fleißig die card Funktion für die Visualisierung meiner PV Anlage:)
Nun möchte ich eine einfache Berechnung integrieren, also anstatt in Watt soll es in kw anzeigen. Leider funktioniert es nicht. Sieht jemand was ich falsch mache?
funktioniert in Watt
card([PlenticorePlus8:Daily_Yield:100col1w],"Solarenergie in W pro Tag","solar_icon",0,15,0,90,"PV",undef,"1","130,,,,1,,200","0,0,0,0")
funktioniert nicht, das ganze widget wird damit nicht angezeigt
card([PlenticorePlus8:Daily_Yield:100col1w]/1000,"Solarenergie in kWh pro Tag","solar_icon",0,15,0,90,"PV",undef,"1","130,,,,1,,200","0,0,0,0")
Zitat von: Tobias am 17 Mai 2022, 11:19:30
Hi,
ich nutze fleißig die card Funktion für die Visualisierung meiner PV Anlage:)
Nun möchte ich eine einfache Berechnung integrieren, also anstatt in Watt soll es in kw anzeigen. Leider funktioniert es nicht. Sieht jemand was ich falsch mache?
funktioniert in Watt
card([PlenticorePlus8:Daily_Yield:100col1w],"Solarenergie in W pro Tag","solar_icon",0,15,0,90,"PV",undef,"1","130,,,,1,,200","0,0,0,0")
funktioniert nicht, das ganze widget wird damit nicht angezeigt
card([PlenticorePlus8:Daily_Yield:100col1w]/1000,"Solarenergie in kWh pro Tag","solar_icon",0,15,0,90,"PV",undef,"1","130,,,,1,,200","0,0,0,0")
Berechnungen in DOIF-spezifischen Angaben (Angaben in eckigen Klammern) sind nicht möglich, du musst über ein Zwischenreading gehen. Das kann man direkt im Zählerdevice über userreadings machen oder im jeweiligen DOIF z. B. über DOIF_Readings realisieren. Der Vorteil von DOIF_Readings ist, dass sie keine zusätzlichen Events nach außen produzieren, aber das eigene Device triggern.
Edit: Bei Collector-Angaben, wie bei Card, geht es auch nicht außerhalb, sondern nur wie oben beschrieben
Ich habe es hinbekommen, etwas versteckt im Wiki :)
card([PlenticorePlus8:Daily_Yield:100col1w:$_ / 1000],"Solarenergie in kWh pro Tag","solar_icon",0,42,0,90,"PV",undef,"1","130,,,,1,,200","0,0,0,0")
Zitat von: Tobias am 18 Mai 2022, 08:38:19
Ich habe es hinbekommen, etwas versteckt im Wiki :)
card([PlenticorePlus8:Daily_Yield:100col1w:$_ / 1000],"Solarenergie in kWh pro Tag","solar_icon",0,42,0,90,"PV",undef,"1","130,,,,1,,200","0,0,0,0")
ja, du hast Recht, die Option habe ich neulich eingebaut um z. B. von on/off auf Zahlen zu kommen. Das habe ich schon verdrängt. :)
Ich habe das di_counter-Beispiel aus dem Wiki für mich etwas erweitert.
Pro Sensor habe ich jetzt eine Tages-, Monats- und Jahresdarstellung definiert (siehe Anhang).
Am Wochenende habe ich noch das Messen des Zisternenwasserverbrauchs eingebaut (siehe Foto im Anhang)
An einem esp8266 mit Tasmota hängen jetzt zwei Wasserzähler, zwei Stromzähler und ein Gaszähler.
Hi,
ich habe nochmal eine frage zur col definition.
Irgendwo hatte ich mal gelesen,das man mit der Zahl vor(!) col die Anzahl der zu sammelnden Werte einstellen kann, anstatt default 72 Werte.
In Zusammenhang mit den steps kann man dann nämlich bars bauen.
card([DOIF_counter:SEN_EM_Elektro.000_EM_All.day:7col1w],"Verbrauch in kWh pro Tag","fa_bolt",0,12,0,90,"kw",undef,"1","130,,1,,1,,200","0,0,0,0")
Hier sollen genau 7 Werte über einen Zeitraum der letzten 7 Tage gesammelt werden. Also pro Tage genau ein Wert Damit wird dann pro Tag der Stromverbrauch angezeigt. Der aktuelle Tag zählt immer von 0 hoch bis Mitternacht.
Jetzt habe ich das Gefühl das nicht richtig gezählt wird. Finde aber auch diese Definition nicht im Wiki. Gibt es dieses Feature wirklich und ist nur im Wiki nicht beschrieben?
Zitat von: Tobias am 21 Mai 2022, 06:07:34
Hi,
ich habe nochmal eine frage zur col definition.
Irgendwo hatte ich mal gelesen,das man mit der Zahl vor(!) col die Anzahl der zu sammelnden Werte einstellen kann, anstatt default 72 Werte.
In Zusammenhang mit den steps kann man dann nämlich bars bauen.
card([DOIF_counter:SEN_EM_Elektro.000_EM_All.day:7col1w],"Verbrauch in kWh pro Tag","fa_bolt",0,12,0,90,"kw",undef,"1","130,,1,,1,,200","0,0,0,0")
Hier sollen genau 7 Werte über einen Zeitraum der letzten 7 Tage gesammelt werden. Also pro Tage genau ein Wert Damit wird dann pro Tag der Stromverbrauch angezeigt. Der aktuelle Tag zählt immer von 0 hoch bis Mitternacht.
Jetzt habe ich das Gefühl das nicht richtig gezählt wird. Finde aber auch diese Definition nicht im Wiki. Gibt es dieses Feature wirklich und ist nur im Wiki nicht beschrieben?
Das Feature ist aktiv und kann genutzt werden. Man muss aber wissen, was man tut, daher habe ich es noch nicht dokumentiert. 7 Zeitfenster sollten 7 Werte aufnehmen, wenn es aber nur eine Sekunde Ungenauigkeit gibt, dann können zwei Werte in einem Timeslot landen und im nächsten keiner. Dabei habe ich einen Algorithmus eingebaut, so dass nach Möglichkeit nur unwichtige Werte untergehen, der kann zu Ergebnissen führen, mit denen du nicht rechnest.
Card-Plots sind nicht auf Genauigkeit ausgelegt, sondern auf Geschwindigkeit und die soll noch gegeben sein, wenn jemand über einen langen Zeitraum häufig Daten liefert. So kann die Darstellung bei SVG-Plots Minuten dauern, bei Card-Plots sind es Millisekunden.
Ich habe im Wiki die Definition der Cards geändert, jetzt wird auch ein ganzes Jahr dargestellt.
Hier ist die Auflösung höher ist als die Anzahl der Werte.
Bei 72/12=6 ist das mehr als genug, ob 12 gut funktioniert, weiß ich nicht. Mit 24 z. B. ist man auf der sicheren Seite.
Bei der Monatsübersicht, kann auch nichts passieren:
72/31=2,31
es kann kein Wert verloren gehen.
Bei der Darstellung des Tagesverlaufs dagegen reicht die Anzahl der Slots natürlich nicht aus.
Bei mir wird im Minutentakt gesendet.
Es gibt also pro Tag 24*60=1440 Werte.
Pro Slot kommen 1440/72=20 Werte, 19 werden verworfen. Es wird jeweils der höchste übernommen. Bei einem aufsteigenden Zähler ist es dann immer der letzte.
Mir reicht die Stufenform (Steps) aus. Selbst bei 30 Werten (siehe neue Monatsübersicht im Wiki) kann ich ziemlich genau erkennen, wie hoch der Verbrauch an einem bestimmten Tag war.
Danke für die doch sehr ausführliche Erklärung.
Zitat7 Zeitfenster sollten 7 Werte aufnehmen, wenn es aber nur eine Sekunde Ungenauigkeit gibt, dann können zwei Werte in einem Timeslot landen und im nächsten keiner.
Ich denke du gehst davon aus das der Tageswert nur einmal genau zu Mitternacht kommt, oder? Die Werte kommen bei mir aber alle 60sek. Ich hatte es so verstanden das im aktuellen (Tages-)Wert der letzte immer durch den neuen (alle 60sek) ersetzt wird. Wenn das Datum auf den nächsten Tag wechselt bleibt der Wert zum gestrigen Tag stehen und es wird dann hochlaufend für den neuen Tag gezählt.
Funktioniert das so?
Zitat von: Tobias am 21 Mai 2022, 14:35:22
Danke für die doch sehr ausführliche Erklärung.
Ich denke du gehst davon aus das der Tageswert nur einmal genau zu Mitternacht kommt, oder? Die Werte kommen bei mir aber alle 60sek. Ich hatte es so verstanden das im aktuellen (Tages-)Wert der letzte immer durch den neuen (alle 60sek) ersetzt wird. Wenn das Datum auf den nächsten Tag wechselt bleibt der Wert zum gestrigen Tag stehen und es wird dann hochlaufend für den neuen Tag gezählt.
Funktioniert das so?
Der date-Wert wird solange erhöht, solange der Zählerwert steigt. Um 00:01 wird er in last_date übernommen und auf Null zurückgesetzt. Ob dann in 7 Slots immer die richtigen Tageswerte landen, kann ich - wie schon beschrieben - nicht vorhersagen.
Ich hatte ja eher an last_date gedacht.
Guten Morgen,
ich bekomme bei meinen DOIF-Cards jetzt folgende Fehlermeldung:
"ReferenceError: doifUpdateCell is not defined"....
"doifUpdateCell('di_Energy','doifId','di_Energy_uiTable_c_8_4_0_0','___','display:inline-table;')"
Die Cards funktionieren, aber die PopUps kommen im Sekundentakt und lassen sich kaum wegklicken.
Die Definition der Devices ist unverändert, aber ich habe die Tage ein FHEM-Update gemacht.
Was kann ich tun ?
Zitat von: Bartimaus am 17 Juni 2022, 10:01:43
Guten Morgen,
ich bekomme bei meinen DOIF-Cards jetzt folgende Fehlermeldung:
"ReferenceError: doifUpdateCell is not defined"....
"doifUpdateCell('di_Energy','doifId','di_Energy_uiTable_c_8_4_0_0','___','display:inline-table;')"
Die Cards funktionieren, aber die PopUps kommen im Sekundentakt und lassen sich kaum wegklicken.
Die Definition der Devices ist unverändert, aber ich habe die Tage ein FHEM-Update gemacht.
Was kann ich tun ?
Die Fehlerursache lässt sich leider nicht erkennen. Die FHEM-Definition passt nicht zur HTML-Definition.
So habe ich z:b. ein Card definiert:
defmod di_Energy DOIF ##
attr di_Energy room DOIF_Cards
attr di_Energy uiTable {package ui_Table}\
card([1wire_Strom_Gesamt:E-Power:col48],"aktueller Strom,fill:darkorange","power","0.00","10.00",120,0,"kW",undef,"2")|\
card([1wire_Strom_Gesamt:Hz-Power:col48],"Strom_Heizung,fill:darkorange","power","0.00","0.35",120,0,"kW",undef,"2")|\
card([1wire_Strom_Gesamt:E-Energy:col48],"Tagesstrom,fill:darkorange","power",0.00,25.00,120,0,"kWh",undef,2)|\
card([Shelly.DachbodenPV:power_1:col48],"Balkonkraftwerk,fill:darkorange","sani_solar",0.00,1000,0,90,"W",undef,0)|\
card([powerday:TagesErtrag:col1w],"TagesErtrag PV","sani_solar",0,6,0,90,"kWh",undef,3)\
card([Shelly.GartenhausPV:power:col96],"Gartenkraftwerk,fill:darkorange","sani_solar",0.00,600,0,90,"W",undef,0)|\
card([powerday:TagesErtrag2:col1w],"GartenPVTagesErtrag","sani_solar",0,6,0,90,"kWh",undef,3)|\
card([Shelly.DachbodenPV:GesamtPower:col96],"GesamtPowerPV,fill:darkorange","sani_solar",0.00,1250,0,90,"W",undef,0)|\
card([powerday:GesamtErtrag:col1w],"GesamtTagesErtragPV","sani_solar",0,6,0,90,"kWh",undef,3)|\
card([Shelly.DachbodenPV:SunAlt:col24],"Einstrahlwinkel","sani_solar",-30,90,0,120,"Grad",undef,0)\
card([Shelly.DachbodenPV:SunAz:col24],"Einstrahl-Richtung","sani_solar",0,360,0,120,"Grad",undef,0)|\
card([Zwave.KinoHifi:power:col48],"KinoHifi,fill:darkorange","power","0.00","250",120,0,"W",undef,0)|\
card([Tasmota.Koogeek2:ENERGY_Power:col48],"HifiWz,fill:darkorange","power","0.00","100",120,0,"W",undef,0)|\
card([MQTT2_DVES_462F4B:ENERGY_Power:col48],"PS5-Marius,fill:darkorange","power",0.00,350,90,0,"W",undef,0)|\
card([MQTT2_DVES_4519BA:ENERGY_Power:col48],"RPi4-PS4,fill:darkorange","power","0.00","350",120,0,"W",undef,"2")\
card([MQTT2_shellyplug_s_F02BB3:relay_0_power:col48],"KellerPC,fill:darkorange","power","0.00","150",120,0,"W",undef,0)|\
card([MQTT2_DVES_45B635:ENERGY_Power:col48],"WzTV,fill:darkorange","power","0.00","250",120,0,"W",undef,0)|\
card([Strom.Dachboden:Dachboden:col48],"Ubiquiti,fill:darkorange","power","0.00","100",120,0,"W",undef,"2")|\
card([Shelly.DachbodenPV:power_0:col48],"RPi4-FHEM,fill:darkorange","power","0.00","15",120,0,"W",undef,"2")|\
card([Tasmota.Trockner:ENERGY_Power:col48],"Trockner,fill:darkorange","power","0.00","3600",90,0,"W",undef,0)\
card([Tasmota.Koogeek4:ENERGY_Power:col48],"Spülmaschine,fill:darkorange","power","0.00","3500",120,0,"W",undef,0)|\
card([Waschmaschine:ENERGY_Power:col48],"Waschmaschine,fill:darkorange","power","0.00","2800",120,0,"W",undef,0)|\
card([Tasmota.Oelradiator:ENERGY_Power:col48],"Ölradiator,fill:darkorange","power",0.00,3600,120,0,"W",undef,0)|\
card([Licht.SaunaRuheRaum:power:col48],"Luftentfeuchter,fill:darkorange","power","0.00","260",120,0,"W",undef,0)|\
card([Licht.Stehlampe:power:col48],"Licht.StehlampeWz,fill:darkorange","power","0.00","50",120,0,"W",undef,2)\
card([Licht.TV:power:col48],"Licht.TV,fill:darkorange","power","0.00","15",120,0,"W",undef,2)|\
card([Licht.Kino:power:col48],"Licht.Kino,fill:darkorange","power","0.00","150",120,0,"W",undef,2)|\
card([Licht.Kueche:power:col48],"Licht.Kueche,fill:darkorange","power","0.00","50",120,0,"W",undef,"2")|\
card([Licht.Moritz:power:col48],"Licht.Moritz,fill:darkorange","power","0.00","50",120,0,"W",undef,"2")|\
card([Licht.Marius:power:col48],"Licht.Marius,fill:darkorange","power","0.00","50",120,0,"W",undef,"2")\
card([Licht.Flur:power:col48],"Licht.Flur,fill:darkorange","power","0.00","25",120,0,"W",undef,"2")|\
card([Licht.Gaeste:power:col48],"Licht.Gaestezimmer,fill:darkorange","power","0.00","50",120,0,"W",undef,"2")|\
card([Licht.Treppe:power:col48],"Licht.Treppe,fill:darkorange","power","0.00","50",120,0,"W",undef,"2")|\
card([Licht.Gartenhaus:power:col48],"Licht.Gartenhaus,fill:darkorange","power","0.00","25",120,0,"W",undef,"2")|\
card([Licht.Terasse:relay_0_power:col48],"Licht.Terasse,fill:darkorange","power","0.00","40",120,0,"W",undef,"2")\
card([Licht.Terasse2:relay_1_power:col48],"Licht.Terasse2,fill:darkorange","power","0.00","40",120,0,"W",undef,"2")|\
card([Licht.Stehlampe.Gaeste:power:col48],"Licht.StehlampeGaeste,fill:darkorange","power","0.00","25",120,0,"W",undef,"2")|\
card([Zwave_Plug1:power:col48],"PC-Claudia,fill:darkorange","power","0.00","350",120,0,"W",undef,"2")|\
card([MQTT2_DVES_657752:ENERGY_Power:col48],"XMasLicht,fill:darkorange","power","0.00","50",90,0,"W",undef,0)|\
card([MQTT2_DVES_657752:ENERGY_Today:col48],"XMas,fill:darkorange","power","0.00","5",90,0,"kWh",undef,0)\
card([sysmon:cpu_temp:col48],"RPi4-Temp,fill:darkorange","temp_inside","15.00","85",90,0,"°C",undef,0)|\
card([Switch24Port:switch_general_temperature:col1w],"UnifiSwitch-Temp,fill:darkorange","temp_inside","15.00","85",90,0,"°C",undef,0)|\
card([Shelly.DachbodenPV:inttemp:col1w],"ShellyPV-Temp,fill:darkorange","temp_inside","15.00","85",90,0,"°C",undef,0)|\
card([MQTT2_shellyplug_s_BBA348:relay_0_power:col48],"ArbeitsPC,fill:darkorange","power","0.00","150",120,0,"W",undef,0)|\
card([MQTT2_shellyplug_s_1C121B:relay_0_power:col48],"MediaServer,fill:darkorange","power","0.00","150",120,0,"W",undef,0)\
card([Tasmota.Frei_1.1:ENERGY_Power:col1w],"SolarThermie,fill:darkorange","power","0.00","40",120,0,"W",undef,0)|\
Dann reduziere die Definition. Nimm erst mal die Hälfe (restliche Zeilen mit ## auskommentieren), wenn es funktioniert, dann nimmst du vom Rest wieder die Hälfte dazu - bis du die Card-Definition eindeutig herausgefunden hast.
neues Feature: Diagramm ohne Ring
Man kann jetzt die Anzeige des Rings ausblenden, dadurch gewinnt man mehr Platz für das Diagramm.
Im Anhang zwei Darstellungen: mit Ringen wie bisher und auch ohne Ringe - neu. Bei der Monats- und der Jahresübersicht wurden die Ringe hier ausgeblendet.
Neue Version eingecheckt.
Auszug aus der Dokumentation zu card:
Zitat$prop
# Eigenschaft von card: "<size>,<y-scaling>,<steps>,<noFooter>,<noColor>,<ring>,<width>", optional
# <size>: Größe der der Karte, default = 130,
# <y-scaling>: feste Y-Skalierung: 1, sonst automatische Skalierung,
# <steps>: 1 für Stufen,
# <noFooter>: 1 für keine Fußzeile,
# <noColor>: 1 für graue y-Achsenbeschriftung,
# <ring>: leer für Ring, 0 für kein Ring, 1 für Halbringdarstellung, default: Ring
# <width>: Breite der Karte, default: 160
Dürfte ich einen Vorschlag für eine bessere Lesbarkeit machen??
Anstatt die Parameter hintereinander weg zu schreiben wäre es lesbarer wenn man soetwas schreibt wie:
Footer=1, Ring=0, usw.....
Wäre soetwas grundsätzlich möglich wenn du mal Zuviel Zeit hast? ;)
Zitat von: Tobias am 19 Juni 2022, 17:25:55
Dürfte ich einen Vorschlag für eine bessere Lesbarkeit machen??
Anstatt die Parameter hintereinander weg zu schreiben wäre es lesbarer wenn man soetwas schreibt wie:
Footer=1, Ring=0, usw.....
Wäre soetwas grundsätzlich möglich wenn du mal Zuviel Zeit hast? ;)
Ja, da ich aber die einfache Variante bereits gewählt habe, muss man alleine wegen der Kompatibilität dabei bleiben. Außerdem handelt es sich hier um reine Perlfunktionen und diese arbeitet von sich aus mit Parametern, die aufgrund ihrer Reihenfolge zugeordnet werden. In javaScript hätte man es sicherlich anders gelöst.
Ich habe noch die Fußzeile erweitert, weil man ohne Ring gar nicht mehr erkennen konnte, was dargestellt wurde.
andere Frage: wie kommt man auf einfache Weise an den min/max-Wert ran,
ohne das versteckte Reading z.B. ".col_72_MQTT2_strom_wert_kwh_24_values" zu durchsuchen.
Zitat von: jkriegl am 19 Juni 2022, 19:09:11
andere Frage: wie kommt man auf einfache Weise an den min/max-Wert ran,
ohne das versteckte Reading z.B. ".col_72_MQTT2_strom_wert_kwh_24_values" zu durchsuchen.
Diese sind in der Kollektor-Struktur abgelegt.
Man kann sie im gleichen DOIF z. B. über DOIF_Readings in einem Reading ablegen oder direkt in uiTable visualisieren.
z. B.
attr di_light DOIF_Readings max: ${[di_setreading:humidity:col1w]}{max_value}
Genauso gibt es
min_value und
max_value_time bzw.
min_value_time in Sekunden, die man in Zeit-Darstellung umwandeln kann.
Eine Anfängerfrage zu cards mit zwei EInheiten. Ich habe das so gelöst
card([Viessmann2:Temperature3:col],"Wasser Verbrauch/Temp",undef,20,65, undef,undef,"°C",\&warmwasser_hue,"0","130,0,0,0,0,0,400",undef,undef,[Wasserzaehler_IEC_01:Verbrauch:col],0,,240,240,"l",undef,"0")\
und hätte aber gern keine Dezimalstellen beim Verbrauch. Ich dachte, die letzte Null liefert das - dem ist aber nicht so (Screenshot, rechts). Weiß jemand, warum?
Zitat von: andies am 25 Juli 2022, 22:22:30
Eine Anfängerfrage zu cards mit zwei EInheiten. Ich habe das so gelöst
card([Viessmann2:Temperature3:col],"Wasser Verbrauch/Temp",undef,20,65, undef,undef,"°C",\&warmwasser_hue,"0","130,0,0,0,0,0,400",undef,undef,[Wasserzaehler_IEC_01:Verbrauch:col],0,,240,240,"l",undef,"0")\
und hätte aber gern keine Dezimalstellen beim Verbrauch. Ich dachte, die letzte Null liefert das - dem ist aber nicht so (Screenshot, rechts). Weiß jemand, warum?
Bei dir fehlt der Maximalwert, siehe Fragezeichen:
Zitatcard([Viessmann2:Temperature3:col],"Wasser Verbrauch/Temp",undef,20,65, undef,undef,"°C",\&warmwasser_hue,"0","130,0,0,0,0,0,400",undef,undef,[Wasserzaehler_IEC_01:Verbrauch:col],0,?,240,240,"l",undef,"0")
Danke! Gibt es eine Möglichkeit, dies dynamisch bestimmen zu lassen, also in Abhängigkeit der dann vorliegenden Daten (ich dachte durch das weglassen wäre das dynamisch)?
Zitat von: andies am 26 Juli 2022, 07:50:12
Danke! Gibt es eine Möglichkeit, dies dynamisch bestimmen zu lassen, also in Abhängigkeit der dann vorliegenden Daten (ich dachte durch das weglassen wäre das dynamisch)?
Du hast die Farbzuordnung 240 (blau) für min und 240 für max angegeben. Das musst du für deine Bedürfnisse anpassen. HSV-Werte kanns du über colorpicker (google) bestimmen. 0 ist rot, 60 ist gelb, 120 ist grün usw.
@Damian
ich habe hier zwei optische Probleme bei der Card.
1. Die Anzeige unten, Tage und Uhrzeit überlappen bei mir.
2. Der Text aus dem Ring, bei mir "Pv W" spiegelt sich unten links in der Ecke. Vielleicht auch der Grund, warum Tage und Uhrzeit überlappen.
In deinem Beispiel unter https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg ist das nicht der Fall.
defmod di_collect_pv_01 DOIF ##
attr di_collect_pv_01 room 14.PV
attr di_collect_pv_01 uiTable {package ui_Table;;}\
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1600,30,120,"Pv W",undef,"1,font-size:50%")
setstate di_collect_pv_01 initialized
setstate di_collect_pv_01 2022-09-21 19:45:13 .col_72_PV_Deye1600_01_Power_12_times 1663739818,1663740418,1663741018,1663741317,1663742219,1663742817,1663743417,1663743774,1663744618,1663745217,1663745817,1663746417,1663747017,1663747317,1663748217,1663748517,1663749117,1663750017,1663750317,1663751217,1663751517,1663752417,1663753017,1663753317,1663753917,1663754817,1663755417,1663755717,1663756617,1663756914,1663757517,1663758117,1663759017,1663759617,1663759917,1663760517,1663761118,1663761717,1663762617,1663762917,1663763517,1663764417,1663764654,1663765617,1663765917,1663766596,1663767417,1663767718,1663768617,1663769217,1663769817,1663770117,1663771017,1663771617,1663771918,1663772817,1663773417,1663774017,1663774317,1663774917,1663775817,1663776418,1663776692,1663777617,1663777917,1663778437,1663779417,1663779717,1663780617,1663781217,1663781400,1663782105
setstate di_collect_pv_01 2022-09-21 19:45:13 .col_72_PV_Deye1600_01_Power_12_values 30,42,52,59,76,102,141,141,161,197,227,268,279,264,343,371,325,388,389,425,435,426,456,526,589,698,939,918,924,924,927,927,950,961,961,946,952,954,936,919,910,903,903,878,859,859,824,797,760,725,700,680,618,578,578,513,467,422,404,322,80,53,53,45,44,45,24,20,8,0,0,0
setstate di_collect_pv_01 2022-09-17 10:47:40 cmd 0
setstate di_collect_pv_01 2022-09-17 10:47:40 mode enabled
setstate di_collect_pv_01 2022-09-17 10:47:40 state initialized
Wie kann ich es richten?
Gruß schwatter
Stell mal die Sprache im Device global im Attribut language auf de, dann passt das.
Das ist kein Spiegeln, sondern die Beschriftung der Zeile.
Mh, "de" habe ich gesetzt, aber der Text ist noch auf Englisch. Klemmt wohl noch an einer anderen Stelle.
Ok, aber die Beschriftung möchte ich nicht. In deinem Beispiel ist die Zeile auch nicht beschriftet. Das ist dein Original
card([zaehler:l-Produktion:col12],undef,[zaehler:l-Produktion] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,3.6,30,60,"PV kW",undef,"1,,font-size:50%")|\
Da ist die Zeile unten links nicht beschriftet.
Gruß schwatter
Zitat von: schwatter am 21 September 2022, 23:26:54
Mh, "de" habe ich gesetzt, aber der Text ist noch auf Englisch. Klemmt wohl noch an einer anderen Stelle.
Ok, aber die Beschriftung möchte ich nicht. In deinem Beispiel ist die Zeile auch nicht beschriftet. Das ist dein Original
card([zaehler:l-Produktion:col12],undef,[zaehler:l-Produktion] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,3.6,30,60,"PV kW",undef,"1,,font-size:50%")|\
Da ist die Zeile unten links nicht beschriftet.
Gruß schwatter
Die Beschriftung kann man nicht abschalten, im Wiki ist noch die alte Version. Die Beschriftung ist wichtig, da man inzwischen auch Diagramme ohne Ring erstellen kann, dann wüsste man nicht, um was es sich handelt, vor allem, wenn man zwei Readings darstellt.
Nabend,
ich habe die Sprache in global auf "DE". Kleingeschrieben wäre bei mir falsch.
Jedenfalls funktioniert es noch nicht bei mir.
Was ich zu global und Sprache finde ist, das dies nur für die commandref funktioniert und bis jetzt nicht weiter verfolgt wurde.
https://forum.fhem.de/index.php/topic,110274.15.html
Oder liest dein Modul einfach das gesetzte Attribute aus?
Gruß schwatter
Du musst vor allem die Spracheinstellung des Systems auf DE vornehmen:
https://www.google.com/search?q=raspberry+pi+sprache+einstellen
Habe seit dem letzten update einen kleinen Schöheitsfeher bei cylinder. Die Werte (62, 51, 45) s. beigefügtes png, waren davor verteilt.
cylinder(undef,30,85,"",75,80,undef,0,[HK.SOL:P.Temp],"0.70.70","",[HK.SOL:P.Temp_m],40,"",[HK.SOL:P.Temp_u],200,"")
@Damian
Ok, Systemweit hat geholfen. Danke.
Noch eine Frage zur Card. Gibt es ein Autoresize für Card?
Gesetzt hab ich es so:
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,262")
Toll wäre es so:
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,[color=red]auto[/color]")
Wegen verschiedener Devices (Handy,Tablet,Pc,...)
Gruß schwatter
Zitat von: schwatter am 25 September 2022, 15:48:32
@Damian
Ok, Systemweit hat geholfen. Danke.
Noch eine Frage zur Card. Gibt es ein Autoresize für Card?
Gesetzt hab ich es so:
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,262")
Toll wäre es so:
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,[color=red]auto[/color]")
Wegen verschiedener Devices (Handy,Tablet,Pc,...)
Gruß schwatter
Für alle Cards gelten die gleichen Default-Werte - das ist beabsichtigt, damit das Erscheinungsbild bei mehreren Cards einheitlich bleibt. Eine Auto-Funktion würde dazu führen, dass die Skalierungen (Schriftgröße, Höhe, Breite, usw.) unterschiedliche wären.
Zitat von: jkriegl am 25 September 2022, 13:52:25
Habe seit dem letzten update einen kleinen Schöheitsfeher bei cylinder. Die Werte (62, 51, 45) s. beigefügtes png, waren davor verteilt.
cylinder(undef,30,85,"",75,80,undef,0,[HK.SOL:P.Temp],"0.70.70","",[HK.SOL:P.Temp_m],40,"",[HK.SOL:P.Temp_u],200,"")
Problem behoben. Neue Version eingecheckt.
Eher ein Wunsch: mit Telegram "set myTelegramBot cmdSend { plotAsPng('SVG_FileLog_Solar') }"
versende ich SVG-Plot SVG_FileLogs.
Gibt es eine Möglichkeit SVG-cards zu verschicken?
Alternativ: ein Bild verschicken
https://wiki.fhem.de/wiki/TelegramBot (https://wiki.fhem.de/wiki/TelegramBot)
Mit Signalbot geht das:
set Signalbot send @Empfänger &DI_device
Details: https://wiki.fhem.de/wiki/Signalbot#Details_zum_Versenden_von_Plots
Ist aber zugegeben ein bisschen "hacky" und verwendet Internas von DOIF.
Das könnte der Autor von TelegramBot grundsätzlich aber auch übernehmen.
Eine offizielle API von DOIF wäre natürlich noch schöner.
Falls man im Status eines Devices eine Card visualisiert haben möchte, dann kann man wie folgt vorgehen.
Man definiert ein DOIF welches die Daten von einem bestimmten Device sammelt. Im ursprünglichen Device werden diese Daten dann über devStateIcon visualisieren.
Dieses DOIF kann auch von mehreren anderen Devices Daten sammeln, die man wo anders visualisieren will.
Beispiel:
Das Device MQTT2_DVES_D90D08 empfängt Co2 Daten, dessen Status wird gar nicht belegt, daher erscheinen dort nur drei Fragezeichen. Im Reading MHZ19B_CarbonDioxide von MQTT2_DVES_D90D08 werden die co2 Werte geliefert.
Zuerst definiert man sich ein DOIF mit dem Attribut event_Readings zum Sammeln der Daten des Readings:
defmod di_collect DOIF ##
attr di_collect event_Readings co2:[MQTT2_DVES_D90D08:MHZ19B_CarbonDioxide:col3d]
dann definiert man im eigentlichen Device ein devStateIcon mit dem Card-Aufruf auf das definierte Reading co2 des DOIFs:
attr MQTT2_DVES_D90D08 devStateIcon {ui_Table::card(ReadingsVal("di_collect","co2",0),undef,"air\@silver",400,1200,120,0,"ppm",[(600,120,1000,60,1200,0)],"0,,fill:silver","130,,1,0,1",'0,,1')}
Und schon wird im Status des MQTT-Devices statt Fragezeichen die card-Grafik dargestellt und diese wird sogar beim Event automatisch aktualisiert.
Neue Features
Man wird in der kommenden Version Readings angeben können, deren Daten nicht gesammelt werden sollen und damit auch nicht geplottet. Im Anhang ist ein Beispiel, wo die aktuelle PV-Leistung sowie und Einspeise/Bezugsleistung im Plot erscheint. Die Gesamtenergie (PV/Bezug/Einspeisung) wird dagegen nur angezeigt, erscheint jedoch nicht im Plot selbst.
Und hier mal ein Beispiel, wo zwei Readings angegeben wurden. PV-Leistung wird geplottet, PV-Energie dagegen nicht, beide Readingwerte werden im Ring angezeigt.
Neue Version wurde eingecheckt.
Neuerung: Der Parameter collect2 kann jetzt, wie der Parameter collect, auch ein Array mit Readings sein. Wird die Collector-Angabe col nicht angegeben, so werden die Daten des Readings nicht gesammelt und nicht geplottet, sondern nur im Ring angezeigt (die erste Readingangabe des ersten collect-Arrays muss col beinhalten). Ein Icon in der Kopfzeile wird jetzt immer links angezeigt.
Hier die Definition der beiden zuletzt geposteten Diagramme:
card([[MQTT2_DVES_C58DCB:power_pv:144col1d],[MQTT2_DVES_C58DCB:power_fc:144col1d]],undef,"fa_bolt\@silver",-3.6,3.6,0,90,["PV","Netz"],[(-1,0,-0.01,30,1,60,3.6,90)],"2,,fill:silver","130,,1,0,1","1,,1,0,1",undef, [[di_counter_new:MQTT2_DVES_C58DCB.total_pv.day],[di_counter_new:MQTT2_DVES_C58DCB.total_c.day],[di_counter_new:MQTT2_DVES_C58DCB.total_f.day]],-25,25,0,90,["PV","Bezug","Einsp."],[(-10,0,-0.01,30,10,60,25,90)],"3,,fill:silver")|
card([MQTT2_DVES_C58DCB:power_pv:144col1d],"","fa_bolt\@silver",-3.6,3.6,0,90,"kW",undef,"2,,fill:silver","130,,1,0,1","1,,1,0,2",undef, [di_counter_new:MQTT2_DVES_C58DCB.total_pv.day],-25,25,0,90,"kWh",undef,"2,,fill:silver")
Die Doku wurde angepasst: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Verständnisfragen können hier gestellt werden.
Mit der steigenden Anzahl an Optionen wäre eine Art Editor langsam interessant.
Also ein Formular in das man alle Daten eintragen kann, ggf. mit Hilfestellungen und Auswahlboxen.
Der stellt dann auf Knopfdruck das entsprechenden card Kommando zusammen, so dass man es mit copy&paste einfügen kann - oder holt/setzt das gleich direkt in einer DOIF Device.
Zitat von: Adimarantis am 04 November 2022, 08:59:03
Mit der steigenden Anzahl an Optionen wäre eine Art Editor langsam interessant.
Also ein Formular in das man alle Daten eintragen kann, ggf. mit Hilfestellungen und Auswahlboxen.
Der stellt dann auf Knopfdruck das entsprechenden card Kommando zusammen, so dass man es mit copy&paste einfügen kann - oder holt/setzt das gleich direkt in einer DOIF Device.
Ja, vielleicht möchtest du den Anfang machen :)
Hier mal ein paar Erläuterungen zu aktueller Version.
- Die Parameter von card haben sich prinzipiell nicht geändert. collect2 und unit2 können jetzt Arrays für mehrere Readings sein, wie es bereits bei collect schon zuvor möglich war. Diese Version ist also abwärtskompatibel.
- Es gibt nur einen ganzen Ring mit einem Wert oder einen Doppelring mit zwei Werten wie bisher, alle weiteren Werte landen als Halbringe in der Kopfzeile. Wenn eine 1 beim Parameter hring angegeben wird, so werden alle Werte als Halbring in der Kopfzeile dargestellt, es gibt dann keinen Ring und keinen Doppelring.
- Die col-Angabe kann bei Readingsangaben weggelassen werden, dann werden die Daten dieser Readings nicht gesammelt und erscheinen nur in den Ringen aber nicht im Plot und nicht in der Fußzeile. Mindestens ein Reading muss mit col angegeben werden.
- Für collect bzw. collect2 können beliebig viele Werte angegeben werden.
- Die ersten beiden Werte aus collect werden im Doppelring angezeigt, alle weiteren landen in Halbringen in der Kopfzeile; wenn collect nur einen Wert hat und collect2 mehrere, dann wird der erste Wert von collect und der erste Wert von collect2 im Doppelring angezeigt, die restlichen von collect2 landen in Halbringen der Kopfzeile.
- Bei einer Card mit der Standardbreite können maximal 6 Werte angezeigt werden. Zwei im Doppelring und vier in Halbringen in der Kopfzeile. Möchte man mehr als 6 Werte anzeigen, dann muss man die Breite von card vergrößern, damit mehr als vier Halbringe in der Kopfzeile Platz finden.
Hallo Damian,
seite dem neuest Update habe ich im uitable-Card eine falsche Farbe (siehe Anhang)
Ist das ein Bug oder müssen die Parameter angepasst werden ?
Gruß,
JudgeDredd
der letzte update ist nicht ganz abwärtskompatiebel.
So wars früher https://forum.fhem.de/index.php/topic,128598.msg1231128.html#msg1231128 (https://forum.fhem.de/index.php/topic,128598.msg1231128.html#msg1231128)
Bei #7 ist der code
Zitat von: Damian am 04 November 2022, 15:05:42
Diese Version ist also abwärtskompatibel.
Zitat von: jkriegl am 05 November 2022, 11:47:57
der letzte update ist nicht ganz abwärtskompatiebel.
Mmmh, also meine Parameter habe ich jetzt mal mit dem Wiki verglichen und da sieht es eigentlich so aus, das sie korrekt sind.
Nur die Ausgabe ist halt nicht so, wie sie sein sollte.
Ich bin noch nicht ganz dahintergestiegen, wo genau die Unterschiede zwischen den beiden Versionen liegen.
Hast Du einen Tipp, wie ich ohne größere Analyse meinen Aufruf ändern muss ?
Zitat von: JudgeDredd am 05 November 2022, 12:41:55
Mmmh, also meine Parameter habe ich jetzt mal mit dem Wiki verglichen und da sieht es eigentlich so aus, das sie korrekt sind.
Nur die Ausgabe ist halt nicht so, wie sie sein sollte.
Ich bin noch nicht ganz dahintergestiegen, wo genau die Unterschiede zwischen den beiden Versionen liegen.
Hast Du einen Tipp, wie ich ohne größere Analyse meinen Aufruf ändern muss ?
Ich habe das Problem bereits gefixt - muss noch etwas testen, dann gibt es ein Update.
Zitat von: Damian am 05 November 2022, 13:42:14
Ich habe das Problem bereits gefixt - muss noch etwas testen, dann gibt es ein Update.
Ah ok, Danke für die Info. Dann mach Dir kein Stress, Wenn ich weiß, das es in Arbeit ist, dann passt das.
Ich dachte nur es läge evtl. an meiner FHEM Installation oder das ich irgendwas nicht mitbekommen hätte.
Zitat von: JudgeDredd am 05 November 2022, 13:45:00
Ah ok, Danke für die Info. Dann mach Dir kein Stress, Wenn ich weiß, das es in Arbeit ist, dann passt das.
Ich dachte nur es läge evtl. an meiner FHEM Installation oder das ich irgendwas nicht mitbekommen hätte.
Ich bin wohl im Thread verrutscht, ich habe das Problem von jkriegl gefixt.
Du musst mir deine Definition posten.
Zitat von: Damian am 05 November 2022, 14:27:24
Ich bin wohl im Thread verrutscht, ich habe das Problem von jkriegl gefixt.
Du musst mir deine Definition posten.
Oh ok, dann war das ein Missverständnis.
Hier meine DEF:
card([slWM:wm02_nn_luftdruck:col12],"Luftdruck (".[slWM:wm02_luftdrucktrend].")","weather_barometric_pressure",980,1047,30,90,"hPa",undef,0)
Ich kann bei mir das Problem nicht nachstellen. Vielleicht wird es durch eine andere card auf der gleichen HMTL-Seite hervorgerufen.
Ich habe gerade die aktuelle Version hochgeladen. Du kannst es damit testen. Wenn das Problem weiterhin auftritt, dann leg die card in einen separaten Raum (room) und schau mal ob es dann geht.
Zitat von: Damian am 05 November 2022, 19:37:16
Ich habe gerade die aktuelle Version hochgeladen. Du kannst es damit testen.
Also nach Update auf Rev 26655 leider keine Besserung.
Auch in einem neuen Device in einem neuen leeren Raum ist die Anzeige leider Fehlerhaft.
Rev 26444 funktioniert weiterhin.
Seltsam finde ich, das ich von niemand Anderem etwas vergleichbares hier im Forum lese.
Entweder ist das tatsächlich etwas individuelles bei mir oder ich frage einfach zu schnell ;)
Zitat von: JudgeDredd am 06 November 2022, 12:33:20
Also nach Update auf Rev 26655 leider keine Besserung.
Auch in einem neuen Device in einem neuen leeren Raum ist die Anzeige leider Fehlerhaft.
Rev 26444 funktioniert weiterhin.
Seltsam finde ich, das ich von niemand Anderem etwas vergleichbares hier im Forum lese.
Entweder ist das tatsächlich etwas individuelles bei mir oder ich frage einfach zu schnell ;)
Tja, schade eigentlich. Ich kann auch mit der Version 26655 das Problem nicht verifizieren. Vielleicht hängt es mit der Perlversion zusammen.
Zitat von: Damian am 06 November 2022, 14:54:02
Tja, schade eigentlich. Ich kann auch mit der Version 26655 das Problem nicht verifizieren. Vielleicht hängt es mit der Perlversion zusammen.
Die Perlversion scheint der richtige Tipp gewesen zu sein.
Wenn ich die Card auf einer neuen Perl-Version ausführe, dann stimmen zumindest die Farben wieder.
Allerdings ist das Symbol nun Linksbündig. Vorher (und auch im Wiki) war es Rechtsbündig.
Aber es könnte ja sein, das das Wiki noch nicht vollständig aktualisiert ist.
Kurze andere Frage:
Ist es möglich die Skalierung der Y-Achse zu fixieren ?
Aktuell skaliert sie sich automatisch am höchsten und niedrigsten Wert der Daten.
Zitat von: JudgeDredd am 07 November 2022, 15:41:05
Die Perlversion scheint der richtige Tipp gewesen zu sein.
Wenn ich die Card auf einer neuen Perl-Version ausführe, dann stimmen zumindest die Farben wieder.
Allerdings ist das Symbol nun Linksbündig. Vorher (und auch im Wiki) war es Rechtsbündig.
Aber es könnte ja sein, das das Wiki noch nicht vollständig aktualisiert ist.
Kurze andere Frage:
Ist es möglich die Skalierung der Y-Achse zu fixieren ?
Aktuell skaliert sie sich automatisch am höchsten und niedrigsten Wert der Daten.
Das Icon ist jetzt einheitlich immer links, das habe ich bereits geschrieben. Im Wiki sind noch die Ausgaben der alten Version.
Für Skalierung ist der Parameter $prop zuständig.
Beispiel zur Visualisierung von Energie-Statistik mit Hilfe von card im uiTable-Attribut über Templates realisiert:
https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-.2C_Monats-_und_Jahresstatistik_f.C3.BCr_Strom-.2C_Gas-.2C_Wasserz.C3.A4hler_und_andere_Z.C3.A4hler
Card-Doku um Anwendungsbeispiele erweitert:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anwendungsbeispiele_mit_card
Hallo zusammen,
bin durch Zufall auf die uiTables gestoßen. Sieht klasse aus und steckt sicher auch nicht wenig Hirnschmalz und Arbeit drin -> Hut ab!
Allerdings habe ich dazu ein paar Fragen die sich mir da auftun:
1. Wie man auf dem Bild sehen kann, hab ich 5 Sensoren pro Zimmer. in den oberen Zeilen sind die einzeln, bei dem unteren wollte ich alles in eine Card bringen. Jedoch wird bei dem Innenring nicht richtig dargestellt und auch die Farben sollten, entsprechend der Anwendungsbeispiele mit Card, anders sein (rechts bei Wohn- und Schlafzimmer auch, da sollten die \&temp_hue und \&hum_hue Farben verwendet werden).
Dann bekomme ich nur eine Scala im Chart angezeigt (kann man das irgendwo hinterlegen? Habe schon probiert sie zu hinterlegen, dann versschwinden die Halbkreisanzeigen oben)
2. Die drei Halbkreise oben haben verschiedene Scalenwerte, kann man die separat hinterlegen? Einer sollte ja von 400-1200, einer von 0-1 und einer von 0-3 gehen. Die Definition hänge ich mal an, damit man sieht was ich da verzapft habe.
{package ui_Table;
}
card([MQTT2_WP6003_WZ11:CO2:col1d],undef,"feinstaub",400,1200,120,0,"CO2",[400,60,800,120,1000,60,1200,0],0,"130,,,,,,300",'0,1,1',"50,35,45,35,50,35")|
card([MQTT2_WP6003_WZ11:HCHO:col1d],undef,"feinstaub",0.0,1,120,0,"HCHO",[0.3,120,0.7,60,1,0],2,"130,,,,,,300",'0,1,1',"50,35,45,35,50,35")|
card([MQTT2_WP6003_WZ11:TVOC:col1d],undef,"feinstaub",0.0,3,120,0,"TVOC",[0.2,60,0.3,120,3,0],2,"130,,,,,,300",'0,1,1',"50,35,45,35,50,35")|
card([MQTT2_Wohnzimmer:Temperature:col1d],"Wohnzimmer","temp_inside",10,35,undef,undef,"°C",\&temp_hue,"1","130,,,,,,300",undef,undef,
[MQTT2_Wohnzimmer:Humidity:col1d],0,100,undef,undef,"%rH",\&hum_hue,"0")
card([MQTT2_WP6003_SZ1:CO2:col1d],undef,"feinstaub",400,1200,120,0,"CO2",[400,60,800,120,1000,60,1200,0],0,"130,,,,,,300",'0,1,1',"50,35,45,35,50,35")|
card([MQTT2_WP6003_SZ1:HCHO:col1d],undef,"feinstaub",0.0,1,120,0,"HCHO",[0.3,120,0.7,60,1,0],2,"130,,,,,,300",'0,1,1',"50,35,45,35,50,35")|
card([MQTT2_WP6003_SZ1:TVOC:col1d],undef,"feinstaub",0.0,3,120,0,"TVOC",[0.2,60,0.3,120,3,0],2,"130,,,,,,300",'0,1,1',"50,35,45,35,50,35")|
card([MQTT2_Schlafzimmer:Temperature:col1d],"Schlafzimmer","temp_inside",10,35,undef,undef,"°C",\&temp_hue,"1","130,,,,,,300",undef,undef,
[MQTT2_Schlafzimmer:Humidity:col1d],0,100,undef,undef,"%rH",\&hum_hue,"0")
"Temp_AUSSEN" | ring([Wetter:TemperaturC],-10,40,250,0,'°C',"150,1",[(-9,250,10,180,22,120,40,0)],1,'0,0,1,0')|
"Temp_SZ" | ring([MQTT2_WP6003_SZ1:temperature],10,40,undef,undef,'°C',"150,1",[(18,60,28,120,40,0)],1,'0,0,1,0')
card([[MQTT2_Wohnzimmer:Temperature:144col1d],[MQTT2_Wohnzimmer:Humidity:144col1d]],"Wohnzimmer","fa_bolt\@silver",1,100,undef,undef,["°C","%rH"],
[(30,0,60,25,90,50,75,120)],"2,,fill:silver","130,,1,0,1,,300","1,,1,0,1",undef, [[MQTT2_WP6003_WZ11:CO2],[MQTT2_WP6003_WZ11:HCHO],[MQTT2_WP6003_WZ11:TVOC]],0,1200,120,0,
["CO2","HCHO","TVOC"],[(600,120,1000,60,1200,0)],"2,,fill:silver")
Also man kann bei card nur zwei verschiedene Einheiten (mit entsprechenden Farbverläufen) hinterlegen. Ursprünglich waren auch nur zwei Readings möglich (beim Plot linke Einheit und rechte Einheit). Man kann inzwischen zwar beliebig viele Readings angeben, aber bei zwei verschiedenen Einheit-Definitionen ist es geblieben.
Hallo Damian,
schade, muss ich halt doch mehrere Cards anlegen und laufenlassen.
Bleibt dennoch die Frage, warum die Farbe der Cards nicht richtig angezeigt wird, da ich ja die Variablen benutzt habe, die auch in der Doku verwendet werden und dort richtig dargestellt werden.
Im vorliegenden Fall die Karte "Schlafzimmer" in der zweiten Reihe. Der Code ist doch 1:1 aus der Doku.
card([MQTT2_Schlafzimmer:Temperature:col1d],"Schlafzimmer","temp_inside",10,35,undef,undef,"°C",[color=red]\&temp_hue[/color],"1","130,,,,,,300",undef,undef,[MQTT2_Schlafzimmer:Humidity:col1d],0,100,undef,undef,"%rH",[color=red]\&hum_hue[/color],"0")
Wenn ich den Code richtig interpretiere, sollte hinter den Variablen doch schon eine Farbe/Farbverläufe hinterlegt sein.
Es funktioniert alles wie programmiert.
Die Farbzuordnung für Temperatur und Feuchte entspricht der zugeordneten Farbe aus den Funktionen temp_hue, hum_hue, sie ist abhängig vom jeweiligen Wert.
neue Version eingecheckt:
Die Parameter
$prop und
$ringmodel/$model wurden um Klartext-Angaben erweitert. Statt Zahlen können nun Schlüsselwörter zur besseren Lesbarkeit angegeben werden.
Beispiel:
Zitatcard([MQTT2_DVES_D90D08:MHZ19B_CarbonDioxide:col2d],undef,"air\@silver",400,1200,120,0,"ppm",[(600,120,1000,60,1200,0)],"0,,fill:silver","130,,1,0,1",'0,,1')
entspricht
Zitat[card([MQTT2_DVES_D90D08:MHZ19B_CarbonDioxide:col2d],undef,"air\@silver",400,1200,120,0,"ppm",[(600,120,1000,60,1200,0)],"0,,fill:silver","130,autoscaling,nosteps,footer,noycolor",'nogradient,nominmaxvalue,innerring,nopointer,minmax')
Die Version ist wie immer abwärtskompatibel.
Doku zu card und zu den ring-Funktionen wurde angepasst:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card
Guten Morgen,
bei der Darstellung eines Readingwertes mit aktuellem Reading nebst Verlauf, gibt es ja die Möglichkeit den Verlauf mittels "col52w" für ein Jahr bzw. 52Wochen anzeigen zu lassen. So weit so gut. Gibt es auch die Möglichkeit feste Zeiträume zu definieren ? (01.01.-31.12.) Wenn nicht, was würdest Du davon halten ?
Und ich hätte noch einen Wunsch, bzw. Idee... in der Fusszeile werden die Min/Max-Werte eines Readings dargestellt, ich fände auch den Durchschnittswert super....
Justmy2cents
Es wird demnächst eine Balkendarstellung geben. Die wird man dann auch für ein ganzes Jahr nutzen können. Es soll dann auch eine Trendlinie als Durchschnittsverbrauch geben.
neue Version eingecheckt:
card im Originaldevice wird jetzt offiziell. Mit der neuen Version bleibt ebenso wie bei uiTable der Verlauf auch nach einem Neustart erhalten.
siehe neuer Wiki-Beitrag dazu:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#card_im_Status_des_Originaldevices
Moin,
ich habe jetzt für einen Sensor 3 verschiedene Cards angelegt.
So sind die definiert:
card([WeatherScreenPro:temperature:col1w],"Dach-Woche","temp_outside",0,35,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[WeatherScreenPro:humidity:col1w],0,100,undef,undef,"%",\&hum_hue,"0")|
card([WeatherScreenPro:temperature:col4w],"Dach-Monat","temp_outside",0,35,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[WeatherScreenPro:humidity:col4w],0,100,undef,undef,"%",\&hum_hue,"0")|
card([WeatherScreenPro:temperature:col52w],"Dach-Jahr","temp_outside",0,35,undef,undef,"°C",\&temp_hue,"1","130,,,,",undef,undef,[WeatherScreenPro:humidity:col52w],0,100,undef,undef,"%",\&hum_hue,"0")|
Der einzige Unterschied besteht in der Definition der "Laufzeit".
Dennoch ist das Diagramm beim 3. Card mit einer unterschiedlichen Skala. Bug oder feature ?
Zitat von: Bartimaus am 28 Dezember 2022, 14:15:32
Dennoch ist das Diagramm beim 3. Card mit einer unterschiedlichen Skala. Bug oder feature ?
feature, wenn du die Zeitskalierung meinst :)
Meine die Temperaturskalierung... ;)
Zitat von: Bartimaus am 28 Dezember 2022, 14:50:37
Meine die Temperaturskalierung... ;)
Das ist auch normal. Du hast autoscaling gewählt, das kann erst bestimmt werden, wenn es zwei Werte gibt. Bei einem Jahr musst du etwas länger warten ;)
Verständnisfrage zu "fixedscaling": Bei negativer Temperatur, also -10 bis 40 müsste die Scallierung bei -10 beginnen, beginnt aber bei Null. Muss man -10 speziell eingeben?
Zitat von: jkriegl am 28 Dezember 2022, 18:18:12
Verständnisfrage zu "fixedscaling": Bei negativer Temperatur, also -10 bis 40 müsste die Scallierung bei -10 beginnen, beginnt aber bei Null. Muss man -10 speziell eingeben?
Ich glaube den Fall hatten wir irgendwo schon mal. Der negativer Teil wird erst dann angezeigt, wenn es tatsächlich auch negative Zahlen gibt, dann auch bis -10. Wäre sonst schade um die verschwendete Auflösung.
Meine ersten Gehversuche mit der card Funktion.
daher zunächst eine einfache Frage.
Wie bekomme ich die Cards nebeneinander ohne Abstand positioniert ?
{package ui_Table;}\
card([MAX_0f7833:temperature:col],"Büro","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)|
card([MAX_095f9b:temperature:col],"Fernsehzimmer","temp_outside",10,35,undef,undef,"°C",\&temp_hue,undef)|
card([MAX_0f77d4:temperature:col],"Wohnzimmer","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)|
card([MAX_103329:temperature:col],"Büro Annette","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)
card([MAX_0db066:temperature:col],"Bad","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)|\
card([MAX_18ea44:temperature:col],"Schlafzimmer","temp_outside",10,35,undef,undef,"°C",\&temp_hue,undef)|\
card([MAX_0771fc:temperature:col],"Schafen_Annette","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef)|\
card([MAX_1bff4b:temperature:col],"Wintergarten","temp_outside",-10,45,undef,undef,"°C",\&temp_hue,undef,"130,,,,,,200")
In FHEM orientiert sich die Spaltenbreite an der größten Zelle der Spalte der gesamten Tabelle.
Das passiert in der Details-Ansicht oder wenn es darunter Devices gibt, die aufgrund vieler Daten die Breite auseinanderziehen.
Das ist eine HTML-Eigenschaft.
In einem Raum, wo das Device alleine ist oder die darunter liegenden Devices nicht breiter sind, werden die cards wie im Wiki nebeneinander dargestellt.
Danke, verstanden :)
Hi,
ich nutze die card funktion schon seit über 6monaten erfolgreich um meine PV und Energieverbräuche zu visualisieren.
Jetzt ist mir gestern das FHEM mit einem "Out of Memory" abgeschmiert. NAch einem Restart stellte ich fest, das die eingelesenen Daten 10 Tage alt waren. Das kam daher da das statefile (fhem.save) vor 10 Tagen das letzte Mal gespeichert wurde.
Ich bekomme es nicht hin die aktuellen Werte zu korrigieren. In der DOIF_counter funktion besteht schon das problem. einfach den aktuellen *_year" wert anzupassen bringt nix da er andauernd überschrieben wird. Die aktuellen und korrekten Werte befinden sich im filelog.
daher meine Fragen:
1. wäre es möglich eine ReInit Funktion zu integrieren die alle Werte des des DOIF_counters bzw der Card´s auf Basis eines Logs neu einließt?
2. eigentlich viel wichtiger: wie könnte man einfach die aktuellen Werte häufiger sichern? Wäre es ein Workaround das statefile täglich automatisiert zu schreiben? Wenn ja wie?
ICh habe schon diesen Trick (https://wiki.fhem.de/wiki/Trick_der_Woche#Backup_der_Konfiguration_.28fhem.cfg_und_fhem.state.29_bei_jedem_.22save.22)gefunden, aber wie sichert man das statefile?
Zitat von: Tobias am 19 Januar 2023, 08:10:53
Hi,
ich nutze die card funktion schon seit über 6monaten erfolgreich um meine PV und Energieverbräuche zu visualisieren.
Jetzt ist mir gestern das FHEM mit einem "Out of Memory" abgeschmiert. NAch einem Restart stellte ich fest, das die eingelesenen Daten 10 Tage alt waren. Das kam daher da das statefile (fhem.save) vor 10 Tagen das letzte Mal gespeichert wurde.
Ich bekomme es nicht hin die aktuellen Werte zu korrigieren. In der DOIF_counter funktion besteht schon das problem. einfach den aktuellen *_year" wert anzupassen bringt nix da er andauernd überschrieben wird. Die aktuellen und korrekten Werte befinden sich im filelog.
daher meine Fragen:
1. wäre es möglich eine ReInit Funktion zu integrieren die alle Werte des des DOIF_counters bzw der Card´s auf Basis eines Logs neu einließt?
2. eigentlich viel wichtiger: wie könnte man einfach die aktuellen Werte häufiger sichern? Wäre es ein Workaround das statefile täglich automatisiert zu schreiben? Wenn ja wie?
ICh habe schon diesen Trick (https://wiki.fhem.de/wiki/Trick_der_Woche#Backup_der_Konfiguration_.28fhem.cfg_und_fhem.state.29_bei_jedem_.22save.22)gefunden, aber wie sichert man das statefile?
1) wird es vermutlich bald geben, für card-bars habe ich es schon integriert
2) bei mir läuft einfach:
defmod di_save DOIF {[:00];; fhem"save"}
danke :)
Das sind wirklich gute aussichten :)
Zitat von: Tobias am 19 Januar 2023, 13:29:06
danke :)
Das sind wirklich gute aussichten :)
Neue Version eingecheckt.
Die viel gewünschte Option, Daten aus dem Log zu visualisieren, wurde realisiert. Dieses Feature ist dann nützlich, wenn man bestehende Daten aus dem Log bei Neudefinition von card oder nach einem Systemcrash übernehmen möchte. Die Card-Daten werden zur Laufzeit auch ohne Log weiterhin event gesteuert gesammelt und in versteckten Readings gespeichert.
Dokumentation: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Import.2C_.C3.84nderung_und_L.C3.B6schung_von_Diagrammdaten
Wiki-Beitrag zu Verbrauchsstatistiken aktualisiert: https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-.2C_Monats-_und_Jahresstatistik_f.C3.BCr_Strom-.2C_Gas-.2C_Wasserz.C3.A4hler_und_andere_Z.C3.A4hler
Es werden jetzt neben Tages-, Monats- auch Jahresverbräuche der letzten zwei Dekaden als Säulen visualisiert. Per set di_counter_new get_data können bisher geloggte Daten der Vorgängerversion in die Diagramme übernommen werden.
Man kann jetzt über den output-Parameter ungültige Werte über die Angabe undef herausfiltern:
Bsp.
card ([bla:test:col1:($_ > 10 or $_ < 0) ? undef : $_],...)
Werte über 10 und unter 0 sollen nicht ins Diagramm übernommen werden.
HI Damian,
im Wiki habe ich gelsen, das man eine uiTable auch als devstateicon benutzen kann.
Ist es jetzt irgendwie möglich dieses devstateicon in TabletUI (FTUI) Frontent einzubringen?
Zitat von: Tobias am 15 Februar 2023, 14:30:52
HI Damian,
im Wiki habe ich gelsen, das man eine uiTable auch als devstateicon benutzen kann.
Ist es jetzt irgendwie möglich dieses devstateicon in TabletUI (FTUI) Frontent einzubringen?
ich meine, dass das geht. Such mal im passenden Board nach uiTable
Ich habe hier https://forum.fhem.de/index.php/topic,129898.0.html ein paar Experiemente dazu beschrieben uiTable in FTUI3 zu integrieren.
Zur Vereinfachung basiert das auf einer Hilfsfunktion die im SignalBot Modul eingebaut ist (da ich da schon eine Unterstützung hatte uiTables per Messenger zu schicken).
So richtig perfekt ist das alles nicht - aber vielleicht hilft es dir ja weiter, bzw. hast du Anregungen es zu verbessern.
Jörg
neue DOIF-Version eingecheckt
-neuer Datentyp bei card barAvg https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Darstellung_fortlaufender_Daten_als_S.C3.A4ulen
-In der Monatsübersicht von bar/barAvg werden Sonntage gekennzeichnet und der Tag des Monats über den aktuellen Monat hinaus (bei Feb z. B. 29, 30 und 31) in der Beschriftung abgedunkelt.
-import von Excel-csv-Dateien per DOIF_get_file_data https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Import.2C_.C3.84nderung_und_L.C3.B6schung_von_Diagrammdaten
-fehlerhafte collect-Angaben in card werden nun als Fehler in der Tabelle ausgegeben
-Die Zeichen / und - sind nun im Namen des DOIF-Blocks im Perlmodus erlaubt
Neue DOIF-Version eingecheckt.
Die Breite der Säulen wurde angepasst. Jetzt sind die Säulen etwas breiter insb. wenn man mehrere Perioden darstellt.
In der Zählerstatistik https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-.2C_Monats-_und_Jahresstatistik_f.C3.BCr_Strom-.2C_Gas-.2C_Wasserz.C3.A4hler_und_andere_Z.C3.A4hler habe ich jetzt auch die Monatsdarstellung, sowie bei der Jahres- und Dekaden-Darstellung, auf zwei Perioden (statt einer) gestellt. So hat man einen besseren Vergleich zum Vormonat.
Hallo Damian,
gibt es über die card Funktion die Möglichkeit sich den Verlauf eines Wertes z.B. in den letzten 6 Stunden als Balkendiagramm ohne Beschriftung der x- und y-Achse anzeigen zu lassen, d.h. die es werden immer nur 6 Balken angezeigt, 1 pro Jede stunde. In Excel gibt es eine Funktion dafür die Sparklines. Man sieht zwar keine genauen Werte, aber zumindest die Tendenz. Mit "colX" als Parameter kann ich auch die Periode < 1 Tag definieren, mit barX geht das scheinbar nicht? Ich habe dazu im WIKI leider nichts gefunden.
"Raumname"|"Helligkeit"|"Temperatur"|"Luftfeuchtigkeit"|"Batterie"
"Abstellkammer"|card([Schlafzimmer:luminosity:col1],undef,undef,0,undef,90,0,"lum",undef,"0","75,0,0,1,1,0,80")|
ring([Abstellkammer:temperature],15,30,220,0,"°C","120,1",undef,1)|
ring([Abstellkammer:humidity],30,70,undef,undef,'%',"120,1",[(30,240,40,180,45,140,50,120,55,75,70,0)],0,'0,0,1,10')|
icon_label("measure_battery_100\@".([Abstellkammer:batVoltage] < 2.0 ? "red":"green"),[Abstellkammer:batVoltage],([Abstellkammer:batVoltage] < 2.0 ? "red":"green"),"white",-10)
Man könnte sicherlich die Funktion cylinder_bars nehmen, aber da es sich um einen Sensor handelt, müsste man einen Mittelwert in einem bestimmten Zeitraum bilden und das macht die card Funktion ja bereits.
Danke im voraus.
Viele Grüsse
Marcus
Zitat von: Aeroschmelz am 06 März 2023, 10:08:15
Hallo Damian,
gibt es über die card Funktion die Möglichkeit sich den Verlauf eines Wertes z.B. in den letzten 6 Stunden als Balkendiagramm ohne Beschriftung der x- und y-Achse anzeigen zu lassen, d.h. die es werden immer nur 6 Balken angezeigt, 1 pro Jede stunde. In Excel gibt es eine Funktion dafür die Sparklines. Man sieht zwar keine genauen Werte, aber zumindest die Tendenz. Mit "colX" als Parameter kann ich auch die Periode < 1 Tag definieren, mit barX geht das scheinbar nicht? Ich habe dazu im WIKI leider nichts gefunden.
"Raumname"|"Helligkeit"|"Temperatur"|"Luftfeuchtigkeit"|"Batterie"
"Abstellkammer"|card([Schlafzimmer:luminosity:col1],undef,undef,0,undef,90,0,"lum",undef,"0","75,0,0,1,1,0,80")|
ring([Abstellkammer:temperature],15,30,220,0,"°C","120,1",undef,1)|
ring([Abstellkammer:humidity],30,70,undef,undef,'%',"120,1",[(30,240,40,180,45,140,50,120,55,75,70,0)],0,'0,0,1,10')|
icon_label("measure_battery_100\@".([Abstellkammer:batVoltage] < 2.0 ? "red":"green"),[Abstellkammer:batVoltage],([Abstellkammer:batVoltage] < 2.0 ? "red":"green"),"white",-10)
Man könnte sicherlich die Funktion cylinder_bars nehmen, aber da es sich um einen Sensor handelt, müsste man einen Mittelwert in einem bestimmten Zeitraum bilden und das macht die card Funktion ja bereits.
Danke im voraus.
Viele Grüsse
Marcus
Der bar-Datentyp kann z. Zt. nur eine ganze Periode darstellen (Tag, Woche, Monat, Jahr, Decade). Eine Anzeige der letzten X-Werte ist z. Zt. nicht möglich, da muss man auf col ausweichen.
Hi, ich habe Card genutzt, um die Temperatur-forecast-Werte aus dem Weather-Modul anzuzeigen. Getriggert wird DOIF durch Weather. Die Daten werden dann per Perl in DOIF in zwei Strings (Höchst/Tiefsttemperaturen) geladen, die ich dann mit set_card_data in DOIF_Readings lade. Soweit funktioniert es. Für die Card musste ich aber die Daten per Offset um 7 Tage zurückverlegen damit die Zeitachse wieder passt, bzw. lädt sonst set_card_data die Daten nicht. Geht das irgendwie auch ohne Offset?
VG
Hajo
Zitat von: hajo23 am 07 März 2023, 14:30:38
Hi, ich habe Card genutzt, um die Temperatur-forecast-Werte aus dem Weather-Modul anzuzeigen. Getriggert wird DOIF durch Weather. Die Daten werden dann per Perl in DOIF in zwei Strings (Höchst/Tiefsttemperaturen) geladen, die ich dann mit set_card_data in DOIF_Readings lade. Soweit funktioniert es. Für die Card musste ich aber die Daten per Offset um 7 Tage zurückverlegen damit die Zeitachse wieder passt, bzw. lädt sonst set_card_data die Daten nicht. Geht das irgendwie auch ohne Offset?
VG
Hajo
Mit set werden vorherige Daten gelöscht, daher verstehe ich die Vorgehensweise nicht. Wenn die anderen Werte im Diagramm erhalten bleiben sollen, dann musst du die modify-Funktion nutzen. Das Problem mit dem Offset musst du mit konkreten Daten zum Nachvollziehen belegen.
Zitat von: Damian am 07 März 2023, 15:14:50
Mit set werden vorherige Daten gelöscht, daher verstehe ich die Vorgehensweise nicht. Wenn die anderen Werte im Diagramm erhalten bleiben sollen, dann musst du die modify-Funktion nutzen. Das Problem mit dem Offset musst du mit konkreten Daten zum Nachvollziehen belegen.
Das Speichern oder Sammeln der forecast-Daten macht keinen Sinn, weil die Daten nach dem nächsten Update (für die folgenden 7 Tage) völlig anders sein können. Deshalb werden die alten Daten beim Triggern durch die neuen ersetzt. Da es sich aber um eine Vorhersage handelt, liegt der Zeitstempel in der "Zukunft" und damit scheint set_card_data nicht umgehen zu können. Als Workaround nutze ich nun offset um die Zeitstempel um eine Woche in die Vergangenheit zu legen.
Die verwendeten Daten:
2023.03.07 19:02:31 3: 2023-03-07_16:36 4,2023-03-08_16:26 5,2023-03-09_15:40 7,2023-03-10_15:27 7,2023-03-11_13:19 6,2023-03-12_13:02 6,2023-03-13_14:41 13, 2023-03-08_04:59 -1,2023-03-09_06:54 -1,2023-03-09_23:44 3,2023-03-11_05:55 1,2023-03-12_06:11 -2,2023-03-12_19:00 4,2023-03-14_07:00 6
Zitat von: hajo23 am 07 März 2023, 18:41:13
Das Speichern oder Sammeln der forecast-Daten macht keinen Sinn, weil die Daten nach dem nächsten Update (für die folgenden 7 Tage) völlig anders sein können. Deshalb werden die alten Daten beim Triggern durch die neuen ersetzt. Da es sich aber um eine Vorhersage handelt, liegt der Zeitstempel in der "Zukunft" und damit scheint set_card_data nicht umgehen zu können. Als Workaround nutze ich nun offset um die Zeitstempel um eine Woche in die Vergangenheit zu legen.
OK. Die Idee ist ja fortlaufende Daten per Event abhängig der Zeit zu visualisieren. Daher wird die Zukunft nicht abgebildet. Daten in der Zukunft können also nur über negative Offsetverschiebung in die Vergangenheit verschoben werden. Sie werden dann in der aktuellen Zeitperiode oder in der Vergangenheit dargestellt. Das Ausblenden der X-Achsenbeschriftung ist nicht vorgesehen.
Alternativ kannst du cylinder bars verwenden:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Balkendarstellung_mehrerer_Zahlenwerte_mit_Hilfe_der_universellen_SVG-Funktion_cylinder_bars
Dann muss du dich selbst zum die Wertebeschriftung kümmern und die Werte den einzelnen Säulen zuordnen.
HI Damian,
ich versuche das Beispiel aus dem Wiki, card data ändern umzusetzen, bekomme aber einen Fehler:
{DOIF_modify_card_data('DOIF_counter_new','PM_Solardach','PM_Solardach.Consumption.year','bar1decade',-300,'2023.01.01_00:10 2959.067,2023.03.27_00:01 330')}
Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1489.
Im Device DOIF_counter_new gibt es die Definition nicht: [PM_Solardach:PM_Solardach.Consumption.year:bar1decade]
Edit: Wahrscheinlich aber: [DOIF_counter_new:PM_Solardach.Consumption.year:bar1decade]
Danke, hab es verstanden und sofort hat es funktioniert.
Ich habe meinen Counter mit den Card´s neu aufgesetzt. Dummerweise fängt aber mein Counter für die Monats- und Jahreszähler bei 0 an zu zählen und ich bekomme es nicht hin einen Aufsatzpunkt vorzugeben.
Zb. einfach das Reading überschreiben bringt leider nichts:
setreading DOIF_counter_new PM_Solardach.Consumption.year 333
Hast du eine Idee wie ich das anstellen könnte?
Zitat von: Tobias am 27 März 2023, 11:52:09Danke, hab es verstanden und sofort hat es funktioniert.
Ich habe meinen Counter mit den Card´s neu aufgesetzt. Dummerweise fängt aber mein Counter für die Monats- und Jahreszähler bei 0 an zu zählen und ich bekomme es nicht hin einen Aufsatzpunkt vorzugeben.
Zb. einfach das Reading überschreiben bringt leider nichts:
setreading DOIF_counter_new PM_Solardach.Consumption.year 333
Hast du eine Idee wie ich das anstellen könnte?
In dieser Routine wird u. a. der Jahresverbrauch berechnet:
sub midnight { ## Diese Funktion wird um Mitternacht ausgeführt
my ($device,$reading,$mday,$yday)=@_;
set_Reading("$device.$reading.day_counter",ReadingsVal($device, $reading,1));
set_Reading("$device.$reading.last_day",get_Reading("$device.$reading.day",0),1);
set_Reading("$device.$reading.day",0,1);
set_Reading ("$device.$reading.month",int((ReadingsVal($device, $reading,0)-(get_Reading("$device.$reading.month_counter",0)))*1000)/1000,1);
set_Reading ("$device.$reading.year",int((ReadingsVal($device, $reading,0)-(get_Reading("$device.$reading.year_counter",0)))*1000)/1000,1);
if ($mday == 1) {
set_Reading("$device.$reading.month_counter",ReadingsVal($device, $reading,0));
set_Reading("$device.$reading.last_month",get_Reading("$device.$reading.month",0),1);
set_Reading("$device.$reading.month",0,1);
if ($yday == 0) {
set_Reading("$device.$reading.year_counter",ReadingsVal($device, $reading,0));
set_Reading("$device.$reading.last_year",get_Reading("$device.$reading.year",0),1);
set_Reading("$device.$reading.year",0,1);
}
}
}
Du müsstest beim Berechnen des Jahresverbrauchs den letzten Monat drauf addieren:
statt:
set_Reading ("$device.$reading.year",int((ReadingsVal($device, $reading,0)-(get_Reading("$device.$reading.year_counter",0)))*1000)/1000,1);
if ($mday == 1) {
set_Reading ("$device.$reading.year",int((get_Reading($device.$reading.last_month)+get_Reading("$device.$reading.year",0))*1000)/1000,1);
HI Damian,
bei mir ist ja alles 0, bzw wurde heute von 0 angefangen zu zählen. Dementsprechend ist last_month/year = 0 und der aktuelle monat und Jahr identisch bei dem aktuellen Tageswert.
Ich würde gerne mit einem Befehl einmalig(!) und manuell gerne die Werte korrigieren. Also einen offset vorgeben,
Bei jedem Event wird das Jahres-Reading ebenfalls aktualisiert und hochgezählt. Ändere ich das Reading manuell, wird es beim nächsten Event wieder überschrieben...
Edit: Ich häng dir mal ein scrrenshot an, oben an den Halbringen siehst du das es heute bzw gestern bei 0 anfing. Monat und Jahr
Die ganze Berechnung geht von einem fortlaufenden Zähler aus, der immer weiter zählt. Bei dir funktioniert dann die tägliche Berechnung aufgrund der Zählerstände nicht.
Deswegen muss du die tägliche Berechnung des year-Readings und des month rausnehmen:
set_Reading ("$device.$reading.month",int((ReadingsVal($device, $reading,0)-(get_Reading("$device.$reading.month_counter",0)))*1000)/1000,1);
set_Reading ("$device.$reading.year",int((ReadingsVal($device, $reading,0)-(get_Reading("$device.$reading.year_counter",0)))*1000)/1000,1);
dann kannst du das year-Reading manuell setzen und wie vorgeschlagen am Monatsende hochzählen lassen.
danke für die Hinweise, zwischenzeitlich hatte ich mal weiter herumprobiert:
setreading DOIF_counter PM_Solardach.Consumption.year_counter <year - ZielWert>
also in meinem Fall:
setreading DOIF_counter PM_Solardach.Consumption.year_counter 2959
Damit konnte ich zumindest den aktuellen Wert anpassen. Ich hoffe ich habe damit nichts anderes kaputt gemacht ;)
ja, aber wenn dein Zähler am Monatsende auf Null gesetzt wird (es sei denn wir reden von mehreren Zählern), dann wird es nicht funktionieren, weil bei allen Berechnungen Differenzen von absoluten Zählerständen gebildet werden. Das hat den Vorteil, dass auch wenn FHEM zwischendurch offline ist und etwas nicht mitbekommt, die Verbräuche am Ende des Tages stimmten, solange der Zähler selbst weiter zählt.
Hi Damian,
eine neue Frage: die in einer Card, die Bars, möchte ich ich dynamisch nach oben, aber fix bei 0 setzen.
In der Card definition, bei den Properties -> # <y-scaling>: "fixedscaling" (1), "autoscaling" (undef)
Setze ich autoscaling, ist für den kleinesten Wert keine Bar zu sehen weil der unterste Wert der kleinste Wert ist.
Setze ich fixedscaling, fängt zwar die y-Achse bei 0 an, aber der obere Wert ist auch fix.
siehe fotos. Was ich gerne möchte ist, das die y-achse bei 0 anfängt, aber bei oben im autoscaling arbeitet. Geht das irgendwie?
Zitat von: Tobias am 28 März 2023, 09:46:47Hi Damian,
eine neue Frage: die in einer Card, die Bars, möchte ich ich dynamisch nach oben, aber fix bei 0 setzen.
In der Card definition, bei den Properties -> # <y-scaling>: "fixedscaling" (1), "autoscaling" (undef)
Setze ich autoscaling, ist für den kleinesten Wert keine Bar zu sehen weil der unterste Wert der kleinste Wert ist.
Setze ich fixedscaling, fängt zwar die y-Achse bei 0 an, aber der obere Wert ist auch fix.
siehe fotos. Was ich gerne möchte ist, das die y-achse bei 0 anfängt, aber bei oben im autoscaling arbeitet. Geht das irgendwie?
z. Zt. geht das nicht. Du musst fixedscaling nehmen, beim Überschreiten der Obergrenze wird die Obergrenze automatisch angepasst.
Zitat von: Damian am 28 März 2023, 11:10:26z. Zt. geht das nicht. Du musst fixedscaling nehmen, beim Überschreiten der Obergrenze wird die Obergrenze automatisch angepasst.
Das geht, perfekt.
Und, sorry, weitere frage:
Im Wiki habe ich die wunderschöne Grafik mit den Halbringen im oberen Bereich gesehen. Ich würde die gerne fast 1:1 übernehmen aber ich bekomme es nicht hin nur einen Ring (nur PV anstatt wie im Beispiel PV und Netz) mit einem Wert plus die 3 Halbringe im oberen Bereich zu erstellen.
Geht das aktuell nicht oder stell ich mich gerade nur dämlich an?
https://wiki.fhem.de/w/images/thumb/2/2e/Di_card_energie2.png/300px-Di_card_energie2.png
Hintergrund, ich möchte in einer Card den aktuellen PV Tagesverlauf haben, im Ring den aktuellen Erzeugungswert in KW und in den 3 Halbringen oberhalb den aktuellen Tages/Monats- und Jahreswert.
Zitat von: Tobias am 28 März 2023, 11:55:51Zitat von: Damian am 28 März 2023, 11:10:26z. Zt. geht das nicht. Du musst fixedscaling nehmen, beim Überschreiten der Obergrenze wird die Obergrenze automatisch angepasst.
Das geht, perfekt.
Und, sorry, weitere frage:
Im Wiki habe ich die wunderschöne Grafik mit den Halbringen im oberen Bereich gesehen. Ich würde die gerne fast 1:1 übernehmen aber ich bekomme es nicht hin nur einen Ring (nur PV anstatt wie im Beispiel PV und Netz) mit einem Wert plus die 3 Halbringe im oberen Bereich zu erstellen.
Geht das aktuell nicht oder stell ich mich gerade nur dämlich an?
https://wiki.fhem.de/w/images/thumb/2/2e/Di_card_energie2.png/300px-Di_card_energie2.png
Hintergrund, ich möchte in einer Card den aktuellen PV Tagesverlauf haben, im Ring den aktuellen Erzeugungswert in KW und in den 3 Halbringen oberhalb den aktuellen Tages/Monats- und Jahreswert.
z. Zt. gibt es noch nicht so viel Flexibilität, es landen immer die ersten zwei Werte im zentralen Ring, alle weiteren kommen in die Halbringe. In der Zukunft wird man beliebige SVG-Funktionen in der Kopfzeile angeben können.
Hi,a
ich habe das merkwürdige Problem das mein TagesChart (Chart nummer 2 von links) währes des Tages schön sauber mit hochzählt (Attribut +.day) und dann bei der TagesRückstellung um 00:01 den hochgezählten Vortag wieder auf 0 zurücksetzen.
Lese ich mittels der Funktion die Logdaten via get_data (-> last_day) ein, werden Charts sauber aufgebaut (und bleiben).
Als Workarround müsste ich also immer um 00:01 mittels get_data die Charts neu aufbauen, aber so schön ist das nicht....
Ich könnte natürlich die Tagescharts auch gleich auf last_day setzen, allerdings wird dann im Tagesverlauf nicht mit hochgezählt :(
Für den Monats- und Jahreschart gilt dasselbe.
Hast du eine kluge Idee wie ich das anstellen kann das der zähler wärend des Tages sauber mit hochläuft und dann bei Rückstellung auch bleibt?
die Definition, der DOIF_counter ist als eigenes Device, von hier übernommmen (https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-.2C_Monats-_und_Jahresstatistik_f.C3.BCr_Strom-.2C_Gas-.2C_Wasserz.C3.A4hler_und_andere_Z.C3.A4hler):
subs {
push (@{$_counter},["PM_Solardach","Consumption"]); # Solarenergie
}
get_data { # Optionale Übernahme bestehender Daten aus dem Log
for (my $i=0;$i<@{$_counter};$i++) {
::DOIF_set_card_data ("$SELF","DOIF_counter","$_counter[$i][0].$_counter[$i][1].day","bar1month",-300,fhem("get log.counter.$_counter[$i][0].$_counter[$i][1] ./log/counter.$_counter[$i][0].$_counter[$i][1].log - 2000 3000 4:last_day"));
::DOIF_set_card_data ("$SELF","DOIF_counter","$_counter[$i][0].$_counter[$i][1].month","bar2year",-300,fhem("get log.counter.$_counter[$i][0].$_counter[$i][1] ./log/counter.$_counter[$i][0].$_counter[$i][1].log - 2000 3000 4:last_month"));
::DOIF_set_card_data ("$SELF","DOIF_counter","$_counter[$i][0].$_counter[$i][1].year","bar2decade",-300,fhem("get log.counter.$_counter[$i][0].$_counter[$i][1] ./log/counter.$_counter[$i][0].$_counter[$i][1].log - 2000 3000 4:last_year"));
}
}
}
Das Attribut UiTable:
{package ui_Table;
}
card([[PM_Solardach:power:col:$_ >= 0 ? $_ / 1000 : 0],[SEN_EM_Elektro:000_EM_All_usage:col:$_ >= 0 ? $_ / 1000 : 0]],"Energie",[PM_Solardach:power]>0?"sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,6,0,120,["PV","Netz"],undef,"2","130,,,,1,,210","0,0,0,0",undef,
[[DOIF_counter:PM_Solardach.Consumption.day],[DOIF_counter:PM_Solardach.Consumption.month],[DOIF_counter:PM_Solardach.Consumption.year]],0,0,0,120,["Day","Month","Year"],[(-10,0,-0.01,30,10,60,25,90)],"1,,fill:silver") |
card([DOIF_counter:PM_Solardach.Consumption.day:bar1month-300],"Solarenergie in kWh pro Tag","solar_icon",0,30,0,120,"kwh",undef,"0","130,,0,,1,,200","0,0,0,0") |
card([DOIF_counter:PM_Solardach.Consumption.month:bar2year-300],"Solarenergie in kWh pro Monat","solar_icon",0,600,0,120,"kwh",undef,"0","130,fixedscaling,,,1,,200","0,0,0,0") |
card([DOIF_counter:PM_Solardach.Consumption.year:bar2decade-300],"Solarenergie in kWh pro Jahr","solar_icon",0,3000,0,120,"kwh",undef,"0","130,fixedscaling,,,1,,200","gradient,nominmaxvalue,noinnerring,nopointer,minmax")
Du musst das last_day, last_month und last_year-Reading visualisieren und nicht day, month und year.
Hi Damian,
aber verstehe ich es dann nicht so dass den ganzen Tag nichts passiert und erst zu Mitternacht der Balken gesetzt wird?
Analog der Monatsbalken erst am 31. und vorher nichts?
Zitat von: Tobias am 02 April 2023, 14:01:09Hi Damian,
aber verstehe ich es dann nicht so dass den ganzen Tag nichts passiert und erst zu Mitternacht der Balken gesetzt wird?
Analog der Monatsbalken erst am 31. und vorher nichts?
Ja. So ist es bei last...-Readings gelöst. Die Werte werden erst am Ende des Tages gesetzt. Um genau zu sein:
Day muss irgendwann am Ende des Tages zurückgesetzt werden und zuvor in last_day gesichert werden. Ich mache das in der Definition eine Minute nach Mitternacht. Das hat den Vorteil, dass ich einfach erkennen kann, wann eine Periode (Tag, Monat, Jahr) zu ende ist und eine neue anfängt.
Damit last_day aber in der richtigen Periode landet, wird es mit -300 definiert (z. B. [...bar2month-300]), damit es 5 Minuten in die Vergangenheit gespeichert wird. day wird dagegen ohne Zeitverschiebung gespeichert. Es wird im ersten Diagramm dargestellt. Dort kann man, im Gegensatz zu last_day, die bisherige verbrauchte Menge des Tages erkennen.
Hallo Damian,
nach einem Update bekomme ich bei meinen forecast cards den Fehler:
wrong definition at collect2 parameter: 0
list zeigt:
Internals:
CFGFN /opt/fhem/FHEM/wetter.cfg
DEF ## {[Wetter]}
subs {
sub get_date { ## create timestanp
my ($wd)=@_;
my %mon = ('Jan' => 1,'Feb' => 2,'Mär' => 3,'Apr' => 4,'Mai' => 5,'Jun' => 6,'Jul' => 7,'Aug' => 8,'Sep' => 9,'Okt' => 10,'Nov' => 11,'Dez' => 12);
my @datum = split(" ", $wd);
my $ts = sprintf("%4d", $datum[3]).sprintf("-%02d", $mon{$datum[2]}).sprintf("-%02d", $datum[1])."_$datum[4]";
return $ts;
}
sub get_day {
my ($wd)=@_;
my %mon = ('Jan' => 1,'Feb' => 2,'Mär' => 3,'Apr' => 4,'Mai' => 5,'Jun' => 6,'Jul' => 7,'Aug' => 8,'Sep' => 9,'Okt' => 10,'Nov' => 11,'Dez' => 12);
my @datum = split(" ", $wd);
my $ts = sprintf("%4d", $datum[3]).sprintf("-%02d", $mon{$datum[2]}).sprintf("-%02d", $datum[1])."_";
return $ts;
}
}
get_data { [Wetter]; ## Übernahme der forecast-Daten aus dem Wettermodul
my ($hash) = @_;
my $temp;
my $rain;
for (my $i=1; $i<49; $i++) {
my $ts = get_date(ReadingsVal("Wetter", "hfc".$i."_pubDate",""));
my $rain_snow = ReadingsVal("Wetter", "hfc".$i."_rain1h", 0) + ReadingsVal("Wetter", "hfc".$i."_snow1h", 0);
$temp .= $ts." ".ReadingsVal("Wetter", "hfc".$i."_temp_c", 0).",";
$rain .= $ts." $rain_snow,";
}
for (my $i=3; $i<9; $i++) {
my $day_rain = get_date(ReadingsVal("Wetter", "fc".$i."_pubDate",""));
my $day_part = get_day(ReadingsVal("Wetter", "fc".$i."_pubDate",""));
my $day_eve = $day_part."18:30";
my $day_nig = $day_part."22:30";
my $day_mor = $day_part."08:30";
my $day_mid = $day_part."14:30";
my $rain_snow = ReadingsVal("Wetter", "fc".$i."_rain", 0) + ReadingsVal("Wetter", "fc".$i."_snow", 0);
$temp .= $day_mor." ".ReadingsVal("Wetter", "fc".$i."_temperature_morn", 0).",".$day_mid." ".ReadingsVal("Wetter", "fc".$i."_temperature", 0).",";
$temp .= $day_eve." ".ReadingsVal("Wetter", "fc".$i."_temperature_eve", 0).",".$day_nig." ".ReadingsVal("Wetter", "fc".$i."_temperature_night", 0).",";
## $rain .= $day_rain." ".ReadingsVal("Wetter", "fc".$i."_rain", 0).",";
$rain .= "$day_rain $rain_snow,";
}
chop($temp);
chop($rain);
Log3($hash, 3, "Temperatur: $temp Regen: $rain");
::DOIF_set_card_data ("$SELF","$SELF","temp_h","col7d",-604800,$temp);
::DOIF_set_card_data ("$SELF","$SELF","rain_h","col7d",-604800,$rain);
}
FUUID 640b44cf-f33f-36b2-bf03-cd67e562b7672699
MODEL Perl
NAME di_Wetter_h
NOTIFYDEV di_Wetter_h,global,Wetter
NR 853
NTFY_ORDER 50-di_Wetter_h
STATE initialized
TYPE DOIF
VERSION 27367 2023-03-27 21:37:33
eventCount 2
DOIF_Readings:
rain_h ::ReadingValDoIf($hash,'di_Wetter_h','rain_h','','col7d')
temp_h ::ReadingValDoIf($hash,'di_Wetter_h','temp_h','','col7d')
READINGS:
2023-04-03 15:10:18 mode enabled
2023-04-03 14:57:01 rain_h HASH(0x5912a78)
2023-04-03 15:10:18 state initialized
2023-04-03 14:57:01 temp_h HASH(0x5925aa8)
Regex:
DOIF_Readings:
di_Wetter_h:
rain_h:
rain_h ^di_Wetter_h$:^rain_h:
temp_h:
temp_h ^di_Wetter_h$:^temp_h:
accu:
bar:
barAvg:
collect:
di_Wetter_h:
collect:
rain_h ^di_Wetter_h$:^rain_h:
temp_h ^di_Wetter_h$:^temp_h:
cond:
Wetter:
0:
&STATE ^Wetter$
uiTable:
di_Wetter_h:
di_Wetter_h_uiTable_c_0_0_0_0:
temp_h ^di_Wetter_h$:^temp_h:
di_Wetter_h_uiTable_c_0_1_0_0:
rain_h ^di_Wetter_h$:^rain_h:
card:
collect:
di_Wetter_h rain_h:
168:
animate 0
dim 72
hours 168
last_slot 200062
last_v 0
max_value 2.4
max_value_slot 50
max_value_time 1680346800
min_value 0
min_value_slot 71
min_value_time 1680527368
name di_Wetter_h
reading rain_h
time 1680529082
type col
value 0
times:
1679929200
1679932800
1679943600
1679950800
1679958000
1679968800
1679976000
1679983200
1679994000
1680001200
1680008400
1680019200
1680026400
1680033600
1680044400
1680051600
1680058800
1680069600
1680076800
1680084000
undef
undef
undef
undef
undef
undef
undef
undef
undef
1680174000
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1680260400
undef
undef
undef
undef
undef
undef
undef
undef
undef
1680346800
undef
undef
undef
undef
undef
undef
undef
undef
undef
1680433200
undef
undef
undef
undef
undef
undef
undef
undef
undef
1680519600
1680527368
values:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
undef
undef
undef
undef
undef
undef
undef
undef
undef
0
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
0
undef
undef
undef
undef
undef
undef
undef
undef
undef
2.4
undef
undef
undef
undef
undef
undef
undef
undef
undef
0.17
undef
undef
undef
undef
undef
undef
undef
undef
undef
0
0
di_Wetter_h temp_h:
168:
animate 0
dim 72
hours 168
last_slot 200062
last_v 2
max_value 13
max_value_slot 40
max_value_time 1680265800
min_value -1
min_value_slot 16
min_value_time 1680058800
name di_Wetter_h
reading temp_h
time 1680529082
type col
value 0
times:
1679929200
1679940000
1679947200
1679950800
1679958000
1679968800
1679976000
1679990400
1679997600
1680004800
1680008400
1680022800
1680030000
1680037200
1680044400
1680051600
1680058800
1680073200
1680080400
1680087600
1680093000
1680107400
undef
1680121800
undef
undef
undef
1680157800
undef
undef
1680179400
undef
1680193800
1680208200
undef
undef
undef
undef
1680244200
undef
1680265800
undef
1680280200
undef
1680294600
undef
undef
undef
1680330600
undef
1680352200
undef
1680366600
undef
1680381000
undef
undef
undef
1680417000
undef
undef
1680438600
1680453000
undef
1680467400
undef
undef
undef
1680503400
undef
undef
1680527120
values:
8
3
0
-1
-1
-1
-1
3
5
7
7
5
2
0
0
0
-1
3
6
8
8
6
undef
4
undef
undef
undef
0
undef
undef
11
undef
7
5
undef
undef
undef
undef
4
undef
13
undef
9
undef
6
undef
undef
undef
5
undef
6
undef
7
undef
6
undef
undef
undef
3
undef
undef
8
6
undef
1
undef
undef
undef
2
undef
undef
0
condition:
0 ::InternalDoIf($hash,'Wetter','STATE'); my ($hash) = @_;
my $temp;
my $rain;
for (my $i=1; $i<49; $i++) {
my $ts = get_date(ReadingsVal("Wetter", "hfc".$i."_pubDate",""));
my $rain_snow = ReadingsVal("Wetter", "hfc".$i."_rain1h", 0) + ReadingsVal("Wetter", "hfc".$i."_snow1h", 0);
$temp .= $ts." ".ReadingsVal("Wetter", "hfc".$i."_temp_c", 0).",";
$rain .= $ts." $rain_snow,";
}
for (my $i=3; $i<9; $i++) {
my $day_rain = get_date(ReadingsVal("Wetter", "fc".$i."_pubDate",""));
my $day_part = get_day(ReadingsVal("Wetter", "fc".$i."_pubDate",""));
my $day_eve = $day_part."18:30";
my $day_nig = $day_part."22:30";
my $day_mor = $day_part."08:30";
my $day_mid = $day_part."14:30";
my $rain_snow = ReadingsVal("Wetter", "fc".$i."_rain", 0) + ReadingsVal("Wetter", "fc".$i."_snow", 0);
$temp .= $day_mor." ".ReadingsVal("Wetter", "fc".$i."_temperature_morn", 0).",".$day_mid." ".ReadingsVal("Wetter", "fc".$i."_temperature", 0).",";
$temp .= $day_eve." ".ReadingsVal("Wetter", "fc".$i."_temperature_eve", 0).",".$day_nig." ".ReadingsVal("Wetter", "fc".$i."_temperature_night", 0).",";
$rain .= "$day_rain $rain_snow,";
}
chop($temp);
chop($rain);
Log3($hash, 3, "Temperatur: $temp Regen: $rain");
::DOIF_set_card_data ("di_Wetter_h","di_Wetter_h","temp_h","col7d",-604800,$temp);
::DOIF_set_card_data ("di_Wetter_h","di_Wetter_h","rain_h","col7d",-604800,$rain);
helper:
NOTIFYDEV di_Wetter_h,global,Wetter
globalinit 1
last_timer 0
sleeptimer -1
triggerDev
triggerEvents
triggerEventsState
internals:
all Wetter:STATE
perlblock:
0 get_data
uiState:
uiTable:
dev di_Wetter_h
header
<table uitabid='DOIF-di_Wetter_h' class=' block wide uiTabledoif doif-di_Wetter_h ' style='border-top:none;'>
package package ui_Table;
reading rain_h
shownostate 1
table:
0:
0:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_Wetter_h_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'di_Wetter_h','temp_h','','col7d'),"Temperatur Vorhersage,font-size:75%","temp_temperature",-50,50,0,250,"°C",\&temp_hue,"0","180,,,,,0,210","1,1,0,0,2",undef,"0"),"")
1:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_Wetter_h_uiTable_c_0_1_0_0',card(::ReadingValDoIf($hash,'di_Wetter_h','rain_h','','col7d'),"Regen Vorhersage,font-size:75%","weather_rain_gauge",0,30,180,280,"l/m²",undef,"0","180,,,,,0,210","1,1,0,0,2",undef,"0"),"")
tc:
0 style='padding-left: 3px;;padding-right: 3px'
1 style='padding-left: 3px;;padding-right: 3px'
2 style='padding-left: 3px;;padding-right: 3px'
3 style='padding-left: 3px;;padding-right: 3px'
td:
0:
tr:
Attributes:
DOIF_Readings temp_h:[di_Wetter_h:temp_h:col7d],
rain_h:[di_Wetter_h:rain_h:col7d]
alias forecast
comment 2023-03-10 15:47:38 hfc10_cloudCover 100
2023-03-10 15:47:38 hfc10_code 14
2023-03-10 15:47:38 hfc10_condition Mäßiger Schnee
2023-03-10 15:47:38 hfc10_day_of_week Sa, 00:00
2023-03-10 15:47:38 hfc10_dew_point 0
2023-03-10 15:47:38 hfc10_humidity 97
2023-03-10 15:47:38 hfc10_icon chance_of_snow
2023-03-10 15:47:38 hfc10_iconAPI 13n
2023-03-10 15:47:38 hfc10_pressure 999
2023-03-10 15:47:38 hfc10_pubDate Sa, 11 Mär 2023 00:00
2023-03-10 15:47:38 hfc10_rain1h 0
2023-03-10 15:47:38 hfc10_snow1h 0.29
2023-03-10 15:47:38 hfc10_tempFeelsLike -6
2023-03-10 15:47:38 hfc10_temp_c 0
2023-03-10 15:47:38 hfc10_temperature 0
2023-03-10 15:47:38 hfc10_uvi 0
2023-03-10 15:47:38 hfc10_visibility 299
2023-03-10 15:47:38 hfc10_wind 26
2023-03-10 15:47:38 hfc10_wind_condition Wind: NW 26 km/h
2023-03-10 15:47:38 hfc10_wind_direction 322
2023-03-10 15:47:38 hfc10_wind_gust 46
2023-03-10 15:47:38 hfc10_wind_speed 26
2023-03-10 15:47:38 hfc11_cloudCover 100
2023-03-10 15:47:38 hfc11_code 14
2023-03-10 15:47:38 hfc11_condition Mäßiger Schnee
2023-03-10 15:47:38 hfc11_day_of_week Sa, 01:00
2023-03-10 15:47:38 hfc11_dew_point -1
2023-03-10 15:47:38 hfc11_humidity 97
2023-03-10 15:47:38 hfc11_icon chance_of_snow
2023-03-10 15:47:38 hfc11_iconAPI 13n
2023-03-10 15:47:38 hfc11_pressure 1000
2023-03-10 15:47:38 hfc11_pubDate Sa, 11 Mär 2023 01:00
2023-03-10 15:47:38 hfc11_rain1h 0
2023-03-10 15:47:38 hfc11_snow1h 0.19
2023-03-10 15:47:38 hfc11_tempFeelsLike -5
2023-03-10 15:47:38 hfc11_temp_c 0
2023-03-10 15:47:38 hfc11_temperature 0
2023-03-10 15:47:38 hfc11_uvi 0
2023-03-10 15:47:38 hfc11_visibility 1152
2023-03-10 15:47:38 hfc11_wind 20
2023-03-10 15:47:38 hfc11_wind_condition Wind: NW 20 km/h
2023-03-10 15:47:38 hfc11_wind_direction 316
2023-03-10 15:47:38 hfc11_wind_gust 43
2023-03-10 15:47:38 hfc11_wind_speed 20
group Umwelt
room doif_ntfy,Übersicht
uiTable {package ui_Table;$SHOWNOSTATE=1;
$TC{0..3}="style='padding-left: 3px;;padding-right: 3px'"
}
card([$SELF:temp_h:col7d],"Temperatur Vorhersage,font-size:75%","temp_temperature",-50,50,0,250,"°C",\&temp_hue,"0","180,,,,,0,210","1,1,0,0,2",undef,"0")|
card([$SELF:rain_h:col7d],"Regen Vorhersage,font-size:75%","weather_rain_gauge",0,30,180,280,"l/m²",undef,"0","180,,,,,0,210","1,1,0,0,2",undef,"0")
verbose 3
Was könnte der Fehler sein?
Gruß
Hajo
collect2 ist der vierzehnte Parameter von card.
Wenn es die gepostete Definition ist, dann solltest du die unvollständigen Angaben weglassen:
card([$SELF:temp_h:col7d],"Temperatur Vorhersage,font-size:75%","temp_temperature",-50,50,0,250,"°C",\&temp_hue,"0","180,,,,,0,210","1,1,0,0,2",undef,"0")|
card([$SELF:rain_h:col7d],"Regen Vorhersage,font-size:75%","weather_rain_gauge",0,30,180,280,"l/m²",undef,"0","180,,,,,0,210","1,1,0,0,2",undef,"0")
stimmt, vielen Dank! :)
Zitat von: Damian am 03 April 2023, 16:10:39collect2 ist der vierzehnte Parameter von card.
Wenn es die gepostete Definition ist, dann solltest du die unvollständigen Angaben weglassen:
ich habe die Definition geändert auf:
card([$SELF:temp_h:col7d],"Temperatur Vorhersage,font-size:75%","temp_temperature",-50,50,0,250,"°C",\&temp_hue,"0","180,undef,undef,undef,undef,0,210","1,1,0,0,2",undef)|
card([$SELF:rain_h:col7d],"Regen Vorhersage,font-size:75%","weather_rain_gauge",0,30,180,280,"l/m²",undef,"1","180,undef,undef,undef,undef,0,210","1,1,0,0,2",undef)
Damit gibt es keine Fehlermeldung mehr. Aber immer wenn die Daten aktualisiert werden, stellt sich die card auf feste Skalierung um.
Im log habe ich die Daten, die ich an set_card_data übergebe:
Temperatur:
2023-04-03_18:00 8,2023-04-03_19:00 8,2023-04-03_20:00 6,2023-04-03_21:00 4,2023-04-03_22:00 2,2023-04-03_23:00 -1,2023-04-04_00:00 -1,2023-04-04_01:00 -1,2023-04-04_02:00 -1,2023-04-04_03:00 -1,2023-04-04_04:00 -1,2023-04-04_05:00 -1,2023-04-04_06:00 -1,2023-04-04_07:00 -1,2023-04-04_08:00 0,2023-04-04_09:00 2,2023-04-04_10:00 3,2023-04-04_11:00 4,2023-04-04_12:00 5,2023-04-04_13:00 6,2023-04-04_14:00 7,2023-04-04_15:00 7,2023-04-04_16:00 7,2023-04-04_17:00 7,2023-04-04_18:00 7,2023-04-04_19:00 5,2023-04-04_20:00 3,2023-04-04_21:00 2,2023-04-04_22:00 1,2023-04-04_23:00 0,2023-04-05_00:00 0,2023-04-05_01:00 0,2023-04-05_02:00 0,2023-04-05_03:00 0,2023-04-05_04:00 0,2023-04-05_05:00 -1,2023-04-05_06:00 -1,2023-04-05_07:00 -1,2023-04-05_08:00 1,2023-04-05_09:00 3,2023-04-05_10:00 5,2023-04-05_11:00 6,2023-04-05_12:00 7,2023-04-05_13:00 8,2023-04-05_14:00 8,2023-04-05_15:00 7,2023-04-05_16:00 7,2023-04-05_17:00 7,2023-04-05_08:30 -1,2023-04-05_14:30 8,2023-04-05_18:30 6,2023-04-05_22:30 4,2023-04-06_08:30 0,2023-04-06_14:30 11,2023-04-06_18:30 7,2023-04-06_22:30 5,2023-04-07_08:30 4,2023-04-07_14:30 13,2023-04-07_18:30 9,2023-04-07_22:30 6,2023-04-08_08:30 5,2023-04-08_14:30 6,2023-04-08_18:30 7,2023-04-08_22:30 6,2023-04-09_08:30 3,2023-04-09_14:30 8,2023-04-09_18:30 6,2023-04-09_22:30 1,2023-04-10_08:30 2,2023-04-10_14:30 7,2023-04-10_18:30 6,2023-04-10_22:30 2
Regen:
2023-04-03_18:00 0,2023-04-03_19:00 0,2023-04-03_20:00 0,2023-04-03_21:00 0,2023-04-03_22:00 0,2023-04-03_23:00 0,2023-04-04_00:00 0,2023-04-04_01:00 0,2023-04-04_02:00 0,2023-04-04_03:00 0,2023-04-04_04:00 0,2023-04-04_05:00 0,2023-04-04_06:00 0,2023-04-04_07:00 0,2023-04-04_08:00 0,2023-04-04_09:00 0,2023-04-04_10:00 0,2023-04-04_11:00 0,2023-04-04_12:00 0,2023-04-04_13:00 0,2023-04-04_14:00 0,2023-04-04_15:00 0,2023-04-04_16:00 0,2023-04-04_17:00 0,2023-04-04_18:00 0,2023-04-04_19:00 0,2023-04-04_20:00 0,2023-04-04_21:00 0,2023-04-04_22:00 0,2023-04-04_23:00 0,2023-04-05_00:00 0,2023-04-05_01:00 0,2023-04-05_02:00 0,2023-04-05_03:00 0,2023-04-05_04:00 0,2023-04-05_05:00 0,2023-04-05_06:00 0,2023-04-05_07:00 0,2023-04-05_08:00 0,2023-04-05_09:00 0,2023-04-05_10:00 0,2023-04-05_11:00 0,2023-04-05_12:00 0,2023-04-05_13:00 0,2023-04-05_14:00 0,2023-04-05_15:00 0,2023-04-05_16:00 0,2023-04-05_17:00 0,2023-04-05_13:00 0,2023-04-06_13:00 0,2023-04-07_13:00 0,2023-04-08_13:00 2.4,2023-04-09_13:00 0.17,2023-04-10_13:00 0
2
Dann poste mal das Bild von dem Diagramm.
Sehr gern, vorher = nach einer Aktualisierung. Nachher nach dem Setzen des Attributes.
Ich habe es korrigiert. Neue DOIF-Version eingecheckt.
Zitat von: Damian am 03 April 2023, 22:35:04Ich habe es korrigiert. Neue DOIF-Version eingecheckt.
Danke, es funktioniert.
Zitat von: Damian am 02 April 2023, 14:27:06Zitat von: Tobias am 02 April 2023, 14:01:09Hi Damian,
aber verstehe ich es dann nicht so dass den ganzen Tag nichts passiert und erst zu Mitternacht der Balken gesetzt wird?
Analog der Monatsbalken erst am 31. und vorher nichts?
Ja. So ist es bei last...-Readings gelöst. Die Werte werden erst am Ende des Tages gesetzt. Um genau zu sein:
Day muss irgendwann am Ende des Tages zurückgesetzt werden und zuvor in last_day gesichert werden. Ich mache das in der Definition eine Minute nach Mitternacht. Das hat den Vorteil, dass ich einfach erkennen kann, wann eine Periode (Tag, Monat, Jahr) zu ende ist und eine neue anfängt.
Damit last_day aber in der richtigen Periode landet, wird es mit -300 definiert (z. B. [...bar2month-300]), damit es 5 Minuten in die Vergangenheit gespeichert wird. day wird dagegen ohne Zeitverschiebung gespeichert. Es wird im ersten Diagramm dargestellt. Dort kann man, im Gegensatz zu last_day, die bisherige verbrauchte Menge des Tages erkennen.
Hi Damian,
ich habe den Fehler gefunden. Natürlich funktioniert es mit *.day im card und *.last_day in der get_data funktion. Der Fehler lag in der ZEitverschiebung von 300s in der Carddefinition. DIe muss man setzen wenn man last_day verwendet. Aber bei Nutzung von *.day darf diese nicht mit rein.
card([[PM_Solardach:power:col:$_ >= 0 ? $_ / 1000 : 0],[SEN_EM_Elektro:000_EM_All_usage:col:$_ >= 0 ? $_ / 1000 : 0]],"Energie",[PM_Solardach:power]>0?"sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,6,0,120,["PV","Netz"],undef,"2","130,,,,1,,210","0,0,0,0",undef,
[[DOIF_counter:PM_Solardach.Consumption.day],[DOIF_counter:PM_Solardach.Consumption.month],[DOIF_counter:PM_Solardach.Consumption.year]],0,0,0,120,["Day","Month","Year"],[(-10,0,-0.01,30,10,60,25,90)],"1,,fill:silver") |
card([DOIF_counter:PM_Solardach.Consumption.day:bar1month],"Solarenergie in kWh pro Tag","solar_icon",0,30,0,120,"kwh",undef,"0","130,,0,,1,,200","0,0,0,0") |
card([DOIF_counter:PM_Solardach.Consumption.month:bar2year],"Solarenergie in kWh pro Monat","solar_icon",0,600,0,120,"kwh",undef,"0","130,fixedscaling,,,1,,200","0,0,0,0") |
card([DOIF_counter:PM_Solardach.Consumption.year:bar2decade],"Solarenergie in kWh pro Jahr","solar_icon",0,3000,0,120,"kwh",undef,"0","130,fixedscaling,,,1,,200","gradient,nominmaxvalue,noinnerring,nopointer,minmax")
damit funktioniert es nun wie gewünscht. Jeder Tag wird sauber kwh für kwh hochgezählt und bleibt dann ab mitternacht sauber stehen :)
Zitat von: Tobias am 02 April 2023, 14:01:09damit funktioniert es nun wie gewünscht. Jeder Tag wird sauber kwh für kwh hochgezählt und bleibt dann ab mitternacht sauber stehen :)
Bis auf die Tatsache, dass bei day in der ersten Minute des neuen Tages noch der Wert des Vortages rein kommen kann, falls in dieser Minute ein Event vom Sensor kommt, danach wird er ja auf 0 gesetzt und ist nicht mehr sichtbar.
Zitat von: Damian am 04 April 2023, 18:50:54Zitat von: Tobias am 02 April 2023, 14:01:09damit funktioniert es nun wie gewünscht. Jeder Tag wird sauber kwh für kwh hochgezählt und bleibt dann ab mitternacht sauber stehen :)
Bis auf die Tatsache, dass bei day in der ersten Minute des neuen Tages noch der Wert des Vortages rein kommen kann, falls in dieser Minute ein Event vom Sensor kommt, danach wird er ja auf 0 gesetzt und ist nicht mehr sichtbar.
Stimmt, aber sicherlichbei PV zu Mitternacht vernachlässigbar.
Andere Frage:
im ersten Chart habe ich PV und Netzbezug zusammen damit ich die oberen 3 Halbkreise bekomme (du hattest ja gesagt das die Halbkreise erst kommen wenn 2 Werte im Vollkreis unten stehen)
Bekommt ich das irgendwie hin das die Linien von PV und Netz jeweils andere Farben und auch farbverläufe bekommen?
aktuell habe ich es so definiert:
card([[PM_Solardach:power:col:$_ >= 0 ? $_ / 1000 : 0],[SEN_EM_Elektro:000_EM_All_usage:col:$_ >= 0 ? $_ / 1000 : 0]],"Energie",[PM_Solardach:power]>0?"sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,6,0,120,["PV","Netz"],undef,"2","130,,,,1,,210","0,0,0,0",undef,
[[DOIF_counter:PM_Solardach.Consumption.day],[DOIF_counter:PM_Solardach.Consumption.month],[DOIF_counter:PM_Solardach.Consumption.year]],0,0,0,120,["Day","Month","Year"],[(-10,0,-0.01,30,10,60,25,90)],"1,,fill:silver") |
[url="https://forum.fhem.de/index.php?action=dlattach;attach=170411;type=preview;file"]Screenshot 2023-04-02 114205.png[/url]
Du kannst der Diagrammlinie eine feste Farbe vergeben (siehe Doku zu card). Sonst gibt es nur zwei mögliche Definitionen für Farbverläufe. Beide hast du wohl schon ausgeschöpft.
Ich habe es bei mir so gelöst, dass PV-Leistung, Einspeise-Leistung/Bezug (negativ) über eine Definition abgedeckt werden.
Ich habe da was gebastelt.
Man kann jetzt beliebige Werte mit beliebiger Formatierung zusätzlich zu den geplotteten Werten in einer card darstellen. Ebenfalls lassen sich jetzt Einheiten hinter dem Wert darstellen. Beispiel siehe Anhang.
Die Version wird bald eingecheckt.
card-unit.png
So kann man das neue Feature für Verbräuche (bar-Darstellung) nutzen.
Gasverbrauch.png
Und so sieht Tagesverlauf aus mit aktuellen Angaben zum Tag, Monat und Jahr.
Gas Tagesverlauf.png
Super!!!
Könntest du neben dem Bild auch immer noch die Definition mit reinschreiben? 🙏
Zitat von: Tobias am 08 April 2023, 19:08:08Super!!!
Könntest du neben dem Bild auch immer noch die Definition mit reinschreiben? 🙏
Ich teste noch etwas. Dann wird die Doku im Wiki mit den Beispieldefinitionen angepasst.
Neue DOIF-Version eingecheckt. Doku wurde angepasst.
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Darstellung_mehrere_Readingwerte_mit_und_ohne_Verlaufvisualisierung
Neue Features: eigene Formatierungsangaben pro Wert und Einheit hinter dem Zahlenwert siehe zweites Beispiel
Man kann jetzt auch Daten in der Zukunft der aktuellen Periode bei bars darstellen. Beispiel dazu siehe: https://forum.fhem.de/index.php?topic=132188.msg1272752#msg1272752
Damit könnte man ebenfalls prognostizierten Wetterdaten des aktuellen Tages, der Woche oder des Monats visualisieren.
Neue DOIF-Version eingecheckt.
Zitat von: Damian am 25 September 2022, 16:59:09Zitat von: schwatter am 25 September 2022, 15:48:32@Damian
Ok, Systemweit hat geholfen. Danke.
Noch eine Frage zur Card. Gibt es ein Autoresize für Card?
Gesetzt hab ich es so:
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,262")
Toll wäre es so:
card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,[color=red]auto[/color]")
Wegen verschiedener Devices (Handy,Tablet,Pc,...)
Gruß schwatter
Für alle Cards gelten die gleichen Default-Werte - das ist beabsichtigt, damit das Erscheinungsbild bei mehreren Cards einheitlich bleibt. Eine Auto-Funktion würde dazu führen, dass die Skalierungen (Schriftgröße, Höhe, Breite, usw.) unterschiedliche wären.
Nabend,
wie wäre es, die Größe an das attr plotsize von FHEMWEB zu verknüpfen? Grund, ich habe Handy, Tablet und PC.
Das sieht dann bei dem gleichen Raum unschön aus. Leider oder auch zum Glück (liegt immer im Auge des Betrachters)
wird bei FHEMWEB vieles geteilt und jede Webinstanz schaut (relativ) identisch aus.
Momentan habe ich extra Räume dafür eingerichtet...
Oder für DOIF ein extra attr, in dem die Webinstanz mit Größe angegeben werden kann.
z.b "attr cardsize WEBphone:480,200 Webtablet:1024,480 Webpc:1900,500"
Gruß schwatter
Du kannst bei card beim Parameter prop-size statt einer festen Größe eine abhängig von der aktuellen WEB-Instanz übergeben.
Ich habe die Visualisierung der Verbräuche angepasst, jetzt auch mit Stundenverlauf und Anzeige des aktuellen und letzten Verbrauchs in der Kopfzeile:
Ausgehend von dem Wiki-Beispiel: https://wiki.fhem.de/wiki/DOIF/Automatisierung#Tages-,_Monats-_und_Jahresstatistik_f%C3%BCr_Strom-,_Gas-,_Wasserz%C3%A4hler_und_andere_Z%C3%A4hler
habe ich die uiTable-Definition wie folgt angepasst:
{package ui_Table;} ## Optionale Visualisierung der Energie-Verbräuche/-Produktion im DOIF-Device
## Template für die Darstellung eines Wertes, einzelne card-Aufrufe können auskommentiert werden
DEF TPL_single (
##card([$SELF:$2.$3.day:col1w],"$1",undef,$4,$5,$10,$11,"$12",undef,"1","130,fixedscaling,,footer,noycolor,halfring,220","0,0,0,0,2")| Wochendarstellung
card([[$SELF:$2.$3.last_hour:bar2day-10],[$SELF:$2.$3.hour]],"$1 in $12/h",undef,$4/12,$5/12,$10,$11,["letzte","aktuell"],undef,"2","130,fixedscaling,,footer,noycolor,halfring,220","0,0,0,0,2")|
card([[$SELF:$2.$3.last_day:bar2month-300],[$SELF:$2.$3.day]],"$12/Tag",undef,$4,$5,$10,$11,["letzter","aktuell"],undef,"1","130,fixedscaling,,footer,noycolor,halfring,220","0,0,0,0,2")|
card([[$SELF:$2.$3.last_month:bar2year-300],[$SELF:$2.$3.month]],"$12/Monat",undef,$6,$7,$10,$11,["letzter","aktuell"],undef,"0","130,fixedscaling,,footer,noycolor,halfring,220","0,0,0,0,2")|
card([[$SELF:$2.$3.last_year:bar2decade-300],[$SELF:$2.$3.year]],"$12/Jahr",undef,$8,$9,$10,$11,["letzter","aktuell"],undef,"0","130,fixedscaling,,footer,noycolor,halfring,220","0,0,0,0,2")
)
## Template für die Darstellung von zwei Werten, einzelne card-Aufrufe können auskommentiert werden
DEF TPL_double (
##card([[$SELF:$3.$4.day:col1w],[$SELF:$6.$7.day:col1w]],"$1",undef,$8,$9,$14,$15,["$2","$5"],undef,"1","130,fixedscaling,,footer,noycolor,noring,220","0,0,0,0,2")| Wochendarstellung
card([[$SELF:$3.$4.last_hour:bar2day-10],[$SELF:$6.$7.last_hour:bar2day-10],[$SELF:$3.$4.hour],[$SELF:$6.$7.hour]],"$1/h",undef,$8/12,$9/12,$14,$15,["$2","$5","$2","$5"],undef,"2","130,fixedscaling,,footer,noycolor,noring,220","0,0,0,0,2")|
card([[$SELF:$3.$4.last_day:bar2month-300],[$SELF:$6.$7.last_day:bar2month-300],[$SELF:$3.$4.day],[$SELF:$6.$7.day]],"pro Tag",undef,$8,$9,$14,$15,["$2","$5","$2","$5"],undef,"1","130,fixedscaling,,footer,noycolor,noring,220","0,0,0,0,2")|
card([[$SELF:$3.$4.last_month:bar2year-300],[$SELF:$6.$7.last_month:bar2year-300],[$SELF:$3.$4.month],[$SELF:$6.$7.month]],"pro Monat",undef,$10,$11,$14,$15,["$2","$5","$2","$5"],undef,"0","130,fixedscaling,,footer,noycolor,noring,220","0,0,0,0,2")|
card([[$SELF:$3.$4.last_year:bar2decade-300],[$SELF:$6.$7.last_year:bar2year-300],[$SELF:$3.$4.year],[$SELF:$6.$7.year]],"pro Jahr",undef,$12,$13,$14,$15,["$2","$5","$2","$5"],undef,"0","130,fixedscaling,,footer,noycolor,noring,220","0,0,0,0,2")
)
## Die Visualisierung einer Tabellenzeile wird über die obigen beiden Templates vorgenommen, hier zeilenweise anpassen/löschen:
## Über das Template TPL_single wird jeweils pro card ein Wert visualisiert
## Überschrift,Device,Reading,minTag,maxTag,minMonat,maxMonat,minJahr,maxJahr,minColor,maxColor,Einheit
TPL_single (Frischwasser,MQTT2_DVES_C58DCB,total_w,0,500,0,10000,0,80000,90,0,Liter)
##TPL_single (Leitungswasser,counter_rw,total_l,0,500,0,10000,0,80000,90,0,Liter)
##TPL_single (Regenwasser,counter_rw,total_z,0,500,0,10000,0,80000,90,0,Liter)
TPL_single (Gas,MQTT2_DVES_C58DCB,total_gas,0,10,0,250,0,2000,90,0,m³)
TPL_single (Einspeisung,MQTT2_DVES_C58DCB,total_f,0,30,0,600,0,5000,0,90,kWh)
TPL_single (Bezug,MQTT2_DVES_C58DCB,total_c,-10,0,-300,0,-3000,0,0,90,kWh)
TPL_single (Stromkosten,di_tibber,costsSum,0,4,0,90,0,1200,90,0,€)
Das Ergebnis sieht dann wie im Anhang aus.
Edit: Das Wiki-Beispiel wurde entsprechend angepasst.
Zitat von: Damian am 06 Mai 2023, 19:29:04Du kannst bei card beim Parameter prop-size statt einer festen Größe eine abhängig von der aktuellen WEB-Instanz übergeben.
Ok, aber wie?
Doku sagt nur
<size>: Größe der der Karte, default = 130,
Den 2ten Parameter
<y-scaling>
hatte ich auch schon angewendet. Da sehe ich aber keine Besserung.
Wenn <size> von der Größe der Webinstanz zerrt, wie verhält sich dann <width> im Verhältniss zu <size>? Prozentual?
Bitte ein Beispiel.
Gruß schwatter
Wie heißen deine WEB-Instanzen vom TYPE FHEMWEB?
Die heißen WEB,WEBphone und WEBtablet.
Gruß schwatter
Beispiel
Wenn im Dummy size die Größe gespeichert ist dann kannst du beim card-Aufruf beim prop-Parameter diese wie folgt angeben:
card([bla:day:bar2day],[$SELF:avg]."Gasverbrauch in m³",undef,0,10,undef,undef,"m³",undef,"1",[?size].",fixedscaling,,,,halfring")
Du kannst auch irgendeine Perlfunktion statt [size] angeben, die dir die Größe der Grafik definiert.
Jetzt musst du noch herausfinden, wie man herausbekommt, welche aktive WEB-Instanz man gerade ist um size entsprechend zu belegen.
Wenn eine Perlfunktion z. B. aktuelle_Webinstanz die aktuelle Instanz liefert, dann könntest du es so angeben:
card([bla:day:bar2day],[$SELF:avg]."Gasverbrauch in m³",undef,0,10,undef,undef,"m³",undef,"1",(::aktuelle_Webinstanz() eq "WEB" ? 150: ::aktuelle_Webinstanz() eq "WEBphone"? 200 : 100).",fixedscaling,,,,halfring")
Beim Parameter size bleiben die Proportionen der Grafik erhalten.
Super,
das ist der richtige Hinweis. Ich habe in 01_FHEMWEB.pm geschmöckert und $FW_wname gefunden.
{ $FW_wname }
liefert sicher den Instanznamen.
Nur beim Einbau haperts noch bei mir. Klammerproblem? []
{package ui_Table;}
card([Pv_Total:SummPower:col12],undef,[Pv_Total:SummPower] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,2100,0,120,"PV W",undef,"1,font-size:50%",(::$FW_wname eq "WEB" ? 150: ::$FW_wname eq "WEBphone"? 200 : 100).",fixedscaling,,,,halfring")
Gruß schwatter
Du musst statt ::$FW_wname angeben $::FW_wname - das ist die korrekte Perlsyntax für Variablen aus dem package main.
Morgen,
super danke! Jetzt funktioniert es. Width hab ich auch mit angepasst. So bekomme ich endlich
auf allen Displays mein gewünschtes Format.
{package ui_Table;}
card([Pv_Total:SummPower:col12],undef,[Pv_Total:SummPower] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,2100,0,120,"PV W",undef,"1,font-size:50%",($::FW_wname eq "WEB" ? 200: $::FW_wname eq "WEBphone"? 140 : 300).",,,,,,".($::FW_wname eq "WEB" ? 480: $::FW_wname eq "WEBphone"? 260: 430))
Gruß schwatter
Zitat von: schwatter am 07 Mai 2023, 09:48:08Morgen,
super danke! Jetzt funktioniert es. Width hab ich auch mit angepasst. So bekomme ich endlich
auf allen Displays mein gewünschtes Format.
{package ui_Table;}
card([Pv_Total:SummPower:col12],undef,[Pv_Total:SummPower] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,2100,0,120,"PV W",undef,"1,font-size:50%",($::FW_wname eq "WEB" ? 200: $::FW_wname eq "WEBphone"? 140 : 300).",,,,,,".($::FW_wname eq "WEB" ? 480: $::FW_wname eq "WEBphone"? 260: 430))
Gruß schwatter
Schön, dass es wie gewünscht funktioniert. Vielleicht kann es der eine oder andere gebrauchen. Und das Beste ist, dass es mit bisherigen Mitteln klappt.
Statusbildschirm (erstes Bild rechts in der Einleitung) mit aktuellen card-Optionen aktualisiert:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg
Nabend,
heute ist mir aufgefallen, das es eine Wechselwirkung gibt. Problem zeigt sich, wenn mehr als ein Device gleichzeitig
auf verschiedene FHEMWEB's zugreift. At Home habe ich ein Tablet, welches per Fully Kiosk Browser auf Webtablet
eingeloggt ist. Logge ich mich von Unterwegs auf meinem Handy per Webphone ein, ist erst alles ok, dann aber nach dem
4 bis 5 poll springt die Anzeige auf verschiedene Größen. Vermutung, die Größen der 2 eingeloggten Devices kollidieren.
Nachdem ich beide Geräte direkt nebeneinander platziert habe, konnte ich es dann 100% bestätigen. Die Werte werden per
"longpoll" auf beiden FHEMWEB's aktualisiert. Ohne, passiert es nicht. Vielleicht hast du noch eine Idee, wie das
zu lösen wäre. Longpoll würde ich gerne beibehalten.
Gruß schwatter
Zitat von: schwatter am 31 Mai 2023, 19:55:15Nabend,
heute ist mir aufgefallen, das es eine Wechselwirkung gibt. Problem zeigt sich, wenn mehr als ein Device gleichzeitig
auf verschiedene FHEMWEB's zugreift. At Home habe ich ein Tablet, welches per Fully Kiosk Browser auf Webtablet
eingeloggt ist. Logge ich mich von Unterwegs auf meinem Handy per Webphone ein, ist erst alles ok, dann aber nach dem
4 bis 5 poll springt die Anzeige auf verschiedene Größen. Vermutung, die Größen der 2 eingeloggten Devices kollidieren.
Nachdem ich beide Geräte direkt nebeneinander platziert habe, konnte ich es dann 100% bestätigen. Die Werte werden per
"longpoll" auf beiden FHEMWEB's aktualisiert. Ohne, passiert es nicht. Vielleicht hast du noch eine Idee, wie das
zu lösen wäre. Longpoll würde ich gerne beibehalten.
Gruß schwatter
ja, ich konnte es nachvollziehen, die Aktualisierung über Websocket funktioniert nicht sauber, weil es keine eindeutige Zuordnung der spezifischen größenabhängigen Card zu WEB-Instanz gibt. Das muss ich mir genauer anschauen. Es erfordert auf jeden Fall eine Erweiterung der bisherigen der uiTable-Funktionalität.
Neue DOIF-Version eingecheckt siehe: https://forum.fhem.de/index.php?topic=134207.0
Mit
.DOIF_card:hover {transition: transform 0.3s ease; transform: scale(2.0); transform-origin: 0 0;z-index: 9999; position:relative}
im Css-Attribut des FHEMWEB-Devices kann man einen Vergrößerungseffekt von card erzielen, wenn man den Mauszeiger über eine card bewegt.
Dokumentation mit Beispielen folgt noch.
Ebenso lässt es sich für ring, bar und cylinder anwenden, dort heißen die Klassen DOIF_ring, DOIF_bar und DOIF_cylinder. Sollen alle DOIF-SVG-Grafiken eine Transformation erfahren, dann reicht die Angabe:
svg:hover {transition: transform 0.3s ease; transform: scale(2.0); transform-origin: 0 0;z-index: 9999; position:relative}
Wie es funktioniert siehe Animation dazu: https://forum.fhem.de/index.php?action=dlattach;attach=172147;image
Zitat von: Damian am 07 Mai 2023, 09:12:39Du musst statt ::$FW_wname angeben $::FW_wname - das ist die korrekte Perlsyntax für Variablen aus dem package main.
Könntest du das bitte mit dem $::xyz irgendwo an prominenter Stelle in deiner Hilfe platzieren? Ich bin ja auch darüber gestolpert. Vielleicht erspart dir das in Zukunft einige Fragen. 😇
Doku zu hover: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#SVG-Grafiken_beim_%C3%9Cberstreichen_mit_dem_Mauszeiger_vergr%C3%B6%C3%9Fern
Zitat von: mumpitzstuff am 10 Juli 2023, 19:20:06Zitat von: Damian am 07 Mai 2023, 09:12:39Du musst statt ::$FW_wname angeben $::FW_wname - das ist die korrekte Perlsyntax für Variablen aus dem package main.
Könntest du das bitte mit dem $::xyz irgendwo an prominenter Stelle in deiner Hilfe platzieren? Ich bin ja auch darüber gestolpert. Vielleicht erspart dir das in Zukunft einige Fragen. 😇
Ich habe die Syntax für Variablenangaben ergänzt: https://wiki.fhem.de/wiki/DOIF/Perl-Modus#Eigener_Namensraum%3A_DOIF
Hi,
ich habe mir einen Chart gebaut der mir die aktuelle PV Leistung von meinem WR anzeigt. Funktioniert!.
{
package ui_Table;
$TABLE='text-align:center;;';
}
card([PlenticorePlus8:_Leistung_WR:col],"Solar in kWh Tagesverlauf",[PlenticorePlus8:_Leistung_WR]>0?"sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,7.5,0,90,"kw",undef,"2","130,,,,1,,200","0,0,0,0")
Nun habe ich einen zweiten WR dazu bekommen und ich bekomme es nicht hin das Chart so umzubauen, das es die Summe beider PV-Leistungen zeigt.
PlenticorePlus8:_Leistung_WR
PlenticorePlus10:_Leistung_WR
Kann mir jemand einen Denkanstoss geben oder ein Beispiel zeigen?
Vielleicht mit #sum, in der Hilfe zu finden unter: Aggregieren von Werten.
Zitat von: Tobias am 25 Juli 2023, 17:35:04Nun habe ich einen zweiten WR dazu bekommen und ich bekomme es nicht hin das Chart so umzubauen, das es die Summe beider PV-Leistungen zeigt.
PlenticorePlus8:_Leistung_WR
PlenticorePlus10:_Leistung_WR
Kann mir jemand einen Denkanstoss geben oder ein Beispiel zeigen?
Ich würde im gleichen DOIF ein DOIF_Reading als Summe der beiden Readings definieren und dieses anzeigen.
Danke :)
damit klappt es...
defmod Chart_PlenticorePlus8 DOIF {};;
attr Chart_PlenticorePlus8 DOIF_Readings _Leistung_WR:[#sum:"^PlenticorePlus":"_Leistung_WR"]
attr Chart_PlenticorePlus8 DbLogExclude .*
attr Chart_PlenticorePlus8 room Photovoltaik
attr Chart_PlenticorePlus8 uiTable {\
package ui_Table;;\
$TABLE='text-align:center;;;;';;\
}\
card([$SELF:_Leistung_WR:col],"Solar in kWh Tagesverlauf",[$SELF:_Leistung_WR]>0?"sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,7.5,0,90,"kw",undef,"2","130,,,,1,,200","0,0,0,0")\
Zitat von: Tobias am 26 Juli 2023, 11:20:28Danke :)
damit klappt es...
defmod Chart_PlenticorePlus8 DOIF {};;
attr Chart_PlenticorePlus8 DOIF_Readings _Leistung_WR:[#sum:"^PlenticorePlus":"_Leistung_WR"]
attr Chart_PlenticorePlus8 DbLogExclude .*
attr Chart_PlenticorePlus8 room Photovoltaik
attr Chart_PlenticorePlus8 uiTable {\
package ui_Table;;\
$TABLE='text-align:center;;;;';;\
}\
card([$SELF:_Leistung_WR:col],"Solar in kWh Tagesverlauf",[$SELF:_Leistung_WR]>0?"sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,7.5,0,90,"kw",undef,"2","130,,,,1,,200","0,0,0,0")\
Das kann man so machen, allerdings würde ich bei zwei konkreten Readings diese einfach addieren. Bei #sum wird das System nach entsprechenden Devices jedes mal durchsucht, das kostet mehr Performance.
Bei mir überlappen sich die Beschriftungen bei card in der Fußzeile, woran kann das liegen?
2023-08-28 09_31_39-Home, Sweet Home — Mozilla Firefox.jpg
Ich habe mich schon erfolglos an den Parametern versucht, aber das ist unabhängig von <size> und <width> so unansehnlich.
Einfaches Beispiel mit konstanten Werten:
define DI.Anzeige.Test DOIF ##
attr DI.Anzeige.Test uiTable {package ui_Table;;;;$SHOWNOSTATE=1;;;;}\
card([[$SELF:l_1:col12],[$SELF:l_2:col12]],"Taupunkt","weather_humidity",5,20,130,280,["Garten","Keller"],undef,"1","190,,,,")
setreading DI.Anzeige.Test l_1 1
setreading DI.Anzeige.Test l_2 2
Die Schriftgröße variiert schon mal je nach System.
Du kannst in diesem Fall die Breite der Grafik etwas erhöhen.
Zitat$prop
# Eigenschaft von card: "<size>,<y-scaling>,<steps>,<footer>,<color_y_scale>,<ring>,<width>", optional
# <size>: Größe der der Karte, default = 130,
# <y-scaling>: "fixedscaling" (1), "autoscaling" (undef)
# <steps>: "steps" (1),"nosteps" (undef)
# <footer>: "footer" (undef),"nofooter" (1)
# <color_y_scale>: "ycolor" (undef), "noycolor" (1)
# <ring>: "ring" (undef), "noring" (0), "halfring" (1)
# <width>: Breite der Karte, default: 160[/td][/tr][/table]
es ist der letzte Parameter (default 160), z. B.
"190,,,,,,,180"
Zitat von: Damian am 28 August 2023, 11:28:55Die Schriftgröße variiert schon mal je nach System.
Mag sein, aber das Problem habe ich auf drei unterschiedlichen Systemen (Android, Win10, Win11) und Browsern (FF, Chrome, Edge).
Zitat von: Damian am 28 August 2023, 11:28:55Du kannst in diesem Fall die Breite der Grafik etwas erhöhen.
Hatte ich schon versucht, die Überlappung bleibt, nur ein paar Pixel weniger:
2023-08-28 11_38_17-Home, Sweet Home — Mozilla Firefox.jpg
width hat nur bis zum Wert von size einen Effekt, wenn ich size erhöhe, wird gleichmäßig skaliert, die Überlappung bleibt.
Über ein Style-SVG-Attribut wie beim decFontUnit Parameter kommt man da nicht ran, um die Schriftgröße anzupassen?
Was mir aber noch gerade auffällt: in den Beispielen im Wiki sind die Wochentage mit zwei Buchstaben abgekürzt ("Mo"), bei mir werden aber bei Type plot drei angezeigt ("Mon").
Interessanterweise ist es beim type bar immer 2-stellig, auch beir mir.
Das würde das Problem auch lösen, lässt sich das wo einstellen?
Ich habe mit "sudo raspi-config" die locale default auf "de_DE.UTF-8 eingestell.
Nach reboot sind dann doe Wochentage 2-stellig
Zitat von: KlaGho am 28 August 2023, 15:17:23mit "sudo raspi-config" die locale default auf "de_DE.UTF-8"
Danke für den Hinweis, der hat mich zur Lösung geführt: ich starte fhem jetzt mit gesetztem LC_ALL=de_DE.UTF-8
Den systemweiten default wollte ich nicht ändern, ich hab die locale erzeugt und dann /etc/systemd/system/fhem.service entsprechend um das Environment erweitert.
Hallo,
ich hoffe das passt hier her.
Seit gestern beschäftige ich mich mit den DOIF und der uiTable zur Visiualisierung, sieht wirklich klasse aus!
Leider werden plätzlich alle Grafiken nur noch in Schwarz-Weiß angezeig.
BYD.JPG
{package ui_Table;}
"BYDB-Box"| ring2([myBYDBox:BatteryPower],-10000,10000,120,0,"W",undef,undef,"1,font-weight:normal",[myBYDBox:Battery_1_SOC],0,100,0,120,"%",undef,"1,font-weight:normal") |
ring2([myBYDBox:BatteryCurrent],-30,30,120,0,"A",undef,undef,"1,font-weight:normal",[myBYDBox:BatteryOutVoltage],300,400,0,120,"V",undef,"1,font-weight:normal") |
ring2([myBYDBox:Battery_1_MaxmVolt],2800,3500,120,0,"mV",undef,undef,"1,font-weight:normal",[myBYDBox:Battery_1_MinmVolt],2800,3500,0,120,"mV",undef,"1,font-weight:normal") |
ring2([myBYDBox:BatteryMaxTemp],10,30,120,0,"°C",undef,undef,"1,font-weight:normal",[myBYDBox:BatteryMinTemp],10,30,0,120,"°C",undef,"1,font-weight:normal")
Woran könnte das liegen?
Dies ist mir erst aufgefallenb nachdem ich diese Grafik erstellt habe.
BYD2.JPG
{package ui_Table;
sub floor_round {
my ($zahl)=@_;
return(POSIX::floor($zahl / 100) * 100);
}
sub ceil_round {
my ($zahl)=@_;
return(POSIX::ceil($zahl / 100) * 100);
}
sub color {
my ($zahl)=@_;
my $min = 2800;
my $max = 3600;
my $mid = 3000;
my $mid2 = 3400;
my $color_green = 120;
my $num = 0;
if($zahl >= $mid2)
{
$num = $zahl-$mid/$max-$mid * $color_green;
}
elsif($zahl < $mid)
{
$num = $zahl-$min/$min-$mid * $color_green;
}
elsif($zahl >= $mid)
{
$num = $color_green;
}
return($num);
}
}
cylinder_bars("BYD Modul 1",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_000],color([myBYDBox:Battery_1_VoltsperCell_000]),"0",
[myBYDBox:Battery_1_VoltsperCell_001],color([myBYDBox:Battery_1_VoltsperCell_001]),"1",
[myBYDBox:Battery_1_VoltsperCell_002],color([myBYDBox:Battery_1_VoltsperCell_002]),"2",
[myBYDBox:Battery_1_VoltsperCell_003],color([myBYDBox:Battery_1_VoltsperCell_003]),"3",
[myBYDBox:Battery_1_VoltsperCell_004],color([myBYDBox:Battery_1_VoltsperCell_004]),"4",
[myBYDBox:Battery_1_VoltsperCell_005],color([myBYDBox:Battery_1_VoltsperCell_005]),"5",
[myBYDBox:Battery_1_VoltsperCell_006],color([myBYDBox:Battery_1_VoltsperCell_006]),"6",
[myBYDBox:Battery_1_VoltsperCell_007],color([myBYDBox:Battery_1_VoltsperCell_007]),"7",
[myBYDBox:Battery_1_VoltsperCell_008],color([myBYDBox:Battery_1_VoltsperCell_008]),"8",
[myBYDBox:Battery_1_VoltsperCell_009],color([myBYDBox:Battery_1_VoltsperCell_009]),"9",
[myBYDBox:Battery_1_VoltsperCell_010],color([myBYDBox:Battery_1_VoltsperCell_010]),"10",
[myBYDBox:Battery_1_VoltsperCell_011],color([myBYDBox:Battery_1_VoltsperCell_011]),"11",
[myBYDBox:Battery_1_VoltsperCell_012],color([myBYDBox:Battery_1_VoltsperCell_012]),"12",
[myBYDBox:Battery_1_VoltsperCell_013],color([myBYDBox:Battery_1_VoltsperCell_013]),"13",
[myBYDBox:Battery_1_VoltsperCell_014],color([myBYDBox:Battery_1_VoltsperCell_014]),"14",
[myBYDBox:Battery_1_VoltsperCell_015],color([myBYDBox:Battery_1_VoltsperCell_015]),"15") |
cylinder_bars("BYD Modul 2",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_016],color([myBYDBox:Battery_1_VoltsperCell_016]),"0",
[myBYDBox:Battery_1_VoltsperCell_017],color([myBYDBox:Battery_1_VoltsperCell_017]),"1",
[myBYDBox:Battery_1_VoltsperCell_018],color([myBYDBox:Battery_1_VoltsperCell_018]),"2",
[myBYDBox:Battery_1_VoltsperCell_019],color([myBYDBox:Battery_1_VoltsperCell_019]),"3",
[myBYDBox:Battery_1_VoltsperCell_020],color([myBYDBox:Battery_1_VoltsperCell_020]),"4",
[myBYDBox:Battery_1_VoltsperCell_021],color([myBYDBox:Battery_1_VoltsperCell_021]),"5",
[myBYDBox:Battery_1_VoltsperCell_022],color([myBYDBox:Battery_1_VoltsperCell_022]),"6",
[myBYDBox:Battery_1_VoltsperCell_023],color([myBYDBox:Battery_1_VoltsperCell_023]),"7",
[myBYDBox:Battery_1_VoltsperCell_024],color([myBYDBox:Battery_1_VoltsperCell_024]),"8",
[myBYDBox:Battery_1_VoltsperCell_025],color([myBYDBox:Battery_1_VoltsperCell_025]),"9",
[myBYDBox:Battery_1_VoltsperCell_026],color([myBYDBox:Battery_1_VoltsperCell_026]),"10",
[myBYDBox:Battery_1_VoltsperCell_027],color([myBYDBox:Battery_1_VoltsperCell_027]),"11",
[myBYDBox:Battery_1_VoltsperCell_028],color([myBYDBox:Battery_1_VoltsperCell_028]),"12",
[myBYDBox:Battery_1_VoltsperCell_029],color([myBYDBox:Battery_1_VoltsperCell_029]),"13",
[myBYDBox:Battery_1_VoltsperCell_030],color([myBYDBox:Battery_1_VoltsperCell_030]),"14",
[myBYDBox:Battery_1_VoltsperCell_031],color([myBYDBox:Battery_1_VoltsperCell_031]),"15") |
cylinder_bars("BYD Modul 3",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_032],color([myBYDBox:Battery_1_VoltsperCell_032]),"0",
[myBYDBox:Battery_1_VoltsperCell_033],color([myBYDBox:Battery_1_VoltsperCell_033]),"1",
[myBYDBox:Battery_1_VoltsperCell_034],color([myBYDBox:Battery_1_VoltsperCell_034]),"2",
[myBYDBox:Battery_1_VoltsperCell_035],color([myBYDBox:Battery_1_VoltsperCell_035]),"3",
[myBYDBox:Battery_1_VoltsperCell_036],color([myBYDBox:Battery_1_VoltsperCell_036]),"4",
[myBYDBox:Battery_1_VoltsperCell_037],color([myBYDBox:Battery_1_VoltsperCell_037]),"5",
[myBYDBox:Battery_1_VoltsperCell_038],color([myBYDBox:Battery_1_VoltsperCell_038]),"6",
[myBYDBox:Battery_1_VoltsperCell_039],color([myBYDBox:Battery_1_VoltsperCell_039]),"7",
[myBYDBox:Battery_1_VoltsperCell_040],color([myBYDBox:Battery_1_VoltsperCell_040]),"8",
[myBYDBox:Battery_1_VoltsperCell_041],color([myBYDBox:Battery_1_VoltsperCell_041]),"9",
[myBYDBox:Battery_1_VoltsperCell_042],color([myBYDBox:Battery_1_VoltsperCell_042]),"10",
[myBYDBox:Battery_1_VoltsperCell_043],color([myBYDBox:Battery_1_VoltsperCell_043]),"11",
[myBYDBox:Battery_1_VoltsperCell_044],color([myBYDBox:Battery_1_VoltsperCell_044]),"12",
[myBYDBox:Battery_1_VoltsperCell_045],color([myBYDBox:Battery_1_VoltsperCell_045]),"13",
[myBYDBox:Battery_1_VoltsperCell_046],color([myBYDBox:Battery_1_VoltsperCell_046]),"14",
[myBYDBox:Battery_1_VoltsperCell_047],color([myBYDBox:Battery_1_VoltsperCell_047]),"15") |
cylinder_bars("BYD Modul 4",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_048],color([myBYDBox:Battery_1_VoltsperCell_048]),"0",
[myBYDBox:Battery_1_VoltsperCell_049],color([myBYDBox:Battery_1_VoltsperCell_049]),"1",
[myBYDBox:Battery_1_VoltsperCell_050],color([myBYDBox:Battery_1_VoltsperCell_050]),"2",
[myBYDBox:Battery_1_VoltsperCell_051],color([myBYDBox:Battery_1_VoltsperCell_051]),"3",
[myBYDBox:Battery_1_VoltsperCell_052],color([myBYDBox:Battery_1_VoltsperCell_052]),"4",
[myBYDBox:Battery_1_VoltsperCell_053],color([myBYDBox:Battery_1_VoltsperCell_053]),"5",
[myBYDBox:Battery_1_VoltsperCell_054],color([myBYDBox:Battery_1_VoltsperCell_054]),"6",
[myBYDBox:Battery_1_VoltsperCell_055],color([myBYDBox:Battery_1_VoltsperCell_055]),"7",
[myBYDBox:Battery_1_VoltsperCell_056],color([myBYDBox:Battery_1_VoltsperCell_056]),"8",
[myBYDBox:Battery_1_VoltsperCell_057],color([myBYDBox:Battery_1_VoltsperCell_057]),"9",
[myBYDBox:Battery_1_VoltsperCell_058],color([myBYDBox:Battery_1_VoltsperCell_058]),"10",
[myBYDBox:Battery_1_VoltsperCell_059],color([myBYDBox:Battery_1_VoltsperCell_059]),"11",
[myBYDBox:Battery_1_VoltsperCell_060],color([myBYDBox:Battery_1_VoltsperCell_060]),"12",
[myBYDBox:Battery_1_VoltsperCell_061],color([myBYDBox:Battery_1_VoltsperCell_061]),"13",
[myBYDBox:Battery_1_VoltsperCell_062],color([myBYDBox:Battery_1_VoltsperCell_062]),"14",
[myBYDBox:Battery_1_VoltsperCell_063],color([myBYDBox:Battery_1_VoltsperCell_063]),"15") |
cylinder_bars("BYD Modul 5",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_064],color([myBYDBox:Battery_1_VoltsperCell_064]),"0",
[myBYDBox:Battery_1_VoltsperCell_065],color([myBYDBox:Battery_1_VoltsperCell_065]),"1",
[myBYDBox:Battery_1_VoltsperCell_066],color([myBYDBox:Battery_1_VoltsperCell_066]),"2",
[myBYDBox:Battery_1_VoltsperCell_067],color([myBYDBox:Battery_1_VoltsperCell_067]),"3",
[myBYDBox:Battery_1_VoltsperCell_068],color([myBYDBox:Battery_1_VoltsperCell_068]),"4",
[myBYDBox:Battery_1_VoltsperCell_069],color([myBYDBox:Battery_1_VoltsperCell_069]),"5",
[myBYDBox:Battery_1_VoltsperCell_070],color([myBYDBox:Battery_1_VoltsperCell_070]),"6",
[myBYDBox:Battery_1_VoltsperCell_071],color([myBYDBox:Battery_1_VoltsperCell_071]),"7",
[myBYDBox:Battery_1_VoltsperCell_072],color([myBYDBox:Battery_1_VoltsperCell_072]),"8",
[myBYDBox:Battery_1_VoltsperCell_073],color([myBYDBox:Battery_1_VoltsperCell_073]),"9",
[myBYDBox:Battery_1_VoltsperCell_074],color([myBYDBox:Battery_1_VoltsperCell_074]),"10",
[myBYDBox:Battery_1_VoltsperCell_075],color([myBYDBox:Battery_1_VoltsperCell_075]),"11",
[myBYDBox:Battery_1_VoltsperCell_076],color([myBYDBox:Battery_1_VoltsperCell_076]),"12",
[myBYDBox:Battery_1_VoltsperCell_077],color([myBYDBox:Battery_1_VoltsperCell_077]),"13",
[myBYDBox:Battery_1_VoltsperCell_078],color([myBYDBox:Battery_1_VoltsperCell_078]),"14",
[myBYDBox:Battery_1_VoltsperCell_079],color([myBYDBox:Battery_1_VoltsperCell_079]),"15") |
cylinder_bars("BYD Modul 6",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_080],color([myBYDBox:Battery_1_VoltsperCell_080]),"0",
[myBYDBox:Battery_1_VoltsperCell_081],color([myBYDBox:Battery_1_VoltsperCell_081]),"1",
[myBYDBox:Battery_1_VoltsperCell_082],color([myBYDBox:Battery_1_VoltsperCell_082]),"2",
[myBYDBox:Battery_1_VoltsperCell_083],color([myBYDBox:Battery_1_VoltsperCell_083]),"3",
[myBYDBox:Battery_1_VoltsperCell_084],color([myBYDBox:Battery_1_VoltsperCell_084]),"4",
[myBYDBox:Battery_1_VoltsperCell_085],color([myBYDBox:Battery_1_VoltsperCell_085]),"5",
[myBYDBox:Battery_1_VoltsperCell_086],color([myBYDBox:Battery_1_VoltsperCell_086]),"6",
[myBYDBox:Battery_1_VoltsperCell_087],color([myBYDBox:Battery_1_VoltsperCell_087]),"7",
[myBYDBox:Battery_1_VoltsperCell_088],color([myBYDBox:Battery_1_VoltsperCell_088]),"8",
[myBYDBox:Battery_1_VoltsperCell_089],color([myBYDBox:Battery_1_VoltsperCell_089]),"9",
[myBYDBox:Battery_1_VoltsperCell_090],color([myBYDBox:Battery_1_VoltsperCell_090]),"10",
[myBYDBox:Battery_1_VoltsperCell_091],color([myBYDBox:Battery_1_VoltsperCell_091]),"11",
[myBYDBox:Battery_1_VoltsperCell_092],color([myBYDBox:Battery_1_VoltsperCell_092]),"12",
[myBYDBox:Battery_1_VoltsperCell_093],color([myBYDBox:Battery_1_VoltsperCell_093]),"13",
[myBYDBox:Battery_1_VoltsperCell_094],color([myBYDBox:Battery_1_VoltsperCell_094]),"14",
[myBYDBox:Battery_1_VoltsperCell_095],color([myBYDBox:Battery_1_VoltsperCell_095]),"15") |
cylinder_bars("BYD Modul 7",floor_round([myBYDBox:Battery_1_MinmVolt]),ceil_round([myBYDBox:Battery_1_MaxmVolt]),"mV",undef,undef,undef,0,
[myBYDBox:Battery_1_VoltsperCell_096],color([myBYDBox:Battery_1_VoltsperCell_096]),"0",
[myBYDBox:Battery_1_VoltsperCell_097],color([myBYDBox:Battery_1_VoltsperCell_097]),"1",
[myBYDBox:Battery_1_VoltsperCell_098],color([myBYDBox:Battery_1_VoltsperCell_098]),"2",
[myBYDBox:Battery_1_VoltsperCell_099],color([myBYDBox:Battery_1_VoltsperCell_099]),"3",
[myBYDBox:Battery_1_VoltsperCell_100],color([myBYDBox:Battery_1_VoltsperCell_100]),"4",
[myBYDBox:Battery_1_VoltsperCell_101],color([myBYDBox:Battery_1_VoltsperCell_101]),"5",
[myBYDBox:Battery_1_VoltsperCell_102],color([myBYDBox:Battery_1_VoltsperCell_102]),"6",
[myBYDBox:Battery_1_VoltsperCell_103],color([myBYDBox:Battery_1_VoltsperCell_103]),"7",
[myBYDBox:Battery_1_VoltsperCell_104],color([myBYDBox:Battery_1_VoltsperCell_104]),"8",
[myBYDBox:Battery_1_VoltsperCell_105],color([myBYDBox:Battery_1_VoltsperCell_105]),"9",
[myBYDBox:Battery_1_VoltsperCell_106],color([myBYDBox:Battery_1_VoltsperCell_106]),"10",
[myBYDBox:Battery_1_VoltsperCell_107],color([myBYDBox:Battery_1_VoltsperCell_107]),"11",
[myBYDBox:Battery_1_VoltsperCell_108],color([myBYDBox:Battery_1_VoltsperCell_108]),"12",
[myBYDBox:Battery_1_VoltsperCell_109],color([myBYDBox:Battery_1_VoltsperCell_109]),"13",
[myBYDBox:Battery_1_VoltsperCell_110],color([myBYDBox:Battery_1_VoltsperCell_110]),"14",
[myBYDBox:Battery_1_VoltsperCell_111],color([myBYDBox:Battery_1_VoltsperCell_111]),"15")
Auch wenn ich das DOIF mit den Zellspannungen Lösche bleiben die anderen alle Schwarz.
Danke und Schöne Weinachten.
Gruß
Max
Möglicherweise hängt es mit deinem Style zusammen.
Bei mir sieht deine Definition korrekt aus.
Ich benutze den f18-Style.
Das hatte ich auch schon versucht, auch mit dem F18 funktioniert es nicht.
Ich habe noch ein 2. FHEM zum testen, da funktioniert es auch.
Gestern Nachmittag hat es auch geklappt aber nachdem ich das mit den Batterie Zellen gebastelt hatte waren die anderen anzeigen nur schwarz.
Bei neu laden im Browser wird alles kurz farbig und dann ist es dunkel.
Leg dir das DOIF in einen separaten Raum und schau dann noch mal. Es kann nämlich sein, dass sich HTML-Definitionen gegenseitig beeinflussen, die auf einem Bildschirm dargestellt werden.
Ich habe das Problem auch mit anderen Darstellungen.
Das hier ist in einem ganz anderen Raum und auch nur noch schwarz.
{package ui_Table;}
icon_temp_hum_ring("temp_outside",[Wetterstation:temperature],[Wetterstation:humidity],undef,undef,150)|
icon_temp_ring ("temp_windchill",[Wetterstation:WindChill],undef,undef,150) |
icon_temp_ring ("temperature_humidity",[Wetterstation:Taupunkt],undef,undef,150) |
icon_ring2([Wetterstation:windSpeed_kmh] > 0 ? "wind".",1,0,0,".[Wetterstation:windDirectionDegree]:"no_wind",[Wetterstation:windSpeed_kmh],0,50,120,0,"km/h",150,undef,1,[Wetterstation:windGust_kmh],0,50,120,0,"km/h",undef,1) |
icon_ring2("weather_rain_gauge",[Wetterstation:rain_hour],0,10,180,270,"mm/h",150,undef,1,[Wetterstation:rain],0,50,180,270,"mm",undef,1)
Gruß Max
Hallo,
ich habe das Problem gefunden.
sub color {...}
Damit habe ich wohl den kompletten aufruf aller DOIF uiTable gekillt...
sub colorBYD {...}
funktioniert :)
Zitat von: MadMax am 26 Dezember 2023, 16:15:30Hallo,
ich habe das Problem gefunden.
sub color {...}
Damit habe ich wohl den kompletten aufruf aller DOIF uiTable gekillt...
sub colorBYD {...}
funktioniert :)
Mit color hast du wohl die color-sub aus dem package ui_Table überschrieben ;)
Ja so wird es gewesen sein.
Jedoch musste ich das ändern und erst nach einem Neustart war alles wieder normal.
Gelöscht hatte ich das ganze schon ohne neu zu starten.
Zitat von: MadMax am 26 Dezember 2023, 20:22:22Ja so wird es gewesen sein.
Jedoch musste ich das ändern und erst nach einem Neustart war alles wieder normal.
Gelöscht hatte ich das ganze schon ohne neu zu starten.
Vermutlich hätte ein "reload 98_DOIF.pm" auch geholfen.
Möglich, würde ich mal versuchen
Hallo zusammen,
zunächst einmal vielen Dank für die card Implementierung. Ich bin nun schon seit Wochen dran mein FHEM mal wieder aufzuräumen (Frühjahrsputz...) und statt das ich endlich mal Dinge entferne die ich schon gar nicht mehr nutze, probiere ich ständig neue Sachen aus. Wie nun zum Beispiel Card :)
Es gab aber leider ein Problem: Ich benutze den Flex Style und die Card Grafiken sind alle uuuuuunendlich klein (1.35 em um genau zu sein...). Da ich nun aber den Flex Style liebe habe ich mich mal auf Ursachenforschung begeben. Diese Mini Grafiken resultieren aus der flexstyle.css vom Flex:
/* Icons skalieren */
#content svg:not([id^=SVGPLOT]):not(.zw_nr), #content img.icon, #content .col2 img{
min-width: 1.35em;
max-width: 1.35em;
max-height: 1.35em;
margin-top: -0.25em;
margin-bottom: -0.1em;
vertical-align: middle;
}
Hiermit wird (unter anderem) alles was nicht SVGPLOT als id hat sehr klein gemacht. Unter anderem auch die Card...
Lösung:
#content svg:not([id^=SVGPLOT]):not(.zw_nr):not([class^=DOIF_card]), #content img.icon, #content .col2 img{
min-width: 1.35em;
max-width: 1.35em;
max-height: 1.35em;
margin-top: -0.25em;
margin-bottom: -0.1em;
vertical-align: middle;
}
Die class DOIF_card wird vom Skalieren ausgenommen :)
@Damian: Ich würde ja einen Pull request beim flex Style auf github machen, aber ich glaube nicht das das bearbeitet wird... Wenn du SVGPLOT in die id vom SVG an den Anfang schreibst, wäre es auch gefixt ;)
Gruß Desmo
Zitat von: desmoloch am 02 Januar 2024, 00:33:42@Damian: Ich würde ja einen Pull request beim flex Style auf github machen, aber ich glaube nicht das das bearbeitet wird... Wenn du SVGPLOT in die id vom SVG an den Anfang schreibst, wäre es auch gefixt ;)
Das könnte ich machen, allerdings kann ich nicht abschätzen, ob es danach ggf. irgendwo anders Nebenwirkungen gibt, da card dann als SVG_Plot deklariert wäre. Eleganter fände ich über die eindeutige Klasse zu gehen. Frag erst mal nach, ob man es dort nicht einbaut, zumal du nicht der erste bist, der cards im flex-Style verwenden möchte.
Hallo, kurze Frage, ist es möglich bei cylinder die Werte zu "stapeln". Also 2kWh Akku, 10kWh PV 10 kWh Netz und alle übereinander so das ich dann insgesamt aug 22kWh komme.
Gruß Max
Zitat von: MadMax am 11 Januar 2024, 16:39:54Hallo, kurze Frage, ist es möglich bei cylinder die Werte zu "stapeln". Also 2kWh Akku, 10kWh PV 10 kWh Netz und alle übereinander so das ich dann insgesamt aug 22kWh komme.
Gruß Max
ja, mit cylinder_s siehe:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#3d-Balkendarstellung_mehrerer_Zahlenwerten_mit_Hilfe_der_universellen_SVG-Funktion_cylinder/cylinder_s
Klasse Danke,
das hatte ich ich leider übersehen.
Gruß
Max
Wenn man mit card etwas ausprobiert, können schon mal versteckte Daten in Vergessenheit geraten.
Es gibt zwar DOIF_delete_card_data, aber da muss man noch alle Parameter wissen.
Ein DOIF_list_card_data wäre nicht schlecht, um Leichen zu finden
oder verschwinden derartige Daten bei einem Neustart automatisch?
Zitat von: jkriegl am 12 Januar 2024, 18:32:04Wenn man mit card etwas ausprobiert, können schon mal versteckte Daten in Vergessenheit geraten.
Es gibt zwar DOIF_delete_card_data, aber da muss man noch alle Parameter wissen.
Ein DOIF_list_card_data wäre nicht schlecht, um Leichen zu finden
oder verschwinden derartige Daten bei einem Neustart automatisch?
Leichen verschwinden nach dem Booten von alleine. delete_card_data ist vielmehr dafür gedacht, in einer bestehenden Card (deren Definition in der Tabelle noch existiert) Daten zu löschen.
Beziehe mich auf die Antwort https://forum.fhem.de/index.php?msg=1225438 (https://forum.fhem.de/index.php?msg=1225438) #294
Scheinbar gibt es den Wert für average z.B. <{avg_value}> nicht
Zitat von: jkriegl am 05 März 2024, 12:58:23Beziehe mich auf die Antwort https://forum.fhem.de/index.php?msg=1225438 (https://forum.fhem.de/index.php?msg=1225438) #294
Scheinbar gibt es den Wert für average z.B. <{avg_value}> nicht
{average_value} sollte funktionieren
Danke funktioniert.
Wie kann ich das Ergebnis noch runden?
ZitatPV_avg: ${[myCounter:PV_day:bar1week]}{average_value}
Habe mit sprintf und den notwendigen Klammern noch Probleme.
Edit: Hab es geschafft, aber die Klammern sind sehr kompliziert.
Zitat von: jkriegl am 05 März 2024, 16:48:26Danke funktioniert.
Wie kann ich das Ergebnis noch runden?
ZitatPV_avg: ${[myCounter:PV_day:bar1week]}{average_value}
Habe mit sprintf und den notwendigen Klammern noch Probleme.
Edit: Hab es geschafft, aber die Klammern sind sehr kompliziert.
ja, die geschweiften gehören nun mal zu Perl, die habe ich mir nicht ausgedacht :)
Hallo zusammen,
habe meine Wasseruhr mit Hilfe des AI on the edge digitalisiert. Die Werte werden auch übertragen, alledings teilweise negativ. Deswegen sieht der Chart sehr komisch aus:
Tagesgraphen.jpg
Auch im List des Graphen sehe ich die negativen Werte:
values:
-2348.129
-2348.129
-2348.129
-2348.129
0.401
-2348.129
0.458
0
0.011
0.089
-2348.587
0.121
0.157
-2348.587
0.294
0.379
0
0.008
0.008
-2349.008
0.138
0.161
0.202
0.227
0.26
0.395
0.461
0
0.094
0.101
0.114
0.279
0.399
0.477
-2349.472
0.651
-2349.472
0.682
0.021
0.044
0.044
0.153
-2350.155
0.465
-2350.155
0.572
-2350.155
0.71
0.001
0.018
0.101
0.124
-2350.866
0.183
-2350.866
0.26
0.27
0.339
0
0.02
0.12
0.183
0.199
0.241
Hat jemand eine Idee oder die gleichen Probleme, dass der Wasserzähler teilweise negative Werte liefert?
Gruß
Marco
Wenn das nur das Vorzeichen ist und die Zahl stimmt, dann reicht es ein DOIF_Reading (oder userReading) mit der abs-Perlfunktion auf den Zählerwert zu definieren und dann nur noch das DOIF_Reading für die Statistik anzugeben.
In dem Gerät ist aber kein negatives Reading, das ist das Komische...
Zitat von: marboj am 06 März 2024, 07:35:49In dem Gerät ist aber kein negatives Reading, das ist das Komische...
Dann schau mal was von dem Zähler geloggt wird, evtl. sind die Werte nicht immer aufsteigend.
Habe mal ein anderes Reading mit dem gleichen Inhalt zum testen genommen. Mal beobachten, was da passiert...
Hallo,
ist es möglich oder angedacht mit cylinder_bars die Min/Max Werte anzeigen zu lassen?
Also pro Balken?
Ich erfasse die als Reading, würde diese gerne noch mit darstellen.
Gruß
Max
Im Gegensatz zu card-Darstellung werden keine Statistiken bei cylinder_bars gemacht. Abgesehen davon wüsste ich nicht, wo man pro Wert noch zwei weitere Werte unterbringen soll.
Ich wollte bei card-Balken-Darstellung gestapelte Werte ermöglichen. Dort gibt es ja bereits schon min/max/Durchschnitt.
Mein Gedanke war so aber ohne die Min/Max Werte als Text mit anzuzeigen.
ja, die Idee ist gut, muss man nur noch programmieren :) Weiß aber nicht, wann ich dazu komme.
Kein Stress, ist nur eine Idee eventuell hast du ja mal Zeit und Lust dazu ;)