[erledigt] valuestyle und valueformat _ verständnisproblem

Begonnen von the ratman, 02 August 2017, 17:31:23

Vorheriges Thema - Nächstes Thema

the ratman

hiho,
ich will mir ne batterieübersicht basteln.
dazu sammel ich mal meine batterien mit.*:FILTER=TYPE!=ZWave|netatmo:battery
.*:userBattery
.*:battery_percent
.*:powerLevel
funzt
nun bastel ich mir %_balken mitvalueStyle
style="width:200px; text-align:center; border: 1px solid #ccc; background:-webkit-linear-gradient(left, green $VALUE%, red)"
funzt
da ich sensoren hab, die nur low und ok liefern, bau ich nochvalueFormat
{
return "10" if( $VALUE eq "low" );
return "100" if( $VALUE eq "ok" );
}
nicht gut.
die anzeige solcher sensoren steht zwar richtig geschrieben, aber ich krieg keine balken.

was mach ich falsch?

nochmals alles zusammen:defmod moRat_Batteriewaechter_test readingsGroup .*:FILTER=TYPE!=ZWave|netatmo:battery\
.*:userBattery\
.*:battery_percent\
.*:powerLevel
attr moRat_Batteriewaechter_test DbLogExclude .*
attr moRat_Batteriewaechter_test alias Batteriestatus TEST
attr moRat_Batteriewaechter_test mapping %ALIAS
attr moRat_Batteriewaechter_test noheading 1
attr moRat_Batteriewaechter_test nolinks 1
attr moRat_Batteriewaechter_test notime 1
attr moRat_Batteriewaechter_test room Startseite
attr moRat_Batteriewaechter_test sortDevices 1
attr moRat_Batteriewaechter_test valueFormat {\
return "10" if( $VALUE eq "low" );;\
return "100" if( $VALUE eq "ok" );; \
}
attr moRat_Batteriewaechter_test valueStyle style="width:200px;; text-align:center;; border: 1px solid #ccc;; background:-webkit-linear-gradient(left, green $VALUE%, red)"
→do↑p!dnʇs↓shit←

the ratman

→do↑p!dnʇs↓shit←

supernova1963

Keine konkrete Lösung!

Hast du mal versucht die Anführungszeichen um die 100 und 10 wegzulassen?

Gernot

the ratman

gute idee, funzt aber leider auch ned.
scheint ihm egal zuu sein, ob mit oder ohne ""
→do↑p!dnʇs↓shit←

supernova1963


the ratman

ändert nix.
die zahlen passen ja auch, siehe bild im 1. beitrag. alles auf 100, wies sein soll.
der valueFormat wird also richtig angewendet, der valueStyle greift aber nicht.
→do↑p!dnʇs↓shit←

supernova1963

Du hast recht. Das ist wahrscheinlich der Grund. ValueStyle verwendet nicht den Return-Wert von valueFormat.
Ich würde als nächstes versuchen ein UserReading an einem der betroffenen Devices anzulegen, dass die 10 bzw. 100 aus low bzw. OK ermittelt und dieses Reading hier in der Übersicht verwenden.

LG

Gernot

the ratman

das übersteigt mein können.
ich bräuchte - so denk ich mal - je ein dynamisch angelegtes userreading pro gerät. keinen schimmer, wie ich das machen kann.
einfallen würd mir da nur ein doif, das mir die userreadings einschießt, aber wie das aussehen müsste ... keinen schimmer.
→do↑p!dnʇs↓shit←

MadMax-FHEM

#8
Vielleicht noch die Idee (so mache ich das):

ich habe ein Notify welches auf alle (bei mir) möglichen Batteriewerte triggert und dann eine Sub in myUtils, die dann abhängig vom Gerät(etyp) bzw. Batteriewert (also "nur" ok oder low oder Spannungswerte oder schon Prozentangaben [z.B. ZWave]) eine Prozentangabe "bastelt/berechnet" (bei low->0 bei ok->100 bei Spannungswerten je nach max/min Spannung -> 0, 25, 75, 100 % und bei ZWave "einfach" das Prozentzeichen weg [ginge auch anders aber da ich die Funktion schon mal habe ;)  ]).
Die berechneten Werte schreibe ich dann in einen Dummy, d.h. für jedes Gerät ein Reading in Prozent (also als Zahl zwischen 0 und 100).

Das zeige ich mir dann in einer readingsGroup mit farbigen und je nach Prozent gefüllten Batterie-Icons an...

Vielleicht würde die Vorgegensweise ja auch für dich funktionieren.

Alternativ zum Dummy geht dann aber wohl auch ein userReading direkt in jedes Gerät und das dann anzeigen lassen.
(habe schon drüber nachgedacht aber da es so läuft wie ich will... ;)  )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

the ratman

wie gsagt: zu viel für den perl-noob.

ich hab aber mittlerweile ne andere idee: ich mißbrauch das knob-widget im command-teil eines readings. das funzt bei mir schon auch als windanzeige mit richtung, breite und stärke.
mal schauen, ob command mit valuStyle was anfangen kann.
→do↑p!dnʇs↓shit←

supernova1963

Auch auf die Gefahr, dass ich einen Abriss von einen "Wissenden" erhalte, versuche ich mal laienhaft einen Lösungsansatz ungetestet und ohne Gewähr zu publizieren.
Viel mehr Perl als du im valueFormat verwendet hast, ist imo nicht notwendig (und kann ich auch nicht).
Probiere doch einfach mal an einem Device
(ersetze "[device]" durch deinen Device-Namen und "[OriginalbatterieStatus]" durch den Namen deines Readings, was den Batteriestatus "OK" oder "low" enthält):
attr [device] userreadings BatterieStatus { if ( [OrginalbatterieStatus] eq "low" )  { return 10} else { return 100}}
Meines Wissens nach wird das userReading bei jeder Statusänderung/-abfrage des Devices dann neu berechnet.
Danach mußt du noch den Filter in der readingsGroup entsprechend anpassen!

LG

Gernot


the ratman

das würd wohl funzen, aber dann wars das mit dynamischen anzeigen von devices bei mir. könnte ich gleich in der rg alle devices einzeln und händisch aufführen.

ich würd ungern von meiner suche nach devices.*:FILTER=TYPE!=ZWave|netatmo:battery\
.*:userBattery\
.*:battery_percent\
.*:powerLevel
weggehen
und wie ich so nen filter in ner readingsgroup baue, is mir ein rätsel.

und ganz ehrlich: eig. wollt ich eher mal wissen, warum attribute nicht mit anderen zusammen werkeln, oder wenigstens wissen, welches attribut vor welchem steh.
ich hab die ganze rg ja eig. schon am laufen, nur halt anstelle der balken mit verschiedenfarbigen svg's nach batteriestand. da funzt das auch alles problemlos. drum will mir ned in kopf, was da falsch rennt.
→do↑p!dnʇs↓shit←

supernova1963

Zitat von: the ratman am 13 August 2017, 09:39:50
... , aber dann wars das mit dynamischen anzeigen von devices bei mir ...
Wieso, wird doch genau, wie die Anderen, dynamisch ermittelt (Zeigt den Inhalt der Readings der Devices).
Zitat von: the ratman am 13 August 2017, 09:39:50
... könnte ich gleich in der rg alle devices einzeln und händisch aufführen.

ich würd ungern von meiner suche nach devices.*:FILTER=TYPE!=ZWave|netatmo:battery\
.*:userBattery\
.*:battery_percent\
.*:powerLevel
weggehen
und wie ich so nen filter in ner readingsgroup baue, is mir ein rätsel. ...
Mußt du imo garnicht, das userReading wird mit der gleichen Syntax gefiltert wie die Readings, die du schon hast.

.*:FILTER=TYPE!=ZWave|netatmo:battery\
.*:userBattery\
.*:battery_percent\
.*:powerLevel
.*:BatterieStatus

Zitat von: the ratman am 13 August 2017, 09:39:50
.. und ganz ehrlich: eig. wollt ich eher mal wissen, warum attribute nicht mit anderen zusammen werkeln, oder wenigstens wissen, welches attribut vor welchem steh.
ich hab die ganze rg ja eig. schon am laufen, nur halt anstelle der balken mit verschiedenfarbigen svg's nach batteriestand. da funzt das auch alles problemlos. drum will mir ned in kopf, was da falsch rennt.
Na dann, poste für andere Leser zusammengefaßt "deine Erkenntnisse" und kennzeichne im 1. Beitrag das Thema als [geklärt] bzw. [abgeschlossen].

the ratman

ZitatNa dann, poste für andere Leser zusammengefaßt "deine Erkenntnisse" und kennzeichne im 1. Beitrag das Thema als [geklärt] bzw. [abgeschlossen].
hab ja leider keine, trotz deiner mühen.

blöd bin ich auch noch.
dachte du willst die userreadings in der rg und nicht beim device anlegen *g*.
wobei das halt auch nicht sinn der sache sein kann ... bei x devices immer ein userreading anlegen und daran auch noch in nem jahr denken, wenn mal neue magnetkontakte oder so kommen.
→do↑p!dnʇs↓shit←

MadMax-FHEM

#14
Dann vielleicht halt doch noch mal die Variante mit dem Dummy von mir oben...

Letztendlich ist es nicht mehr perl als du schon hast, weil ich ja auch nur

setreading BatterieDummy DEVICENAME BERECHNETERBATTERIEWERT

(setreading Gerät Readingname Wert)

mache.

Über den notify bekomme ich den Gerätenamen der irgendein Batterie-Event gefeuert hat (da passt ja wahrscheinlich schon was du in deinem DOIF hast) und auch den Wert der gefeuert wurde (oder ich frage den halt beim Gerät [habe ich ja] ab) und schreibe dann nach einer "Berechnung", z.B. wenn "ok" dann BERECHNETERBATTERIEWERT=100 bzw. wenn "low" dann halt =0 usw. in den Dummy.
Der Readingname ist dann eben der Gerätename.
So habe ich pro Gerät einen Eintrag...

Ich berechne halt noch für diverse Homematic welche Spannungswerte liefern wieviel Prozent denn das noch sind und setze das dann auch im Dummy.
Und wie geschrieben "entferne" ich bei den ZWave Geräten noch das %-Zeichen (weil die liefern schon in Prozent aber halt mit dem Zeichen was meine readingsGroup nicht so mag, da keine "reine Zahl") und wie geschrieben könnte ich das auch anders (valueFormat etc.) machen aber da ich den Mechanismus schon habe einfach Abfragen, ob der Gerätetyp "Zwave" ist und dann wird eben der Teil für ZWave durchlaufen: entferne %-Zeichen...

Für Homematic wird auch je nach Typ entweder nur battery mit den Werten "ok" oder "low" genommen und dann eben 0 oder 100 draus...
...bei anderen Typen, die auch zusätzlich den Spannungswert liefern "berechne" ich mir halt einen Prozentwert...

Dann eine readingsGroup die mir alle Readings des Dummy anzeigt (weil da stehen ja nur die Geräte mit Batteriewerten drin) die kannst du ja dann formatieren wie du es willst (ich eben durch farbige Icons)...

Wenn neue Geräte dazu kommen dann landen die beim ersten senden des Batteriewertes automatisch im Dummy und damit automatisch in der reagingsGroup...
...sofern sie ein Batterie-Event schicken, welches für das erstellte Notify passt.
Aber solange kein neuer Gerätetyp mit neuer (exotischer) Batteriemeldung kommt/verwendet wird passt das dann ja...


Wenn du wissen willst, warum ein Attributergebnis nicht in einem anderen verwendet wird/werden kann, dann in den Code schauen ist ja open source oder gezielt danach fragen...


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)