Erweiterung CULFW um Somfy/Simu

Begonnen von thdankert, 31 Mai 2014, 14:20:23

Vorheriges Thema - Nächstes Thema

thdankert

Zitat von: Puschel74 am 01 Juli 2014, 20:20:09
Wobei es da ja eher um die Orienta Receiver geht da der Empfang wohl "nur noch" von Thomas in die culfw eingebaut werden muss - oder seh ich da was falsch?

Hi,

"nur noch" trifft es ganz gut :)
Aktuell hindert mich hier nur mein fehlendes Verständnis der culfw (speziell dem Teil in rf_receive), um das einzubauen.
Vielleicht kann mich da auch jemand unterstützen, der schon Empfangs-Support für andere Systeme eingebaut hat.

ZitatWäre es nicht auch mit überschaubarem Aufwand möglich beim initialisieren vom Modul das letzte Logfile davon durchzusehen und die entsprechenden Werte daraus zu ziehen?
Die Werte sind intern als Attribute des Device gespeichert, und das wird nur in der Config gesichert.
Vielleicht ist es besser, die als Reading abzulegen, dann würden sie auch im Statefile gesichert, ohne dass man die FHEM-Config speichern muss.

ZitatWie würde eigentlich nach aktuellen Stand der Technik eine Lösung für Somfy's io-homecontrol aussehen?
Tja, ich kenne das Protokoll leider gar nicht, aber eine kurze Google-Suche hat zumindest einen Funk-Chip zutage gebracht, der das Protokoll unterstützt (Analog Devices ADF7022).
Mangels Hardware kann ich leider nichts testen, ob man das vielleicht auch mit einem CUL senden (+ empfangen) kann.

Dazu muss man aber wieder die CULFW erweitern, soweit ich gelesen habe, ist io-homecontrol nicht kompatibel zu Somfy RTS (andere Frequenz, Modulation, etc).

Grüße,
Thomas
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)

rudolfkoenig

Zitatfehlendes Verständnis der culfw (speziell dem Teil in rf_receive)

Grob angerissen:
- im SlowRf-Modus liefert das CC1101 einen Interrupt beim Flankenwechsel
- in  ISR(CC1100_INTVECT) wird der Zeitstempel jeweils festgehalten, und je nach state ausgewertet
- zunaechst wird auf ein Sync gewartet, was aus mind 4-mal 0 bestehen muss. In diesem Status (STATE_SYNC) wird zero.hightime und zero.lowtime gemessen.
- danach muss ein 1-er kommen, was zum bestimmen von one.hightime bzw. one.lowtime verwendet wird.
- nachfolgend werden die Flankenwechsel ausgewertet, und je nach laenge ein 1 oder 0 ins "Eimer" (bucket) gepackt.
- wenn mindestens 4ms lang kein Flankenwechsel kommt, dann wird ISR(TIMER1_COMPA_vect) aufgerufen, der die im Eimer gesammelten Bits auswertet. Waehrend dieser Auswertung wird der naechste Eimer moeglicherweise gefuellt.
- es wird fuer alle bekannten Protokolle geprueft ob parity & CRC stimmt.
- wenn ja, dann wird es als erkannt gemeldet und ein HEX-Wert mit passenden ersten Typ-Byte ausgegeben.

Der Algorithmus benoetigt also eine bestimmte Syncfolge (n*0 und dann einmal 1), das Timing der 0 bzw. 1-er Bits wird aber weitgehend automatisch erkannt.

IT und REVOLT sind Ausnahmen: diese erkennen an der High- bzw Low-Zeiten des ersten Bits das Protokoll.

thdankert

Hallo Rudi,

danke, das hilft mir weiter!

Zitat von: rudolfkoenig am 01 Juli 2014, 23:14:02
Der Algorithmus benoetigt also eine bestimmte Syncfolge (n*0 und dann einmal 1), das Timing der 0 bzw. 1-er Bits wird aber weitgehend automatisch erkannt.

Dann bekomme ich wohl ein Problem, wenn ich Somfy empfangen will - der Sync sieht schon anders aus (n-mal 0 und 1 im Wechsel, mit doppelter Symbollänge),
und zu allem Überfluss sind die eigentlichen Daten Manchester-kodiert.
Da dürfte die Erkennung der 0 bzw. 1-er Bits ins Leere laufen, wenn die Zeit zwischen 2 Flankenwechseln gemessen wird, die ist ja nicht fest, sondern abhängig vom folgenden Bit.

Konkret sieht das bei Somfy so aus:

|   1208 us   |
|604 us|

       +------+      +------+------+      +------+             +------+
+------+      +------+             +------+      +------+------+ 

|      1      |      1      |      0      |      0      |      1      |


Ist es sinnvoller, hier eine eigene Datei rf_somfy mit eigenem rf_task anzulegen (z.B. wie bei m-bus), oder bekomme ich die Manchester-Dekodierung in rf_receive mit unter?

Grüße,
Thomas
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)

rudolfkoenig

Dirk (von busware) hat in rf_receive.c Manchaster eingebaut fuer HMS, komplett verstanden habe ich es ehrlicherweise aber nie. Wie du anhand dieser Syncs das Somfy-RTS-Protokoll von den restlichen unterscheiden kannst, ist mir erstmal schleierhaft, allerdings waere es relativ einfach ein somfy_rts Modus einzufuehren (analog zu MAX/HomeMatic/etc), und diese Signale dann exklusiv zu empfangen. Da alles auf 433MHz laeuft, waere das vmtl. auch nicht weiter tragisch.

Falls diese Modus-Variable gesetzt ist, dann wuerde man in dem ISR(CC1100_INTVECT) direkt zu den somfy-dekodier-Routinen verzweigen.

hyper2910

Hallo,

das sieht ja interessant aus.  Gibt es zu 10_SOMFY.pm auch eine komplett Anleitung, wie das ganze eingebunden wird.


Gruss Dirk
Cubietruck mit FHEM, CUL V3 443MHz, 2 x CULV3 868MHz, Milights, Max Heizungssteuerung, Homematic, IT,

thdankert

Zitat von: hyper2910 am 02 Juli 2014, 16:12:02
Hallo,

das sieht ja interessant aus.  Gibt es zu 10_SOMFY.pm auch eine komplett Anleitung, wie das ganze eingebunden wird.


Gruss Dirk

Hallo Dirk,

ja, die Commandref ist aktualisiert und kennt auch SOMFY.
Grob gesagt:

  • CUL mit neuester Firmware flashen
  • Somfy Device in FHEM anlegen (siehe Commandref)
  • Rolladen in Programmiermodus versetzen
  • Prog-Befehl über FHEM absenden, Rolladen sollte das mit kurz auf/ab quittieren

Grüße,
Thomas
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)

Mitch

Mal eine blöde Fragen, ich habe noch die Version 1.57 auf meinem CUNO mit IR Support.
Den IR Support benötige ich weiterhin, weil ich damit mit meiner TV FB die Lcihter im Wohnzimmer steuer.

Wie bekomme ich nun die neue Firmware inkl. Somfy und IR auf meinen CUNO?
FHEM im Proxmox Container

thdankert

Zitat von: Mitch am 02 Juli 2014, 16:37:00
Wie bekomme ich nun die neue Firmware inkl. Somfy und IR auf meinen CUNO?
Ich habe selbst keinen CUNO, daher die Frage: ist der IR-Support irgendwann deaktiviert worden?

Lösen kannst du das vermutlich nur, indem du die CULFW selbst baust - du kannst die Board-Definition des CUNO anpassen und z.B. IR und Somfy gleichzeitig aktivieren.
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)

Mitch

Zitat von: thdankert am 02 Juli 2014, 16:39:30
Ich habe selbst keinen CUNO, daher die Frage: ist der IR-Support irgendwann deaktiviert worden?
Ja, ist er, weiß nur nicht mehr wann und warum genau.

Zitat von: thdankert am 02 Juli 2014, 16:39:30
Lösen kannst du das vermutlich nur, indem du die CULFW selbst baust - du kannst die Board-Definition des CUNO anpassen und z.B. IR und Somfy gleichzeitig aktivieren.
dazu fehlt mir leider das KnowHow  :-[
FHEM im Proxmox Container

hyper2910

Hallo,

danke, habe keinen normalen Rolladen, sondern ein Garagentor als Rolladen mit SOMFY RTS Steuerung, sollte dann doch auch funktionieren? oder?
Cubietruck mit FHEM, CUL V3 443MHz, 2 x CULV3 868MHz, Milights, Max Heizungssteuerung, Homematic, IT,

thdankert

Zitat von: hyper2910 am 03 Juli 2014, 06:51:16
Hallo,

danke, habe keinen normalen Rolladen, sondern ein Garagentor als Rolladen mit SOMFY RTS Steuerung, sollte dann doch auch funktionieren? oder?

Hi,

ja, das müsste auch gehen - wenn du es in den Programmiermodus versetzen kannst, kannst du FHEM als neue "Fernbedienung" anlernen.
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)

postman

Hallo Thomas,
ich habe gesehen, dass es eine neue 10_SOMFY.pm gibt. Hast Du da das Problem mit den keys und codes behoben?
Mir fehlt derzeit leider noch ein wenig das Verständnis, wie Perl-Quellcode funktioniert.
Ansonsten funktioniert das Modul sehr gut. Derzeit verwende ich ein PDA als zusätzliche FB  ;D
Da reagieren die Rollis genauso, wie ich es möchte.

Gruß Uwe
Raspberry Pi Version 2 QUAD-CORE CPU und 1 GB RAM, CUL V3 868 MHz,  stapelbarer CC1101 (SCC) 433 MHz, Enocean-Stick,Jeelink-Stick, BSB-Lanadapter

Spruch eines Ausbilders: Theorie ist, wenn man alles weiss und nichts funktioniert; Praxis ist, wenn alles funktioniert und keiner weiss warum...

Mitch

Habe gerade mal im board.h File editiert, um IR Support zu aktivieren und festgestellt, dass in der v1.6 für den CUNO2 gar kein SOMFY drinnen ist?
FHEM im Proxmox Container

thdankert

Zitat von: postman am 03 Juli 2014, 08:07:23
Hallo Thomas,
ich habe gesehen, dass es eine neue 10_SOMFY.pm gibt. Hast Du da das Problem mit den keys und codes behoben?
Mir fehlt derzeit leider noch ein wenig das Verständnis, wie Perl-Quellcode funktioniert.
Ansonsten funktioniert das Modul sehr gut. Derzeit verwende ich ein PDA als zusätzliche FB  ;D
Da reagieren die Rollis genauso, wie ich es möchte.

Gruß Uwe

Hallo Uwe,

nein, das habe ich noch nicht behoben - einziger Workaround ist bisher, vor einem FHEM-Neustart auf "Save config" zu drücken, damit die aktuellen Werte gesichert sind.
Dann funktioniert das Somfy-Modul auch nach einem Neustart von FHEM.

Wie weiter oben schon geschrieben: evtl. ist es sinnvoller, wenn ich die keys und codes als Reading speichere, statt als Attribut. Dann würden sie im Statefile gespeichert, und sind immer aktuell.

Grüße,
Thomas
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)

thdankert

Zitat von: Mitch am 03 Juli 2014, 09:42:44
Habe gerade mal im board.h File editiert, um IR Support zu aktivieren und festgestellt, dass in der v1.6 für den CUNO2 gar kein SOMFY drinnen ist?

Mist, das habe ich tatsächlich vergessen - ich habe damals nur für den CUNO (1) die board.h angepasst.
Es reicht aber nicht aus, nur in board.h das #define HAS_SOMFY_RTS hinzuzufügen, es müssen auch in CUNO2.c noch ein paar Zeilen Code hinzugefügt werden.
Die sorgen für das Mapping vom Kommando "Y" auf den Somfy-Code.

Müsste etwa so aussehen, bei den includes:

#ifdef HAS_SOMFY_RTS
#include "somfy_rts.h"
#endif


Und direkt darunter in der fntab:

#ifdef HAS_SOMFY_RTS
  { 'Y', somfy_rts_func },
#endif


Grüße,
Thomas
RPI mit FHEM, 2x Stackable CC (868 und 433MHz)