*gelöst* Markisensteuerung mit Aqara Sensoren

Begonnen von Terra, 22 Mai 2020, 17:06:49

Vorheriges Thema - Nächstes Thema

Terra

Hallo liebe fhem Gemeinde

Seit fast 5 Jahren habe ich einen raspberry mit fhem-Installation als Smart Home Zentrale. Als IODev benutze ich den HMLAN-Adapter von Homematic. Alle Geräte (Heizkörperthermostate, Wandthermostate, Fensterkontakte, Bewegungsmelder sowie diverse andere Sensoren und Aktoren) sind von Homematic. Zusätzlich befindet sich ein Jeelink USB-Stick für einige Technoline Thermometer, eine 1-wire Platine für Temperaturen am Heizkessel, sowie ein USB-Stick für die Speicherung der Log-Files und regelmäßigen fhem-Backups am raspberry.

Mein Dank an alle die mir damals im Forum mit Geduld und Ratschlägen geholfen haben.

Als neueste Errungenschaft habe ich eine Markise zur Beschattung der Terrasse. Auf fertige Fernsteuerungen oder Sensoren (wie somfy oder dgl.) habe ich bewusst verzichtet, da ich lieber Herr im eigenen Haus bin, statt über irgendeine Cloud eines Herstellers die Markise zu bedienen. Als Aktor benutze ich den Aufputz Homematic HM-LC-BL1-SM Rollladenaktor mit der Homematic Fernbedienung HM-RC-12. Alles war leicht über fhem einzurichten und funktioniert soweit tadellos.

Für den Fall einer Abwesenheit der Hausbewohner möchte ich aber noch zusätzliche Sicherheiten einbauen falls vergessen wurde die Markise einzufahren. Die An-/Abwesenheit wird schon über das structure Modul gesteuert.

Von den etablierten Herstellern gibt eine Menge zusätzlicher Sensoren wie Windsensor, Regensensor, Virbrationssensor, Sonnensensor u.s.w. die aber aus genannten Gründen nicht in Frage kommen. Als alternative habe ich die sehr preiswerten Aqara-Sensoren mit Zigbee-Protokoll in fhem integriert. Dazu brauchte ich ein entsprechendes IO-Device. Meine Wahl fiel auf den ConBeeII-Stick von Dresden Elektronik. Um mit dem Experiment nicht meinen System-raspberry zu belasten und möglicherweise zu zerschiessen, habe ich einen anderen raspberry mit einem Kartenimage von Dresden Elektronik versehen, den Stick eingesteckt und in Betrieb genommen. Alles klappte reibungslos.

Als Sensoren habe ich auf gut Glück den Xiaomi/Aqara Schock-/Vibrationsensor DJT11LM und den Aqara WaterLeakSensor SJCGQ11LM beschafft. Beide wurden vom ConBeeII-Stick auf Anhieb erkannt. Dann noch den ConBeeII-raspberry am System-raspberry als deConz angemeldet, die Device-ID der Sensoren ausgelesen und alles war gut.

Der WaterLeakSensor kennt nur das Reading water=0 oder water=1. Der Vibrationsensor hat verschiedene Readings. Ich brauche aber nur das Reading vibration. vibration=0 oder vibration=1.

Durch notify's werden die Sensoren der Markise gesteuert.

define Markise_Regenalarm notify RegenSensor:water:.1 set Markisenschalter pct 0
define Markise_Windalarm notify VibrationsSensor:vibration:.1 set Markisenschalter pct 0


Der Regensensor ist extrem empfindlich. Schon bei geringer Benetzung der Kontakte spricht er schon an. Das gleiche für den Vibrationssensor. Die sensitivity des Vibrationssensors soll sich noch anpassen lassen.

Bei starker Sonneneinstrahlung wird die Markise durch ein doif mit einem Thermometer, dass sich auf auf der Terrasse befindet, zur Beschattung ausgefahren.

define Markise_Temperaturalarm doif ([LaCrosse_2A:temperature] >30) (set Markisenschalter pct 100)

Alles funktioniert soweit und so gut. Das die Markise bei Regen komplett einfährt und das sie bei Hitze ausfährt ist ja ok.

Allerdings möchte ich die Markise, wenn sie auf größer als pct 90 ausgefahren ist, mit dem VibrationsSensor erst einmal auf pct 60 schliessen. Wenn dann der VibrationsSensor durch Windboen immer noch anspricht, zu pct 30 schliessen u.s.w.

Das kann man sicherlich mit entsprechenden notify's/doif's mit if/elsif/and/or Regeln machen. Soweit bin ich aber leider noch nicht. Seit 3 Wochen scheitere ich bei allen Bemühungen eine funktionierende Syntax für den VibrationsSensor für meine Zwecke zu schreiben. Mittlerweile habe ich alle FHEM-WIKI Seiten zu doif und notify durch. Ich komme einfach nicht auf eine Lösung. Deshalb wende ich mich jetzt an das Forum um Hilfe und einen Lösungsansatz zu bekommen. Ich erwarte keine fertige Lösung, nur jemand müsste mich in die richtige Richtung schubsen.

Vielen Dank fürs Lesen und Anteilnahme

Hier noch die Internals, Readings und Attributes
Xiaomi/Aqara Schock-/Vibrationsensor DJT11LM:
------------------------------------------------
Internals
----------------------------------------------
CFGFN
DEF sensor 6 IODev=deCONZ
FUUID 5ec04640-f33f-6cfc-12e4-aebb2d9e6f645768
FVERSION 31_HUEDevice.pm:0.218370/2020-05-02
ID S6
INTERVAL
IODev deCONZ
NAME VibrationsSensor
NR 675
STATEInitialized
TYPE HUEDevice
lastupdated 2020-05-17 08:26:41
lastupdated_local 2020-05-17 10:26:41
manufacturername LUMI
modelid lumi.vibration.aq1
name VibrationsSensor
on 1
reachable 1
sensitivity 11
sensitivitymax 21
swversion 20180130
type ZHAVibration
uniqueid 00:15:8d:00:04:83:5e:90-01-0101
--------------------------------------------
Readings
--------------------------------------------
battery 100
2020-05-17 10:57:44 batteryPercent 100
2020-05-17 10:57:44 orientation 0,-1,89
2020-05-17 10:47:30 reachable 1
2020-05-17 10:57:44 temperature 28
2020-05-17 10:57:44 tiltangle 177
2020-05-17 10:47:30 vibration 0
2020-05-17 10:47:30 vibrationstrength 38
-------------------------------------------
Attributes
-------------------------------------------
IODev deCONZ
event-on-change-reading vibration
genericDeviceType security
icon hue2019_devicesMotionSensor
model lumi.vibration.aq1
room Markise
stateFormat vibration
-------------------------------------------

Otto123

Hi,

ich habe nicht verstanden wo Dein Problem liegt und Du Hilfe brauchst.
Nur das fällt mir auf:
notify VibrationsSensor

name Vibrationssensor

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Terra

#2
Moin Otto,
der Name aus den Internals (Vibrationsensor) ist jetzt korrekterweise VibrationsSensor. Hatte ihn gestern geändert, aber die Internals vorher schon mit dem falschen Namen herauskopiert. >:(

Mein Problem ist einfach das ich keinen Ansatz finde durch ein doif oder notify die Markise in Schritten einfahren kann. Der VibrationsSensor befindet sich am Ende der Markise im Gehäuse und ist etwa 3,5x3,5 cm groß. Bei 4m Ausfall schüttelt es die Markise bei entsprechendem Wind schon heftig.

Beispiel: Die Markise ist auf pct 100 ausgefahren d.h. langer Hebelarm. Jetzt kommt Wind auf und rüttelt an der Markise und bringt sie ins Schwingen. Dann löst der  VibrationsSensor aus und fährt sie auf pct 60. Wenn das reicht, ist alles ok. Sollte es nicht reichen und der Wind immer noch an der Markise rüttelt, löst der VibrationsSensor wieder aus und schliesst die Markise auf pct 30 oder was immer man möchte. Das Reading vibration wechselt in ca. 60 sek. nach Auslösung von 1 auf 0
Mit meinem notify:
define Markise_Windalarm notify VibrationsSensor:vibration:.1 set Markisenschalter pct 0
klappt das ja auch schon. Nur fährt sie dann auf pct 0 ein. Das möchte ich nicht, da die Markise ja zur Beschattung der Terrasse / Wohnzimmer bei hohen Temperaturen dienen soll. Das Ganze ist ja auch nur gedacht für den Fall das niemand Zuhause ist.

Gruß, Ludwig

Otto123

Hallo Ludwig,

Und jedesmal einfach relativ fahren, also set Markisenschalter down 30

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

flummy1978

Hallöchen,

ich weiss nicht inwiefern Du Dich mit Perl auseinander gesetzt hast, aber sollte hier die Erfahrung bei null liegen, kannst Du nur mehrere DOIFs anlegen, die dann auf die verschiedenen Umstände (Vibration in Abhängigkeit von pct ). Da ich aber mich selbst so gut wie gar nicht mit DOIFs auskenne, wäre ich da eher Verwirrung als Hilfe.

Wo ich Dir helfen kann ist ein Gedankenganz, den Du für Deine Umstände anpassen musst....
Ich würde es mit einem Faktor (reading) lösen, das Du einmalig setzt und es entsprechend in die Berechnung mit eingeht. Angenommen Deine Markise muss bei einem Wer von 1 einfahren das wären dann 100 % Vibrationsstärke die zum Einfahren nötig sind also:

Faktor * 1.1 * (pct) 100 = Vibrationswert der zum Einfahren in die nächste Stufe nötig ist
(Faktor * 1.6) * (pct) 70 = Vibrationswert der zum Einfahren in die nächste Stufe nötig ist
(Faktor * 3.7) * (pct) 30 =  Vibrationswert der zum Einfahren in die nächste Stufe nötig ist

Als Beispiel wäre das dann ein Faktor 3:
3 * 1.1 * 100 = 330
3 *1.6 * 70 = 336
3 *3,7* 30 = 333

Nun müsstest Du Faktor und Anpassung so einsetzen, dass am Ende immer ein eindeutiger Wert herausommt (z.B. > 330 ) Dann kannst Du anhand diesem dann weiter vorgehen:
Prüfe auf Wert > 330 => tritt dieser ein => bestimme die Position (100 oder <100 und >70 oder <70 und >30 ) => Bestimmte anhand der aktuellen Position die nächst niedrigere => Die von Otto vorgeschlagene relativ Fahrt ist noch besser an der Stelle

Wenn Du nun feststellst, dass das viel zu früh ist wie die Markise rein fährt, nimmst Du als Faktor 4 oder streckst die Bestimmungszahlen (1,1 1,6 und 3,7) für die prozentuellen Anteile ein wenig.... oder oder ....

Zur Umsetzung da bewusst mal nichts vor, weil ich es direkt per if / elsif / ellse Abfragen in Perl lösen würde (Einfach so Laienhanft ::) weil ich DOIF einfach nicht kapiere und bisher ohne auskomme )

Aber vielleicht hilft der Gedankengang ja schonmal weiter :)

Viele Grüße
Andreas

Hollo

#5
Mal so als Gedankenanregung ohne vorheriges Testen (ich habe etwas Ähnliches zur Lautstärkesteuerung)...

Eine Funktion in der 99_myUtils anlegen:


sub
Windschutz()
{
# aktuellen %-Wert der Markise ermitteln
my $pct_old = ReadingsVal("Markisenschalter","pct","");
# mit Hilfe der Schrittweite neuen Wert ermitteln
my $pct_new = $pct_old - 30;
# kleiner 0 heisst ganz einfahren
if ($pct_new < 0) { $pct_new = 0 };
# Markise mit neuem Wert setzen
fhem ("set Markisenschalter pct $pct_new");
}


Dein Notify würde dann nicht mehr direkt den Wert setzen, sondern die Funktion aufrufen:
define Markise_Windalarm notify VibrationsSensor:vibration:.1 {Windschutz}
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Terra

@Otto,
@Andreas,
@Hollo,

Danke, dass ihr euch des Themas angenommen habt. Der Hinweis von Otto hat nicht funktioniert.
Und jedesmal einfach relativ fahren, also set Markisenschalter down 30 Was mit 'relativ' gemeint ist konnte ich nicht umsetzen.

Die Hinweise von Andreas habe ich nicht wirklich nachvollziehen können. Ich bin mittlerweile ziemlich unbedarft in diesen Dingen. Als ich vor ca. 5 Jahren mit allem anfing, habe ich mich sehr in das Thema fhem eingearbeitet. Seitdem habe ich nicht mehr viel gemacht und man verlernt so einiges.

Die Gedankenanregung von Hollo traf genau ins Schwarze. Es ist genau das was ich wollte. Es funktioniert perfekt. Den Wert von 30 habe ich in 25 geändert um die Markise in 25er Schritten einzufahren. Was ich jetzt noch machen muß ist die Einbindung des Anwesenheits Status. Die drei Sensoren sollen ja nur bei Abwesenheit der Hausbewohner die Kontrolle übernehmen. Wo kann/sollte ich den ZuHause Staus einbauen, in die sub in der 99_myUtils oder im Aufruf des notifys?

Vielen Dank an alle,

Gruß, Ludwig

Otto123

Hallo Ludwig,

perfekt das Du ein Lösung hast.

Noch zur Erklärung "relativ":
set Markisenschalter down 30
Im Gegensatz zu pct 30 wird mit down 30 nicht auf den Level 30% gefahren, sondern vom existierenden Punkt um 30% gefahren.
Also steht der Rollladen auf 100 -> down 30 -> steht er jetzt auf 70 -> dann wieder down 30 -> jetzt steht er auf 40 usw.

Gruß Otto
 
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Terra

Hallo Otto,

Habe alle Varianten von
define Markise_Windalarm notify VibrationsSensor:vibration:.1 set Markisenschalter down 30

ausprobiert. So wie es oben steht. Danach mit Klammern in allen Variationen. Es geht leider nicht. Die Version von Hollo ist die Einzige die funktioniert.

Wenn Du jetzt noch eine Idee hast, wie ich das notify
define Markise_Regenalarm notify RegenSensor:water:.1 set Markisenschalter pct 0
dahingehend ändern kann, dass das notify nur anspricht wenn niemand Zuhause ist. Das structure Modul ZuHause gibt den state "present oder "absent". Ich möchte, dass die Markise nur einfährt wenn niemand Zuhause ist. Habe schon alles mit notify laut FHEM-WIKI ausprobiert. Komme leider nicht klar.

Danke nochmal, Ludwig

Otto123

Ich will nicht auf meiner Idee rumreiten, weil die andere sicher viel besser ist. Aber funktioniert denn
set Markisenschalter down 30 in der FHEM Kommandozeile wie beschrieben? Oder gibt es Fehler.
Oder andersrum, funktioniert die andere Richtung?
set Markisenschalter up 30

Dein anders notify musst Du mit einer Bedingung im Ausführungsteil ausstatten, entweder FHEM IF oder Perl if:
Ungetestet!
IF ([ZuHause:state] eq "absent") (set Markisenschalter pct 0)
{if (ReadingsVal('ZuHause','state',error) eq "absent") {fhem('set Markisenschalter pct 0')}}

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Terra

Moin Otto,

Die Eingabe in der FHEM-Kommandozeile set Markisenschalter up 30
erzeugt die Fehlermeldung off requires no parameters
Umgekehrt mit down ebenfalls.

Das notify für die Abfrage "absent" / "present" funktioniert einwandfrei. Ich hatte einen Denkfehler in der Syntax mit >Suchmuster< und >Ausführungsteil<. Jetzt klappt auch das. :)  Dank Dir und Hollo bin ich jetzt zufrieden. Als letztes versuch ich nur noch eine Meldung mit dem Modul sendemail zu generieren, die mir meldet wann die Markise bei Abwesenheit ein-/ausfährt. Bei z.B. Fensterstatus bei Abwesenheit klappt das wunderbar Das ist aber eine andere Geschichte. Der WAF ist im Moment nicht mehr so groß  ;)

Gruß, Ludwig

Otto123

Hallo Ludwig,

damit ich das verstehe, kannst Du mal bitte die Ausgabe posten
list Markisenschalter

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Terra

Hallo Otto,

aber gerne,

Internals:
   DEF        67E4F3
   FUUID      5ea2d1df-f33f-6cfc-3efc-8e83fde0d9f461f3
   HMLAN1_MSGCNT 54
   HMLAN1_RAWMSG E67E4F3,0000,2E6A8438,FF,FFBF,5DA41067E4F332241A06010000
   HMLAN1_RSSI -65
   HMLAN1_TIME 2020-05-25 11:09:38
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     54
   NAME       Markisenschalter
   NOTIFYDEV  global
   NR         400
   NTFY_ORDER 50-Markisenschalter
   STATE      up
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:5D - t:10 s:67E4F3 d:32241A 06010000
   protLastRcv 2020-05-25 11:09:38
   protRcv    53 last_at:2020-05-25 11:09:38
   protResnd  1 last_at:2020-05-25 00:54:56
   protSnd    54 last_at:2020-05-25 11:09:38
   protState  CMDs_done
   rssi_HMLAN1 cnt:27 min:-83 max:-67 avg:-72.51 lst:-69
   rssi_at_HMLAN1 cnt:54 min:-85 max:-58 avg:-68.77 lst:-65
   READINGS:
     2020-05-25 11:09:33   CommandAccepted yes
     2020-04-29 17:18:47   D-firmware      2.11
     2020-04-29 17:18:47   D-serialNr      OEQ2478938
     2020-04-29 13:52:23   PairedTo        0x32241A
     2020-04-27 23:43:11   R-driveDown     28 s
     2020-04-28 20:17:30   R-driveTurn     1 s
     2020-04-27 23:43:11   R-driveUp       28 s
     2020-04-27 23:43:10   R-pairCentral   0x32241A
     2020-04-28 11:06:11   R-self01-lgActionType jmpToTarget
     2020-04-28 11:06:11   R-self01-lgOnLevel 100 %
     2020-04-28 11:06:11   R-self01-shActionType jmpToTarget
     2020-04-28 11:06:11   R-self01-shOnLevel 100 %
     2020-04-28 11:06:15   R-self02-lgActionType jmpToTarget
     2020-04-28 11:06:15   R-self02-lgOnLevel 100 %
     2020-04-28 11:06:15   R-self02-shActionType jmpToTarget
     2020-04-28 11:06:15   R-self02-shOnLevel 100 %
     2020-04-27 23:43:11   R-sign          off
     2020-04-29 13:52:23   RegL_00.        00:00 02:01 0A:32 0B:24 0C:1A 15:FF 18:00
     2020-04-29 13:52:24   RegL_01.        00:00 08:00 09:00 0A:00 0B:01 0C:18 0D:01 0E:18 0F:0A 10:00 30:06 56:00 57:24
     2020-05-25 11:09:38   commState       CMDs_done
     2020-05-25 11:09:38   deviceMsg       off (to HMLAN1)
     2020-05-25 11:09:38   level           0
     2020-05-25 11:09:38   motor           stop:off
     2020-05-25 11:09:38   pct             0
     2020-05-25 11:09:38   recentStateType info
     2020-05-25 11:09:38   state           off
     2020-05-25 11:09:38   timedOn         off
   helper:
     HM_CMDNR   93
     cSnd       1132241A67E4F3020100,1132241A67E4F3020100
     dlvlCmd    ++A01132241A67E4F3020100
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no
       cmdKey     :1:1:0::0005:01
       TmplCmds:
       cmdList:
         assignHmKey:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename:newName
         down:[-changeValue-] [-ontime-] [-ramptime-] ...
         eventL:-peer- -cond-
         eventS:-peer- -cond-
         fwUpdate:-filename- -bootTime- ...
         getConfig:
         getDevInfo:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         getSerial:
         getVersion:
         inhibit:[on|off]
         off:
         on:
         pair:
         pct:[-value-] ... [-ontime-]
         peerBulk:-peer1,peer2,...- [set|unset]
         peerIODev:[IO] -btn- [set|unset]... not for future use
         press:[long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
         raw:data ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         reset:
         sign:[on|off]
         statusRequest:
         stop:
         toggle:
         toggleDir:
         tplDel:tmplt
         unpair:
         up:[-changeValue-] [-ontime-] [-ramptime-] ...
     dir:
       cur        stop
       rct        down
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +67E4F3,00,00,00
       nextSend   1590397778.30425
       prefIO     
       rxt        0
       vccu       
       p:
         67E4F3
         00
         00
         00
     mRssi:
       mNo        5D
       io:
         HMLAN1:
           -61
           -61
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMLAN1
       flg        A
       ts         1590397778.21767
       ack:
         HASH(0x34c5fc0)
         5D800232241A67E4F300
     rssi:
       HMLAN1:
         avg        -72.5185185185185
         cnt        27
         lst        -69
         max        -67
         min        -83
       at_HMLAN1:
         avg        -68.7777777777778
         cnt        54
         lst        -65
         max        -58
         min        -85
     tmpl:
Attributes:
   IODev      HMLAN1
   alexaName  Markise
   autoReadReg 4_reqStatus
   devStateIcon up:fts_sunblind_0@green 2\d.*:fts_sunblind_20@red 1\d.*:fts_sunblind_10@red 3\d.*:fts_sunblind_30@red 4\d.*:fts_sunblind_40@red 5\d.*:fts_sunblind_50@red 6\d.*:fts_sunblind_60@red 7\d.*:fts_sunblind_70@red 8\d.*:fts_sunblind_80@red 9\d.*:fts_sunblind_90@red down:fts_sunblind_100@red
   eventMap   on:down off:up
   expert     2_defReg+raw
   firmware   2.11
   genericDeviceType blind
   group      MarkiseSensoren
   icon       fts_sunblind@yellow
   model      HM-LC-BL1-SM
   peerIDs    00000000,
   room       9_Markise
   serialNr   OEQ2478938
   subType    blindActuator
   webCmd     pct:toggleDir:on:off:up:down:stop

Otto123

#13
Du Schlingel :)
eventMap   on:down off:up
Dachte ich mir so etwas.

Damit hast Du Dir genau diese Möglichkeit der relativen Steuerung selbst genommen.
Und auch noch damit die Logik gedreht!
on bedeutet "Licht an" - also beim Rolladen hoch (bei Dir runter)
off bedeutet "Licht aus" - also beim Rolladen runter (bei Dir hoch)

Ohne weitere Angabe mach up/down übrigens 10 % - also kleine Schritte.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Hollo

Zitat von: Otto123 am 25 Mai 2020, 12:47:28
...
on bedeutet "Licht an" - also beim Rolladen hoch (bei Dir runter)
off bedeutet "Licht aus" - also beim Rolladen runter (bei Dir hoch)
...
Sehr schöne Eselsbrücke  ;D

@Terra
Freut mich, dass wir helfen konnten und Du nun eine funktionierende Lösung hast.
Evtl. kannst Du den entsprechenden Code am Ende nochmal zusammenfassen und dann vor den Thread-Titel noch ein [gelöst] setzen.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"