Sender direkt mit Zentrale verknüpfen

Deutsche Foren Konfiguration
#1

Guten Morgen,

ich fange gerade mit dem Thema Hausautomatisierung an und teste gerade die verschiedenen Softwarelösungen durch. Zur Zeit bin ich bei der Kombination hmland + homegear + openhab, welche mir soweit am besten gefällt. Jedoch bin ich auf ein kleines Problem gestoßen für das “googlen” mir noch keine Lösung gebracht hat.

Ist es möglich einen Sender direkt an die Homegear zu binden, so dass dieser einen ACK erhält?

Hintergrund ist folgender: Ich möchte mit meinen Homematic Wandsendern hue birnen schalten welche in openhab eingebunden sind. Das funktioniert soweit auch nur da der Kanal des Wandsenders mit keinem gerät direkt verbunden ist hat (scheinbar) zwei nachteile:

  1. Die Status LED am Wandsender meldet sich nicht wie gewohnt zurück (blinkt nur orange, nicht grün)

  2. Die Latenz bis das Event in openhab ankommt ist vom nicht verbundenem Kanal ist wesentlich länger als die des Kanals der zusätzlich direkt mit einem anderen Aktor verbunden ist (gleicher Wandsender). Schätzungsweise 0.5 Sekunden, also gerade bei Lampen deutlich merklich. Wenn man sich die logfiles Anschaut scheint es dabei irgendwo zwischen hmland und homegear zu hängen.

Bei fhem wird zumindest für Problem 1 empfohlen einen virtuellen Aktor anzulegen und diesen zu verbinden. Ich hab gesehen, dass es virtuelle Devices auch bei homegear gibt komm aber mit der Konfiguration nicht weiter (konnte eins anlegen aber mit nichts direkt verbinden). Ist das der richtige Weg?

#2

Wäre für irgendeinen Tipp wirklich dankbar. Ist der einzige Punkt, der mich an dem aktuellen Setup noch wirklich stört.

Oder ist was ich vorhabe nicht möglich?

#3

Hallo Koshu,

was du möchtest ist gar kein Problem und sollte automatisch der Fall sein. Irgendetwas scheint bei dir beim Anlernen schiefgelaufen zu sein. Mach noch einmal einen Werksreset des Senders und lerne ihn erneut an Homegear an. Achte nach dem Anlernen darauf, dass “Config Pending” verschwindet. Falls nach 20 Sekunden immer noch “Config Pending” sichtbar ist, drücke alle 20 Sekunden die Anlerntasten solange, bis die Konfiguration komplett übertragen wurde. Jetzt sollte beim Drücken der Sender-Taste die grüne LED aufleuchten. Um welchen Sender handelt es sich? Vielleicht habe ich diesen auch noch nicht in die Liste der Sender, die ein ACK bekommen sollen aufgenommen - das wäre aber in einer Minute gelöst :wink:.

Die Latenz von 0,5 Sekunden ist zu groß. Ich würde das aber am ehesten auf OpenHAB schieben. Versuch einmal, die Hue-Lampe über ein Homegear-Ereignis zu schalten (RPC-Funktion addEvent). Damit sollte es deutlich schneller gehen. Falls dir nicht klar ist, wie das gehen soll, poste ich dir hier gerne eine kurze Anleitung.

Viele Grüße

Sathya

#4

Hallo Sathya,

erstmal vielen Dank für deine Rückmeldung und generell für Homegear :slight_smile:. Bei dem Sender handelt es sich um einen HM-PB-2-WM55 2-Fach-Wandtaster. Ich habe diesen Effekt bei zwei Sendern der Reihe, welche ich (beim Rumprobieren) schon mehrer male komplett resetet und neu angelernt habe. Config Pending war meines wenn ich mich recht erinnere nicht mehr angezeigt und auch ansonsten kann ich alle Funktionen nutzen (bsp. direktes anlernen über Homegear). Werde das aber heute Abend noch überprüfen, da ich heute sowieso zwei weitere Sender der Reihe, sowie den HM-PB-6-WM55 6-Fach Wandsender erhalte. Genügend Testmaterial sollte damit dann zur Verfügung stehen :smiley: . Als Empfänger auf der Serverseite verwende ich den HM-CFG-USB-2. Das ganze (hmland+homegear+openhab+bischen anderes Zeug) läuft direkt auf einem Atom Board mit Ubuntu Server.

Mit dem direkten Schalten über ein Homegear Ereignis werde ich dann ebenfalls testen. Auf den ersten Blick sieht es aber eher nach der stelle hmland <-> homgear aus. Zumindest wenn man die drei logs der drei Programme Gleichzeitig betrachtet erscheinen die Homegear logs und openhab logs nahezu verzögerungsfrei, während die Nachricht im hmland log beiden um etwa diese 0,5s vorauseilt. Zugegeben nicht die genaueste Messmethode. Wäre natürlich auch möglich, dass das Problem bei hmland liegt aber soweit ich es verstanden habe, hat die “lan-bridge” keine wirkliche Intelligenz bzw. sollte keinen Unterschied zwischen direkt-verknüpften oder nicht direkt-verknüpften Signalen machen. Oder Irre ich mich da?

Nachtrag:
Falls das in meinem vorherigen Post nicht ganz deutlich war: Die Verzögerung bis hin zu openhab tritt nicht auf, wenn der Sender zusätzlich direkt mit einem anderen Aktor Verknüpft ist. In meinem Fall ein HM-ES-PMSw1-Pl Funk-Schaltaktor.

Zur Zeit befinde ich mich noch auf der stabilen Version 0.5. Könnten manche der Probleme auch daher rühren, bzw. wäre es generell sinnvoll lieber die 0.6 Reihe zu verwenden? Und wenn ja, kann ich problemlos updaten oder gehen mir die bisherigen Einstellungen dann verloren?

Vielen Dank,

koshu

#5

Update:

So die neue Hardware ist verlötet und mit Batterien versehen. Die beiden jungfräulichen 2-Fach Sender und der 6-Fach Sender sind an homgear gepairt. Auffällig beim pairen war, dass die 2-Fach Sender nicht mit grüner led bestätigt haben. Ein Config-Pending wird aber nicht angezeigt. Der 6-Fach Sender hat mit grün bestätigt und bei diesem Funktioniert auch die Rückmeldung bei einem Tastendruck. Das Latenz-problem besteht allerdings bei allen drei Schaltern. Das schalten einer Schaltsteckdose (welche etwas besser zu timen ist als die dimmenden hues) über openhab ist dabei nahezu synchron zur grünen Rückmeldung des 6-Fach Schalters. Erfolg die Rückmeldung direkt bei erfolgreicher Übertragung oder ist das orange->grün timing immer gleich?

Für den Test mit der RPC Funktion bräuchte ich allerdings doch eine kleine Starthilfe.

Update 2:
Die peers list des 6-Fach Schalters enthält für jeden Channel einen pairing zur Zentral. Die peer list der 2-Fach Schalter ist leer. Kann man die per Hand anlegen?

#6

Hallo koshu,

der HM-PB-2-WM55 war tatsächlich nicht in der Liste der Fernbedienungen, welche ein Feedback bekommen sollte. Das habe ich mal schnell gefixt. Im nächsten Nightly ist es enthalten :wink:.

Die Verzögerung ist wirklich komisch - allerdings habe ich den hmland auch noch nicht wirklich selbst genutzt (außer kurz zum Testen). Poste mal das Homegear-Log, vielleicht kann ich damit etwas mehr dazu sagen. Hier die kurze Starthilfe, um ein Ereignis anzulegen, welches einen Schalter schaltet:

<?php
$hg = new \Homegear\Homegear();

$hg->removeEvent("Schaltertest");
$hg->addEvent(array(
  "TYPE" => 0,
  "ID" => "Schaltertest",
  "PEERID" => 33, //Hier muss die ID des Tasters rein
  "PEERCHANNEL" => 1, //Hier muss der Kanal der Taste rein (1 ist Taste 1, 2 Taste 2, usw.)
  "VARIABLE" => "PRESS_SHORT", //PRESS_SHORT oder PRESS_LONG
  "TRIGGER" => 8,
  "TRIGGERVALUE" => true,
  "EVENTMETHOD" => "setValue",
  "EVENTMETHODPARAMS" => Array(34, 1, "STATE", true) //34 ist die Peer-ID des Schalters, der zweite Parameter (hier die "1") der Kanal, welcher geschaltet werden soll.
));
?>
#7

Hallo sathya,

hier das gewünscht Log. Ich habe das Debug-Level auf 10 gestellt, wodurch die Verzögerung sich leicht vergrößert hat. Das Log umfast alles, was direkt nach dem Drücken des Tasters geloggt wird, ink. der Response von openhab.

10/13/15 19:59:39.043 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN. Raw data:
453342364237422C303130302C38413532423142362C46462C464642432C323841323430334236423742464432304446303138370D0A
10/13/15 19:59:39.043 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN: E3B6B7B,0100,8A52B1B6,FF,FFBC,28A2403B6B7BFD20DF0187
10/13/15 19:59:39.043 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Waiting for AES handshake.
10/13/15 19:59:39.395 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN. Raw data:
453342364237422C303034302C38413532423142362C30312C464642432C323841323430334236423742464432304446303138370D0A
10/13/15 19:59:39.395 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN: E3B6B7B,0040,8A52B1B6,01,FFBC,28A2403B6B7BFD20DF0187
10/13/15 19:59:39.395 HomeMatic BidCoS packet received (hmland, RSSI: 0x44): 0B28A2403B6B7BFD20DF0187
10/13/15 19:59:39.396 Info: Calling RPC method "system.multicall" on server 192.168.0.2.
10/13/15 19:59:39.396 Parameters:
(Array length=1)
{
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0397491:0
        (String) RSSI_DEVICE
        (Integer) -68
      }
    }
  }
}
10/13/15 19:59:39.397 Module HomeMatic BidCoS: Info: INSTALL_TEST on channel 1 of HomeMatic BidCoS peer 9 with serial number MEQ0397491 was set to 0x87.
10/13/15 19:59:39.397 Debug: Calling getFileDescriptor...
10/13/15 19:59:39.397 Info: Connecting to host 192.168.0.2 on port 9123...
10/13/15 19:59:39.397 Module HomeMatic BidCoS: Info: PRESS_SHORT on channel 1 of HomeMatic BidCoS peer 9 with serial number MEQ0397491 was set to 0x87.
10/13/15 19:59:39.398 Info: Connected to host 192.168.0.2 on port 9123. Client number is: 171747
10/13/15 19:59:39.398 Sending packet: 42696E00000000940000001073797374656D2E6D756C746963616C6C00000001000001000000000100000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303339373439313A30000000030000000B525353495F44455649434500000001FFFFFFBC
10/13/15 19:59:39.400 RPC client receiving binary rpc packet with size: 29. Payload size is: 21
10/13/15 19:59:39.400 Debug: Received packet from server 192.168.0.2: 42696E0100000015000001000000000100000003000000056576656E7400
10/13/15 19:59:39.400 Response was:
(Array length=1)
{
  (String) event
}
10/13/15 19:59:39.455 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Ignoring ACK packet.
10/13/15 19:59:39.455 Info (hmland): Packet processing took 60 ms.
10/13/15 19:59:39.455 Info: Calling RPC method "system.multicall" on server 192.168.0.2.
10/13/15 19:59:39.456 Parameters:
(Array length=2)
{
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0397491:1
        (String) INSTALL_TEST
        (Boolean) 1
      }
    }
  }
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0397491:1
        (String) PRESS_SHORT
        (Boolean) 1
      }
    }
  }
}
10/13/15 19:59:39.457 Debug: Calling getFileDescriptor...
10/13/15 19:59:39.457 Info: Connecting to host 192.168.0.2 on port 9123...
10/13/15 19:59:39.458 Info: Connected to host 192.168.0.2 on port 9123. Client number is: 171748
10/13/15 19:59:39.458 Sending packet: 42696E00000001030000001073797374656D2E6D756C746963616C6C00000001000001000000000200000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303339373439313A31000000030000000C494E5354414C4C5F54455354000000020100000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303339373439313A31000000030000000B50524553535F53484F52540000000201
10/13/15 19:59:39.461 RPC client receiving binary rpc packet with size: 29. Payload size is: 21
10/13/15 19:59:39.461 Debug: Received packet from server 192.168.0.2: 42696E0100000015000001000000000100000003000000056576656E7400
10/13/15 19:59:39.464 Response was:
(Array length=1)
{
  (String) event
}
10/13/15 19:59:39.490 RPC Server (Port 2001): Info: Connection from 127.0.0.1:41649 accepted. Client number: 171749
10/13/15 19:59:39.492 RPC Server (Port 2001): Listening for incoming packets from client number 171749.
10/13/15 19:59:39.492 RPC Server (Port 2001): Debug: Packet received: 42696E00000000360000000873657456616C756500000003000000030000000C4D4551303237323931373A31000000030000000553544154450000000200
10/13/15 19:59:39.492 RPC Server (Port 2001): Receiving binary rpc packet with size: 54
10/13/15 19:59:39.492 RPC Server (Port 2001): Info: Client number 171749 is calling RPC method: setValue Parameters:
(String) MEQ0272917:1
(String) STATE
(Boolean) 0
10/13/15 19:59:39.493 Module HomeMatic BidCoS: Debug: STATE of peer 1 with serial number MEQ0272917:1 was set to 00.
10/13/15 19:59:39.493 Module HomeMatic BidCoS: Creating SAVEPOINT BidCoSQueue3605595_171
10/13/15 19:59:39.494 Debug: Thread priority successfully set to: 45
10/13/15 19:59:39.494 Module HomeMatic BidCoS: Debug: Sending packet 0E7BA011FD20DF37045B0201000000 immediately, because it seems it is no response (no packet information found).
10/13/15 19:59:39.494 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Info: Sending (hmland): 0E7BA011FD20DF37045B0201000000
10/13/15 19:59:39.494 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Sending: S625B90E6,00,00000000,01,8A52B385,7BA011FD20DF37045B0201000000
10/13/15 19:59:39.494 Info: Calling RPC method "system.multicall" on server 192.168.0.2.
10/13/15 19:59:39.494 Parameters:
(Array length=1)
{
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0272917:1
        (String) STATE
        (Boolean) 0
      }
    }
  }
}
10/13/15 19:59:39.495 Debug: Calling getFileDescriptor...
10/13/15 19:59:39.495 Info: Connecting to host 192.168.0.2 on port 9123...
10/13/15 19:59:39.495 Info: Connected to host 192.168.0.2 on port 9123. Client number is: 171750
10/13/15 19:59:39.495 Sending packet: 42696E000000008B0000001073797374656D2E6D756C746963616C6C00000001000001000000000100000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303237323931373A31000000030000000553544154450000000200
10/13/15 19:59:39.496 RPC Server (Port 2001): Response: 
(void)
10/13/15 19:59:39.496 RPC Server (Port 2001): Response binary:
42696E01000000080000000300000000
10/13/15 19:59:39.499 RPC client receiving binary rpc packet with size: 29. Payload size is: 21
10/13/15 19:59:39.499 Debug: Received packet from server 192.168.0.2: 42696E0100000015000001000000000100000003000000056576656E7400
10/13/15 19:59:39.499 Response was:
(Array length=1)
{
  (String) event
}
10/13/15 19:59:39.500 RPC Server (Port 2001): Info: Connection to client number 171749 closed (3).
10/13/15 19:59:39.715 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN. Raw data:
5236323542393045362C303030312C38413532423435452C46462C464643332C374238303032333730343542464432304446303130313030303033430D0A
10/13/15 19:59:39.715 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN: R625B90E6,0001,8A52B45E,FF,FFC3,7B800237045BFD20DF010100003C
10/13/15 19:59:39.716 HomeMatic BidCoS packet received (hmland, RSSI: 0x3D): 0E7B800237045BFD20DF010100003C
10/13/15 19:59:39.717 Module HomeMatic BidCoS: Popping from BidCoSQueue: 171
10/13/15 19:59:39.717 Module HomeMatic BidCoS: Message now at front: Message type: 0x2 Control byte: 0x0
10/13/15 19:59:39.717 Module HomeMatic BidCoS: Debug: Device 1: Access granted for packet 0E7B800237045BFD20DF010100003C
10/13/15 19:59:39.717 Module HomeMatic BidCoS: Popping from BidCoSQueue: 171
10/13/15 19:59:39.717 Module HomeMatic BidCoS: Info: Queue 171 is empty and there are no pending queues.
10/13/15 19:59:39.718 Info: Calling RPC method "system.multicall" on server 192.168.0.2.
10/13/15 19:59:39.718 Parameters:
(Array length=1)
{
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0272917:0
        (String) RSSI_DEVICE
        10/13/15 19:59:39.718(Integer)  Module HomeMatic BidCoS: Info: STATE on channel 1 of HomeMatic BidCoS peer 1 with serial number MEQ0272917 was set to 0x00.
-61
      }
    }
  }
}
10/13/15 19:59:39.718 Module HomeMatic BidCoS: Info: WORKING on channel 1 of HomeMatic BidCoS peer 1 with serial number MEQ0272917 was set to 0x00.
10/13/15 19:59:39.719 Debug: Calling getFileDescriptor...
10/13/15 19:59:39.719 Info: Connecting to host 192.168.0.2 on port 9123...
10/13/15 19:59:39.719 Info (hmland): Packet processing took 3 ms.
10/13/15 19:59:39.720 Info: Connected to host 192.168.0.2 on port 9123. Client number is: 171751
10/13/15 19:59:39.721 Sending packet: 42696E00000000940000001073797374656D2E6D756C746963616C6C00000001000001000000000100000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303237323931373A30000000030000000B525353495F44455649434500000001FFFFFFC3
10/13/15 19:59:39.722 RPC client receiving binary rpc packet with size: 29. Payload size is: 21
10/13/15 19:59:39.724 Debug: Received packet from server 192.168.0.2: 42696E0100000015000001000000000100000003000000056576656E7400
10/13/15 19:59:39.724 Response was:
(Array length=1)
{
  (String) event
}
10/13/15 19:59:39.724 Info: Calling RPC method "system.multicall" on server 192.168.0.2.
10/13/15 19:59:39.724 Parameters:
(Array length=2)
{
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0272917:1
        (String) STATE
        (Boolean) 0
      }
    }
  }
  (Struct length=2)
  {
    [methodName]
    {
      (String) event
    }
    [params]
    {
      (Array length=4)
      {
        (String) Homegear
        (String) MEQ0272917:1
        (String) WORKING
        (Boolean) 0
      }
    }
  }
}
10/13/15 19:59:39.725 Debug: Calling getFileDescriptor...
10/13/15 19:59:39.725 Info: Connecting to host 192.168.0.2 on port 9123...
10/13/15 19:59:39.726 Info: Connected to host 192.168.0.2 on port 9123. Client number is: 171752
10/13/15 19:59:39.726 Sending packet: 42696E00000000F80000001073797374656D2E6D756C746963616C6C00000001000001000000000200000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303237323931373A3100000003000000055354415445000000020000000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008486F6D6567656172000000030000000C4D4551303237323931373A310000000300000007574F524B494E470000000200
10/13/15 19:59:39.728 RPC client receiving binary rpc packet with size: 29. Payload size is: 21
10/13/15 19:59:39.729 Debug: Received packet from server 192.168.0.2: 42696E0100000015000001000000000100000003000000056576656E7400
10/13/15 19:59:39.729 Response was:
(Array length=1)
{
  (String) event
}
10/13/15 19:59:39.795 Module HomeMatic BidCoS: Debug: Deleting queue 171 for BidCoS peer with address 0x37045B
10/13/15 19:59:39.796 Module HomeMatic BidCoS: Releasing SAVEPOINT BidCoSQueue3605595_171

Das php-script hab ich ausprobiert und mit einem zusätzlichen try catch lief es dann auch :slight_smile: . Openhab hab ich zum testen komplett abgeschaltet. Die Latenz ist aber auf einem ähnlichen Niveau wie mit openhab.

Gruß und vielen Dank,
koshu

#8

Hallo koshu,

wie du richtig vermutet hast, liegt das Problem irgendwo an der Verbindung zum hmland, am hmland oder an der Kommunikation zum HM-CFG-USB. Hast du noch weitere USB-Geräte angeschlossen? Das kann die USB-Latenz deutlich erhöhen. Nutzt du einen Raspberry Pi? Da kann auch eine hohe Netzwerkauslastung die Latenz zum HM-CFG-USB erhöhen, da die Netzwerkkarte über USB angeschlossen ist. Die Verbindung zu OpenHAB oder eine SSH-Verbindung reichen dafür aber nicht aus. Ich kann mal meinen HM-CFG-USB anschließen und die Latenz noch einmal bei mir messen… Das wird aber erst Anfang nächster Woche etwas.

Paket empfangen: 395
Event-Paket an OpenHAB: 456, Empfangsbestätigung: 464
setValue von OpenHAB: 492
TCP-Paket an hmland senden: 494, Empfangsbestätigung: 716

Viele Grüße

Sathya

#9

USB-Geräte hab ich ansonsten keine angeschlossen aber es läuft noch der ein oder andere Dienst auf meinem Server (NFS, Owncloud, Softraid etc). Das ganz aber nicht auf einem RaspberryPi sondern auf einem Intel Atom board und ein Großteil der Dienste Idlet 95% der Zeit vor sich hin, sollte also eigentlich genügend Resourcen haben (der Teufel liegt natürlich manchmal im Detail). Netzwerkkarte ist an PCI angeschlossen. Was mich halt verwundert, ist das die Latenz eben nicht auftritt, wenn die Geräte noch direkt Verlinkt sind und homegear nur “mitlauscht”. Ich nehme an Homegear gibt in diesem Fall keine Rückmeldung selbst an den Taster? Gibt Homegear erst Meldung an Openhab, wenn die Rückmeldung zum Taster erfolgreich war? Ich hoffe, dass ich heute Abend noch mal etwas Zeit hab, dann teste ich das mit der direkten Verlinken nochmal und zeichne ein paar logs auf, vielleicht hilft es das Problem einzugrenzen.

Und noch was eigenartiges, ich hab gestern nach längerer Lieferschwierigkeit von ELV meinen Bewegungsmelder (HM-Sen-MDIR-WM55) bekommen, welcher ebenfalls auch zwei Taster enthält. Bei diesem Tritt die Latenz nicht auf oder ist zumindest bei weitem nicht so deutlich. (Oh, und es gibt bei diesem auch keine grüne Rückmeldung, wobei ich mir nicht sicher bin ob der Bewegungsmelder es genauso meldet). Ich werde mir das heute Abend nochmal genauer anschauen.

Gruß,
koshu

Edit: hier noch ein schnelles Log vom Bewegungsmelder (Zur zeit noch ohne Aktion von openhab).

10/16/15 09:52:39.257 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN. Raw data:
453336313932442C303030302C39373941303543442C46462C464643442C383941323430333631393244464432304446303231450D0A
10/16/15 09:52:39.257 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN: E36192D,0000,979A05CD,FF,FFCD,89A24036192DFD20DF021E
10/16/15 09:52:39.257 HomeMatic BidCoS packet received (hmland, RSSI: 0x33): 0B89A24036192DFD20DF021E
10/16/15 09:52:39.259 Module HomeMatic BidCoS: Info: INSTALL_TEST on channel 2 of HomeMatic BidCoS peer 18 with serial number MEQ0669433 was set to 0x1E.
10/16/15 09:52:39.259 Module HomeMatic BidCoS: Info: PRESS_SHORT on channel 2 of HomeMatic BidCoS peer 18 with serial number MEQ0669433 was set to 0x1E.
10/16/15 09:52:39.317 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Ignoring ACK packet.
10/16/15 09:52:39.317 Info (hmland): Packet processing took 60 ms.
10/16/15 09:52:41.721 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN. Raw data:
453341453341342C303030302C39373941304636452C46462C464643412C4538383635413341453341343030303030303838443133380D0A
10/16/15 09:52:41.721 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmland": Debug: Packet received from HM-CFG-LAN: E3AE3A4,0000,979A0F6E,FF,FFCA,E8865A3AE3A400000088D138
10/16/15 09:52:41.721 HomeMatic BidCoS packet received (hmland, RSSI: 0x36): 0CE8865A3AE3A400000088D138
10/16/15 09:52:41.723 Module HomeMatic BidCoS: Info: ACTUAL_HUMIDITY on channel 2 of HomeMatic BidCoS peer 3 with serial number MEQ0476209 was set to 0x38.
10/16/15 09:52:41.723 Module HomeMatic BidCoS: Info: ACTUAL_TEMPERATURE on channel 2 of HomeMatic BidCoS peer 3 with serial number MEQ0476209 was set to 0x00D1.
10/16/15 09:52:41.723 Module HomeMatic BidCoS: Info: SET_TEMPERATURE on channel 2 of HomeMatic BidCoS peer 3 with serial number MEQ0476209 was set to 0x22.
10/16/15 09:52:41.724 Info (hmland): Packet processing took 3 ms.

Edit2:

Ok, die Verbindung zum Bewegungsmelder ist standardmäßig nicht AES gesichert. Wenn ich AES für die Bewegungsmelder anschalte ist die Latenz ebenfalls vorhanden. Umgekehrt, wenn ich AES bei den restlichen Tastern abschalte ist auch die Latenz weg.

#10

Hallo Koshu,

Hehe. Ja, das ist der Nachteil von AES. Es muss erst der ganze Handshake abgewartet werden, bevor das Paket verarbeitet werden kann. Da habe ich im Log auch nicht aufgepasst - ich hätte sehen können, dass AES eingeschaltet war :unamused:. Der Handshake besteht noch einmal aus drei Paketen, so dass insgesamt vier Pakete übertragen werden. Zwischen jedem Paket liegen etwa 100 ms. Das erklärt natürlich die Latenz und ist der Grund, warum ich für das Lichtschalten bei mir zu Hause AES auch ausgeschaltet habe (auch wenn ich es selbst ebenfalls lieber aktiviert hätte…).

Viele Grüße

Sathya

Nachtrag: Der HM-SEN-MDIR-WM55 hat jetzt auch ein LED-Feedback :wink:. Nur muss er mit der neuen Homegear-Version leider neu angelernt werden.

#11

Ah, vier wegen Challenge-Response. War kurzfristig irritiert, dass es so viele sind aber ist natürlich sinnvoll. Ich nehme an, dass ist von Homematic Seite schon so festgelegt oder kann man daran irgendwas ändern (was den Ablauf und die Wartezeiten zwischen den Paketen angeht)? Bzw. sind derartige Latenzen für Homematic normal? (Hatte nie eine original Zentrale und daher keine Erfahrungen)

Werde morgen dann mal updaten und die ganzen Rückmeldungen testen.

Danke für deine Hilfe,
koshu

#12

Genau, das ist festgelegt und daran lässt sich leider nichts ändern.

Ja, sind normal. Du kannst natürlich das erste Paket vom Gerät direkt verarbeiten (da sind die Daten drin), aber dann macht der Handshake keinen Sinn.

Viele Grüße

Sathya