HMLAN disconnected sporadisch

[Matthias]

Hallo,
ich wühle in fhem users und finde für meinen Fehler keine Erklärung. Also frag ich mal los...
Meine Hardware: Fritzbox 7390 mit fhem 5.3, Homematic LAN Konfigurator, eine HM-LC-SW1-FM zum Testen, CUL ist bestellt.

Die Einrichtung war soweit keine Schwierigkeit und durch die vielen Anleitungen auch keine große Sache und jetzt kommt das ABER:
Ich bekomme disconnects alle 4 Stunden für 5 sec. und später dann ist die Verbindung von der 7390 zum HMLAN ganz weg.
Ein Netz aus/ein hilft dann nur kann ich so kein system aufbauen was unter den Augen der Weiblichkeit besteht.
Hier ein log:

2012.12.11 23:07:43 1: Including fhem.cfg

2012.12.11 23:07:44 3: telnetPort: port 7072 opened

2012.12.11 23:07:45 3: WEB: port 8083 opened

2012.12.11 23:07:45 3: WEBphone: port 8084 opened

2012.12.11 23:07:45 3: WEBtablet: port 8085 opened

2012.12.11 23:07:46 3: Opening Lankonf1 device 192.168.1.116:1000

2012.12.11 23:07:46 3: Lankonf1 device opened

2012.12.11 23:07:46 1: Including ./log/fhem.save

2012.12.11 23:07:47 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 14269)

2012.12.11 23:08:11 1: HMLAN setting owner to 245202 from C7AF02

2012.12.12 00:53:41 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 00:53:46 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 04:52:25 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 04:52:31 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 08:51:33 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 08:51:38 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 12:50:41 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 12:50:46 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 16:49:48 1: 192.168.1.116:1000 disconnected, waiting to reappear

Diese Regelmäßigkeit ist schon auffällig.

Gruß

Matthias

[Markus Bloch]

Hallo Matthias,

kannst mal einen Blick in https://groups.google.com/forum/#!topic/fhem-users/y_rlL8POnlY werfen. Dein Problem wurde dort durch UliM und dem HM-Martin analysiert. Die Quintessenz ist, das durch Sleep-Befehle in mehreren FHEM Modulen der Keep-Alive Timer für das HMLAN irgendwann statt nach 25 Sekunden erst nach 30 Sekunden geschickt werden und dadurch das HMLAN die Verbindung abbricht.

z.B. das Modul WOL führt einen Ping Befehl durch, wodurch das gesamte FHEM Programm bis zur Rückmeldung wartet (ping -c1 dauert ca. 1 Sekunde) und dadurch sämtliche at Befehle sich ebenfalls um 1 Sekunde verzögern. In dem Modul Twilight soll es wohl auch irgendwas verzögerndes geben (sleep?).

Aber ich denke da kann Martin mehr zu sagen, da er das zusammen mit Uli sehr intensiv untersucht hatte.

VIele Grüße

Markus  

[Matthias]

Hallo Markus,

ja das sieht leider nach genau dem Fehler aus.

Dank dir

Gruß

Matthias

[Martin]

Hallo Matthias,

das Problem liegt in WOL. Twilight ist unschuldig.
Generell kann es noch weitere Module geben, die solche Vezögerungen auslösen - auch eine kombination aus mehreren ist möglich. Aber identifiziert ist bisher nur die eine.

Lösen kannst du es indem du im Modul 98_WOL.pm die Zeile
  if (`ping -c 1 $ip` =~ m/100/)
ersetzt gegen
  if (`ping -c 1 -w 1 $ip` =~ m/100/)

Einbauen möchte ich dies nicht, da ich das Modul WOL nicht verstehe. Dieses "Ping" ist systemabhaengig und funktioniert nicht auf allen systemen. Windows sollte ausscheiden und die Parameter funktionieren nicht bei allen Unix/Linux distributionen.
Auf eine FB funktioniert es.

Den Wert -w 1 kannst du hoch setzen bis '-w 3'. Mehr solltest du nicht riskieren.

Nachteil ist: es wird nicht mehr 10sec auf ein device gewartet - könnte also zu Probleme führen, falls das device oder das Netzwert langsam ist - im heimnetz eher unwarscheinlich.

Ausserdem: WOL sollte nicht funktionierne, falls euere IP die 100 enthält - das ist ein Bug. z.B. 192.168.178.100

Übrigens - das Problem verschärft sich mit jedem Device, das ihr hier eintragt. Es wird für jedes device ein eigener timer gestartet.

Gruss
Martin

[Zrrronggg!]

Aeh... was macht WOL?

Also ich meine was ist der Sinn des Moduls?

[Martin]

Am Freitag, 14. Dezember 2012 00:18:30 UTC+1 schrieb Zrrronggg!:

Aeh... was macht WOL?

Also ich meine was ist der Sinn des Moduls?

etwas magere Beschreibung - aber es ist ein WakeOnLan. Details kenne ich nicht, ich benutze es auch nicht. 
Es prüft jedenfalls regelmaessig, ob das eingetragene device wach ist. Probleme gibt es übrigens nur, wenn es schläft

[Matthias]

Hallo Martin,

die Änderung im WOL- Modul auf w -1 hat erstmal keine Veränderung gebracht. Ich werde jetzt mit -2 weiter testen und berichten.
Der inzwischen eingetroffene CUL läuft ohne Probleme.
Ich denke es werden noch 2 weitere CUL´s an die Fritzbox kommen und der LAN Konfigurationsadapter landet bei ibähh.
 

Gruß

Matthias

2012.12.14 15:02:19 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.14 16:38:12 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.14 16:38:17 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.14 20:37:17 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.14 20:37:22 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.15 00:36:21 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.15 00:36:26 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.15 04:35:24 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.15 04:35:29 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.15 08:34:27 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.15 08:34:32 1: 192.168.1.116:1000 reappeared (HMLAN1)

[Matthias]

Hi,

ich habe im WOL-Modul den Test mit -2 gemacht und leider gibt es keinen reconnect mehr:

2012.12.15 12:44:17 1: Including fhem.cfg
2012.12.15 12:44:18 3: telnetPort: port 7072 opened
2012.12.15 12:44:19 3: WEB: port 8083 opened
2012.12.15 12:44:19 3: WEBphone: port 8084 opened
2012.12.15 12:44:19 3: WEBtablet: port 8085 opened
2012.12.15 12:44:19 3: Opening HMLAN1 device 192.168.1.116:1000
2012.12.15 12:44:19 3: Can't connect to 192.168.1.116:1000: Connection refused
2012.12.15 12:44:20 3: Opening CUL_0 device /dev/ttyACM0
2012.12.15 12:44:21 3: Setting CUL_0 baudrate to 9600
2012.12.15 12:44:21 3: CUL_0 device opened
2012.12.15 12:44:21 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2012.12.15 12:44:21 3: No I/O device found for schalter1
2012.12.15 12:44:21 1: Including ./log/fhem.save
2012.12.15 12:44:22 1: usb create starting
2012.12.15 12:44:22 1: usb create end
2012.12.15 12:44:22 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 25942)
2012.12.15 13:07:46 0: Server shutdown
2012.12.15 13:07:49 1: Including fhem.cfg
2012.12.15 13:07:51 3: telnetPort: port 7072 opened
2012.12.15 13:07:51 3: WEB: port 8083 opened
2012.12.15 13:07:51 3: WEBphone: port 8084 opened
2012.12.15 13:07:51 3: WEBtablet: port 8085 opened
2012.12.15 13:07:52 3: Opening HMLAN1 device 192.168.1.116:1000
2012.12.15 13:07:52 3: Can't connect to 192.168.1.116:1000: Connection refused
2012.12.15 13:07:53 3: Opening CUL_0 device /dev/ttyACM0
2012.12.15 13:07:53 3: Setting CUL_0 baudrate to 9600
2012.12.15 13:07:53 3: CUL_0 device opened
2012.12.15 13:07:53 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2012.12.15 13:07:54 3: No I/O device found for schalter1
2012.12.15 13:07:54 1: Including ./log/fhem.save
2012.12.15 13:07:54 1: usb create starting
2012.12.15 13:07:54 1: usb create end
2012.12.15 13:07:54 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 26256)

Ich werde nochmal mit -3 testen...


Matthias

[Markus Bloch]

@ Matthias, verwendest du denn auch das WOL Modul? Bei mir tritt der Fehler auf auch ohne WOL Modul.

[Matthias]

Hi Markus,
ich verwende WOL nicht, habe aber jetzt seit gestern mit -3 den Effekt, dass nach dem Neustart von fhem der Adapter gleich geöffnet wird und bis heute morgen geöffnet blieb.
Es scheint also bei der Anbindung eines Hm Lan cfg Adapters an die Fritzbox 7390 notwendig den WOL auf -3 zu setzen. Sieht im Moment gut aus.
Ich werde weiter berichten.

Gruss

Matthias

[Martin]

Hallo Matthias,

ich verwende WOL nicht, habe aber jetzt seit gestern mit -3 den Effekt, dass nach dem Neustart von fhem der Adapter gleich geöffnet wird und bis heute morgen geöffnet blieb.
Es scheint also bei der Anbindung eines Hm Lan cfg Adapters an die Fritzbox 7390 notwendig den WOL auf -3 zu setzen. Sieht im Moment gut aus.

verstehe ich nicht. das ist -3?  Die Zeit im WOL.pm für den Ping? Wenn du WOL aber nicht verwendest und keinen Entity eingebunden hast sollte es wirklich keinen effekt haben.
Falls es noch auftritt sollten wir den Fehler eingrenzen und dazu die Logs ziehen - also die messages vom HMLAN - wie gewohnt
attr gloval verbose 1
attr gloval mseglog 1
attr <hmlan> loglevel 1

Gruss
Martin

[Martin Thomas Schrott]

Hi,
 denke das sollte nicht

attr gloval verbose 1
attr gloval mseglog 1

sondern

attr global verbose 1
attr global mseclog 1

sein?! :-)

lG
Martin

--
To unsubscribe from this group, send email to
fhem-users+...@googlegroups.com

[Matthias]

Hi,
ich hatte den Wert im Modul WOL auf -w 3 erhöht:

Generell kann es noch weitere Module geben, die solche Vezögerungen auslösen - auch eine kombination aus mehreren ist möglich. Aber identifiziert ist bisher nur die eine.

Lösen kannst du es indem du im Modul 98_WOL.pm die Zeile
  if (`ping -c 1 $ip` =~ m/100/)
ersetzt gegen
  if (`ping -c 1 -w 1 $ip` =~ m/100/)

Einbauen möchte ich dies nicht, da ich das Modul WOL nicht verstehe. Dieses "Ping" ist systemabhaengig und funktioniert nicht auf allen systemen. Windows sollte ausscheiden und die Parameter funktionieren nicht bei allen Unix/Linux distributionen.

und nun scheint die Verbindung dauerhaft zu sein.
Andere Veränderungen hatte ich noch nicht vorgenommen. Ich kann aber gerne mal loggen.

Gruß
Matthias

[Martin]

Hi,

ich hatte den Wert im Modul WOL auf -w 3 erhöht:

ok - verstanden. Per default sind es 10 - also wenn kein Parameter angegeben wird.
Gefuehlsmaesig sind 3sec ausreichend fuer einen ping-test in einem Hausnetzwerk.
Fragen:
 - Hattest du Probleme. wenn du -w 1 angibst?
 - du hast gschrieben. dass du dies modul nicht 'in betrieb' hast. Wenn du keinen entity aus 'WOL' definiert hast sollte das alles ohne Bedeutung sein. Stimmt dies so?

und nun scheint die Verbindung dauerhaft zu sein.
Andere Veränderungen hatte ich noch nicht vorgenommen. Ich kann aber gerne mal loggen.

Wenn alles funktioniert ist loggen der Messages nicht notwendig.  Um das timerverhalten zu pruefen sind andere Logs notwendig

Gruss
Martin

[Matthias]

Hi Martin,

leider muss ich das mit dem kein disconnect mehr zurück nehmen:

2012.12.17 08:23:19 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.17 08:23:24 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.17 12:22:22 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.17 12:22:27 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.17 16:21:26 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.17 16:21:31 1: 192.168.1.116:1000 reappeared (HMLAN1)

Also ist klar - ohne WOL Nutzung bringt auch Veränderung der pingwaittime nichts.
Ich hatte mit -w 1 die gleichen disconnects.
Die regelmäßigen Abstände machen mich stutzig. Alle 4 h für 5 sec..

Ich werde also mal loggen, um zu sehen was wirklich passiert.

Gruß

Matthias

[Matthias]

Hi,

erste Zeilen vom log sehen so aus:

2012.12.17 19:10:07.064 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A5537D d2:0000
2012.12.17 19:10:32.100 1: HMLAN_Send:  K
2012.12.17 19:10:32.104 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A5B4EB d2:0000
2012.12.17 19:10:57.116 1: HMLAN_Send:  K
2012.12.17 19:10:57.124 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A61643 d2:0000
2012.12.17 19:11:22.132 1: HMLAN_Send:  K
2012.12.17 19:11:22.136 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A67799 d2:0000
2012.12.17 19:11:47.152 1: HMLAN_Send:  K
2012.12.17 19:11:47.156 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A6D8F3 d2:0000
2012.12.17 19:12:12.188 1: HMLAN_Send:  K
2012.12.17 19:12:12.208 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A73A6B d2:0000
2012.12.17 19:12:37.228 1: HMLAN_Send:  K
2012.12.17 19:12:37.232 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A79BCC d2:0000
2012.12.17 19:13:02.256 1: HMLAN_Send:  K
2012.12.17 19:13:02.260 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A7FD2F d2:0000
2012.12.17 19:13:27.272 1: HMLAN_Send:  K
2012.12.17 19:13:27.276 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A85E86 d2:0000
2012.12.17 19:13:52.296 1: HMLAN_Send:  K
2012.12.17 19:13:52.300 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A8BFE4 d2:0000
2012.12.17 19:14:17.340 1: HMLAN_Send:  K
2012.12.17 19:14:17.344 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:04A92157 d2:0000
2012.12.17 19:14:42.384 1: HMLAN_Send:  K
2012.12.17 19:14:42.388 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:2452

alles gut würde ich sagen.
Also alle 25 sec. wird ein keep alive geschickt. Die Frage ist: 
Wenn meine Abbrüche in den Morgenstunden kommen, wurde ien keep alive gesendet oder kam die Antwort nicht oder zu spät?
Hat den Fehler sonst niemand?
Es sind doch mit Sicherheit einige user mit der Kombi Fritzbox/HM-Lanadapter unterwegs.
Na schaun wir mal auf das log morgen früh....

Gruß
Matthias

[UliM]

Am Montag, 17. Dezember 2012 19:21:40 UTC+1 schrieb Matthias:

Hat den Fehler sonst niemand?
Es sind doch mit Sicherheit einige user mit der Kombi Fritzbox/HM-Lanadapter unterwegs.

Wie in dem anderen fred geschrieben habe ich seit Deaktivierung WOL kein disconnect/reappeared mehr. (genaugenommen in WOL nur in der Routine, in der das ping steht, gleich zu Anfang ein return; eingetragen -> kein ping mehr -> alles ist schön)

Wenn ei Dir kein Zusammenhang mit WOL erkennbar: evtl pingst Du ja aus einer anderen eigenen Routine heraus?  Einige der Handy-Anwesenheits-Routinen gehen m.W. diesen Weg...

=8-)

[Andreas Seeber]

Hi Matthias,

ich leide ebenfalls unter dem Phänomen, bei mir trat es in Zusammenhang WOL und lanping.sh auf und brachte mein IPTV in regelmäßigen Abständen zum stehen.
Aus diesem Grund habe ich meinen Adapter vorläufig in die Schublade verbannt und nutze jetzt einen CUL um den Hausfrieden zu waren.

Wenn sich morgen etwas Zeit ergibt werde ich alles mal auf HMLAN umstricken und sehen was passiert.

Danke an alle beteiligten für die Erforschung.

Grüße Andreas  

Am Montag, 17. Dezember 2012 19:21:40 UTC+1 schrieb Matthias:

[Matthias]

Hi Andreas,

heute morgen ging seit dem Auskommentieren des WOL-ping das erste Mal wieder eine angelegte Zeitschaltuhr. Ich habe nur kurz auf das log schauen können, welches durch die ausführliche Ausführung sehr lang wurde.
Dort waren auch wieder disconnects. Allerdings kam die Verbindung zum HMLAN wieder und somit die Testlampe heute morgen.
Werde heute nachmittag das log posten. Ich bin kurz davor noch 2 CUL zu bestellen denn der eine CUL läuft ohne probs. Ich wollte meine Hausautomation auf Rolladen- und Heizungssteuerung ausbauen.
Und spätestens bei einer kalten Wohnung wird meine Frau etwas kühler im Bezug zu den technischen "Spielereien". ;)

Gruß

Matthias

[Martin]

Hallo Zusammen,

Noch einmal klargestellt: WOL erzeugt eine "totzeit" von 10sec pro nicht beantworteten Pings (schlafendem device in der Liste). Das ist definitiv ein Problem. Es kann durch Reduzierung der Zeit (-w parameter bei FB, keine Garantie fuer andere Linux distributionen, funktioniert nicht auf Windows)  verbessert werden.

Generell hatte ich schon beschrieben, dass es jederzeit weitere Prozesse geben koennte, die sich auch einen ordentlichen Brocken Kerarbeitungs - oder Wartezeit koennen.

HMLAN kann aus 2 Gruenden disconnecten (soweit mir aufgefallen)
1) wenn die keepalive ausbleiben
2) bei zu hoher message last


2) hier habe ich eine Bremse eingebaut so dass es funktioniert hat. Kann aber durch wiederholer und last 'in der Luft' immer noch zu probleme fuehren - das kann ich nicht ausschliessen. Ein regelmaessiges auftreten halte ich fuer eher unwarscheinlich.

1) das beschriebene Problem deuten auf grund seiner Regelmaessigkeit auf ein timerproblem hin. Meine Vermutung ist ein 'zeitgraifender ' prozess  - im angegebenen Fall alle 4h
Zu sehen sollte in den Logs sein, dass kein 'K' nach 30sec vor dem disconnect kommt.

Sollte vermutung 1) zutreffen brauchen wir
a) welchen Funktionen laufen in dem environment?
b) 'instrumentierte ' load die das Verhalten der Timer dokumentiert
c) 'instrumentierte ' load die langlaeufer processe entlarvt.

fuer b) und c) kann ich ggf ein testimage basteln

Gruss
Martin

[Ralf]

Moin! 

1. Bei mir treten die Disconnects auch ohne WOL Modul (und auch bei 1-Sek-Timeout) auf.

2. Die Disconnects kommen auch (oder sogar vor allem) bei niedriger Funklast (z.B. regelmäßig Nachts...)

Kann ich irgendwo testweise die Zeitspanne der Keepalives z.B. auf 15 Sekunden reduzieren, bis das Senden geforked wurde? 

Viele Grüße, Ralf

[Martin]

a) kannst du einmal logs schicken um festzustellen, ob es am keep-alive haengt oder eine andere Ursache hat?
b) das keep-alive kannst du in 00_HMLAN.pm aendern, line 454(etwa)
  InternalTimer(gettimeofday()+25, "HMLAN_KeepAlive", "keepAlive:".$name, 1);

Gruss,
Martin

[Johan van der Kolk]

Hi Martin,

congratulations with a wonderful job on the HM module, it works like a charm !!

Thanks!

in the Basic Application I wrote, I had the same problems. In that case not a WOL but a module polling other devices took up all time.

Overloading the HMLAN with messages can be detected, I believe, since it echo's back what you sent it. Once it stops doing that, you know it has not sent out the command to the device. So you throttled that, which is the best solution.

One option is to reduce the wakeup time to 15 seconds so it would survive 1 failed ping, but I believe that would only solve the problem for the WOL module. There might be other modules that wait for a response from a device.

Is it not possible to run this HMLAN wakeup "outside" of the regular modules, so it is not affected by other modules?

Johan

--Johan

2012/12/18 Martin <marti...@gmail.com>

[Markus Bloch]

Ich denke, dass das ein generelles Problem ist. Ist ja nicht nur das Warten auf Antwort bei Systemcalls, sondern auch bei GetHttpFileFromUrl() als Beispiel. Die wartet ja auch maximal wie im Timeout angegeben auf eine Antwort vom Server. 

Dazu kommt noch die Last auf dem jeweiligen System wo FHEM läuft, etc. Evtl. hilft hier das auslagern des KeepAlive sendens in einen Thread. Der würde dann unabhängig laufen und den Socket immer Brav beschreiben.

Hab mich da aktuell intensiv mit beschäftigt (Multitthreaded Server in Perl).

Gruß

Markus

[Matthias]

Hi,
ich habe nun mit auskommentiertem WOL ein log über Nacht laufen lassen und :

2012.12.18 12:16:37.827 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:0850FC85 d2:0000
2012.12.18 12:16:37.831 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:0850FC95 d2:0000
2012.12.18 12:17:02.819 1: HMLAN_Send:  K
2012.12.18 12:17:02.831 1: HMLAN_Send:  K
2012.12.18 12:17:02.843 1: HMLAN_Send:  K
2012.12.18 12:17:02.847 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DD8 d2:0000
2012.12.18 12:17:02.847 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DE3 d2:0000
2012.12.18 12:17:02.859 1: HMLAN_Send:  K
2012.12.18 12:17:02.863 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DEF d2:0000
2012.12.18 12:17:02.867 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DFF d2:0000
2012.12.18 12:16:34.564 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.18 17:04:47.020 1: HMLAN_Send:  SAEC29A5B,00,00000000,01,AEC29A5B,06A0112452021783EE0201C80000D027
2012.12.18 17:04:49.036 1: HMLAN_Send:  SAEC2A23B,00,00000000,01,AEC2A23B,06A0112452021783EE0201C80000D027
2012.12.18 17:04:50.056 1: HMLAN_Send:  SAEC2A637,00,00000000,01,AEC2A637,06A0112452021783EE0201C800

Was ist das denn? Die Zeit läuft beim disconnect wieder rückwärts?
Bei mir sind im Moment die disconnects im Bereich von eigentlicher Ruhe für fhem.
Ich habe nur einen HM-LC-SW1-FM, einen AB440 über einen CUL an der Fritzbox 7390 und den besagten HMLAN im Einsatz.
Ich habe kein WOL am laufen und lediglich eine Zeitschaltuhrfunktion für die HM-LC-SW1-FM und den AB440 im System.
Zusätzlich logge ich nur die Daten von einem FHT80b und zweier FHT8 mit. Weiteres folgt erst wenn der HMLAN ohne Probleme läuft.

Ich hoffe das log hilft weiter.

Gruß

Matthias

Gruß

Matthias

[Matthias]

nochmal das log wegen der Zeit:

2012.12.18 12:16:12.743 1: HMLAN_Send:  K
2012.12.18 12:16:12.755 1: HMLAN_Send:  K
2012.12.18 12:16:12.767 1: HMLAN_Send:  K
2012.12.18 12:16:12.771 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08509AFF d2:0000
2012.12.18 12:16:12.771 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08509B0A d2:0000
2012.12.18 12:16:12.783 1: HMLAN_Send:  K
2012.12.18 12:16:12.787 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08509B16 d2:0000
2012.12.18 12:16:12.791 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08509B26 d2:0000
2012.12.18 12:16:37.783 1: HMLAN_Send:  K
2012.12.18 12:16:37.795 1: HMLAN_Send:  K
2012.12.18 12:16:37.807 1: HMLAN_Send:  K
2012.12.18 12:16:37.811 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:0850FC6D d2:0000
2012.12.18 12:16:37.811 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:0850FC79 d2:0000
2012.12.18 12:16:37.823 1: HMLAN_Send:  K
2012.12.18 12:16:37.827 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:0850FC85 d2:0000
2012.12.18 12:16:37.831 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:0850FC95 d2:0000
2012.12.18 12:17:02.819 1: HMLAN_Send:  K
2012.12.18 12:17:02.831 1: HMLAN_Send:  K
2012.12.18 12:17:02.843 1: HMLAN_Send:  K
2012.12.18 12:17:02.847 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DD8 d2:0000
2012.12.18 12:17:02.847 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DE3 d2:0000
2012.12.18 12:17:02.859 1: HMLAN_Send:  K
2012.12.18 12:17:02.863 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DEF d2:0000
2012.12.18 12:17:02.867 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245202 d:173FE7 O:245202 m:08515DFF d2:0000
2012.12.18 12:16:34.564 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.18 17:04:47.020 1: HMLAN_Send:  SAEC29A5B,00,00000000,01,AEC29A5B,06A0112452021783EE0201C80000D027
2012.12.18 17:04:49.036 1: HMLAN_Send:  SAEC2A23B,00,00000000,01,AEC2A23B,06A0112452021783EE0201C80000D027
2012.12.18 17:04:50.056 1: HMLAN_Send:  SAEC2A637,00,00000000,01,AEC2A637,06A0112452021783EE0201C80000D027

[Johan van der Kolk]

Is that a wakeup every 12 ms?

[Martin]

Johan

Overloading the HMLAN with messages can be detected, I believe, since it echo's back what you sent it. Once it stops doing that, you know it has not sent out the command to the device. So you throttled that, which is the best solution.

I noticed that - but I have no full understanding  in the replies. I identified some status conditions but not all of them. sometimes I get 2 for one message.
Nevertheless I will try to identify a mechanism to controll traffic dependant on responses.
 

One option is to reduce the wakeup time to 15 seconds so it would survive 1 failed ping, but I believe that would only solve the problem for the WOL module. There might be other modules that wait for a response from a device.

I agree

Is it not possible to run this HMLAN wakeup "outside" of the regular modules, so it is not affected by other modules?

good idea. Nevertheless I would target a solution the other way round. Currently there are several timing constrains to be considered with even tighter timings:
- HMLAN keep-alive ~30s
- respose to weakup devices 300ms max
- acks to deivces 200-300ms

not talking about user timer settings by now.

My suggestion would be to
- restrict max process time for single task - suggestion is less then 100ms
- developer have to obey that rule - FHEM can supervice that and post logs upon violation

Martin

[Martin]

which version do you use?
This is only the keepalive without answer

2 things suprise me:
- some versions ago  I put in some code to prevent multiple keep-alive timer
- recently I added code for fast reconnect once there is no answer to the keep-alive. Original mechanism is based on ethernet events, not on keep-alive

Therefore I consider yuo are no on the latest version 2340 - correct?

[Ralf]

Hallo Martin, 

Am Dienstag, 18. Dezember 2012 13:20:23 UTC+1 schrieb Martin: 

 das keep-alive kannst du in 00_HMLAN.pm aendern, line 454(etwa)
 InternalTimer(gettimeofday()+25, "HMLAN_KeepAlive", "keepAlive:".$name, 1); 

 Hab dort und wenige Zeilen höher die 25 gegen 15 getauscht und die Disconnects sind völlig verschwunden! 

Zum Log weiter unten: Vielleicht benutzt die FBF keine "saubere" Zeitadaption per clock skew des ntpd sondern wird hart auf die NTP-Zeit gesetzt? 

Gibt es dafür ein Ereignis, auf das man reagieren könnte?

[Martin]

ah - dass war der Kommentar von johank
also die Frage an dich - ist dies das neuste HMLAN?

Seltsam sind die 4 'keep-alive'. Ich werde noch einmal eine Version Basteln mit Timer-Logs.

Und natuerlich ist der Zeitstempel seltsam.
Kannst du einen groesseren Ausschnitt posten - evtl als anhang? HMLAN hat in diesem Ausschnitt NICHT neu connected - da sind andere Messages zu sehen

Gruss
Martin

[Johan van der Kolk]

Die timer sind vieleicht richtig, es kann sein das die nicht im richtigen reihenfolge im log geschrieben sind. Normalerweise wen es im 200 und mehr ms geht hat mann moeglichewiese dieses problem nicht,

Die aendereung nach 15 is nur proof das ein anders modul dise probleme verursacht, es ist nicht die loesung. Design rules (<100ms) oder multithreading. ist die loesung.

Ubrichens, der HMLAN schickt seiene eigene Ack, das kansst du tun durch ein +A12345,0 wo A12345 die HM device addresse ist zum HMLAN zu schicken.


 (muss mal checken ob es A12345,0 oder A12345,02,0 ist um den Ack vom HMLAN abschicken zu lassen. 

Die anzahl Acks die HMAN in stock hat sieht man im antwort auf dem K, leider nicht fuer welche devices. Jedenfalls so habe Ich das interpretiert.

Ich schicke gar kein Acks ab in mein Basic program..

--Johan

2012/12/19 Martin <marti...@gmail.com>

[Johan van der Kolk]

In addition to my previous message, I initialize the HMLAN and then send

' setup ACK's for paired units
  rResult = Devices.FindDevicesForInterface(36)
  FOR EACH rResult
  SendHMLAN("+" & rResult!address & ",00,00")
  NEXT

where rResult!address is a pull from a DB giving me the Homematic deviceaddresses

And everytime a message has been acknowledged by the HMLAN I prepare a new ACK

IF Sdst = sHMLANid AND bAckRequested = TRUE AND sMsgtype <> "00" AND sMsgtype <> "3F" AND Left$(sSegments[0], 1) = "E" THEN
    sCmd = "+" & sSrc & ",02,00,"
    SendHMLAN(sCmd)

I'm dealing with the pairing request (00) and the timesync (3F) separate.

--Johan

2012/12/19 Johan van der Kolk <johan.va...@gmail.com>

[Martin]

Johank

Am Mittwoch, 19. Dezember 2012 18:02:40 UTC+1 schrieb Johank:

Die timer sind vieleicht richtig, es kann sein das die nicht im richtigen reihenfolge im log geschrieben sind. Normalerweise wen es im 200 und mehr ms geht hat mann moeglichewiese dieses problem nicht,

Could be. That is why I need a deeper log. After a disconnect there are some setup messages that I can find. As those are not present there was no disconnect to HMLAN.  The connection was not restarted.

Die aendereung nach 15 is nur proof das ein anders modul dise probleme verursacht, es ist nicht die loesung. Design rules (<100ms) oder multithreading. ist die loesung.

we can see the  delay out of the traces then we can adjust

Ubrichens, der HMLAN schickt seiene eigene Ack, das kansst du tun durch ein +A12345,0 wo A12345 die HM device addresse ist zum HMLAN zu schicken.

I know that the HMLAN sends ACK itself - and waits for ACK as well. It will repeat messages with a delay of 200ms approx.  I have no idea how to controll that. Current implementation is that FHEM does not send 'normal' acks to the device thru HLMAN. It does so for the CUL. I experienced big confusion when the additional acks are sent. What is sent are 'ack_Status' if necessary. Those are necessary if FHEM acts as actor.
My recomendation is not to do that but use a virtual device/channel instead. This gives a cleaner environment.

If you have some information about the meaning of the FHEM-HMLAN protocoll let me know . There is certainly room for improvement

 (muss mal checken ob es A12345,0 oder A12345,02,0 ist um den Ack vom HMLAN abschicken zu lassen. 

Die anzahl Acks die HMAN in stock hat sieht man im antwort auf dem K, leider nicht fuer welche devices. Jedenfalls so habe Ich das interpretiert.

Ich schicke gar kein Acks ab in mein Basic program..

HLMAN also supress simple-ACK. If CUL is used ACKs will pass thru.

Martin

[Martin]

Am Mittwoch, 19. Dezember 2012 18:38:23 UTC+1 schrieb Johank:

In addition to my previous message, I initialize the HMLAN and then send

' setup ACK's for paired units
  rResult = Devices.FindDevicesForInterface(36)
  FOR EACH rResult
  SendHMLAN("+" & rResult!address & ",00,00")
  NEXT

where rResult!address is a pull from a DB giving me the Homematic deviceaddresses

And everytime a message has been acknowledged by the HMLAN I prepare a new ACK

IF Sdst = sHMLANid AND bAckRequested = TRUE AND sMsgtype <> "00" AND sMsgtype <> "3F" AND Left$(sSegments[0], 1) = "E" THEN
    sCmd = "+" & sSrc & ",02,00,"
    SendHMLAN(sCmd)

I'm dealing with the pairing request (00) and the timesync (3F) separate.

Similar to the current impelmentation in FHEM.
each device that needs to be handles is addded with
+<hmid>
There is also a command
 -<hmid>

I assume those are for multi-HMLAN setups and you can use to to controll which HMLAN has to serve the rspective  device.

I have seen the additional values
+<hmID>,00,00
also with different values then "00". Do you have an idea or guess about the meaning of the numbers? It was used whensetting up teh RC12from HMCONFIG

Martin

[Johan van der Kolk]

I used Wireshark to analyze the traffic, some parts I did not understand.

For what I can see is that the +hmid,00,00 results in 2 things

1. Acks being sent by the HMLAN

2. The last word in the reply to K increases with the amount of Acks in stock

The +hmid,02,00 is required to wake up the device.

If I don't send it the device will not reliably return in an awake status (HM-CC-TC)

My sequence is basically:

1. Send a +hmid,02,00 after the any message that needed to be Acked. (not after any received message)

2. then when a command needs to be sent to the device, just send it and don’t wait for anything.

Normally the HMLAN provides you with the result of the last sent command. In this case you will receive a

0008 = NACK from HMLAN. I store the command in the stack.

3. I follow that with a +hmid,02,00

The next time the device reports status, the HMLAN now reports 0081, the device is awake and ready to accept commands. So the HMLAN prepends data to the received device message.

4. Then I kick out all commands that I had stored in the stack for that device in sequence, and clear the sent command from the stack when I receive the message 0001 (Ack received from remote device) from the HMLAN.

the 0001,0081 and 0008 are the first characters received in the HMLAN message, before it echoes the timestamps an the actual radio message to the TCP port

Once I sent out all messages for the device I send -hmid and +hmid. It seems to clear an internal register in the HMLAN.

This last step is just a result from the Wireshark analysis, but it apparently needs to be sent to keep the HMLAN happy.

Now, while this works fine for the HM-CC-TC, I have not tested it against other HM devices.

Unless I choke the interface, this method gives 100% success-rate.

I'll try to send you a log from a few commands if you are interested. Obviously only the thermostat, that is all I have, and I have not written any code for other devices.

--Johan

On Wed, Dec 19, 2012 at 8:53 PM, Martin <marti...@gmail.com> wrote:

Similar to the current impelmentation in FHEM.
each device that needs to be handles is addded with
+<hmid>
There is also a command
 -<hmid>

I assume those are for multi-HMLAN setups and you can use to to controll which HMLAN has to serve the rspective  device.

I have seen the additional values
+<hmID>,00,00
also with different values then "00". Do you have an idea or guess about the meaning of the numbers? It was used whensetting up teh RC12from HMCONFIG

Martin

--

[Martin]

johank,

that is an interresting information.

The detail with +<hmID> was expected. Interresting is the 02 feature.

For TC I would say this is not necessary. It works fine without. Maybe we can improve functionallity.
But I will try this with the VD. this does not react adequate if we try to control it from FHEM.

Regarding the HMLAN status-word reply I have
0000 : message "E" type - message ok for further parsing Not seen with 'R' type
0001 : send  - ack received
0002 : ?? return our own message?
0008 : no ack received
0021 :??  also something with wakeup?
0081 : => according to you this is the wakeup indication from  - pending data can be transmitted by now

To control I have
+<hmId> # should be send once - then the deivce will be handled by this HLMAN adapter
-<hmId> # remote this ID fom LAN adapter - could be used if multiple adapter are in use.
+<hmId>,00,00 # I think there is no difference to the first one - seems to be default
+<hmId>,02,00 # prepare for wakeup??? have to experiment
+<hmId>,01,00,F1EF #send from HMconfig to my RC12 once a while during read - after a certain block.

Others I am not aware off

I don't agree that -hmid +hmid needs to be sent. It works fine without that.  Some similar procedure was implemented at the time I forst looked at the code. I came to the conclusion after some testing that this is  not necessary. All it finally did was to add some delay to the transmission.
You have to obey that many (most?/all?)  HM deviceses need an outage of ~100ms between messages. Sending faster may cause message loss. Second you have to obey wireless transmission speed of HMLAN. Sending faster then that will cause the HMLAN to disconnect. I do calculate that briefly out of the data to be transmitted. I cannot consider concestion on the air interface nor resend aktions due to missing acks.
I am not sure about the HMLAN buffer for transmitt messages - but it is very short. You need to queue and delay externally.

Thanks - I will restart testing the VD with your information

Martin

[Martin]

One more thing:
After status 0008 I cannot assume that  this is a wakeup device. It also can be that the device is not present, dead,... it even comes if I addressed a wron channel.

Therefore I will try to send the 02 prior to the send-message for wakeup devices.

[Martin Thomas Schrott]

Hi Martin,

> Therefore I will try to send the 02 prior to the send-message for
> wakeup devices.

kann es sein, dass dies auch mein Rauchmelder Problem behebt? Oder hast
du die Hoffnung bei denen schon aufgegeben? ;-)

cheers
Martin

[Johan van der Kolk]

On Thu, Dec 20, 2012 at 1:41 PM, Martin <marti...@gmail.com> wrote:

johank,

that is an interresting information.

The detail with +<hmID> was expected. Interresting is the 02 feature.

For TC I would say this is not necessary. It works fine without. Maybe we can improve functionallity.
But I will try this with the VD. this does not react adequate if we try to control it from FHEM.

Regarding the HMLAN status-word reply I have
0000 : message "E" type - message ok for further parsing Not seen with 'R' type
0001 : send  - ack received
0002 : ?? return our own message?
0008 : no ack received
0021 :??  also something with wakeup?
0081 : => according to you this is the wakeup indication from  - pending data can be transmitted by now

I have to check, I believe there is also one that means "nice message, but for another HMLAN)

To control I have
+<hmId> # should be send once - then the deivce will be handled by this HLMAN adapter

 

the device will always be handled by this HMLAN (pairing), this makes sure it sends Acks

-<hmId> # remote this ID fom LAN adapter - could be used if multiple adapter are in use.  

 

Don't think so, the messages are also used in a single HMLAN setup. Additionally, each HM device can only pair with one HMLAN adapter...at least that is what the third message in the pairing sequence tells me.

But I might be proven wrong, after all there is a dual HMLAN  setup possible.

 

+<hmId>,00,00 # I think there is no difference to the first one - seems to be default

 

I'm sending 00,00 at the init, afterwards only 00,02, and once I'm done with a device -hmid,+hmid.

Send the 00,00 message and the count at the end of the K reply will go up, not sure if the same is true for the +hmid message, might well be but in this case I copied the behaviour of the homematic software.

+<hmId>,02,00 # prepare for wakeup??? have to experiment
+<hmId>,01,00,F1EF #send from HMconfig to my RC12 once a while during read - after a certain block.

Others I am not aware off

I don't agree that -hmid +hmid needs to be sent. It works fine without that. 

 If you start using the 02 feature it might become necessary.

Some similar procedure was implemented at the time I forst looked at the code. I came to the conclusion after some testing that this is  not necessary. All it finally did was to add some delay to the transmission.
You have to obey that many (most?/all?)  HM deviceses need an outage of ~100ms between messages. Sending faster may cause message loss. Second you have to obey wireless transmission speed of HMLAN. Sending faster then that will cause the HMLAN to disconnect. I do calculate that briefly out of the data to be transmitted. I cannot consider concestion on the air interface nor resend aktions due to missing acks.

I used actually 350ms between commands. So far I only noted the length of my command queue to make sure all messages had an ACK. I also requeued failed commands to give it another try. (and kept a general counter). So not very sophisticated.

Actually I have 2 queues, a "interface queue" (emptied one message per 350 ms) and a command stack.

In the command stack oldest messages for a device are sent first. Also when resending failed commands I re-timestamp them.

 

I am not sure about the HMLAN buffer for transmit messages - but it is very short. You need to queue and delay externally.

I think I wrote registers, not command buffer, the command buffer/queue is in the software. HMLAN just transmits up to three times the last command, until it gets an ACK from the device.

Thanks - I will restart testing the VD with your information

If you are brave you can try to set registers in the HMLAN, the D and Y command will probably do that, with the right code behind it :)

D1 and D2 will give some info back, again I don't know what, did not make sense to me.

the B command sets the red light, an puts the HMLAN in a mode in which it seems to be waiting for something. Power off and on to regain control of the adapter :)

Good luck !

Johan

[Johan van der Kolk]

Correct, you should keep track of all messages returning with 0008 status, and after some amount declare the device dead, or unreachable. If you re-stack failed commands for a next try, you could count how often a command for a device was re-stacked, and let that trigger a message. You could always get the odd radio transmission failure.

--Johan

--

[Martin]

kann es sein, dass dies auch mein Rauchmelder Problem behebt?

ich denke nicht. Rauchmelder sind "burst devices" keine "weakup devices". Ausserdem reagieren sie ja
 

Oder hast du die Hoffnung bei denen schon aufgegeben? ;-)

nein, habe ich nicht - habe gerade die referenz-logs gefunden und werden diese noch einmal durchgehen.

Gruss
Martin

[Martin]

Am Donnerstag, 20. Dezember 2012 15:26:07 UTC+1 schrieb Johank:

I have to check, I believe there is also one that means "nice message, but for another HMLAN)

I don't understand. messages do not destinguish between HMLAN and other  HMID. So what you mean is that those message could be like monitored events between two HM devices? I will watch

To control I have
+<hmId> # should be send once - then the deivce will be handled by this HLMAN adapter

 

the device will always be handled by this HMLAN (pairing), this makes sure it sends Acks

-<hmId> # remote this ID fom LAN adapter - could be used if multiple adapter are in use.  

 

Don't think so, the messages are also used in a single HMLAN setup. Additionally, each HM device can only pair with one HMLAN adapter...at least that is what the third message in the pairing sequence tells me.

But I might be proven wrong, after all there is a dual HMLAN  setup possible.

I consider an environment with 2 HMLAN both having the same ID. Someone with a remote walking thru the house wants to use the closest HMLAN. I would assume eq3 has a mechanism in place to support that. This would mean that you can switch off sending to a HMID unless it is put on your list. Receive should always be possible  in order to determin the RSSI for best transmission. Even though I am not sure how it works I would be disapointed if this is not forseen by a protocoll of that complexity .

 

+<hmId>,00,00 # I think there is no difference to the first one - seems to be default

 

I'm sending 00,00 at the init, afterwards only 00,02, and once I'm done with a device -hmid,+hmid.

Send the 00,00 message and the count at the end of the K reply will go up, not sure if the same is true for the +hmid message, might well be but in this case I copied the behaviour of the homematic software.

+<hmId>,02,00 # prepare for wakeup??? have to experiment
+<hmId>,01,00,F1EF #send from HMconfig to my RC12 once a while during read - after a certain block.

Others I am not aware off

I don't agree that -hmid +hmid needs to be sent. It works fine without that. 

 If you start using the 02 feature it might become necessary.

will see. You mentioned both 00,02 and 02,00. Is this a type?

Some similar procedure was implemented at the time I forst looked at the code. I came to the conclusion after some testing that this is  not necessary. All it finally did was to add some delay to the transmission.
You have to obey that many (most?/all?)  HM deviceses need an outage of ~100ms between messages. Sending faster may cause message loss. Second you have to obey wireless transmission speed of HMLAN. Sending faster then that will cause the HMLAN to disconnect. I do calculate that briefly out of the data to be transmitted. I cannot consider concestion on the air interface nor resend aktions due to missing acks.

I used actually 350ms between commands. So far I only noted the length of my command queue to make sure all messages had an ACK. I also requeued failed commands to give it another try. (and kept a general counter). So not very sophisticated.

Actually I have 2 queues, a "interface queue" (emptied one message per 350 ms) and a command stack.

350ms is to long I think. The window for wakeup devices is like 200ms (without 02...) Waiting 350 will certainly be too late - we tried that.
I had not issue with 100ms on a device level. HMLAN can do more - but I am not sure about the actual restrictions - e.g. how many pending acks in parallel.

In the command stack oldest messages for a device are sent first. Also when resending failed commands I re-timestamp them.

this is a deep field. e.g. setting parameter in the device is a sequence of at least 3 messages. If one is lost you would have to resent starting with the first one. I have not jet implemented this complexity. Also I added some timer in the device-layer. Thus the correct procedure in my architecture would be to queue only on device level, not on IO-level. Resend need to  consider device-type. a resend for a weakup device needs to be delayed untill next weakup (not jet impelmented)
My current resent is pretty stupid and does not obey those things. At some time I intend to consider device-type and command level (multi-message commands)  - but first I will try to weakup a device with the inforamtion from you

 

I am not sure about the HMLAN buffer for transmit messages - but it is very short. You need to queue and delay externally.

I think I wrote registers, not command buffer, the command buffer/queue is in the software. HMLAN just transmits up to three times the last command, until it gets an ACK from the device.

agree. I think it was able to handle more then one message during testing. But  this is insecure and hard to handle.

Thanks - I will restart testing the VD with your information

If you are brave you can try to set registers in the HMLAN, the D and Y command will probably do that, with the right code behind it :)

D1 and D2 will give some info back, again I don't know what, did not make sense to me.

the B command sets the red light, an puts the HMLAN in a mode in which it seems to be waiting for something. Power off and on to regain control of the adapter :)

Good luck !

Thanks
Martin

[Johan van der Kolk]

On Thu, Dec 20, 2012 at 5:03 PM, Martin <marti...@gmail.com> wrote:

Am Donnerstag, 20. Dezember 2012 15:26:07 UTC+1 schrieb Johank:

I have to check, I believe there is also one that means "nice message, but for another HMLAN)

I don't understand. messages do not destinguish between HMLAN and other  HMID. So what you mean is that those message could be like monitored events between two HM devices? I will watch

HMLAN monitors all traffic, I have 2 and can see all messages on the one that is not paired with anything.
 

I consider an environment with 2 HMLAN both having the same ID.

Agree in that scenario

 

 

will see. You mentioned both 00,02 and 02,00. Is this a type?

is typo

350ms is to long I think. The window for wakeup devices is like 200ms (without 02...) Waiting 350 will certainly be too late - we tried that.

I'm not delaying the first message, only the subsequent ones. And the TCP socket implementation is not so robust in Gambas, I may have choked something else before the adapter. At least I could send over 20 messages to the same device after it woke up, so I was happy :)
 

this is a deep field. e.g. setting parameter in the device is a sequence of at least 3 messages.

Same problem encountered for pairing yes, I worked around that by not sending the next one before I have a successful previous msg.
Looks like a layered approach is required, time the messages going out, sequence the command messages, do errorchecking, report errors and let the layer(s) above that take care of the errors.

 

Johan

[Johan van der Kolk]

Von FHEM wiki, Request for Proposals

start quote:

Mechanismus fuer langsame Readings

Problemstellung: Laengere Verarbeitungsprozesse in einzelnen Modulen (z.B. aufgrund von Netzwerklatenzen oder toten Geraeten) halten fhem komplett an und verhindern die Verarbeitung von Events.

Loesung: Multiprocessing

Beim Multiprocessing wird der fhem-Prozess geforkt, wenn ein Reading vom Geraet eingelesen werden soll. Der Vaterprozess wird sofort fortgesetzt und erledigt weitere Aufgaben. Der Kindprozess holt die Readings vom Geraet, liefert sie an den Vaterprozess und verendet.

Die Lieferung an den Vaterprozess erfolgt durch eine Verbindung zu fhem via Netzwerk und Aufruf des Befehls

ende quote

--Johan

[Martin]

 Johan,

ja, multiprocessing ist die einzige Lösung. Aber der Einbau ist nicht trivial - und das debuggen auch nicht. Generell muss man immer noch mit delays rechnen - man hat das timesharing auf die Linux ebene verlegt - aber warte ist kein Problem mehr.
Generell sollte man ich ein konzeptuenerlegen, ob man Pro 'warten' einen prozess forked, einen child-thread oeffnet oder generell einen slow-thread generiert, der low-level tasks behandelt.
Besonders letzteres ist etwas resourcen freundlicher, erfordert aber deutlich mehr Disziplin und Koordination beim Programmieren. #
Das Forken eines Prozesses gibt es auch nicht zum Null-tarif.

Aber Generell Korrekt - multi-prozessing ist der einzige Weg so etwas zu verhindern.

Gruss
Martin