Hallo,
ich habe 8 Rollläden über 3 Stockwerke verteilt, von denen immer mal wieder ein Rollladen unzuverlässig fährt. Vor allem, wenn ich per Script abends alle Rollläden runter fahre. Ursprünglich waren überall HM ( ohne IP) Rollladenaktoren installiert. Inzwischen habe ich den einen HM Aktor an dem einen Rolladen, der immer wieder offen bleibt, gegen den HMIP-BROLL ausgetauscht. Alles ist über eine CCU2 (neueste FW) verbunden.
Trotzdem bleibt der Rollladen an einem von 10 Abenden offen. Wenn ich ihn danach über IPS Webfront sozusagen manuell fahre, funktioniert es sofort.
Da der entsprechende Rollladen als letzter in meinem Skript geschlossen wird, habe ich 1 Sekunde Pause zwischen den einzelnen Befehlen eingebaut, da ich eine Kollision der gleichzeitigen Schließbefehle im Verdacht hatte. D.h. jede Sekunde startet die Schließung eines Rollladens.
Leider ist der Rollladen trotz der Sekunden-Pause heute Abend wieder offen geblieben.
Nun suche ich eine Idee, wie ich der Ursache auf die Spur kommen könnte.
Gibt es denn Logfiles (auf CCU - IPS scheint mir nicht das Problem zu sein), die mir hier helfen könnten?
Könnte eine Kollision die Ursache sein. Denn die Aktoren melden ja auch während sie fahren ständig die aktuelle Position. Wie kann ich das rausfinden?
In der CCU sehe ich, dass der Duty Cycle zwischen 1 und 3% steht.
Kann man daraus schließen, dass es dann keine Kollisionen gibt und es eine andere Ursache geben muss?
Hast Du denn irgendwo im Haus noch z.B. Homematic IP Steckdosen, die als Repeater dienen oder versorgt die CCU2 das gesamte Haus, bzw. die 3 Stockwerke?
Was passiert denn wenn Du die Rollläden als Gruppe in der CCU2 auf einen virtuellen Taster legest und dann nur den virtuellen Taster aus IP-Symcon auslöst?
Ich habe die CCU2 im EG stehen und diese versorgt alle HM und HMIP Geräte im OG und UG. Habe keine weiteren HMIP Geräte, die als Repeater dienen könnten.
Ich würde aber gerne erst einmal herausfinden, warum der BROLL nicht fährt. Liegt es am zu schlechten Empfang / zu großer Entfernung BROLL zur CCU2 oder liegt es an Duty Cycle / Kollisionen.
Kann ich das denn irgendwo in einem Log abfragen (v.a. Empfangsstärke)?
Rollladen als Gruppe habe ich noch nicht getestet. Möchte eigentlich alle Gruppierungen und Logik komplett auf IPS haben.
Logik macht vielleicht Sinn in IP-Symcon zu haben, aber eine Direktverknüpfung kann und sollte IP-Symcon nicht ersetzten. Alleine deshalb weil eine Direktverknüpfung immer funktioniert, egal ob die CCU oder IP-Symcon vielleicht auch mal nicht erreichbar sein sollten. Daher macht es zumindest Sinn wenn Du mehrere Rollläden als Gruppe schalten willst diese auch in der CCU selber als Direktverknüpfung auf einen Virtuellen Taster zu legen, das reduziert auch den Funkverkehr.
Hast Du denn bei dem einen Gerät was mal Aussetzer hat irgendwelche Meldungen in der CCU selber?
Ich habe nur Direkt-Verknüpfungen zwischen den Schaltern (4-fach bzw 6-fach Batterie-Schalter) und den Rollladen-Aktoren. Damit kann im Raum der Rollladen auch bei Ausfall von CCU oder IPS bedient werden.
Eine „Alle Zu“ per Taste habe ich zwar auch, aber dazu benötige ich schon die IPS Logik. Ich habe ein einem Array alle Rollläden definiert und dort jedem Rollladen u.a. eine Gruppe (EG, UG, OG) aber auch den Level für Auf, Beschattung, Zu zugewiesen. Bei Auf und Zu könnte man frage, wozu dies variabel sein muss. Grund ist, dass bei manchen Rollläden Zu (0) nicht ganz zu ist, sondern 0,15, weil wir (meine Frau…) Blumenkästen auf einigen Festerbänken stehen hat und daher der Rollladen in der Küche nicht ganz runter fahren darf.
Ich habe für den betreffenden BROLL keine Meldungen in der CCU - nehme an, Du meinst die Servicemeldungen?
Allerdings habe ich für einen anderen Rollladenaktor (der ist noch altes HM) im EG eine Meldung: „Gerätekommunikation gestört“. Zuletzt gestern Nachmittag, als die Sonnenautomatik Sonne gemeldet hat. Da ist dann die Beschattung nicht runtergefahren. Das ist aber nicht so schlimm, da das Skript alle 5 Minuten läuft und Soll/Ist vergleicht. Sprich, 5 Minuten später ging der Rollladen dann auch in Beschattungs-Level.
Kann „Gerätekommunikation gestört“ auch von Funk-Kollisionen /Dirty Cycles kommen? Oder war dann die Verbindung zu schlecht? Wobei der betreffende Rollladen im EG (Küche) ist und die CCU im Wohnzimmer steht. Dazwischen ist nicht mal eine Türe.
Das kann ich mir nicht vorstellen. HM unternimmt wenn ich mich nicht täusche standardmäßig sechs Sendeversuche bevor aufgegeben wird. Eine schlechte Verbindung schon eher oder etwas dass dort dauerhaft stört.
Vielen Dank für Deine tolle und schnelle Unterstützung.
Gibt es denn eine Möglichkeit, die Signalstärke für HM IP Aktoren abzufragen? Soweit ich über die Suche gelesen habe, geht das nur für HM aber nicht für HM-IP. Bzw für HP-IP nur wenn die Geräte mit der Cloud verbunden sind.
Würde für eine schlechte Verbindung sprechen, wenn der Firmware-Update des BROLLs 1 Tag dauert? Es steht zwar auf der Seite, dass der Update mehrere Tage dauern kann, aber vielleicht ist das ja ein Indikator für Verbindungsprobleme.
Wenn ich wüsste, dass dies das Problem ist, würde ich ein LAN Gateway im OG bzw. im Dachspitz installieren. Aber dazu müsste ich ja erst mal auf CCU3 / Raspberrymatic umsteigen. Dies nur zum Test, ob danach die Verbindung besser ist, zu machen, wäre schon viel Aufwand
ich hatte das Problem mit meinen BROLL auch.
Update dauerte teilweise 2-3 Tage, ist also normal. In der Zeit ist der DutyCycle entsprechend erhöht.
Ich habe es jetzt so gelöst, dass ich im Script nach jedem „Fahrbefehl“ und pro Rollladen danach ein IPS_sleep(500) gesetzt habe.
So habe ich keine „vergessenen“ Rolläden mehr und die halbe Sekunde Verzögerung bis der nächste Rollladen losfährt merkt man ehrlicherweise gar nicht.
bei 13 Rollläden sind es dann insgesamt 6,5 Sekunden Verzögerung vom Start des ersten Rollladen bis der letzte Rollladen losfährt.
IPS_sleep habe ich auch eingefügt um 1 Sekunde zu warten. Allerdings dachte ich, der Wert ist die Zeit in Zehntel-Sekunden. Dank Deiner Angabe habe ich aber festgestellt, dass dies in ms angegeben wird.
Habe dies gerade von 10 auf 1000 erhöht. Mal schauen, ob es damit jetzt zuverlässiger läuft.
Völlig korrekt. Ich habe schon einmal mehr als 1 Woche gewartet bis die neue Firmware auf dem Aktor war und das Update ausgelöst werden konnte.
Mit IPS_Sleep ist das so eine Sache weil in Eurem Beispiel ein PHP-Thread für 6,5 Sekunden blockiert wird. Das mag im Moment noch kein Problem sein aber spätestens wenn das System mal komplexer wird fällt einem das wieder auf die Füsse. Es gab hier von Steiner mal ein Beispiel wie man das mit Scripttimern lösen kann.
Vorher normal auf die CCU gehen und dann die Session-ID aus der Browser URL rüberkopieren.
Ich habe auch ein Script, aber weiß gerade nicht wie einfach das in deinem System integrierbar ist. Falls der Trick oben nicht funzt melde Dich nochmal!
Nachtrag, ich habe über 1 Jahr mit den BROLLs rumgemacht - hinsichtlich Empfang nicht die besten Geräte. Der Eine der gar nicht wollte - da habe ich die Antenne nach außen gelegt (Gehäuse geöffnet und den Drahtstummel durch ein kleines Loch rausgeführt) - seit dem funktionieren die Teile 1A und ohne Sleep!
Hatte ich nicht mehr im Kopf!