Ich habe eine HM Wired Testinstallation bestehend aus
HMW-SYS-OP-DR
HMW-IO-12-Sw7-DR
HMW-LC-Bl1-DR
in Verbindung mit einem WIZ108SR Ethernet GW aufgebaut und soweit funktioniert alles wie gewünscht.
Was mir allerdings aufgefallen ist, dass sobald ein Taster (lokal) am HMW-LC-Bl1-DR gedrückt wird, die Reaktion aller Aktoren aus Fhem heraus verzögert (ca. 1 sek) ist. Stoppe ich den HM485d und starte ich diesen wieder funktioniert alles wieder einwandfrei ohne Verzögerung.
Das Verhalten (Verzögerung) tritt nicht auf, wenn die lokalen Taster vom HMW-IO-12-Sw7-DR verwendet werden. Kann das ev. an der Peering Configuration des HMW-LC-Bl1-DR liegen? Habe mich an Thorsten's Info (https://forum.fhem.de/index.php/topic,55856.msg474537.html#msg474537) orientiert.
Andreas
Hi,
so 100%ig verstehe ich noch nicht, was Du genau meinst. Ich nehme mal an, dass Du mit "lokale Taster" die Tastereingänge meinst und nicht die kleinen Knöpfchen am Gerät selbst (oder?). Außerdem nehme ich an, dass Du sowohl die zwei Tastereingänge vom HMW-LC-Bl1-DR als auch zwei Tastereingänge vom HMW-IO-12-Sw7-DR mit dem Rolloaktor gepeert hast. Korrekt soweit?
Was genau meinst Du dann mit "die Reaktion aller Aktoren"? Bedeutet das, dass Du nach dem Betätigen des Tasters irgend einen HMW (?) Aktor von FHEM aus ansteuerst und das dauert dann lang?
Möglicherweise "überschwemmt" da irgendwas den Bus. Könntest Du mal das Log für den HM485d einschalten und hier mal die ersten 10 Sekunden oder so nach dem Drücken des Tasters einstellen?
Gruß,
Thorsten
Thorsten,
Danke für deine schnelle Reaktion. Find' ich klasse. Scheinbar war das ein (bis jetzt) temporäres Problem, da ich prompt beim Logging die Verzögerung nicht mehr nachstellen konnte. Sobald es nochmal auftritt melde ich mich nochmal.
Zu deinen Fragen:
Ich nehme mal an, dass Du mit "lokale Taster" die Tastereingänge meinst und nicht die kleinen Knöpfchen am Gerät selbst (oder?)
Korrekt. Meinte die die an den Aktoren angeschlossenen Taster
Außerdem nehme ich an, dass Du sowohl die zwei Tastereingänge vom HMW-LC-Bl1-DR als auch zwei Tastereingänge vom HMW-IO-12-Sw7-DR mit dem Rolloaktor gepeert hast
Fast. Hatte 2 Taster jeweils für den HMW-LC-Bl1-DR und HMW-IO-12-Sw7-DR verwendet. Gepeert sind für den Rolloaktor aber nur 'seine' beiden Taster.
Was genau meinst Du dann mit "die Reaktion aller Aktoren"? Bedeutet das, dass Du nach dem Betätigen des Tasters irgend einen HMW (?) Aktor von FHEM aus ansteuerst und das dauert dann lang?
Meinte damit, wenn z.B. ein
set HMW_IO_12_Sw7_DR_OEQ1529654_15 on
in Fhem getriggert wurde, eine Verzögerung von ca. 1 sek. auftritt. Und zwar nur, nachdem einer der HMW-LC-Bl1-DR Taster (zu irgendeinem Zeitpunkt vorher) betätigt wurde. Diese Verzögerung trat dann anschließend für alle Aktoren Trigger (also HMW-IO-12-Sw7-DR und HMW-LC-Bl1-DR) aus Fhem heraus auf, bis der HM485d restartet wurde. Vielleicht noch interessant: bei einem Trigger aus Fhem heraus war in dieser Zeit z.B. kurz das Ausrufezeichen im Glühlampen Symbol zu sehen.
Andreas
Hi,
ich hatte auch mal einen ähnlichen Effekt, den ich nie nachstellen konnte. Es hing damit zusammen, dass FHEM sich beim HMW-LC-Bl1-DR immer wieder die Rollladenstellung (also die Prozentwerte) abholt, solange sich dieser bewegt. Normalerweise endet das, sobald der Rollladen anhält, aber irgendwie hatte das nicht geklappt. Wenn dann noch irgendeine Störung auf dem Bus dazukommt kann es etwas wild werden.
...aber wie gesagt, ich konnte das auch nie nachvollziehen.
Gruß,
Thorsten
Thorsten,
konnte jetzt mal eine Verzögerung loggen. Siehe Attachment. Interessanterweise schwillt das Log extrem an (ca. 54000 Records in 3min). Am Anfang des Logs sollte das verzögerte Drücken eines Tasters geloggt worden sein.
Andreas
Hi,
was hast Du denn im HMW-LC-Bl1-DR als logging_time eingestellt?
Gruß,
Thorsten
Steht auf 0.40s.
Andreas
Hi,
ok, das ist etwas klein, erklärt aber noch nicht ganz das Verhalten. Könntest Du es mal auf 2 Sekunden stellen und dann nachsehen, inwiefern sich das ganze bessert? ...und dann vielleicht noch eine "Versuchsreihe" bei der das Logging komplett aus ist.
Gruß,
Thorsten
Thorsten,
hier meine Beobachtungen:
Könntest Du es mal auf 2 Sekunden stellen und dann nachsehen, inwiefern sich das ganze bessert?
Brachte keine Veränderung
...und dann vielleicht noch eine "Versuchsreihe" bei der das Logging komplett aus ist.
Das könnte ev. in die richtige Richtung gehen, da ich bei ausgeschaltetem Logging vom HMW_LC_Bl1_DR_OEQ0936184_03 bisher eine Verzögerung nicht (mehr) provozieren konnte (werde aber noch weiter testen). Was mir auch noch aufgefallen ist: In der Vergangenheit hatte ich ab und zu ganz kurz Response Timeouts - mit dem ausgeschalteten Logging jetzt aber gar keine mehr.
Andreas
Hi,
dasmit den Response Timeouts kann schon alleine davon kommen, dass der Bus tatsächlich von diesen Nachrichten "überschwemmt" wird. Da kommt einfach sonst nichts mehr durch.
Zur Erklärung: Wie schon gesagt fragt das FHEM-Modul bei einem sich bewegenden HMW_LC_Bl1_DR zyklisch den Stand des Rollladens ab, wenn "logging" auf on steht. Das passiert so oft wie in logging_time angegeben. Bei Dir müsste es also alle 0,4 Sekunden passiert sein.
Blöderweise scheint da aber was faul zu sein, und es passiert öfter. Hast Du vielleicht noch irgendeinen anderen Mechanismus, der den Stand des Rollladens abfragt? Das könnte nämlich das Polling dann nochmal anstoßen.
Gruß,
Thorsten
Thorsten,
dasmit den Response Timeouts kann schon alleine davon kommen, dass der Bus tatsächlich von diesen Nachrichten "überschwemmt" wird. Da kommt einfach sonst nichts mehr durch.
das macht eigentlich Sinn - die Fragen wären nur
- warum das erst nach einem Tastendruck vom HMW-LC-Bl1-DR auftritt (und nicht sofort nach dem Booten)?
- warum das nach dem Restart vom hm485d auch erst wieder nach einem Tastendruck vom HMW-LC-Bl1-DR auftritt?
- warum das nur beim HMW-LC-Bl1-DR so ist, und nicht auch beim HMW-IO-12-Sw7-DR?
Zur Erklärung: Wie schon gesagt fragt das FHEM-Modul bei einem sich bewegenden HMW_LC_Bl1_DR zyklisch den Stand des Rollladens ab, wenn "logging" auf on steht
Übrigens: die Verzögerungen bleiben - auch wenn der HMW_LC_Bl1_DR sich nicht mehr 'bewegt'.
Blöderweise scheint da aber was faul zu sein, und es passiert öfter. Hast Du vielleicht noch irgendeinen anderen Mechanismus, der den Stand des Rollladens abfragt?
Ist nicht der Fall. Das ganze läuft z.Z. in einer Sandbox (Proxmox sei Dank ;)) ohne weitere (Fhem) Logik.
Andreas
Zitat- warum das erst nach einem Tastendruck vom HMW-LC-Bl1-DR auftritt (und nicht sofort nach dem Booten)?
- warum das nur beim HMW-LC-Bl1-DR so ist, und nicht auch beim HMW-IO-12-Sw7-DR?
Die zyklische Abfrage erfolgt nur beim HMW_LC_Bl1_DR und auch nur wenn sich dieser bewegt und das "logging" auf on steht.
Du kannst mal in den Kanälen des HMW_LC_Bl1_DR das "logging" auf off stellen.
Gruß Ralf
Zitat von: Ralf9 am 14 Oktober 2019, 19:50:42
Du kannst mal in den Kanälen des HMW_LC_Bl1_DR das "logging" auf off stellen.
Haben wir ja schon vorher gemacht und festgestellt (bis dato), dass keine Verzögerungen mehr auftreten. Die Frage ist jetzt nur, ob das die (einzige) Lösung ist, oder ev. noch etwas am hm485d gemacht werden kann ...
Andreas
Hi,
am hm485d hängt's wahrscheinlich nicht, aber momentan weiß ich auch nicht so recht, was da so ganz genau abgeht. Ich habe aber einen Verdacht.
Könntest Du mir noch ein hm485d-Log machen mit ausgeschaltetem logging? Also das hm485d-Log einschalten und danach die Taste drücken.
...und zwar einmal mit der Tasten am HMW_LC_Bl1_DR und einmal am HMW-IO-12-Sw7-DR.
Danke&Gruß,
Thorsten
Hallo Thorsten,
anbei das Log. Logging war für alle Channels denen Taster zugeordnet sind, ausgeschaltet. Es wurden Tastendrücke jeweils beider Taster am HMW_LC_Bl1_DR und am HMW-IO-12-Sw7-DR geloggt.
Gruß,
Andreas
Hi,
ich habe das Log mal analysiert und soweit ist es erwartungsgemäß, zumindest wenn Du tatsächlich alle Taster mehrfach gedrückt hast:
2x Kanal 1 vom HMW-IO-12-Sw7-DR
2x Kanal 2 vom HMW-IO-12-Sw7-DR
2x Kanal 2 vom HMW_LC_Bl1_DR
2x Kanal 1 vom HMW_LC_Bl1_DR
Falls das nicht stimmt, dann haben wir hier noch ein anderes Problem. Hast Du die Tasten genau so gedrückt?
Für weitere Details habe ich hier eine kommentierte Version des Logs angehängt.
Ich weiß jetzt leider noch nicht ganz, welche Änderung hier Abhilfe schaffen könnte. Ich habe zwar eine Idee, bin mir aber nicht sicher, ob das wirklich sinnvoll ist. (Ich habe momentan selbst keinen Testaufbau, da bin ich lieber vorsichtig.)
Könntest Du mir noch zwei Logs machen? Diesmal so:
1. "logging" einschalten
2. Eine Taste am HMW-IO-12-Sw7-DR einmal drücken.
3. 5 Sekunden warten
Jetzt alles wieder auf Anfang (also hm485d restart) und dann:
1. "logging" einschalten
2. Eine Taste am HMW_LC_Bl1_DR einmal drücken.
3. 5 Sekunden warten
EDIT: Was ich vergessen hatte: Die Tastendrücke bitte so, dass sich am Rollladenaktor tatsächlich was "bewegt".
Danke&Gruß,
Thorsten
Hallo Thorsten,
ich habe das Log mal analysiert und soweit ist es erwartungsgemäß, zumindest wenn Du tatsächlich alle Taster mehrfach gedrückt hast:
2x Kanal 1 vom HMW-IO-12-Sw7-DR
2x Kanal 2 vom HMW-IO-12-Sw7-DR
2x Kanal 2 vom HMW_LC_Bl1_DR
2x Kanal 1 vom HMW_LC_Bl1_DR
Falls das nicht stimmt, dann haben wir hier noch ein anderes Problem. Hast Du die Tasten genau so gedrückt?
Ja habe ich. Also alles ok.
Könntest Du mir noch zwei Logs machen?
Habe ich. Das File 'hm485d_3_1.zip' ist vom HMW-IO-12-Sw7-DR und das File 'hm485d_3_2.zip' ist vom HMW_LC_Bl1_DR mit jeweils einem Tastendruck.
EDIT: Was ich vergessen hatte: Die Tastendrücke bitte so, dass sich am Rollladenaktor tatsächlich was "bewegt".
Ja das war der Fall. Aktor hat geschaltet.
Gruß,
Andreas
Zitat von: Thorsten Pferdekaemper am 17 Oktober 2019, 09:58:47
Für weitere Details habe ich hier eine kommentierte Version des Logs angehängt.
2019.10.16 23:31:53 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (216) I[3](0,F,B)(1E) 00000001 -> 0001B886 [4] 53(S) 02
Zentrale an 0001B886 Abfrage Kanal 3 (weil Tastendruck vom Rollladenaktor empfangen)
Ich finde es seltsam, daß beim Tastendruck beim HMW_LC_Bl1_DR, von der Zentrale eine Abfrage Kanal 3 gemacht wird, obwohl das logging ausgeschaltet ist.
Beim Tastendruck beim HMW-IO-12-Sw7-DR macht die Zentrale keine Abfrage.
Gruß Ralf
Hi,
(wie vorher die kommentierten Logs hier im Anhang).
Also im Prinzip läuft laut den beiden Logs alles ok.
Der HMW-IO-12-Sw7-DR scheint gar nicht mit dem Rollladenaktor gepeert zu sein, also geht von dem höchstwahrscheinlich auch kein Problem aus. Ich hatte mir erhofft zu sehen, was bei einem echten externen Peering auf dem Bus passiert, aber das könnte auch erstmal egal sein.
Beim HMW_LC_Bl1_DR ist auch alles erwartungsgemäß. Man kann 48 Level-Abfragen innerhalb von ca. 20 Sekunden sehen, also eine etwa alle 417ms. Das passt recht gut zu dem, was konfiguriert ist. (Auch wenn ich 400ms immer noch für etwas gewagt halte.)
...also sehen wir hier erst einmal kein Problem. Die Frage ist jetzt, wie das ursprüngliche Log zustande kommt. Dort habe ich 50 Level-Abfragen in ungefähr 2 Sekunden gesehen, also etwa eine alle 40ms. Komischerweise zeigt die Message dort als "direction" 0x30, was "undefined" bedeutet. Das ist auch etwas seltsam.
Kannst Du das Problem irgendwie provozieren? Könnte es z.B. sein, dass Du während der Rollladen läuft die Tasten am Rollladenaktor mehrfach gedrückt hast? ...oder hast Du einen langen Tastendruck ausprobiert? Ich würde nur sehr ungern auf Verdacht eine Änderung machen. Könntest Du mal versuchen, das Problem zu provozieren, während ein Log mitläuft?
Gruß,
Thorsten
Zitat von: Ralf9 am 17 Oktober 2019, 21:24:31
Ich finde es seltsam, daß beim Tastendruck beim HMW_LC_Bl1_DR, von der Zentrale eine Abfrage Kanal 3 gemacht wird, obwohl das logging ausgeschaltet ist.
Ja, seltsam, aber steht so im Coding. In HM485_ProcessEvent wird bei einem 4B von einem HMW_LC_BL1_DR immer nach 2 Sekunden eine 53 abgesetzt. Dabei wird nicht nach logging oder logging_time geschaut. Das macht mir aber gar keine so großen Sorgen.
Ich überlege mir gerade, ob man vielleicht einfach in HM485_ProcessResponse ein RemoveInternalTimer machen sollte, bevor der Timer für die 53 gesetzt wird. Ich kann mir nämlich vorstellen, dass es hier Probleme bei langen Tastendrücken (also einem 4B alle 300ms) oder bei mehrfachen kurzen Tastendrücken gibt.
Das ganze ist meiner Meinung nach sowieso ein bisschen blöd gelöst. Eine kontinuierliche Levelabfrage gibt es nur, wenn ein 4B vom HMW_LC_BL1_DR selbst kommt oder der Wert über die Zentrale gesetzt oder abgefragt wird. Externe Peerings bleiben außen vor, glaube ich. Vielleicht müsste man sich grundsätzlich an die 69er Message hängen. Die erste müsste ja vom HMW_LC_BL1_DR selbst kommen, wenn das logging eingeschaltet ist.
Gruß,
Thorsten
Hallo Thorsten,
Der HMW-IO-12-Sw7-DR scheint gar nicht mit dem Rollladenaktor gepeert zu sein, also geht von dem höchstwahrscheinlich auch kein Problem aus. Ich hatte mir erhofft zu sehen, was bei einem echten externen Peering auf dem Bus passiert, aber das könnte auch erstmal egal sein.
Korrekt. Wie ganz am Anfang mal beschrieben habe ich nur jeweils 2 Taster am 'HMW-IO-12-Sw7-DR' und am 'HMW-LC-Bl1-DR' gepeert ohne 'Quer'-Peering zwischen beiden Devices.
Kannst Du das Problem irgendwie provozieren?
Leider nein, da das wie gesagt sporadisch und nicht konsistent reproduzierbar ist. Auf jeden Fall ist es mit ausgeschaltetem Logging beim 'HMW-LC-Bl1-DR' bis jetzt überhaupt noch nicht aufgetreten.
Könnte es z.B. sein, dass Du während der Rollladen läuft die Tasten am Rolladenaktor mehrfach gedrückt hast? ...oder hast Du einen langen Tastendruck ausprobiert?
Ja das war der Fall. Habe Taster teilweise mehrfach gedrückt, z.B. für 1x an und 1x aus, sowie länger gedrückt um eine definierte Dauer entsprechend der Länge des Tastendrucks zu simulieren.
Könntest Du mal versuchen, das Problem zu provozieren, während ein Log mitläuft?
Das ist mir ja schon gelungen - siehe Attachment von https://forum.fhem.de/index.php/topic,104376.msg983358.html#msg983358
Gruß,
Andreas
[19.10.19] P.S. was mir übrigens auch noch aufgefallen ist: wenn ich das Logging beim HMW-IO-12-Sw7-DR ausschalte, wird der Status bei Tasterbetätigung am Aktor in Fhem nie upgedated (denke mal das sollte so sein). Beim HMW-LC-Bl1-DR jedoch wird der Status in Fhem immer upgedated, egal ob Logging ein- oder ausgeschaltet ist. Der einzige Unterschied ist, dass der Update bei ausgeschaltetem Logging nicht während des Fahrens stattfindet. Beim Stoppen aber immer.
Hi,
ich habe die fortlaufende Level-Abfrage jetzt überarbeitet:
Es sollte jetzt nicht mehr zu "Überschwemmungen" des Busses kommen, wenn man eine Taste mehrfach oder lange drückt.
Es wird maximal alle 1,5 Sekunden abgefragt.
Wenn das logging abgeschaltet ist, dann ist es auch abgeschaltet.
Gruß,
Thorsten
Hallo Thorsten,
habe jetzt mal upgedated und das Logging wieder aktiviert. Schaut bis jetzt gut aus, sprich ich konnte bis jetzt keine Verzögerung mehr provozieren. Werde es weiter beobachten.
Beim HMW-LC-Bl1-DR jedoch wird der Status in Fhem immer upgedated, egal ob Logging ein- oder ausgeschaltet ist. Der einzige Unterschied ist, dass der Update bei ausgeschaltetem Logging nicht während des Fahrens stattfindet. Beim Stoppen aber immer.
Das ist jetzt auch gefixt.
Danke dafür.
Andreas