widgetoverride kopiert sich sowohl in "setters" UND "getters" - falls das reading matched.
Das ist nicht immer gewünscht.
ich kann leider kein list mit dummy bieten,
daher ex KNX (du brauchst dafür keine HW) ohne widgetoverride:
Internals:
.FhemMetaInternals 1
DEF 14/7/252:dpt1
FIRSTGADNAME g1
FUUID 637547ae-f33f-0e08-e1a8-6678050c083078b2
FVERSION 10_KNX.pm:v5.1.0-s26815/2022-12-08
GETSTRING g1:noArg
IODev myF2F_KNXIO_MH_RPI_21
NAME knxdummy4
NR 270
SETSTRING on:noArg off:noArg g1:on,off,toggle
STATE ???
SVN 26815-1 2022-12-08 12:09:41
TYPE KNX
model dpt1
.attraggr:
.attrminint:
GADDETAILS:
g1:
CODE 0e7fc
GROUP 14/7/252
MODEL dpt1
NO 1
OPTION
RDNAMEGET getG1
RDNAMEPUT putG1
RDNAMESET setG1
SETLIST :on,off,toggle
GADTABLE:
0e7fc g1
READINGS:
2022-12-12 16:12:26 IODev myF2F_KNXIO_MH_RPI_21
Attributes:
set und get:
RPI10-FHEM> set knxdummy4 ?
unknown argument ? choose one of on:noArg off:noArg g1:on,off,toggle
RPI10-FHEM> get knxdummy4 ?
unknown argument ? choose one of g1:noArg
RPI10-FHEM>
soweit ok, jetzt will der user NUR die "setters" anpassen... - "getters" haben im KNX-Modul nie weitere param.
attr KNXdummy4 widgetOverride g1:on,off,toggle,blabla,foo
Die " unknown arguments...." ändern sich nicht, allerdings ist das widgetOverride sowohl im SET-cmd als auch im GET-cmd!
die harte Variantes das zu verhinden, (im FHEMWEB):
FW_pO FW_detailSelect($d, "set",
FW_widgetOverride($d, getAllSets($d, $FW_chash)));
FW_pO FW_detailSelect($d, "get",
#MH FW_widgetOverride($d, getAllGets($d, $FW_chash)));
getAllGets($d, $FW_chash));
ist nicht sehr backward kompatibel...
im Modul hab ich bisher keine option gefunden, das zu umgehen/verhindern, ich kann natürlich das get komplett wegmachen, aber das ist auch nicht im Sinn des Erfinders....
Vorschlag: nachdem "getters" im KNX-Modul immer mit :noArg spezifiziert sind, könnte man evtl. ein weiteres widget erfinden, z.b: noGetwidget..
l.g. erwin
PS: ich glaube mich zu erinneren, das das vor einiger Zeit nicht so war.....
...etwas "kompatibler" - dieser fix (01_FHEMWEB.pm):
sub
FW_widgetOverride($$)
{
my ($d, $str) = @_;
return $str if(!$str);
my $da = AttrVal($d, "widgetOverride", "");
my $fa = AttrVal($FW_wname, "widgetOverride", "");
return $str if(!$da && !$fa);
my @list;
push @list, split(" ", $fa) if($fa);
push @list, split(" ", $da) if($da);
foreach my $na (@list) {
my ($n,$a) = split(":", $na, 2);
$a = 'noArg' if ($str =~ /\b$n\b:noArg/g); #<<<<<<<<<<<<<<<<
$str =~ s/\b($n)\b(:[^ ]*)?/$1:$a/g;
}
return $str;
}
Idee: falls ein Modul-Author :noArg spezifiziert, rechnet er im code nicht damit, dass weitere parameter kommen...- auch wenn der user mittels widgetoverride das möchte.....
l.g. erwin
Ich habe jetzt widgetOverride mit dem optionalen Typ erweitert:
ZitatTo specify the widget for a specific type, use the name@type:modifier
syntax, where type is one of set, get and attr
Hallo Rudi,
danke, soeben getestet, funktioniert !
Ich muss mir überlegen, wie ich das als "Empfehlung" in der cmd-ref beschreibe... ;D
Technisch hätt ich jetzt auch die option, dass während Attr_FN im Modul zu forcieren, ....
Danke nochmals fürs implementieren!
l.g. erwin
Hallo,
ich bin jetzt dazu gekommen das aktuelle Modul FHEMWEB.pm zu installieren.
Ich habe bei mir einige Devices , bei denen ich das StateFormat nutze, um einige Werte farblich und von der Größe her, anzupassen.
Nach dem Update funktioniert das Stateformat nicht mehr, alle Werte werden im Standartformat angezeigt. Ist dieses Verhalten auch bei anderen aufgetreten?
Liebe Grüße Jörg
ZitatNach dem Update funktioniert das Stateformat nicht mehr, alle Werte werden im Standartformat angezeigt.
#1 Dieses Thema hat (soweit ich es verstanden habe) nichts mit stateFormat zu tun.
Themen-Entfuehrung wird hier nicht gerne gesehen.
#2 Fehlermeldungen der Art "Probleme nach update" sind nicht hilfreich, wenn man nicht weiss, was die alte Version war.
#3 Mir sind aktuell keine Probleme mit stateFormat bekannt.
#4 Um sinnvoll helfen zu koennen braucht man in diesem Fall ein Beispiel (Definition, Attribute, etc. ), woraus das Problem ersichtlich ist.
Wenn nicht offensichtlich, dann auch Beschreibung/Screenshot/etc, von dem, was man erwartet.
Danke für die schnelle Antwort.
Das "Verhalten" mit dem attr stateformat hängt bei mir unmittelbar mit der neuen Version von FHEWEB.pm zusammen. Ich habe die "alte" Version wieder eingespielt, und das "Fehlverhalten" ist weg. Daher war für mich der Zusammenhang gegeben. Ich melde mich später, wenn ich zurück bin, mit weiteren Informationen.
LG Jörg
Hallo,
...hier meine Beobachtung:
Beispiel-Definition eines Dummy mit stateFormat:
defmod do_3Tage_Messung_Statusinfo dummy
attr do_3Tage_Messung_Statusinfo group 1,3Tage_Steuerung
attr do_3Tage_Messung_Statusinfo room Hzg_Verbrauch_Steuerung,Hzg_Verbrauch_Übersicht
attr do_3Tage_Messung_Statusinfo stateFormat <div style="font-size:10px;; color:black;;" >time   Dat\
\
\
<div \
\
style="font-size:16px;; color:green;; " >state   </\
\
style="font-size:18px;; color:red;; " > Temp°C</\
\
div> \
\
<div style="font-size:13px;; color:black;; " >Hzg-Old:  oldstate </div>\
\
attr do_3Tage_Messung_Statusinfo webCmd .
attr do_3Tage_Messung_Statusinfo webCmdLabel 3Tage_Messung_Statusinfo
Darstellung vor dem Update der FHEMWEB.pm FVERSION 01_FHEMWEB.pm:0.269740/2023-01-06
Darstellung nach dem Update der FHEMWEB.pm FVERSION 01_FHEMWEB.pm:0.270890/2023-01-20
Liebe Grüße Jörg
...Sorry, hatte ich vergessen:
define do_3Tage_Messung_Statusinfo dummy
attr do_3Tage_Messung_Statusinfo group 1,3Tage_Steuerung
attr do_3Tage_Messung_Statusinfo room Hzg_Verbrauch_Steuerung,Hzg_Verbrauch_Übersicht
attr do_3Tage_Messung_Statusinfo stateFormat <div style="font-size:10px;; color:black;;" >time   Dat\
\
\
<div \
\
style="font-size:16px;; color:green;; " >state   </\
\
style="font-size:18px;; color:red;; " > Temp°C</\
\
div> \
\
<div style="font-size:13px;; color:black;; " >Hzg-Old:  oldstate </div>\
\
\
\
\
attr do_3Tage_Messung_Statusinfo webCmd .
attr do_3Tage_Messung_Statusinfo webCmdLabel 3Tage_Messung_Statusinfo
# FUUID 5c4375f0-f33f-c487-e98d-fb459f8c0ea25d9b
# FVERSION 98_dummy.pm:0.256060/2022-02-01
# NAME do_3Tage_Messung_Statusinfo
# NR 3303
# STATE <div style="font-size:10px; color:black;" >16:04   28.01.2023
#
#
#<div
#
# style="font-size:16px; color:green; " >EIN   </
#
# style="font-size:18px; color:red; " > -0.5°C</
#
#div>
#
#<div style="font-size:13px; color:black; " >Hzg-Old:  EIN </div>
#
#
#
#
#
# TYPE dummy
# READINGS:
# 2023-01-28 16:05:00 Dat 28.01.2023
# 2023-01-28 16:05:00 Temp -0.5
# 2023-01-28 16:05:00 oldstate EIN
# 2023-01-28 16:05:00 state EIN
# 2023-01-28 16:05:00 time 16:04
#
setstate do_3Tage_Messung_Statusinfo <div style="font-size:10px;; color:black;;" >16:04   28.01.2023\
\
\
<div \
\
style="font-size:16px;; color:green;; " >EIN   </\
\
style="font-size:18px;; color:red;; " > -0.5°C</\
\
div> \
\
<div style="font-size:13px;; color:black;; " >Hzg-Old:  EIN </div>\
\
\
\
\
setstate do_3Tage_Messung_Statusinfo 2023-01-28 16:05:00 Dat 28.01.2023
setstate do_3Tage_Messung_Statusinfo 2023-01-28 16:05:00 Temp -0.5
setstate do_3Tage_Messung_Statusinfo 2023-01-28 16:05:00 oldstate EIN
setstate do_3Tage_Messung_Statusinfo 2023-01-28 16:05:00 state EIN
setstate do_3Tage_Messung_Statusinfo 2023-01-28 16:05:00 time 16:04
FHEMWEB untersucht ein mehrzeiliges STATE Zeile fuer Zeile, ob ein passendes Icon fuer diese Zeile existiert.
Zu einem leeren String wurde (fehlerhaft) "" als IconName zurueckgeliefert, was seit der Aenderung neulich als gueltiger Icon akzeptiert wird.
Das wurde zu <img src=""> konvertiert, was keine Auswirkung hat, es sei denn es wird mitten in einem <div> Tag eingebaut, weil dieser auf mehrere Zeilen verteilt ist. Dass das HTML an sich nicht korrekt ist, tut sein uebriges dazu.
Ich habe jetzt die oben erwaehnte fehlerhafte Konvertierung von "" zu Icon gefixt, wodurch die Anzeige etwas besser geworden ist.
Ich empfehle
- fuer HTML Anzeige devStateIcon zu verwenden, stateFormat ist nicht fuer sowas da.
- die HTML Fehler zu beheben. Dazu als erstes jedes <div>..</div> auf eine Zeile schreiben.
:)...danke für die Hinweise!
Ich werde meine "stateFormat" dahingehend überarbeiten.
Ich wünsche noch ein angenehmes Rest- Wochende.
LG Jörg