SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

Begonnen von timtom, 20 Mai 2017, 14:35:24

Vorheriges Thema - Nächstes Thema

hugo

Hallo habeIchVergessen,
klar mache ich das.
List vom Somfy

Internals:
   ADDRESS    36B995
   CFGFN
   DEF        36B995 A3 01F0
   IODev      RC_SIGNALduino
   LASTInputDev RC_SIGNALduino
   MSGCNT     24
   NAME       SOMFY_36B995
   NR         40
   RC_SIGNALduino_DMSG YsABBBB9A1348DBB
   RC_SIGNALduino_MSGCNT 24
   RC_SIGNALduino_RAWMSG MC;LL=-1245;LH=1337;SL=-597;SH=665;D=ABBBB9A1348DBB;C=640;L=56;R=253;
   RC_SIGNALduino_RSSI -75.5
   RC_SIGNALduino_TIME 2017-08-27 14:46:21
   STATE      closed
   TYPE       SOMFY
   move       on
   CODE:
     1          36B995
   READINGS:
     2017-08-27 12:58:05   enc_key         AC
     2017-08-27 12:58:05   exact           200
     2017-08-27 14:46:21   parsestate      stop
     2017-08-27 12:58:05   position        200
     2017-08-27 12:58:05   rolling_code    01F9
     2017-08-27 12:58:05   state           closed
Attributes:
   IODev      RC_SIGNALduino
   comment    Markiese
   room       SOMFY


List vom Siganlduino

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   DMSG       u63ACEFEDF461D8EE
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   FD         11
   LASTDMSG   u63ACEFEDF461D8EE
   MSGCNT     51
   NAME       RC_SIGNALduino
   NR         30
   PARTIAL
   RAWMSG     MU;P0=1344;P1=-1228;P2=690;P3=-587;D=0101230321232301232323232323012301232323230103232123032323212323012303232123230123230;CP=2;R=245;
   RSSI       -79.5
   STATE      opened
   TIME       1503839413
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages 2017-08-27 15:17:13-MU;P0=-118;P1=204;P2=375;P3=-175;P4=120;P5=-339;D=01023434515131345131515132515234510131313;CP=1;R=197;#2017-08-27 15:22:10-MU;P1=243;P2=-164;P4=-117;P5=-404;P6=158;P7=119;D=0121415156270647010621005756272751215126514121;CP=1;R=196;#2017-08-27 15:23:08-MU;P0=-120;P1=258;P2=-176;P3=-312;P4=189;P6=372;P7=120;D=012134243134313634343126313407243427343734;CP=4;R=196;#2017-08-27 15:29:13-MU;P0=556;P1=120;P2=-298;P3=215;P5=-118;P6=-483;D=3532323632323235061636321232323632323532321235;CP=3;R=198;#2017-08-27 15:29:28-MU;P0=-140;P2=468;P3=-289;P4=163;P5=119;P6=-414;P7=245;D=0023435356704356405673407040567043434343704;CP=4;R=196;#2017-08-27 15:32:22-MU;P0=167;P1=-346;P2=1000;P3=117;P4=-159;P5=262;P6=-116;D=0121345101062631010151045431515101040134;CP=0;R=196;#2017-08-27 15:43:02-MU;P0=215;P1=-162;P2=146;P3=-330;P5=-116;P6=412;P7=-537;D=0123212563230525232761070521032127212501;CP=2;R=196;#2017-08-27 15:53:09-MU;P0=117;P1=-120;P2=-340;P3=476;P4=-174;P5=204;P6=-516;D=0102343256510252525154345254545456545251;CP=5;R=195;#2017-08-27 15:57:03-MU;P0=-247;P1=139;P2=-117;P3=202;P4=-414;P5=330;P7=-170;D=0123430343212501434303430171752541710103437;CP=1;R=197;#2017-08-27 16:05:43-MU;P0=-424;P1=-196;P2=222;P3=-291;P4=140;P5=-118;D=012345214343232321432345202540232045212325;CP=2;R=197;#2017-08-27 16:11:08-MU;P0=-500;P1=380;P2=-177;P3=240;P4=157;P6=-116;D=012324242423230423010301246124036464236124;CP=4;R=196;#2017-08-27 16:12:45-MU;P0=-161;P1=173;P2=-119;P3=284;P4=-302;P5=119;P7=432;D=012123214541054343414345414345474121054121;CP=1;R=196;#2017-08-27 16:28:00-MU;P0=243;P1=-117;P3=-206;P4=160;P5=-476;P6=116;P7=-305;D=01030303430501036307070703030767010707636701;CP=0;R=194;#2017-08-27 16:34:03-MU;P0=-453;P1=-123;P2=150;P4=-215;P5=231;P6=-338;D=0121245624515421215124242620502021512656212;CP=2;R=197;#2017-08-27 16:46:16-MU;P0=-124;P1=170;P2=-255;P3=116;P5=-449;P6=336;D=01232321215601212351230121212626210103535;CP=1;R=196;#2017-08-27 16:49:46-MU;P0=652;P1=-309;P2=186;P3=-160;P4=422;P5=-118;P7=120;D=0123452321452105232141210173737171252173;CP=2;R=196;#2017-08-27 16:52:00-MU;P1=-376;P2=145;P3=243;P4=-164;P6=-116;D=0121213426312121012626212131362136212624242124213131212104;CP=2;R=196;#2017-08-27 17:01:26-MU;P0=-627;P1=179;P2=433;P3=-267;P5=-170;P6=307;P7=-438;D=012315136567632711251021106025171515151715;CP=1;R=195;#2017-08-27 17:27:44-MU;P0=222;P1=136;P2=-137;P4=-373;P6=666;P7=-208;D=411670717011401026704171714011412021402140;CP=1;R=195;#2017-08-27 17:32:07-MU;P0=-391;P1=716;P2=-135;P3=238;P5=159;P6=118;D=01232523262323050603260325232601260605232;CP=3;R=196;#2017-08-27 17:44:32-MU;P0=159;P1=-158;P2=-374;P3=270;P5=-118;P6=428;P7=116;D=0102023232020102050202613275027201310272;CP=0;R=198;#2017-08-27 17:45:19-MU;P0=116;P1=215;P2=-170;P3=-119;P5=-365;P7=512;D=012101312121510151212131512751510121005137;CP=1;R=197;#2017-08-27 18:00:46-MU;P0=219;P1=-410;P3=553;P4=-226;P5=-601;P6=-117;D=01010101343105060401013604050105063404010;CP=0;R=197;#2017-08-27 18:09:14-MU;P1=189;P2=-192;P4=-117;P5=119;P6=-690;P7=556;D=0121454545054145452161672145412141214101;CP=5;R=193;#2017-08-27 18:16:22-MU;P0=-428;P1=161;P2=-315;P3=117;P4=-132;P5=712;P7=275;D=01234141254147072147472107234107214143414;CP=1;R=195;
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-08-27 18:33:58   ping            OK
     2017-08-27 12:52:54   state           opened
     2017-08-27 12:52:54   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     8
     9
Attributes:
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    5
Raspi 3 mit CUL HM-MOD-UART; nanoCUL
Homematic: HM-SEC-SCo 5x;HM-LC-SW1-BA-PCB 3x;HM-Dis-EP-WM55; HM-LC-SW4-PCB; ARLO;
Somfy RTS Rollo 14x; Alexa; GardenaSmartDevice; Stromzähler(GPIO); shelly1; shelly2.5;Wasserzähler(GPIO);Brennerstuhlsteckdosen;

habeIchVergessen


Luke2000

Hallo zusammen,

ich habe folgende Frage:
Bisher habe ich meine SomfyRTS-Motoren mit Hilfe eines nanoCULs mit culFW 1.66 gesteuert. Bekanntermaßen lassen sich hiermit keine Somfy-Befehle der Handsender empfangen. Daher habe ich den Stick heute zu einem SIGNALduino geflasht.

M.E. hat auch alles soweit funktioniert. Die Rollläden kann ich jedenfalls mittels FHEM steuern. Dazu musste ich lediglich das IODev der bereits angelegten Rollladen-Devices auf den SIGNALduino wechseln.

Es funktioniert allerdings nicht, dass die Handsender als neue Devices in FHEM auftauchen. "autocreate" ist aktiviert. "Verbose 5" liefert nichts im Log-file, wenn ich einen Handsender drücke. Die Sender tauchen einfach nicht auf...

Hat jemand eine Idee? Kann der Stick ggfs. nicht empfangen, sprich ein Hardware-Defekt?

Viele Grüße
Luke

Elektrolurch

Hast Du die Frequenz für den Empfang auch permanent auf 433.20 Mhz gesetzt?
ccconf          freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:16dB 
Für das Senden macht das Somfy-Modul das temporär.

Elektorlurch
configDB und Windows befreite Zone!

Luke2000

Hallo Elektrolurch,

so, kann mich jetzt wieder an fhem versuchen...

Das mit der Frequenz war offensichtlich zunächst das Problem. Danke für den Hinweis! Und sorry, dass ich nicht selbst drauf gekommen bin. Es steht ja in vielen Posts. Ich war irgendwie der Meinung, dass ich die Frequenz bereits richtig eingestellt hatte.

Soweit so gut. Die Fernbedienungen werden vom SD also jetzt erkannt. Aber offensichtlich nur per "autocreate". Dies ist ja wegen der rollingcodes nicht sinnvoll, habe ich verstanden. Daher habe ich "autocreate" disabled und die angelegten FB-devices gelöscht. Danach werden die FBs bei erneutem Anlernen aber nicht mehr angelegt. Was mache ich falsch?

Sorry, für die vermeintlich einfachen Fragen, aber irgendwie komme ich nicht zurecht, trotz langer Rumprobiererei...

Gruß
Luke

RaspiLED

Hi,
Wenn du ein Device händisch löscht wird es erst nach dem nächsten reboot von FHEM wieder neu angelegt.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Schnello

Hallo.

Entschuldigt vorab die ein oder andere Blöde Frage aber selbst nach einem Jahr hab ich bisher nur das Anlegen eines Somfy Devices benötigt und das hab ich hinbekommen.
Der aktuelle Stand:
Ich hab bisher hier einen nanoCUL in Verwendung gehabt und hab mir aus Langeweile und weil es auch nett wäre den aktuellen Status der Markise zu kennen einen Signalduino gebaut.
FHEM hat via Autocreate meine echte Somfy FB angelegt. In diesem Device sieht man auch in "echtzeit" welcher Status gerade aktiv ist (off/on/stop...etc)

Zuerst eine generelle  Frage:
Ich hab schon festgestellt das wenn bei meinem alten Somfy Device das IO Device einfach von CUL auf Singnalduino ändere funktioniert das nicht. Seh ich das richtig das das eine Art Softwareschutz ist in FHEM damit nicht jeder so einfach die Rollos vom Nachbarn übernimmt. Signalduino sendet "anders" und darum muss einfach das Device nochmal extra angelernt werden. Richtig?


Zum Thema jetzt selbst:
Sind die Änderungen von Elektrolurch schon via Update zu erhalten oder muss man noch das somfy Modul austauschen?

Ich versteh den Syntax nicht ganz:
attr Az_FB_FRoll userattr associated-devices
attr Az_FB_FRoll associated-devices  Az_FRolladen


Wo gibt man diese Befehle ein? Auf der Hauptseite oder im FHEM Somfy device oder im Autocreate Device?
Was genau ist "Az_FB_FRoll" und "Az_FRolladen"


Grüße,
Christian





Heiner

Hi,

ist die Lösung mit associated-Devices schon im Standard?

Ich habe festgestellt das es viele Verweise auf "associated devices" gibt, aber nichts im comandref zu finden ist und auch "mein" Problem ausser hier noch nicht zu finden ist.

Ich habe einen SignalDuino um SOMFY RTS einzubinden

Die Somfy Fernbedienung wird per autocreate erstellt

Das Somfy device (ein Rollo)musste manuel angelernt werden.
Ebenso habe ich eine drive-down-time und drive-up-time gesetzt damit sich der status des devices aendern kann

Weil Somfy RTS Devices keine Rueckmeldung gibt habe ich in der Fernbedienung folgendes attribut gesetzt wie von Elektrolurch beschrieben:

Code: [Auswählen]
attr Rollo_FB userattr associated-devices

das fuehrt zu einem neuen Eintrag in der attribute Liste und damit setze ich dann

Code: [Auswählen]
attr Rollo_FB  associated-devices Rollo

Jetzt sollte ein Fernbedienungsbefehl dazu fuehren das sich der Status des Rollo veraendert.

Klappt aber leider nicht.
Im reading der Fernbedienung sehe ich zwar das ich die Fernbedienung betätigt habe,
der Staus des Devices ändert sich aber leider nicht.

Das reading de Fernbedienung sieht so aus:
Zitat
Readings
enc_key       A5         2017-12-09 10:54:28
exact           50          2017-12-09 10:54:28
parsestate   off          2017-12-19 08:48:10
position       50          2017-12-09 10:54:28
rolling_code 008B     2017-12-09 10:54:28
state            moving  2017-12-09 10:54:28

Muss es noch ein mapping der Fernbedienungsbefehle, mit den Devicebefehlen geben? (obwohl stop, off, on wie es unter "parsstate" steht eignetlich mit den Devicebefehlen harmoniert)

webcmd und eventmap im Rollo sind vorsichtshalber gelöscht auch wenn ich die gerne nutzen wollen würde

mach ich sonst irgendwas falsch?
Heiner
--------------------------------
fhem auf Pi3+
CUL 868MHz, Signalduino 434MHz, HM-CFG-USB
HM, THZ, Kostal, Somfy, Conbee, Pytonbinding, FritzBox, FTUI, MQTT2

Heiner

ach so hier noch das Log in Verbose 5:

Einmal an der Fernbedienung Befehl on gesetzt ( also runterfahren), dann noch einmal off ( also hoch) der Rest ist Schmutz nehm ich mal an

Zitat2017.12.19 18:31:14 3: SignalDuino: setting Verbose to: 5
2017.12.19 18:31:19 4: SignalDuino/msg READ: MC;LL=-1301;LH=1280;SL=-671;SH=606;D=F1F1CFBB0A91;C=642;L=48;R=34;
2017.12.19 18:31:54 4: SignalDuino/keepalive ok, retry = 0
2017.12.19 18:31:55 4: SignalDuino/msg READ: MU;P0=-1311;P1=1284;P2=-629;P3=638;D=012323232301232323012301232323012303232323212301232301232323230323212303210123230123;CP=3;R=25;
2017.12.19 18:31:55 5: SignalDuino: applying filterfunc SIGNALduino_filterSign
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 21 -> einhell garagedoor mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 26 -> remote26 mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 34
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 36 -> socket36 mismatches, aborting
2017.12.19 18:31:55 5: SignalDuino: applying filterfunc SIGNALduino_compPattern
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 39 -> X10 Protocol mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 49 -> quigg_gt9000 mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 1
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 9
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 3
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 1
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 69 -> Hoermann mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 3
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 71 -> PV-8644 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 3
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 75 -> ConradRSL2 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 1
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 3
2017.12.19 18:31:55 4: SignalDuino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2017.12.19 18:31:55 5: SignalDuino: Starting demodulation at Position 1
Heiner
--------------------------------
fhem auf Pi3+
CUL 868MHz, Signalduino 434MHz, HM-CFG-USB
HM, THZ, Kostal, Somfy, Conbee, Pytonbinding, FritzBox, FTUI, MQTT2

gestein

Hallo Heiner,

konntest Du da noch etwas herausfinden?
Ich habe nämlich das gleiche Problem und komme auch nicht weiter.

Danke, lg, Gerhard

JWRu

Ich habe mal nachgeschaut - die Lösung mit "associated-devices" ist (noch?) nicht im Standard.
Ich werde Elektrolurch mal eine PM schicken, ob das in die 10_SOMFY.pm aufgenommen werden kann.
ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

JWRu

Ich habe zwischenzeitlich das Problem mit einem einfachen notify gelöst:
define notify_FB_Markise notify FB_Markise:parsestate.* set Markise virtual $EVTPART1
"FB_Markise" ist das mit autocreate erzeugte Device, das die Signale der Hand-Fernbedienung empfängt.
"Markise" ist das von mir definierte Device, das an der Markise angelernt wurde. "set ... virtual" verhindert, dass "Markise" wirklich sendet.
Wenn ich nun die Fernbedienung betätige, ändert sich abhängig von der Laufzeit das Reading "position" in "Markise".
ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

Elektrolurch

Sorry, war länger nicht online.
Dass Attribut "associated--device" macht mit dem Code im Modul genau das, was Du auch mit dem notify machtst.


Gruß

Elektrolurch
configDB und Windows befreite Zone!

MichlW

Hallo liebe Community,

ich möchte mich vielmals bei allen "alten Hasen" und Tippgebern in diesem Forum bedanken. Ich konnte viele meiner Anliegen mit Hilfe dieses Forums bereits umsetzen. Heute musste ich mich nun dennoch anmelden, da ich eine spezielle auf diesem Thread aufbauende Frage habe.

Was funktioniert bereits?
- Steuerung unserer Reflexa-Markise mit Somfy-Funksteuerung über einen SIGNALduino mit CC1101.
- Einbindung in Homekit über Homebridge mit prozentualer Steuerung in 10% Schritten.
- Lauschen auf Signale des vorhandenen Telis 1 RTS Handsenders mittels dem zwei Posts über mir stehenden "virtual" notify's, um den Markisenstatus mitzuführen.

Was fehlt noch / Was ist mein Problem?
- Die meistgenutzte Taste auf unserem Handsender ist die My-Taste, welche eine Position anfährt, die bei ca. 90% Ausladung der Markise liegt. Das hat verschiedene Gründe, auf die ich jetzt gar nicht eingehen möchte.
- Genau diese My-Taste wird vom Somfy-Modul jedoch immer als Stop Signal gewertet, weswegen das oben stehende "virtual" notify gerade für diese Taste nicht funktioniert und der Status der Markise nicht mitgeführt wird. Dadurch ist Homekit auch immer nicht mehr synchron zum tatsächlichen Zustand.

Auf github habe ich folgendes Detail ausfindig gemacht:


sub SOMFY_DispatchRemoteCmd($$) {
...
if ($cmd eq "10") {
$cmd = "11"; # use "stop" instead of "go-my"
}


Warum aber wird dieser go-my Befehl zwingend auf ein stop gemapped? Kennt jemand die Hintergründe dafür?

Ich habe zeitweise über eine Änderung von somfyremote zu somfyshutter gehofft den Funktionsumfang des fhem-Devices für den Handsender mit dem fhem-Device für die Markise gleichzuziehen, das hatte aber nicht den erhofften Erfolg.

Vielen Dank im Voraus für weiterführende Informationen und evtl. Lösungsvorschläge. Ich weiß leider gerade überhaupt nicht, wie ich mir damit helfen soll.

Beste Grüße
Michael

Elektrolurch

Hallo Michael,

die Stop / GoMi - Taste hat leider eine context-sensitive Funktion:
Steht der Rolladen, dann wird die gespeicherte Position angefahren. Also müsste man zuerst hier korrekterweise ein Attribut hinterlegen, damit fhem dann auch weiß, wohin die Reise geht.

Läuft der Rolladen, dann wird ein Stopp verarbeitet, sowohl am Rolladen, als auch in fhem.

Möglicher Lösungsweg:
a) zusätzliches Attribut für die GoMi - Position einführen.
b) Die Dispatch-Funktion für das Kommando müsste abfragen, ob der Rolladen läuft, wenn ja dann stopp,
wenn nein, dann mit der Option Virtual die gespeicherte Position in fhem für GoMi nachbilden.

Sollte eigentlich nicht so schwierig sein, habe aber keinen Entwickler-Account und bin auch nicht der maintainer.

Elektrolurch
configDB und Windows befreite Zone!