Rademacher DuoFern USB Stick

Begonnen von Telekatz, 16 August 2015, 16:19:46

Vorheriges Thema - Nächstes Thema

amenomade

50% = 50% der gesamten Fahrzeit (inkl. Belüftung => komplett zu)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

tomcat.x

... oder anders gesagt: Wenn 50% = halb zu im sichtbaren Bereich sein sollten, wären 100% ganz unten, aber mit geöffneten Schlitzen. Mehr ginge dann nicht.

Dazu kommt noch, dass sich meines Wissens bei den Gurtwicklern Abweichungen durch die Dicke des Gurts ergeben, da sich die % Angaben auf Umdrehungen beziehen.
FHEM: 6.1 auf Raspi 3, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

Pfriemler

#842
Prozentangaben bei Rolladenaktoren beziehen sich immer auf die Position der Welle (Anzahl der Umdrehungen) bzw auf die Position des Aufwickelrades im Gurtwickler. Bei extern gesteuerten Rolladenmotoren ist das über die Laufzeit der Motoren zusätzlich ungenau.
Ein aufgewickelter Rolladen hat die größte lineare Geschwindigkeit bezogen auf die Rotationsgeschwindigkeit der Rolladenwelle. Wird die Welle mit konstanter Geschwindigkeit gedreht, ist der Rolladen also oben schnell und unten langsam.
Bei Gurtwicklern kommt dazu noch der Einfluss des Gurtes: Auch hier bewegt sich der Gurt am schnellsten, wenn der Rolladen oben ist. Und als dritte Punkt kommt die Gurtrolle an der Rolladenwelle hinzu.
Alles sorgt also dafür, dass sich die Geschwindigkeit je nach Position ändert oder umgekehrt die Position bezogen auf die Laufzeit stark nichtlinear ist. Ein sichtbarer Behang von 50% an der Balkontür entspricht hier beispielsweise einer Motorposition von 26%. Bei 50% ist der Rolladen dann schon zu mehr als 75% geschlossen.

Feinjustieren könnte man das mit einer "Übersetzungskurve", also einer Umrechnung von Motorposition zu tatsächlicher Position. Das ließe sich mit einer Regression und der Angabe der Motorpositionen bezogen auf die tatsächliche Rolladenposition schon einrichten. Wenn Telekatz mal ganz viel Langeweile hat, wird er das sicher gern einrichten ...  ;D ;D 8)

Bis dahin werden wir wohl mit der Ungenauigkeit leben müssen...  ;)
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

amenomade

Zitat von: Pfriemler am 02 August 2019, 11:06:42

Feinjustieren könnte man das mit einer "Übersetzungskurve", also einer Umrechnung von Motorposition zu tatsächlicher Position. Das ließe sich mit einer Regression und der Angabe der Motorpositionen bezogen auf die tatsächliche Rolladenposition schon einrichten. Wenn Telekatz mal ganz viel Langeweile hat, wird er das sicher gern einrichten ...  ;D ;D 8)

Dann müsste man auch bei Rollladen die Belüftungsposition mitberücksichtigen. Wenn 50% mitte des Fensters sein soll, dann wäre logischerweise 100% wenn der untere Rand der Jalousie ganz unten ist... aber die Schlitze noch offen sind. Dann müsste die Position über 100% gehen können, was andere Einflüsse hat...

Deswegen lebe ich gerne mit der Ungenauigkeit. Wer nutzt sowieso genau eine Prozentangabe? Meine Rollos sind entweder offen, oder zu, oder in Belüftungsposition oder in Beschattungsposition. Das sind vordefinierte Positionen, die ich nur einmal nach Bedarf eingestellt habe. Danach sind mir 37% oder 57,25% eigentlich egal.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Dondo

Hallo,

betreibe hier sechs Duofern Rollladenmotoren, die zu 99% ohne Schluckauf laufen, sodass ich das FHEM Log nur sporadisch kontrolliere.

Jetzt sehe ich zum ersten mal dies:

2019.08.06 07:11:03 3: DUOFERN unknown msg: 810100BB00000000000000000000006FAFFE490DD000
2019.08.06 07:11:03 3: Rademacher: Unknown code 120107070000000000000000000003490DD06FAFFE02, help me!


Gibt es dafür eine Erklärung?

Grüße aus G'heim...
-Dondo

amenomade

Mögliche Erklärung: ein Nachbar benutzt auch DuoFern
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Dondo

So etwas Ähnliches habe ich auch schon vermutet, aber dann ist die Senderreichweite beachtlich.  Gab es da nicht eine Möglichkeit in FHEM, Geräte gezielt zu ignorieren?  Hab' da irgendwas im Hinterkopf...  :-\

amenomade

Zitat von: Dondo am 10 August 2019, 13:32:49
So etwas Ähnliches habe ich auch schon vermutet, aber dann ist die Senderreichweite beachtlich.  Gab es da nicht eine Möglichkeit in FHEM, Geräte gezielt zu ignorieren?  Hab' da irgendwas im Hinterkopf...  :-\
Ja, das gibt es. Eine Suche im Forum bringt z.B. (u.a.)(gefühlt 1000mal schon erwähnt) https://forum.fhem.de/index.php?topic=54903.0
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Dondo

Zitat von: amenomade am 10 August 2019, 13:37:07
Ja, das gibt es. Eine Suche im Forum bringt z.B. ...

Ja, genau!  Allerbesten Dank für den Link!!!!  Wollte zuerst von einem Erleuchteten verifiziert bekommen, dass Fremdgeräte die Verursacher sein könnten.

Alfred0738

Hallo Telekatz,

Seit kurzem habe ich einen ILFS Rohrmotor in Betrieb, den ich allerdings nicht für einen Rolladen benutze, sondern für ein einfaches Rollo.

Er lässt sich dank Deiner tollen Module perfekt steuern, daher auch von mir ein riesengroßes Dankeschön  dafür an Dich :) :) :)

Dieser erste DuoFern Antrieb ersetzt bei mir den ersten von 4 Siro Rolloantrieben. Die anderen 3 werden nach dem nun erfolgreichem Test in Kürze folgen.

Ich habe auserdem 3 Homematic Fensteröffner in Betrieb, die natürlich automatisch (gesteuert mittels eines CO2 Sensors) arbeiten.

Wenn eins der Fenster auf Kipp stehen würde und das dazu gehörende Rollo aus der obersten Position nach unten fahren würde, würde es auf dem Fenster aufsetzen, was zwar nicht so dramatisch wie bei einem Rolladen, aber trotzdem weniger schön wäre.

Aus diesem Grund fahre ich die Rollos immer nur in ihre Favoritenpositionen (in diesem Fall mit set Rollo_Schlafzimmer position 7) die so gewählt sind, das sie etwas unter der Oberkante der geöffneten Fenster liegen. Schöner wäre es natürlich wenn es zusätzlich zu sunPosition/sunMode und ventilatingPosition/ventilatingMode auch ein favoritPosition/favoritMode geben würde.

Es wäre super, wenn Du das bei Gelegenheit mal mit einbauen könntest, oder sind sunMode/ventilatingMode durch die Hardware vorgegeben und ein Erweitern nicht möglich?

Ich werde sunMode und ventilatingMode benutzen, habe bisher aber erstmal nur die entsprechenden Positionen gesetzt.

Aufgefallen ist mir dabei zum einen, das es zwar ein sunAutomatic [on]/[off], aber kein ventilatingAutomatic [on]/[off] gibt. Wird letzterer nicht gebraucht?

Des weiteren viel mir auf, das wenn ich das Rollo mittels des down Befehls aus einer Position oberhalb der ventilatingPosition herunterfahren will, das Rollo immer an der ventilatingPosition stoppt. Nach einem weiteren down Befehl fährt es dann weiter in Richtung untere Endlage.

Das ganze passiert unabhängig davon ob ventilatingMode oder manualMode auf [on] oder [off] stehen.

Bug oder Feature?

Ein set Rollo position X stoppt nicht in der ventilatingPosition wenn X > ventilatingPosition ist.

Ein setreading Rollo ventilatingAutomatic on/off ändert wie eigentlich erwartet auch nichts daran.  8)
Wobei hingegen ein attr Rollo eventMap /position 100:down/ zwar das Problem umgeht, aber wohl nicht wirklich im Sinne des Erfinders (sprich Dir) ist.  ;)


LG und noch einen schönen Restfeiertag, Alfred
3 Zimmer Wohnung mit MAX! via FHEM/MAX!cubeCUL
Homematic/Winmatic Fensteröffner, CO2 Minnisensor
Rollos mit Rademacher ILMS 6/28 via FHEM/USB-DuoFernStick/Handsender.
Automatische Pflanzenbewässerung mit WH51/DP100 via SIGNALduino und SONOFF 4CHPRO via MQTT2

Alfred0738

#850
So,  sunAutomatic/sunMode/sunPosition funktionieren ja so:

Wenn sunAutomatic auf [on] steht, fährtder Antrieb bei set <device> sunMode on in die sunPosition und bei set <device> sunMode off in die obere Endstellung.
Bei sunAutomatic auf [off], werden die set <device> sunMode on/off Befehle ignoriert.

Außerdem fährt der Antrieb zur Bestätigung bei jedem set <device> sunAutomatic on/off zur Bestätigung kurz hoch runter.

[/i]Bei set <device> ventilatingMode on/off, fährt der Antrieb aber nicht in die ventilatingPosition, oder die obere Endlage, sondern fährt wie bei set <device> sunAutomatic on/off nur kurz hoch runter.

Deshalb vermute ich mal, das ventilatingMode in Wirklichkeit ventilatingAutomatic ist, und das richtige ventilatingMode dafür fehlt.

sunMode on kann ich so wie es ist benutzen.
sunMode off leider nicht, weil es in die obere Endstellung fährt, wo ich meine Rollos jedoch nur hin fahre, wenn der Fensterputzer kommt.

Ein attr eventMap /position x:sunMode off/ bügelt das aber aus.  8)

Meine Rollos heißen Rollo_WZ_Strasse, Rollo_WZ_Wiese, Rollo_Schlafzimmer und Rollo_Buero.
Ich habe es noch nicht probiert, aber gehe mal davon aus, das ein set Type=DUOFERN:FILTER=SUBTYPE=(Rollo).* sunMode off dann alle Rollos in die jeweilige mittels eventMap gesetzt Position (meine Favoritenpositionen) fährt.

sunMode off wird dann zwar unabhängig davon ausgeführt ob sunAutomatic auf [on] oder [off] steht, was aber sowieso egal ist, weil es nur wichtig ist das sunMode on , den Status von sunAutomatic [on]/[off] berücksichtigt!

So könnte ich mir zwar auch mittels eventMap ein favoriteMode on/off zusammen basteln, von dem das favoriteMode on dann aber leider kein favoriteAutomatic [on]/[off] berücksichtigt.
3 Zimmer Wohnung mit MAX! via FHEM/MAX!cubeCUL
Homematic/Winmatic Fensteröffner, CO2 Minnisensor
Rollos mit Rademacher ILMS 6/28 via FHEM/USB-DuoFernStick/Handsender.
Automatische Pflanzenbewässerung mit WH51/DP100 via SIGNALduino und SONOFF 4CHPRO via MQTT2

Alfred0738

Ah, ich habe gerade gelernt das set Type=DUOFERN:FILTER=SUBTYPE=(Rollo).* sunMode on/off nicht funktioniert und ich statt dessen set Type=DUOFERN:FILTER=SUBTYPE=(Rohrmotor).* sunMode on/off oder set Rollo.* sunMode on/off für alle Rollos, oder set Rollo_Buero,Rollo_WZ_Strasse sunMode on/off für eine Kombination bestimmter Rollos benutzen muss. 8)
3 Zimmer Wohnung mit MAX! via FHEM/MAX!cubeCUL
Homematic/Winmatic Fensteröffner, CO2 Minnisensor
Rollos mit Rademacher ILMS 6/28 via FHEM/USB-DuoFernStick/Handsender.
Automatische Pflanzenbewässerung mit WH51/DP100 via SIGNALduino und SONOFF 4CHPRO via MQTT2

Telekatz

Alle Befehle, die das Modul zur Verfügung stellt, sind so von der Hardware vorgegeben. Für das Umsetzen der Befehle unter Berücksichtigung aller Automatikfunktionen ist allein der Antrieb verantwortlich.

Zur Funktion der Lüftungsposition zitiere ich mal aus der HomePilot Anleitung:
ZitatDie Lüftungsposition kann bei Bedarf eingeschaltet werden. Das hat zur Folge, dass jeder manuelle und automatische Schließbefehl in der gewählten Position endet. Manuell kann der Rollladen durch einen weiteren Schließbefehl komplett geschlossen werden. Wird in einer Szene 100% als Ziel gewählt, wird die Lüftungsposition nicht berücksichtig.
Einen ventilatingAutomatic Befehl gibt es nicht.

Alfred0738

Zitat von: Telekatz am 04 Oktober 2019, 17:44:12
Alle Befehle, die das Modul zur Verfügung stellt, sind so von der Hardware vorgegeben. Für das Umsetzen der Befehle unter Berücksichtigung aller Automatikfunktionen ist allein der Antrieb verantwortlich.

Zur Funktion der Lüftungsposition zitiere ich mal aus der HomePilot Anleitung:Einen ventilatingAutomatic Befehl gibt es nicht.

Hmm, also manchmal ist es echt komisch.
Ganz im Ernst! Ich habe gestern lediglich die ventilatingPosition gesetzt.
Danach hat der Antrieb bei jeder Abwärtsfährt dort gehalten, egal ob ventilatingMode auf [on] oder [off] war!

Nach Deinem Beitrag eben gerade habe ich es nochmal versucht, und auf einmal hält der Antrieb bei ventilatingMode [off] nicht mehr in der ventilatingPosition [GRÜBEL !?!]

Und mit dem Wunsch nach favoritePosition/favoriteMode/favoriteAutomatic hat es sich eh auch erledigt, weil ich die Favoritenposition eh immer anfahre, und daher gar kein favoriteAutomatic brauche [LOL]

Und das favoritePosition/favoriteMode erledigt dann ein schlichtes eventMap /position x:fav/  8)

Aber trotzdem Danke, das Du Dich mit meinen abstrusen Gedanken befasst hast! [TWO THUMBS UP]
3 Zimmer Wohnung mit MAX! via FHEM/MAX!cubeCUL
Homematic/Winmatic Fensteröffner, CO2 Minnisensor
Rollos mit Rademacher ILMS 6/28 via FHEM/USB-DuoFernStick/Handsender.
Automatische Pflanzenbewässerung mit WH51/DP100 via SIGNALduino und SONOFF 4CHPRO via MQTT2

Alfred0738

Aber wo ich gerade dabei bin.

Kann man an irgend etwas verlässlich erkennen, das ein Antrieb nach dem Senden eines Befehls gestartet ist, sprich er den Befehl empfangen hat, oder nicht?

Und kann man bei einem Neustart (z.B. nach einem Stromausfall) irgendwie abfragen mit wievielen Aktoren der DuoFernStick gepaired ist, um dann, falls es einer oder mehrere zu wenig ist/sind alle neu zu pairen?

Es gibt ja das Internal pair. Jedoch existiert dieses ja nicht immer.
Nach einem set myDuoFernStick pair existiert es, jedoch steht es in meinem Fall immer auf 1 egal ob es mit meinem zur Zeit einzigen Rolloantrieb gepaired ist, oder nicht.   :'(
3 Zimmer Wohnung mit MAX! via FHEM/MAX!cubeCUL
Homematic/Winmatic Fensteröffner, CO2 Minnisensor
Rollos mit Rademacher ILMS 6/28 via FHEM/USB-DuoFernStick/Handsender.
Automatische Pflanzenbewässerung mit WH51/DP100 via SIGNALduino und SONOFF 4CHPRO via MQTT2