NEU! UPGRADE IP 11 verfügbar!
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[Gelöst] [V1.5 RC7.1] Defaultwerte für Flags der TWS ETS-Applikation
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
-
- Reactions:
- Beiträge: 3744
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1171 Mal
- Danksagung erhalten: 2076 Mal
[V1.5 RC7.1] Defaultwerte für Flags der TWS ETS-Applikation
Basierend auf der Diskussion hier (4 Postings abgetrennt): viewtopic.php?f=24&t=1530,
möchte ich mal die Frage einwerfen, ob die Flags am TWS standardmäßig alle gesetzt sein sollen?
Ich hab das noch vor mir, dass ich bei 1000 Objekten die Flags anpassen muss, denn das L-Flag passt eigentlich nie.
1) meist ist der Aktor führend
2) nach einem Speichern der Logik ist derzeit nicht zwingend Logik und Stack am gleichen Stand, so dass ein lesen einen falschen Wert zurück liefert.
Lg
Robert
Lg
Robert
möchte ich mal die Frage einwerfen, ob die Flags am TWS standardmäßig alle gesetzt sein sollen?
Ich hab das noch vor mir, dass ich bei 1000 Objekten die Flags anpassen muss, denn das L-Flag passt eigentlich nie.
1) meist ist der Aktor führend
2) nach einem Speichern der Logik ist derzeit nicht zwingend Logik und Stack am gleichen Stand, so dass ein lesen einen falschen Wert zurück liefert.
Lg
Robert
Lg
Robert
Zuletzt geändert von Robert_Mini am Mi Okt 16, 2019 10:38 pm, insgesamt 1-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 2184
- Registriert: So Aug 12, 2018 1:38 pm
- Wohnort: Karlsruher Raum
- Hat sich bedankt: 482 Mal
- Danksagung erhalten: 889 Mal
Nachdem ich da letztens selbst ein bisschen auf die Nase gefallen bin, ist die Frage gut. Ich sehe es auch so, dass das L-Flag meist unpassend sein dürfte. Die anderen könnten m.E. gesetzt sein. Das sollten wir im größeren Kreis mal diskutieren, welche Standardeinstellung sinnvoll wäre (m.M.n. alles gesetzt außer L).
Ich hab bei mir mittlerweile an vielen KO das L-Flag rausgenommen, bin aber noch weit von 1000 entfernt. Wo ich weiß, dass zyklisch ein plausibler Wert gesendet wird, hab ich das aus Faulheit noch nicht gemacht, obwohl es richtig wäre.
Insgesamt ein Thema, das bei den Meisten vermutlich unter dem Radar ist...
Ich hab bei mir mittlerweile an vielen KO das L-Flag rausgenommen, bin aber noch weit von 1000 entfernt. Wo ich weiß, dass zyklisch ein plausibler Wert gesendet wird, hab ich das aus Faulheit noch nicht gemacht, obwohl es richtig wäre.
Insgesamt ein Thema, das bei den Meisten vermutlich unter dem Radar ist...
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
-
- Reactions:
- Beiträge: 408
- Registriert: Mo Aug 13, 2018 10:51 am
- Wohnort: Hannover
- Hat sich bedankt: 187 Mal
- Danksagung erhalten: 272 Mal
Top Thema! Macht einer von euch beiden dazu einen neuen Thread auf? Würde darüber gerne mehr erfahren, nur geht das thematisch hier unter und wird nie mehr gefunden....
--
TWS 2500 (ID=137), PBM, Wartungs-VPN=ON, Reboot bitte nur nach Absprache
TWS 2500 (ID=137), PBM, Wartungs-VPN=ON, Reboot bitte nur nach Absprache
-
- Reactions:
- Beiträge: 2184
- Registriert: So Aug 12, 2018 1:38 pm
- Wohnort: Karlsruher Raum
- Hat sich bedankt: 482 Mal
- Danksagung erhalten: 889 Mal
Das führt letztlich auch wieder zu dem Thema Read-Request durch den TWS selbst, was auch schon öfter kontrovers diskutiert wurde. Definitiv sollte dieses Feature -wenn es mal kommt- selektiv und sehr bewußt aktiviert werden. Ich habe einen OpenHAB Docker laufen und nutze auch die OpenHab Visu. Die allein frägt beim Start oder Änderungen schon jede konfiguriete GA ab (wird jede andere Visu auch so machen, um konsistent zu sein). Wenn dann noch eine Dev und Prod parallel läuft, vielleicht noch die ein oder andere Spielwiese und der TWS selbst würde nochmal alles abfragen: Da ist mal mehr als ein paar Minuten "Schicht im Schacht".
Einzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus. Aber jetzt schweife ich gerade ein bisschen vom Thema ab.
Einzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus. Aber jetzt schweife ich gerade ein bisschen vom Thema ab.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
-
- Elaborated Networks
- Reactions:
- Beiträge: 9775
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7820 Mal
- Kontaktdaten:
Ja, genau und dann gehen die Requests womöglich sogar in den Timeout der jeweiligej KNX Stacks und die Antwort kommt gar nicht mehr.Dragonos2000 hat geschrieben: ↑Do Okt 17, 2019 9:38 amWenn dann noch eine Dev und Prod parallel läuft, vielleicht noch die ein oder andere Spielwiese und der TWS selbst würde nochmal alles abfragen: Da ist mal mehr als ein paar Minuten "Schicht im Schacht".
Nicht zu vergessen, wenn solche Abfragen auch Stati beinhalten von DALI-Endgeräten, dann geht das bei 6 Telegrammen pro Sekunde auf dem DALI-Abschnitt noch langsamer.
Jep, so sehen wir das auch, der KNX Bus sollte geschont werden, damit er seine Arbeit tun kann.Dragonos2000 hat geschrieben: ↑Do Okt 17, 2019 9:38 amEinzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus.
lg
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 408
- Registriert: Mo Aug 13, 2018 10:51 am
- Wohnort: Hannover
- Hat sich bedankt: 187 Mal
- Danksagung erhalten: 272 Mal
Was seht ihr denn für hohen KNX-Traffic bei Visus?StefanW hat geschrieben: ↑Do Okt 17, 2019 9:48 am [Jep, so sehen wir das auch, der KNX Bus sollte geschont werden, damit er seine Arbeit tun kann.Dragonos2000 hat geschrieben: ↑Do Okt 17, 2019 9:38 amEinzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus.
So wie ich das verstanden habe, lauschen die wie alle anderen KNX-Teilnehmer am Bus und senden, wenn eine Aktion (z. B. Klick auf Schaltfläche) stattfindet. Ist das nicht das Standardverhalten? Die Stati werden ja in der Regel nicht periodisch abgefragt, sondern kommen von den Aktoren, wo die Telegramme auch eingestellt werden (periodisch, bei Änderung, gar nicht, usw.).
--
TWS 2500 (ID=137), PBM, Wartungs-VPN=ON, Reboot bitte nur nach Absprache
TWS 2500 (ID=137), PBM, Wartungs-VPN=ON, Reboot bitte nur nach Absprache
-
- Reactions:
- Beiträge: 3615
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1272 Mal
- Danksagung erhalten: 1674 Mal
Es geht da weniger um den Regelbetrieb als viel mehr das Systemverhalten bei Wiederanlauf entweder vom Server oder vom gesamten Bus.gurumeditation hat geschrieben: ↑Do Okt 17, 2019 12:16 pm Was seht ihr denn für hohen KNX-Traffic bei Visus?
Beides kann unterschiedlich oft auftreten.
Grüße
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
-
- Reactions:
- Beiträge: 2184
- Registriert: So Aug 12, 2018 1:38 pm
- Wohnort: Karlsruher Raum
- Hat sich bedankt: 482 Mal
- Danksagung erhalten: 889 Mal
@gurumeditation : Wie Göran schon geschrieben hat, geht es um das Anlaufverhalten. Wenn da hunderte / tausende GAs mitunter mehrfach und gleichzeitig abgefragt werden, legst Du den KNX lahm.
Das ursprüngliche Thema, nämlich die KO Flags, sind auch hauptsächlich in diesem Zusammenhang in der Diskussion. Nämlich welcher Teilnehmer hat den richtigen Zustand und darf/sollte überhaupt eine Leseanfrage beantworten...
Das ursprüngliche Thema, nämlich die KO Flags, sind auch hauptsächlich in diesem Zusammenhang in der Diskussion. Nämlich welcher Teilnehmer hat den richtigen Zustand und darf/sollte überhaupt eine Leseanfrage beantworten...
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
-
- Reactions:
- Beiträge: 314
- Registriert: Mo Sep 24, 2018 9:59 am
- Hat sich bedankt: 284 Mal
- Danksagung erhalten: 195 Mal
Ja, ich finde ein Hinweis, die L-Flags kritisch zu prüfen sollte in einer Doku zur Konfiguration der TWS-KO seinen Platz finden. Ich hatte mir erst auch keine Gedanken dazu gemacht und mich dann auch mal über falsch beantwortete Read-Requests gewundert. Bis mir der Zusammenhang bewusst wurde hat es etwas gedauert...Dragonos2000 hat geschrieben: ↑Mi Okt 16, 2019 4:11 pm Ich hab bei mir mittlerweile an vielen KO das L-Flag rausgenommen, bin aber noch weit von 1000 entfernt. Wo ich weiß, dass zyklisch ein plausibler Wert gesendet wird, hab ich das aus Faulheit noch nicht gemacht, obwohl es richtig wäre.
Insgesamt ein Thema, das bei den Meisten vermutlich unter dem Radar ist...
Gruß
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache