[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

mark79

Ich würde dir lieber WLAN Steckdosen empfehlen, das läuft weitaus besser, ist verschlüsselt und man erhält eine Rückmeldung ob geschaltet wurde.
Z.B. eine Sonoff S20 Steckdose, oder von Obi eine WiFi Steckdose für 9,99€ https://www.obi.de/hausfunksteuerung/wifi-stecker-schuko/p/2291706
Es gibt noch einige mehr, ich glaube mit bis zu 3 Relays als Steckdosenleisten. Wichtig ist nur, das ein ESP8266 dort drin steckt.

Löten kannst du ja und dann einfach Tasmota oder Espeasy drauf flashen und dann hast du was zuverlässiges...
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 19 April 2018, 22:29:47
Z.B. eine Sonoff S20 Steckdose, oder von Obi eine WiFi Steckdose für 9,99€ https://www.obi.de/hausfunksteuerung/wifi-stecker-schuko/p/2291706
Kennt jemand da eigentlich den Eigenverbrauch von den Teilen (mal abgesehen davon, dass dafür auch die ganze Netzwerkinfrastruktur zwingend laufen muß)?

Da sind übrigens die Baumarktsteckdosen teilweise auch nicht besser.

Wenn schon "was richtiges mit Rückkanal", dann würde ich aus diesen Gründen überlegen, ob es nicht sinnvoller ist, gleich auf "richtige Hausautomatisierungstechnik" zu setzen. Funksteckdosen mit Rückkanal gibt es nach meiner Kenntnis in jedem größeren Programm, Eigenverbrauch typischerweise <0,5W...

Just my2ct
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

mark79

Zitat von: Beta-User am 19 April 2018, 22:52:11
Kennt jemand da eigentlich den Eigenverbrauch von den Teilen (mal abgesehen davon, dass dafür auch die ganze Netzwerkinfrastruktur zwingend laufen muß)?

Da sind übrigens die Baumarktsteckdosen teilweise auch nicht besser.

Wenn schon "was richtiges mit Rückkanal", dann würde ich aus diesen Gründen überlegen, ob es nicht sinnvoller ist, gleich auf "richtige Hausautomatisierungstechnik" zu setzen. Funksteckdosen mit Rückkanal gibt es nach meiner Kenntnis in jedem größeren Programm, Eigenverbrauch typischerweise <0,5W...

Ich habe selber nur mal mit einem Schätzeisen nachgemessen, wie er hier: https://www.youtube.com/watch?time_continue=1&v=iljg4oaH9O4
und ich komme auf die selben Ergebnisse.

Wegen der Netzwerkinfrastruktur.. Einen Router und Fhem Server, hat man ja denke ich eh am laufen. Mehr braucht man nicht.  :)

Wenn man Energie sparen möchte, kann man ein 4CH Sonoff verwenden, also 1x ESP mit 4 Relays. Anstatt 4 einzelne WiFi Steckdosen. Von denen habe ich mittlerweile zwei im Einsatz.
Ist halt nur mehr arbeit, das unterzubringen...

Ein weiterer Vorteil ist noch, das man Sensoren anschließen kann (Temperatursensoren oder Bewegungsmelder etc.) und das man es einfach über ein Webinterface konfigurieren kann.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

[Sorry für OT]
Na ja, 1,6-1,7W im "Normalbetrieb" ist nicht die Wucht, war aber nach den Specs des ESP8266 zu erwarten. Und dass das Netzteil an sich schon ca. 0,6W schluckt, ist m.E. auch nicht unbedingt state of the art. Wie viele von deinen ESP's hast du auf diese Art schlafen gelegt?

Was Netz angeht: "Hat man eh' am Laufen" ist schon richtig, aber an sich sollte man HA-Netz und den Rest (mind. logisch) trennen, und - so wie mark79 es beschrieben hat, benötigt man eben (mind.) genau das eine Gerät mehr (Router, ggf. weitere Switches und AP's). Nur wenn du den Server direkt als AP verwendest, müssen - ähnlich wie bei Kauflösungen nur zwei Geräte grade Strom haben, dass das ganze funktioniert.

Und dass die Welt im Übrigen für Bastler noch größer ist (und nicht nur beschränkt auf Bewegungsmelder und Temp-Sensoren), ist klar, aber da gibt es auch noch andere Optionen wie Asksin++, MySensors, KVP.... Nur zur Klarstellung: Modifikationen an Sonoff & Co können zu Problemen mit der Versicherung führen.

Damit sollten wir diesen OT-Exkurs aber wirklich beenden ;) .
[/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

mark79

1,7 Watt wenn das Relay angezogen ist und mit original Firmware. Baumarkt Funksteckdosen kommen da vermutlich auch über 1 Watt Verbrauch. :)

Wenn man bei den WiFi Steckdosen die originale (Cloud) Firmware runterhaut und stattdessen ESPeasy oder Tasmota (Opensource Firmware) drauf flasht, sehe ich keinen Grund das Netz abzusichern.
Weil das Gerät ab dann gar nicht mehr mit einer externen Cloud spricht, sondern alles lokal im Netz bleibt. Es gibt ein Fhem Modul für ESPeasy, oder halt über MQTT.

Der Nachteil ist dann nur noch, das die Hersteller APP fürs Handy nicht mehr funktioniert.
Aber auf die APP kann man gut verzichten, ich habe mir die selber noch nie angeschaut, weil man alles mit Fhem oder alexa schalten kann.
Dazu haben die Steckdosen mit der neuen Firmware auch eigenständige und mächtige Funktionen: https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

Ich habe von 7 WiFi Aktoren, bei 6 den Sleep Modus aktiviert. Das geht glaube ich nur bei der Tasmota Firmware.
2x 4CH, 2x Touch, 1x TH16 1x S20 Sonoffs und 1x Obi WiFi Steckdosen

Ich habe auch mit Funk angefangen, nanoCUL/Signalduino und dazu später noch pilight, viel gelernt, aber mittlerweile verfluche ich das ganze 433MHZ Zeugs:
Bei einer Funksteckdose bzw. Marke konnte der Nachbar mit seinem VW Autoschlüssel die Steckdose schalten.
Einige 433 Kerui Fensterkontakte senden bei Kälte nur noch einen "auf" Status.
Dann habe ich einen Funkschalter, welcher ziemlich schwach auf der Brust sendet und öfters die Signale nicht ankommen.
Und manche 433 Funkthermometer haben des öfteren auch Aussetzer. Die werde ich bald durch ein BME280/AMS2302 Sensor ersetzen, der jeweils an einer Sonoff Steckdose via 2,5mm Klinkenkabel hängt.

MySensors habe ich auch hier liegen, aber bisher noch nicht wirklich dazu gekommen was umzusetzen.
Ist ja nicht ganz OT, er ist noch neu und damit zeigt man ihn die anderen (neuen) Möglichkeiten auf. :)
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

[OT]
Es ist und bleibt hier OT. @TE: Bitte ggf. um klare Worte, wenn dich das nervt (habe aber eigentlich dann auch wirklich fertig).

Nur, um diesbezüglich keine Mißverständnisse aufkommen zu lassen:

Ich bin auch definitiv _kein_ Fan von dem 433MHz-"Gruscht" und stimme @mark79 dahingehend zu, dass sogar die WLAN-Geräte in vielen Fällen besser sind als dieser 433-er Mi*t. (Evtl. Qualitätsware ausgenommen, damit sich hier keiner veranlaßt sieht, "ja aber..." zu sagen).

Ob man getrennte Netze haben sollte, darüber kann und darf man lange streiten. Viele von den "langjährigen" Usern, vor allem, wenn sie aus der Admin-Welt kommen (ich bin nur User, siehe Nickname!), scheinen die Trennung tendenziell zu bevorzugen. Mir ist das zu viel Aufwand, u.A. deswegen meide ich WLAN-Devices, aber dennoch ist "mein" Netzwerk eben auch das meiner Familie - da ist leider nicht ganz auszuschließen, dass immer mal wieder Geräte auftauchen, die da nix zu suchen haben (Für was richte ich ein Gastnetz ein?!?). Solange jemand eigenwillige JSON-Strings senden können müßte, um das Licht auszuschalten oder die Stereoanlage lauter zu drehen, geht das grade noch, aber es nervt mich schon, dass es trouble gibt, wenn ich das Passwort ändern will, die Fritte spinnt, alles mögliche nach Hause telefonieren will usw.. Also: Bogen drum, lieber direkte Anbindung. Ich hatte das "Glück", vor ESPEasy mehrere ESP in der Hand gehabt zu haben und wegen deren Zickigkeit dann rechtzeitig bei MySensors gelandet zu sein :) .

Von daher: Viel Spaß beim Einarbeiten in das Thema, und vielleicht kommen wir in ein paar Jahren mal dazu darüber zu quatschen, was wir alles besser anders gemacht hätten. Ich hätte mir neben der ESP-Geschichte diverse Versuche mit PI-GPIO's sparen sollen.
[/OT]

Partly back to topic :
Besser Finger weg von PI-GPIO's (Stichwort pilight). Das ist - abgesehen vom HM-PI-Modul und einer RTC - für Anfänger m.E. zu anfällig, da die sehr prozessornah sind. Ich habe mir jedenfalls den ersten PI mit Geh-Versuchen mit 1wire teilweise zerschossen. Außerdem halte ich die damit einhergehende Vermischung von Steuerungslogik und Hardware für tendenziell problematisch; ich bin jedenfalls sehr froh, dass ich _keinen_ PI mehr als Server einsetze.

Wieder nur just my2ct.

Grüße jedenfalls,

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

mark79

Bzgl. Pilights, das stimmt.. Ich hatte die Funk Hardware auch anfangs an den GPIO Ports betrieben, aber da ging die CPU Last ziemlich in die Höhe. Abhilfe schaffte ein Arduino Nano dazwischen zu schalten.
Das ganze ist ein ziemliches gefrickel und ich will auch von pilight weg. Aber mir blieb anfangs keine Wahl, weil ich 3 Temperatursensoren (von Pearl) nur mit pilight zum laufen bekommen habe.
Nach dem Umstieg von RPi1 zum Rock64, ist mir der pilight Daemon vor kurzem Amok gelaufen und hat auf einen Core 100% CPU Last erzeugt und die CPU Temp war fast bei 80 Grad. Zum Glück hatte ich mir ein TEMP Warnung als Benachrichtigung eingerichtet.

Getrennte Netze kann man ja machen, ich habe es nicht umgesetzt und halte das auch nicht für nötig. Besonders nicht, wenn man auf unverschlüsselte Funk Kommunikation setzt.
Man kann in ESPEasy oder Tasmota ein Backup WiFi Netzwerk konfiguieren. Wenn man das WLAN Kennwort wechseln möchte, würde das auch schnell über die WPS Funktion klappen.

Zickig laufen die ESPs bei mir nicht, sondern im gegenteil sehr stabil und zuverlässig. Vielleicht hattest du nur Pech, oder hast es am Anfang der Entwicklung ausprobiert.
Ich habe noch mehr ESP für IR Transmitter, oder als BLE Anwesenheitskontrolle, ESP_HMUART und einer steckt sogar im Briefkasten mit 2 AA Eneloops und die Batterien halten auch mehr als ein Jahr durch.

Das beste wäre natürlich alles über Kabel anzubinden, falls ich mal ein Haus bauen sollte, dann.... :)

So ich bin jetzt aber auch raus, wurde alles gesagt und wir sind uns in bestimmten Punkten sogar einig.  ;)

Wünsche allen ein schönes Wochenende!


Viele Grüße
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

[definitiv OT, sorry]
Hast du für die Pearls auch mal die dev-Version vom Signalduino ausprobiert?
Wenn das noch nicht implementiert ist, kann evtl. sidey&co helfen, die Hardware scheint ja doch eine gewisse Verbreitung zu haben.

Was deine Server-Hardware angeht: Jedenfalls auf den ersten Blick sieht die HW valide aus. Vielleicht magst du einen Eintrag für https://wiki.fhem.de/wiki/Kategorie:Server_Hardware erstellen? (Kann auch ein Thread hier sein, kann das gerne dann übertragen, wenn du einverstanden bist).

Und: A cable is a cable, da hast du recht. Zumindest in unserm Altbau-Keller ist eh' weitestgehend Aufputz angesagt. Bin daher ein RS485-MySensors-Fan :) .

Gruß, Beta-User
[/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

mark79

Zitat von: Beta-User am 20 April 2018, 14:20:07
Hast du für die Pearls auch mal die dev-Version vom Signalduino ausprobiert?
Ich hatte das vor etwa 2 Wochen noch mal ausprobiert, jedoch mit der Signalduino FW (CC1101) auf einem ESP8266  ;D Weil bei mir schon alle USB + HUB Anschlüsse belegt sind. :(
Ausprobiert hatte ich das 3.3.1 Release Candidate 4 von hier: https://github.com/RFD-FHEM/SIGNALESP/releases
Damit wurden die leider auch nicht erkannt.

Zitat von: Beta-User am 20 April 2018, 14:20:07
Wenn das noch nicht implementiert ist, kann evtl. sidey&co helfen, die Hardware scheint ja doch eine gewisse Verbreitung zu haben.
Ich kann ihn die Tage mal anschreiben, sind ja auch relativ günstig und die verschiedenen Sensoren von Pearl haben wohl alle das selbe Protokoll... dann könnte ich die Teile wenigstens noch für was anderes verwenden. Hier gibt es zu den Pearl Dingern auch Informationen: https://forum.pilight.org/showthread.php?tid=3080

Zitat von: Beta-User am 20 April 2018, 14:20:07
Was deine Server-Hardware angeht: Jedenfalls auf den ersten Blick sieht die HW valide aus. Vielleicht magst du einen Eintrag für https://wiki.fhem.de/wiki/Kategorie:Server_Hardware erstellen? (Kann auch ein Thread hier sein, kann das gerne dann übertragen, wenn du einverstanden bist).
Was meinst du genau, über das Rock64 Board?
Das läuft bisher ganz gut und auch schnell, USB, Netzwerk und Sound funktionieren stabil. Was nur nicht geht, ist die HMUART MOD RPI PCB Platine via GPIO und bei Python GPIO fehlen ein paar Funktionen. An letzteren wird aber noch dran gearbeitet.
Ich kann darüber was schreiben, aber erst nächste Woche. Habe für das WE noch andere Baustellen eingeplant.

Zitat von: Beta-User am 20 April 2018, 14:20:07
Und: A cable is a cable, da hast du recht. Zumindest in unserm Altbau-Keller ist eh' weitestgehend Aufputz angesagt. Bin daher ein RS485-MySensors-Fan :) .
Ja es geht nix über das gute alte Kabel. :)


Viele Grüße
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 20 April 2018, 14:54:50
Weil bei mir schon alle USB + HUB Anschlüsse belegt sind. :(
Genug USB-Anschlüsse waren einer der Gründe für die Wahl des T5740: 8xUSB bei moderatem Stromverbrauch, das war den Test wert...

Zitat
Ausprobiert hatte ich das 3.3.1 Release Candidate 4
Dann dürfte es da noch keine news geben. Am besten für weitere Protokolle einen issue uf gitub aufmachen, wenn ich das richtig verstanden habe (mit weiteren Angaben aus dem log).

Btw.: Mit einem MapleCUx kannst du bis zu 4 CC1101-Transceiver nutzen (aculfw) - jedenfalls für 433MHz ist da auch einiges implementiert, aber das hast du sicher als erstes probiert? Dann wären da an einem Maple noch 2 serielle Schnittstellen, das würde für das PI-PCB reichen, dazu RX+TX vom Signalduino an die andere, dann sollten wieder USB-Ports frei werden ;) .
Zitat
Was meinst du genau, über das Rock64 Board?
Yup, eilt auch nicht. Finde es aber interessant zu sehen, dass es noch Leute gibt, denen der PI mit der SD-Karte und dem USB-Flaschenhals suspekt ist. Und vom Preis-Leistungsverhältnis her sieht das auch ok aus - je nachdem halt auch, was man schon an Equipment hat.
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

mark79

Zitat von: Beta-User am 20 April 2018, 15:08:57
Genug USB-Anschlüsse waren einer der Gründe für die Wahl des T5740: 8xUSB bei moderatem Stromverbrauch, das war den Test wert...
Stimmt davon kann man irgendwie nie genug haben. :D
Am RPi1 hatte ich inkl. USB Hub nur 5 Slots und die waren alle belegt. Eine DAC Soundkarte, weil die Soundqualität am RPi so schlecht war.. Dann noch 2x Bluetooth Sticks, ein nanoCUL und Pilight.
Die Soundqualität beim Rock ist besser, so das die Soundkarte nun weg fällt.
Ein x86 hat auch seine Vorteile, stabile Hardware mit Sata etc. und sehr gute Treiberunterstützung, aber etwas höherer Stromverbrauch.

Ich habe mit meinen Schätzeisen nach gemessen, im Idle 1,3 Watt und bei Vollast (CPU) mit einem Benchmark Programm 2,6 Watt. Kann ich irgendwie immer noch nicht so richtig glauben.
Ich habe vor ein paar tagen noch MySQL installiert und Nextcloud, bei letzterem traue ich mich nur noch nicht, den Port nach außen freizugeben. :D

Zitat von: Beta-User
Dann dürfte es da noch keine news geben. Am besten für weitere Protokolle einen issue uf gitub aufmachen, wenn ich das richtig verstanden habe (mit weiteren Angaben aus dem log).
Ja Github, muss mir aber erst noch ein Account anlegen. Dann kann ich auch direkt noch den Entwickler für die Debian Distro (ayufan-rock64) anschreiben, wie man den UART auf 115200 Baud setzt. Dann würde evtl. auch die HM Platine am GPIO Leiste funktionieren. Die scheint laut Berichten fix auf 150000 Baud eingestellt zu sein.

Zitat von: Beta-User
Btw.: Mit einem MapleCUx kannst du bis zu 4 CC1101-Transceiver nutzen (aculfw) - jedenfalls für 433MHz ist da auch einiges implementiert, aber das hast du sicher als erstes probiert? Dann wären da an einem Maple noch 2 serielle Schnittstellen, das würde für das PI-PCB reichen, dazu RX+TX vom Signalduino an die andere, dann sollten wieder USB-Ports frei werden ;) .Yup, eilt auch nicht.
MapleCUx kenne ich nur vom Namen her. Aber ich habe mich immer gefragt, wozu man 4x CC1101  benötigt?! Zwei CC1101 kann ich verstehen, auf unterschiedlichen Frequenzen.

Kann man beim Maple CUL zwei verschiedene FW parallel betreiben? Also z.B. einmal acul-fw und einmal Signalduino?
Aber wenn ich da noch die HM Platine anschließen könnte, wäre das schon was. :) Dann muss ich mir mal eine besorgen. :)

Zitat von: Beta-User
Finde es aber interessant zu sehen, dass es noch Leute gibt, denen der PI mit der SD-Karte und dem USB-Flaschenhals suspekt ist. Und vom Preis-Leistungsverhältnis her sieht das auch ok aus - je nachdem halt auch, was man schon an Equipment hat.
Das sehe ich auch so, der war mir zu langsam, zumal das Netzwerk immer noch am USB2 Port hängt. :/
Der einzige Vortei beim RPi ist, dass das teil schon so alt ist und es eine große Community gibt und dadurch guten Support.
Aber für ein headless Server kann man den Schritt schon gehen, weil man keine Grafik Hardwareunterstützung benötigt.

Hier haben einige ein ODROID oder Orange PI, letztere sind auch noch günstiger, aber das liegt wohl eher am niedrigen Ram Speicher.
Der Rock64 hat übrigens noch Hardwareverschlüsslung onboard und man könnte ein VPN darauf betreiben.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

titanbird

Also Ihr, also mich stört das gar nicht dass Ihr mal etwas mehr schreibt und auch etwas weiter ausholt. Hab's gerne durchgelesen. Wobei ich bei vielem da schon aussteige wenn Ihr da mit Begriffen umherwerft  :o ;D

Es gibt aber leider keine (guten) Neuigkeiten zum Thema 433 Steckdose "sniffen".

Was ich jetzt probiert habe, sind folgende Konstellationen:

Arduino nano mit 433 Modul - a-culfw geflashed
Arduino nano mit 433 Modul - SIGNALduino geflashed
Arduino nano mit 868 Modul - a-culfw geflashed
Arduino nano mit 868 Modul - SIGNALduino geflashed

Jedes mal dann auf beiden Fernbedienungen (die CMI Obi Steckdosen und auch die neuen IT-1500 Steckdosen aus dem Bauhaus) rumgedrückt. Entfernung zur Antenne: 2-10cm.
Fhem Event Monitor und Logfile offen (beim Logfile dann immer F5 im Browser gedrückt). Außer die CUL Meldungen wie INIT vom CUL oder auch mal ein
2018.04.20 18:42:39 5: SW: ?
2018.04.20 18:42:39 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of A B C E e F f G i K l M N
2018.04.20 18:42:39 5: CUL/RAW (ReadAnswer):  R T t U V W X x Z

hat sich gar nichts getan zwecks Empfangen von den Daten.

Hier nochmal die Infos zu den einzelnen Konstellationen:


Arduino nano mit 433 Modul - a-culfw geflashed
Info:
Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   CUL_MSGCNT 1
   CUL_TIME   2018-04-20 23:11:10
   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         12
   FHTID      1234
   NAME       CUL
   NR         21
   PARTIAL   
   RAWMSG     ��V���ꊨ������U� UUP�X�Q�QT����.UET�T�U����*Q
   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-20 23:23:01   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-04-20 23:22:40   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-04-20 18:45:59   fhtbuf          No answer
     2018-04-20 23:22:40   state           Initialized
Attributes:
   model      nanoCUL
   rfmode     SlowRF
   verbose    5

Hier mal aus dem Log. Unten nichts obwohl alle Tasten 1x gedrückt:
2018.04.20 23:22:37 3: Setting CUL serial parameters to 38400,8,N,1
2018.04.20 23:22:37 5: SW: V
2018.04.20 23:22:40 5: SW: V
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): V 1.
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): 26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)

2018.04.20 23:22:40 5: SW: ?
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of A B C e F f G i K L l M N
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer):  R T t U V W X x

2018.04.20 23:22:40 3: CUL: Possible commands: ABCeFfGiKLlMNRTtUVWXx
2018.04.20 23:22:40 5: SW: X21
2018.04.20 23:22:40 5: SW: T01
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): 1234

2018.04.20 23:22:40 5: GOT CUL fhtid: 1234
2018.04.20 23:22:40 1: /dev/ttyUSB0 reappeared (CUL)
2018.04.20 23:23:01 5: SW: C0D
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C0D = 10 / 16

2018.04.20 23:23:01 5: SW: C0E
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C0E = B0 / 176

2018.04.20 23:23:01 5: SW: C0F
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C0F = 71 / 113

2018.04.20 23:23:01 5: SW: C10
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C10 = 57 / 87

2018.04.20 23:23:01 5: SW: C1B
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C1B = 07 /  7

2018.04.20 23:23:01 5: SW: C1D
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C1D = 90 / 144


Arduino nano mit 433 Modul - SIGNALduino geflashed
Info:
Internals:
   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         20
   PARTIAL   
   STATE      opened
   TIME       1524258744
   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-20 23:12:41   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-20 23:15:49   ping            OK
     2018-04-18 23:47:48   raw             ccFactoryReset done
     2018-04-20 23:14:49   state           opened
     2018-04-20 23:14:49   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   getcmd:
   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

Mal was aus dem Logfile (unten leider nichts erschienen obwohl Tasten gedrückt):
2018.04.20 23:14:47 3: SIGNALduino reset
2018.04.20 23:14:47 3: Opening SIGNALduino device /dev/ttyUSB0
2018.04.20 23:14:47 3: Setting SIGNALduino serial parameters to 57600,8,N,1
2018.04.20 23:14:47 1: SIGNALduino/define: /dev/ttyUSB0@57600
2018.04.20 23:14:47 1: SIGNALduino/init: /dev/ttyUSB0@57600
2018.04.20 23:14:47 3: SIGNALduino device opened
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: /Using sF
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: Using sF/IFO
Reading values fom eeprom
CCVersion=4
CCPartnu
2018.04.20 23:14:48 4: SIGNALduino/msg READ: Using sFIFO
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: Using sFIFO
2018.04.20 23:14:48 4: SIGNALduino/msg READ: Reading values fom eeprom
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: Reading values fom eeprom
2018.04.20 23:14:48 4: SIGNALduino/msg READ: CCVersion=4
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: CCVersion=4
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: CCPartnu/m=0
CC1101 found
Starting timerjob

2018.04.20 23:14:48 4: SIGNALduino/msg READ: CCPartnum=0
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: CCPartnum=0
2018.04.20 23:14:48 4: SIGNALduino/msg READ: CC1101 found
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: CC1101 found
2018.04.20 23:14:48 4: SIGNALduino/msg READ: Starting timerjob
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: Starting timerjob
2018.04.20 23:14:48 3: SIGNALduino/init: disable receiver (XQ)
2018.04.20 23:14:48 5: SIGNALduino SW: XQ
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: /receiver enabled

2018.04.20 23:14:48 4: SIGNALduino/msg READ: receiver enabled
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: receiver enabled
2018.04.20 23:14:49 3: SIGNALduino/init: get version, retry = 0
2018.04.20 23:14:49 5: SIGNALduino SW: V
2018.04.20 23:14:49 5: SIGNALduino/RAW READ: /V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

2018.04.20 23:14:49 4: SIGNALduino/msg READ: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
2018.04.20 23:14:49 5: SIGNALduino/noMsg Parse: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
2018.04.20 23:14:49 5: SIGNALduino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
2018.04.20 23:14:49 2: SIGNALduino: initialized. v3.3.3-dev_17.04.
2018.04.20 23:14:49 5: SIGNALduino SW: XE
2018.04.20 23:14:49 3: SIGNALduino/init: enable receiver (XE)


Arduino nano mit 868 Modul - a-culfw geflashed
Info:

Save config
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Internals:
   CMDS       ABCEeFfGiKlMNRTtUVWXxZ
   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         13
   FHTID      1234
   NAME       CUL
   NR         21
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.02 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
   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-20 23:07:52   ccconf          freq:3322.000MHz bWidth:58KHz rAmpl:33dB sens:8dB
     2018-04-20 23:06:59   cmds             A B C E e F f G i K l M N R T t U V W X x Z
     2018-04-20 18:45:59   fhtbuf          No answer
     2018-04-20 23:06:59   state           Initialized
Attributes:
   model      nanoCUL
   rfmode     SlowRF
   verbose    5


Arduino nano mit 868 Modul - SIGNALduino geflashed
Info:
Internals:
   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         10
   LASTDMSG   nothing
   NAME       SIGNALduino
   NR         20
   PARTIAL   
   STATE      opened
   TIME       1524256787
   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-20 22:51:20   ccconf          freq:790.264MHz bWidth:541KHz rAmpl:24dB sens:16dB  (DataRate:955322.27Baud)
     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-20 23:00:44   ping            OK
     2018-04-18 23:47:48   raw             ccFactoryReset done
     2018-04-20 22:48:44   state           opened
     2018-04-20 22:48:44   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   getcmd:
   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



Also irgendwas muss ich hier doch komplett falsch machen... Ich kann mir nicht vorstellen dass das so schwer sein kann, irgendwo übersehe ich doch was?!
Die ccconf          freq:3322.000MHz ist auch merkwürdig. Jedes mal wenn ich ccconf abfrage, sind da willkürliche, teils sehr hohe Werte. Ich glaube nur beim 868er CUL.

Hoffe Ihr habt wieder ein paar Tipps was ich noch so machen/beachten könnte.

mark79

Hi,

ich kann dir leider auch nicht so wirklich weiter helfen, hier ist ein List von meinem (arduino) nanoCUL:

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_A9SZV11H-if00-port0@38400 4444
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9SZV11H-if00-port0@38400
   FD         17
   FHTID      4444
   NAME       nanoCUL
   NR         248
   PARTIAL   
   RAWMSG     om8AAAA0F6
   RSSI       -28.5
   STATE      Initialized
   TIME       1524335202.38965
   TYPE       CUL
   VERSION    V 1.26.01 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   nanoCUL_MSGCNT 6242
   nanoCUL_TIME 2018-04-21 20:32:26
   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................................$
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     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-01-21 15:57:06   ccconf          freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB
     2018-04-20 00:03:01   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-04-15 15:56:01   raw             is11DD1FDDDDF1
     2018-04-21 20:32:26   state           Initialized
Attributes:
   DbLogExclude .*
   model      nanoCUL
   rfmode     SlowRF
   verbose    5


Setzte evtl. mal die bWidth hoch. Ansonsten müssen dir da leider andere helfen, von den Funkgedöns habe ich zu wenig Ahnung.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

RalfRog

Hi
Wenn 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.
Ein CUL auf 868 MHz kann zwar 433 senden hört aber auf der Frequenz 433 nicht mit.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Beta-User

Zitat von: titanbird am 20 April 2018, 23:26:27
Die ccconf          freq:3322.000MHz ist auch merkwürdig. Jedes mal wenn ich ccconf abfrage, sind da willkürliche, teils sehr hohe Werte. Ich glaube nur beim 868er CUL.
Wenn 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).
Und 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 (Signalduino muß nach dem flashen übrigens einmal resettet werden ("raw e"?).

Zitat von: titanbird am 20 April 2018, 23:26:27
Also Ihr, also mich stört das gar nicht dass Ihr mal etwas mehr schreibt und auch etwas weiter ausholt. Hab's gerne durchgelesen. Wobei ich bei vielem da schon aussteige wenn Ihr da mit Begriffen umherwerft  :o ;D
Danke für die Rückmeldung, die Stichworte waren für die SuFu gedacht ;) .

Zitat von: mark79 am 20 April 2018, 22:21:39
Ich habe mit meinen Schätzeisen nach gemessen, im Idle 1,3 Watt und bei Vollast (CPU) mit einem Benchmark Programm 2,6 Watt. Kann ich irgendwie immer noch nicht so richtig glauben.
Das kommt mir auch sehr wenig vor, aber selbst wenn es 5W sind, ist es für die Leistung doch ein sehr guter Wert!

Zitat
[...]wie man den UART auf 115200 Baud setzt. Dann würde evtl. auch die HM Platine am GPIO Leiste funktionieren. Die scheint laut Berichten fix auf 150000 Baud eingestellt zu sein.
Genau solche Sachen sind es dann, die im Wiki für mutige Nachahmer gut aufgehoben wären...

Zitat
MapleCUx kenne ich nur vom Namen her. Aber ich habe mich immer gefragt, wozu man 4x CC1101  benötigt?! Zwei CC1101 kann ich verstehen, auf unterschiedlichen Frequenzen.
Die Frage hatte ich mir früher auch mal gestellt, mittlerweile finde ich 4 Transceiver fast etwas wenig ;) : 2*SlowRF (433/868), HM (ok, da baut man besser das PI-Modul ran), MAX... Dann hast du noch kein ZWave...

Zitat
Kann man beim Maple CUL zwei verschiedene FW parallel betreiben?
Nein, es ist ein Microcontroller, also eine Firmware, die dann aber auf den verschiedenen Transceivern unterschiedliche Protokolle senden und empfangen kann (s.o.).

Zitat
[...] Signalduino?
Den kannst du dann an der 2. durchgereichten seriellen Schnittstelle anschließen (separater Microcontroller, ein mit RX/TX fix und fertig verdrahteter Sockel für einen Pro Mini ist auf der Platine schon drauf, soweit ich mich entsinne (für ein MySensors-GW...).

Kurz: Das Ding ist ein richtiges "Schweizer Taschenmesser", gehört damit aber nicht zu den "ganz einfachen" Devices...

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