HS/FS Hinweise zum Logikbaustein 12278 Impulsgenerator mit Lösungen

[HartmutB]

Hallo,
ich bin erst vor kurzem auf den Baustein "12278 Impulsgenerator Stunde/Tag/Woche/Monat/Jahr" von NilsS aufmerksam geworden. Den wollte ich nutzen, um viel über die Jahre gewachsene "händische" Logik durch einen Trigger-Baustein zu ersetzen.

Ich wollte den Baustein verwenden, um Auslöser *vor* gewissen Zeitpunkten zu generieren (z.B. 1 Minute vor Monatsende, 1 Minute vor voller Stunde, etc).

Leider ist der Baustein für diese Belange defekt (EIB-TECH hatte am Ende dieses Themas https://knx-user-forum.de/knx-eib-fo...mit-logik.html schon einmal eine entsprechende Anmerkung gemacht).

Mir sind noch andere Sachen aufgefallen und ich habe den Baustein überarbeitet. Wenn er "als besser" befunden wird, sollte man den in der Datenbank vielleicht aktualisieren.

Geänderte Punkte:
- Enable-Eingang mit Funktion versehen (war bisher ohne Funktion)
- Funktion war fehlerhaft bei Zeitdifferenz <>0 und in anderen Fällen
- Umgruppierung des Bauchsteins in Rubrik "Zeit-Funktionen"
- Lesbarkeit erhöht (wegen Fehlersuche, bin sonst nicht durchgestiegen)


Ein Hinweis noch:
Der Baustein gibt nicht (wie man es eigentlich erwarten würde) einfach "Trigger-Impulse" aus, wenn ein Ereignis eintritt, sondern den Zeitpunkt. Bei einem neuen Monat würde auf dem entsprechenden Ausgang dann eine Zahl zwischen 1 und 12 ausgegeben usw.
Das Problem liegt beim Ausgang "Stunde": Hier wird 0 bis 23 ausgegeben, bei einer 0 triggert das halt aber keine Logik dahinter ...

Ich habe die Ausgänge aus Kompatibilitätsgründen so gelassen, verwende selbst aber einen modifizierten Baustein, der immer nur eine "1" ausgibt und keine Zeitpunkte. Für den Baustein hier muss man eine Logik wie im gezeigten Bild verwenden, sonst verpasst man einen Stundenwechsel um Mitternacht.

Gruß
Hartmut

[marlan99]

Hallo Hartmut,

Fantastisch ! Habe schon seit Ewigkeiten den Baustein mit der konfig -10s drin der natürlich noch nie funktioniert hat.
Habe nun deinen Baustein integriert und bin soeben dran das Projekt zu laden.

Ich finde es vom Prinzip her korrekt dass bei der Stunde 0:00 eine Null ausgegeben wird, aber wie du schreibst muss man dies in der Logik eben beachten. Ich nutze für einen Tageswechsel den Tag als Trigger.

Besten Dank für deine Arbeit

Gruss
Marcel

[NilsS]

Hi Hartmut,

schön dich wieder hier zu lesen

Danke das du das Problem gefixed hast, auch wenn ich deine "normierung" nicht ganz verstehe.

#    Ende nach Ausführen
#    | Bedingung
#    | |                                                             Formel
#    | |                                                             |                                                                                     Zeitformel
#    | |                                                             |                                                                                     |            Ausgang
#    | |                                                             |                                                                                     |            | Zeitspeicher
#    | |                                                             |                                                                                     |            | | Speichervariable
#    | |                                                             |                                                                                     |            | | | Negierter Ausgang
#    | |                                                             |                                                                                     |            | | | |
# Bei Initalisierung und bei Timerablauf Zeit bis zum nächsten Timerablauf ausrechnen und in Speicher 3, zuerst unnormiert 
5012|0|"EI or OC[1]"                                                |"( lambda x:( 3600- (x[0]*60+x[1]) ) )( __import__('time').localtime()[4:6] ) +EN[2]"|""          |0|0|3|0

# Bei Initalisierung des Bausteins: (korrigierte) Zeit bis zum nächsten Stundenimpuls in Sekunden bestimmen und in Zeitspeicher 1 schreiben
5012|1|"EI and (SN[3]<=0)"                                          |""                                                                                   |"SN[3]+3600"|0|1|0|0
5012|1|"EI and (SN[3]>3600)"                                        |""                                                                                   |"SN[3]-3600"|0|1|0|0
5012|1|"EI"                                                         |""                                                                                   |"SN[3]"     |0|1|0|0

# bei Timer-Ablauf: nächsten Timer und Vergleichszeit setzen (vereinfacht ist dies immer 3600sek, aber wegen ggf. Rundungsproblemen auf Nummer Sicher)
5012|0|"OC[1]"                                                      |"__import__('time').localtime(__import__('time').time() -EN[2] )"                    |""          |0|0|1|0
5012|0|"OC[1] and (SN[3]<=0)"                                       |""                                                                                   |"SN[3]+3600"|0|1|0|0
5012|0|"OC[1] and (SN[3]>3600)"                                     |""                                                                                   |"SN[3]-3600"|0|1|0|0
5012|0|"OC[1] and (SN[3]>0) and (SN[3]<=3600)"                      |""                                                                                   |"SN[3]"     |0|1|0|0

localtime[4:6] ist von der aktuellen Zeit die Minuten und die Sekunden.

Wenn ich die Minuten nun * 60 und die Sekunden dazu rechne, dann ist dieser Wert maximal 3599 oder minimal halt 0.

Damit sind die anschließenden Vergleiche mit <=0 und >3600 eigentlich überflüssig, denn > 3600 ist nicht möglich.

Ebenso die Rundungsproblematik, die du da beschreibst verstehe ich nicht.
Da es sich bei der Berechnung um Integer handelt die lediglich Addiert, Subtrahiert oder Multipliziert werden.

Die Standard Homeserver Kategorien habe ich eigentlich immer absichtlich vermieden, da so deutlich ist das es sich NICHT um eine GIRA/DACOM Logik handelt.

EDIT: oh klar ich sehe gerade das man mit dem EN[2] die sache natürlich auch größer als 3600 bekommt, ich hatte EN[2] bei mir immer als negativen Wert. Bei einem Positiven Wert muss das natürlich -3600 gerechnet werden falls der Wert in größer 3600.

EDIT2:

# Bei Initalisierung und bei Timerablauf Zeit bis zum nächsten Timerablauf ausrechnen und in Speicher 3, zuerst unnormiert 
5012|0|"EI or OC[1]"                                                |"(( lambda x:( 3600- (x[0]*60+x[1]) ) )( __import__('time').localtime()[4:6] ) +EN[2])%3600"|""          |0|0|3|0

ein modulo 3600 sollte das Problem eigentlich lösen

[HartmutB]

Hallo Nils,

ich fand den Baustein sinnvoll und praktisch, er hat leider nicht richtig funktioniert und ich habe ihn nach meinen Möglichkeiten repariert. Ich behaupte nicht, dass es die "schönste" Lösung ist, aber sie ist getestet und funktioniert jetzt.

Da sich der Baustein selbst retriggert und (auch langfristig) nicht "auslaufen" oder "wegdriften" darf, habe ich keinen festen Wert 3600 genommen, sondern berechne den Wert immer wieder zum nächsten Stundenwechsel. Hintergedanke: Es verschleppt sich (durch hohe Auslastung oder was auch immer) der Timer um eine Sekunde, dies könnte sich im Dauerbetrieb summieren. Oder jemand (oder die Zeitsynchronisation) stellt die Uhrzeit des HS neu/um, auch dann sollte es immer passen. Mit der Berechnung des Wertes wird hier immer wieder synchronisiert.


Dein Vorschlag mit Modulo 3600 funktioniert nach (kurzer und vielleicht nicht kompletter) Überlegung meinerseits auch nicht hundertprozentig, er würde dann *sicher* funktionieren, wenn man zum Wert vorher 3600 (oder ein vielfaches) addiert und dann mod 3600 rechnet. Vielleicht ist das auch nicht notwendig, who cares ?

Die Einsortierung ist Geschmackssache, ich empfinde es als sinnvoller, Bausteine nach Funktion einzugruppieren und nicht nach Autor, da ich sie dann einfach schneller finde. Das entspricht auch der aktuellen Empfehlung von Dacom zum Entwickeln von Bausteinen, das kann man aber natürlich halten, wie man möchte.

Mir ist es wichtig, dass auch im Dauerbetrieb (mein HS startet inzwischen recht selten neu, ich ändere nur noch wenig) das Ding sicher läuft und das macht es jetzt (getestet über fast 4 Wochen, Zeitverzögerung im Bild von 2sek/4sek/6sek sind gewollt). Wenn der nächste Monatswechsel auch klappt (alles andere ist sehr unwahrscheinlich), dann stelle ich meine produktiven Logiken auf den Baustein um.


Gruß
Hartmut

[NilsS]

so ich hab das jetzt mal mit dem Modulo eingebaut und auch einen weiteren Eingang der es erlaubt das die Ausgänge nur einen binären Impuls senden anstatt der aktuellen Zeit/Datums.

Wenn das funktioniert dann werd ich das auch im Download hinzufügen.

PS: Beim nächsten mal wenn ein Baustein von mir einen defekt hat, einfach eine PN schreiben.

[NilsS]

Fehler beim überschreiten des Tages behoben

[dira]

Hallo,

ich habe ein Problem mit der Anwendung des Impulsgenerators. Ich möchte über den Baustein die Kalenderwoche in der Visu ausgeben. Nach dem Neustart des Servers wird dann auch die korrekte Kalenderwoche angezeigt. Jedoch erfolgt im weiteren Verlauf kein Update.
Benötigt der Implusgenerator einen externen Triggerimpluls, oder wo liegt der Fehler in meiner Logik?

Impulsgenerator.png