Hi,
anbei ein versuch zur weiteren stabilisierung des HMLAN interface.
Die SW berücksichtigen die Queuelänge den HMLAN - welcher sich verschlickt, wenn mehr als 4 messages gelichzeitig übertragen werden sollen.
Wer testen will, kann die 3 File einmal einbauen (ansonsten neuster Stand).
Einstellen kann man die "Queuelänge" im HMLAN attr "hmLanQlen".
Setzt man die Länge auf "1" (oder 1_min) sollte man das stabilste Ergebniss erhalten. Höhere Werte erhöhen die mögliche Parallele Übertragung, die meist auch gut funktioniert. Allerdings habe ich hie und da "resends" gehabt, je nach datenlast, also parallel gesendete Requests.
Prüfen kann man am einfachsten mit HMInfo:
define hm HMInfo
Summe alle protokoll-events
set hm protoEvents
Events kann man "nullen" mit
set hm clear Protocol
Wenn es bei euch stabil läuft werde ich es einbauen, also bitte testen...
Danke
Martin
Hallo Martin,
muss ich nur die 3 Dateien austauschen oder auch das Attribut wie beschrieben auf 1 ändern?
Gruß
Christian
Hallo Christian,
Das Attribut wird automtisch gesetzt, falls du es nicht aenderst.
Du kannst mit dem Wert spielen.
Noch ein Hinweis: Die Version stoppt die Verarbeitung der Messages, falls HMLAN "disconnected". Messages werden 1 min gespeichert - sollte HMLAN wiederkommen werden die Nachrichten gesendet (bisher wurden sie gelöscht).
Um Probleme zu verhindern werden die Messages jedoch nach 1min gelöscht - alles ander ist zu gefährlich. Somit sollte ein einfacher disconnect/reconnect verlustfrei bleiben
Gruss Martin
Hi,
und schon einen Bug gefunden.
Neue Version:
oh,oh!
nachdem ich die 3 Dateien ausgetauscht habe, schaffe ich es genau 1 Befehl erfolgreich abzusetzen. Danach wird kein einziger Befehl mehr vom HMLAN ausgeführt, bis ich ein shutdown restart mache. Dann geht wieder ein Befehl über den HMLAN.
als Status steht beim HMLAN immer "hmPairSerial ******"
Und als Status bei den Aktoren bleibt "set an" oder ähnlich stehen und wird nicht ausgeführt.
Kein Missing Ack.
Und im HMInfo wird jeder Befehl unter protIOerr gelistet!
Was nun?
Gruß Christian
Hallo Christian,
du hast die 2. CUL_HM datei? Welcher Befehl ist dies?
Kannst du ein "list <hmlan>" schicken wenn de Fehler ansteht?
Gruss Martin
Hallo Martin,
ja ich habe die korrigierte CUL_HM genommen.
Welchen Befehl ich absetzen kann, ist dem HMLAN egal (set Rolladen hoch oder set Aussenbeleuchtung an). Ein Befehl wird problemlos ausgeführt. Alle weiteren Befehle danach werden nicht mehr ausgeführt und es bleibt im Status der Aktoren "set ***" stehen. Erst nach einem Shutdown Restart kann ich wieder 1 beliebigen Befehl ausführen.
Die Statusmeldungen der Aktoren, wenn ich zum Beispiel den Rollladen manuell fahre, werden aber übermittelt.
Das list schicke ich heute Nachmittag.
Übrigens ist das letzte Pairen eines Aktors schon ewig her. Wie bekomme ich diesen Status des HMLAN weg? Vielleicht hat es damit zu tun? Oder bleibt dort einfach der letzte direkte Befehl an den HMLAN stehen?
Gruß
Christian
Hallo Christian,
HMLAN gibt statusinfo vor - und blockiert somit weiteres Senden.
Der Status des HMLAN wird automatisch generiert. Sollte HMLAN disconnecten beispielsweise.
Welchen status hat dein HMLAN?
Wichtig ist auch "XmitOpen" - sollte 1 sein.
Das ganze sollte sich auch mit einem stromaus/an des HMLAN reseten
Das ganze MUSS aber letztendlich automatisch funktionieren, was es bei mir auch tut. Bin gespannt,was bei dir los ist.... hat du AES devices? die habe ich nicht am Start
Gruss Martin
Hallo Martin,
hier das versprochene List
Internals:
DEF 192.168.0.101:1000
DeviceName 192.168.0.101:1000
FD 4
HMLAN1_MSGCNT 73
HMLAN1_TIME 2013-09-05 16:50:49
HM_CMDNR 1
NAME HMLAN1
NR 36
PARTIAL
RAWMSG E1B3FF8,0000,0999170B,FF,FFAB,4EA4101B3FF8CE77110601C800
RSSI -85
STATE hmPairSerial JEQ0146945
TYPE HMLAN
XmitOpen 1
assignIDs 1BE410
assignIDsCnt 1
assignIDsReport 0
firmware 0.961
msgParseDly min:6 max:37 last:9 cnt:71
owner CE7711
serialNr JEQ0315943
uptime 001 44:55:45.095
Readings:
2013-09-05 06:31:50 Xmit-Events init:1
2013-09-05 06:31:50 cond init
2013-09-05 06:31:45 prot_disconnected last
2013-09-05 06:31:50 prot_init last
2013-09-05 06:22:50 prot_ok last
2013-01-04 21:18:43 state hmPairSerial JEQ0146945
Helper:
1b3f7a:
nextSend 1378392616.41904
1b3fdc:
nextSend 1378355921.41468
1b3ff8:
nextSend 1378392649.32151
1b4014:
nextSend 1378361959.67687
1b4017:
nextSend 1378361947.43561
1b4020:
nextSend 1378392642.61927
1b4025:
nextSend 1378392629.36324
1b4036:
nextSend 1378355945.17939
1b403a:
nextSend 1378392600.11354
1b4049:
nextSend 1378361958.04219
1b404e:
nextSend 1378355792.9325
1b449e:
nextSend 1378355927.88289
1be410:
chn 01
flg 0
msg
name HWR_Zirkulation
newChn +1BE410,00,01,
nextSend 1378354970.98177
to 1378354972.17196
1bfd8c:
nextSend 1378364401.52874
Ce7711:
flg 0
Dly:
cnt 71
lst 9
max 37
min 6
Q:
HMcndN 255
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Ref:
drft -0.000159961609213789
hmtL 161745095
kTs 0
offL 1378231621270
sysL 1378393366365
Attributes:
hmId CE7711
hmLanQlen 1_min
room HWR
wdTimer 25
XmitOpen ist 1
Der Status von meinem HMLAN ist hmPairSerial *** seit 04.01.2013
AES-Devices habe ich keine.
Selbst nachdem ich Ihn stromlos gemacht habe, bleibt der Status so bestehen und Befehle werden wieder nicht umgesetzt.
Nach einem Shutdown Restart steht STATE auf opened und state bleibt auf hmPairSerial ***
Nach Absetzen von set Aussenbeleuchtung aus geht die Außenbeleuchtung aus und STATE vom HMLAN geht wieder auf hmPairSerial *** und keine weiteren Befehle werden angenommen.
hmLanQlen habe ich schon auf 3 gesetzt.
Gruß
Christian
der state ist falsch - ich versuche es nachzuvollziehen.
darf nur opened/disconnected o.ä. sein
sehr eigenartig.
kannst du ggf ein einmal rohmessages schicken?
Gruss Martin
Nachtrag: STATE wird auch von devIO gesetzt, also ausserhalb meiner SW. Was stand da sonst bei dir drin?
sagst du mir bitte nochmal kurz, was ich umstellen muss um die Rohmessages zu bekommen?
Zitat von: martinp876 schrieb am Do, 05 September 2013 17:24Nachtrag: STATE wird auch von devIO gesetzt, also ausserhalb meiner SW. Was stand da sonst bei dir drin?
das stand da schon ewig drin seit dem Pairen meiner Aktoren. Hat mich zum Anfang auch gewundert, aber da alles funktionierte, habe ich mir nichts weiter dabei gedacht.
Wie gesagt nach Shutdown Restart bleibt ist STATE opened aber state in den Readings immer noch hmpairserial ***. Und dann nach einem erfolgreichen Befehl wieder das gleiche auch im STATE.
so das Log mit Rowmessages seit dem Aktivieren der Rohdaten.
Ich habe um 17:36 einen Befehl zum Fahren des Rollladens
1B3FDC geschickt:
2013.09.05 17:35:01 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:35:01 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:0017513D IDcnt:0001
2013.09.05 17:35:26 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:35:26 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:0017B2F8 IDcnt:0001
2013.09.05 17:35:51 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:35:51 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001814AB IDcnt:0001
2013.09.05 17:36:16.992 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:36:16.999 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:0018765E IDcnt:0001
2013.09.05 17:36:41.998 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:36:42.004 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:0018D80F IDcnt:0001
2013.09.05 17:37:07.004 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:37:07.010 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001939C1 IDcnt:0001
2013.09.05 17:37:32.010 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:37:32.016 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:00199B72 IDcnt:0001
2013.09.05 17:37:57.033 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:37:57.040 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:0019FD35 IDcnt:0001
2013.09.05 17:38:20.391 1: HMLAN_Parse: HMLAN1 R:E162E16 stat:0000 t:001A5867 d:FF r:FF9A m:6B A002 162E16 1A9ADD 04897D71F3F9DD02
2013.09.05 17:38:20.649 1: HMLAN_Parse: HMLAN1 R:E162E16 stat:0000 t:001A596A d:FF r:FF9A m:6B 8002 162E16 1A9ADD 0036D29F5F
2013.09.05 17:38:22.040 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:38:22.047 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001A5EE7 IDcnt:0001
2013.09.05 17:38:47.053 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:38:47.060 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001AC0A0 IDcnt:0001
2013.09.05 17:39:12.065 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:39:12.072 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001B2258 IDcnt:0001
2013.09.05 17:39:37.093 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:39:37.100 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001B841F IDcnt:0001
2013.09.05 17:40:02.101 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:40:02.108 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001BE5D2 IDcnt:0001
2013.09.05 17:40:27.117 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:40:27.124 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001C478E IDcnt:0001
2013.09.05 17:40:52.125 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:40:52.132 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001CA941 IDcnt:0001
2013.09.05 17:41:17.133 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:41:17.141 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001D0AF5 IDcnt:0001
2013.09.05 17:41:42.157 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:41:42.164 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001D6CB8 IDcnt:0001
2013.09.05 17:42:07.165 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:42:07.172 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001DCE6B IDcnt:0001
2013.09.05 17:42:32.171 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:42:32.178 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001E301D IDcnt:0001
2013.09.05 17:42:54.147 1: HMLAN_Parse: HMLAN1 R:E162E16 stat:0000 t:001E85EA d:FF r:FF98 m:6C A002 162E16 1A9ADD 04F1E5D9CDC1B102
2013.09.05 17:42:54.406 1: HMLAN_Parse: HMLAN1 R:E162E16 stat:0000 t:001E86ED d:FF r:FF9A m:6C 8002 162E16 1A9ADD 000299C28D
2013.09.05 17:42:57.378 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:42:57.429 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001E9298 IDcnt:0001
2013.09.05 17:43:22.385 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:43:22.392 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001EF44A IDcnt:0001
2013.09.05 17:43:47.391 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:43:47.398 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001F55FC IDcnt:0001
2013.09.05 17:44:12.398 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:44:12.404 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:001FB7AD IDcnt:0001
2013.09.05 17:44:37.405 1: HMLAN_Send: HMLAN1 I:K
2013.09.05 17:44:37.412 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315943 d:1C6AB2 O:CE7711 t:00201961 IDcnt:0001
Hi Christian,
hm - das ist sehr seltsam. der state wird u.a. auch ausserhalb von HMLAN gesetzt, von DEVio.
Der STATE steht also schon direkt nach dem booten drin?
Was passiert, wenn du das LANIf stromlos machst und wieder powerst? Der Zustand sollte sich aendern (ganz ohne meine Aenderungen...)
Ich habe verschiedenes probiert und bekomme es einfach nicht hin.
ist DevIo auf dem letzten Stand?
Gruss Martin
Also nach dem stromlos Machen des HMLANs bleibt der STATE so wie vorher. mit Shutdown restart ist der STATE opened aber in den Readings der state ist weiterhin hmpairserial.
Ich habe jetzt FHEM beendet in der Konfigsoftware ein Update der FW gemacht. Die Firmware ist zwar gleich geblieben aber egal. Selbst nach dem Neustarten von FHEM war der State noch drin.
Also habe ich den HMLAN gelöscht und wieder neue definiert. Jetzt ist der STATE opened aber in den Readings gibt es kein state mehr. Und nun wird nicht mal mehr ein Befehl übertragen an die Aktoren. Aber der Status beim manuellen Bedienen meiner Rollläden wird schön sauber empfangen.
Ich weiß echt nicht mehr weiter. es geht alles nur noch manuell zu bedienen jetzt.
Das Pairing der Aktoren ist ja weiterhin erhalten geblieben trotz Löschen und Neudefinieren des HMLANS oder? Denn bei den Aktoren steht weiterhin drin paired to drin.
Was meinst du mit DEVio?
Gruß
Christian
Hi Christian,
DevIO ist das Modul, das HMLAN nach TCP/IP verbindet. Hier werden auch die meisten disconnects entdeckt.
state hat in den Readings von HMLAN nichts verloren, habe ich auch noch nie gesehen. Alles wird direkt in STATE geschrieben, keine Readings.
Hast du ein device mit der gleichen HMId wie HMLAN?
So, wenn nun im STATE "opened" steht sollte das übertragen klappen. XmitOpen sollte "1" sein.
sonst bitte noch einmal das list des HMLAN - vielleicht hat sich noch etwas verschoben.
Gruss Martin
So nun gibt es nur noch das STATE und kein state mehr im Reading vom HMLAN.
Und durch das Löschen des HMLAN´s waren die Aktoren zwar gepairt. Aber es ist kein Kommando angekommen. Also habe ich nun einfach manuell in jeden Aktor IODEV HMLAN1 eingetragen und nun funktionieren die Kommandos wieder.
Bei nur einem HMLAN sollte IODEV ja eigentlich nicht notwendig sein. Aber das Löschen und Neuanlegen scheint dies wohl notwendig zu machen.
Jetzt werden wir mal beobachten, was morgen früh beim gleichzeitigen Ansteuern von mehreren Rollläden passiert.
Warum der Status beim HMLAN so komisch war, weiß ich zwar nicht, zumal er ja bisher auch funktionierte.
Gruß Christian
ok, klar. Das Problem ist, dass das ioDev zuerst definiert sein muss. Wenn ein CUL_HM definiert wird wird ein vorhandenes IODev eingetragen.
Es ist also wichtig, das IO-device auch im fhem.cfg VOR allen anderen devices stehen zu haben, dann klappts.
Gruß Martin
Hallo,
ich wollte nur mal ein kurzes feedback geben. Seitdem ich diese files verwende, sind bei mir jetzt keine Rollladen mehr oben bzw. unten geblieben. Es scheint stabiler als vorher zu laufen. Vielen Dank für die Arbeit!
schöne Grüße
Jo
Hi,
die Version ist jetzt online - 3879
Also ab morgen im Update.
Gruss Martin
Auch bei mir läuft es nun seit Donnerstag Abend problemlos.
Abends werden 12 Rollläden gleichzeitig gefahren auch ohne Probleme.
Im HMInfo sind auch keine Resends zu sehen. Und trotzdem kann man abends beobachten, wie die Rollläden teilweise leicht zeitversetzt losfahren.
Vielen Dank Martin.
Gruß
Christian
Hi Christian,
Das zeitversetzt kann gut sein, klar.
Man kann mit hmLanQLen etwas spielen, da kann es dann schon schneller gehen.
danke für die Tests
Martin
Hallo Martin,
das zeitversetzt war überhaupt nicht negativ gemeint. Es ist wirklich minimal und ich erhebe auch gar nicht den Anspruch, dass alle Läden exakt gleichzeitig fahren. Die Zuverlässigkeit ist mir viel wichtiger und die scheint ja gegeben zu sein.
Verstehe ich das richtig, dass die Befehle, sollte es zu Kollisionen kommen zwischengespeichert werden, und dann erneut versandt werden und dadurch die kleinen Zeitversätze entstehen? Oder wie muss ich mir das vorstellen, wenn 12 mal der Befehl zum Schließen der Rollläden verschickt wird?
Gruß
Christian
Hi Christian,
habe ich schon richtig verstanden. Es ist aber gut zu hören, dass es so funktioniert.
Mit Kollision dieser Teil nichts zu tun. HMLAN bestätigt die Verarbeitung der Messages - das war bislang nicht berücksichtigt. Ich haben bis zu 4 messages parallel an HMLAN gesendet und alle wurden ordentlich verarbeitet, bei mehr gab es meist Probleme. Allerdings spielt hier auch das Timing eine Rolle. Über das Attribut kannst du jetzt steuern, wie viele messages HMLAN parallel gefüttert bekommt.
Die Antworten des device können immer immer noch überlappen, was auch kein Problem ist.
Du kannst die Verzögerung also verringern, wenn du den Wert hoch setzt, es kann dann zu Wiederholungen kommen - aber bei Werten wie 2 oder 3 sollte es nicht zu "verlusten" kommen.
Kritisch könnte es nur bei wakeup devices werden, z.B. TC. Da könnte die verzögerung einen Abbruch verursachen...
Gruss Martin
Hallo,
ich hoffe ich habe nichts übersehen aber ich habe nach der letzten Aktualisierung (gerade gnoch einmal ganz aktuell von heute) das Problem, dass meine LED Lampen, welche über einen HM-LC-SW4-PCB geschaltet werden nicht mehr funktionieren.
Besser gesagt, nach dem Neustart kann ich die Lampe exakt einmal anschalten. Danach aber nicht wieder aus schalten.
Kann das mit der Aktualisierung zu tun haben? Vorher funktionierte alles einwandfrei und wenn ich das Backup zurück spiele geht es auch wieder. Übersehe ich eine neue config Option?
Ich betreibe mein FHEM auf einer Fritzbox 7390 und die HM devices werden über einen HMLAN adapter gesteuert.
folgendes sehe ich im Webfrontend:
Internals
DEF
1D86F9
HMLAN1_MSGCNT
1
HMLAN1_RAWMSG
R0D09ECD8,0001,037D08A1,FF,FFC0,0180021D86F9123A000101C80044
HMLAN1_RSSI
-64
HMLAN1_TIME
2013-09-11 14:40:56
IODev
HMLAN1
LASTInputDev
HMLAN1
MSGCNT
1
NAME
CUL_HM_switch_1D86F9
NR
103
STATE
CMDs_done_events:1
TYPE
CUL_HM
channel_01
CUL_HM_switch_1D86F9_Sw_01
channel_02
CUL_HM_switch_1D86F9_Sw_02
channel_03
CUL_HM_switch_1D86F9_Sw_03
channel_04
CUL_HM_switch_1D86F9_Sw_04
lastMsg
No:01 - t:02 s:1D86F9 d:123A00 0101C80044
protCmdDel
7
protIOerr
2 last_at:2013-09-11 14:44:07
protLastRcv
2013-09-11 14:40:56
protSnd
1 last_at:2013-09-11 14:40:55
protState
CMDs_done_events:1
rssi_HMLAN1
avg:-68 min:-68 max:-68 lst:-68 cnt:1
rssi_at_HMLAN1
avg:-64 min:-64 max:-64 lst:-64 cnt:1
Readings
CommandAccepted
yes
2013-01-11 18:35:31
level
0 %
2013-09-11 09:04:48
powerOn
-
2013-09-11 09:04:48
state
CMDs_done_events:1
2013-09-11 14:44:07
Hallo Derdon23,
in "proto..." kannst du sehen, dass der HMLAN Probleme hatte (IOErr) und es wurden 7 Kommandos (messages) gelöscht.
Es könnte schon mit dem Update zu tun haben, aber Anhaltspunkt habe ich keinen. Wenn der HMLAN einen "error" hat ist dies 'overload' - da muss man 6 min warten bis man wieder senden kann. FHEM betreibt das Recovery, aber warten muss man.
Während dieser 6 min kann von FHEM alles gelesen werden, aber nichts gesendet.
Einzige mir bekannte Alternative ist die Power des hmlan zu ziehen.
Neu ist dies nicht, das könnte schon vorher vorkommen.
Wäre gut, wenn du einmal roh-messages aufnehmen könntest, beim nächsten mal. Dann kann ich es untersuchen
Gruss Martin
Hi,
Danke für die Antwort. Ich habs gerade nochmal versucht und das loglevel hochgesetzt. Hier die Ausgaben:
Ich habe jetzt alles drin gelassen, die Geräte 1A7E10, 1A84ED und 1C6134 sind Thermostate. Der Schalter ist die 1D86F9. Zu sehen im Log sollte sein ein erfolgreiches Ausschalten der Lampe (14:44:11 bis 14:44:12 denke ich) und dann ein fehlschlagender Anschaltversuch gleich im Anschluss.
Sag Bescheid wenn ich noch irgend etwas beitragen kann.
2013.09.15 14:43:59.890 1: HMLAN_Parse: HMLAN1 R:E1A7E10 stat:0000 t:181A1361 d:FF r:FFC9 m:9F A258 1A7E10 1A84ED 0000
2013.09.15 14:44:00.313 1: HMLAN_Parse: HMLAN1 R:E1A84ED stat:0000 t:181A13E4 d:FF r:FFB3 m:9F 8202 1A84ED 1A7E10 0101000041
2013.09.15 14:44:04.298 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:44:04.309 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181A24AA IDcnt:0000
2013.09.15 14:44:11.926 1: HMLAN_Send: HMLAN1 I:+1D86F9,00,00,
2013.09.15 14:44:11.934 1: HMLAN_Send: HMLAN1 S:S21A65A5D stat: 00 t:00000000 d:01 r:21A65A5D m:01 A011 123A00 1D86F9 0201000000
2013.09.15 14:44:12.187 1: HMLAN_Parse: HMLAN1 R:R21A65A5D stat:0001 t:181A4317 d:FF r:FFBF m:01 8002 1D86F9 123A00 0101000045
2013.09.15 14:44:12.189 1: HMLAN_Parse: HMLAN1 new condition ok
2013.09.15 14:44:29.318 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:44:29.328 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181A8669 IDcnt:0001
2013.09.15 14:44:54.325 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:44:54.336 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181AE81C IDcnt:0001
2013.09.15 14:45:19.332 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:45:19.346 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181B49CF IDcnt:0001
2013.09.15 14:45:44.350 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:45:44.360 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181BAB8D IDcnt:0001
2013.09.15 14:46:09.357 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:46:09.367 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181C0D3F IDcnt:0001
2013.09.15 14:46:25.649 1: HMLAN_Parse: HMLAN1 R:E1A7E10 stat:0000 t:181C4CD5 d:FF r:FFC9 m:A0 8670 1A7E10 000000 00D744
2013.09.15 14:46:34.370 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:46:34.379 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181C6EF8 IDcnt:0001
2013.09.15 14:46:45.649 1: HMLAN_Parse: HMLAN1 R:E1A7E10 stat:0000 t:181C9AF8 d:FF r:FFC9 m:A0 A258 1A7E10 1C6134 0000
2013.09.15 14:46:45.989 1: HMLAN_Parse: HMLAN1 R:E1C6134 stat:0000 t:181C9B7C d:FF r:FFC1 m:A0 8202 1C6134 1A7E10 0101000040
2013.09.15 14:46:59.377 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:46:59.386 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181CD0AB IDcnt:0001
2013.09.15 14:47:24.389 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:47:24.400 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181D3263 IDcnt:0001
2013.09.15 14:47:49.406 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:47:49.417 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181D9420 IDcnt:0001
2013.09.15 14:48:14.415 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:48:14.429 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181DF5D8 IDcnt:0001
2013.09.15 14:48:39.787 1: HMLAN_Send: HMLAN1 I:K
2013.09.15 14:48:39.890 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314911 d:1C68C5 O:123A00 t:181E594F IDcnt:0001
Gruß
Stefan
hi,
kannst du ein "list" des device (nicht channel) machen, wenn der hängt?
gruss martin
Hi,
meinst du sowas?
list CUL_HM_switch_1D86F9
Internals:
DEF 1D86F9
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG R2294E6B5,0001,00DAD4D5,FF,FFC0,0180021D86F9123A000101C80043
HMLAN1_RSSI -64
HMLAN1_TIME 2013-09-15 19:04:45
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1
NAME CUL_HM_switch_1D86F9
NR 103
STATE CMDs_done_events:1
TYPE CUL_HM
channel_01 CUL_HM_switch_1D86F9_Sw_01
channel_02 CUL_HM_switch_1D86F9_Sw_02
channel_03 CUL_HM_switch_1D86F9_Sw_03
channel_04 CUL_HM_switch_1D86F9_Sw_04
lastMsg No:01 - t:02 s:1D86F9 d:123A00 0101C80043
protCmdDel 1
protIOerr 1 last_at:2013-09-15 19:06:02
protLastRcv 2013-09-15 19:04:45
protSnd 1 last_at:2013-09-15 19:04:45
protState CMDs_done_events:1
rssi_HMLAN1 avg:-67 min:-67 max:-67 lst:-67 cnt:1
rssi_at_HMLAN1 avg:-64 min:-64 max:-64 lst:-64 cnt:1
Readings:
2013-01-11 18:35:31 CommandAccepted yes
2013-09-11 09:04:48 level 0 %
2013-09-11 09:04:48 powerOn -
2013-09-15 19:06:02 state CMDs_done_events:1
Helper:
burstEvtCnt 1
mId 002D
rxType 1
Role:
dev 1
Rssi:
Hmlan1:
avg -67
cnt 1
lst -67
max -67
min -67
At_hmlan1:
avg -64
cnt 1
lst -64
max -64
min -64
Attributes:
expert 2_full
firmware 1.9
model HM-LC-SW4-PCB
peerIDs
room CUL_HM
serialNr JEQ0569624
subType switch
webCmd getConfig
ja, habe ich gemeint.
zu sehen ist, dass 1 von 1 sendeversuch fehlgeschlagen ist. Grund war ein io-error, also hmlan hat/hatte ein problem.
schaue einmal mit
list HMLAN1
etwas siehst. wie ist dessen state?
Bittesehr, ich seh jetzt leider nicht so wirklich was der für ein Problem haben könnte. Aber du vielleicht ;)
Internals:
DEF 192.168.1.120:1000
DeviceName 192.168.1.120:1000
FD 11
HMLAN1_MSGCNT 1
HMLAN1_TIME 2013-09-16 09:44:17
HM_CMDNR 1
NAME HMLAN1
NR 36
PARTIAL
RAWMSG R25BA21FC,0001,04002F59,FF,FFC0,0180021D86F9123A000101C80044
RSSI -64
STATE hmPairForSec 30
TYPE HMLAN
XmitOpen 1
assignIDs 1D86F9
assignIDsCnt 1
assignIDsReport 1
firmware 0.961
owner 123A00
serialNr JEQ0314911
uptime 000 18:38:52.801
Readings:
2013-09-16 09:44:17 Xmit-Events ok:1
2013-09-16 09:44:17 cond ok
2013-09-16 09:43:38 prot_disconnected last
2013-09-16 09:43:39 prot_init last
2013-09-16 09:44:17 prot_ok last
2013-01-11 18:35:22 state hmPairForSec 30
Helper:
123a00:
flg 0
1d86f9:
chn 02
flg 0
msg
name CUL_HM_switch_1D86F9
newChn +1D86F9,00,01,
to 1379317459.08481
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Ref:
hmtL 67132801
kTs 0
offL 1379250336259
sysL 1379317469060
Attributes:
hmId 123A00
hmLanQlen 1_min
wdTimer 25
Moin,
weil ich es in dem anderen Thread hier gerade gelesen habe... Der State hmPairForSec 30 ist drin seit ich HMLAN1 das letzte mal gepairt habe... dazwischen war er aber auch schon ein paar mal stromlos.
Kann ich den state irgendwie sonst noch ändern? Ich hab auch schon ein Firmware update über den Windows Homematic Lan-Interface Configurator versucht, aber der scheint nur eine ältere (???) Firmware zu haben.
Gruß
Stefan
hallo Stefan,
ja, das ist auch dein problem.
eigentlich sollte der state geaendert werden, wenn du den Stecker des hmlan ziehst. dann sollte es stimmen.
die neue Version des hmlan ist in SVN
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/00_HMLAN.pm?format=raw (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/00_HMLAN.pm?format=raw)
ein update funktioniert erst morgen, aber du kannst das file auch einfach holen und das im fhem-verzeichniss ersetzen. dann einen
shutdown restart
Gruss Martin
Hi,
leider hilft das gerade nicht...
Was ich getan habe:
1. deine neue Version von grad ebend rüber kopiert
2. shutdown restart
3. HMLAN1 vom Strom getrennt - warten - wieder anschließen
4. shutdown restart
Direkt nach den restart ist in FHEM der STATE auf opened gesetzt, aaaaber unter Readings steht immer noch ein State vom Januar 2013: hmPairForSec 30
Internals
DEF
192.168.1.120:1000
DeviceName
192.168.1.120:1000
FD
11
NAME
HMLAN1
NR
36
PARTIAL
STATE
opened
TYPE
HMLAN
XmitOpen
1
assignIDsReport
0
firmware
0.961
owner
123A00
serialNr
JEQ0314911
uptime
000 00:03:24.079
Readings
Xmit-Events
init:1
2013-09-16 10:58:16
cond
init
2013-09-16 10:58:16
prot_disconnected
last
2013-09-16 10:58:16
prot_init
last
2013-09-16 10:58:16
prot_ok
last
2013-09-16 10:54:16
state
hmPairForSec 30
2013-01-11 18:35:22
HMLAN1 Attributes
hmId
123A00
deleteattr
hmLanQlen
1_min
deleteattr
wdTimer
25
deleteattr
Select icon
Extend devStateIcon
Device specific help
wenn ich jetzt ein Kommando absetze, Lampe an oder aus... egal, dann steht auch der STATE vom HMLAN1 auf hmPairForSec 30:
Internals
DEF
192.168.1.120:1000
DeviceName
192.168.1.120:1000
FD
11
HMLAN1_MSGCNT
4
HMLAN1_TIME
2013-09-16 11:01:49
HM_CMDNR
1
NAME
HMLAN1
NR
36
PARTIAL
RAWMSG
R26011ED0,0001,00059804,FF,FFBD,0180021D86F9123A000101C80046
RSSI
-67
STATE
hmPairForSec 30
TYPE
HMLAN
XmitOpen
1
assignIDs
1D86F9
assignIDsCnt
1
assignIDsReport
1
firmware
0.961
msgParseDly
min:9 max:229 last:229 cnt:4
owner
123A00
serialNr
JEQ0314911
uptime
000 00:06:19.211
Readings
Xmit-Events
ok:1
2013-09-16 11:01:49
cond
ok
2013-09-16 11:01:49
prot_disconnected
last
2013-09-16 10:58:16
prot_init
last
2013-09-16 10:58:16
prot_ok
last
2013-09-16 11:01:49
state
hmPairForSec 30
2013-01-11 18:35:22
HMLAN1 Attributes
hmId
123A00
deleteattr
hmLanQlen
1_min
deleteattr
wdTimer
25
deleteattr
Ich habe schon überlegt den HMLAN1 adapter einmal aus FHEM zu löschen und neu anzulegen unter dem gleichen Namen. Weißt du ob dann alle damit verknüpften Geräte noch funktionieren oder ob ich die dann alle noch einmal neu anlegen muss?
Gruß
Stefan
Hallo Stefan,
das mit dem Löschen vom HMLAN aus FHEM war auch bei mir der einzige Weg den falschen Status los zu bekommen.
Die anderen Geräte bleiben erhalten. Aber ich musste in jedem Gerät manuell den HMLAN als IODEV setzen, bevor es wieder funktionierte.
Seitdem läuft es wieder problemlos.
Warum er sich aber auf einmal aufgehangen hat, ist unerklärlich. Bei mir war es vor dem Update auf die neue Versionen von Martin. Kein Update, nix gemacht und auf einmal fing er mit den Mucken an.
Gruß Christian
hi,
löschen und neu anlegen hat schon bei einem anderen geholfen. Ich bin nicht sicher, dass die devices sauber hochkommen. was passieren kann ist, dass hmlan NACH den devices definiert wird. Du müsstest im fhem.cfg sicherstelle, dass hmlan VOR allen geräten steht, die es nutzen, also einfach nach oben verschieben.
dann werde ich noch einmal suchen, wer da überschreibt. Ich denke es liegt an den readings. das state darin ist uralt und wird immer gesichert... und dann wird damit STATE überschrieben, alles grund-funktionen... leider
Gruss Martin
ps: Christian spricht die 2. Option an, das Attribut setzen. Dann ist egal, an welcher Stelle hmlan definiert wird.
ich werde das entsprechende reading löschen, in zukunft wird es also dieses Problem nicht mehr geben
OK, Danke für die Unterstützung.
Ich werde heute Abend mal versuchen das Interface zu löschen und neu anzulegen. Werd mal berichten wie es lief.
Gruß
Stefan
Ach, das Leben könnte so einfach sein wenn man immer gleich drauf kommen würde.
Als du sagtest die Readings werden gespeichert hat es bei mir klick gemacht. Es gibt im fhem Verzeichnis unter log/ eine Datei fhem.save. Dort werden die ganzen Werte gespeichert.
Die Lösung des Problems ist also insofern einfach:
1. shutdown (ohne restart)
2. in der Datei fhem.save die Zeile folgende Zeile löschen:
setstate HMLAN1 2013-01-11 18:35:22 state hmPairForSec 30
3. fhem wieder starten
Siehe da, das uralte Reading ist weg. Niemand setzt mehr unnötigerweise den Status vom HMLAN um und alles funktioniert mit deiner aktuellen Version.
Danke nochmals für die Unterstützung.
Gruß
Stefan
Hi Stefan,
korrekt bin auch nicht auf die readings gekommen.
Aber das muss hmlan am ende des Tages selbst machen - und die Version 3913 sollte es schaffen