nanoCUL für MAX Fensterkontakt und Intertechno Steckdosen -> switch_rfmode ?

Begonnen von schnitzelbrain, 18 März 2016, 15:35:36

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1
Benutzer-Aktionen

schnitzelbrain

18 März 2016, 15:35:36 Letzte Bearbeitung: 19 März 2016, 19:30:12 von schnitzelbrain
Hallo,

wie in dem Topic hab ich meinen CUL auf der Raspi unter Jessie für MAX Kontakte und Intertechno Steckdosen in Gebrauch
Gestern stieg Abends die Steuerung einmal aus. Bedeutet weder Steckdosen noch Fensterkontakt waren ansprechbar (bzw. haben Schaltänderungen gezeigt) und die Frequenz am CUL stand auf 0 MHZ.
Alles an, Reset, Neustart usw brachte nix.
Ich hab dann als Lösung den CUL an der Pi kurz einmal rausgezogen und wieder neu im USB eingesteckt, dann ging es wieder.

Jetzt ist mir aufgefallen das die ccconf  bWidth beim CUL auf 101khz geändert wurde, wenn ich mich recht erinnere stand da vorher 325khz.
Nach einigem lesen heißt das wohl der CUL steht auf Homatic statt auf MAX.
Aktuell:
Code Auswählen
freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB

Bei der Suche habe ich gesehen das dies wohl mit dem Switch_rfmode = 1 bei den Intertechno Dosen zusammenhängen könnte.

Bevor ich jetzt wild die Parameter verändere, die Frage (auch gerne nur Hinweis wo es steht, hab nix gefunden):

1. Was muss bei den Intertechno Steckdosen gesetzt sein Switch_rfmode 1 oder 0?
2. Gibt es eine Übersicht wie die Einstellungen Freq, Bwidth, usw vom ccconf eigentlich bei den verschiedenen CUL Modes sein müssen?

Grüße
Schnitzelbrain


Gelöst:
Ich hab jetzt mangels Antworten einfach auf switch_rfmode auf 0 gestellt, die Frequenz scheint so zu stimmen.
Nach weiterem Testen und Fehlersuche tauchte der Fehler (Sendefrequenz auf 0 und keine Reaktion mehr auf IT sowie auf Fensterkontakt) trotzdem immer wieder auf.
Der CUL meldete sich im Log als disconnected.

Dann hab ich, zumindest für mich, die Lösung gefunden:
In der raspi (in der Kommandozeile) folgendes eingeben.
Code Auswählen
dmesg  | grep tty

es kam bei mir mehrmals folgende Fehlermeldung:
Code Auswählen
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
zum gleichen Zeitpunkt als ein Ereignis (IT oder Fensterkontakt) arbeiten sollte.

Eine weitere Suche brachte mich zu folgender Lösung
In der raspi folgendes eintragen:
Code Auswählen
add dwc_otg.speed=1 to /boot/cmdline.txt

Bei dem Eintrag werden die USB Ports der PI von USB 2.0 auf 1.1 zurückgestellt. Scheinbar ist bei einigen China Arduinos der FTDI Chip nicht in der Lage 2.0 zu halten.
Nach der Änderung läuft es bei mir seit Stunden stabil.


Schnitzelbrain

schnitzelbrain

#1
20 März 2016, 21:12:30
Ist während der Nacht doch wieder ausgefallen.

Nach vielem hin und her gab ich jetzt den CC1101 gewechselt.

Jetzt läuft es erst mal wieder, mal sehen wie es über Nacht sich verhält.

schnitzelbrain

#2
21 März 2016, 20:34:40
Update, nach dem Wechsel vom CC1101 erster Tag ohne abbrüche.

schnitzelbrain

#3
28 März 2016, 20:04:40
Nach einer Woche folgendes Fazit.
Nach dem Wechsel des CC1101 Moduls lief der nanoCUL unter USB 2.0 (den von mir vorgeschlagenen Eintrag hatte ich wieder entfernt)  "fast" stabil.

Fast da trotzdem in unregelmäßigen Abständen (ca. einmal in 12 Stunden der CUL mit folgender Meldung seinen Dienst versagte:
Code Auswählen
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

Mit mehrmailgen Abfragen der ccconf in FHEM oder der Firmwareversion scheint der nanoCUL wieder "aufzuwachen" und läuft bis zum nächsten Ausfall.
Im FHEM Log steht dann auch ein reconnect des nanoCUL

Nach weiterer Suche bin ich heute hier https://forum.fhem.de/index.php/topic,46098.msg409051.html#msg409051 auf folgendes gestoßen:
Zitat von: amunra am 13 Februar 2016, 09:26:28
Ein Kernel downgrade hat hier geholfen.
Wie es geht ist z.B. hier beschrieben
Wichtig: alles auf eigene Gefahr!!! Bitte an Backup denken!!!
Ich habe es auf meinem RPI auch gemacht, es dauert nur ein paar Minuten - Neuinstallation war bei mir nicht nötig.
Code Auswählen
cat /proc/version
#version vorher: Linux version 4.1.6+
Code Auswählen

sudo rpi-update 6413da9f74871b239c5bd27d7edf90a8afeab363
reboot
Code Auswählen
cat /proc/version
#version nachher: Linux version 3.12.36+

Viele Grüße
Arthur

In meiner Verzweiflung auch dies durchgeführt, vorher aber ein komplett Backup der SD karte gemacht.
Downgrade hat funktioniert, CUL läuft erst mal stabil. Ich werde es jetzt weiter beobachten.

Note:
Mein RasPi var/log/messages (und auch die syslog) füllte sich nach dem downgrade mit folgenden Meldungen:
Code Auswählen
Mar 28 14:16:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:16:31 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:17:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:17:31 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:19:29 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:19:59 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:21:07 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:21:37 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:22:48 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:23:18 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:24:16 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:24:46 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:24:46 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:25:16 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 28 14:25:16 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Mon Mar 28 14:25:46 2016 [try http://www.rsyslog.com/e/2007 ]



Dies scheint ein Problem der Firmware Version zu sein (zumindest ist dies immo mein Kenntnisstand.
Abgestellt wurde es mit

Code Auswählen
Folgende Zeilen mit einem "#" in der  /etc/rsyslog.conf Auskommentieren:


    #daemon.*;mail.*;\
    #       news.err;\
    #       *.=debug;*.=info;\
    #       *.=notice;*.=warn       |/dev/xconsole

Nun läuft das System erst mal stabil.

schnitzelbrain

#4
01 April 2016, 09:46:57
Update:

Nacj zwei Tagen wiederum Ausfall mit der Fehlermeldung:
Code Auswählen
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
im Syslog der RasPi

FHEM hat selbst nicht sehr viel vom Ausfall gemeldet. Der CUL hat einfach nicht mehr reagiert.
Erst nach mehrfacher anfrage über die Oberflächer "wacht" der CUL anscheinend auf.
Code Auswählen
2016.03.28 06:06:14 5: CUL_MAX_Parse: len 15, msgcnt 00, msgflag 04, msgTypeRaw ThermostatState, src 112ebc, dst 000000, groupid 0, payload 18092400B8
2016.03.28 08:32:56 5: SW: C0D
2016.03.28 08:33:23 5: SW: C0D
2016.03.28 08:33:26 5: SW: C0D
2016.03.28 08:55:25 1: PERL WARNING: Use of uninitialized value $v in sprintf at fhem.pl line 2094.
2016.03.28 08:57:37 5: SW: C0D
2016.03.28 09:04:02 5: SW: X
2016.03.28 09:04:05 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 disconnected, waiting to reappear (nanoCUL1)
2016.03.28 09:04:05 3: Setting nanoCUL1 serial parameters to 38400,8,N,1
2016.03.28 09:04:05 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 reappeared (nanoCUL1)
2016.03.28 09:04:05 5: CUL/RAW (ReadAnswer):

2016.03.28 09:04:05 4: CUL_Parse: nanoCUL1
2016.03.28 09:04:05 2: nanoCUL1: unknown message
2016.03.28 09:04:06 5: SW: V
2016.03.28 09:04:09 5: SW: V
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer):
2016.03.28 09:04:09 5: CUL/RAW (ReadAnswer): V 1.66 nanoCUL868

2016.03.28 09:04:09 4: CUL_Parse: nanoCUL1 V 1.66 nanoCUL868
2016.03.28 09:04:09 2: nanoCUL1: unknown message V 1.66 nanoCUL868
2016.03.28 09:04:12 5: SW: V
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer): V 1.66 nanoCUL868

2016.03.28 09:04:12 5: SW: ?
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer):  F i A
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer):  Z E
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer): k G M
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer): K U Y
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer):  R T V
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer):  W X e
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer):  f l
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer): t x

2016.03.28 09:04:12 3: nanoCUL1: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2016.03.28 09:04:12 5: SW: X21
2016.03.28 09:04:12 5: SW: Zr
2016.03.28 09:04:12 5: SW: Za123456
2016.03.28 09:04:12 5: SW: Zw111111
2016.03.28 09:04:12 5: SW: T01
2016.03.28 09:04:12 5: CUL/RAW (ReadAnswer): 1234

2016.03.28 09:04:12 5: GOT CUL fhtid: 1234
2016.03.28 09:04:23 5: SW: V
2016.03.28 09:04:23 5: CUL/RAW (ReadAnswer): V 1.66 nanoCUL868

2016.03.28 09:04:35 5: SW: t
2016.03.28 09:04:35 5: CUL/RAW (ReadAnswer): 00000DC0

2016.03.28 09:05:22 5: SW: C0D
2016.03.28 09:05:22 5: CUL/RAW (ReadAnswer): C0D = 21 / 33

2016.03.28 09:05:22 5: SW: C0E
2016.03.28 09:05:22 5: CUL/RAW (ReadAnswer): C0E = 65 / 101

2016.03.28 09:05:22 5: SW: C0F
2016.03.28 09:05:22 5: CUL/RAW (ReadAnswer): C0F = 6A / 106

2016.03.28 09:05:22 5: SW: C10
2016.03.28 09:05:22 5: CUL/RAW (ReadAnswer): C10 = C8 / 200

2016.03.28 09:05:22 5: SW: C1B
2016.03.28 09:05:22 5: CUL/RAW (ReadAnswer): C1B = 43 / 67

2016.03.28 09:05:22 5: SW: C1D
2016.03.28 09:05:22 5: CUL/RAW (ReadAnswer): C1D = 91 / 145

2016.03.28 09:10:39 5: CUL/RAW: /Z0B9
2016.03.28 09:10:39 5: CUL/RAW: Z0B9/80002
2016.03.28 09:10:39 5: CUL/RAW: Z0B980002/123456
2016.03.28 09:10:39 5: CUL/RAW: Z0B980002123456/132DC20000
2016.03.28 09:10:39 5: CUL/RAW: Z0B980002123456132DC20000/00
Z0
2016.03.28 09:10:39 4: CUL_Parse: nanoCUL1 Z0B980002123456132DC2000000 -74
2016.03.28 09:10:39 5: nanoCUL1 dispatch Z0B980002123456132DC20000
2016.03.28 09:10:39 5: CUL_MAX_Parse: len 11, msgcnt 98, msgflag 00, msgTypeRaw Ack, src 123456, dst 132dc2, groupid 0, payload 00
2016.03.28 09:10:39 5: CUL/RAW: Z0/B980630132DC2123456001
2016.03.28 09:10:39 5: CUL/RAW: Z0B980630132DC2123456001/0EF

Man sieht gleich am Anfang um 6 Uhr noch Kontakt, dann bis um 08:32 nix mehr. Erst nach Abfrage kommt dann plötzlich "CUL disconnected".
Nach 5 Uhr ist dann auch die besagte Fehlermeldung im RasPi Log.

Mittlerweile hab ich dann wieder Update auf die neuste RasPi Firmware Version gemacht.
Als nächstes hatte ich nun einen aktiven USB 1 HUB angeschlossen. Da ging erst recht nichts mehr, die besagten Fehlermeldungen kamen im Sekundentakt.

Ich hab als letzten Versuch einen passiven USB 2 Hub, an dem nur der CUL hängt, angeschlossen.
Was soll ich sagen, es läuft seit 29.03 jetzt ohne Ausfall !

Warten wir mal die kommende Woche ab.

viegener

#5
01 April 2016, 15:27:38
Ein passiver USB-Hub erscheint mir als Lösung eher abwegig, denn welches problem sollte das lösen. Auch einiges andere ist eher etwas, dass das eigentliche Problem überdeckt (USB 1.1 fallback)?

Eine Vermutung wäre, dass Du ein Problem mit der Stromversorgung hast. Es gibt reichlich Beiträge wo unerklärliche Effekte bei USB-Devices mit Problemen bei der Raspberry Stromversorgung zusammenhängen. Alternativ ein Powered USB-Hub.

Alernativ kann natürlich auch der Arduino Nano ein Problem haben, es gibt zum Beispiel einige Chargen aus China mit speziellen Fehlern (Stichwort FTDI test Pin).


Johannes

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

schnitzelbrain

#6
01 April 2016, 21:02:10
Zitat von: viegener am 01 April 2016, 15:27:38
Ein passiver USB-Hub erscheint mir als Lösung eher abwegig, denn welches problem sollte das lösen. Auch einiges andere ist eher etwas, dass das eigentliche Problem überdeckt (USB 1.1 fallback)?

Eine Vermutung wäre, dass Du ein Problem mit der Stromversorgung hast. Es gibt reichlich Beiträge wo unerklärliche Effekte bei USB-Devices mit Problemen bei der Raspberry Stromversorgung zusammenhängen. Alternativ ein Powered USB-Hub.

Alernativ kann natürlich auch der Arduino Nano ein Problem haben, es gibt zum Beispiel einige Chargen aus China mit speziellen Fehlern (Stichwort FTDI test Pin).


Johannes

Hallo,

das mit dem passiven USB Hub dachte ich auch. Hier im Forum hat es aber schon einmal so funktioniert (finde es nur grad net).
Ich bin im Microcontroller Forum über anbringen von Kondensatoren (im nF bereich und an den Pwr Lines)  und Widerständen betreffend FTDI (oder generell USB Chip Probleme) gestolpert.

Ich habe meinen HUB nicht zerlegt könnte mir aber vorstellen das da entweder Kondensatoren zur Entstörung drinne sind oder sich eben die Kapazitäten durch den Hub ändern.
Zumindest läuft es bis jetzt ohne Probleme.

Die von Dir angesprochenen Test Pin Probleme hatte ich am Anfang auch (musste Pin 25/26 vom FTDI brücken). Fallback auf USB 1.1 hatte ich auch an der Pi eingestellt da lief es dann auch aber da meine Logs über USB Stick an der Pi laufen wurde die Reaktionszeit doch merklich langsamer. Der Chip meldet sich als FTDI_SIO mit 12M an. Das sollte dann wohl USB 1.1 Full Speed sein. Ich denke da ist das Problem, eigentlich ist der Chip doch USB 2.X.
Ich vermute dann auch eher ein China Arduino Problem.

Falls ich das Problem (später mit mehreren CULs über aktiven Hub) nicht in den Griff bekomme werde ich wohl auf gekaufte umsteigen müssen. Oder ich finde noch eine zuverlässige Quelle die "gute" Arduinos ausliefert.

Grüße

Drucken
Nach oben Seiten1
Benutzer-Aktionen