Die Lösung ist ganz einfach. Man muss nur einen nicht-störenden Pi einsetzen und hat die Problematik nicht. Die kommt auch bei Dir nicht zum Tragen und hat auch ganz andere Auswirkungen als die Nichtfunktionalität einer einzelnen Taste eines Aktors. Das Problem hat also nichts mit dem von Dir beschriebenen zu tun.
Das kann auch eine ganz andere Ursache haben. Die einfachste wäre, Du hast einen UND-verknüpften virtuellen Kanal in den falschen Status gebracht (im Programm mit irgendeiner seltenen Sonderkonstellation falschen Kanal ausgewählt oder so, so dass die Problematik nur selten auftritt).
Ja was denn nun? DV da oder nicht, verändert oder nicht? Und "viele auftretende Probleme"? Nach meiner Beobachtung eher nicht. Scheinen Einzelfälle zu sein. Ich habe zwar nur einen einzigen BROLL im Produktivbetrieb (RM auf Pi3) und einen in einer Testinstallation (CCU2) und benutze die Tasten eher selten (betreibe Hausautomation mit Schwerpunkt auf "automatisch"), aber einen solchen Ausfall hatte ich noch nicht. Die WebUI zeigt auch keine Auffälligkeiten (deaktivierte Bedienung o.ä.).
Da bei einem Ablernen eines Aktors auch ein Werksreset durchgeführt wird, kann man das wohl per Software auslösen. Ob diese Funktion getrennt vom Ablernvorgang ansprechbar ist, steht auf einem anderen Blatt. Ablernen willst Du den Aktor bestimmt nicht, da er sonst aus allen Programmen fliegt und auch andere DVs gelöscht werden. Somit könnte auch die auf der CCU gespeicherte Konfiguration nicht mehr zurückgeschrieben werden. Und für eine gute Idee halte ich das auch nicht. Aber das ist eine persönliche Geschmackssache.
Das ist aber die einzige Prozedur, einen lokalen auf den Aktor beschränkten Werksreset durchführen zu können. Wichtiger wäre es, die Ursache zu finden und zu beseitigen. Ein erster Ansatz wäre mal, die Status der virtuellen Kanäle und deren Konfigurationen zu prüfen. Einen grundsätzlichen Firmwarefehler würde ich mal weitestgehend ausschließen, denn dann wäre das Problem verbreiteter und würde bei vielen Anwendern auftreten. Hier werden aber nur gaaaanz wenige Einzelfälle berichtet, die nicht mal was miteinander zu tun haben müssen. Ich tippe immer noch auf einen falsch stehenden virtuellen Kanal. Um diese Problematik zu umgehen (weil ich virtuelle Kanäle teils auch als Aussperrschutz benutze), habe ich zusätzliche Direktverknüpfungen der lokalen Tasten zu den virtuellen Kanälen angelegt um durch Handbedienung am Aktor eine mögliche Fehlstellung der virtuellen Kanäle korrigieren zu können. Könnte man auch per WebUI machen, aber ich möchte das lokal im Aktor haben, damit die betreffende Terrassentür als Fluchtweg benutzt werden könnte, solange noch Spannung da ist.
Und das Grundproblem wäre auch mit einem FROLL nicht gelöst, da die lokale Bedienung über die S-Eingänge im Gegensatz zu den intern verbauten Tastern eines BROLL ebenfalls nur als Direktverknüpfungen angelegt sind. Nur der Hardwareaufbau unterscheidet sich etwas. Ich glaube nicht, dass sich die Firmware von FROLL und BROLL in den Grundfunktionen (Einbindung der lokalen Bedienmöglichkeit) groß unterscheidet. Die werden nicht das Rad für eine andere Aktorvariante neu erfunden haben, nur weil dem einen Aktor z.B. eine Stromsensorik zur Erkennung der Endlagen oder die Mirkotaster für die lokale Bedienung fehlen und durch Klemmeingänge ersetzt wurden. Das wird wohl nur in der Firmware und Anzeige deaktiviert und/oder angepasst sein. Ich pflege selbst ein paar kleinere Softwareprojekte (VBA) und recycle auch immer wieder den eigenen Code für andere vergleichbare Zwecke. Ich denke mal, Firmwareentwickler gehen ähnlich vor.
Gruß Xel66
