HMLAN disconnected und Messages verloren ?!

[bugster_de]

Hi,

die Rolläden hier sind alle so eingestellt, dass sie um 18:30:00 mit jeweils 2 Sekunden Versatz via at zufahren sollen (also 18:30:00, 18:30:02: 18:30:04, usw)

Ich hatte dieser Tage den Effekt, dass FHEM die Verbindung zum HMLAN genau um 18:29:59 verloren hat und erst ca. 30 Sekunden später wieder aufnahme. Also just in dem Moment, als dfas HMLAN weg war. Ergo blieben die Rolläden oben.

Kann es sein, dass die FHEM MEssages zwischen disappeared und re-appeared des HMLAN dann verloren sind? Und was passiert, wenn genau in so einem Moment ein Fenstersensor einen Einbruch meldet?

[betateilchen]

Das wäre dann unter "dumm gelaufen" zu verbuchen. Der Fensterkontakt schickt seine Meldung ab und bekommt kein ACK. Er wird dies einfach mit rotem Licht signalisieren und das wars. Deshalb sollte man eine Alarmanlage nie mit Funkkontakten ausstatten, wenn man wirklich auf Zuverlässigkeit angewiesen ist.

Zu Deinem Rollladenproblem: Wieviele Rollläden steuerst Du im 2-Sekunden-Takt? Dir ist schon bewusst, dass es eine maximal erlaubte Menge von Funkübertragungen pro Minute gibt?

[martinp876]

interessanter Fall.

Problem 1) FHEM will etwas senden und der HMLAN adapter verschwindet. Es können ein paar messages verloren gehen, wenn sie gerade in Bearbeitung sind. Weiteres Senden wird verzögert.
=> der Fehler ist in proto... Variablen nachzulesen. Einen triggerfähigen output gibt es (noch) nicht.

Problem 2) ein Device will eine Meldung absetzen während HMLAN disconnected ist. Nach meinen Tests speichert der HMLAN die Messages und sendet die nach reconnect. Umklar ist die Speichertiefe. Ausserdem werden Antworten(acks) von FHEM zu spät kommen. Konkrete Probleme sehe ich nicht. Falls der Auslöser natürlich ein Absturz des HMLAN war sind die Meldungen weg.

Prinzipiell sollte man einen "systemAlarm" einbauen auf den man triggern kann. Protokoll Probleme und disconnects sollten dabei erfasst werden. Mal sehen - ich sehe hier HMInfo als möglichkeit.

[bugster_de]

Hi,

also ich steuere im Moment 'nur' 6 Rolläden. Da kommen aber noch 13 Stck. dazu. ich gebe das geld für die weiteren Rolläden aber erst aus, wenn die 6 Stück mal zufrieden stellend laufen :-)
Desweiteren habe ich zwei Homemmatic Temperatur Sensoren sowie 2 Homematic Fensterdrehgriffsensoren im Einsatz. Ansonsten ist auf 868MHz nichts angeschlossen.

Dir ist schon bewusst, dass es eine maximal erlaubte Menge von Funkübertragungen pro Minute gibt?

irgendwie ja. Aber diese Frage hatte ich in einem anderen Fred ja schonmal gestellt. Wieviele sind das dann?

Und genau deshalb versuche ich die einzelnen Devices ja auch mit einem gewissen Zeitversatz zu anzusteuern, um so weit als möglich aus diesen Konflikten raus zu kommen.
Allerdings scheinen nur wir mit FHEM dieses problem zu haben. Ein Arbeitskollege, der 1 büro weiter sitzt hat sein ganzes Haus mit Homematic ausgerüstet. Im prinzip hat der einmal den ELV Katalog bestellt und auch die Hoemmatic Zentrale dazu. Ihm sind solche Probleme völlig unbekannt. Allerdings hat er natürlich auch nicht den Freiheitsgrad, den wir mit FHEM haben.

meine erste Umsetzung der Ansteuerung war wie folgt
set Rolladen off
sleep 0,2
set Rolladen2 off
usw

Da war dann die Anmerkung hier im Forum, dass dies nicht geht, da sleepx FHEM lahmlegt und somit ankommende Messages (ACK) der Aktoren nicht behandelt werden können.

zweiter Versuch war dann.
set Rolladen off
set Rolladen2 off
usw
das führt dann zu missing ack, da wohl einfach zu viel Traffic in der Luft ist und die Messages kollidieren. Wobei ich mir aber nicht vorstellen kann, dass dies im Protokoll von Homematic nicht erkannt und abgefrühstückt wird. Wäre ja ziemlich dämlich, wenn alle Devices einfach mal drauf los senden ohne erst mal zu horchen, was überhaupt in der luft los ist.

Nun mein dritter Versuch der Umsetzung
define myRoll_auto at +00:01:00 set Rolladen off
define myRoll2_auto at +00:01:02 set Rolladen2 off
usw

Sprich zeitversatz von 2 Sekund und Aufruf mittels at, um danach die Kontrolle wieder an FHEM zugeben.

Die MISSING ACK sind momentan weg, aber nun poppt das lustige Problem des verschwundenen HMLAN auf.


In diesem fred: Link, der mittlerweile etwas off-topic ist, wird das asynchrone Verhalten diskutiert.

Deshalb sollte man eine Alarmanlage nie mit Funkkontakten ausstatten

:-) War ja auch nur ein Beispiel. Momentan schaffe ich es ja nicht mal die Rolläden mehr als eine Woche am Stück zuverlässig zu schalten, ohne dass ich Hand anlegen muß. Für eine Alarmanlage wäre mir etwas mehr zuverlässigkeit schon lieb. Und die Alarmanalge soll ja eh nur scharf sein, wenn keiner zu Hause. Und da sind wir noch bei der Baustelle iPhone meiner Frau und Anwesenheitserkennung :-)

[martinp876]

hi bugster_de

Dir ist schon bewusst, dass es eine maximal erlaubte Menge von Funkübertragungen pro Minute gibt?

irgendwie ja. Aber diese Frage hatte ich in einem anderen Fred ja schonmal gestellt. Wieviele sind das dann?

eigentlich ist dies nicht Aufgabe des Users sondern von FHEM. Ich habe nach besten Erkenntnissen verzögerungen und repeats eingebaut. Falls jemand belastbare Infos hat über maximale msg/sec in irgendeiner Form sollten wir dies einbauen.
Eine Beschränkung aufgrund der Übertragungsgeschwindigkeit ist eh klar - was kennt ihr noch?

zweiter Versuch war dann.
set Rolladen off
set Rolladen2 off
usw
das führt dann zu missing ack, da wohl einfach zu viel Traffic in der Luft ist und die Messages kollidieren. Wobei ich mir aber nicht vorstellen kann, dass dies im Protokoll von Homematic nicht erkannt und abgefrühstückt wird. Wäre ja ziemlich dämlich, wenn alle Devices einfach mal drauf los senden ohne erst mal zu horchen, was überhaupt in der luft los ist.

doch, so ist es wohl. sonst wären die ACKs alle da. Aber hast du wirklich ein Problem? Wenn es ein missing ACK gibt wieder holt FHEM. Missing ACKs sind nicht weiter schlimm - wirkliche Probleme gibt es erste, wenn protoResendFail gezählt wird.
Wo sind die Beispiele deiner Rollos? und sind sie nicht gefahren oder hast du "nur" missing Ack?

wäre cool einmal bei deinem Kollegen in der Luft zu sniffen, wenn er 20Rollos am Stück runterfahren lässt :) wie schnell fahren die an?...

Gruss Martin

[betateilchen]

meine erste Umsetzung der Ansteuerung war wie folgt
set Rolladen off
sleep 0,2
set Rolladen2 off
usw

Da war dann die Anmerkung hier im Forum, dass dies nicht geht, da sleepx FHEM lahmlegt und somit ankommende Messages (ACK) der Aktoren nicht behandelt werden können.

Deshalb würde ich sowas immer mit select() machen.

Code Auswählen Erweitern


set Rolladen off
select(undef, undef, undef, 2);
set Rolladen2 off


Und ich würde die Abstände größer als 2 Sekunden wählen (vermutlich würde ich 10 Sekunden nehmen, aber bei mir gibt es gar keine Rollläden) Außerdem würde ich mit at arbeiten und nicht alle Rollläden in einem einzigen Aufruf abhandeln.

[betateilchen]

interessanter Fall.
Problem 1)

Problem 2)

Problem 3) HMLAN verschwindet komplett, weil er gerade neu bootet (beispielsweise per Parameter -r im hmland) oder Stromausfall war.

[martinp876]

was geht bei Problem3 verloren?
ok, bei Stromausfall ist mehr hin. Da muss man komplett neu aufsetzen. Welchen Stronkreis hat es erwischt?
Aber bei ethernet-disconnect sollte es weitgehend klappen , wie beschrieben.

[bugster_de]

Deshalb würde ich sowas immer mit select() machen.

und das bringt was genau? Ist ja eigentlich auch egal, da ich ja nun auf at umgestellt habe

Und ich würde die Abstände größer als 2 Sekunden wählen

naja, das bedeutet dann bei 19 Rolläden eine ordentliche Fahrzeit und Geräuschkulisse. Denn die Rolläden fahren ca. 30 Sek. um komplett zu schliessen. Während dieser Zeit senden sie auch ihre jeweils aktuelle Position, sprich es gibt Traffic in der Luft. Um dem also komplett aus dem Weg zu gehen, müsste der Abstand pro Rolladen größer 30 Sekunden sein. Bei 19 Rolläden sind das dann mal schlanke 9:30h. Der WAF wird da nicht hoch sein :-)
Und während dieser Zeit darf dann auch kein HM Sender irgendwas funken.

Außerdem würde ich mit at arbeiten und nicht alle Rollläden in einem einzigen Aufruf abhandeln

genau so mache ich das doch. Ein at pro Rolladen.

Ich bin aber überzeugt davon, dass dies alles nur dem Kurieren der Symptome dient. Der Hase liegt irgendwo anders im FHEM-Pfeffer. Wie gesagt ist die Homematic Installation meines Kollegen deutlich umfangreicher und rennt seit Monaten einfach durch. Irgendwas geht da in den unteren Schichten von FHEM schief. Leider habe ich keine Ahnung, wo anfangen mit suchen.

Und gerade wo ich dies hier schreibe habe ich wieder einen MISSING ACK auf einem Rolladen. Hat ja auch ganze 5 Tage funktioniert :-(

[Dirk]

Man kann doch alle bzw. eine Gruppe von Rolladenaktoren direkt mit einer Fernbedienung, also auch der virtuellen Peeren.
Dann sollte z.B. ein "set vitualButton01 press_short" alle Aktoren bzw. alle der Gruppe zeitgleich in Bewegung setzen.
Somit reduziert sich die Funklast hier deutlich. Oder übersehe ich hier was?

Gruß
Dirk

[bugster_de]

Hi,

keine Ahnung ob Du was übersiehst. Ich kenne die virtuellen Fernbedienungen nicht. Wie geht das?

[Dirk]

Aus der Commandref:

Code Auswählen Erweitern


define vRemote CUL_HM 100000 # the selected HMid must not be in use
set vRemote virtual 20 # define 20 button remote controll
set vRemote_Btn4 peerChan 0 <actorchannel> # peers Button 4 and 5 to the given channel
set vRemote_Btn4 press


Wenn deine Rolladenaktoren signiert kommunizieren, dann muss die HM-ID oben die selbe ID deines HM-LAN sein. Ansonsten ist die ID frei wählbar.

Jede Taste kannst du dann mit deinen Aktoren deiner Wahl peeren. Genau so wie mit einer echten Fernbedienung.

So kannst du dann an eine Taste auch mehrere Rolladenaktoren peeren, welche dann alle nahezu gleichzeitig losfahren sollten. Bei eingeschalteter Signierung werden die vermutlich nacheinander loslaufen, da jeder Aktor noch seine Challenge gelöst bekommen haben möchte.

Gruß
Dirk

[bugster_de]

Hi,

Danke. Ich hatte die Definition parallel auch gerade gefunden. Sorry.
Das probiere ich gleich mal aus !

Wenn deine Rolladenaktoren signiert kommunizieren,

ich wär ja schon froh, wenn sie mal mehr wie 5 Tage am Stück normal kommunizieren würden ohne MISSING ACK :-) Ich hab das signierte noch nicht eingescahltet.

[bugster_de]

das glaub ich jetzt nicht. Habe den vRemote gepeered und sogar der Rolladen Aktor, der gerade wieder in MISSING ACK stand kann nun angefahren werden. Bisher musste ich da immer mittels Sicherung raus / Sicherung rein für reset sorgen, damit ich mit FHEM überhaupt wieder drauf kam.

Sprich wäre das nun eine intelligente Lösung, für alle Rolläden ein solches Peering zu machen und die Rolläden dann via diesen vRemotes fahren zu lassen? Zumindest bis komplett auf und komplett zu? Set Rolladen01 20 geht ja damit nicht, oder?

[EDIT]
vergiss die Fragen oben. Nun habe ich ja damit die Möglichkeit, mir eine Diagnose Routine in Perl zu machen, die einmal am Tag alle Rolläden auf MISSING ACK checkt und im Fall der Fälle den Rolladen per vRemote wieder ins FHEM Leben ruft. Sprich falls ein MISSING ACK gefunden wird, dann kann ich diesen Rolladen per set vRemote_Btn4 press und set vRemote_Btn5 press einmal runter und wieder hoch fahren lassen und er steht FHEM wieder zur Verfügung.
Hach ich freu mich ja so :-)

[Dirk]

Sprich wäre das nun eine intelligente Lösung, für alle Rolläden ein solches Peering zu machen und die Rolläden dann via diesen vRemotes fahren zu lassen?

Aber nicht jeden einzelnen Rolladen einen Taster zuweisen. Sondern gruppenweise, oder ggf. auch alle. Nur dann bewegen sich alle gleichzeitig. Ansonsten musst du wieder mehrere Befehle absetzen und hättest wieder die Gefahr der Kollision.

Set Rolladen01 20 geht ja damit nicht, oder?

Nicht so direkt. Die virtualRemote arbeitet halt ähnlich wie eine rechte FB. Ich kenne die Register vom Rolladenaktor jetzt nicht. Aber man kann einer gepeerten Taste bestimmt sagen dass dass Rollo auf eine bestimmte Position fahren soll?
Somit müsste man dann pro gewünschter Position auch eine eigene "taste" definieren. Ggf. unterschiedliche Werte für einen kurzen und langen Tastendruck?

Gruß
Dirk

[bugster_de]

das sollte wohl gehen. Ich habe ja nur 2 Positionen, die von zu und auf abweichen: die Nachtstellung (10% kleiner Schlitz) und die Sonnenschutzstellung (25%). Und die sind wieder für alle Rolläden gleich.

[martinp876]

Hi,

habe (wieder einmal) nur quer gelesen.Dennoch ein paar Anmerkungen,sind da einige Themen angesprochen.

virtuelleButtons arbeiten prinzipiel wie andere Buttons auch, sind entsprechend programmierbar im Aktor. Vorteil ist, dass alle Aktoren auf eine message reagieren.

Man kann einen Aktor mit mehreren vRemotes peeren. Und jeder vRemote hat ein long und ein short. So kann man (wenn man die übersicht behält) seine Rollogruppen peeren und dann einstellen:
vRemoteBtn1 short : alle Rollos zu
vRemoteBtn1 long : alle Rollos auf
vRemoteBtn2 short : alle Rollos 10%
vRemoteBtn2 long : alle Rollos 25%

Protokol übersicht kann man mit HMInfo erhalten
set <hmInfo> protoEvents

Eine HM Übersicht sollte man erhalten
set <hmInfo> update # HMdaten werden refreshed

neu eingebaut habe ich, dass man den Update per timer einschalten kann
autoUpdate <hminfo> 00:10 #update hmInfo alle 10 min

ausserdem sind die Ergebnisse in die Readings verschoben und du kannst darauf triggern, also
define hmErrors notify hm:ERR.* wasIchWill

hilft dass?

Einchecken klappt gerade nicht... das mit dem notofy muss also warten
Gruss Martin

[bugster_de]

Hi,

so nun habe ich mal die Abwesenheit meiner beiden Damen für eine Nacht-Seance am Computer genutzt :-)

wenn man die übersicht behält

das ist tasächlich nicht ganz einfach, da auch mein Perl Code mittlwerweile recht umfangreich wird. Also habe ich mal eine meiner S100 unter Debian 7 aufgesetzt. Darauf läuft jetzt:
- Subversion Server: um die verschiedenen "Entwicklungsstände" zu revisionieren. Auf den verschiedenen PCs dann Tortoise-SVN
- Wikimedia: ein privates Wiki, um die verschiedenen Sachen, Tricks, Kniffe und Weblinks zu verwalten
- FHEM Playground: eine FHEM Installation, mit der ich mal rumspielen kann, ohne gleich das live System auf der FB zu zerschiessen. Diese Installation kann natürlich nicht auf die echten Devices zugreifen, da der CUL433 und der RFXTRX an der FB hängt. Theoretisch müsste der HMLAN zwar gehen, habe ich aber nicht versucht

Einziger Schachpunkt an dem Setup ist TortoiseSVN. Wenn mal was nicht funktioniert, dann helfen einem die tollen kryptischen Fehlermeldungen mal genau gar nicht weiter.


nicht für FHEM relevant aber auch ein nettes Spielzeug:
- SAMBA um mein billig-NAS ggf. mal abzulösen
- Apache: einfach mal so, um rumzuspielen
- Logitech Media-Server: als Server für die verschiedenen SB Devices im Haus

noch zu tun:
- Streaming Server für DVB-C Signal, um dann Fernsehen via iPAD schauen zu können

[bugster_de]

Hi,

so, nun hatte ich heute Nacht folgenden, interessanten Effekt.

Setup:
ROLL_01 ist ein Homematic Rolladen
dieser ist mit den BTN_05 (hoch) und BTN_06 (runter) gepeert

Zeitlicher Ablauf
16:00h: Befehl set ROLL_01 25 per FHEM
16:01h: ROLL_01 geht auf MISSING ACK und Rolladen bewegt sich nicht
16:02h: mittels FHEM Oberfläche BTN_05 short_press --> ROLL_01 fährt nach unten
16:03h: mittels FHEM Oberfläche BTN_06 short_press --> ROLL_01 fährt nach oben
kein MISSING ACK und alles gut
18:30h: ROLL_01 fährt auf Grund FHEM Automatik in die Nachtstellung. In Perl fhem( "set ROLL_01 off" );
heute nacht fährt dann auf einmal der Rolladen in die 25% Position. Sprich irgendwann heute Nacht hat FHEM den verlorenen Befehl set ROLL_01 25 abgearbeitet.

Sorry, ich habe gerade kein Logfile hier, da mir der Vorgang erst im Auto auf dem Weg zur Arbeit spanisch vorkam.

Der ROLL_01 ist im Zimmer meiner kleinen Tochter. Ergo war sie natürlich wach, hat geheult und meine Frau war nicht so gutlaunig :-)

Wie kann das sein?

Und wie kann ich das verhindern?
ich würde gerne abends folgendes machen:
- Rolladen in die Schlafstellung bringen
- überprüfen ob der Rolladen in dieser Stellung ist oder ob MISSING ACK
- die Pipeline der FHEM Befehlen dann leeren (kann auch vor dem ersten Punkt sein)

[martinp876]

Hi,

das mit dem verzögerten Befehl verstehe ich nicht. Muss ich einmal überlegen, wie das sein kann (darf nicht)

Und wie kann ich das verhindern?
ich würde gerne abends folgendes machen:
- Rolladen in die Schlafstellung bringen

sollte klar sein

- überprüfen ob der Rolladen in dieser Stellung ist oder ob MISSING ACK

von Hand oder automatisch?
von hand gibt es HMInfo:
define hm HMInfo
set hm param -f <Rollo> level protState


automatisch kannst du die Parameter mit get param abfragen und verarbeiten.
get <Rollo> protState

- die Pipeline der FHEM Befehlen dann leeren (kann auch vor dem ersten Punkt sein)

set <rollo> clear msgEvents

Also zusammenfassend:
set <rollo> clear msgEvents
set <rollo> <nachtlevel>
warten bis gefahren ist
if (<nachtlevel> != get <rollo> param level) => fehler
if (CMDs_done ne <rollo> param protState) => fehler

set <rollo> clear msgEvents # wenn man will


die if's sind freilich nur "schematisch"

Gruss Martin

[bugster_de]

Hi,

Danke für die ausführliche Erklärung, wie ich das flushen der Commandpipeline mache. Werde ich so umsetzen und melde mich im Fall der Fälle.

von Hand oder automatisch?

wie meinst Du das "von Hand" :-) Natürlich automatisch, dafür habe ich FHEM.

Im Ernst: mittlerweile läuft meine Rolladen Automatik so zufriedenstellend, dass wir den Hand Betrieb nur brauchen, wenn mal wieder MISSING ACK an einem Aktor kam. Ansonsten macht das Haus echt alles selbst und sogar offensichtlich so gut, dass meine Frau ihrer besten Freundin ganz stolz erzählt hat, was unser Haus so alles kann.
das bringt natürlich deren Mann in Zugzwang. Er hat schon den ELV Katalog gewälzt :-)
Killerfeatures für meine Frau: die Rolläden machen unter Woche um 8:30h auf. Wenn man aber an der billigen Intertechno fernbedienung den aus Knopf 1x mal drückt, denn verschiebt es sich um 1:00h, bei 2x um 2h usw.
Killerfeature für mich: ich sehe am Logfile, wie lange sie geschlafen hat :-)

[crissiloop]

Hallo Zusammen,

ich steuere meine 12 Rollläden auch gleichzeitig an, was bisher auch gut funktionierte. Aber seit 28.08.13 gibt es teilweise Problem in dieser Form:

Code Auswählen Erweitern

2013-09-03_20:07:03 GWC_Rolladen level: set_1
2013-09-03_20:07:03 GWC_Rolladen set_1
2013-09-03_20:07:03 HWR_Rolladen level: set_1
2013-09-03_20:07:03 HWR_Rolladen set_1
2013-09-03_20:07:03 WZ_Nord_Rolladen level: set_1
2013-09-03_20:07:03 WZ_Nord_Rolladen set_1
2013-09-03_20:07:03 WZ_NordOst_Rolladen level: set_1
2013-09-03_20:07:03 WZ_NordOst_Rolladen set_1
2013-09-03_20:07:03 WZ_SuedOst_Rolladen level: set_1
2013-09-03_20:07:03 WZ_SuedOst_Rolladen set_1
2013-09-03_20:07:03 WZ_Terasse_Rolladen level: set_1
2013-09-03_20:07:03 WZ_Terasse_Rolladen set_1
2013-09-03_20:07:03 K_Rolladen level: set_1
2013-09-03_20:07:03 K_Rolladen set_1
2013-09-03_20:07:03 Bad_Rolladen level: set_1
2013-09-03_20:07:03 Bad_Rolladen set_1
2013-09-03_20:07:03 SZ_Rolladen level: set_45
2013-09-03_20:07:03 SZ_Rolladen set_45
2013-09-03_20:07:03 KZ_Rolladen level: set_1
2013-09-03_20:07:03 KZ_Rolladen set_1
2013-09-03_20:07:03 GZ_Rolladen level: set_1
2013-09-03_20:07:03 GZ_Rolladen set_1
2013-09-03_20:07:04 SZ_Rolladen level: hoch
2013-09-03_20:07:04 SZ_Rolladen deviceMsg: on (to HMLAN1)
2013-09-03_20:07:04 SZ_Rolladen on
2013-09-03_20:07:04 SZ_Rolladen motor: stop:on
2013-09-03_20:07:04 KZ_Rolladen level: hoch
2013-09-03_20:07:04 KZ_Rolladen deviceMsg: on (to HMLAN1)
2013-09-03_20:07:04 KZ_Rolladen on
2013-09-03_20:07:04 KZ_Rolladen motor: stop:on
2013-09-03_20:07:04 HWR_Rolladen level: hoch
2013-09-03_20:07:04 HWR_Rolladen deviceMsg: on (to HMLAN1)
2013-09-03_20:07:04 HWR_Rolladen on
2013-09-03_20:07:04 HWR_Rolladen motor: stop:on
2013-09-03_20:07:10 Bad_Rolladen MISSING ACK
2013-09-03_20:07:11 GWC_Rolladen MISSING ACK
2013-09-03_20:07:11 SZ_Rolladen MISSING ACK
2013-09-03_20:07:11 WZ_Nord_Rolladen MISSING ACK
2013-09-03_20:07:12 WZ_Terasse_Rolladen MISSING ACK
2013-09-03_20:07:13 K_Rolladen MISSING ACK
2013-09-03_20:07:13 WZ_NordOst_Rolladen MISSING ACK
2013-09-03_20:07:13 WZ_SuedOst_Rolladen MISSING ACK
2013-09-03_20:07:13 HWR_Rolladen MISSING ACK
2013-09-03_20:07:13 GZ_Rolladen MISSING ACK
2013-09-03_20:07:15 KZ_Rolladen MISSING ACK
2013-09-03_20:07:18 WZ_SuedOst_Rolladen MISSING ACK
2013-09-03_20:07:19 Bad_Rolladen MISSING ACK
2013-09-03_20:07:20 WZ_NordOst_Rolladen MISSING ACK
2013-09-03_20:07:21 K_Rolladen MISSING ACK
2013-09-03_20:07:21 WZ_Nord_Rolladen MISSING ACK
2013-09-03_20:07:23 WZ_Terasse_Rolladen MISSING ACK
2013-09-03_20:07:24 GWC_Rolladen MISSING ACK
2013-09-03_20:07:25 GZ_Rolladen MISSING ACK

Es wurde aber nichts verändert und wir waren sogar im Urlaub. Am WE ging es dann mal wieder und heute abend trat das Problem wieder auf. Natürlich fuhren die Rollläden nicht und im Status blieb überall set_1 stehen.

Verschluckt sich der HMLAN auf einmal, obwohl es bisher immer ging? Oder woran könnte das liegen?


Gruß Christian

[martinp876]

Hallo Buster, Christian,

wie in
http://forum.fhem.de/index.php?t=msg&goto=93257&rid=251#msg_93257

beschrieben habe ich ein neues Konzept  (jedenfalls einen neuen level der flusskontrolle) vorgesehen. Macht den Transfere stabiler, man kann selbst etwas an Attribut spielen. Jedenfalls habe ich bei massenfragen geschafft, ohne missing-Acks auszukommen.

Zusätzlich werden messages über ein Disconnect gerettet.

Auch dabei: HMInfo
zum einen kann man regelmäsig einen "update" den HMInfo fahren(attr autoUpdate in [hh:mm])

Beim "Update" von HMInfo kann man dann auf die Readings triggern.
Ich will hier leven einbauen: error,warning,info,comment.

so kann man ein notify bauen mit
set xx notify hm:ERR.* blabla

da sollten u.a. auch alle nicht korrigierten Fehler in den Protokollen enthalten sein. Da würde sich eine email lohnen...

gruss Martin