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

[CoolTux]

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.

Hatte das eher so verstanden das dort lediglich die Namen der Devices und der Readings stehen und das Modul abfragen soll und dann müsste es ja auch auswerten.

[hexenmeister]

Das mag sein, aber das "Script" kann ja auch nur der Befehl "ReadingVal" zum lesen eines bestimmten Readings sein. Das sollte jeder noch hinbekommen...
Den aktuellen Wert sieht man doch dann auch?! Oder bin hab ich jetzt was falsches im Kopf?

Schon, aber irgendwie find ich das zu viel verlangt von einem Anfänger.
Wenn es kein reines Script ist, dann natürlich kann man was sehen.

Grundsättzlich ist man schon mit userReading flexiebler. ABer auch etwas kryptischer.

[Cluni]

Ok, mir soll's egal sein. Ich komme mit beidem zurecht. Und zur Not kann man dort ja auch einen Dummy angeben, den man dann nach eigenem Gusto "behandelt"....
Mit einem userReading könnte man halt direkt ohne Zwischendevice mächtigere Aktionen erreichen.

[hexenmeister]

Hatte das eher so verstanden das dort lediglich die Namen der Devices und der Readings stehen und das Modul abfragen soll und dann müsste es ja auch auswerten.

So war das auch gemeint. Das Gerät kommt in NOTIFYDEV und in NotifyFn fragt man den Wert ab.

[hexenmeister]

Ok, mir soll's egal sein. Ich komme mit beidem zurecht. Und zur Not kann man dort ja auch einen Dummy angeben, den man dann nach eigenem Gusto "behandelt"....
Mit einem userReading könnte man halt direkt ohne Zwischendevice mächtigere Aktionen erreichen.

Bin unentschieden, was besser ist. Kann, wie gesagt mit beidem leben.

[Cluni]

Ja, wenn du meinst,dass das für Anfänger einfacher ist, dann bin ich natürlich auch mit einem Device einverstanden. Warum auch nicht  - viele Wege führen nach Rom....


Gesendet von iPhone XR mit Tapatalk

[CoolTux]

Auf Klo ist mir aufgefallen das mein Gedanke mit den userReadings kacke ist. Ich muss ja das Event abfangen, und das kann ich nur wenn ich das Device kenne. Also benötige ich auf jeden Fall einen Deviceeintrag welches dem Rollladen zugeordnet ist. Also Fernsehr steht im Rollladen WohnZimmerLi und WohnzimmerRe. Also das muss auf jeden Fall schon mal in ein Attribut. Und dann kann man mit userReadings arbeiten. Somit habe ich auf jeden Fall einen Trigger der dann die Auswertung ALLER? oder EINES? userReadings abarbeitet.

[Cluni]

Ach so - hast ja Recht. Ich denke dann aber direkt aller userReadings, oder spricht da was gegen?

EDIT: Wofür so eine ausgedehnte Sitzung doch manchmal gut ist. Da wird nicht immer nur Scheiße produziert.... 

[CoolTux]

Ach so - hast ja Recht. Ich denke dann aber direkt aller userReadings, oder spricht da was gegen?

EDIT: Wofür so eine ausgedehnte Sitzung doch manchmal gut ist. Da wird nicht immer nur Scheiße produziert.... 

Ja da spricht gegen das ein userReading, hier stünde es ja im Rollladen drin wegen der Zuordnung, nur geschrieben wird wenn ein Event vom Device kommt in welchen das userReading beschrieben ist. Aber wann liefert der Rollladen schon mal ein Event ausser er fährt.

Eine Möglichkeit wäre pro Rolladen ein userDevice zu zu lassen und max. 3 festgelegte userReadings. Triggert das ASC Device Events des userDevices werden die max 3 bekannten userReadings abgefragt und verarbeitet.

[Cluni]

max 3 / max 2?

[CoolTux]

max 3 / max 2?

[hexenmeister]

Ich habe auch zuerst so verstanden, dass es einen UserReading in RolladenDev sein würde, nicht irgendwo anders. Dann müsste dies bei Änderung einen Event generieren und den würden wir ja bekommen. Aber irgendwie finde ich auch diese Vorgehensweise nicht so ganz 'rund'.

Ich würde nur ein Device und eine _Liste_ der Readings erlauben (z.B. leerzeichensepariert). Man bekommt eh alle Events von dem Device und dann würde man einfach das sich geänderte Reading mit einem grep gegen diese Liste prüfen.

[CoolTux]

Ich habe soeben Version 0.2.0.6 ins SVN geladen. Antifreeze wurde erweitert und die Values des Attributes etwas geändert.
Bitte kontrolliert Eure NotifyDEV dann mal. Am besten über den get Befehl. Den sieht man nun nicht mehr wenn man verbose hoch dreht sondern wenn man ASC_expert auf 1 stellt.
Und wenn Ihr Meldungen im Log habt wegen fehlenden Attribut dann ist das ok. Es sollte glaube sogar ein rotes Fragezeichen in FHEMWEB kommen.


Grüße

[netwalk]

Hallo,

ich teste ASC seit kurzem mit einem meiner Rollladen und habe ein Problem mit dem Hochfahren nach Zeit. In der Woche soll der Rollladen um 06:00, am WE und im Urlaub zuhause um 09:00 Uhr hochfahren.
Verstehe ich es richtig, dass sich ASC_Time_Up_WE_Holiday nur auf sunrise bezieht?

Ich habe folgende Einstellungen probiert:
im ASC:

Code Auswählen Erweitern

sunriseTimeWeHoliday on

im Device:

Code Auswählen Erweitern

ASC_Time_Up_Early 06:00
ASC_Time_Up_WE_Holiday 09:00
ASC_Up time

Mit diesen Einstellungen meldet mir ASC_Time_DriveUp 06:00 Uhr des nächsten Tages, obwohl WE ist.

Setze ich im Device

Code Auswählen Erweitern

ASC_Up astro

meldet mir ASC_Time_DriveUp 09:00 Uhr des nächsten Tages.

Wie macht man es richtig?

[CoolTux]

Hallo,

ich teste ASC seit kurzem mit einem meiner Rollladen und habe ein Problem mit dem Hochfahren nach Zeit. In der Woche soll der Rollladen um 06:00, am WE und im Urlaub zuhause um 09:00 Uhr hochfahren.
Verstehe ich es richtig, dass sich ASC_Time_Up_WE_Holiday nur auf sunrise bezieht?

Ich habe folgende Einstellungen probiert:
im ASC:

Code Auswählen Erweitern

sunriseTimeWeHoliday on

im Device:

Code Auswählen Erweitern

ASC_Time_Up_Early 06:00
ASC_Time_Up_WE_Holiday 09:00
ASC_Up time

Mit diesen Einstellungen meldet mir ASC_Time_DriveUp 06:00 Uhr des nächsten Tages, obwohl WE ist.

Setze ich im Device

Code Auswählen Erweitern

ASC_Up astro

meldet mir ASC_Time_DriveUp 09:00 Uhr des nächsten Tages.

Wie macht man es richtig?

Du hast Recht. Bisher bezieht sich das Wochenend fahren nur auf Astro. Werde ich die Tage korrigieren.
Danke für den Bugreport