Selbstbau CUL reagiert nicht

Begonnen von Flipper92, 17 Oktober 2017, 17:43:26

Vorheriges Thema - Nächstes Thema

Flipper92

Hallo zusammen,

Ich hab mir ein CUL zusammen gebaut, bekomme jedoch kein Eingangssignal.
Wie ich den Ausgang testen kann weiß ich leider nicht.

Naja kurz zur "Fehlerbeschreibung":
Ich hab versucht ein paar MAX-Fensterkontakte in fhem einzubinden.
Wenn ich alles richtig verstanden habe müsste es ja selbst erzeugt werden.
Auf jedenfall kommt bei fhem nichts an was mit dem CUL zu tun haben könnte.
Da ich beim signalduino (433Mhz) auch schon ein Verkabelung falsch hatte, möchte ich das nicht ausschließen.
Ich hab dafür anbei paar Bilder eingefügt.
Ist diese soweit richtig?

Ich kann auch gerne nochmal ein flasch machen und hier alles aufschreiben (mit Ergebnissen), würde dann heute abend kommen.

aktuell sieht es in Fhem so aus:
LOG:
2017.10.16 21:06:13 3: Opening CUL0 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0
2017.10.16 21:06:13 3: Setting CUL0 serial parameters to 9600,8,N,1
2017.10.16 21:06:22 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0, ignoring it (CUL0)


defmod CUL0 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@9600 0000
attr CUL0 rfmode MAX

setstate CUL0 opened
setstate CUL0 2017-10-16 21:34:40 credit10ms No answer
setstate CUL0 2017-10-16 21:34:09 raw No answer
setstate CUL0 2017-10-16 21:06:13 state opened
setstate CUL0 2017-10-16 21:34:46 uptime No answer
setstate CUL0 2017-10-16 21:34:50 version No answer


defmod cm CUL_MAX 123456
attr cm IODev CUL0

setstate cm Defined


und der pi:

lrwxrwxrwx 1 root root 13 Okt 17 09:16 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Okt 17 17:15 usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0 -> ../../ttyUSB1

-> ../../ttyUSB0 = 433mhz signalduino
-> ../../ttyUSB1 = CUL

Hat mir jemanden einen Tipp woran es liegen kann?

Grüße
Flipper

Beta-User

Du scheinst einen fake-FTDI erwischt zu haben, die Nummer liefert jedenfalls mehrere Treffer bei ixquick.

Der Arduino wird jedenfalls nicht richtig initialisiert ("ignoring it"). Evtl. bringt stromlos machen und neu einstecken was. Evtl. mal einen aktiven Hub nehmen, die fake-USB-Seriell-Wandler scheinen teilweise deutlich mehr Strom als die Originalen FTDI's zu brauchen. Dann: mal nachsehen, was das Teil so an der seriellen Konsole ausgibt (kann man z.B. mit der Arduino IDE->serieller Monitor machen). Befehle zur Steuerung bei culfw.de.

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

Flipper92

#2
anbei die Bilder.

CUL oder nanoCUL Firmware flaschen?

RaspiLED

#3
Hi,
ein nanoCUL hat aber eine andere Baudrate statt 9600 mal bitte 38400 im define probieren.

Wenn der CUL nur open ist statt initialized kann es nicht gehen.

Erst wenn
get CUL0 ccconf
ein Ergebnis liefert kann man was empfangen!

Gruß Arnd

Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Flipper92

Ich hab ihn nun mal an den Windows angeschlossen.
Irgendwie komm ich garnich drauf  hab ich das Gefühl.
Vermutlich liegt das aber aber nur an mir.

Komm mit culfw.de auch nicht weiter.
Ich hab das Gefühl egal wo ich anfange lande ich entweder bei toten Links oder im Program.

Gerade auch nochmal versucht zu flaschen, für den fall, das dort der fehler liegt.
Nun kommt:
pi@raspberrypi:/opt/culfw-1.67/Devices/nanoCUL $ sudo make program
#@if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
#@if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
#echo out > /sys/class/gpio/gpio17/direction
#echo out > /sys/class/gpio/gpio18/direction
#echo 0 > /sys/class/gpio/gpio17/value
#echo 0 > /sys/class/gpio/gpio18/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio17/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio18/value
avrdude -D -p atmega328p -P /dev/ttyUSB2 -b 57600 -c arduino    -U flash:w:nanoCUL.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "nanoCUL.hex"
avrdude: input file nanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (24700 bytes):

Writing | ################################################## | 100% 10.64s

avrdude: 24700 bytes of flash written
avrdude: verifying flash memory against nanoCUL.hex:
avrdude: load data flash data from input file nanoCUL.hex:
avrdude: input file nanoCUL.hex auto detected as Intel Hex
avrdude: input file nanoCUL.hex contains 24700 bytes
avrdude: reading on-chip flash data:

Reading | ##############################################     | 91% 9.56s
avrdude: stk500_paged_load(): (a) protocol error, expect=0x14, resp=0xbe
avrdude: stk500_cmd(): programmer is out of sync
makefile:217: recipe for target 'program' failed
make: *** [program] Error 1


Zitat von: RaspiLED am 17 Oktober 2017, 20:30:42
ein nanoCUL hat aber eine andere Baudrate statt 9600 mal bitte 38400 im define probieren.
Umgestellt.

Zitat von: RaspiLED am 17 Oktober 2017, 20:30:42
Wenn der CUL nur open ist statt initialized kann es nicht gehen.
CUL0 = Initialized check

Zitat von: RaspiLED am 17 Oktober 2017, 20:30:42
Erst wenn get CUL0 ccconf ein Ergebnis liefert kann man was empfangen!
CUL0 ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB

Nun lautet es:
defmod CUL0 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 0000
attr CUL0 rfmode MAX

setstate CUL0 2017-10-17 21:12:17 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
setstate CUL0 2017-10-17 21:13:13 cmds  A B C E e F f G h i K k l M m R T t U V W X x Y Z z
setstate CUL0 2017-10-16 21:34:40 credit10ms No answer
setstate CUL0 2017-10-16 21:34:09 raw No answer
setstate CUL0 2017-10-17 21:13:13 state Initialized
setstate CUL0 2017-10-16 21:34:46 uptime No answer
setstate CUL0 2017-10-17 21:09:17 version V 1.67 nanoCUL868


und im log ein autocreate :-O

defmod MAX_18cc7e MAX ShutterContact 18cc7e
attr MAX_18cc7e IODev cm
attr MAX_18cc7e room MAX

setstate MAX_18cc7e opened
setstate MAX_18cc7e 2017-10-17 21:16:41 RSSI -55
setstate MAX_18cc7e 2017-10-17 21:16:41 battery ok
setstate MAX_18cc7e 2017-10-17 21:15:06 firmware 1.0
setstate MAX_18cc7e 2017-10-17 21:15:06 msgcnt 1
setstate MAX_18cc7e 2017-10-17 21:16:41 onoff 1
setstate MAX_18cc7e 2017-10-17 21:16:41 state opened
setstate MAX_18cc7e 2017-10-17 21:15:06 testresult 0


und ich hab das letzte Wochenende dran gearbeitet :-D

Danke es funktioniert.


Kurze Frage (hat zwar noch mit dem CUL zu tun, aber eher allgemein):
Wenn ich noch ein anderes gerät hab, das auf 868 funkt (ein ASUS Wassermelder), kann ich das mit diesem CUL versuchen oder wie muss man was umstellen?

RaspiLED

Hi,
attr CUL0 verbose 5
Dann im Eventmonitor schauen ob Du von dem Gerät was siehst, falls nicht
attr CUL0 rfmode SlowRF
set CUL0 raw X25
Und wieder im Eventmonitor schauen
Und hier oder in einem neuen Thread mal posten.

Mit
set CUL0 raw X21
wieder in Standard slowrf mode
danach
attr CUL0 rfmode MAX

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Flipper92

Zu früh gefreut.
Als ich die Heizungssteuerung aktualisieren wollte ist mir aufgefallen, das keine Daten mehr übertragen werden.
Nichts im Log mit Verbose 5.
Fensterkontakt (von Max) blinkt einmal.
Reaktion in FHEM = 0

Einer hat noch bis gestern (18.) Herabeiter, die anderen haben am Einrichtungstage (17.) Nichts mehr geliefert.

Wenn niemand ein schlauen Tipp hat, bleibt mir glaub nur ein Backup. Ich wüsste jetzt auch nicht was sich dazwischen geändert hat. Neustarten hat nichts gebracht.

Beta-User

Für den Fall, dass es doch kein fake-FTDI sein sollte (oder die fakes sich in dem Punkt gleich verhalten):

Evtl. das Test-PIN-Problem (einer der PINS des FTDI sollte auf GND liegen; wenn das nicht der Fall ist, kann man ihn mit dem danebenliegenden zusammenlöten, bitte mal im Wiki nachsehen, habe leider grad keine Fundstelle).

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

Flipper92

Zitat von: Beta-User am 19 Oktober 2017, 08:03:13
Evtl. das Test-PIN-Problem (einer der PINS des FTDI sollte auf GND liegen; wenn das nicht der Fall ist, kann man ihn mit dem danebenliegenden zusammenlöten, bitte mal im Wiki nachsehen, habe leider grad keine Fundstelle).

Ich hab eine Lötstelle (war schon drauf).
Habe es auf dem Bild "IMG_20171017_070539.jpg" eingekreist.
Bin mir nur nicht sicher ob die Lötstelle leitend ist. (Sollte ich mal den Widerstand messen.)

Beta-User

Hm, auf dem Bild sieht das nicht nach viel Lötzinn aus; meine von Chinesen gelöteten waren deutlicher, kann aber auch am Bild liegen.

Ich vermute immer noch, dass du einen schlechten, gefälschten FTDI erwischt hast, weil die Seriennummer Treffer liefert bei der Suchmaschine meiner Wahl. Muß zwar nichts heißen, weil auch fakes oft genug funktionieren, aber wenn man Probleme hat, ist es evtl. doch besser, das zu testen und den Arduino ggf. zu tauschen (und zu reklamieren!). Ich mache das, indem ich eine andere Seriennummer (und Herstellerangabe etc.) schreibe, das funktioniert jedenfalls nach meiner Erfahrung bei fakes nicht.

Wenn du grade keinen anderen zur Hand hast, kannst du auch "by-path" einbinden und 2 CH340G-Nanos nehmen.

Die fakes brauchen evtl. auch mehr Strom, wenn du kannst: Testweise mal einen aktiven Hub dazwischenklemmen.

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

Flipper92

Kann man dich mieten? :-D

Ich hab heute abend nochmal drauf geschaut und siehe da ohne etwas zu machen hat es wieder funktioniert.
Ich werde mir dennoch mal einen Aktiven Hub besorgen, eventuell liegt es ja daran.

Am Wochenende werde ich mir den Wassermelder mal genauer anschauen.

Beta-User

Zitat von: Flipper92 am 19 Oktober 2017, 21:27:35
Am Wochenende werde ich mir den Wassermelder mal genauer anschauen.
? Worauf bezieht sich das?

Zitat von: Flipper92 am 19 Oktober 2017, 21:27:35
Kann man dich mieten? :-D
Für Geld tue ich manches 8) .

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

RaspiLED

Moin,
Also der Debug Pin Fehler ist einfach zu testen. Wenn nach einem RasPi Boot der CUL open bleibt und durch rausziehen, 5s warten, einstecken wieder auf Initialized geht fehlt ein Kontakt Debug auf GND (oder  AGND direkt daneben).
Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...