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
[FR] Read-Request zyklisch senden
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: 28
- Registriert: Sa Mär 16, 2019 10:51 pm
- Hat sich bedankt: 181 Mal
- Danksagung erhalten: 10 Mal
Read-Request zyklisch senden
Hallo,
wahrscheinlich schon längst irgendwo beschrieben, aber ich finde es nicht:
Ich habe KNX-Heizungsaktoren, die leider den aktuellen Stellwert nicht zylisch senden.
Habe diesen bisher per Read-Request vom Wiregate zyklisch (alle 5min) abgefragt und suche nun eine Lösung dies per TW zu erledigen.
Danke und Grüße
Tobias
wahrscheinlich schon längst irgendwo beschrieben, aber ich finde es nicht:
Ich habe KNX-Heizungsaktoren, die leider den aktuellen Stellwert nicht zylisch senden.
Habe diesen bisher per Read-Request vom Wiregate zyklisch (alle 5min) abgefragt und suche nun eine Lösung dies per TW zu erledigen.
Danke und Grüße
Tobias
TWS 950 ID:324 VPN:offen, Neustart:erlaubt
-
- Reactions:
- Beiträge: 3614
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1271 Mal
- Danksagung erhalten: 1674 Mal
Readrequest geht nicht, aber einen einmalig gesendeten/empfangenen Wert zyklisch ausgeben geht. gab hier auch schon eine Anleitung zu, ggf auch bis in die KB bei den Anleitungen zu den fertigen Bausteinen.
suche mal nach LE zyklisch senden.
suche mal nach LE zyklisch senden.
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: 2322
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 898 Mal
- Danksagung erhalten: 700 Mal
Hallo zusammen,
nativ im TWS so nicht unterstützt. Ließe sich aber m. E. Über den Plugincontainer bzw. die neue App nachbauen.
Beste Grüße
Jens
nativ im TWS so nicht unterstützt. Ließe sich aber m. E. Über den Plugincontainer bzw. die neue App nachbauen.
Beste Grüße
Jens
-
- Elaborated Networks
- Reactions:
- Beiträge: 9773
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7810 Mal
- Kontaktdaten:
Hallo Tobias,
wir haben verstanden, dass es - für veraltete und schlechte KNX-Geräte die nicht zykl. senden können - eine Möglichkeit der Abfrage geben soll.
Darüber denken wir nach.
Stefan
wir haben verstanden, dass es - für veraltete und schlechte KNX-Geräte die nicht zykl. senden können - eine Möglichkeit der Abfrage geben soll.
Darüber denken wir nach.
- Es ist nur nicht ganz so einfach, weil was ist, wenn das abfragende Gerät nicht antwortet (weil abgesteckt, Busfehler etc), wie soll man dann darauf reagieren (was wünscht der Kunde hier), dass man dann etwas schickt, was in einem Testament vorher hinterlegt wurde?
- Wie lange soll man einen (früher) empfangenen Wert zwischenspeichern? Auch über Reboots hinweg?
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: 3744
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1171 Mal
- Danksagung erhalten: 2076 Mal
Ich verstehe nicht, warum du hier so extrem vorsichtig bist!?
Es liegt in der Verantwortung des Anwenders, sich zu sorgen, was passiert, wenn xyz eintritt.
Ihr müsst nur die Funktionen dafür bereit stellen. Read Verhalten und Reboot sind 2 paar Schuhe.
Konkret:
- Read-Baustein mit GA als Parameter oder Objekt als Eingang.
- TimeOut festlegbar
- Ausgang mit Wert des Response Telegramms (hauptsächlich für Custom Logics)
- Ausgang Response: True, wenn innerhalb ResponseTime < Timeout, dann kann über einen Multiplexer selbst entscheiden, was man macht, wenn keine Antwort kommt.
Zusätzlich: Erweiterung des Triggers um “after reboot” und “nach Busspannungswiederkehr” (für integrierte KNX Schnittstellen).
Lg
Robert
Es liegt in der Verantwortung des Anwenders, sich zu sorgen, was passiert, wenn xyz eintritt.
Ihr müsst nur die Funktionen dafür bereit stellen. Read Verhalten und Reboot sind 2 paar Schuhe.
Konkret:
- Read-Baustein mit GA als Parameter oder Objekt als Eingang.
- TimeOut festlegbar
- Ausgang mit Wert des Response Telegramms (hauptsächlich für Custom Logics)
- Ausgang Response: True, wenn innerhalb ResponseTime < Timeout, dann kann über einen Multiplexer selbst entscheiden, was man macht, wenn keine Antwort kommt.
Zusätzlich: Erweiterung des Triggers um “after reboot” und “nach Busspannungswiederkehr” (für integrierte KNX Schnittstellen).
Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Elaborated Networks
- Reactions:
- Beiträge: 9773
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7810 Mal
- Kontaktdaten:
Hallo Robert,
die Logikengine und der Dispatcher sind ereignisgesteuert, da geht ein Read-Baustein nicht, wir haben gar nicht eine solche Kommunikationsrichtung implementiert, weil alles was gepollt werden muss (wie 1-Wire, ModBus) wird von entsprechenden Subsystemen vorgenommen und das Ergebnis dann als Message an den Dispatcher gegeben.
Daher müssen wir das als komplett neues Modul implementieren und hier haben wir das Gefühl - auch wegen dem gewünschten Persistenz-Feature - dass wir das noch nicht zu Ende gedacht haben. Außerdem wird von einem Produkt heute nicht nur "maximale Freiheit in der Konfiguration" erwartet, sondern auch "Das Produkt muss das doch merken" wenn dann was falsches konfiguriert wurde.
Merksatz: "Im Support findet der (private) Kunde jedes Argument warum er für eine vergebliche Fehlerbehebung nicht bezahlen muss und hat beliebige Zeit das zu Diskutieren".
Beispiel: Es gibt Kunden, die installieren gemäß der veröffentlichten Anleitung einen Docker mit Edomi. Das Edomi schreibt per Backup dann die Platte voll bis zum letzten Byte. Der Server funktioniert nicht mehr. Der Kunde ruft aufgeregt an, dass nix mehr am Server geht und braucht SOFORT einen Ersatz, wegen der Heizungsregelung. Ansich hatte dieser Kunde nur Bronze und keinen Anspruch auf einen Vorab-Austausch (sondern entsprechend der gesetzlichen Regelung kann er es zur Reparatur einsenden, die hier dann eigentlich kostenpflichtig wäre, weil das Vollschreiben der Platte fällt nicht unter die gesetzliche Gewährleistung). Der Sachverhalt war aber da noch nicht bekannt, da uns ein defekter Server mit viel Wehklagen geschildert wurde und wir keine schlechte Presse im Forum haben wollen "TWS tot, Kinder frieren", haben wir eben den Server sofort und gleich ausgetauscht. Nach dem Einsenden stellt sich dann der Sachverhalt mit der vollgeschriebenen Platte heraus. Der Kunde wünscht dann sogar noch dass man ihm seine Daten von Edomi extrahiert und zuschickt. Da sind wir dann schon über "Platin" Support. Der Vorgang hat kalkulatorisch ungefähr 500 EUR bei uns gekostet.
Darum sind wir vorsichtig. Stellen wir uns vor, ein Kunde stellt dann 50 Read-Reguestes ein, die alle zwei Sekunden rausgehen, dann ist der KNX Bus zur Hälfte voll. Dann gibt es einen Thread im Forum "immer wenn der TWS läuft, steht mein Bus". Gelöst wird das dann oft im Hintergrund und die Wahrheit ("dass der Kunde das System überfordert hat") wird von uns auf Rücksicht auf den Kunden nicht gepostet. Aber für Mitleser bleibt ein Beigeschmack über, dass "der Server hat den Bus tot gemacht" hat. Wir kennen das zur Genüge aus dem alten Forum mit dem WireGate Server. Da wurde mit Root-Rechten die tollsten Sachen gemacht und ElabNET wurde schnell als der "schuldige" dargestellt. Wir wurden sogar mit schlechten Berichten in Foren erpresst, wenn wir den Server nicht kostenlos reparieren.
Es ist am Ende nicht wichtig, was wirklich passiert ist und in welcher Sphäre etwas liegt, sondern nur welcher Eindruck in der Öffentlichkeit entsteht. Und als Hersteller haben wir da immer die schlechteren Karten, weil von uns erwartet wird, dass wir eher mit leichter Demut alles ertragen, uns für alles ausgiebig bedanken und auf keinen Fall eine direkte oder klare Antwort geben die auch nur annähernd als Schuldzuweisung an einen Kunden verstanden werden könnte.
Wir haben auf diese Weise schon viel Geld mit "unberechtigtem Support" verloren, darum sind wir mit allen Features, die irgendwas am heiligen KNX-Bus zumüllen können wirklich sehr vorsichtig. Der KNX Bus ist absichtlich auf Event-based aufgebaut, weil er für ein "Read-System" nicht ausreichend schnell ist.
Wenn wir ein solches Feature einbauen, an das wir durchaus denken, dann muss das Proof sein und auch mit in die bereits eingebauten Telegrammratenbegrenzung eingebaut sein.
Ich bitte einfach um Verständnis, dass wir uns immer auch über den Impact von Leistungsmerkmalen Gedanken machen und daher eher zweimal darüber nachdenken.
lg
Stefan
die Logikengine und der Dispatcher sind ereignisgesteuert, da geht ein Read-Baustein nicht, wir haben gar nicht eine solche Kommunikationsrichtung implementiert, weil alles was gepollt werden muss (wie 1-Wire, ModBus) wird von entsprechenden Subsystemen vorgenommen und das Ergebnis dann als Message an den Dispatcher gegeben.
Daher müssen wir das als komplett neues Modul implementieren und hier haben wir das Gefühl - auch wegen dem gewünschten Persistenz-Feature - dass wir das noch nicht zu Ende gedacht haben. Außerdem wird von einem Produkt heute nicht nur "maximale Freiheit in der Konfiguration" erwartet, sondern auch "Das Produkt muss das doch merken" wenn dann was falsches konfiguriert wurde.
Merksatz: "Im Support findet der (private) Kunde jedes Argument warum er für eine vergebliche Fehlerbehebung nicht bezahlen muss und hat beliebige Zeit das zu Diskutieren".
Beispiel: Es gibt Kunden, die installieren gemäß der veröffentlichten Anleitung einen Docker mit Edomi. Das Edomi schreibt per Backup dann die Platte voll bis zum letzten Byte. Der Server funktioniert nicht mehr. Der Kunde ruft aufgeregt an, dass nix mehr am Server geht und braucht SOFORT einen Ersatz, wegen der Heizungsregelung. Ansich hatte dieser Kunde nur Bronze und keinen Anspruch auf einen Vorab-Austausch (sondern entsprechend der gesetzlichen Regelung kann er es zur Reparatur einsenden, die hier dann eigentlich kostenpflichtig wäre, weil das Vollschreiben der Platte fällt nicht unter die gesetzliche Gewährleistung). Der Sachverhalt war aber da noch nicht bekannt, da uns ein defekter Server mit viel Wehklagen geschildert wurde und wir keine schlechte Presse im Forum haben wollen "TWS tot, Kinder frieren", haben wir eben den Server sofort und gleich ausgetauscht. Nach dem Einsenden stellt sich dann der Sachverhalt mit der vollgeschriebenen Platte heraus. Der Kunde wünscht dann sogar noch dass man ihm seine Daten von Edomi extrahiert und zuschickt. Da sind wir dann schon über "Platin" Support. Der Vorgang hat kalkulatorisch ungefähr 500 EUR bei uns gekostet.
Darum sind wir vorsichtig. Stellen wir uns vor, ein Kunde stellt dann 50 Read-Reguestes ein, die alle zwei Sekunden rausgehen, dann ist der KNX Bus zur Hälfte voll. Dann gibt es einen Thread im Forum "immer wenn der TWS läuft, steht mein Bus". Gelöst wird das dann oft im Hintergrund und die Wahrheit ("dass der Kunde das System überfordert hat") wird von uns auf Rücksicht auf den Kunden nicht gepostet. Aber für Mitleser bleibt ein Beigeschmack über, dass "der Server hat den Bus tot gemacht" hat. Wir kennen das zur Genüge aus dem alten Forum mit dem WireGate Server. Da wurde mit Root-Rechten die tollsten Sachen gemacht und ElabNET wurde schnell als der "schuldige" dargestellt. Wir wurden sogar mit schlechten Berichten in Foren erpresst, wenn wir den Server nicht kostenlos reparieren.
Es ist am Ende nicht wichtig, was wirklich passiert ist und in welcher Sphäre etwas liegt, sondern nur welcher Eindruck in der Öffentlichkeit entsteht. Und als Hersteller haben wir da immer die schlechteren Karten, weil von uns erwartet wird, dass wir eher mit leichter Demut alles ertragen, uns für alles ausgiebig bedanken und auf keinen Fall eine direkte oder klare Antwort geben die auch nur annähernd als Schuldzuweisung an einen Kunden verstanden werden könnte.
Wir haben auf diese Weise schon viel Geld mit "unberechtigtem Support" verloren, darum sind wir mit allen Features, die irgendwas am heiligen KNX-Bus zumüllen können wirklich sehr vorsichtig. Der KNX Bus ist absichtlich auf Event-based aufgebaut, weil er für ein "Read-System" nicht ausreichend schnell ist.
Wenn wir ein solches Feature einbauen, an das wir durchaus denken, dann muss das Proof sein und auch mit in die bereits eingebauten Telegrammratenbegrenzung eingebaut sein.
Ich bitte einfach um Verständnis, dass wir uns immer auch über den Impact von Leistungsmerkmalen Gedanken machen und daher eher zweimal darüber nachdenken.
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: 2184
- Registriert: So Aug 12, 2018 1:38 pm
- Wohnort: Karlsruher Raum
- Hat sich bedankt: 482 Mal
- Danksagung erhalten: 889 Mal
Sagt denn der Standard nichts dazu? MDT bietet in ihren Logikmodulen auch solche Funktionen. Ich würde es wie folgt machen:
- Jeder Eingang bekommt eine Option zum "Read", wie auch a,c,u,i
Optional: Zusätzlich kann ein zeitlicher Trigger definiert werden (wie dies für die gesamte Logik möglich ist) - Lesen einmal (oder was im Standard steht)
- Timeout fix (was der Standard dazu sagt)
- Das "Read"-Flag greift auch, wenn der Logikbaustein neu gestartet wird (wie bspw. beim Speichern nach einer Änderung)
- Das "Read"-Flag greift auch nach einem Reboot des TWS, wobei hierfür global die max. Telegrammrate eingestellt werden kann (maximal einstellbarer Wert liegt unterhalb der Sättigung des Bus)
Zuletzt geändert von Dragonos2000 am Do Aug 15, 2019 11:02 am, insgesamt 1-mal geändert.
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: 3744
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1171 Mal
- Danksagung erhalten: 2076 Mal
Hab‘s jetzt verstanden (technisch), auch deine Sorgen, wobei man die Kunden such erziehen muss. Kulanz gibt es nur, wenn es auch gerechtfertigt ist. Der beschriebene Fall ist da schon ein Grenzfall.StefanW hat geschrieben: ↑Do Aug 15, 2019 10:39 am Hallo Robert,
die Logikengine und der Dispatcher sind ereignisgesteuert, da geht ein Read-Baustein nicht, wir haben gar nicht eine solche Kommunikationsrichtung implementiert, weil alles was gepollt werden muss (wie 1-Wire, ModBus) wird von entsprechenden Subsystemen vorgenommen und das Ergebnis dann als Message an den Dispatcher gegeben.
Daher müssen wir das als komplett neues Modul implementieren und hier haben wir das Gefühl - auch wegen dem gewünschten Persistenz-Feature - dass wir das noch nicht zu Ende gedacht haben.
Stefan
Ich hatte das auch (Kameraarchiv), Änderungen von Namen v. TimeSeries ließen sich nicht mehr speichern ...
Blick auf das Gesundheitszeichen genügte, um das Problem zu erkennen.
Zum Read:
Ich denke es braucht gar nicht so eine tiefe Integration wie von Jochen beschrieben.
Getrennter Baustein (mit Triggereingang und Objekt, gelesen werden soll), der den separaten Prozess mit lesen anstößt, auf das Response wartet und dann auf seinem Ausgang den Wert und einen 2. Ausgang mit erfolgreich true/false.
Alle weiteren Logiken werden ja ohnehin durch das Ereignis Response getriggert und dann kann man entscheiden, was man damit macht.
Wie beim eibd würde ich ein parametrierbares MaxAlter vorsehen, dass entweder den letzten Wert aus dem Stack (der in der Objektverwaltung angezeigt wird) verwendet wird oder neu ein read gelesen wird => mit timeout.
Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 3744
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1171 Mal
- Danksagung erhalten: 2076 Mal
Ergänzung: wenn man Objekte persistent speichern könnte (selektiv?), braucht es noch eine Auswahl an Regeln:
- Active Read after Reboot
- use stored (persistent) value
- Active Read, but use persistent value in case of timeout
- no action
Lg
Robert
- Active Read after Reboot
- use stored (persistent) value
- Active Read, but use persistent value in case of timeout
- no action
Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297