HM-TC-IT-WM-W-EU: Funk-Wandthermostat

[CQuadrat]

Hallo Zusammen,

ich kann nicht beobachten, dass Templisten zwischen TC und RT in irgendeinerweise synchronisiert werden (Update ist aktuell).

Was ich aber beobachten kann ist folgendes - sicherlich nicht beasichtigtes - Verhalten:

• Situation: Templiste des TC weicht von Templiste des RT ab
• Ich schalte TC auf MANU -> RT geht auch auf MANU (auch im entsprechenden internen Register) -> so soll es wohl auch sein 
• Der RT übernimmt die am TC eingestellten Temperaturen (beide sind gepeert) -> so soll es wohl auch sein
• Ich schalte am TC auf AUTO -> RT geht auch auf AUTO (auch im internen Register) ->  das führt offensichtlich zu Problemen (siehe weiter)
• Jetzt wird es spannend: der RT reagiert jetzt auf alle Schaltpunkte beider Templisten des RT und des TC -> das kann so sicherlich nicht gewollt sein 
• Das heißt, unter diesen Voraussetzungen müssen die Templisten des RT und TC identisch sein.
• Alternativ (ich weiß nicht, ob das möglich ist): man muss den RT zwingen immer im MANU-Modus zu bleiben. Dann werden die Temperaturen vom TC übernommen (egal ob dort MANU oder AUTO eingestellt ist)

Viele Grüße

Christoph

[betateilchen]

Und ich kann beobachten, dass von meinem TC seit 21:18 Uhr keine Daten mehr in fhem ankommen...

[betateilchen]

ich finde übrigens die Kombi on/off am logischsten (und am besten zu vereinheitlichen, ohne bei jedem Register nachdenken oder nachlesen zu müssen)

Warum wundert es mich eigentlich in keinster Weise, dass jetzt in jedem Lock-Register das beschissene lock/unlock eingebaut wurde anstatt dem viel logischeren on/off?

Und wieso funktioniert es nicht wenigstens, wenn man es schon ändert?

(http://up.picr.de/17417580ww.png)

[martinp876]

Hi,

als aussenstehender ohne TC-IT:
das Verhalten und die Synchroisation ist in der FW realisiert - kann FHEM nicht aendern, bestenfalls damit umgehen. Das mit dem abarbeiten beider templisten im RT kann ich mir gut vorstellen, das passt gut in das allgemeine Verhalten.
Moeglichkeinten:
a) ManuMode
immer manu-mode benutzen => scheidet aus, macht keinen Sinn
b) AutoMode
templisten Synchen. Immer wenn am TC oder dem RT ein Wert in der Templiste geaendert wird, werden der TC und alle seine gepeerten RTs upgedated.
c)CheckMode
HMInfo checkConfig prueft, ob templisten von gruppierten RTs und TC/RTs identisch sind und wirft einen report bei Abweichungen
d)passivMode
die templiste des RT sollte disabled werden. Nicht ganz eiach, aber man koennte 18:24 einstellen, also nur einen Schaltpunkt. damit wird um mitternacht ein wert eingestellt und beim naechsten Schaltpunkt des "Master" (meist TC-IT) wird dies ueberschrieben. Im Normalfall muesste der TC dabei immer 'recht' bekommen und den RT ueberschreiben - so die Zeiten 100% synchron sind. Einfach durch die processing time der uebertragung
e) externMode
man baut ein notify, dass die Listen syncht. => ist sache des User, gefaellt mit in diesem Fall nicht
f) copyMode
ist eine Variante von b) Der User legt tempListen in einem File ab (HMInfo templist funktion) und kopiert diese liste per template (tempListTmpl in HMInfo ) in alle seine peer RTs. Laesst sich mit 2 kommandos realisieren - ist aber User-abhaengig.

mehr optionen denkbar?

a) und e) sehe  ich nicht
b) ist elegant aber ggf. sehr aufwaendig. wuerde ich vermeiden wollen. Man muss jede aenderung der templist in allen RT/TC in der Gruppe abfangen und dann einbauen... aber wie soll man mixen... und das message aufkommen...
c) sollte in jeden Fall realiert werden, abhaengig von der praeferierten Loesung
d) halte ich fuer elegant und sinnvoll. Ich empfehle, einen schaltpunkt im TC um 00:30 - damit stellt man sicher, dass der RT auch gesyncht wird. Man hat bestenfall 30min einen falschen Wert von 00:00 bis 00:30.
f)diese Moeglichkeit besteht schon jetzt, als funktionen vorhanden. Man braucht nur eine guideline fuer den User. So man will kann man dies auch regelmaessig durchfuehren. FHEM wird nicht schreiben, wenn keine aenderung zu den aktuellen werten (in FHEM!) festgestellt werden - ist also realitv performance-arm

Meinungen?

@betateilchen

jedem Lock-Register das beschissene lock/unlock eingebaut wurde

uh - starke wortwahl. muss ein echtes Problem sein.
bin ich aber leidenschaftslos. Wenn es auf 'lock' steht ist alles klar, wenn es auf 'on' steht gibt es immer wieder User mit Fragezeichen in den Augen ob dies nun Lock oder unlock signalisieren soll. Du bist sicher der Meinung, dass der User eben korrekt lesen soll - kann man nicht von der Hand weisen

Und wieso funktioniert es nicht wenigstens, wenn man es schon ändert?

weil ich evtl den falschen wert schreibe. HM hat ein 1Byte bool und sagt nicht, was true und false ist. Ich denke aber, dass es morgen funktionieren wird.
Gruss Martin

[hexenmeister]

Moin!

Hm... Ich hätte mir b) vorgestellt, aber ich könnte auch mit d) leben, auch wenn dies schon eher ein unschöner Hack ist. Vor allem welchen Wert sollte man da wählen, dass es für alle Wetterlagen passt? Kann man Zeitsync automatisch durchführen? Dann könnte man die 'falsche Pause' auf wenige Sekungen verkürzen, wäre dann der Wert von 12 Grad oder so OK. Kostet aber trotzdem Batterie, da uU. der Ventil unnötig hin- und hergefahren wird... Kann man in dem d)-Fall die RT-Listen automatisch setzen (mit dem besser passenden Disired-Wert), oder mutiert dass dann zu einem Abart von b)?

[betateilchen]

@betateilchen
uh - starke wortwahl.

Ja. Aber schwache Worte haben die Eigenschaft, von Dir regelmäßig nicht wahr- geschweige denn ernstgenommen zu werden.

muss ein echtes Problem sein.

Ja, und nicht nur eines. Und auch keine "fiktiven" Probleme, sondern tatsächlich existierende:

• Wertepaare on/off werden z.B. von 93_DbLog automatisch in sinnvolle und einfach weiterzuverarbeitende Werte 1 und 0 umgewandelt und geloggt. Mit lock/unlock funktioniert das nicht
• für das Plotten eines Wertepaares on/off gibt es standardisierte Lösungen in den fhem plot-Files. Für lock/unlock gibt es das nicht. (Warst nicht Du es, der beim völlig sinnlosen Leerzeichen im actuator-Reading zwischen Wert und "%" auf diesem Leerzeichen bestand, weil es "für das Plotten wichtig" sei?
• Die drei lock-Register bezeichnen Schalter und ein Schalter hat nunmal nur die Zustände on und off. Die Funktion des Schalters wird dadurch noch verstärkt, dass im Display des TC korresponierende Symbole ein- bzw. ausgeschaltet werden
• Alle anderen Schalter in den Registern werden auch mit on/off dargestellt, bei dayLightSaveTime schreibst Du auch nicht "Sommer/Winter", genausowenig wie bei winOpnBoost "boost/noboost" usw...

bin ich aber leidenschaftslos.

"Leidenschaftslos" beschreibt die Sache nicht richtig. Ich würde sagen, Du bist in Deiner Homematic-Welt manchmal betriebsblind bis an die Grenze zum Autismus.

als aussenstehender ohne TC-IT

als solcher solltest Du nicht darüber befinden, was für Leute, die das Gerät besitzen, die richtige (und vor allem logische!) Anzeige ist.

Wenn es auf 'lock' steht ist alles klar,

Gar nichts ist damit klar (s.o.!)

hm - ok. da es aber mutwillig und mit Aufwand eingebaut wurde scheint es Rudi zu gefallen - und meine Sichtweise teilt er meist nicht.
...
damit ist es aus meiner Sicht nicht nur sinnlos sondern störend.

Sinnlos und störend ist auch "lock/unlock" anstatt "on/off".

Merkst Du eigentlich nicht, dass Du genau in dem Verhalten, das Du an Rudi kritisierst, noch viel schlimmere Ausprägungen an den Tag legst? Mit Rudi kann man aber reden und er sieht die Sinnhaftigkeit mancher Useranforderungen ab und zu auch ein. Das ist der grundlegende Unterschied zwischen Euch beiden.

[betateilchen]

Moeglichkeinten:
a) ManuMode
immer manu-mode benutzen => scheidet aus, macht keinen Sinn

Für mich ist das der einzige sinnvolle Weg.

[hexenmeister]

Für mich ist das der einzige sinnvolle Weg.

Begründung? Wieso willst Du die Automatiken abschalten? Dann braucht man dach gar keine dynamische Regelung und kann bei einem mechanischen Regler bleiben? Oder verstehe ich Dich falsch?

[CQuadrat]

Begründung? Wieso willst Du die Automatiken abschalten? Dann braucht man dach gar keine dynamische Regelung und kann bei einem mechanischen Regler bleiben? Oder verstehe ich Dich falsch?

Für mich würde es Sinn ergeben, AUTO am RT abzuschalten/deaktivieren.


Als Workaround werde ich mir wohl Notifys basteln, die den RT bei Bedarf wieder auf MANU setzen. Sollte eigentlich nur bei entsprechenden Änderungen am TC notwendig sein.

[betateilchen]

Relativ einfach erklärt:

Fall 1:
Wenn ich einen RT mit dem TC (komplett ohne fhem oder andere Zentrale, z.B. CCU2) verbinde, dann will der Anwender den RT mittels TC steuern und für fhem stellt sich die Frage überhaupt nicht.

Fall 2:
Wenn ich einen RT und einen TC mit fhem betreibe, dann will der Anwender (ich zumindest) die Kontrolle an fhem abgeben. Dann braucht es den Automatikmodus überhaupt nicht mehr, weil alles, was der Automatikmodus macht (und das sind letztendlich nur die Temperaturlisten) durch die Steuerung von fhem ersetzt wird. Auch Zeitpläne.

• Bei mir laufen sowohl RT als auch TC im manu-Mode.
• Der RT ist für die Bedienung am Gerät komplett gesperrt.
• Der TC ist in der Betriebsart modusBtnLock gesperrt. Das gibt Personen die Möglichkeit, die Temperatur manuell zu regeln, solange bis die nächste Vorgabe von fhem kommt.
• Die gesamte Steuerung der Heizzeiten kommt von fhem anhand der Definitionen in einem Google-Kalender.

Ich brauche die tempList weder im TC noch im RT, und deshalb brauch ich auch den Automatikmodus nicht. Die tempList würde jede zuverlässig Steuerung durch fhem zunichte machen, weil sie komplett durchschlägt. Deshalb steht bei mir in ALLEN tempList für ALLE Tage immer nur ein einziger Eintrag: "24:00 16.0" damit sind die quasi komplett ausser Kraft gesetzt.

[CQuadrat]

Ich brauche die tempList weder im TC noch im RT, und deshalb brauch ich auch den Automatikmodus nicht. Die tempList würde jede zuverlässig Steuerung durch fhem zunichte machen, weil sie komplett durchschlägt. Deshalb steht bei mir in ALLEN tempList für ALLE Tage immer nur ein einziger Eintrag: "24:00 16.0" damit sind die quasi komplett ausser Kraft gesetzt.

Das ist sicherlich eine angemessene Sicht der Dinge und gerade wenn man mit FHEM steuern will die eigentlich sinnvolle Konfiguration.

Aber: es gibt sicher User (dazu gehöre ich), die die Thermostate auch autark von FHEM betreiben möchten. Dazu ist der Betrieb im AUTO-Modus mit Templisten notwendig. FHEM kann/sollte dabei zusätzlich für "Sonderaufgaben" (z.B. Abwesenheitsschaltung (bin jetzt für 12h weg->Heizung so lange aus), Nachtschaltung (gehe früher ins Bett als üblich->alle Heizkörper bis morgens den Nachtmodus), etc.) eingesetzt werden.

[martinp876]

Hi Betateilchen,

das ist nicht der einzige schalter, der nicht on/off hat, da hast du nicht recht. Kandidante sind:

Code Auswählen Erweitern

intKeyVisib    invisib,visib
btnLock        unlock ,lock
globalBtnLock  unlock ,lock
modusBtnLock   unlock ,lock
showSetTemp    actTemp,setTemp
showHumitidy   temp   ,tempHum

Bisher hat es keine Einwaende gegeben - und wenn es welche gibt, gehe ich ihnen nach. dabei versucher ich, nicht nur eine Meinung zu beruecksichtigen.

Merkst Du eigentlich nicht, dass Du genau in dem Verhalten, das Du an Rudi kritisierst,

nicht passend. Ja, auch ich habe Meinungen zu den Teilen die ich Implementieren und versuche eine Linie reinzubringen. Rudi ist mit unter anderer Meinung, was sein gutes Recht ist - auch wenn ich nicht in allen Details uebereinstimme. Es war keine Kritik von mir sondern eine Anmerkung, wenn ich etwas gut finde wird es in Rudis Modulen noch lange nicht Implementiert - es galt in diesem Fall Rudi zu ueberzeugen - mehr war da nicht.
Hingenge unterstreichst du deine Meinung mit ausgewaehlt blumiger Wortwahl. An deiner Meinung besteht sicher kein Zweifel - sorry fuer jegliche Kommentare an deiner Person und deinen Erguessen

Dach den vielen Blumen die du hier verteilt hast verstehe ich, dass Vorschlaege meiner Seits jeglicher Art zum TC-IT nicht gewuenscht sind - habe ich verstanden.
Gruss Martin

[betateilchen]

da hast du nicht recht. Kandidante sind:

Code Auswählen Erweitern

intKeyVisib    invisib,visib
btnLock        unlock ,lock
globalBtnLock  unlock ,lock
modusBtnLock   unlock ,lock
showSetTemp    actTemp,setTemp
showHumitidy   temp   ,tempHum

Doch, ich habe recht. Denn die von dir aufgeführten showSetTemp und showHumidity sind nämlich UMschalter für WERTE - im Gegensatz zu den Lock-Schaltern, die ZUSTÄNDE lediglich EIN- bzw. AUSschalten.

verstehe ich, dass Vorschlaege meiner Seits jeglicher Art zum TC-IT nicht gewuenscht sind - habe ich verstanden.

Nö, verstanden hast Du das nicht. Denn das was Du jetzt als "verstanden" hier präsentierst, hat niemand geschrieben. Natürlich sind Vorschläge von Deiner Seite erwünscht und willkommen. Du solltest aber als Entwickler auch die Möglichkeit in Betracht ziehen, dass Anwender, die mit dem Gerät arbeiten, andere Vorstellungen und Anforderungen aus der Praxis für eine sinnvolle Nutzung haben als Du lediglich in der Theorie Deiner Entwicklungsarbeit. Um nichts anderes geht es.

Für mich bleiben "lock/unlock" als Werte für Ein-/Ausschalter weiterhin "sinnlos und störend" (Zitat von Dir) - und das aus tatsächlichen Gründen, die ich versucht habe, sachlich und ohne blumige Wortwahl dazustellen und die sich mMn auch problemlos nachvollziehen lassen.

[martinp876]

Hi Alle ausser Betateilchen,

mit sicherheit wollen einige das HM feature der eingebauten templisten nutzen. Dafuer gibt es viele Gruende und wie immer liegt die Entscheidung beim User
So der User Loesung a) will und die Steuerung aus FHEM heraus betreibt ist er fertig hier und muss sich nicht weiter einmischen. Das Funktioniert und bedarf keiner weiteren Aenderung.

Beim Peeren eines TC mit einem RT standalone uebertraegt der TC die templiste an den RT - automatisch. Warscheinlich wuerde er dies auch tun, wenn die templist (P1,P2,P3) im TC ungeschaltet wird. HM hat hier offensichtlich einen weiteren Sicherheitsleven vorgesehen.
Loesung b) ist sicher elegant - hat aber das Problem des handelns relativ vielen Messages.
So man ein autonomes System haben will machen m.E. nur d) und f) sinn.

d) ist einfach zu realisieren, ist schon alles vorhanden. Um sicher zu stellen, dass der RT zeitlich nicht nacheilend ist muss man schlimmstenfalls die 30min in kauf nehmen.
f) ist eigentlich auch vorhanden, es waere nur eine Anleitung notwendig. Der User sollte HMInfo und die Verwaltung der Templisten verstehen. Dann bedarf es eines Notify, das beim Umschalten der P123 listen den RT entsprechend ueberschreibt. Ausserdem kann man mit at z.B. alle 24h die templiste proforma kopieren - ist sie aktuell wird nichts gesendet, also kein Problem

Gruss Martin

[martinp876]

@betateilchen

Doch, ich habe recht

wie konnte ich zwiefeln - selbstverstaendlich.
Der Schalter showHumitidy ist kein Schalter - klar! er schaltet die Anzeige der Humidity nicht ein und aus - klar, ich dummchen. Der macht da anders.

Denn das was Du jetzt als "verstanden" hier präsentierst, hat niemand geschrieben

als solcher solltest Du nicht darüber befinden, was für Leute, die das Gerät besitzen, die richtige (und vor allem logische!) Anzeige ist.

Du bist in Deiner Homematic-Welt manchmal betriebsblind bis an die Grenze zum Autismus.

was gibt es hier nicht zu verstehen?

Du solltest aber als Entwickler auch die Möglichkeit in Betracht ziehen, dass Anwender, die mit dem Gerät arbeiten, andere Vorstellungen und Anforderungen aus der Praxis für eine sinnvolle Nutzung haben als Du lediglich in der Theorie Deiner Entwicklungsarbeit.

hm - jetzt bin ich (ohne ausfallens zu werden)  - auf deinen Wunsch eingegangen die Schalterzustaende umzubenennen - als Antwort werde ich beschimpft - weil ich sonst angeblich auf nichts reagieren. Eigentlich reagieren ich auf Beschimpfungen nicht - und es ist nicht der uebliche Umgangston, auch hier nicht.

Gruss Martin