Latenz HMLAN vs. HM-CFG-USB

[vbs]

Ich habe bisher einen HMLAN benutzt, habe mir jetzt jedoch auch mal einen HM-CFG-USB besorgt, um Firmware-Updates durchführen zu können und evtl. komplett umzusteigen. Ich hatte hier an mehreren Stellen gelesen, dass der USB Latenzvorteile hätte ggü. dem HMLAN.

Nun ist es so, dass der USB bei mir leider langsamer ist als der HMLAN. Ich merke das zum Beispiel, wenn ich drei Befehle hintereinander absende. Also zum Beispiel drei Steckdosen am Stück schalte. Bei dem HMLAN liegen zwischen den Schaltvorgänge subjektiv nur minimale Pausen. Mit dem USB sind die merklich länger.

So sieht die Log-Ausgabe aus von drei Befehlen an den USB (man beachte die Zeitstempel):

Code Auswählen Erweitern


2014.11.22 23:12:32.865 3: CUL_HM set wz_lightRed on
2014.11.22 23:12:32.867 5: HMLAN_Send:  HMUSB S:SD9904D2C stat:  00 t:00000000 d:01 r:D9904D2C m:12 A011 F15544 2072A5 0201C80000
2014.11.22 23:12:32.868 3: CUL_HM set wz_lightSpot on
2014.11.22 23:12:32.870 3: CUL_HM set wz_lightDesk on
2014.11.22 23:12:33.081 5: HMLAN/RAW: /RD9904D2C,0001,24E4E3E9,FF,FFC0,1280022072A5F155440101C8003C

2014.11.22 23:12:33.083 5: HMLAN_Parse: HMUSB R:RD9904D2C stat:0001 t:24E4E3E9 d:FF r:FFC0     m:12 8002 2072A5 F15544 0101C8003C
2014.11.22 23:12:33.084 5: HMUSB dispatch A0E1280022072A5F155440101C8003C::-64:HMUSB
2014.11.22 23:12:33.271 5: HMLAN_Send:  HMUSB S:SD9904EC0 stat:  00 t:00000000 d:01 r:D9904EC0 m:13 A011 F15544 22BA55 0201C80000
2014.11.22 23:12:33.501 5: HMLAN/RAW: /RD9904EC0,0001,24E4E588,FF,FFC5,13800222BA55F155440101C8003B

2014.11.22 23:12:33.503 5: HMLAN_Parse: HMUSB R:RD9904EC0 stat:0001 t:24E4E588 d:FF r:FFC5     m:13 8002 22BA55 F15544 0101C8003B
2014.11.22 23:12:33.505 5: HMUSB dispatch A0E13800222BA55F155440101C8003B::-59:HMUSB
2014.11.22 23:12:33.677 5: HMLAN_Send:  HMUSB S:SD9905056 stat:  00 t:00000000 d:01 r:D9905056 m:14 A011 F15544 2071DA 0201C80000
2014.11.22 23:12:33.880 5: HMLAN/RAW: /RD9905056,0001,24E4E728,FF,FFC9,1480022071DAF155440101C80032

2014.11.22 23:12:33.882 5: HMLAN_Parse: HMUSB R:RD9905056 stat:0001 t:24E4E728 d:FF r:FFC9     m:14 8002 2071DA F15544 0101C80032
2014.11.22 23:12:33.883 5: HMUSB dispatch A0E1480022071DAF155440101C80032::-55:HMUSB


Und so sieht das gleiche aus mit einem HMLAN:

Code Auswählen Erweitern


2014.11.22 23:21:28.181 3: CUL_HM set wz_lightRed on
2014.11.22 23:21:28.183 5: HMLAN_Send:  HMLAN0 S:SD9987840 stat:  00 t:00000000 d:01 r:D9987840 m:12 A011 F15544 2072A5 0201C80000
2014.11.22 23:21:28.185 3: CUL_HM set wz_lightSpot on
2014.11.22 23:21:28.186 3: CUL_HM set wz_lightDesk on
2014.11.22 23:21:28.346 5: HMLAN/RAW: /RD9987840,0001,05141D03,FF,FFBC,1280022072A5F155440101C80040

2014.11.22 23:21:28.347 5: HMLAN_Parse: HMLAN0 R:RD9987840 stat:0001 t:05141D03 d:FF r:FFBC     m:12 8002 2072A5 F15544 0101C80040
2014.11.22 23:21:28.347 5: HMLAN0 dispatch A0E1280022072A5F155440101C80040::-68:HMLAN0
2014.11.22 23:21:28.389 5: HMLAN_Send:  HMLAN0 S:SD998790E stat:  00 t:00000000 d:01 r:D998790E m:13 A011 F15544 22BA55 0201C80000
2014.11.22 23:21:28.550 5: HMLAN/RAW: /RD998790E,0001,05141DCF,FF,FFB6,13800222BA55F155440101C80049

2014.11.22 23:21:28.551 5: HMLAN_Parse: HMLAN0 R:RD998790E stat:0001 t:05141DCF d:FF r:FFB6     m:13 8002 22BA55 F15544 0101C80049
2014.11.22 23:21:28.551 5: HMLAN0 dispatch A0E13800222BA55F155440101C80049::-74:HMLAN0
2014.11.22 23:21:28.592 5: HMLAN_Send:  HMLAN0 S:SD99879D9 stat:  00 t:00000000 d:01 r:D99879D9 m:14 A011 F15544 2071DA 0201C80000
2014.11.22 23:21:28.755 5: HMLAN/RAW: /RD99879D9,0001,05141E9C,FF,FFB5,1480022071DAF155440101C80046

2014.11.22 23:21:28.757 5: HMLAN_Parse: HMLAN0 R:RD99879D9 stat:0001 t:05141E9C d:FF r:FFB5     m:14 8002 2071DA F15544 0101C80046
2014.11.22 23:21:28.758 5: HMLAN0 dispatch A0E1480022071DAF155440101C80046::-75:HMLAN0


So wie ich das sehe, dauert das Abarbeiten eines Befehls beim USB ungefähr doppelt so lang wie beim HMLAN. Also bei dem USB liegen zwischen zwei Sends ca. 400 ms. Bei dem HMLAN sind es nur ca. 200 ms.
Das reine Senden zum Device bis zum Empfang des ACK dauert beim USB etwas über 200 ms (Differenz zwischen 'Send' und 'RAW') und beim HMLAN nur 160 ms. Ist also erstmal noch nicht sooo der riesen Unterschied. In die 200 ms beim USB gehen ca. 50 - 70 ms ein, die hmland für die reine USB-Übertragung benötigt. Also die erste Frage, die sich mir stellt, wäre: Ist das ein "normaler" Wert, dass mit dem CFG-USB mehr als 200 ms vom Versenden des Befehls bis zum ACK vergehen? Ich hatte eigentlich eine geringere Latenz als beim HMLAN erwartet (gemäß anderen Threads).

Eine andere Sache, die in den Logs auffällt ist, dass beim USB zwischen dem Dispatch und dem nachfolgenden Send auch wieder knapp 200 ms vergehen. Beim HMLAN jedoch nur ca. 40 ms. Ist das nicht komisch? Was passiert da? Wenn ich es richtig verstehe, dann muss es sich dabei ja um Verarbeitungszeit in fhem handeln und nicht im Device selber. Außerdem dachte ich, dass fhem nicht weiß, ob es sich um ein USB oder ein HMLAN handelt.

Ich habe übrigens beide Tests mit einer fast leeren fhem-Config durchgeführt, die eigentlich nur das jeweilige HM-Device und die drei Lampen beinhaltet. Das Ganze läuft in einer VMWare mit TinyCore-Linux auf einem i5-Windows8.1-Host.

[franky08]

Da kann ich dir nur beipflichten, ich habe den Usb nur noch für update Zwecke und ansonnsten zwei HMLAN über vccu am laufen. Mit dem USB Teil war ich, was timings angeht auch nicht glücklich.

VG
Frank

[martinp876]

ich habe kein HMUsb zum testen.
Was schneller ist hängt von der SW in den Devices sowie dem Protokoll stack im Rechner ab. Beides ist denkbar.

[vbs]

Hi Martin!
Klar, verstehe ich. Aber könntest du evtl. etwas sagen zu der Pause zwischen dem Dispatch und dem nachfolgenden Send des nächsten Befehls? Die Pause ist bei dem USB doch recht groß (fast 200 ms) und ich kann mir im Moment so gar nicht erklären, woher die kommt.


Könnte vielleicht jemand anders mit einem HMUsb einmal testen, wie die Zeiten bei ihm aussehen? Einfach Logging auf 5 stellen und mseclog aktivieren. Dann drei Devices in einem Befehl schalten.

[martinp876]

Hi,
Hmlan und usb werden im culhm code nicht unterschieden. Ist garnicht moeglich (eigentlich schade, da es noch nicht einmal in 00_hmlan moeglich ist.
Eine zwangspause legt hmlan ein, wenn wir zu schnell sind. Eine antwort darf erst nach 100ms kommen. Hmlan oder auch cul warten entsprechend. Hier wird aktiv gewartet, da die antwort nach 250ms gegeben werden muss. Wuerden wir dispatchen koennten wir das nicht halten.
Die zeit wird anhand der timestamps des hmlan / usb kalkuliert - die zeiten in fhem sind zu ungenau. Der delay und die varianz der interfaces sind zu unstabil. Bei cul ist das in vorbereitung - wartet auf eine akzeptanz von rudi - schon recht lange. Bei bedarf gibt es aber schon fertigen .funktionsfaehigen code hierzu.
Alles was sonst noch verzoegert sollte identisch sein oder liegt am stack des io - oder im io.
Wenn usb scheller ist kann das delay in fhem vortaeuschen, dass es langsamer ist... da fhem warten muss

[vbs]

Sorry, dass ich nochmal nachfragen muss, aber ich versteh es leider noch nicht

Vielleicht beschreibe ich das Problem nochmal anders:
Das Abarbeiten eines Befehls besteht doch aus der Sequenz aus den Log-Zeilen Send->RAW->Parse->Dispatch, richtig? Das Abarbeiten eines einzelnen Befehls funktioniert wie erwartet. Zwischen dem "Send" und dem "RAW" liegt die erwartete Differenz, die ich dem Device zuschreiben würde. Ich gehe davon aus, dass "Send" den Befehl an das Device sendet und bei "RAW" die Antwort eingeht. Sieht gut aus.

Aber: wenn ich den HMUSB benutze und drei Befehle am Stück absende, dann liegt manchmal _zwischen_ zwei Befehlen (zwischen Dispatch und Send) eine Pause von ~200 ms, manchmal jedoch nur 2 ms.
Hier nochmal ein Beispiel anhand eines Logauszugs, bei dem drei Befehle gesendet werden. Zwischen dem ersten und zweiten Befehl, passiert die unerwartete Pause. Zwischen dem zweiten und dritten Befehl passiert die Pause nicht. Diese sporadischen Pausen zwischen den Befehlen sind deutlich merkbar. Ich habe mal Kommentare an die beiden Stellen geschrieben, die ich meine:

Code Auswählen Erweitern


2014.11.23 20:32:58.810 3: CUL_HM set wz_lightRed on
2014.11.23 20:32:58.810 5: HMLAN_Send:  HMUSB S:SDE249283 stat:  00 t:00000000 d:01 r:DE249283 m:14 A011 F15544 2072A5 0201C80000
2014.11.23 20:32:58.811 3: CUL_HM set wz_lightSpot on
2014.11.23 20:32:58.812 3: CUL_HM set wz_lightDesk on
2014.11.23 20:32:59.031 5: HMLAN/RAW: /RDE249283,0001,019FF7BE,FF,FFC2,1480022072A5F155440101C8003A
2014.11.23 20:32:59.031 5: HMLAN_Parse: HMUSB R:RDE249283 stat:0001 t:019FF7BE d:FF r:FFC2     m:14 8002 2072A5 F15544 0101C8003A
2014.11.23 20:32:59.031 5: HMUSB dispatch A0E1480022072A5F155440101C8003A::-62:HMUSB

<hier ist jetzt der erste Befehl abgearbeitet, oder? Bis zum "Send" des zweiten Befehls vergehen jedoch noch 182 ms>

2014.11.23 20:32:59.213 5: HMLAN_Send:  HMUSB S:SDE249416 stat:  00 t:00000000 d:01 r:DE249416 m:15 A011 F15544 22BA55 0201C80000
2014.11.23 20:32:59.412 5: HMLAN/RAW: /RDE249416,0001,019FF95D,FF,FFB6,15800222BA55F155440101C8004C
2014.11.23 20:32:59.413 5: HMLAN_Parse: HMUSB R:RDE249416 stat:0001 t:019FF95D d:FF r:FFB6     m:15 8002 22BA55 F15544 0101C8004C
2014.11.23 20:32:59.413 5: HMUSB dispatch A0E15800222BA55F155440101C8004C::-74:HMUSB

<hier ist jetzt der zweite Befehl abgearbeitet. Dieses Mal wird jedoch vor dem dritten Befehl nur eine Pause von 2 ms gemacht (?!)>

2014.11.23 20:32:59.415 5: HMLAN_Send:  HMUSB S:SDE2494E0 stat:  00 t:00000000 d:01 r:DE2494E0 m:16 A011 F15544 2071DA 0201C80000
2014.11.23 20:32:59.604 5: HMLAN/RAW: /RDE2494E0,0001,019FFA1D,FF,FFC9,1680022071DAF155440101C80032
2014.11.23 20:32:59.604 5: HMLAN_Parse: HMUSB R:RDE2494E0 stat:0001 t:019FFA1D d:FF r:FFC9     m:16 8002 2071DA F15544 0101C80032
2014.11.23 20:32:59.605 5: HMUSB dispatch A0E1680022071DAF155440101C80032::-55:HMUSB


Nochmals sorry, falls du das weiter oben schon beantwortet hast, dann hab ich es scheinbar nicht verstanden :/

[vbs]

Hi Martin,

ich habe mir das heute nochmal angesehen und ich glaube, ich weiß jetzt, woher die Verzögerung kommt:
Wenn man mehrere Befehle queuet, dann wird ja ein Befehl sofort abgesendet. Mit dem Senden dieses Befehls wird der Timer "CUL_HM_sndIfOpen" gestartet, der alle 200 ms aufgerufen wird. Sobald dann die Antwort auf den ersten Befehl empfangen wurde, wird der nächste Befehl erst im Raster dieses 200ms-Timers abgesendet.

Also wenn ich mit dem HMLAN einen Befehl absende, dann wird zeitgleich der 200ms-Timer gestartet. Nach 160ms (bei mir) erhalte ich vom HMLAN die Antwort. Nach weiteren 40ms (160 + 40 = 200) kommt wieder der Timer zum Zug und kann den nächsten Befehl verschicken. Also war da eine künstliche Pause von 40 ms vor dem Versenden des nächsten Befehls.
Im Falle von HMUSB ist die Latenz bei mir schwankend. Manchmal größer als 200 ms. Das heißt, wenn ich mit HMUSB einen Befehl versende und, sagen wir, nach 210 ms die Antwort bekomme, dann habe ich gerade den Timer zum Absenden des nächsten Befehls verpasst und ich muss nun weitere 190 ms warten bis der nächste Timer kommt, um den nächsten Befehl zu versenden.

Diese ganze Theorie passt mMn auch perfekt auf die Logs, die ich oben gepostet habe. Alle Pausen, die man sieht, sind immer genau die Differenzen zu einem 200ms-Raster ausgehend vom ersten Aufruf von "HMLAN_Send".

Ich glaube daher, dass man das Zeitverhalten beim Absenden mehrer Befehle verbessern könnte, wenn man die Pausen wegbekommt. Der einfachste Weg wäre, das Interval von 200 ms kleiner zu machen. Zum Beispiel 20 ms. Aber das hat natürlich auch entsprechend Nachteile...
Noch schöner wäre es, wenn man sich beim Senden von mehreren Befehlen komplett von diesem Timer-Raster entkoppeln könnte. Wenn man zB direkt nach dem Empfang der Antwort gucken würde, ob noch Befehle in der Queue zum Absenden vorhanden sind und dies dann direkt machen würde, ohne dass man auf den nächsten Timer warten müsste. Leider kenn ich mich im HM-Code zu wenig aus, um da konkrete Vorschläge machen zu können. Aber vielleicht hast du da ja eine Idee...

[martinp876]

Das Abarbeiten eines Befehls besteht doch aus der Sequenz aus den Log-Zeilen Send->RAW->Parse->Dispatch, richtig?

nun ja... wie mans nimmt. parsen kommt schon auch noch - und trigger.... und....

die ich dem Device zuschreiben würde.

warum? es kommt immerhin noch dein OS mit dem Stack den USB oder Ethernet. Sende und Empfangsseitig. Das kann erheblich sein.

Das heißt, wenn ich mit HMUSB einen Befehl versende und, sagen wir, nach 210 ms die Antwort bekomme, dann habe ich gerade den Timer zum Absenden des nächsten Befehls verpasst und ich muss nun weitere 190 ms warten bis der nächste Timer kommt, um den nächsten Befehl zu versenden.

das sollte nicht sein. Mit dem Empfang der message muss sofort - nciht nach Raster - geprüft werden, ob was zu senden ist. Wenn das nicht der Fall ist, muss es geändert werden.

Die 200ms beziehen sich nur auf das Senden an ein device. Es kann an  ein anderes Device gesendet werden. Die HMQlen steuert, wie viele Devices parallel behandelt werden sollen.

Ich werde mir die Logs einmal durchsehen. Ein Raster darf es nicht geben - melde mich wieder.

[martinp876]

die 200ms eixistieren so nicht.
1) wie du gesehen hast, kannst du raw und dispatch aus denlogs entfernen. HMLAN_Send und HMLAN_Parse sind genau genug (+-1ms). Macht das lesen deutlich einfacher.

2) Sendeverzögerungen beziehen sich immer auf eine destination. HMLAN kann schneller senden - es gibt aber ein paar Zusammenhänge, die es schwierig mchen

3) was du aufgezeichnet hast mit den 200ms delay sind verzögerungen der Antworten eines Device. Ein Device antwortet etwa 150ms nach dem Empfang eines Kommandos. HM erwartet eine Antwort nach 150 bis 300ms nach einer Message. Das darfst du nicht verletzen. Es ist je device - zwischendurch könntest du an andere senden... wird dann aber kompex, da keine Arbitrierung der "Luft" stattfindet und es kollisionen geben kann.

4) Ein Befehl ist nicht nach "dispatch" dem CUL_HM zugestellt - dann geht es erst los!

5) das Timing, wann AN EIN DEVICE gesendet werden darf wird NICHT aus den aus den fhem-zeitstempeln errechnet - die sind bei weiten zu ungenau. Die berechnung erfolgt anhand der vom HMLAN bereitgestellten Zeitstempel.

6) HMLAN verzögert activ. Grund ist, dass die verzögerung relativ kurz ist. passives Warten ist nicht möglich, da der FHEM kernal leider nicht rechtzeitig ein auswachen garantiert - es käme zu Protokollfehlern

7) CUL_HM queued Kommandos wenn HMLAN nicht sendebereit ist. Hier haben wir die 200ms polling. Das warten hier bezeiht sich aber auf nicht geöffnete Devices (overload,...) und fragt regelmäßig ab, ob die Bedingung nicht mehr existiert. Ein Abfragen alle 20ms empfehle ich nicht, da es die systemlast unnötig erhöht. Generell werde ich das keinem System zumuten. Du kannst es dir gerne ändern ($IOpoll in CUL_HM) aber ich glaube nicht, dass es irgendetwas im normalbetrieb beschleunigt. Nach meinen Tests wird die Prozedur nie aufgerufen wenn ich z.B. eine Konfig abrufe.

provizierte Delays werden ggf. von HMLAN geloggt - du kannst es einschalten, HMLAN loglevel 3

Ich sehen keinen Ansatz für eine Beschleunigung - auch in deinen Logs nicht.

Ich sehe

[vbs]

7) CUL_HM queued Kommandos wenn HMLAN nicht sendebereit ist. Hier haben wir die 200ms polling. Das warten hier bezeiht sich aber auf nicht geöffnete Devices (overload,...) und fragt regelmäßig ab, ob die Bedingung nicht mehr existiert. Ein Abfragen alle 20ms empfehle ich nicht, da es die systemlast unnötig erhöht. Generell werde ich das keinem System zumuten. Du kannst es dir gerne ändern ($IOpoll in CUL_HM) aber ich glaube nicht, dass es irgendetwas im normalbetrieb beschleunigt. Nach meinen Tests wird die Prozedur nie aufgerufen wenn ich z.B. eine Konfig abrufe.

Also ich mag mich ja irren, du bist hier der Experte. Aber ich habe relativ viel mit diesem 200ms-Raster rumprobiert und ich meine sehr deutlich gesehen zu haben, dass nur in diesem Raster gesendet wird, wenn ich zB 3 Befehle am Stück absetzen möchte (mit hmqlen=1). Wenn ich die 200ms verringere, dann führt das dazu, dass die Lampen (deutlich sichtbar) schneller schalten.

Nochmal zu dem Log bitte:

Code Auswählen Erweitern


2014.11.23 20:32:58.810 5: HMLAN_Send:  HMUSB S:SDE249283 stat:  00 t:00000000 d:01 r:DE249283 m:14 A011 F15544 2072A5 0201C80000
2014.11.23 20:32:59.031 5: HMLAN_Parse: HMUSB R:RDE249283 stat:0001 t:019FF7BE d:FF r:FFC2     m:14 8002 2072A5 F15544 0101C8003A

<hier ist jetzt der erste Befehl abgearbeitet, oder? Bis zum "Send" des zweiten Befehls vergehen jedoch noch 182 ms>

2014.11.23 20:32:59.213 5: HMLAN_Send:  HMUSB S:SDE249416 stat:  00 t:00000000 d:01 r:DE249416 m:15 A011 F15544 22BA55 0201C80000


Hier sieht man das Senden von zwei Befehlen am Stück. Nachdem der erste abgearbeitet ist (HMLAN_Parse), entsteht eine Pause von 182 ms bis der folgende Befehl gesendet wird. Diese Pause ist doch keine Verzögerung der Antworten eines Device, oder? Die Pause entsteht mMn durch das 200ms-Raster, welches mit dem ersten Send gestartet wird. Es wird scheinbar nicht nach dem Parsen des ersten Befehls direkt geschaut, ob noch ein weiterer Befehl zum Senden da ist, sondern erst der folgende 200ms-Poll löst das nächste Senden aus.

Das erste "Send" findet um 20:32:58.810 statt und startet den 200ms-Timer. Damit sind die nächsten Gelegenheiten zum Senden um 20:32:59.010 und dann wieder um 20:32:59.210. Erst dieser Zeitpunkt wird genutzt, um den zweiten Befehl abzusenden (20:32:59.213), obwohl der erste Befehl bereits um 20:32:59.031 durch "Parse" beendet war (182 ms Pause).

Ich habe bei meinen Tests das $IOpoll von 200 ms auf 20 ms abgesenkt und wie erwartet ist dann die entstehende Pause ebenfalls entsprechend maximal 20 ms lang. Und das ist auch merklich in der Praxis.

So wie ich dich verstehe, sagst du, dass das so nicht sein dürfte und das der zweite Befehl direkt im Anschluss an den ersten gesendet werden sollte. Das scheint dann bei mir nicht so zu sein komischerweise.

[martinp876]

hast du recht - kann vorkommen.

probiere 10_CUL_HM.pm Version 7092

[vbs]

Danke, klasse! Funktioniert! Keine Pausen mehr!

Code Auswählen Erweitern


2014.11.30 10:45:51.038 5: HMLAN_Send:  HMLAN0 S:+2072A5,00,01,00
2014.11.30 10:45:51.039 5: HMLAN_Send:  HMLAN0 S:S00178E08 stat:  00 t:00000000 d:01 r:00178E08 m:0F A011 F15544 2072A5 0201C80000
2014.11.30 10:45:51.202 5: HMLAN_Parse: HMLAN0 R:R00178E08 stat:0001 t:01A6BCBE d:FF r:FFBD     m:0F 8002 2072A5 F15544 0101C8003F
2014.11.30 10:45:51.203 5: HMLAN0 dispatch A0E0F80022072A5F155440101C8003F::-67:HMLAN0

<nur 1 ms Pause bis zum nächsten Send! Das "Raster" würde normalerweise erst um 10:45:51.238 greifen!>

2014.11.30 10:45:51.204 5: HMLAN_Send:  HMLAN0 S:+22BA55,00,01,00
2014.11.30 10:45:51.204 5: HMLAN_Send:  HMLAN0 S:S00178EAE stat:  00 t:00000000 d:01 r:00178EAE m:10 A011 F15544 22BA55 0201C80000
2014.11.30 10:45:51.366 5: HMLAN_Parse: HMLAN0 R:R00178EAE stat:0001 t:01A6BD62 d:FF r:FFBE     m:10 8002 22BA55 F15544 0101C80043
2014.11.30 10:45:51.366 5: HMLAN0 dispatch A0E10800222BA55F155440101C80043::-66:HMLAN0

<hier das Gleiche!>

2014.11.30 10:45:51.368 5: HMLAN_Send:  HMLAN0 S:+2071DA,00,01,00
2014.11.30 10:45:51.368 5: HMLAN_Send:  HMLAN0 S:S00178F52 stat:  00 t:00000000 d:01 r:00178F52 m:11 A011 F15544 2071DA 0201C80000
2014.11.30 10:45:51.532 5: HMLAN_Parse: HMLAN0 R:R00178F52 stat:0001 t:01A6BE08 d:FF r:FFC1     m:11 8002 2071DA F15544 0101C80039
2014.11.30 10:45:51.533 5: HMLAN0 dispatch A0E1180022071DAF155440101C80039::-63:HMLAN0


[onkel-tobi]

Hi VBS,

wie zufrieden bist Du denn nun mit dem HM USB?
ICh habe bisher einen HMLAN, aber aufgrund von 3 Etagen und teilw. Reichweite PRoblemen, würde ich gerne einen zweiten HMLAN oder ein USB kaufen, bin mir da aber noch unschlüssig. Der HMLAN ist ja wieder was teurer, aber wenn der HM USB keine Verbesserung bringt ist das auch wieder rausgeschmissenes Geld.
Der USB würde bei mir direkt am RPi im EG angeschlossen und dann die EG devices steuern. Der HMLAN würde dann für die devices oben zuständig sein.
Wie sind so deine Erfahrungen?

Gruß,
Tobi

[vbs]

Also ich bin jetzt mit dem HMUSB recht zufrieden. Habe jetzt jedoch viele Geräte direkt gepeert, um die meisten Probleme zu umgehen. Unterm Strich halte ich den HMLAN latenzmässig weiterhin für leicht überlegen.