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

Begonnen von Beta-User, 15 Februar 2019, 13:39:48

Vorheriges Thema - Nächstes Thema

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

WarBird

 ;D ich wieder...

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


    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   ;D

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

Zitat von: WarBird am 29 April 2022, 21:32:25
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!

Zitat
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.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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():

Zitat von: Beta-User am 03 Mai 2022, 07:44:35
[...] 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:
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":
sub myWinContactNotify {  #three parameters, last (timeout) is optional
[...]


Und dann der intern verzögert aufgerufene "ist noch offen?"-Code:
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 04 Mai 2022, 13:00:35
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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":
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":
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):
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":
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:
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!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files