Homematic-Aktoren schalten manchmal nicht

[snoop]

Hallo Martin,

kurzes Feedback.
Gestern ist einer von meinen 4 HM-LC-Bl1PBU-FM ausgestiegen mit Meldung: MISSING ACK
Heute Morgen haben die 3 übrig gebliebenen geschaltet.
Heute Abend sind weitere 2 HM-LC-Bl1PBU-FM ausgestiegen mit MISSING ACK.
Ergo: nur noch einer funktioniert.
Ich habe versucht sie zu pairen zu schalten immer mit dem gleichen Ergebnis: MISSING ACK.
Nun habe ich die alte (letzte funktionierende Version) rein kopiert und reloadet ohne HMLAN reset.
Ergebnis: ich konnte sofort ein statusRequest ausführen und ein auf/zu commando ausführen.
Dies nur zur Info, dass da scheinbar noch was (möglicherweise auch nur eine Kleinigkeit) nicht ganz funktioniert.
Logs kann ich im Moment nicht liefern - sorry.
Viele Grüße
Arthur

[snoop]

Hallo Martin,

ich würde gerne heute Abend wieder die alte 00_HMLAN.pm (Modifizierte) siehe hier einspielen und erneut loggen.
Gibt es bereits eine neue Version der HMLAN oder kann ich die o.g. nehmen? Danke.
Viele Grüße
Arthur

P.S: Seit ich am Wochenende die Aktoren auf "autoReadReg 3_onChange" gestellt habe - habe ich massive Probleme mit MISSING ACK - ist nur eine Vermutung. Selbst mit der , ich nenne Sie mal, "stabileren" (älteren Version) hat heute Morgen ein Rollo nicht geöffnet. (Logs kann ich auf Wunsch schicken).

[martinp876]

Hallo Arthur,

die neue Version ist seit gestern online.

kannst du ein paar logs aufzeichnen mit missing-acks?
Die Alte Version musst du auc SVN holen: version 3034

Gruss
Martin

[cwagner]

Moin,
die verschiedenen Updates der letzten Tage habe ich alle jeweils zeitnah eingespielt und das Verhalten der inzwischen 7 Rollladenaktoren so weit ich konnte beobachtet. Das geschilderte Problem trat nun an 5 Tagen in Serie nicht mehr auf. Somit waren entweder Deine Anpassungen erfolgreich oder mein Fall beruhte doch auf Zufällen oder anderen Störungen.
Danke für Dein bemerkenswertes Engagement für dieses Projekt!

Christian

[Georg312]

Hallo Martin,

habe jetzt mal ein längeres logfile erstellt, in dem man die fehlenden Statusmeldungen beobachten kann.

6 Rolläden bekommen Befehl runterzufahren und tun dies tatsächlich auch. Bei 2 kommt die Rückmeldung "off" allerdings nie an.
Ein expliziter "statusRequest" liefert allerdings direkt den korrekten Zustand.

(file kommt per PM)

Hallo Georg,

Stabilitaet interessiert mich immer, ist schliesslich die Grundlage saemtlicher hoeherer Auswertungen.
Wann tritt dass Problem auf? Hast du ein Scenario? Kannst du es loggen, die roh-messages?

[martinp876]

Hallo Georg,

was ich sehen kann ist, dass die einige Messages wiederholt werden muessen und dass einig Aktoren ihren Status 3mal melden.
Der Status der beiden Problemkinder fehlt.
Da ich die Fahrzeiten der Rollos nicht kenne, ist unklar ob die potentiellen Antwort gerade in einem Bulk von Messages untergegangen ist.
So recht komme ich nicht weiter. Was auffaellt ist, dass eine potentiell neuere FW (groesser 2.1) Einstellungen zum Transmitt der Statusmessages bietet (leider sind meine BL FW2.1...) .
Ich schliesse jetzt einfach einmal, dass HM mit unter Probleme beim Uebermitteln der Status-info hat, die in FW > 2.1 behoben sind (oder verbessert).
Stand ist also, dass das Uebertragen der Kommandos mittels des Wiederhol-machanismus funktioniert. Messages, die von Device kommen, koennen verloren gehen.

Demnach ist das Problem in FHEM nicht ursaechlich loesbar, bestenfalls umgehbar.
Was ist machbar: Eine Allgemeine Loesung kann es nicht geben, da FHEM nicht bekannt sein kann, ob ein Device etwas gesendet hat.

Eine spezielle Loesung fuer Falle ist denkbar falls FHEM eine "Schaltung" gesehen hat aber keine statusInfo. FHEM koennte den Status nachfragen, falls dieser nicht automatisch kommt. Natuerlich nur, wenn FHEM ein Kommando gesendet hat, das eine Statusaenderung nach sich zieht.
Ich werden darueber nachdenken. Klar ist, dass die Nachfrage lange dauern wird. Rollos fahren ueber eine Min. Nachfragen also erst nach >2min.
Aktuell stelle ich mir einen weiteren Level des autoReadReg vor, mit dem man einstellen kann, dass Statusaenderungen abzufragen sind.

Gruss
Martin

[LuckyDay]

Hi, ich habe auch eine Batterie Rollos 6 Stück die gleichzeitig runter und rauf fahren,
und hatte auch immer wieder das Problem mit fehlenden Status.

    

Code Auswählen Erweitern

*{sunset(0,"20:35","23:10")} set eg_Roll1 zu;sleep 0.5;set eg_Roll2 zu;sleep 0.5;set eg_Roll3 zu;sleep 0.5;set eg_Roll4 zu;sleep 0.5;set eg_ku zu;sleep 0.5;set eg_klo zu;

mit dem Fhem sleep(nicht perl sleep) von 0.5 sec tut es seit einem halben Jahr zu 99% perfekt, (bei mir)
5 rollos haben gleiche Lauflänge.
ich habe mich von 0,3 über 0,4, auf 0,5 gesteigert, und 0.5 sek ist meine Zeit :)

[martinp876]

Hi,

mit Verzoegerungen klappt das sicher besser, ist m.E aber EXTERM unschoen und user-unfreundlich. Sollte die Annahme korrekt sein koennen Stati verloren gehen, weil "die luft dicke" ist. Beispielsweise durch TC/VDs die sich auch gerade einmal einmischen.

Gerade in diesem Fall (FHEM sendet, info MUSS kommen) kann man etwas machen und sollte es auch.
Gruss
Martin

[LuckyDay]

:)
unschön finde ich , das der Status als Broadcast kommt, und daher keine Prüfung ob Fhem empfangen hat, also keine Wiederholung des Status.
unschön ist es auch , wenn das Rollo nicht fährt,

Schön finde ich, das es bei mir so geht.

Martin, mir ist es schon klar, das dir eine andere Lösung besser gefällt, ich kann mit der leben.
eigentlich sollte die firmware von Broadcast auf direkt zur Zentrale umgestellt werden.....
So kannst du aber nur eine Routine schreiben,
wenn befehl an Rollo, warte auf Status x sekunden, falls nicht kommt, mache einen statusrequest
die xSekunden könnte man den Wert nehmen von der Laufzeit + z.b 5 sekunden.

besser? :)

[martinp876]

unschön finde ich , das der Status als Broadcast kommt,

sollte nicht so sein. Wenn gepairt ist kommt er eigentlich an die Zentrale. Trotzdem kann es zu Probleme kommen.
pruefen einmal dein pairing. Hast du ein Beispiel von Broadcast? Ich schaue noch einmal

Schön finde ich, das es bei mir so geht.

prima

die xSekunden könnte man den Wert nehmen von der Laufzeit + z.b 5 sekunden.

denke ich nicht. Die Laufzeit habe ich nicht sicher.
Aber generell ist das der Ansatz.
Aktuelle Idee ist (hoffentlich sparsam)
- Bei 'set' Befehlen wird ein Status erwartet. Einschaltbar im DEVICE fuer alle Aktoren (autoRegRead = 4)
- Wartezeit ist 120sec NACH DEM LETZTEN SET. Ist aktuell egal fuer welchens Device ein set gekommen ist. Es gibt nur einen Timer in CUL_HM.
- wenn kein InfoStatus fuer diesen Kanal gekommen ist wird der Statusrequest gestartet. Immer einer nach dem anderen, alle 5 sec einer.

Nachdem es 'nur' eine Info ist kann man sich erlauben etwas zu warten.

Beachte, dass auch Dimmer mit Rampen von Stunden programmiert werden koennen, oder eine onTime von Stunden. Diese Faelle decke ich nicht ab.
Abgedeckt sollte Faelle von Rollos und einfachen Dimmern sein, das ist normal in 120sec erledigt.

Ich denke, das reicht, was meinst du?

Interessant waere noch, trigger abzufangen. Also wenn eine remote an den Lichtschalter einen trigger sendet, sollte FHEM irgendwann einen Status bekommen. Das will ich im 2. Schritt addieren.

Gruss
Martin

[Georg312]

Hallo Martin,

bei Deinen Überlegungen bitte berücksichtigen. Die Rolladen schicken nach einem set 2x einen Status:
- das erste mal direkt wenn es los geht. Status "motor:up"
- das zweite mal wenn er angekommen ist. Status "motor:off"

Georg

[LuckyDay]

Code Auswählen Erweitern

2013-04-17 15:59:44.237 CUL_HM wz_Roll4 level: set_90
2013-04-17 15:59:44.269 CUL_HM wz_Roll4 set_90
2013-04-17 15:59:44.302 HMLAN hmlan1 SND L:0C N:65 F:A0 CMD:11 SRC:F12222 DST:wz_Roll4 0201B4 (SET CHANNEL:0x01 VALUE:0xB4) (,BIDI,RPTEN)
2013-04-17 15:59:44.523 CUL_HM wz_Roll4 level: 99.5 %
2013-04-17 15:59:44.523 CUL_HM wz_Roll4 deviceMsg: 99.5 % (to hmlan2)
2013-04-17 15:59:44.523 CUL_HM wz_Roll4 99.5 %
2013-04-17 15:59:44.523 CUL_HM wz_Roll4 motor: down:99.5 %
2013-04-17 15:59:52.359 HMLAN hmlan1 RCV L:0D N:66 F:84 CMD:10 SRC:wz_Roll4 DST:broadcast 0601B400 (INFO_ACTUATOR_STATUS) (,CFG,RPTEN)
2013-04-17 15:59:52.407 CUL_HM wz_Roll4 level: 90 %
2013-04-17 15:59:52.407 CUL_HM wz_Roll4 deviceMsg: 90 % (to broadcast)
2013-04-17 15:59:52.407 CUL_HM wz_Roll4 90 %
2013-04-17 15:59:52.407 CUL_HM wz_Roll4 motor: stop:90 %

meiner sendet nach broadcast, wenn er die höhe erreicht hat

Code Auswählen Erweitern



Internals:
   CHANGED    
   DEF        152C48
   EVENTS     1
   IODev      hmlan1
   LASTInputDev hmlan2
   MSGCNT     167
   NAME       wz_Roll4
   NR         76
   NTFY_TRIGGERTIME 2013-04-17 16:09:18
   STATE      offen
   TYPE       CUL_HM
   hmlan1_MSGCNT 89
   hmlan1_RAWMSG R1854E4D1,0001,FF9B2FA7,FF,FFB6,6C8010152C48F122220049455130303136313635
   hmlan1_RSSI -74
   hmlan1_TIME 2013-04-17 16:10:16
   hmlan2_MSGCNT 78
   hmlan2_RAWMSG E152C48,0000,588E8FE0,FF,FFAC,6C8010152C48F122220049455130303136313635
   hmlan2_RSSI -84
   hmlan2_TIME 2013-04-17 16:10:16
   lastMsg    No:6C - t:10 s:152C48 d:F12222 0049455130303136313635
   protLastRcv 2013-04-17 16:10:16
   protSnd    1 last_at:2013-04-17 16:10:16
   protState  CMDs_done
   rssi_at_hmlan1 avg:-74 min:-74 max:-74 lst:-74 cnt:1
   rssi_at_hmlan2 avg:-84 min:-84 max:-84 lst:-84 cnt:1
   rssi_hmlan1 avg:-69.52 min:-78 max:-63 lst:-77 cnt:17
   Readings:
     2013-04-17 16:09:01   CommandAccepted yes
     2013-04-17 15:48:47   PairedTo        0xF12222
     2013-04-17 15:48:52   R-driveDown     50 s
     2013-04-17 15:48:52   R-driveTurn     0.5 s
     2013-04-17 15:48:52   R-driveUp       50 s
     2013-04-17 15:48:47   R-intKeyVisib   invisib
     2013-04-17 15:48:47   R-pairCentral   0xF12222
     2013-04-17 15:48:52   R-refRunCounter 0
     2013-04-17 15:48:52   R-sign          off
     2013-04-17 15:48:47   RegL_00:         02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:F1 0B:22 0C:22 00:00
     2013-04-17 15:48:52   RegL_01:         08:00 09:00 0A:00 0B:01 0C:F4 0D:01 0E:F4 0F:05 10:00 00:00
     2013-04-17 15:49:01   RegL_03:Fernb_19TBtn_7  01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00
     2013-04-17 15:49:09   RegL_03:Fernb_19TBtn_8  01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00
     2013-04-17 16:09:18   deviceMsg       on (to broadcast)
     2013-04-17 16:09:18   level           100 %
     2013-04-17 16:09:18   motor           stop:on
     2013-04-17 15:48:51   peerList        Fernb_19TBtn_7,Fernb_19TBtn_8,
     2013-04-17 16:09:18   state           on
     2013-04-03 20:28:36   virtLevel       set_43
   Helper:
     mId        0005
     peerIDsRaw ,15FD0C08,15FD0C07,00000000
     rxType     1
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlan1:
         avg        -74
         cnt        1
         lst        -74
         max        -74
         min        -74
       At_hmlan2:
         avg        -84
         cnt        1
         lst        -84
         max        -84
         min        -84
     Shadowreg:
Attributes:
   .devInfo   010100
   IODev      hmlan1
   eventMap   /on:offen/80:halb/55:lzu/43:zu/
   expert     2_full
   firmware   1.5
   group      Rollo
   model      HM-LC-BL1-FM
   peerIDs    00000000,15FD0C07,15FD0C08,
   room       Wohnzimmer
   serialNr   IEQ0016165
   subType    blindActuator
   webCmd     offen:halb:lzu:zu



[martinp876]

Hi Hary,

cool, mein model HM-LC-Bl1PBU-FM

HMLAN_Parse:     m:14 A410 1BCCB8 1743BF 0601C800

die Zentrale. Eigentlich habe ich so gut die nichts nach Broadcast ausgenommen anlernen.
Ich halte es fuer einen Bug in der HM FW - evtl war es eine fruehe FW version.
Bei Georg mit den Fehlenden Statusmessages ist es ebenso, trotz angefordertem ACK.

Die Version mit dem Wiederholen werden ich nacher einstellen, da ist es wir der Status geschickt wird.

Einschalten mit autoRegRead 4

Gruss
Martin

[LuckyDay]

ist wirklich cool,
macht dann deiner eine wiederhohlung, wenn er kein ack bekommt?

ich lese auch die anderen Beiträge mit, hab nur nicht immer etwas zu melden :)

[martinp876]

macht dann deiner eine wiederhohlung, wenn er kein ack bekommt?

denke schon. Das Problem ist, dass HMLAN das ACK schickt. Hatte ich anfaenglich komplett uebersehen, erst beim Monitoren mit einer parallele CUL.
Somit ist der Test schwierig, besonders mit HMLAN.

Ich koennte es mit der CUL testen.
Du musst sicherlich beachten:
- welches device
- welche FW version
=> XML zeigt da (m.E. erhebliche) unterschiede auf. HM hat offensichtlich nachgebessert.

Sicher ist auch, dass einige Devices dies bereits einstellbar haben, sogar in recht umfangreicher Form. Anzahl der Wiederholungen/zeit zwischen den Wiederholungen/randomtimer fuer Wiederholungen. Diese Devices warten offenlichtlich auf ACKs.

Gehe davon aus, dass bit 5 des Flags die Anforderung eines ACKs ist. Und dass dann auch gewartet und wiederholt wird.
Welche ACKs ein HMLAN sendet kannst du ohne CUL (oder andern Monitor) schlecht erkennen.

Version 1 ist freigegeben - falls du einen Test machen kannst mit deinem Aufbau, ohne die 0.5sec gib Bescheid.

ich lese auch die anderen Beiträge mit, hab nur nicht immer etwas zu melden :)

denke ich mir, daher der Kommentar ;-)