[Testversion] Heating_Control=>WeekdayTimer

Begonnen von Beta-User, 03 Mai 2019, 17:12:11

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: amenomade am 05 Mai 2019, 10:33:13
steht aber doch in 98_WeekdayTimer.pm
Danke für den Hinweis!
(Grummel, manchmal sollte man die cref vielleicht intensiver lesen ::) , sonst wäre mir ohne deinen Hinweis nicht aufgefallen, dass wir hier eine unnötige Doppelung haben, nur weil die Funktionen anders angeordnet sind als im HC-code... Ergo werde ich das so umbauen, dass für die set-Aufrufe diese Funktionsaufrufe genutzt werden, aber mit der neuen Option des gruppenweisen Aufrufens).

ZitatAber egal. Ich finde deine Lösung mit set Kommandos viel schöner als auf Perl wechseln zu müssen. Mehr in der Philosophie von Fhem :)
Vielleicht gibst du mir noch Rückmeldung zur Benennung? Kann mich da auch an dem vorhandenen "setParm" orientieren und statt global "all" zulassen, die Gruppe dann mit "WDT_group", damit es zum Attributnamen besser paßt?
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

amenomade

Ich mag "set <name> setTimer xxx" nicht, da es für mich nach (Zeit-)Timer, also Verzögerung, klingt.
"set <name> setParm xxx" ist m.M.n. in dem Sinn besser, aber set...set... naja...

Mir ist auch etwas wie "current" aufgefallen: "set <name> currentParm all|group|single" oder  "set <name> currentValue all|group|single" finde ich nicht schlecht

WDT_group ist OK

Warum soll ich aber der einzige sein, der eine Meinung hat? ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Hmmm, in der Regel lesen die meisten erst mal mit, bis ihnen was gar nicht gefällt.

Das mit setset fand ich auch nicht so prickelnd, das mit dem impliziten Hinweis auf den geltenen Parametersatz finde ich eigentlich ganz gut. Würde jetzt noch ein "apply" davor setzen (statt "set..."), und das ganze noch mit einer "Richtung" ergänzen, also:

set <name> applyCurrentParamsTo all|WDT_group|single
Werde etwas brauchen, bis das dann Eingang in die nächste Testversion findet, solange bleibt für dich bzw. die bisher nur Mitlesenden Zeit, noch was kreativeres vorzuschlagen :) .
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

eurofinder

Die Kombination
set <name> applyCurrentParamsTo all|WDT_group|single
finde ich schon etwas zu viel.

Wenn ich ein set-Kommando absetze, sollte klar sein, dass ich die aktuellen (current) Werte ändern (apply) will.

Daher mein Vorschlag:
set <name> WDT_Params all|WDT_group|single

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

Beta-User

Lesen ja doch noch andere hier mit :) ...

Kann mit dem neuen Vorschlag auch gut leben, hätte aber vielleich noch eine ganz andere Variante:
set <device> switchInThePast (this|WDT_group|TYPE)

Ist zwar auch lang, aber der Zusammenhang zwischen dem Attribut und dem setter wäre so evtl. durch den ersten Teil klarer. Der zweite Parametrierungsteil wäre dann noch etwas "sprechender"(?). Die Länge finde ich nicht so dramatisch, denn händisch eingeben wird man das sowieso in den seltensten Fällen (und ich mache grade mit eine ZWave-Schalter rum, da sind die Commands teilweise noch deutlich länger...).
Wer die Funktionalität benötigt, wird in der Regel sowieso in die cref und/oder das Wiki schauen bzw. das in FHEMWEB mal austesten, wo sich die Angebote aus den dropdowns ablesen lassen ::) .
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

amenomade


switchInThePast: ein set und ein Attribut mit gleichem Name finde ich eher irreführend (auch wenn es irgendwie ja eine Abhängigkeit gibt). Daher lieber die Variante von eurofinder.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

So,

Im ersten Beitrag gibt's ein aktualisiertes Modul, war dann am Ende gar nicht so dramatisch, das vollends aufzubohren.

Jetzt kann (=optional!) WeekdayTimer_SetAllParms()auch mit einem Gruppennamen aufgerufen werden, die set-Aufrufe ohne Perl entsprechen dem Vorschlag von eurofinder:

set <name> WDT_Params single|WDT_group|all

Wäre nett, wenn sich noch ein, zwei Tester finden würden :) .
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

Im ersten Post jetzt auch eine (hoffentlich finale) Fassung von Heating_Control.

Da gibt es ein neues "set" mit dem sich HC-Geräte einfach auf WeekdayTimer umstellen lassen, alle kommen dann in eine Gruppe, so dass sie auch zukünftig miteinander geschaltet werden können.

Der Anwender muß dann nur seinen Code durchsuchen, ob er irgendwo die Perl-Aufrufe aus HC nutzt. Das läßt sich leider nicht so einfach automatisiert umstellen.

Danach das "save" nicht vergessen...

Rückmeldung wäre nett, ansonsten gehe ich davon aus, dass das ganze recht unproblematisch ist und checke das bei Gelegenheit ein :) .
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

maseb

Hallo,

ich habe mir die Testversion von WeekdayTimer installiert.

Bei einem WeekdayTimer Device erhalte ich im LOG eine Fehlermeldung

2019.05.11 15:56:34 3 : [HZ_WZ_2] TYPE 'dummy' of CUL_FHTTK_9b6e10 not yet supported, CUL_FHTTK_9b6e10 ignored - inform maintainer

Das ist ein FS20 Fenster Sensor der über FHEM2FHEM angeschlossen ist und als attr HZ_WZ_2 WDT_delayedExecutionDevices angelegt ist.

Kann man da etwas machen?

Grüße
Rudi
CUL mit EM 1000 S/IR und EM 1000 HSM

Beta-User

@all zur Info:

Da bisher keine kritischen Rückmeldungen kamen, habe ich die beiden Module eben in's svn geladen, die kommen also morgen via update.

Für das Ausphasen des HC habe ich noch keinen Zeitplan.





Zitat von: maseb am 11 Mai 2019, 16:03:29
Das ist ein FS20 Fenster Sensor der über FHEM2FHEM angeschlossen ist und als attr HZ_WZ_2 WDT_delayedExecutionDevices angelegt ist.
Frage: war das vorher ein HC-Device, das mit dem dummy-FK "konnte" (dürfte eigentlich auch vorher nicht gegangen sein), oder ist das ein feature request?

Im Moment sollte es anders gehen: über eine Perl-Funktion im entsprechenden Attribut.

Was ich gerne noch machen würde, wäre die "Devices"-Sektion mit entsprechenden (vereinfachten) Abfragemöglichkeiten zu ergänzen. Das kann aber etwas dauern...
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

maseb

Ja das war vorher ein HC Device. Mit diesem lief das dummy als attr WindowSensor.

Jetzt mit WeekdayTimer eben nicht mehr.

ZitatIm Moment sollte es anders gehen: über eine Perl-Funktion im entsprechenden Attribut.

Kannst du mir verraten wie..

Grüße
Rudi


CUL mit EM 1000 S/IR und EM 1000 HSM

Beta-User

Ich habe eben ins svn eine aktualisierte Version eingecheckt, die mit [Oo]pen.* in _state_ bei dummy-Geräten klarkommen sollte.

Da das bei dir ein FHTTK ist, kann es sein, dass f2f das auch nach Window (?) spiegelt, nicht in state. Dann bitte ein userreading anlegen, das Window-Events nach state doppelt.

Ansonsten sollte eigentlich ein
ReadingsVal("CUL_FHTTK_9b6e10","state","closed") =~ /open/
als delayedExecutionCond funktionieren.

Wenn das nicht klappt bitte die möglichen Readings bzw. Reading-Werte liefern (ggf. ein list).
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

ToKa

#27
Hi beta-user,

bin gerade dabei mein Heating_Control Devices auf das neue WeekdayTimer umzustellen. Zwei Dinge sind mir dabei aufgefallen bzw. funktionieren nicht:
1. Meine ReadingsGroup Devices, welche die Heating_Control Device verwendet haben, haben beim Umstellen den Bezug zum Device verloren. Kann man aber durch manuelles Ändern wieder herstellen.
2. Das Alias Attribut wird nicht übernommen. Aber auch manuell leicht wieder ergänzbar.
3. Ich habe in meinen Heating_Control Devices eine stateFormat Anweisung verwendet, mit der die neue Version von WeekdayTimer Probleme hat.

{\
my $cValue = ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","currValue","");;\
my $idx = index($cValue,":");;\
if ($idx != -1) {\
$cValue = substr($cValue,0,$idx);;\
}\
my $nValue = ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","nextValue","");; \
$idx = index($nValue,":");;\
if ($idx != -1) {\
$nValue = substr($nValue,0,$idx);;\
}\
return "nächste Schaltung: ".ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","nextUpdate","")." ".$cValue." ==> ".$nValue\
}


Die Fehlermeldung lautet:
Error evaluating E2_ez_THKV_Heizkoerper_Fenster_hC_01 stateFormat: Experimental aliasing via reference not enabled at (eval 14507) line 2.

Muss ich hier in meinem stateFormat was ändern oder muss hier im Modul noch etwas angepasst werden?

Beste Grüße und toll, dass Du die Module zusammenführst.
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

Beta-User

Zitat von: ToKa am 12 Mai 2019, 14:58:02
2. Das Alias Attribut wird nicht übernommen. Aber auch manuell leicht wieder ergänzbar.
Moin,
hast du mir etwas mehr Info zum Umfeld? Klingt danach, als wären es die Testersionen gewesen iVm. einem älteren FHEM? (Das FUUID noch nicht kennt, weswegen statt der FUUID in dem RAW-Array das erste Attribut rausgeworfen wird).

Zitat1. Meine ReadingsGroup Devices, welche die Heating_Control Device verwendet haben, haben beim Umstellen den Bezug zum Device verloren. Kann man aber durch manuelles Ändern wieder herstellen.
Danke für den Hinweis; läßt sich vermutlich auch nicht vollständig abfangen, wenn z.B. der Modultyp mit abgefragt wird oder das anders benannte Attribut.
Zitat3. Ich habe in meinen Heating_Control Devices eine stateFormat Anweisung verwendet, mit der die neue Version von WeekdayTimer Probleme hat.
Hmm, bist du sicher, dass das auf die Umstellung zurückzuführen ist, un dnicht z.B. auf einen update der Perl-Version? An sich hat HC intern eigentlich nur Funktionen aus WDT verwendet und (fast) alles war ansonsten gleich. Wenn es das mit dem Perl-update nicht ist, muß ich mir das mal ansehen...
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

majestro84

So haben dann auch mal von Heat Control umgestellt bis jetzt sieht alles gut aus.
Haben ein manuell umgestellt und das andere Heat Contol Device mit dem neuen set Befehl converttoWDT im Heat Control hat super funtioniert.
Vielen Dank
Alex
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT