[gelöst] Wieder ein Anfänger mit 433 Selbstbau-nanoCUL (Empfangen unmöglich)?

Begonnen von titanbird, 18 April 2018, 18:33:16

Vorheriges Thema - Nächstes Thema

titanbird

Hallo an alle.

Bin neu in der Hausautomatisierungswelt.
Fhem habe ich mir soweit ohne Geräte bisher "eingerichtet" auf einem Server (NAS).
Auf dem PC habe ich mir Fhem ebenfalls installiert um erstmal rumzuspielen (Testumgebung).

Nun versuche ich mich an CMI Obi Steckdosen. Diese sind Selbstlernend und fungieren auf 433.92 MHz. Mit Fernbedienung. Im Set sind 3 Steckdosen.

Gesendet habe ich noch nichts erfolgreich... Ich muss erstmal den Homecode der Steckdosen "sniffen".
Wenn ich alles richtig verstanden habe!

Den CUL habe ich mir selber zusammengelötet. Die Verlötung habe ich triple-checked.

Geflasht hab ich a-culfw. Mein PC erkennt den nanoCUL also und in Fhem konnte ich das Gerät anlegen mit:
define CUL CUL /dev/ttyUSB0@38400 1234

Weitere Eingaben von mir:
verbose: 5
rfmode: SlowRF
model: nanoCUL


Zudem habe ich mal set raw x67 probiert (Debugmodus?) bzw. wieder zurück auf X27.

Dabei habe ich immer wieder zum Versuch auf die ON oder OFF Taste auf der Fernbedienung gedrückt. In Fhem tut sich rein gar nichts in dem Moment.

Genauere Infos zu der Hardware des Sticks:

  • CC1101 Wireless RF Transceiver 315/433/868/915MHZ + SMA Antenna Wireless Module
  • Arduino Nano V3.0 controller ATMEGA328P ATMEGA328 original FT232RL +USB cable

Weitere Infos zum CUL in Fhem:
FHTID: 1234
STATE: Initialized
TYPE: CUL
VERSION: V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
initString: X21
CUL ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB


Jetzt die Frage an Euch Cracks:
Was kann ich tun? Woran könnte es hapern?
Ziel wäre es doch erstmal, dass ich etwas sehe was der CUL empfängt? Um dann weiter zu machen. Please help ;-)
Wenn ich zu wenige Infos gegeben habe, bitte fragt mich, ich spuck sie sofort aus.

KölnSolar

Dann fangen wir mal mit dem richtigen Subforum an:Bitte den Post nach CUL/Hardware u. Firmware verschieb(Button unten links)

Auf den ersten Blick sieht der nano OK aus. Stell mal ein list ein.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

andies

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

titanbird

Scusi. Hab ich erledigt.

Gern. Also ein
list CUL
bringt mir aktuell
Internals:
   CFGFN     
   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:
   DEF        /dev/ttyUSB0@38400 1234
   DeviceName /dev/ttyUSB0@38400
   FD         11
   FHTID      1234
   NAME       CUL
   NR         58
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-04-18 18:35:12   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-04-18 18:00:59   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-04-18 17:55:00   fhtbuf          No answer
     2018-04-18 17:54:53   raw             No answer
     2018-04-18 18:00:59   state           Initialized
     2018-04-18 17:54:46   uptime          0 00:00:25
     2018-04-18 17:55:35   version         V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
Attributes:
   model      nanoCUL
   rfmode     SlowRF
   verbose    5

Phantomato

Zitat von: titanbird am 18 April 2018, 18:33:16
Nun versuche ich mich an CMI Obi Steckdosen. Diese sind Selbstlernend und fungieren auf 433.92 MHz. Mit Fernbedienung. Im Set sind 3 Steckdosen.

Nun ja.. klingt fast so als wären diese steckdosen nicht InterTechno kompatibel. InterTechno sollte out of the box gehen. Alles andere wird kompliziert und Glückssache. Andere Vorschläge: Signalduino firmware nehmen oder den RFLink.

https://forum.fhem.de/index.php?topic=31997.0
Server: RaspberryPi4 4GB @Raspbian GNU/Linux 10 (buster), Docker, FHEM Docker | Homematic nanoCUL868 (VCCU) | Tasmota Switch & Sensors | Tasmota Zigbee | Zigbee2mqtt | SIGNALduino | Alexa & GoogleHome

titanbird

Danke für die Infos und den Link.
Den Link habe ich mir letztens schon angeschaut und habe zu Beginn probiert zu senden um die Steckdose im Lernmodus ansprechen zu können. Da hat sich nichts getan.
Daher wollte ich nun selbst zum Lesen kommen.

Hab im Wiki gelesen. So wie ich es verstanden habe kann ich aus meinem 433 CUL einen SIGNALduino machen mit der richtigen Firmware und sollte dann empfangen können.

Das hab ich eben gemacht:
update
shutdown restart
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
define SIGNALduino SIGNALduino /dev/ttyUSB0@57600
State war dann bei dem Device: Opened
attr SIGNALduino hardware nanoCC1101
attr SIGNALduino verbose 5
attr SIGNALduino debug 1
set SIGNALduino flash

Ein
list SIGNALduino
gibt gerade:
Internals:
   CFGFN     
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/ttyUSB0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/ttyUSB0@57600
   FD         4
   LASTDMSG   nothing
   NAME       SIGNALduino
   NR         31
   PARTIAL   
   STATE      opened
   TIME       1524087265
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   versionmodul v3.3.3-dev_17.04.
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     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   ^u30#.*
     18:FLAMINGO ^P13#[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
     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 ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-04-18 23:49:18   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-04-18 23:49:32   cmds             V R t X F S P C r W x e
     2018-04-18 23:49:36   config          MS=1;MU=1;MC=1
     2018-04-18 23:53:41   ping            OK
     2018-04-18 23:47:48   raw             ccFactoryReset done
     2018-04-18 23:54:01   state           opened
     2018-04-18 23:54:01   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     65
     68
     7
     72.1
     80
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     75
     79
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    5


Ich habe dann noch ein paar mal auf der Fernbedienung gedrückt (diese zeigt mit einer LED dass sie tut und dann wohl auch was sendet) aber im Eventmonitor oder Logfile in Fhem sehe ich in dem Moment gar nichts auftauchen.

Hab ich hier was falsch gemacht?

Beta-User

Bei diesen 433MHz-Dingern ist es nicht selten ein Ratespiel. Vielleicht kommst du damit weiter: https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

Da wird's für meine Verhältnisse kompliziert.
Kann es eigentlich auch sein, dass eine Lötstelle doch nicht ganz korrekt ist oder dass das Funkmodul einfach tot ist? Kann durch das Löten durch die Hitze ein Element schaden auf der Platine davongetragen haben?
Ist es so, dass bei gänzlich unbekannten Geräten gar nichts geloggt wird (Receive) oder sollte eigentlich mit dem SIGNALduino immer etwas im Log zu sehen sein?

Habe hier noch einen Selbstbau 868 CUL, mit dem gleichen Model des Arduinos, nur eben mit anderem Funkmodul:
CC1101 Wireless Module Long Distance Transmission Antenna 868MHZ M115 For FSK GFSK ASK OOK MSK 64-byte SPI Interface Low Power
Kann man den denn für diesen Zweck auch ausprobieren und die 433 a-culfw drauf flashen?

KölnSolar

ZitatKann es eigentlich auch sein, dass eine Lötstelle doch nicht ganz korrekt ist oder dass das Funkmodul einfach tot ist? Kann durch das Löten durch die Hitze ein Element schaden auf der Platine davongetragen haben?
Kann natürlich immer oder der CC1101 war schon defekt. Deshalb ist es immer ungünstig den 1. Funktionstest mit eher unbekannten Geräten auszuführen.
ZitatKann es eigentlich auch sein, dass eine Lötstelle doch nicht ganz korrekt ist oder dass das Funkmodul einfach tot ist? Kann durch das Löten durch die Hitze ein Element schaden auf der Platine davongetragen haben?
Sowohl CUL als auch S'duino würden immer etwas loggen, wenn mit der richtigen Frequenz u. Modulationsverfahren(slowRF) etwas empfangen wird. Der S'duino ist für unbekannte Protokolle besser, weil man mit ihm auch empfangene Signalfolgen von ungewöhnlichen Protokollen "einfach" senden kann.

Beim Suchen habe ich den gefunden. Demnach scheint auch die Artikel-Nr. eine Rolle zu spielen, um welches Protokoll es sich handelt. Der Code des letzten Posts hat auf jeden Fall nicht annähernd etwas mit IT-Protokoll zu tun, sollte aber mit dem S'duino funktionieren.

ZitatKann man den denn für diesen Zweck auch ausprobieren und die 433 a-culfw drauf flashen?
Kannst Du. Hat halt nur ne schlechte Reichweite.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

titanbird

Danke :-)
Der eine Eintrag ist schon interessant, zwecks Benutzung der Soundkarte ;-)

Als ich mir Deine Antwort nun durchgelesen habe, bin ich zu dem Entschluss gekommen, dass ich erst einmal eine Steckdose oder ein Set mit DIP-Schaltern holen muss von einem "bekannten" Hersteller.
Dann testen. Dann kann ich sicher gehen, dass die Steckdosen tun sollten und weiß danach ob mein Funkmodul generell tut oder nicht.

Kannst Du mir günstige 433 Steckdosen empfehlen, die 100% mit Fhem gut und einfach funktionieren?
Damit ich mir diese mal in den Besitz hole und damit einen Test machen kann. Wäre hilfreich

dkreutz

Zitat von: titanbird am 19 April 2018, 09:32:32
Kannst Du mir günstige 433 Steckdosen empfehlen, die 100% mit Fhem gut und einfach funktionieren?
Damit ich mir diese mal in den Besitz hole und damit einen Test machen kann. Wäre hilfreich

Einen von Intertechno, z.B. das IT-1500 3er-Set. Gibt es in vielen Baumärkten (z.B. Bauhaus).
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

titanbird

Prima, ein Bauhaus haben wir und die führen die Dosen und sind vorrätig. Werde mir so ein Set holen und wieder berichten.
Wobei die IT-1500 sind bei denen als selbstlernende geführt. Mit DIP-Schalter wär's aber erstmal besser?

KölnSolar

ZitatMit DIP-Schalter wär's aber erstmal besser?
Das ist egal. Hauptsache Du kannst den Empfang testen. S'duino und CUL können beide Protokolle: Dip(IT-V1) u. selbstlernend(IT-V3).
Etwas günstiger aber nur per Post gibt es diese Dosen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

titanbird

Werde es mal mit original Intertechnos probieren. Theor. sollte ja direkt was lesbar sein wenn ich die Fernbedienung davon drücke. Das probiere ich wie gesagt heute Abend auch mal mit dem 868er CUL aus (ich versuche da 433 zu flashen).

Beta-User

Zitat von: titanbird am 19 April 2018, 13:27:48
(ich versuche da 433 zu flashen).
Den brauchst du m.E. nicht umzuflashen, der kann auch so 433MHz senden (und vermutlich auch empfangen), wenn ccconf entsprechend eingestellt ist (und rfmode). Das mit der Frequenzumstellung erfolgt btw auch, wenn über einen 868-er 433-er Signale gesendet werden.

Letzteres ist aber nicht so besonders zu empfehlen, da jedesmal ins EEPROM geschrieben wird. Steht glaube ich auch irgendwo im Wiki.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files