Autor Thema: Erweiterung CULFW um Somfy/Simu  (Gelesen 338413 mal)

Offline RaspII

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 548
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #750 am: 05 Januar 2017, 23:51:22 »
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
RaspII

Offline majorshark

  • Sr. Member
  • ****
  • Beiträge: 519
    • Frank's Technik Blog
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #751 am: 07 Januar 2017, 17:07:24 »
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!

Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

Offline stefanru

  • Sr. Member
  • ****
  • Beiträge: 737
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #752 am: 08 Januar 2017, 13:01:15 »
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:
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.
# 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
« Letzte Änderung: 08 Januar 2017, 20:23:38 von stefanru »

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4165
    • Meine Seite im fhemwiki
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #753 am: 09 Januar 2017, 16:34:31 »
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.




Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline RaspII

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 548
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #754 am: 09 Januar 2017, 17:01:20 »
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
Zitat
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.:
Zitat
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.
RaspII

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4165
    • Meine Seite im fhemwiki
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #755 am: 09 Januar 2017, 17:15:58 »
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 ;)



Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline RaspII

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 548
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #756 am: 14 Januar 2017, 01:47:38 »
Hallo,
muss mich nochmal zu folgendem Thema melden:

Zitat
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  8) 8) 8)
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

RaspII

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4165
    • Meine Seite im fhemwiki
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #757 am: 14 Januar 2017, 16:31:27 »
Na das ist doch schön - die Signalduino-Entwickler freuen sich bestimmt (wenn sie das lesen sollten)!
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline RaspII

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 548
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #758 am: 14 Januar 2017, 17:58:23 »
 :)
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:
# 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:
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?
« Letzte Änderung: 14 Januar 2017, 18:00:35 von RaspII »
RaspII

Offline stefanru

  • Sr. Member
  • ****
  • Beiträge: 737
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #759 am: 14 Januar 2017, 18:16:19 »
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

Offline RaspII

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 548
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #760 am: 14 Januar 2017, 23:01:11 »
Wo finde ich die V3.3.1?

Gesendet von meinem SM-G900F mit Tapatalk

RaspII

Offline stefanru

  • Sr. Member
  • ****
  • Beiträge: 737
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #761 am: 14 Januar 2017, 23:56:06 »
Ich denke du brauchst nur updaten:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txtund 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

Offline RaspII

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 548
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #762 am: 15 Januar 2017, 19:10:26 »
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:
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
RaspII

Offline stefanru

  • Sr. Member
  • ****
  • Beiträge: 737
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #763 am: 15 Januar 2017, 21:36:23 »
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

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4165
    • Meine Seite im fhemwiki
Antw:Erweiterung CULFW um Somfy/Simu
« Antwort #764 am: 16 Januar 2017, 01:15:27 »
@RaspII - Sorry aber das ist hier irgendwie offtopic und würde auch besser im signalduino thread diskutiert werden
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können