ElabNET Technik Forum

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

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.

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

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.

• 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?

lg

Stefan

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

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

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)

Nachtrag: Okay, nach dem Lesen von Stefans Post ist ein zeitlicher Trigger vielleicht doch keine gute Idee...

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

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.

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

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