HMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway

NilsB · 07 März 2017, 20:32:25

Habe den HM-LGW-O-TW-W-EU bei einem Bekannten im Einsatz und erlebe nach ein paar Wochen ähnliche Schwierigkeiten, was den Load angeht. Gibt es da irgend einen klugen Workaround oder bleibt das ein offenes Thema für den Moment?

Hier mal ein Ausschnitt direkt nach dem Neustart (gerade eben anlässlich eines Updates gemacht):

Code Auswählen

2017.03.07 20:13:22 0: Featurelevel: 5.8
2017.03.07 20:13:22 0: Server started with 51 defined entities (fhem.pl:13622/2017-03-05 perl:5.020002 os:linux user:fhem pid:3286)
2017.03.07 20:13:22 3: Opening OG.WZ.HMLAN:keepAlive device 10.0.70.3:2001
2017.03.07 20:13:22 3: OG.WZ.HMLAN device opened
2017.03.07 20:13:22 3: OG.WZ.HMLAN:keepAlive device opened
2017.03.07 20:13:22 3: HMUARTLGW OG.WZ.HMLAN BidCoS-port opened
2017.03.07 20:13:22 3: HMUARTLGW OG.WZ.HMLAN:keepAlive KeepAlive-port opened
2017.03.07 20:13:24 3: CUL_HM set DB.Kabuff.Rauchmelder statusRequest
2017.03.07 20:13:25 3: CUL_HM set DB.Zimmer.Rauchmelder statusRequest
2017.03.07 20:13:26 3: CUL_HM set EG.Flurwohnung statusRequest
2017.03.07 20:13:27 3: CUL_HM set EG.Kinderzimmer statusRequest
2017.03.07 20:13:28 3: CUL_HM set EG.SCHLAFZIMMER statusRequest
2017.03.07 20:13:29 3: CUL_HM set EG.Treppenhaus statusRequest
2017.03.07 20:13:30 3: CUL_HM set EG.Wohnzimmer statusRequest
2017.03.07 20:13:31 3: CUL_HM set OG.Birgitschlafzimmer statusRequest
2017.03.07 20:13:32 3: CUL_HM set OG.Flurwohnung statusRequest
2017.03.07 20:13:33 3: CUL_HM set OG.Lenaschlafzimmer statusRequest
2017.03.07 20:13:34 3: CUL_HM set OG.Wohnzimmer statusRequest
2017.03.07 20:13:35 3: CUL_HM set UG.Flur statusRequest
2017.03.07 20:13:36 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:36 3: CUL_HM set UG.Partykeller statusRequest
2017.03.07 20:13:37 3: CUL_HM set UG.Serverraum statusRequest
2017.03.07 20:13:37 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:38 3: CUL_HM set UG.Waschkeller statusRequest
2017.03.07 20:13:38 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:42 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:42 3: CUL_HM set DB.Kabuff.Rauchmelder getConfig
2017.03.07 20:13:43 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:46 3: CUL_HM set EG.Kinderzimmer getConfig
2017.03.07 20:13:47 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:48 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:13:50 3: CUL_HM set EG.SCHLAFZIMMER getConfig
2017.03.07 20:13:51 1: HMUARTLGW OG.WZ.HMLAN: queue is full, dropping packet
2017.03.07 20:14:02 3: CUL_HM set OG.Birgitschlafzimmer getConfig
2017.03.07 20:14:14 3: CUL_HM set OG.Wohnzimmer getConfig

Sporadisch tritt der Fehler auch auf. Seit Anfang des Monats ohne besonderen Zusammenhang 2x.
Im Einsatz sind rund 15 HM Devices, davon ein HM-Sec-WDS-2 ansonsten nur die neuen HM-Sec-SD-2, welche einen virtuellen Team-Lead in FHEM haben.

Schönen Abend und Gruß
Nils

Otto123 · 07 März 2017, 21:14:31

Hallo Nils,

qLen 60 gesetzt?

Gruß Otto

mgernoth · 08 März 2017, 10:11:17

Hallo,

nur um mal das Attribut qLen etwas zu erklären:

Das HMUARTLGW-Modul hat eine interne Warteschlange, in der die Befehle landen, bevor sie an das IO weitergegeben werden. Jeder Befehl in dieser Warteschlange wird bei Fehlern (abhängig vom Fehlertyp) maximal 3s lang wiederholt. Der Default von 20 stellt also sicher, dass niemals Befehle die älter als 1 Minute sind ausgeführt werden (im Worst-Case, wenn das IO bei jedem Befehl um Wiederholung bittet).

Wenn man das Attribut erhöht, erhöht sich auch das maximale Alter eines Befehls. Bei 60 (also 3 Minuten) sollte das aber noch kein Problem darstellen.

Mein HM-MOD-UART hat 56 HM-Geräte zugewiesen und ich habe mit der Standard-qLen von 20 keine Probleme.

Viele Grüße
Michael

Otto123 · 08 März 2017, 11:51:36

Hallo Michael,

ich habe 78 Geräte (wenn ich hmInfo glauben darf) und hatte mal die Meldung queue is full
Dann habe ich ohne viel nachzudenken qLen gesetzt (kam mir so wie eine Standardlösung rüber) und alles ist gut.

Danke für die Erklärung

Sollte man das nicht als Standardhilfe empfehlen?

Gruß Otto

NilsB · 08 März 2017, 21:19:50

Zitat von: Otto123 am 07 März 2017, 21:14:31
qLen 60 gesetzt?

Moin Otto,

besten Dank! Das hat für Abhilfe gesorgt. Kein Ärger mehr beim Neustart, bleibt nur noch der Langzeittest

Habe beim recherchieren zu dem Parameter deinen Blog gefunden - wandert in die RSS Feeds

Grüße
Nils

Klaus.A · 08 März 2017, 22:41:06

Hallo,

ich sehe ca. 1 x pro Tag Meldungen folgender Art im log:

Code Auswählen

2017.03.08 11:42:46 1: HMUARTLGW HMLANGW2 Ack with invalid counter received, dropping. We: 98, device: 245, state: 99, msg: 1 0402

Für ausreichend gute RSSI-Werte habe ich insgesamt 1 x HMLAN und 3 x HM-LGW-O-TW-W-EU (d.h. LAN-Gateways). Welches Device da mit falschem Zähler erkannt wird kann ich nicht erkennen. Mit Ausnahme von 2 Fernbedienungen sind alle Devices über eine VCCU als "preferred IO" zugewiesen. Der Zeitpunkt der Meldungen lässt für mich keinen Rückschluss auf das Device zu (kann zu dem Zeitpunkt nicht einer der FB's sein).

Weiter fällt mir auf, dass Gateways 2 und 3 eine längere Liste "Ackpending" haben. Das erste Gateway ist OK. Hier z.B. ein "list" vom zweiten Gateway (alle IOs sind durchnummeriert, beginnend mit dem HMLAN, deshalb ist der Name HMLANGW3):

Code Auswählen

Internals: 
   AssignedPeerCnt 30 
   CFGFN      ./myConfig/myHmLAN.cfg 
   CNT        98 
   DEF        192.168.53.137 
   DEVCNT     98 
   DevState   99 
   DevType    LGW 
   DeviceName 192.168.53.137:2000 
   FD         13 
   LastOpen   1488388736.12567 
   NAME       HMLANGW3 
   NR         57 
   PARTIAL 
   RAWMSG     040205 
   RSSI       -66 
   STATE      opened 
   TYPE       HMUARTLGW 
   XmitOpen   1 
   msgLoadCurrent 3 
   msgLoadHistory 0/0/0/-1/0/0/0/0/0/0/0/0 
   msgLoadHistoryAbs 2/2/2/2/3/3/3/3/3/3/3/3/3 
   owner      257867 
   owner_CCU  VCCU 
   Helper: 
     CreditTimer 41374 
     FW         66561 
     Initialized 1 
     SendCnt    4415 
     Ackpending: 
       1: 
         cmd        02000000A68002257867379E6A01013300 
         dst        1 
         frame      FD0013010102000000A68002257867379E6A01013300250B 
         time       1489007329.44136 
       111: 
         cmd        02000000828002257867379E4D01015B00 
         dst        1 
         frame      FD0013016F02000000828002257867379E4D01015B008A08 
         time       1489005370.35347 
       112: 
         cmd        02000000828002257867379E4D01015B00 
         dst        1 
         frame      FD0013017002000000828002257867379E4D01015B000782 
         time       1489005371.20172 
       118: 
         cmd        02000000A08002257867379E6A01013200 
         dst        1 
         frame      FD0013017602000000A08002257867379E6A0101320088B5 
         time       1489005451.52346 
       136: 
         cmd        02000000838002257867379E4D01015B00 
         dst        1 
         frame      FD0013018802000000838002257867379E4D01015B00144A 
         time       1489005697.12846 
       143: 
         cmd        02000000A18002257867379E6A01013200 
         dst        1 
         frame      FD0013018F02000000A18002257867379E6A010132000F6A 
         time       1489005795.45717 
       157: 
         cmd        02000000848002257867379E4D01015B00 
         dst        1 
         frame      FD0013019D02000000848002257867379E4D01015B006FCE 
         time       1489005994.10777 
       166: 
         cmd        02000000A28002257867379E6A01013300 
         dst        1 
         frame      FD001301A602000000A28002257867379E6A010133003FD1 
         time       1489006109.03323 
       177: 
         cmd        02000000858002257867379E4D01015B00 
         dst        1 
         frame      FD001301B102000000858002257867379E4D01015B00E231 
         time       1489006260.7647 
       18: 
         cmd        02000000898002257867379E4D01015B00 
         dst        1 
         frame      FD0013011202000000898002257867379E4D01015B0054B1 
         time       1489007561.20847 
       188: 
         cmd        02000000A38002257867379E6A01013300 
         dst        1 
         frame      FD001301BC02000000A38002257867379E6A01013300099C 
         time       1489006392.25937 
       205: 
         cmd        02000000868002257867379E4D01015B00 
         dst        1 
         frame      FD001301CD02000000868002257867379E4D01015B00D496 
         time       1489006630.95984 
       207: 
         cmd        02000000A48002257867379E6A01013300 
         dst        1 
         frame      FD001301CF02000000A48002257867379E6A010133000DF1 
         time       1489006645.65157 
       229: 
         cmd        02000000878002257867379E4D01015B00 
         dst        1 
         frame      FD001301E502000000878002257867379E4D01015B00893A 
         time       1489006971.36121 
       23: 
         cmd        02000000A78002257867379E6A01013300 
         dst        1 
         frame      FD0013011702000000A78002257867379E6A01013300E3B6 
         time       1489007626.33223 
       233: 
         cmd        02000000A58002257867379E6A01013300 
         dst        1 
         frame      FD001301E902000000A58002257867379E6A010133000886 
         time       1489007002.72027 
       253: 
         cmd        02000000888002257867379E4D01015B00 
         dst        1 
         frame      FD001301FD02000000888002257867379E4D01015B00EA50 
         time       1489007281.44293 
       42: 
         cmd        02000000A88002257867379E6A01013300 
         dst        1 
         frame      FD0013012A02000000A88002257867379E6A010133004614 
         time       1489007892.87259 
       47: 
         cmd        020000008A8002257867379E4D01015B00 
         dst        1 
         frame      FD0013012F020000008A8002257867379E4D01015B00731C 
         time       1489007944.50651 
       69: 
         cmd        02000000A98002257867379E6A01013300 
         dst        1 
         frame      FD0013014502000000A98002257867379E6A0101330072CA 
         time       1489008263.10265 
       73: 
         cmd        020000008B8002257867379E4D01015B00 
         dst        1 
         frame      FD00130149020000008B8002257867379E4D01015B00F376 
         time       1489008297.99522 
       94: 
         cmd        02000000AA8002257867379E6A01013300 
         dst        1 
         frame      FD0013015E02000000AA8002257867379E6A01013300AF93 
         time       1489008603.4927 
       96: 
         cmd        020000008C8002257867379E4D01015B00 
         dst        1 
         frame      FD00130160020000008C8002257867379E4D01015B00BBC8 
         time       1489008621.18598 
     LastSendLen: 
       3 
       3 
     Log: 
       IDs: 
     PeerQueue: 
     PendingCMD: 
     Roundtrip: 
       Delay      0.00380802154541016 
     Loadlvl: 
       lastHistory 1489008539.21785 
   Peers: 
     22BFE7     +22BFE7,00,01,00 
     22C462     +22C462,00,01,00 
     22C592     +22C592,00,01,00 
     22DD82     +22DD82,00,01,00 
     22F36C     +22F36C,00,01,00 
     22F6F8     +22F6F8,00,01,00 
     22F6F9     +22F6F9,00,01,00 
     230059     +230059,00,01,00 
     234657     +234657,00,01,00 
     2386DE     +2386DE,00,01,00 
     23871A     +23871A,00,01,00 
     238887     +238887,00,01,00 
     238BBC     +238BBC,00,01,00 
     238E89     +238E89,00,01,00 
     24DE15     +24DE15,00,01,00 
     261C4A     +261C4A,00,01,00 
     267BC1     +267BC1,00,01,00 
     2C681C     +2C681C,00,01,00 
     2C6856     +2C6856,00,01,00 
     3276E6     +3276E6,00,01,00 
     369122     +369122,00,01,00 
     374BB2     +374BB2,00,01,00 
     379E4D     +379E4D,00,01,00 
     379E6A     +379E6A,00,01,00 
     382324     +382324,00,01,00 
     38BEDA     +38BEDA,00,01,00 
     38BEF8     +38BEF8,00,01,00 
     4832CD     +4832CD,00,01,00 
     4C246E     +4C246E,00,01,00 
     4E504B     +4E504B,02,01,00 
   Readings: 
     2017-03-01 18:18:59   D-HMIdAssigned  257867 
     2017-03-01 18:18:59   D-HMIdOriginal  FFFFFF 
     2017-03-01 18:18:56   D-LANfirmware   1.1.5 
     2017-03-01 18:18:59   D-firmware      1.4.1 
     2017-03-01 18:18:56   D-serialNr      NEQ0707882 
     2017-03-01 18:18:56   D-type          eQ3-HM-LGW 
     2017-03-01 18:18:59   cond            ok 
     2017-03-08 22:30:23   load            3 
     2017-03-01 18:18:59   loadLvl         low 
     2017-03-01 18:18:56   state           opened 
   Helper: 
   Keepalive: 
     CNT        17 
     DEVCNT     16 
     DevState   99 
     DevType    LGW-KeepAlive 
     DeviceName 192.168.53.137:2001 
     FD         77 
     LastOpen   1488388736.17668 
     NAME       HMLANGW3:keepAlive 
     NR         7723 
     PARTIAL 
     STATE      opened 
     TEMPORARY  1 
     TYPE       HMUARTLGW 
     XmitOpen   0 
     Helper: 
       NextKeepAlive 1489008655.58634 
       Log: 
         Resolve    1 
         IDs: 
     Readings: 
       2017-03-01 18:18:56   state           opened 
     Lgwhash: 
Attributes: 
   hmId       257867 
   icon       hm_ccu 
   lgwPw      8TyerKrnhV 
   room       ZZ_Network

Jedes IO (HMLAN, Gateways) hat ca. 30 Devices zugeordnet. Die 2 FBs wechseln je nach Position.

Kommen die ACKs evtl. von einem anderen IO zurück und das aktuelle Gateway bekommt das deshalb nicht mit? Insgesamt funktioniert alles, die Devices haben auch keinerlei Probleme mit fehlenden ACKs. Sonderbar ist in FHEM von welchen IOs Rückmeldungen kommen - teilweise sind es IOs mit den schlechtesten RSSI Werten. Ich weiß, darauf hat FHEM keinen Einfluss, alle hören mit und irgendeiner gewinnt, warum auch immer ...

Ein Log ist etwas problematisch, weil viel abläuft und die Meldungen nur sporadisch auftreten. Ich könnte es natürlich versuchen, wenn das hilft - was sollte ich dann bitte als Log definieren?

Gruß, Klaus

mgernoth · 09 März 2017, 10:08:13

Hallo,

Zitat von: Klaus.A am 08 März 2017, 22:41:06
Code Auswählen Erweitern
2017.03.08 11:42:46 1: HMUARTLGW HMLANGW2 Ack with invalid counter received, dropping. We: 98, device: 245, state: 99, msg: 1 0402

Für ausreichend gute RSSI-Werte habe ich insgesamt 1 x HMLAN und 3 x HM-LGW-O-TW-W-EU (d.h. LAN-Gateways). Welches Device da mit falschem Zähler erkannt wird kann ich nicht erkennen.

Das ist Ok. Mit Device ist hier das IO gemeint, die Firmware ACKed ein Frame manchmal nach mehreren Stunden nochmals, wenn das ursprünglich angesprochene HM-Gerät wieder sendet. Ich werde den Log-Level auf 5 setzen, da das ein (nicht problematischer) Firmware-Quirk ist.

Zitat
Weiter fällt mir auf, dass Gateways 2 und 3 eine längere Liste "Ackpending" haben. Das erste Gateway ist OK. Hier z.B. ein "list" vom zweiten Gateway (alle IOs sind durchnummeriert, beginnend mit dem HMLAN, deshalb ist der Name HMLANGW3):

Frames, bei denen das BIDI-Bit nicht gesetzt ist (die also kein ACK vom Gerät anfordern) werden von der Firmware auch erst nach langer Zeit beantwortet, weswegen es diese AckPending-Liste gibt. Auf den ersten Blick haben alle Frames in AckPending bei Dir dieses Bit nicht gesetzt, weswegen das auch Ok ist.

Viele Grüße
Michael

Klaus.A · 09 März 2017, 10:23:08

Hallo Michael,

Danke für die ausführliche Erläuterung - gut zu wissen das alles OK ist (und auch immer wieder interessant und hilfreich einige Dinge besser zu verstehen).

Danke auch für Deine Arbeit an dem Modul für FHEM. Funktioniert hier wunderbar, das Gateway liefert sehr gute RSSI-Werte (scheint intern auch hardwareseitig wesentlich leistungsfähiger zu sein als der HMLAN) und läuft sehr stabil.

Gruß, Klaus

topfi · 09 März 2017, 10:26:19

Zitat von: mgernoth am 09 März 2017, 10:08:13
Hallo,

Das ist Ok. Mit Device ist hier das IO gemeint, die Firmware ACKed ein Frame manchmal nach mehreren Stunden nochmals, wenn das ursprünglich angesprochene HM-Gerät wieder sendet. Ich werde den Log-Level auf 5 setzen, da das ein (nicht problematischer) Firmware-Quirk ist.

Danke, das freut auch mich sehr. Bislang mache ich das nach jedem update händisch...

topfi · 09 März 2017, 20:39:48

Ich habe hier gerade ein neues Problem: Meine Installation umfasst zwei HMLAN-Adapter und ein HMUART-Modul auf einem entfernten Raspi über Socat.

Zuletzt musste ich freeze-Zeiten meines Hauptsystems feststellen. Die längste umfasste ca. 80 Minuten (!) nachts zwischen 2 und 4 Uhr. Ich habe das an HMLAN-Disconnects bemerkt und dann gesehen, dass in der Zeit sogar die Sysmon-Logs leer geblieben sind. Da hat FHEM auf dem NUC (Hauptsystem) überhaupt nichts mehr gemacht. Auf dem NUC läuft sonst noch ein Zarafa (das ist ein Exchange-Klon zum Synchronisieren meiner Kontakte und Kalender auf den Telefonen und Tablets), das hat derweil brav mit meinen Devices synchronisiert. Aber FHEM war echt tot. Das tritt ca. einmal am Tag auf, manchmal nur 1 Minute, manchmal lange. In solcher Phase empfängt der Raspi mit dem Modul (da ist sonst nur ein Mini-FHEM2FHEM drauf, dort läuft Sysmon dann noch) sehr viel übers Netzwerk. Ist der Spuk dann vorbei, sendet der NUC richtig viel übers Netz und der Raspi sendet und empfängt außergewöhnlich viel. Danach ist wieder alles in Ordnung.

Nach langer Fehlersuche habe ich das HMUART als Übeltäter ausgemacht. Wenn ich das auf dem NUC deaktiviere (dummy 1), ist das Phänomen weg. Was kann das sein? Kann das mit dem Puffer (qLen) zu tun haben? Ich habe das Attribut nicht verändert bzw. gesetzt. Die Zeitpunkte der Freezes sind oft nach Zeiten mit viel HM-Aufkommen wie Türkontakte usw. NUC und Raspi sind übrigens über LAN-Kabel verbunden, nicht über WLAN und auch nicht über Powerline.

Hier ist das Listing von dem HMUART:

Code Auswählen


Internals: 
   AssignedPeerCnt 7 
   CNT        201 
   DEF        uart://192.168.178.3:2000 
   DEVCNT     201 
   DevState   99 
   DevType    UART 
   DeviceName 192.168.0.83:2000 
   FD         108 
   LastOpen   1489046410.48903 
   NAME       HMUART1 
   NR         91 
   PARTIAL 
   RAWMSG     040201 
   RSSI       -53 
   STATE      opened 
   TYPE       HMUARTLGW 
   XmitOpen   1 
   msgLoadCurrent 1 
   msgLoadHistory 0/0/0/0/1/0/0/0/0/0/0/0 
   msgLoadHistoryAbs 1/1/1/1/1/0/0/0/0/0/0/0/0 
   owner      3844B1 
   owner_CCU  vccu 
   Helper: 
     CreditTimer 2707 
     FW         66561 
     Initialized 1 
     SendCnt    15 
     Ackpending: 
       100: 
         cmd        020000008280023844B127DD4601017400 
         dst        1 
         frame      FD00130164020000008280023844B127DD46010174002C62 
         time       1489086297.33707 
       101: 
         cmd        020000007480023844B12C96D700 
         dst        1 
         frame      FD00100165020000007480023844B12C96D700EB20 
         time       1489086297.64506 
       102: 
         cmd        020000008380023844B127DD4601017200 
         dst        1 
         frame      FD00130166020000008380023844B127DD46010172006FCA 
         time       1489086297.95299 
       94: 
         cmd        02000000A880023844B1390C7001012100 
         dst        1 
         frame      FD0013015E02000000A880023844B1390C700101210004A3 
         time       1489086295.57272 
       95: 
         cmd        020000001780023844B1390BB501011400 
         dst        1 
         frame      FD0013015F020000001780023844B1390BB501011400AF17 
         time       1489086295.88141 
       96: 
         cmd        020000008180023844B127DD4601017400 
         dst        1 
         frame      FD00130160020000008180023844B127DD46010174007CB1 
         time       1489086296.18956 
       98: 
         cmd        020000008280023844B127DD4601017400 
         dst        1 
         frame      FD00130162020000008280023844B127DD4601017400541A 
         time       1489086296.50718 
       99: 
         cmd        020000008380023844B127DD4601017200 
         dst        1 
         frame      FD00130163020000008380023844B127DD46010172002B8E 
         time       1489086296.815 
     LastSendLen: 
       3 
       3 
     Log: 
       IDs: 
     PeerQueue: 
     PendingCMD: 
     Roundtrip: 
       Delay      0.00555205345153809 
     Loadlvl: 
       lastHistory 1489087513.6712 
   Peers: 
     23DC7D     +23DC7D,00,02,00 
     2510B1     +2510B1,00,02,00 
     2C96D7     +2C96D7,00,02,00 
     2ECDBC     +2ECDBC,00,02,00 
     31B7A8     +31B7A8,00,02,00 
     35AE4C     +35AE4C,00,02,00 
     388666     +388666,00,02,00 
   Readings: 
     2017-03-09 09:00:13   D-HMIdAssigned  3844B1 
     2017-03-09 09:00:13   D-HMIdOriginal  4C6652 
     2017-03-09 09:00:13   D-firmware      1.4.1 
     2017-03-09 09:00:13   D-serialNr      NEQ0605455 
     2017-03-06 20:52:25   D-type          HM-MOD-UART 
     2017-03-09 09:00:13   cond            ok 
     2017-03-09 20:04:58   load            1 
     2017-03-09 09:00:13   loadLvl         low 
     2017-03-09 09:00:10   state           opened 
   Helper: 
Attributes: 
   devStateIcon .*opened:10px-kreis-gruen .*disconnected:10px-kreis-rot .*dummy:leer 
   event-on-change-reading .* 
   fp_FPDisplay1 982,1885,0 
   group      HMLAN 
   hmId       3844B1 
   hmKey      01:xxxxxxxxxxxxxxxxxxxxxxx

topfi · 16 März 2017, 22:30:20

Nachdem mein System ohne das HMUART nun seit 2 Wochen wieder tadellos läuft, habe ich zum Test mal einen jungfräulichen Raspi mit einem Minimal-Jessie versehen und außer dem Modul und socat überhaupt nichts installiert. Also im Prinzip ein reiner Selbstbau-HMLAN ohne Extras....

Ich bin gespannt, ob das nun fehlerfrei läuft und werde berichten.

Vielleicht liegen die oben beschriebenen Probleme ja daran, dass sich socat nicht mit einem gleichzeitig laufenden FHEM2FHEM verträgt, wer weiß?

mgernoth · 17 März 2017, 14:19:04

Hallo,

Zitat von: topfi am 16 März 2017, 22:30:20
Nachdem mein System ohne das HMUART nun seit 2 Wochen wieder tadellos läuft, habe ich zum Test mal einen jungfräulichen Raspi mit einem Minimal-Jessie versehen und außer dem Modul und socat überhaupt nichts installiert. Also im Prinzip ein reiner Selbstbau-HMLAN ohne Extras....

Hmm, ich wüsste nicht, wo das HMUARTLGW-Modul blockieren könnte, das ist schon merkwürdig, was da bei Dir passiert ist.

Zitat
Ich bin gespannt, ob das nun fehlerfrei läuft und werde berichten.

Kannst Du falls es doch nochmal passiert (was ich nicht hoffe) bitte versuchen mit apptime herauszufinden, was blockiert?

Viele Grüße
Michael

topfi · 28 März 2017, 21:22:25

Um das angesprochene Problem abzuschließen:

Nachdem ich den Zweit-Raspi, der dem Hauptsystem das HMUART mit socat zur Verfügung stellt und (unabhängig davon) mit FHEM2FHEM und einem zweiten CUL Intertechno-Befehle wiederholt, komplett neu mit aktuellem Jessie und aktuellem FHEM aufgesetzt habe, ist alles in Ordnung und läuft stabil. Das Repeatersystem war einfach nicht ordentlich gepflegt, da lief noch FHEm 5.6 ...

leachim200 · 05 Juli 2017, 14:46:34

Hallo
Ich hab mich nun etwas eingelesen durchgeschaut und alles versucht so halbwegs richtig zu verstehen.

Jetzt bleibt mir nur mehr die Frage hab ich das so richtig verstanden.
Was habe ich vor:
HM-MOD-RPI-PCB an seperaten RPI anschließen auf dem kein FHEM läuft
Diesen in meine FHEM installation integrieren

Ausgangslage:
FHEM neueste Version mit einer VCCU und HM-USB.

Was würde ich machen:
1) Vorbereitung der Seriel Schnittstelle laut anleitung
2) Kontrolle
3) Remoteanbindung - Pi + RPI Modul = LAN Modul
4) define RM_HmUART_EG HMUARTLGW uart://<ip-adresse>:2000
5) Anlernen an die VCCU

Stimmt das so oder habe ich etwas falsch verstanden?

MadMax-FHEM · 05 Juli 2017, 16:10:50

Zitat von: leachim200 am 05 Juli 2017, 14:46:34
Hallo
Ich hab mich nun etwas eingelesen durchgeschaut und alles versucht so halbwegs richtig zu verstehen.

Jetzt bleibt mir nur mehr die Frage hab ich das so richtig verstanden.
Was habe ich vor:
HM-MOD-RPI-PCB an seperaten RPI anschließen auf dem kein FHEM läuft
Diesen in meine FHEM installation integrieren

Ausgangslage:
FHEM neueste Version mit einer VCCU und HM-USB.

Was würde ich machen:
1) Vorbereitung der Seriel Schnittstelle laut anleitung
2) Kontrolle
3) Remoteanbindung - Pi + RPI Modul = LAN Modul
4) define RM_HmUART_EG HMUARTLGW uart://<ip-adresse>:2000
5) Anlernen an die VCCU

Stimmt das so oder habe ich etwas falsch verstanden?

Wenn du mit Remoteanbindung sowas wie socat etc. meinst und du das Einspielen der aktuellen FW usw. machst (also nur wegen Übersichtlichkeit ausgelassen hast) sollte es so in etwa gehen...
...allerdings ist das ein ganz schön teurer "HM-LAN" wenn der PI nichts anderes mehr tut.

Dann würde ein ESP mit SerialBridge auch gereicht haben bzw. auch ein PI Zero...
...oder wenn LAN (statt WLAN) auch einfach ein Serial-LAN-Adapter...

Gruß, Joachim