HM-TC-CC Unstimmigkeiten in der Anzeige nach statusRequest

[Jörg]

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?

gerade 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.

Um 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.

Ich 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!

[martinp876]

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

[martinp876]

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