Ankündigung

Einklappen
Keine Ankündigung bisher.

[Smart-MF] GardenControl Bewässerungsautomat

Einklappen
Dieses Thema ist geschlossen.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Masifi
    antwortet
    PS: es gibt jetzt auch eine angepasste Aufbauanleitung V1.4. Dank starwarsfan konnte ich diese jetzt auch mit neuen Bildern versehen. Danke dafür!


    Einen Kommentar schreiben:


  • Masifi
    antwortet
    Zitat von coko Beitrag anzeigen
    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?
    Bis jetzt macht der GardenControl hier noch nichts. Da man früher jedes Ventil über ein eigenes KO schalten musste, war mir das Risiko noch gering, dass jemand einfach 12 verschiedene KOs gleichzeitig hintereinander sendet.

    Ach es gibt noch viel Arbeit

    Einen Kommentar schreiben:


  • shortyle
    antwortet
    ach mist, hatte noch die 0.2.1 installiert. bin jetzt auf der 0.2.4 und es läuft direkt der Upload an.

    Einen Kommentar schreiben:


  • thewhobox
    antwortet
    shortyle Welche Version vom KnxFileTransferClient hast du denn?
    In der neuesten Version gab es da noch mehr Ausgaben und seit dem wurde auch an der Stabilität gearbeitet.

    Auf macOS kenne ich mich nicht aus.
    Evtl kann GeminiServer da weiter helfen.

    Gruß Mike

    Einen Kommentar schreiben:


  • shortyle
    antwortet
    etwas offtopic vielleicht, aber hat hier jemand schon per knxfiletransfer das update auf die 0.9 gemacht?
    Ich bekomme das einfach nicht hin, denn er bricht immer ab, bevor der eigentliche upload startet.
    pkg und Delay habe ich schon alle möglichen Varianten ausprobiert.

    Bildschirmfoto 2025-05-08 um 08.28.13.png

    Der Gardencontrol liegt auf der Außenlinie und die zickt immer etwas beim knxfiletransfer, lief final aber dann doch durch. Innenlinie geht immer reibungslos.
    Securecoupler ist von Enertex und die Filterung habe ich für 60. min deaktiviert.

    Ergänzungsfrage. Nutzt jmd den knxfiletransfer mit MacOSX? Ich wollte einmal die MacOSX Variante versuchen, ob es damit vielleicht klappt. Installation von PS und KFT hat geklappt allerdings scheitere ich dann an der korrekten Pfadeingabe.

    Code:
    PS /Users/david/Downloads/GardenControl-Release-0.9> /Users/david/Downloads/KnxFileTransferClient-0.2.4/tools/MacOS/KnxFileTransferClient fwupdate .\data\firmware.uf2 --pkg 50 --delay 250 --pa 1.1.141
    ​
    jetzt öffnet er die KnxFileTransferClient Datei mit irgendwelchen kryptischen Zeichen.

    Einen Kommentar schreiben:


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

    Zitat von Masifi Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • Molybdean
    antwortet
    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.

    Einen Kommentar schreiben:


  • Masifi
    antwortet
    Zitat von coko Beitrag anzeigen
    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

    Zitat von coko Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • coko
    antwortet
    Zitat von Masifi Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    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

    Einen Kommentar schreiben:


  • coko
    antwortet
    Zitat von mumpf Beitrag anzeigen
    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).

    Einen Kommentar schreiben:


  • traxanos
    antwortet
    Zitat von mumpf Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Zitat von coko Beitrag anzeigen
    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

    Einen Kommentar schreiben:

Lädt...
X