ControlMode von HM-TC-CC setzen

[Guest]

Originally posted by: <email address deleted>

Hallo,

set controlMode (auto | manual | party)

benötigt eine Reihe von anderen, vorher gesetzten Parametern.

Martin hatte in einem anderen Post Folgendes vorgeschlagen:

###### Auszug aus Post
# Ich baue an einer Umstellung und bin noch am Basteln. Folgender Weg
funktioniert schon:
# Du hat einen TC mit allen 3 Kanaelen definiert - oder zumindest den
Climate Channel 02
#
# set TC getConfig   # die Aktuell laufenden Werte werden aus dem Device
gelesen - fuer alle Kanaele
#             # evtl warten bis reading ausgefuerhrt ist.
# set TC_Climate regSet MdTempReg AUTO
#
####################

Ich habe mir folgende Funktion in myUtils gebaut:

sub SetTCMode($$)
{
     my ($dev, $par) = @_;
     {fhem("set $dev displayTempUnit celsius")}    
     {fhem("set $dev displayTemp actual")}
     {fhem("set $dev decalcDay Wed")}
     {fhem("set $dev displayMode temp-hum")}
     {fhem("set $dev controlMode $par")}
 }

Das funktioniert, hat nur recht viele Befehle und CommandAccepted zur Folge.
Wie funktioniert das getConfig? Theoretisch müsste ich ja ein getConfig
ausführen und dann erst nach der Antwort den Befehl zum Ändern des
controlMode absetzen - oder übernimmt das CUL_HM bzw. HMLAN?

Wenn ja, würde die Funktion wie folgt funktionieren?

sub SetTCMode($$)
{
     my ($dev, $par) = @_;
     {fhem("set $dev getConfig")}    
     {fhem("set $dev controlMode $par")}
 }

Grüße,
Merhan

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Billy]

                                                         

Hallo Merhan

set controlMode (auto | manual | party)
> benötigt eine Reihe von anderen, vorher gesetzten Parametern.
>

Bei mir geht das auch ohne andere Parameter! Frage mich aber bitte nicht
wieso?

Ich setze einfach über die Weboberfläche z.B.
 set EG_WZ controlMode auto

 EG_WZ
actiondetect clear controlMode day-temp decalcDay desired-temp devicepair
displayMode displayTemp displayTempUnit getConfig getRegRaw getdevicepair
getpair night-temp pair party-temp raw regRaw regSet reset sign
statusRequest tempListFri tempListMon tempListSat tempListSun tempListThu
tempListTue tempListWed unpair virtual

 

das wars. Das Einzig störende ist dass bei mir dann der displayMode von
temp-hum auf displayMode temp-only umspringt!
Das könnte ich aber über ein Script abfangen.

Gruss
Billy

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo ihr beide,

Dieses umstaendliche Setzen ist immer dann notwendig wenn mehrere
Einstellungen in ein und dem selben Byte zu tun sind. FHEM muss erst die
Infos des gesamten Bytes habe um sauber 'einstellen' zu koennen. Es kommt
bei einigen Einstellungen vor. Ist also systembedingt.
Was macht FHEM:
- verbreitete Loesung ist, dass FHEM erst alle Daten vom User abfragt und
dann alles setzt. Die gesetzten Werte werden gespeichert. Wenn man sie
einmal eingegeben hat und gesaved hat sollte es funktionieren, einzelne
Werte zu aendern

- eine Alternative ist, die aktuellen Einstellungen aus dem Device zu lesen
und dies als Basis zu nehmen.  
  es gibt 2 Moeglichkeiten an die Parameter im Baustein zu kommen
a) Manche Bausteine schicke einen Teil der Parameter bei Aenderung an die
Zentral. Dies passiert autonom und ist nicht (einfach) steuerbar -
ausserdem unvollstaendig
b) die Parameter ALLER devices lassen sich KOMPLETT auslesen. getConfig
sollte dies bewerkstelligen und macht es auch recht gut.
Es gibt eine Satz kommandos in diesem zusammenhang die von Prinzip fuer
alle Bausteine funktionieren, auch fuer TC und VD. Ich habe sie Register
genannt, haette vielleicht device-settings sagen sollen.

"getConfig" liest quasi alle Einstellparameter aus dem Device. Dies
funktioniert imPrinzip bei allen Devices, auch TC

Man kann also
set getConfig: alle nicht-fluechtigen daten aus dem Device/channel auslesen
(peers/register/zuordnungen).
set regSet: Setzen eines Registerwerts

alle get-befehle geben dem User 'lesbare info' ueber deviceeinstellungen.
Die Daten werden nich aus den Device gelesen sondern aus den gespeicherten
Infos vom letzten Lesen! Also vorher ist ein getConfig ratsam
get regList : Darstellung aller Register, die FHEM dekodiert. Ein device
koennte noch mehr register haben...
get reg : Wert dieses Registers
get reg all: Ausgabe einer Tabelle aller Werte, die dekodiert werden
koennen und gueltig sind.

Im Gegensatz zu "attributen"  die meinst Einstellungen in FHEM betreffen
haben die Register das "Problem" dass sie "im device" gehalten werden.
Lesen/refreshen  der Werte ist immer eine 'aktion'. Vorteil ist, dass man
defacto sieht, was eingestellt ist, da es aus dem Device kommt. Falls etwas
bein schreiben scheif gegangen ist kann man den Inhalt verifizieren.

Warum ich so darauf herumreite: Der TC hat ein recht komplettes interface,
man kann fast alles einstellen auf dem "traditionellen" Weg. Aber fuer alle
andern Devices muss ich ein eigens Interface zimmern. Mit Registern ist das
Interface fuer alle gleich. Ich muss nur noch eingeben, wie ein Register
aussieht und schon kann alle 'device-settings' unterstuetzen.

Auch ueber Register muss ich die Bitmasken beruecksichtigen. Aber wenn ich
mit einem getConfig starte hat fhem alles, was es braucht und man kann
loslegen. Am schluss kann man wieder einmal ein getConfig machen.
Auch register unterschieden, ob ein wert 'gesetzt' wurde oder ob er
'bestaetigt' ist also  onTime "20s" oder onTime "set_20s" - analog der
state variable

Generell wird die Unterstuetzung der aktuellen Methode nicht eingestellt,
da sich zu viele daran gewoehnt haben. Aber ich werde fuer neuen Bausteine
nur die Register unterstuetzen.

Noch eins - was sind nicht-fluechtige parameter: Alles, was im HM-baustein
selbst nach 'stromausfall' erhalten bleibt. Dies sind nicht desired-temp
o.ae. - aber schon die temp-settings der ganzen Woche

So hoffentlich klaert das mehr, als es Fragen aufwirft.

Gruss
Martin


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com