Fertig: DFF4.1 - Roto RotoTronic Dachfenster Aktor

[tuxedo]

Denke ich hab den Fehler gefunden:

Das abschließende "speichern" der aktuellen position ist nur dann erfolgt, wenn der Aktor von der Verfahrzeit ans Ende gelaufen ist, aber nicht wenn er quasi vorzeitig gestoppt wurde.
Hab noch einen Else-Fall eingebaut der das nun abprüft. Ich kann den Aktor nun auf 50% fahren lassen, von Hand stoppen (habs mit den Tasten am Gerät getestet). Der Aktor hält an und die aktuelle, korrekte Position wird auf den Bus gesendet.

Bildschirmfoto vom 2018-12-06 11-28-29.pngIch kann auch weiterfahren oder in die andere Richtung steuern. Er macht an der passenden Position weiter.
Kleiner Fehler, große Wirkung.

Fix ist commited. HIer die relevante Änderung:

https://github.com/KONNEKTING/DFF4.1...722e2dae54R822

Bitte gegentesten.

Gruß
Alex

[higgx]

Hi Alex,

super! Vielen Dank für den schnellen Fix!
So wie es aussieht, geht jetzt auch bei mir alles so, wie ich es erwarten würde.

Ich denke damit sollte auch der zweite Teil der geschilderten Probleme von smarthausen gefixt sein. Die Fehlermeldungen lesen sich jedenfalls so ähnlich, wie ich es zu vor auch erfahren hatte.

Habe also heute zum ersten Mal die Fenster (zumindest provisorisch) an die Aktoren angeschlossen und kann sie mit dem Handy über openhab vernünftig ansteuern. Jetzt muss ich nur noch die Verfahrzeiten besser ausmessen und dann bin ich mal gespannt, wie sich das ganze System so bewährt.

Beide Daumen hoch!

viele Grüße
Roland

[tuxedo]

Bei mir sind es 40 bzw. 47sek für die Fahrzeiten des Fensters. Schon krass dass das doch so weit auseinander liegt. Wenn noch Fehler auffallen: USB Kabel dran und/oder die StatusKOs mit der ETS mitloggen, Szenario dazu und hier melden. Oder aber noch besser: Selbst mal in den Code rein schauen :-) (und trotzdem hier melden und berichten)

Gruß
Alex

[higgx]

Nichts für ungut, aber ich habe in den Code geschaut... aber mehr so wie ein Schwein ins Uhrwerk :-)
Habe zwar ein wenig Programmiererfahrung, aber so ohne alles den Code von jemand anderem zu verstehen und dann auch noch den Bug zu beheben ist manchmal nicht so leicht. War ja schon glücklich, dass ich so halbwegs die Ursache pinpointen konnte ...

Der Aktor hatte auch schon vor dem Fix funktioniert, das einzige was nicht ging, war das manuelle Unterbrechen der Fahrt. Wenn das von den anderen Usern keiner benutzt, fällt der Fehler auch nicht so schnell auf.

Das die Fahrzeiten so unterschiedlich sind, führe ich mal darauf zurück, dass das Fenster einmal mit der Schwerkraft und gegen eine Feder arbeitet und im anderen Fall eben nicht. Wenn man die Federspannkraft anders einstellt, wie auch z.T. erforderlich, wenn man nachträglich einen Rolladen anbringt, kann sich das Verhalten wieder verändern.

viele Grüße
Roland

[tuxedo]

Ok, wer keinerlei nennenswerte Programmiererfahrung hat, wird im Code nicht weit kommen. Aber auch ich muss mich nach 2-3 Monaten Abstinenz in diesem Code wieder '"einarbeiten". Ist einfach zu viel um das permanent im Kopf zu haben :-)

Die Log-Ausgabe hilft ein wenig.

[higgx]

Jetzt hab ich noch eine Frage zum Programmieren mit der Suite.

Ich hatte die Fahrzeit jetzt mal testweise auf 45s für jeden verwendeten Kanal eingestellt, um sicher zu sein, dass der Aktor nicht mitten in der Fahrt das Fenster anhält , weil dieses zu langsam und der Aktor denkt es wäre schon offen.

Habe die Parameter geändert und dann über den orangen Knopf "KO und Parameter programmieren" über das KNX Netz programmiert.

Leider wird die Zeit nicht angenommen und steht immer noch auf 30 Sekunden (also im Aktor) in der Suite steht 45s. Der Aktor fährt also nach wie vor 30s.

Das Protokoll in der ETS zeigt beim Programmiervorgang an, dass die Suite versucht auf die Adresse 15/7/255 zu schreiben. Sollte das nicht individuell je nach verwendeter PA anders sein? Einige Zeilen werden auch gelb hinterlegt, hat das was zu bedeuten?

vielen Dank und viele Grüße
Roland

[tuxedo]

15/7/255 wird als allgemeines Ziel für die Programmierung genutzt. Das ist bei allen konnekting Geräten so und völlig normal. Kannst dich da ja in unserem Wiki einlesen.

Die Zeit sollte aber im Aktor ankommen. Bin gerade nicht am PC, aber ich meine die Infos werden beim Start des aktors auf der seriellen Schnittstelle geloggt.

[higgx]

Ok, habe eben mit dem Orangen Button probiert - hatte nicht die richtigen Werte. Habe dann mit dem grünen Button probiert - jetzt geht es. Aber vlt. habe ich auch zuvor noch einen anderen Fehler gemacht. Wer weiß, jetzt ist die richtige Zeit drin.

[smarthausen]

Hallo Alex und Roland,

schön wieder was vom dem Projekt zu hören! :-)

Schwein und Uhrwerk: wie kann ich die aktuellen (also die Änderungen im Dezember) vom Code bei mir hier austesten? Bin gespannt auf die Änderungen!

Viele Grüße

Richard

[higgx]

Also ich habe dazu den aktualisierten Code vom GitHub runtergeladen, das INO File in der Arduino IDE geöffnet. Den Aktor per USB Kabel mit dem Rechner verbunden. Den Sketch mit der Arduino IDE kompiliert und dann auf den Aktor geladen.

Brauchst Du es detaillierter?

Ich habe hier auch schon etwas ausführlicheres dazu gefunden, müsste aber suchen, um es zu finden.

Aber die Arduino IDE und die Konnekting Suite hast Du schon installiert, oder wie hast Du den Aktor zum ersten Mal mit dem Sketch geladen?

viele Grüße
Roland

[higgx]

Ah habe gerade in deinem Post ( smarthausen vom 05.06.) gesehen, dass Du ja schon weißt, wie es geht.
In dem Fall also nur den aktualierten Code vom GitHub und los geht's :-)

viele grüße

[higgx]

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

[tuxedo]

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.

[higgx]

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

[tuxedo]

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:

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