UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

Erweiterung für Persistenz: Senden nach Reboot

Hier stellen Foristen und Kunden Ihre EIGENEN Logikbausteine vor. Diese Logikbausteine stehen jedem im Rahmen der vom Autor eingeräumten / genannten Lizenz zur Verfügung.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

Erweiterung für Persistenz: Senden nach Reboot

#1

Beitrag von Robert_Mini »

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:
  • 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!
Baustein 2:
  • 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.
Bild

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
Zuletzt geändert von Robert_Mini am Fr Apr 09, 2021 6:35 pm, insgesamt 2-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#2

Beitrag von pbm »

Hallo Robert,

ich hab mir gedacht, ich baue mir deine Logik auf "float" um.

Grund ist das Speichern meiner Raumtemperatur-Sollwerte (Beregnungs-Zeiten, Laufzeiten, usw.), die in der Cometvisu einstellbar sind.
(oder gibts da ne bessere Idee?)

Aktuell macht das der Logikprozessor auf dem Wiregate.
z.B. --> sollwert_EG_Wohn => { transmit=>'1/2/3', reply_to_read_requests=>1 },

Wenn ich deine Logik 1:1 kopiere, lässt sie sich speichern. Aber nur für Binärwerte.

Für Float habe ich die Logik zum Testen mal auf einen Ein/Ausgang reduziert.
Ich bekomme jedoch immer nen Fehler beim Abspeichern und soll die LE-Seite neu laden.

Was mache ich falsch?

Code: Alles auswählen

/**===========================================================
Baustein 2: Persistente Zelle zum Senden von float nach Reboot
============================================================*/
{
  "Input": [
        ["Eingang 1","Eingang 1","$Eingang1","u"],
		["Trigger","Triggereingang","$Trigger","a"]
  ],
  "Output": [
		["Ausgang 1","Ausgang 1","$Ausgang1","c"]
  ],
  "Level": [
		["$Eingang1","float",false],
		["$Ausgang1","float",false],
		["$Trigger","bool",false]
  ],
  "Module": [
		["Multiplexer",["$Eingang1","$Eingang1"],"$Ausgang1","$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. */

(Kann ich eigentlich eine bestehende Custom-Logik um Ein/Ausgänge "erweitern",
wenn sie erstmal gespeichert wurde? Finde den Button dafür nicht.)
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache

S. Kolbinger
Elaborated Networks
Reactions:
Beiträge: 588
Registriert: Mi Aug 15, 2018 11:34 am
Hat sich bedankt: 82 Mal
Danksagung erhalten: 558 Mal

#3

Beitrag von S. Kolbinger »

Hi Peer,

der Default-Wert für einen Level vom Typ float kann niemals false sein.

Versuch mal:

Code: Alles auswählen

["$Eingang1","float",1.0],
["$Ausgang1","float",1.0],
Gruß,
Stefan K.

pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#4

Beitrag von pbm »

Anfängerfehler... :lol:

Dank' dir Stefan!
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#5

Beitrag von Robosoc »

Ich hatte mir dieses Topic damals als Du @Robert_Mini es geschrieben hast, als Lesezeichen gesetzt und nun endlich diese Woche mal begonnen einzusetzen und zu verstehen.

Nun habe ich ein paar Anmerkungen und Fragen:

1.
Robert_Mini hat geschrieben: Di Jan 14, 2020 12:25 am Baustein 1:
[..] 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).
Ich glaube das ist in aktuellen Versionen nicht mehr möglich und führt zum Fehler beim Speichern der Logik. Daher würde ich vorschlagen diesen Halbsatz zunächst zu löschen. Später mit Einführung von MQTT wird dann ja vermutlich eine andere Lösung als die KNX-Variante geben, aber aktuell scheint es mir nur über einen KNX-Wert zu gehen.

2.
Die Outputs in Baustein 1 sollten alle das merkmal A (Always Send after Trigger) haben, was Du ja in Deinem Screenshot auch umgesetzt hast. Im Code steht aber überall c...ich würde daher vorschlagen den Code im Beitrag 1 entsprechend zu ändern, einverstanden?

3.
Dieser Punkt ist reine "Schönheitssache" bzw. Verbesserung der Nachvollziehbarkeit.

Im Baustein 2 hat mich zunächst verwirrt, dass Du jeweils zweimal den gleichen Eingangswert eingetragen hast

Code: Alles auswählen

["Multiplexer",["$Eingang1","$Eingang1"],"$Ausgang1","$Trigger"],
Ich meiner damit den zweiten Modul-Parameter:

Code: Alles auswählen

["$Eingang1","$Eingang1"]
Natürlich funktioniert es so, aber in der KB steht ja auch, dass man den Eingangswerte-Parameter begrenzen kann, wenn sich die Werte am Ende der Kette nicht mehr unterscheiden. Ich würde daher vorschlagen den Code an dieser Stelle zu reduzieren (auch weil es beim Kopieren und erweitern dann weniger zu tippen und aufzupassen gibt):

Code: Alles auswählen

["Multiplexer",["$Eingang1"],"$Ausgang1","$Trigger"],
Insgesamt fände ich hier den Einsatz von Latch besser, weil es ja ohnehin nur ein Zuweisen eines Wertes ist und dieser im Multplexer nicht vaiiert. Ich glaube, dass es Beides auf das völlig Gleiche hinausläuft, aber ich glaube auch, das eine Latch-Zuweisung den meisten Einsteigern hier schneller einleuchtet. Ist vielleicht auch einfach Geschmackssache, welches Modul man eher durchschaut (aber auch hier habe ich immer wieder das Gefühl, dass sich viele Custom-Code Einsteiger mit dem genialen Multiplexer schwer tun).


In jedem Fall ein ganz ganz dickes LOB und vielen Dank für diese ja eigentlich simplen, aber dennoch sehr wertvollen und wichtigen Bausteiene, auf die ich vermutlich von alleine nicht gekommen wäre! Und ohne die ich aber ein wenig Probleme im Haus habe, weil Initialwerte in den der CometVisu bisher fehlen. :bow-yellow:
Zuletzt geändert von Robosoc am Fr Okt 09, 2020 11:47 am, insgesamt 2-mal geändert.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#6

Beitrag von Dragonos2000 »

@Robosoc Wie hast Du angedacht das per Latch zu lösen? Ich denke da auch gerade drauf rum und die Lösung per Multiplexer ist m.E. wohl einfacher. Beim Latch muss man viel mehr Überlegungen in das richtige Triggern stecken und -spontan gedacht- auch die erste Logik anpassen, damit wegen der Persistenz als Trigger ein Flankenwechsel kommt.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#7

Beitrag von Dragonos2000 »

Ich geb' mir (Euch) nach weiterem brüten selbst die Antwort:

Code: Alles auswählen

["Latch","$Eingang1","$Ausgang1","$KonstEins", 0]
Trigger als Level bzw. Input in der Custom-Logik braucht man dann gar nicht mehr und kann einen Trigger über die GUI-Funktion ergänzen (das Plus-Zeichen). An dem ersten Logikbaustein braucht man dann doch nichts ändern.

Welcher Code angenehmer ist, muss jeder für sich entscheiden. Danke @Robert_Mini für die Vorlagen der Bausteine.
Zuletzt geändert von Dragonos2000 am Di Dez 01, 2020 6:16 pm, insgesamt 3-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#8

Beitrag von Robert_Mini »

Perfekt! Heute würde ich es auch Latch umsetzen, aber multiplexer tut eben in diesem Fall bei mir das gleiche.

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

SchlaubySchlu
Reactions:
Beiträge: 211
Registriert: Mo Aug 13, 2018 9:32 pm
Wohnort: Allgäu
Hat sich bedankt: 106 Mal
Danksagung erhalten: 91 Mal

#9

Beitrag von SchlaubySchlu »

Dragonos2000 hat geschrieben: Di Dez 01, 2020 6:13 pm Ich geb' mir (Euch) nach weiterem brüten selbst die Antwort:

Code: Alles auswählen

["Latch","$Eingang1","$Ausgang1","$KonstEins", 0]
Trigger als Level bzw. Input in der Custom-Logik braucht man dann gar nicht mehr und kann einen Trigger über die GUI-Funktion ergänzen (das Plus-Zeichen). An dem ersten Logikbaustein braucht man dann doch nichts ändern.

Welcher Code angenehmer ist, muss jeder für sich entscheiden. Danke @Robert_Mini für die Vorlagen der Bausteine.
Hallo Jochen,

kannst du uns bei gelegenheit mal deinen ganzen Code zeigen?
Wie du ja schon mitbekommen hast, bin ich gerade daran mir auch eine ZUS für die Weihnachtsbeleuchtung zu bauen ;-) aber mit dem Baustein 1 habe ich irgendwie noch meine Verständnisprobleme...

Vielen Dank!

Gruß
Ralf
Timberwolf Server 2600 #196, VPN offen, Reboot nach Vereinbarung, BM 729

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#10

Beitrag von Robert_Mini »

Baustein 1 ist ganz einfach:
Durch das Clocksignal wird die Logik automatisch nach Reboot oder Restart des Logik-Prozesses ausgeführt.
Nach dem ersten Aufruf wird die Variable State auf True gesetzt und das Clocksignal damit auf inaktiv gesetzt (-$State). Damit erfolgt kein weiterer Aufruf.

Lg
Robert

PS: bez. ZSU: hätt ich schon fertig, wenn du noch kurz warten kannst. Hab jetzt doch viel Energie in exaktes Schalten und Zeitumstellung gesteckt.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
Antworten

Zurück zu „Zusätzliche Logikbausteine“