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

[xerion]

Und welche Version hast Du nun? Ich habe ja diesbezüglich rein gar nichts geändert.

Jetzt nutze ich die Version aus dem FHEM svn -> v0.8.7

[CoolTux]

Ich habe nun mit meiner aktuellen Version getestet. Es hast sich nichts wesentliches seit 0.8.7 geändert.
Ich bekomme leider keine falsche Angabe

[xerion]

Ich habe nun mit meiner aktuellen Version getestet. Es hast sich nichts wesentliches seit 0.8.7 geändert.
Ich bekomme leider keine falsche Angabe

Bei dir steht aber ASTRO du musst mit Brightness und Privacy testen...

[CoolTux]

Sorry ich hatte deine das 1 zu 1 übernommen

[CoolTux]

Dennoch keine Änderung.

[xerion]

Dennoch keine Änderung.

Kannst du bitte noch einen Screenshot vom dem Rollo Device anhängen?

[CoolTux]

Habe die ganze Zeit rumprobiert. Bekomme und verrecken keine falsche Anzeige. Es ist zum aus der Haut fahren.

Vielleicht muss ich so 6-7 davon anlegen.

[xerion]

Komisch....Aber @Kaialfonso hat ja auch von dem Problem berichtet also müssen wir beide was gemeinsam haben?

Ich habe erst drei Rollos eingerichtet die per Brightness fahren und dann das Rollo mit Brightness und Privacy, der Auslöser bei mir ist ja immer das Attribute PrivacyUp(Down)Value

[CoolTux]

Kaialfonso hatte glaube Homematic. Also nicht das Rollo Modul. Ich war am Anfang so zuversichtlich da wir in der Tat so ein Phänomen mal hatten. Also Raumnamen statt Rollonamen. Schuld war das verwenden von FHEM Funktionen innerhalt einer Schleife. Das mache ich aber nicht mehr, schreibe nun die Hashs direkt.

[Deckoffizier]

Hallo,

sorry vielleicht dumme Frage nutze ja auch das Rollo Modul als Zwischenschicht
müsten nicht die Devices den gleichen Namen haben

attr Rollo_KuecheCarport rl_commandDown set Rollo_Kueche_Carport_Schliessen Schliessen
attr Rollo_KuecheCarport rl_commandStop set  Rollo_Kueche_Carport_Oeffnen OFF
attr Rollo_KuecheCarport rl_commandUp set Rollo_Kueche_Carport_Oeffnen Oeffnen

? Rollo_Kueche_Carport_Schliessen

bei mir z.B. so

rl_commandDown
set eg_sz_rollo down
rl_commandStop
set eg_sz_rollo stop
rl_commandUp
set eg_sz_rollo up

Gruß
Hans-Jürgen

[Beetle2003]

Guten Morgen,

hat jemand auch so ein Verhalten bemerkt?

Das Rollo im Schlafzimmmer wird durch den Fensterkontakt ( geöffnetes Fenster ) auf 50% geöffnet.
Das Fenster steht die ganze Nacht auf.

Ich habe es schön mehrmals bemerkt, dass das Rollo morgens geschlossen ist. Habe gedacht, dass meine Frau es geschlossen hat.
Deshalb heute mal in das Log geschaut, da ich um wenige Minuten nach 6 Uhr im Schlafzimmer war und beobachtet habe wie das Rollo geschlossen wurde.
Im Log finde ich folgende Einträge:
2019.12.27 01:16:51.718 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/73_AutoShuttersControl.pm line 4435.
2019.12.27 01:17:44.216 3: CUL_HM set Rollo_Elternschlafzimmer_1OG pct 0

2019.12.27 06:08:10.364 3: CUL_HM set Rollo_Elternschlafzimmer_1OG pct 0
2019.12.27 06:08:17.467 3: CUL_HM set Rollo_Wohnzimmerfenster_EG pct 0

Ich habe weder  das Rolle im SChlafzimmer noch im Wohnzimmer betätigt.

Kann mir jemand sagen, warum meine Rollos ein Eigenleben haben? Habe die Version 0.8.7 im Einsatz.

Danke 

[xerion]

Hallo,

sorry vielleicht dumme Frage nutze ja auch das Rollo Modul als Zwischenschicht
müsten nicht die Devices den gleichen Namen haben

? Rollo_Kueche_Carport_Schliessen

bei mir z.B. so

Gruß
Hans-Jürgen

Hallo eigentlich sind das ja die Namen der Aktoren das dürfte m.E. egal sein. Ich habe ja auch zwei Test Devives die nur Telegramm Nachrichten senden. Man könnte es versuchen aber dann würde ich es nicht verstehen.

Gesendet von meinem JSN-L21 mit Tapatalk

[xerion]

Kaialfonso hatte glaube Homematic. Also nicht das Rollo Modul. Ich war am Anfang so zuversichtlich da wir in der Tat so ein Phänomen mal hatten. Also Raumnamen statt Rollonamen. Schuld war das verwenden von FHEM Funktionen innerhalt einer Schleife. Das mache ich aber nicht mehr, schreibe nun die Hashs direkt.

Heute morgen waren die Raumnamen von alleine da, ohne das ich gestern noch renewalltimer betätigt habe.

Gesendet von meinem JSN-L21 mit Tapatalk

[xerion]

Guten Morgen,

hat jemand auch so ein Verhalten bemerkt?

Das Rollo im Schlafzimmmer wird durch den Fensterkontakt ( geöffnetes Fenster ) auf 50% geöffnet.
Das Fenster steht die ganze Nacht auf.

Ich habe es schön mehrmals bemerkt, dass das Rollo morgens geschlossen ist. Habe gedacht, dass meine Frau es geschlossen hat.
Deshalb heute mal in das Log geschaut, da ich um wenige Minuten nach 6 Uhr im Schlafzimmer war und beobachtet habe wie das Rollo geschlossen wurde.
Im Log finde ich folgende Einträge:
2019.12.27 01:16:51.718 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/73_AutoShuttersControl.pm line 4435.
2019.12.27 01:17:44.216 3: CUL_HM set Rollo_Elternschlafzimmer_1OG pct 0

2019.12.27 06:08:10.364 3: CUL_HM set Rollo_Elternschlafzimmer_1OG pct 0
2019.12.27 06:08:17.467 3: CUL_HM set Rollo_Wohnzimmerfenster_EG pct 0

Ich habe weder  das Rolle im SChlafzimmer noch im Wohnzimmer betätigt.

Kann mir jemand sagen, warum meine Rollos ein Eigenleben haben? Habe die Version 0.8.7 im Einsatz.

Danke

Was steht denn als Fahrgrund  in ?

Code Auswählen Erweitern


ASC_ShuttersLastDrive

Gesendet von meinem JSN-L21 mit Tapatalk

[xerion]

Kaialfonso hatte glaube Homematic. Also nicht das Rollo Modul. Ich war am Anfang so zuversichtlich da wir in der Tat so ein Phänomen mal hatten. Also Raumnamen statt Rollonamen. Schuld war das verwenden von FHEM Funktionen innerhalb einer Schleife. Das mache ich aber nicht mehr, schreibe nun die Hashs direkt.

Moin CoolTux,

ich habe die Ursache bei mir gefunden. Ich habe so wie du gestern ein neues Rollo Device angelegt und komischerweise trat bei mir der Fehler bei diesem Device auch nicht mehr auf. Dann habe ich die Atributen nochmal verglichen und gesehen, dass bei dem neuen Device "event-on-change-reading .*" gesetzt war, da ich das automatisch bei jedem erstellen eines Device setzen lassen
Sobald ich das lösche ist der Fehler reproduzierbar.
Wenn ich "event-on-change-reading .*" in den anderen Device wieder eintrage kann ich die sogar mit "ScanForShutters" wiederherstellen...unglaublich was sowas anrichten kann. 
Was ich nur komisch finde dass du das laut deinem Screenshot auch nicht hattest, aber trotzdem funktionierte es bei dir?