HM-CC-RT-DN Clima-Kanal: FHEMWEB-devStateIcon u.a. Tools

[Beta-User]

Hallo zusammen,

bin grade dabei, mein UI etwas aufzuhübschen. Zielsetzung: Es soll keine andere UI genutzt werden, sondern möglichst mit FHEMWEB-Bordmitteln auszukommen sein. f18 sollte ja flexibel genug sein, um das dann auch auf unterscheidlichen Geräten darzustellen. Da meine Mitbewohner ggf. die Möglichkeit erhalten sollen, alle Geräte in ihren Räumen auch zu bedienen, sollte das ganze weg von der gerade für die HK-Thermostate üblichen Variante, das mit ReadingsGroup zu lösen.

Vorarbeiten:
Da in den "normalen" Räumen zukünftig nur noch die bedienbaren Geräte sichtbar sein sollen, habe ich allen anderen Krimskrams woanders hin geschoben, nämlich in diverse Unterräume des Raums Steuerung wie hier im Wiki und hier im Forumsbeitrag kurz beschrieben. 

Webdarstellung der RT's und WT's, insbesondere: das "Icon":
Leider haben die CUL_HM-Geräte häufig im allgemeinen und die HM-CC-RT-DN und HM-TC-IT-WM-W-EU im speziellen die Eigenart, ihre Informationen und Steuerungsmöglichkeiten über mehrere Untergeräte zu verteilen.
Dabei bin ich auf einen Beitrag des Modulautors von CUL_HM hier gestoßen, der seine HK-Thermostate auch nur über die Clima-Kanäle steuert. Da die desired-temp nur über diesen Kanal sinnvoll erreicht werden kann, und diese einstellbar sein sollte (templates werden nicht benötigt, der Rest geht anders, s.u.), wird eben nur dieser in der Raumansicht angezeigt. Auszugsweises Beispiel für einen RT (für einen WT geht das genauso mit dem Climate-Kanal):

Code Auswählen Erweitern

attr Thermostat_Esszimmer_Gang_Clima alias HK Esszimmer (Gang)
attr Thermostat_Esszimmer_Gang_Clima devStateIcon {devStateIcon_Clima($name)}
attr Thermostat_Esszimmer_Gang_Clima group Heizung
attr Thermostat_Esszimmer_Gang_Clima icon hm-cc-rt-dn
attr Thermostat_Esszimmer_Gang_Clima webCmd desired-temp
Es wird also für das devStateIcon Perl-Code aufgerufen. Dieser ist in der angehängten 99_myUtils_Homematic.pm enthalten und generiert - je nach Typ - "ein" devStateIcon, das aus mehreren Elementen besteht, die jeweils für sich wieder anklickbar sind und dann unterschiedliche Aktionen auslösen. Dargestellt und gesteuert werden nicht nur der Clima(te)-Kanal, sondern teilweise auch das Hauptdevice. Der einzige Nachteil, den ich bisher entdecken konnte: Werden Aktionen am Hauptdevice ausgelöst, dauert es uU. eine Zeitlang, bis "das" Icon sich aktualisiert hat, hier muß man ggf. einen Browser-refresh auslösen, damit das direkt angezeigt wird.

Elemente:
- Batteriesymbol: dynamisch nach batteryLevel; sind CMD_pending, erscheint ein anderes Symbol, bei NACK wird das dann rot. Wird eine Batterie angezeigt, löst ein Klick "getConfig" aus, ist was pending etc., erfolgt "clear msgEvents".
- Schloß: zeigt an, ob ein lokaler LockMode gesetzt ist (toggle zwischen den Modi)
- Modus: Schaltet zwischen Auto und Manual um.
- Ventilstand (RT) oder Programm (Weiterschalten) + Luftfeuchtigkeit
- Ist-Temperatur: Klick auf das Thermometer löst Boost-Modus aus

Sonstiges:
In der myUtils ist auch etwas Code enthalten, um einen einzelnen WT oder RT in den partyMode zu versetzen. Die Basis dazu kommt aus dem Wiki, der Aufruf ist jedoch anders und es sind zwei Varianten möglich:
- Einmal über die Angabe aller Elemente:

Code Auswählen Erweitern

{HM_TC_Holiday (<Thermostat>,"16", "14.02.19", "16:30", "15.02.19" ,"05:00")}
- oder über eine verkürzte Fassung:

Code Auswählen Erweitern

{easy_HM_TC_Holiday(<Thermostat>,"16" [,<startsec>,<Dauer in Sec>])}Angabe von Startsekunde und Dauer sind optional, es kann "now" für Startsekunde verwendet werden, dann wird sofort gestartet, ohne Angabe der Dauer wird dann für 3 (abgerundete!) Stunden der PartyMode aktiviert. "stop" als Startsec beendet den Partymode bei der nächsten regulären Datenübernahme vom RT.

Viel Spaß damit, Verbesserungsvorschläge sind selbstredend willkommen.

Beta-User

EDIT: Formatierung, PM jetzt mit commandref...
EDIT 2: Update der pm v.a. wg. commState
EDIT 3: Update für WeekdayTimer
EDIT 4: Generalisierterer Fenster-offen-Code

Statistik: ca. 55 Downloads Stand 11/2020 + 50 downloads bis 04/2022 + 8 05/2022

[Beta-User]

Hallo zusammen,

zum einen kurz die Info: der Code beinhaltet jetzt auch eine kleine commandref (engl).

Und weil's thematisch vielleicht ganz gut paßt, noch ein paar einfachere Dinge für CUL_HM-Gerätschaft. Bilder sind unten angefügt:

HM-LC-Bl1PBU-FM:
Das devStateIcon verursacht bei einem Jalousienstand in der oberen Hälfte eine Fahrt nach unten, sonst nach oben. Da mir das etwas wenig Steuerelemente waren, gibt es noch hoch und runter und einen Slider für alles dazwischen. Damit man leicher sehen kann, was offen und was zu ist, das ganze in der Brightness-Variante:

Code Auswählen Erweitern


attr Jalousie_Mitte cmdIcon on:fts_shutter_up off:fts_shutter_down
attr Jalousie_Mitte devStateIcon off:fts_shutter_up:up on:fts_shutter_down:down 9\d.*:fts_shutter_10:down 8\d.*:fts_shutter_20:down 7\d.*:fts_shutter_30:down 6\d.*:fts_shutter_40:down 5\d.*:fts_shutter_50:down 4\d.*:fts_shutter_60:up 3\d.*:fts_shutter_70:up 2\d.*:fts_shutter_80:up 1\d.*:fts_shutter_90:up 0\d.*:fts_shutter_100:up .*::control_centr_arrow_up
attr Jalousie_Mitte icon fts_shutter_updown
attr Jalousie_Mitte webCmd on:off:pct
attr Jalousie_Mitte widgetOverride pct:colorpicker,BRI,0,1,100

HM-PB-6-WM55:
Angezeigt wird die zuletzt gedrückte Taste mit

Code Auswählen Erweitern

attr Schalter_Spuele devStateIcon .*Btn_01.*:taster_ch6_1 .*Btn_02.*:taster_ch6_2 .*Btn_03.*:taster_ch6_3 .*Btn_04.*:taster_ch6_4 .*Btn_05.*:taster_ch6_5 .*Btn_06.*:taster_ch6_6
attr Schalter_Spuele icon it_remote

HM-LC-SW2-FM:
Da braucht man eigentlich gar nichts machen, einfach nur an dem Kanal-Device z.B. folgendes, das webCmd : schaltet dabei die Anzeige weiterer Elemente aus:

Code Auswählen Erweitern

attr Licht_Bad_Decke alias Licht Bad Decke
attr Licht_Bad_Decke group Licht
attr Licht_Bad_Decke icon FS20.off
attr Licht_Bad_Decke webCmd :

Auch damit ggf. viel Spaß!

[rrnetz]

sieht sehr gut aus.
wie bekomme ich die devstateicon farbig, meine sind weiss

[Beta-User]

Hallo und willkommen im Forum, rrnetz.

Die Icons sollten eigentlich - abgesehen von den Störfällen - dem allgemeinen Farbschema entsprechen. Das ist bei mir f18@dark.

@all: Ich habe den Code nochmal etwas erweitert, jetzt sollten für den "easy-Holiday/Party-Modus" auch weitere Zeitangaben funktionieren, Details in der cref.

[Beta-User]

Hallo zusammen,

nachdem jüngst der erste Z-Wave-Thermostat in meinem Zoo gelandet war und sowieso das Thema "weekprofile" anstand, ist jetzt die file im ersten Post noch um zwei Routinen erweitert worden, mit denem man zwischen HMinfo-konformen Formaten und weekprofile@useTopics konvertieren kann.

Da ich bisher nur eine "flache Struktur" hatte, bei der alle Profile in der tempList-File enthalten waren (und die Anwendungsfälle/zuordnungen dann via notify erfolgt sind) und das nicht wie im Wiki auf verschiedene "Topic"-Dateien verteilt war, hatte ich dazu einen etwas anderen Code genutzt, als jetzt im ersten Post enthalten ist. Da sind ein paar Dinge geändert, die sich in der Nachschau als verbesserungswürdig herausgestellt haben - feedback wäre also willkommen. Der hier gepostete sollte jetzt auch in der Lage sein,

- mehrere tempList-files aus dem Attribut bei HMinfo zu importieren, (die file-Namen sollten dann als Topics gesetzt werden), und
- beim Export aus weekprofile heraus dann für jeden Topic eine eigene File zu generieren.
Weiter ist gg. der Ausgangsversion die Benennung von Profil und Topic getauscht, mein anonymisierter Aufschrieb paßt daher in der Beziehung nicht mehr ganz, dürfte aber ggf. trotzdem interessant sein für diejenigen, die bisher nicht mit weekprofile gearbeitet haben:

Das Ausgangsnotify war (RAW):

Code Auswählen Erweitern

defmod n_BW_Ferientag notify BW_Ferientag  { Value("BW_Ferientag") ? \
fhem "set Thermostat_Wohnzimmer_.*_Clima tempListTmpl restore FHEM/99_tempList.cfg:Wohnzimmer_Ferien,\
set Thermostat_Esszimmer_.*_Clima tempListTmpl restore FHEM/99_tempList.cfg:Esszimmer_Ferien,\
set Thermostat_Buero_Clima tempListTmpl restore FHEM/99_tempList.cfg:Buero_Ferien,\
set Thermostat_EssZi_Climate regSet weekPrgSel prog2"\
: fhem "set Thermostat_Wohnzimmer_.*_Clima tempListTmpl restore FHEM/99_tempList.cfg:Wohnzimmer,\
set Thermostat_Esszimmer_.*_Clima tempListTmpl restore FHEM/99_tempList.cfg:Esszimmer,\
set Thermostat_Buero_Clima tempListTmpl restore FHEM/99_tempList.cfg:Buero,\
set Thermostat_EssZi_Climate regSet weekPrgSel prog1" }


Import von HMinfo zu meinem "Einheits-weekprofile"-Device namens "weekprofile":

Code Auswählen Erweitern

{hm_copy_HMInfoTowp("hm","weekprofiles")}
Umbenennungen (Achtung: topic- und profile-Namen sind im neuen Code getauscht):

Code Auswählen Erweitern


set weekprofiles copy_profile 99_tempList.cfg:Bad_OG Bad_OG:default
set weekprofiles copy_profile 99_tempList.cfg:Buero Buero:default
set weekprofiles copy_profile 99_tempList.cfg:Buero_Ferien Buero:Ferien
set weekprofiles copy_profile 99_tempList.cfg:Hobbyraum Hobbyraum:default
set weekprofiles copy_profile 99_tempList.cfg:Hobbyraum_Gast Hobbyraum:Gast
set weekprofiles copy_profile 99_tempList.cfg:Esszimmer Esszimmer:default
set weekprofiles copy_profile 99_tempList.cfg:Esszimmer_Ferien Esszimmer:Ferien
set weekprofiles copy_profile 99_tempList.cfg:Flur Flur:default

set weekprofiles copy_profile 99_tempList.cfg:Kinder_Ferien Kinder:Ferien
set weekprofiles copy_profile 99_tempList.cfg:Adam Kind1:default
set weekprofiles copy_profile 99_tempList.cfg:Berta_hinten Kind2_hinten:default
set weekprofiles copy_profile 99_tempList.cfg:Berta_vorne Kind2_vorne:default
set weekprofiles copy_profile 99_tempList.cfg:Caesar Kind3:default

set weekprofiles copy_profile 99_tempList.cfg:Schlafzimmer Schlafzimmer:default
set weekprofiles copy_profile 99_tempList.cfg:Wohnzimmer Wohnzimmer:default
set weekprofiles copy_profile 99_tempList.cfg:Wohnzimmer_Ferien Wohnzimmer:Ferien
set weekprofiles copy_profile 99_tempList.cfg:Zentrale_Esszimmer Esszimmer_WT:default

Das "allgemeine Kinder-Ferienprogramm" für alle ausrollen:

Code Auswählen Erweitern

set weekprofiles reference_profile Kinder:Ferien Kind1:Ferien
set weekprofiles reference_profile Kinder:Ferien Kind2_hinten:Ferien
set weekprofiles reference_profile Kinder:Ferien Kind2_vorne:Ferien
set weekprofiles reference_profile Kinder:Ferien Kind3:Ferien


weekprofile in den Thermostaten (bzw. im Clima-Kanal zuordnen):
check:

Code Auswählen Erweitern

list TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=chanNo=04
erforderliches userattr ergänzen:

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=chanNo=04 userattr weekprofile
weekprofile
Zuordnungen machen:

Code Auswählen Erweitern


attr Thermostat_Bad_OG_Clima weekprofile Bad_OG
attr Thermostat_Buero_Clima weekprofile  Buero
attr Thermostat_Hobbyraum_Clima weekprofile Hobbyraum
attr Thermostat_Esszimmer_Gang_Clima weekprofile  Esszimmer
attr Thermostat_Esszimmer_Wand_Clima weekprofile Esszimmer
[...]

notify ändern (RAW):

Code Auswählen Erweitern

defmod n_BW_Ferientag notify BW_Ferientag  { ReadingsNum('BW_Ferientag','state',0) ? \
fhem("set weekprofiles restore_topic Ferien,\
set Thermostat_EssZi_Climate regSet weekPrgSel prog2")\
: fhem("set weekprofiles restore_topic default,\
set Thermostat_EssZi_Climate regSet weekPrgSel prog1") }

Den WT habe ich erst mal noch nicht angefasst, das ist eigentlich auch ok mit den unterschiedlichen Programmen.

Bin jetzt mal gespannt, wie das so läuft...

Anm.: Das Verfahren ist vermutlich auch für all diejenigen interessant, die von CUL_HM auf HMCCU.* umstellen wollen/müssen, denn weekprofile kann auch mit diesem TYPE umgehen.


Wer die Möglichkeiten schätzt, die HMinfo bietet, um die Konsistenz der übertragenen Profile zu prüfen, wird ggf. eine Möglichkeit suchen, die von weekprofile ggf. geänderten Wochenpläne auch wieder zu exportieren. Auch dafür ist eine Routine enthalten, die allerdings auch nach dem Antesten angepaßt worden ist, damit die einzelnen Topics auch je eigene Dateien enthalten. Ist daher (nach der Änderung) ungetestet.

Da es jetzt auch noch um ein paar andere Dinge geht, ist der Thread-Titel jetzt angepasst.

Wie immer: Feedback ist willkommen...

[Beta-User]

Update: da weekprofile in topic:entity "denkt", waren meine "Tauschaktionen" grade verkehrt herum...

Wie dem auch sei, entsprechend angepaßter Code ist im ersten Beitrag zu finden, die Export-Funktion ist auch soweit getestet, und für den import habe ich testweise eine Schleife dazugebastelt, die bei mehreren entities in der Ausgangsfile das erste als Referenzprofil verwenden sollte. Feedback ist wie immer willkommen...

[Frini]

Morgen,
Danke für die Anregungen. Gefällt mir sehr gut.
Bei den Rollladen habe ich eine Frage. Wie kann ich denn das devStateIcon so darstellen, dass es bei erneuten drücken stoppt?
Irgendwie klappt es nicht.

[Beta-User]

Morgen,
Danke für die Anregungen. Gefällt mir sehr gut.

Danke für die Rückmeldung!

Was das mit dem Rollladen-stop angeht:
Das ist kein "intelligentes" devStateIcon, das erkennen kann, ob der Rollladen fährt. Dafür müßte man - so wie bei der ZWave-Variante oder dem RT-DN - Perlcode verwenden und das "motor"-Reading auswerten.
Wenn du Code liefern magst, baue ich das gerne ein .

Ansonsten könntest du auch einfach einen expliziten webCmd/cmdIcon-stop-Button ergänzen.
Ich hatte das früher mal drin, hab's aber nie benutzt, weil man ja bei der Bedienung über FHEMWEB auch immer den slider nehmen kann, um seinen Wünschen Ausdruck zu verleihen.

[WarBird]

Huhu,
also als erstes mal nen super Daumen nach Oben 
bin heut Abend über dein  Beitrag gestolpert und hab ach schon mein ganzes Haus umgemodelt, funktioniert soweit auch super, nur wenn ich bei den Heizkörper Stellern auf die "Boost" Funktion klicke, also die Temperaturanzeige, dann kommt immer folgende Fehlermeldung

Code Auswählen Erweitern

Unknown argument controlMode, choose one of getRegRaw getConfig:noArg getDevInfo:noArg inhibit:off,noArg,on reset:noArg regSet assignHmKey:noArg raw regBulk fwUpdate clear:msgErrors,noArg,msgEvents,rssi,attack,trigger,register,oldRegs,readings,all deviceRename burstXmit:noArg unpair:noArg sysTime:noArg

und ist es normal das auch bei den Heizkörper Stellern das Symbol für die Luftfeuchtigkeit angezeigt wird?

und ist es möglich die Icons noch farbig anzupassen? also grün gelb orange rot bei Batterie z.B. oder dem stellgrad des Ventiles?

Danke Schonmal Vorab und gute Nacht
Gruß Tobias

[Beta-User]

Moin.

Erst mal Danke für die nette Rückmeldung !

Was den controlMode angeht, müßte es in Zeile 133 z.B. so heißen:

Code Auswählen Erweitern

my $boostname = $TC ? $climaname : $climaname;
(Der Code ist an der Stelle dann ziemlich sinnfrei, ist eher erst mal ein hotfix).

Was Symbole angeht, sind bei mir RT-DN und WT unterschiedlich. Was hast du für ein Modell, und welchen Kanal nutzt du zur Anzeige (gedacht ist es bei den RT-DN für den Climate-Channel).

Farbe ginge pirinzipiell auch, aber das müßtest du dann selber reinknödeln, ich mag das nicht so bunt und nutze für Batteriewarnungen etc. sowieso hauptsächlich dann andere Mechanismen.

[WarBird]

 Huhu,
Danke für die schnelle Antwort!
Also den hotfix  hab ich rein gebastelt, aber bei mir war es Zeile 132,
Die hab ich dann ersetzt durch die neue,
Funktioniert aber soweit gut, zumindest auf die schnelle getestet und keine Fehlermeldung und der boost geht los 

Was das zweite angeht.... Naja es war spät und ich blind 
Was ich für das luftfeuchte Symbol gehalten hab war das für die Temperatur 
Dachte die grün markierten Werte und Symbole gehören zusammen und hab erst heute gesehen das die rot markierten ja viel besser passen und es dann auch alles Sinn ergibt 

Und das mit dem farblich anpassen ja ist Geschmacksache, ich finde es eben übersichtlicher bei mehreren um gleich zu sehen, da is ne Heizung an oder aus, da ein bisschen und dort läuft sie auf volle pulle...
Selber basteln würde ich es auch wenn du mir nen tip gibst wie, bin nämlich noch ziemlicher Neuling was das angeht, aber ich lerne schnell 

Vielen Dank
Gruß Tobias

[Beta-User]

Also den hotfix  hab ich rein gebastelt,

Update des "Gesamtwerks" ist im ersten Beitrag zu finden.

Selber basteln würde ich es auch wenn du mir nen tip gibst wie, bin nämlich noch ziemlicher Neuling was das angeht, aber ich lerne schnell 

Na ja, es wird eine bestimmte Perl-Funktion aufgerufen, und z.B. in Zeile 76 wird dann auch das Batterie-Symbol rot, wenn die Spannung unter 2.2V liegt. Das solltest du dir erst mal ansehen und verstehen, wie da der "String" insgesamt aufgebaut wird, dann beantworte ich gerne auch weitere Detailfragen.
Falls du "Spielmaterial" suchst: In mqtt2.template und Color.pm gibt es dann noch viele Beispiele, wie man mit Perl in devStateIcon "Multi-Icons" bastelt bzw. auch mal was einfärbt...

[WarBird]

So ich habe gebastelt 
Das batterie symbol funktioniert super...

Code Auswählen Erweitern


  #Battery
  my $batval  = ReadingsVal($name,"batteryLevel","");
  my $symbol_string = "measure_battery_";
  my $command_string = "getConfig";
  if ($batval >=3) {
    $symbol_string .= "100"
  } elsif ($batval >2.6) {
    $symbol_string .= '75@green'
  } elsif ($batval >2.4) {
    $symbol_string .= '50@yellow'
  } elsif ($batval >2.1) {
    $symbol_string .= '25@orange'
  } else {
    $symbol_string .= '0@red'
  };


Bei dem Stellrad des stellventiels gibt es 2 Varianten, die erste wie ich es gern gehabt hätte.... Funktioniert leider nicht ganz weil dann immer der Text angezeigt

Code Auswählen Erweitern


sani_heating_level_$actor_rounded@red

anstelle des Symbols

Code Auswählen Erweitern


    #my $humcolor = "";
    $symbol_string = "humidity";
    $ret .= " " . FW_makeImage($symbol_string,"humidity") . " $humval%rH";
  } else {
    my $actorval = ReadingsVal($name,"actuator","");
    my $actor_rounded = int (($actorval +5)/10)*10;
    $symbol_string = "sani_heating_level_";
if ($actor_rounded >95) {
      $symbol_string .= "100"
} elsif ($actor_rounded >75) {
      $symbol_string .= '$actor_rounded@red'
} elsif ($actor_rounded >50) {
      $symbol_string .= '$actor_rounded@orange'
} elsif ($actor_rounded >25) {
      $symbol_string .= '$actor_rounded@yellow'
} elsif ($actor_rounded >5) {
      $symbol_string .= '$actor_rounded@green'
} else {
      $symbol_string .= "0"
    };

und Variante 2 funktioniert allerdings habe ich damit nicht mehr die schöne Aufschlüsselung von dir mit den 10 verschiedenen möglichen Symbolen der Heizung....

Code Auswählen Erweitern


    #my $humcolor = "";
    $symbol_string = "humidity";
    $ret .= " " . FW_makeImage($symbol_string,"humidity") . " $humval%rH";
  } else {
    my $actorval = ReadingsVal($name,"actuator","");
    my $actor_rounded = int (($actorval +5)/10)*10;
    $symbol_string = "sani_heating_level_";
if ($actor_rounded >95) {
      $symbol_string .= "100"
} elsif ($actor_rounded >75) {
      $symbol_string .= '70@red'
} elsif ($actor_rounded >50) {
      $symbol_string .= '50@orange'
} elsif ($actor_rounded >25) {
      $symbol_string .= '20@yellow'
} elsif ($actor_rounded >5) {
      $symbol_string .= '10@green'
} else {
      $symbol_string .= "0"
    };

[Beta-User]

OK, dann ein "kleiner Schubs":

Dein Code:

Code Auswählen Erweitern

$symbol_string .= '$actor_rounded@red'
hat (ein bis) zwei "Macken":
- single quote => keine Extrapolation der Variablen (das ist schneller, daher ist mein Code zwischenzeitlich auch an den meisten Stellen mit single quotes...)
- Extrapolation der Variablen klappt auch bei double quotes nur, wenn die für Perl "abgrenzbar" sind. Manchmal muss man nachhelfen (hier gleich mit "ordnungsgemäßen" Semikolon am Zeilenende):

Code Auswählen Erweitern

$symbol_string .= "${actor_rounded}@red";

[WarBird]

Huhu 😗 ich schon wieder...
Also ich habe versucht nachzuvollziehen was du meinst aber ich bekomme es leider nicht so ganz umgesetzt,
Habe deinen Code eingesetzt dann sagt er mir beim speichern, Fehler weil ,, @red" nicht angelegt, oder so in der Art,
Und wenn ich statt ,," dann ,' nehme dann kommt zwar keine Fehlermeldung aber dafür dann wieder, wenn die Bedingung dafür erfüllt ist,  anstatt dem Symbol der Text

Code Auswählen Erweitern

sani_heating_level_$actor_rounded@red
Auch mit den Klammern habe ich Experimentiert (){} beides leider nicht von Erfolg gekrönt....
Und das semicolon muss doch erst ans Ende der ,,Code Zeile" oder? Weil die ,,Code Zeile" ja nur zwecks Lesbarkeit auf mehrere Zeilen aufgeteilt wurde oder bin ich dort auf dem Holzweg?
Vielen Dank
Gruß Tobias

[Beta-User]

...ah, sorry, da war doch was mit dem "@"....

Das ist für Perl eigentlich das Zeichen, dass hier eine Variable (Liste) kommt, die aber nicht definiert ist. Also entweder dieses Zeichen escapen, oder eben die Farbe getrennt anfügen (ohne Evaluierung).

Viel Spaß beim Dechiffrieren...

[WarBird]

  ich wieder...

also das erste war einfach und hat auch schon zum gewünschten ziel geführt 

Code Auswählen Erweitern


    my $actorval = ReadingsVal($name,"actuator","");
    my $actor_rounded = int (($actorval +5)/10)*10;
    $symbol_string = "sani_heating_level_";
if ($actor_rounded >95) {
$symbol_string .= "$actor_rounded\@purple"
} elsif ($actor_rounded >75) {
$symbol_string .= "$actor_rounded\@red"
} elsif ($actor_rounded >50) {
$symbol_string .= "$actor_rounded\@orange"
} elsif ($actor_rounded >25) {
$symbol_string .= "$actor_rounded\@yellow"
} elsif ($actor_rounded >5) {
$symbol_string .= "$actor_rounded\@green"
} else {
$symbol_string .= "$actor_rounded\@blue"
};
funktioniert super danke an dieser stelle vielmals dafür und vor allem auch für die Art und weise der Erklärung! Genau Das finde ich die beste weise der Hilfe, nämlich Hilfe zur Selbsthilfe, dadurch hab ich soooo viel gelernt, wesentlich besser als du setzt mir nur nen fertigen CODE vor, einfügen fertig. Klar kann das mal schnell helfen aber jetzt verstehe ich ihn besser und kann ihn auch selbstständiger an meine Bedürfnisse anpassen.
Find Ich Super   

das zweite klingt auch interessant aber habs noch nicht so ganz hinbekommen,
ich nehme an du meinst die Auswertung für das passende Symbol machen und dann das fertige Ergebnis im Anschluss einfärben oder?

Gruß Tobias

[Beta-User]

funktioniert super danke an dieser stelle vielmals dafür und vor allem auch für die Art und weise der Erklärung!

Danke für die nette Rückmeldung!

ich nehme an du meinst die Auswertung für das passende Symbol machen und dann das fertige Ergebnis im Anschluss einfärben oder?

Genau. Dann kann man z.B. das '@' auch separat per "concatenation" dazubasteln. Eigentlich sind da insgesamt sowieso zu viele "elsif" drin...
Vielleicht noch ein weiterführendes Stichwort: pah-Color (zu finden unter Color.pm): Das erlaubt gleitende Übergänge/Farbverläufe, ist aber etwas schwieriger zu durchschauen. (es gibt Beispielcode dazu auch in den "ebus-myUtils" zu MQTT2_DEVICE.)

[Beta-User]

...da ich jüngst mal wieder drüber gestolpert bin, dass in der myUtils ja noch was "vergraben" ist, im ersten Post ein update und eine kurze Erläuterung zu den Funktionen myWinContactNotify() und myTimeoutWinContact():

[...] habe dazu folgende Lösung im Einsatz - "leider" ist die CUL_HM-spezifisch, weil alle realen Kontakte eines Raumes/einer Gruppe von Heizkörpern jeweils zu einem "virtuellen" Device zusammengefasst werden. Den Teil müßte man auf ZWave anpassen. Was wie zusammengehört, ist über Attribute (userattr) festgelegt, und z.B. auch, wie lange gewartet werden soll, bis die "ist offen"-Reaktion erfolgen soll.

Ein notify für alle relevanten Fenster und Türen:

Code Auswählen Erweitern

defmod n_FK_TK_notify notify Fenster_.*:open|Fenster_.*:closed|Fenster_.*:tilted|Dachfenster_.*:open|Dachfenster_.*:closed|Terrassentuer_.Z:open|Terrassentuer_.Z:closed|Balkontuer:open|Balkontuer:closed|Haustuer:closed|Haustuer:open { myWinContactNotify ($NAME, $EVENT) }

Das ruft immer denselben Code auf, egal, ob geöffnet oder geschlossen gemeldet wird. Zuerst der "Initialcode":

Code Auswählen Erweitern

sub myWinContactNotify {  #three parameters, last (timeout) is optional
[...]


Und dann der intern verzögert aufgerufene "ist noch offen?"-Code:

Code Auswählen Erweitern

sub myTimeoutWinContact {
[...]

[...]

Habe das ganze jetzt noch erweitert, dass es im Prinzip auch mit WeekdayTimer-"geführten" Thermostaten klappen sollte (also dann auch nicht mehr beschränkt ist auf CUL_HM).

Wer das nutzen will, muss allerdings etwas in den Code sehen und für sich checken, ob das für die eigene Installation auch so paßt:
- Es passiert grundsätzlich nur was, wenn "Heizperiode" ist (bei mir (ausnahmsweise!) ein dummy).
- die virtuellen Kontakt-Kanäle sind (leider) per eventMap "eingedeutscht"
- die für den jeweiligen virtuellen Kontakt (bzw. WeekdayTimer) relevanten Angaben können/müssen per userattr festgelegt werden, sonst "weiß" der Code nicht, welcher echte Fensterkontakt zu welchem virtuellen Kanal gehört (bei WeekdayTimer kommt die Info aus dem "Verzögerungsdevice"-Attribut, bei dem ist dann aber anzugeben, was bei Fensteröffnung passieren soll, eventuelle Verzögerungen (ZWave) muss man händisch konfigurieren)

Prinzipiell ist das ganze so ausgelegt, dass man es im Prinzip beliebig kombinieren kann, ein "echter" Kontakt kann also für mehrere virtuelle Kontakte (oder WDT) als Auslöser verwendet werden, ein virtueller Kontakt kann mehrere Sensoren auf sich vereinen und selbstredend mit mehreren Thermostat-Geräten gepeert sein...

[Beta-User]

Wer das nutzen will, muss allerdings etwas in den Code sehen und für sich checken, ob das für die eigene Installation auch so paßt:
- Es passiert grundsätzlich nur was, wenn "Heizperiode" ist (bei mir (ausnahmsweise!) ein dummy).
- die virtuellen Kontakt-Kanäle sind (leider) per eventMap "eingedeutscht"

Dieser Teil ist jetzt angepaßt. Man kann mit dem im ersten Post angehängten Code die "Heizperiode" anders benannt haben und auch auf andere Readings/Readingwerte prüfen. Details sind in der commandref enthalten.
Das eventMap ist raus, man "muss" also die virtuellen Fenster-Kontakte im "default" betreiben...

[Beta-User]

Da hier jemand Bedenken hatte, dass das mit den "verzögerten und virtualisierten" Fensterkontakten ggf. schwer verständlich ist, hier mal kurz ein Beispiel, wie das in einem Raum bei mir aussieht:

Es gibt ein "virtuelles Mutter-Device":

Code Auswählen Erweitern

define Fake_Fenster_Buero CUL_HM 332216
attr Fake_Fenster_Buero .mId FFF1
attr Fake_Fenster_Buero IOgrp VCCU:CUL_CUL,mapleCUN1
attr Fake_Fenster_Buero commStInCh off
attr Fake_Fenster_Buero expert defReg,rawReg
attr Fake_Fenster_Buero model VIRTUAL
attr Fake_Fenster_Buero modelForce VIRTUAL
attr Fake_Fenster_Buero msgRepeat 0
attr Fake_Fenster_Buero subType virtual
attr Fake_Fenster_Buero webCmd virtual

An dem gibt es (u.a., s.u.) einen "virtuellen Fenster-Kanal":

Code Auswählen Erweitern

define Virtueller_FK_Buero CUL_HM 33221601
attr Virtueller_FK_Buero userattr myRealFK myTimeout myRealTempsensor
attr Virtueller_FK_Buero devStateIcon .*open:fts_window_1w_open@red:postEvent+closed .*closed:fts_window_1w@green:postEvent+open
attr Virtueller_FK_Buero model VIRTUAL
attr Virtueller_FK_Buero myRealFK Fenster_Buero_Ost,Fenster_Buero_Sued
attr Virtueller_FK_Buero peerIDs 2E7D4803
attr Virtueller_FK_Buero webCmd :


Dann gibt es mehrere (konkret 2) Fenster, einen in ZigBee (der aber auch "open" und "closed" in "state" meldet):

Code Auswählen Erweitern

define Fenster_Buero_Ost HUEDevice sensor 51  IODev=phoscon
attr Fenster_Buero_Ost devStateIcon open:fts_window_1w_open@red closed:fts_window_1w tilted:fts_window_1w_tilt
attr Fenster_Buero_Ost event-on-change-reading .*
attr Fenster_Buero_Ost model 902010/21B
attr Fenster_Buero_Ost timestamp-on-change-reading state,tampered


Und einen "echten HM":

Code Auswählen Erweitern

define Fenster_Buero_Sued CUL_HM 2BD93E
attr Fenster_Buero_Sued devStateIcon open:fts_window_1w_open@red closed:fts_window_1w tilted:fts_window_1w_tilt
attr Fenster_Buero_Sued model HM-SEC-RHS
attr Fenster_Buero_Sued peerIDs 00000000
attr Fenster_Buero_Sued subType threeStateSensor


Die Querbeziehung ergibt sich aus dem Attribut "myRealFK" - da stehen beide drin. Wird einer der beiden geöffnet (oder geschlossen), greift das gezeigte notify. Ist (jetzt konfigurierbar durch weitere Aufrufparameter, siehe commandref) "Heizperiode" angesagt, wird (ggf. nach einer Wartezeit für Stoßlüftungen, kurze Türöffnungen usw.) der obige virtualisierte Fensterkontakt "bewegt", also das "offen" (verzögert) bzw. "geschlossen" (gleich) an den Peer gesendet. (Selbstredend wird dabei für "geschlossen" gecheckt, ob _alle_ zu sind).

Man braucht für jeden Raum (bzw. jede Gruppe von gleichlaufenden Thermostaten) je ein separates "Mutterdevice"! Dieses Mutterdevice darf dann aber noch weitere Kanäle haben, die dürfen dann nur nicht "auf/zu" oä. senden. Was aber geht, wäre einen zweiten Kanal für einen virtualisierten Raumsensor anzulegen:

Code Auswählen Erweitern

define Fake_Fenster_Buero_Temp CUL_HM 33221602
attr Fake_Fenster_Buero_Temp userattr myRealTempSensor
attr Fake_Fenster_Buero_Temp icon sani_heating_temp
attr Fake_Fenster_Buero_Temp model VIRTUAL
attr Fake_Fenster_Buero_Temp myRealTempSensor Raumfuehler_Buero
attr Fake_Fenster_Buero_Temp peerIDs 2E7D4801
attr Fake_Fenster_Buero_Temp verbose 2
attr Fake_Fenster_Buero_Temp webCmd :

Falls es jemand interessiert:
In diesem Fall kommt der Temperaturwert von einem BTLE-Gerät, das via OpenMQTTGateway empfangen, von einem readingsWatcher auf Aktivität gecheckt und per notify dann auf den virtuellen Sensor übertragen wird (bzw. im Fall der erkannten Inaktivität wird der Wert gelöscht!)