Wie lange dauert es bei Euch um ein Signal in der IPSymcon zu erhalten

paresy · 28. September 2010 um 17:17

Soweit ich weiß, schicken die Aktoren erst, wenn sie mit der Aktion fertig sind. Und das mit einer gewissen Verzögerung, die du auch im WebPanel der CCU siehst.

paresy

khc · 28. September 2010 um 18:41

Hallo Community,

ich habe genau das Problem wie es @Bernardo71 zusammengeafasst hat.

Es geht hier um keine Laufzeit der Rollläden sondern rein um die Dauer wie lange eine Signal vom Sensor bis in die IPSymcon braucht.

@paresy: Ich habe am Taster keine zusätzliche Funktion - sprich das ist nur ein Taster welcher keine Verbindung zu einem Aktor hat. Ich will in der IPSymcon nur mitbekommen, wann der taster gedrückt wurde, dann per Script darauf reagieren und möglichwerweise damit einen Aktor schalten. Z.B.: Taster -> Script -> Licht ein
Jetzt dauert es vom Drücken des Tasters bis zum Schalten des Lichtes 2-3 Sekunden. Der Großteil dieser Zeit ist, bis ich in der IPSymcon den Status des Tasters signalisiert bekomme (2-3sek). Das Absetzen des Schaltbefehls geht SOFORT an den Aktor.

Grooooog · 28. September 2010 um 20:02

Hallo,

also, ich habs bei mir mal mitgeloggt:


28.09.2010	19:52:08,872122	[FB E3][][1]
28.09.2010	19:52:08,892159	Script Call
28.09.2010	19:52:09,119140	Script End
28.09.2010	19:52:09,312748	[Unterputzschalter][][1]
...
28.09.2010	19:52:11,375711	[FB E3][][]
28.09.2010	19:52:11,385888	Script Call
28.09.2010	19:52:11,630474	Script End
28.09.2010	19:52:11,826369	[Unterputzschalter][][]
...
28.09.2010	19:52:15,651954	[FB E3][][1]
28.09.2010	19:52:15,661884	Script Call
28.09.2010	19:52:15,890133	Script End
28.09.2010	19:52:16,183342	[Unterputzschalter][][1]
...
28.09.2010	19:52:17,764868	[FB E3][][]
28.09.2010	19:52:17,764912	Script Call
28.09.2010	19:52:18,826000	Script End
28.09.2010	19:52:18,215556	[Unterputzschalter][][]

Folgendes wird geloggt:

[ul]
[li]Per „Variable Changed“ der FS20 Fernbedinung (FB E3) wird ein Script aufgerufen
[/li][li]Das Script loggt „Script Call“, führt „HM_WriteValueBoolean(29920, „STATE“, $IPS_VALUE);“ aus und loggt „Script End“
[/li][li]Ein „Variable Changed“ auf die „State“ Variable des HomeMatic HM-LC-Sw1-FM
[/li][/ul]

Der Weg ist folgender:

[ul]
[li]FHZ1300
[/li][li]Silex
[/li][li]Devolo dLAN
[/li][li]IP-Symcon VirtualBox VM
[/li][li]IP-Symcon
[/li][li]Devolo dLAN
[/li][li]HM Lan-Adapter
[/li][li]Unterputzschalter
[/li][/ul]

Grüße,
Dirk.

Nachtrag:
Ich habe das ganze jetzt mal umgekehrt ausprobiert, also HM → FS20 und kann die Verzögerungen bestätigen. Allerdings nicht im Log:


28.09.2010	20:13:37,625271,00	[Unterputzschalter][][1]
28.09.2010	20:13:37,605319,00	Script Call
28.09.2010	20:13:37,618792,00	Script End
28.09.2010	20:13:37,835550,00	[Steckdose][][1]
...
28.09.2010	20:13:45,897765,00	[Unterputzschalter][][]
28.09.2010	20:13:45,877715,00	Script Call
28.09.2010	20:13:45,889431,00	Script End
28.09.2010	20:13:46,87418,00	[Steckdose][][]

Wenn ich den HM UP-Schalter umschalte, dann dauert es 2-4 Sekunden, bis die FS20-Steckdose schaltet. Laut Script bekommt IPS den Schaltvorgang allerdings erst so spät mit.

Bernardo71 · 28. September 2010 um 20:39

@Groooog

Das ist ja zumindest mal ein Anfang das Thema zu analysieren.

Hat HM irgendwelche Default Verzoegerungen die man verstellen koennte ?

Irgendetwas was man im HM Konfig Interface beschleunigen koennte ?

Die Strecke HM Sender in Richtung IPS und Datenaktualisierung sollten wir zumindest mal im Auge behalten wo hier die Zeit auf der Strecke bleibt.

Ich werde die Messungen naechste Woche auch mal machen wenn meine ersten Aktoren kommen.

Gruss
B71

Grooooog · 28. September 2010 um 21:07

Hi,

Nicht daß ich wo gesehen hätte.

Ich bin bei der Suche nach deiner ersten Frage über die BidCos Logs gestolpert und kann IPS damit entlasten:

Selbst wenn BidCos um 20:13:37,00000 das Signal empfangen hätte, dann hätte IPS 0,625271 Sekunden später das Signal gehabt und die Steckdose wäre 0,835550 Sekunden später geschaltet. Scheint wirklich der Weg UP-Sensor -> LAN Adapter -> BidCos zu sein, der die Verzögerung bewirkt.

Grüße,
Dirk.

Nachtrag:
Ich hab den Versuchsaufbau nochmal aufgebaut und genau zur vollen Minute den UP-Schalter geschaltet. Hier die Logs vom BidCos:


28.09.2010 21:17:04 <Debug> RX for HExxxxxxx: @1506203240 RSSI=-82dB 0x13E701 -> 0x000000 INFO_ACTUATOR_STATUS [geqxxxxxxx]:
  CNT=8,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
  CHANNEL = 1
  STATUS = 0
  STATE = 0
  CLOCK = 0
  LOWBAT = 0
  DUTY_CYCLE = 0
  RSSI = 0

Also knappe 4 Sekunden später hat der BidCos die Änderung mitbekommen.

Bernardo71 · 28. September 2010 um 21:14

Hi,

Ich hatte, da FS20 normal funktioniert den Weg zum Bidcos Service ja auch im Verdacht, deshalb hatte ich mich ja auch immer zur HM Gesamtstrecke geaeusserrt und IPS, man lernt ja dazu, nicht als Urheber der Verzoegerung in unmittelbaren Verdacht gezogen.

Es muss dann aber das HM empfangen am LAN Adapter, verarbeiten und weiterleiten zum BIDCOS einen Versatz erzeugen und hier dann die Frage an die Leute die was davon verstehen, ob man diesen Dienst beschleunigen koennte oder delays eliminiert werden koennen indem bestimmte LAN Konfigurationen oder was auch immer gemacht werden.

Gruss
B71

Bernardo71 · 29. September 2010 um 08:39

Hallo zusammen,

könnten ein paar weitere HM Nutzer vielleicht mal die Sendestrecke HM Aktor - LAN Adapter - BIDCOS Service - IPS in Bezug auf zeitliche Verzögerungen von 2-3 Sekunden untersuchen um das Thema eventuell für die hier betroffenen weiter einzugrenzen ?

Feedback wäre toll.

Wenn Ihr dieses Phänomen nicht habt, was habt Ihr anders gemacht ?
HM Aktoren direkt angelernt und IPS nur „mitlesend“ ?

Gruss
B71

cyberganny · 29. September 2010 um 08:52

also bei den Fenstergriffkontakten habe ich 0,5 Sekunden Verzögerung bis der aktuelle Status im Webfrontend angezeigt wird. Das ist für mich vollkommen akzeptabel, da zwischen iPS und Webfront auch noch mal die Aktualisierung getriggert werden muss.

Den einzig viel zu grossen Delay habe ich beim Einstellen der Soll-Temperatur am Raumthermostat aber das ist eine andere Baustelle.

Grooooog · 29. September 2010 um 09:24

Hallo,

ich habe mir nochmal die BidCos Ausgabe angeschaut:


28.09.2010 21:17:04 <Debug> RX for HExxxxxxx: @1506203240 RSSI=-82dB 0x13E701 -> 0x000000 INFO_ACTUATOR_STATUS [geqxxxxxxx]:
  CNT=8,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
  CHANNEL = 1
  STATUS = 0
  STATE = 0
  CLOCK = 0
  LOWBAT = 0
  DUTY_CYCLE = 0
  RSSI = 0

Kann bitte mal jemand ein Log von einem Aktor posten (z.B. Fensterkontakt oder noch besser Fernbedienung), der sofort umschaltet? Ich könnte mir vorstellen, daß es Aktoren gibt, die Priority-Nachrichten schicken können (Stichwort BURST=0). Daß auch die Fernbedienung 4 Sekunden braucht, bis BidCos das Signal verteilt kann ich nicht glauben.

Grüße,
Dirk.

khc · 29. September 2010 um 12:16

 
28.09.2010 12:50:55 <Debug> RX for GEQxxxxxxx: @1475833328 AES(5) RSSI=-40dB 0x124B84 -> 0x1219F8 INFO_ACTUATOR_STATUS [GEQxxxxxx]:
CNT=24,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=1,BCAST=1,TYPE=0x10
CHANNEL = 1
STATUS = 38
STATE = 0
CLOCK = 0
LOWBAT = 0
DUTY_CYCLE = 0
RSSI = 0

Weitere Logs heute abend.

Bernardo71 · 29. September 2010 um 12:49

Meine Fensterkontakte sind auch schnell.
Ich habe 0,5 s Wartezeit eingestellt und genau diese würde ich als Zeitfenster für die Aktualisierung im Webfront benennen wollen.

Also hier ist aus meiner Sicht die Ampel grün.

Sprich: Taster, IR Melder und Aktoren als Strecke für die Untersuchung zu beachten.

Gruss
B71

kronos · 29. September 2010 um 15:26

Hallo.

Habt Ihr das Problem bei gesicherter oder ungesicherter Übertragung? Ungesichert geht laut Homematic-Konfig schneller und spart daher sogar Batteriestrom.

Und wie viele Verknüpfungen haben die Geräte?

Welche Homematic Devices sind betroffen? Netzgestützt oder Batterie? Aktor oder Sender? Ich habe auch den Eindruck es gibt „schnellere“ und „langsamere“ Geräte. Müsste aber auch noch testen ob man die Unterschiede an Gerät oder Standort d.h. Sende-/Empfangsqualität fest machen kann.

Und noch eine Frage - sind CCU-Besitzer davon auch betroffen oder wird die Statusänderung an einer CCU sofort wahrgenommen?

Grüsse.

Bernardo71 · 29. September 2010 um 20:28

Also bei mir sind die normal schnellen Fensterkontakte alle gesichert angemeldet…also diese Sender würde ich mal vorerst vom Radar bei derr Suche nehmen.

Die Thermostate sind ungesichert und die Motoren ebenfalls.

Gruss
B71

khc · 29. September 2010 um 20:35

@kronos:
Bei mir ist auch ALLES gesichtert angemeldet.

khc · 29. September 2010 um 20:39

Hier noch ein paar Logs:

Drehgriffkontakt:

29.09.2010 20:33:43 <Debug> Event: HEQxxx:1.STATE=2
29.09.2010 20:33:44 <Debug> RX for HEQ0105153: @1590003103 AES(5) RSSI=-61dB 0x12FC72 -> 0x1219F8 CONDITIONAL_SWITCH [GEQxxx]:
  CNT=32,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
  COUNTER = 17
  CHANNEL = 1
  LOWBAT = 0
  DURATION = 0
  CONDITION = 0
  TIMES = 0

Tür-/Fensterkontakt:

29.09.2010 20:36:27 <Debug> Event: FEQxxx:1.STATE=false
29.09.2010 20:36:27 <Debug> RX for FEQxxx: @1590165743 AES(5) RSSI=-49dB 0x111B3E -> 0x1219F8 CONDITIONAL_SWITCH [GEQxxx]:
  CNT=58,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
  COUNTER = 30
  CHANNEL = 1
  LOWBAT = 0
  DURATION = 0
  CONDITION = 200
  TIMES = 0

HM-LC-SW2-FM (2Fach Schaltaktor):

29.09.2010 20:37:34 <Debug> RX for HEQxxx: @1590233131 RSSI=-42dB 0x136073 -> 0x000000 INFO_ACTUATOR_STATUS [GEQxxx]:
  CNT=36,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
  CHANNEL = 1
  STATUS = 0
  STATE = 0
  CLOCK = 0
  LOWBAT = 0
  DUTY_CYCLE = 0
  RSSI = 0

cyberganny · 29. September 2010 um 21:38

bei mir sind auch alle Komponenten gesichert angemeldet, das werde ich auch nicht ändern.

kronos · 29. September 2010 um 21:42

Ein paar Versuche später…

Habe mich nicht mit Logs beschäftigt sondern mit Gerätetypen und Einstelloptionen im Homematic-Konfig:

Fensterkontakte immer schnell - es sei denn es waren mehrere Sendeversuche notwendig.
Tasterschnittstelle immer schnell - siehe oben…
Wandtaster (1-fach, 2-fach, OLED) - siehe oben. Wasser-/Neigungswinkelsensor ebenso.

Mehr Sendertypen habe ich nicht.

Aktoren (Dimm-Zwischenstecker, Schalt-Zwischenstecker, Zwischendeckendimmer, Unterputzschalter) - alle (!) bei näherungsweise 3 Sekunden bis Statusänderung in IPS und das zuverlässig.

Mehr Aktoren-Typen habe ich derzeit nicht zur Verfügung.

Keinerlei Einfluss ob gesichert oder ungesichert.
Wenig Einfluss der Signalstärke. Ob direkt neben LAN-Adapter oder ein Stockwerk (Keller/Stahlbeton) entfernt - kein nennenswerter Unterschied.
Auch kein Einfluss ob mit einem oder mehreren LAN-Adaptern gearbeitet wird.

Kann das jemand so bestätigen und gibt es Erfahrungswerte wie das mit einer CCU läuft?

System ist übrigens ein Athlon X2 2.5Ghz mit 4GB RAM und WHS. Sollte also keinen wesentlichen Einfluss auf die Rückmeldezeit haben.

Was ich noch nicht getestet habe und auch gerne vermeiden würde wäre die Konfiguration mit und ohne AES. Dazu müsste ich alles neu anlernen und das möchte ich dann doch lieber nicht (warum nur?).

Ehrlich gesagt hat mich dieser 3-Sekunden-Versatz in den letzten Monaten aber auch nicht beeinträchtigt da der Aktor in obigen Tests sehr zeitnah reagiert hat und nur die Rückmeldung an IPS die besagten 3 Sekunden dauert. Eine Aktion HM-Wandtaster => IPS-Script => HM-Aktor geht bei mir also schnell. Ich schätze auch, dass das so seine Richtigkeit hat. Wenn der Aktor einen Befehl bekommt reagiert zuerst die Variable WORKING, d.h. der Aktor ist mit der Ausführung beschäftigt. Erst wenn WORKING dann von TRUE auf FALSE geht erfolgt bei mir die Statusänderung. Und das wurde in diesem Thread ja schon vorher mal festgestellt.

Grüsse.

chrisu · 30. September 2010 um 10:27

Hi,

das ist auch bei der CCU so.
Die Statusänderung wird etwas zeitversetzt gesendet, damit nix kollidiert.
Bei den Wired-Aktoren gehts natürlich etwas schneller (max. 1 sec.).

renovierer · 12. März 2011 um 19:02

Bin auch über das Problem mit den 4 Sekunden Zeitverzögerung gestossen. Dachte zuerst, dass dies daran liegt, dass ich einen Aktor als Sender missbraucht habe. Und habe daher diesen neuen Thread aufgemacht:

Nun glaube ich aber, dass HM schnellere und langsamere Geräte hat.

Ich kann zu den oben beschriebenen Test folgende beiden Ergebnisse beisteuern:

Funk-Schaltaktor HM-LC-Sw2-FM als Sender missbraucht --> 4-5 Sekunden
Funk-Taster 4fach (Batterie) HM-PBI-4-FM --> < 0,5 Sekunden

In beiden Fällen war ein Jung-Taster an 1. bzw. 2 angeschlossen. Die gemessene Zeit war die Zeit, die zwischen Drücken des Tasters bis zur Ausführung des damit verbundenen Skriptes (in meinem Fall - Rolladen in Fahrt setzen) verging.
Also: Taster - HM-Tatsterkomponente - Lan-Adapter - IPS - Lan-Adapter - HM Aktor - Alle Rolladen ab

Mir unerklärlich, warum die HM Komponenten so unterschiedlich schnell/langsam sind.

chrisu · 12. März 2011 um 21:48

Hi,

das liegt daran das 2. wirklich ein SENDER ist und daher auch sendet wenn du den Taster drückst.
Der Schaltaktor sendet ja nicht weil du den Taster drückst, sondern sendet einfach nur die Statusänderung am Ausgang!
Und das passiert eben etwas Zeitversetzt, zwecks Kollisionsvermeidung.

Also alles genau so wie es gehört.

Nimmst du nen Sender dann hast du auch einen Sender