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

[volschin]

Ich finde das gleichmäßig fahren auch komisch, meine waren bis vor 1 Monat auch mit 10 Minuten zufällig gefahren, so war das Haus nicht komplett mit einmal dunkel.

Wie wäre es mit gleichzeitig Licht anschalten?


Gesendet von iPhone mit Tapatalk

[CoolTux]

Ich finde das gleichmäßig fahren auch komisch, meine waren bis vor 1 Monat auch mit 10 Minuten zufällig gefahren, so war das Haus nicht komplett mit einmal dunkel.

Wie gesagt Du bekommst das alte Verhalten wenn Du mindestens OffsetStart auf 1 setzt und dannn Offset auf 60 meinetwegen.

[CoolTux]

ASC_Pos_Reading = pct
Gleich wie bei den anderen.

Ok Jetzt schaust Du im Eventmonitor nach ob genau das Rolllo bei manueller Fahrt ein Event für das Reading pct wirft.
Alternativ kannst Du auch ASC auf verbose 4 stellen und dann das Rolllo manuell fahren.

[Typ1er]

Ich bin dabei den Den OffsetStart Zufällig zu setzen. Möchte die Zeit wenn er fährt auch ablesen können. Das berechne ich mir dann.

Das Bild ist vom iPhone über HomeKit.

[CoolTux]

Wie willst Du die Zeit ablesen wenn er zufällig fährt?
Die offset Zeit wird erst mit absetzen des eigentlichen Fahrbefehles ermittelt.

[Typ1er]

Ich berechne jeden Tag um 3 Uhr Nachts die variablen Offsetwerte und mit dehnen kann ich ja dann rechnen. Ist dann in jedem Rollladen separat.

[Loredo]

Übrigens noch ein Nachtrag zu gestern: Das einzige, was nicht funktioniert hat (neben schon erwähnter Regen/Wind Erkennung), war das klassische Herunterfahren nach Brightness Unterschreitung
Erst zum Ultimo um 21:30 sind die Rollos runtergefahren. Daran haben auch die readingsProxy Devices für jedes einzelne Reading nichts geändert (wie gesagt, kann hier aber auch am speziellen Fall, dass die Readings "state" heißen, liegen).

[CoolTux]

Hast Du denn ein readingsProxy für jedes Reading gemacht?
Dann musst Du nur die alten Zuordnungen löschen. Also wirklich ASC_BrightnessSensor als Attribut löschen und neu anlegen mit den neuen Device und Reading

Code Auswählen Erweitern

attr ROLLO ASC_BrightnessSensor readingsProxyBrightness:state

Jetzt ist es eh verhunst denke ich, Du kannst das also auch jetzt ohne löschen machen also nur ändern und musst dann ein createNewNotifyDev machen.

[Loredo]

Ja, für jedes Reading außer für Temperature, das nutze ich direkt (erschien mir unnötig solange ich für alles andere separate Devices habe).
Zuordnungen in den Attributen habe ich selbstverständlich entsprechend geändert und danach auch das NOTIFYDEV vom ASC Device kontrolliert (es stimmte), zur Sicherheit trotzdem nochmals FHEM neu gestartet (hat ja den selben Effekt wie createNewNotifyDev, was aber wie gesagt unnötig war, weil das NOTIFYDEV Internal schon korrekt war).



Hast du denn vor das zu fixen, so dass man das selbe Device mit unterschiedlichen Readings für die jeweilige Sensorik nutzen kann?

[CoolTux]

Ja, für jedes Reading außer für Temperature, das nutze ich direkt (erschien mir unnötig solange ich für alles andere separate Devices habe).
Zuordnungen in den Attributen habe ich selbstverständlich entsprechend geändert und danach auch das NOTIFYDEV vom ASC Device kontrolliert (es stimmte), zur Sicherheit trotzdem nochmals FHEM neu gestartet (hat ja den selben Effekt wie createNewNotifyDev, was aber wie gesagt unnötig war, weil das NOTIFYDEV Internal schon korrekt war).



Hast du denn vor das zu fixen, so dass man das selbe Device mit unterschiedlichen Readings für die jeweilige Sensorik nutzen kann?

Also vorweg, ein restart hat nicht den selben Effekt wie ein createNotifyDev. Schau mal bitte mittels showNotifyDevsInformation nach wie es bei Dir ausschaut. Alternativ trage die Ausgabe mal hier ein.

Nun zum Thema fixen. Habe mir natürlich Gedanken gemacht ob wenn ja wie man das fixn kann. Leider habe ich keine Lösung gefunden. Ich benötige eine eindeutige Zordnung zum Attribut und Device welches ein Event aus löst. Da kommt für mich nur der Devicename in Frage und der darf auch nur einem Ereignis zugeordnet werden. Also Helligkeit oder Regen oder Wind oder oder.
Ich kann mal schauen ob ich noch was in Richtung Kombiabfrage machen kann. Also wenn DEVICE X und READING Y dann. Mal schauen

[CoolTux]

Ja, für jedes Reading außer für Temperature, das nutze ich direkt (erschien mir unnötig solange ich für alles andere separate Devices habe).
Zuordnungen in den Attributen habe ich selbstverständlich entsprechend geändert und danach auch das NOTIFYDEV vom ASC Device kontrolliert (es stimmte), zur Sicherheit trotzdem nochmals FHEM neu gestartet (hat ja den selben Effekt wie createNewNotifyDev, was aber wie gesagt unnötig war, weil das NOTIFYDEV Internal schon korrekt war).



Hast du denn vor das zu fixen, so dass man das selbe Device mit unterschiedlichen Readings für die jeweilige Sensorik nutzen kann?

Also ich habe mir das mal für readingsProxy an geschaut. Es kommt in der Tat kein state: mit. Daher wird das nicht erkannt. Das ist natürlich ärgerlich.
Auch habe ich getestet ob man nicht doch mehrere Readings aus einem Device verwenden kann. Es geht leider nicht, schon alleine beim anlegen der Struktur zur Wiedererkennung wird das vorherige Reading aus dem selben Device überschrieben.

[Loredo]

Ich habe jetzt mal statt readingsProxy cloneDummy Devices genutzt. Konnte noch keine Besserung damit sehen, das heißt vielleicht: Gerade gab es ein "wind un-protection", was durchaus dafür spricht, dass die Events jetzt zumindest alle einzeln verarbeitet werden statt nach dem Zufallsprinzip. Allerdings macht es keinen Sinn nach Ende des Windschutzes die Markise wieder herauszufahren, denn die Bedingungen dafür sind gar nicht mehr erfüllt (beispielsweise die Helligkeit über 40.000 Lux). Die ganzen Wetterschutz Mechanismen sollten (zumindest bei einer Markise) nur dafür sorgen, dass die Beschattung abgebrochen wird, aber nicht wieder aufgenommen wird und auch nicht eine "letzte Position" angefahren wird, weil eben diese letzte Position gar durch die Beschattung bedingt war und keinesfalls manuell gewählt.

[CoolTux]

Man kann schauen ob Beschattung noch aktiv ist und dann dahin fahren. Ansonsten halt irgendwo anders hin. Aber wohin?
Das Problem ist das man solche Anfragen ins unermessliche treiben kann. Wenn Beschattung nach Wind unprotected aktiv fahre in Beschattung, wenn nicht und es ist in 10 Min Nacht schließe das Rolllo oder mache es ganz auf wenn....

Du siehst man kann es ausarten lassen. Ich habe mich versucht an das zu halten was die User aktiv verwenden. Das war bis dato letzte Position.

[Loredo]

Verstehe ich nicht. Wie kann es denn noch einfacher sein, als dass durch ein Ereignis die Beschattung unterbrochen wird und einfach wieder über den gleichen Mechanismus wie bei beginn er Beschattung erneut getriggert wird? Da muss man nirgendwohin fahren. Das einmalige Ereignis fährt einmal in eine Richtung, danach passiert nix mehr. Die Beschattung wird wieder aktiv, sobald die Voraussetzungen wieder ok sind - that's it (und "no rain" und "no wind" sind ja Teil der Bedingung). Da muss man IMHO nichts ins unermessliche treiben.

[CoolTux]

Verstehe ich nicht. Wie kann es denn noch einfacher sein, als dass durch ein Ereignis die Beschattung unterbrochen wird und einfach wieder über den gleichen Mechanismus wie bei beginn er Beschattung erneut getriggert wird? Da muss man nirgendwohin fahren. Das einmalige Ereignis fährt einmal in eine Richtung, danach passiert nix mehr. Die Beschattung wird wieder aktiv, sobald die Voraussetzungen wieder ok sind - that's it (und "no rain" und "no wind" sind ja Teil der Bedingung). Da muss man IMHO nichts ins unermessliche treiben.

Du beziehst es jetzt ja auf Beschattung. Das gab es vorher ja nicht. Aber davon mal ab, was ist wenn nicht die Beschattungsposition aktiv war sondern eine andere Position, dann wird in Wind Protection gefahren als Beispiel und wenn Wind unprotected kommt wohin soll dann gefahren werden? Gar nicht, so habe ich Dich gerade verstanden, oder in die alte Position?