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

[vbs]

Per USB. Werd ich im Post ergänzen, danke.

[frank]

die schwankungen der latenz kannst du eventuell besser in der roundtrip meldung im log verfolgen, wenn du attr logIDs=sys setzt.

für deinen anwendungsfall wäre der gpio sicher die beste anbindung mit der geringsten latenz. eine lan anbindung zeigt auch noch eine relativ geringe latenz. das zeigt ja auch dein hmlan.

[vbs]

Hab da auch schon drüber nachgedacht, welche Latenz man sich da einkauft, wenn man die Daten per USB-Seriall an den Maple schickt - der die Daten aus dem USB pult und dann auf die echte serielle Schnittstelle zum HM-MOD-UART schiebt. Unter guten Umständen, würde ich da jedoch eigentlich auch nur wenige Millisekunden erwarten, oder? Kann da jemand was zu sagen, um welche Größenordnung es da geht? Wäre schon unschön, wenn man den HM-MOD-UART vom Maple runter löten müsste und nochmal dediziert per seriell anbinden müsste, für gute Latenzen. Dann kann ich eigentlich auch gleich beim HM-CFG-USB bleiben

Aber zu dem Thema:
Die Latenz, die man hier sieht, die ist doch noch in FHEM, oder? Evtl. Maple-Latenzen kämen doch erst on top?

Code Auswählen Erweitern

2019.01.06 17:52:26.553 3 : CUL_HM bd_hmVirtualWeather CUL_HM_valvePosUpdt
2019.01.06 17:52:26.573 3 : CUL_HM bd_hmVirtualWeather nextF: 1546793698.55164
2019.01.06 17:52:26.626 3 : HMUARTLGW sys_culHm Dispatch: A0B448470F167890000000136::-35:sys_culHm

Habt ihr das Problem nicht bzw. ist euch nicht auch eine geringe Latenz wichtig? Also für mich ist auch unabhängig von dem virt.Sensor eine Schaltlatenz von merkbaren 400 ms einfach generell sehr unschön

Das mit dem roundtrip werde ich mir gerne ansehen, klingt spannend.

[frank]

hier gibt es ein paar vergleichsdaten, allerdings kein usb.
https://forum.fhem.de/index.php/topic,92576.msg851257.html#msg851257

der roundtripdelay ist scheinbar die zeit vom senden an den hmuart bis zum erhalt der angeforderten antwort (aktuelle load). im prinzip 2x signallaufzeit fhem => hmuart plus verarbeitungszeit beim hmuart.

bei deinen logeinträgen könnten auch noch fhem freezes beteiligt sein.

[vbs]

Das roundtrip ist interessant. Das ist ja einfach nur zum Weinen  :

Code Auswählen Erweitern

2019.01.06 21:35:18.411 0: HMUARTLGW sys_culHm roundtrip delay: 0.1397
2019.01.06 21:35:33.283 0: HMUARTLGW sys_culHm roundtrip delay: 0.0073
2019.01.06 21:35:46.889 0: HMUARTLGW sys_culHm roundtrip delay: 0.0151
2019.01.06 21:35:48.288 0: HMUARTLGW sys_culHm roundtrip delay: 0.0075
2019.01.06 21:36:03.633 0: HMUARTLGW sys_culHm roundtrip delay: 0.3464
2019.01.06 21:36:18.301 0: HMUARTLGW sys_culHm roundtrip delay: 0.0083
2019.01.06 21:36:33.468 0: HMUARTLGW sys_culHm roundtrip delay: 0.1709
2019.01.06 21:36:48.584 0: HMUARTLGW sys_culHm roundtrip delay: 0.2814
2019.01.06 21:37:03.636 0: HMUARTLGW sys_culHm roundtrip delay: 0.3276
2019.01.06 21:37:18.320 0: HMUARTLGW sys_culHm roundtrip delay: 0.0072
2019.01.06 21:37:33.537 0: HMUARTLGW sys_culHm roundtrip delay: 0.2199
2019.01.06 21:37:48.329 0: HMUARTLGW sys_culHm roundtrip delay: 0.0065
2019.01.06 21:38:03.335 0: HMUARTLGW sys_culHm roundtrip delay: 0.0078
2019.01.06 21:38:18.340 0: HMUARTLGW sys_culHm roundtrip delay: 0.0089
2019.01.06 21:38:33.535 0: HMUARTLGW sys_culHm roundtrip delay: 0.2000
2019.01.06 21:39:03.352 0: HMUARTLGW sys_culHm roundtrip delay: 0.0086
2019.01.06 21:39:18.538 0: HMUARTLGW sys_culHm roundtrip delay: 0.1904
2019.01.06 21:39:33.827 0: HMUARTLGW sys_culHm roundtrip delay: 0.4752
2019.01.06 21:39:48.379 0: HMUARTLGW sys_culHm roundtrip delay: 0.0237
2019.01.06 21:40:03.068 0: HMUARTLGW sys_culHm roundtrip delay: 0.0127
2019.01.06 21:40:03.365 0: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.06 21:40:18.371 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080

Der Kollege in dem Thread hat da per WLAN eine Latenz von 60 ms. Davon kann ich ja nur träumen. Geht bei mir locker bis 500 ms. Und das in nur ein paar Minuten. Ist doch nicht normal, oder? So diese 7-8 ms, die man da auch sieht - das wäre so meine Erwartung gewesen.

bei deinen logeinträgen könnten auch noch fhem freezes beteiligt sein.

Hab es einige Male mit HMLAN hin- und her getestet und der HMLAN hatte nie solche erhöhten Latenzen, darum glaub ich nicht, dass das FHEM-Freezes sind. Diese roundtrips scheint ein Feature vom UARTGW zu sein, oder? HMLAN spuckt sowas nicht aus, so scheint mir.

[frank]

bei solchen bescheidenen werten, wäre vielleicht auch eine warnung vom HMUARTLGW modul nicht schlecht. (oder max/min/avg werte als internal)

ich vermute mal, dass das maple-konzept/fw an den starken schwankungen schuld ist. werden dort nicht die signale auf bis zu 4 gateways verteilt?

ich denke mit einem "normalen" seriellen adapter am hmuart sieht das besser aus. für das timing der "normalen" kommunikation sind die delays sicherlich auch nicht schön.

[vbs]

ich vermute mal, dass das maple-konzept/fw an den starken schwankungen schuld ist. werden dort nicht die signale auf bis zu 4 gateways verteilt?

Generell ja, aber aber der HMUART hat in Linux ein eigens Device, welches 1:1 durchgeroutet wird soweit ich weiß. Also der Maple muss da nix überlegen, sondern nur vom USB die Daten lesen und dann auf den UART "kopieren" (und das auch wieder zurück natürlich).
Also die Verzögerungen (wenn sie denn dadurch kommen), würde ich erstmal als Bug einstufen. Weigere mich zu glauben, dass das per Konzept bis zu 500 ms Sekunden dauern soll, diese 30 Bytes von A nach B und wieder nach A zu kopieren.

Hab die Kollegen schon angefragt: https://forum.fhem.de/index.php/topic,60458.msg882753.html#msg882753

ich denke mit einem "normalen" seriellen adapter am hmuart sieht das besser aus. für das timing der "normalen" kommunikation sind die delays sicherlich auch nicht schön.

Das wäre wirklich mal interessant. Dann wüsste man definitiv, ob es an der Maple-Zwischenstation liegt, oder nicht. Dieser Verzögerungen wären für mich schon ein ziemlicher Showstopper 

[frank]

zum vergleich 5min meines hmuart am gpio eines pi3B

Code Auswählen Erweitern

2019.01.07 00:06:06.174 0: HMUARTLGW hmuart1 roundtrip delay: 0.0030
2019.01.07 00:06:21.178 0: HMUARTLGW hmuart1 roundtrip delay: 0.0030
2019.01.07 00:06:36.186 0: HMUARTLGW hmuart1 roundtrip delay: 0.0031
2019.01.07 00:06:51.190 0: HMUARTLGW hmuart1 roundtrip delay: 0.0032
2019.01.07 00:07:06.783 0: HMUARTLGW hmuart1 roundtrip delay: 0.0066
2019.01.07 00:07:21.784 0: HMUARTLGW hmuart1 roundtrip delay: 0.0031
2019.01.07 00:07:36.790 0: HMUARTLGW hmuart1 roundtrip delay: 0.0027
2019.01.07 00:07:51.795 0: HMUARTLGW hmuart1 roundtrip delay: 0.0030
2019.01.07 00:08:06.804 0: HMUARTLGW hmuart1 roundtrip delay: 0.0032
2019.01.07 00:08:13.597 0: HMUARTLGW hmuart1 roundtrip delay: 0.0049
2019.01.07 00:08:21.808 0: HMUARTLGW hmuart1 roundtrip delay: 0.0029
2019.01.07 00:08:36.814 0: HMUARTLGW hmuart1 roundtrip delay: 0.0030
2019.01.07 00:08:51.818 0: HMUARTLGW hmuart1 roundtrip delay: 0.0030
2019.01.07 00:09:06.825 0: HMUARTLGW hmuart1 roundtrip delay: 0.0032
2019.01.07 00:09:21.831 0: HMUARTLGW hmuart1 roundtrip delay: 0.0031
2019.01.07 00:09:36.838 0: HMUARTLGW hmuart1 roundtrip delay: 0.0031
2019.01.07 00:09:51.844 0: HMUARTLGW hmuart1 roundtrip delay: 0.0028
2019.01.07 00:10:06.848 0: HMUARTLGW hmuart1 roundtrip delay: 0.0030
2019.01.07 00:10:21.855 0: HMUARTLGW hmuart1 roundtrip delay: 0.0029
2019.01.07 00:10:36.860 0: HMUARTLGW hmuart1 roundtrip delay: 0.0031
2019.01.07 00:10:51.867 0: HMUARTLGW hmuart1 roundtrip delay: 0.0028
2019.01.07 00:11:06.875 0: HMUARTLGW hmuart1 roundtrip delay: 0.0032


[vbs]

Ja danke, sieht ja um ein paar Größenordnung besser aus.

Das letzte, was ich mich frage, ist, ob es diese RRT-Latenz ist, die man in diesen Logs sieht, oder ob die sogar noch oben drauf kommt:

Code Auswählen Erweitern

2019.01.06 17:54:58.606 3 : CUL_HM bd_hmVirtualWeather CUL_HM_valvePosUpdt
2019.01.06 17:54:58.616 3 : CUL_HM bd_hmVirtualWeather nextF: 1546793836.10302
2019.01.06 17:54:58.973 3 : HMUARTLGW sys_culHm Dispatch: A0B458470F16789000000013B::-36:sys_culHm
2019.01.06 17:54:58.975 5 : HMLAN/RAW: /EF16789,0000,056FEBFB,FF,FFAE,458470F16789000000013B
2019.01.06 17:54:58.975 5 : HMLAN_Parse: HMLAN0 R:EF16789 stat:0000 t:056FEBFB d:FF r:FFAE m:45 8470 F16789 000000 013B
2019.01.06 17:54:58.975 5 : HMLAN0: dispatch A0B458470F16789000000013B::-82:HMLAN0

[frank]

gute frage.

Code Auswählen Erweitern

2019.01.06 17:54:58.975 5 : HMLAN/RAW: /EF16789,0000,056FEBFB,FF,FFAE,458470F16789000000013B

die erste message vom hmlan zeigt ja bereits den empfang der funkmessage über den hmlan an. also muss der hmuart zu diesem zeitpunkt bereits gesendet haben. real wahrscheinlich sogar ein paar ms früher. also zumindestens ein teil der verzögerung sollte bereits enthalten sein. obwohl auch noch nicht geklärt ist, ob diese verzögerungen zum hmuart, vom hmuart, oder in beiden richtungen auftreten können.

ich frage mich gerade, in wie weit die roundtrip aktion/messung zb einen "freeze" erzeugt. wartet zb fhem auf die antwort, oder können andere aktionen zwischendurch abgearbeitet werden? dann könnte zb auch eine roundtrip messung, wenn sie zufällig gerade kurz vorm senden der virtuellen temp kommt, dieses senden zusätzlich verzögern.

ich würde mal beide logs zusammen anschauen, also mit "attr logIDs sys,bd_hmVirtualWeather". zusätzlich auch noch freezemon laufen lassen und hier zb mit "attr fm_freezeThreshold 0.3" auch kürzere freezes sichtbar machen.

[vbs]

Ich hoffe ja, dass mgernoth dazu noch was sagen kann. Ist gefühlt ja momentan etwas Fischen im Trüben.

Ich bin mir recht sicher, dass irgendwas im HMUARTLGW beim Senden blockierend passiert, da es bei mir recht schnell in apptime auftaucht mit ~300 ms.

[mgernoth]

Hallo,

HMUARTLGW benutzt die Fhem DevIO-Funktionen zum Senden. Um den Roundtrip zu berechnen, werden die periodischen Credits-Abfragen genutzt und deren Antwortzeit ausgewertet. Dabei wartet HMUARTLGW _nicht_ auf die Antwort vom Modul sondern wird beim Eintreffen derselben durch Fhem benachrichtigt (ist also nichtblockierend implementiert). Sollte irgendeine empfangene Nachricht dazwischenkommen wird die Roundtripberechnung nicht durchgeführt.

Wenn anscheinend die USB-Kommunikation mit dem MapleCUL nicht interruptbasiert ist, dann kann das diese riesen Latenzen erklären. Die verwendete DevIO-Funktion ist im eigentlichen send() blockierend, das ist aber eigentlich nirgends (bis auf den Fall jetzt) ein Problem. Selbst wenns nichtblockierend wäre, wären die riesigen und schwankenden Latenzen zum HMUART unbrauchbar.

Probier mal die im anderen Thread verlinkte Firmware, die wohl die Kommunikation auf Interrupts umstellt.

Viele Grüße
  Michael

[vbs]

Hallo Michael,

ok, vielen Dank! Also ich hab jetzt den HM-MOD-UART direkt per USB-Wandler an den Rechner angeschlossen und jetzt sehen die RTTs sehr gut aus:

Code Auswählen Erweitern

2019.01.08 08:36:15.050 5: HMUARTLGW sys_culHm roundtrip delay: 0.0039
2019.01.08 08:36:30.060 5: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.08 08:36:45.065 5: HMUARTLGW sys_culHm roundtrip delay: 0.0093
2019.01.08 08:38:05.711 0: HMUARTLGW sys_culHm roundtrip delay: 0.0052
2019.01.08 08:38:20.719 0: HMUARTLGW sys_culHm roundtrip delay: 0.0084
2019.01.08 08:38:35.728 0: HMUARTLGW sys_culHm roundtrip delay: 0.0088
2019.01.08 08:38:50.735 0: HMUARTLGW sys_culHm roundtrip delay: 0.0113
2019.01.08 08:39:05.744 0: HMUARTLGW sys_culHm roundtrip delay: 0.0113
2019.01.08 08:39:20.751 0: HMUARTLGW sys_culHm roundtrip delay: 0.0154
2019.01.08 08:39:35.747 0: HMUARTLGW sys_culHm roundtrip delay: 0.0059
2019.01.08 08:39:50.754 0: HMUARTLGW sys_culHm roundtrip delay: 0.0085
2019.01.08 08:40:05.762 0: HMUARTLGW sys_culHm roundtrip delay: 0.0126
2019.01.08 08:40:20.771 0: HMUARTLGW sys_culHm roundtrip delay: 0.0153
2019.01.08 08:40:35.778 0: HMUARTLGW sys_culHm roundtrip delay: 0.0183
2019.01.08 08:40:50.779 0: HMUARTLGW sys_culHm roundtrip delay: 0.0155
2019.01.08 08:41:05.787 0: HMUARTLGW sys_culHm roundtrip delay: 0.0124
2019.01.08 08:41:20.784 0: HMUARTLGW sys_culHm roundtrip delay: 0.0055


Ich hab jetzt auch mit dem gepeerten Sensor wieder eine Erfolgsrate >97 %. Also es lag wirklich an der schlechten RTT mit dem Maple. Telekatz sagte gerade jedoch, dass er bei sich auch mit Maple eine gute RTT hat. Also ich werde da mal weiter forschen müssen, warum das bei mir so schlecht its! 

Danke auch an frank für (immer wieder) sehr hilfreiche Kommentare.

[aHome77]

Hallo Zusammen,

hatte das attribut hmKey in hmlan1 und hmlan2. Da ein myHmUART dazugekommen ist läuft jetzt alles via vccu, auch das attribut hmKey ist jetzt nur noch in vccu.
Bei pairen von 2 HM-CC-RT-DN_Funk-Heizkörperthermostat kommt folgender Fehler:

Code Auswählen Erweitern

2019.02.09 14:20:31.825 1: HMUARTLGW myHmUART Adding peer 1FAA0C failed! You have probably forced an unknown aesKey for this device.
2019.02.09 14:20:31.831 1: HMUARTLGW myHmUART Adding peer 27A7CA failed! You have probably forced an unknown aesKey for this device.

An was könnte dies liegen? Bzw. wie löse ich das? 

[mfeske]

Hallo @mgernoth,

ich setze gerade einen RPI3B+ neu auf mit FHEM und bin jetzt beim einbinden des HM-CFG-USB-2 angekommen.
In meiner alten Installation ist er so eingebunden:

Code Auswählen Erweitern


define hmusb HMLAN 127.0.0.1:1234
setuuid hmusb 5c50079c-f33f-a44f-c529-2ec43549eb3055e5
attr hmusb event-on-change-reading 1
attr hmusb hmId 240271
attr hmusb hmLanQlen 1_min
attr hmusb loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr hmusb room Funkzentrale


Gibt es vielleicht mit diesem Modul einen einfacheren Weg ?

Gruß
Micha