[HM-Wired] Bus wird lahmgelegt, wenn ein Gerät ausfällt

[Thorsten Pferdekaemper]

nach einem shutdown restart bleiben meine 6 Geräte auch nach 15 Minuten noch in "reading" stehen.

Blöd...

Code Auswählen Erweitern


2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1cea3b8)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1afb0d0)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1d0d780)
2015.07.23 22:18:19 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:21 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 02
2015.07.23 22:18:21 3: HM485: HBW_1W_T10_HBW7341310_03: temperature -> 19.87
2015.07.23 22:18:23 3: HM485_LAN: Event: I[0](0,Y,F,B)(98) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:23 3: HM485: HMW_IO_12_Sw14_DR_LEQ0251870_18: state -> off
Danach sind nur noch normale Events. in der Queue wird nichts mehr abgearbeitet.

So etwas ähnliches habe ich bei mir auch schonmal gesehen. Ich glaube, dass es damit zusammenhängt. dass FHEM während diesen ganzen Konfigurations-Anforderungen auch noch "ungefragte" Events empfängt. In dem Fall sind das die Temperatur-Meldungen vom HBW_1W_T10. (Wo hatte es gestern Abend denn unter 20 Grad???)
Irgendwas geht da schief mit den Message-Ids. Ich hoffe, dass ich noch dazu komme, das zu knacken.

Ein Device bleibt die ganze Zeit in "Response Timeout".

Warum es in den Zustand "Response Timeout" kommt kann viele Ursachen haben. Was ist das denn für ein Device?
Wenn es mal in "Response Timeout" ist, dann ändert sich das nur, wenn es wieder etwas empfängt. Normalerweise passiert das automatisch nach etwa 10 Sekunden durch den waitForConfig-Mechanismus. Wenn aber die Queue hängt, dann passiert einfach gar nichts mehr.
Man kann die Queue ggf. aus dem Schlaf holen, wenn man irgendeinem Device manuell was sendet, also einfach mal auf irgend einen Aktor ein "set ... level ..." machen.

Der Queue-Mechanismus verlässt sich momentan darauf, dass jede Message in der Queue entweder mit einer Response beantwortet wird oder intern ein NACK erzeugt wird. Anscheinend funktioniert dieser Mechanismus manchmal nicht. Ich könnte jetzt irgendwas mit Timeouts in die Queue-Verarbeitung einbauen, aber ich bevorzuge, die dadurch gefundenen Bugs auszubauen.

Gruß,
   Thorsten

[stephan-221]

Hallo Thorsten,

nach einem shutdown restart bleiben meine 6 Geräte auch nach 15 Minuten noch in "reading" stehen.

Update via Smartphone mal reingeschaut:

2 der 6 Geräte sind jetzt in OK.

Reading weiterhin bei HMW_LCBl1_DR und HMW_IO_12_Sw14_DR.

(IMHO die Geräte mit großem EEPROM?!)

Wo hatte es gestern Abend denn unter 20 Grad???

In meinem Bastelkeller

Du hast ja auch von der Irritation der Message IDs gesprochen. Das könnte in der Tat eben ein Problem sein.
Ich kann das mal ohne HBW testen. HBW und IO12/14 sind die beiden Elemente, die von sich aus gerne quatschen.

Alle Devices sind übrigens wieder in ACK.

Viele Grüße
Stephan

[Thorsten Pferdekaemper]

Reading weiterhin bei HMW_LCBl1_DR und HMW_IO_12_Sw14_DR.
(IMHO die Geräte mit großem EEPROM?!)

Es kann sein, dass Probleme bei Devices mit "großem EEPROM" mit höherer Wahrscheinlichkeit auftreten. Beim Konfig-Lesen gehen da einfach mehr Nachrichten über den Bus und es gibt damit auch mehr Chancen, dass irgendwas schief geht.

Alle Devices sind übrigens wieder in ACK.

Ja, das "Response Timeout" löst sich in der Regel von selbst, wenn das Device was sendet. Dabei ist egal, ob als Response, Ack oder Event.

[Ralf9]

Der Queue-Mechanismus verlässt sich momentan darauf, dass jede Message in der Queue entweder mit einer Response beantwortet wird oder intern ein NACK erzeugt wird. Anscheinend funktioniert dieser Mechanismus manchmal nicht. Ich könnte jetzt irgendwas mit Timeouts in die Queue-Verarbeitung einbauen, aber ich bevorzuge, die dadurch gefundenen Bugs auszubauen.

Hallo Thorsten,

Ich denke es ist trotzdem sinnvoll Timeouts in die Queue-Verarbeitung einzubauen, da man wahrscheinlich auch nach entfernung der Bugs nicht gänzlich ausschließen kann, das die Queue-Verarbeitung hängen bleibt.
Du kannst ja den timeout über Konstanten am Anfang der 10_HM485.pm konfigurierbar und deaktivierbar machen.
Der Timeout hätte auch den Vorteil, daß Du bei einem Timeout zusätzliche debug infos in den Log schreiben und den state auf timeout setzen kannst.

Beim Testen der Homebrew Module ist mir auch aufgefallen, daß es zu einer Endlosschleife kommt, wenn die DeviceId im Modul nicht zu der im Devicefile passt.

Könntest Du bitte auch mal bei Deiner Version die Versionsnr erhöhen (z.B. auf 150) und dann bei änderungen hochzählen?

Nachtrag: oder reinschreiben, daß es eine Testversion ist und dann eine eigene (Unter) Versionsnr.

Gruß Ralf

[Thorsten Pferdekaemper]

Ich denke es ist trotzdem sinnvoll Timeouts in die Queue-Verarbeitung einzubauen, da man wahrscheinlich auch nach entfernung der Bugs nicht gänzlich ausschließen kann, das die Queue-Verarbeitung hängen bleibt.

Ja, aber erst kommen die Bugs raus. Sonst ist der Leidensdruck nicht groß genug...
Ein Timeout an der Stelle ist auch gar nicht so einfach. Es kann auch ganz normal recht lange dauern, bis eine Queue abgearbeitet ist. ...aber dazu wird mir auch noch was einfallen.

Beim Testen der Homebrew Module ist mir auch aufgefallen, daß es zu einer Endlosschleife kommt, wenn die DeviceId im Modul nicht zu der im Devicefile passt.

Was meinst Du mit DeviceId?

Gruß,
   Thorsten

[Ralf9]

Was meinst Du mit DeviceId?

Ich habe es verwechselt, ich meinte eigentlich den Devicetype. z.B.  0x81 für  HBW-1W-T10. Wenn es dann kein Devicefile mit 129 gibt, dann kommt es zur einer Endlosschleife.

Gruß Ralf

[Thorsten Pferdekaemper]

Hi,

ich habe den Bug gefunden, wo das Teil durcheinanderkommt, wenn das Device Events sendet, während eine "Konfig-Queue" abgearbeitet wird. Es kam vor, dass das Device eine Message sendet ganz kurz bevor FHEM einen Befehl schickt. Dann hat ein Teil in FHEM die Message vom Device als Response interpretiert, obwohl der Befehl eigentlich noch gar nicht richtig abgeschickt war.
...war ziemlich schwierig zu finden, sollte aber jetzt funktionieren.
Ein Teil der Probleme sind auch die Homebrew-Module, die sich nicht so 100% an die Timing-Vorgaben des Protokolls halten. Es kann passieren, dass ein Gerät sendet, obwohl der Bus anderweitig belegt ist.

Ich habe auch die vielen Log-Ausgaben auf Level 5 gesetzt, so dass das Log nicht ganz so zugemüllt wird.
Leider bin ich noch nicht dazugekommen, Ralfs Änderungen zu integrieren. Um das oben beschriebene Problem zu lösen braucht man aber die 10_HM485.pm gar nicht. Der Fix ist in den anderen beiden Dateien.

So, jetzt ist es wieder spät geworden. Vielleicht will das jemand testen.

Gruß,
   Thorsten

[stephan-221]

Hallo Thorsten,

die Frühschicht meldet sich zum Dienst....

Ich habe die drei Files eingespielt.
Danach einen kompletten Reload gemacht und alle 7 Module sind in Config OK.
Mal gucken, was den Tag über passiert.

Viele Grüße
Stephan

[Thorsten Pferdekaemper]

Hi,

ich bin jetzt so langsam etwas durcheinander gekommen mit meinen eigenen Versionen und was denn noch so offen ist.
Es gibt im Git jetzt einen neuen (oder eher einen auferstandenen) Branch "dev". In den habe ich "meine" aktuelle Version reingepackt. Die Version heißt jetzt 0.6.0.
https://github.com/kc-GitHub/FHEM-HM485/tree/dev
Wenn die nächsten Tage dazu keine "Problemmeldungen kommen", dann packe ich das in den master-Branch.

Die folgenden Sachen sind noch offen:

1. Wenn ein Device auf eine Message tatsächlich mit einem ACK antwortet, dann kann es sein, dass die Queue hängenbleibt. Da bin ich mir aber nicht so ganz sicher, da meine Devices das nicht tun.
Prio niedrig, da es ein "kaputtes" Device voraussetzt.

2. Intelligenteres Lesen des EEPROM ("E-Befehl").
Prio niedrig, da es auch so ganz gut funktioniert. Außerdem: So oft passiert das dann doch nicht.

3. Wiederholen des Konfig-Lesens bzw. regelmäßige Konfig-Lesen-Versuche nach "Device vom Bus" abschaltbar machen.
Prio wird für mich höher, da ich ein Gerät plane, das öfter komplett abgeschaltet wird.

4. Irgendein Mechanismus, der das Ändern der Konfiguration in FHEM verhindert, wenn CONFIG_STATUS nicht auf ok.
Prio "ganz nett" und ich weiß noch nicht so recht, wie das elegant gelöst werden könnte.

5. Zeit bis zur Wiederholung des Konfig-Lesens vergrößern oder einstellbar machen.
Prio: Vielleicht brauchen wir das gar nicht. 10 Sekunden sind gar nicht sooo schlecht. Ansonsten kann man es dem Device überlassen, sich wieder zu melden.

6. Timeout-Lösung für die Konfig-Queue. Das wäre sozusagen für ungeklärte Hänger der Queue. Allerdings ist das gar nicht so einfach, da es auch ganz normal sein kann, dass es eine Weile dauert, bis die Queue abgearbeitet ist.
Prio: Da bin ich mir nicht so sicher. Besser ist manchmal ein hoher Leidensdruck, Bugs auszubauen.

7. Endlosschleife, wenn es zum Modul kein Device-File gibt. D.h. wenn ein Device einen Devicetype (so wie 0x81) zurückmeldet, zu dem es keine Datei gibt.
Prio: Mittel. Solche Devices sollte es nicht geben, aber es deutet auf ein Problem hin.

8. Probleme bei Key-Events. (http://forum.fhem.de/index.php/topic,39397.0). Am besten Ralfs Coding testen und übernehmen.
Prio: Hoch, sonst kommen wir mit den Versionen durcheinander.

Wahrscheinlich ist da noch mehr, aber das ist erstmal, was ich aus dem Thread hier herauslese.

Ein Problem tritt auf, weil die Homebrew-Devices sich manchmal etwas frech verhalten. Das gehört aber nicht hier hin.

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

8. Probleme bei Key-Events. (http://forum.fhem.de/index.php/topic,39397.0). Am besten Ralfs Coding testen und übernehmen.
Prio: Hoch, sonst kommen wir mit den Versionen durcheinander.

Das ist jetzt erledigt, siehe http://forum.fhem.de/index.php/topic,39397.msg316063.html#msg316063

[Thorsten Pferdekaemper]

7. Endlosschleife, wenn es zum Modul kein Device-File gibt. D.h. wenn ein Device einen Devicetype (so wie 0x81) zurückmeldet, zu dem es keine Datei gibt.
Prio: Mittel. Solche Devices sollte es nicht geben, aber es deutet auf ein Problem hin.

So, das dürfte jetzt auch erledigt sein. (https://github.com/kc-GitHub/FHEM-HM485/tree/dev.)

Wenn es zum Devicetype keine Datei gibt, dann wird das Teil als HMW_Generic angelegt. Außerdem erscheint eine Meldung im Log. HMW_Generic-Devices haben keine Kanäle, man kann aber raw-Befehle auf sie loslassen.

Gruß,
   Thorsten

[Ralf9]

Beim Programmieren meines IO-Moduls bin ich auf ein Hardcoding in der sub getFrameInfos($$;$$$) in der device.pm gestossen:

Code Auswählen Erweitern


my $frameTypeName  = getValueFromDefinitions( $deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/frequency/physical/get/response');


Wenn man in einem Modul als response ein zusätzlichen info_level mit 2 oder 3 Byte benötigt, funktioniert dies nur wenn der frameTypeName vom entsprechenden response Eintrag im devicefile geholt wird.
Ich habe es so gelöst. Ich hoffe es ist so ok. Es müsste nocht getestet werden ob es mit dem frequenzeingang wie gewünscht funktioniert.

Code Auswählen Erweitern



sub getFrameInfos($$;$$$) {
my ($deviceKey, $data, $event, $behaviour, $dir) = @_;

my $frameType = hex( substr( $data, 0, 2)); # 4B
my %retVal;
my $chNr =  hex( substr( $data, 2, 2)) + 1;
my $chTyp          = HM485::Device::getChannelType( $deviceKey, $chNr);
my $values;
my $frameTypeName = "info_level";

$values = getValueFromDefinitions($deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/');
if (defined($values)) {
foreach my $value (keys %{$values}) {
#HM485::Util::logger('HM485:Device: getFrameInfos = ', 3, ' $values = ' . $value);
if ( defined( $values->{$value}{physical}{get}{response})) {
$frameTypeName = $values->{$value}{physical}{get}{response};
last;
}
}
}
#HM485::Util::logger('HM485:Device:getFrameInfos', 3, ' frameTypeName = ' . $frameTypeName);

# my $frameTypeName  = getValueFromDefinitions( $deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/frequency/physical/get/response');

# $frameTypeName = $frameTypeName ? $frameTypeName : 'info_level';
if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}
..



Gibt es eigentlich im git auch die Möglichkeit die Dateien einzeln herunterzuladen, anstatt alles zusammen im Download.zip?

Gruß Ralf

[Thorsten Pferdekaemper]

Hi Ralf,
ich habe Deinen Änderungsvorschlag eingebaut und ins Git hochgeladen. Version ist jetzt 0.6.4.

Um nur eine Date vom Git zu holen gehe ich normalerweise folgendermaßen vor: Ich navigiere zu der Datei. Wenn die Datei angezeigt wird, dann sieht man über dem Text den Button "Raw". Auf der nächsten Seite dann einfach Rechtsklick und dann Datei-> Speichern unter.
..zumindest mit Internet Explorer.

Gruß,
  Thorsten