Hallo Martin,
über einen Notify steuere ich mehrere Aktoren (Rollladen) und hatte in der Vergangenheit das Problem, dass beim Schalten der Aktoren nicht alle, bspw. auf ein "auf", reagiert haben - sprich 3/4 ok | 1er keine Reaktion.
Nach langem Suchen bin ich auf eine Lösung (00_HMLAN.pm) gestossen:
#Zeile ca. 235 (je nach Version der HMLAN)
my $tm = int(gettimeofday()*1000) % 0xffffffff;
$msg = sprintf("S%08X,00,00000000,01,%08X,%s",$tm, $tm, substr($msg, 4));
HMLAN_SimpleWrite($hash, $msg);
#EIGENTLICH HIER DIESE ZEILE
######################################
# Some linux installations are broken with 0.001, T01 returns no answer
select(undef, undef, undef, 0.03);
Kannst du deinerseits diese Implementierung begrüssen?
Ich habe bisher gute Erfahrung gemacht - habe leider nur ein Problem: nach jedem Update muss ich die Zeile einfügen ergo *es nervt*! Macht es hier nicht evtl. Sinn das global zum implementieren (ja ich weiß, 0.03 funktioniert vielleicht bei mir bei anderen nicht - klar)?
Oder soll ich eher mit "sleep" arbeiten?
Oder ist es Geschmackssache was man macht?
Vorzugsweise würde ich eine stabile Variante bevorzugen.
Oder anders gefragt: was hat es mit dem Problem auf sich - offensichtlich ist das Problem noch da? Mache ich etwas falsch?
Viele Grüße
Arthur
Hallo Arthur,
ich erinnere mich an das Problem...
Natuerlich bin ich an einer stabilen Implementierung interessiert, sprich sie soll ueberall funktionieren, also auch bei dir. Ueber kurz oder lang gibt es eh groessere Probleme, wenn diese Grundlagen nicht stabil sind.
Im Allgemeinen mag ich keine delays, manchmal sind sie notwendig. Bevor ich den einbaue werde ich also noch einmal forschen. Lieber waere mir eine event-getriebene Steuerung, die ist, wenn der mechanismus verstanden ist immer robuster UND schneller
Kannst du es unterstuetzen mit ein paar tests und traces -ich weiss, ich hatte schon ein paar, aber ich arbeite gerne mit frischen, da muss ich mir nicht merken, was einmal war und was geaendert wurde.
Du kannst es ja simulieren, ein neues notify bauen mit einfachen trigger und gleicher aktion. Dann laufen lassen mit deiner Aenderung und mit orginal SW. Angaben was haengt.
Gruss, Danke Martin
Hallo Martin,
dieses Problem tritt nur sporadisch auf - also 2 Tage gehen die Rollos auf - dann wieder nicht.
Ich baue mal was - schauen wir mal, ob ich es reporoduzieren kann - sonst wird es ein paar Tage dauern bis da was kommt.
Melde mich.
Viele Grüße
Arthur
kein Problem. Es waren 4 Rollos? fuer meinen Test...
nur als gedanke der ausgeschlossen werden sollte: könnte es daran liegen das die befehle zu den aktoren sequentiell gesendet werden und das ack von einem aktor dem befehl für den nächsten in die quere kommt? ich habe dieses problem z.b. wenn ich meine fenstergriffe zu schnell bewege und der zweite status vom griff dem gesendeten rollladen kommando in die quere kommt.
gruss
andre
Hallo Martin,
Zitatkein Problem. Es waren 4 Rollos? fuer meinen Test...
Hmm also ich steuere gleichzeitig/sequenziell 4 Rollladen Aktoren an.
Zu einem bestimmten Zeitpunkt (08:00h) wird mittels Notify ein Befehl abgefeuert:
set Rollo_1 auf,set Rollo_2 auf, etc.Viele Grüße
Arthur
@andre: es hat sicher etwas mit dem message-verkehr zu tun. HMLAN hat hier ein nicht zu vernachlässigendes eigenleben. Ein device muss seine Nachrichten wiederholen und damit Probleme bei Kollisionen beheben.
@Arthur: Der Zeitpunkt ist eher nicht das Problem, es sollte wohl jedes andere Notify auch machen, es sei denn um 8:00 geht in deine Installation noch mehr ab.
Ich werde einmal mit meinen Rollos testen.
Gruss
Martin
Hallo Martin,
also heute sind Rollos alle auf gegangen. :o(
Ferner habe ich gestern ca. 20-30x rauf und runter fahren lassen - bisher habe ich das Problem nicht reproduzieren können.
Morgens passiert eigentlich wenig, MDIRs sind zu dem Zeitpunkt nicht aktiv, im Hintergrund laufen nur die CC-TCs - es kann natürlich sein, dass genau zum gleichen Zeitpunkt einer von denen, sein Status schicken möchte.
Schade ich habe das entsprechende Log (RAW) die Tage gelöscht *grrr.
Also weiter warten...
Gruß
Arthur
@martin: das beheben der probleme durch kollisionen ist aber nicht so zuverlässig das man es einfach vernachlässigen kann und es sind ja auch nur 3 retries. ein reproduzierbares beispiel ist den rolladen per fenstergriff zu steuern. da sind dann 3 oder 4 nachrichten plus die acks pro rolladen unterwegs. das problem hatte ich schon mit dem cul alleine. ich glaube mit dem zusätzlichen hmlan ist es nicht schlimmer geworden. beim fenstergriff gibt es ja auch extra die möglichkeit das senden des status nach dem betätigen zu verzögern. ich habe es noch nicht probiert aber ich vermute es soll genau den fall abdecken das von zu über offen auf gekippt gedreht wird und nur ein einziger status übertragen werden soll.
gruss
andre
@Andre
Zitatsind ja auch nur 3 retries.
von HMLAN sind es 3. FHEM macht noch einmal 3,ergibt 9.Die werden zeitverzoegert mit randon delay 1-5sec gestartet um bursts zu entzerren.
Zitatein reproduzierbares beispiel ist den rolladen per fenstergriff zu steuern. da sind dann 3 oder 4 nachrichten plus die acks pro rolladen unterwegs.
falls es direkt gepeert ist sollte es funktionieren
Zitatdas problem hatte ich schon mit dem cul alleine.
hier geht es um HMLAN. Von der CUL kenne ich dieses Problem nicht. Das funktioniert dann im MicroKosmos nicht wie HMLAN. Da muss man das timing komplett anders untersuchen!
Zitatbeim fenstergriff gibt es ja auch extra die möglichkeit das senden des status nach dem betätigen zu verzögern.
warum das so ist? Das ist nicht das ACK! Es ist nur die Statusmeldung. Ich denke einer der Gruende ist ein ent-jittern undent-spiken zu erreichen. Erst wenn der Status stabil ist kommt eine Nachricht. Schön zu sehen bei dimmern, die senden eine Info immer erst wenn alles eineZeit stabil ist. Die ACK kommt immer gleich!, muss auch.
Zitatich habe es noch nicht probiert aber ich vermute es soll genau den fall abdecken das von zu über offen auf gekippt gedreht wird und nur ein einziger status übertragen werden soll.
sehe ich auch so. Machen auch die Dimmer aehnlich....
Gruss
Martin
Hi Arthur,
ich habe einmal eine testbench mit 4 Rollos aufgebaut. Kannst du evtl einfach nachbauen
define td1 dummy
define td2 dummy
define tn1 notify td1 set Rollo1 up 10;;set Rollo2 up 10;;set Rollo3 up 10;;set Rollo4 up 10
define tn2 notify td2 set Rollo1 down 10;;set Rollo2 down 10;;set Rollo3 down 10;;set Rollo4 down 10
und dann mit
set td1 # alles 10% runter
set td1 # alles 10% hoch
Prüfen geht am Schnellsten, wenn du ein 98_HMinfo nimmst, ich habe die aktuelle Version angehängt.
define hm HMinfo
set hm param -f ^Rollo.* state
geht auch im browser, dann immer refresh...
Ich hatte bei 20 Tests 2 wiederholer, keinen Hänger.
Wenn du ein setup hast in dem es hängen bleibt, schicke es doch
Gruss
Martin
Hallo Martin,
probiere ich nachher aus (HMInfo habe ich auch schon im Einsatz ;o)).
Mein Konstrukt sieht wie folgt aus:.
define Rollo_Auto dummy
attr Rollo_Auto group Dummys
attr Rollo_Auto webCmd auf:stop:zu
define vaRollo_auf notify Rollo_Auto:auf {if (Value('Rollo_Auto') eq "auf") {fhem ("set Rollo1 auf;;set Rollo2 auf;;set Rollo3 auf;;set Rollo4 auf";;}Log 1, "Ja, ausgeführt...";;}
define vaRollo_stop notify Rollo_Auto:stop {if (Value('Rollo_Auto') eq "stop") {fhem ("set Rollo1 stop;;set Rollo2 stop;;set Rollo3 stop;;set Rollo4 stop");;}Log 1, "Ja, ausgeführt...";;}
define vaRollo_zu notify Rollo_Auto:zu {if (Value('Rollo_Auto') eq "zu") {fhem ("set Rollo1 zu;;set Rollo2 zu;;set Rollo3 zu;;set Rollo4 zu");;}Log 1, "Ja, ausgeführt...";;}
Viele Grüße
Arthur
Hallo Martin,
HMinfo habe ich nun eingerichtet - testen kann ich aber erst Morgen.
Infos folgen.
Viele Grüße
Arthur
Hallo Martin,
ich bin mir nicht sicher ob ich was gefangen habe.
param done:
param list
KU_Rollladen : MISSING ACK
SZ_Rollladen : 90 %
WZ_Rollladen_Strasse: 90 %
WZ_Rollladen_Terrasse: 90 %
Raw Messages:
2013.03.30 09:09:21 4: HTTP FHEMWEB:1.2.3.4:61039 GET /fhem?cmd=set+td2+*
2013.03.30 09:09:21 5: Cmd: >set td2 *<
2013.03.30 09:09:21 4: dummy set td2 *
2013.03.30 09:09:21 5: Triggering td2 (1 changes)
2013.03.30 09:09:21 5: Notify loop for td2 *
2013.03.30 09:09:21 5: Triggering tn2
2013.03.30 09:09:21 5: Cmd: >set WZ_Rollladen_Strasse down 10<
2013.03.30 09:09:21 5: Triggering WZ_Rollladen_Strasse (1 changes)
2013.03.30 09:09:21 5: Notify loop for WZ_Rollladen_Strasse set_down 10
2013.03.30 09:09:21 2: CUL_HM set WZ_Rollladen_Strasse down 10 rxt:1
2013.03.30 09:09:21 5: HMLAN_Send: SBA57FE8F,00,00000000,01,BA57FE8F,BAA0111234561AE5DC0201B403207FF0
2013.03.30 09:09:21 5: Cmd: >set WZ_Rollladen_Terrasse down 10<
2013.03.30 09:09:21 5: Triggering WZ_Rollladen_Terrasse (1 changes)
2013.03.30 09:09:21 5: Notify loop for WZ_Rollladen_Terrasse set_down 10
2013.03.30 09:09:21 2: CUL_HM set WZ_Rollladen_Terrasse down 10 rxt:1
2013.03.30 09:09:21 5: HMLAN_Send: SBA57FEDD,00,00000000,01,BA57FEDD,BBA0111234561B81FE0201B403207FF0
2013.03.30 09:09:21 5: Cmd: >set KU_Rollladen down 10<
2013.03.30 09:09:21 5: Triggering KU_Rollladen (1 changes)
2013.03.30 09:09:21 5: Notify loop for KU_Rollladen set_down 10
2013.03.30 09:09:21 2: CUL_HM set KU_Rollladen down 10 rxt:1
2013.03.30 09:09:21 5: HMLAN_Send: SBA57FF2A,00,00000000,01,BA57FF2A,BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:21 5: Cmd: >set SZ_Rollladen down 10<
2013.03.30 09:09:21 5: Triggering SZ_Rollladen (1 changes)
2013.03.30 09:09:21 5: Notify loop for SZ_Rollladen set_down 10
2013.03.30 09:09:21 2: CUL_HM set SZ_Rollladen down 10 rxt:1
2013.03.30 09:09:21 5: HMLAN_Send: SBA57FF76,00,00000000,01,BA57FF76,BDA0111234561B5CD40201B403207FF0
2013.03.30 09:09:21 4: HTTP FHEMWEB:1.2.3.4:61042 GET /fhem
2013.03.30 09:09:21 4: /fhem / RL: 1083 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2013.03.30 09:09:21 5: HMLAN/RAW: /RBA57FE8F,0001,0CE2662B,FF,FFC1,BA80021AE5DC1234560101C5203E
2013.03.30 09:09:21 5: HMLAN_Parse: HMLANAMA S:RBA57FE8F stat:0001 t:0CE2662B d:FF r:FFC1 m:BA80021AE5DC1234560101C5203E
2013.03.30 09:09:21 5: HMLANAMA dispatch A0EBA80021AE5DC1234560101C5203E::-63:HMLANAMA
2013.03.30 09:09:21 5: Triggering WZ_Rollladen_Strasse (3 changes)
2013.03.30 09:09:21 5: Notify loop for WZ_Rollladen_Strasse deviceMsg: 98.5 % (to HMLANAMA)
2013.03.30 09:09:22 4: Connection accepted from FHEMWEB:1.2.3.4:61046
2013.03.30 09:09:22 5: HMLAN/RAW: /RBA57FEDD,0001,0CE26679,FF,FFCE,BB80021B81FE1234560101C6204E
RBA57FF2A,0008,00000000,FF,7FFF,BCA0111234561B5CB60201B403207FF0
RBA57FF76,0001,0CE267DA,FF,FFB3,BD80021B5CD41234560101C22047
2013.03.30 09:09:22 5: HMLAN_Parse: HMLANAMA S:RBA57FEDD stat:0001 t:0CE26679 d:FF r:FFCE m:BB80021B81FE1234560101C6204E
2013.03.30 09:09:22 5: HMLANAMA dispatch A0EBB80021B81FE1234560101C6204E::-50:HMLANAMA
2013.03.30 09:09:22 5: Triggering WZ_Rollladen_Terrasse (3 changes)
2013.03.30 09:09:22 5: Notify loop for WZ_Rollladen_Terrasse deviceMsg: 99 % (to HMLANAMA)
2013.03.30 09:09:22 5: HMLAN_Parse: HMLANAMA S:RBA57FF2A stat:0008 t:00000000 d:FF r:7FFF m:BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:22 5: HMLAN_Parse: discard
2013.03.30 09:09:22 5: HMLAN_Parse: HMLANAMA S:RBA57FF76 stat:0001 t:0CE267DA d:FF r:FFB3 m:BD80021B5CD41234560101C22047
2013.03.30 09:09:22 5: HMLANAMA dispatch A0EBD80021B5CD41234560101C22047::-77:HMLANAMA
2013.03.30 09:09:22 5: Triggering SZ_Rollladen (3 changes)
2013.03.30 09:09:22 5: Notify loop for SZ_Rollladen deviceMsg: 97 % (to HMLANAMA)
2013.03.30 09:09:23 4: Connection accepted from FHEMWEB:1.2.3.4:61047
2013.03.30 09:09:23 4: HTTP FHEMWEB:1.2.3.4:61039 GET /fhem/js/fhemweb.js
2013.03.30 09:09:23 4: HTTP FHEMWEB:1.2.3.4:61044 GET /fhem/js/svg.js
2013.03.30 09:09:23 4: HTTP FHEMWEB:1.2.3.4:61042 GET /fhem/css/style.css
2013.03.30 09:09:23 4: HTTP FHEMWEB:1.2.3.4:61046 GET /fhem/icons/favicon
2013.03.30 09:09:23 4: HTTP FHEMWEB:1.2.3.4:61042 GET /fhem/icons/icoEverything
2013.03.30 09:09:23 4: HTTP FHEMWEB:1.2.3.4:61042 GET /fhem?room=all&XHR=1&inform=1
2013.03.30 09:09:23 5: HMLAN_Send: SBA580700,00,00000000,01,BA580700,BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:23 4: CUL_HM_Resend: KU_Rollladen nr 2
2013.03.30 09:09:24 5: HMLAN/RAW: /RBA580700,0008,00000000,FF,7FFF,BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:24 5: HMLAN_Parse: HMLANAMA S:RBA580700 stat:0008 t:00000000 d:FF r:7FFF m:BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:24 5: HMLAN_Parse: discard
2013.03.30 09:09:25 5: HMLAN/RAW: /E1AE5DC,0000,0CE273AD,FF,FFC5,BBA4101AE5DC1234560601B400
2013.03.30 09:09:25 5: HMLAN_Parse: HMLANAMA S:E1AE5DC stat:0000 t:0CE273AD d:FF r:FFC5 m:BBA4101AE5DC1234560601B400
2013.03.30 09:09:25 5: HMLAN: manual ACK
2013.03.30 09:09:25 5: HMLAN: Skip ACK
2013.03.30 09:09:25 5: HMLANAMA dispatch A0DBBA4101AE5DC1234560601B400::-59:HMLANAMA
2013.03.30 09:09:25 5: HMLAN: Skip ACK
2013.03.30 09:09:25 5: Triggering WZ_Rollladen_Strasse (3 changes)
2013.03.30 09:09:25 5: Notify loop for WZ_Rollladen_Strasse deviceMsg: 90 % (to HMLANAMA)
2013.03.30 09:09:26 5: HMLAN/RAW: /E1B81FE,0000,0CE27861,FF,FFCB,BCA4101B81FE1234560601B400
2013.03.30 09:09:26 5: HMLAN_Parse: HMLANAMA S:E1B81FE stat:0000 t:0CE27861 d:FF r:FFCB m:BCA4101B81FE1234560601B400
2013.03.30 09:09:26 5: HMLAN: manual ACK
2013.03.30 09:09:26 5: HMLAN: Skip ACK
2013.03.30 09:09:26 5: HMLANAMA dispatch A0DBCA4101B81FE1234560601B400::-53:HMLANAMA
2013.03.30 09:09:26 5: HMLAN: Skip ACK
2013.03.30 09:09:26 5: Triggering WZ_Rollladen_Terrasse (3 changes)
2013.03.30 09:09:26 5: Notify loop for WZ_Rollladen_Terrasse deviceMsg: 90 % (to HMLANAMA)
2013.03.30 09:09:26 5: HMLAN/RAW: /E1B5CD4,0000,0CE278FA,FF,FFB4,BEA4101B5CD41234560601B400
2013.03.30 09:09:26 5: HMLAN_Parse: HMLANAMA S:E1B5CD4 stat:0000 t:0CE278FA d:FF r:FFB4 m:BEA4101B5CD41234560601B400
2013.03.30 09:09:26 5: HMLAN: manual ACK
2013.03.30 09:09:26 5: HMLAN: Skip ACK
2013.03.30 09:09:26 5: HMLANAMA dispatch A0DBEA4101B5CD41234560601B400::-76:HMLANAMA
2013.03.30 09:09:26 5: HMLAN: Skip ACK
2013.03.30 09:09:26 5: Triggering SZ_Rollladen (3 changes)
2013.03.30 09:09:26 5: Notify loop for SZ_Rollladen deviceMsg: 90 % (to HMLANAMA)
2013.03.30 09:09:27 4: Connection closed for FHEMWEB:1.2.3.4:61047
2013.03.30 09:09:28 5: HMLAN_Send: SBA58189D,00,00000000,01,BA58189D,BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:28 4: CUL_HM_Resend: KU_Rollladen nr 3
2013.03.30 09:09:28 5: HMLAN/RAW: /RBA58189D,0008,00000000,FF,7FFF,BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:28 5: HMLAN_Parse: HMLANAMA S:RBA58189D stat:0008 t:00000000 d:FF r:7FFF m:BCA0111234561B5CB60201B403207FF0
2013.03.30 09:09:28 5: HMLAN_Parse: discard
2013.03.30 09:09:29 4: Connection closed for FHEMWEB:1.2.3.4:61042
2013.03.30 09:09:29 4: HTTP FHEMWEB:1.2.3.4:61039 GET /fhem?cmd=set+HM+param+-f+.*Rolll.*+state
2013.03.30 09:09:29 5: Cmd: >set HM param -f .*Rolll.* state<
2013.03.30 09:09:29 4: /fhem?cmd=set+HM+param+-f+.*Rolll.*+state / RL: 1021 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2013.03.30 09:09:30 4: Connection accepted from FHEMWEB:1.2.3.4:61048
2013.03.30 09:09:30 4: HTTP FHEMWEB:1.2.3.4:61046 GET /fhem/js/fhemweb.js
2013.03.30 09:09:30 4: HTTP FHEMWEB:1.2.3.4:61039 GET /fhem/css/style.css
2013.03.30 09:09:30 4: HTTP FHEMWEB:1.2.3.4:61044 GET /fhem/js/svg.js
2013.03.30 09:09:30 4: Connection accepted from FHEMWEB:1.2.3.4:61049
2013.03.30 09:09:30 4: HTTP FHEMWEB:1.2.3.4:61048 GET /fhem/icons/favicon
2013.03.30 09:09:30 4: HTTP FHEMWEB:1.2.3.4:61039 GET /fhem/icons/icoEverything
2013.03.30 09:09:30 4: HTTP FHEMWEB:1.2.3.4:61039 GET /fhem?room=all&XHR=1&inform=1
2013.03.30 09:09:31 5: HMLAN/RAW: /E1B0D69,0000,0CE28BD9,FF,FFCC,A584101B0D6912345606019E00
2013.03.30 09:09:31 5: HMLAN_Parse: HMLANAMA S:E1B0D69 stat:0000 t:0CE28BD9 d:FF r:FFCC m:A584101B0D6912345606019E00
2013.03.30 09:09:31 5: HMLANAMA dispatch A0DA584101B0D6912345606019E00::-52:HMLANAMA
2013.03.30 09:09:31 5: HMLAN_Send: SBA5825BD,00,00000000,01,BA5825BD,A580021234561B0D6901019E00
2013.03.30 09:09:31 5: Triggering WZ_Bewegungsmelder (3 changes)
2013.03.30 09:09:31 5: Notify loop for WZ_Bewegungsmelder brightness: 158
2013.03.30 09:09:31 5: Triggering EMail_Batteriewarnung
......
2013.03.30 09:09:31 5: HMLAN/RAW: /RBA5825BD,0002,00000000,FF,7FFF,A580021234561B0D6901019E00
2013.03.30 09:09:31 5: HMLAN_Parse: HMLANAMA S:RBA5825BD stat:0002 t:00000000 d:FF r:7FFF m:A580021234561B0D6901019E00
2013.03.30 09:09:31 5: HMLAN_Parse: discard
2013.03.30 09:09:32 5: Triggering KU_Rollladen (1 changes)
2013.03.30 09:09:32 5: Notify loop for KU_Rollladen MISSING ACK
2013.03.30 09:09:32 5: HMLAN_Send: K
2013.03.30 09:09:32 5: HMLAN/RAW: /HHM-LAN-IF,03C1,J123456789,1ACA40,123456,0CE29045,0009
2013.03.30 09:09:32 5: HMLAN_Parse: HMLANAMA V:03C1 sNo:J123456789 d:1ACA40 O:123456 m:0CE29045 IDcnt:0009
2013.03.30 09:09:35 4: Connection closed for FHEMWEB:1.2.3.4:61049
2013.03.30 09:09:37 4: Connection closed for FHEMWEB:1.2.3.4:61039
2013.03.30 09:09:37 4: HTTP FHEMWEB:1.2.3.4:61046 GET /fhem?cmd=set+HM+param+-f+.*Rolll.*+state
2013.03.30 09:09:37 5: Cmd: >set HM param -f .*Rolll.* state<
2013.03.30 09:09:37 4: /fhem?cmd=set+HM+param+-f+.*Rolll.*+state / RL: 1024 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
Hinweis: Nach einen erneuten Trigger "zu" und wieder "auf" auf den "KU_Rollladen" hat dieser ohne Probleme funktioniert.
Viele Grüße
Arthur
Hi Arthur,
Der Rollo hat kein Ack geschickt,jedenfalls wurde keins von HMLAN gemeldet.
Es wurde aber eine Statusmeldung empfangen. es sollte also funktioniert haben.
Gruss
Martin
Hallo Martin,
hmm Rollo stand aber bei 100% also "auf" und nicht bei 90% wie alle anderen :o( => Rollo hat nicht reagiert ;o) = Realität.
Habes es heute ca. 10-15 rauf und runter fahren lassen also, 10% runter 10% rauf, dabei ist dieses Problem aufgetreten - hätte ja sein können, dass es was verwertbares gewesen ist - wenn HMLAN meldet "alles ok" dann kann man FHEM Seitig sicher auch nicht mehr viel machen.
Warten wir mal ab, ob es bei den täglichen "notify's" auftritt.
Viele Grüße
Arthur
Edit: Wir sind jetzt aber nicht dabei HMLAN Probleme mit FHEM zu lösen oder?
Hi,
Das Problem mit dem fehlenden ACK beim gleichzeitigen Senden vieler Befhele trat bei mir beim schrittweisen Einbinden vieler Rollladenaktoren beim 6. auf. Ich sende per structure die Befehle auf einen Schlag
Funkprobleme sind unwahrscheinlich.
Christian
Hallo Christian,
Das senden auf einen Schlag soll (muss) funktionieren - FHEM muss die notwendigen Schritte bedienen. Es gibt natuerlich Grenzen... aber 6 devices und derTrigger von FHEM will ich schon noch schaffen
Ich habe (leider) nur eine begrenzte Anzahl an Devices.
Du benutzt HMLAN?
Kannst du testen mit
attr global verbose 1
attr global mseglog 1
attr <hmlan> loglevel 1
und dann tests wie vor beschrieben - oder wie auch immer du es starten willst.
Mittlerweile gab es ja einige veraenderungen, ich hoffe es waren alles Verbesserungen ;-)
Gruss
Martin
Hi. Martin,
will ich gerne checken, allerdings muss ich die nächsten Tage erstmal arbeiten und melde mich dann wieder.
Christian
Hi Zusammen,
ich habe einen neuen Ansatz bei 00_HMLAN und der Zeitsteuerung.
Es reagiert auf rückgabeWerte des HMLAN und verbessert hoffentlich das Verhalten.
Wenn jemand testen will, siehe Anhang.
Ist eine Beta-version!!!
Bitte um Rückmeldungen
Gruss
Martin
Hallo Martin,
ok, bei mir läuft die Version nun - mal schauen.
Bisher ist das Problem nicht mehr aufgetretten - liegt auch vermutlich daran, dass ich noch zu viel rumschraube.
Viele Grüße
Arthur
Hi,
hier eine verbesserte Version. Könnte sein, dass die vorher hängen bleibt. Hier habe ich einen timeout für das Delay eingebaut.
Verbessert hat sich beispielsweise das Auslesen 'komplexer' Devices, beispielsweise einer RC12/RC19 mit vielen Kanälen. Hier konnte es zu Problemen kommen, evtl auch zu einer Überlast am HMLAN.
Nachdem der Ablauf jetzt interaktiv ist, also auf Rückmeldung des HMLAN wartet könnten sich auch sonstige Abläufe verbessern, wenn viel gesendet werden muss
Soweit der Hintergrund.
Gruss
Martin
Hallo Martin,
ok, RC12/19 habe ich zwar nicht aber Verbeserungen sind immer gut ;o)
Die aktuelle Version läuft nun bei mir...
Viele Grüße
Arthur
Hallo,
ich habe eine größere Anzahl Rolladenaktoren und steuere diese über HMLAN. Vor dem Update von Martin Anfang des Jahres haben diese teilweise Befehle nicht ausgeführt, obwohl sie diese laut Logfile scheinbar empfangen haben. Das scheint jetzt wohl ok zu sein.
Seit der Aufrüstung auf mittlerweile 10 Aktoren, habe ich allerdings öfter das Problem, dass die Rolladen zwar den Befehl ausführen, aber die Statusrückmeldung nicht empfangen wird. D.h. der Status steht weiter bei "motor: down:99 %" obwohl er längst zu ist. Ein "statusRequest" aktualisiert den Zustand dann sofort und richtig.
2013-04-07_20:12:55 WZ_Rolladen set_off
2013-04-07_20:12:55 WZ_Rolladen deviceMsg: 99 % (to HMLAN1)
2013-04-07_20:12:55 WZ_Rolladen motor: down:99 %
2013-04-07_20:12:55 WZ_Rolladen 99 %
... statusRequest und dann
2013-04-07_20:20:54 WZ_Rolladen deviceMsg: off (to HMLAN1)
2013-04-07_20:20:54 WZ_Rolladen motor: stop:off
2013-04-07_20:20:54 WZ_Rolladen off
Gut, das könnte natürlich prinzipiell auf Funkprobleme hindeuten, tritt aber bei verschiedenen Aktoren auf und wäre dann schon sehr ärgerlich.
Gibt es vielleicht noch eine andere Lösungsmöglichkeit? Ich habe den Eindruck, dass sich da die Rückmeldungen mehrerer Aktoren überlagern. Vielleicht die Rolläden leicht verzögert nacheinander starten?
Im schlimmsten Falle würde natürlich ein pollen über " at ... statusRequest" helfen
Gruß
Georg
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?
Der Ablauf sollte klar sein:
Schalten von FHEM -> FHEM erhaelt ein "ack":Befehl erhalten, aktueller Status x%
Wenn der Aktor zur Ruhe gekommen ist sendet er einen Status an die Zentrale (wenn gepairt...) und will von der ein ack. Wird, wenn korrekt eingestellt vom Blind 3-mal wiederholt.
wenn du einen HM-LC-Bl1PBU-FM hast kannst du das Senden der status-message einstellen
transmitTryMax =>{min=>1 ,max=>10 t=>"max message re-transmit"
statusInfoMinDly=>{min=>0.5,max=>15.5 t=>"status message min delay"
statusInfoRandom=>{min=>0 ,max=>7 t=>"status message random delay"
Also Scenario und logs waeren gut. Gerne mit neuen HMLAN. Nach etwas tuning wird es wohl kommen
Gruss
Martin
Hallo Martin,
bei den letzten 3 Schaltvorgängen hat alles fehlerfrei funktioniert. Seltsam. Werde es weiter beobachten.
Und ja, ich habe HM-LC-Bl1PBU-FMs.
Gruß
Georg
Hallo,
ok, einstellen kann ich "transmitTryMax", etc. über "setReg". Aber wie kann ich den aktuell eingestellten Wert lesen? In "getConfig" sind sie nicht enthalten.
Gruß
Georg
Hi,
hast du eine FW version kleiner gleich 2.1? Da gibt es diese Register noch nicht. FW Versionen unterschiede ich nicht....
Diese Einstellmoeglichkeiten gibt es dann nicht.
Zum Verhalten von FHEM:
- in der regList sind alle register der neusten FW enthalten, keine FW Unterscheidung.
- das Device schickt nur Register, die auch mindestens einen Inhalt haben
- FHEM zeigt nur Werte an, wenn das Device auch das entsprechende Register geliefert hat.
Sorry, geht bei dir nicht
Gruss
Martin
Hi,
ja, FW der HM-LC-Bl1PBU-FM ist 2.1.
Gibt es da schon was neueres? Die Geräte sind nagelneu. Gibt es eine Möglichkeit, die FW upzudaten?
Gruß
Georg
Hi Georg,
hm - mein HM-LC-Bl1PBU-FM hat auch 2.1 :-(
XML unterscheidet <=2.1 und andere. Also ist mindestens eine geplant.
Wir beide koennen es aber nicht einstellen... schade
Gruss
Martin
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
Hallo Martin,
ich würde gerne heute Abend wieder die alte 00_HMLAN.pm (Modifizierte) siehe hier (http://forum.fhem.de/index.php?topic=11942.msg72419#msg72419) 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).
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
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
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)
Zitat von: martinp876 schrieb am Mo, 08 April 2013 08:59Hallo 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?
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
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.
*{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 :)
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
:)
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? :)
Zitatunschö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
ZitatSchön finde ich, das es bei mir so geht.
prima
Zitatdie 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
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
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
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
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
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 :)
Zitatmacht 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.
Zitatich lese auch die anderen Beiträge mit, hab nur nicht immer etwas zu melden :)
denke ich mir, daher der Kommentar ;-)
ich lasse heute abend mal 10 stück über einen Dummy fahren, mehr habe ich nicht
:)