Rolladenmotor steuern

Für welche Projekte verwendet Ihr OpenHAB? Was habt Ihr automatisiert?

Moderator: seppy

mcdandrew
Beiträge: 42
Registriert: 13. Dez 2018 17:42

Re: Rolladenmotor steuern

Beitrag von mcdandrew » 7. Feb 2019 20:36

mcdandrew hat geschrieben: ↑
Heute 17:39
Im Grund funktioniert es ja mit dem Pulsetime Befehl, obwohl deine Umsetzung natürlich schicker wäre. :-)

Es ist schlicht falsch :)
Jetzt machst du mir doch glatt nen schlechtes Gewissen :roll:
Ich glaube ich muss da nochmal ran :-)
Das verstehe ich jetzt nicht so ganz. Ich habe selbst T1 im Einsatz, ich kann Dir versichern, dass die wunderbar bidirektional funktionieren. Aber solange Du sie nicht als Rollladenaktoren verwendest, dürfen sie natürlich nicht als Rolladenaktoren konfiguriert sein, sie müssen stattdessen im normalen Schaltbetrieb konfiguriert sein.
So nochmal von vorne...ich habe die Taster mit dem Tasmota-Fork von Stefan Bode geflasht. Allerdings bis setoption 14 nicht anderes geändert. Somit sollte Sie nicht als Rollladenaktor konfiguriert sein..richtig?

Als Rule hat ich folgendes probiert.

Mein Think-File (ich nutze bereits MQTT2)

Code: Alles auswählen

Thing topic Sonoff_T1_WZ "Sonoff T1 Wohnzimmer" @ "MQTT" { 
    Channels:
		Type switch			: T1_WZ_Power1			[ stateTopic="stat/sonoff_t1_wz/POWER1", commandTopic="cmnd/sonoff_t1_wz/POWER1" ]
		Type switch			: T1_WZ_Power2 			[ stateTopic="stat/sonoff_t1_wz/POWER2", commandTopic="cmnd/sonoff_t1_wz/POWER2" ]
	}
Mein Item-File der T1 Taster

Code: Alles auswählen

//#################################### Wohnzimmer ###################################################################
Switch T1_WZ_Power1			"Power Switch 1"		{ channel="mqtt:topic:mqttbroker:Sonoff_T1_WZ:T1_WZ_Power1" }
Switch T1_WZ_Power2			"Power Switch 2"		{ channel="mqtt:topic:mqttbroker:Sonoff_T1_WZ:T1_WZ_Power2" }
Mein Item-File der DUAL (noch MQTT1 Version)

Code: Alles auswählen

//###Terrassenfenster links##
Rollershutter Dual_WZ_TF_links   	"Terrassenfenster links [%d%%]" (rolladen_wz) 	{ mqtt=">[Sentshuas:cmnd/dual_wz_tf_l/shutterposition1:command:*:default]", autoupdate="false" }
Rollershutter Dual_WZ_TF_links_ud 	"Terrassenfenster links [%d%%]" (rolladen_wz) 	{ mqtt=">[Sentshuas:cmnd/dual_wz_tf_l/shutteropen1:command:UP:null],>[Sentshuas:cmnd/dual_wz_tf_l/shutterclose1:command:DOWN:null],>[Sentshuas:cmnd/dual_wz_tf_l/shutterstop1:command:STOP:null],<[Sentshuas:stat/dual_wz_tf_l/SHUTTER1:state:default],<[Sentshuas:tele/dual_wz_tf_l/SENSOR:state:JSONPATH($.SHUTTER-1)]", autoupdate="false" }
Der Rule-File

Code: Alles auswählen

rule "T1_WZ nach Aktor"
when
    Item T1_WZ_Power1 received command or
    Item T1_WZ_Power2 received command
then
    if(receivedCommand == OFF)
        Dual_WZ_TF_links_ud.sendCommand(STOP)
    else if(triggeringItem.name == "T1_WZ_Power1")
                Dual_WZ_TF_links_ud.sendCommand(UP)
    else if(triggeringItem.name == "T1_WZ_Power2")
                Dual_WZ_TF_links_ud.sendCommand(DOWN)
end
Im OpenHab Log selbst steht beim betätigen: "T1_WZ_Power1 changed from OFF to ON"
Es kann ohne weiteres sein, dass Du damit eine Überversorgung hast und die WLAN AP sich gegenseitig eher behindern. Wie sind die AP konfiguriert? Welcher Typ AP?
Es handelt sich um 2x Linksys WRT54GL geflasht mit DD-WRT und 1x Linksys WRT1200Ac ebenfalls mit DD-WRT.
WLAN Kanäle habe ich manuell eingestellt (natürlich verschiedene)
SSID und Password sind jeweils gleich...damit Clients unter den AP wechseln können.

Benutzeravatar
udo1toni
Beiträge: 1416
Registriert: 11. Apr 2018 18:05
Wohnort: Darmstadt

Re: Rolladenmotor steuern

Beitrag von udo1toni » 8. Feb 2019 01:08

Für die Rückmeldung (also das Ausschalten des T1) müsstest Du jetzt noch eine entsprechende Rule definieren, die beim Stop-Kommando den Taster ausschaltet. Du musst vorher nachschauen, was der Dual für ein Kommando zurück schickt.

Die Konfiguration der AP klingt erstmal ok. Es kann halt immer noch sein, dass ein Modul zwischen den verschiedenen AP hin und her wechselt. Beim Umbuchen wird es natürlich immer wieder zu kurzen Unterbrechungen kommen.

mcdandrew
Beiträge: 42
Registriert: 13. Dez 2018 17:42

Re: Rolladenmotor steuern

Beitrag von mcdandrew » 8. Feb 2019 09:10

Für die Rückmeldung (also das Ausschalten des T1) müsstest Du jetzt noch eine entsprechende Rule definieren, die beim Stop-Kommando den Taster ausschaltet. Du musst vorher nachschauen, was der Dual für ein Kommando zurück schickt.
Das Problem ist hier bereits, dass die erste Rule zum Betätigen der Rolladen nicht ausgelöst wird.

Ein

Code: Alles auswählen

 Item T1_WZ_Power1 received command or
    Item T1_WZ_Power2 received command
scheinen die T1 nicht abzusetzen.

Ändere ich es auf changed wird zumindest die Rule ausgelöst.

Die andere Regel habe ich wie folgt definiert.

Code: Alles auswählen

rule "Aktor nach T1_WZ"
when
    Item Dual_WZ_Fenster_1_ud received command
then
    if(receivedCommand == STOP) {
        T1_WZ_Power1.sendCommand(OFF)
        T1_WZ_Power2.sendCommand(OFF)
    }
end


Die Konfiguration der AP klingt erstmal ok. Es kann halt immer noch sein, dass ein Modul zwischen den verschiedenen AP hin und her wechselt. Beim Umbuchen wird es natürlich immer wieder zu kurzen Unterbrechungen kommen.
Ich werde versuchen mit einem MAC-Filter zuarbeiten, um den Sonoffs nur die Einwahl in den jeweiligen AP seiner Ettage zur ermöglichen.

Benutzeravatar
udo1toni
Beiträge: 1416
Registriert: 11. Apr 2018 18:05
Wohnort: Darmstadt

Re: Rolladenmotor steuern

Beitrag von udo1toni » 8. Feb 2019 13:26

mcdandrew hat geschrieben:
8. Feb 2019 09:10
Das Problem ist hier bereits, dass die erste Rule zum Betätigen der Rolladen nicht ausgelöst wird.

Ein

Code: Alles auswählen

 Item T1_WZ_Power1 received command or
    Item T1_WZ_Power2 received command
scheinen die T1 nicht abzusetzen.
Ah. Ja, stimmt, war mir gar nicht aufgefallen, das ist in MQTT2 neu dazu gekommen. Siehe hier https://www.openhab.org/addons/bindings ... parameters der nötige Parameter heißt dann postCommand (vermutlich postCommand=true? hab auf die Schnelle kein Beispiel gefunden) und sorgt dafür, dass das empfangene Status Update als Befehl ausgewertet wird. Andererseits kann man ja mit received update oder changed genauso gut arbeiten.

Ändere ich es auf changed wird zumindest die Rule ausgelöst.

Die andere Regel habe ich wie folgt definiert.

Code: Alles auswählen

rule "Aktor nach T1_WZ"
when
    Item Dual_WZ_Fenster_1_ud received command
then
    if(receivedCommand == STOP) {
        T1_WZ_Power1.sendCommand(OFF)
        T1_WZ_Power2.sendCommand(OFF)
    }
end
Das gleiceh Problem dürfte dann bei der zweiten Rule genauso auftreten, dort müsstest Du also den Trigger vermutlich auch auf changed ändern, und weil es dann kein receivedCommand gibt, musst Du natürlich stattdessen den Status auswerten. Es bietet sich noch an, nur dann ein OFF zu schicken, wenn der Status nicht ohnehin schon OFF ist:

Code: Alles auswählen

rule "Aktor nach T1_WZ"
when
    Item Dual_WZ_Fenster_1_ud changed
then
    if(Dual_WZ_Fenster_1_ud.state == STOP) {
        if(T1_WZ_Power1.state != OFF) T1_WZ_Power1.sendCommand(OFF)
        if(T1_WZ_Power2.state != OFF) T1_WZ_Power2.sendCommand(OFF)
    }
end

mcdandrew
Beiträge: 42
Registriert: 13. Dez 2018 17:42

Re: Rolladenmotor steuern

Beitrag von mcdandrew » 8. Feb 2019 23:37

Für alle die es interessiert, ich habe es nun wie folgt umgesetzt.

In der Thing Konfig wird, wie von Udo geschrieben, der Befehl von PostCommand hinzugefügt.

Code: Alles auswählen

Thing topic Sonoff_T1_WZ "Sonoff T1 Wohnzimmer" @ "MQTT" { 
    Channels:
		Type switch			: T1_WZ_Power1			[ stateTopic="stat/sonoff_t1_wz/POWER1", commandTopic="cmnd/sonoff_t1_wz/POWER1", postCommand="true"]
		Type switch			: T1_WZ_Power2 			[ stateTopic="stat/sonoff_t1_wz/POWER2", commandTopic="cmnd/sonoff_t1_wz/POWER2", postCommand="true"]
	}
Die Rules sehen dann wie folgt aus

Code: Alles auswählen

rule "T1_WZ_u nach Aktor"
when
    Item T1_WZ_Power1 received command or
    Item T1_WZ_Power2 received command
then
    if(receivedCommand == OFF)
	{
        Dual_WZ_TF_links_ud.sendCommand(STOP)
	}
    else if(triggeringItem.name == "T1_WZ_Power1")
	{
		Dual_WZ_TF_links_ud.sendCommand(DOWN)
	}
    else if(triggeringItem.name == "T1_WZ_Power2")
	{
		Dual_WZ_TF_links_ud.sendCommand(UP)
	}
end

rule "Aktor nach T1_WZ_u"
when
    Item Dual_WZ_TF_links_ud changed
then
        if(T1_WZ_Power1.state != OFF) T1_WZ_Power1.sendCommand(OFF)
        else if(T1_WZ_Power2.state != OFF) T1_WZ_Power2.sendCommand(OFF)
end
Die Abfrage

Code: Alles auswählen

if(Dual_WZ_ud.state == OFF)
in der zweiten Rule habe ich entfernt, da nach dem Stoppen des Rolladen statt "OFF" die aktuelle Höhe des Rolladen in % geliefert wird.
Da es meiner Meinung nach egal was geliefert wird habe ich es entfernt.

Morgen werde ich dann noch einmal alles testen.
Vielen Dank an Udo für die Untertützung!

Benutzeravatar
udo1toni
Beiträge: 1416
Registriert: 11. Apr 2018 18:05
Wohnort: Darmstadt

Re: Rolladenmotor steuern

Beitrag von udo1toni » 9. Feb 2019 02:08

mcdandrew hat geschrieben:
8. Feb 2019 23:37
in der zweiten Rule habe ich entfernt, da nach dem Stoppen des Rolladen statt "OFF" die aktuelle Höhe des Rolladen in % geliefert wird.
Da es meiner Meinung nach egal was geliefert wird habe ich es entfernt.
Super! :)

mcdandrew
Beiträge: 42
Registriert: 13. Dez 2018 17:42

Re: Rolladenmotor steuern

Beitrag von mcdandrew » 16. Mär 2019 08:22

ich muss noch einmal "stören"....mittlerweile ist noch ein zweites Problem aufgetretten.

Ich habe eine Rule zum Öffnen der Rollläden

Code: Alles auswählen

rule "open all wochenende"
when
	  Time cron "0 15 08 ? * *"
then
	if (now.getDayOfWeek > 5) // Samstag bis Sonntag
	{
		//Alle Rollladen öffnen
		grp_rolladen_ud.sendCommand(UP)
		Thread::sleep(30000)
		//Im Anschluss spezifische Höhen einstellen
		grp_rolladen.sendCommand(5)
	}
end
Das funktioniert soweit super, das Problem hierbei ist folgendes.
Heute bspw. habe ich alle Rollladen um 7 UIhr manuell geöffnet um 8:15 hat dann die Rule ausgelöst und wieder alle Rollladen gechlossen :?:
So recht verstehe ich das nicht da ja das Kommando UP ausgeführt wird.
Hat jemand eine Erklärung bzw. Lösungsvorschlag?

Benutzeravatar
udo1toni
Beiträge: 1416
Registriert: 11. Apr 2018 18:05
Wohnort: Darmstadt

Re: Rolladenmotor steuern

Beitrag von udo1toni » 17. Mär 2019 17:57

Das Eine ist die Formulierung der Rule, Du kannst den Wochentag auch im Time cron Ausdruck eingrenzen:

Code: Alles auswählen

Time cron "0 15 8 ? * 6,7"
triggert nur Samstag und Sonntag. Du kannst auch statt 6,7 SAT,SUN schreiben, falls Dir das lieber ist.
Eine zweite Sache wäre, dass Du innerhalb der Rule die aktuelle Höhe bestimmen solltest, bevor Du den Steuerbefehl sendest.
Eine dritte Anmerkung: Thread::sleep(30000) ist hässlich und ineffizient, ja sogar gefährlich.
Thread::sleep() hält tatsächlich den laufenden Thread an, womit der Threadpool für die angegebenen Zeit um eins kleiner ist. Da die Rule über den Scheduler (Time cron) gestartet wird, und der Scheduler default nur zwei Threads gleichzeitig abarbeiten kann, besteht eine gute Chance, dass sich das System selbst in die Quere kommt.
Besser ist es, mit einem Timer zu arbeiten. Thread::sleep() sollte nur für kleine Verzögerungen bis maximal 500 Millisekunden verwendet werden.

Warum der UP-Befehl zu einer Abwärtsbewegung führt, kann ich Dir nicht beantworten. hier treten solche Phänomene nicht auf, aber ich verwende zur Ansteuerung der Sonoff Rollläden den Fork von Stefan Bode, der unterstützt Positionsfahrten direkt.

mcdandrew
Beiträge: 42
Registriert: 13. Dez 2018 17:42

Re: Rolladenmotor steuern

Beitrag von mcdandrew » 17. Mär 2019 18:16

Danke für die hilfreichen Tipps!

Das mit dem Wochentag direkt im Cron habe ich verstanden...ich spare mir somit die IF Schleife.
Eine zweite Sache wäre, dass Du innerhalb der Rule die aktuelle Höhe bestimmen solltest, bevor Du den Steuerbefehl sendest.
Das verstehe ich nun garnicht, wofür sollte das gut sein? In der Gruppe "grp_rolladen_ud" befinden sich alle Rollladen des Hauses die natürlich unterschiedliche Höhen haben. In der Regel sind bis auch Küche und Bad alle zu 95% geschlossen. Die beiden erwähnten sind bei 60%.
Eine dritte Anmerkung: Thread::sleep(30000) ist hässlich und ineffizient, ja sogar gefährlich.
Thread::sleep() hält tatsächlich den laufenden Thread an, womit der Threadpool für die angegebenen Zeit um eins kleiner ist. Da die Rule über den Scheduler (Time cron) gestartet wird, und der Scheduler default nur zwei Threads gleichzeitig abarbeiten kann, besteht eine gute Chance, dass sich das System selbst in die Quere kommt.
Besser ist es, mit einem Timer zu arbeiten. Thread::sleep() sollte nur für kleine Verzögerungen bis maximal 500 Millisekunden verwendet werden.
Okay verstanden vielleicht noch eine kurze Anmerkung warum ich diesen nutze. Meine Frau findet es "schicker" wenn die Rollläden nicht ganz eingefahren sind, aus diesem Grund lasse ich diese nach dem Öffnen auf 5% fahren.
Ein direktes ansteuern auf 5% der gesamten Gruppe klappte nicht so recht. Einzelne Rollläden waren dann irgendwann nicht mehr richtig synchron. Durch das komplette UP (am Morgen) und down (am Abend) resseten sich die Endlagen.
Aber ich habe gerade eine neue Idee... Die Rollläden der Terrassenfenster haben mit ihren 30sek. die längste Laufzeit (deshalb auch Thread 30). Ich könnte natürlich auch ein Event ausführen lassen wenn diese abschalten und dann damit die 5% für die Gruppe triggern.


Warum der UP-Befehl zu einer Abwärtsbewegung führt, kann ich Dir nicht beantworten. hier treten solche Phänomene nicht auf, aber ich verwende zur Ansteuerung der Sonoff Rollläden den Fork von Stefan Bode, der unterstützt Positionsfahrten direkt.
Nach Deiner Empfehlung nutze ich dieses auch ;)

Benutzeravatar
udo1toni
Beiträge: 1416
Registriert: 11. Apr 2018 18:05
Wohnort: Darmstadt

Re: Rolladenmotor steuern

Beitrag von udo1toni » 17. Mär 2019 20:23

Das verstehe ich nun garnicht, wofür sollte das gut sein?
Das war einfach auf die konkrete Rule bezogen. Warum solltest Du den Laden fahren lassen, wenn er schon seine Position hat?
Ich habe den Vorteil, dass meine Rollladenaktoren direkte Positionsfahrten unterstützen. Ic hfahre meine Rollläden ausschließlich über direkte Positionaangaben, weshalb ich mit keinen Kopf darum machen muss, ob der Laden nun fahren soll oder nicht - der Aktor weiß, dass der Laden bereits auf 5% steht und macht dann gar nichts.
Wenn der Aktor das aber nicht unterstützt, sollte man das vor dem Ansteuern prüfen, falls nicht sicher ist, auf welcher Position der Laden steht.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast