ungewünschtes Delay bei Ausführung von Schaltbefehlen

[abc2006]

Hi,

also, ich habs nochmal getestet, dabei ergibt sich nun ein reproduzierbares Fehlerbild:

ich habe in meiner Installation sämtliche Taster mit NYM5x1,5 in meinen Elektroschrank gelegt. Diese sind auf WAGO-Reihenklemmen (2003-7641/42) aufgelegt. Masse/GND/V- habe ich per Steckbrücker auf alle Klemmen und somit die angeschlossenen Taster verteilt. Die Rückader vom Taster klemmt dann jeweils auf einem Eingang des 12/7er. Eingang 12 ist abweichend direkt per Klingelleitung aufgelegt und geht nicht über die Klemmsteine. Der zugehörige Taster befindet sich etwa seit anfang meiner Probleme direkt an meinem PC, zum einfacheren Testen.

Folgendes Vorgehen lässt sich jetzt reproduzieren:

Ich klemme Eingang 1 ab und drücke Taster 12 etwa 10 mal im Abstand von 1 Sekunde. Hierbei ist beispielsweise zu beobachten, dass die Tastendrücke bis zu 10 Sekunden delay aufweisen.
Nun klemme ich Eingang 1 wieder an und entferne Eingang zwei. Wieder drücke ich Taster 12 usw.
Bei irgendeinem Eingang (bsp 5) reagiert Fhem/HM dann abweichend sofort, so wie es ja eigentlich sein soll.
Lasse ich diesen Eingang 5 nun ab, funktioniert HM einwandfrei - für ca einen Tag. Dann haben die übrigen Taster wieder das delay, auch ohne den vorher entfernten Eingang 5.
Nun kann ich Eingang 5 wieder anklemmen und führe die Prozedur erneut durch.
Diesesmal ist bsp. Eingang 8 der problematische, klemme ich diesen ab, funktioniert alles einwandfrei ^^ für einen Tag.

Das ist zwar nicht zufriedenstellend, wäre aber als Ansatz zu gebrauchen gewesen, den Fehler weiter einzugrenzen.
Dann kam mit das nächste Problem dazwischen:

Ich wollte gerne die HMW-Eingänge sortieren - das Attribut room kann ich aber nicht mehr über das WEB-Interface ändern. Während es bei allen! sonstigen Geräten einwandfrei funktioniert (Dropdown "room", ins Textfeld klicken, aus der Liste einen zusätzlichen Raum anhaken, OK klicken, dann steht der Raum mit im Textfeld, dann attr klicken und der Raum wird beim attr "room" hinzugefügt und im entsprechenden Raum angezeigt) hapert es ausschließlich bei Homematic Wired an den letzten zwei Schritten: der klick auf attr tut einfach nichts.
Wenn ich im Input-Feld ( ganz oben) eingebe

Code: [Auswählen]

attr HMW01.O02_Mischer_warm room HM485,Heizung funktioniert es. [/s]
edit: Fehler gefunden: es liegt am perlSyntaxCheck... sobald ich den rausnehme, geht alles wie gewohnt

AAAlso habe ich einen Fehler in meinem Fhem vermutet. Deshalb habe ich mal wieder meinen Raspi zu Hilfe genommen und dort fhem erneut komplett neu installiert (incl. purge und fhem update).

Dort wiederum bekomme ich das 12/14 einwandfrei erkannt ( an dem hängt mein Wärmemengenzähler), die 12/7er liefern den bekannten Fehler

Code: [Auswählen]

MyHMLAN: Device 0000D125 not defined yet. We need the type for autocreateKannst du mir erklären, welcher Fehler hier genau besteht? Was ist anders als bei dem 12/14er, bei dem das autocreate anscheinend funktioniert?
Damit ich es wenigstens verstehe, vielleicht können wir ja auch noch einen Fehler finden...


Wenn ich dann eingebe

Code: [Auswählen]

define 1271 HM485 0000D125legt er das device an, lädt sich aber beim config-auslesen zu tode (habs über die ganze Nacht laufen lassen, am nächsten morgen stand immer noch "READING" drin...


Ich hab jetzt mal KNX bestellt, vielleicht bekomme ich damit schonmal etwas zuverlässig zum laufen. Abgesehen davon jedoch ist KNX verdammt teuer, und ich habe auch eigentlich wenig lust, die mittlerweile über 700 Euro, die ich in HMW investiert habe, einfach wegzuwerfen... Wäre von daher trotzdem begeistert, wenn wir nen Fehler finden würden.

Hast du ne Testumgebung? Dann könnte ich dir ggf. mal ein paar der Teile zukommen lassen, wenn du Interesse hast könntest du die dann mal bei dir testen... melde dich per PN, wenn du willst :-)

Danke auf jeden Fall nochmal für den Support bis hierher, ohne dich hätte ich vermutlich schon längst aufgegeben... 

Grüße
Stephan

[Thorsten Pferdekaemper]

Ich klemme Eingang 1 ab und drücke Taster 12 etwa 10 mal im Abstand von 1 Sekunde. Hierbei ist beispielsweise zu beobachten, dass die Tastendrücke bis zu 10 Sekunden delay aufweisen.

Das mit den 10 Sekunden Delay kommt mir sehr seltsam vor. Ein HMW-Device probiert es niemals so lange. Entweder sendet es den Tastendruck genau einmal oder maximal dreimal. Letzteres dauert höchstens etwa 600ms. Dann gibt das Device auf. Ich denke also, dass alles, was mehr als eine Sekunde Delay erzeugt nicht wirklich am HM-Wired liegen kann.
Höchstens vielleicht, wenn der Bus die ganze Zeit belegt ist, aber da bin ich mir nicht wirklich sicher.

Nun klemme ich Eingang 1 wieder an und entferne Eingang zwei. Wieder drücke ich Taster 12 usw.
Bei irgendeinem Eingang (bsp 5) reagiert Fhem/HM dann abweichend sofort, so wie es ja eigentlich sein soll.
Lasse ich diesen Eingang 5 nun ab, funktioniert HM einwandfrei - für ca einen Tag. Dann haben die übrigen Taster wieder das delay, auch ohne den vorher entfernten Eingang 5.
Nun kann ich Eingang 5 wieder anklemmen und führe die Prozedur erneut durch.
Diesesmal ist bsp. Eingang 8 der problematische, klemme ich diesen ab, funktioniert alles einwandfrei ^^ für einen Tag.

Ich würde mal vermuten, dass es nicht die An/Abklemmerei ist. Lässt Du bei der Aktion alles am Strom oder schaltest Du vorher irgendwas ab?

Früher gab es öfter Probleme mit dem automatischen Lesen der Device-Konfiguration. Kannst Du mal probieren, ob diese Probleme auch noch auftreten, wenn Du das Attribut autoReadConfig für alle HMW-Devices auf "never" stellst? ...oder Du stellst sicher, dass es für keins der Devices gesetzt ist und setzt es im HM485_LAN auf "never". 

Code: [Auswählen]

MyHMLAN: Device 0000D125 not defined yet. We need the type for autocreateKannst du mir erklären, welcher Fehler hier genau besteht?

Das ist kein Fehler. Es bedeutet nur, dass FHEM ein Device mit der Hmwid 0000D125 gefunden hat, aber den Typ nicht kennt. Daraufhin müsste FHEM ein Kommando ans Device schicken, um den Typ zu erfahren. Ich denke, dass es danach schief geht. 

Was ist anders als bei dem 12/14er, bei dem das autocreate anscheinend funktioniert?

Tja, wahrscheinlich antwortet der 12/14 er auf die Frage nach dem Gerätetyp und der 0000D125 tut es eben nicht. Möglicherweise ist mit dem 0000D125 etwas faul.

Wenn ich dann eingebe

Code: [Auswählen]

define 1271 HM485 0000D125legt er das device an, lädt sich aber beim config-auslesen zu tode (habs über die ganze Nacht laufen lassen, am nächsten morgen stand immer noch "READING" drin...

Ich vermute mal, dass der 0000D125 auf gar nichts antwortet.

Ich hab jetzt mal KNX bestellt, vielleicht bekomme ich damit schonmal etwas zuverlässig zum laufen. Abgesehen davon jedoch ist KNX verdammt teuer, und ich habe auch eigentlich wenig lust, die mittlerweile über 700 Euro, die ich in HMW investiert habe, einfach wegzuwerfen... Wäre von daher trotzdem begeistert, wenn wir nen Fehler finden würden.

Ja, das wäre schade. Bei mir funktioniert mit HMW alles, außer eben dem HMW-LAN-Adapter.

Hast du ne Testumgebung? Dann könnte ich dir ggf. mal ein paar der Teile zukommen lassen, wenn du Interesse hast könntest du die dann mal bei dir testen... melde dich per PN, wenn du willst :-)

Ja, eine Testumgebung habe ich. Ich schreib' Dir mal ne PM.

[abc2006]

Lässt Du bei der Aktion alles am Strom oder schaltest Du vorher irgendwas ab?

ich ... hm. glaube dass ich den Strom anlasse. Hab aber schon so viel gemacht, dass es auch gut anders sein kann. Okay, auf noch eine Runde kommts ja jetzt auch nicht mehr an.

Früher gab es öfter Probleme mit dem automatischen Lesen der Device-Konfiguration. Kannst Du mal probieren, ob diese Probleme auch noch auftreten, wenn Du das Attribut autoReadConfig für alle HMW-Devices auf "never" stellst? ...oder Du stellst sicher, dass es für keins der Devices gesetzt ist und setzt es im HM485_LAN auf "never". 

Okay, war nicht gesetzt hab ich gemacht. Schauen wir mal, obs nach meiner "Runde" jetzt stabiler bleibt.

Das ist kein Fehler. Es bedeutet nur, dass FHEM ein Device mit der Hmwid 0000D125 gefunden hat, aber den Typ nicht kennt. Daraufhin müsste FHEM ein Kommando ans Device schicken, um den Typ zu erfahren. Ich denke, dass es danach schief geht.

Du hattest in einem anderen Thread geschrieben, dass es "kein Problem" oder "ziemlich leicht" wäre, den Bus mitzusniffen?
Dann könnte ich schonmal herausfinden, ob und was er antwortet.

Tja, wahrscheinlich antwortet der 12/14 er auf die Frage nach dem Gerätetyp und der 0000D125 tut es eben nicht. Möglicherweise ist mit dem 0000D125 etwas faul.
Ich vermute mal, dass der 0000D125 auf gar nichts antwortet.

Ich glaube, dass er zb auf Schaltbefehle (die er noch relativ zuverlässig ausführt, wenn sie vom FHEMWEB kommen), ein ACK o.ä. sendet, da die Glühbirne zuerst ein Ausrufezeichen bekommt und nach einer halben bis ganzen Sekunde das Ausrufezeichen wieder verschwindet. Auch dafür wärs ja cool, den Bus mal mitzuschneiden..

Danke

Stephan

[Thorsten Pferdekaemper]

Okay, war nicht gesetzt hab ich gemacht. Schauen wir mal, obs nach meiner "Runde" jetzt stabiler bleibt.
Du hattest in einem anderen Thread geschrieben, dass es "kein Problem" oder "ziemlich leicht" wäre, den Bus mitzusniffen?
Dann könnte ich schonmal herausfinden, ob und was er antwortet.

Dazu braucht man einen Arduino und einen RS485-Transceiver. Dann noch einen kleinen Sketch, der alles anzeigt, was über den Transceiver kommt.

Ich glaube, dass er zb auf Schaltbefehle (die er noch relativ zuverlässig ausführt, wenn sie vom FHEMWEB kommen), ein ACK o.ä. sendet, da die Glühbirne zuerst ein Ausrufezeichen bekommt und nach einer halben bis ganzen Sekunde das Ausrufezeichen wieder verschwindet.

Das ist jetzt etwas seltsam. Wie sendest Du denn von FHEM aus ein Kommando, wenn FHEM das Device gar nicht erkennt?

[abc2006]

Dazu braucht man einen Arduino und einen RS485-Transceiver. Dann noch einen kleinen Sketch, der alles anzeigt, was über den Transceiver kommt.

Das hätte ich soweit vorrätig. Ich schau mal, ob ich so nen sketch finde. In welchem Format kannst du was mit den Infos anfangen?

Das ist jetzt etwas seltsam. Wie sendest Du denn von FHEM aus ein Kommando, wenn FHEM das Device gar nicht erkennt?

Wenn ich eine neue Config anlege, erkennt er die Geräte nicht. Ich habe aber noch meine alte config, in der die Geräte bereits definiert sind. Und die funktioniert dann (mit den bekannten Einschränkungen) ... Und in dieser alten Config habe ich jetzt das autoReadConfig auf never gestellt. Bisher läufts ... :-)

[Thorsten Pferdekaemper]

Das hätte ich soweit vorrätig. Ich schau mal, ob ich so nen sketch finde. In welchem Format kannst du was mit den Infos anfangen?

Wenn man den Busverkehr im Hex-Format hat, dann kann man damit schon was anfangen.

[abc2006]

Bis heute läuft alles einwandfrei. 
Ich habe lediglich zwei Schalter aus dem Schlafzimmer abgeklemmt.
Sobald ich diese wieder verbinde, habe ich wieder Probleme.
Wenn ich dazu komme, werde ich noch einmal probieren, ob jetzt auch das erkennen der Geräte besser klappt.

Danke jedenfalls für alle Antworten und Hilfen!

Viele Grüße
Stephan

[abc2006]

so, nachdem es die ganze zeit einwandfrei lief, habe ich seit gestern, 20:57 wieder folgende Meldungen im Log.
Gemacht habe ich zu dem Änderungen an diversen notifies, aber nichts, was mit HMW zu tun gehabt hätte.

Code: [Auswählen]

2016.04.29 20:57:10.971 3: MyHMLAN: Unknown HM485 device detected, define one to get detailed information.
2016.04.29 20:57:11.897 3: MyHMLAN: Unknown HM485 device detected, define one to get detailed information.
2016.04.29 20:57:12.743 3: MyHMLAN: Unknown HM485 device detected, define one to get detailed information.
Seitdem kann ich z.B. keine Attribute mehr über die WEB-Oberfläche setzen, die Schalter und Taster gehen nicht mehr usw...
Mal schauen, ob ich dieses Wochenende Zeit finde, den Sniffer zu bauen...
Oder hat dieser Fehler ne neue Bedeutung?  Den hatte ich ja schließlich noch nicht 

Grüße
Stephan

[Thorsten Pferdekaemper]

Hi,
ich habe mir gerade mal die Sourcen angeschaut. Ich habe im ganzen HM485-Kram keine solche Meldung gefunden. Keine Ahnung, wo die herkommt.
Kann es sein, dass Du direkt in der fhem.cfg rumbastelst und Dir damit manchmal was kaputt haust?
Gruß,
   Thorsten

[abc2006]

Kann es sein, dass Du direkt in der fhem.cfg rumbastelst und Dir damit manchmal was kaputt haust?

  Obwohl sich das ja schon sehr vorwurfsvoll anhört  nein, ich habe nicht "rumgebastelt" *fg*

Nein, schon okay, muss man ja auch ausschließen , aber ich habe vor einigen Monaten einen Hinweis bekommen, dass das editieren der fhem.cfg nicht erwünscht wäre ( ah ja, das war bei der "editConfig 1"-Diskussion) und seitdem nutze ich schön brav ausschließlich!! den DEF-Editor und die Input-Leiste...
Ich häng mal meine fhem.cfg an, genau so, wie sie jetzt gerade ist. Darin sind noch ein paar Reste von OWDevice, die ich mal ausgelagert hatte und dann nach obigem Entschluss wieder zusammengeführt habe, danach kommt dann nur noch fhem-Erzeugnis...

Code: [Auswählen]

root@mediacenter:/opt/fhem# ll
total 508K
drwxr-xr-x 11 root root    4,0K Apr 26 21:00 ./
drwxr-xr-x  7 root root    4,0K Apr 17 14:49 ../
drwxr-xr-x  2 fhem dialout 4,0K Apr 25 10:17 backup/
-rw-r--r--  1 fhem dialout  45K Apr 17 14:55 backup.fhem.cfg
-rw-r--r--  1 fhem dialout 143K Apr 25 10:18 CHANGED
-rw-r--r--  1 fhem dialout  33K Apr 17 14:23 configDB.pm
drwxr-xr-x 39 fhem dialout 4,0K Apr 29 17:35 contrib/
-rw-r--r--  1 root root     916 Apr 25 10:40 db_fhem.conf
drwxr-xr-x  3 fhem dialout 4,0K Apr 17 14:23 demolog/
drwxr-xr-x  4 fhem dialout 4,0K Apr 17 14:23 docs/
drwxr-xr-x  5 fhem dialout  20K Apr 29 17:49 FHEM/
-rw-r--r--  1 fhem dialout  61K Apr 30 08:06 fhem.cfg
-rw-r--r--  1 fhem dialout  16K Apr 17 14:23 fhem.cfg.demo
-rw-r--r--  1 fhem dialout 9,6K Apr 17 14:23 fhem.cfg.orig
-rwxr-xr-x  1 fhem dialout 120K Apr 25 10:18 fhem.pl*
drwxr-xr-x  2 fhem dialout 4,0K Apr 30 00:00 log/
-rw-r--r--  1 fhem dialout  935 Apr 17 14:23 README_DEMO.txt
drwxr-xr-x  5 fhem dialout 4,0K Apr 25 10:18 restoreDir/
drwxr-xr-x  2 fhem dialout 4,0K Apr 17 14:23 unused/
drwxr-xr-x  8 fhem dialout 4,0K Apr 17 14:23 www/
root@mediacenter:/opt/fhem#


[Thorsten Pferdekaemper]

Hi,
sorry, hätte nicht so rüberkommen sollen.
Bei Deiner fhem.cfg fällt mir auf, dass Du eine gar nicht so kleine Installation hast. Außerdem ist anscheinend so ziemlich alles über notify und DOIF gesteuert. Möglicherweise kommt das System nicht mehr so ganz mit. ...aber das ist auch nur eine wilde Vermutung.
Jetzt sollte man vielleicht erst einmal herausfinden, wor diese Meldung herkommt. Vom HM485-Modul meiner Meinung nach nicht. Kannst Du mal in Deiner Installation nach "define one to get detailed information" suchen? Dann wüssten wir wenigstens, wie das ausgelöst wird.
Gruß,
   Thorsten

[abc2006]

Außerdem ist anscheinend so ziemlich alles über notify und DOIF gesteuert.

Frage: wie sonst? Hab ich nen wichtigen Punkt übersehen? Wird das "üblicherweise" anders gemacht?

Jetzt sollte man vielleicht erst einmal herausfinden, wor diese Meldung herkommt. Vom HM485-Modul meiner Meinung nach nicht. Kannst Du mal in Deiner Installation nach "define one to get detailed information" suchen? Dann wüssten wir wenigstens, wie das ausgelöst wird.

Code: [Auswählen]

root@mediacenter:/opt/fhem# grep -r "define one to get detailed information" * -n --exclude-dir=log
fhem.pl:3348:                        "define one to get detailed information.";
restoreDir/2016-04-25/fhem.pl:3348:                        "define one to get detailed information.";
root@mediacenter:/opt/fhem#
fhem.pl, Zeile 3348. im SVN checkout ists fhem.pl Zeile 3349.
Hilft das?

fhem.pl:

Code: [Auswählen]

  if(!int(@found) || !defined($found[0])) {
3329     my $h = $hash->{MatchList}; $h = $module->{MatchList} if(!$h);
3330     if(defined($h)) {
3331       foreach my $m (sort keys %{$h}) {
3332         if($dmsg =~ m/$h->{$m}/) {
3333           my ($order, $mname) = split(":", $m);
3334
3335           if($attr{global}{autoload_undefined_devices}) {
3336             my $newm = LoadModule($mname);
3337             $mname = $newm if($newm ne "UNDEFINED");
3338             if($modules{$mname} && $modules{$mname}{ParseFn}) {
3339               no strict "refs"; $readingsUpdateDelayTrigger = 1;
3340               @found = &{$modules{$mname}{ParseFn}}($hash,$dmsg);
3341               use strict "refs"; $readingsUpdateDelayTrigger = 0;
3342               last if(defined($found[0]));
3343             } else {
3344               Log 0, "ERROR: Cannot autoload $mname";
3345             }
3346
3347           } else {
3348             Log3 $name, 3, "$name: Unknown $mname device detected, " .
3349                         "define one to get detailed information.";
3350             return undef;
3351
3352           }
3353         }
3354       }
3355     }


[Thorsten Pferdekaemper]

Frage: wie sonst? Hab ich nen wichtigen Punkt übersehen? Wird das "üblicherweise" anders gemacht?

Wenn möglich, dann ist es bei HMW gut, wenn man direkte Peerings verwendet. Das schont die Systemperformance.

fhem.pl:

Code: [Auswählen]

  if(!int(@found) || !defined($found[0])) {
3329     my $h = $hash->{MatchList}; $h = $module->{MatchList} if(!$h);
3330     if(defined($h)) {
3331       foreach my $m (sort keys %{$h}) {
3332         if($dmsg =~ m/$h->{$m}/) {
3333           my ($order, $mname) = split(":", $m);
3334
3335           if($attr{global}{autoload_undefined_devices}) {
3336             my $newm = LoadModule($mname);
3337             $mname = $newm if($newm ne "UNDEFINED");
3338             if($modules{$mname} && $modules{$mname}{ParseFn}) {
3339               no strict "refs"; $readingsUpdateDelayTrigger = 1;
3340               @found = &{$modules{$mname}{ParseFn}}($hash,$dmsg);
3341               use strict "refs"; $readingsUpdateDelayTrigger = 0;
3342               last if(defined($found[0]));
3343             } else {
3344               Log 0, "ERROR: Cannot autoload $mname";
3345             }
3346
3347           } else {
3348             Log3 $name, 3, "$name: Unknown $mname device detected, " .
3349                         "define one to get detailed information.";
3350             return undef;
3351
3352           }
3353         }
3354       }
3355     }


Das sieht so aus, als ob das Attribut autoload_undefined_devices vom Device global nicht gesetzt ist. Mach mal ein "list global" und schau nach autoload_undefined_devices.
Gruß,
  Thorsten

[abc2006]

Das sieht so aus, als ob das Attribut autoload_undefined_devices vom Device global nicht gesetzt ist. Mach mal ein "list global" und schau nach autoload_undefined_devices.

stimmt, steht auf 0. Soll ich es auf 1 stellen?

autoload_undefined_devices
wenn dieses Attribut gesetzt ist, werden die zu einer neu empfangenen Nachricht zugehörigen Module automatisch geladen.  Dies erfolgt vom autocreate Gerät, um so automatisch ein FHEM-Gerät bei erreichen einer entsprechenden Nachricht zu erstellen.

will ich ja eigentlich auch gar nicht.. Alle meine Geräte sind definiert und funktionieren. Was ist das also für eine Meldung, die von einem definierten Gerät kommt und trotzdem ein autocreate auslöst?

[Thorsten Pferdekaemper]

stimmt, steht auf 0. Soll ich es auf 1 stellen?

Na dann müsste zumindest die Meldung verschwinden.

will ich ja eigentlich auch gar nicht.. Alle meine Geräte sind definiert und funktionieren. Was ist das also für eine Meldung, die von einem definierten Gerät kommt und trotzdem ein autocreate auslöst?

Ich dachte, dass etwas nicht funktioniert. Du hattest ja geschrieben:

Seitdem kann ich z.B. keine Attribute mehr über die WEB-Oberfläche setzen, die Schalter und Taster gehen nicht mehr usw...

Also scheint es doch nicht so Recht zu funktionieren.
Na wie dem auch sei. Wenn Du wissen willst, was da ein autocreate auslöst, dann müsstest Du mal das Loglevel erhöhen und nachschauen, welche HMWID da was will.
Möglicherweise gibt es da auch ein Timing-Problem. Es ist vorstellbar, dass da ein Gerät noch nicht ganz angelegt ist (beim Ausführen der fhem.cfg), aber trotzdem schon irgendwas sendet. ...aber das müsste sich dann eigentlich von selbst reparieren.
Auf jeden Fall glaube ich nicht, dass das autoload_undefined_devices etwas schadet.
Gruß,
   Thorsten