Hi,
nach dem heutigen Update, bei dem ja die Module HMConfig.pm, 10_CUL_HM.pm und 00_HMLAN.pm durch neue ersetzt wurden erhalte ich folgende Fehlermeldungen in endloser Reihe:
2015.06.08 08:47:46 1: 127.0.0.1:1000 disconnected, waiting to reappear (hmusb)
2015.06.08 08:47:46 1: HMLAN_Parse: hmusb new condition disconnected
2015.06.08 08:47:47 1: 127.0.0.1:1000 reappeared (hmusb)
2015.06.08 08:47:47 1: HMLAN_Parse: hmusb new condition init
Habe jetzt die alte Version wieder zurückgespielt und Fehler ist weg!
Hi,
Zitat von: punker am 08 Juni 2015, 09:00:10
2015.06.08 08:47:46 1: 127.0.0.1:1000 disconnected, waiting to reappear (hmusb)
2015.06.08 08:47:46 1: HMLAN_Parse: hmusb new condition disconnected
Welche Version des hmland? Alle kleiner 0.99-git haben ein Problem mit sehr grossen Pakete, wie sie nach einem Reconnect auftreten koennen. Das ist evtl. der Ausloeser hier.
Gruss
Michael
Exakt gleiches Problem habe ich seit heutigen Update auch mit dem HMLAN Adapter.
...
2015.06.08 09:36:50 1: HMLAN_Parse: HMLAN1 new condition init
2015.06.08 09:37:17 1: x.x.x.x: 1000 disconnected, waiting to reappear (HMLAN1)
2015.06.08 09:37:17 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.06.08 09:37:17 1: x.x.x.x::1000 reappeared (HMLAN1)
2015.06.08 09:37:17 1: HMLAN_Parse: HMLAN1 new condition init
2015.06.08 09:37:44 1: x.x.x.x::1000 disconnected, waiting to reappear (HMLAN1)
2015.06.08 09:37:44 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.06.08 09:37:44 1: x.x.x.x::1000 reappeared (HMLAN1)
2015.06.08 09:37:44 1: HMLAN_Parse: HMLAN1 new condition init
...
Mein HMLAN Adapter hat D-firmware = 0.964.
Viele Grüße!
Andreas
Guten morgen, ich habe auch dieses Problem.
Wie kann man es beheben ???
Gruß Werner
Ist wohl doch ein Problem in Fhem, das schickt bei Geraeten mit aesCommReq einen ungueltigen Keyindex.
EDIT: aesCommReq ist unschuldig, siehe unten.
Gruss
Michael
Also mein Problem scheint gelöst!
Hab den hmland aus dem Git auf 0.099-git aktualisiert und die Fehlermeldungen sind (vorerst) weg!
HMUSB Adapter hat firmware = 0.967
lg
hier ebenfalls etliche hmlan disconnects nach besagtem fhem update
grüße
chris
Zitat von: punker am 08 Juni 2015, 10:25:59
Also mein Problem scheint gelöst!
Hab den hmland aus dem Git auf 0.099-git aktualisiert und die Fehlermeldungen sind (vorerst) weg!
HMUSB Adapter hat firmware = 0.967
lg
Also. Bei mir hat weder das "git pull" noch das Firmware-Update etwas geändert. Ich bin mit "restore" zurückgegangen.
Bei mir auch erst nach restore alles wieder ok. Besonders unangenehm, weil mein Türschloss nicht mehr von fhem gesteuert werden konnte.
Ich verwende HMLAN.
Ok, das Problem wird durch einen ungültigen Sendebefehl von Fhem ausgeloest, welches versucht ein 0x99 Byte langes Frame zu senden:
2015-06-08 13:05:14.644971: LAN > SD2D875B2,00,00000000,01,D2D875B2,99811268EA13000000
Ich habe jetzt auf Anhieb nicht gefunden, was dieses Sendekommando auslöst, anscheinend hat es aber nichts mit einem evtl. gesetzten AES-Key zu tun...
EDIT: Das ist es auch nicht :-( Der HMLAN erwartet an der Stelle ja gar kein Längenbyte, hab zulange auf RAW-Frames gestarrt am Wochenende...
Gruß
Michael
Hallo,
ich habe mit meinem USB-Stick das selbe Problem:
Zitat2015.06.08 13:07:17 1: HMLAN_Parse: hmusb new condition init
2015.06.08 13:07:26 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2015.06.08 13:07:26 1: HMLAN_Parse: hmusb new condition disconnected
2015.06.08 13:07:26 1: 127.0.0.1:1234 reappeared (hmusb)
2015.06.08 13:07:26 1: HMLAN_Parse: hmusb new condition init
2015.06.08 13:07:27 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2015.06.08 13:07:27 1: HMLAN_Parse: hmusb new condition disconnected
2015.06.08 13:07:27 1: 127.0.0.1:1234 reappeared (hmusb)
2015.06.08 13:07:27 1: HMLAN_Parse: hmusb new condition init
2015.06.08 13:07:37 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2015.06.08 13:07:37 1: HMLAN_Parse: hmusb new condition disconnected
2015.06.08 13:07:37 1: 127.0.0.1:1234 reappeared (hmusb)
2015.06.08 13:07:37 1: HMLAN_Parse: hmusb new condition init
Mit einem Restore wieder das alte eingespielt und gut ist.
Wenn ich was zur Lösung beitragen kann (z.B. was ausprobieren) bitte melden.
Hallo,
So, jetzt aber.
Die neue Version versucht 5 Schlüssel zu setzen, der HMLAN sowie der HMCFGUSB haben aber nur 3 KeySlots und stürzen meistens ab, wenn man auf höhere Slots zugreift.
Lösung: in Zeile 893 der 00_HMLAN.pm (Funktion HMLAN_writeAesKey) diesen Code:
foreach my $i (1..5){
in diesen ändern:
foreach my $i (1..3){
Gruß
Michael
Vielen Dank für die Lösung. Funktioniert wieder bestens.
Komisch. Mein HMLAN-CFG-Adapter hat offenbar 5 Slots und alle 5 Schlüssel sind auch in FHEM belegt (eingetragen).
Ich weiss nicht, ob noch allews funktioniert, wenn ich nur noch 3 einlese?
Odewr sehe ich hier etwas falsch?
Hallo,
Zitat von: Invers am 08 Juni 2015, 14:27:04
Komisch. Mein HMLAN-CFG-Adapter hat offenbar 5 Slots und alle 5 Schlüssel sind auch in FHEM belegt (eingetragen).
Ich weiss nicht, ob noch allews funktioniert, wenn ich nur noch 3 einlese?
Odewr sehe ich hier etwas falsch?
Vor dem Update heute wurden auch nur 3 Schlüssel an den HMLAN übertragen. Falls es nach dem restore also wieder funktioniert, dann kannst Du eigentlich nur 3 Schlüssel benutzen... Die anderen beiden werden laut Code ignoriert.
Gruß
Michael
Hm... hat bei mir gestern 5 keys ohne reset uebertragen.
Dann werde ich auch die attribute auf 3 einschraenken. Mache ich gleich. Falls einer mehr als 3 keys definiert hat wird es nicht mehr akzeptiert. Funktioniert hat es eh nicht
Ich habe keinen AESKey definiert und hatte auch diese reconnects.
Zitat von: martinp876 am 08 Juni 2015, 21:17:44
Hm... hat bei mir gestern 5 keys ohne reset uebertragen.
Ich gehe stark davon aus, dass die Firmware einfach keine Parameterüberprüfung macht und einfach den Key an die Adresse Kno*Schlüssellänge im Speicher schreibt. Und wenn da schon was anderes wichtiges steht und überschrieben wird, führt das zum Crash, manchmal gehts aber auch gut. Der HMCFGUSB ist übrigens deutlich anfälliger für kaputte Parameter, wie ich leidlich feststellen musste.
Wenn das jetzt nur den HMCFGUSB betroffen hätte, dann hätte ich im hmland alle Slots > 3 rausgefiltert, aber nachdem es auch den HMLAN betrifft...
Nur rein interessehalber: Wie sieht bei Dir die Antwort auf ein Y-Kommand aus? Da stehen die belegten und freien Slots drin:
I00,01,00,00
Wobei Slot 0 immer mit dem Defaultkey 00 belegt ist. Hast Du hier mehr mögliche Slots?
Zitat von: stromer-12 am 08 Juni 2015, 21:24:44
Ich habe keinen AESKey definiert und hatte auch diese reconnects.
Beim Verbindungsaufbau wird auf allen möglichen Slots versucht, den Key zu löschen, wenn für den Slot kein Key definiert wurde. Also wurde bei Dir wahrscheinlich einfach zufälliger Speicher genullt...
Gruß
Michael
sollte wieder gehen wie vorher. Nur mit vccu option für die keys
Zitat von: mgernoth am 08 Juni 2015, 13:39:28
foreach my $i (1..5){
in diesen ändern:
foreach my $i (1..3){
Super, das war's bei mir auch ... hätt ich den Thread bloß drei Stunden früher gefunden ;-)
Gruß,
Christoph
Guten Morgen,
habe mich heute auch schwer gewundert ... ist das ein Bug und wird bis heute Nachmittag behoben oder muss man die besagten Werte von Hand ändern?
Grüße
Zitat von: oxident am 09 Juni 2015, 00:08:27
Super, das war's bei mir auch ... hätt ich den Thread bloß drei Stunden früher gefunden ;-)
Gruß,
Christoph
Bei mir mit 2x HMLAN das gleiche, je ein AES Key in Benutzung. Nach der Änderung der Schleife von 5 auf 3 wieder alles in Ordnung.
Es läuft, abert ich bekomme beim Start die Meldung:
2015.06.09 08:46:47 2: Error messages while initializing FHEM: configDB: HMLAN1: unknown attribute hmKey4. Type 'attr HMLAN1 ?' for a detailed list. HMLAN1: unknown attribute hmKey5. Type 'attr HMLAN1 ?' for a detailed list.
Moin,
hab alles geändert wie hier angegeben, aber es hat sich nichts verändert!? Nutze den HMUSBCFG (und VCCU) und habe auch die Fehlermeldung:
Zitat127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2015.06.09 09:46:21 1: HMLAN_Parse: hmusb new condition disconnected
2015.06.09 09:46:22 1: 127.0.0.1:1234 reappeared (hmusb)
Muss ich noch etwas beachten??
Vielen Dank für Eure Hilfe!
Gruß Thommy
Zitat von: ThommyTom am 09 Juni 2015, 09:47:24
hab alles geändert wie hier angegeben, aber es hat sich nichts verändert!? Nutze den HMUSBCFG (und VCCU) und habe auch die Fehlermeldung: [...]
Was hast Du alles geaendert?
fhem gestern geupdated?
Oder heute geupdated (heute ist der fix fuer die 00_HMLAN.pm im update drin)?
00_HMLAN.pm editiert?
hmland geupdated?
Gruss
Michael
Hallo
ich hatte gestern das gleiche Problem, allerdings ohne einen HMLAN oder HMCFG zu nutzen. Mein fhem server war nicht merr verfügbar und startete, wie beschrieben, immer wieder neu. Ich musste die 00_hmlan und die 10_cul_ham aus dem restoredir einspielen, erst dann lief alles wieder problemlos.
Mit dem heutigen update kann ich die 00_hmlan wieder nutzen, allerdings nicht die 10_cul_hm, hier ist mein fhem nach wie vor nicht erreichbar bzw. tsrtet in einer Endlosschiefe immer wieder neu. Sofern ich die 10_cul_hm (10_CUL_HM.pm 8683 2015-06-03 21:26:40Z ) nutze läuft alles problemlos.
Da scheint noch etwas anderes zu sein.
Hallo,
Zitat von: baumeister am 09 Juni 2015, 11:28:04
ich hatte gestern das gleiche Problem, allerdings ohne einen HMLAN oder HMCFG zu nutzen.
Dann benutzt Du ein culfw-Geraet als IO?
Kommentiere bitte mal Zeile 278 der 10_CUL_HM.pm (HMLAN_writeAesKey) aus, das wird da anscheinend auch fuer CULs aufgerufen, obwohl es fuer die nicht definiert ist.
Gruss
Michael
Hallo,
ja ich habe einen CUL mit culfw. Wenn ich in der aktuellen 10_cul_hm diese Zeile 278 auskommentiere funktioniert es wieder. Da scheint noch der Wurm drin zu sein. Danke
Hilfe jetzt ist mein Fhem tot ...
hatte gestern Abend das Problem mit dem hmcfgusb disconnected ...
soeben geupdatet und mit shutdown restart neu starten wollen.
Nun ist Fhem nicht erreichbar .. wenn ich Fhem manuell über SSH beende und starte kommt folgende Meldung:
Starting fhem...
Daemon with PID 2268 started!
2015.06.09 15:47:05 1: Including fhem.cfg
2015.06.09 15:47:05 1: telnetPort: Can't open server port at 7072: Die Adresse wird bereits verwendet. Exiting.
bin zwar kein Experte aber irgendwie hat das für mich keinen Zusammenhang mit dem gestrigen HM Problem .. wie kann ich ein Restore durchführen?
gruß
Bei Dir hängt irgendwo noch ein Perl-Task.
killall -9 perl
oder
ps -e | grep perl
Dann die Nummer des Perl-Tasks raussuchen und den abschießen:
kill -9 <Nummer>
war noch ein Bug, wenn man kein HMLAN oder USB hat drin. Ist behoben.