[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[marvin78]

Ich habe für unser Schildkrötengehege ein Modul gebaut, welches für bestimmte Dinge jeweils ein Attribut für eigene Bedingungen besitzt (Perl). Diese Attribute werden, wenn vorhanden im Modul ausgewertet. Das ist in dem Fall sehr einfach und geradlinig gestaltet, aber ggf. kann man sowas in der Art für gewisse Dinge einbauen?

Ich denke wirklich, dass man die Komplexität hier beliebig ausbauen könnte und das gewisse Dinge nicht vom Modul gestemmt werden können.

[FunkOdyssey]

Könnte es evtl. sein, dass es noch einen kleinen Bug gibt?

Ablauf:
- Meine Jalousien fahren abends über Brightness (always|brightness) runter
- Das Hochfahren ist deaktiviert. (ASC_Mode_Up = "off" und ASC_Up = "Astro").
- Ich habe nirgendwo eine Steuerung anhand von Residents aktiviert.
- Mein Residents-Modul ist aber im ASC-Modul in der Attributen hinterlegt.

- Jalousien sind am Donnerstag abend wie gewollt heruntergefahren.
- Am Freitag morgen wurden die Jalousien manuell hochgefahren. Residents war zu diesem Zeitpunkt noch "asleep".
- Das Hochfahren war vor dem Astro-Zeitpunkt und vor den hinterlegten Uhrzeiten (ASC_Time_Up_Early)
- Residents-Modul wechselte auf "home"
- und die manuell hochgefahrenen Jalousien fuhren wieder herunter.

Anbei die Lists&Logs

[FunkOdyssey]

Andere Installation - anderer Fehler:


ASC-Log

Code Auswählen Erweitern

2018-11-16_07:57:42 Rolladensteuerung Homekit_nextAstroTimeEvent: 16.11.2018 - 16:33
2018-11-16_07:57:42 Rolladensteuerung created new drive timer

FHEM-Log

Code Auswählen Erweitern

2018.11.16 07:57:42.003 1: ERROR: empty name in readingsBeginUpdate
2018.11.16 07:57:42.003 1: stacktrace:
2018.11.16 07:57:42.003 1:     main::readingsBeginUpdate           called by ./FHEM/73_AutoShuttersControl.pm (1340)
2018.11.16 07:57:42.003 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (1556)
2018.11.16 07:57:42.003 1:     AutoShuttersControl::SunRiseShuttersAfterTimerFn called by fhem.pl (3144)
2018.11.16 07:57:42.003 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.11.16 07:57:42.003 1: readingsUpdate(,ASC_Time_DriveDown,16.11.2018 - 16:33) missed to call readingsBeginUpdate first.
2018.11.16 07:57:42.003 1: stacktrace:
2018.11.16 07:57:42.004 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (1341)
2018.11.16 07:57:42.004 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (1556)
2018.11.16 07:57:42.004 1:     AutoShuttersControl::SunRiseShuttersAfterTimerFn called by fhem.pl (3144)
2018.11.16 07:57:42.004 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.11.16 07:57:42.004 1: readingsUpdate(,ASC_Time_DriveUp,17.11.2018 - 07:59) missed to call readingsBeginUpdate first.
2018.11.16 07:57:42.004 1: stacktrace:
2018.11.16 07:57:42.004 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (1353)
2018.11.16 07:57:42.004 1:     AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (1556)
2018.11.16 07:57:42.004 1:     AutoShuttersControl::SunRiseShuttersAfterTimerFn called by fhem.pl (3144)
2018.11.16 07:57:42.004 1:     main::HandleTimeout                 called by fhem.pl (649)

Es gibt hier scheinbar (wieder) ein Homekit-Device. Das hatten wir doch schon früher in ähnlicher Form. Das ist aber ein Raum und keine Jalousie.

Code Auswählen Erweitern

Internals:
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       Rolladensteuerung
   NOTIFYDEV  global,Rolladensteuerung,zw_jal_diele,zw_jal_hwr,zw_jal_kueche_gross,zw_jal_kueche_klein,zw_jal_wc,rgr_Residents
   NR         150
   NTFY_ORDER 51-Rolladensteuerung
   STATE      manual
   TYPE       AutoShuttersControl
   VERSION    0.2.0.5
   OLDREADINGS:
   READINGS:
     2018-11-16 07:57:42   Homekit_nextAstroTimeEvent 16.11.2018 - 16:33
     2018-11-12 16:57:28   lockOut         off
     2018-11-12 16:57:28   partyMode       off
     2018-11-15 14:43:41   room_Homekit_Jalousien zw_jal_diele,zw_jal_hwr,zw_jal_kueche_gross,zw_jal_kueche_klein,zw_jal_wc
     2018-11-12 16:57:28   selfDefense     off
     2018-11-16 09:41:39   state           manual
     2018-11-12 16:57:28   sunriseTimeWeHoliday off
     2018-11-15 14:43:41   userAttrList    rolled out
     2018-11-16 08:00:26   zw_jal_diele_PosValue 99
     2018-11-16 08:00:02   zw_jal_diele_lastPosValue 0
     2018-11-16 08:00:02   zw_jal_diele_nextAstroTimeEvent 16.11.2018 - 16:33
     2018-11-16 08:00:21   zw_jal_hwr_PosValue 99
     2018-11-16 08:00:02   zw_jal_hwr_lastPosValue 0
     2018-11-16 08:00:02   zw_jal_hwr_nextAstroTimeEvent 16.11.2018 - 16:33
     2018-11-16 09:41:39   zw_jal_kueche_gross_PosValue 99
     2018-11-16 08:30:02   zw_jal_kueche_gross_lastPosValue 0
     2018-11-16 08:30:02   zw_jal_kueche_gross_nextAstroTimeEvent 16.11.2018 - 16:33
     2018-11-16 08:30:22   zw_jal_kueche_klein_PosValue 99
     2018-11-16 08:30:02   zw_jal_kueche_klein_lastPosValue 0
     2018-11-16 08:30:02   zw_jal_kueche_klein_nextAstroTimeEvent 16.11.2018 - 16:33
     2018-11-16 08:30:25   zw_jal_wc_PosValue 99
     2018-11-16 08:30:02   zw_jal_wc_lastPosValue 0
     2018-11-16 08:30:02   zw_jal_wc_nextAstroTimeEvent 16.11.2018 - 16:33
   helper:
     shuttersList:
       zw_jal_diele
       zw_jal_hwr
       zw_jal_kueche_gross
       zw_jal_kueche_klein
       zw_jal_wc
   monitoredDevs:
     rgr_Residents:
       Rolladensteuerung ASC_residentsDevice
     zw_jal_diele:
     zw_jal_hwr:
     zw_jal_kueche_gross:
     zw_jal_kueche_klein:
     zw_jal_wc:
Attributes:
   ASC_autoAstroModeEvening REAL
   ASC_autoAstroModeMorning REAL
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_expert 1
   ASC_freezeTemp 3
   ASC_residentsDevice rgr_Residents
   ASC_residentsDeviceReading state
   ASC_temperatureReading temperature
   ASC_twilightDevice astro
   devStateIcon selfeDefense.terrace:fts_door_tilt created.new.drive.timer:clock .*asleep:scene_sleeping roommate.(awoken|home):user_available residents.(home|awoken):status_available manual:fts_shutter_manual selfeDefense.active:status_locked selfeDefense inactive:status_open day.open:scene_day night close:scene_night


[CoolTux]

Code Auswählen Erweitern


2018-11-15 14:43:41   room_Homekit_Jalousien ...

In der Liste finde ich den Rolladen Homekit gar nicht.

Code Auswählen Erweitern


shuttersList:
       zw_jal_diele
       zw_jal_hwr
       zw_jal_kueche_gross
       zw_jal_kueche_klein
       zw_jal_wc
   monitoredDevs:
     rgr_Residents:
       Rolladensteuerung ASC_residentsDevice
     zw_jal_diele:
     zw_jal_hwr:
     zw_jal_kueche_gross:
     zw_jal_kueche_klein:
     zw_jal_wc:

Irgendwie muss er ja auf den Namen gekommen sein.
Kann ich erstmal nur so festhalten und wie beobachten das. Vielleicht ein Neustart machen und nach dem Neustart noch mal ein createNewNofifyDev

[CoolTux]

Könnte es evtl. sein, dass es noch einen kleinen Bug gibt?

Ablauf:
- Meine Jalousien fahren abends über Brightness (always|brightness) runter
- Das Hochfahren ist deaktiviert. (ASC_Mode_Up = "off" und ASC_Up = "Astro").
- Ich habe nirgendwo eine Steuerung anhand von Residents aktiviert.
- Mein Residents-Modul ist aber im ASC-Modul in der Attributen hinterlegt.

- Jalousien sind am Donnerstag abend wie gewollt heruntergefahren.
- Am Freitag morgen wurden die Jalousien manuell hochgefahren. Residents war zu diesem Zeitpunkt noch "asleep".
- Das Hochfahren war vor dem Astro-Zeitpunkt und vor den hinterlegten Uhrzeiten (ASC_Time_Up_Early)
- Residents-Modul wechselte auf "home"
- und die manuell hochgefahrenen Jalousien fuhren wieder herunter.

Anbei die Lists&Logs

Danke Dir für die sehr ausführliche Beschreibung. Dann schaue ich mir gleich mal an.



Grüße

[Cluni]

Das beste, was mit derzeit einfällt, wäre eine Möglichkeit, einen weiteren Device (pro Rolladen) anzugeben, wo eine Reading die Fahrt blockieren könnte. Sowas wie: ASC_inhibit_dev / ASC_inhibit_Reading.

Diesen kann man dann mit eigenen Scripten etc. befüllen. Dann könnte man auch für die heufigsten Anwendungsfälle spezielle Module entwickeln, die solche Informationen bereitstellen würden, ohne dass dabei das Hauptmodul mit verschiedensten Logiken überfrachtet wird.
Dürfte die Entwicklungszeit verkürzen und die Fehlersuche erleichtern.

Was hält ihr davon?

Diese Idee finde ich super genial! Ein + dafür von mir!!!

[CoolTux]

Könnte es evtl. sein, dass es noch einen kleinen Bug gibt?

Ablauf:
- Meine Jalousien fahren abends über Brightness (always|brightness) runter
- Das Hochfahren ist deaktiviert. (ASC_Mode_Up = "off" und ASC_Up = "Astro").
- Ich habe nirgendwo eine Steuerung anhand von Residents aktiviert.
- Mein Residents-Modul ist aber im ASC-Modul in der Attributen hinterlegt.

- Jalousien sind am Donnerstag abend wie gewollt heruntergefahren.
- Am Freitag morgen wurden die Jalousien manuell hochgefahren. Residents war zu diesem Zeitpunkt noch "asleep".
- Das Hochfahren war vor dem Astro-Zeitpunkt und vor den hinterlegten Uhrzeiten (ASC_Time_Up_Early)
- Residents-Modul wechselte auf "home"
- und die manuell hochgefahrenen Jalousien fuhren wieder herunter.

Anbei die Lists&Logs

Kann ich nachvollziehen und werde ich heute noch fixen. Hoffe ohne Nebeneffekte 

Vielen Dank. Haste super gemacht!



Grüße

[CoolTux]

Ich habe in der kommenden Version 0.2.0.6 die Idee mit ASC_Antifreeze off,soft,am,pm,hard nun fertig implementiert.
bei am und pm wird in den entsprechenden Tageszeiten gar nicht gefahren, bei soft wird beim komplett schließen Befehl bis zur ASC_Antifreeze_Pos gefahren und bei hard wird überhaupt nicht gefahren. Ich denke das sollte vorerst reichen.


Grüße

[CoolTux]

Ich habe auch Dachrolläden. Da diese eine Hindernisserkennung besitzen, stellt sich das  Problem nicht so scharf. Dennoch würde ich unter bestimmten Umständen eine Fahrt blockieren wollen. Allerdings nicht, wenn es nur <2°C draußen ist. Ich würde noch mit einberechnen, wenn es z.B. am Vortag/Nacht geregnet hat.
Wie man sieht, kann man es beliebig komplex gestallten. Daher denke ich, wir benötigen eine Art Plugin-Konzept, dmit man eigene Logiken einbinden kann.
Das beste, was mit derzeit einfällt, wäre eine Möglichkeit, einen weiteren Device (pro Rolladen) anzugeben, wo eine Reading die Fahrt blockieren könnte. Sowas wie: ASC_inhibit_dev / ASC_inhibit_Reading.

Diesen kann man dann mit eigenen Scripten etc. befüllen. Dann könnte man auch für die heufigsten Anwendungsfälle spezielle Module entwickeln, die solche Informationen bereitstellen würden, ohne dass dabei das Hauptmodul mit verschiedensten Logiken überfrachtet wird.
Dürfte die Entwicklungszeit verkürzen und die Fehlersuche erleichtern.

Was hält ihr davon?

Das Script dürfte wenn dann lediglich true oder false zurück geben. Dann kann man das recht leicht im Modul implementieren.
man könnte es auch als userReadings mit Standardnamen machen, wenn im Reading eine 1 steht true und bei 0 false. So kann man 2-3 userReadings vom Modul abfragen lassen welche innerhalb des Moduls an den entsprechenden Positionen ausgewertet wird.

ASC_userShading z.B wäre eine zusätzliche Abfrage zum Beschatten. Wenn hier eine 1 drin steht und alle anderen Bedingungen für den Rolladen erfüllt sind wird beschattet. Und so weiter.

[Cluni]

ASC_user_inhibit als userReading wäre auch klasse. Da könnte man dann eintragen, was immer man will - entweder die direkte Abfrage eines Readings eines anderen Device oder aber auch ein Perl-Script. Man muss sich nur auf die Syntax einigen true/false oder 1/0.

[hexenmeister]

Grundsätzlich finde ich das gut mit userReading. Aber auch Extra-Geräte hätten ihren Charme.
Wenn man zusätzlich einen Device/Reading angeben kann, dann könnte man eine Reihe von 'Plugin'-Devices schreiben, die auf bestimmte Standardsituationen mit einer internen Logik antworten liefern würden.

Beispiele:
- Gerät zum Berechnen von Frost-Schutznotwendigkeit (Eingaben: Temperatur, Regensensor, Forecast,..)
- Gerät zum Berechnen von Beschattungsnotwendigkeit (Eingaben, azimuth, Elevation, Temperatur, Fenster-Orientierung,..)
- Sondergerät für Enno für Beschattung (Eingaben: Fernseher-Zustand und SOnnenstand)

Damit wird ASC-Modul einfacher und übersichtlichen und Du muss nicht alle diese Sondergerätschaften selbst entwicklen

[Cluni]

Das wäre aber doch auch mit einem userReading genau so möglich?!


Gesendet von iPhone XR mit Tapatalk

[hexenmeister]

Naja, in userReading muss man dann irgendein Perl-Aufruf schreiben. Ich finde für die meisten Nutzer ist einfacher und übersichtlicher ein Modul / Gerät zu konfigurieren, als ein Script.
Ich kann mit beidem leben, halte aber ein Extra-Gerät für benutzerfreundlicher. Außerdem würde man in der UI auch gleich sehen, wie die Bedingung gerade steht.

[CoolTux]

Beispiele:
- Gerät zum Berechnen von Frost-Schutznotwendigkeit (Eingaben: Temperatur, Regensensor, Forecast,..)
- Gerät zum Berechnen von Beschattungsnotwendigkeit (Eingaben, azimuth, Elevation, Temperatur, Fenster-Orientierung,..)
- Sondergerät für Enno für Beschattung (Eingaben: Fernseher-Zustand und SOnnenstand)

Ok jetzt hast Du dann Dein Device und Dein Reading und noch irgendwas, aber wie, wo soll das ausgewertet werden ab wann das nun greift? Das verstehe ich gerade nicht. Im Modul muss ja bei  Frost-Schutznotwendigkeit immer noch Code drin stehen der sagt wenn Temperatur unter X und Regensensor meldet Regen und Forecast sagt Frost in der Nacht mache XXXX

[Cluni]

Na die Auswertung ist doch relativ einfach: Das Modul prüft vor jeder Fahrt, ob dieses Reading true oder false ist. Wenn true, dann wird einfach nicht gefahren und fertig.

Naja, in userReading muss man dann irgendein Perl-Aufruf schreiben. Ich finde für die meisten Nutzer ist einfacher und übersichtlicher ein Modul / Gerät zu konfigurieren, als ein Script.

Das mag sein, aber das "Script" kann ja auch nur der Befehl "ReadingVal" zum lesen eines bestimmten Readings sein. Das sollte jeder noch hinbekommen...

Außerdem würde man in der UI auch gleich sehen, wie die Bedingung gerade steht.

Den aktuellen Wert sieht man doch dann auch?! Oder bin hab ich jetzt was falsches im Kopf?