Rollladensteuerung: Alternativen zu DOIF

Begonnen von spi3845, 27 März 2017, 13:28:59

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: MarkusHiba am 12 Juni 2017, 14:29:18
Ok ja kompliziert kann man es machen aber ich kenne es so auf Arbeit haben wir auch sowas wenn Wind ist geht Rollo hoch und ist gesperrt wenn Wind weg ist ist es wieder freigegeben sowas wie beim Aussperrschutz könnte man machen für Wind.
Das ist nicht das Problem, aber: Es muß zum Rest des Codes passen bzw. der andere Teil des Codes muß damit umgehen können...

Zitat von: MarkusHiba am 12 Juni 2017, 14:17:03
Welchen code meinst du auf github? Ist das der  https://github.com/rejoe2/FHEM/tree/dev-module/myShutter
Genau der; aber Achtung, ich habe eigentlich seit mehreren Wochen nichts mehr an diesem Teil des codes rumgeschraubt (außer einem Typo), kenne also den wirklichen Stand der Funktionalität nicht, zumal da nur HM abgebildet ist...
Wie gesagt, es geht dabei eher darum zu zeigen, welche Unterschiede hinsichtlich der Syntax exisiteren (es ist auch die "alte" Perl-Routine noch als 99- drin). Hat auch praktisch (noch) nichts/wenig Überschneidungen mit dem Code von Cluni u.a..
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

kjmEjfu

Zitat von: MarkusHiba am 12 Juni 2017, 14:29:18
Ok ja kompliziert kann man es machen aber ich kenne es so auf Arbeit haben wir auch sowas wenn Wind ist geht Rollo hoch und ist gesperrt wenn Wind weg ist ist es wieder freigegeben sowas wie beim Aussperrschutz könnte man machen für Wind.

das betrifft aber primär Jalousien. Rollos kann man ja durchaus bei Sturm runterfahren. Da wäre dann die Option eher die komplett runterzufahren und keine Lüftungsschlitze zu lassen. Nach dem Sturm müssten sie auf eine vorher eventuell vorhandene Lüftungsposition fahren.
Ist also gar nicht so einfach ...
Migriere derzeit zu Home Assistant

Cluni

Zitat von: Beta-User am 12 Juni 2017, 14:41:38
Das ist nicht das Problem, aber: Es muß zum Rest des Codes passen bzw. der andere Teil des Codes muß damit umgehen können...
Das ist auch nicht das Problem - der andere Code wird wenn gesperrt ja gar nicht ausgeführt. Aber es muss durchdacht, programmiert und getestet werden. Wann genau verlasse ich wieder den sicheren Modus und entsperre wieder alles? Da kommen einige Dinge zusammen, die sich AUSSERHALB der Routine gemerkt werden müssen und sehr viele Dinge/Überlegungen, die beachtet werden müssen. Deshalb erstmal der Ansatz: wenn windiger als Schwelle ==> sicher Zustand und warten auf manuelle Freigabe. ALLES ANDERE WIRD DANN SPÄTER NOCH DAZU KOMMEN!
Wer meint, dass er es schneller haben muss, der muss es dann auch selber programmieren... :D


Zitat von: kjmEjfu am 12 Juni 2017, 14:48:33
das betrifft aber primär Jalousien. Rollos kann man ja durchaus bei Sturm runterfahren. Da wäre dann die Option eher die komplett runterzufahren und keine Lüftungsschlitze zu lassen. Nach dem Sturm müssten sie auf eine vorher eventuell vorhandene Lüftungsposition fahren.
Ist also gar nicht so einfach ...
Aus diesem Grund mein obiger Vorschlag zu dem Attribut "Aktion bei Schwellwert-Überschreitung (aus, hoch, runter)"

Chris8888

Zitat von: Cluni am 12 Juni 2017, 09:51:19
Mojn!

Miss dieser Sache momentan bitte mal nicht zu viel Bedeutung zu. Matthias und ich haben uns grade drauf verständigt, dass wir einige Sachen umbauen wollen, damit u.A. das automatische Speichern in der Nacht entfällt (was mir seit Anfang an ein Dorn im Auge war). Da dies ein ziemlich grundlegender Umbau sein wird, werden wir eh alles nochmal umkramen müssen und uns dementsprechend auch bei den einzelnen Fallunterscheidungen alles nochmal genausten anschauen. Der Umbau könnte jedoch ein paar Tage in Anspruch nehmen, da wir ja auch noch andere Dinge tun. Ich bzw. wir melden uns mit einer aktuellen Version, sobald der Umbau fertig ist! ;)

Grüße Bernd

Hallo Bernd,

alles klar. Ich gedulde mich einfach. :-)
Wenn ich testen kann...sag Bescheid.

VG
Christian
FHEM 6.0 auf einem PI4 mit div. Homematic-Komponenten, Alexa, Tablet-UI und Homebridge...und läuft einfach. Erweitert mit CCU3 und Homematic-IP...und läuft immer noch.

Franz Tenbrock

Hallo
Sorry erst mal. hab den ganzen Thread nicht gelesen ....
Wie die meisten hier habe ich auch Rolladenaktoren ( HM )
Wie die meisten hier möchte ich die auch smart schalten.
Es gab da mal einen Versuch ein Modul zu entwickeln, leider ging es nicht weiter.
so in der Art verschiedener Attribute, Aussperrschutz ein aus, Kopplung Türsensor etc.

kann kein Modul programmieren, aber wäre es nicht sinnvoller ein Rolladen Smart Modul zu entwickeln ?
Wenn man sich die doifs so anschaut wie lange der Code ist und das für jede Rollade ?

cubi3, Cul 868, ESA2000WZ, EM1000GZ,  FS20, dashboard, 1-Wire, Max Thermos, Max Wandthermo, Max Lan, Fritzbox callmonitor, , nanocul, HM Led16, HM Bewegungsmelder, HM Schalter, RPi, banana, ESP8266, DoorPi

Cluni

#170
Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
Sorry erst mal. hab den ganzen Thread nicht gelesen ....
Wie die meisten hier habe ich auch Rolladenaktoren ( HM )
Wie die meisten hier möchte ich die auch smart schalten.
Grade dann solltest du dir schon die Mühe machen und wenigstens die letzten paar Seiten lesen...  ::)

Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
so in der Art verschiedener Attribute, Aussperrschutz ein aus, Kopplung Türsensor etc.
Das alles kann unser Code bereits (von Frini und mir):
- fahren morgens/abends: (versch Modi: aus, immer oder nur bei Abwesenheit)
  * nach fester Zeit
  * Sonnenauf- bzw -untergang
  * +/- Zufallszeit (damit die Rollladen 1. nicht alle gleichzeitig und 2. an unterschiedlichen Tagen auch in unterschiedlicher Reihenfolge fahren)
  * + bzw. - Offset (damit ich einen Rollladen z.B. abends gezielt als letztes fahren kann trotz Zufallszeiten und Astrofunktion
  * vordefinierbare Position fürs Öffnen
  * Feiertags-/Wochenend-Modus
- zuschaltbarer Aussperrschutz
- automatisch Lüften auf vordefinierbare Position aktivierbar
- automatisches Öffnen auf vordefinierbare Position bei Drehgriffkontakt aktivierbar
- Automatische Abschattung (Möglichkeiten: ja, nein, verspätet, bei Anwesenheit, bei Abwesenheit)
  * frei pro Aktor definierbare Schwellen
  * frei definierbare Wartezeit (man will ja nicht, dass direkt gefahren wird, wenn die jeweilige Schwelle unter/überschritten wird)
  * einstellbarer Winkel, auf dem das Fenster liegt (es werden nur die Seiten abgeschattet, die in der Sonne sind)
  * frei definierbarer Vor- und Nachlaufwinkel (d.h. die Abschattung geschieht um die Fensterposition +/- den Winkeln (nützlich, wenn ein Baum schon Schatten wirft)
  * Höhe der Sonne (Elevation) einstellbar, ab bzw. bis zu der abgeschattet wird (wenn z.B. Gebäude Schatten werfen, wird die Abschattung früher beendet)
  * Helligkeitssensoren können jedem Aktor separat zugeordnet werden
  * Sperrzeit vor Nacht einstellbar (ich will ja nicht, dass der Rollladen wegen Abschattungsende öffnet und z.B. 2min später regulär schließt - dann bleibt er, wo er grade ist)

Ich bin grade aber dabei den kompletten Code umzustrukturieren - das dauert aber noch ein wenig. Aber im Grunde läuft das so alles bei mir zu Hause schon seit Wochen in der aktuellen Version schon recht sicher und zuverlässig...


Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
kann kein Modul programmieren, aber wäre es nicht sinnvoller ein Rolladen Smart Modul zu entwickeln ?
Wenn man sich die doifs so anschaut wie lange der Code ist und das für jede Rollade ?
Bei uns werkeln nur Notifies und ats. Die ats werden auch bleiben (weil sich die Zeiten ja täglich ändern). Momentan sind es aber noch viele Notifies, die auf ein Minimum reduziert werden sollen. Außerdem packt unsere Routine die ganzen Abfragen und Befehle in das jeweilige def des Notify/at - das soll sich bald auch ändern und somit viel übersichtlicher werden. Ein Modul werde ich aber nach momentanen Stand nicht daraus bauen. Aber vielleicht mache ich das ja mal, wenn alles so weit läuft, wie ich es gerne hätte...

Was genau meinst du ansonsten mit einem "Rollladen Smart Modul"?

PS: Rolladen sind zum essen da... :P

Cluni

Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
Sorry erst mal. hab den ganzen Thread nicht gelesen ....
..
...
..
kann kein Modul programmieren, aber wäre es nicht sinnvoller ein Rolladen Smart Modul zu entwickeln ?
Wenn man sich die doifs so anschaut wie lange der Code ist und das für jede Rollade ?

Zitat von: Cluni am 13 Juni 2017, 11:23:42
Was genau meinst du ansonsten mit einem "Rollladen Smart Modul"?



@Franz Tenbrock: Also ehrlich gesagt bin ich gerade ein wenig angepisst. Du stellst eine Frage hier im Thread und sagst dazu, dass du nicht alles gelesen hast. Ich mache mir daraufhin die Arbeit und schreibe dir nochmal haarklein und Schritt für Schritt alles hin, wonach du gefragt hast und stelle dir noch eine Gegenfrage, ob du vielleicht etwas anderes gemeint hast. Aber du findest in über einer Woche noch nicht mal die 2 Minuten Zeit für eine kurze Antwort??!!??!! Echt unglaublich! Ja, ich bin angepisst....  >:(

Franz Tenbrock

Sorry -Asche auf mein Haupt

bin gerade in der knappen Zeit dabei mich in doorpi einzuarbeiten
war nicht Absicht
hab auch im Forum noch mal gesucht
es gab vor ca 1 Jahr mal einen Versuch von einem Forumsteilnehmer die Automatisierung der Rolladen für nicht Programmierer einfacher zu gestalten
ich hab dann nach dem Thread einige Zeit gesucht aber leider nicht gefunden
Es geht darum das nach Definition der HM Rolaldenaktoren eben einige Bedingungen wie nicht runterfahren wenn Tür offen bei sehr vielen Usern vorkommen aber recht schwierig sind zu definieren, oder Rolladen automatisch schließen wenn Sonnenuntergang etc
FHEM bietet zwar extrem viele Möglichkeiten man muss aber schon bei einfachen Dingen immer recht viel wissen.

Bin gerade wieder an einem Bewegungsmelder und an einer Foscam c!

cubi3, Cul 868, ESA2000WZ, EM1000GZ,  FS20, dashboard, 1-Wire, Max Thermos, Max Wandthermo, Max Lan, Fritzbox callmonitor, , nanocul, HM Led16, HM Bewegungsmelder, HM Schalter, RPi, banana, ESP8266, DoorPi

Frini

@Franz Tenbrock: Also wenn ich eines im Zusammenhang mit FHEM gelernt habe ist, dass man eins nach dem anderen machen sollte.
Zuviele offene Projekte bringen zu viele Variablen.
Also ich wüsste aktuell nicht, wie wir ein Modul umsetzen sollten. Wir feilen noch an den Kinderkrankheiten und versuchen den aktuellen Code Fehlerfrei zu bekommen. Cluni investiert wirklich viel freie Zeit.

FHEM ist nunmal kein KlickiBunti, es erfordert viel Einarbeit, ist dafür aber wirklich mächtig  ???

Franz Tenbrock

muss doch auch nicht sein
bewundere viele hier wie viel Zeit in die Projekte gesteckt wird
aber es wird auch sehr viel Zeit investiert um Fragen zu beantworten wegen fehlender Doku ( kann ich hier nicht beurteilen ) oder eben weil es recht kompliziert ist
es sind halt hier auch viele die eben nicht tagtäglich programmieren
cubi3, Cul 868, ESA2000WZ, EM1000GZ,  FS20, dashboard, 1-Wire, Max Thermos, Max Wandthermo, Max Lan, Fritzbox callmonitor, , nanocul, HM Led16, HM Bewegungsmelder, HM Schalter, RPi, banana, ESP8266, DoorPi

Frini

Also ein zwei Posts vor deinem hat Cluni recht detalliert aufgelistet, was zu tun ist um mit dieser Steuerung zu arbeiten.

Cluni

#176
Zitat von: Franz Tenbrock am 21 Juni 2017, 22:25:07
es sind halt hier auch viele die eben nicht tagtäglich programmieren
Aus diesem Grund habe ich mehrere Dinge getan. Es gibt zwei Dateien. In Fhem wird ein neues, eigenes Modul mit dem Namen "99_myUtils_Shutter.pm" erzeugt. Dort hinein kommt der Inhalt der gleichnamigen Datei in meinem Anhang am obigen Post. Alle anderen Voraussetzungen sind denke ich ziemlich gut Schritt-für-Schritt in der Textdatei erklärt. Für das alles braucht man kein Ass im Programmieren sein - mehr an die Hand genommen werden kann man ja schon kaum. Und ich denke, dass alles, was ggf. noch offen bleibt, auch entweder selber recht schnell und einfach hier im Forum herausgefunden werden kann und wenn man sich dazu auch noch nicht im Stande sieht, dann kann man ja auch immer noch hier fragen. Aber grundsätzlich ohne genauer hinzusehen einfach sagen, das ist zu kompliziert - na, dann musst du halt weiterhin Knöpfchen drücken, wenn es dir zu hell ist. Man muss ja wenigstens mal die Zeit investieren und das lesen, was andere mühsam zusammen geschrieben haben als Erklärung für Außenstehende (mal von der Programmierung bzw dem Testen ganz abgesehen)...

Franz Tenbrock

ich will euch doch gar nichts, eher das Gegenteil
.
Auch hier sind mittlerweile 180 Posts, da braucht es schon recht viel Zeit um alles zu lesen.

Ich habe eine funktionierende Steuerung, die aber nicht optimal ist ...

Du verwaist auf eine Post mit erin pm und Erklärungen, der ist aber auch shcon wieder aufgrund unserer Diskussion einiges weiter oben.

Der Übersichtlichkeit  halber wäre doch vielleicht folgendes sinnvoll.
macht einen neuen Thread auf für euer pm Modul, im ersten Post der aktuell gehalten wird die wichtigsten Infos, so dass man sich schnell zurecht findet und schauen kann ob das Modul für einen selber geeignet ist.
Die Updatereihenfolge, die ja in der TXT drin ist, im 1. Post im Klartext dann kann man schnell sehen was läuft  Hilfe und Erweiterungen im Thread, hier dann ein Link damit es alle finden.

Einige machen das doch so und das kommt sicher gut an.
FHEM hat einfach verdient noch besser zu werden,einfach genial was hier geht.

PS : ohen Hilfe hier aus dem Forum hätte ich sicher ncoh gar nichts. Danke an alle
cubi3, Cul 868, ESA2000WZ, EM1000GZ,  FS20, dashboard, 1-Wire, Max Thermos, Max Wandthermo, Max Lan, Fritzbox callmonitor, , nanocul, HM Led16, HM Bewegungsmelder, HM Schalter, RPi, banana, ESP8266, DoorPi

Cluni

#178
Zitat von: Franz Tenbrock am 22 Juni 2017, 11:34:28
Du verwaist auf eine Post mit erin pm und Erklärungen, der ist aber auch shcon wieder aufgrund unserer Diskussion einiges weiter oben.
Die letzten 5 bis 10 Post sollte man aber schon anschauen, wenn man sich mit der Thematik beschäftigt... (die von mir gemeinte Antwort war #170 und nun sind wir bei #178 - ist sogar auf der gleichen Seite)

Zitat von: Franz Tenbrock am 22 Juni 2017, 11:34:28
Der Übersichtlichkeit  halber wäre doch vielleicht folgendes sinnvoll.
macht einen neuen Thread auf für euer pm Modul, im ersten Post der aktuell gehalten wird die wichtigsten Infos, so dass man sich schnell zurecht findet und schauen kann ob das Modul für einen selber geeignet ist.
Die Updatereihenfolge, die ja in der TXT drin ist, im 1. Post im Klartext dann kann man schnell sehen was läuft  Hilfe und Erweiterungen im Thread, hier dann ein Link damit es alle finden.
Hättest du dir die Mühe gemacht die letzten paar (!) Seiten (ich rede nicht von allen Seiten) zu lesen, dann wüsstest du auch bereits, was ich dazu gesagt habe...
siehe hier (ganz unten im Post im PS): https://forum.fhem.de/index.php/topic,69704.msg642383.html#msg642383

Roni1234

@Cluni: ich habe dein Script erfolgreich bei mir im System eingebaut und soweit funktioniert es perfekt. Ich habe lediglich noch den Civil Sonnenauf- bzw Untergang mit eingebaut.

P.S. in der txt war der Fehler mit Rollanden noch drin.