ElabNET Technik Forum

Hallo Leute,
neue Aufgabenstellung .

Und zwar besitze ich ein Winzierl KNX Multi IO 570 (geiles Teil). An einem der Binäreingänge ist ein Schwimmerschalter angeklemmt, der meldet, wenn das Wasserbecken leer ist.

Leider kann das Winzierl den Status nicht zyklisch auf den Bus senden. Dies wäre mir aber aus Sicherheitsgründen wichtig. Gibt es mit dem Timberwolf (und der Logikengine) eine Möglichkeit diesen Wert zyklisch abzurufen und auf den Bus zu schreiben?

Edit:
Die Auswertung findet aktuell über den Loxone Miniserver statt. Jetzt habe ich mal eingestellt, dass dieser die Werte alle 60 Sekunden abfragt, jedoch zeigt mir der Busmonitor des Timberwolfs an, dass dieser keine Werte vom Weinzierl bekommt. Dann wird der Timberwolf ebenfalls keine Werte abfragen können.

Hallo Dominic,

abrufen nicht (wir haben keinen Lesemodus, weil der KNX-Bus ist auf Events ausgelegt..), aber Du kannst den letzten Status auf eine UND-Logik (einziger Eingang) legen und ein Taktsignal an einen Triggereingang und dann wird er das vorhandensein von "EIN" auch zyklisch entsprechend dem Takt am Triggereingang senden.

Wenn DU auch eine Null zyklisch senden willst, dann baust eine zweite Logik mit dem UND, nur dass Du Ein- und Ausgänge negierst, dann würde er Dir auch eine NULL zyklisch wiederholen.

Und ich bespreche intern, ob wir nicht einen "sende" zyklisch Baustein bekommen können, wobei ich das Feature bereits angesprochen habe mit dem geplanten Persistenz-Feature.

Aber als "sicher" halte ich das nicht, weil wenn Dein verwendeter KNX-IO den Kontakt zum BUS verliert oder dekonfiguriert wird, dann sendet ein wie oben beschriebener Logikbaustein bis zu seinem nächsten Boot ein Signal, das der Wahrheit nicht entspricht.

ICH würde einen IO-Baustein verwenden der auch zyklisch sendet, weil dann ist das autoritativ und bei ganz wichtigen Dingen würde ich noch elektrisch verriegeln (also zum Beispiel mit einem zweiten Schwimmerschalter die Pumpe elektrisch unterbrechen) weil kein Bussystem und keine Logik erreicht - über Jahren hinweg gesehen - die Sicherheit wie ein ordentlicher mechanischer Kontakt mit Zwangsführung.

lg

Stefan

Hallo Stefan,

jetzt muss ich mal nach einer groben Zeitlinie für das Persistenz-Feature fragen - wäre wichtig für die Planung der Migration des WG auf den TW.
Und natürlich die macVLAN Sache

jensgulow hat geschrieben: ↑So Jul 14, 2019 7:57 pmjetzt muss ich mal nach einer groben Zeitlinie für das Persistenz-Feature fragen - wäre wichtig für die Planung der Migration des WG auf den TW.

Es gibt keinen genauen zeitlichen Plan, auch weil wir noch am grundsätzlichen technischen Design feilen, wie wir das machen.

Prio hat erstmal:

- Am DOS müssen wir noch die GA-Anzeigen und GA-Suche verbessern
- Den Logikeditor finishen und veröffentlichen
- WireGate Plugin Container als App
- Stabile Release-Version herausbringen


Danach stehen auf dem Programm:

- DMX (kommt bereits schrittweise bereits in die BETA)
- macVLAN
- ModBus
- MQTT
- Persistenz-Objekte

wobei die Reihenfolge nicht so zwingend ist. Allerdings ist klar, dass wir DMX als nächstes bereitstellen.

lg

Stefan

Okay, danke für die Info

StefanW hat geschrieben: ↑Mi Jul 03, 2019 11:54 am Aber als "sicher" halte ich das nicht, weil wenn Dein verwendeter KNX-IO den Kontakt zum BUS verliert oder dekonfiguriert wird, dann sendet ein wie oben beschriebener Logikbaustein bis zu seinem nächsten Boot ein Signal, das der Wahrheit nicht entspricht.

Das mit dem zyklisch senden des letzten Zustandes, den der TWS empfangen hat, halte ich auch nur für einen Notnagel zB. für Visu-Zwecke.
Aus meiner Sicht sogar deutlich "gefährlicher" als jegliches Lesen vom Bus, denn ein Reboot des TWS oder Restart des logic-services des TWS führt hier möglicherweise zu einem sicher unerwünschten Zustand, nämlich dass ein falscher Wert zyklisch gesendet wird.
Auch nach einem Stromausfall könnte passieren, dass zB 0 zyklisch gesendet wird, nur weil der TWS beim Booten nach dem Stromausfall das 1. Telegramm des KNX-Binäreingangs, das bei Busspannungswiederkehr gesendet wird, mit einer 1 (noch) nicht mitbekommen hat.
Mach ich bei mir sicher nicht!

StefanW hat geschrieben: ↑Mi Jul 03, 2019 11:54 am Und ich bespreche intern, ob wir nicht einen "sende" zyklisch Baustein bekommen können, wobei ich das Feature bereits angesprochen habe mit dem geplanten Persistenz-Feature.

Ich würde auch sehr stark auf ein Lesen und daraus zyklisch Senden pochen. Ehrlicherweise verstehe ich deine (StefanW's) Hartnäckigkeit nicht.
Muss jeder ohnehin entscheiden, ob (und wie oft er sowas einsetzt).

Aber ein aktives (und ggf. zyklisch) Lesen vom Bus hat auch unschlagbare Vorteile:
- hat keine Probleme nach einem Spannungsausfall
- hat kein Problem mit einem defekten KNX-IO (oder dekonfigurierten)=> dann bekommt das Lesen keine Antwort => und der Baustein soll auch nichts senden
- löst die Schwierigkeiten, die man mit älteren KNX-Binäreingängen eben hat (und da gehört der allseits beliebte Siemens Heizungsaktor mit 6 IO auch dazu!!!)
- Persistenz ist bei solchen Spezialfällen von IO, die nicht zyklische senden können, auch nicht 100%ig. Könnte ja während dem Booten auch ein Fenster geöffnet werden (oder eine Leckage gemeldet werden), die genau 1x gesendet wird. Aus der Persistenz wird dann aber ein Fenster zu (oder keine Leckage) gelesen und munter weitergesendet .....
- Weiterer Anwendungsfall (hab ich schon mal wo erwähnt) sind Schaltfelder in Infodisplays. Die Senden bei Betätigung den aktuellen Wert, aber dann nie mehr.

Ich finde ein aktives Lesen in manchen, selteneren Fällen absolut notwendig und unter allen Möglichkeiten die beste, sicherste, zuverlässigste.
Abgesehen davon möchte ich nicht alle Eingänge zyklisch senden, auch wenn es für den Bus kein Problem ist.

lg
Robert

Danke Robert,

ich bin nicht total dagegen, ich habe nur Angst, dass das mit dem Lesen übertrieben wird und der Bus dann überlastet und anschließend es dem Produkt angelastet wird "Der Wolf hat meinen Bus niedergefahren" und wenn man es erklärt dann "... warum machen die dann ein Feature, wenn es gefährlich ist..". Wir müssten also eine Begrenzung einbauen.

Der KNX Bus ist auf "Senden bei Ereignis" ausgelegt, das mit dem Pollen ist angesichts der zum Teil nur 25 Telegramme die manche LK schaffen recht begrenzt.

Du musst heute als Hersteller einer Microwelle höllisch aufpassen, dass keiner einen Hund rein tut zum Trocknen... Zuwenige Leute denken nach und machen dann das Produkt verantwortlich, welches etwas gefährliches zugelassen hat. Es will keiner mehr selbst die Verantwortung übernehmen für das was er konfiguriert, sondern die Erwartung ist, dass der Computer aufpasst... damit sind neue Features immer recht aufwändig..

Deine Beispiele habe ich verstanden. Kurzzeitige (einstellbare) Persistenz mit Lese-Aktualisierung wäre vermutlich hilfreich.

lg

Stefan

Verstehe deine Sorge schon auch, aber gerade bei komplexen Produkten wie Logik ist auch Hirn gefragt.
Man kann auch eine oder mehrer Logiken bauen, die den Bus mit Sendetelegrammen voll müllt.

Ein Lesetelegramm bedeutet statt 1 => 2 Telegramme (theoretisch auch mehr als 2, dann hat man die Basics von KNX nicht verstanden....).

Robert

StefanW hat geschrieben: ↑So Jul 14, 2019 9:19 pm Deine Beispiele habe ich verstanden. Kurzzeitige (einstellbare) Persistenz mit Lese-Aktualisierung wäre vermutlich hilfreich.

Das ist schon die Non-plus-ultra Lösung, ich wüsste auf Anhieb gar nicht wie das umsetzbar sein soll (je Logikeingang wählbar? je Logikzelle wählbar? für alle Objekte? - gefährlich!)

Im Sinne von keep it simple würde mit der ActiveRead-Baustein absolut genügen =>
- Triggereingang mit Möglichkeit zyklisch oder Zeitpunkt (ideal wäre noch after restart)
- Senden zyklisch oder bei Änderung
- Nichts senden, wenn kein Antwort vom KNX gekommen ist.

lg
Robert

PS: ins FR Unterforum verschoben, damit man auch voten kann.

StefanW hat geschrieben: ↑So Jul 14, 2019 9:19 pm ... ich bin nicht total dagegen, ich habe nur Angst, dass das mit dem Lesen übertrieben wird und der Bus dann überlastet und anschließend es dem Produkt angelastet wird "Der Wolf hat meinen Bus niedergefahren" und wenn man es erklärt dann "... warum machen die dann ein Feature, wenn es gefährlich ist..". Wir müssten also eine Begrenzung einbauen.

Eben. Einfach eine Telegrammbegrenzung des TWS im Interval [1 ... 12] pro Sekunde und fertig. Ist exakt so beim HS gelöst. Da kann dann jeder selbst entscheiden, was wie oft in welcher Menge den Bus zumüllt.

Frage: wie viele Telegramme sendet der TWS momentan maximal / s?

Gruss
Stephan

50/sec.
Deinen Vorschlag mit Telegrammratenbegrenzung finde ich sehr gut.

Deckt aber nur Senden und Abfragen ab, nicht den Fall, dass man 4/s abfragt, aber 10 je GA antworten. Ist aber wieder ein konstruierter Fall wo nur Hirn einschalten hilft.

Robert