Hi,
ich habe mir vor einiger Zeit zwei Nano V3 mit ATMega328p und zwei RF1101SE-v3.1 Module bestellt.
Jetzt wollte ich in den Weihnachtstagen das ganze mal an meinem Raspberry in Betrieb nehmen und bin durch Zufall auf die Anleitung in diesem Forum gestoßen.
Ich habe mir also die culfw per svn geladen, die board.h angepasst:
/* if you have an Arduino with only 8MHz disable the next line */
/*#define HAS_16MHZ_CLOCK*/
/* if you are using a CC1101 module for 868MHz disable the next line */
/*#define HAS_CC1100_433*/
Flashen sieht auch gut aus:
avrdude: input file nanoCUL.hex contains 22034 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 4.63s
avrdude: verifying ...
avrdude: 22034 bytes of flash verified
avrdude: safemode: Fuses OK (E:00, H:00, L:00)
avrdude done. Thank you.
Auch das lsusb sieht gut aus:
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Ein dmesg | grep tty gibt folgendes:
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0xb0207106 smsc95xx.macaddr=B8:27:EB:20:71:06 bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[ 0.001717] console [tty1] enabled
[ 0.140855] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 83, base_baud = 0) is a PL011 rev2
[ 0.522927] console [ttyAMA0] enabled
[ 7.128655] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 64.748055] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 76.127316] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Die rote Power LED leuchtet ständig. Ansonsten blinkt nichts....
Starte ich minicom wird die Verbindung als offline angezeigt und ich kann nichts mehr machen. Hat jemand einen Tip?
cu
Da ich ja noch einen nano hatte, der noch nicht geflashed war, habe ich von dem mal das flash ausgelesen und auf den anderen übertragen.
Siehe da - er blinkt wieder.
Dann habe ich aber wohl ein Problem mit der culfw, oder?
Hi,
/*#define HAS_16MHZ_CLOCK*/ <<<<---- Warum??
der ArduinoNano bzw der ATMega328 läuft doch (zumindest bei allen meinen mit 16Mhz.
minicom *g* bist du sicher, dass es richtig konfiguriert ist?
versuch es mal mit screen
screen /dev/ttyUSB8 38400
Grüße,
Stephan
Zitat von: rapi70 am 22 Dezember 2015, 07:57:24
Dann habe ich aber wohl ein Problem mit der culfw, oder?
Das Blinken kannst Du an- bzw. abschalten, siehe http://www.culfw.de/commandref#cmd_l
Gruß PeMue
Hi,
danke - das habe ich jetzt wieder aktiviert:
#define HAS_16MHZ_CLOCK
dann habe ich folgendes gemacht:
sudo make clean && sudo make && sudo make program
Das endet dann mit:
Reading | ################################################## | 100% 4.65s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0xe7
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK (E:00, H:00, L:00)
avrdude done. Thank you.
makefile:216: recipe for target 'program' failed
make: *** [program] Error 1
Zur Sicherheit habe ich dann noch ein -e angehängt:
avrdude -D -p atmega328p -P /dev/ttyUSB0 -b 57600 -c arduino -U flash:w:nanoCUL.hex -e
Ein screen zeigt dann auch nur einen schwarzen Bildschirm und reagiert auf nichts. Wobei ich mir da nicht sicher bin, ob ich es richtig bediene.
PS: Hatte neu verkabelt... Kann es daran liegen?
Hallo,
das sieht so aus, als ob das geflashte und das verglichene stellenweise nicht übereinstimmt.
Normalerweise müßte ein nackter Arduino, ohne Funkmodul auch flashbar sein (zumindest habe ich das bei meinem Signaduino so gemacht, den erst geflasht und dann erst die Funkmodule bekommen und angeschlossen), deshalb, um auszuschließen, daß Du in der Verkabelung etwas falsch gemacht hast oder das Funkmodul eine Macke hat und irgendwas z.B. "zu viel Power" zieht, würde ich mal alles abklemmen und nackt flashen.
Und nur nebenbei: Meine Arduinos blinken nur nach dem Flashen, dann einmal stromlos gemacht und neu gestartet blinkt da nichts mehr... Nur funktionieren sollte der dann schon ;)
Grüße
Christian
Hi,
danke - alle Kabel abgezogen und neu geflashed - wieder ein verification error. Da der Fehler direkt hier passiert:
first mismatch at byte 0x0000
denke ich mal, da wird nicht wirklich was geflashed.
Kenne ich da noch nicht wirklich aus. Muss ich vielleicht den Bootloader neu flashen?
Was mir jetzt eben aufgefallen ist - an einem USB Port am Raspberry wird der Arduino nicht mehr erkannt. Komisch...
hmm, der Arduino wird nicht mehr erkannt ...?
Die Serielle Schnittstelle wird durch die Firmware vom CUL beim nanoCUL nicht beeinflusst.
Hast du vielleichteinfach einen Anderen Prot bekommen ttyUSB1 2 3 4 ...
Hast du noch andere Sachen an der board.h geändert?
Ich hatte solche Probleme nur wenn ich zu viele Protokolle aktiviert hatte (#define HAS_***) und mir der Platz im Atmega aus ging
Ansosnten einfach zwei drei mal flashen ... die China-Arduinos resetten manchmal nicht richtig
Hi,
nein - ist immer ttyUSB0:
[45093.068847] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[45980.604466] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
Nur an einem USB Port geht's halt nicht mehr. Vielleicht mal den Rapsberry booten?
Aber wie auch immer - wenn ich make program mache, dann bekomme ich immer den verification error. Also ob der Arduino nichts mehr schreiben will.[/code]
....aaaalsoooo...
mich würden nun mal ein paar Dinge interessieren:
1) ist das das einzige USB-Gerät an dem Raspi ? Falls nicht, alle abziehen, so dass nur noch der zu flashende dran hängt.
2) Läuft FHEM noch ? Falls ja, dann mit shutdown beenden
3) ich versteh nicht ganz, was Du mit "an einem" meinst, also er wird an allen erkannt, aber an einem speziellen Anschluss nicht ? (hatte ich nach einem Blitzschlag, da hats den einen speziellen zerlegt)
Also wie ich das nach einigen Fehlschlägen machen würde:
Nur den Arduino am Raspi, Raspi vom Strom trennen, ein paar Sekunden warten, Raspi booten, FHEM beenden, Terminal -> schauen ob der Arduino unter /DEV/SERIAL/BY-ID zu sehen ist, wenn ja, dann in den Ordner, wo die zu flashende .hex drin ist, dann einfach "make program", dann wird das Dinge geflasht und verifiziert. Wenn unter /DEV/SERIAL/BY-ID nichts zu sehen ist, einmal den Arduino abziehen, wieder dran stecken (das Problem mit den Fake-FDTIs, wo die Massepins nicht verbunden sind, habe ich auch...), dann sollte der auch erkannt werden.
...Ergebnis wieder hier posten :-)
Grüße
Christian
sooooo................ ;-)
zu 1) Nein - das rennt auch sonst nur DHCP / DNS
zu 2) Der hat noch kein FHEM
zu 3) Der Raspi hat 2 USB Ports. An einem wird der Arduino sauber erkannt (DEV vorhanden), am anderen nicht.
Ich habe den Raspi jetzt stromlos gehabt und dann neu gebootet. Der Arduino war beim booten verbunden. Danach habe ich folgendes gemacht:
pi@raspberrypi ~ $ dmesg |grep tty
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0xb0207106 smsc95xx.macaddr=B8:27:EB:20:71:06 bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[ 0.001715] console [tty1] enabled
[ 0.140829] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 83, base_baud = 0) is a PL011 rev2
[ 0.522897] console [ttyAMA0] enabled
Auch ein lsusb zeigt nichts:
pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Arduino ab und wieder dran:
pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 008: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Das verhält sich am anderen USB Port identisch... (jetzt)
Was hat das mit dem Fake-FDTIs zutun?
Aber trotzdem:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0xe7
avrdude: verification error; content mismatch
...das mit dem Fake FTDI ist hier erklärt:
http://forum.fhem.de/index.php/topic,24651.msg218291.html#msg218291
Wenn ein Arduino sich flashen läßt und der andere die Fehler macht, fürchte ich, ist der zweite vielleicht hops gegangen...
Grüße
Christian
Mit dem zweiten Arduino habe ich noch nichts gemacht, außer die FW auszulesen.
Mein Problem ist, dass ich den Arduino zwar flashen kann, aber der verify fehlschlägt. Also gehe ich davon aus, dass zwar gelesen werden kann aber nicht geschrieben.
Ich denke ich starte mal einen Thread im Arduino Forum. Hat ja nicht direkt was mit FHEM zutun.
also, ich würde das mit dem zweiten (es sei denn der läuft prima und Du willst "nichts kaputt" machen) auch nochmal probieren, denn:
Wenn sich beide nicht flashen und sauber verifizieren lassen, dann sind entweder beide eher (unwahrscheinlich) bzw. das USB-Kabel (das kleine blaue war bei mir auch schon mal wackelig) defekt oder es stimmt was mit dem System nicht, mit dem Du flashen willst.
Grüße
Christian
Kann man den Arduino nicht auch am PC flashen?
Einfach um mal das System auszuschließen. Mit dem zweiten Arduino habe ich bisher noch nichts gemacht. Den habe ich eigentlich als Notreserve....
Warum sich die Mühe machen, sich mit dem Flashen am PC (geht bestlimmt, mindestens mal mit einer Linux-Emulation auf einer virtuellen Maschine, das habe ich auch schon probiert) zu beschäftigen, wenn Du den Arduino ausschließen kannst, wenn Du einfach mal den zweiten flashst ? Ich würde auch mal ein anderes USB-Kabel probieren, die haben manchmal einen Wackler...
Ich nehme mal an, Du hast das richtige Flash für Device NanoCul genommen oder ? Kompilierst Du das selber (make) oder nimmst Du das fertige .hex und flasht nur (make program) ?
Grüße
Christian
Hi,
hab es mit der Arduino IDE am PC getestet.
Ich habe das einfache Blink Beispiel getestet. Auch dort bekomme ich den Verification Error.
Nehme ich den anderen Arduino geht es.
Jetzt würde ich gerne noch verstehen, was ich falsch gemacht habe.
... wenn es mit einem geht und mit dem anderen systemunabhängig nicht, dann tippe ich mal darauf, das der andere kaputt ist...
ich hatte mal irgendwo gelesen, so schnell geht der nicht kaputt - ich werde jetzt mal den bootloader vom anderen aus flashen
Er läuft wieder - bootloader über den zweiten arduino geflashed und er rennt wieder - hier die Anleitung dazu:
http://www.instructables.com/id/How-To-Burn-a-Bootloader-to-Clone-Arduino-Nano-30/step3/Simple-few-steps/
Jetzt muss ich nur die culfw zum laufen kriegen.
Seeeehr cooool !!! Wieder was dazu gelernt !
Was war doch gleich das Problem mit der Cul FW ?
Hab die culfw drauf geflashed - kein funk modul dran - die L LED blinkt ganz schnell.
Ein screen /dev/ttyUSB0 38400 gibt nur ein schwarzes Bild.
PS: Make.h sieht so aus
/* if you have an Arduino with only 8MHz disable the next line */
#define HAS_16MHZ_CLOCK
/* if you are using a CC1101 module for 868MHz disable the next line */
#define HAS_CC1100_433
Das ist normal, daß der direkt nach dem Flashen schnell blinken kann, das machen meine auch. Dann einmal vom USB abziehen und kurz später wieder anstecken, dann sollte da nichts mehr blinken. Im FHEM müßte der sich dann als "initialized" melden. Dann sollte der mit Funkmodul auch funken.
schau mal ob unter DEV/SERIAL/BY-ID was drin steht bzw ob es das Verzeichnis überhaupt gibt. Wenn ja, dann hat der Raspi den auch erkannt und gemounted
Habs schon - habe das funkmodul angeschlossen, dann hörte L auch auf zu blinken und bei screen kommt jetzt folgendes, wenn ich ein V eingebe:
V 1.66 nanoCUL433
Ich brauche aber 868Mhz. Jetzt bin ich mir nicht sicher, was die RF1101SE noch waren.
Cool - Fernbedienung von den Funksteckdosen ausgepackt - screen gestartet und X08 eingegeben und es kommt das:
Was genau möchtest Du denn mit dem Cul machen ?
Alles was geht ;-)
Aber erstmal die Funksteckdosen steuern.
Die meisten Funksteckdosen laufen auf 433 Mhz. Ich habe mit original ELRO gute Erfahrungen gemacht, auch mit dem Dreierpack aus dem Action-Laden (da brauchte ich aber eine IT-Fernbedienung zum Anlernen). Problem ist aber, daß man nie sicher sein kann, ob die wirklich geschaltet haben. Deshalb baue ich grad die wichtigen Sachen auf bidirektional (HM) um. Die wären auch mit dem Cul schaltbar, aber auf 868Mhz. Ich habe bei Ebay günstig den HM-CFG-USB bekommen, der sendet sehr gut. Bei mir laufen die IT-kompatiblen Funksteckdosen mit der V1.65 recht gut, mit der a-FW bekomme ich nur ein ganz paar wenige zum schalten (haben anscheinend einige hier das Problem, bei den anderen läuft das super). Ich nutze einen mit V1.65 für IT und einen mit a-FW für Temperatur/Feuchtigkeitssensoren, das läuft auch recht gut
Ich habe die Brennenstuhl RCS1000N Comfort. Die laufen auch auf 433Mhz.
Die Cul habe ich in FHEM eingebunden und eine Steckdose angelegt:
define CUL_0 CUL /dev/ttyUSB0@38400 1234
attr CUL_0 rfmode SlowRF
define TE.RCS1000N_A IT 000000FFFF FF F0
attr TE.RCS1000N_A IODev CUL_0
attr TE.RCS1000N_A alias Stehlampe
attr TE.RCS1000N_A group Schalter
attr TE.RCS1000N_A model itswitch
attr TE.RCS1000N_A room Fluroben
Im log sehe ich dann:
2015.12.23 21:46:14 3: Opening CUL_0 device /dev/ttyUSB0
2015.12.23 21:46:15 3: Setting CUL_0 serial parameters to 38400,8,N,1
2015.12.23 21:46:15 3: CUL_0 device opened
2015.12.23 21:46:18 3: CUL_0: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2015.12.23 21:46:18 1: Including ./log/fhem.save
2015.12.23 21:46:18 1: statefile: Please define FileLog_IT_00000FFFFF first
Please define IT_00000FFFFF first
Please define IT_00000FFFFF first
Please define IT_00000FFFFF first
2015.12.23 21:46:18 1: usb create starting
2015.12.23 21:46:20 3: Probing CUL device /dev/ttyAMA0
2015.12.23 21:46:20 3: Probing TCM_ESP3 device /dev/ttyAMA0
2015.12.23 21:46:20 3: Probing FRM device /dev/ttyAMA0
2015.12.23 21:46:26 1: usb create end
2015.12.23 21:46:26 2: Error messages while initializing FHEM: statefile: Please define FileLog_IT_00000FFFFF first Please define IT_00000FFFFF first Please define IT_00000FFFFF first Please define IT_00000FFFFF first
2015.12.23 21:46:26 0: Featurelevel: 5.7
2015.12.23 21:46:26 0: Server started with 11 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2827)
2015.12.23 21:46:38 2: IT set TE.RCS1000N_A on
2015.12.23 21:46:40 2: IT set TE.RCS1000N_A on
2015.12.23 21:46:41 2: IT set TE.RCS1000N_A on
Wenn ich im FHEM die Steckdose schalte, dann sehe ich am CUL auch, dass die LED kurz aufblinkt. Die Steckdose wird aber nicht geschaltet.
Die Steckdose wird über DIP Schalter konfiguriert. Die ersten 6 (also 1-5 und A) sind auf ON, die anderen alle auf OFF.
Somit müsste eigentlich alles richtig sein. Was ich nicht verstehe ist das "1234" bei dem define.
Kann es sein, dass FHEM selber lernt? Wenn ich nur die CUL anlege und alles mit TE.RCS1000N_A aus der FHEM.cfg entferne und dann die Fernbedienung drücke, dann trägt FHEM mir was in die cfg ein:
define IT_000000FFFF IT 000000FFFF 0F F0
attr IT_000000FFFF IODev CUL_0
attr IT_000000FFFF room IT
define FileLog_IT_000000FFFF FileLog ./log/IT_000000FFFF-%Y.log IT_000000FFFF
attr FileLog_IT_000000FFFF logtype text
attr FileLog_IT_000000FFFF room IT
define IT_00000FFFFF IT 00000FFFFF 0F F0
attr IT_00000FFFFF IODev CUL_0
attr IT_00000FFFFF room IT
ZitatKann es sein, dass FHEM selber lernt?
Ja, das nennt sich "autocreate". Ist standartmäßig aktiv und wird von vielen per Hand abgeschaltet (attr autocreate disable 1), wenn die Einsteigerzeit beendet und das System im Wesentlichen vollständig ist. Du bist fachlich ja schon sehr gut vorgeschädigt - zieh dir über die Festtage doch mal das Einsteiger- PDF aus dem Wiki rein. Du solltest schnell gute Fortschritte machen... :)
Gruß
Frank
Hi,
danke - das mit dem Autocreate hatte ich zwischenzeitlich schon gefunden.
Gut zu wissen, somit ist mal klar, dass der Stick auch empfängt. Aber ich bekomme die Steckdose damit noch nicht geschaltet:
define CUL_0 CUL /dev/ttyUSB0@38400 1234
attr CUL_0 rfmode SlowRF
define IT_000000FFFF IT 000000FFFF 0F F0
attr IT_000000FFFF IODev CUL_0
attr IT_000000FFFF room IT
attr IT_000000FFFF ITrepetition 12
attr IT_000000FFFF model itswitch
define FileLog_IT_000000FFFF FileLog ./log/IT_000000FFFF-%Y.log IT_000000FFFF
attr FileLog_IT_000000FFFF logtype text
attr FileLog_IT_000000FFFF room IT
Ich hatte dann auch noch das hier getestet:
define IT_000000FFFF IT 000000FFFF FF F0
Das PDF hab ich schon am Tablet ;-)
Aber erst will ich mal den stick mit Basisfunktionen zum laufen bekommen.
cu
Jawoll, so isses :-) FHEM legt jedes Gerät, daß es erkennt, automatisch an, deshalb keine Mühe machen, einfach Taste drücken, dann legt FHEM Dir den Schalter an. Mit "rename <alter Name> <neuer Name>" oben im Eingabefeld kannst Du dann den Wunschnamen vegeben, dann sieht das nicht so kryptisch aus. Wenn FHEM das selber erkennt, sollte es auch die Dosen schalten können. Wenn's mit der a-FW nicht gehen sollte, mal die original probieren. Bei mir geht das auch nur mit der Original wirklich sicher, einige Dosen gehen auch mit der a-FW, bei vielen hier gehen alle... scheint am Arduino zu liegen, je nachdem, was man da für einen erwischt hat.
Kleiner Tip: lege den Cul in der Form an:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50478OC-if00-port0@38400 3456
<-PFAD IM RASPI-><----------EINDEUTIGE ID DES ARDUINO-------> <--BAUTRATE--> <-SELBST GEWÄHLTE 4ST. ID->
Dann findet FHEM den auch wieder, wenn Du noch andere USBs anschließt oder den Anschluss wechselst, hat aber den Nachteil, wenn Du den Arduino tauscht, dann musst Du die neue Adresse von dem anpassen. Ist also Geschmackssache, aber so läuft das ganz gut
Grüße und fröhliche Weihnachten
Christian
PS: Wenn Du zuviele "unbekannte" Geräte aus der Nachbarschaft angelegt bekommst, kannst Du autocreate abschalten oder Ignoretypes festlegen, das kann sonst ganz schön nerven....
ÄHM, warum
Zitat
attr CUL_0 rfmode SlowRF
??? Das ist, wenn Du einen 868er temporär auf 433 schalten willst, wenn du einen 433er hast, würde ich das weglassen...#
Grüße
Christian
Habe es entfernt - bringt aber nichts.
Es kommt mir so vor, als ob der stick nicht sendet.
Das müsste ich doch prüfen können, wenn ich den zweiten stick an einem anderen Raspberry in Betrieb nehme, oder?
Tja - jetzt fällt mir folgendes auf - ich weiß eigentlich nicht genau was für ein Modul ich habe.
Im board.h habe ich auf 433 eingestellt.
Laut AliEpxress ist das ein 868 Modul.
Ich habe die Firmware neu aufgespielt und in der board.h auf 868 gestellt.
Es wurden alle autocreated Items in der fhem.cfg gelöscht und dann neu gestartet. Die Items wurden neu angelegt.
Aber es tut sich noch immer nichts.
Also das sollte damit auf jeden Fall gehen. Dieser Chip ist ja auch im CUL von Busware drin. Wenn vielleicht auch kein abgekupferter, was ich hier nicht ausschließen will... ;)
Beschäftige dich doch jetzt mal mit den Funkparametern des Sticks: In der FHEM- Oberfläche kannst du dem Stick ein "get <Name> ccconf" entlocken (steht auch schon in den Readings). Da bekommst du die Funkkonfiguration ausgegeben. Dann setzt du (ebenfalls hier, bei "set") mal die Freq. auf 433. Und die Idee mit dem 2. Raspi war doch auch schon gut. Ich nehme dafür immer das NB, stecke den CUL dran (FTDI- Treiber ggf. nachinst.) und gucke mit Hyperterm. ob ich was empfangen kann (mit "V" prüfen ob der CUL da ist und dann mit "x21" auf Empfang schalten - ggf. nochmal in der Commandref des CUL nachsehen ob x21 oder X21 bin mir nicht ganz sicher).
Weihnachtliche Grüße
Frank
..auf dem Bild ist ein CC110L zu sehen, habe irgendwo schon mal gelesen, daß einige da Probleme mit haben... Muss aber nichts heissen.
Hi,
so - habe es endlich geschafft.
Ich vermute ich hatte vorher die Frequenz (set CUL_0 freq) nicht richtig gesetzt.
Jetzt rennt das wie Teufel!
Danke noch mal...
Das ist doch schön, wenn's an Weihnachten dann endlich klappt :-)
Fröhliche Weihnachten
???Hallo Zusammen,
ich habe ein ähnliches Problem:
Besitze zwei Arduino Nanos (Revision 3.0 - zumindest laut Aufdruck)und ein RF1100SE 433 und will mit einen 433er CUL gemäss FHEM Wiki aufbauen:
http://www.aliexpress.com/item/Nano-V3-0-FT232-chip-with-usb-cable-for-Arduino-free-shipping/32364776520.html
http://www.aliexpress.com/item/1Pcs-CC1101-Wireless-Transceiver-Module-with-SMA-Antenna-for-Arduino-NEW/32351288041.html
Die Nano's haben definitiv den FTDI -Serialadapter und funktionieren eigentlich tadellos (Testscripte mit der Arduino-IDE
laufen). Die USB-Schnittstelle wird unter Linux erkannt.
Ich konnte auch die CULFW erfolgreich kompilierenund flashen (unter Linux) ohne Fehlermeldungen.
Nur ist es so, dass ich nicht richtig mit dem CUL kommunizieren kann. Mit screen kann ich mich zwar verbinden (38400 Baud) und alle Tastatureingaben werden auch von einem Auflbinken der roten RX LED quittiert. Aber es kommt keine Antwort (z.B. auf V).
Habe schon mehrmals neu geflasht - beide Nanos, mit nanoCUL und alternative nanoCUL, aber immer das selbe Verhalten (auch nackt ohne Funkmodul, da ich zuerst einen Verdrahtungsfehler vermutete). Unter FHEM lässt er sich daher auch nicht einbinden.
Nach dem flashen blinkt die rote LED sehr schnell (hiweis auf Fehler?), nach ab- und an-stecken dann nicht mehr.
Mit meinem Busware CUL (868) funzt hingegen alles wie geschmiert.
Was könnte ich noch tun um herauszufinden, was an der FW nicht passt. Ich vermute, dass irgend ein setting in der board.h nicht passt, aber was? (die 16 MHZ hab ich schon mal auskommentiert, aber das half erwartungsgemäss nichts).
Vielen Dank im Voraus für Eure Hilfe!
Hallo,
hast Du auch die 433er FW geflasht ? Was möchtest Du denn damit schalten ?
Zitat
Nach dem flashen blinkt die rote LED sehr schnell (hiweis auf Fehler?), nach ab- und an-stecken dann nicht mehr
Das ist normal, das machen meine auch so, nach dem flashen trennen, neu anstecken
ZitatHabe schon mehrmals neu geflasht - beide Nanos, mit nanoCUL und alternative nanoCUL, aber immer das selbe Verhalten (auch nackt ohne Funkmodul, da ich zuerst einen Verdrahtungsfehler vermutete). Unter FHEM lässt er sich daher auch nicht einbinden.
unter /DEV/SERIAL/BY-ID schauen, ob der Nano dort erkannt wird. Die ID dort rauskopieren, besonders auf die 00 bzw OO achten, dann den Nano im FHEM definen:
define nanoCUL CUL /dev/serial/by-id/HIER DIE ID VOM NANO EINGEBEN@38400 1234
dann sollte der angelegt werden und wenn alles von Seiten des Nano klappt, mit Status "initialized"
Wenn es dann doch noch nicht geht, dann ist irgendwas mit der Kabelage oder dem CC1100 faul.
Grüße
Christian
Hallo CS-Online,
vielen Dank!
ich habe nun die Lösung gefunden: es lag an einem Layoutfehler auf dem China-Nano.
Nach Indizien in diesem Forum fand ich folgenden link: https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/ (https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/)
Das hat's gebracht :P. Jetzt Antworte die FW über den seriellen Port. Auch das RF1100SE ging auf Anhieb.
Seltsam ist nur, dass ich zuvor ein anderes Sketch zum auslesen eines DS18S20 getestet habe, bei dem das senden per USB
problemlos funktionierte
Hallo Bep,
das ist ein bekannter Fehler bei den China-FTDIs, aber normalerweise arbeiten die trotzdem, nur wenn man den Raspi neu startet, dann wird der Nano nicht erkannt, man muss den dann im Betrieb des Raspis einmal abziehen und dann wieder reinstecken, dann geht das "normalerweise" und der taucht dann wieder unter DEV/SERIAL/BY-ID auf... wenn man den Ärger umgehen will, dann ist die Lötbrücke die beste Lösung,
Grüße
Christian