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

Deckoffizier · 27 Dezember 2019, 14:34:04

Hallo xerion,

vielleicht schon überflüssig aber noch mal laienhaft nach gefragt ...

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.

Im ROLLO Modul berechnest Du doch die Fahrzeiten für EIN Rollo mit z.B. rl_secondsDown 15
bzw. rl_secondsUp 22.

Ergibt sich hier nicht ein Durcheinander wenn Du es auf 2 verschiedene zu steuernde Nachfolge Rollos loslässt ?

Gruß
Hans-Jürgen

xerion · 27 Dezember 2019, 14:36:15

Zitat von: Deckoffizier am 27 Dezember 2019, 14:34:04
Hallo xerion,

vielleicht schon überflüssig aber noch mal laienhaft nach gefragt ...

Code Auswählen Erweitern
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.

Im ROLLO Modul berechnest Du doch die Fahrzeiten für EIN Rollo mit z.B. rl_secondsDown 15
bzw. rl_secondsUp 22.

Ergibt sich hier nicht ein Durcheinander wenn Du es auf 2 verschiedene zu steuernde Nachfolge Rollos loslässt ?

Gruß
Hans-Jürgen

Hallo Hans-Jürgen,

verstehe deine Frage nicht, was meinst du mit zwei verschieden Rollos in einem Rollo-Modul?

Deckoffizier · 27 Dezember 2019, 14:40:41

Hallo xerion,

na einmal set Rollo_Kueche_Carport_Schliessen

und set Rollo_Kueche_Carport_Oeffnen

Gruß
Hans-Jürgen

xerion · 27 Dezember 2019, 14:48:21

Zitat von: Deckoffizier am 27 Dezember 2019, 14:40:41
Hallo xerion,

na einmal set Rollo_Kueche_Carport_Schliessen

und set Rollo_Kueche_Carport_Oeffnen

Gruß
Hans-Jürgen

Ich nutze für meine Rollos Sonoff die mit Tasmota geflasht sind. Diese kommunizieren über MQTT mit FHEM und der Einfachheit halber habe ich ich für jeden Chanel ein Device.
Theoretisch kannst du mit einem ROLLO Device drei Aktoren gleichzeitig schalten darum hat man ja auch für die setbefehle sogar drei "Command-Möglichkeiten"

Beta-User · 27 Dezember 2019, 15:01:53

@xerion:
Es gibt zwischenzeitlich eine offizielle Tasmota-Variante, die direkt "Rollladen" kann (https://github.com/arendst/Tasmota/wiki/Commands#blinds-shutters-and-roller-shades) und auch ein attrTemplate für MQTT2_DEVICE, um das zu konfigurieren. Könntest du dir bei Gelegenheit ansehen, könnte manches vereinfachen, da die Timer-Verwaltung da auf dem ESP8266 erfolgt...

xerion · 27 Dezember 2019, 15:05:34

Zitat von: Beta-User am 27 Dezember 2019, 15:01:53
@xerion:
Es gibt zwischenzeitlich eine offizielle Tasmota-Variante, die direkt "Rollladen" kann (https://github.com/arendst/Tasmota/wiki/Commands#blinds-shutters-and-roller-shades) und auch ein attrTemplate für MQTT2_DEVICE, um das zu konfigurieren. Könntest du dir bei Gelegenheit ansehen, könnte manches vereinfachen, da die Timer-Verwaltung da auf dem ESP8266 erfolgt...

Das hört sich gut an... das werde ich mir mal anschauen. Danke für die Info.

Deckoffizier · 27 Dezember 2019, 16:09:08

Hallo xerion,

bei mir sind es jeweils UNIRoll Rolladen.

Jedes HardwareRollo habe ich einzeln mit dem UNIRoll Modul definiert und dann
mit jeweils zugehörigen einzelnen ROLLO Modul verknüpft bzw. angesteuert.
Ist jetzt vielleicht verständlicher warum ich nachgefragt hatte.

Gruß
Hans-Jürgen

Beetle2003 · 27 Dezember 2019, 22:55:29

Zitat von: xerion am 27 Dezember 2019, 09:10:25
Was steht denn als Fahrgrund in ?
Code Auswählen Erweitern
ASC_ShuttersLastDrive

Ich muss ehrlich gestehen, dass ich daran nicht gedacht habe.
Werde mal schauen wenn es das nächste Mal passiert.

Danke für den Tipp

CoolTux · 28 Dezember 2019, 07:22:41

Zitat von: xerion am 27 Dezember 2019, 14:02:28
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?

Das ist ja sehr interessant. Erklären kann ich es mir nicht. Ich empfehle event-on-change-reading bei den Rollo Devices damit eine alive Methode welche die Readings auch beschreibt nicht ein Event aus löst obwohl nichts passiert ist. ASC würde das dann immer als manuelle Fahrt ansehen.

Beetle2003 · 28 Dezember 2019, 07:56:30

Zitat von: Beetle2003 am 27 Dezember 2019, 22:55:29
Zitat von: xerion am 27 Dezember 2019, 09:10:25
Was steht denn als Fahrgrund in ?
Code Auswählen Erweitern
ASC_ShuttersLastDrive

Ich muss ehrlich gestehen, dass ich daran nicht gedacht habe.
Werde mal schauen wenn es das nächste Mal passiert.

Danke für den Tipp

Guten Morgen,

ich habe gestern noch schnell ein Logfile angelegt. Und siehe da, es ist die Abwesenheitserkennung:

ASC_ShuttersLastDrive: residents absent

Dadurch fährt das Rollo runter.

Ich wollte erreichen, dass die Türen, an denen ein Rollo montiert ist bei Abwesenheit herunter fahren und eines welches in einem unbenutzten Raum ist sich öffnet.

An dem Rollo wollte ich keine Abwesenheitssteuerung.

Neuer Hinweis erwünscht.

Danke

CoolTux · 28 Dezember 2019, 10:02:23

Dann brauchen wir ein list vom Rollo und vom ASC Device

xerion · 28 Dezember 2019, 10:43:16

Zitat von: CoolTux am 28 Dezember 2019, 07:22:41
Das ist ja sehr interessant. Erklären kann ich es mir nicht. Ich empfehle event-on-change-reading bei den Rollo Devices damit eine alive Methode welche die Readings auch beschreibt nicht ein Event aus löst obwohl nichts passiert ist. ASC würde das dann immer als manuelle Fahrt ansehen.

Ich hatte die Mal vor langer Zeit gelöscht da sich beim Neustart immer die Zeiten für hoch runter verstellt hatten.

Gesendet von meinem JSN-L21 mit Tapatalk

xerion · 28 Dezember 2019, 21:08:57

Zitat von: CoolTux am 28 Dezember 2019, 07:22:41
Das ist ja sehr interessant. Erklären kann ich es mir nicht. Ich empfehle event-on-change-reading bei den Rollo Devices damit eine alive Methode welche die Readings auch beschreibt nicht ein Event aus löst obwohl nichts passiert ist. ASC würde das dann immer als manuelle Fahrt ansehen.

Das Problem mit IsDay by Privacy ist leider doch noch vorhanden. Also wenn die Rollos durch Brightness geschlossen wurden, das bleibt es trotzdem "Tag" bei den Rollos mit Privay Atributen. Erst wenn 22:00 Uhr vorbau ist (down late) werden die auf Night gesetzte, scheint doch noch ein bug zu sein?

CoolTux · 28 Dezember 2019, 22:04:01

Das schaue ich mir die nächsten Tage mal an.

CoolTux · 29 Dezember 2019, 20:08:42

Zitat von: xerion am 28 Dezember 2019, 21:08:57
Das Problem mit IsDay by Privacy ist leider doch noch vorhanden. Also wenn die Rollos durch Brightness geschlossen wurden, das bleibt es trotzdem "Tag" bei den Rollos mit Privay Atributen. Erst wenn 22:00 Uhr vorbau ist (down late) werden die auf Night gesetzte, scheint doch noch ein bug zu sein?

Fix gibt es morgen Früh per FHEM Update.
Version 0.8.9