SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

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

Vorheriges Thema - Nächstes Thema

MCh76

Zitat von: Elektrolurch am 29 Juni 2017, 14:55:58
Hallo,

ich habe die SOMFY_Parse sub mal so erweitert, dass man beim Handsender über ein Attribut die Rolläden hinterlegen kann und sich der Status der Rolläden auch ändert, wenn man den Handsender drückt.

So wirds gemacht:

attr Az_FB_FRoll userattr associated-devices
attr Az_FB_FRoll associated-devices  Az_FRolladen

Da können auch mehrere Rolläden stehen, wenn man z.B. auf einer Taste der FB mehrere Rolläden angelernt hat.

Ich hänge mal die geänderte SOMFY-Datei an. Die 10_SOMFY.pm sollte man entfernen, da ansonsten das Modul zweimal geladen wird und beim Neustart das log voll geschrieben wird.

Viel Spaß damit.

Ach ja, damit die Handsender überhaupt erkannt wurden, musste die Abfrage etwas weniger strikt erfolgen. Leider werden über den SignalDuino die gesendeten Signale nicht immer erkannt, so dass er meint, neue devices anlegen zu müssen.
Man sollte
attr autocreate disable 1
setzen, um nicht lauter Leichen oder die Rollos der Nachbarn anzulernen, was ja auch missbraucht werden könnte.

Elektrolurch

darf ich hier nochmals einhakenm ist ja einige zeit vergangen.
ich habe heute meine somfy rts markise auf von einem busware cul auf signalduino umgestellt, klappt alles.
das betätigen des handsenders wurde auch erkannt , device heisst nun out_markise_fb und mittels user-attribute habe
ich diese wie beschrieben mit dem gerät out_markise assoziert.
leider synchronisiert sich der status der markise aber nicht.

nun stehe ich etwas auf dem schlauch:
wenn ich es richtig verstehe wird das associated-devices user-attribut nicht vom 10_somfy unterstützt? oder hat sich seither was getan hier?
und falls nicht: wie entferne ich wie oben von elektrolurch vorgeschlagen die 10_somfy.pm und ersetze diese durch die myutils Version?
danke für ne kurze info.
VG,
Chris

Elektrolurch

Hallo,

für wahr, ist schon lange her....
Ich bin mir nicht sicher, ob das neue Attribut mit in die aktuelle Version  von 10_SOMFY.pm übernommen  wurde.
Es gibt zwei Möglichkeiten, das Modul zu ersetzen:
1. Ersetzte einfach im FHEM - Ordner die 10_SOMFY.pm durch die 99_myUtilsSOMFY.pm und verhindere über das global Attribut exclude_from_update  das bei einem Update das Modul überschrieben wird oder
2. die 99_myUtils...pm Module werden als letztes geladen, überschreiben also andere Module, falls die subs die gleichen Namen haben.

Ich hänge Dir mal die Version an, die bei mir derzeit läuft und auch mit den Handsendern funktioniert.


Elektrolurch
configDB und Windows befreite Zone!

MCh76

Hallo Elektrolurch,

danke für deine Erklärungen. Ich habe nun mal deine 10_SOMFY.pm Datei genommen und meine bestehende ersetzt.
Leider kein Erfolg. im per autocreate erzeugten FB-device kommen die Aktionen beim Drücken an, aber nicht im verknüpften Markisen-device.
Wenn ich im Editor deine Datei mal anschaue, finde ich mit meinen bescheidenen PERL kenntnissen auch kein
Coding zum "associate-devices" attribut...Muss da ggf. noch was bei mir lokal ergänzt werden?
VG,
Chris

Elektrolurch

Hallo,

Meine Fernbedienung sieht so aus:

associated-devices Az_FRolladen
model somfyshutter
userattr associated-devices


und der zugehörige Rolladen Az_FRolladen:

IODev CUL_433
additionalPosReading pos
alias Fenster
devStateIcon geschlossen:fts_shutter_100@#2222ff:offen 0:fts_shutter_100@#3333ff:offen  gesperrt|10$:fts_shutter_90@#4444ff:offen Dämmerung|20:fts_shutter_80@#5555ff:offen Sonnenschutz|30:fts_shutter_70@#6666ff:offen 40:fts_shutter_60@#7777ff:offen 50:fts_shutter_50@#9988CC:offen 60:fts_shutter_40@#AA7788:offen 70:fts_shutter_30@#aa8866:offen 80:fts_shutter_20@#bb8822:offen 90:fts_shutter_10@#cc8822:gesperrt offen:fts_shutter_0@#ff8800:gesperrt
drive-down-time-to-100 13.3
drive-down-time-to-close 16.9
drive-up-time-to-100 3.18
drive-up-time-to-open 17.67
event-on-change-reading state,pos
eventMap {'usr' => {'offen' => 'off', 'geschlossen' => 'on',  'gesperrt' => 'pos 0', 'Dämmerung' => 'pos 20', 'Sonnenschutz' => 'pos 30'}, 'dev' => {'open' => 'offen', 'closed' => 'geschlossen', '^30$' => 'Sonnenschutz', '^20$' => 'Dämmerung', '^0$' => 'gesperrt'}}
genericDeviceType blind
group Rolladen
homebridgeMapping CurrentPosition=position,minValue=0,maxValue=100,minStep=10
icon fts_window_2w
model somfyshutter
positionInverse 1
room Homekit
verbose 1


Habe das gerade noch einmal überprüft. Da ich den SignalDuino an einem anderen System betreibe, habe ich die Fernbedienungen per fhem2fhem gekoppelt und mir auf die Fernbedienungen ein notify gesetzt:

define SD_notify notify (Alle.|[A-Z][a-z])_FB_.*Roll:.* {SD1_not($NAME,$EVENT)}

In Deinem Fall ist die regex für die Fernbedienungen durch den Namen der Fernbedienung für die Markise zu ersetzen.

Und der zugehörige perl-Code sieht wie folgt aus:

sub SD1_not($$)
{
my ($name,$event) = @_;
my ($rd,$val) = split(': ',$event);
my $ads = AttrVal($name,'associated-devices',undef);
if(defined($ads))
{
# Ton ausgeben, FB betätigt
DoSet("sig2",6,2) if($name =~m/FB_.*Roll$/);
foreach my $ad (split("[ ,\t]+",$ads))
{
# Log(1,"SD_not: $name set $ad virtual $val");

DoSet($ad,'virtual',$val);
Log3 $name, 4, "SOMFY $name associated-device $ad $val";
} # liste
} # if ad
return undef;

} # end sub SD1_not
##############################


Die Zeile

DoSet("sig2",6,2) if($name =~m/FB_.*Roll$/);

kannst Du auskommentieren, sie erzeugt nur ein Geräusch, wenn über die FB ein Rolladen bedient wird und fhem das mittrackt.
Sorry, dachte, ich hätte den Code schon in das Somfy-Modul eingebracht.
Das Stückckchen Code liest das Attribut ssociated-devices aus und setzt dann bei den devices die Position.
Da das jetzt schon lange her ist.... na ja. Kann ja schon mal passieren, dass man nicht mehr weiß, wie man etwas gelöst hat.

Elektrolurch


configDB und Windows befreite Zone!

MCh76

Hallo elektrolurch,

*update nach ausprobieren*
dein Lösungsweg funktioniert wunderbar. Markisenstatus wird perfekt synchronisiert nach
Betätigen der Original Fernbedienung. Nochmals vielen Dank!

vg,
chris

diver

Hallo Leute,

habe es hinbekommen, dass ich via Signalduino Stick und FHEM meine Somfy RTS Rolladen steuern kann.
Nun geht es um die Positionsrückmeldung wenn der Sender gedrückt wird.

Problem: wenn ich einmal kurz eine Sendertaste der FB drücke kommen die Befehle nur sporadisch beim Fhem an.
Lasse ich den Finger auf dem Taster dann rattern die Meldungen im Eventmonitor durch.

Meine Somfy Fernbedienung ist die Telis 6 Chronis RTS.

Via FHEM habe ich den Signalduino fest auf 433,42 eingestellt.
Das Fhem Modul habe ich gegen die  99_myUtilsSOMFY.pm  aus diesem Threat getauscht
Via Autocreate wurden alle 6 Kanäle des Senders gefunden.
Duino Firmware ist die
V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
versionmodul v3.4.1_dev_28.10

Nun weis ich nicht mehr wo ich ansetzen soll.
Firmware vom Duino Stick neuer Flashen?
Irgendeinen anderen Parameter anpassen?

Beim aktualisieren der Stick Firmware habe ich die Befürchtung das hinterher nichts mehr geht, alle Einstellungen weg sind oder der Stick hinüber ist....

Es wird nun die FB zurück gemeldet, jedoch kommt das nur zuverlässig an wenn man den Knopf gedrückt lässt.
Im FHEM Logfile kommt noch  nach Tausch auf die  99_myUtilsSOMFY.pm folgende Meldung alle paar Sekunden:

2019.11.02 07:25:06 1: ERROR: >Somfy RTS checksum error!< returned by the SOMFY ParseFn is invalid, notify the module maintainer

Danke und Gruß André

EDIT: wenn ich den Knof an der Fb kurz drücke kommt das am Stick an. Die Led leuchtet dann.
Es kommt also an aber wird nicht verarbeitet.

nagelreo

Hallo,

ich bin neu im Forum und kann Dank der vielen Beiträge im Forum meine Somfy Rollos mit dem Signalduino steuern.
Die Positionsrückmeldung der Fernbedienung (Wandsender/Telis 4, ca. 11 Jahre alt) funktioniert ebenfalls mit Ausnahme der my-Taste. Wird die Taste während dem Auf- oder Abfahren gedrückt, stoppt die Positionsrückmeldung korrekterweise. Beim Ansteuern der my-Position passiert aber nichts, im LogFile wird ,,stop" rückgemeldet.

Zur Problemlösung gab es im Oktober 2018 einen aus meiner Sicht guten Vorschlag von Elektrolurch.

"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."

Bleibt es bei dem Vorschlag?

Dann habe ich noch eine alte Somfy Steuerung (Zeiten/Sonnenaufgang). Der CUL-Stick empfängt zwar, im Fhem kommt aber nichts an. Woran kann das liegen?

Vielen Dank Rolf

nagelreo

Hallo,

leider gab es zu meiner Frage bezüglich dem Abgleich der SOMFY Fernbedienung noch keine Rückmeldung.

Zwischenzeitlich habe ich die manuelle und ASC Steuerung meiner 14 Rollos optimiert und 4 Wochen getestet. Die Steuerung funktioniert sehr zuverlässig.
Probleme habe ich aber immer noch mit dem Abgleich der Handsender, die Sender werden nicht zuverlässig erkannt. Zu dem Thema habe ich im Forum im Wesentlichen den Vorschlag von Elektrolurch ,,userattr associated-devices mit 99_myUtilsSOMFY.pm" gefunden. Im Prinzip funktioniert das, aber leider werden die Handsender nur sehr unzuverlässig, d.h. mit falschem Code ,,erkannt".
In diesen Fällen fehlt immer ein Bit, 56 anstatt 57. Wenn ich ein Bit (0 oder 1) am Ende anfüge und damit decodiere,  sind der rolling code und die Adresse korrekt. Ich habe dies mit mehreren Handsender (RTS, Telis 4 RTS, Simu) und den Modulen 10_SOMFY.pm sowie 99_myUtilsSOMFY.pm bestätigt.

2020.03.01 12:16:15 4: CUL1: Parse_MC, Found manchester Protocol id 43 clock 648 RSSI -50.5 -> Somfy RTS
2020.03.01 12:16:15 4: CUL1: Somfy bitdata: 01010001011101011111000011110101101110010100110001010101 (56)
2020.03.01 12:16:15 4: CUL1: Somfy RTS preprocessing check: 4 enc: 5175F0F5B94C55 dec: 512485054CF519
2020.03.01 12:16:30 4: CUL1: Read, msg: MC;LL=-1328;LH=1263;SL=-685;SH=611;D=A38C868D14FECC;C=647;L=55;R=44;

letztes Bit "0" ergänzt, erstes Bit entfernt:
_10100010111010111110000111101011011100101001100010101010
enc: A2EBE1EB7298AA  dec: A2490A0A99EA32

Ich benutze den Selbstbau NanoCUL von Schlauhaus (Ardunino Nano vc3, traxCUL Platine, cc1101) mit der aktuelle Firmware ,,V 3.4.0-dev SIGNALduino cc1101 (chip CC1101) - compiled at Feb 15 2020". Ältere Firmware Versionen verhalten sich gleich.

Gibt es dafür eine Lösung?
André, konntest du dein Problem lösen?

Vielen Dank und Gruß
Rolf

RaspiLED

Hi,
probiere doch mal bitte die a-culfw und/oder die Signalduino Firmware aus.

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

nagelreo

Hi Arnd,

vielen Dank für die Antwort.
Signalduino Firmware benutze ich momentan und habe die Version 3.3.1, 3.3.2 und die aktuelle 3.4.1 geprüft.
a-culfw 1.26.08 habe ich am Anfang benutzt, da war ich aber noch nicht ganz soweit. Soweit ich mich erinnere, gab es da auch schon Probleme mit dem Erkennen der Handsender. Ich habe den Stick eben mit der a-culfw geflasht, den CUL und einen Hansender (als assotiated device) eingerichtet, der Aufwand war etwas größer als vermutet. Den richtigen rolling code habe ich zuvor mit der Signalduino Firmware ermittelt. Die Rückmeldung war mehrmals unknown device.

Ich habe mir die beiden Protokolle 10_SOMFY.pm und 00_Signalduino.pm angeschaut. Soweit ich diese verstanden habe, vermute ich auch, dass es am Signalduino (Firmware oder Hardware) liegt. Da ich nicht der Einzige mit Empfangsprobleme bin, vermute ich die Firmware.
Ich richte die Frage mal an das entsprechende Forum, vielleicht haben die eine Idee.

Gruß
Rolf


Ralf9

ZitatIm Prinzip funktioniert das, aber leider werden die Handsender nur sehr unzuverlässig, d.h. mit falschem Code ,,erkannt".
In diesen Fällen fehlt immer ein Bit, 56 anstatt 57. Wenn ich ein Bit (0 oder 1) am Ende anfüge und damit decodiere,  sind der rolling code und die Adresse korrekt. Ich habe dies mit mehreren Handsender (RTS, Telis 4 RTS, Simu) und den Modulen 10_SOMFY.pm sowie 99_myUtilsSOMFY.pm bestätigt.

Ich möchte es mir mal anschauen, dazu benötige ich MU-Nachrichten von den empfangenen Signalen der Handsender.
https://forum.fhem.de/index.php/topic,53319.msg762696.html#msg762696

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

nagelreo

Hallo Ralf,

anbei die MU's. Ich habe die down Taste des RTS  Senders 5 mal gedrückt. Die Adresse des Senders ist 96EB97 bzw. final 97EB96. Zuvor habe ich in Serie 5 Signale als MC generiert. 2 davon waren richtig erkannt, 3 nicht. Bei der manuellen Dekodierung wurde bei den 3 nicht zugeordneten Signalen ein Bit angehängt. Damit waren die Codes korrekt.


2020.03.03 21:06:33 4: CUL1: Read, msg READredu: MU;P0=-136;P1=2516;P2=-2622;P3=4828;P4=-1298;P5=1282;P6=-649;P7=621;D=012123454545676747676567676767476767676567476567476765456767674547676767656767676767476765476767;CP=7;R=32;
2020.03.03 21:06:34 4: CUL1: Read, msg READredu: MU;P0=23808;P1=-2644;P2=2472;P3=4812;P4=-1286;P5=1295;P6=-639;P7=633;D=01213454545674767676567676747676767676567674567476765456767674547676767656767676767476765476767;CP=7;R=31;
2020.03.03 21:06:35 4: CUL1: Read, msg READredu: MU;P0=2532;P1=-2636;P2=4820;P3=-1295;P4=1276;P5=632;P6=-644;D=0101234343434356564656534356565656435656465356564346565653435656565646565656565356564356565;CP=5;R=32;
2020.03.03 21:06:36 4: CUL1: Read, msg READredu: MU;P0=-136;P1=2530;P2=-2610;P3=4824;P4=-1287;P5=1290;P6=619;P7=-652;D=0121234545454676767675767646767676767675454576467675457676764546767676757676767676467675467676;CP=6;R=33;
2020.03.03 21:06:37 4: CUL1: Read, msg READredu: MU;P0=1286;P1=625;P2=-641;P3=-4800;P4=2404;P5=-2668;P6=4780;P7=-1285;D=345670707120217121207120217121212070712021712120702121217071212121202121212121712120712121;CP=1;R=32;



"MC Bits, bei den nicht zugeordneten Signalen habe ich bei der manuellen Dekodierung ein Bit 0 angehängt.
Bei allen Signalen wurde das 1. Bit entfernt.
                                                                                                                            fhem                               manuell
010101001111000101111101110101110001110001101001101000100000 A9 4B 1955 96EB97 A9 4B 1955 96EB97
01010101011100001111110001010111000111000110100110100010         55 70 FC57 1C69A2 AA 4B 1956 96EB97
01010101111100000111110011010111000111000110100110100010         55 F0 7CD7 1C69A2 AB 4B 1957 96EB97
01010110011101111111101101010111000111000110100110100010         56 77 FB57 1C69A2 AC 43 1958 96EB97
010101100111011111111011010101110001110001101001101000100000 AC 43 1958 96EB97 AC 43 1958 96EB97


Vielen Dank und Gruß
Rolf

Ralf9

Diese 5 MU Nachrichten werden richtig decodiert, ich benötige MU-Nachrichten bei denen es nicht passt.


MU;P0=-136;P1=2516;P2=-2622;P3=4828;P4=-1298;P5=1282;P6=-649;P7=621;D=012123454545676747676567676767476767676567476567476765456767674547676767656767676767476765476767;CP=7;R=32;
MC;LL=-1298;LH=1282;SL=-649;SH=621;D=A8E0F99D0BE077;C=641;L=56;
SOMFY Unknown device 97EB96 (A8 1964)

MU;P0=23808;P1=-2644;P2=2472;P3=4812;P4=-1286;P5=1295;P6=-639;P7=633;D=01213454545674767676567676747676767676567674567476765456767674547676767656767676767476765476767;CP=7;R=31;
MC;LL=-1286;LH=1295;SL=-639;SH=633;D=A9E1F89D0BE077;C=642;L=56;
SOMFY Unknown device 97EB96 (A9 1965)

MU;P0=2532;P1=-2636;P2=4820;P3=-1295;P4=1276;P5=632;P6=-644;D=0101234343434356564656534356565656435656465356564346565653435656565646565656565356564356565;CP=5;R=32;
MC;LL=-1295;LH=1276;SL=-644;SH=632;D=AAE2FB9D0BE077;C=641;L=56;
SOMFY Unknown device 97EB96 (AA 1966)

MU;P0=-136;P1=2530;P2=-2610;P3=4824;P4=-1287;P5=1290;P6=619;P7=-652;D=0121234545454676767675767646767676767675454576467675457676764546767676757676767676467675467676;CP=6;R=33;
MC;LL=-1287;LH=1290;SL=-652;SH=619;D=ABE3FA9D0BE077;C=641;L=56;
SOMFY Unknown device 97EB96 (AB 1967)

MU;P0=1286;P1=625;P2=-641;P3=-4800;P4=2404;P5=-2668;P6=4780;P7=-1285;D=345670707120217121207120217121212070712021712120702121217071212121202121212121712120712121;CP=1;R=32;
MC;LL=-1285;LH=1286;SL=-641;SH=625;D=ACECF59D0BE077;C=639;L=56;
SOMFY Unknown device 97EB96 (AC 1968)
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

nagelreo

Hallo Ralf,

vielen Dank.
Das überrascht mich, da ich zeitnah mit identischem Testaufbau (lediglich MC und MS disable gesetzt) unknown MC Signale empfangen habe.
Leider kann ich die MU Signale noch nicht selbst dekodieren und daher nicht prüfen, ob diese unvollständig sind. Mit der Beschreibung in "Wiki/Unbekannte_Funkprotokolle" komme ich bei dem Mapping der Pulswerte mit der "sSlL-Notation" und der Zuordnung von Pausen nicht zurecht.
Gibt es dazu eine klarere Beschreibung?

Gruß
Rolf

HomeAuto_User

Hallo Rolf,
ich lese hier im Faden von RollingCode.
Kannst du bitte schauen ob du einen solchen Sender schadensfrei öffnen kannst. Mich würde der Schaltkreise bzw IC interessieren welcher verbaut ist. So erfahren wir ggf mehr über den RollingCode.
Mfg


Gesendet von iPhone mit Tapatalk Pro
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet