Hauptmenü

Rollladen gehen nicht mehr.

Begonnen von Kellerkind86, 05 September 2021, 22:19:49

Vorheriges Thema - Nächstes Thema

Kellerkind86

okay verstanden.


ich versuch es mal.
wenn der dummyschalter ( rollladensteuerung an oder aus ) auf on steht ,
sollen Abends die Rollladen werktags um 19:10 runterfahren / am wochenende um 20:10.
wenn der wandschalter gedrueckt wird,
sollen alle Rollladen hochfahren
wenn der wandschalter nicht gedrueckt wird,
sollen die Rollladen werktags um 07:10 runterfahren / am wochenende um 08:10

((bei dem physischen schalter (OG_Rolllade_Matilda_klein) dachte ich kann einfach auf das State des shellys triggern wenn der state 100 kommt.))

ich weiss nicht ob ich da irgendwie aufm schlauch stehe bei der sache..
Hardware in Nutzung: Fritzbox7490,RP4,nanoCUL868,sonoff(mini),shelly(2.5)

MadMax-FHEM

#16
EDIT: die Uhrzeiten sind aber in deinen DOIF-Versuchen SO auch (noch) nicht drin! ;)

Naja, dann eben den dummy nur Abfragen (Fragezeichen siehe Anmerkung von Damian) und dann aber mit AND weil ja nur dann die Rollladen autom. fahren sollen, korrekt?

Der Shelly hat doch urls die aufgerufen werden können, wenn ein Taster/Schalter gedrückt wird.

Dort dann eben ein Reading (im vorhandenen dummy oder im DOIF) setzen und das dann eben als Trigger nehmen (zusätzliches ELSIF ohne Uhrzeit? Wie geschrieben: nutze kein DOIF aber so sollte es gehen) und damit dann alle Rollläden fahren...

EDIT: bzw. den dummy ganz raus werfen und nur das DOIF nehmen. Dort eben ein Reading setzen, das statt dem on/off im dummy abgefragt wird (würde ich so machen, wenn ich DOIF nutzen würde ;)  )... Aber lass das erst mal, weil sonst wird es (erst mal) nur noch komplizierter (für dich)...

Soll dann auch der Automatik-Betrieb "verriegelt" sein?
Dann entweder den dummy auf "off" setzen (beim manuellen Steuern) oder eine andere "Blockierlösung" überlegen (z.B. das manuell betätigte Reading als weitere Bedingung zum dummy)...

ABER: wie lange nach einer mauellen Bedienung soll denn "gesperrt" bleiben? -> "Lücke" in der "Logik"?

Gruß, Joachim

P.S.: Reaktion auf 100 ist denke ich schlecht, weil das ja doch auch beim autom. Fahren erreicht wird/werden kann? (Trick den ich schon hier gelesen habe: Automatik fährt nur bis 99 und auch nicht auf 0 sondern 1, damit kann das u.U. "unterschieden" werden, außer jemand stoppt manuell zufällig eben auch bei 99 oder 1 ;)  )
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Kellerkind86

ja, die uhrzeiten sollten so besser stimmen.
ich komm mir jetzt schon verwirrt vor.. ;D
was ich jetzt verstanden habe:

ZitatEDIT: die Uhrzeiten sind aber in deinen DOIF-Versuchen SO auch (noch) nicht drin! ;)
ja, die uhrzeiten sollten so besser stimmen.(sorry fuer die verwirrung)

ZitatNaja, dann eben den dummy nur Abfragen (Fragezeichen siehe Anmerkung von Damian) und dann aber mit AND weil ja nur dann die Rollladen autom. fahren sollen, korrekt?
Ja schon.. vielleicht ist das auch das unwissende... ich dachte wenn der physische schalter eh betaetigt wurde,dann verlaeft die automatik ja eh ins leere...wo ich dachte das es nicht schlimm waere. also . wenn um 7 Uhr der physische schalter betaetigt wird und auf 100 steht dann wird die automatik ja ins leere laufen.

rest ist fuer mich grad nicht greifbar.. sitze auf der arbeit und steh wie der ochs vorm berg...und denke..oh man..peinlich..aber ich rall es nicht.. vielleicht muss ich das mal sacken lassen.

hab mir das irgendwie einfacher vorgestellt..sorry. ::)








Hardware in Nutzung: Fritzbox7490,RP4,nanoCUL868,sonoff(mini),shelly(2.5)

Beta-User

Hmm, irgendwie kommt mir das auch "zu kompliziert" vor...

Wenn das ein Shelly@MQTT2_DEVICE ist, sollte es auch ein Tasten-Event geben. Da hier eine manuelle Bedienung (völlig unabhängig von der Zeit) Vorrang haben soll, ist doch - mit Verlaub - völlig wurst, ob man am "Sonnenstand" erkennen kann, ob die Automatik gefahren war oder wegen des Tasters offen (bzw. geschlossen) ist.

Ergo würde ich mal empfehlen, in einer ruhigen Minute den Event-Monitor anzustarren und nebenbei mal "Knöpfe" zu drücken, vielleicht lichtet sich dann der Nebel etwas...? Zur Vorbereitung vielleicht dann schon mal den Wiki-Artikel zum Event-Monitor "trockenüben"?!?

Und deine Frau wird es vermutlich zu schätzen wissen, wenn sie nicht erst warten muss, bis der eine Rollladen offen ist, wenn sie checken will, ob deine Automatik ihren Wunsch denn respektiert, dass jetzt alle zu öffnen sind...

Danach dürfen dann die DOIF-Experten ran und sich beraten, ob man das Ganze am Ende in ein DOIF packt oder nicht; ich würde ein (!) notify dafür spendieren, das dann ggf. auch mit dem "Taster in einem anderen Raum" klarkommt, und diesen Teil schlicht getrennt abfrühstücken... Aber das ist zum Teil auch Geschmackssache.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

#19
Zitat von: Beta-User am 06 September 2021, 14:09:39
Hmm, irgendwie kommt mir das auch "zu kompliziert" vor...

Wenn das ein Shelly@MQTT2_DEVICE ist, sollte es auch ein Tasten-Event geben. Da hier eine manuelle Bedienung (völlig unabhängig von der Zeit) Vorrang haben soll, ist doch - mit Verlaub - völlig wurst, ob man am "Sonnenstand" erkennen kann, ob die Automatik gefahren war oder wegen des Tasters offen (bzw. geschlossen) ist.

Ergo würde ich mal empfehlen, in einer ruhigen Minute den Event-Monitor anzustarren und nebenbei mal "Knöpfe" zu drücken, vielleicht lichtet sich dann der Nebel etwas...? Zur Vorbereitung vielleicht dann schon mal den Wiki-Artikel zum Event-Monitor "trockenüben"?!?

Und deine Frau wird es vermutlich zu schätzen wissen, wenn sie nicht erst warten muss, bis der eine Rollladen offen ist, wenn sie checken will, ob deine Automatik ihren Wunsch denn respektiert, dass jetzt alle zu öffnen sind...

Danach dürfen dann die DOIF-Experten ran und sich beraten, ob man das Ganze am Ende in ein DOIF packt oder nicht; ich würde ein (!) notify dafür spendieren, das dann ggf. auch mit dem "Taster in einem anderen Raum" klarkommt, und diesen Teil schlicht getrennt abfrühstücken... Aber das ist zum Teil auch Geschmackssache.

Klar stimmt die Info ob Shelly-Modul, mqtt oder ganz anders eingebunden fehlt nat.

Dass es bei mqtt einen Tatsendruck-Event gibt wusste ich nicht ;)
(nutze das bei EnOcean-Tastern in ähnlicher Weise, allerdins ist dann bei mir "jedweder Automatikmodus" gesperrt, bis ich eben wieder manuell ausgeschaltet habe -> dann wieder Automatik :)  )

EDIT: und ich würde auch eher darauf reagieren (oder eben den url-Aufruf beim Shelly, falls eben kein mqtt -> siehe Weboberfläche des Shelly unter Action urls oder so) als zu warten bis eine der manuell gesteuerten Rollo auf/zu ist und dann die anderen nachziehen... :)
Allerdings dann eben die weitere Frage: sollen IMMER ALLE mit auf/zu fahren bei manueller Betätigung bei einem? (bei nur einem Bestimmten ist es wieder einfacher ;)  Also wenn nur ein bestimmter Rollo der "Master" für "alle zusammen manuell" sein soll)
Das meinte und meine ich mit GENAU überlegen ;) Und das hat ja wirklich noch nichts mit der Umsetzung an sich zu tun...

So einfach geht es aber auch nur, wenn nach dem manuellen öffnen VOR dem autom. öffnen manuell geöffnet wurde bzw. VOR dem autom. schließen manuell geschlossen wurde.
EDIT: gut klar nach der Automatik macht ja wenig Sinn, außer man sieht nicht, dass schon offen/geschlossen ist ;)

Meine Frage mit dem "wie lange sperren" war eben:

es wird manuell geöffnet (dann ist die Automatik egal, klar ;)  ).
ABER: soll dann abends autom. geschlossen werden? Oder die Automatik weiterhin "gesperrt" sein?

Ich sage nicht, dass es so sein muss/soll...
...habe aber auch noch keine KLARE Aussage darüber vom TE gesehen ;)

(es ändert sich ja immer wieder mal was nun wann gewollt wird ;)  )

Will/wollte nur sagen: einfach wird es nur, wenn man wenige Bedingungen und Abhängigkeiten hat/braucht einem die damit mögliche Automatik etc aber auch GENAU SO reicht und auch dann muss man eben festlegen WAS WANN WIE WODURCH etc. 8)

Also erst mal fertig arbeiten.
Noch mal nachdenken was nun tatsächlich geschehen soll (autom. oder manuell) durch welche Auslöser (Zeitpunkt, [physische] Schalter) und ob/wie lange eine Automatik "gesperrt" sein soll (also echter Automatik-/Manuell-Betrieb [wie bei mir])...

Das dann sauber formuliert hinschreiben weil damit lässt sich das dann (meist) einfach in Logik gießen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 06 September 2021, 14:19:06
Klar stimmt die Info ob Shelly-Modul, mqtt oder ganz anders eingebunden fehlt nat.
Doch, die Info ist da: es gibt oben (indirekt) dazu relativ klare Hinweise - allerdings ist das dem TE leider nicht klar, sonst hätte er von seinem "Master"-Taster auch gleich noch ein list (und ein paar Tasten-Events?) geliefert ::) .

Zitat
Dass es bei mqtt einen Tatsendruck-Event gibt wusste ich nicht ;)
...ich bin auch nicht 100% sicher...

Aber solange dem TE nicht klar ist, dass FHEM grundsätzlich Event-basiert tickt und er daher zu allererst in den Event-Monitor (ersatzweise: ein list (qed...!)) schauen muss, wenn er sowas umsetzen will, ist es ziemlich müßig, "von außen" Lösungen zu suchen.
(Und solange die Grundlagen nicht klar sind, macht es auch keinen Sinn darauf hinzuweisen, dass für derartige timer-basierte "Rollo-Aufgaben" z.B. mit AutoShuttersControl auch ein sehr mächtiges Toolset bereitsteht...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Kellerkind86

Ja, ich versuche mich heute Abend mal daran.. Ich danke jetzt schonmal,dass Ihr mir soweit helfen wollt..
Ich versuche mich mal damit mehr auseinander zu setzen..
und dann werde ich mich nochmal hier melden..
ihr habt ja damit recht... dann versuch ich auch mehr Infos zu liefern.. auch ob der taster ein event liefert.

Zitat(Und solange die Grundlagen nicht klar sind, macht es auch keinen Sinn darauf hinzuweisen, dass für derartige timer-basierte "Rollo-Aufgaben" z.B. mit AutoShuttersControl auch ein sehr mächtiges Toolset bereitsteht...)
Ja,ich hatte das mal ueberflogen aber hab da immer was gelesen von Fenster kontakten.. ich lese mich auch da mal ein..
Problem ist die zeit... kennt ihr ja  :D

vielen dank schonmal bis hier hin..

Gruss Marcell
Hardware in Nutzung: Fritzbox7490,RP4,nanoCUL868,sonoff(mini),shelly(2.5)

Beta-User

Zitat von: Kellerkind86 am 06 September 2021, 14:49:18
ich lese mich auch da mal ein..
Lass das erst mal. Grundlagen wären erst mal sehr viel wichtiger!
Ohne die bist du bei AutoShuttersControl (oder anderen komplexen Modulen) einfach nur aufgeschmissen, völlig unabhängig davon, ob du Fensterkontakte hast, meinst sie zu brauchen, grade beschaffst, ..., oder nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Kellerkind86

ja, ich hab grad mal geschaut.  dabei moechte ich erst mal nur die rollladen einfach nur schalten... und nichts mit sonnenstand etc.. das kann gerne spaeter alles kommen.

grundlagen... was macht da sinn.. gibt es da ein leitfaden..
perl kenntnisse hab ich sogut wie  garnicht..
wuerde gerne mehr lernen um da mehr licht ins dunkle zu bekommen.
Hardware in Nutzung: Fritzbox7490,RP4,nanoCUL868,sonoff(mini),shelly(2.5)

MadMax-FHEM

Zitat von: Beta-User am 06 September 2021, 14:35:03
Doch, die Info ist da: es gibt oben (indirekt) dazu relativ klare Hinweise - allerdings ist das dem TE leider nicht klar, sonst hätte er von seinem "Master"-Taster auch gleich noch ein list (und ein paar Tasten-Events?) geliefert ::) .
...ich bin auch nicht 100% sicher...

Eieiei, stimmt natürlich!
Die Logauszüge ;)

(aber ist halt nicht so einfach, wenn man sich alles zusammensuchen muss ;)  )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Kellerkind86

Zitat von: MadMax-FHEM am 06 September 2021, 15:03:09
Eieiei, stimmt natürlich!
Die Logauszüge ;)

(aber ist halt nicht so einfach, wenn man sich alles zusammensuchen muss ;)  )

Gruß, Joachim
Ja, ich sehe das Problem im ganzen.. ich kenn das aus meiner sicht ja selber..
man muesste nur die zeit haben sich mehr damit zu beschaeftigen..da kommt man im alltag naemlich leider sehr selten zu.. Kinder/Haus/Arbeit...
dann richtet man mal wieder ein device ein und man steht wieder gefuehlt  wieder am anfang..

bis vor kurzem lief fhem garnicht mehr und ich habe die config zurueck gespielt...jetzt laeuft es wieder soweit aber ich hab noch logeintrage die ich noch abstellen muss/will..bevor der log platzt. ???
dann das thema rollladen.. und am besten alles gleichzeitig loesen wollen. aber die Zeit..
jeztzt aber genug rumgeheult..
ich versuche mich mal mehr damit zu beschaeftigen..wo fange ich am besten an. 
wenn ich z.b eine fehlermeldung im log lese, versuche ich die per suche im forum zu finden...aber das funktioniert nicht immer..

danke
gruss Marcell
Hardware in Nutzung: Fritzbox7490,RP4,nanoCUL868,sonoff(mini),shelly(2.5)

Beta-User

Zitat von: Kellerkind86 am 06 September 2021, 14:59:09
grundlagen... was macht da sinn.. gibt es da ein leitfaden..
perl kenntnisse hab ich sogut wie  garnicht..
Na ja, es gibt nach wie vor "das Einsteiger-pdf". Ist zwar etwas angestaubt, aber immer noch eine sehr gute Orientierungshilfe.

Dass FHEM event-basiert "tickt" klang hier ja schon mehrfach an - DIE Anlaufstelle dazu ist der Event-Monitor und der Wiki-Artikel dazu.

Zu Perl gibt es im Einsteiger-pdf auch ein paar kleine if/else-Beispiele, ich würde empfehlen, jeweils die commandref zum gerade verwendeten Modul parat zu haben und die "Perl-Specials" in der commandref immer mal wieder zu überfliegen, das ist eigentlich eine ganz gute Basis.

Zur Logik kann ich nur MadMax-FHEM beipflichten:
Schreib' erst mal auf einen Zettel, was wann aus welchem Anlass passieren soll und welche Rahmenbedingungen dazu (nicht) gegeben sein sollen.

Dann schaust du in den Event-Monitor, ob du zum betreffenden "Anlass" irgendwas "durchrauschen" siehst und fängst damit mal an...

Der Rest ist - verkürzt gesagt: üben, üben, üben...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

Eigentlich ist die Anforderung gar nicht so besonders und lässt sich einfach realisieren.

Es gibt einen Automatikmodus (Rollos_steuerung gleich on) und einen Wandtaster der jederzeit die Automatik übersteuern kann. Alles andere wird zu kompliziert.

DOIF ([?Rollos_steuerung:state] eq "on" and ([19:15|7] or [19:00|8]) or [Wandtaster:"on"] and $cmd ==2) (set Rolladen_OG close)
DOELSEIF  ([?Rollos_steuerung:state] eq "on" and ([08:10|7] or [07:10|8]) or [Wandtaster:"on"] and $cmd ==1)
(set Rolladen_OG open)


Wenn der Wandtaster über zwei Stellungen verfügt, dann kann man rauf und runter separat steuern, sonst wird getoggelt wie im oberen Beispiel.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Kellerkind86

Zitat von: Damian am 06 September 2021, 16:07:57
Eigentlich ist die Anforderung gar nicht so besonders und lässt sich einfach realisieren.

Es gibt einen Automatikmodus (Rollos_steuerung gleich on) und einen Wandtaster der jederzeit die Automatik übersteuern kann. Alles andere wird zu kompliziert.

DOIF ([?Rollos_steuerung:state] eq "on" and ([19:15|7] or [19:00|8]) or [Wandtaster:"on"] and $cmd ==2) (set Rolladen_OG close)
DOELSEIF  ([?Rollos_steuerung:state] eq "on" and ([08:10|7] or [07:10|8]) or [Wandtaster:"on"] and $cmd ==1)
(set Rolladen_OG open)


Wenn der Wandtaster über zwei Stellungen verfügt, dann kann man rauf und runter separat steuern, sonst wird getoggelt wie im oberen Beispiel.
ja, vom lesen her, sieht das schon genau so aus wie ich mir das vorgestellt habe.
nichtsdestotrotz  werde ich mir mal die pdf durchlesen.
leider kam ich gestern abend als ich nach hause kam , nicht mehr dazu die Rolllade zu fahren um im monitor das event zu beobachten,weil dann wahrscheinlich die Kinder wieder wach geworden waeren.
Mein Wandtaster hat zwei taster..(rauf und runter) werde das also erst mal beobachten was der EM da aus spuckt.
eine kleine Frage habe ich dennoch....  wofuer steht das kommando ? 
Zitatand $cmd ==1)

Habe aber durch den Eventmonior eine andere Baustelle loesen koennen..( also ist bei mir doch nicht ganz Hopfen und Malz verloren  ;D. aber ich merke selber ,dass ich mehr machen muss, bzw will ,damit ich mit fhem leichter etwas  bauen kann.
Dazu  kommt man sich ja selber immer bloed vor , wenn man jedes kleinste ding erfragen muss..
Werde auch die anderen Ratschlaege befolgen...
Danke
Hardware in Nutzung: Fritzbox7490,RP4,nanoCUL868,sonoff(mini),shelly(2.5)

Damian

Die Variable $cmd beinhaltet den aktuellen Zustand des Moduls (cmd_1, cmd_2, usw.) siehe Commandref zu DOIF.

Man kann auch nur die Automatik in dem DOIF-Device belassen und in einem separaten DOIF das manuelle Hoch- und Runterfahren per Taster realisieren. Dort könnte man ebenfalls auch das Stoppen mit dem Wandtaster realisieren, wenn man die Rollläden nicht ganz nach oben oder unten bewegen will.

Die Analyse der Events des Tasters ist aber ein guter Anfang.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF