[OpenKNX-Ready] GardenControl Bewässerungsautomat

[traxanos]

Wünsche kann jeder haben Ich möchte nur sensibilisieren warum, das kein gute Idee ist (wenn auch nur technisch).

Halte ich für vertretbar.

Ich z.B. nicht. ich lasse die Tröpfchen immer mit laufen, weil die Pumpe stromfrist und das für eine T-Bewässerung mist ist wenn die Pumpe immer an/aus geht und gleichzeitig Strom verbraucht.

[Stereofeld]

... und es könnte ja auch nicht nur von der Zisternenpume, sondern auch vom verwendeten Trafo abhängig sein, wie viele Ventile man gleichzeitig schalten möchte/kann.

[Stereofeld]

Wünsche kann jeder haben

... eben. ;-) Verstehe aber durchaus deinen Punkt.

[henfri]

Weil es für einen spezifischen Fall ist.

Wie gesagt, das sehe ich anders.

Ich denke, dass in den meisten Fällen nur ein Kreis zur Zeit laufen kann
Eine solche Funktion unterscheidet für mich ein Garden Control von einem Schaltaktor.

[traxanos]

Ich bau die Firmware nicht, daher ist das nicht meine Baustelle. Aber für mich ist der Ausgang nur ein Schaltaktor und ich würde den Baustein einmal bauen und für alle Geräte vernwenden. Also auch bei einem Schaltaktor. Was hier zusätzlich gewünscht ist, dass sich technisch Channels gegenseitig beeinflussen. Das sprich gegen das modulare Konzept und die Wiederverwendbarkeit. Und mit "spzifisch" mein ich für den UseCase Bewässerung. Und selbst da ist es sogar spezifisch. Viele haben zB. eine Ventil vor alle anderen Ventilen als hauptventil geschaltet. Also es ist ein Spezialfall der sicherlich häufiger vorkommt.

Aber unsere Software wäre nicht so flexibel einsetzbar wenn man sowas immer umsetzen würde. Dann wäre wir kein bisschen besser als normale Herstellergerät. Ich weis die Anwender möchte immer alles haben was für Sie vermeintlich das Beste ist, sind sich aber der Tragweite seltens bewusst.

[henfri]

Wenn ich diese Argumentation auf einen Jalousieaktor anwende, erfolgt, da die verschattung auch über ein Logikmodul.

[traxanos]

Es war mir schon klar, dass jetzt eine solche, doch recht lächerliche Argumentation kommt. Ein Jalousieaktor ist doch etwas völlig anderes. Dabei geht es um Positionsermittlung, manuelle und automatische Steuerung, Auf- und Ab-Fahrten, und so weiter. Es werden komplett andere Relais genutzt, die mechanisch gegeneinander verriegelt sind, etc.

Aber ich versuche es mal anders zu erklären: Wenn ich eine solche Funktion überhaupt einbauen würde, dann eher als eigenständiges Sperrmodul, das generisch und oberhalb der Aktoren angesiedelt wäre. Damit könnte man flexibel verschiedenste Sperrlogiken abbilden – und das sogar geräteübergreifend.

Das ist z.B. auch der Grund, warum ein Binäreingang bei uns nicht wie ein kommerzielles Produkt direkt Funktionen wie S0-Zählen oder Tasterfunktionen hat. Stattdessen gibt es ein separates Zählermodul, das von einem eigenständigen Binäreingang gespeist werden kann, oder ein Tastermodul, das jede Art von Binäreingängen oder funktionsarme Taster in funktionsreiche Taster umwandeln kann.

Ich weiß leider nicht, wie aktuell alles umgesetzt ist, aber ich würde sogar Schaltaktor und Bewässerungsmodul trennen. Das Bewässerungsmodul könnte zum Beispiel von einem Sensor (intern oder extern) den Wert der Bodenfeuchte erhalten, und alle Bewässerungssteuerungen könnten dann mit diesem Wert arbeiten. Genau das meine ich mit einem modularen Ansatz. Auch könnte ein Bewässerungsautomat mehrere Schaltaktoren steuern. Denn wenn ich 3 Kanäle haben für einen Rasen, dann ist das für mich eine Bewässerung und ich würde auch die Bewässerungszeit einmal für den kompletten Rasen berechnen.

Ja, das macht es etwas komplexer, aber auch unfassbar flexibel – etwas, das man bei kommerziellen Anbietern so nicht findet. Aber die müssen ja auch noch eine Daseinsberechtigung haben.

[mumpf]

traxanos: Marco, da bin ich nicht Deiner Meinung. Der Vorteil von KNX-Geräten ist nunmal, dass sie lokale Intelligenz zum jeweiligen Verwendungszweck mitbringen. Das GardenControl ist durchaus nicht nur ein Schaltaktor, sondern eine Bewässerungssteuerung (zumindest sollte es das sein). Es könnte ein Schaltaktor-Modul verwenden, um die Ventile zu steuern (wenn es so aufgebaut wäre), aber die Bewässerungssteuerung sollte ein zweckgebundenes Modul sein, dass (intern und extern) Schaltkanäle steuern kann und sinnvolle Bewässerungsprogramme implementiert. Idealerweise so als Modul gekapselt, dass man es auch als Virtuelles Garden Control laufen lassen kann und damit z.B. normale Schaltaktoren schalten kann.

So würde ich das zumindest aufbauen und die verschiedenen Bewässerungsmodi (auch durch Benutzer angeregt) implementieren. VPM und VirtualButton sind gute Beispiele dafür, der virtuelle Jalo-Aktor wird der nächste Meilenstein sein. Ein Glück, dass ich keinen automatisierbaren Garten (mangels Hardware) habe .

Gruß, Waldemar

[traxanos]

Ich glaub das hast du muss verstanden. Ich hab nichts anderes gesagt das es extern sein soll, sondern das ich das in eigene Module auslagern würde und nicht den schaltaktor mit irgendwelche Spezial Logikern zu versehen.

[henfri]

Der Wunsch war hier ja funktional zu sehen und nicht bezüglich der technischen Umsetzung.

Ich denke auch, dass ein virtual watering Module super wäre und diese Funktion beinhalten kann

Ich frage mich aber warum man das überhaupt sperren möchte. Immerhin passiert ja nichts schlimmes.

Also in meinem Fall kann ich sagen, dass dann die grasbewässerung einfach nicht funktioniert, weil nicht genug Druck auf der Leitung ist.

[barontigger]

Ich fände die Funktion auch sinnvoll und bei Hunter Bewässerungscomputern ist das so auch integriert. Bei Versenkregnern kann auch immer nur ein Kreis laufen lassen, da sie sonst nicht ausfahren.
Es stimmt schon, dass es Kreise gibt, die parallel laufen können (Tropfschlauch) aber die kann man genauso gut nacheinander laufen lassen.
Das Risiko, dass die Pumpe nicht genug Wasser liefert finde ich jedenfalls relevanter, als dass mehrere Kreise gleichzeitig laufen müssen.
Und wie erwähnt - professionelle Bewässerungscomputer haben diese Einstellung standardmäßig eingestellt.

[Masifi]

Ok es ging ja etwas hin und her

Genau diesen Punkt habe ich eh schon auf der Liste stehen. In der ESP32 Variante habe ich es schon vorgesehen. Hier kann man im Code festlegen, wie viele Ventile parallel offen sein dürfen.

Das hat aber mehrere Gründe:
- Den Wasserdruck wie hier schon angesprochen.
- Die Stromaufnahme ist aber auch nicht ganz unwichtig.
a) Die Ventile haben alle einen etwas höheren Einschaltstrom. D.h. es ist nicht Sinnvoll zu viele Ventile gleichzeitig zu öffnen.
b) Der Summenstrom aller Ventile darf den Max Output des Trafos nicht überschreiten. Die Trafos haben in der Regel alle eine Schmelzsicherung, daher wird nichts "anbrennen", aber wer hat schon Lust, bei einer Falschbedienung immer die Schmelzsicherung zu tauschen. Gut man könnte eine "großen" Trafo verbauen, der auch mal mehrere Ventile überleben würde. Das ist aber verschenktes Geld, wenn man es nicht braucht. Ich denke ein 1A Trafo ist ausreichend. Damit kann man dann 3 Ventile (~300mA/Ventil) parallel betreiben.

Die Idee ist jetzt, das schalten sequentiell durchzuführen. D.h. die Firmware lässt es nicht zu, das mehr als ein Ventil gleichzeitig geschalten wird.

Definiert man die max Anzahl parallel geöffneter Ventile auf 2 und schalten dann ein drittes ein. Dann
a) schließt die Firmware das am längsten offene Ventil automatisch, wartet 1-2Sek und öffnet dann das neu ausgewählte
oder
b) wenn die max. Anzahl schon erreicht ist, wird der Wunsch ein drittes zu öffnen einfach ignoriert.

Was wäre hier denn besser a) oder b) ?

[vogelsang]

Wenn man sich Hunter als Vorbild nimmt, wäre b in abgewandelter Form gut. Die Ventile bleiben bis zum Ablauf der Zeit in ihrer Position. Wenn ein Ventil schließt, wird die nächste Anforderung ausgeführt.

[Stereofeld]

Dann
a) schließt die Firmware das am längsten offene Ventil automatisch, wartet 1-2Sek und öffnet dann das neu ausgewählte

Ich wäre sehr für diesen Ansatz (das würde ja auch meinem "Radio-Button-Wunsch" entsprechen. Letztendlich kann ich dann nämlich die Ventile einfach nacheinander anschalten und das Ausschalten erledigt dann das GardenControl.

[barontigger]

Meiner Meinung nach ist eine manuelle Schaltung ohnehin eher die Ausnahme (ist aber wahrscheinlich wie die PM Diskussion in anderen Themen). Mit einem vernünftigen Plan kann man alles schön nacheinander laufen lassen. Bei meinem Hunter habe ich immer etwas Abstand gelassen, da dieser bei hohen Temperaturen eine Laufzeitverlängerung hatte. Da muss ich mir aber erst eine Logik einfallen lassen im HomeServer.

Ich wäre eher für a), da nur ein Ventil laufen sollte und es maximal zu Überschneidungen kommen kann. Dann würde es mehr Sinn machen dasjenige abzuschalten, da am längsten läuft.