Erweiterung für Persistenz: Senden nach Reboot
Verfasst: Di Jan 14, 2020 12:25 am
Hallo zusammen!
Einleitung:
Mich hat es jetzt doch keine Ruhe gelassen, dass der TWS zwar mit dem KNX-Stack die Visu richtig versorgt, nach dem Reboot aber vom KNX-Bus teilweise nicht die richtigen Werte gelesen werden können. Hintergrund: Persistenz speichert für jede Logik die letzten Zustände, sendet aber die Werte erst beim nächsten Trigger, bis dahin werden vom KNX-Stack ggf. Read-Requests falsch beantwortet. Die folgenden beiden Bausteine lösen obiges Problem. Der Baustein ist für 4 boolsche Werte vorgesehen, lässt sich aber bei Bedarf auf andere Datentypen modifizieren.
Hinweis: Andere Systeme bieten diesen Komfort des KNX-Stacks mit Read, Write, Init, etc. erst gar nicht!
Hinweis / Grenzen:
Mit den beiden Bausteinen können Zustände definiert werden, für die der TWS der Owner der Information ist, die auch vom KNX per Read-Request gelesen werden können. zB. Status Urlaub, Jalousieautomatik ein/aus etc.
Das betrifft insbesondere Eingänge von Logiken, die über eine Visu geschaltet werden, aber nicht vom KNX lesbar sind.
Sollen Logikausgänge ebenfalls vom Bus lesbar sein, müssen diese parallel zur Verknüpfung mit einem KNX-Objekt auf den Baustein 2 geführt werden.
Funktion:
Baustein 1 wird nach Reboot bzw. Restart des Logik-Services einmalig ausgeführt und sendet einen True-Trigger.
Baustein 2 lauscht permanent auf die verknüpften Eingänge und speichert diese persistent. Beim Empfang des Triggers werden die gespeicherten Werte gesendet.
Baustein 1:
Nutzungsrechte:
Der Schöpfer dieser Custom Logik überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License") die unter https://wrgt.news/TOLL zum Download zur Verfügung steht.
Bei Fragen einfach melden, Feedback wie immer gerne gesehen.
lg
Robert
Einleitung:
Mich hat es jetzt doch keine Ruhe gelassen, dass der TWS zwar mit dem KNX-Stack die Visu richtig versorgt, nach dem Reboot aber vom KNX-Bus teilweise nicht die richtigen Werte gelesen werden können. Hintergrund: Persistenz speichert für jede Logik die letzten Zustände, sendet aber die Werte erst beim nächsten Trigger, bis dahin werden vom KNX-Stack ggf. Read-Requests falsch beantwortet. Die folgenden beiden Bausteine lösen obiges Problem. Der Baustein ist für 4 boolsche Werte vorgesehen, lässt sich aber bei Bedarf auf andere Datentypen modifizieren.
Hinweis: Andere Systeme bieten diesen Komfort des KNX-Stacks mit Read, Write, Init, etc. erst gar nicht!
Hinweis / Grenzen:
Mit den beiden Bausteinen können Zustände definiert werden, für die der TWS der Owner der Information ist, die auch vom KNX per Read-Request gelesen werden können. zB. Status Urlaub, Jalousieautomatik ein/aus etc.
Das betrifft insbesondere Eingänge von Logiken, die über eine Visu geschaltet werden, aber nicht vom KNX lesbar sind.
Sollen Logikausgänge ebenfalls vom Bus lesbar sein, müssen diese parallel zur Verknüpfung mit einem KNX-Objekt auf den Baustein 2 geführt werden.
Funktion:
Baustein 1 wird nach Reboot bzw. Restart des Logik-Services einmalig ausgeführt und sendet einen True-Trigger.
Baustein 2 lauscht permanent auf die verknüpften Eingänge und speichert diese persistent. Beim Empfang des Triggers werden die gespeicherten Werte gesendet.
Baustein 1:
- Ein- und Ausgang muss mit dem selben KNX-Objekt verknüpft sein bzw. kann man auch LE-Objekt-Ausgang mit dem LE-Objekt Eingang verbinden. (Ich möchte das Restart Ereignis auch als Telegramm sehen und protokollieren).
- Startoption muss auf Startwert "false" stehen (das x beim Eingang I1)
- Die Verzögerungszeit [sec] legt fest, wie lange vor dem Senden des Triggers gewartet werden soll.
- Persistenz darf NICHT aktiviert sein!
- Der jeweilige Ein- und Ausgang muss mit dem selben KNX-Objekt verknüpft sein.
ACHTUNG: Die Triggeroption am Eingang muss auf "u" stehen bleiben, sonst kann sich die Logik selbst triggern und den KNX-Bus mit Telegrammen zumüllen! - Persistenz MUSS AKTIVIERT sein!
- Der Triggereingang wird mit dem Ausgang von Baustein 1 verknüpft.
Code: Alles auswählen
/**===========================================================
Baustein 1: Trigger nach Reboot
============================================================*/
{
"Input": [
["State","Status 0 nach Reboot","$State","c"],
["Verzögerungszeit","Verzögerung bis Trigger gesendet wird","$I_Dauer","c"]
],
"Output": [
["State Out","Wird nach Reboot auf 1 gesetzt","$State_Out","ct"]
],
"Level": [
["$State","bool",false],
["$State1","bool",false],
["$State_Out","bool",false],
["$I_Dauer","float",5.0],
["$KonstTrue","bool",true]
],
"Module": [
["Clocksignal","-$State",0,"$I_Dauer"],
["Multiplexer",["$State_Out","$KonstTrue"],"$State_Out","-$State"]
]
}
/** Der Schöpfer dieser Custom Logik überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License")
die unter https://wrgt.news/TOLL zum Download zur Verfügung steht. */
Code: Alles auswählen
/**===========================================================
Baustein 2: Persistente Zelle zum Senden nach Reboot
============================================================*/
{
"Input": [
["Eingang 1","Eingang 1","$Eingang1","u"],
["Eingang 2","Eingang 2","$Eingang2","u"],
["Eingang 3","Eingang 3","$Eingang3","u"],
["Eingang 4","Eingang 4","$Eingang4","u"],
["Trigger","Triggereingang","$Trigger","a"]
],
"Output": [
["Ausgang 1","Ausgang 1","$Ausgang1","a"],
["Ausgang 2","Ausgang 2","$Ausgang2","a"],
["Ausgang 3","Ausgang 3","$Ausgang3","a"],
["Ausgang 4","Ausgang 4","$Ausgang4","a"]
],
"Level": [
["$Eingang1","bool",false],
["$Eingang2","bool",false],
["$Eingang3","bool",false],
["$Eingang4","bool",false],
["$Ausgang1","bool",false],
["$Ausgang2","bool",false],
["$Ausgang3","bool",false],
["$Ausgang4","bool",false],
["$Trigger","bool",false]
],
"Module": [
["Multiplexer",["$Eingang1","$Eingang1"],"$Ausgang1","$Trigger"],
["Multiplexer",["$Eingang2","$Eingang2"],"$Ausgang2","$Trigger"],
["Multiplexer",["$Eingang3","$Eingang3"],"$Ausgang3","$Trigger"],
["Multiplexer",["$Eingang4","$Eingang4"],"$Ausgang4","$Trigger"]
]
}
/** Der Schöpfer dieser Custom Logik überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License")
die unter https://wrgt.news/TOLL zum Download zur Verfügung steht. */
Nutzungsrechte:
Der Schöpfer dieser Custom Logik überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License") die unter https://wrgt.news/TOLL zum Download zur Verfügung steht.
Bei Fragen einfach melden, Feedback wie immer gerne gesehen.
lg
Robert
aber mit dem Baustein 1 habe ich irgendwie noch meine Verständnisprobleme...