[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

ch.eick · 19 Juli 2019, 09:42:44

Zitat von: Beta-User am 19 Juli 2019, 09:28:08
Was die readingsGroups angeht: Die aktuellen Versionen im Wiki sind (hoffentlich) alle so gestrickt, dass auch leere Elemente an der richtigen Stelle angezeigt bzw. eingestellt werden können.

Wer ältere, angepaßte eigene verwendet, muß schlicht in der DEF vor den ganzen "?" jeweils ein "!" eingefügen. Also in der rg für die Zeiten z.B. statt "?ASC_Up" dann "!?ASC_Up" verwenden usw..

Hallo Beta-User,

vielen Dank für die schnelle hilfe, ich war aber schneller

. Mir war nicht bewust, dass ich alte RGs verwende, da ich damit erst vor ca 3 Wochen begonnen hatte.

Viele Grüße
Christian

Beta-User · 19 Juli 2019, 09:50:13

Zitat von: ch.eick am 19 Juli 2019, 09:42:44
Hallo Beta-User,

vielen Dank für die schnelle hilfe, ich war aber schneller . Mir war nicht bewust, dass ich alte RGs verwende, da ich damit erst vor ca 3 Wochen begonnen hatte.

Viele Grüße
Christian

... das hatte ich nicht mehr gesehen...
Und du hast recht, nicht alle Definitionen im Wiki sind schon auf dem letzten Stand. (Das wollte ich bei Gelegenheit mal anpassen und ggf. auch noch etwas weiter generalisiertere Versionen einfügen.... kann nur nicht alles selbst testen, das macht es etwas "tricky")

ch.eick · 19 Juli 2019, 10:17:51

Hallo nochmal,

ich habe da mal Problem gemacht

Ich wollte eine Zeiteinstellung für ASC_UP herausnehmen und den von mir gesuchten "null" Wert setzen. Das bedeutet ich wollte den Zeiteintrag auf nichts setzen, damit er nicht mehr in der RG angezeigt wird. Mein Rollo fährt zeitgestreuert um 9:00 Uhr hoch, weshalb ich ASC_UP_Early/Late auf 09:00 gesetzt habe.

Nun habe ich dann folgendes gemacht. Im commands attribut habe ich vor die früheste Zeit ein "," eingetragen. Hierdurch erscheit im pulldown als oberster Eintrag ein leeres Feld. Klickt man das nun an, so geht fhem mit dem modul ASC in einen Loop!

Achtung nicht eintragen, da es einen Fehler provoziert!
ASC_Time_Up_Early:,05:00,05:05,....

Code Auswählen


ASC_Time_Up_Early => 'ASC_Time_Up_Early:,05:00,05:05,05:30,05:55,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45
,10:00',  \

Und hier das passende Log dazu:

Code Auswählen


2019.07.19 09:27:54 1: RMDIR: ./restoreDir/save/2019-07-16
2019.07.19 09:27:54 4: AutoShuttersControl (ASC) - Devname: global Name: ASC Notify: [
  'SAVE'
]

2019.07.19 09:28:59 4: AutoShuttersControl (ASC) - Devname: global Name: ASC Notify: [
  'ATTR rg_ASC_Rolllaeden_Times commands {position => \'position:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100\', 
 ASC_Up => \'ASC_Up:time,astro,brightness\',
 ASC_Down => \'ASC_Down:time,astro,brightness\',
 ASC_Time_Down_Early => \'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00\', 
 ASC_Time_Down_Late  => \'ASC_Time_Down_Late:19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30\', 
 ASC_Time_Up_WE_Holiday => \'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00\',
 ASC_Time_Up_Early => \'ASC_Time_Up_Early:,05:00,05:05,05:30,05:55,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00\',  
 ASC_Time_Up_Late => \'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00\', 
 ASC_Mode_Down => \'ASC_Mode_Down:always,absent,off\', 
 ASC_Mode_Up => \'ASC_Mode_Up:always,absent,off\' }'
]

2019.07.19 09:29:18 4: AutoShuttersControl (ASC) - Devname: global Name: ASC Notify: [
  'ATTR SC_W_Rollo_FSB61 ASC_Time_Up_Early 1'
]

2019.07.19 09:29:18 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/73_AutoShuttersControl.pm line 2414.
2019.07.19 09:29:18 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: [
  'SC_W_Rollo_FSB61_nextAstroTimeEvent:  1.01.1970 - 01:00'
]

2019.07.19 09:29:18 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: [
  'state: created new drive timer'
]

2019.07.19 09:29:18 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: [
  'SC_W_Rollo_FSB61_lastPosValue: 100'
]

2019.07.19 09:29:18 4: AutoShuttersControl (ASC) - ShuttersCommandSet setDriveCmd wird aufgerufen
2019.07.19 09:29:19 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: [
  'state: created new drive timer'
]

2019.07.19 09:29:19 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: [
  'SC_W_Rollo_FSB61_lastPosValue: 100'
]

2019.07.19 09:29:19 4: AutoShuttersControl (ASC) - ShuttersCommandSet setDriveCmd wird aufgerufen
2019.07.19 09:29:19 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: [
  'state: created new drive timer'
]

....

Gruß
Christian

ch.eick · 19 Juli 2019, 10:23:32

Ich nochmal....

Ein workaroud ist natürlich das Attribut im Device zu löschen, dann wird es als nicht gesetzt in der RG angezeigt.
Durch erneutes setzen einer Zeit im pulldown Menü wird das Reading dann natürlich wieder erzeugt.

Dies geht, denke ich alles in die Richtung von "null" Werten in den Zeit Attributen, die jedoch im Modul abgefangen werden müssten.

Viele Grüße
Christian

Beta-User · 19 Juli 2019, 10:38:19

Na ja, die Idee damals mit den ReadingsGroups iVm. ASC war, dem Anwender deren sinnvolle Befüllung zentral zu ermöglichen und die Einrichtung zu erleichtern. Attributwerte zu löschen, stand nicht auf dem Plan (und ist afaik auch kein allg. feature von ReadingsGroup an sich)...

Generell vielleicht noch:
- natürlich kann man ggf. mit Hilfsmitteln irgendwas verbiegen, aber das ist m.E. nicht Aufgabe des Moduls, sowas auch noch abzufangen.
- Die ReadingsGroups finde ich zwischenzeitlich am "besten", wenn man dafür widgets verwendet, was auch für Zeiten möglich ist (time). Zumindest ein paar Beispiele finden sich zwischenzeitlich auch im Wiki. Dann ist man auch flexibler, was Zwischenwerte usw. angeht (selectnumbers).

ch.eick · 19 Juli 2019, 10:55:16

Zitat von: Beta-User am 19 Juli 2019, 10:38:19
Na ja, die Idee damals mit den ReadingsGroups iVm. ASC war, dem Anwender deren sinnvolle Befüllung zentral zu ermöglichen und die Einrichtung zu erleichtern. Attributwerte zu löschen, stand nicht auf dem Plan (und ist afaik auch kein allg. feature von ReadingsGroup an sich)...

Generell vielleicht noch:
- natürlich kann man ggf. mit Hilfsmitteln irgendwas verbiegen, aber das ist m.E. nicht Aufgabe des Moduls, sowas auch noch abzufangen.
- Die ReadingsGroups finde ich zwischenzeitlich am "besten", wenn man dafür widgets verwendet, was auch für Zeiten möglich ist (time). Zumindest ein paar Beispiele finden sich zwischenzeitlich auch im Wiki. Dann ist man auch flexibler, was Zwischenwerte usw. angeht (selectnumbers).

Okay, attribute zu löschen gehört ja wirklich nicht in eine readingsGroup.
Den Gedanken aus der readingsGroup einen neutralen "null" Wert zu setzen fände ich dann doch schon charmant.
Im Modul die Fehlertoleranz zu erhöhen und Fehleingaben des Anwenders abzufangen wäre eine tolle Erweiterung.
Man könnte prüfen, ob der Wert zb. eine Zeit ist und ansonsten den wert einfach verwerfen.
Im Fall von Timern wäre die Krönung einen bestehen Timer dann auch noch zu löschen.

Beispiel:

ASC_Time_Up_Early steht auf 09:00
Ein Timer ist gesetzt
Der Anwender macht den Fehler "attr <Device> ASC_Time_UP_Early gfjgjjsd"
Das Modul erkennt " gfjgjjsd" ist keine Uhrzeit
Der Wert wird nicht verwendet, oder auf "null" gesetzt
Ein bisheriger Timer ASC_Time_Up_Early wird gelöscht

Dies hätte mehrere Vorteile:
1. Tolerant gegen Fehleingaben
2. Kein loop im ASC Modul durch den Fehler des Anwenders
3. Der Anwender kann einen Timer herausnehmen ohne das Attribut zu löschen

Viele Grüße
Christian

ch.eick · 19 Juli 2019, 11:04:13

Wer viel testet, der schreibt auch viel. Sorry, ich möchte niemanden langweilen.

Wenn man nur

ASC_Time_Up_Late setzt und ASC_Time_Up_Early gelöscht ist, dann geht das Modul von "ASC_Time_DriveUp 20.07.2019 - 09:00" auf die astro Zeit.

Setzt man nur ASC_Time_Up_Early und löscht ASC_Time_Up_Late, dann wird die Zeitsteuerung verwendet.

ASC_Up time
ASC_Down astro

Gruß
Christian

pcjogi · 19 Juli 2019, 22:08:15

Habe ich einen Fehler gefunden, oder kann das nicht funktionieren?

Folgende Situation: Der Rollladen fährt bei Beschattung und offener Terrassentür und aktiviertem ASC_LockOut nicht herunter. Soweit gut. Aber wenn es zum night close kommt fährt der Rolladen trotz aktiviertem ASC_LockOut herunter und sperrt uns aus. Ist das ein Bug oder ein Feature? Heute war nur meine Frau draußen und ich konnte ihr das nicht als Feature verkaufen

Wenn es bei aktiviertem ASC_LockOut und offener Tür der Rolladen oben bleiben sollte liefere ich gerne die notwendigen Infos nach und teste.

Viele Dank

Borkk · 20 Juli 2019, 00:35:27

Hallo CoolTux,

Zitatso ich habe jetzt wieder die 0.6.19 drin und alles klappt, puh... sorry das ich dir nicht mehr Futter zum troubleshooten liefern kann. Da ich ASC aber auf meinem Hauptsystem laufen lasse, musste ich jetzt erst mal zurück gehen. Mein FHEM ist in meinem Haushalt mittlerweile schon sehr "mächtig". Aber das kenn ja die meisten hier
Danke für den schnellen Rat.
Ich konnte noch beobachten, das FHEM abgestürzt ist, wenn ich den Status eines Roommates geändert habe, der in ASC eingetragen ist. Konkret nach setzen eine neuen Location, bumm!

ich muss das Thema nochmal ansprechen. Ich habe heute über FHEM auf 0.6.21 upgedatet und leider chrasht mein FHEM wieder wenn sich der Status eines in ASC verwendeten Roommates ändert.

Die letzte Meldung im Log vor dem Neustart ist:

Code Auswählen

Can't use string ("0") as a SCALAR ref while "strict refs" in use at ./FHEM/73_AutoShuttersControl.pm line 1242.

Ich bin jetzt wieder auf 0.6.19 zurück, die läuft einwandfrei. Was kann ich tun?

Beetle2003 · 20 Juli 2019, 08:11:36

Hallo zusammen,

ich benötige Eure Hilfe.

Folgenden Sachverhalt:
Das Rollo wird vor der nächtlichen Schliessung in eine Position gefahren und soll dann nicht durch das ASC Modul verändert werden.
Ich habe ASC_BlockingTime_afterManual auf 3600 gesetzt. Hat nicht funktioniert. Das Rollo führt trotzdem den Befehl zum schliessen aus obwohl dieser nur ca 10 Minuten später kommt.
Weiter sollen die Rollos morgens, sofern die Nachtposition verändert wurde in der manuellen Position verbleiben. WIe stelle ich das ein?

Danke

kjmEjfu · 20 Juli 2019, 08:51:58

Zitat von: pcjogi am 19 Juli 2019, 22:08:15
Folgende Situation: Der Rollladen fährt bei Beschattung und offener Terrassentür und aktiviertem ASC_LockOut nicht herunter. Soweit gut. Aber wenn es zum night close kommt fährt der Rolladen trotz aktiviertem ASC_LockOut herunter und sperrt uns aus. Ist das ein Bug oder ein Feature? Heute war nur meine Frau draußen und ich konnte ihr das nicht als Feature verkaufen

Wenn es bei aktiviertem ASC_LockOut und offener Tür der Rolladen oben bleiben sollte liefere ich gerne die notwendigen Infos nach und teste.

der Bug war früher mal drin. Mittlerweile (aktuelle ASC-Version) ist dieser Fehler zum Glück wieder verschwunden, zumindest bei mir.
Also vermutlich irgendwas bei dir falsch eingestellt.

ASC_ShuttersPlace auf terrace gesetzt?
Sonst halt das übliche ... list vom Rollo und ASC_Device

pcjogi · 20 Juli 2019, 09:32:52

ASC_ShuttersPlace auf terrace gesetzt? ja. führt das zu dem Verhalten?

Danke

CoolTux · 20 Juli 2019, 15:09:42

Zitat von: Dersch am 18 Juli 2019, 07:45:04
Hi,

ich habe nun auf threestate umgerüstet. Das Verhalten bleibt bei einem gekippten Fenster aber gleich. Er fährt nicht Helligkeitsgesteuert hoch und nur wenn das Fenster nach ASC_Time_Up_Late kurz geschlossen wird.

Grüße
Dirk

Hallo,

Ich habe nun einmal geschaut. Du hast im ASC Device SelfDefense auf on, dadurch wird in der Tat beim Brightnessevent nicht gefahren wenn das Fenster nicht geschlossen ist.
Ich habe es nun etwas erweitert in der kommenden Version. Nun wird geschaut ob Residents auf home steht und dann wird doch gefahren.

Grüße

CoolTux · 20 Juli 2019, 15:27:03

Zitat von: pcjogi am 19 Juli 2019, 22:08:15
Habe ich einen Fehler gefunden, oder kann das nicht funktionieren?

Folgende Situation: Der Rollladen fährt bei Beschattung und offener Terrassentür und aktiviertem ASC_LockOut nicht herunter. Soweit gut. Aber wenn es zum night close kommt fährt der Rolladen trotz aktiviertem ASC_LockOut herunter und sperrt uns aus. Ist das ein Bug oder ein Feature? Heute war nur meine Frau draußen und ich konnte ihr das nicht als Feature verkaufen

Wenn es bei aktiviertem ASC_LockOut und offener Tür der Rolladen oben bleiben sollte liefere ich gerne die notwendigen Infos nach und teste.

Viele Dank

Das Verhalten sollte eigentlich identisch sein, sowohl bei Shading als auch bei Nachtfahrt. Bitte ein list vom ASC und vom Rollo an der Terrassentür.

CoolTux · 20 Juli 2019, 15:35:22

Zitat von: Borkk am 20 Juli 2019, 00:35:27
Hallo CoolTux,

ich muss das Thema nochmal ansprechen. Ich habe heute über FHEM auf 0.6.21 upgedatet und leider chrasht mein FHEM wieder wenn sich der Status eines in ASC verwendeten Roommates ändert.

Die letzte Meldung im Log vor dem Neustart ist:

Code Auswählen Erweitern
Can't use string ("0") as a SCALAR ref while "strict refs" in use at ./FHEM/73_AutoShuttersControl.pm line 1242.

Ich bin jetzt wieder auf 0.6.19 zurück, die läuft einwandfrei. Was kann ich tun?

Ich habe einen Fehler gefunden. Ob es Dein Problem behebt kann ich nicht sagen, da komischer Weise bei mir alles damit geht. Ich fixe es aber jetzt mal für die neue Version.