Hallo,
ich habe ein wenig im Netz um im Forum gestöbert aber leider keine richtige Antwort gefunden. Ich versuche eine CMR 1000 über das Fhem zu schalten. Der Funkschalter sitzt im Außenbereich und der Rasperry natürlich im Haus. Leider bekomme ich kein Schalten hin. Nun bin ich am zweifeln woran es liegt ist die Einstellung falsch, hat der CMR 1000 eine Macke oder ist die Funkverbinung zu weit.
Ein paar Infos zum System
- Fhem läuft auf einem Raspberry
- CRM ist im Außenbereich, zwischen Fhem und CMR liegt eigentlich nur eine Außenwand und ca. 5 Meter Luftlinie
- Sduino schaltet die 433 MHZ, andere 433Mhz Steckdosen werden einwandfrei geschaltet
- bei der 433Mhz Antenne handelt es sich um eine Stabantenne für die Frequenz und diese steht auch frei im Raum
Einstellung im FHEM sind wie im Anhang zu sehen, Code am CMR 1000 steht auf E7.
Dar ich noch ziemlicher Anfänger bin, hoffe ich Ihr könnt mir weiterhelfen.
Beste Grüße
Matthias
Hallo Matthias,
Deiner Beschreibung nach hast Du (fast) alles richtig gemacht. Und Du hast auch die richtigen Vermutungen
Zitathat der CRM 1000 eine Macke oder ist die Funkverbinung zu weit
ZitatCRM ist im Außenbereich, zwischen Fhem und CRM liegt eigentlich nur eine Außenwand und ca. 5 Meter Luftlinie
Hier könnte der Grund begraben liegen. Um Probleme mit der Reichweite/Störsignalen auszuschließen, solltest Du den CRM erst einmal im Innenbereich testen.
Wenn es dann auch nicht funktionieren sollte, dann mit einer Fb testen, ob der CRM überhaupt i.O. ist.
Have fun
Markus
Hallo,
Erstmal Danke für deine Ideen. 50% konnte ich testen. Die Reichweite scheint es schonmal nicht zu sein, ich habe den raspberry mit einem Verlängerungskabel direkt unter den CMR gestellt, also Abstand vielleicht 2 Meter ohne Hinternisse. Leider ohne Erfolg. Die Option mit der Fernbedienung kann ich leider nicht testen, da ich keine habe.
Ich habe auch den Code nochmal verstellt und dabei die Codierscheiben mehrere Umdrehungen gedreht, da ich gelesen habe dass die Kontakte gerne korrodieren.
Habt ihr sonst noch Ideen wo der Fehler liegen könnte?
Beste Grüße
Matthias
Hallo,
So eine Fernbedienung habe ich organisiert und der CMR schaltet zuverlässig, auch vom Haus aus. Daher fällt der CMR sowie der Abstand beides aus. Muss also an der Programmierung von mir liegen. Kann mir hier jemand helfen.
Beste Grüße
Matthias
Ich vermute, es liegt am Protokoll. Bei mir wird V1 verwendet, du verwendest V3. Habe allerdings einen nanoCul433 mit Firmware V1.66. Einstellungen: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB.
Damit funktionieren aber nur die IT-Geräte mit Codierschalter. Die neueren (selbstlernenden, V3?) nicht.
Mehr kann ich dazu nicht sagen. Vielleicht kann jemand anders den Unterschied zwischen V1 und V3 erklären bzw. sagen, wie du den Sduino dazu bekommst, das V1-Protokoll zu verwenden.
Hast du das schon gelesen:
https://wiki.fhem.de/wiki/Intertechno_Code_Berechnung (https://wiki.fhem.de/wiki/Intertechno_Code_Berechnung)
Zitath vermute, es liegt am Protokoll. Bei mir wird V1 verwendet, du verwendest V3
Gutes Auge. V3 ist Quatsch. Das Attribut braucht es auch nicht.
Über die Definition ist es V1.
ZitatVielleicht kann jemand anders den Unterschied zwischen V1 und V3 erklären.
Ist ein ganz anderes Protokoll. Länger und dadurch variabler, weniger störanfällig.... Aber die Hardware(CMR mit Einstellrädern) ist halt V1.
Besten Dank, ich habe das Device nochmal neu erstellt und jetzt ist auch das v1 Protokoll eingestellt. Wenn ich jetzt über die Fernbedienung den CMR schalte (Ein sowie Aus), dann ändert sich im Device des Fhems der Zustand. Schalte ich aber am Fhem das Device, dann tut sich nichts. Die Kommunikation scheint doch daher schonmal zu laufen, aber warum schaltet dann der CMR nicht?
Beste Grüße
Teilerfolg.
Dann kann es nur noch am Sduino liegen. Da
ZitatSduino schaltet die 433 MHZ, andere 433Mhz Steckdosen werden einwandfrei geschaltet
u. die Reichweite gechecked ist, hab ich keine Idee. Bitte Mal ein list vom Sduino.
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
DMSG s0B80C0654800
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
FD 7
FUUID 6061fe55-f33f-0553-0630-67713da07114f556
IDsNoDispatch 2,72.1,82
ITClock 250
LASTDMSG s0B80C0654800
LASTDMSGID 0
MSGCNT 16232
NAME sduino
NR 15
NR_CMD_LAST_H 1
PARTIAL
RAWMSG MS;P1=573;P2=-2056;P3=-4097;P4=-9051;D=1412121212131213131312121212121212131312121212121212131312121312131213121213;CP=1;SP=4;R=3;O;b=117;s=5;m0;
RSSI -72.5
STATE opened
TIME 1658819550
TYPE SIGNALduino
cc1101_available 1
sendworking 0
version V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
versionProtocols 1.20
versionmodul v3.4.4_dev+14042020
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^\d+#.*
QUEUE:
READINGS:
2022-07-17 20:29:28 cc1101_config Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud
2022-07-17 20:29:28 cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
2022-07-17 20:29:29 cc1101_patable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2022-07-17 17:47:32 ping OK
2022-07-17 20:29:27 state opened
XMIT_TIME:
1658809800
additionalSets:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
Über den Sduino schalte ich verschiedene Steckdosen sowie die somfy Rolläden im Haus
Beste Grüße
Matthias
Versuche mal die Definition des CRM zu ändern: 00F00FF00F FF F0 statt 0F am Schluss. Das vorletzte FF ist für "on", das letzte F0 ist für "off". Vielleicht hilfts. So sieht es jedenfalls bei mir aus. Steht so auch in dem verlinkten Wiki.
Stimmt, da war ein Fehler, aber leider ohne Erfolg :'(
Bin ratlos. :-[
Ich würde jetzt mit verbose=5 Empfang u. Senden untersuchen. :-\
Was mir noch in deinem List des Sduino auffällt:
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
Bei mir steht da als Baudrate 38400. Versuchs mal damit.
Sollte das auch nicht helfen, dann bin ich mit meinem Latein leider auch am Ende.
Auch noch zwei Anmerkungen, die aber uU. auch nicht weiterhelfen:
a) der FTDI (A50285BI) ist ein Fake, von daher könnte es hilfreich sein, die Baudrate zu reduzieren. Da anscheinend das Empfangen klappt (und das Senden für Somfy), müßte wohl auch die firmware entsprechend neu kompiliert werden (meiner auf Prolific-Basis läuft auch @57600); sonst ggf. ganz die Hardware tauschen (würde was auf Maple-Basis empfehlen). Komisch ist auf jeden Fall, dass "opened" so "jung" ist (1 Sek.!).
b) Wenn da Somfy im Spiel ist, wird afaik zum Teil auch auf anderer Frequenz gesendet. Weiß nicht, ob da was auf dem CC1101 umgestellt wird, aber vielleicht kommen da auch Probleme her? Würde sicherheitshalber für diesen Teil einen separaten Transceiver verwenden (kann auch ein CC1101 an einem Mehrfach-Mapleduino sein).
ZitatBin ratlos. :-[
Ich würde jetzt mit verbose=5 Empfang u. Senden untersuchen. :-\
2022.07.27 11:27:41 3: sduino IT_set: Gartenbeleuchtung on 2022.07.27 11:27:41 5: sduino IT_set: Type=SIGNALduino Protocol=V1 2022.07.27 11:27:41 4: sduino IT_set: sendMsg=P3#is0F000F000FFF#R6 2022.07.27 11:27:47 3: sduino IT_set: Gartenbeleuchtung off 2022.07.27 11:27:47 5: sduino IT_set: Type=SIGNALduino Protocol=V1 2022.07.27 11:27:47 4: sduino IT_set: sendMsg=P3#is0F000F000FF0#R6 |
Einmal hier die auswertung vom Einschalten und anschließendem Ausschalten.
@ Beta-User und rih, besten Dank, werde mal die Baudrate verändern und probieren, den Rest muss ich erstmal schauen was ich davon machen kann. Bin noch eher ganz am Anfang von FHEM ;) ???
a) benutze bitte Code-Tags (der #-Button)
b) Hat sich der Zeitstempel von state ("opened") im Zusammenhang mit dem Senden aktualisiert? Wenn ja, ist das m.E. nicht gut, das Ding scheint sich zu resetten (meiner hat state/opened auf den Zeitpunkt vom letzten FHEM-Start stehen).
Zitata) benutze bitte Code-Tags (der #-Button)
zur Reduzierung der Baudrate? :o oder meintest du für das Einfügen vom Code im Forum?
Zitatb) Hat sich der Zeitstempel von state ("opened") im Zusammenhang mit dem Senden aktualisiert? Wenn ja, ist das m.E. nicht gut, das Ding scheint sich zu resetten (meiner hat state/opened auf den Zeitpunkt vom letzten FHEM-Start stehen).
nein opened status bleibt unberührt beim schalten, habe ich eben extra nochmal probiert
Zitat von: MaPae am 27 Juli 2022, 12:41:46
zur Reduzierung der Baudrate? :o
;D ymmd...
Für die Baudrate mußt du vermutlich nicht nur eine Zahl in FHEM ändern, sondern dazu auch die firmware selbst backen, spätestens das geht nicht so einfach von FHEM (oder dem Browser) aus. Aber wenn der "FTDI" sich nicht resettet, scheint (!) das nicht das Thema zu sein. Das Problem mit den fakes ist: Es ist tendenziell so, dass dem Vernehmen nach mit höheren Baudraten Übertragungsfehler zustande kommen. Ob das wirklich auch hier der Fall ist, kann dir vermutlich vorab keiner sagen...
ZitatZitat von: MaPae am Heute um 12:41:46
zur Reduzierung der Baudrate? :o
;D ymmd...
das beruhigt mich, hatte schon an meinen wenigen Kenntnissen gezweifelt ;)
habe noch einen busware mit 433 mhz, den müsste ich doch parallel betreiben können oder? Dann sollte das damit doch eventuell klappen. Oder ist der Versuch sinnlos? Will an dem Somfy Rolläden nicht zu viel ändern, da der Urlaub kurz bevor steht und da sollte das laufen.
IT V1 sollte afaik auch ein "Original"-CUL mit "normaler" culfw beherrschen. Wenn nicht, gibt es wohl auch eine Signalduino-Firmware (raduino?).
evtl passt auch die ITclock nicht
https://fhem.de/commandref_DE.html#ITclock
Bitte poste mal die MS Nachrichten die Du beim drücken der on- und off Taste empfängst
Die MS Nachrichten sehen ungefähr so aus:
MS;P2=1292;P3=-511;P4=389;P5=-1416;P6=-13975;D=46452345234523452345234523452345452323454545454545;CP=4;SP=6;
Gruß Ralf
Ah jetzt. Hab Dich schon vermisst.
Zitathabe noch einen busware mit 433 mhz, den müsste ich doch parallel betreiben können oder? Dann sollte das damit doch eventuell klappen. Oder ist der Versuch sinnlos?
Klar kannst Du den parallel betreiben. Ist doch prima zum Paralleltest. Achte nur auf das attr IODev ! Und die culfw drauf.
Zitatevtl passt auch die ITclock nicht
https://fhem.de/commandref_DE.html#ITclock
Bitte poste mal die MS Nachrichten die Du beim drücken der on- und off Taste empfängst
Die MS Nachrichten sehen ungefähr so aus:
Code: [Auswählen]
MS;P2=1292;P3=-511;P4=389;P5=-1416;P6=-13975;D=46452345234523452345234523452345452323454545454545;CP=4;SP=6;
Gruß Ralf
die nach dem Schalten an der Fernbedienung oder? aus dem Logfile oder? Hier bekomme ich dieses hier:
2022.07.29 13:13:12 3: sduino IT: Gartenbeleuchtung off->on
2022.07.29 13:13:12 3: sduino IT: IT_0F000F000F off->on
2022.07.29 13:13:14 3: sduino IT: Gartenbeleuchtung on->off
2022.07.29 13:13:14 3: sduino IT: IT_0F000F000F on->off
Im Device, welches ich ja über die Fernbedinung schalten kann und sich der Status im FHEM ändert steht dies hier: Hoffe das ist das richtige:
sduino_RAWMSG
MS;P0=-1121;P1=333;P2=1037;P3=-413;P4=-11615;D=14101010231010101010101023101010101010102310231010;CP=1;SP=4;R=15;O;b=41;s=1;m0;
MS;P0=-1121;P1=333;P2=1037;P3=-413;P4=-11615;D=14101010231010101010101023101010101010102310231010;CP=1;SP=4;R=15;O;b=41;s=1;m0;
Bitte teste es mal mit dem Attribut ITclock 330
Mega, das war es wohl. Jetzt funktioniert es über die Fernbedienung sowie über FHEM.
Ihr seid Klasse! Vielen vielen Dank!
Hi Ralf,
ich wusste doch, dass Du das sofort löst. ;)
Aber wo kommt die itclock=250(in Post#8) her ? Klar, dachte ich, aus der signalduino_protocols. Aber da steht -1=auto. ??? Was heißt denn auto beiim S'duino? IT-V1 ist eigentlich 400(glaub ich;420 lt aculfw).
Grüße Markus
Wenn im IT device kein Attribut ITclock gesetzt ist und in der Protokolldefinition bei clockabs -1 (auto) steht, dann wird beim 00_SIGNALduino Modul beim Senden eine ITclock von 250 verwendet.
if (!defined($clock)) {
$hash->{ITClock} = 250 if (!defined($hash->{ITClock}));
$clock=$ProtocolListSIGNALduino{$protocol}{clockabs} > 1 ?$ProtocolListSIGNALduino{$protocol}{clockabs}:$hash->{ITClock};
}
Gruß Ralf
Dann müsste man den Wert für IT doch eigentlich von -1 auf sagen wir Mal 350 setzen ?
Wundert mich, dass es nicht mehr Probleme mit Original IT und V1 gibt.(Ich selber betreibe sie ja mit RFXTRX und lausche nur mit S'duino auf einem Testsystem)
Grüße Markus
ZitatDann müsste man den Wert für IT doch eigentlich von -1 auf sagen wir Mal 350 setzen ?
Nein, wenn es nicht auf -1 stehen würde, dann würden nicht mehr alle Sensoren erkannt werden.
Bei der clockabs gibts bei der Erkennung eine Toleranz von 0,3
Bei 350 wäre das ein Bereich von ca 245 - 455 (350 x 0,3 = 105)
Es gibt auch Sensoren mit einer ITclock kleiner 200