Hallo zusammen,
es gibt ja schon zahlreiche Themen hier im Forum zu ,,MissingAck", aber leider konnte ich meine Fehler nicht beheben.
Das Problem besteht ca. seit dem 10.07.13.
Anfang des Jahres hatte ich eine Beschattungssteuerung integriert und alles funktionierte ohne Fehler (MissingAck).
Am 09.07.13 hatte ich dann das Problem, dass sich 2 Jalousieaktoren verabschiedet haben. Ursache war wahrscheinlich ein driveTurn von 0.
Danach hatte ich alle meine Aktoren auf driveTurn gleich 1 gesetzt und habe zeitgleich von der Fritzbox auf einen RaspberryPI gewechselt. Danach hatte ich ständig E-Mails mit ,,missingAck" (Habe ein notify, welches jedes ,,missingAck" per Mail verschickt).
Jetzt habe ich 2 für mich 3 Ursachen in Betracht gezogen:
1) Wechsel auf PI
2) Wechsel von driveTurn auf 1
3) Aktuelle FHEM-Version (resend?)
Gestern habe ich dann zurück auf die Fritzbox gewechselt, aber leider habe ich immer noch die Emails.
Interessant ist, dass ich teilweise ein MissingAck von Strukturen bekomme.
Des Weiteren habe ich festgestellt, dass ich das Problem nur habe, wenn ich alle Jalousien ansprechen (morgens und abends). Tagsüber, wenn nur eine Hausseite runter oder hochfährt, habe ich das Problem nicht.
Im Anhang habe ich mal das Log von heute Abend.
Hoffe es hat jemand eine Idee.
VG
Marc
hm - wenn ich mir den Ablauf ansehe verstehe ich den nicht.
Es werden jede Mange Rollos "off" gesetzt. Vorab gibt es ein "stop" (das ist 'neu' seit dieser Zeit - als zu untersuchen)
Die Offs werden zwischen 21:11:16 und 12:12:00 gesendet - das dauert 45sec - warum? Das habe ich schon schneller gesehen.
danach kommt eine email
um 21:12:04-07 werden die acks empfangen (4) und die eigentlichen "off" gesendet. 11 weitere ACKs kommen nicht und es wird ein weiteres mal gesendet. - alles in einer sekunde.
um 21:21:09 sind weitere 4 erfolgreich
um 21:12:11 kommt der nächste Schub retries.
weiter habe ich noch nicht geschaut.
Zum einen verstehe ich die verzögerung am Anfang nicht - hat dein System hier eine Problem?
zum 2. verstehe ich nicht warum alle resend zum gleiche Zeitpunkt kommen. Die werder zufällig um 1-4 sek verzögert. Die dürfen nicht in der selben Sekunden kommen.
Bist du auf der neusten Version?
Gruss Martin
Nachträge
- sind deine Rollos eigentlich gepairt? Warum senden die einen infoStatus an "broadcast"
- um 21:12:50 bis 13:10 scheint ja alles zu kommen, was gefehlt hat.
=> bist du sicher dass dein System nicht etwas verzögert?
- kannst du das ganze ohne hmProtokollEvents aufzeichnen, also nur mit HMLAN logs roh messages? Die sind viel näher am ethernet timing. Ausserdem verzögert hmProtokollEvents ziemlich.
milisekundenauflösung wäre hilfreich
Hi Martin,
danke für die Antwort.
diese Verzögerung kommt durch ein sleep(2), weil ich dachte, dass eine verzögerung die Probleme behebt. Leider nicht...
Version von FHEM ist auf dem Stand von gestern.
Was meinst du genau mit dem "stop" am Anfang? Schickst du das intern vorab?
VG
Marc
Hi Martin,
soll ich mal für morgen Abend dei Rev. 3371 einspielen?
Dann hätten wir einen Hinweis, ob es an dem Stop liegt.
VG
Marc
Hallo Marc,
im Anhang ist die aktuelle Version aber mit abgeschaltetem "pre-stop". Also erst ein Update machen dann das File einspielen (oder HMConfig updaten).
Ich denke aber nicht, dass es daran liegt.
Sicher ist, dass keine einzige message nicht beantwortet wurde. Die Antworten kommen nur unendlich spät. Da sind verzögerungen von über 10 sekunden vorhanden. So lange darf es aber nicht dauern. Ich vermute die Verzögerung nicht in der "Luft" oder HM sondern in FHEM oder dem PI.
Mit den Rohmessages könnte man mehr zum Timing sagen.
Gruss Martin
Hallo Martin,
habe mal die Logs umgeschaltet und dir ein aktulles Log in den Anhang gepackt (ohne patch von 08:44).
Interessant ist meiner Meinung nach auch, dass nicht nur das Ack auf sich warten läßt, sondern auch die Jalousien erst nach ca. 10 sec anfangen sich zu bewegen, aber dann gleichmäßig. Also alle 2 sec (sleep 2) fängt die nächste an sich zu bewegen.
Sehr merkwürdig.
Wie kann ich deine Frage verstehen, ob die Rollos gepairt sind? Würden die sonst überhaupt funktionieren? Hatte jedenfalls initial alle Aktoren über HMLAN gepairt. Bin nur zwischenzeitlich mit der Installation auf den PI und wieder zurück, aber immer der gleiche HMLAN.
Dank dir für die Analyse
Gruß
Marc
das mit dem plötzlich später bewegen habe ich auch schon beobachtet. keine 10 minuten aber etwa 5.
zwischendurch konnte ich sie ganz normal über den taster bedienen und nach einer weile fahren sie dann doch noch automatisch.
gruss
andre
Hallo,
also ich beobachte bei mir seit ca. 2 Wochen Ähnliches, meine beiden Rollladen im Wohnzimmer werden über "structure" geschalten. Bis dahin immer gleichzeitig, jetzt hab ich einen Versatz der Schaltzeiten von ca. 2sec und meist noch ein missing act im Webinterface(für den Rollladen der als zweites runterfährt), was aber gar nicht stimmt. Fhem läuft auf einer Fritzbox.
mfg Jens
Hi Zusammen,
bislang habe ich "nur" logs auf CUL_HM ebene. Da ist noch IO (HMLAN oder CUL) drunter. Die Info ist also nicht komplett.
Für alle zum Mitdenken und verstehen was zu sehen ist
- die messages werden gesendet
- die messages werden ggf wiederholt
- es kommen alle Antworten - ggf auch auf einen repeat-request
=> der Ablauf ist komplett und ohne eine fehlende message
- das timing ist exterm fraglich
-- die Antworten kommen eklatant zu spät
-- die Send-requests werden gestaffelt gesendet - 13 requests mit je 3-4 sec Abstand.
?? wo kommen die 3-4 sekunden her? Sind die Absicht, wenn ja wo? wie wird "geschlafen"?
- das Empfangen der 4 erfolgreichen ACKs kommt je in 1 sec Abstand - leider haben wir nur Sekunden Auflösung. Eigentlich sollte dies in 1sec möglich sein
?? hmProtokolEvents ist auf max-level? Das könnte erheblichen Delay erzeugen. Mein Rat: Abschalten - zumindest den Level!
- Die erfolgreichen ACKs werden 4sec nach dem Letzten Send empfangen - und 48sec !!! nach dem Kommando. Das unterstützt HM sowieso nicht - ein ack kann kaum länger als 1-2 sec dauern (MAX!!!) Das bedeuted, dass die Nachricht erheblich früher in HMLAN empfangen und an FHEM gesendet wurde. Dann steckt sie sicher in irgend einem Puffer und warten - aber wo, und wer blockiert?
- die Resends (erste Staffel) kommen direkt nach dem Empfangen der Message, alle auf einmal. Das ist nicht logisch. Ein resend kommt spätestens nach 4 sec. => auch die resend-timer werden aufgehalten.
Zusammenfassend
- das timing ist eigentlich eine einzige Katastrophe
?? welchen Delays bist du dir bewusst? Wo hast du irgendwelche sleeps, waits oder timings eingebaut? Wenn möglich entferne alle. Allen voran hmProtokollEvents.
- Beachte, dass viele Notifies pervormance benötigen. Jedes Logfile ist auch ein Notify! Schreiben in ein File kann - je nach System dauern.
Zum Pairing - du musst es einfach kontorllieren. So würde ich dies machen - kleine Anleitung:
# setze autoRegRead in allen Devices, ausser devices die nur "Config" können, also RCs
define hm HMInfo
set hm param -de PairedTo autoReadReg
#=> setze in allen Devices das Attribut autoReagReg auf 4 (ausser RC)
falls die Daten noch nicht gelesen sind mache ein
set hm autoReadReg
=> alle Device die autoReadReg gesetzt haben werden erneut gelesen - und zwar zeitlich gestaffelt.
mit
set hm update
erzeugt hm einen Statusreport - danach kannst du die Readings ansehen (u.a. Batteriestatus...). Im reading
I_autoReadPend
von hm kannst du sehen, wer noch in der Queue hängt. Wenn die leer ist sollte alles da sein.
ein erneutes
set hm param -de PairedTo autoReadReg
zeigt den Status.
Nur gepairte Devices sind gute Devices (sieht nicht jeder so, aber ich schon;-))
Nur getConfig (alternativ attr autoReadReg) können den Status prüfen
Gruss Martin
Hallo Martin,
momentan bin ich mir nur bewusst, dass zwischen jedem ansprechen eines aktors ein sleep von 2 ist. Dies kann du auch in den Logs sehen.
Notifys habe ich momentan 11 verbaut.
Um zu die pairings zu kontollieren versuche ich mal deine Anleitung zu befolgen.
Als erstes hier mein HMLAN config:
define HMLAN1 HMLAN 192.168.146.15:1000
attr HMLAN1 hmId 123ABC
attr HMLAN1 hmProtocolEvents 0
attr HMLAN1 wdTimer 25
attr HMLAN1 loglevel 1
Und nun die Steps aus deiner Anleitung:
1) Ich füge folgendes meiner config hinzu
define hm HMInfo
2) Führe folgendes aus:
set hm param -de PairedTo autoReadReg
3) Danach füge ich allen jalousieAktoren folgende zeile hinzu:
attr <name> autoReadReg 4
4) Danach führe ich folgendes aus:
set hm autoReadReg
und
set hm update
5) Danach die readings vom hm (HMInfo) anschauen --> I_autoReadPend
6) Als letzte erneut set hm param -de PairedTo autoReadReg ausführen um den Status zu sehen.
Sehe ich dann da, welche Aktoren paired sind und welche nicht?
Oder was sehe ich da alles?
Habe ich alles richtig verstanden?
Wenn ja, dann stelle ich das jetzt alles ein.
Gruß
Marc
PS: Habe für heute Abend das File mit abgeschaltetem "pre-stop" eingespielt.
Hi Martin,
mein AT für Jalousie runter am Abend ist um 21:08 gelaufen, aber diesmal ist rein gar nichts passiert?!? Komisch... Kann es an dem Patch ohne "pre-stop" liegen?
Nachdem die Automatik nicht funktionierte, konnte ich aber über die Oberfläche bedienen.
Im Anhang mein Log, vielleicht kannst du ja etwas erkennen. Hatte auch "sleep(2)" ausgebaut.
VG
Marc
Hallo Martin,
habe Punkt 2 und 3 getauscht.
Bei Punkt 3 (set hm param -de PairedTo autoReadReg) bekomme ich folgende Ausgabe:
param done:
param list
CUL_HM_threeStateSensor_19F43F: - |-
CUL_HM_threeStateSensor_19F525: - |-
LC_EG_1_NO_Rollo_Kueche: 0x123ABC |4
LC_EG_2_SO_Rollo_Kueche: 0x123ABC |4
LC_EG_3_SO_Rollo_Esszimmer: 0x123ABC |4
LC_EG_4_SW_Rollo_Esszimmer: 0x123ABC |4
LC_EG_5_SW_Rollo_Wohnzimmer: 0x123ABC |4
LC_EG_6_SW_Rollo_Wohnzimmer: 0x123ABC |4
LC_EG_7_NW_Rollo_Gaestezimmer: 0x123ABC |4
LC_EG_8_NO_Rollo_Gaestebad: 0x123ABC |4
LC_EG_9_NO_Rollo_Flur: 0x123ABC |4
LC_OG_10_SO_Rollo_Maike: 0x123ABC |4
LC_OG_11_SO_Rollo_Jacob: 0x123ABC |4
LC_OG_12_NW_Rollo_Eltern: 0x123ABC |4
LC_OG_13_NW_Rollo_Ankleide: 0x123ABC |4
WDS_NW : - |-
WDS_SO : - |-
WDS_SW : - |-
autoReadReg done:
cleared
LC_EG_1_NO_Rollo_Kueche
LC_EG_2_SO_Rollo_Kueche
LC_EG_3_SO_Rollo_Esszimmer
LC_EG_4_SW_Rollo_Esszimmer
LC_EG_5_SW_Rollo_Wohnzimmer
LC_EG_6_SW_Rollo_Wohnzimmer
LC_EG_7_NW_Rollo_Gaestezimmer
LC_EG_8_NO_Rollo_Gaestebad
LC_EG_9_NO_Rollo_Flur
LC_OG_10_SO_Rollo_Maike
LC_OG_11_SO_Rollo_Jacob
LC_OG_12_NW_Rollo_Eltern
LC_OG_13_NW_Rollo_Ankleide
Punkt 5 zeigte mir dann in den Readings folgendes:
CFGFN homematic.cfg
C_sumDefined entities:25 device:18 channel:22 virtual:1
ERRactNames WDS_SW,WDS_SO,CUL_HM_threeStateSensor_19F525,CUL_HM_threeStateSensor_19F43F,WDS_NW
I_HM_IOdevices HMLAN1:ok
I_actTotal alive:0 dead:0 unkn:5 off:0
I_autoReadPend LC_EG_6_SW_Rollo_Wohnzimmer,LC_EG_7_NW_Rollo_Gaestezimmer,LC_EG_8_NO_Rollo_Gaestebad,LC_EG_9_NO_Rollo_Flur,LC_OG_10_SO_Rollo_Maike,LC_OG_11_SO_Rollo_Jacob,LC_OG_12_NW_Rollo_Eltern,LC_OG_13_NW_Rollo_Ankleide
I_rssiMinLevel 59<:2 60>:14 80<:0 99>:0
NAME hm
NR 104
STATE updated:2013-08-23 11:33:03
TYPE HMinfo
Version 01
W_sum_motor stop:on:6;stop:35 %:7;
Habe dann alle Devices kontrolliert und festgestellt, dass alle gepairt sind im Zeitraum zwischen 11:33 und 11:35.
Allerdings sind die Readings teilweise total unterschiedlich. Mal habe ich 15 Werte und bei anderen habe ich dann wieder 76 Werte. Ist das normal?
VG
Marc
Nachtrag:
Habe noch ein aktuelles Log angehängt (aktuelles fhem + alle Devices gepairt)
Hallo zusammen,
habe heute Abend alle "notify" ausgebaut.
Gefühlt läuft alles viel schneller und sauberer.
Allerdings finde ich immer noch 16 mal "no ACK from Device" im Log.
Habe das Log noch mal angehängt.
@Martin: Wäre wirklich super, wenn du dir das noch mal anschauen kannst und evtl. etwas findest.
Viele Grüße
Marc
Hi,
so, mal sehen, dass ich alles Beantworte:
11 notifyes sollten schon gehen, perfornamcemessungen habe ich nicht. Bedenke, dass jedes einzelen Logfile auch quasi ein Notify ist.
Bedenklich sehe ich dein Sleep. Es sieht wie ein aktives Warten aus. Das wäre verherend - und absolut kontraproduktiv. Dass es aktiv (also nicht unterbrechbar) ist zeigtmir, dass keine Antworten in der zwischenzeit kommen. Wenn das so ist machst du damit alles kaputt.
Warum brauchst du die? Sind sie notwendig? Wenn ja suche eine passive möglichkeit zu warten, wenn nein werfe sie einfach raus.
Sehe ich dann da, welche Aktoren paired sind und welche nicht?
Oder was sehe ich da alles?
=> einfach ausprobieren
Habe dann alle Devices kontrolliert und festgestellt, dass alle gepairt sind im Zeitraum zwischen 11:33 und 11:35.
=> das ist der Zeitstempel, wann es gelesen wurde.
Ich habe nur das letzte Log angesehen. Wieder das Timingproblem. Alle Antworten müssen in deiner Konfig warten bis deine sleeps beendet sind. Ich bin eigentlich sicher dass alles besser läuft wenn du diese einfach entfernst. Dann können wir noch einmal nachsehen.
Mit den Sleeps hat es keinen Sinn.
Im Prinzip sollte die FHEM SW das Mini-warten berücksichtigen - sleeps sollten nur in wenigen speziellen Fällen notwendig sein.
Sorry, ich mag keine Sleeps, aktive schon 2mal nicht
Gruss Martin
Hi Martin,
danke für die Antwort!
Ich verstehe es echt nicht mehr :-(
Habe jetzt folgende Änderungen vorgenommen:
1) ALLE sleeps ausgebaut
2) Von 11 auf 4 notify abgespeckt
3) 7 structuren für die Jalousien entfernt
Trotzdem immer noch diese Verzögerung und 12 MissingAck
Aktuelles Log im Anhang.
Bin echt ratlos, keine Ahnung was ich noch abspecken soll, damit die Probleme weg sind
Hast du oder jemand anders noch eine Idee?
VG
Marc
wie du unten sehen kannst gibt es eine Pause vor jeden CUL_HM set von 600ms bis 2 sek. Evtl wird hier in strukt gearbeitet, keine Ahnung.
Da muss man ggf einmal nachsehen, was strukt so alles errechnet und ob auch dies meint warten zu müssen.
Probiere einfach einmal alle Rollos auf ein
set roll1 1;set rollo2;set....
also alle rollos auf einmal, ohne structure . Gibt eine ganz schöne last, mal sehen.
In strukt muss man getrennt suchen.
Gruss Martin
14:23:06.388 CUL_HM set LC_EG_1_NO_Rollo_Kueche 1
14:23:06.397 HMLAN_Send: HMLAN1 S:SB04722DA stat: 00 t:00000000 d:01 r:B04722DA m:4C A011 123ABC 184F32 0301
14:23:06.402 Struct element
14:23:06.403 $dependencyDevice=0SC_EMA_PA7_tuerSeiteneingangAuf - Value=Value(0SC_EMA_PA7_tuerSeiteneingangAuf)
14:23:06.405 set $dependencyValue=66
Pause 2 sek
14:23:08.411 CUL_HM set LC_EG_2_SO_Rollo_Kueche 66
14:23:08.417 HMLAN_Send: HMLAN1 S:SB0472ABE stat: 00 t:00000000 d:01 r:B0472ABE m:4D A011 123ABC 184F1B 0301
14:23:08.422 Struct element
pause 600ms
14:23:09.020 CUL_HM set LC_EG_3_SO_Rollo_Esszimmer 1
14:23:09.025 HMLAN_Send: HMLAN1 S:SB0472D1E stat: 00 t:00000000 d:01 r:B0472D1E m:4E A011 123ABC 215FA8 0301
14:23:09.078 Struct element
pause 600ms
14:23:09.734 CUL_HM set LC_EG_4_SW_Rollo_Esszimmer 1
14:23:09.754 HMLAN_Send: HMLAN1 S:SB0472FF0 stat: 00 t:00000000 d:01 r:B0472FF0 m:4F A011 123ABC 215F90 0301
14:23:09.767 Struct element
14:23:09.778 $dependencyDevice=0SC_EMA_PA6_tuerTerasseAuf - Value=Value(0SC_EMA_PA6_tuerTerasseAuf)
14:23:09.780 set other Value=1
pause 600ms
14:23:10.368 CUL_HM set LC_EG_5_SW_Rollo_Wohnzimmer 1
14:23:10.396 HMLAN_Send: HMLAN1 S:SB0473276 stat: 00 t:00000000 d:01 r:B0473276 m:50 A011 123ABC 193F4B 0301
14:23:10.406 Struct element
pause 900ms
14:23:11.330 CUL_HM set LC_EG_6_SW_Rollo_Wohnzimmer 1
pause 700ms
14:23:11.415 HMLAN_Send: HMLAN1 S:SB0473649 stat: 00 t:00000000 d:01 r:B0473649 m:51 A011 123ABC 1941BE 0301
14:23:11.422 Struct element
14:23:11.423 $dependencyDevice=0SC_EMA_PA8_tuerGaesteAuf - Value=Value(0SC_EMA_PA8_tuerGaesteAuf)
14:23:11.425 set other Value=1
pause 800ms
14:23:12.222 CUL_HM set LC_EG_7_NW_Rollo_Gaestezimmer 1
Hallo Martin,
die Ausgabe "Struct" ist leider noch verwirrend. Der Text in der Ausgabe ist noch alt.
Habe ja extra alles umgebaut auf ein Array. Strukturen habe ich nicht mehr.
der code sieht in etwa so aus
my @Array = ("Rollo1","Rollo2")
for(@Array)
{
>>>> Prüfungen je Element für $_
danach je Prüfung in eine bestimmte postition fahren
}
ganz am ende schicke ich noch eine email
und alles ohne sleep. nur einmal über das Array iterieren und die set's absetzen.
Soll ich dir mal die "Methode" schicken?
VG
Marc
ja, schicke sie einmal - schon aus neugier.
Die Email geht aber nicht je Rollo weg - oder? Email senden könnte schon diese Verzögerung verursachen.
Gruss Martin
Hi Martin,
habe die cfg's und meine 99_myUtils.pm als pm zugeschickt.
Eine E-Mail verschicke ich nur am Ende der Methode oder wenn bei den Prüfungen eine Ausnahme auftritt. Z.B. wenn noch eine Tür auf ist und die Jalousie nur halb runtergefahren wurde.
Hoffe du findest etwas.
Vorab vielen Dank für deine Hilfe
Gruß
Marc
Hi Martin,
bin gestern Abend wieder auf meinen rPI umgezogen.
Das System sieht laut logs jetzt deutlich schneller aus, aber immer noch 16 NACKs
Hab das Log ich wieder angehängt.
VG
Marc
Hallo Marc,
nach meinem Dafürhalten sieht es relativ gut aus.
Meine Analyse:
Du startest 13 Rolladen quasi zeitgleich. Effektiv in 1,3sec.
Gesendet werden 2 messages je Rollo (stop und set) plus Wiederholungen.
Die erste und die 2. message überlappen zeitlich zwischen den Rollos.
2 Rollos kommen ohne jede Wiederholung aus
5 Rollos wiederholen die erste Message 1 mal
2 Rollos wiederholen die erste Message 2 mal
2 Rollos wiederholen die zweite Message 1 mal
1 Rollos wiederholt die zweite Message 1 mal
Und
1 Rollo scheitert beim 3. mal an der ersten message
In Summe haben wir immer noch ein Rollo, das nicht gefahren ist. Die anderen 16 missingACK halte ich für unschön aber unkritisch.
Im Gegensatz zum Beginn ist dies schon sehr nahe am Ziel.
- ich konnte die Anzahl der Wiederholungen auf 3 setzen (also 4mal senden) oder einstellbar machen (attr)
- im HMLAN kannst du msgParseDly ansehen. Das soll Auskunft darüber geben, wie 'langsam' dein FHEM ist. Sieht nicht so schlecht aus, aber einmal ist FHEM500ms hinten dran. Was steht in der Variable?
Wenn ich 13 Rollos zeitgleich also relativ hohe Last ansehe...
wie ich die missing-ACKs noch verbessern kann ist nicht 100% klar.
Willst du einen Test mit 3 Wiederholungen machen?
Hallo Martin,
danke für die Analyse.
In welchen Abständen schickst du die Wiederholungen? Wäre es denkbar 5 Wiederholungen einzubauen, aber dann mit steigenden Abständen?
Also quasi:
1. Wdh. nach 3 sek
2. Wdh. nach 5 sek der 1. Wdh.
3. Wdh. nach 10 sek der 2. Wdh.
4. Wdh. nach 20 sek der 3. Wdh.
5. Wdh. nach 30 sek der 4. Wdh.
Für mich wäre es schon wichtig, dass alle Jalousien immer fahren, da man sich ja im Urlaub oder bei sonstiger Abwesenheit darauf verlassen möchte.
Gibt es irgendwas, wie ich das letzte MissingAck abfangen kann? Damit ich nur beim letzten NACK mir eine E-Mail schicken kann?
Schicke dir gleich eine Auswertung von "set hm protoEvents".
VG
Marc
Hier die Auswertung von protoEvents:
protoEvents done:
name :protState |protCmdPend |protSnd |protLastRcv |protResndFail |protResnd |protNack
CUL_HM_threeStateSensor_19F43F: Info_Cleared |- |- |- |- |- |-
CUL_HM_threeStateSensor_19F525: Info_Cleared |- |- |- |- |- |-
LC_EG_1_NO_Rollo_Kueche: CMDs_done_events:2 |- |2:2013-08-27 07:57:55 |2013-08-27 07:58:02 |- |2:2013-08-27 07:57:55 |-
LC_EG_2_SO_Rollo_Kueche: CMDs_done_events:2 |- |2:2013-08-27 07:57:52 |2013-08-27 07:58:22 |- |2:2013-08-27 07:57:54 |-
LC_EG_3_SO_Rollo_Esszimmer: CMDs_done_events:2 |- |2:2013-08-27 07:57:55 |2013-08-27 07:58:25 |- |2:2013-08-27 07:57:55 |-
LC_EG_4_SW_Rollo_Esszimmer: CMDs_done_events:2 |- |2:2013-08-27 07:57:54 |2013-08-27 07:58:25 |- |2:2013-08-27 07:57:54 |-
LC_EG_5_SW_Rollo_Wohnzimmer: CMDs_done_events:2 |- |2:2013-08-27 07:57:59 |2013-08-27 07:58:41 |- |2:2013-08-27 07:57:59 |-
LC_EG_6_SW_Rollo_Wohnzimmer: CMDs_done_events:3 |- |2:2013-08-27 07:57:54 |2013-08-27 07:58:30 |- |3:2013-08-27 07:57:59 |-
LC_EG_7_NW_Rollo_Gaestezimmer: CMDs_done_events:3 |- |2:2013-08-27 07:58:02 |2013-08-27 07:58:32 |1:2013-08-27 07:57:59 |2:2013-08-27 07:57:54 |-
LC_EG_8_NO_Rollo_Gaestebad: CMDs_done_events:2 |- |2:2013-08-27 07:57:58 |2013-08-27 07:58:28 |- |2:2013-08-27 07:57:56 |-
LC_EG_9_NO_Rollo_Flur: CMDs_done_events:3 |- |2:2013-08-27 07:57:58 |2013-08-27 07:58:26 |1:2013-08-27 07:57:56 |2:2013-08-27 07:57:54 |-
LC_OG_10_SO_Rollo_Maike: CMDs_done |- |2:2013-08-27 07:57:52 |2013-08-27 07:57:59 |- |- |-
LC_OG_11_SO_Rollo_Jacob: CMDs_done_events:2 |- |2:2013-08-27 07:57:52 |2013-08-27 07:58:12 |- |2:2013-08-27 07:57:54 |-
LC_OG_12_NW_Rollo_Eltern: CMDs_done_events:1 |- |2:2013-08-27 07:57:52 |2013-08-27 07:58:14 |- |1:2013-08-27 07:57:51 |-
LC_OG_13_NW_Rollo_Ankleide: CMDs_done_events:1 |- |2:2013-08-27 07:57:52 |2013-08-27 07:58:15 |- |1:2013-08-27 07:57:51 |-
Das Log hiervon ist im Anhang (fhemMissingAck9.log)
hi,
5 wiederholungen sind möglich. Bei diesem Level werde ich aber ein Attribut einbauen. Mehr als 3 repeat(also 4 send) baue ich nicht fix ein.
eine gestaffelte Wiederholung baue ich auch nicht ein. Das macht keinen Sinn. wenn du 13 Aktoren startest und alle gleichzeitigloslegen gibt es Probleme. Wenn dann alle nach 3 sek wieder senden hast du das gleiche Problem. Also no-go
Vielmehr ist es ein Zufalls-abstand. Wenn etwas schief geht wird um 1-4 sec (raster 0.1sec) per zufallsgenerator verzögert. Das ist jetzt schon drin und leistet recht gute Dienste.
Bei deiner Staffel habe ich auch einsprüche, die Zeiten sind nicht ok. Sollte es tatsächlich zur 5. Wiederholung kommen haben wir eine Verzögerung von 70sec. Wenn jemand das zusammen mit einem Taster nutzt rechnet er definitiv nicht mehr mit einer Reaktion. Das kann man nicht generell machen.
Das mit der Verlässlichkeit ist auf meiner Priolist immer GANZ oben. Dennoch kann es FHEM nicht garantieren. Nur ein Beispiel:Ist der Aktor defekt muss irgendwann Schluss sein.
Kommt also die Frage der Benachrichtigung.
Aktuell sind protokoll-events nicht mit Trigger verbunden und lösen keinen Event aus.
FHEM hat keine Alarm-strategie (so wie ich es verstehe)
Lösung 1a)
Du kannst also einen zyklischen Job aufsetzen, der nach Fehlern sucht.
Lösung 1b)
du setzt eine zyklischen Job auf, der HMInfo update zyklisch macht und du suchst nach fehler in HMInfo
Lösung 2)
ich erweitere HMInfo zum Alarm-system aus.
Könnte so aussehen:
- User definiert eine wiederholzeit, in der HMInfo einen update macht. Zeit in Minuten, vorschlag ist 5min default
- Errors zeigt HMInfo jetzt schon an bei rssi_Critical, protocoll-errors
- User kann (jetzt schon) definieren, welche Readings ERRROS sind
- Wie bei allen anderen readings kann sich der User ein Event generieren, wenn es eine Änderung des Status gibt.
Nachteil von Lösung 2:
- du hast eine Verzögerung von x min. Aber für ein remote-User interface halte ich dies für ok
- du bekommst ein Event und ein paar details zum Fehler. Was genau du in die email schreibst entscheidest du selbst. Wenn du zugang hast, suchst du den Fehler und die Detail.
Interessiert? War die Richtung der Erklärung verständlich
Gruss Martin
Hi,
das mit der Staffel war ja auch erstmal nur eine Idee, da bei mir ja immer mal wieder eine Jalousie nicht fährt und mit einer längeren Verzögerung evtl. doch.
Generell fände ich es super, wenn du ein attr einbaust, indem die user die repeats einstellen können.
Lösung 2 fände ich super und mit der Verzögerung könnte ich auch leben.
Lösung 1a hatte ich bereits vorbereitet, damit ich nur noch im Notfall eine Email bekomme.
VG
Marc
Hi,
mit Version 3804 kannst du msgRepeat setzen (siehe auch Commandref)
Gruss Martin
Danke!
Werde heute Abend ein update von der Umgebung machen.
Gruß
Marc
Hallo Init,
ist das Problem jetzt bei Dir komplett beseitigt? Bei mir ist es jetzt nämlich ebenso - seit einem Austausch habe ich auch das Problem, daß die Ersatzaktoren genauso unzuverlässig sind, wie Du es eingangs geschildert hast...
Gruß
zur Info,
ich habe in einem Zimmer 4 rollo-aktoren. Einer hatte immer wieder einmal Probleme.
Ich habe die RSSI werte angesehen, schwanken und gehen manchmal so auf -85. Andere devices waren schlechter.
dennoch habe ich einen Repeater eingesetzt, selektiv nur für diesen Aktor.
Jetzt ist der RSSI wert (min) auf -75 - und es klappt alles.
Also wenn ihr gelegentlich Probleme habt, schaut einmal die RSSI werte an.
Es gibt - wie das Beispiel anschaulich zeigt, keinen absoluten Wert, der Gültig ist.
Gruss Martin
Zitat von: Init am 24 August 2013, 14:31:18
Hi Martin,
danke für die Antwort!
Ich verstehe es echt nicht mehr :-(
Habe jetzt folgende Änderungen vorgenommen:
1) ALLE sleeps ausgebaut
2) Von 11 auf 4 notify abgespeckt
3) 7 structuren für die Jalousien entfernt
Trotzdem immer noch diese Verzögerung und 12 MissingAck
Aktuelles Log im Anhang.
Bin echt ratlos, keine Ahnung was ich noch abspecken soll, damit die Probleme weg sind
Hast du oder jemand anders noch eine Idee?
VG
Marc
Hallo Init,
ich habe leider die gleichen Probleme. Hast Du Deine in den Griff bekommen?
VG
Manuel
könnt ihr das noch einmal zusammenstellen:
- welche devices habe missing-ack?
- wie häufig tritt es auf? immer,meistens,oft oder manchmal?
- roh-messages aufzeichnen
das ist das beste, was ich anbieten kann.
Hallo Martin,
dieser Post ist zwar schon was älter, da ich aber z.Zt. genau mit einem Rolladenschalter ständig MissingAck bekomme,
hätte ich da noch zwei Fragen zu Deiner Bemerkung:
ZitatIch habe die RSSI werte angesehen, schwanken und gehen manchmal so auf -85. Andere devices waren schlechter.
dennoch habe ich einen Repeater eingesetzt, selektiv nur für diesen Aktor.
Jetzt ist der RSSI wert (min) auf -75 - und es klappt alles.
Was sagen diese RSSI Werte eigentlich aus? (Damit ich mal mit den anderen Vergleiche)
Was meinst Du mit einem Repeater genau für diesen Aktor? Was kann man da machen?
Gruß Adam
Hallo Adam,
RSSI ist die Feldstärke
http://de.wikipedia.org/wiki/Received_Signal_Strength_Indication
http://de.wikipedia.org/wiki/Feldst%C3%A4rke
Das ist also der Pegel des Empfangssignal logarithmisch. Die werte sind negativ, da kleiner als der Referenzwert. Bei Werten unterhalb von -80 kann man aufpassen.... ob es noch reicht hängt von der Empfindlichkeit des Empfängers ab.
Es kann auch sein, dass die Werte in Abhängigkeit der Batteriespannung sinken oder der Empfänger schlechter wird
Wie ich es machen würde:
- Werte unter -80 sind beachtenswert
- wenn keine protokollfehler auftreten ist alles ok
- Hat man Protokollfehler UND der RSSI ist schlecht sollte man nach Verbesserungsmöglichkeit suchen
als erst prüfen - hier würde ich HMinfo bemühen (define hm HMinfo vorausgesetzt)
a) set hm rssi => Komplettliste aller RSSI werte für HM- incl der werte zwischen den Devices (remote nach actor)
b) set hm protoEvents short => Übersicht über Protokoll Ereignisse und Fehler.
c) attr hm autoUpdate xx => zyklische Prüfung auf HM Infos/Warnungen und Fehler. In der Webansicht von hm kann man sehen, welche devices bei RSSI schlecht liegen, ob Protokollfehler aufgetreten sind und wo, ob Batteriewarnungen vorliegen. Eigene Überwachungen kann man addieren.
Wenn du dann erkennst, dass Devices schlechten Empfang haben und Probleme machen kannst du erst einmal den Standort deines IO devices optimieren.
Wenn das auch nicht reicht kannst du den selectiven repeater von HM einsetzen. Der wiederholt messages. Du kannst ihm also an eine Position setzen in der der Empfang schlecht ist. Du musst dann Einstellen, welche IDs wiederholt werden sollen. FHEM zeigt die RSSI werte zum Repeater getrennt an (nicht alles möglich... aber fast alle Verbindungen)
Du kannst natürlich die Tabellen löschen, wenn du etwas geändert hast - über die ganze HM Installation:
set hm clear rssi
set hm clear msgStat
....
Gruss Martin
Hallo Martin,
vielen Dank für die ausführlichen Erklärungen, ich werde das HMinfo mal am Wochenende bemühen!
Danke,
Adam