Moinsen,
dank eines SDR-Sticks komme ich einem meiner zahllosen FHEM-Mysterien etwas näher: Meine VELUX Solarrolläden der ersten Generation lassen sich aktuell nur mit meinem 868er CUL, aber nicht mit dem 433er und auch nicht mit dem SIGNALEsp steuern.
Der 868er funkt dann auf ca 433,39 MHz (mit einer Oberwelle bei 866,78), d.h. er wird temporär sauber umgeschaltet und die Rolläden fahren wie gewünscht:
Internals:
CMDS BbCFiAZNkGMKUYRTVWXefmLltux
...
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/ttyACM0 1965
DeviceName /dev/ttyACM0
...
TYPE CUL
VERSION V 1.66 CUL868
...
MatchList: ...
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
...
Readings:
2017-07-21 16:53:02 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2017-08-28 11:28:37 cmds B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
...
2017-04-20 22:08:17 version V 1.66 CUL868
Der 433er läuft mit einer halbwegs frischen a-culf, und beim Senden passiert: nichts, nada, niente. Kein Signal zwischen 432 und 434 MHz.
Internals:
CMDS ABCeFfGiKLlMNRTtUVWXx
...
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9Z0UKO7-if00-port0@38400 2014
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9Z0UKO7-if00-port0@38400
FD 116
FHTID 2014
NAME CUL433
...
VERSION V 1.25.01 a-culfw Build: 257 (2017-07-14_17-38-58) nanoCUL433 (F-Band: 433MHz)
...
MatchList: ...
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
...
READINGS:
2017-08-28 11:52:55 ccconf freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:4dB
2017-09-13 17:26:54 cmds A B C e F f G i K L l M N R T t U V W X x
...
2017-09-18 16:56:11 version V 1.25.01 a-culfw Build: 257 (2017-07-14_17-38-58) nanoCUL433 (F-Band: 433MHz)
Prinzipiell funktioniert der 433er, er empfängt CUL_WS-Wetterdaten und sendet IT problemlos.
Der SIGNALEsp433 sendet, allerdings auf der voreingestellten 433,92, und wird daher vom Rolladen nicht gehört:
Internals:
Clients :IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
DEF 192.168.178.153:23
...
NAME SIGNALEsp433
...
version V 3.3.1-dev SIGNALduino cc1101 - compiled at Aug 18 2017 18:37:31
MatchList: ...
15:SOMFY ^YsA[0-9A-F]+
...
READINGS:
2017-09-02 15:20:09 ITParms Unsupported command
2017-09-13 22:52:03 cmds V R t X F S P C r W x e b
...
2017-09-13 22:51:51 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Aug 18 2017 18:37:31
Die Fragen:
a) Nach meinen Erkenntnissen unterstützt a-culfw seit geraumer Zeit das Senden von SOMFY. Ich habe hier inzwischen auch die Hardware getauscht (aktuell ein nanoCUL mit a-culfw 1.25, vorher ein miniCUL mit a-culf 1.21), aber gleiches Device (nur die DEF geändert und alle gets ausgeführt). Wieso bekomme ich aber keine Sendung hin?
b) was muss ich dem SIGNALduino ggf. noch mitgeben, damit er auf die korrekte Frequenz switcht?
Ein Rolladen in Auszügen:
Internals:
...
DEF BE1601
IODev CUL1
LASTInputDev CUL1
MSGCNT 11
NAME VeluxSSL1
NR 531
STATE open
TYPE SOMFY
move off
CODE:
1 BE1601
READINGS:
...
2017-09-18 16:44:36 exact 0
2017-09-18 16:29:04 parsestate off
2017-09-18 16:44:36 position 0
2017-09-18 16:44:36 rolling_code 0095
2017-09-18 16:44:36 state open
Attributes:
IODev CUL1 # <--- hier habe ich eben auch CUL433 bzw. SIGNALEsp433 versucht
...
verbose 5
webCmd off:stop:on
Durch Verbose 5 erscheint im Log beim Senden sowas wie:
2017.09.18 16:43:58 4: SOMFY_set: VeluxSSL1 -> entering with mode :send: cmd :off: arg1 :: pos :0:
2017.09.18 16:43:58 4: SOMFY_set: handled command off --> move :off: newState :open:
2017.09.18 16:43:58 5: SOMFY_set: handled for drive/udpate: updateState :: drivet :0: updatet :0:
2017.09.18 16:43:58 4: SOMFY_sendCommand: VeluxSSL1 -> cmd :off:
2017.09.18 16:44:36 4: SOMFY_set: VeluxSSL1 -> entering with mode :send: cmd :off: arg1 :: pos :0:
2017.09.18 16:44:36 4: SOMFY_set: handled command off --> move :off: newState :open:
2017.09.18 16:44:36 5: SOMFY_set: handled for drive/udpate: updateState :: drivet :0: updatet :0:
2017.09.18 16:44:36 4: SOMFY_sendCommand: VeluxSSL1 -> cmd :off:
2017.09.18 16:44:36 5: SOMFY_sendCommand: VeluxSSL1 -> message :sA4200094BE1601:
16:43 wurde mit dem SIGNALEsp433 versucht, 16:44 mit dem CUL433.
Any hints, folks?
Hallo,
ich habe auch die Velux mit der FB des Types: 3UR D01 941920 und bringe die Steuerung nicht gekoppelt.
Leider finde ich nicht bezüglich der Frquenzen, hasst du schon etwas erreicht?
Nein, bei mir hat sich seitdem nichts getan, ich habe auch keine Tipps zum Einstellen des SIGNALEsp gefunden oder bekommen.
Kurzes Googlen nach 3URD01 führt mich aber zu "io HomeControl" - die sind m.W. mit CUL und Co ohnehin nicht zu empfangen oder zu steuern.
Kurzes Googlen nach io Homecontrol: "Die Funktechnologie arbeitet auf 3 Kanälen im Frequenzbereich von 868 MHz bis 870"
Zitat von: Pfriemler am 18 September 2017, 17:15:47
Prinzipiell funktioniert der 433er, er empfängt CUL_WS-Wetterdaten und sendet IT problemlos.
habe mal den Code zum Ändern der Frequenz beim Senden aus RFD-FHEM/SIGNALDuino (https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101) portiert.
Meine Sourcen findest du auf github branch dev-cc1101-cb (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb)
dort gibt es auch einen Bugfix für den Empfang von MC-Nachrichten.
!!! bin noch nicht zum Testen gekommen !!!Wenn dein 00_SIGNALduino.pm aktuell ist, dann sollte die Frequenz beim Senden automatisch umgestellt werden.
Frequenz für Empfang ändern
set signalESP cc1101_freq 433.42
edit 2: Fehler mit musterDec geklärt, hatte die libraries nicht aktualisiert.
edit 3: läuft, mal sehen was passiert ...
Sicher dass in Deiner 433er aculfw Somfy aktiviert ist ?
Hier
Zitat2017-09-13 17:26:54 cmds A B C e F f G i K L l M N R T t U V W X x
...
fehlt doch das Y für Somfy :-\
Zitat von: KölnSolar am 18 Oktober 2017, 21:33:06
Sicher dass in Deiner 433er aculfw Somfy aktiviert ist ?
Hier fehlt doch das Y für Somfy :-\
Jetzt wo Du es sagst ... Ich bin mir eben keineswegs sicher, ging aber verschiedentlich davon aus, dass das a-culfw längst beherrscht. Vielleicht begreife ich aber gerade in diesem Moment, dass
Zitat#### 1.20.06
- miniCUL: Code cleanup
- miniCUL: added more protocols (e.g. Belfox, Hoermann, Kopp FC, Somfy)
eben nur für miniCUL und nicht für nanoCUL gilt. Na toll. Den miniCUL hatte ich gerade wegen vermutlich schlechter Empfangsleistung weggelegt. Also von vorn...
Ich bin mir aber ziemlich sicher, dass der damals, mit der 1.21, auch nicht gesendet hat. Gut dass ich die alte DEF gesichert hatte. Da steht ein Y bei cmds.
Ich check das mal vor dem Neuflashen. Aber nicht mehr heute oder morgen. Stay tuned ...