[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.10

[pc1246]

Moin
Ok, das erste habe ich wohl schon selber gefunden. ASC_blockAscDrivesAfterManual sollte dann wohl das Fensterputzproblem beheben!?
Gruss Christoph

[flummy1978]

Moin Christoph,

Ein manual drive interessiert mein ASC leider gar nicht, was beim Fensterputzen extrem hinderlich ist. So schnell wie das Rollo wieder runter will, hat man nicht mal das Tuch im Eimer!

schau mal 2 Beiträge zurück ... da wurde mein Problem dahin gehend bearbeitet und für mich gelöst. Auch hier wurde eine manuelle Fahrt nicht erkannt und es ist (oder besser gesagt erscheint mir) identisch. Es fehlt ein event-on-change ..........

Viele Grüße
Andreas

[pc1246]

Moin Andreas
Danke, aber ich erkenne nicht woran Marko das erkannt hat, und weiss auch nicht wo ich das setzen muss. Im ASC oder am jeweiligen Rollladen!
Gruss Christoph

[CoolTux]

Moin
Ok, das erste habe ich wohl schon selber gefunden. ASC_blockAscDrivesAfterManual sollte dann wohl das Fensterputzproblem beheben!?
Gruss Christoph

Du hast so ein zwei Attribute stehen die gibt es nicht mehr.
Meine Empfehlung, ASC löschen, danach in den Rollos schauen ob wirklich alles von ASC auch aus den Rollos ist und dann alles neu machen.
Ganz wichtig, nur Attribute setzen die Du auch anders wie Default belegen willst. Defaults stehen in der Commandref.



Grüße

[pc1246]

Moin Marko
Danke, das war auch meine Vermutung.
Nur einmal kurz eine Frage, wie ist das mit der Position? Ich habe tahoma devices, da ist dim vorgegeben, aber das reading gibt es gar nicht.
Wie funktioniert das, wo kann ich das nachlesen?
Danke und Gruss
Christoph

Edith:
ClosureState als Posreading hilft. Aber wie kann ich testen, ob er jetzt noch faehrt?

[CoolTux]

Moin Marko
Danke, das war auch meine Vermutung.
Nur einmal kurz eine Frage, wie ist das mit der Position? Ich habe tahoma devices, da ist dim vorgegeben, aber das reading gibt es gar nicht.
Wie funktioniert das, wo kann ich das nachlesen?
Danke und Gruss
Christoph

Edith:
ClosureState als Posreading hilft. Aber wie kann ich testen, ob er jetzt noch faehrt?

Nimm dim und erstelle ein userreadings dim aus einem Reading welches den Positionswert enthält.

[MCh76]

Nimm dim und erstelle ein userreadings dim aus einem Reading welches den Positionswert enthält.

mensch genial, das war der entscheidende hinweis mit dem userReading für mich.
d.h. das erkennen einer manuellen fahrt hängt davon ab dass entsprechend benamte readings gesetzt sein müssen?
in meinen rolläden gibt es standard readings namens pct, manuelle fahrten wurden seit jeher wunderbar erkannt.
an der markise gibt es als standard-reading für die position nur gleichnamig "position" (gleichzeitig auch von mir verwendet für ASC_Pos_Reading). Wenn ich manuell über "set markise position xx" gesteuert habe --> kein wegschreiben des Status einer manuellen fahrt.
nun mit dem setzen eines UserReadings namens pct (auf den Wert von "position") erkennt ASC die manuelle Fahrt...
hab ich wohl nirgends in der doku entdecken können.
grüße,
Chris

[pc1246]

Komisch nur, dass ich der Einzige bin, der dies Problem hat.
Ja, ich weiss, dass die meisten von tahoma zu KLF200 gewechselt sind, mein KLF ist ja auch schon da, aber trotzdem haette ich diese Frage schon oefter erwartet!
Und bei mir erkennt er das immer noch nicht!
Gruss Christoph

Edith:
Da ich jetzt erstmal keine Zeit mehr habe, werde ich mal abwarten wie es morgen frueh aussieht, habe jetzt unterschiedliche Ansaetze auf den 6 Rolllaeden!
Das mit dem Loeschen gefaellt mir am wenigsten, da fummele ich mir ja nen Wolf!

[CoolTux]

Komisch nur, dass ich der Einzige bin, der dies Problem hat.
Ja, ich weiss, dass die meisten von tahoma zu KLF200 gewechselt sind, mein KLF ist ja auch schon da, aber trotzdem haette ich diese Frage schon oefter erwartet!
Und bei mir erkennt er das immer noch nicht!
Gruss Christoph

Edith:
Da ich jetzt erstmal keine Zeit mehr habe, werde ich mal abwarten wie es morgen frueh aussieht, habe jetzt unterschiedliche Ansaetze auf den 6 Rolllaeden!
Das mit dem Loeschen gefaellt mir am wenigsten, da fummele ich mir ja nen Wolf!

Das löschen muss!!! aber sein, sonst wird es nie richtig klappen.

[D3ltorohd]

der CoolTux war weiter vorne so nett und hatte mal geantwortet dass auch ein dummy device geht, welches als werte für STATE rain oder dry annehmen kann.
ich habe dann ein dummy device namens asc_rain_dry erstellt und damit ein notify auf meine wetterstation verknüpft. grund: helligkeit-, wind- und regensensor sind bei mir allesamt von der gleichen wetterstation, was stand heute nicht geht.
das notify sieht wie folgt aus:

Code Auswählen Erweitern


out_hm_ip_wetter:1.RAINING:.* {
my $raining = ReadingsVal("out_hm_ip_wetter","1.RAINING",0);
# $raining = "yes"; #only debug
if ( $raining eq "yes" ) { #it is raining
fhem ("set asc_rain_dry rain");
}
else { #it is not raining
fhem ("set asc_rain_dry dry");
}
}


im asc device dann folgendes attribut für ASC_rainSensor gesetzt:
asc_rain_dry 1:0 0

funktioniert wie gewünscht. vielleicht hilft dir das ja

Danke dir, aber dieses Perl, ich komm einfach nicht drauf klar. Mein UserReading hat wohl schon mal geklappt und ich habe das jetzt im Device stehen mit 0 / 1 So im ASC hab ich jetzt folgendes eingetragen ::

Code Auswählen Erweitern

zigbee.0.00158d00045a3466.detected:Regenstatus 1:0 0

Ich werde das gleich mal testen.

So das müsste jetzt wie laufen, nur wenn das Fenster offen ist, was das Rollo ja durch den Fensterkontakt weiß, fährt er runter ? Wenn der Sensor meldet, kein Regen mehr, fährt er wieder hoch ?

EDIT::

Also das reading im Device ändert sich. Am Rollo passiert nichts. Am Wunschrollo ja nur

Code Auswählen Erweitern

ASC_RainProtection eintragen und fertig ? @CoolTux
Das ist nun mein Eintrag im ASC

Code Auswählen Erweitern

ASC_rainSensor zigbee.0.00158d00045a3466.detected:Regenstatus 1:0 0

[CoolTux]

Danke dir, aber dieses Perl, ich komm einfach nicht drauf klar. Mein UserReading hat wohl schon mal geklappt und ich habe das jetzt im Device stehen mit 0 / 1 So im ASC hab ich jetzt folgendes eingetragen ::

Code Auswählen Erweitern

zigbee.0.00158d00045a3466.detected:Regenstatus 1:0 0

Ich werde das gleich mal testen.

So das müsste jetzt wie laufen, nur wenn das Fenster offen ist, was das Rollo ja durch den Fensterkontakt weiß, fährt er runter ? Wenn der Sensor meldet, kein Regen mehr, fährt er wieder hoch ?

EDIT::

Also das reading im Device ändert sich. Am Rollo passiert nichts. Am Wunschrollo ja nur

Code Auswählen Erweitern

ASC_RainProtection eintragen und fertig ? @CoolTux
Das ist nun mein Eintrag im ASC

Code Auswählen Erweitern

ASC_rainSensor zigbee.0.00158d00045a3466.detected:Regenstatus 1:0 0

Hast Du heute ein Update gemacht? Wenn nicht bitte machen und noch mal testen.

[CoolTux]

mensch genial, das war der entscheidende hinweis mit dem userReading für mich.
d.h. das erkennen einer manuellen fahrt hängt davon ab dass entsprechend benamte readings gesetzt sein müssen?
in meinen rolläden gibt es standard readings namens pct, manuelle fahrten wurden seit jeher wunderbar erkannt.
an der markise gibt es als standard-reading für die position nur gleichnamig "position" (gleichzeitig auch von mir verwendet für ASC_Pos_Reading). Wenn ich manuell über "set markise position xx" gesteuert habe --> kein wegschreiben des Status einer manuellen fahrt.
nun mit dem setzen eines UserReadings namens pct (auf den Wert von "position") erkennt ASC die manuelle Fahrt...
hab ich wohl nirgends in der doku entdecken können.
grüße,
Chris

Es gibt vereinzelt noch einen kleinen Fehler wo das auslesen des Attributs ASC_Pos_Reading nicht korrekt funktioniert und das ein default genommen wird. Dieser ist immer pct. Ich suche da noch.

[pc1246]

Moin
Also alle sind gefahren. Lastdrive und positon sind aber nicht so ganz richtig, manche ja manche nein.
@Marko
Ich habe mir den code zwar nicht angesehen, aber ich vermute mal, dass Du doch intern alle Rollos als Element abbildest!?
Waere es nicht denkbar, dass Du die auch nach aussen zeigst, und einfach die Schnittstelle zum echten Rollo parametrierbar machst.
Ich bin da heute morgen drauf gekommen, da ich mich gewundert habe, dass es eine position gibt, die man nur auf der ASC Seite sehen kann im Element aber nicht.
Das haette auch diverse Vorteile, da Du nicht wissen musst, wie welches Rollo faehrt, oder wo man die Position findet. Und fuer den Anwender waere die Trennung klarer, da man nicht am "echten" Element sucht, wenn mit ASC was nicht funktioniert.
Gruss Christoph

[CoolTux]

Moin
Also alle sind gefahren. Lastdrive und positon sind aber nicht so ganz richtig, manche ja manche nein.
@Marko
Ich habe mir den code zwar nicht angesehen, aber ich vermute mal, dass Du doch intern alle Rollos als Element abbildest!?
Waere es nicht denkbar, dass Du die auch nach aussen zeigst, und einfach die Schnittstelle zum echten Rollo parametrierbar machst.
Ich bin da heute morgen drauf gekommen, da ich mich gewundert habe, dass es eine position gibt, die man nur auf der ASC Seite sehen kann im Element aber nicht.
Das haette auch diverse Vorteile, da Du nicht wissen musst, wie welches Rollo faehrt, oder wo man die Position findet. Und fuer den Anwender waere die Trennung klarer, da man nicht am "echten" Element sucht, wenn mit ASC was nicht funktioniert.
Gruss Christoph

Leider verstehe ich nicht ganz was Du mit Element meinst.
Wird denn der LastDriveStatus nicht korrekt bei Dir gesetzt?

[gestein]

default ist on sobald ein Fensterkontakt definiert ist.

Hallo,

Ich habe nun die Parameter für Ventilate gesetzt. Funktioniert soweit auch.
Eines verwundert mich aber:
Wenn die Beschattung beginnt, fahren die Rollos bei den jeweiligen offenen Türen gar nicht.
Erst wenn man die Tür zu macht, fährt der Rollo runter in die Beschattungsposition.
Öffnet man dann die Tür wieder, fährt der Rollo in die Ventilate_Pos.
Nur am Anfang passiert nix - wenn die Tür offen ist.
Sollte der Rollo dann nicht in die Ventilate_Pos fahren?

Lg, Gerhard