Betatester für neues Modul AutoShuttersControl gesucht!

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

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: Cluni am 10 September 2018, 08:47:50
@BetaUser und @CoolTux: Das mit dem Aussperrschutz ist so gewachsen, weil irgendjemand das mal so haben wollte. Der Schalter sollte nicht mehr bedienbar sein, wenn z.B. die Terrassentür offen ist. Hintergedanke war das Kleinkind, was einen sonst aussperren könnte, wenn man draußen ist. In meinem eigenen Code wollte ich jetzt dafür eine Differenzierung einbauen: Entweder nur Aussperrschutz, welcher die automatischen Fahrten (also von der Abschattung oder automatisches Schließen) sperrt, wenn der Rollladen dadurch weiter herunter fahren würde und die andere Möglichkeit sperrt dann zusätzlich noch (wie bisher) den physikalischen Schalter.

Grüße Cluni

Die Idee finde ich auch super. Ersteres ist bereits im Code implementiert. Der Rest wäre auch simpel ein zu binden.
Danke Bernd
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

Deckoffizier

Hallo CoolTux,

irgendwo ist bei mir noch der Wurm drin.
In einem zweiten UniRoll Rollo stehen unter Readings Readings drin vom Rollo an dem ich nur zum probieren arbeite, von dem Du auch mein List bekommen hast.
An dem anderen Device hatte ich rein gar nichts geändert.

Leider ist das sage mal Probier Rollo leider heute morgen nach Astro nicht hochgefahren.
Geht eigentlich auch gemischt z.B.  morgens nach Astro abends nach time.
Im Log war zwar die Auslösung morgens zu lesen, aber ich vermute der Sendebefehl(bedingt vom angepassten) userReadings war nicht richtig gegenüber gestern abend. Werde mich noch mal dran versuchen.

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

CoolTux

Zitat von: Deckoffizier am 10 September 2018, 09:54:33
Hallo CoolTux,

irgendwo ist bei mir noch der Wurm drin.
In einem zweiten UniRoll Rollo stehen unter Readings Readings drin vom Rollo an dem ich nur zum probieren arbeite, von dem Du auch mein List bekommen hast.
An dem anderen Device hatte ich rein gar nichts geändert.

Leider ist das sage mal Probier Rollo leider heute morgen nach Astro nicht hochgefahren.
Geht eigentlich auch gemischt z.B.  morgens nach Astro abends nach time.
Im Log war zwar die Auslösung morgens zu lesen, aber ich vermute der Sendebefehl(bedingt vom angepassten) userReadings war nicht richtig gegenüber gestern abend. Werde mich noch mal dran versuchen.

Gruß
Hans-Jürgen

Danke für die Rückmeldung. Du fährst Dein Rollo doch über FHEM mit

set Rollo pos 4

Dann muss ja beim Rollo als Attribut für Cmd auch pos drin stehen. Das hast du ja bestimmt.
Dann solltest du schauen ob 0 wirklich auf bei Dir ist und 16 zu, oder anders rum. Ist 16 denn auch der höchste Wert für voll auf oder voll zu?
Und das stellst du dann in PosUp und PosDown entsprechend ein.
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

Moin zusammen!

@Cluni: Willkommen in diesem Thread!

Was den Aussperrschutz angeht: Das Thema wird schnell beliebig kompliziert, wenn man alle Eventualitäten mit abfangen will. Die beiden Varianten, nur die automatischen Fahrten aus dem Modul zu unterbinden und optional den Rolladen gegen lokale Bedienung zu sperren finde ich erst mal einen akzeptablen Anfang.

Auch hier wäre der Vorschlag, nicht alle erforderlichen Angaben auf beliebig viele Attribute zu verteilen, sondern das "auf einen Rutsch" zu machen (oder zwei "Rutsche", damit ggf. für eigene Notify der Rückweg zum Shutter einfacher ist):

AutoShuttersControl_WindowRec FensterKinZimLi [twostate|treestate] [inhibit|blocked|<weitere Sperrvarianten>]

oder mit einem ergänzenden
AutoShuttersControl_WindowRecOptions [twostate|treestate] [inhibit|blocked|<weitere Sperrvarianten>]Das Options-Attribut würde ich dann wieder nicht auf alle Rolläden ausrollen, sondern stattdessen im Falle von nicht gesetzt "twostate" als default unterstellen (und nicht blockiert).

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

Ich dachte da mehr an

In den Rollos

attr AutoShuttersControl_lock-out hard/soft


Und im Moduldevice ein set Befehl mit Reading

set Rollosteuerung on/off


überall wo soft steht wird über das Modul nicht mehr gefahren und wo hard steht wird über das Modul nicht mehr gefahren und entsprechend des Rollotypes hart gesperrt mit inhibit|blocked.
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

Hmm,
an sich wäre ich davon ausgegangen, dass der, der einen FK angibt, auch "immer" mind. die soft-Variante haben will und auch eine automatische Reaktion auf das Öffnen des Fensters haben will, im Sinne von: Fahre den Rolladen mind. bis zur Lüften-Position hoch (es sei denn, der Bewohner schläft?) und durch eine automatische Fahrt vom Modul aus auch nicht weiter runter. Aber doppelt genäht hält besser.

Das Aktivierbar zu machen, finde ich gut, wobei m.E. "set Rollosteuerung lock-out on" als default aktiv sein sollte nach einem Start ohne bekannten Status.
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 10 September 2018, 11:03:37
Hmm,
an sich wäre ich davon ausgegangen, dass der, der einen FK angibt, auch "immer" mind. die soft-Variante haben will und auch eine automatische Reaktion auf das Öffnen des Fensters haben will, im Sinne von: Fahre den Rolladen mind. bis zur Lüften-Position hoch (es sei denn, der Bewohner schläft?) und durch eine automatische Fahrt vom Modul aus auch nicht weiter runter. Aber doppelt genäht hält besser.

Das Aktivierbar zu machen, finde ich gut, wobei m.E. "set Rollosteuerung lock-out on" als default aktiv sein sollte nach einem Start ohne bekannten Status.

;D Du denkst zu Eng. Ich habe zum Beispiel Innenraumrollos, ich brauche sowas wie Lüften und Co gar 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

Beta-User

Zitat von: CoolTux am 10 September 2018, 11:19:59
;D Du denkst zu Eng. Ich habe zum Beispiel Innenraumrollos, ich brauche sowas wie Lüften und Co gar nicht  ;)
Man lernt nie aus ;D .

Aber warum vergibst du überhaupt einen Wert für den FK, wenn das gar keine Auswirkungen haben soll?
Oder babsichtigst du das Attribut für eigene Funktionen außerhalb des Moduls zu nutzen und verhinderst so, dass du die Angaben bei anderen Rolläden doppelt vergeben mußt ;) ?

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

Zitat von: Beta-User am 10 September 2018, 14:01:43
Man lernt nie aus ;D .

Aber warum vergibst du überhaupt einen Wert für den FK, wenn das gar keine Auswirkungen haben soll?
Oder babsichtigst du das Attribut für eigene Funktionen außerhalb des Moduls zu nutzen und verhinderst so, dass du die Angaben bei anderen Rolläden doppelt vergeben mußt ;) ?

Gruß, Beta-User

Sagen wir ich experimentiere da noch etwas. Und muß ja auch bisschen das Modul testen  ;D
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

Cluni

[Klugscheißermodus]
Nur mal so zur Info: https://www.korrekturen.de/wortliste/rollladen.shtml
[/Klugscheißermodus]

...und schnell wech....  8)

CoolTux

Zitat von: Cluni am 10 September 2018, 14:39:39
[Klugscheißermodus]
Nur mal so zur Info: https://www.korrekturen.de/wortliste/rollladen.shtml
[/Klugscheißermodus]

...und schnell wech....  8)

Mit 3 L
Vergiss es, dafür bin ich zu alt  ;D
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

Cluni

Ist doch schon 14 Jahre so - warst du damals auch schon zu alt?  :o  :P

CoolTux

Auf jeden Fall. Da war ich schon 6 Jahre aus der Schule und 3 aus der Berufsschule. Somit schon 2 Jahre Selbstständig. Da macht man sowas nicht mehr mit. Lach
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

#178
Zitat von: Cluni am 10 September 2018, 14:39:39
...und schnell wech....  8)
:o ;D ;D ;D ymmd

Damit auch noch was mit "Fortschritt für's Projekt" in diesem Beitrag steht, hier noch was zum Nebenthema "Wie füttere ich meine vorher nicht vorhandenen Bewohner mit sinnvollem content?":
define rr_Mann dummy
attr rr_Mann event-on-change-reading .*
attr rr_Mann group Persons
attr rr_Mann icon user_unknown
attr rr_Mann readingList state smartphone_MAC smartphone
attr rr_Mann room Steuerung attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep smartphone:absent,present smartphone_MAC
attr rr_Mann userReadings lastState:(home|awoken|asleep|gotosleep|absent) {OldValue($name) }

define rr_Mann_Presence_Timer WeekdayTimer rr_Mann !$we|06:30|awoken !$we| 06:40|home $we|08:00|awoken $we|08:30|home !$we|07:30|absent !$we|19:00|home 01234|21:45|gotosleep 01234|22:00|asleep 56|22:40|gotosleep 01234|56|23:00|asleep {fhem "set $DEVICE $EVENT unless (ReadingsVal($DEVICE,'smartphone','absent') eq 'present' and $EVENT eq 'absent')"  }
attr rr_Mann_Presence_Timer commandTemplate set $NAME  $EVENT
attr rr_Mann_Presence_Timer disable 0
attr rr_Mann_Presence_Timer group Persons
attr rr_Mann_Presence_Timer icon status_automatic
attr rr_Mann_Presence_Timer room Steuerung

define rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {if ($EVTPART1 eq "inactive") {
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");
  } else {
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone present");
  }
}

define rr_xn_smartphone notify rr_.*:smartphone:.* {my $newState = "absent";
$newState = "home" if ($EVTPART1 eq "present");
my $timerName = $NAME."_Presence_Timer";
fhem "set $NAME $newState" if (ReadingsVal($timerName,"currValue","home") eq "absent"); }
attr rr_xn_smartphone group Persons
attr rr_xn_smartphone icon edit_settings
attr rr_xn_smartphone room Steuerung


(Achtung: das ist die modifizierte Ausgabe von einem "list -r" und sollte so für den RAW-Input passen; aber bitte ggf. erst nochmal prüfen, v.a. wg. der Zeilenumbrüche).
Irgendwann werde ich wohl um diese ROOMMATE-Dingens nicht rumkommen >:( , aber vermutlich macht das demnächst eh' Sinn wg. der Heizungssteuerung.
Jedenfalls scheint nach einem "set rr_Mann smartphone_MAC xx_usw:" erkannt zu werden, wenn ich wider Erwarten zuhause bin und dann auch wieder gehe... (das notify für die Auswertung der Fritzbox-Readings ist eine generalisierte Variante des Wiki-Abschnittes). Wer's nachbauen will/muss: Das ist nicht vollständig erprobt, kritische Prüfung wäre also angesagt...
Vielleicht ergänze ich das noch um eine Kalender-Auswertung, dann können meine Kinder das zum eigenen Komfort zusätzlich darüber erledigen bzw. teilweise übersteuern. Oder Telegram?!? Mist, warum gibt es hier nur so viele Optionen 8) .

[ad Klugscheißermodus]
Wer Schreibfehler findet, darf sie behalten; Verbesserungen am Code nehme ich dagegen gerne entgegen...
Bin zwar auch schon etwas länger aus der Schule, aber alles dreimal mit Duden Korrektur zu lesen, ist auch nicht meins ;) . In der Regel kann man schon erkennen, was mit dem Geschreibsel gemeint gewesen sein könnte...
[/ad Klugscheißermodus]

Gruß, Beta-User

EDIT: Code verbessert
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

Beta-User

Was für die Wunschliste:
Das mit der structure (und ggf. weiteren) wäre einfacher, wenn bei Nichtvorhandensein des oldState-Readings stattdessen lastState verwendet würde - das macht structure nämlich automatisch und dürfte leicht in den Code zu integrieren sein :) .

Ansonsten läuft seit eben V. 0.1.35 :) .

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