Ankündigung

Einklappen
Keine Ankündigung bisher.

Fertig: DFF4.1 - Roto RotoTronic Dachfenster Aktor

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • appi
    antwortet
    hallo Alex
    danke für die prompte Antwort. Somit warte ich und würde mich freuen den Aktor trotzdem noch nutzen zu können. Ist echt schöne HW welche ich nicht einfach rumliegen lassen will.

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Hey Remo. Also eine Firmware als reinen schaltaktor gibt es noch nicht. Dürfte aber nicht soo aufwendig sein. Ist von der Logik her ja extrem viel einfacher als der DFF Code.

    Hab das erstellen einer schaltaktor Software auch noch auf dem Plan stehen, bin aber bedingt durch das Gartenwetter und die ausstehende beta5 Finalisierung noch dazu gekommen.

    Einen Kommentar schreiben:


  • appi
    antwortet
    Hallo
    ich habe einen DFF4.1 damals in der Sammelbestellung bestellt und auch zusammengebaut, leider wurden nun Funk Steuerungen für die Lamellen eingebaut und ich benötige den Aktor in dieser Funktion nicht.
    Gibt es eine Möglichkeit den Aktor auch einfach als normalen 8-fach Schaltaktor zu verwenden oder ist es zu aufwändig die SW anzupassen?

    Ansonsten würde ich das Teil günstig abgeben.

    Danke und Gruss
    Remo

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Wichtig beim loggen wäre:

    1) USb Anschließen und seriell verbinden
    2) DFF mit dem Bus verbinden
    3) Problem ohne Umwege reproduzieren
    4) Loggen beenden
    5) Notieren wann was auf dem Bus oder am DFF gemacht wurde, damit ich weiß wie ich das Log nachvollziehen muss.

    Und deine gemachten Einstellungen wären auch ganz hilfreich. Am besten die kconfig.xml aus dem Projektverzeichnis kopieren. Da steht alles drin.

    Einen Kommentar schreiben:


  • smarthausen
    antwortet
    Danke für Deine schnelle Antwort!

    Version: Im Februar von github runtergeladen.

    Logging: ok, das werde ich machen.

    Was mir auch noch auffällt: Öffne ich (über OpenHAB) das Fenster, klickt das Relais zu Beginn manchmal einmal (Klick Klack), manchmal aber auch zweimal. (Klick Klack, Klick Klack). Auch klickt das Relais nach Ablauf der eingestellten Verfahrzeit. Das ist unnötig, das Fenster stoppt ja selbstständig.

    Vorher dem Logging Experiment werde ich aber das Fenster nochmal über einen anderen MDT KNX Taster ansteuern. Vielleicht sendet der (alte) Glastaster ja seltsame Werte.

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Die Datentypen siehst du in der Suite bei den KOs.
    Welche Version hast du geflashed? Kannst du die serielle Schnittstelle anschließen und mit derArduino das ganze mitloggen.

    Einen Kommentar schreiben:


  • smarthausen
    antwortet
    Hallo!
    Endlich habe den neuen Sketch auf den Aktor geladen.

    Leider kann ich den Aktor (damit die Fenster) nicht per KNX steuern: Die Befehle Auf/Ab oder Öffnen/Schließen bewirken keine Bewegung. Manchmal "ruckt" der Motor kurz, bleibt aber sofort wieder stehen. Der Aktor ist dann verwirrt, auch reagiert er dann nicht mehr auf auf den Start einer Referenzfahrt.
    Was funktioniert ist das Senden von prozentualen Werten: der Aktor fährt das Fenster auf die passende Position.

    Mit welchen KNX Datentypen gibt sich der Aktor zufrieden? Mein Ziel: Öffnen und Schließen der Fenster über einen KNX Taster. (Kurzer Druck: Stop! Langer Druck: Fahren, jeweils mit Richtungsumkehr. Das ging mit dem MDT Aktor.

    Viele Grüße!

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Stimmt, das wäre noch einfacher als ein weiteres KO einzuführen.

    Einen Kommentar schreiben:


  • Eugenius
    antwortet
    Na dann einfach parametrierbar machen (ist ja nur ein extra Parameter in der XML und IF Abfrage mit 100-x im code)

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    D.h. DFF schickt die Werte falsch herum
    Nö, tut er nicht.

    Man muss halt unterscheiden zwischen "Dachfenster 100% offen" und "Rolladen 100% geschlossen".
    Die Semantik des DFF ist also korrekt, nur die Visu's sind darauf ausgelegt dass etwas zu 100% geschlossen wird, was im Falle des Dachfensters eben nicht passt.

    Fände es irritierend wenn das Dachfenster in 100% Stellung "zu" und in 0% "offen" wäre.

    Einen Kommentar schreiben:


  • Eugenius
    antwortet
    higgx, du kannst in OpenHab eigene Icons nehmen, bzw. die vorhanden nehmen, anders benennen und die Prozente umkehren. (0 zu 100, 10 zu 90...).
    Ich nutze selbst OpenHab und bei mir passen die Icons zu Rollo-Aktor. D.h. DFF schickt die Werte falsch herum

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    So eine Logik ist eigentlich nicht schwer umzusetzen. In meiner eigenen Logik-Engine (alles Java-basiert) würde ich da auf die GA hören, den Wert entgegen nehmen, invertieren und einfach auf einer anderen GA wieder raussenden. Hab ich z.b. schon für das Tag/Nacht-Signal der MDT Wetterstation gemacht:

    Code:
    package de.root1.logiccollection;
    
    import de.root1.kad.knxservice.KnxAddress;
    import de.root1.kad.knxservice.KnxServiceException;
    import de.root1.kad.logicplugin.Logic;
    
    public class Logic104InvertDayNightMode extends Logic {
    
    String pa = "1.0.104";
    KnxAddress ga;
    KnxAddress gaInvert;
    
    @Override
    public void init() {
    setPA(pa);
    
    ga = getAddress("Daemmerung Tag-Nacht Modus");
    gaInvert = getAddress("Daemmerung Tag-Nacht Modus invertiert");
    
    listenTo(ga);
    }
    
    @Override
    public void onDataWrite(KnxAddress ga, String value) throws KnxServiceException {
    boolean mode = getValueAsBoolean(value);
    write(gaInvert, getBooleanAsValue(!mode));
    log.info("Inverting day-night mode");
    }
    
    }
    Müsste man das gleiche halt mit einem Zahlenwert statt Boolean tun. In OpenHAB sieht das zwar anders aus, aber die Idee ist sicherlich die gleiche oder zumindest ähnlich.

    Bzgl. Anpassung des Aktors:

    * Erweitern der XML um die passenden KOs, inkl. Ein/Ausschalten des KOs per Parameter
    * Anpassen der .h Datei (generieren...)
    * In RotoChannel.cpp das entsprechende KO implementieren und passend zum Parameter ein/ausschalten
    Zuletzt geändert von tuxedo; 12.12.2018, 11:23.

    Einen Kommentar schreiben:


  • higgx
    antwortet
    Ich werde mal im openhab Forum versuchen eine Antwort bzgl. der externen Logik zu finden.

    Die dynamischen Icons sind ja eigentlich gut gedacht, aber ich denke, es wäre sinnvoll denen auch irgendwie einen MIN/MAX Bereich mitgeben zu können, auf den sie auch ihre Darstellung skalieren können (z.B. bei Temperaturangaben, da können verschiedene Werte kalt oder heiß bedeuten aber ich habe noch keinen Weg gefunden, denen das mitzuteilen) und auch Prozentangaben sind in der Regel relativ und manchmal auch zu invertieren.

    Das Problem haben auch Homematic User bei einigen Rolladenaktoren, glaube ich. Bei dem Zigbee oder ZWave Binding, kann man die ggf. erforderliche Invertierung in der jeweiligen Item-Definition mitangeben habe ich gelesen. Für das KNX Binding wäre doch so etwas auch sinnvoll. Vlt. lässt sich dass ja umsetzen.

    Ich würde ja beim Adaptieren des DFF XML Files auch unterstützen. Reicht es da die .XML und die kdevice_DFF_4.1.h anzufassen oder ist da mehr erforderlich, außer, dass auch die Berechnung noch irgendwo untergebracht werden muss?

    viele Grüße
    Roland

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Ich denke ein invertiertes KO wäre am einfachsten für den User. Allerdings muss man dann die XML Ändern und sicherstellen dass nichts durcheinander gerät. Oder alternativ eine Logik die außerhalb des Aktors realisieren die den Wert invertiert.

    Einen Kommentar schreiben:


  • higgx
    antwortet
    Hallo zusammen,

    nachdem sich meine Fenster mit dem DFF Aktor nun auch knx-seitig ansteuern lassen, habe ich die Fenster in meine "Visualisierung" mit aufgenommen.
    Zur Ansteuerung und Darstellung auf dem Handy/PC benutze ich openhab auf einem raspberry. Funktioniert soweit auch alles wie erwartet.
    Zur Darstellung benutze ich Rollershutter-Items und mit denen und den dazugehörigen dynamischen Icons habe ich nun immer das "Problem", dass das Symbol für das geöffnete Fenster (100% abs. Position) ein geschlossener Rolladen und für das geschlossene Fenster (0%) ein geöffneter Rolladen ist.

    Jetzt wollte ich fragen, wie ihr das prinzipiell gelöst habt. Nehmt ihr auch openhab oder etwas anderes (das wäre bei mir allerdings ziemlich aufwändig, da sonst alles auf openhab läuft) oder arrangiert ihr euch mit der inversen Darstellung der Icons oder gibt es eine Lösung per JS Transforms in openhab, die auch auf Rollershutter Items anwendbar ist oder wäre es vlt. sinnvoll auch ein invertiertes KO in die Gerätedefinition vom Aktor aufzunehmen?

    Wie sieht's bei euch aus?

    viele Grüße
    Roland

    Einen Kommentar schreiben:

Lädt...
X