Hallo zusammen,
ich habe seit gester ein sehr komisches Verhalten meines Homematic Wired Systems.
Sobald ich einen Eingang eines HMW_IO_12_Sw7_DR Moduls mit einem Ausgang peere, dann produziere ich scheinbar eine "Schleife", die dazu führt, dass der Ausgang alle 20 Sekunden ein und ausgeschaltet wird. Diese "Schleife" läuft permanent weiter, bis dass das Modul vom der Stromversorgung getrennt wird.
Eine Auflösen des Peering unterbricht die Schleife nicht.
Es ist egal, ob sich der Ein- und Ausgang auf dem gleichen Modul befindet oder sich über unterschiedliche Module erstreckt.
Auch ist es egal, welcher Ein- oder Ausgang genutzt wird. Das Verhalten ist reproduzierbar.
Sämtliche existierende Konfiguration funktioniert weiterhin, nur ein neues Peering ist nicht möglich.
Aufgetreten ist das ganze gestern Abend, kurz davor gab es einen Kurzschluss und die Hauptsicherung ist rausgeflogen.
Nun habe ich die Befürchtung, dass irgendeine Komponente Schaden genommen hat.
Das Fhem läuft auf einem Raspberry, die Verbindung läuft über ein hmw-lgw-o-dr-gs-eu.
Vom Gefühl her glaube ich, dass entweder der Raspberry kaputte Pakete schickt, so dass der Aktor falsch programmiert wird, oder dass das Lan GW etwas kaputt macht.
Gibt es irgendeine Möglichkeit das Verhalten zu analysieren und die kaputte Komponente zu verifizieren?
Das Problem hatte ich auch.
Hier steht die Auflösung dazu:https://forum.fhem.de/index.php/topic,69224.0.html (https://forum.fhem.de/index.php/topic,69224.0.html)
Das Problem scheint das gleiche zu sein, allerdings funktioniert die Lösung nicht.
Der Befehl, den ich nutze ist: set peer HMW_IO_12_Sw7_DR_XXX_08 KU.Licht
Ein press short löst nun die "Schleife" aus.
Wenn ich allerdings ein set unpeer mache, dann läuft die Schleife dennoch weiter.
Ein unpeer und erneuter Peer hat es also nicht gelöst.
Danach habe ich wie vorgeschlagen die Datei hmw_io12_sw7_dr_V3_02.pm gelöscht, aber weder ein shutdown restart, noch ein Reboot des Raspberry hat eine Veränderung gebracht.
Sobald ich wieder neu peere und einen press short auslöse, startet die "Schleife" von vorne.
Hi,
zeig mal wie Deine peersettings aussehen.
Gruß,
Thorsten
Hallo,
einmal die Settings bei einem funktionierenden Peering und dann von dem "kaputten".
Gibt es eine elegante Möglichkeit die einzelnen Settings zurückzusetzen, oder muss ich jeden einzelnen Wert anpassen?
Welcher Wert ist denn derjenige, der die "Schleife" produziert?
Hi,
bist Du sicher, dass Du die zwei nicht verwechselt hast? Die 19,2s short_on_time kommen mir verdächtig vor.
Gruß,
Thorsten
Hi,
ich war auch über die 19 Sekunden verwundert, weil es ziemlich genau zu der Zeit der "Schleife" passt, aber der Wert ist bei allen funktionierenden Peerings so.
Die Screenshots sind also nicht verwechselt.
Die Ausgänge bleiben auch länger als die 19 Sekunden an.
Gruß
Wenn ich versuche die Werte bei Peersettings zu ändern, erhalte ich folgende Fehlermeldung:
fhem?detail=WZ.Taster.Terasse.mr line 1:
ReferenceError: FW_HM485setChange is not defined
Hi,
seltsam...
Was zeigt das Teil denn als Firmware Version an? Z.B. im Internal FW_VERSION?
...oder gib uns einfach mal ein "list".
Gruß,
Thorsten
Hier das list von dem IO Modul.
Ich versuche Channel 1 mit 13 zu peeren.
Macht es Sinn, dass ich zur alten Version von Fhem zurück gehe?
Also vor der Version 5.8?
Hi,
ich glaube nicht, dass das abhängig von der FHEM-Version ist. Das Problem ist eher, dass durch eine falsche Zuordnung der Gerätebeschreibungsdatei etwas im EEPROM nicht mehr stimmt.
Ich würde folgendes empfehlen:
1. Die hmw_io12_sw7_dr_V3_02.pm hast Du ja schon gelöscht. Lass die auch weiterhin weg. Falls Du sie wieder zurückgeholt hast, dann wieder löschen und shutdown restart.
2. Das Gerät zurücksetzen: (Aber NICHT in FHEM löschen!) Entweder mit den Knöpfchen am Gerät laut Bedienungsanleitung oder per "set ... reset"-Befehl in FHEM. Danach so 30 Sekunden warten und dann in FHEM ein "get ... config all" hinterher. Dann warten bis das Reading configStatus wieder auf OK geht (sollte zwischendurch auf READING gehen).
3. Das peering wieder herstellen und die peersettings am besten ganz in Ruhe lassen.
Wie schon gesagt bin ich derzeit dabei, den HM485-Kram komplett zu überarbeiten. Mit der neuen Version sollten solche Probleme erledigt sein. Allerdings kann das noch ein bisschen dauern, da ich sehr viel umgebaut habe.
Gruß,
Thorsten
Hi,
1) gelöscht habe ich sie nicht, aber in hmw_io12_sw7_dr_V3_02_orig.pm umbenannt. Das sollte ja auch reichen, oder?
2) Eine Taste hat das IO Modul nicht, deshalb habe ich es mit dem Reset aus fhem gemacht und dann mit get config all wieder geladen. Ein Reading sehe ich im Status kurz.
2) Das Peering habe ich wieder gemacht, allerdings ändert sich an der Situation nichts.
Die Peersettings sehen immernoch kaputt aus und die "Schleife" wird auch wieder gestartet.
Gruß
Ich habe gesehen, dass ich die Datei 10_HM485.pm noch in der Version 0.7.24 benutze.
Sollte ich diese manuell auf die letzte Version aktualisieren?
Müsste ein fhem update das nicht automatisch tun?
Zitat von: fritzhugo123 am 23 März 2017, 17:53:58
1) gelöscht habe ich sie nicht, aber in hmw_io12_sw7_dr_V3_02_orig.pm umbenannt. Das sollte ja auch reichen, oder?
Nein, das reicht überhaupt gar nicht. Das hat gar keine Wirkung. Du kannst sie selbst "hubendubel.pm" nennen. Aus dem Verzeichnis löschen! Alles andere hilft nix.
Zitat
Die Peersettings sehen immernoch kaputt aus und die "Schleife" wird auch wieder gestartet.
Ja, weil die Datei immer noch da ist.
Gruß,
Thorsten
Zitat von: fritzhugo123 am 23 März 2017, 17:58:02
Ich habe gesehen, dass ich die Datei 10_HM485.pm noch in der Version 0.7.24 benutze.
Das ist für diesen Fehler egal.
Zitat
Sollte ich diese manuell auf die letzte Version aktualisieren?
Nein, da die Datei dann nicht mehr mit den anderen zusammenpasst.
Zitat
Müsste ein fhem update das nicht automatisch tun?
Kommt darauf an, wie Du den Kram installiert hast.
Mach mal das, was hier beschrieben ist:
https://wiki.fhem.de/wiki/HomeMatic_Wired#Installation_und_Upgrade_in_FHEM
Danach klappt das auch mit dem FHEM-update.
...aber wie gesagt: Hilft bei Deinem Problem nichts.
Gruß,
Thorsten
ZitatHier das list von dem IO Modul.
Damit ist mir klar, warum im Fehlerfall die peersettings um ein Byte versetzt ins EEPROM des IO Moduls geschrieben werden.
Durch das um ein Byte versetzte schreiben ins EEPROM, wird aus den 49152 für "dont use" die 20-25 Sek
Wenn man sich die beiden Gerätebeschreibungsdateien anschaut, sieht man den Unterschied:
'HMW_IO12_SW7_DR':
long_on_time_mode "index" => 17.7
short_jt_on "index" => 15.3
short_on_time "index" => 9
short_off_time "index" => 13
'HMW_IO12_SW7_DR_V3_02':
long_on_time_mode "index" => 7.7
short_jt_on "index" => 16.3
short_on_time "index" => 10
short_off_time "index" => 14Wenn man nun in Deinem list von dem IO Modul schaut, sieht man, daß dort die falschen Address indexe vom 'HMW_IO12_SW7_DR_V3_02' stehen
Short_on_time: Address index 10
Short_off_time: Address index 14Solange dort die falschen Address indexe stehen, werden alle peerings die eingerichtet oder geändert werden zu Blinklichtern.
ZitatDie Peersettings sehen immernoch kaputt aus und die "Schleife" wird auch wieder gestartet.
Hast Du vor dem wieder einrichten der peerings ein fhem neustart gemacht?
Damit HM-wired mit FHEM 5.8 funktioniert, muß das csrfToken abgeschaltet werden
attr WEB.* csrfToken noneHier ist eine Beschreibung warum das csrfToken eingeführt wurde
https://forum.fhem.de/index.php/topic,68314.msg598070.html#msg598070
Gruß Ralf
Hallo Thorsten,
da mir u.a. bei meinen Selbstbau HM-wired IO-Modulen auch aufgefallen ist, daß bei der Zuordnung der Gerätebeschreibungsdatei die Firmware-Version nicht richtig berücksichtigt wird, habe ich es in meiner Version angepasst.
Meine Anpassungen habe ich mit #### markiert
sub initModels() {
foreach my $deviceKey (keys %deviceDefinitions) {
if ($deviceDefinitions{$deviceKey}{'supported_types'}) {
foreach my $modelKey (keys (%{$deviceDefinitions{$deviceKey}{'supported_types'}})) {
if ($deviceDefinitions{$deviceKey}{'supported_types'}{$modelKey}{'parameter'}{'0'}{'const_value'}) {
$models{$modelKey}{'model'} = $modelKey;
$models{$modelKey}{'name'} = $deviceDefinitions{$deviceKey}{'supported_types'}{$modelKey}{'name'};
$models{$modelKey}{'type'} = $deviceDefinitions{$deviceKey}{'supported_types'}{$modelKey}{'parameter'}{'0'}{'const_value'};
my $minFW = $deviceDefinitions{$deviceKey}{'supported_types'}{$modelKey}{'parameter'}{'2'}{'const_value'};
$minFW = $minFW ? $minFW : 0;
$minFW = '000' . $minFW; ####
$minFW = substr($minFW, -4); ####
$models{$modelKey}{'versionDeviceKey'}{$minFW} = $deviceKey;
}
# Handling of the "generic" device
# This is probably not perfect, but should work
elsif($deviceKey eq 'HMW_GENERIC') {
$models{$modelKey}{'model'} = $modelKey;
$models{$modelKey}{'name'} = $deviceDefinitions{$deviceKey}{'supported_types'}{$modelKey}{'name'};
$models{$modelKey}{'type'} = 0;
$models{$modelKey}{'versionDeviceKey'}{'0000'} = $deviceKey; ####
}
}
}
}
#print Dumper(%models);
}
sub getDeviceKeyFromHash($) {
my ($hash) = @_;
if(defined($hash->{devHash})) {
$hash = $hash->{devHash};
}
my $retVal = '';
if ($hash->{'MODEL'}) {
my $model = $hash->{'MODEL'};
my $fw = $hash->{'FW_VERSION'} ? $hash->{'FW_VERSION'} : 0;
my $fw1 = $fw ? int($fw) : 0;
my $fw2 = ($fw * 100) - int($fw) * 100;
my $fwVersion = hex(
sprintf ('%02X%02X', ($fw1 ? $fw1 : 0), ($fw2 ? $fw2 : 0))
);
foreach my $version (sort keys (%{$models{$model}{'versionDeviceKey'}})) { #### sort
if ($version <= $fwVersion) {
$retVal = $models{$model}{'versionDeviceKey'}{$version};
} else {
last;
}
}
}
return $retVal;
}
Gruß Ralf
Hi,
das ist in meiner momentanen Entwickler-Version schon repariert, nur dass auch die Conditions (GE, GT, LE etc.) beachtet werden und die Priority auch noch ausgewertet wird.
Gruß,
Thorsten
So, einen Schritt weiter bin ich nun.
Nach dem Löschen der Datei werden die Module jetzt neu eingelesen.
Ich kann allerdings kein neues Peering machen, ich erhalte die Fehlermeldung noch PeerID free.
In den Internals sehe ich folgende Zuordnungen:
peer_act_25
channel_52 → unknown
peer_act_26
channel_52 → unknown
peer_act_3
channel_52 → unknown
peer_act_4
channel_52 → unknown
peer_act_5
channel_52 → unknown
peer_act_6
channel_52 → unknown
peer_act_7
channel_52 → unknown
peer_act_8
channel_52 → unknown
peer_act_9
channel_52 → unknown
peer_sen_0
channel_52 ← unknown
peer_sen_1
channel_52 ← unknown
peer_sen_10
channel_52 ← unknown
peer_sen_11
channel_52 ← unknown
peer_sen_12
channel_52 ← unknown
peer_sen_13
channel_52 ← unknown
peer_sen_14
channel_52 ← unknown
peer_sen_15
channel_52 ← unknown
Was muss ich tun, um diese loszuwerden, so dass ich wieder ein neues Peering erstellen kann?
Ich habe den Raspberry dann noch einmal neu gestartet und nun funktioniert wieder alles.
Auch ein neues Peering konnte ich erstellen.
Was eine einzelne Datei doch so alles anrichten kann...
Vielen Dank für die Geduld und den Support.
Ich bin wieder etwas schlauer geworden und wünsche viel Erfolg bei der Aktualisierung des HM485 Moduls.
LG
Hi,
das mit den channel_52 ist auch schon gefixt. Leider habe ich anscheinend noch ein paar Problemchen eingebaut, denen ich jetzt noch nachgehen muss. Es kann also noch ein bisschen dauern, bis ich das "ausliefern" kann.
Gruß,
Thorsten