Ich hoffe, openHAB stellt die - mangels Threads - grerade nicht ausführbaren Aufgaben einfach hintenan und ignoriert sie nicht komplett?
Dann sehe ich da wenig Probleme.
In der Rules-DSL dürften in der Regel(!) wenig mega-aufwändige Aufgaben abgearbeitet werden, so dass eine Verzögerung um 200 ms weniger tragisch sein dürfte. Wer natürlich gerne mit Thread::sleep arbeitet, bekommt eventuell ernste Probleme.
Ich wollte die Polling-Lösung auch nicht als super-elegant oder die ultimative Lösung hinstellen. Bei mir funktioniert das super und ich habe ziemlich viele Rules, welche teilweise sogar wirklich rechnen (Stromverbrauch). Dennoch konnte ich noch keine Blockade feststellen.
Gibt es eigentlich eine Warnung im Log, wenn man ans Limit kommt?
Ein nicht zu unterschätzender Vorteil beim Polling ist auch dann gegeben, wenn man eine am Reicheweitelimit platzierte Zigbee-Steckdose für die Versorgung des Ambilights benutzt. Wenn das dämliche Ding nämlich mal wieder nicht reagiert, besteht die Chance, dass sie es beim nächsten Polling mitbekommt.
Meine Rule heißt irgendwie so ähnlich wie "AmbilightScheduler". Sie soll zeitgesteuert prüfen, ob die Bedingungen für eingeschaltetes Ambilight gegeben sind oder nicht. Sie prüft dabei den Zustand der aktuellen HarmonyHub-Activity (NvidiaShield, FireTV, BluRay, PowerOFF). Da aber gewisse Familienmitglieder auch mal andere Fernbedienungen benutzen
wird auch noch der Denon direkt über LAN abgefragt (Denon OFF bedeutet immer auch Ambilight OFF).
Das über mehrere Rules zu verteilen gefällt mir persönlich nicht. Deshalb also lieber die Polling-Variante, da diese auch eher meiner logischen Denkweise entspricht.
Aus der Softwareentwickler-Sicht würde ich natürlich (fast) niemals Polling wählen, wenn ich ereignisorientiert arbeiten kann. Hier geht in der Regel Performance vor Lesbarkeit und ja, Polling verbraucht mehr Ressourcen.