[Smart-MF] GardenControl Bewässerungsautomat

[mumpf]

Ich würde mir keine Queue antun. Sobald Du sowas machst, brauchst Du auch eine Queueverwaltung. Queue leeren, wie viele Elemente sind in der Queue, Löschen von Elementen usw. Und ich meine nicht im Gerät, sondern über den Bus zugreifbar. Denn Du landest ganz schnell in der Situation, dass Du bei b) eine Aktion auslöst und nichts passiert. Und dann willst Du den Status abfragen. Und dann stellst Du fest, dass die Tröpfchenbewässerung Deinen letzten manuellen Wunsch verhindert hat. Und dann stoppst Du die, aber es geht der Rasensprenger an, aber Du hast doch den Vorgarten machen wollen. Und dann guckst Du in die Queue, welche Aufträge noch vorher da sind. Und die willst Du alle löschen etc...
Queue würde ich nur mit sowas wie HA machen, aber nicht im Gerät.
Insofern hast Du Recht Masifi, die Idee mit dem Ignorieren war gar nicht so doof . Ich würde aber nicht ignorieren sondern den (letzten) Befehl merken und bei nächster Gelegenheit ausführen. Und sofort einen Status senden, der klar macht, ob geschaltet wurde nicht.

Gruß, Waldemar

[vogelsang]

Variante b (abgewandelt) wäre doch lediglich ein queue, der abgearbeitet werden muss.

[mumpf]

Masifi: Frage nie nach Funktionalität, User wollen immer "alles" haben .

IMO ist ein Ignorieren (Deine Variante b) keine Option, aber die abgewandelte Variante von vogelsang hat durchaus was für sich. Ich glaube aber, Du solltest wirklich beides (wählbar) implementieren, denn beides macht Sinn, es ist quasi nur eine Prioritätsverteilung:

• Variante A gibt der neuen Schaltung Priorität und schaltet das längste aktive Ventil ab
• Variante B (abgewandelt) gibt der bisherigen Schaltung Priorität und schaltet das neue Ventil erst, wenn (irgendein) altes abgeschaltet wird somit wieder Kapazitäten für das neue frei sind.

Trotzdem ist Variante B schwer zu realisieren (wenn man sich mehrere Schaltungen vorstellt, die konkurrierend eintreffen und alles belegt ist) und man sollte eventuell darauf verzichten (falls es zu Problemen in der Implementierung führt).

scw2wi: Zeitschaltuhren haben nichts mit dem GardenControl und dessen Implementierung zu tun. Bei Zeitschaltuhren wird es demnächst zwar Erweiterungen geben (habe 2 auf dem TODO stehen), aber keine Applikationsspezifischen.

Gruß, Waldemar

[scw2wi]

Möglicherweise benötigt dieser Wunsch gar keine Umsetzung im GardenControl, sondern eher eine spezielle Variante der Zeitschaltuhr.
Aktuell gebe ich ja in der Zeitschaltuhr immer die Start und Endezeit ein, entweder als Uhrzeit oder relativ zur Sonne.

Wäre es möglich, statt einer Zeitschaltuhr eine Zeitschaltsequenz zu definieren.
Der Start (oder auch das Ende) dieser Sequenz würde dann weiterhin als Uhrzeit oder relativ zur Sonne definiert, die Weiterschaltsequenz jedoch nur als Zeitdauer.

Als Jahresschaltsequenz kann dann weiterhin definiert werden, an welchen Wochentagen das jeweils aktiv sein soll.
Und es ist auch möglich, für jedes Monat andere Zeitdauern zu definieren.

Aktuell kann eine Jahresschaltuhr zwar nur 4 Schaltzeiten, für das GardenControll wären aber mehr Sequenzschritte passender.

[vogelsang]

Für b würde sprechen, dass man spontan einen Bewässerungswunsch anstoßen kann, der dann ausgeführt wird, wenn alle anderen Aufgaben abgelaufen sind.

[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.

[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.

[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.

[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) ?

[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.

[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.

[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.

[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]

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.

[henfri]

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