du hast zwave?
Ja! Nachdem mich eQ-3 nachhaltig verärgert hat, habe ich erst MCU-Programmieren gelernt (MySensors) und bei der Kaufhardware nach Alternativen geschaut. Und die Rollladenaktoren von Fibaro sind VIEL universeller wie alles, was man bisher in Homematic hätte bekommen können. (Jalousie/Venetian-blind-Betrieb per Konfigurationskommando einstellbar, Doppel- und Dreifachklick-Erkennung, "Gate"-Modus in verschiedenen Varianten, ...).
meldet zwave infos zum fahrtstatus? welche (start/stop/up/down/error/...)?
Die melden nur, dass Energie verbraucht wird, "Stillstand" ist "0 W", und das kommt nach dem "state", der auch den dim-Wert beinhaltet (letzteren muss man da per userReading extrahieren).
(Man sieht daran, auch ZWave braucht eine gründlichere Einarbeitung...)
meldet zwave infos, wenn die position nicht mehr stimmt. zb nach device booten?
Wenn die Dinger spannungslos waren, machen (oder brauchen?) sie erst mal eine Kalibrierfahrt. Kein Gefrickel mit der Einstellung der Fahrtdauern...
0.4 habe ich noch nicht gefunden.
0.6.x habe ich gefunden, aber .... 214 seiten a 15 beiträge. 
ich hatte auch keine Lust zum Suchen, war aber eben auch von Anfang an dabei (und hatte nur zwischendurch auch etwas den Faden verloren).
ich bin gespannt!
Ich auch!
übrigens (die entwickler haben das sicherlich auf dem schirm):
Falls du damit mich mit ansprechen willst: bin leider aus den Tiefen schon lange wieder draußen, und der Code ist mir zu verteilt...
wenn das position reading des rollos events-on-update sendet, erzeugt jeder statusrequest am aktor eine neue manuelle fahrt mit entsprechendem blocking. zusätzliche probleme kann es geben, wenn der request nach einer automatischen fahrt kommt, da dadurch dann die letzte automatische fahrt zur letzten manuellen fahrt wird.
wäre es nicht überlegenswert, dass asc von sich aus wiederholungen des position readings filtert?
wenn ich mir so die list der rollos diverser asc-user anschaue, ist das attribut event-on-change im rollo eher sehr selten selten zu sehen.
Dass event-on-change-reading nicht gesetzt ist, ist in der Tat ein häufiger "Fehler" von Neueinsteigern, die dadurch praktisch "alle" aus der Kurve fliegen. Wenn wir das wegbekämen, wäre das vermutlich hilfreich. Andererseits gibt es eben auch eine nicht unerhebliche Zahl von Usern, die das kennen und ggf. auch aktiv für sich nutzen (?).
Prinzipiell sehe ich auch eigentlich kein Problem darin, das aufzugeben und dazu noch einige andere "alte Zöpfe", wie die vermeintlich strikte 10-er-Unterteilung (Attribut-Vorgabe) und/oder das Verbot gleicher Ziel-Werte für verschiedene Zwecke. In den länglichen Threads zur Entwicklung hatte ich mehrfach schon die Auffassung vertreten, dass es eigentlich genügen müßte, jedem "Fahrgrund" eine Priorität zu geben und dann einfach zu schauen, ob bei Eintritt einer Bedingung für "irgendwas" die Position zu ändern wäre oder ob es Gründe gibt, die dagegen sprechen (höhrere Prio für anderen Fahrgrund).
Dass man den Grund ändert, warum ein Rollladen auf einer bestimmten Position steht, bedeutet ja nicht zwangsläufig, dass auch gefahren werden müßte...
