Missing Ack & disconnected bei HMLAN - Änderung in 00_HMLAN.pm erforderlich?

[MisterEltako]

Hallo Martin!

rudolfkönig hat mich mit meiner Frage an dich verwiesen. Also:

Problem1: gleichzeitiges Schalten von mehreren Aktoren über HMLAN bringt missing ack's der Aktoren
Problem2: häufiges disconnecten des HMLAN

temporäre Lösung: aus altem Thread habe ich gefunden, dass das Einfügen der Zeile
                  select(undef, undef, undef, 0.3);
                  als letzte Zeile im Abschnitt HMLAN_write($$$) der 00_HMLAN.pm hilft.

Ergebnis: missing acks- und disconnect-Problem ist weg!!!!!

Frage: Gibt es irgendwelche Probleme mit FHEM, wenn ich diesen Eintrag belasse?

Kommentar von Rudolf König dazu:
Diese Zeile blockiert fhem fuer 0.3 Sekunden, und das kann sich schnell zu eine stoerende Laenge aufschaukeln. Ich dachte das waere inzischen wie beim FS20 geloest, da wird das mit InternalTimer aus einer Warteschlange abgearbeitet. Wie auch immer, dieser Punkt gehoert in die HM Gruppe, da HM von Martin uebernommen wurde.

Habe in der 10_FS20.pm aber keinen Durchblick, wo da die angesprochene Schleife wäre und wo müsste ich sie dann in der 00_HMLAN.pm einfügen?

MfG, MisterEltako

[StefanV]

Hallo MisterEtalko,

ich kann das Verhalten bestätigen, ich fahre zeitgleich einmal 2 und 3 Rolladen herunter.
Vorhin ist eine davon stehen geblieben.

Code Auswählen Erweitern

2013-01-04_17:01:32 wz_HM_FensterErker_Rolladen set_55%
2013-01-04_17:01:36 wz_HM_FensterErker_Rolladen MISSING ACK
2013-01-04_17:04:13 wz_HM_FensterErker_Rolladen set_55
2013-01-04_17:04:13 wz_HM_FensterErker_Rolladen CommandAccepted: yes
2013-01-04_17:04:14 wz_HM_FensterErker_Rolladen deviceMsg: 98.5 % (to HMLAN1)
2013-01-04_17:04:14 wz_HM_FensterErker_Rolladen motor: down:98.5 %
2013-01-04_17:04:14 wz_HM_FensterErker_Rolladen 98.5 %
2013-01-04_17:04:23 wz_HM_FensterErker_Rolladen deviceMsg: 55 % (to HMLAN1)
2013-01-04_17:04:23 wz_HM_FensterErker_Rolladen motor: stop:55 %
2013-01-04_17:04:23 wz_HM_FensterErker_Rolladen 55 %
Ein erneutes Schalten hatt dann funktioniert.

Den Verbindungsverlust des HMLAN kann ich allerdings nicht entdecken.

Ciao, Stefan.

[MisterEltako]

Hi, Stefan!

Versuche es mal testweise mit der Ergänzung in der 00_HMLAN.pm. Ich bin trotz Rudolf König's Einwand echt happy, das es jetzt damit funktioniert.

Leider scheint das disconnected-Problem nicht weg, aber derzeit zumindestens nur 1x/Tag.

2013.01.04 16:58:37 2: CUL_HM set Rollladen_EG 1 rxt:1
2013.01.04 16:58:38 1: 192.168.100.33:1000 disconnected, waiting to reappear
2013.01.04 16:58:43 1: 192.168.100.33:1000 reappeared (HMLAN)
2013.01.04 16:58:43 2: CUL_HM set Rollladen_Flur 39 rxt:1

MfG, MisterEltako

[martinp876]

Hallo,

das einfügen einer Pause von 300ms zerstört so gut wie alle antworten. Ein Device erwartet eine Antwort so nach 100-200ms. Das es in euerem Mode funktioniert verstehe ich - ihr sendet nur und der Aktor sendet die Antwort. Probleme gibt es wenn das HM-device eine 'anfrage' stellt und fhem antworten soll. da sind 300ms zu viel.
Unter anderem betrifft es den TC. Will man eine temp einstellen muss man nach dem Aufwachen des TC in 200ms reagieren.

Wenn es bei Euch funktioniert soll es mir recht sein. Für die Allgemeinheit ist es keinen Lösung.
Das ich persönlich ein Problem habe eine Wartezeit von 300ms einzubauen - und das je gesendeter message - ist zweitrangig. FHEM ist so schon langsam und zeitkritisch.

Dennoch muss an der 'Flusskontrolle' noch gearbeitet werden.

Gruss
Martin

[MisterEltako]

Hallo Martin!

Danke für die Antwort.
Natürlich ist jede Verzögerung nicht schön. Das damit Antworten zerstört werden, war mir nicht klar (bin ja auch noch Neuling ;o)). Ich habe großen Respekt vor deiner Arbeit, die du dir mit dem HMLAN-Modul gemacht hast. Manche Zeilen begreift man als Neuling wirklich nicht. Ich hoffe das wird mit der Zeit... ;o) Also ich bitte um Nachsicht, falls das Anfängerfragen sind!

Aber ich muss sagen, dass die "missing acks" bei gleichzeitiger Schaltung von 3 Schaltaktoren (einer schaltet, 2 Acks) für mein Aussenlicht auch nerven.

Hatte das zunächst so umgangen:

define Aussenlampen_an at *17:00:00 {fhem("set Aussenlicht_Tuer An;;\
                                                         sleep 0.5;;\
                                                         set Aussenlicht_Kueche An;;\
                                                         sleep 0.5;;\
                                                         set Aussenlicht_Terrasse An;;")}

... und dann später mit Eintrag der Zeile:

select(undef, undef, undef, 0.3); in 00_HMLAN.pm konnte ich wie nachfolgend ohne "missing acks" schalten:

define Aussenlampen_an at *17:00:00 {fhem("set Aussenlicht_Tuer An;;\
                                                         set Aussenlicht_Kueche An;;\
                                                         set Aussenlicht_Terrasse An;;")}

Aber kann man den nicht statt der select-Pause es so wie beim FS20 in der 00_CUL.pm lösen? Da wird doch lt. Rudolf König das ganze mit InternalTimer aus einer Warteschlange abgearbeitet und würde FHEM somit nicht blockieren.

Zitat von rudolfkoenig:
"...00_CUL.pm/CUL_Write() -> CUL_AddFS20Queue, da wird auch HomeMatic abgedeckt.
Aber evtl. verwendest Du ein HMLAN und kein CUL..."

Geht das???

MfG, MisterEltako

[martinp876]

Hallo MisterEltako,

>Natürlich ist jede Verzögerung nicht schön. Das damit Antworten zerstört werden, war mir nicht klar (bin ja auch noch Neuling >;o)). Ich habe großen Respekt vor deiner Arbeit, die du dir mit dem HMLAN-Modul gemacht hast. Manche Zeilen begreift man als >Neuling wirklich nicht. Ich hoffe das wird mit der Zeit... ;o) Also ich bitte um Nachsicht, falls das Anfängerfragen sind!

kein Problem

>Aber ich muss sagen, dass die "missing acks" bei gleichzeitiger Schaltung von 3 Schaltaktoren (einer schaltet, 2 Acks) für >mein Aussenlicht auch nerven.

muss gelöst werden, keine Frage.

Generell kannst du immer mit warten arbeiten. So nach 400ms sollten einfache Anfragen beendet sein - also 'list-an'. Ein device antwortet so in 100-200ms, evtl gibt es wiederholer, das sind bis zu 3. Wenn dann nicht etwas anderes 'in der Luft' gebote ist, sollte dieses Ereigniss funktionieren.

Das Warten in der CUL fuer HM habe mit HMLAN ziemlich gleichgezogen. HMLAN ist einiges komplexer als CUL 'dank' der eingebauten Wiederholer.
Generell - und das weiss Rudi sicher besser als ich - stoppt jedes warten den kompletten Ablauf von FHEM. CUL und HMLAN haben bisher einen device-spezifischen queues - das ist in CUL_HM realisiert. Was du willst ist ein stopp aller Übertragungen bis der eine Schalter fertig ist. Damit kann es eben zu Problemen bei den anderen kommen, die ein ACK erwarten oder Folgeaktionen.
Was Rudi gemeint hat, weiss ich nicht.

kannst du noch ein Log schicken mit den HMLAN messages und msec auflösung?

Danke
Martin

[MisterEltako]

Hallo Martin!


Hier die def und Log-Ausgabe bei Auschalten der 3 Lampen über einen struktur-Befehl:
(Aussenlicht_Kueche o.k., Aussenlicht_Terrasse & Aussenlicht_Tuer bringen "missing ack")

define Aussenlicht_Tuer CUL_HM 1B730F
define Aussenlicht_Kueche CUL_HM 1B01E1
define Aussenlicht_Terrasse CUL_HM 1AFCC9
define Licht_all structure room Aussenlicht_Tuer Aussenlicht_Kueche Aussenlicht_Terrasse


2013.01.06 18:42:37.909 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0XXXXXX d:1ACB86 O:250902 m:5C3C4EBB IDcnt:0005
2013.01.06 18:42:52.150 1: HMLAN_Send:  +1B01E1,00,00,
2013.01.06 18:42:52.151 1: HMLAN_Send:  S10F53B32,00,00000000,01,10F53B32,06A0112509021B01E10201000000
2013.01.06 18:42:52.152 1: SND L:0E N:06 F:A0 CMD:11 SRC:250902 DST:Aussenlicht_Kueche 0201000000 (SET CHANNEL:0x01 VALUE:0x00 RAMPTIME:0x0000) (,BIDI,RPTEN)
2013.01.06 18:42:52.219 1: HMLAN_Send:  +1AFCC9,00,00,
2013.01.06 18:42:52.219 1: HMLAN_Send:  S10F53B77,00,00000000,01,10F53B77,07A0112509021AFCC90201000000
2013.01.06 18:42:52.220 1: SND L:0E N:07 F:A0 CMD:11 SRC:250902 DST:Aussenlicht_Terrasse 0201000000 (SET CHANNEL:0x01 VALUE:0x00 RAMPTIME:0x0000) (,BIDI,RPTEN)
2013.01.06 18:42:52.354 1: HMLAN_Send:  +1B730F,00,00,
2013.01.06 18:42:52.355 1: HMLAN_Send:  S10F53BFE,00,00000000,01,10F53BFE,08A0112509021B730F0201000000
2013.01.06 18:42:52.356 1: SND L:0E N:08 F:A0 CMD:11 SRC:250902 DST:Aussenlicht_Tuer 0201000000 (SET CHANNEL:0x01 VALUE:0x00 RAMPTIME:0x0000) (,BIDI,RPTEN)
2013.01.06 18:42:52.422 1: HMLAN/RAW: /R10F53B32,0001,5C3C86FD,FF,FFB0,0680021B01E12509020101000052

2013.01.06 18:42:52.422 1: HMLAN_Parse: HMLAN S:R10F53B32 stat:0001 t:5C3C86FD d:FF r:FFB0 m:0680021B01E12509020101000052
2013.01.06 18:42:52.430 1: RCV L:0E N:06 F:80 CMD:02 SRC:Aussenlicht_Kueche DST:250902 0101000052 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x52) (,RPTEN)
2013.01.06 18:42:52.831 1: HMLAN/RAW: /R10F53B77,0008,00000000,FF,7FFF,07A0112509021AFCC90201000000

2013.01.06 18:42:52.832 1: HMLAN_Parse: HMLAN S:R10F53B77 stat:0008 t:00000000 d:FF r:7FFF m:07A0112509021AFCC90201000000
2013.01.06 18:42:52.958 1: HMLAN/RAW: /R10F53BFE,0008,00000000,FF,7FFF,08A0112509021B730F0201000000

2013.01.06 18:42:52.959 1: HMLAN_Parse: HMLAN S:R10F53BFE stat:0008 t:00000000 d:FF r:7FFF m:08A0112509021B730F0201000000
2013.01.06 18:42:54.225 1: HMLAN_Send:  S10F5434D,00,00000000,01,10F5434D,07A0112509021AFCC90201000000
2013.01.06 18:42:54.365 1: HMLAN_Send:  S10F543D9,00,00000000,01,10F543D9,08A0112509021B730F0201000000
2013.01.06 18:42:54.829 1: HMLAN/RAW: /R10F5434D,0008,00000000,FF,7FFF,07A0112509021AFCC90201000000

2013.01.06 18:42:54.829 1: HMLAN_Parse: HMLAN S:R10F5434D stat:0008 t:00000000 d:FF r:7FFF m:07A0112509021AFCC90201000000
2013.01.06 18:42:54.969 1: HMLAN/RAW: /R10F543D9,0008,00000000,FF,7FFF,08A0112509021B730F0201000000

2013.01.06 18:42:54.969 1: HMLAN_Parse: HMLAN S:R10F543D9 stat:0008 t:00000000 d:FF r:7FFF m:08A0112509021B730F0201000000
2013.01.06 18:42:55.235 1: HMLAN_Send:  S10F5473F,00,00000000,01,10F5473F,07A0112509021AFCC90201000000
2013.01.06 18:42:55.375 1: HMLAN_Send:  S10F547CB,00,00000000,01,10F547CB,08A0112509021B730F0201000000
2013.01.06 18:42:55.839 1: HMLAN/RAW: /R10F5473F,0008,00000000,FF,7FFF,07A0112509021AFCC90201000000

2013.01.06 18:42:55.839 1: HMLAN_Parse: HMLAN S:R10F5473F stat:0008 t:00000000 d:FF r:7FFF m:07A0112509021AFCC90201000000
2013.01.06 18:42:55.979 1: HMLAN/RAW: /R10F547CB,0008,00000000,FF,7FFF,08A0112509021B730F0201000000

2013.01.06 18:42:55.979 1: HMLAN_Parse: HMLAN S:R10F547CB stat:0008 t:00000000 d:FF r:7FFF m:08A0112509021B730F0201000000
2013.01.06 18:43:02.915 1: HMLAN_Send:  K
2013.01.06 18:43:02.919 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0XXXXXX,1ACB86,250902,5C3CB071,0005

2013.01.06 18:43:02.919 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ01XXXXXX d:1ACB86 O:250902 m:5C3CB071 IDcnt:0005

MfG, MisterEltako

[martinp876]

Hallo MisterEltako,

ich werden in heute eine neue Version einstellen - mit Verbesserungen im Protokoll.

a) HMLAN: ich konnte Probleme nachstellen wenn mehrere Devices gleichzeitig gesteuert werden sollen. Das konnte ich verbessern (bei mir eliminieren) durch entfernen einer Verzögerung in HMLAN. Es ist ein bisschen der Tanz auf dem Vulkan: Die Verzögerung führte offensichtlich dazu, dass die letzten Messages send mit den ersten receive 'zusammengestossen' sind. Im Umkehrschluss hiest dies wenn der User leicht verzögert sendet kann das Problem noch auftreten. Sicher auch wenn man 'genügent' devices gleichzeitig senden lässt.
Anmerkung: das Handling von Kanälen hat CUL_HM, CUL und HMLAN unter kontrolle. Mit mehreren Devices meine ich nicht Kanaele!

b)CUL_HM hat jetzt auch ein 'resend' für konfigurations-messages. Also Nachrichten die nicht auf ACK sondern auf Infos warten. Also getConfig, u.ä.

c) Es gibt keine Wiederholung mehr für wakeup und config gesteuerte Devices aus CUL_HM heraus (nur noch HMLAN, nocht CUL).Dies ist sinnlos da eine Wiederholung immer ausserhalb der Wartezeit des Device ist und nicht funktionieren kann.

Bin gespannt, ob es Euere Probleme löst - oder verbessert.
Gruss
Martin

[MisterEltako]

Hallo Martin!

Vielen Dank für die Änderung der 00_HMLAN.pm.

Jetzt kann ich meine 3 Außenlampen ohne den zugefügten Eintrag "select" schalten und habe den Eindruck, dass die 3 Schalter auch noch wesentlich schneller angesprochen werden als zuvor!!!!

Super!!!! Bisher konnte ich noch keine Fehler bemerken.

Verräts du, was du genau geändert hast? ;o)


MfG, MisterEltako

[martinp876]

Verräts du, was du genau geändert hast? ;o)

klar - hatte ich schon angesprochen:

HMLAN hatte eine Verzögerung eingebaut um den Transmitt-channel (die Luftschnittstelle) nicht zu überfahren. Ich lasse jetzt mehr traffic zu, es wird also schneller in das HMLAN 'reingepumpt'.
Ist eigentlich merkwürdig, aber macht auch etwas sinn:
durch das "schnelle" senden sind die Messages 'im HMLAN' und unter dessen Kontrolle.
beim "Langsamen senden" ist es wahrscheinlich zu kollisionen gekommen - zwischen dem Senden den HMAN und den Antworten der Aktoren.
Vorstellbar ist, dass HMLAN alle Messages 'in einem' schickt und erst danach den 'luftkanal' freigibt. erst dann senden die Aktoren.

Es gibt auch Nachteile - man kann jetzt den HMLAN auch überfahren. Das nimmt der evtl. übel - hatte ich auch schon.

Die Alternative ist bei jeder message zu warten, bis alle Antworten gekommen sind (300ms-thema). Die Nachteile hier sind ungleich grössen und es ist im endeffekt instabiler.

Anzumerken ist auch, dass durch "langsames abschicken" ein Problem wie vor wieder vorkommen kann. Also wenn Aktionen aus mehreren Notify gestartet werden.

kompliziert genug erklärt? ;-) Ist nicht alles straight forward.

Um das ganze zu stabilisieren - besonders im Bezug auf die Abfrage-funktionen (getConfig ...) ist dort nun auch ein wiederhol-mechanismus eingebaut. Sonst gab es hier Probleme, ist jetzt auch stabiler bei mehrfachabfragen.

Was mir noch fehlt ist ein Kommando, den HMLAN zu resetten! Falls jemand einen Tip hat?


Gruss
Martin

[Markus Bloch]

Hallo Martin,

auch nochmal meinen tiefsten Dank an dich. Nun läuft bei mir das HMLAN superstabil, ohne reconnects und ohne MISSING ACKS bei structures.

Einsame Spitze.

PS: kleiner Vorschlag für deinen fehlenden Reset-Befehl - mach doch einfach einen KeepAlive-Sturm, hat bei mir immer einen Reset hervorgerufen ;-)

Viele Grüße und besten Dank

Markus

[Dennis D.]

Also nach dem Update bekomme ich immer noch "MISSING ACKS" bei meinen Rollladenaktoren. Dies betrifft eigentlich jedoch nur einen. Dieser eine fährt meist morgens nicht hoch.
Empfangsprobleme können ausgeschlossen werden, da die Entfernung nicht groß ist.
Interessant ist dabei, dass ich die Probleme in diesem Raum auch schon mit einem Rollladenaktor aus dem RWE-Smarthome-Programm (ebenfalls von eq-3) hatte.

hier mal ein Auszug aus dem Log:

Code Auswählen Erweitern


2013-01-15_07:56:08 HA_Jalousie deviceMsg: runter (to LANInterface)
2013-01-15_07:56:08 HA_Jalousie motor: up:runter
2013-01-15_07:56:08 HA_Jalousie runter
2013-01-15_07:56:11 KU_Jalousie deviceMsg: 5 % (to LANInterface)
2013-01-15_07:56:11 KU_Jalousie motor: up:5 %
2013-01-15_07:56:11 KU_Jalousie 5 %
2013-01-15_07:56:11 WZ_Jalousie deviceMsg: 1 % (to LANInterface)
2013-01-15_07:56:11 WZ_Jalousie motor: up:1 %
2013-01-15_07:56:11 WZ_Jalousie 1 %
2013-01-15_07:56:12 EZ_Jalousie MISSING ACK
2013-01-15_07:56:12 VR_Jalousie MISSING ACK
2013-01-15_07:57:06 EZ_Jalousie deviceMsg: rauf (to LANInterface)
2013-01-15_07:57:06 EZ_Jalousie motor: stop:rauf
2013-01-15_07:57:06 EZ_Jalousie rauf
2013-01-15_07:57:06 KU_Jalousie deviceMsg: rauf (to LANInterface)
2013-01-15_07:57:06 KU_Jalousie motor: stop:rauf
2013-01-15_07:57:06 KU_Jalousie rauf
2013-01-15_07:57:06 HA_Jalousie deviceMsg: rauf (to LANInterface)
2013-01-15_07:57:06 HA_Jalousie motor: stop:rauf
2013-01-15_07:57:06 HA_Jalousie rauf

Lustigerweise fährt der Rollladen hoch, wenn ich ihn anschließend über Fhem noch mal anstoße.

Hat jemand eine Idee hierzu?

[martinp876]

Hallo Spunky,

interessant sind immer die message-logs. Dazu ist immer die Liste der HMIDs hilfreich sowie die Beschreibung, was schief ging.
Evtl hat ein Raum ein Empfangsproblem, evtl ein stoersender im zimmer,... wenn es schon oefter vorkam, sprich auch bei anderen device anderer Familien.

Auch immer vorsichtig mit der Aussage 'Funkproblem kann ich ausschliessen'. Stoersender, abschirmungen und auch Schwankungen im deviceempfaenger und dessen Qualitaet koennen - leider - probleme verursachen.

Testhalber kannst du auch erst einmal die Reihenfolge der Devices in deinem Kommando aendern - vielleicht bleibt es dann anderswo dunkel ;-)

Gruss
Martin

[Dennis D.]

sorry, weiß nicht was ihr da am besten braucht bzw. wie ich das log so einstelle, dass ich diese infos bekomme.

also der aktor ist noch nicht mal weit entfernt, andere sind deutlich weiter weg. in dem raum sind keinerlei sender oder störquellen. es gibt nur zwei dinge die ich mir vorstellen könnte:

1. neben meiner nas und dem Lan-Interface steht die Fritzbox. der auffällige aktor ist der einzige, bei dem die fritzbox "fast" auf einer linie mit der funkstrecke liegt. vielleicht stört hier das WLAN?

2. Habe gerade mal die configs angeschaut. ich habe fünf jalousie-aktoren, welche bei sonnenaufgang alle gleichzeitig angesteuert werden. der fünfte (und damit letzte) ist der, der die missing acts bringt.

ich bin jetzt erstmal hingegangen und habe "define at"-Jobs gemacht und steuer die rollladen nun nicht gleichzeitig an, sondern jeder mit einer verzögerung von einer sekunde.

[martinp876]

Hallo spunky78

um festzustellen wo das Prolem liegt muessen wir auf die IO-ebene runter gehen. Da mit es nicht zu viele traces gibt sollte man

attr global verbose 1
attr global mseclog 1
attr <iodev> loglevel 1
attr <iodev> hmProtocolEvents 0

setzen
die Logs werden dann ins 'zentrale' fhemlog geschrieben. Hier habe ich dann den Ablauf mit timing

Gruss
Martin