[gelöst] nanoCUL433 mit a_culfw (SlowRF) sendet nicht, aber empfängt

[Heimel]

Hallo,

ich nutze einen Pi2, fhem wurde aktualisiert. Angeschlossen sind:

    EnOcean-Stick
    nativer CUL868
    Eigenbau CUL433

Code Auswählen Erweitern

lrwxrwxrwx 1 root root  13 Nov 26 19:01 platform-3f980000.usb-usb-0:1.2:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root  13 Nov 26 19:01 platform-3f980000.usb-usb-0:1.3:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Nov 26 19:01 platform-3f980000.usb-usb-0:1.5:1.0-port0 -> ../../ttyUSB1


Code Auswählen Erweitern

lrwxrwxrwx 1 root root  13 Nov 26 19:01 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root  13 Nov 26 19:01 usb-EnOcean_GmbH_EnOcean_USB_300_DB_FTO7G3Q-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root  13 Nov 26 19:01 usb-FTDI_FT232R_USB_UART_A105N72D-if00-port0 -> ../../ttyUSB0


    Alle Sticks sind "Initialized".
    Zwischen Sender und Empfänger sind keine 5m Abstand.


1. Versuch:
nanoCUL433 mit culfw (V 1.67) geflasht: IT-Dose kann geschaltet werden.
2. Versuch (da ich auch empfangen möchte):
nanoCUL433 mit a_culfw (V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) nanoCUL433 (F-Band: 433MHz)) geflasht:

    Wetterdaten von den Nachbarn werden empfangen.
    Aber: Kein senden mehr möglich; IT-Dose schaltet nicht mehr.

3. Gegenprobe mit CUL868 (IODev beim Schalter auf CUL868 geändert): IT-Dose schaltet wieder.

Sind die Standardeinstellungen bei culfw und a_culfw unterschiedlich? Trotz Suche habe ich dazu nichts gefunden.

Code Auswählen Erweitern

define CUL433 CUL /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0@38400 3045
attr CUL433 icon cul_cul
attr CUL433 rfmode SlowRF
attr CUL433 room Administration
attr CUL433 verbose 5
Habe nur "verbose 5" ergänzt, um im Log evtl. einen Hinweis zu finden. Ist mir (vermutlich aus Unkenntnis) nicht gelungen.

Was braucht Ihr noch für Daten, bzw. was kann ich tun?

[KölnSolar]

Was ist das für ne Dose(Hersteller/Typ) ? IT-V1 od. V3 ? Mehrere Codes probiert ?

Sind die Standardeinstellungen bei culfw und a_culfw unterschiedlich?

Nein.

Mal ne ältere aculfw probieren ?

[isy]

Ich habe meinen 433er CUL gar nicht auf SlowRF gestellt und funktioniert einwandfrei,  auch mit IT.
Es kann allerdings sein, dass SlowRF als default genommen wird. In diversen Anleitungen wird das Attribut aber gesetzt.

Kannst du ja mal testen.
Gruß Helmut

[Heimel]

Was ist das für ne Dose(Hersteller/Typ) ? IT-V1 od. V3 ?

   
• Original intertechno V1
• Conrad (--> FLS100)

Mehrere Codes probiert ?

Ja - als auch beide Typen (s.o.). Da die selben Definitionen bei Nutzung des CUL868 funktionieren, habe ich die Richtigkeit der Codes eigentlich nie infrage gestellt.

Mal ne ältere aculfw probieren ?

Hmm - da die FW-Version bereits seit 2 Monaten raus und ich sonst keine Probleme dazu gelesen habe, kann ich da nicht wirklich dran glauben. Würde ich daher erst einmal vermeiden wollen.

Ich habe meinen 433er CUL gar nicht auf SlowRF gestellt und funktioniert einwandfrei,  auch mit IT.
Es kann allerdings sein, dass SlowRF als default genommen wird. In diversen Anleitungen wird das Attribut aber gesetzt.

Kannst du ja mal testen.

In der Not, teste ich auch das. 
Attribut gelöscht und zur Sicherheit einen Neustart ausgeführt: Hat nicht geholfen.


Zur Ergänzung: Den nanoCUL habe ich nach dieser Anleitung verdrahtet (zur Erinnerung: die culfw 1.67 hat funktioniert).

[KölnSolar]

Attribut gelöscht und zur Sicherheit einen Neustart ausgeführt: Hat nicht geholfen.

Klar  slowRF ist der default-mode

In Deiner Konstellation(culfw 1.67 funktioniert für Original IT-V1) kann ich mir das nur mit einem Flash- oder Hardware-Problem erklären. Hab gerade noch mal schnell meinen nanoCUL mit der 1.25.00 ans Testsystem gehangen: einwandfrei.

Edit: Du hattest eingangs geschrieben, dass Du Wettersensoren empfängst. Wie sieht es denn mit einer IT-FB aus ?

[Beta-User]

Klingt nach einem HW-Problem, würde auf einen Wackelkontakt tippen.

Was sagt den ccconf? - Evtl. nochmal auf Werkseinstellungen setzen?

In der verlinkten Anleitung (jedenfalls in der Grafik unten, das Video war mir zu lang) fehlen die Spannungsteilerwiderstände, die im Wiki (Selbstbau-CUL) vorgesehen sind => CC1101 könnte beschädigt worden sein (ich weiß, das muß nicht so sein ).

Btw: warum machst du by-path, wenn by-id genauso eindeutig ist?

[Heimel]

Klingt nach einem HW-Problem, würde auf einen Wackelkontakt tippen.

An ein HW-Problem habe ich heute auch schon gedacht ...  - an welcher Stelle könnte der Wackelkontakt sein? - Ich habe die Antenne in Verdacht. Ist es normal, dass die schwarze Kappe auf der Antenne gedreht werden kann? (Bei meiner Antenne vom CUL868 ist das nicht so.)
Kann es auch einen Konflikt mit dem CUL868 geben? Nachdem ich diesen testweise entfernt habe, kann ich immerhin auf kurze Distanz schalten (d.h. senden). Allerdings ist die Sendeleistung kleiner als beim CUL868 - so sollte es natürlich nicht sein (entferntere IT-Dose ließ sich nur mit CUL868 schalten). Könnte ein Wackelkontakt sich nur auf die Sende-, aber nicht auf die Empfangsleistung auswirken? - Der Empfang bereitet mir kein Problem.

Was sagt den ccconf? - Evtl. nochmal auf Werkseinstellungen setzen?

Code Auswählen Erweitern

CUL433 ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
- Das sollten doch die Werkseinstellungen sein, da ich nichts verändert hatte - oder?!

In der verlinkten Anleitung (jedenfalls in der Grafik unten, das Video war mir zu lang) fehlen die Spannungsteilerwiderstände, die im Wiki (Selbstbau-CUL) vorgesehen sind => CC1101 könnte beschädigt worden sein (ich weiß, das muß nicht so sein ).

Ja ich weiß ...  - die Standard culfw hat jedenfalls funktioniert ...

Btw: warum machst du by-path, wenn by-id genauso eindeutig ist?

Eine gute Frage! Ich hätte auch lieber by-id genutzt, aber bei gleichzeitiger Nutzung aller Sticks über by-id kamen nie alle in den Status "Initialized" - komisch, aber wahr. In der Not habe ich dann by-path beim nanoCUL gewählt und was soll ich sagen (obwohl ich mir das nicht erklären kann) - so kommen alle Sticks in den Status "Initialized". Glücklich bin ich mit dieser Lösung in der Tat nicht (würde eine manuelle Einbindung via udev evtl. eine besser Variante sein?).

[Beta-User]

Das klingt insgesamt jetzt mit der Schilderung eher nach einem Problem mit der gesamten Spannungsversorgung, udev usw. bringen da m.E. gar nichts...
Senden braucht eben mehr Saft als Empfangen .

Kannst du mal einen aktiven Hub zwischenschalten?

Danach können wir nach dem Rest sehen (Wackler nur beim Senden gab es schon mal, aber da war ccconf auch seltsam).

[Heimel]

Das klingt insgesamt jetzt mit der Schilderung eher nach einem Problem mit der gesamten Spannungsversorgung, udev usw. bringen da m.E. gar nichts...
Senden braucht eben mehr Saft als Empfangen .

Das klingt logisch! 

Kannst du mal einen aktiven Hub zwischenschalten?

Nein, da keiner vorhanden. Habe aber sowohl Netzteil, als auch Pi2 getauscht. Kein Effekt.

Habe dann noch einmal die "normale" culfw geflasht, um HW-Fehler bzw. zu niedrige Spannungsversorgung auszuschließen.
Ergebnis: Senden funktioniert wieder. --> Also keine HW Probleme

Da habe ich mich an @KölnSolar erinnert:

Mal ne ältere aculfw probieren ?

Hätte ich doch nur gleich auf das Gefühl eines Profis gehört!

Habe nun a_culfw Version 1.24.02 Build: 208 drauf. Und was soll ich sagen?! Jetzt funktioniert alles wie es soll!

Ich danke Euch für Eure Unterstützung - als Anfänger fehlt einem noch das Gespür dafür, wo der Hase im Pfeffer liegen kann.

[Heimel]

Oooops - diesen Post hatte ich ganz überlesen ... 

In Deiner Konstellation(culfw 1.67 funktioniert für Original IT-V1) kann ich mir das nur mit einem Flash- oder Hardware-Problem erklären. Hab gerade noch mal schnell meinen nanoCUL mit der 1.25.00 ans Testsystem gehangen: einwandfrei.

Aaah - dann hätte ich vermutlich auch diese Version nehmen können, egal nun ist die 1.24.02 drauf - die funktioniert bei mir auch.

Edit: Du hattest eingangs geschrieben, dass Du Wettersensoren empfängst. Wie sieht es denn mit einer IT-FB aus ?

Nur der Vollständigkeit halber: Ja IT-FB wurde auch empfangen.

[KölnSolar]

Hab jetzt auch mal die 1.26.01 auf nanoCUL u. busware_V3 geflashed: Funktioniert völlig problemlos mit IT_V1 u. IT_V3 

Ich vermute daher, dass bei Deinem ersten flashen etwas schief gelaufen ist oder Du die 1.26.01 selbst kompiliert hattest ?

[Heimel]

Hab jetzt auch mal die 1.26.01 auf nanoCUL u. busware_V3 geflashed: Funktioniert völlig problemlos mit IT_V1 u. IT_V3 

Es gibt Dinge, die lassen einen einfach nicht in Ruhe ... 

Ich vermute daher, dass bei Deinem ersten flashen etwas schief gelaufen ist

Das könnte ich natürlich durch einen erneuten Flashversuch verifizieren ... - aber da alles läuft (und ich zufrieden bin), arbeite ich lieber an anderen Baustellen weiter.    - 2,5 Tage Fehlersuche und intensives WWW-Durchsuchen haben meinen Bedarf an Experimenten im Moment erschöpft.

oder Du die 1.26.01 selbst kompiliert hattest ?

Nein, wenn ich kann, vermeide ich das.

[KölnSolar]

klar, dass Du nicht neu flashen möchstest, aber interessant wärs...

Ich hatte schon das "bug-fixing" eingeleitet.    Umso wichtiger ist mir daher einfach nur die Klarstellung für Mitleser und die Nachwelt, dass die 1.26.01 kein prinzipielles Problem mit IT hat.

[Heimel]

klar, dass Du nicht neu flashen möchstest, aber interessant wärs...

War mir klar, dass Du an mein Gewissen appelierst, habe eh schon ein kleines schlechtes Gewissen ...
... aber ich hoffe, dass ich als Neuling noch etwas Welpenschutz geniese.

Ich hatte schon das "bug-fixing" eingeleitet.    Umso wichtiger ist mir daher einfach nur die Klarstellung für Mitleser und die Nachwelt, dass die 1.26.01 kein prinzipielles Problem mit IT hat.

Ich weiß das Engagement zu schätzen und danke Dir dafür! (Hier fehlt irgendwie "einDaumenhoch-Icon".)