HM-TC-CC Unstimmigkeiten in der Anzeige nach statusRequest

[Billy]

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

[martinp876]

wird  korrigiert in Version NACH 4005 (noch heute...)

[Billy]

Ein herzliches Dankeschön!
Billy

[Jörg]

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? 

[martinp876]

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.

[Jörg]

Hmm - so wie sich das anhört, ist das was Du mir da sagst genau das Gegenteil von dem, was ich eigentlich möchte. 

Was ich brauche, ist eine Möglichkeit, zu sehen, wann die letzte Änderung stattgefunden hat und nicht wann es zuletzt gesehen wurde. 


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?

[martinp876]

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

[Jörg]

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

[martinp876]

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

[Jörg]

Danke, dass Du das auf Dimmer beschränkst !!! 
Ich werde hier sonst kirre. 

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

Einige Logausschnitte werde ich nachliefern, da ich nun die Bettkarte stempeln werde. 

[Jörg]

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

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

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

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
_________________________________________________________________________

[betateilchen]

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

zum Glück bin ich nicht der einzige, der sich über diese aufgezwungene Standardeinstellung ärgert ... das beruhigt mich dann doch sehr.

[martinp876]

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

[Jörg]

Hi Martin,

HMLAN ist definitv die falsche Stelle

Ja klar, da hast Du recht, es war ja auch nur als Beispiel gedacht.

Bei 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 !!!
Seit dem Du Dich um die HM-Devices kümmerst, haben sich hier viele Dinge um Welten verbessert !!!!

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

das" 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.

[martinp876]

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