NEU! HTTP-/REST-API jetzt auch in der Rolle des TWS als HTTP-Server
Viele Details dazu hier im Forum
Upgrade: Digest Access Authentication im Subsystem HTTP-/REST-API Client
Upgrade: 361 neue Icons & kompletter Refresh aller Icons für VISU und Admin-UI
Upgrade: Dekodierung für sieben weitere DPT im Busmonitor
Upgrade: Verbesserung im Logik Manager bei Modul "SendExplicit"
Upgrade: Verbesserte und erweiterte Benutzerverwaltung bei "Passwort vergessen" der Elab ID
Jetzt in der Insider Version 8 zur 4.5 - für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki
[TIPP] LE: Wie geht's: Read-Request nach Logik
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: 1908
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 644 Mal
- Danksagung erhalten: 797 Mal
LE: Wie geht's: Read-Request nach Logik
Kann ich über den LE ein KNX-Read Request erzeugen. Wenn ja, wie?
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 4105
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1435 Mal
- Danksagung erhalten: 1925 Mal
Nein!
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
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
-
- Elaborated Networks
- Reactions:
- Beiträge: 10813
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5342 Mal
- Danksagung erhalten: 8938 Mal
- Kontaktdaten:
Hallo Sven,
der Dispatcher und die Logikengine des Timberwolf Servers sind eventbasiert ausgelegt, d.h. Meldungen über Stati werden verarbeitet und Statusänderungen triggern eine Berechnung in der Logik (je nach Einstellung).
In einem eher "langsamen" Bussystem wir dem KNX System ist das zyklische Abfragen von Parametern der falsche Weg, weil wenn 250+ Teilnehmer die jeweils 250+ anderen Teilnehmern zu je 20 KO reihum abfragen, wäre die Buslast zu hoch (und man bedenke, ein KNX System kann auf mehr als 60.000 Teilnehmer anwachsen). Daher wurde das System eventbasiert ausgelegt, gerne auch mit zyklischem Senden.
Seltene oder einmalige Telegramme (Knopf an einer Visu gedrückt) kann man mit der persistenten Logikengine abfangen, indem man diesen Wert über eine Logikzelle führt und diese Zelle als "persistent" markiert.
Dennoch mag es Fälle geben (etwa KNX Teilnehmer, die das ein oder andere nicht senden können) in denen eine Abfrage sinnvoll sein mag. Das ist heute aber noch nicht implementiert, steht aber auf der Liste. Dennoch möchte ich appellieren, selbst wenn wir das Abfrage-Feature dann implementiert haben, trotzdem immer zuerst einen Weg über "eventbasiert" und ggfls Persistenz zu suchen, der Buslast wegen.
lg
Stefan
der Dispatcher und die Logikengine des Timberwolf Servers sind eventbasiert ausgelegt, d.h. Meldungen über Stati werden verarbeitet und Statusänderungen triggern eine Berechnung in der Logik (je nach Einstellung).
In einem eher "langsamen" Bussystem wir dem KNX System ist das zyklische Abfragen von Parametern der falsche Weg, weil wenn 250+ Teilnehmer die jeweils 250+ anderen Teilnehmern zu je 20 KO reihum abfragen, wäre die Buslast zu hoch (und man bedenke, ein KNX System kann auf mehr als 60.000 Teilnehmer anwachsen). Daher wurde das System eventbasiert ausgelegt, gerne auch mit zyklischem Senden.
Seltene oder einmalige Telegramme (Knopf an einer Visu gedrückt) kann man mit der persistenten Logikengine abfangen, indem man diesen Wert über eine Logikzelle führt und diese Zelle als "persistent" markiert.
Dennoch mag es Fälle geben (etwa KNX Teilnehmer, die das ein oder andere nicht senden können) in denen eine Abfrage sinnvoll sein mag. Das ist heute aber noch nicht implementiert, steht aber auf der Liste. Dennoch möchte ich appellieren, selbst wenn wir das Abfrage-Feature dann implementiert haben, trotzdem immer zuerst einen Weg über "eventbasiert" und ggfls Persistenz zu suchen, der Buslast wegen.
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: 4105
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1435 Mal
- Danksagung erhalten: 1925 Mal
Den Text muss an sich Mal speichern, das kommt ja immer Mal vor die Frage.
Finde die Antwort aber auch berechtigt.
Finde die Antwort aber auch berechtigt.
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
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU