neue Versionen der Bausteine 11721, 11722 und 11724 verfügbar

[MarcNaroska]

Hey Manuel!

Das beruhigt mich ja fürs erste ungemein ;-)
Obwohl ich auch etwa 30 Rollos über meine Bausteine steuere (inkl. des Positionierungsbausteins pro Rollo) und ich bislang noch keine "Aussetzer" festgestellt habe.
Aber ich habe ansonsten auch nicht so viel Intelligenz bislang mit dem HS umgesetzt...

Also, noch einen schönen Abend.

[ThorstenW]

Hallo Marc,

da ich ebenfalls mit dem gelegentlichen Problem des ungewollten verfahrens Erfahrung gemacht habe habe ich mich mal auf Fehlersuche begeben.Ich nutzte insgesamt 20 mal den Baustein Rolladenbaustein 2.0 geweils immer mit direkter Verbindung mit dem Baustein Sonnenstand/Zeit(ID 2481) auf den Eingang Zeitrunter.Zur "Diagnose" habe ich mir alle Ein und Ausgangsobjekte mal auf eine Visuseite gelegt.
Dabei ist mir aufgefallen, dass der Sonnenstandbaustein die Dezimalzeit zum Teil mit 2 Nachkommastellen ausgibt z.B. 19.49
Ich habe mir daraufhin 2 KO angelegt, diese auf eine Nachkommastelle begrenzt (siehe Anhang) und dann jeweils an den Eingang Zeitrunter gelegt.Um ein gemeinsames verfahren aller Rolladen zu verhindern, habe ich noch eine zeitlich Stafflung eingebaut.
Seit dieser Umstellung hatte ich keine einzige Fehlfunktion mehr.Jetzt kann das natürlich Zufall sein aber in diesem Fall wäre mir das sogar egal.Eventuell kann das ja mal noch jemand testen.

Gruß Thorsten

[MarcNaroska]

Hey Thorsten!

Ich habe bei mir auch Dezimalzahlen mit 2 Nachkommastellen im Einsatz.
Und keine Unregelmäßigkeiten feststellen können.
Allerdings ist der Eingang auch eher nicht dafür ausgelegt, dass hier dynamisch Werte auflaufen...
Eigentlich ist der Eingang "dunkel" für das Verfahren der Rollos auf Tag/Nacht-Position gedacht und der Eingang ZeitRunter für eine festen Zeitpunkt, wann die Rollos spätestens runterfahren, aber erst nachdem dunkel=1 geworden ist. Wenn du jetzt den Eingang Zeitrunter änderst, während es schon dunkel ist, die Rollos aber noch nicht gefahren sind, kann es evtl. zu interessanten Effekten kommen (sollte es zwar nicht, da ausschließlich der Wert zum Zeitpunkt dunkel=1 genommen wird, aber wer weiß)...
Ich würde erstmal vermuten, dass die zeitliche Staffelung bei dir die Abhilfe geschaffen hat, aber auch hier lasse ich mich gerne korrigieren...

[AndyS]

Hi Marc,

ich hab noch etwas in HS debug zu Deiner Logik gefunden.

im Debug des HS unter Execptions steht folgender Eintrag:

07.10.2009 16:04:42 (3)
File "/hs/compile/hs_logik.py", line 170, in calc
File "formula", line 0, in ?
ZeroDivisionError: float division
[5012L, 11722L, 0L, '(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]) and (SN[6][SN[7]))', 'float(SN[5])+(float(2*SN[8]-1)*float(SN[7]-SN[6])*(float(100)/float(SN[9]+(1-SN[8])*SN[10])))', '', 0L, 0L, 1L, 0L]

Kannst Du mir bitte sagen, was das bedeutet bzw. was hat dies für Auswirkungen und wie kann ich den Fehler beheben.

Vielen Dank schon mal für Deine Mühe.

Grüße

Andy

[proxy]

und der Eingang ZeitRunter für eine festen Zeitpunkt, wann die Rollos spätestens runterfahren, aber erst nachdem dunkel=1 geworden ist.

Eingang 33: ZeitRunter 17.0 Dezimalzeit ab der das Rollo abends

runtergefahren wird.

Das verwirrt mich jetzt ein bischen...

Ich habe nämlich alle paar Wochen das Problem das alle Rolladen um "ZeitRunter" schon runterfahren obwohl dunkel noch 0 ist.

[DJGockel]

der Eingang 33: Die Zeit welche hier angegeben wird, ist die Zeit wo die Rollos frühstens runterfahren, nachdem dunkel=1 ist.

Der Eingang ist für den Winter gedacht. wo es evtl. um 16Uhr schon dunkel ist, damit die Rollos da noch nicht fahren gibt man hier z.b. 18Uhr vor.
Also würden die Rolladen dann erst um 18Uhr runter fahren

[proxy]

Genau so hatte ich es auch verstanden, deswegen habe ich auch 17 Uhr eingetragen.
Nur fahren manchmal alle Rollos um Punkt 17:00 Uhr schon runter, obwohl es Taghell ist und auch das KO Dunkel definitiv 0 hatte.
Ich kann damit leben, das passiert maximal ein mal pro Monat. Wäre trotzdem interessant zu wissen warum...

[DJGockel]

mmh, also den Fall hatte ich noch nicht ???

[MarcNaroska]

Hallo Leute!

Also, die Logik im Baustein macht folgendes:
Wenn dunkel 0->1, dann wird geprüft, ob die Zeit größer gleich der Zeit in E33 ist. Falls ja, wird gefahren, falls nicht, wird ein Timer gestartet, der dann zum Zeitpunkt E33 die Rollos fährt.
D.h., der Baustein kann gar nicht von selbst um 17:00 Uhr das Fahren der Rollos veranlassen.
Ich würde eher vermuten, dass hier die Logik für die Erzeugung von dunkel nicht immer ganz lückenlos funktioniert. Das Problem hatte ich auch schon bei mir...
Evtl. mal das iKo dunkel in ein Archiv schreiben lassen (bei jeder Änderung)...

[MarcNaroska]

Hey Andy!

Das kann eigentlich nur vorkommen, wenn du den Eingang "gemessene Fahrtzeit" E3 auf 0 setzt. Dann kommt es zu einer Division durch Null, welches dann zu diesem Fehler führt...

[proxy]

Sehr misteriös,
das Dunkel Objekt ist eine externe Adresse und kommt von einem Theben Luna.
Einen Fehler dadurch konnte ich anhand vom eibmon ausschliessen.
(Andere Aktionen die an Dunkel gekoppelt sind wurden auch nicht ausgeführt.)
Ich warte mal ab, ob das mit der neuen Version immer noch passiert.

Gruß,
Sascha

[swenga]

Hallo Marc,

bin ebenso freudiger Nutzer Deines Bausteins 11722 um meinen doch etwas einfach gestrickten Lingg+Janke Jalousieaktoren die Positionsintelligenz beizubringen. Ich nutze allerdings nur die Positionierung, die Beschattung habe ich ueber einen eigenen Baustein geloest. Zwei Problemchen habe ich derzeit:

1) Alle manuellen Fahrbefehle der Raumbedienung werden derzeit nicht direkt an die Aktoren weitergeleitet sondern an den HS, dort werden sie ueber Weiterleitung auf die Einzelfahrbefehle fuer jedes Fenster umgesetzt (Lang/Kurz-Befehle auf Eingangs-Seite des 11722 vom Taster, Lang/Kurz-Befehl fuer jedes Fenster individuell vom Ausgang 11722 an Aktor). Die Ansprechzeiten sind aber fuehlbar und somit nicht optimal. Will heissen, der Bediener dureckt im Raum die Taste und die 3 Rolläden fahren nicht zur selben Zeit sondern so ca. 400ms versetzt, speziell beim Ausrichten von Lamellen fühlt sich das komisch an. Daher wuerde ich gerne auf die Weiterleitung im Baustein verzichten und die manuellen Fahrbefehle als zweite GA's auf die Aktoren programmieren, es ist jedoch wichtig dass der Baustein die Positionsänderung mitkriegt. Wenn ich die ersten Zeilen in den Blöcken

### 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

auskommentiere, erreiche ich dann das gewuenschte?

2) Zeitliche Performance: Bei uns werden insgesamt 84 Fenster angesteuert. Wenn die Wetterstation jetzt "Dunkelheit weg" meldet, gehen alle auf Sollposition 0. Im Sommer passierte das nicht, da es eher hell war als "Zeitpunkt frühestens hoch", aber jetzt ist "Hell" später.
Es gibt immer wieder Performance-Probleme, dass einzelne Fenster nur halb hoch fahren oder 10cm vor oberem Ende stehen bleiben. Gibt es Erfahrungen, bis wieviel Fenster ein HS3 das Ganze handeln kann? Als derzeiten Workaround werde ich demnächst mal Telegrammverzögerungen in das Dunkel-Signal einbauen und diese stockwerk-/gebäude-sortiert aufreihen, so dass immer nur ca. 20 fenster fahren.

mfg Swen

[MarcNaroska]

Hallo Swen!

Zur ersten Frage:
Bei Langzeit: ja.
Bei Kurzzeit: hier musst du eher das " or EC[2]" aus der Zeile löschen.

UPDATE: Ich habe gerade einen neuen Eingang (E9) eingefügt, mit dem die Weiterleitung von manuellen Befehlen ausgeschaltet (E9=0) werden kann. Getestet habe ich das Ganze noch nicht, da ich gerade keinen HS-Zugang habe.
Sobald die Freigabe erfolgt ist, sollte die V2.2 im Donwloadbereich zur Verfügung stehen. Bei Problemen bitte kurz melden.

Zur zweiten Frage:
Bzgl. der HS3-Performance kann ich leider keine Aussagen machen. Bei mir läuft es mit ca. 30 Rollos ohne Probleme, bei anderen Nutzern kommt es auch bei weniger Rollos ab und an zu "Aussetzern" (wobei ich bislang auch noch keine Visu am laufen habe, die Nutzer mit Aussetzern hingegen schon...).
Wie ist denn das Verhalten im Sommer? Fährst du die Rollos dort auch zeitgleich über meinen Baustein hoch?

Eine weitere Lösung ist ja aber auch, dass du (mit den Änderungen am Baustein bzw. der V2.2 und E9=0), das zentrale, zeitgleiche Hoch- und Runterfahren direkt über die KOs der Rolloaktoren vornimmst...

[swenga]

Hallo Marc,

schonmal danke fuer die Integration des Weiterleitungs-Schalters, ich werde dann noch bis zum Update warten.

Ein direktes Hochfahren per GA durch die WS wil ich vermeiden, es koennte noch das Signal "Kind schläft" an sein oder im Sommer bereits "Beschattung", dann darf nicht ganz hoch gefahren werden sondern auf die entsprechenden Werte. Daher muss das ganze ueber die Sollposition laufen.

Die Zeiten "frühestens hoch" sind für beide Gebäude unterschiedlich, daher sind im Sommer weniger Rolläden zeitgleich gefahren. Jetzt aber kommt "Dunkelheit weg" nachdem beide "frühestens hoch" bereits freigegeben haben, somit fährt alles zeitgleich.

Ich werde wie gesagt ein paar Verzögerungen einbauen und einzelne Gruppen von Rolläden dann zeitlich versetzt fahren.
Ja, auf dem HS läuft ne Visu und noch ein paar andere Dinge, insofern könnten rechnenintensive Sachen evtl. verzoegert werden. Ärgerlich ist halt, dass Rollos nicht ganz hochfahren. Das liegt dann vermutlich am verzoegerten Absenden des Hochkommandos, dein Baustein will es senden, der HS kriegt es aber nicht raus und queuet es dann. Es geht verzoegert auf den Bus. Die Stop-Kommandos dagegen fallen nicht alle zeitgleich an (nicht alle Rollos sind gleich lang), so dass diese zeitgerecht gesendet werden.

Da faellt mir ein: Wäre es möglich, bei den Endlagen (also 100 und 0) kein Stop-Kommando zu senden?

mfg Swen

[MarcNaroska]

Hallo Swen!

Habe ich gerade noch als E10 eingebaut und hochgeladen...