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

[HartmutB]

Ich will hier nicht langweilen, aber ich habe mein Problem weitgehend eingrenzen können:

Wenn man - nachdem der Eingang "Nacht" auf "an" getriggert wurde - am HS arbeitet und ihn wegen irgendwelcher Änderungen neu startet, dann vergißt der Baustein den Zustand "Nacht" und das oben beschriebene Verhalten tritt auf.

Gestern abend habe ich nichts am HS geändert und heute früh war alles normal, deshalb kam ich auf den obigen Gedanken und habe es auch verifizieren können.

Könnte man den Zustand "Nacht" nicht remanent im Baustein speichern, damit dieser bei einem HS-Neustart nicht "aus der Spur" kommt ?

Alternativ wäre der momentane Workaround das zyklische oder zumindest nach dem HS-Neustart einmalige Senden des "Nacht"-Zustands an den Baustein. Eine Integration in den Baustein wäre aber halt deutlich eleganter.

Gruß
Hartmut

[HartmutB]

@MarcNaroska:

Hallo Marc,
hier nochmals eine "Überprüfungsanfrage":

Ich betreibe den 11721 (V1.6) nicht mit allen Automatikfunktionen, ich baue sowas gerne Zug um Zug ein. Was ich aber nutze, ist die Lüftungsfunktion mit "Trigger Lüftung" an den Fensterkontakten.

Dazu ist "dunkel an/aus" mit einem zyklisch von meinem Außenlichtsensor auf ein KO (nicht iKO !) gesendeten Wert (direkt, ohne Umwege auf den Eingang des Bausteins) beschaltet. Der Wert wird auch tatsachlich alle 3 Minuten auf den Bus gegeben und ist OK (Nachts = Dunkel = 1).
"Auto Morgens" und "Auto Abends" sind beide nicht genutzt, also "0".

Jetzt passiert folgendes:
Abends funktioniert die Lüftungsautomatik (also Fenster auf -> Rollo auf Lüftung, Fester zu -> Rollo wieder auf 100&#37.
Morgens, wenn Dunkel immer noch "an" ist, geht sie aber nicht (Fenster auf -> Rollo auf, Fenster zu -> Rollo fahrt auf 0%). Ich vermute, dass in der Nacht irgendwelche internen Stati zurückgesetzt werden und der Baustein "nicht mehr weiß", dass Nacht ist (?).

Fürs Debuggen: Gebe ich den (bereits zyklischen) Eingang des KO des Helligkeitssensors über einen Binarauslöser auf ein iKO (mit Befehl "Wert setzen auf 1" bzw. "0") und dieses iKO dann auf den Eingang "dunkel an/aus", dann funktioniert es wie gewollt. Das ware wieder ein funktionierender Workaround, aber sollte doch eigenlich nicht notwendig sein, oder ....


Es ware nett, wenn Du vielleicht noch einmal einen Blick auf den "Nacht-Eingang" werfen könntest, ich schließe aber auch nicht 100-prozentig aus, dass ich irgendeinen der zahlreichen Eingange falsch beschaltet habe.


Danke und Gruß
Hartmut

[MarcNaroska]

Hallo Leute!

Da bin ich mal einmal im Urlaub...

So, ich habe aktuell noch mal nachgesehen, was mein Baustein 11721 (V1.6) denn bei der Initialisierung so macht:
1. Die Ausgänge 1-5 werden aktualisiert (mit dem intern im Baustein remanent gespeicherten Werten).
2. Bei Initialisierung und Sperre=0 wird die aktuell intern remanent gespeicherte Position auf Ausgang 10 geschickt.

Da ich bei mir eigentlich GAR KEINE manuellen Fahrten mache, tritt das Problem wahrscheinlich bei mir nicht auf.
Wenn man entweder die Zeile "5012|0|"(EI and (EN[31]==0)) or EC[31]"|"SN[10]"|""|10|0|0|0" löscht oder das "#" vor der Zeile "#5012|0|"EI"|"EN[17]"|""|0|0|10|0" entfernt, müsste dieser Effekt behoben sein, da dann enweder gar keine neue Position vom 11721 ausgegeben wird, oder vorher die aktuelle Position von Eingang 17 geholt und dann ausgegeben wird.
Ich habe aber auch noch einige weitere Kleinigkeiten angepasst, damit z.B. die Timer für morgens hoch oder abends runter nach einem Neustart ggf. neu gestartet werden, wenn die entsprechende Zeit noch nicht erreicht ist. Ich stelle die V1.7 dann mal in den Downloadbereich, wenn ich wieder zu Hause bin. Außerdem denke ich noch mal über die "aktuelle Positions"-Thematik nach.

[goeran]

Hallo Hartmut,

HS-Neustarts und ungewolltes Rollofahren:
In der Kombi "Rolladenbaustein ID 11721" mit "Rolladen mit Pos. ID 1172" sind beim HS-Neustart meine Rollos immer auf die zuletzt mit "Set Pos" gesetzte Position gefahren. Alle Sperren an den Eingängen haben bei mir nicht geholfen.
Ich habe dann eine Sperre (wie im ersten Bild gezeigt) zwischen den beiden Bausteinen ergänzt, jetzt ist Ruhe !

Da sind wir ja "Leidensgenossen". Ich habe 16 Jalousien mit den beiden Bausteinen angesteuert und bei genau einer habe ich das Problem auch gehabt. Nun nach dem Einfuegen Deiner Sperrfunktion, ist das ungewollte Fahren nun auch verschwunden. Danke fuer deinen tollen Tipp!!!

Als Hilfe beim Debuggen fuer Marc ist vielleicht wichtig, dass es nur bei der einen Jalousie mit eingeschalteter Komfortfunktion passierte, alle anderen 15 blieben auch nach einem Neustart des FS stehen. Bei der Jalousie (ausgerechnet im Schlafzimmer...) war es so, dass sie sich nach einem Neustart ganz schloss, also auf 100% fuhr, auch wenn sie vorher offen war.

[Hightech]

Ein Hoch auf Hartmut!

Hallo!

Habe jetzt die Sperrlogik von Hartmut integriert und siehe da: Nach dem Reboot ist Ruhe! Nichts fährt mehr von alleine!

Also dickes Dankeschön an Dich, Hartmut, für diesen Tipp!

Olaf

[HartmutB]

Das Problem habe ich auch, doch ich habe eine Vermutung.

Ich lasse meine Rollos nicht nur nur über den Baustein laufen.
...

Hallo Jörg,
die Konfiguration habe ich auch. Ich habe beim Testen (ein Rollo müsste kurz vor dem Ende seiner Lebenszeit sein ) aber explizit über die ETS nur Befehle an den Baustein abgesetzt und da tritt es bei mir auch auf.

Im Busmonitor sieht man auch schön korrekte Ist- und Soll-Position, aber kurz nach Anlaufen der Logik wird ein (irgendwo noch remanent gespeicherter) Alt-Wert für die Soll-Position ausgegeben und dann laufen die Rollos...

Mir ging es hier tatsächlich eher um "Problemumgehung" als Ursachenkorrektur, bei den Internas der Logikbausteine verstehe ich trotz aller Bemühungen nur "Bahnhof".

Gruß
Hartmut

[Hightech]

Hallo Hartmut!

Ob das klappt, weiß ich heute abend - sitze jetzt hier schon wieder auf der Arbeit und würde am liebsten direkt nach hause fahren....

Ein weiteres kleines Problem mit den Rolläden habe ich aber auch noch: An einem Rolladenaktor hängt eine Vertikallamelle (die Dinger, bei denen bei manuellem Betrieb eine Kette fürs Drehen der Lamellen und ein Band zum Auf-und-Zuziehen dran ist). Wenn ich das Ding über Beschattungslogik auf 100 % fahre, fährt er schön sauber zu, dreht dann die Lamellen zu - nur leider dreht er dann 15 Sekunden später die Lamellen wieder auf....hier habe ich noch keine Idee, woran es liegt.

Gruß

Olaf

[lochj]

Das Problem habe ich auch, doch ich habe eine Vermutung.

Ich lasse meine Rollos nicht nur nur über den Baustein laufen. (Falls mal der HS nicht läuft, will ich es trotzdem noch hell bekommen).
Somit habe ich auch Taster zum Fahren integiert,welche den Fahrbefehl an das Rollo und an den Baustein senden.
Doch irgendwie registriert der Baustein das nicht. D.H. der Baustein fährt die Rollos hoch, ich fahre mit Taster runter und nach einem Neustart vom HS, fahren die Rollos hoch.

Gruß Jörg

[HartmutB]

bei Dir fahren die Rolläden also auch nicht, wenn die Sperre aufgehoben wird?

Hallo Olaf,

nein, bisher geht alles. Ich nutze zwar lange nicht alle Funktionen des Bausteins, aber das sollte keinen Einfluß haben. Die Sperre hat auch nur eine Dauer von 30 Sekunden (auch 10 reichen), kann man also schnell überprüfen.

Würde mich freuen, wenn es Dir hilft !

Gruß
Hartmut

[Hightech]

Ahh...

Hallo Hartmut!

Dein Problem mit dem "Fahren in ungewünschte Position nach Neustart" habe ich auch - wenn auch trotz absolut identischer Einstellungen nur an 9 von insgesamt 34 Rolläden.....Jedes einzelne Objekt mit den funktionierenden Logiken verglichen - alles absolut gleich. Auch Marc konnte keinen Fehler finden.

Verzweifel schon fast daran, weil ausgerechnet die Rolläden von unserem Mieter dabei sind

Ich hatte es ähnlich wie Du mit einer Sperre versucht, allerdings auf dem Prozenteingang. Das funktionierte soweit auch ganz gut, allerdings holten die Rolläden ihre eigenmächtige Fahrt dann nach, sobald ich die Sperre herausgenommen habe!

Werde also nachher nochmal mit Deiner Sperre einen Versuch machen - bei Dir fahren die Rolläden also auch nicht, wenn die Sperre aufgehoben wird?

Viele Grüße

Olaf

[HartmutB]

Hallo,
ich bringe dieses Thema nochmals nach oben, um von meinen Erfahrungen zu berichten und ein, zwei Tipps für die Implementierung zu geben, die ich bisher nicht beim Lesen gefunden hatte. Vielleicht hilft es, vielleicht habe ich mich aber nur zu dämlich angestellt und es geht ueinfacher:

HS-Neustarts und ungewolltes Rollofahren:
Bei mir ist es eher die Regel als die Ausnahme, dass ich erst abends zum "Spielen" am HS komme. Da ist es dann WAF-technisch unklug, wenn das Haus dabei unkontrollierte Sachen macht.
In der Kombi "Rolladenbaustein ID 11721" mit "Rolladen mit Pos. ID 1172" sind beim HS-Neustart meine Rollos immer auf die zuletzt mit "Set Pos" gesetzte Position gefahren. Alle Sperren an den Eingängen haben bei mir nicht geholfen.
Ich habe dann eine Sperre (wie im ersten Bild gezeigt) zwischen den beiden Bausteinen ergänzt, jetzt ist Ruhe !
Angesteuert wird die Sperre durch eine "HS-Neustart-Sperre". Davon ist immer wieder hier im Forum die Rede, ich hatte bisher aber nie eine Abbildung gesehen und wußte auch nicht genau, wie das geht. Hier meine Variante in Bild 2 und 3, hilft hoffentlich auch dem einen oder anderen.

Datentyp für "Set-Pos%"-Eingang E26 am Rollosteuerungsbaustein:
Ich habe hier "intuitiv" den Datentype auf "8-bit (0..100%/EIS 6)" eingestellt. Das hat auch solange problemlos geklappt, wie ich nicht die Ansteuerung der "Spezialpositionen" mit 101%, 102%, 103% und 104% machen wollte. Das geht nämlich nicht, da bei 100% Schluß ist. Der HS rechnet ja alle Datentypen automatisch um, deshalb merkt man es nicht, wenn sich alles nur innerhalb des HS mit Logik und Visu abspielt. Der Datentyp muss aber auf "8-bit (0..255/EIS 2.6)" stehen, damit es mit den "Spezialpositionen" geht. Steuert man die auch über Taster oder ähnliches an (z.B. mit einer Szene), dann muss man auch hier den Datentyp anpassen, sonst reicht es, den Typ im HS ändern.

Hoffe es hilft hier und da,

Gruß
Hartmut

[MarcNaroska]

Hallo Hartmut!

Von Ergänzungen habe ich in der Tat nicht gesprochen, sondern nur von der angesprochenen Anpassung ;-)

Das mit der Positionsrückmeldung bei 0 und 100% muss ich mir noch mal anschauen. Das Problem dabei war allerdings, dass bei sofortiger Rückmeldung Werte <0% bzw. >100% aufgetreten sind, die ich nur so in den Griff bekommen habe... Aber mal sehen...

Die Rückmeldung der laufenden Position ist in der Tat nicht gerundet. Ich wollte hier eine möglichst schnelle Lösung bauen, damit die Genauigkeit hoch bleibt und habe deshalb an Zeilen gespart. Ist aber nur eine Kleinigkeit, die die Laufzeit des Bausteins vermutlich nur sehr unwesentlich beeinflussen wird.

Über die Linearisierung habe ich auch schon nachgedacht, ich werde mal sehen, wie sich dein Vorschlag "einarbeiten" lässt.

So, noch einen schönen Nachmittag

[HartmutB]

Aufgrund meiner Überlegung werde ich den Baustein "Rolladen mit Pos" nicht mehr anpassen, ...

... aber ich hoffe, noch erweitern .

Als jetzt aktiver (und zufriedener) Nutzer Deines Bausteins hatte ich folgende Wünsche / Anmerkungen. Gutes kann man ja oft noch besser machen:

Positionsrückmeldung wahrend des Laufs und Rolloendlagen:
Mir ist aufgefallen, dass das wunderbar klappt, aber in den "Endbereichen" die 0&#37; bzw. 100% erst sehr spat erscheinen. Steht der Rollo z.B. bei 80% und ich lasse ihn per Fahrbefehl weiter "nach unten" laufen, dann steigt die Rückmeldung sagen wir 85, 89, 93, 97% und bleibt dort, bis die max. Fahrzeit des Rollos (z.B. 24 Sek) abgelaufen ist. Die letzte Position 100% wird erst dann ausgegeben, obwohl der Rollo schon 23 Sek steht. Gleiches bei 0%. Hier sollte die Ausgabe möglichst sofort kommen (oder halt nach einer Sekunde).

Rückmeldepositionen in Prozent als Real-Wert:
Ich habe ein dynamisches Symbol für die Rollos, das nach dem Muster: Symbol 1 für 0% bis 10%, Symbol 2 für 11% bis 20%, Symbol 3 für 21% bis 30%, ... gestrickt ist. Standardsymbol ist das Symbol für 0%.

Mir ist aufgefallen, dass das Symbol wahrend des Laufs machmal auf das Standard-Symbol gesprungen ist. Ich nehme an, dass dann Werte wie 10,4% aufgelaufen sind, was ich nicht erwartet hatte.
Meine Lösung war: Symbol 1 für 0% bis 10%, Symbol 2 für 10% bis 20%, Symbol 3 für 20% bis 30%,...
Vielleicht kann man auch die Ausgabe der Position schon im Baustein auf volle Prozentwerte runden (?)


Und das "Wichtigste": Linearisierung der Rollo-Positionen
Das Thema ist mathematisch tatsachlich nicht ganz trivial. Es gibt diverse Spiralformen, deren Formel für die Bogenlange man als Weg für den Rollo nehmen könnte (es lebe mein alter Bronstein). Sind aber ziemlich lange Formeln, gleichzeitig braucht man ja auch die Umkehrformel und die Umstellung möchte ich nicht machen ...

Ich habe ein wenig mit Excel rumgespielt und denke, eine Parabel reicht als Naherung vollkommen aus. Es geht ja nur darum, die sehr großen Schritte im oberen Bereich der Rollos gegen die kleineren Schritte "unten" anzugleichen.

Mein Vorschlag (quasi die Bausteinerganzung in Textform):

- Zusatzlicher Eingangsparameter "Linearisierung", Bereich zwischen "0.0" und "1.0", "0.0" als Standard (entspricht dann auch dem bisherigen Verhalten)
- Wenn "Linearisierung" < "0.0" dann "Linearisierung" = "0.0"
- Wenn "Linearisierung" > "1.0" dann "Linearisierung" = "1.0"
- interne Konstante "Faktor" = 100 ^ "Linearisierung" (damit der Wert nur einmal berechnet werden muss
- Beziehung "Soll-Position%" -> bisherigen Eingang: "Eingang" = ("Soll-Position%" ^ ("Linearisierung" + 1) ) / "Faktor"
- Beziehung "bisheriger Istwert-Ausgang" -> Ausgang neu: "Ausgang neu" = ("Istwert" * "Faktor") ^ (1 / ("Linearisierung" +1) )

(siehe Excel-Tabelle mit Grafiken: Hier den Wert "Linearisierung" in A3 andern, um den Effekt zu sehen).

Ich denke, einen Versuch ware es wert, in Python gibt es bestimmt die Potenzfunktion. Ich mache auch gerne den Tester, bei raumhohen Rollos vor Terassentüren sollte der Effekt gut erkennbar sein ...

Gruß
Hartmut

[MarcNaroska]

Hallo allerseits!

Ich bin noch mal in mich gegangen und habe über die GA Problematik nachgedacht:
Sobald man nur 1 GA Langzeit und 1 GA Kurzzeit für Taster und Aktor benutzt, kommt es zwangsweise IMMER zu einer Schleife, wenn alle Funktionalitäten meiner Bausteine genutzt werden Sollen. Egal ob ich die Weiterleitung im Baustein "Rolladen mit Pos" abschalte oder nicht: Sobald eine Position angefahren worden ist, wird ja z.B. ein Kurzzeitbefehl auf die entsprechende GA gesendet, welche dann automatisch wieder am Eingang anliegt. Ebenso wenn eine Position angefahren werden soll: jetzt sendet der Baustein einen Befehl auf die entsprechende GA und somit auch wieder an die Eingänge des Bausteins.
Die einzige Möglichkeit, dies zu umgehen, besteht darin, die GAs für Taster und Aktor zu trennen. Nur so kommt es zu keiner Rückwirkung.
Dieses Problem tritt übrigens auch bei Holgers Baustein auf, allerdings ist es hier weniger kritisch, da während einer laufenden Positionierung keine Lang-/Kurzzeitbefehle zugelassen werden...

Aufgrund meiner Überlegung werde ich den Baustein "Rolladen mit Pos" nicht mehr anpassen, da es mit oder ohne Anpassung zu einer Schleife kommen wird, wenn nur je eine GA genutzt wird.

Die Schleife kann aber relativ einfach umgangen werden, indem man Hartmuts Weg geht, und dem Aktor jeweils eine zweite GA verpasst und diese dann an die entsprechenden Ausgänge des Bausteins hängt...

[HartmutB]

da bleibt nur die Variante mit doppelten Adressen

OK, einmal mit Abstand darüber nachgedacht und festgestellt, dass es gar nicht "so schlimm" ist: Jeder Rolloaktorkanal bekommt eine zusätzliche Kurz- und Fahradresse, neu programmieren und die Adressen neu in den Experten importieren.
Dort ist es dann nur ein "Umhängen" der Bausteinausgänge "Kurzzeit" und "Langzeit" des (unmodifizierten) Bausteins auf die neu angelegten Adressen, damit der Loop weg ist. Ist noch überschaubar.

Der Test bei einem Rolloaktor hat mir in Bezug auf die Positionierungsgenauigkeit und insbeondere das Feature der Positionsausgabe während des Laufs doch sehr gefallen. Sieht einfach nett aus, wenn sich das Rollosymbol schon während der Fahrt verändert ...
Und die direkte Ansteuerung, falls mir einmal der HS geklaut wird (kaputt geht ja höchstens die Schnittstelle ) habe ich auch.

Deshalb auch von mir - wenn auch spät: Danke an Marc für den Baustein !

Gruß
Hartmut