[OpenKNX-Ready] GardenControl Bewässerungsautomat

[mumpf]

WICHTIG: mit dieser Änderung wird die Applikation in der ETS nicht mehr updatefähig sein!

Matthias, bist Du sicher? Kann ich hier vielleicht helfen? Ich wüsste keinen Grund, warum Du inkompatibel werden müsstest, nur indem Du ein neues Modul aufnimmst. Du hattest doch schon im GardenControl unsere Module verwendet, oder?

Gruß, Waldemar

[Masifi]

Auf coko Hinweis hin habe wir die Nummerierung der Module angepasst und meinem Verständnis nach, sollte es dann nicht mehr updatefähig sein.
Können das aber gerne noch einmal besprechen.

[traxanos]

Wenn das so wäre , dann wäre das wirklich so .

[coko]

Die vorgeschlagene Umnummerierung (mit Blick auf längerfristige Erweiterbarkeit) betrifft nur die beiden Relais und die Analog-Eingänge, also die meisten Einstellungen und KOs sollten erhalten bleiben.

[traxanos]

Das wäre ja kein Problem. Dann müsste die Version weiter Upgradebar sein und die nächste neue Version nur dies Version als Zwischenversion erlauben und gut ist.

[mumpf]

Die vorgeschlagene Umnummerierung (mit Blick auf längerfristige Erweiterbarkeit) betrifft nur die beiden Relais und die Analog-Eingänge,

Ich hab mal reingeschaut. coko und Masifi: Wo seht ihr da die Notwendigkeit die Modulnummern zu ändern? Es ist doch ohne Vorteil, die jetzt ab 20 aufsteigend in Einzelschritten zu machen.

Nach dem, was ich gesehen habe, ist das überhaupt nicht notwendig. coko Dein Modul kann die 8 bekommen, da Du ja einen größeren Nummernkreis brauchst. Und ich sehe kein weiteres Modul, dass mit einer einstelligen Modulnummer in den GardenControl rein muss. Das heißt, man hat immer noch Platz für 60-70 Module, auch wenn ihr nicht umnummeriert.

Ich würde mir das stark überlegen, immerhin ist Updatebarkeit eines der wirklich guten Features von OpenKNX. Und hier ohne wirkliche Not was zum machen, finde ich ehrlich gesagt ein No-Go. Oder hab ich was übersehen?

Gruß, Waldemar

[traxanos]

Ich würde mir das stark überlegen, immerhin ist Updatebarkeit eines der wirklich guten Features von OpenKNX. Und hier ohne wirkliche Not was zum machen, finde ich ehrlich gesagt ein No-Go. Oder hab ich was übersehen?

nein das sehe ich auch so. bei einer beta vor stable zu wechseln kann ich noch nachvollziehen. aber das sind ist ja nun schon länger draußen. einen echten mehrwert bringt das nicht.

[coko]

Wo seht ihr da die Notwendigkeit die Modulnummern zu ändern?

Ich war angesichts der bereits zweistelligen ModulTypen und dem letzten Stable-Releases aus 2023 davon ausgegangen, dass die Modul-Unterteilung sowieso neu ist (was bei genauerem Hinsehen nicht der Fall ist) und sich der Kompatiblitätsbruch somit auf Testversionen beschränkt hätte. Da mit dem DFA-Modul der letzte große Nummernkreis belegt wurde, spracht das für mich dafür lieber aufzuräumen bevor von einem Kompatiblitätsbruch größere Nutzerzahlen beeinflusst werden und eine größere Anzahl von Parametern betroffen ist (aktuell betrifft die Änderung maximal etwa 60 Parameter). Mit den nun vorliegenden Kenntnissen würde ich auf die Änderung der ModulTypen aber auch verzichten wollen, bzw. nur den Typ von ConfigTransfer anpassen (definitiv neu dazu gekommen und die die Informationen sind in der aktuellen Implementierung sowieso nicht auf dauer relevant).

[mumpf]

Hi @coko,

genau das habe ich eben Masifi vorgeschlagen: ConfigTransfer bekommt eine neue Modulnummer (die von Dir vorgeschlagene 19).
Die anderen 3 Module behalten ihre 30, 40 und 50. Die StateEngine bekommt weiterhin die 8 (und belegt damit 80-89).
Somit bleibt alles kompatibel und Masifi kann noch viele Module unterbringen. Bevor es wieder ein "Einstelliges" Modul gibt, wird noch einige Zeit vergehen, und ob das dann für den GardenControl relevant wird, ist auch noch offen.

Gruß, Waldemar

[Masifi]

Dann wird es die Tage ein angepasstes Release geben, dass auch weiterhin updatefähig sein wird.

[coko]

Dazu gibt es jetzt noch ein zentrales KO(DPT5.10 ) mit mit dem man die Ventile steuern kann.
Man schreibt auf dieses KO die Nummer des Kanals welcher sich "öffnen" soll.

Bsp.: man sendet den Wert im KO = 5 -> dann öffnet sich CH5, danach sendet man den Wert im KO = 9 -> dann wird parallel dazu auch noch CH9 geöffnet.

D.h. Es werden immer nur die Ausgänge im GardenControl aktiviert. Sendet man den gleichen Wert noch einmal, dann bleibt der Ausgang trotzdem noch aktiv.
WICHITG: es gibt keine Überwachung, wie viele Ausgänge schon offen sind. Man kann also in der Theorie alle Ausgänge damit aktivieren.

Parallel dazu gibt es noch den Wert im KO = 0 -> dann werden immer ALLE Ausgänge deaktiviert und damit alle Ventile geschlossen.
WICHTIG: Magnetventile benötigen immer noch Wasserdruck damit sie sauber schließen. D.h. Wenn viele Ventile gleichzeitig offen sind, kann es beim schließen aller gleichzeitig unter Umständen zu "Problemen/Verzögerungen" kommen, da der Wasserdruck in diesem Zustand vielleicht schon zu gering ist.

[...]

FRAGE: wäre es besser, wenn man den Ausgang toggelt? Bsp.: ich sende eine 5 und CH5 wird geöffnet. Sende ich wieder eine 5 wird CH5 geschlossen.

Umschalten bei eingehender Kanal-Nummer würde ich nicht machen. Das würde in Verbindung mit den Zustandsautomaten dazu führen, dass ein erneutes Aufruf des selben Zustands (mit entsprechender Ausgabe) nicht zum selben Resultat führt. Wenn Du explizit abschalten willst, dann könnte man noch über die Verwendung negativer Kanal-Nummern nachdenken. Passt aber aber nicht gut zur Nutzung mit Zustandsautomaten.

Besser wäre eine Lösung mit der sich eine eindeutige Abbildung von Automaten-Zustand auf Öffnungs-Zustand aller Ventile realisieren lässt. Einfach in der Realisierung, aber unschön in der Eingabe wäre die Auswertung von 12 Bits aus einem Ganzahlwert. Schöner ein Mapping von Szenen auf Öffnung der Ventile.

[Masifi]

Der neue passende Release habe ich jetzt hier abgelegt: GardenControl-Release-0.9.zip

[Masifi]

Umschalten bei eingehender Kanal-Nummer würde ich nicht machen. Das würde in Verbindung mit den Zustandsautomaten dazu führen, dass ein erneutes Aufruf des selben Zustands (mit entsprechender Ausgabe) nicht zum selben Resultat führt.

Das ist ein guter Punkt, dann ändere ich hier nichts mehr

Besser wäre eine Lösung mit der sich eine eindeutige Abbildung von Automaten-Zustand auf Öffnungs-Zustand aller Ventile realisieren lässt. Einfach in der Realisierung, aber unschön in der Eingabe wäre die Auswertung von 12 Bits aus einem Ganzahlwert. Schöner ein Mapping von Szenen auf Öffnung der Ventile.

Das habe ich mir auch schon überlegt, aber wenn man hier einen falschen Wert sendet , sowas wie "4095" = 111111111111, dann gehen alle angeschlossenen Ventile gleichzeitig auf. Der Einschaltstrom aller Ventile wäre dann so groß, das mindestens die Sicherung im GardenControl fliegt. Das sollte man tunlichst verhindern.

[Molybdean]

Ein KO für öffnen und eins für schließen? Dann kann man alle Ventile einzeln ansteuern aber bei einer Fehlbedienung ist das Risiko geringer.

[coko]

Masifi bei zyklischem Senden wäre Umschalten auch unglücklich.

dann gehen alle angeschlossenen Ventile gleichzeitig auf. Der Einschaltstrom aller Ventile wäre dann so groß, das mindestens die Sicherung im GardenControl fliegt. Das sollte man tunlichst verhindern.

Sollte das nicht die Implementierung im Garddencontrol verhindern, anders als ein normaler Schaltaktor? Was passiert denn wenn Du direkt hintereinander weg, ohne die 20-30ms Verzögerung vom Bus, die Einschaltsignale sendest? Wobei die Einschaltströme auch von der eingesetzten Ventilen abhängig sein dürften.