Hallo Martin
ich möchte auf eine kleine Unstimmigkeit in der Webanzeige und den Readings
nach einem statusRequest hinweisen.
Für mich nicht besonders störend aber vielleicht ist es ja nur eine Kleinigkeit.
Ich habe 2 Heizkörper im Keller die normalerweise ausgeschschaltet sind!
In den Readings: --> controlMode central und desired-temp off
(siehe Anhang / see attachement)
Im Web sieht das so aus:
(siehe Anhang / see attachement)
Nach statusRequest des Heizkörpers UG_WS-->
2013.10.04 11:30:30 2: CUL_HM set UG_WS statusRequest
In den Readings: --> controlMode central und desired-temp 5.5
(siehe Anhang / see attachement)
Im Web controlMode central und desired-temp on
Im Web sieht das so aus:
(siehe Anhang / see attachement)
Wie man sieht, ändert sich die Anzeige im WEB und den readings ohne eine Änderung an den Einstellungen des
TC vorzunehmen.
Gruss Billy
wird korrigiert in Version NACH 4005 (noch heute...)
Ein herzliches Dankeschön!
Billy
Hi Martin,
ich habe auch ein, zwei Fragen zu dem statusRequest.
Wozu dient der statusRequest denn?
Kannst Du den nicht auf Loglevel 3 erhöhen?
Ich frage deshalb, da ich nun recht viele Logeinträge habe wie:
2013.10.15 19:13:24 2: CUL_HM set n15_Pumpe_Wasserfall statusRequest
2013.10.15 19:41:17 2: CUL_HM set i01_Treppe statusRequest
2013.10.15 20:05:51 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
...
Was auch sehr stört, ist das das Datum, bzw die Uhrzeit durch den statusRequest bei den Readings nicht mehr stimmen. (Siehe Dateianhang)
Bei CommandAccepted steht die richtige Uhrzeit der letzten Statusänderung.
Bei state sollte auch 2013-10-15 00:10:25 stehen, da sich seit dem der Status nicht geändert hat.
Kannst Du bitte einmal nachschauen, was da nicht stimmt? :)
schaue ich mir an.
aber: in den readings steht NIE, wenn es sich das letzte man geändert hat sondern wann es das letzte mal gesehen wurde.
commandAccepted ist ein Stiefkind... aber ich werden einmal nachsehen. eigentlich sollte das ein neueres Datum haben...
und zum loglevel... muss ich mal nachdenken. loglevel 3 kommen alle ausgeführten kommandos. Und der statusRequest ist auch so einer.
der statusRequest fragt den Zustand (level) ab. Das wird zur sicherheit an einigen Stellen, an denen es nicht automatisch von Device kommt - von FHEM automatisiert. z.B. nach neustart. Wenn du das nicht willst, einfach autoReadReg auf "0" stellen. dann musst du mit alten werten leben, von hand abfragen oder auf das Device/ein neues Ereigniss warten.
Hmm - so wie sich das anhört, ist das was Du mir da sagst genau das Gegenteil von dem, was ich eigentlich möchte. :D :D :D
Was ich brauche, ist eine Möglichkeit, zu sehen, wann die letzte Änderung stattgefunden hat und nicht wann es zuletzt gesehen wurde. :D
Zum Loglevel:
Wenn das nur einmal nach einem Neustart stattfindet, finde ich das ja ok, aber bei mir werden einige Aktoren mehrfach abgefragt und müllen mir das log zu.
Um Dir zu zeigen, was ich meine, habe ich als Beispiel alle statusRequest von einem Aktor (model HM-LC-SW4-PCB) an einem Tag herausgesucht und hier aufgelistet:
2013.10.12 08:30:33 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 08:52:36 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 09:02:00 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 09:08:11 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 09:17:21 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 10:16:35 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 11:13:02 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 13:55:05 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 14:06:55 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 14:22:30 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 14:33:06 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 15:43:27 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 15:49:04 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 16:05:11 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 17:04:25 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 18:04:39 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 19:04:54 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 19:19:39 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 20:05:59 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 20:57:31 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 21:16:53 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 21:46:47 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 22:35:01 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 23:03:38 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.12 23:52:20 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
2013.10.13 00:01:35 2: CUL_HM set CUL_HM_switch_19BB49 statusRequest
Das sollte doch nun bestimmt nicht so sein, oder?
zu den readings und dem Zeitstempel - bei einigen Readings will man den Zeitpunkt der Änderung sehen, bei anderen jede gutmeldung (z.B. Batterielevel - man will sehen, wann die letzte gutmeldung war - und ob die regelmässig kommen).
Es wird immer der komplette inhalt der message ausgewertet und alle Readings upgedated. Das zu unterscheiden wäre kaum nachvollziehbar.
du kannst die notifies, die aus den readings generiert werden auf "event-on-change" einstellen. Die Zeitstempel werden immer noch geaendert, aber wenn du einen Ablauf willst kannst du es in ein log schreiben.
Die statusRequests sind definitiv nicht ok. was ist passiert? war das System in Ruhe, gab es restarts, wurde geschaltet? Bitte mehr info. Der Abstand ist oft eine Stunde, manchmal kürzer. Sagt die das etwas?
Gruss Martin
Die statusRequests kommen dann, wenn sich bei einem 4 Kanal Switch (HM-LC-SW4-PCB) ein Kanal der Status ändert. Dann werden die anderen Kanäle wieder abgefragt.
Nun taucht das Problem auf, dass nach einem FHEM-Neustart diese Fehlermeldung kommt:
2013.10.16 22:14:43 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
Ich vermute mal, dass das das Sendelimit, nach der Statusabfrage von ca. 200 HM-Devices ist?
Nun habe ich das von Dir erwähnten autoReadReg 0 getestet und das ist genau das was ich möchte. 8)
Da ich wie schon erwähnt ca. 200 HM-Devices habe, möchte ich fragen, ob es eine Möglichkeit gibt, die Funktion global abzuschalten?
Wenn nicht, könntest Du bitte solch eine Möglichkeit einbauen? - Vielen Dank!
Hallo Jörg,
diese Abfrage ist bei Dimmern notwendig um den wahren Zustand zu erhalten. Bei Schaltern ist es nicht gewünscht (war nie).
Ich werde es auf Dimmer beschränken.
Ab version 4057 passiert es nicht mehr bei switches.
Die Message, die deine Schalter senden unterscheidet sich von 'meinen'.
Kannst du ein paar mitschneiden? Interessehalber. Welchen switch hast du?
Gruss Martin
Danke, dass Du das auf Dimmer beschränkst !!! :) :) :)
Ich werde hier sonst kirre. :o
Es sind bei mir 35 mal HM-LC-SW4-PCB. Somit 140 Aktoren:
http://www.elv.de/homematic-4-kanal-schaltaktor-hm-lc-sw4-pcb-komplettbausatz-inkl-gehaeuse.html (http://www.elv.de/homematic-4-kanal-schaltaktor-hm-lc-sw4-pcb-komplettbausatz-inkl-gehaeuse.html)
Einige Logausschnitte werde ich nachliefern, da ich nun die Bettkarte stempeln werde. ;D
Hi Martin,
hier sind noch einige Logs. Wenn Du noch weitere brauchst, sag bitte bescheid.
Im ersten Log mit dem HM-LC-SW2-FM kannst Du ein Beispiel sehen, dass Fehlschaltungen auftauchen, da ich sehr häufig Das Datum und die Uhrzeit abfrage.
Daher noch einmal die Bitte das Du eine optionale Möglichkeit einbaust, den statusRequest generell zu deaktivieren Ich brauche es eigentlich auch bei den Dimmern nicht. :)
z.B. über das HMLAN: attr HMLAN autoReadReg 0
_________________________________________________________________________
Bei einem HM-LC-SW2-FM http://www.elv.de/homematic-funk-schaltaktor-2fach-unterputzmontage-1.html (http://www.elv.de/homematic-funk-schaltaktor-2fach-unterputzmontage-1.html)
2013.10.17 07:10:12 1: set i01_Treppe on
2013.10.17 07:11:42 2: CUL_HM set i01_Treppe off
2013.10.17 07:11:42 1: set i01_Treppe off
2013.10.17 07:11:52 2: CUL_HM set i01_Treppe statusRequest
2013.10.17 07:11:52 1: set i01_Treppe off
2013.10.17 07:11:53 1: set i02_Flur_Eingang off <<<------ Sendet ungewollt durch das statusRequest.
_________________________________________________________________________
Bei einem HM-LC-DIM1T-CV http://www.elv.de/homematic-funk-dimmaktor-phasenabschnitt-zwischendeckenmontage.html (http://www.elv.de/homematic-funk-dimmaktor-phasenabschnitt-zwischendeckenmontage.html)
2013.10.17 07:10:02 2: CUL_HM set a01_Decke_1 0 0 30
2013.10.17 07:10:03 3: FS20 set a02_Decke_2 off 30
2013.10.17 07:10:05 3: FS20 set a03_Tischlampen off 30
2013.10.17 07:10:12 2: CUL_HM set a01_Decke_1 statusRequest
2013.10.17 07:10:23 2: CUL_HM set a01_Decke_1 statusRequest
2013.10.17 07:10:33 2: CUL_HM set a01_Decke_1 statusRequest
_________________________________________________________________________
Bei einem HM-LC-SW4-PCB http://www.elv.de/homematic-4-kanal-schaltaktor-hm-lc-sw4-pcb-komplettbausatz-inkl-gehaeuse.html (http://www.elv.de/homematic-4-kanal-schaltaktor-hm-lc-sw4-pcb-komplettbausatz-inkl-gehaeuse.html)
2013.10.16 22:05:21 2: CUL_HM set z87_Regensensorheizung on-for-timer 1800
2013.10.16 22:05:31 2: CUL_HM set n15_Pumpe_Wasserfall statusRequest
2013.10.16 23:04:53 2: CUL_HM set z87_Regensensorheizung on
2013.10.16 23:05:03 2: CUL_HM set n15_Pumpe_Wasserfall statusRequest
2013.10.17 00:05:44 2: CUL_HM set z87_Regensensorheizung on-for-timer 1800
2013.10.17 00:05:54 2: CUL_HM set n15_Pumpe_Wasserfall statusRequest
2013.10.17 08:03:07 2: CUL_HM set a71_Jalousie_Fenster_AUF on-for-timer 22
2013.10.17 08:03:08 2: CUL_HM set a73_Jalousie_Tuer_AUF on-for-timer 33
2013.10.17 08:03:10 2: CUL_HM set b71_Jalousie_AUF on-for-timer 1
2013.10.17 08:03:13 2: CUL_HM set c71_Jalousie_AUF on-for-timer 1
2013.10.17 08:03:16 2: CUL_HM set f71_Jalousie_AUF on-for-timer 30
2013.10.17 08:03:18 2: CUL_HM set g71_Jalousie_AUF on-for-timer 30
2013.10.17 08:03:20 2: CUL_HM set j71_Jalousie_AUF on-for-timer 25
2013.10.17 08:03:30 2: CUL_HM set a71_Jalousie_Fenster_AUF statusRequest
2013.10.17 08:03:34 2: CUL_HM set f71_Jalousie_AUF statusRequest
2013.10.17 08:03:38 2: CUL_HM set g72_Jalousie_AB statusRequest
2013.10.17 08:03:42 2: CUL_HM set k71_Jalousie_AUF statusRequest
_________________________________________________________________________
Zitat von: Jörg am 17 Oktober 2013, 10:28:27Daher noch einmal die Bitte das Du eine optionale Möglichkeit einbaust, den statusRequest generell zu deaktivieren Ich brauche es eigentlich auch bei den Dimmern nicht
zum Glück bin ich nicht der einzige, der sich über diese aufgezwungene Standardeinstellung ärgert ... das beruhigt mich dann doch sehr.
Hallo Jörg,
HMLAN ist definitv die falsche Stelle - immerhin kannst du mehrere HMLAN haben.
Wenn dann also in HMInfo, das gibt es einmal je FHEM. .
In HMInfo kannst du auch einfach prüfen, dass/wo du die Einstellungen gesetzt hast.
Ob es jetzt sinn macht, in HMInfo defaults zu setzen...
Bei dimmern wird dann nicht mehr garantiert, dass du den korrekten LichtLevel angezeigt bekommst - wenn du das nicht brauchst ist es mir recht.
Die Logs waren leider nicht die rohmessages, die ich gewollt hatte.
Wenn du event-on-change .* einstellst bekommst du keine doppel-meldungen. das macht auch aus Performance-sicht sehr viel sinn.
das" set on" kommando löst set Version 4057 kein statusRequest aus- welche Version hast du in Betrieb?
Was ich mich frage ist, wie wichtig dir die korrekte Statusanzeige ist. Es gab immer wieder Probleme, dass das Device nicht korrekt gemeldet hat. das kannst du auch manuell abfangen, klar. Normals User sollte man nicht in diese fallen laufen lassen.
Gruss Martin
Hi Martin,
ZitatHMLAN ist definitv die falsche Stelle
Ja klar, da hast Du recht, es war ja auch nur als Beispiel gedacht. ;)
ZitatBei dimmern wird dann nicht mehr garantiert, dass du den korrekten LichtLevel angezeigt bekommst - wenn du das nicht brauchst ist es mir recht.
Siehst Du, genau da ist der Punkt, den ich bei der Sache nicht verstehe.
Wenn ich FHEM neu starte, dann dauert das ca. 20 Sekunden. Was soll in den 20 Sekunden denn passieren, damit die Anzeige nicht stimmt? Klar, es kann sein, dass genau dann mal Einer das Bedürfnis hat, herum zu dimmen. Wenn die Anzeige dann nicht stimmt, habe ich halt Pech gehabt, aber die Welt geht davon nicht unter.
In den 20 Sekunden könnte aber auch jemand einen Aktor betätigen, der stimmt dann aber auch nicht. Die müsstest Du dann auch wieder in die Abfrage nehmen. Aber das sprengt mit Sicherheit, je nach Anzahl der Aktoren, wie bei mir den Rahmen.
Bei mir stimmte die Anzeige der Aktoren und der Dimmer bisher immer. Wo es schon einmal klemmt ist bei einem on-for-timer Event bei den
HM-LC-SW4-PCB, da die nach dem Timerevent das Abschalten nicht geziehlt an FHEM, sondern nur allgemein senden.
Verstehe das bitte nicht falsch, denn ich schätze Deine Arbeit hier wirklich sehr !!! 8)
Seit dem Du Dich um die HM-Devices kümmerst, haben sich hier viele Dinge um Welten verbessert !!!!
ZitatWas ich mich frage ist, wie wichtig dir die korrekte Statusanzeige ist. Es gab immer wieder Probleme, dass das Device nicht korrekt gemeldet hat.
Natürlich ist eine korrekte Statusanzeige wichtig!
Das Problem, was einige User da mit dem Devices haben, die sich nicht korrekt melden, ist das die Statusänderung nicht gezielt an FHEM gesendet wurde.
Beispiel 1: Funktaster ist gepairt mit einem Dimmer danach mit FHEM.
Wenn nun der Taster betätigt wird sendet er an den Dimmer. Der Dimmer antwortet dem Taster "ok habe verstanden". der Taster ist zufrieden und gibt Ruhe. :) FHEM bekommt aus welchen Gründen auch immer nicht mit, dass der Vorgang abgeschlossen ist und zeigt dadurch den falschen Wert an. :(
Beispiel 2: Funktaster und Dimmer sind direkt mit FHEM gepairt. (So habe ich das bei allen Devices gemacht)
Wenn der Taster jetzt betätigt wird, geht das direkt an FHEM. Danach sendet FHEM den Befehl direkt an den Dimmer. Wenn der Dimmer dann fertig ist, gibt er die Info an FHEM, dann stimmt die Anzeige auch
immer. :)
Das ist zwar ein wenig mehr Programmieraufwand, aber wesentlich flexibler im Handling und einfacher bei komplexeren Programmabläufen. :D
Zitatdas" set on" kommando löst set Version 4057 kein statusRequest aus- welche Version hast du in Betrieb?
bis gestern war es die # $Id: 10_CUL_HM.pm 4042 2013-10-14 17:46:05Z martinp876 $
Momentan ist es die aktuelle von Heute.
Mit event-on-change .* habe ich noch nicht viel gemacht, werde es aber jetzt am WE testen.
Hallo Jörg,
wenn dein restart 20sec dauert ist das deine Sachen.
Wenn ich ein stabiles system will darf ich hier nicht spekulieren.
Das Beispiel mit dem Dimmer ist ein anderes: wenn di logical channels nutzt muss separat nachgefragt werden - sonst bekomme ich den physical level nicht heraus.
Nutzt du logical channels bei dimmer?
Nach dem start ist dimmer/switch/blind egal.
Meine zeigen regelmäsig im status ??? an - nicht prikelnd.
wenn während der 20 sekunden etwas passiert bekomme ich dies mit - wieso nicht? sonst würde ich ja immer etwas verpassen. Wieso sollte das den Rahmen sprengen?
Beispiel 1: der Dimmer sollte an die Zentrale den "Endzustand" melden -mit adresse. Das sollte kein Probem sein - und hier muss man auch nicht nachfragen.
Sollte der Dimmer noch in 'bewegung' sein kann man nocheinmal nachfragen.
Beispiel 2: nicht unbedingt. Der dimmer sendet an den Trigger NIE den enszustand sondern IMMER die Bestätigung des Kommandos (leider gibt es hier auch manchmal Probleme)
in diesem Beispiel belastest du übrigens dein HMLAN deutlich mehr als wenn hie und da ein statusRequest nachgesendet wird. Es sollte so der Dopplete Traffic sein. Und wie gesagt - die Anzeige ist GENAUSO ungenau besonders bei dimmern mit rampe, on-for-timer, on-time, treppenhausschaltern...
Solltest du einmal überdenken.
gerade bei grossen Systemen empfehle ich event-on-change als default. Es gibt nur wenig ausnahmen (motion detcector meldet immer "motion" - das ist kein change).
Ausnahmen würde ich in event-on-update abfangen.
Um eins klarzustellen: ich habe etwas großzügig status-requests eingebaut- aber immer an stellen, an denen es Probleme gab. Auch(besonders) das Lesen der Register beim start sowie der Burst-mode sind problematisch.
Wenn etwas unnötig abgefragt wird muss ich es überdenken- und gehe gerne den Hinweisen nach.
Nachdem ich den HMLAN ausgemessen habe bin ich am reduzieren der messages
Aber deine Beispiele kann ich so nicht nachvolliehen.
Noch eine generelle sache:
man kann eine grob gesagt die Voreinstellungen eher auf automatik oder eher auf manuell stellen. Zu beginn habe ich das mit Rudi besprochen - FHEM soll eher automatisch sein (was ich für gut halten).
Das muss einem nicht gefallen, ist eben Philosophie. Es darf das system nicht destabilisieren, klar.
Wenn es keine Wahlmöglichkeit gäbe würde ich die Aufregung verstehen. aber du hast die Wahl. Du musst es doch nur ausschalten. Kontrollieren kannst du es mit einem einzigen Befehl
set hm param -d autoReadReg
es muss ja nur im device gesetzt werden.
Ich bin sehr interessiert an deinen Ergebnissen - wenn du noch mit AutoReadReg arbeitest. Wenn du ein log über einig Zeit schickst kann ich es nach überflüssigen untersuchen.
Ich bin immer für konstruktive zusammenarbeit und gehe allen beschriebenen Problemen nach
Gruss Martin
Hi Martin,
hat was länger gedauert, aber habe nun bei allen HM-Devices mit
attr DEVICE autoReadReg 0 den statusRequest abgeschaltet.
Bei den Dimmern scheint das aber noch nicht zu gehen, oder ist das Absicht?
Zitatgerade bei grossen Systemen empfehle ich event-on-change als default.
Das habe ich bisher hauptsächlich bei Temperatursensoren eingesetzt. Die Restlichen Aktoren werden bisher über das Notify z.B. mit
define n01_Gaeste_WC notify i06_Gaeste_WC_Licht:(deviceMsg.*) abgefragt. Damit wird auch alles nur einmalig ausgeführt. Das werde ich aber demnächst nach und nach auf
event-on-change ändern. Danke für den Tipp.
ZitatUm eins klarzustellen: ich habe etwas großzügig status-requests eingebaut- aber immer an stellen, an denen es Probleme gab.
Prinzipiell finde ich das ja auch gut, aber das hat in der Form für meine Konstellation zu viele Nachteile:
- Nach jedem Request ändert sich der Timestamp. Da ich als Frontend PGM 3 benutze (siehe Anhang) habe ich das Problem, dass ich dann nicht mehr sehen kann, wann sich bei HM-Devices das letzte Mal der Status geändert hat. Sondern sehe da nur, wann der letzte Request stattgefunden hat.
- Mit z.B. my $ChangeHeizung1 = ReadingsTimestamp('a81_Heizung', 'state', '1970-01-01 01:00:01') lese ich häufig den Timestamp aus. Das ist aber durch den statusRequest dann auch nicht mehr möglich, da der Timestamp nicht mehr stimmt.
- Ein Statusrequest ist für meine Begriffe eine Hintergrundangelegenheit und da finde ich ist Loglevel 2 zu niedrig. Der Loglevel der Requests sollte zumindest irgendwie optional einstellbar sein.
ZitatIch bin immer für konstruktive zusammenarbeit und gehe allen beschriebenen Problemen nach
Das finde ich ja auch gut an Dir das Du nicht so eingestellt bist, wie viele Andere Programmierer, denen alles egal ist !!! :)
Ich kann nur wiederholen, dass ich das was Du hier machst, wirklich bewundere!
korrekt, bei dimmern ist es noch drin. Kann ich rausnehmen. Da kann es dann Probleme in ein paar Fällen geben -bei dimmern mit virtuellen channels beispielsweise. Es ist auch noch bei Blind Aktoren drin - auch hier hatten wir einige male mit fehlenden end-zuständen zu kämpfen, die kamen nicht immer.
Bei event-on-change musst (nun ja kannst) du berücksichtigen, dass fhem jedem möglichen notify, log,... und allen "trigger-empfaängern" jeden log "anbietet". Der muss ihn dann parsen und erkennen, dass es ihn nichts angeht - in 95% allen fälle. Also auch wen dein notify funktioniert sparst du rechenzeit in fhem. darauf will ich hinaus.
das mit dem timestamp kann ich dir so oder so nicht garantieren - so sind readings nicht aufgebaut. Zum einen senden mache devices zyklisch Info-messages. dann kannst du eine status-request von hand machen (ok - machst du nicht) und man kann das licht auch 2-mal ausschalten -was den Zeitstempel ändert.
Aber wenn du damit zurecht kommst ist es ja ok. Du kannst es ja abklemmen,autoReadReg =0 (dimmer werden ich entsprechend auch verriegeln)
Das mit dem loglevel verstehe ich nicht. was hat der statusrequest damit zu tun? der status-request hat keinen eigenen loglevel. da musst du mit erklären, was du meinst.
Über die status-message kommt übrigens nicht nur state sondern auch andere Werte (batterie, motorzustand, dimmer-operation) - und alle diese Readings werden identisch mit Zeitstempeln versehen. Das habe ich auch nicht vor zu ändern. Der timestamp ist nicht "letzte Änderung" sondern "letztes mal gesehen". Würde ich dies ändern würde event-on-change und event-on-update nicht mehr funktionieren.
Wenn ein Reading notwendig ist "last-change" oder "state-since" - darüber kann man sicher nachdenken - warum nicht. Das wäre dann auch garantiert.
Gruss Martin
mit 4104 kannst du auch die statusupdates bei dimmer und Blind ausschalten.
Auch der update vom desired-temp beim TC mode-umschaltungen kann damit ausgeschaltet werden.
Status nur noch, wenn es HM freiwillig rausgibt - oder im Handbetrieb.
status liegt somit in eigener verantwortung (nun, ich übernehme eh keine Haftung ;-))
Gruss Martin