Erweiterung CULFW um Somfy/Simu

[RaspII]

Hallo zusammen,
ganz kurz ein Themawechsel:
ich überlege mir seit kurzem Somfy Rolläden über FHEM zu steuern.
Kann mir jeman folgendes Zitat etwas erklären?

Hallo Marko,
die Grundregel für Somfy RTS ist ganz einfach:

cul --> NUR Senden
fhemduino --> NUR Empfangen

Das Protokoll ist unidirektional, es wird also nur vom Sensor/Fernbedienung/FHEM (Sender) zum Aktor/Rolladen (Empfänger) etwas "gefunkt". Um von FHEM einen Somfy-Device steuern zu können wird ein CUL benötigt, um (zusätzlich) eine Fernbedienung empfangen zu können wird der fhemduino benötigt.

Hier meine Fragen:

• gilt obige Aussage generell für alle Somfy Protokoll Varianten (neben RTS) oder kann bei anderen Protokoll Ausprägungen z.B. auch der CUL empfangen bzw. der FHEMDUINO auch senden?
• Was ist der Grund dafür, dass beim cul nur Senden und beim fhemduino nur Empfang implementiert wurde?
  (beim CUL hatte ich verstanden, dass der Empfang sehr komplex zu implementieren ist), bei fhemduino hätte ich aber erwartet, dass dort auch das Senden implementiert ist (einfach vom CUL übernommen).
• das Somfy.pm Modul kann beides (senden/empfangen), richtig (oder wie nutzte ich beide Funktionen in FHEM)?

Wäre toll wenn mir jemand die Fragen beantworten kann.
Ich würde mir ggf. eine CUL FW bauen, die Senden und Empfangen kann, falls das einfach vom FHEMDUINO ableitbar ist.  (Ich nutzte sowieso für jedes Protokoll einen eigenen CUL, da die Sende-/Empfangsparameter bisher je Protokoll immer unterschiedlich waren, bei manchen Protokollen sind die korrekten Parameter entscheidend für die Reichweite)

Viele Grüße
RaspII

[majorshark]

So ganz kurz (weil genervt vom nanoCUL  ).
Test abgebrochen.
- nanoCUL initialisiert nicht richtig beim Hochfahren des Raspi
- Rollläden fahren unzuverlässiger als beim Busware 868 CUL (Da sind es nur Empfangsprobleme)
- IT wir empfangen und via autocreate angelegt kann aber nicht geschaltet werden. Keine Ahnung warum das nicht geht
- NanoCUL hängt sich auch mit Optiboot auf.

Der nanoCUL darf jetzt in die Krabbelkiste!

[stefanru]

Hi,

ich habe eine Frage zu SOMFY Garagentor und Lichtschaltung.
Rolläden über RTS habe ich eingebunden und es geht nach einiger Konfiguration einwandfrei!

Nun hätte ich gerne noch mein Licht und die Garagentore dran.
Bei diesen kommt ein einfacheres Protokol als RTS zum Einsatz, sieht aber aus als würde es ähnlich funktionierten bis auf den encryption key.
Die Fernbedienung ist eine 2(http://www.ebay.de/itm/SOMFY-original-Handsender-2-Kanal-433-42-MHz-grau-/121836155712) oder 4 Kanal(https://www.handsender-shop.de/handsender-somfy-4-433-433-mhz-4-kanal-p-207.html).
Die Sender werden mittels DIP Code Schalter programiert(siehe Bild 2 Kanal Sender).

Die Dip schalter haben 3 Stellungen - 0 +. Es gibt 9 Schalter.

Mein Handsender hat nun die Stellung - + - - + - + - +.

FHEMduino empfängt ihn als Somfy Gerät:

Taster 1 wird als Command 20 und Taster 2 als Command 11 empfangen.
Wenn ich das richtig sehe ist das mapping: 20 = off, 11 = stop

Der Unterschied scheint in dem encryption Key zu liegen. Während der bei Somfy Rolläden wie der Rollingcode hochgezählt wird ist er hier wohl starr.

Hier mal ein Auszug von 4 mal scahlten vom FHEMduino Empfang:

Code Auswählen Erweitern


1.
fduino_RAWMSG Ys a0 20 1caf 9c39d7
command 20

2.
fduino_RAWMSG Ys a0 20 1cb0 9c39d7
command 20

3.
fduino_RAWMSG Ys a0 20 1cb1 9c39d7
command 20

4.
fduino_RAWMSG Ys a0 20 1cb2 9c39d7
command 20


Somit denke ich der unterschied ist dass der encryption key nicht hochgezählt wird?
Ys(Somfy) a0(encryption key) 20() 1cb2(roling code) 9c39d7(deviceid)

Anlegen eines somfy devices mit device id, rollingcode usw führt nicht zum erfolg da der encryption key sich ändert.
Wie könnte ich es bewerkstelligen dass er ihn nicht ändert? Ich denke sogar dass der rolling code in dem Protokol wurscht ist, macht aber nichts wenn er mit zählt.

Kann ich noch informationen zur Verfügung stellen? Habe sender und empfänger vor mir.
Könnte das jemand implementieren?

Gruß und Danke,
Stefan

P.S.: HAbe gerade noch ein Erfolg gehabt.
Lege ich das Somfy device folgendermaßen an:
define lichttest4 SOMFY D7399C a0 1c6a
Und schalte off für 20. Funktioniert es genau beim 1. mal.
Ich denke da beim 1.mal encryption A0 ist.
Danach nicht mehr da sie dann hochgezählt wurde.

P.P.S:
Konnte es nun mehrfach reproduzieren.
Der Rolingcode ist egal da auch mehrere Fernbedienungen einen Lichtschalter / Garage steuern kann.
Der Encryption Key muss gleich bleiben.

Könnte dies bitte jemand in die SOMFY.pm aufnehmen als Garage/licht Sender?

Noch eine Anmerkung. Zur Zeit bekomme ich es nur hin wenn ich über den sduino sende. Mit dem nanoCUL geht es nicht.
Meine Rolläden gehen mit beiden.

Noch eine Anmerkung:
Habe es jetzt am laufen in dem ich in Somfy.pm Zeile 428-430 auskommntiert habe und bei dem Garage/Lichtdevice den enc-key als attribut auf A0 setze.

Code Auswählen Erweitern

# delete old attribute
#delete($attr{$name}{"enc-key"});
#delete($attr{$name}{"rolling-code"});

Kann man sicher über Model schöner lösen, aber tut.
Seltsam ist nach wie vor, der Sender muss der sduino sein. Der nanoCUL geht nicht. Vieleicht etwas am timing? Es wird ja doch einiges geändert beim nano.

Danke und Gruß,
Stefan

[viegener]

Hallo zusammen,
ganz kurz ein Themawechsel:
ich überlege mir seit kurzem Somfy Rolläden über FHEM zu steuern.
Kann mir jeman folgendes Zitat etwas erklären?


Hier meine Fragen:

• gilt obige Aussage generell für alle Somfy Protokoll Varianten (neben RTS) oder kann bei anderen Protokoll Ausprägungen z.B. auch der CUL empfangen bzw. der FHEMDUINO auch senden?
• Was ist der Grund dafür, dass beim cul nur Senden und beim fhemduino nur Empfang implementiert wurde?
  (beim CUL hatte ich verstanden, dass der Empfang sehr komplex zu implementieren ist), bei fhemduino hätte ich aber erwartet, dass dort auch das Senden implementiert ist (einfach vom CUL übernommen).
• das Somfy.pm Modul kann beides (senden/empfangen), richtig (oder wie nutzte ich beide Funktionen in FHEM)?

Wäre toll wenn mir jemand die Fragen beantworten kann.
Ich würde mir ggf. eine CUL FW bauen, die Senden und Empfangen kann, falls das einfach vom FHEMDUINO ableitbar ist.  (Ich nutzte sowieso für jedes Protokoll einen eigenen CUL, da die Sende-/Empfangsparameter bisher je Protokoll immer unterschiedlich waren, bei manchen Protokollen sind die korrekten Parameter entscheidend für die Reichweite)

Viele Grüße
RaspII

Einfach vom CUL übernommen ist eine wunderbare Idee, da wären wir bestimmt nicht draufgekommen 

Im Ernst: Wenn es so einfach wäre, hätte ich es bestimmt gemacht. Ich habe erhebliche Zeit in die Implementierung des Empfangens in der culfw investiert, aber die Ergebnisse waren mir zu unzuverlässig bisher, deshalb läuft das nachwievor nur im Labor. Aber vielleicht kannst Du es ja mal eben übernehmen 

Aber die gute Nachricht: Die Aussage ist so nicht mehr korrekt. Senden und Empfangen ist inzwischen im Signalduino implementiert dank der fleissigen Arbeit der Kollegen am Signalduino - schau doch mal dort.

[RaspII]

Danke für die Antwort.
Ich schau mir das mal an.

Wie soll ich die leicht "zynischen" Kommentare einordnen?
Da ich Eure Vorgeschichte nur zum Teil kenne, ist mir auch nicht klar was ihr wann/warum versucht oder eben nicht versucht habt.


Mit

Einfach vom CUL übernehmen

hatte ich das Übernehmen der Senderoutine vom CUL in den fhemduino gemeint, mag sein ich habe das unterschätzt.

Ich habe das KOPP_FC Protokoll in den CUL und in FHEM implementiert (senden und empfangen).
Damals habe ich mich gegen die Implementierung in das "Slow-RF Protokoll" entschieden und KOPP als eigenständiges Protokoll implementiert (benötigt dann einen eigenen CUL).
Dafür gab es 2 Gründe:
a) Die Komplexität des Slow_RF Protokolls (ist mir damals auch aufgefallen
b) Die RF Einstellungen sind bei den verschiedenen Protokollen etwas unterschiedlich, beim KOPP Protokoll hat das dazu geführt, dass die Reichweite stark eingeschränkt war. Mit unterschiedlichen RF Einstellungen kann man aber sowieso nur ein Protokoll empfangen, dann kann man das auch gleich "Standalone" implmentieren

Bzgl.:

Aber vielleicht kannst Du es ja mal eben übernehmen 

Am Kopp Protokoll habe ich etwa 2 Jahre lang Nachtschichten eingelegt, d.h. mit eben mal übernehmen wird das sicher nichts, das ist mir klar.

Macht ja auch nichts, wenn das Problem schon mit dem Signalduino gelöst ist.
Also nochmal vielen Dank für die Info.

Falls Doch noch jemand eine CUL Lösung angehen will, ich unterstütze hier gerne mit meinem Know How.

[viegener]

Danke für die Antwort.
Ich schau mir das mal an.

Wie soll ich die leicht "zynischen" Kommentare einordnen?
Da ich Eure Vorgeschichte nur zum Teil kenne, ist mir auch nicht klar was ihr wann/warum versucht oder eben nicht versucht habt.


Mit  hatte ich das Übernehmen der Senderoutine vom CUL in den fhemduino gemeint, mag sein ich habe das unterschätzt.

Wollte nicht zynisch erscheinen, gerne aber ironisch. Zur Erklärung es sind doch relativ grosse Unterschiede, denn CUL ist AVR direkt in C, während FHEMDuino Arduino-Umgebung ist und das ist ja leider nur der Auftakt, denn die CULFW hat eine sehr eigene Struktur insbesondere, wenn man es nicht als getrenntes Protokoll haben will, denn einen CUL nur für Somfy wäre eigentlich nicht so schön. Wie gesagt die Implementierung im CUL ist fertig, sie funktioniert nur nicht und das liegt einfach an der Zeit

[RaspII]

Hallo,
muss mich nochmal zu folgendem Thema melden:

Aber die gute Nachricht: Die Aussage ist so nicht mehr korrekt. Senden und Empfangen ist inzwischen im Signalduino implementiert dank der fleissigen Arbeit der Kollegen am Signalduino - schau doch mal dort.

Ich habe mich hingesetzt und mir einen Signalduiono zusammengestöpselt (Teile waren alle da, siehe Bild).
Und was muss ich sagen?
Mit meinen Brennerstuhl Funksteckdosen hat das sofort funktioniert, senden/empfangen via FHEM (autodetect).
Ich bin begeistert 
Vor allem die Architektur der Firmware (Aufbau des Protokolls zum SIGNALduino) ist einfach Klasse.

Der nächsten Schritt mit Somfy wird dann wohl ähnlich problemlos über die Bühne gehen.

Nochmal danke für den Tipp.
Gruß
RaspII

[viegener]

Na das ist doch schön - die Signalduino-Entwickler freuen sich bestimmt (wenn sie das lesen sollten)!

[RaspII]

 
Mit Somfy klappt es jetzt leider gar nicht.
Weder Empfang noch senden (es kommt keine HF)
(Der SIGNALduino funktioniert mit dem IT Protokoll wie gesagt in beide Richtungen.

Hier mal der relevante Teil meiner fhem.cfg:

Code Auswählen Erweitern


# Signalduino in Betrieb nehmen (2017-01-13)
# ==========================================
define sduino SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
attr sduino flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]

# Test Somfy
# ==========
define Rollo1 SOMFY 000001
attr Rollo1 IODev sduino
attr Rollo1 room Somfy
attr Rollo1 devStateIcon open:shutter_open closed:shutter_closed


Wie gesagt, parallel dazu ist das IT Protokoll genutzt:

Code Auswählen Erweitern


define IT_000000FFFF IT 000000FFFF 0F F0
attr IT_000000FFFF IODev sduino
attr IT_000000FFFF room IT


Der SIGNALduino meldet sich mit Version:
sduino version => V 3.3.0 SIGNALduino - compiled at Jan 11 2017 23:14:10

Wer kann helfen?

[stefanru]

Das geht schon.
Ich glaub da gabs ne Änderung.
Ich hab    
V 3.3.1-dev SIGNALduino - compiled at Jan 3 2017 23:59:32

Gruß,
Stefan

[RaspII]

Wo finde ich die V3.3.1?

Gesendet von meinem SM-G900F mit Tapatalk

[stefanru]

Ich denke du brauchst nur updaten:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
und dann den sduino flashen über FHEM
Schau  mal obs dann passt.

Ich hoffe ich habe nicht ne Testversion aus irgendeinem Thread hier. Glaube aber nicht.

Gruß,
Stefan

[RaspII]

Super, hat geklappt.
ich hab jetzt die SIGNALduino V3.3.1 drauf.
Per SOMFY senden und empfangen klappt auch. Alles bestens.

Bei Gelegenheit könnte mir jemand erklären, was ich mit dem Updatebefehl:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

eigentlich genau mit meiner FHEM Installation angestellt habe.
-> eine SIGNALduino Betaversion dazuinstalliert?
-> nicht offizielle Add-Ons dazugeladen?

Wichtig wäre zu wissen, ob das alles irgendwann in der offiziellen FHEM Version enthalten ist oder ob ich mir künftig die aktuelle Verstion dieses Updates immer dazuinstallieren muss

Nochmal vielen Dank !!!
Gruß
RaspII

[stefanru]

Soweit ich das verstehe ist das das offizielle github des signalduino.
Wird auch im FHEM-Wiki so beschrieben: https://wiki.fhem.de/wiki/SIGNALduino

Wann da mal ins FHEM Repo gesynct wird weiß ich nicht.

Du kannst dir das github repo mit hilfe von update add mit zu deinem FHEM update laden.
So mache ich das auch.

Dann updated er erst FHEM und direkt hinterher das Signalduino repoi drüber.

Ich habe so eine update liste im FHEM:
http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt

Gruß,
Stefan

[viegener]

@RaspII - Sorry aber das ist hier irgendwie offtopic und würde auch besser im signalduino thread diskutiert werden