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.
-
-
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.Kommentar
-
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.
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
Kommentar
-
Variante b (abgewandelt) wäre doch lediglich ein queue, der abgearbeitet werden muss.Kommentar
-
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
Kommentar
-
Volle Übereinstimmung
Kommentar
-
Aber das wird dann auch etwas kompliziert, falls man eine Zeitschaltuhr/Treppenlichtfunktion aus deinem Logikmodul nimmt zum Schalten von Ventilen. Die Läuft dann ja schon ab, auch wenn das Ventil noch nicht geöffnet ist. Oder kann man die solange "pausieren" bis das Ventil dann geschalten werden darf?Zitat von mumpf Beitrag anzeigen
Ich wollte es eigentlich einfach haben, aber ihr macht mich echt fertig
Kommentar
-
Hallo,
ich würde es wirklich auf Ebene der Automatik machen. Also ein "Virtual-Garden-Bewässerer"-Modul.
Und da läuft dann ein Programm ab, welches die Randbedingungen kennt (Relais für Pumpe an, nur X-Ventile gleichzeitig, außer das Tropfding, das darf immer, Laufzeiten pro Strang, ...).
Wer dann manuell eingreift, muss wissen was er tut.
So läuft das bei mir seit 10 Jahren.
Softwareseitig vielleicht noch Gürtel+Hosenträger indem man auf Schaltaktor-Ebene (also außerhalb des VGB-Modul) einen Treppenlichtautomat verwendet, so dass ein Ventil nie länger als 30Min an ist.
Gruß,
HendrikKommentar
-
Mach a) und gut ist. 😉Zitat von Masifi Beitrag anzeigenIch wollte es eigentlich einfach haben, aber ihr macht mich echt fertig
Kommentar
-
Ich hab auch das Gefühl, dass aktuell etwas zu kompliziert gedacht wird.
Warum muss man irgendeine Logik bauen, die zu viele gleichzeitige Schaltbefehle irgendwie erkennt und abblockt, zurückstellt oder sonst was, wenn man es auch einfach haben kann.
Wenn man will, dass ein Ventil nach dem anderen startet, dann kann das doch eine Sequenz ganz einfach sicherstellen.
Und wenn man will, dass immer 2 bis X Ventile gleichzeitig offen sein dürfen, dann startet man eben 2 bis X Sequenzen.
Wenn so eine Sequenz mit einer KNX-App nicht so einfach machbar ist, dann wäre es vermutlich besser, diese in HA oder sonst wohin auszulagern.
In diesem Fall wäre es jedoch hilfreich, wenn es zumindest den Treppenlichtautomat als Hosenträger direkt auf KNX-Ebene gibt.Kommentar
-
Hab ich jetzt richtig gelesen, dass GardenControl nur 2 Ventile ansteuern kann (2 statt 3 Relais)? Ich steuere aktuell die Gartenbewässerung mittels Schaltkatoren. Überlege mir aber, hier mit einzusteigen.
Außerdem möchte ich Feuchtigkeitssensoren mit einsetzen und darüber die Bewässerung steuern. Ist das auch möglich?
Für die neue Saison wäre das schon ein schönes Teil.Kommentar
-
Schau dir bitte den ersten Beitrag von mir an. Da steht es genauer. Es sind 12 Ventile und 2 externe Relais mit denen man dann auch 230V Geräte wie Pumpen schalten könnte.Zitat von Parodius Beitrag anzeigenKommentar
-
Habe einen Prototypen von der ESP32 Variante zur Verfügung bekommen und habe darauf Tasmota laufen. Die Hardware Components werden vollständig erkannt und unterstützt, Verbindung zum MQTT Broker wird hergestellt und läuft stabil (Tasmota Basics...).
Bin nun soweit, dass ich ein bestimmtes "Programm" zyklisch zur vollen Stunde laufen lasse, um die Stabilität zu testen. Parallel erfolgt die Visualiserung mit Node-Red und MQTT.
Das Beispiel "Programm" umfasst 8 Zonen mit unterschiedlicher Duration zwischen 10 und 15 Minuten. Das läuft nun im Dauertest bis nächstes WE...
Das "Programm" ist derzeit hardcoded in Tasmota/Berry, umfasst eine Liste von Zonen (Channel Number) und Duration in Minuten. Zum Testen interpretiere ich derzeit die Minuten als Sekunden.
Im nächsten Schritt wird das "Programm" als Json parametrierbar gemacht, bekommt noch einen Startzeitpunkt und kann dann über MQTT parametriert werden.
An den beiden 4-20mA Inputs habe ich Simulatoren angeschlossen, die Inputs werden linear in Prozent-Werte umgerechnet und über MQTT zur Verfügung gestellt.
Weitere Schritte:
.) Option zum parallelen On/Off Schalten von R1 während eine der Zonen 1..12 aktiv ist.
.) Status von Zone 1..8 parallel jeweils über KNX an eine Status GA senden (derzeit unterstützt Tasmota "nur" 8 verschiedene KNX GAs für Outputs, kann aber wenn notwendig dann später auch erweitert werden...)
grafik.png
grafik.png Zuletzt geändert von Noschvie; 26.01.2025, 16:44. Grund: Sorry, Screenshots versehentlich gelöscht, nun wieder dabei.Kommentar
-
Hi Matthias.
Konnte leider bei deinem GardenControl Teams-Meeting nicht teilnehmen :/ Bin gespannt auf die Aufzeichnung.
Hab die Tage mal kurz das Release 0.7-pre-release geflasht und über die ETS die phys. Adresse und Applikation aufgespielt.
Die Status-LED leuchtet nicht, aber die Prog.-LED blinkt dauerhaft.
Ist das normal?
(Ich hab noch nichts angeschlossen (z.B. 24V AC), aber da man über das 5V Relais ja 24V wegknipsen kann, bin ich davon ausgegangen, dass 24V AC erstmal nicht benötigt wird...hab leider noch kein Trafo da...)
Grüße,
Kommentar
-
Hallo,
das Blinken ist normal und zeigt an, dass keine 24V anliegen bzw. noch nie angelegen haben. Richtig, mit dem Relais kann man dann den Trafo ausschalten, wenn nicht benutzt.
Gruß
ThomasKommentar
Kommentar