Betatester für neues Modul AutoShuttersControl gesucht!

Begonnen von CoolTux, 01 September 2018, 12:10:35

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 17:29:34
Hm - die Logik verstehe ich nicht. "Aufwecken" ist immer etwas, das automatisch zeitgesteuert ablaufen sollte (oder manuell, wenn der Wecker ausgeschaltet war). Das Herunterfahren der Rollläden ist viel komplizierter. In meinem TimeHelper für YAAHM habe ich das wie folgt realisiert:

"wakeup" => Fährt Rollläden hoch.
"night"     => Fährt Rollläden herunter, aber nur wenn a.) nicht durch Roll.block manuell blockiert UND b.) nicht im Party-Modus
"sleep"    => Manueller Event, hat mit Rollläden nur dann etwas zu tun, wenn diese beim "night"-Event wegen des Party-Modus nicht heruntergefahren wurden.

Klar ist, dass der Party-Modus nicht während des Absence-Modus eingeschaltet werden kann.

LG

pah

Das ganze ist noch viel flexibler gelöst.
Aber erst mal zu asleep und awoken und home und so. awoken gibt es bei mir zum Beispiel nur wenn mein Wecker gestellt ist. Am Wochenende geht es direkt von asleep zu home. Nur zur Erklärung.

Nun zum flexibleren. Die Roommate/Bewohner Sache ist pro Rolladen ein zu stellen. Es geht also um die Bewohner des jeweiligen Zimmers. Wenn meine Tochter bis 11 Uhr schlafen will soll bei Sonnenaufgang ihr Rollo nicht hochfahren. Wenn meine Freundin und ich aufstehen soll unser Rollo hochfahren. Alle anderen Rollos in Küche, Bad, Wohnzimmer können schon bei Sonnenaufgang hoch fahren.
So ist mein Gedanke.


Bin gerade dabei eine kurze Anleitung zu schreiben. Viel zu beachten gibt es ja noch nicht.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

enno

Moin zusammen,

klingt interessant.
ZitatWas solltet Ihr dazu haben? Rolläden, Fensterkontakte und Bewohnerstatus auf Basis von Residents/Roomates in englisch. Es können auch Dummys sein welche home,asleep,gotosleep und awoken setzen. Wichtig wäre noch ein Reading lastState. Aber sowas kann man schnell zaubern, ich helfe da gerne.

- Rolläden (Somfy)
- Fensterkontakte (1-Wire)
- Bewohnerstatus (noch nicht, schnell gemacht auf Basis Bewegungsmelder und diversen Lichtschaltern (alles Homematic))

Mache das zur Zeit mit DOIF, ASTRO,Dummys, wenn es mit eurem Modul eleganter geht dann schaue ich mir das mal an. Ich habe aber die Befürchtung dass das Produkt für mich als nicht Informatiker wieder zu komplex wird. An pahs YAAHM und Alarmanlage bin ich schon erfolgreich gescheitert.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

Beta-User

Zitat von: CoolTux am 01 September 2018, 17:17:29Wow, mit soviel Zuspruch hätte ich jetzt nicht gerechnet.
Warum nicht?

Brauchst die nur den Thread von cluni und den Vorgänger-Thread dazu anzusehen, dass weißt du, wie viele darauf gewartet haben ;D 8) ::) . (cluni mag zusätzlich schmunzeln, er dürfte sich noch an den eigentlichen Anlaß erinnern, da war uns beiden was zu kompliziert, wir haben es einfach nicht verstanden.... Jetzt programmieren wir halt Perl ;D ;D ;D ).

@enno und andere:
Nur Mut, cluni hat sehr viele "Normaluser" erfolgreich beim Einrichten unterstützt, das ist kein Hexenwerk (auch wenn ich selbst auch nicht sooo begeistert bin, dass scheinbar zwingend eine An- und Abwesenheitserkennung erforderlich sein soll. Aber notfalls mach ich mir dazu ein paar weekdaytimer oder einen separateren Kalender, dann wird das zwar wieder starr, aber evtl. hilft es auch zukünfitgen Neueinsteigern, erst mal eine Basis zu schaffen und dann erst Bewohner für Bewohner wirklich "zu verfolgen"...

Zitat von: CoolTux am 01 September 2018, 17:17:29So in etwa

Für den Fall, dass es jemand ohne weitere Zauberei mit raw-Import haben will ;) :
defmod rr_Maria dummy
attr rr_Mann readingList state
attr rr_Mann room Test
attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep
attr rr_Mann userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }

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

CoolTux

Zitat von: enno am 01 September 2018, 17:42:23
Moin zusammen,

klingt interessant.
- Rolläden (Somfy)
- Fensterkontakte (1-Wire)
- Bewohnerstatus (noch nicht, schnell gemacht auf Basis Bewegungsmelder und diversen Lichtschaltern (alles Homematic))

Mache das zur Zeit mit DOIF, ASTRO,Dummys, wenn es mit eurem Modul eleganter geht dann schaue ich mir das mal an. Ich habe aber die Befürchtung dass das Produkt für mich als nicht Informatiker wieder zu komplex wird. An pahs YAAHM und Alarmanlage bin ich schon erfolgreich gescheitert.

Gruss
  Enno

Hallo Enno,

Na ich hoffe ja nicht das es zu komplex zum einrichten ist. Aber auch gerade das gilt es zu überprüfen. Ich bin bekannt dafür Anwenderfreundlich zu entwickeln. Siehe AMAD und den Installationsassistenten.
Und noch ist es klein und überschaubar.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Zitat von: Beta-User am 01 September 2018, 17:59:12
@enno und andere:
Nur Mut, cluni hat sehr viele "Normaluser" erfolgreich beim Einrichten unterstützt, das ist kein Hexenwerk (auch wenn ich selbst auch nicht sooo begeistert bin, dass scheinbar zwingend eine An- und Abwesenheitserkennung erforderlich sein soll. Aber notfalls mach ich mir dazu ein paar weekdaytimer oder einen separateren Kalender, dann wird das zwar wieder starr, aber evtl. hilft es auch zukünfitgen Neueinsteigern, erst mal eine Basis zu schaffen und dann erst Bewohner für Bewohner wirklich "zu verfolgen"...

Es wird später keine Voraussetzung sein. Aber zum testen wäre es super.
Und ich denke mal so verkehrt ist das auch nicht. Warum soll in den Schlafräumen der Rolladen bei Sonnenaufgang fahren wenn dort noch geschlafen wird.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

ACHTUNG!!

Ich habe den ersten Post angepasst.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Prof. Dr. Peter Henning

ZitatAber erst mal zu asleep und awoken und home und so. awoken gibt es bei mir zum Beispiel nur wenn mein Wecker gestellt ist. Am Wochenende geht es direkt von asleep zu home. Nur zur Erklärung.

Ist aber nicht ganz konsistent - denn "home" ist ein Zustand, "awoken" auch - aber der Übergang löst doch das Event aus. Beispielsweise wird bei mir auch das Teewasser aufgesetzt.

LG

pah

CoolTux

Zitat von: Prof. Dr. Peter Henning am 01 September 2018, 18:46:40
Ist aber nicht ganz konsistent - denn "home" ist ein Zustand, "awoken" auch - aber der Übergang löst doch das Event aus. Beispielsweise wird bei mir auch das Teewasser aufgesetzt.

LG

pah

Ich denke das ist für jeden unterschiedlich. Bei mir wird schon beim Übergang von asleep zu awoken der Kaffee gekocht. Von awoken zu home brauche ich keinen Kaffee oder mache ihn später (Wochenende) zusammen mit einer Durchsage wie das Wetter ist, wird und wo Fenster auf sind.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Prof. Dr. Peter Henning

Zitatawoken zu home

Oben hast du geschrieben, dass es am Wochenende direkt von asleep nach home wechselt. Das zeigt m.E., dass Eure Begriffe noch genauer definiert werden könnten  ;)

Wenn mein (FHEM-)Wecker ausgestellt ist, gibt es natürlich den Zustandsübergang zu "Morgen" - aber ohne dass die Aufwachaktionen durchgeführt werden. Das Event "Wakeup" kann (gerne auch später ...) einfach ausgelöst werden, indem man einem der Stimmenerkennungsdevices (3 Tablets und das Weckerdisplay auf einem festmontierten Handy) "Guten Morgen" wünscht. Vorher werden weder Rollläden, noch Teewasser in Bewegung gesetzt.

Genaue Definition der verschiedenen Typen von Übergängen hier: https://wiki.fhem.de/wiki/Modul_YAAHM#Tages-Profil.

Die Flexibilisierung ist gut. Geht bei YAAHM auch, indem für einen anderen Nutzer ein eigenes Wochenprofil angelegt wird. Das betrifft aber nicht die astronomischen Zeiten, sondern nur die manuellen Events.

LG

pah

Beta-User

So, ersten Test gemacht, und gleich Anmerkungen und Wünsche:

- Mein Raw-Vorschlag war nicht durchgängig ;) : Entweder "Mann" oder "Maria", gemischt ist naja...
- zu chmod: Habe das Modul mit sudo+mcedit erstellt und dann - wie üblich - einfach user+gruppe angepaßt (chown fhem:dialout). Dann das define durchgeführt => Fehlermeldung, Modul angeblich nicht vorhanden. Reload veranlaßt => geht nicht... chmod wie vorgeschlagen durchgeführt => selbes Ergebnis... Erst nach einem Neustart wollte es.
Vorschlag: Hinweis, dass chown auf (idR.) fhem:dialout + Neustart erforderlich ist.

- das mit "auto" ist ja nett, aber meine Rolladen heißen zwar alle Roll.*, aber eben nicht die Jalousien :( . Habe noch nicht in den Code gesehen, aber evtl. wäre es ja möglich, zwei set-Varianten dazuzufügen: "set bla addShutter <devspec>" und das Gegenteil "removeShutter"?
Dann könnte man z.B. mit Filter auf alle passenden HM-Typen arbeiten. (Die Luxus-Variante wäre zum klicken wie bei der Raum-Auswahl).

Dann mach' ich jetzt mal weiter...

Gruß, Beta-User

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

CoolTux

Vielen Dank für's testen. Eigentlich sollte es auch ohne restart klappen. Schaue ich mir mal an. Eventuell liegt es an der Art wie ich das Modul aufgebaut habe. Ich arbeite das erste mal mit package Namen.


Wie fangen denn Deine Jalousien an mit Namen? Eventuell kann ich da was machen.
Auswahl per Checkbox ist eine gute Idee. Lege ich ganz unten auf die To-Do Liste.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

der-Lolo

Guten Morgen Julian & Bernd,
mit begeisterung nehme ich wahr das hier ein neues Modul entsteht... Gerne würde ich das in Zukunft einsetzen - bei mir sind aber sicher noch einige "Grundvorraussetzungen" zu treffen. Welche Informationen werden von den jeweiligen Rollos benötigt? Zur Zeit habe ich nur eine simple Tasterschaltung realisiert - kurzer druck nach oben fährt obere Endlage an, kurzer Druck nach unten fährt untere endlage an. Langer druck bringt die Steuerung in Handbetrieb und öffnet oder schliest solange wie betätigt wird...
Denkbar ist hier auch eine rückmeldung der Position von meiner zentralen Steuerung aus.

Wäre also toll wenn Ihr darstellt welche informationen von den jeweiligen Rollo Devices genutzt und verarbeitet werden...

Danke!

CoolTux

Zitat von: der-Lolo am 02 September 2018, 09:14:39
Guten Morgen Julian & Bernd,
mit begeisterung nehme ich wahr das hier ein neues Modul entsteht... Gerne würde ich das in Zukunft einsetzen - bei mir sind aber sicher noch einige "Grundvorraussetzungen" zu treffen. Welche Informationen werden von den jeweiligen Rollos benötigt? Zur Zeit habe ich nur eine simple Tasterschaltung realisiert - kurzer druck nach oben fährt obere Endlage an, kurzer Druck nach unten fährt untere endlage an. Langer druck bringt die Steuerung in Handbetrieb und öffnet oder schliest solange wie betätigt wird...
Denkbar ist hier auch eine rückmeldung der Position von meiner zentralen Steuerung aus.

Wäre also toll wenn Ihr darstellt welche informationen von den jeweiligen Rollo Devices genutzt und verarbeitet werden...

Danke!

Hallo,

Das Modul benötigt Devices worüber die Rollos gesteuert werden. Diese Devices müssen Befehl unterstützen über diesen Du in Prozent die Rollos fahren kannst. 0 oben 100 unten oder auch umgekehrt. Dieser Befehl muss auch 1 zu 1 als Reading vorhanden sein.

Beispiel:
set Rolloname position 80

Reading position 80

oder

set Rolloname pct 20

Reading pct 20

Wie im ersten Post geschrieben. Mehr ist nicht nötig.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Was das "erste Mal" angeht: "Eigentlich" ist schon richtig, aber es hat halt nicht funktioniert...

Was die Jalousien angeht: Fangen alle mit "Jalou" an, alle passenden Devices kämen mit "list TYPE=CUL_HM:FILTER=subType=blindActuator". Warum macht ihr die Initialisierung bei "auto" nicht mit dem und weiteren TYPE-Filtern (ROLLO, somfy...), soweit das bisher unterstützt wird?

Was "unten" auf der Todo-Liste angeht: Manches geht hinterher schwer wieder zu ändern; evtl. wäre es eine Idee, die eingebundenen Devices in einer internen Liste zu speichern, das sollte dann aber evtl. gleich überall berücksichtigt werden (ohne in den code gesehen zu haben, kann auch sein, dass das nachträglich noch leicht geht). Aber was das aufhübschen angeht, bin ich voll bei dir...
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

CoolTux

Zitat von: Beta-User am 02 September 2018, 10:42:20
Was das "erste Mal" angeht: "Eigentlich" ist schon richtig, aber es hat halt nicht funktioniert...

Was die Jalousien angeht: Fangen alle mit "Jalou" an, alle passenden Devices kämen mit "list TYPE=CUL_HM:FILTER=subType=blindActuator". Warum macht ihr die Initialisierung bei "auto" nicht mit dem und weiteren TYPE-Filtern (ROLLO, somfy...), soweit das bisher unterstützt wird?
Das ist mir viel zu speziell. Meine Rollo Devices haben zum Beispiel keines Deiner Filter. Vielleicht hat auch einer nur Dummys und steuert damit GPIOs an. Jalou baue ich gerne noch ein.
Man sieht ja in den Readings wunderbar welche Devices erwischt wurden. Sollten noch Feinheiten nötig sein so kann man das später ohne Probleme noch machen.

Zitat von: Beta-User am 02 September 2018, 10:42:20
Was "unten" auf der Todo-Liste angeht: Manches geht hinterher schwer wieder zu ändern; evtl. wäre es eine Idee, die eingebundenen Devices in einer internen Liste zu speichern, das sollte dann aber evtl. gleich überall berücksichtigt werden (ohne in den code gesehen zu haben, kann auch sein, dass das nachträglich noch leicht geht). Aber was das aufhübschen angeht, bin ich voll bei dir...

Es gibt eine interne ARRAY List aller Rollos. Wir haben versucht weitestgehend flexibel zu entwickeln.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net