Hallo liebe Homematic-Jünger,
ich muss ehrlich sagen, dass ich bald total am Rad drehe. :-) Ich nutze bereits sehr Jahren mein FHEM für diverse Zwecke. Unter anderem habe ich auch Jalousienaktoren, normale Aktoren, Dimmer, Bewegungsmelder, Türkontakte, etc. im Einsatz. Reine Homematic-Gerät sind es bei mir ca. 50 Stück. Nebenbei habe ich auch Z-Wave bei mir am laufen.
Ich habe das Problem, dass immer wieder einzelne Geräte nicht reagieren. Und es liegt definitiv nicht an der Programmierung in irgendwelchen Notifys oder DOIFs. Die Befehle werden vom HMUSB abgesetzt, vom Aktor empfangen, aber scheinbar nicht ausgeführt.
Beispiel:
Hier sollte eine Jalousie um 18:00 Uhr auf 15% heruntergefahren werden. Aber die Aktion wurde nicht ausgeführt.
2017-01-30_12:28:07 eltern_jalousie deviceMsg: on (to vccu)
2017-01-30_12:28:07 eltern_jalousie level: 100
2017-01-30_12:28:07 eltern_jalousie motor: stop:on
2017-01-30_12:28:07 eltern_jalousie pct: 100
2017-01-30_12:28:07 eltern_jalousie on
2017-01-30_12:28:07 eltern_jalousie timedOn: off
2017-01-30_18:00:18 eltern_jalousie level: set_15
2017-01-30_18:00:18 eltern_jalousie set_15
2017-01-30_18:00:19 eltern_jalousie deviceMsg: on (to vccu)
2017-01-30_18:00:19 eltern_jalousie level: 100
2017-01-30_18:00:19 eltern_jalousie motor: stop:on
2017-01-30_18:00:19 eltern_jalousie pct: 100
2017-01-30_18:00:19 eltern_jalousie on
2017-01-30_18:00:19 eltern_jalousie timedOn: off
Ich habe ab heute bei den üblichen Verdächtigen mal verbose auf gesetzt, um mehr Details liefern zu können.
Die RSSI-Werte sind absolut in Ordnung:
rssi done:
Device receive from last avg min_max count
eltern_jalousie hmusb eltern_jalousie -64.0 -64.8 -68.0< -63.0 10
eltern_jalousie eltern_jalousie hmusb -65.0 -66.5 -68.0< -65.0 2
Es wurden auch zeitgleich keine anderen HMUSB-Aktionen ausgeführt. Ich versuche in meinen DOIFs immer ausreichend "Luft" zu lassen:
Wobei mich das schon sehr ärgert, dass ich mittlerweile ca. 15 Jalousien mit viel zu viel Abstand herunterfahren muss.
Ich warte mindestens die driveDown-Zeit + Minimum 30sec Pause + Zufallswert.
2017.01.30 17:56:33 3: CUL_HM set wohnzimmer1_jalousie 0
2017.01.30 17:56:33 3: CUL_HM set wohnzimmer2_jalousie 0
2017.01.30 17:56:33 3: CUL_HM set wohnzimmer3_jalousie 0
2017.01.30 17:57:17 3: CUL_HM set kueche1_jalousie 0
2017.01.30 17:57:17 3: CUL_HM set kueche2_jalousie 0
2017.01.30 17:57:48 3: CUL_HM set arbeit_jalousie 0
2017.01.30 17:57:48 3: CUL_HM set wc_jalousie 0
2017.01.30 17:58:44 3: CUL_HM set diele_jalousie 0
2017.01.30 17:58:45 3: CUL_HM set hwr_jalousie 0
2017.01.30 17:59:33 3: CUL_HM set ankleide_jalousie 0
2017.01.30 17:59:33 3: CUL_HM set bad_jalousie 0
2017.01.30 18:00:19 3: CUL_HM set eltern_jalousie 15
Keine Ahnung, ob das an der Entfernung zum HMUSB liegt, aber in der Nähe des HMUSB kann ich ca. vier Jalousien gleichzeitig starten. Je weiter weg desto weniger Jalousien gleichzeitig (ca. 2 Stück zeitgleich). Dies hat aber nichts mit dem "Nichtreagieren" zu tun. Denn wenn ich zu schnell ausführe, folgt ein MISSING_ACK. Diesen habe ich im obigen Fall (Eltern-Jalousien) nicht.
protoEvents:
protoEvents done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
eltern_jalousie : done | - | 10: | - # - | - | - | -
================================================================================================================
sum 0 |0 |743 |1 #0 |0 |0 |0
Kann mir bitte irgendjemand einen Tipp geben, woran das liegen könnte?
Oder mir ein paar Möglichkeiten nennen, den Fehler einzugrenzen?
Vielen vielen Dank.
zeig mal ein list vom hmusb.
ZitatWobei mich das schon sehr ärgert, dass ich mittlerweile ca. 15 Jalousien mit viel zu viel Abstand herunterfahren muss.
Ich warte mindestens die driveDown-Zeit + Minimum 30sec Pause + Zufallswert.
Hi,
ich fahre 13 Rollläden mit "einem" Befehl runter und hoch und habe keine Probleme.
Gruß Otto
Zitat von: frank am 31 Januar 2017, 14:17:28
zeig mal ein list vom hmusb.
Ist das okay, wenn ich die lange Liste mit den IDs weglasse? Oder brauchst du die auch?
...
ZitatIst das okay, wenn ich die lange Liste mit den IDs weglasse? Oder brauchst du die auch?
passt schon und ist unauffällig.
dann sniffe mal so eine problematische aktion.
Ich konnte für heute noch gerade rechtzeitig das Sniffen aktivieren.
Dann habe ich wie gespannt auf das Herunterfahren der Jalousien gewartet.
Und prompt kam der übliche Vorführeffekt. Aber das ist normal, denn der Fehler tritt halt sporadisch auf.
Ich vermute mal, dass ein Log ohne Fehlverhalten keinen Sinn macht, oder?
Dann warte ich mal auf morgen und hoffe, dass ich daran denke, das Sniffen zu aktivieren.
Hmm. Ich bin anscheinend nicht alleine mit dem Problem:
https://forum.fhem.de/index.php?topic=66162.new#new
So, nun habe ich einen Volltreffer.
Ab 17:18:52 Uhr sollten etappenweise die Jalousien runterfahren. Von acht Jalousien haben jedoch nur vier Jalousien ihr Ziel erreicht.
...
Ich muss jedoch dabeisagen, dass ich heute bei allen HM-Geräten die VCCU-Zuweisung entfernt habe. Ich glaube zwar nicht, dass das etwas damit zu tun hatte. Aber vielleicht haben die Jalousien aus diesem Grund heute einmalig nicht direkt reagiert. Wobei das heutige Fehlverhalten wieder absolut identisch mit dem üblichen Fehlverhalten war.
...
Eine halbe Stunde später sind alle Jalousien auf Level=0 gefahren und das mit keinerlei Problemen.
Das ist wieder typisch sporadisch. Mal klappt es - mal nicht. Und ich erkenne keinen Rhythmus.
Die vccu sollte nichts damit zu tun. Haben.
Setze hmLanQlen auf 1. Ich bin nicht mehr sicher, was der Default ist. Es wird wahrscheinlich zu schnell gesendet. Da geht was verloren in der Luft.
Ich sehe nicht alle Komandos, nur 5.
Die stehengeblieben melden zu Beginn, dass der Motor nicht fährt. Scheinbar haben sie die Nachricht nicht empfangen.
Hast du mehr als eine hmusb?
Hallo,
ich habe da einen Verdacht: passiert das immer maximal einmal (pro Gerät) nach einem Fhem-Neustart? Wenn ja, hilft evtl. der angehängte Patch.
Bei mir melden die Geräte nur den Status zurück und führen die Aktion nicht aus, wenn die letzte Messagenummer wiederverwendet wird. Beim Neustart ist das immer die 1. Der angehängte Patch setzt die Nummer zufällig, ich weiss nicht, ob man die nicht eigentlich in der fhem.save speichern will. @Martin?
Viele Grüße
Michael
Hmm. Ich kann gerade nicht ausführlich antworten.
@martinp876:
hmLanQlen ist per default auf 1min.
Ich hatte mal zwei HMUSB per vccu in Betrieb. Das ist ein Jahr her.
Mittlerweile habe ich nur einen HMUSB.
Ich fahren die Jalousien einzeln per DOIF. Aber eigentlich sollte genug Pause dazwischen sein. Ich nutze selten (wenn dann manuell) Structures (mit async_delay=2). Hier habe ich kaum Probleme festgestellt. Aber dies ist kaum repräsentativ, da zu selten benutzt.
Werden die "Befehle" nicht in eine Art Warteschlange gepackt und sukzessive ausgeführt? Kann ein DOIF zu schnell sein? Ich starte ca. 3-4 Jalousien pro Durchlauf. Dann kommt eine Pause von 30sec + rand(30) Sekunden. Und dann die nächsten.
Bei einem Structure werden doch quasi auch alle zeitgleich gestartet.
@mgernoth:
In der Tat starte ich Fhem nahezu täglich neu und habe auch ca. einmal am Tag den Bug. Gestern nicht und genau dann hatte ich mal ein Update/Neustart ausgelassen. Ich habe ein gutes Gefühl bei deinem Verdacht.
Ich habe aber auch Geräte, die noch nie begriffen waren. Häufig die ersten Jalousien, die ich starte.
Ich habe für heute folgendes gemacht:
- kein Update und somit auf kein FHEM Neustart
- alle Jalousien in den DOIFs "enger" zusammengefasst. Also alle Jalousien in gerade einmal zwei Gruppen heruntergefahren. Zwischen den beiden Läufen waren nur wenige Sekunden Pause. Damit wollte ich eigentlich mehr Last und mehr Konflikte provozieren.
- Außerdem habe ich alle Jalousien quasi zweimal laufen lassen. Einmal auf 50% und eine halbe Stunde später auf 0% gefahren.
Und man mag es Zufall nennen, aber heute lief alles wunderbar.
Ich werde die nächsten Tage weiter beobachten, ob ein FHEM Neustart meine Probleme verursacht.
Hallo zusammen,
bei mir scheint es auch nur nach dem Neustart zu passieren.
Ich werde es ebenfalls beobachten, aber es sieht ganz danach aus.
Guter Tipp :)
Ciao!
Das ist wirklich ein guter Hinweis.
Ich werde den startcounter zufällig wählen. Da hat man dann eine Chance von 1:255. Sollten vorher statusrequest kommen bewegt sich der Counter auch.
Statusrequest werden eigentlich beim Neustart immer ausgeführt. Ausser ihr habt autoreadreg komplett abgeschaltet.
Zitat von: martinp876 am 03 Februar 2017, 06:08:14
Sollten vorher statusrequest kommen bewegt sich der Counter auch.
Statusrequest werden eigentlich beim Neustart immer ausgeführt. Ausser ihr habt autoreadreg komplett abgeschaltet.
Hmm, das macht mir nun wiederum Sorgen. Ich habe das "autoReadReg" natürlich nicht ausgeschaltet. Und ich sehe auch alle statusRequest(s) nach dem Neustart. Verstehe ich das dann richtig, dass die möglich Ursache dann doch eine andere sein muss? Kann man sich diesen Counter irgendwie im Frontend oder beim Sniffen sichtbar machen? Bzw. woran erkennt man das, falls es schon irgendwo angezeigt wird? Das Internal "hmusb_MSGCNT" ist das nicht, oder? "IDcnt" im Sniffing-Log auch nicht, oder?
Ich hole mir gleich mal die geänderte 10_CUL_HM (https://svn.fhem.de/trac/changeset/13315/) und starte mal neu. Dann werde ich das heute abend mal beobachten.
Ich habe getestet. Wenn man ein. Stellkommando mit alter Nummer und neuen Werten sendet wird es beantwortet und der wert ignoriert. Ich habe nicht getestet, dazwischen ein statusrequest zu senden.
In jedem Fall ist es ein Problem, dass jetzt mit einer Chance von 1:255 gelöst ist.
Da fällt mir noch eins ein. Ich wiederhole settings wenn der Zielwert nicht erreicht ist. Ein Mal. Aber ich erhöhe den Zähler nicht. Das wäre offensichtlich hilfreich. Es müsste das Problem zu 100% lösen.
Zitat von: martinp876 am 03 Februar 2017, 19:46:47
Da fällt mir noch eins ein. Ich wiederhole settings wenn der Zielwert nicht erreicht ist. Ein Mal. Aber ich erhöhe den Zähler nicht. Das wäre offensichtlich hilfreich. Es müsste das Problem zu 100% lösen.
Heißt das, dass noch ein Fix folgt?
Es sieht so erst einmal gut aus. Die folgekommandos werden sauber eingehängt. Ich habe zwar schon nachgesehen, werde es morgen aber noch einmal machen.
Hat es nach der jetzigen Implementierung noch Probleme gegeben?
Ich hatte bisher keine Probleme.
Ich hatte entweder nicht neu gestartet oder den Fix aktiv.
Andererseits habe ich auch alles was mit meiner VCCU zu tun hatte, entfernt. Aber du sagtest ja, dass es daran nicht liegen könnte.
Mit Sicherheit liegt es nicht an der vccu.