[73_AutoShuttersControl] Jalousien:Lamellen steuern -Version 0.9.x Beta

[xerion]

Von der Konfiguration her hast Du nichts geändert?

Wenn nicht starte mal bitte FHEM neu. Danke

Meinst du allgemein verändert oder im Bezug auf ASC und Rollläden?

Gesendet von meinem JSN-L21 mit Tapatalk

[CoolTux]

Ich meine an den Attributen für die Positionen

[xerion]

Ich meine an den Attributen für die Positionen

Nein daran habe ich nichts geändert.

[CoolTux]

Nein daran habe ich nichts geändert.

Ok dann wie gesagt bitte neustart und weiter beobachten. Ansonsten müssen wir bei dir debuggen wo das her kommt. Ich habe auch keine Lamellen und bekomme den Fehler nicht.

[GU!DO]

Hallo Marko,

ich hatte ja im anderen Thread angefragt ob Du noch Tester gebrauchen kannst. Aktuell bin ich noch bei der Grundkonfiguration des ASC, wollte mich hier aber schon mal parallel einlesen.

Ich werden aus Deinem ersten Post leider nicht wirklich schlau. Vor allem die Geschichte mit dem slatCMD verstehe ich nicht.

Meine Steuerung funktioniert wir folgt:

• Ich habe 2 Taster UP und DOWN
• Wenn ich die Lamellenposition ändern möchte, gehe ich wie folgt vor:
  
  
  
  • Ich fahre bis zur gewünschten Position z.B. DOWN
  • Dann fahre ich kurz entgegensetzt zur Positionsfahrt (in diesem Fall dann UP), da sich die Lamellen drehen bevor das Raffstore endgültig in die neue Richtung losfährt

Ich steuere entweder direkt im Device (das war die HCAN Anbindung bei der Du mir mal unter die Arme gegriffen hast, und die - mangels Zeit leider immer noch - auf rudimentärem Stand ist)
oder mittel Rollo Device.

D.h. eigentlich benötige ich 2 Befehle aus dem ASC:

• Einen Positionsbefehl
• Einen entgegengesetzten kurzen "Lamellen drehen"-Befehl. Wobei die Zeispanne dieses "Fahrbefehls" dem Drehwinkel der Lamellen entspricht.

Kann ich das mit dem ASC umsetzen, oder muß ich erstmal meinem HCAN Modul beibringen, dass es z.B. mit, "Du fährst jetzt auf Position X und Lamellenwinkel Y" etwas anfangen kann?

Vielen Dank

Guido

[Beta-User]

@GU!DO: Das ist das selbe Thema wie bei meinen "Nicht-Jalousien-CUL_HM"-Aktoren. Das kann ASC derzeit nicht und mMn. ist es auch sehr schwer, das ASC beizubringen.

Meine derzeitige gedankliche Lösung wäre, über den "Zweitkanal" ein notify zu triggern und dann die notwendigen "Zu-Viel-Fahrten" (bzw. zu wenig-Fahrten) samt Gegenbewegung (umgesetzt als "sleep" mit Warten auf Erreichen der (im notify zu errechnenden) Zwischenposition) extern abzuwickeln. Für ASC ist ja "nur" wichtig, dass am Ende die Zielposition wieder korrekt ist.

(Ich komme nur im Moment nicht dazu, das mal zu vercoden; aber wenn es jetzt außer mir noch jemanden gibt, ist das evtl. Motivation...?!? Wäre mir aber lieber, du könntest das angehen, gerne in einem separaten Thread.).

[GU!DO]

 @Beta-User
Die Notify Lösung wäre für mich ein ziemlicher Umstand. Da ich viel Glas habe, habe ich auch viele Raffstore. Aktuell sind es 33. Wenn ich die geplante Beschattung der schrägen Fenster in den Giebeln umsetze kommen im Endausbau nochmal 26 Raffstore hinzu, da ich Fenster über 1,2m Breite auf mehrere Raffstores aufteilen muß.
Das wären dann wenn es "ganz schlecht läuft" 59 Notifies. Daher wäre es für mich sinnvoller mein HCAN Modul zu erweitern. Wenn ich nur die Zeit hätte.

Hinzu kommt, dass sich, das Bisschen das ich bisher (mangels Zeit) mit FHEM gemacht habe auf die letzten 4 Jahre verteilt. Ich muß teilwiese immer wieder Grundlagen nachlesen, da ich sie nicht präsent habe. Ich glaube ich würde das Projekt mehr behindern als ihm nutzen. Bringe mich aber gern ein soweit es geht.

[CoolTux]

Hallo Marko,

ich hatte ja im anderen Thread angefragt ob Du noch Tester gebrauchen kannst. Aktuell bin ich noch bei der Grundkonfiguration des ASC, wollte mich hier aber schon mal parallel einlesen.

Ich werden aus Deinem ersten Post leider nicht wirklich schlau. Vor allem die Geschichte mit dem slatCMD verstehe ich nicht.

Meine Steuerung funktioniert wir folgt:

• Ich habe 2 Taster UP und DOWN
• Wenn ich die Lamellenposition ändern möchte, gehe ich wie folgt vor:
  
  
  
  • Ich fahre bis zur gewünschten Position z.B. DOWN
  • Dann fahre ich kurz entgegensetzt zur Positionsfahrt (in diesem Fall dann UP), da sich die Lamellen drehen bevor das Raffstore endgültig in die neue Richtung losfährt

Ich steuere entweder direkt im Device (das war die HCAN Anbindung bei der Du mir mal unter die Arme gegriffen hast, und die - mangels Zeit leider immer noch - auf rudimentärem Stand ist)
oder mittel Rollo Device.

D.h. eigentlich benötige ich 2 Befehle aus dem ASC:

• Einen Positionsbefehl
• Einen entgegengesetzten kurzen "Lamellen drehen"-Befehl. Wobei die Zeispanne dieses "Fahrbefehls" dem Drehwinkel der Lamellen entspricht.

Kann ich das mit dem ASC umsetzen, oder muß ich erstmal meinem HCAN Modul beibringen, dass es z.B. mit, "Du fährst jetzt auf Position X und Lamellenwinkel Y" etwas anfangen kann?

Vielen Dank

Guido

Hallo Guido,

Wie schon gesagt funktioniert ASC ausschließlich mittels Positionsangaben. So wie Du es beschreibst scheint allein schon die normale Steuerung ein Problem zu werden. Also einfach nur das auf und zu ziehen. Oder geht das bei Dir?

[Beta-User]

@Beta-User
Die Notify Lösung wäre für mich ein ziemlicher Umstand.

Bin eher auch für generalisierten Code .

Hier mal eine Basis:

Wir brauchen _einen_ zentralen dummy. Der ist "für alle da" und eigentlich nur erforderlich, damit der set-Command irgendwo ankommt:

Code Auswählen Erweitern

defmod d_Jalousie_slats dummy

Der wird dann das Ziel für die Lamellenposition. Und damit wir wissen, zu welcher Jalousie das gehört, wird der Name einfach statt der "pct"-Angabe mitgegeben:

Code Auswählen Erweitern

attr Jalousie_Mitte ASC_SlatPosCmd_SlatDevice Jalousie_Mitte:d_Jalousie_slats

(Ansonsten wären die üblichen Lamellen-Positionen in den ASC-Attributen zu verteilen).

Auf die Änderung am dummy reagiert dann ein notify, das dann daraus wieder unser eigentliches Zieldevice ermittelt und die am Ende gewünschte Lamellenposition:

Code Auswählen Erweitern

defmod n_slat_Jalousien notify .*d_Jalousie_slats.* {myASC_slat_command($EVTPART0,$EVTPART1)}


Die eigentliche Ermittlung aller weiteren Dinge wie Zwischenpositionen usw. wäre dann in myUtils-Code unterzubringen. Bisher nur ein Fragment, das bisher nur Zieldevice und Ziel-Lamellenposition ins Log schreibt:

Code Auswählen Erweitern

sub myASC_slat_command {
  my $target = shift // return;
  my $event = shift // return;
  Log3($target, 3, "$target: slat level might be set to $event");
}

Irgendwann hatte ich mal auch längeren Code zur Fahrterkennung von HM-Aktoren usw. gehabt, aber der bringt dich hier vermutlich erst mal nicht weiter. Mal sehen, ob und wann ich Muße habe, das weiterzuentwickeln, oder ob sich ab hier jemand findet, der sich daran versuchen mag...

[GU!DO]

@CoolTux

Wie schon gesagt funktioniert ASC ausschließlich mittels Positionsangaben. So wie Du es beschreibst scheint allein schon die normale Steuerung ein Problem zu werden. Also einfach nur das auf und zu ziehen. Oder geht das bei Dir?

Was meinst Du mit auf und zu ziehen?
Ich fahre die Raffstores mit dem Rollo Modul genau so wie es ein Rollo fahren würde, als also AUF, AB und wenn ich möchte kann ich auch die Lamellen kippen, indem ich z.B. nach einer Abwärtsfahrt kurz nach oben fahre. Denn bevor das Raffstore sich nach oben bewegt, drehen sich die Lamellen in die waagerecht Position.
Anders verhält es sich bei einer Aufwärtsfahrt, da stehen die Lamellen bereits waagerecht. Sofern ich dann anhalte und diese schließen möchte, muss ich dementsprechend kurz abwärts fahren, damit sie sich senkrecht stellen.

@Beta-User
Du machst es einem ja nicht leicht nein zu sagen. Generalisierter Code klingt gut. Sofern Du Zeit hättest mich zu coachen, könnte ich in den Abendstunden mal damit spielen (sofern meine Regierung mich läßt!).

[CoolTux]

@CoolTuxWas meinst Du mit auf und zu ziehen?
Ich fahre die Raffstores mit dem Rollo Modul genau so wie es ein Rollo fahren würde, als also AUF, AB und wenn ich möchte kann ich auch die Lamellen kippen, indem ich z.B. nach einer Abwärtsfahrt kurz nach oben fahre. Denn bevor das Raffstore sich nach oben bewegt, drehen sich die Lamellen in die waagerecht Position.
Anders verhält es sich bei einer Aufwärtsfahrt, da stehen die Lamellen bereits waagerecht. Sofern ich dann anhalte und diese schließen möchte, muss ich dementsprechend kurz abwärts fahren, damit sie sich senkrecht stellen.

@Beta-User
Du machst es einem ja nicht leicht nein zu sagen. Generalisierter Code klingt gut. Sofern Du Zeit hättest mich zu coachen, könnte ich in den Abendstunden mal damit spielen (sofern meine Regierung mich läßt!).

Hast Du Deine Module irgendwo zum reinschauen abgelegt?

[GU!DO]

Hast Du Deine Module irgendwo zum reinschauen abgelegt?

Ich dachte den hättest Du noch, wir hatten uns doch noch Ende 2017 deshalb ausgetauscht. 

Wie lass ich Dir den denn am besten zukommen? Keine Ahnung wie wir das damals gemacht haben...

[CoolTux]

Du kannst die Module hier ablegen wenn Du magst.
https://cloud-tuxnet.ddns.net/index.php/s/GRAt542GNRZ5wPb

[GU!DO]

Mag ich gern. 

ist passiert. Ich glaube 20_HCAN ist das entscheidende. Das 10_HCAN dient nur der Kommuniaktion mit dem HCAN Controller.

Wenn Du dir schon die Mühe machst, vielleicth könntest Du die 10_HCAN trotzdem mal ansehen. Ich frage mich, wie ich es am besten bewerkstellige, dass er sich nach einem Neustart automatisch mit dem Controller verbindet. aktuell muß ich das immer händisch mit connect machen.

Vielen Dank

Guido

[CoolTux]

Mag ich gern. 

ist passiert. Ich glaube 20_HCAN ist das entscheidende. Das 10_HCAN dient nur der Kommuniaktion mit dem HCAN Controller.

Wenn Du dir schon die Mühe machst, vielleicth könntest Du die 10_HCAN trotzdem mal ansehen. Ich frage mich, wie ich es am besten bewerkstellige, dass er sich nach einem Neustart automatisch mit dem Controller verbindet. aktuell muß ich das immer händisch mit connect machen.

Vielen Dank

Guido

Ist angekommen. Ich schaue die Tage mal.

Grüße