ElabNET Technik Forum

²Definitiv, wenn er ausschließlich mit Heizwendeln arbeitet und einen mechanischen E/A Schalter hat. Mit Regelelektronik ...

773H hat geschrieben: ↑Do Jul 18, 2019 8:08 pm ²Definitiv, wenn er ausschließlich mit Heizwendeln arbeitet und einen mechanischen E/A Schalter hat. Mit Regelelektronik ...

Einen elektronischen Dreistufenschalter³, wir nehmen aber eigentlich immer nur Stufe 3/3.
Ich habe mich damals für den entschieden, weil der sich seine Stellung merkt, wenn man ihm den Strom wegnimmt und in dieser Stellung wieder an geht, wenn der Strom zurückkommt. Das mag für die zukünftige Steuerung über einen KNX-Aktor und den Raumthermostaten sinnvoll sein.

Grüße
Marc

³ https://mert-heizkörper.de/epages/3f362c2c-20f4-4f28-bff0-be091f92398b.sf/de_DE/?ObjectPath=/Shops/3f362c2c-20f4-4f28-bff0-be091f92398b/Products/KTX2 - irgendwie wollte das mit dem [url] tag nicht klappen

StefanW hat geschrieben: ↑Mi Jul 03, 2019 11:54 am abrufen nicht (wir haben keinen Lesemodus, weil der KNX-Bus ist auf Events ausgelegt..),

Das nützt einen aber nicht wenn man ein dummes Gerät hat, das sich weigert die Events dann zu verschicken wenn der Meister sie haben möchte.

StefanW hat geschrieben: ↑Mi Jul 03, 2019 11:54 am 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.

Das skaliert gar nicht. Mir fallen auf Anhieb zwanzig Gruppenadressen in meinem Haus ein, für die ich so ein zyklisches Wiederholen gebrauchen könnte, da klickt man sich einen Wolf wenn man für jede Gruppenadresse ZWEI Logiken braucht um das gewünschte Feature zu implementieren.

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.

Die Persistenz-Diskussion ist so zerklüftet, da habe ich den aktuellen Stand und Sinn nicht verstanden.Ich bin mir nicht sicher, ob das das ist was ich hier brauche.

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.

Man muss halt wissen was man tut.

StefanW hat geschrieben: ↑Mi Jul 03, 2019 11:54 am 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.

Aber vielleicht hat man welche, die das eben nicht tun, und anstelle teure Hardware auszutauschen, die dann vielleicht andere Features nicht hat, wäre es sicher fein, hier mit dem Timberwolf ein Pflaster draufkleben zu können.

Grüße
Marc

Hallo Marc,

Zugschlus hat geschrieben: ↑So Jan 19, 2020 7:05 pmDas nützt einen aber nicht wenn man ein dummes Gerät hat, das sich weigert die Events dann zu verschicken wenn der Meister sie haben möchte.

Das ist ein Fehler des betreffenden KNX Devices. Der Bus ist auf Events ausgelegt. Ich bin überrascht, dass es heute Geräte gibt, die nicht regelmäßig einen Zustand senden können. Das konnte schon (selbstverständlich) der erste WireGate Server 2009.

Zugschlus hat geschrieben: ↑So Jan 19, 2020 7:05 pmAber vielleicht hat man welche, die das eben nicht tun, und anstelle teure Hardware auszutauschen, die dann vielleicht andere Features nicht hat, wäre es sicher fein, hier mit dem Timberwolf ein Pflaster draufkleben zu können.

Ja, das ist die normative Kraft des faktischen.

Es zerreißt uns zwar innerlich, weil zyklisches Abfragen / Mithören eines dritten Gerätes um dessen Zustand an dessen Stelle zu senden ist eigentlich Mist.

Aber wir haben das Bedürfnis der Kunden dafür verstanden und am Ende sind uns die Wünsche der Kunden wichtiger. Ich musste dem betreffenden Entwickler des KNX Stacks sehr sehr gut zureden und viele Eimer zum reinkotzen hinstellen und hab selber die Hälfte davon vollgemacht. Schließlich ist das Austauschen von Geräten (auch im Sinne von Ressourcen sparen) ebenfalls subotimal.

Bedeutet: Wir haben das auf der Liste, müssen dazu aber auch was umbauen. Ziel ist dann eine Seite, in der man einfach die Objekte (von mir aus auch GAs) eintragen kann und diese kann man dann einmalig / zyklisch lesen und das letzte Telegramm wiederholen (wobei es dann schwierig wird, wenn ein erneuter Status so zeitgleich knapp vor einer Repeption kommt, dass womöglich die dann falsche Repetition den Zyklus gewinnt [nein, wir werden nicht auch noch die PA auswerten, weil der Dispatcher hat diese Info nicht]).

lg

Stefan

StefanW hat geschrieben: ↑So Jan 19, 2020 7:21 pm

Zugschlus hat geschrieben: ↑So Jan 19, 2020 7:05 pmDas nützt einen aber nicht wenn man ein dummes Gerät hat, das sich weigert die Events dann zu verschicken wenn der Meister sie haben möchte.

Das ist ein Fehler des betreffenden KNX Devices. Der Bus ist auf Events ausgelegt. Ich bin überrascht, dass es heute Geräte gibt, die nicht regelmäßig einen Zustand senden können. Das konnte schon (selbstverständlich) der erste WireGate Server 2009.

MDT macht sehr sehr gute Geräte, aber die Heizungsaktoren können z.B. den Ventilstatus nicht zyklisch senden, sondern nur bei Änderungen, und das bei einem Wert, der teilweise monatelang konstant auf Null oder 100 bleibt.



Und auch die Comet Visu kann einmal eingestellte Werte (z.B. den Heizungs-Sollwert) nicht wiederholen - wobei ich auch eigentlich hier den Logikbaustein / Regler / Aktor in der Pflicht sehen würde, auch seine Eingangswerte zu repetieren (dann kann man nämlich den einen aussuchen, der "zählen" soll, wenn mehrere Devices auf denselben Sollwert hören).

StefanW hat geschrieben: ↑So Jan 19, 2020 7:21 pm

Zugschlus hat geschrieben: ↑So Jan 19, 2020 7:05 pmAber vielleicht hat man welche, die das eben nicht tun, und anstelle teure Hardware auszutauschen, die dann vielleicht andere Features nicht hat, wäre es sicher fein, hier mit dem Timberwolf ein Pflaster draufkleben zu können.

Ja, das ist die normative Kraft des faktischen.

Es zerreißt uns zwar innerlich, weil zyklisches Abfragen / Mithören eines dritten Gerätes um dessen Zustand an dessen Stelle zu senden ist eigentlich Mist.

Aber wir haben das Bedürfnis der Kunden dafür verstanden und am Ende sind uns die Wünsche der Kunden wichtiger. Ich musste dem betreffenden Entwickler des KNX Stacks sehr sehr gut zureden und viele Eimer zum reinkotzen hinstellen und hab selber die Hälfte davon vollgemacht. Schließlich ist das Austauschen von Geräten (auch im Sinne von Ressourcen sparen) ebenfalls subotimal.

Ich kotze gerne mit, denn nach der "reinen Lehre" habt Ihr völlig Recht, aber das Feature ist dennoch wichtig. Danke im Voraus dafür, dass Ihr es trotz Bedenken und Eurem Wunsch, auf dem Pfad der Tugend zu bleiben, implementieren werdet.

Grüße
Marc

Hallo Marc,

danke, aber es steht ja auch unter den "TOP FR", das Merkmal hätte ich nicht vergeben, wenn wir es nie machen wollen würden

Stefan

Mir ist hier noch eine Macke der MDT-Aktoren aufgefallen: Der Jalousieaktor kann die Position zwar zyklisch senden, aber nur "nicht", "alle 5s" und "alle 10s". Das ist mir zu viel. Wenn ich den Wert alle 10 Minuten haben will, müsste ich mir was stricken.

Grüße
Marc

StefanW hat geschrieben: ↑So Jan 19, 2020 7:21 pm Bedeutet: Wir haben das auf der Liste, müssen dazu aber auch was umbauen. Ziel ist dann eine Seite, in der man einfach die Objekte (von mir aus auch GAs) eintragen kann und diese kann man dann einmalig / zyklisch lesen und das letzte Telegramm wiederholen (wobei es dann schwierig wird, wenn ein erneuter Status so zeitgleich knapp vor einer Repeption kommt, dass womöglich die dann falsche Repetition den Zyklus gewinnt [nein, wir werden nicht auch noch die PA auswerten, weil der Dispatcher hat diese Info nicht]).

Verstehe ich das richtig:
Ihr baute eine zusätzliche Seite, auf der man GAs oder Objekte eintragen kann die dann (einmailig) bzw. zyklisch gelesen werden und dazwischen ihren Wert einstellbar wiederholen?
zB: Zylisch 1x/h und Wiederholung alle 5min.

Das angesprochene Timing-Problem bezieht sich auf den Fall, dass auch ein weiterer Teilnehmer liest? Oder?

Warum baut ihr nicht einen einfachen Baustein mit Standard Trigger-Eingang (zyklisch oder per Objekt wie heute bei allen Bausteinen verfügbar), der dann einen Read-Request absetzt?
Am Ausgang könnte man dann im DOS ein LE Objekt eintragen, ein 2. Ausgang könnte True/False melden, ob ein Response erfolgt ist.
Alternativ könnte man natürlich eine Logik auch auf das Objekt der gelesenen GA hören lassen.

Mir ist klar, dass das intern dann ein getrenntes Service ist, um das Timing des LE nicht zu beeinflussen, aber vom Interface würde ich das im LE belassen.

Vorteil: Man könnte damit auch ein Read on Demand triggern anstelle zwingend zyklisch zu lesen. Und zu weit in den Menüs verteilen würde ich das Read auch nicht. Schön kompakt als LE Baustein wäre auf jeden Fall mein Favorit. Ähnlich der ZSU könnte man dafür natürlich später auch eine GUI bauen, aber das sollte aus meiner SIcht gleich wie bei der ZSU den LE Baustein nicht ersetzen!!!

lg
Robert

Hallo robert,

Robert_Mini hat geschrieben: ↑So Jan 19, 2020 9:12 pmIhr baute eine zusätzliche Seite, auf der man GAs oder Objekte eintragen kann die dann (einmailig) bzw. zyklisch gelesen werden und dazwischen ihren Wert einstellbar wiederholen?

Das ist eine Überlegung. Das würde es sehr einfach machen für die Kunden.

Robert_Mini hat geschrieben: ↑So Jan 19, 2020 9:12 pmWarum baut ihr nicht einen einfachen Baustein mit Standard Trigger-Eingang (zyklisch oder per Objekt wie heute bei allen Bausteinen verfügbar), der dann einen Read-Request absetzt?

Weil das eben nicht einfach ist.

Korrekterweise müsste man dies dann für alle andockbaren Technologien implementieren

Robert_Mini hat geschrieben: ↑So Jan 19, 2020 9:12 pmVorteil: Man könnte damit auch ein Read on Demand triggern anstelle zwingend zyklisch zu lesen. Und zu weit in den Menüs verteilen würde ich das Read auch nicht. Schön kompakt als LE Baustein wäre auf jeden Fall mein Favorit.

Ich verstehe Dein Argument. Damit wäre sehr viel möglich.

Aber wir müssen auch sehen, dass selbst sehr IT affine Kunden die Menge der Möglichkeiten nicht leicht erfassen können. Du bist da weiter als viele andere, ich muss aber auch an die Mehrheit denken, da sind einfache Lösungen eben auch gefragt.

lg

Stefan

Hallo Stefan!

StefanW hat geschrieben: ↑Mo Jan 20, 2020 12:09 am Korrekterweise müsste man dies dann für alle andockbaren Technologien implementieren

Du meinst zyklisch Lesen von anderen System? Das wundert mich, da es das ohnehin nur bei manchen Systemen gibt und zweitens ja ohnehin unterschiedliche Implementierungen sind zB zyklisch KNX vs. zyklisch Modbus abfragen?

StefanW hat geschrieben: ↑Mo Jan 20, 2020 12:09 am

Robert_Mini hat geschrieben: ↑So Jan 19, 2020 9:12 pmVorteil: Man könnte damit auch ein Read on Demand triggern anstelle zwingend zyklisch zu lesen. Und zu weit in den Menüs verteilen würde ich das Read auch nicht. Schön kompakt als LE Baustein wäre auf jeden Fall mein Favorit.

Ich verstehe Dein Argument. Damit wäre sehr viel möglich.

Aber wir müssen auch sehen, dass selbst sehr IT affine Kunden die Menge der Möglichkeiten nicht leicht erfassen können. Du bist da weiter als viele andere, ich muss aber auch an die Mehrheit denken, da sind einfache Lösungen eben auch gefragt.

Ich überlege schon immer sehr stark, wie das eure Zielgruppe(n) sehen könnten. Ich bin da relativ leidenschaftslos.
Es gibt eben die Gruppe 1 der Anspruchsvollen (die Flexibilität wünschen) und die Gruppe 2, da muss es einfach sein.

Für Gruppe 1: einen Baustein mit Trigger, der ein read sendet. Mit dem Response kann man dann eine andere Logik triggern und ggf. auch über einen Timer prüfen, ob innerhalb 1s eine Antwort gekommen ist. d.g. meinen Wunsch oben kann ich mir dann schon selber erfüllen und damit ggf. auch die anderen Anspruchsvollen bedienen.

Für Gruppe 2: eine Seite, an der man zyklische Abfragen parametrieren kann.
Eventuell könnte man da ein Trigger-Objekt vorsehen, das dann den DOS aufruft => würde dann 1 und 2 kombinieren.

Ich bin eben ein Freund des schrittweise Vorgehens => zuerst die Kernimplementierung mit LE-Baustein, dann Erweiterung um GUI.

Robert