- √ - neue Version 1.2 meines Rolladenbausteins (ID 11721) fertig...

[DaniSane]

Durchgefallen

Hallo Marc,

folgende vorteile bietet dein Baustein gegeüber dem alten:

die Auf / ab Zeit steuerung ist OK

Das direkte vorhandensein der Lüftungs/Mittags/Beschattungspos. war der Hauptgrund für den wechsel auf den neuen Baustein.

Negativ:
Wegfall der An/Abwesen Erkennung und die damit verbunde Steuerung eines Rolladens (z.B.) bei dunkelheit und an/abwesend.

Aus diesem grund wird wohl der Rollo bei dunkeheit auch nicht mehr hochgefahren. (er macht gar nicht mehr, tot)

Öffne/kippe ich nachts ein Fenster macht der Rollanden gar nicht, ich muss ihn von hand verfahren, bisher: Rollo Fähr auf Lüften/Schlitz.

Anliegende Signale müssen (wenn man denn eine Sperre zurücknimmt) neu getriggert werden, was bei Globaen Siganeln wie Dunkel, Beschattung usw. dazu führt das alle rollos in aktion kommen -> ober negativ,
bisher: der baustein fahrt immer die postion an die er nach anliegen Sigalen anfahren soll. (kein Trigger)


Der alte Baustein:
Vorteil: Ausgereifter Baustein der ohne komplizierte sperren das macht was man will und nie beleidigt den Dienst einstellt.

Hat man den Rollo von Hand bewegt ist die Automatik auch gesperrt.

Geht man aus dem haus und drück "alles Aus" und setzt somit abwesen ist der Baustein wieder aktiv und macht den Tagsüber was er soll. Alternativ setze ich Auto über die Visu und der Baustein fahrt ohne Trigger seine soll pos an.

Nachteil:
Lüften, Mittag, Beschattung ist nur mit hin und her kopieren der Hell Pos zu realisieren.

Er übernimmt keine änderungen der Soll pos direkt.

Mit dem alten Baustein muss ich meine Taster eigedlich nie verwenden, mit dem neuen ist wieder manuelles zutun nötig. Das nicht ganz zu durschauende sperren System immer wieder zurückzusetzen ist keine erleichterung, zudem müsste ich danach des zugehöriger ereigniss Neu Triggern (globales Dunkel; beschattung usw... 14 Rollos fahren spazieren.)


Aus diesem Grund ist der Baustein bei mir in der Aktuellen Version:

Durchgefallen bzw keine Weiterentwicklung des alten.

DaniSane

[MarcNaroska]

Hallo DaniSane!

Ich weiß ja nicht, WAS du alles mit diesem Baustein anstellst, bei mir zu Hause funktioniert alles, wie es in der Beschreibung aufgeführt ist (inkl. Lüftungsposition).
Wenn du keine Sperre haben willst, setzt du E7 einfach auf 0 und gut ist.
Wenn du durch einen manuellen Befehl das Rollo fährst und möchtest, dass es beim nächsten Triggern von z.B. Beschattung wieder fährt, musst du Bit 1 bis 3 nutzen, um den Status der jeweilige Funktion durch einen manuellen Befehl zurückzusetzen. Ansonsten muss der Status durch den Trigger erst zurückgesetzt werden und dann erneut gesetzt werden.
Wenn du möchstest, dass bei einem manuellen Befehl diese Funktion bis zum Ende des Tages nicht mehr ausgeführt wird, musst du Bit 4 bis 6 nutzen.
Wenn man jetzt mit den Sperren "herumdaddelt" ohne genau zu wissen, wie das Ganze funktioniert, muss man sich auch nicht wundern, dass z.B. die Lüftungsfunktion nicht mehr funktioniert weil sie evtl. gesperrt ist...

Ich weiß ja nicht was bei dir "der alte" und "der neue" Baustein sind, aber es gab (zumindest bei meinen Bausteinen) NIE eine An-/Abwesenheitsfunktion.

Im übrigen führt ein erneutes Triggern nur bei den Bausteinen zu einer Aktion, bei denen der Status NICHT gesetzt war (wie dann bei denen, bei denen die Sperre zurückgenommen wurde).

Ob du jetzt den "neue" oder den "alten" Baustein nutzen willst, musst du selber wissen. Wie schon gesagt, die Sperren sind standardmäßig NICHT aktiv (E7=0). Von daher verstehe ich dein Problem mit den "komplizierten" Sperre nicht so ganz.

Ich habe übrigens bei mir dafür gesorgt, dass "Trigger" niemals doppelt geschickt werden, d.h. wenn Beschattung = 1 gesetzt wurde, wird danach keine 1 wieder geschickt, solange Beschattung aktiv ist...

Ach ja, wieso sollte ein Rollo bei Dunkelheit hochfahren?

Ich kann dir jetzt nur noch anbieten, dass du mir mal dein Projekt schickst und ich schaue, wie du den Baustein angebunden hast...

[goeran]

Hallo Marc,

ich habe in der letzten Nacht nun die ganzen Aktoren umadressiert und die komplette Bedienung ueber Deine Bausteine realisiert. Das funktioniert alles auch sehr gut. Prima Sache, das. Danke fuer Deine Programmierarbeit!

Zwei oder drei Fragen zu der Sperre habe ich noch.

1. Muessen die Ausgaenge 10 und 12 des 11721 parallel mit dem Eingang 6 des 11722 verbunden werden, wenn man moechte, dass die Rollade nach Beenedigung der Sperrsituation ihre vorherige Position wieder anfaehrt? Oder speichert der Baustein das intern und es wuerde A10 auf E6 reichen? (Ist ja fast wie beim Schach hier )

2. Kann es sein, dass nach Beendigung der Sperrsituation eine gewisse Zeit verstreichen muss, bevor wieder manuelle Befehle ueber E22 und E23 angenommen werden? Wenn ja, kann man dieser Zeit beeinflussen?

Meine Markiese wuerde ich bei Regen oder Wind ueber 7m/s gern sofort automatisch einfahren und dann eingefahren lassen. Man soll sie erst wieder manuell ausfahren koennen, wenn obige Bedingung fuer eine Stunde nicht mehr vorlag.

Dafuer wuerde ich mich ueber einen Tipp freuen (vielleicht mit Grafik?), wie ich es verhindere, dass so Zustaende wie "warm/sonnig" oder "nass/windig" flattern. Ich habe das mit zwei Watchdogs und einem RS-FlipFlop versucht (siehe meine Grafik), bin damit aber nicht so sehr zufrieden, weil ich den Eindruck habe, dass das nicht so ganz zuverlaessig funktioniert oder taeusche ich mich da?

Ich habe schon was von "Schwellwert mit Hysterese" gelesen, kann dem aber nicht wirklich folgen. Deswegen meine Frage nach einer Grafik. Sowas hilft immer den "Groschen fallen zu lassen".

[HaraldP]

Hallo zusammen,

ich verwende auch den Baustein von Marc, wollte aber die Gruppenadressen weiterhin direkt an die Aktoren senden. Das geht auch ohne Probleme, wenn man folgende 2 Zeilen in der Logik auskommentiert:

### neue Position berechnen wenn Kurzzeit oder Langzeit in andere Richtung oder neue Position oder Positionierung beendet
### 5012|0|"(OC[4]==0) and (OC[5]==0) and (SN[6]!=-1) and ((EC[1] and (EN[1]!=SN[8])) or EC[2] or EC[6] or OC[3])"|"EN[2]"|""|3|0|0|0 # Kurzzeit weiterleiten

### Verhalten bei Langzeitbefehl
### 5012|0|"(OC[4]==0) and (OC[5]==0) and EC[1]"|"EN[1]"|""|2|0|0|0 # Langzeit weiterleiten

Wäre zwar eleganter, das Weiterleiten über ein Flag zu steuern, aber auskommentieren ging schneller. :-)

Gruß,
Harald

[goeran]

Hallo,

ich verwende auch den Baustein von Marc, wollte aber die Gruppenadressen weiterhin direkt an die Aktoren senden. Das geht auch ohne Probleme, wenn man folgende 2 Zeilen in der Logik auskommentiert:

Hhmmm...., das klingt interessant. Hat das irgendwelche anderweitigen Nebeneffekte?

Dann hast Du auf den Aktoren auch nur eine GA, richtig? Nicht wie DaniSahne zwei?

[goeran]

Hallo Marc,

ich haette evtl. noch einen Erweiterungsvorschlag fuer Deinen Baustein "Rolladensteuerung 11721".

Im letzten Winter hatte ich zweimal ziemliches Pech mit zugefrorenen Rollaeden. Wer schon mal versucht hat, vereiste geschlossenen Rollaeden hoch zu fahren, weiss vielleicht wovon ich spreche. Das Ding hat sich komplett verwickelt und den Kasten und die seitlichen Fuehrungsschienen beschaedigt. Die Lamellen waren in der Fuehrung festgefroren oder einfach ganz zusammengefroren und konnten so beim Hochfahren nicht auseinandergezogen werden. Dann entstehen beim Aufwickeln eine wesentlich groessere Rolle und ganz unangenehme Geraeusche....

Wie liesse sich denn eine Frostsicherung nach den Bedingungen "wenn es in den letzten drei Stunden geregnet/geschneit hat, die Rollade geschlossen ist und die Temperatur unter zwei Grad gefallen ist" oder "wenn es friert und es zu regnen/scheien beginnt und die Rollade geschlossen ist" realisieren?

Damit meine ich nicht nur die Automatikfunktionen, sondern auch die eventuellen manuellen Fahrbefehle.

Natuerlich sollten die Rollaeden jedoch bei "trockenem" Frost fahren koennen.

Liesse sich das in den Baustein integrieren oder sollte/kann man das mit zusaetzlicher Logik machen? Wenn ich an E1 eine Sperre bzw. Sicherungslogik andocke, dann verhindere ich ja nur die automatischen Fahrbefehle, nicht die manuellen.

Hat jemand eine elegante Idee?

[HaraldP]

Hallo,

Hallo,

Hhmmm...., das klingt interessant. Hat das irgendwelche anderweitigen Nebeneffekte?

Dann hast Du auf den Aktoren auch nur eine GA, richtig? Nicht wie DaniSahne zwei?

Nebeneffekte sind mir keine bekannt. Auf dem Aktor habe ich zwei Gruppenadressen. Eine direkt von Taster, die andere von Marc's Baustein aus dem HS. Wenn der Taster aber einen Langzeit- oder Kurzzeitbefehl sendet, wird dieser direkt an den Aktor gesendet und der HS hört quasi nur mit und aktualisiert damit Daten wie z.B. für die aktuelle Position. Vorteil dabei ist, dass die Bedienung über die Taster auch ohne HS unverändert funktioniert.

Gruß,
Harald

[MarcNaroska]

Hallo Goeran!

Um ALLE Bewegungen zu sperren, kannst du E31 und E32 im Baustein 11721 benutzen. Wenn E31=1 oder E31=2, dann werden keine Befehle mehr gesendet.
Die Sperre müsstest du dann über eine Logik entsprechend ein- bzw. ausschalten.

A10 von 11721 muss mit E6 von 11722 vebunden werden. A12 ist nur eine Statusrückmeldung...
Sobald die Sperre wieder aufgehoben ist, sollten manuelle Befehle wieder funktionieren. Es gibt keine Verzögerung bei Aufhebung der Sperre.

Für die Bestimmung des Status hell/dunkel habe ich mir einen kleinen Baustein gebastelt, der sicherstellt, dass nur was gesendet wird, wenn der Status sich ändert. Außerdem sorge ich in diesem Baustein dafür, dass die Beschattung erst 5 Sekunden nach hell freigegeben wird bzw. dass 5 Sekunden vor dunkel die Beschattung beendet wird und dass ein Statuswechsel erst dann gesendet wird, wenn der Status eine gewisse Zeit anliegt:

5000|"Naroska\dunkel&Beschattung (V1.0)"|0|5|"akt. Helligkeit"|"Hell morgens hoch"|"Hell abends runter"|"Verzögerung (sek)"|"Freigabe"|2|"dunkel"|"Freigabe Beschattung"
5001|5|2|2|1|15002|1|0|0
5002|2|100|0
5002|3|15|0
5002|4|60|0
5002|5|0|0
5003|1|0|0
5004|1|0|0|2|0
5004|2|0|0|2|0
5012|1|"EI or (EN[5]==0)"|""|""|0|0|0|0
5012|1|"OC[1] and (AN[1]!=ON[1])"|"ON[1]"|""|1|0|0|0
5012|1|"OC[2] and (AN[2]!=ON[2])"|"ON[2]"|""|2|0|0|0
5012|1|"OC[1] or OC[2]"|""|""|0|0|0|0
5012|0|""|"EN[4]"|""|0|0|1|0
5012|0|"SN[1]<1"|"1"|""|0|0|1|0
5012|0|"EN[1]>=EN[2]"|"0"|"int(SN[1])"|0|1|0|0
5012|1|"EN[1]>=EN[2]"|"1"|"int(SN[1])+5"|0|2|0|0
5012|0|"EN[1]<=EN[3]"|"0"|"int(SN[1])"|0|2|0|0
5012|1|"EN[1]<=EN[3]"|"1"|"int(SN[1])+5"|0|1|0|0

[MarcNaroska]

Hallo HaraldP!

Das mit dem Flag kann ich ja mal auf die "Wunschliste" setzen.
Das Problem mit dem parallel Ansteuern (direkt und über 11721) liegt ja nur darin, dass die Genauigkeit der Positionierung darunter leidet, da direkte Befehle schneller aufgeführt werden als über den HS...

[HaraldP]

Hallo,

Auf dem Aktor habe ich zwei Gruppenadressen. Eine

Da muss ich korrigieren. Ich habe sowohl Aktoren mit 2 Gruppenadressen, als auch solche mit einer. Beide funktionieren identisch.

@Marc
Genauigkeitsprobleme habe ich bisher nicht bemerkt, aber das ist sicher ein Argument. Ein Parameter für Weiterleiten Ja/Nein wäre sicher das beste, vor allem in Hinblick auf neue Versionen.

Gruß,
Harald

[HartmutB]

Hallo HaraldP!

Das mit dem Flag kann ich ja mal auf die "Wunschliste" setzen.

Mallo Marc,

ich würde auch sehr gerne Deinen 11722 statt des Originalbausteins einsetzen und das dann weiter mit dem 11721 "verfeinern".

Tatsächlich war für mich bisher die fehlende direkte Ansteuerung das K.O.-Kriterium, egal wie andere zu dem Thema stehen.

Umso mehr war ich über den Beitrag von Harald erfreut. Auch ich würde mich also sehr über eine entsprechendes "Flag" freuen, da ein manuelles Ändern des Bausteins m.E. keine dauerhaft gute Lösung wäre. Du hättest dann (wenigstens) einen glücklichen Anwender mehr ...


Gruß
Hartmut

[HartmutB]

Ach ja,
noch was für die Wunschliste (obwohl ich die Bausteine noch gar nicht nutze ):

Wie wäre es mit einer "Linearisierung" der Rolloposition beim 11722 ?

10% Weg "oben" sind ja ganz was anderes als 10% Weg "unten", da sich der Durchmesser des Rollopakets mit dem Abspulen verringert. Ich weiß nicht, wie man das programmtechnisch oder mathematisch am besten machen kann, aber es muß ja nicht absolut exakt sein. Es sollte sowas wie einen Parameter 0.0 .. 1.0 geben (mit Standard 0 oder 1), über den man (sowohl eingangs- als auch ausgangsseitig) die Prozentangaben "verzerrt". Bei unverändertem Standard sollte dann das Verhalten wie bisher sein (aus Kompatibilitätsgründen).


Danke und Gruß
Hartmut

[goeran]

Hallo,

10&#37; Weg "oben" sind ja ganz was anderes als 10% Weg "unten", da sich der Durchmesser des Rollopakets mit dem Abspulen verringert. Ich weiß nicht, wie man das programmtechnisch oder mathematisch am besten machen kann,

Oho! Jetzt wird's knifflig....

Das wird insbesondere ein Problem, weil die Rollaeden ja nicht alle gleich grosse Lamellen haben und deswegen die Rolle mit kleineren Lamellen weniger stark an Durchmesser zunimmt, als eine mit grossen Lamellen.

[MarcNaroska]

Hallo Hartmut!

Wie schon gesagt, das mit dem Flag zum ein/ausschalten der Weiterleitung von Kurzzeit/Langzeitbefehlen ist in der nächsten Version dabei.
Über die "Linearisierung" muss ich noch mal nachdenken. Dabei gibt es ja auch noch das Problem, dass die meisten Motoren noch eine gewisse Zeit "nachlaufen" beim herunterfahren. Diese Zeit müsste man auch noch berücksichtigen, um die "linearen" Positionen anfahren zu können.
Mal sehen, was mir dazu einfällt...

[HartmutB]

@HaraldP:

Hallo Harald,
ich möchte das Thema nochmals aufgreifen, da es bei mir leider (noch !) nicht funktioniert:

ich verwende auch den Baustein von Marc, wollte aber die Gruppenadressen weiterhin direkt an die Aktoren senden. Das geht auch ohne Probleme, wenn man folgende 2 Zeilen in der Logik auskommentiert:
...

OK, die Änderungen habe ich gemacht und sie sind auch wirksam im Sinne von "es hat sich was geändert".

Auf dem Aktor habe ich zwei Gruppenadressen. Eine direkt von Taster, die andere von Marc's Baustein aus dem HS.

Nach der obigen Aussage hast Du doppelte GAs eingesetzt (was man beim Originalbaustein von Holger Schwinghammer nicht braucht).

Da muss ich korrigieren. Ich habe sowohl Aktoren mit 2 Gruppenadressen, als auch solche mit einer. Beide funktionieren identisch.

Hhhm. Reicht jetzt doch eine Gruppenadresse (und man muss nach Deinem "Patch" keine weiteren GAs auf die Aktoren legen ?

Bei mir habe ich folgenden Effekt: Ohne Änderung am Baustein und mit einer GA die bekannten Loops und den Rest kennt man. Steht ja oben in diversen Beiträgen. Mit der Änderung (und immer noch einer GA) klappt alles beim manuellen Fahren und die Position wird zurückgemeldet, fahre ich aber eine Position an über "SetPos %", dann kommt kein "Stop" mehr, die Positionsanzeige bleibt auf dem Wunschwert, aber der Rollo läuft auf oberes oder unteres Ende.
Mache ich was falsch, oder brauch es doch immer doppelte Adressen ? Und wenn ja, warum muss man dann noch patchen, dann sollte es auch so gehen, oder ...

Irgendwo habe ich auch einen Gedanken-Loop, denke ich mal ...

Gruß
Hartmut