Neues Modul: Rolladensteuerung

Begonnen von ThomasRamm, 11 Januar 2016, 00:00:21

Vorheriges Thema - Nächstes Thema

AndiL

Hallo Tim,

was meinst Du mit manuellem Fahren?
Hast du HM-Taster die mit dem 4-fach Homematic Schalter im Rolladen direkt verheiratet sind?
Falls ja, mußt Du das natürlich löschen und trennen.
Fhem reagiert auf die die HM-Taster und sendet dann den entsprechenden Befehl an an den 4-fach Homematic Schalter, der den Rolladen ansteuert.
So ist Fhem immer im Bilde wie die Rollos stehen, egal wodurch sie bedient wurden.

So schwebt mir das mit den alten FS20 Empfängern vor die ich noch habe. Die Rückmeldung von den Aktoren ist durch dieses Modul völlig entbehrlich.

Gruß
Andi
FHEM 5.8 auf RasPi 3
***********************************
FB 7390, FS20, HM mit USB-CFG, 1-wire (DS1820 und DS2408), Buderus KM200 mit GB 152, Phillips HUE und Bastelkram....

HoTi

Ich habe schon lange vor FHEM eine eigene Steuerung der Rollos mit einem Mega8 drin gehabt.

Diesen habe ich raus geschmissen und an seiner Stelle einen 4Fach HM Aktor eingebaut.

Dessen Interne Tasten ich nun anzapfe für die Rollo direktsteuerung. Diese kann ich nicht vom Aktor an sich trennen und das will ich auch nicht damit meine Frau die Rollos auch ohne funktionierendes Fhem fahren kann.

Das Problem ist jetzt nur das ich bei manuellen Fahren ich die Position nicht kenne.
Da habe ich mich an Perl versucht und die Wiki Einträge gelesen usw. Das ist zu hoch für mich.

Viele Grüße aus Oberbayern

Mobil vom Smartphone aus gesendet. Deswegen kurz gehalten.

Viele Grüße aus  Oberbayern
Tim (RettungsTim)

ThomasRamm

Zitat von: RettungsTim am 11 Januar 2016, 13:34:12

hätte da gerne ein Problem :-D

2016.01.11 13:25:28 1: PERL WARNING: "my" variable $value masks earlier declaration in same scope at ./FHEM/44_ROLLO.pm line 139.
2016.01.11 13:25:37 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at ./FHEM/44_ROLLO.pm line 141.
2016.01.11 13:26:55 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at ./FHEM/44_ROLLO.pm line 180.
2016.01.11 13:26:55 3: DEBUG: set EG_wz_RO_li_RUNTER on
2016.01.11 13:26:55 3: set EG_wz_RO_li_HOCH on


Den ersten Hinweis kannst du beheben indem du Zeile 139 das my entfernst (da du den Code schon geändert hast ist dies wohl der einfachste weg:
my $value = "";
my $value = $a[2] if defined $a[2]; #join("", @a);


wird zu
my $value = "";
$value = $a[2] if defined $a[2]; #join("", @a);


Warnung 2+3 betrifft nur das Logging, in beiden Fällen sagt er das kein Wert ausgelesen wurde,. Weiß aktuell noch nicht woran das bei dir liegen könnte, hat aber keine Auswirkung auf die Funktionsweise.

ThomasRamm

#18
Folgende Wünsche/Anregungen sind aktuell offen:

1. Einstellbare Arbeitsweise der Kanäle:
Version 1 (default)
Kanal1 Kanal2  Fahrtrichtung
on       off         hoch
on       on         runter
off                    stop

Version 2 (manuelle änderung am Threadanfang beschrieben)
Kanal1 Kanal2  Fahrtrichtung
on       off         hoch
off       on         runter
off       off         stop

Version 3 mit nur einem Kanal (hoffe ich habe das mit dem FS20rsu so richtig verstanden)
set xy on = hoch
set xy on = stop (also 2. senden eines on stoppt den fahrenden Rollo)
set xy off = runter
set xy off = stop (während er runter fährt ein set xy off stoppt den fahrenden Rollo)

2. Status aktualisieren bei Benutzung eines externen Tasters
Das Modul speichert den aktuellen Status in Readings. Wenn dein Tastendruck in fhem ein Event auslöst könnte man ja die entsprechenden Readings aktualisieren.
Ginge vermutlich auch über ein notify, kann ich aber noch ins Modul übernehmen.
Was genau kann denn über die Taster gesendet werden?
Fährst du mit den Tastern immer komplett hoch/runter?
Eine Idee wäre ein neuer set-Befehl korrigierePosition [nn] mit dem nur der fhem status aktualisiert wird.
Wird dein Taster gedrückt kann man dann set myRollo korrigierePosition 100 (100=zu) aufrufen und fhem zeigt dein Rollo als geschlossen an.

3. toggle
set myRollo toggle fährt das Rollo in die gegengesetzte Richtung wie bei letzter Fahrt.

Ich denke alle drei Themen sind sinnvoll und umsetzbar.
Einzig bei Version3 der Kanalansteuerung bin ich mir noch recht unsicher ob das so einfach umsetzbar ist.

Updates folgen jeweils wenn ich eines der Anforderungen umgesetzt habe.
Erstes Update anbei, in dem die Warning Zeile 139 korrigiert wurde (ändert aber nichts an der Funktionsweise/stabilität, ist nur eine Schönheitskorrektur im Log

Gruß
Thomas

AndiL

#19
Hallo Thomas,

erst mal  Danke, daß Du meinen Toggle-Wunsch aufgenommen hast.

Ich wollte schon mal mit der Einrichtung loslegen, bin aber leider ausgebremst worden.
Die 44_Rollo.pm wird nicht in Fhem geladen.


2016.01.12 20:02:14 1: reload: Error:Modul 44_ROLLO deactivated:
Bareword "port" not allowed while "strict subs" in use at ./FHEM/44_ROLLO.pm line 295.
Bareword "ab" not allowed while "strict subs" in use at ./FHEM/44_ROLLO.pm line 295.


Es handelt sich um die unveränderte 44_ROLLO.pm aus deinem letzten Post vom 18:02.

Gruß
Andi
FHEM 5.8 auf RasPi 3
***********************************
FB 7390, FS20, HM mit USB-CFG, 1-wire (DS1820 und DS2408), Buderus KM200 mit GB 152, Phillips HUE und Bastelkram....

ThomasRamm

Der Fehler ist reingerutscht als ich den anderen Fehler beheben wollte.

anbei die aktuellste Version, inklusive toggle-Funktionalität.

Es gibt ein neuen state-Befehl "Fahrtrichtung" mit dem die letzte Fahrt ausgelesen werden kann, und die auch für den toggle-Befehl benutzt wird.
Habe außerdem einen kleinen Bug behoben der auftreten konnte wenn das Rollo gerade herunterfährt und dann während der Fahrt auf "offen" gestellt wird.

Der Dateianhang im ersten Post ist aktualisiert

Gruß
Thomas

ThomasRamm

Die zweite Art der Kanalansteuerung ist integriert, es gibt einen weiteren optionalen Parameter in der definition, als wert wird Typ1 (bisheriger standard) oder Typ2 (siehe die ersten posts im thread) akzeptiert.
Der erste post im Thread wurde entsprechend aktualisiert.

Würde mich über eine Rückmeldung freuen ob Typ2 so funktioniert, kann ich nicht komplett testen, da ja meine Rollo anders funktionieren.

Gruß
Thomas

miche

Hallo,

ich kann dann nur den FS20 Typ testen.
Du hast es auch richtig verstanden.
ON-> auffahren
2. ON-> stop

OFF-> zufahren
2. OFF-> stop

Wenn währen des Fahrens der die andere Richtung gedrückt wird, wird gestoppt und die Richtung gewechselt

HoTi

Hallo,

erstmal vielen Dank für die Aufnahme und bisherige Umsetzung der Wünsche. Es ist doch gar nicht mehr Weihnachten. 8)

Also zum Typ:
Das funktioniert einwandfrei, was mich ein wenig stört ist das du obwohl der jeweils andere Kanal aus ist, ihn nochmal ausschaltest. Das erhöht die Funklast, kannst du das vermeiden?
Wäre es nicht besser die Typ-Auswahl als Attribut zu hinterlegen?

Allgemein:
Als Anregung: Wie wäre es wenn das Device, Kanal 1 und Kanal 2 auch als Attribut hinterlegt werden, statt bei der Definition? Siehe 39_STELLMOTOR.pm welches hier schon erwähnt wurde.

Ich will nicht dass es hier als nörgeln oder sonst irgendwas rüber kommt, es ist einfach ein super Modul welches du gebaut hast und will nur Anregungen geben wie es noch besser werden kann (in meinen Augen).

Also bitte nicht böse sein, wenn ich hier was verzapfe.
Wenn ich helfen kann, mache ich das jederzeit gerne!
Viele Grüße aus  Oberbayern
Tim (RettungsTim)

AndiL

Uiii, geht das hier schnell. Ich bin begeistert.
Da muß ich mir die Woche gleich mal einen Testaufbau machen.
Der Ansteuer-Typ2 ist übrigens bestens geeignet um die Velux Dachrolläden mit Polwendung zu betreiben.

Dem Wunsch mit den Attributen für Typ und Kanäle vom Kollegen würde ich mich gerne anschließen.

Ich weiß. Gibst du den kleinen Finger, wird dir der ganze Arm abgerissen ;D

Gruß
Andi

PS: Das Modul ist so praktisch und hilfreich, das sollte auf jeden Fall eingecheckt werden.
FHEM 5.8 auf RasPi 3
***********************************
FB 7390, FS20, HM mit USB-CFG, 1-wire (DS1820 und DS2408), Buderus KM200 mit GB 152, Phillips HUE und Bastelkram....

ThomasRamm

Bezüglich der Attribute:
wo liegt denn da der Vorteil? Sowohl ports als auch Typ ist doch etwas was nach der Definition nie wieder geändert wird.
Ein Nachteil ist ganz klar das das Vorhandensein der Attribute jedes mal geprüft werden muss, da man sie versehentlich mit einem klick löschen könnte.
Und wenn du doch mal Typ oder Port ändern musst kannst du das in der Oberfläche im nachhinein ja auch noch machen, klick auf den Eintrag def und die Parameter entsprechend ändern.

Bezüglich dem zusätzlichen OFF-Schalten:
Wenn ich den zweiten Kanal nicht OFF schalte, dann ist er doch immer noch ON, woher weiß mein Rollo dann in welche Richtung er fahren soll? Oder steckt da noch mehr Logik hinter?
Bei mir sind es ganz einfache Relais die solange in ihrem Status bleiben bis ich per fhem was anderes sage.

Bezüglich FS20rsu-Modul:
kommt, bin aber die nächsten 2 Tage unterwegs. Evlt. werde ich mal versuchen das "blind" zu erweitern.
Kommt diesmal aber nicht als Typ=Typ3 sondern als Typ=FS20rsu.
Da es hier einen eindeutigen Namen gibt würde ich den auch verwenden wollen, bei der Unterscheidung Typ1 und Typ2 sind mir einfach keine Aussagekräftigen Namen eingefallen.

Gruß
Thomas

HoTi

#26
Zitat von: ThomasRamm am 13 Januar 2016, 10:39:00

Bezüglich dem zusätzlichen OFF-Schalten:
Wenn ich den zweiten Kanal nicht OFF schalte, dann ist er doch immer noch ON, woher weiß mein Rollo dann in welche Richtung er fahren soll? Oder steckt da noch mehr Logik hinter?
Bei mir sind es ganz einfache Relais die solange in ihrem Status bleiben bis ich per fhem was anderes sage.


Hallo Thomas,

bei meinem Gräten sieht das so aus, als ob du wenn du 0 1 schalten willst Kanal1 erst auf 0 schaltest und dann Kanal2 auf 1. Unabhänging ob Kanal1 0 oder 1 ist.

Wenn ein Kanal schon den Wert hat, dann brauche ich den doch nicht nochmal schalten?!

2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Define redefined at ./FHEM/44_ROLLO.pm line 64.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Undef redefined at ./FHEM/44_ROLLO.pm line 111.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Set redefined at ./FHEM/44_ROLLO.pm line 126.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Start redefined at ./FHEM/44_ROLLO.pm line 182.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Stop redefined at ./FHEM/44_ROLLO.pm line 319.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine calculateDriveTime redefined at ./FHEM/44_ROLLO.pm line 363.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Get redefined at ./FHEM/44_ROLLO.pm line 392.
2016.01.13 10:46:14 1: PERL WARNING: Subroutine ROLLO_Attr redefined at ./FHEM/44_ROLLO.pm line 430.
2016.01.13 10:46:50 3: DEBUG: set   EG_wc_RO_mi_SW_01 off
2016.01.13 10:46:50 3: DEBUG: set   EG_wc_RO_mi_SW_02 on
2016.01.13 10:46:50 3: CUL_HM set EG_wc_RO_mi_SW_01 off
2016.01.13 10:46:50 3: CUL_HM set EG_wc_RO_mi_SW_02 on
2016.01.13 10:47:00 3: CUL_HM set EG_wc_RO_mi_SW_02 off
2016.01.13 10:47:03 3: DEBUG: set   EG_wc_RO_mi_SW_02 off
2016.01.13 10:47:03 3: DEBUG: set   EG_wc_RO_mi_SW_01 on
2016.01.13 10:47:03 3: CUL_HM set EG_wc_RO_mi_SW_02 off
2016.01.13 10:47:03 3: CUL_HM set EG_wc_RO_mi_SW_01 on
2016.01.13 10:47:13 3: CUL_HM set EG_wc_RO_mi_SW_01 off


Zitat von: ThomasRamm am 13 Januar 2016, 10:39:00
Bezüglich der Attribute:
wo liegt denn da der Vorteil? Sowohl ports als auch Typ ist doch etwas was nach der Definition nie wieder geändert wird.
Ein Nachteil ist ganz klar das das Vorhandensein der Attribute jedes mal geprüft werden muss, da man sie versehentlich mit einem klick löschen könnte.
Und wenn du doch mal Typ oder Port ändern musst kannst du das in der Oberfläche im nachhinein ja auch noch machen, klick auf den Eintrag def und die Parameter entsprechend ändern.

Da hast du nicht unrecht! Es ist reine gewohnheitssache aus anderen Modulen.


------------

Sollte es bei dem CMD's nicht heißen: öffnen schließen schlitz  8)

Viele Grüße aus  Oberbayern
Tim (RettungsTim)

ThomasRamm

Hallo,
habe mal eine entsprechende Abfrage für die off-Befehle auf den aktuellen Status eingefügt.
Da ich gerade keine Möglichkeit habe das ganze zu testen (nur reinen texteditor zur Hand) kann es aber sein das es eine Fehlermeldung gibt.
Typisch für mich sind vergessene ; am Zeilenende oder ( statt {, etc.

zum testen kannst du mich auch direkt anschreiben, dann müssen wir den Thread nicht mit Kleinigkeiten zuhauen und können uns auf funktionierende Versionen beschränken

Gruß
Thomas

ThomasRamm

Zitat von: RettungsTim am 13 Januar 2016, 10:45:12
Sollte es bei dem CMD's nicht heißen: öffnen schließen schlitz  8)

Ja ginge auch. Ich habe mich aber gegen Verben entschieden, da die cmd Positionen darstellen sollen, die das Rollo anfahren soll.
Eigentlich gibt es nur 2 "echte" cmd: position und stop.
offen,geschlossen,schlitz sind hinterlegte Namen für die cmd: "position 0", "position 100", "position 90" (beliebige weitere Namen können hinzugefügt werden wie z.B. beschattung=70 etc.).
Ich hätte auch schreiben können oben,unten,schlitz

Gruß
Thomas

grappa24

... genau das, was ich gerade für meine Visualisierung mit smartVISU suche ... ;)

Ich hab allerdings eine EIB/KNX-Rollo-Steuerung und (nur) folgende Befehle zur Verfügung:

- set EIB_3207 on (Rollo runterfahren)
- set EIB_3207 off (Rollo hochfahren)
- set EIB_3208 on/off (Rollo Stop)

Thomas, kann ich da drauf mit Deinem Modul aufsetzen, wie setze ich das auf Deine Kanalsteuerung um?
FHEM 6.1, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...