[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

Moin zusammen.

ZitatWenn die Antwort auf ccconf jedes Mal anders ist, stimmt entweder die Verkabelung nicht, oder der CC1101 ist kaputt. Das solltest du prüfen, ob das wirklich nur "beim 868-er CUL" so ist (oder ob das nur zufällig so war, dass nach dem flashen ein Wackelkontakt auf diese Art erkennbar war).

Das heißt ich muss weiter "ausprobieren" und testen.

Ich werde heute Abend nochmal:

  • die PIN-Belegung erneut prüfen (und nur am 433 Modul, denn das interessiert uns ja nur)
  • nochmal die a-culfw downloaden, compilieren und flashen und mir dann die eingestelle Frequenz ansehen (ob die wieder zu hoch ist oder korrekt auf 433 steht) und natürlich testen mit der Fernbedienung

ZitatWenn Du schon die Verbindungen zwischen Arduino und dem CC1100 geprüft hast (bei dem Fehlerbild insbesondere GD00 und GD02) ist vielleicht tatsächlich der Sendeteil des CC1100 defekt.
Mit Sendeteil meinst Du damit dann auch den Empfänger, richtig?

ZitatUnd wenn du einen für 433MHz optimierten Transceiver verwendest, macht eine Firmware für 868MHz keinen großen Sinn. aculfw oder Signalduino sind da m.E. die einzigen beiden Varianten
Hol mich hier bitte nochmal kurz "für Dumme" ab :-D   Ich habe einen 433 Transreceiver. Aber ich dachte die a-culfw (oder auch die culfw) kann man "in den 433" Modus versetzen. Man muss vorher die board.h anpassen wenn ich das richtig verstanden habe.
Bei der a-culfw ist das in der board.h:
/* if you are using a CC1101 module for 868MHz disable the next line */
#if defined (nanoCUL433)
#define HAS_CC1100_433
#endif

und in der culfw ist das in der board.h:
/* if you are using a CC1101 module for 868MHz disable the next line */
/*#define HAS_CC1100_433*/

Habe ich irgendwo denn versehentlich eine 868 Firmware geflasht die ausschließlich für 868 Module ausgelegt ist?

Desweiteren habe ich folgende Idee.
Kann ich mir denn nicht auf einem Steckboard mal einen arduino Nano hernehmen, ein paar Steckkabel und dieses RXB6 Modul hier:
https://www.aliexpress.com/item/RXB6-433Mhz-Superheterodyne-Wireless-Receiver-Module-ARM-AVR/32712577501.html

Oder dieses RXB8 Modul hier:
https://www.aliexpress.com/item/RXB8-433Mhz-Superheterodyne-Wireless-Receiver-Module-Perfect-for-Arduino-AVR/32821761257.html

Diese mir auf dem Board zusammenstecken und damit die Codes der Fernbedienung empfangen und im Fhem anschauen?
Oder bin ich da total auf dem Holzweg.
Zum Arduino Nano mit einem RXB6 zum Beispiel habe ich nicht wirklich das konkretes im Netz gefunden bis auf das hier:
https://forum.pimatic.org/topic/202/4-homeduino-433-mhz-sending-receiving-and-even-more/2
Bin mir nun unsicher ob ich das mal einfach so zusammenkaufen/zusammenstecken soll als Versuch oder ob sich das nicht lohnt.
Dort ist von "Homeduino" die Rede. Ich frage mich wie gesagt ob ich die a-culfw "im 433 Modus" auf dem Arduino belassen kann und eben den RXB6 nehmen kann?

Kennt Ihr Euch damit aus, funktioniert das mit der aculfw und wäre das ein Versuch wert?
Was sind die Unterschiede zwischen dem RXB6 und dem RXB8 und wie finde ich raus welche für meine Idee kompatibel sind?
:-)

Beta-User

Zitat von: titanbird am 07 Mai 2018, 09:50:34
Hol mich hier bitte nochmal kurz "für Dumme" ab :-D   Ich habe einen 433 Transreceiver.
Nicht ganz: du hast auf dem Transceiver-Modul einen Chip, der - aus dem Kopf - alles zwischen 350MHz und 915MHz empfangen und senden kann. Wie gut das klappt, ist eine Frage der Dinge, die um den Transceiverchip "drumrum" verbaut sind (siehe Modulbeschriebung im Wiki), also vor allem der Antenne. Und eine 433-er Antennen-Beschaltung ist halt nicht (gut) für 868MHz geeignet. ABER: die SW ist im Kern dieselbe, wie eben auch der eigentliche Transceiver-Chip; es werden ggf. andere Standardeinstellungen vorgenommen und andere Protokolle aktiviert. Aber mit einer 868-er firmware eher keine aus dem 433MHz-Bereich ;) .

Also nochmal kurz gefaßt: Wenn du 433MHz haben willst, nimm die aculfw, bzw., wenn du Alternativen suchst stand das Stichwort "Signalduino" ja schon im Raum; da geht auch der RXBx. Es muß dann nur die jeweils passende firmware ausgewählt werden. Aber (a-)culfw und RXBx geht nicht...
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

OK, Merci :-)
Was ich jetzt gleich gemacht habe, hab mir bestellt:

  • (mein erstes) Steckboard
  • paar Kabel
  • ein FS1000A Sendemodul (dabei ist gleich ein billiges XY-MK-5V-Empfängermodul)
  • und gleich noch ein besseres RXB6 Empfangsmodul

Damit werde ich dann was zusammenstecken nach Anleitung und SIGNALduino nochmal sauber nach Anleitung flashen.
Sagen wir es so: Wenn dann immer noch nichts reinkommt wenn ich auf der Fernbedienung drücke, muss was anderes ganz faul sein, oder? ;-)
Eine Frage noch zur SIGNALduino Firmware:
ZitatEs muß dann nur die jeweils passende firmware ausgewählt werden.
Ich werde für die Testvariante auf dem Steckboard SIGNALduino verwenden. Muss ich hier auch noch auf eine "passende Variante" achten oder ist und bleibt SIGNALduino SIGNALduino?

Wie kann man sicherstellen oder testen, dass z.B. das Sende- und Empfangsmodul an meinem "433 CUL" defekt ist?
Ich habe letztens mal einen Raw Code an den CUL gesendet, der testet, ob der Empfang eingeschaltet ist.
https://wiki.fhem.de/wiki/CUL
Ist Empfang eingeschaltet ?
get myCUL raw C35 (13 = ja, z. b.: C35 = 0D / 13)

Da kam bei mir 13 bzw. "OK" zurück. Bedeutet das, dass mein CUL keine Defekte hat, wohl eher nicht?
Wisst Ihr denn ich tappe da ja schon sehr im dunkeln. Ist es die Firmware, die Verkabelung, oder doch ein Defekt (? zu viele Unbekannte :-D ). Wenn ich wenigstens ausschließen könnte, dass etwas defekt ist, wäre das schon mal was.
Natürlich kann ich auch 5 Mal etwas zusammenlöten / auf dem Board stecken und austesten, auch eine Möglichkeit :-D ;-)

Beta-User

Wenn über die firmware bzw. die Anfrage der raw-Codes was zurückkommt, ist das erst mal gut, dann ist zumindest der CC1101 richtig verbunden (Wackler aber nicht ausgeschlossen). Für einen ordentlichen Funktionstest müßte man irgendwas verwenden, von dem man weiß, dass es erkannt wird (IT-Fernbedienung).

Ob der diskret aufgebaute Signalduino mehr hergibt, wage ich zu bezweifeln, es bleibt eher bei dem hier:
Zitat von: Phantomato am 18 April 2018, 21:58:03
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.
Ergo: Kauf' ordentliche Funksteckdosen...
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

OK das klingt doch schonmal nicht verkehrt. Bei den Raw Codes kommt in der Tat immer was (sauberes) zurück.
Das zeigt sich im Log mit "(ReadAnswer)".

Ich weiß nicht, ob ich es schon erzählt habe. Aber mittlerweile habe ich "ordentliche" Funksteckdosen, also keine Baumarkteigenbausteckdosen sondern zumindest originale InterTechno IT-1500 aus dem Bauhaus.

titanbird

Hallo zusammen wieder :-)

Es gibt Neuigkeiten.

Zitat von: titanbird am 07 Mai 2018, 11:52:28

  • (mein erstes) Steckboard
  • paar Kabel
  • ein FS1000A Sendemodul (dabei ist gleich ein billiges XY-MK-5V-Empfängermodul)
  • und gleich noch ein besseres RXB6 Empfangsmodul

Erhalten und zusammengesteckt und getestet mir der SIGNALduino Firmware. Erfolge habe ich. Allerdings tun sich gleich wieder ein paar Fragen auf. :-D

Zunächst mal ein Bild von dem Board mit dem ich sauber empfangen kann (board.jpg).
Damit klappt es mit dem Empfang, da kommt viel im Log (er versucht den empfangen Code zu erkennen und das richtige Protokoll (Flamingo, IT, usw.) zu finden).

Senden klappt nicht (vermute ich). Denn FHEM hat die IT-Steckdose als ich sie mit dem ON-Knopf angelegt habe automatisch als Device angelegt. Wenn ich on/off anklicke in Fhem rührt sich die Steckdose nicht (aber auf dem Arduino blinken die LEDs und zeigt kurz eine Aktivität an).

Fragen:

  • Mein Sendemodul sieht anders aus als ein Bild was ich im Netz gefunden habe. Bei mir fehlt im Vergleich eine der beiden Spulen. Siehe Bild meines Empfängers sender1.jpg und das Bild aus dem Netz sender2.jpg. Ist da was faul oder sieht das OK aus?
  • Ich habe eine kleine Antenne mitgeliefert bekommen. Ich weiß nicht mehr ob die für den Empfänger oder den Sender bestimmt ist :-D Sollte ich die an den Sender löten? Wenn ja: Dort ist der Lötpunkt mit ANT gekennzeichnet. Welches der Lötstellen ist aber die richtige? Ich vermute das kleine Loch direkt beim "T" von "ANT"?
  • Wo würdet Ihr den Fehler jetzt noch suchen, eher bei der Hardware (Sendemodul) oder fehlt einfach die Antenne am Sendemodul oder liegt es jetzt nur noch an der FHEM-Config (Sendecode usw.)? Beim Versuch die Steckdose über FHEM einzuschalten habe ich die Steckdose lediglich 10 cm vom Sendemodul entfernt gehabt.
  • Der Empfang klappt aktuell nur mit dem RXB6. Wenn ich das RX-RM-5V (siehe empfänger1.jpg) drin eingebaut habe bekomme ich gar nichts rein (egal wie nah ich mit der Fernbedienung bin). Der Arduino Nano blinkt dann auch nicht (logisch). Darf man hier sagen dass RX-RM-5V wirklich einfach Billig-Schrott ist und das ganz normal ist dass nichts tut?

Vielleicht könnt Ihr mir noch mehr Klarheit in diese Fragen reinbringen... :-) Würde mich freuen.
Wie würdet Ihr nun an meiner Stelle weitermachen um mal eine Steckdose über FHEM und dem Board zum Schalten zu bekommen?


Grüße!

Beta-User

Zunächst ist es immer eine eher schlechte Idee, Sender ohne Antenne zu betreiben. Habe "das andere" Modul mal im Einsatz gehabt, von daher würde ich behaupten, dass die Antenne auch bei diesem Modul in das Loch oben rechts gehört (also verwirrenderweise das Loch, das am weitesten von "Ant" weg ist...).

Also erst löten, dann sehen wir weiter.

Und ja, dieses "andere" Empfangsmodul gehört auch m.E. in die Kategorie Elektroschrott....
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

Moin, Merci. Dort habe ich sie sauber dran gelötet.
Klappen tut es leider noch nicht. Gleicher Effekt, Arduino Blinkt kurz auf, im Log steht dass was in die Send Queue gestopft wurde und dann auch raus ging, ITclock 250, diesen Wert habe ich testhalber auch auf 230 mal gesetzt. Kein Erfolg.

Anbei ein Foto bei ebay wie das Funkmodul laut Foto aussehen sollte... (ebay.jpg).
Aber ich vermisse dort diese 2. Spule, die sehe ich über all auf den Bildern im Netz. Dezent angemerkt: WTF?!?! An der wird es wohl doch liegen?

Beta-User

Leider kann ich dir nicht sagen, ob es an der fehlenden Spule liegt; du kannst ja den Test machen und einfach einen gewickelten Draht reinlöten - schlechter wird es kaum werden...

Ansonsten sollte es so klappen, wie von dir beschrieben: Bei den von autocreate erstellten Devices auf "on" bzw. "off" klicken, das sollte es gewesen sein. Vielleicht postest du die lists von den IT-Devices mal, dann kann sich jemand das ansehen, der davon mehr versteht als ich. Testweise kannst du dafür ja mal den 868-er CUL als IO definieren (die IT-Definition sollte damit auch unverändert funktionieren).

Ansonsten solltest du den Sender doch wechseln, wobei ich insgesamt zur CC1101-Variante raten würde. "Eigentlich" ist das stressreier.
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

Schlecht Nachricht zu erst: Das mit dem Draht hat nicht funktioniert. Werde es umtauschen oder einfach ein neues kaufen.

Jetzt kann ich mal behaupten es gibt gute Nachrichten.

Ich habe aber sehr viel rumprobiert.

SIGNALduino: Arbeitet super :-) Er snifft alles und schreibt's ins Log was er nur zu lesen bekommt.
Senden geht nicht... Siehe erster Satz.

Zum ersten mal hat sich was getan als ich per autocreate, wie Du es geschrieben hast, das Gerät so behalten habe und dann den 868er CUL angeschlossen habe. Erfolg!
Aber: Ich hatte ja am Anfang hier mal geschrieben dass der 868er spinnt. ccconf gibt immer wieder Werte aus von 0 MHZ bis 8000 und mehr MHZ. Zwischendrin als ich oft versucht habe zu senden hat er sogar die Verbindung verloren und sich dann wieder initialisiert. Hier muss ein Wackler oder Defekt vorliegen wie schon richtig angenommen wurde. Die Verlötung war nicht gut oder das Sendemodul hat eine Macke gehabt.
Jetzt kann ich es leider nicht nochmal neu anlöten bzw. die Kabel ins Board stecken um auf dem Board "sicherzugehen" dass es wirklich eine Macke hat oder nicht. Denn:
Mir passiert es schon zum dritten mal dass die Lötstellen an der Platine des Sendemoduls abreißen wenn ich etwas zu fest an einem Kabel ziehe, z.B. um es herunterzubiegen.
Ich löte aktuell halt erst seit kurzer Zeit intensiver, ich denke da fehlt Übung. Dieses Modul werfe ich jetzt knallhart weg und bestelle mir neue.
Ich behaupte jetzt mal, das Ganze funktioniert! Und es liegt an dem Problem des CULs dass es sporadisch mal funktionierte, und mal nicht... Also OK! Muss einfach nur einen neuen bauen und gescheit löten!

Dann habe ich weiter gemacht. 433 CUL dran, "ON" geklickt... Nichts tut. Gar nichts. Die LEDs blinken kurz, in FHEM wird angezeigt dass was "rausgeschickt" wurde, sah alles OK aus, aber die Steckdose: Arbeitsverweigerung! Da dachte ich mir, jetzt prüfst Du mal alles schön weiter. Also, alles abgelötet, Kabel frisch dran gelötet ("gewissenhaft") und die Kabel aber ab ins Board und per Steckkabel an den Arduino Nano. Frisch geflasht... Klick auf "ON". Works! Und zwar bei allen Versuchen ohne "Fehlzündung"!.

Übrigens: Bei meinen Tests habe ich immer folgende Szenarien probiert:
Steckdose: 20cm entfernt, 2.5m entfernt, 4.5m entfernt + eine Wand und Bett dazwischen, 6m entfernt schräg durch 1 Wand, 7.5m entfernt durch 1-2 Wände und schräg. Bei allen versuchen: WORKED! Ohne Probleme.



Was mich wundert:
SIGNALduino empfängt immer fleißig wenn ich auf der Fernbedienung drücke. Aber ich muss ganz oft drücken und nach einigen malen (Zufall?) legt er dann ein Gerät an. Ab und zu schreibt er ins Log sowas in die Richtung: "UNDEFINED IT blah blah". Warum ist das da so sporadisch und funktioniert nur manchmal, ist das normal?
Und mich wundert dass ich so schlecht löten kann, hab mir eigentlich Mühe gegeben... Kein CUL hat zu  100% funktioniert was ich da verbrochen habe...  :-X  ;D ;D

titanbird

Ich wollte mich an dieser Stelle einfach nochmal für Eure Unterstützung bei meinen Startproblemen bedanken! Ihr habt mir sehr gut weitergeholfen.  :D

andies

Ich hatte mit diesen Empfängern massive Probleme, die haben einfach nichts sauber empfangen (damals noch mit pilight, steht irgendwo auf deren Seite im Forum und kann ich bei Bedarf raussuchen, wenn dich das interessiert). Bei IT Geräten musst du beim Signalduino eventuell die ITclock einstellen, bei mir geht 290 stabil. Alles andere ist unzuverlässig.

PS https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=164177&start=50
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

Merci. Ja wenn Du das raussuchen könntest wäre das super.
Empfangen war eig. von Anfang an möglich bei mir wenn ich richtig sauber gelötet bzw. dann beim "Verlegen" der Kabel aufgepasst hätte :)

Einzige Seltsamkeit: Ich musste mit der IT-Fernbedienung häufig drücken. Oft kam unknown code aber irgendwann hat er sie erkannt und als Device angelegt... Sind das die Probleme, die Du gerade angesprochen hast die mit der ITclock gelöst werden können?

andies

defmod Steckdose_A IT 0FF000FFFF 0F F0
attr Steckdose_A IODev sduino
attr Steckdose_A ITclock 302

Ja, Probleme sind gelöst. Link steht oben.
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

Beta-User

Zwei Dinge sind hier m.E. noch offen:
@titanbird: Ist dein Problem jetzt gelöst - dann bitte den Thread entsprechend kennzeichnen.

[OT]
@mark79: Zwischenzeitlich alle offenen Fragen zum Rock64 soweit gelöst? (Bislang tauchte nichts in den "neuen Seiten" im Wiki auf ;) )
[/OT]
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