Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Markus,
ja das sieht leider nach genau dem Fehler aus.
Dank dir
Gruß
Matthias
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Aeh... was macht WOL?
Also ich meine was ist der Sinn des Moduls?
On 13 Dez., 07:55, Martin wrote:
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
>
> 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)
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@ Matthias, verwendest du denn auch das WOL Modul? Bei mir tritt der Fehler
auf auch ohne WOL Modul.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 loglevel 1
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am 17.12.2012 09:12, schrieb 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 loglevel 1
>
> Gruss
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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:
>
> 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
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am Montag, 17. Dezember 2012 21:11:09 UTC+1 schrieb 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:
>>
>> 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
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am Dienstag, 18. Dezember 2012 12:52:05 UTC+1 schrieb Martin:
>
>
> HMLAN kann aus 2 Gruenden disconnecten (soweit mir aufgefallen)
> 1) wenn die keepalive ausbleiben
> 2) bei zu hoher message last
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> 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
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am Dienstag, 18. Dezember 2012 19:20:22 UTC+1 schrieb 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
>>
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Is that a wakeup every 12 ms?
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
Am Dienstag, 18. Dezember 2012 19:35:17 UTC+1 schrieb Johank:
>
> Is that a wakeup every 12 ms?
>
> 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
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> 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
>
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> 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
>
>> 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
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
>
>
> --Johan
>
>
> 2012/12/19 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
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
+
There is also a command
-
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
+,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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 wrote:
>
>
>
> Similar to the current impelmentation in FHEM.
> each device that needs to be handles is addded with
> +
> There is also a command
> -
>
> 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
> +,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
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
johank,
that is an interresting information.
The detail with + 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
+ # should be send once - then the deivce will be handled by this
HLMAN adapter
- # remote this ID fom LAN adapter - could be used if multiple
adapter are in use.
+,00,00 # I think there is no difference to the first one - seems to
be default
+,02,00 # prepare for wakeup??? have to experiment
+,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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am 20.12.2012 13:44, schrieb 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.
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Thu, Dec 20, 2012 at 1:41 PM, Martin wrote:
> johank,
>
> that is an interresting information.
>
> The detail with + 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
> + # 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
- # 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.
> +,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.
+,02,00 # prepare for wakeup??? have to experiment
> +,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
>
> Martin
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
On Thu, Dec 20, 2012 at 1:44 PM, Martin wrote:
> 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.
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>> + # 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
>
> - # 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 .
>
>> +,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.
>
> +,02,00 # prepare for wakeup??? have to experiment
>> +,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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Thu, Dec 20, 2012 at 5:03 PM, Martin 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
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
On Thu, Dec 20, 2012 at 7:43 PM, Johan van der Kolk <
johan.vanderkolk@gmail.com> wrote:
>
>
> On Thu, Dec 20, 2012 at 5:03 PM, Martin 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
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com