Modul-Entwicklung: Somfy RTS

[stefanru]

Hi andies,

kurzfassung.

Du musst zuerst das Device wie du es auch schreibst anlegen.
Dann musst du per handsender deinen Rollo in den Prog modus bringen (Prog taste am Handsender drücken bis der Rollo mit kurzer auf/ab bewegung bestätigt).
Der Rollo ist nun lernwillig.

Nun musst du im FHEM an deinem device per set den prog Befehl senden. Damit deine "virtuelle"/"neue" Fernbdienung vom FHEM auch eingelernt wird.
Der Rolladen sollte wieder mit auf/ab Bewegung bestätigen.
Das ist dass Zeichen dass er nun auch deine FHEM Fernbedienung akzeptiert. Er kennt dann also 2 Stück.

Gruß,
Stefan

[andies]

Vielen Dank, hat geklappt.

[habeIchVergessen]

@viegener: Weiterentwicklung SOMFY

aktuell wird pro Fernbedienung ein SOMFY-Device angelegt. Diese entspricht nicht dem Status eines Rollladens, der durch mehrere Fernbedienungen verändert werden kann.

Auch Gruppen (mehrere Blind reagieren auf eine ID) sind denkbar.

Hältst du eine entsprechende Erweiterung für machbar (mehrere IDs nebst Enc-Key und Rolling-Code an einem Device verwalten; entsprechende Management-Funktion zum zusammen führen; etc.)?

[viegener]

@habeIchVergessen: Ja ein solcher Umbau ist denkbar. Da sich im Somfy-Modul inzwischen sehr viel historischer Code angesammelt hat, würde ich dazu das Modul wohl in grossen Teilen neu schreiben.

Das Konzept Der multiplen Adressen müsste aber noch überlegt werden, ob wirklich die verschiedenen Adressen in einem Device sein sollten oder ob man auf eine Kopplung zwischen verschiedenen Devices setzt.

Dabei würden sich auch ein paar andere Dinge umsetzen lassen, die schon länger angedacht waren.

[Garbsen]

@habeIchVergessen: Ja ein solcher Umbau ist denkbar. Da sich im Somfy-Modul inzwischen sehr viel historischer Code angesammelt hat, würde ich dazu das Modul wohl in grossen Teilen neu schreiben.

Das Konzept Der multiplen Adressen müsste aber noch überlegt werden, ob wirklich die verschiedenen Adressen in einem Device sein sollten oder ob man auf eine Kopplung zwischen verschiedenen Devices setzt.

Dabei würden sich auch ein paar andere Dinge umsetzen lassen, die schon länger angedacht waren.

Das Bessere ist zwar immer der Feind des Guten, aber umfangreiche Änderungen an Modulen bergen natürlich auch immer die Gefahr von neuen Fehlern, nicht vorhergesehenen Änderungen im Verhalten bei komplexen Einrichtungen etc.
Wunsch/Vorschlag:
Kannst Du beim Neuschreiben die alte und die neue Version parallel laufen lassen? D.h. Quasi ein Somfy_Neu Modul?
Dann könnten wir dummen Anwender die Neuerungen schrittweise ausprobieren, ohne Gefahr zu laufen, dass die bestehende Rolladensteuerung zu spinnen an fängt. Ist ja ein durchaus kritischer Teil der Haussteuerung, der bei Fehlfunktionen den Ärger der gesamten Familie auf sich zieht und bei dem Fehlverhalten immer möglichst schnell abgestelltwerden sollte.

[habeIchVergessen]

dann schlage folgende Arbeitshypothese bzgl. der Rollos (R1 - R4) und Fernbedienungen (FB physikalisch; FE logische in FHEM) vor.

Pro Rollo können max. 12 FBs angelernt werden.

ID	Beschreibung	R1	R2	R3	R4
000FB0	phys. FB Kanal 1	x
000FB1	phys. FB Kanal 2		x
000FB2	phys. FB Kanal 3	x	x
000FB3	phys. FB Kanal 4		x	x	x
111FE0	log. FB fhem	x
111FE1	log. FB fhem		x
111FE2	log. FB fhem			x
111FE3	log. FB fhem				x
222FE0	Gruppe Wohnzimmer	x	x
222FE1	Gruppe Küche			x	x
222FE2	Gruppe Südseite	x		x
222FE3	Gruppe Sichtschutz	x	x
222FE4	Gruppe Alle	x	x	x	x

[viegener]

dann schlage folgende Arbeitshypothese bzgl. der Rollos (R1 - R4) und Fernbedienungen (FB physikalisch; FE logische in FHEM) vor.

Pro Rollo können max. 12 FBs angelernt werden.

ID	Beschreibung	R1	R2	R3	R4
000FB0	phys. FB Kanal 1	x
000FB1	phys. FB Kanal 2		x
000FB2	phys. FB Kanal 3	x	x
000FB3	phys. FB Kanal 4		x	x	x
111FE0	log. FB fhem	x
111FE1	log. FB fhem		x
111FE2	log. FB fhem			x
111FE3	log. FB fhem				x
222FE0	Gruppe Wohnzimmer	x	x
222FE1	Gruppe Küche			x	x
222FE2	Gruppe Südseite	x		x
222FE3	Gruppe Sichtschutz	x	x
222FE4	Gruppe Alle	x	x	x	x

ich muss zu geben ich verstehe das oben nicht, speziell was die Frage angeht, ob die Fernbedienungen eigene Geräte sein sollten.
Nach dem HM-Konzept wären ein Motor/Aktor und eine FB - 2 Devices zwischen denen ein Peering existiert und zusätzlich gäbe es eine virtuelle FB, die in FHEM zum Steuern verwendet werden kann...

Wenn man das auflöst und der Motor repräsentiert einen Device mit allen FB, dann hat das andere Vorteile (# devices / einfachererer Umbau / ...)

[habeIchVergessen]

ich hatte versucht darzustellen, welches Rollo von welcher Fernbedienung gesteuert wird.
Nur eine fiktives Anwendungsszenario, dass die Ausgangssituation und zu betrachtende Kombinatorik darstellt.

[viegener]

OK, verstanden.

Mein Ansatz wäre, dass es zwei Arten von Somfy-Devices gibt
a) Aktoren - diese haben einen Status, der die Position des Rollos, Markis, Rolladen angibt - Jeder Aktor hat auch eine Adresse, die von FHEM benutzt wird um den Aktor zu steuern
b) Reine Fernbedienungen- diese haben die Adresse aus der FB und können mit einem oder mehreren Aktoren gepeered sein - Liste von Aktor-Adressen

Pro Adresse nur ein Device - Identifikation des devices über die Adresse (nicht über Namen)
Beide Devicetypen haben dieselbe rolling-code/etc - Logik / Autocreate wäre möglich

Einziges Szenario, dass ich bisher sehe, dass nicht abgebildet werden kann sind mehrere Aktoren, die man anfangs als Einheit anlegt (Typ a - ein Device) und später trennen möchte

Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden

Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen

Zu dem oben aufgebrachten Punkt: Nein ich würde wohl kein Somfy_Neu danebenstellen, sondern einen ausgiebigen Betatest veranstalten. Dann kann es eine automatische Migration geben, die Zuordnung für Parse würde funktionieren. Trotzdem wären Nacharbeiten erforderlich, da es doch einige Änderungen geben würde (siehe offene Punkte)

Das mal so als ad hoc design 

[Ellert]

OK, verstanden.

Mein Ansatz wäre, dass es zwei Arten von Somfy-Devices gibt
a) Aktoren - diese haben einen Status, der die Position des Rollos, Markis, Rolladen angibt - Jeder Aktor hat auch eine Adresse, die von FHEM benutzt wird um den Aktor zu steuern
b) Reine Fernbedienungen- diese haben die Adresse aus der FB und können mit einem oder mehreren Aktoren gepeered sein - Liste von Aktor-Adressen

Pro Adresse nur ein Device - Identifikation des devices über die Adresse (nicht über Namen)
Beide Devicetypen haben dieselbe rolling-code/etc - Logik / Autocreate wäre möglich

Einziges Szenario, dass ich bisher sehe, dass nicht abgebildet werden kann sind mehrere Aktoren, die man anfangs als Einheit anlegt (Typ a - ein Device) und später trennen möchte

Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden

Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen

Zu dem oben aufgebrachten Punkt: Nein ich würde wohl kein Somfy_Neu danebenstellen, sondern einen ausgiebigen Betatest veranstalten. Dann kann es eine automatische Migration geben, die Zuordnung für Parse würde funktionieren. Trotzdem wären Nacharbeiten erforderlich, da es doch einige Änderungen geben würde (siehe offene Punkte)

Das mal so als ad hoc design 

@viegener
Tatsächlich verhält es sich etwas anders.

1. Es gibt Fernbedienungen und Aktoren.

1.1 Hardware-Fernbedienungen (Schaltuhren, Handsender, Windwächter, Sonnenwächter, usw.) besitzen Adressen. Jede Adresse verhält sich wie eine Fernbedienung und kann Up, Down, Stop, Programm senden.

1.2 Es gibt virtuelle Fernbedienungen, die FHEM-Somfy-Geräte, denen der Benutzer eine beliebige Adresse zuweist. Beliebig insofern als es eine gültige Somfy-Adresse sein muss und keine der Hardware-Fernbedienungen diese Adresse besitzt.

2 Aktoren habe keine Adresse, sie müssen die Adressen der Fernbedienungen lernen (von Hardware und FHEM-Somfy-Geräten), von denen Sie gesteuert werden sollen (maximal 25 Adressen kann ein Aktor lernen).

Ein aktuelles FHEM-Gerät des Somfy-Moduls bildet eine Fernbedienung nach (Senden von Up, Down, Stop, Programm) und bildet einen Aktor nach (Richtungs- und Positionsangaben). Es sind aber nur die Fernbedinungs-Komponente des Gerätes mit der Aktorkomponente des gleichen Gerätes verknüpft.

Die Aktor-Komponente müsste so erweitert werden, dass sie die Adressen von anderen Fernbedienungen lernen kann (durch manuellen Eintrag), damit die Aktor-Komponente des Gerätes reagieren kann. (Für den FHEMduino ist das ja ansatzweise schon realisiert.)

[viegener]

@viegener
Tatsächlich verhält es sich etwas anders.

1. Es gibt Fernbedienungen und Aktoren.

1.1 Hardware-Fernbedienungen (Schaltuhren, Handsender, Windwächter, Sonnenwächter, usw.) besitzen Adressen. Jede Adresse verhält sich wie eine Fernbedienung und kann Up, Down, Stop, Programm senden.

1.2 Es gibt virtuelle Fernbedienungen, die FHEM-Somfy-Geräte, denen der Benutzer eine beliebige Adresse zuweist. Beliebig insofern als es eine gültige Somfy-Adresse sein muss und keine der Hardware-Fernbedienungen diese Adresse besitzt.

2 Aktoren habe keine Adresse, sie müssen die Adressen der Fernbedienungen lernen (von Hardware und FHEM-Somfy-Geräten), von denen Sie gesteuert werden sollen (maximal 25 Adressen kann ein Aktor lernen).

Ein aktuelles FHEM-Gerät des Somfy-Moduls bildet eine Fernbedienung nach (Senden von Up, Down, Stop, Programm) und bildet einen Aktor nach (Richtungs- und Positionsangaben). Es sind aber nur die Fernbedinungs-Komponente des Gerätes mit der Aktorkomponente des gleichen Gerätes verknüpft.

Die Aktor-Komponente müsste so erweitert werden, dass sie die Adressen von anderen Fernbedienungen lernen kann (durch manuellen Eintrag), damit die Aktor-Komponente des Gerätes reagieren kann. (Für den FHEMduino ist das ja ansatzweise schon realisiert.)

Deshalb habe ich geschrieben das wäre MEIN Ansatz, denn natürlich ist mir klar, dass Aktoren keine Adresse haben

IM Somfy-Modul ist es heute so konzipiert, dass sie virtuelle FB und Aktor in einem Device repräsentieren (implizit gepeered innerhalb des moduls) - das sollte man auch nicht trennen, denn dann wäre Status des Aktors und deren Bedienung nicht mehr im selben Device - das wäre nicht sinnvoll.
Heir ist SOmfy halt anders als HM und andere, da keine Aktor-ID/Adresse existiert.

Ich glaube aber Du meinst vermutlich dasselbe wie ich - Nur schlage ich vor weitere Fernbedienungen (oder in meiner Beschreibung REINE Fernbedienungen) auch als separate Devices anzulegen und nur einmal RollingCode per Device zu haben und die Verbindung zwischen Reiner FB (Typ b) und Aktor+FB (Typ a) als "Peering" zu gestalten

[Ellert]

Ja, jetzt sehe ich auch, dass wir beide das Gleiche meinen.

Aktor a) ist der virtuelle Aktor des FHEM-Gerätes, das auch die FHEM Fernbedienung (mit selbst festgelegter Adresse) darstellt.
Fernbedienung b) ist das per autocreate angelegte Gerät der Hardware Fernbedienung.

Fernbedienung b) (und ggf. weitere reine FB) müsste mit dem Aktor a) gepeert werden.

Damit ist die Übereinstimmung hergestellt.

[viegener]

Ja, jetzt sehe ich auch, dass wir beide das Gleiche meinen.

Aktor a) ist der virtuelle Aktor des FHEM-Gerätes, das auch die FHEM Fernbedienung (mit selbst festgelegter Adresse) darstellt.
Fernbedienung b) ist das per autocreate angelegte Gerät der Hardware Fernbedienung.

Fernbedienung b) (und ggf. weitere reine FB) müsste mit dem Aktor a) gepeert werden.

Damit ist die Übereinstimmung hergestellt.

Das klingt gut!

Dann nochmal die offenen Punkte für die weitere Diskussion:

Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden

Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen

Meinungen und Vorschläge sind willkommen !
(Und ich habe noch keine Ahnung wann ich die Zeit für den Umbau hätte, beim Blick in den Code kann ich sagen, dass der Aufwand auch stark von den Altlasten / Migrationsaufwänden ab)

[habeIchVergessen]

LaCross verwaltet intern (glaube DevPtr) eine zentrale Liste aller bekannten IDs. Wären für Somfy dann die FBs, die weiterhin einmalig EncKey und RollingCode verwalten.

Die eigentlichen Devices wären dann die nur noch die Rollos mit einer Liste der assoziierten FBs.

Interessant wird es, wenn mehrere Rollos einer FB zugeordnet sind (Gruppe).
Ist das ein eigenständiges Device?
Mit Statusanzeige?
Was zeigt diese an, wenn erst die Gruppe geschlossen und anschließend ein einzelnes Rolle wieder geöffnet wird?

[Ellert]

Das klingt gut!

Dann nochmal die offenen Punkte für die weitere Diskussion:

Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden

Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen

Meinungen und Vorschläge sind willkommen !
(Und ich habe noch keine Ahnung wann ich die Zeit für den Umbau hätte, beim Blick in den Code kann ich sagen, dass der Aufwand auch stark von den Altlasten / Migrationsaufwänden ab)

Lt. Statistik gibt es 173 Installationen, die das Somfy-Modul nutzen und kaum Probleme aufzeigen, daher würde ich am Modul nur kleine Änderungen vornehmen und ein neues Modul verwerfen.

Zunächst vielleicht erstmal die per autocreate angelegten Hardware-Fernbedienungen auf die Aktorenkomponente der reinen FB mappen.
Also

HWFB:parsestate => reineFB:state
  "off"  => "open",
  "on"   => "closed",
  "stop" => "go-my"
  "prog" => "prog"

damit wäre eine Grundlegende Verknüpfung erreicht.