Von Zeit zu Zeit fällt mein Jeelink von STATE "Initialized" zurück nach "Openend". Eine Ursache konnte ich im Log nicht erkennen, eine Fehlfunktion allerdings auch nicht. D.h. der Jeelink funktioniert weiter einwandfrei (ich benutze ihn mit LaCrosse-Sketch zum Empfang von mehreren TFA 30.3144 und TFA 30.3147). Ich erkenne es nur daran, dass die blaue LED wieder blinkt (eigentlich per "initCommands 0a v" abgeschaltet). Wenn ich den Stick kurz abziehe und wieder einstecke initialisiert er sich wieder richtig, alternativ kann ich Fhem neustarten.
Letzteres würde ich jetzt per watchdog implementieren, um Ruhe zu haben. Aber mich interessiert natürlich ob das Verhalten bekannt ist, und ich evtl. etwas falsch konfiguriert habe bzw. etwas weniger holzhammermässiges dagegen tun kann.
Hier noch die Definition des Jeelink:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 13
JEELINK_MSGCNT 29405
JEELINK_TIME 2015-06-02 21:10:02
NAME JEELINK
NR 70
PARTIAL
RAWMSG OK 9 29 1 4 158 63
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1e @17.241 kbps / 868300 kHz]
Matchlist:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
Readings:
2015-06-02 12:20:08 state opened
Attributes:
devStateIcon Initialized:jeelink@green .*:jeelink@red
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
fp_Wohnung 640,30,0,
fp_Wohnung2 715,1100,0,
group Antenne
icon cul_usb
initCommands 0a v
room System
Hallo,
auch wenn das Thema schon etwas älter ist bin ich darauf gestoßen, weil ich seit ein paar Tagen genau das gleiche Problem habe.
Mein JeeLink (V3c) verliert unregelmäßig die Verbindung und danach leuchtet die blaue LED.
Das Reading "state" ändert sich zu opened und es wird nichts mehr empfangen.
Oftmals reicht es schon die Definition neu zu setzen. Heißt ich klicke auf aif "DEF" ändere nichts und speichere die config wieder.
Ist das mittlerweile ein bekannteres Problem?
Grüße
Zitat von: Morrino am 06 Dezember 2015, 10:34:51
Oftmals reicht es schon die Definition neu zu setzen. Heißt ich klicke auf aif "DEF" ändere nichts und speichere die config wieder.
Ja, wenn man die def ändert, macht das einen Reset. ist wie "set myJeeLink reset"
Kannst das timeout Attribut vom JeeLink device auf z.B. 120,30 setzten, dann macht er automatisch einen Reset, wenn zwei Minuten lang keine daten mehr kommen.
In den allermeisten Fällen war das Problem bisher durch eine nicht stabil genuge Spannungsversorgung des Raspi verursacht.
hallo,
ich habe das gleiche problem das der jeelink nur noch im state opened bleibt, auch ein "set myjeelink reset" nützt nichts.
den jeelink habe ich so zugewiesen /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL06YRIK-if00-port0@57600 es kommen zwar
daten an aber ich meine das vor dem neustart von meinem raspberry pi 2 immer initialized im state stand.
oder ist es doch normal das der jeelink im state opened bleibt?
Gruß
hallo, also bei mir ist der normale Jeelink und der WlanJeelink sowie der HM-USB immer auf opened.
Nur mein CUL_433 und CUL_868 sind auf inizialisiert
gruß
Ich habe das Problem auch seit einigen Tagen, mal hilft reset comman, mal def und speichern, keine hinweise im log, hatt schon ein HW Problem im Verdacht aber da ich nicht alleine bin...
Spannungsversorgung kann eigentlich nicht das Problem sein, habe einen Hub mit extra Spannungsversorgung im Einsatz, die anderen 6 USB Geräte arbeiten einwandfrei, die Konfiguration läuft seit gut einam halben Jahr unverändert.
Gruß
Sent from my iPad using Tapatalk
@Andre, ich fürchte daran ist mein Vorschlag mit dem Frischhalten des Timestamp vom state Readings schuld :(
Nimmt man dort die Zeile :
readingsSingleUpdate($hash, "state", $hash->{READINGS}{state}{VAL}, 0);
wieder raus nimmt das Internal STATE auch wieder den Zustand Initialized an, allerdings sind dann danach STATE und state nicht synchron
Der state sollte initialized sein.
Interessant ist, dass es ein habes Jahr läuft, und dann ohne jegliche Veränderung nicht mehr.
Zitat von: Wzut am 21 Februar 2016, 18:45:18
@Andre, ich fürchte daran ist mein Vorschlag mit dem Frischhalten des Timestamp vom state Readings schuld :(
schka17 schreibt aber, dass er nichts verändert hat ...
Hat er nun ein Update gemacht oder nicht?
Zitat von: HCS am 21 Februar 2016, 18:47:55
Hat er nun ein Update gemacht oder nicht?
Die Update Sucht ist doch so verbreitet das es für die meisten keine Änderung ist ....
Hallo,
Ich meinte die Hardware ist unverändert(wegen meiner Vermutung mit HW Problem), updates mach ich relativ regelmäßig, vor ein paar Tagen das letzte Mal
Gruß
Sent from my iPad using Tapatalk
Zitat von: schka17 am 21 Februar 2016, 19:08:07
Ich meinte die Hardware ist unverändert, updates mach ich relativ regelmäßig, vor ein paar Tagen das letzte Mal
Na dann hat Wzut recht
Mit der Updatesucht?
Sent from my iPad using Tapatalk
Zitat von: schka17 am 21 Februar 2016, 19:10:57
Mit der Updatesucht?
Nein, damit, dass er vermutlich das Probelm ausgelöst hat.
Sorry, klar, war nur ein Scherz
Sent from my iPad using Tapatalk
sollte ich versuchen ein backup zurück zu spielen?
IMHO ist der Fehler nicht tragisch, der Jee macht was er soll nur das halt eben ein paar Buchstaben der Anzeige nicht ganz stimmen :)
also ist es auch egal das die reading state fast jede sekunde aktualisiert wird? ist bei meinem nanocul nicht so, dort steht nur die zeit wann er
initialisiert worden ist.
bitte testet mal die angehängte version.
das timestamp aktualisieren ist noch drin aber es wird nur noch state direkt geändert und STATE sollte immer synchron sein.
gruss
andre
state und State beide inizialisiert, nix openend ;)
oh da hast ja richtig tabula rasa mit $hash->{STATE} gemacht :)
Ein Schnelltest hier auf meiner Testinstallation schaut schon mal gut aus,
die Live Systeme sind erst heute Abend dran wenn ich zu Hause bin.
Dann ist STATE jetzt ja state of the art ;D ;D ;D
ich hab oben noch mal eine etwas neuere version angehängt.
bitte vor allem auch mal testen ob direkt nach dem fhem start alles passt. d.h. die initCommands auch korrekt abgearbeitet werden und initMessages für KVP richtig gefüllt wird.
wenn alles funktioniert checke ich es morgen ein.
gruss
andre
Zitat von: HCS am 22 Februar 2016, 15:25:38
Dann ist STATE jetzt ja state of the art
@HCS, der war gut 8) aber was blieb ihm auch anderes übrig, der strenge fhem Modul TÜV Prüfer betateilchen hätte ihm sonst vermutlich demnächst die svn Plakette abgekratzt .... ;D Spatz beiseite :
@Andre : meinem Systeme sind wohl zu schnell oben, da ist im Browser das opened nach shutdown restart erst gar nicht sichtbar sondern nur "initialized"
Zitat von: justme1968 am 22 Februar 2016, 13:55:24
bitte testet mal die angehängte version.
Gerade auf einem Testsystem probiert, sieht gut aus.
Sowohl shutdown restart als auch myJeeLink reset:
opened -> initialized
initCommands werden gesendet
timestamp ändert sich
hab diese version eingecheckt.
gruss
andre
Hallo Andre,
auch bei mir funktionierts , nur die Umstellung von Status "Initialized" auf "initialized" hat mich ein bischen herausgefordert ;)
Gruß
Karl
Bei mir steht seit Kurzem auch opened obwohl ich schon den timeout mit 120,30 belegt habe. Auch die * 36_JeeLink.pm kommt ja denke ich mal via fhem update. Gibt es da noch andere Probleme ?
Hallo,
ich habe versucht einen JeeLink in Betrieb zu nehmen, aber bei mir steht der Status auch nur auf "opened".
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB2@57600
DeviceName /dev/ttyUSB2@57600
FD 15
NAME JeeLink868
NR 106
PARTIAL ��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
STATE opened
TYPE JeeLink
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2017-12-17 17:45:32 state opened
Attributes:
flashCommand 1
initCommands 0xA706h
room system
verbose 5
Und dann habe ich noch das Problem, dass bei PARTIAL die 1000 Fragezeichen stehen.
Woran könnte das liegen?
Geflashed habe ich mit Sketch für PCA 301.
Gruß
Robby
ganz sicher das USB2 auch der richtige Port ist ?
Dein Partial sieht aus als ob da zwar irgend ein Gerät antwortet aber mit einer falschen Baudrate
check den mal auf der Konsole mit lsusb , bzw. binde den besser mit /dev/serial/by-id/ ein (zur not auch mit /dev/serial/by-path wenn dein Chip keine eindeutige ID hat)
So schauts z.b. bei mir aus mit zwei JeeLinks:
define JeeLink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI028YFE-if00-port0@57600
define JeeLink2 JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02ID33-if00-port0@57600
Ja USB2 ist richtig. Habe noch 2 CULs.
drwxr-xr-x 2 root root 60 Dez 17 16:13 .
drwxr-xr-x 4 root root 80 Dez 17 16:13 ..
lrwxrwxrwx 1 root root 13 Dez 17 16:13 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2
Habe definiert über path
Sieht besser aus, aber jetzt Status "disconnect".
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /usb-1a86_USB2.0-Serial-if00-port0@-b57600
DeviceName /usb-1a86_USB2.0-Serial-if00-port0@-b57600
NAME JeeLink868
NR 106
PARTIAL
STATE disconnected
TYPE JeeLink
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2017-12-17 21:03:38 state disconnected
Attributes:
flashCommand 1
initCommands 0xA706h
room system
verbose 5
Hat jemand eine Idee, was bei mir im Argen liegt? :-\
Zitat von: ing.robby am 17 Dezember 2017, 21:08:06
Habe definiert über path
Sieht besser aus, aber jetzt Status "disconnect".
DEF /usb-1a86_USB2.0-Serial-if00-port0@-b57600
DeviceName /usb-1a86_USB2.0-Serial-if00-port0@-b57600
Nein , das schaut nicht besser aus sondern schlechter. So ist der Pfad nicht , vergleiche das mal mit meinem Define Beispiel.
Bei dir fehlt das /dev/serial/by-path vor deinem /usb-1a86_USB2.0-Serial-if00-port0@-b57600
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0@-b57600
DeviceName /dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0@-b57600
NAME JeeLink868
NR 106
PARTIAL
STATE disconnected
TYPE JeeLink
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2017-12-20 13:03:18 state disconnected
Attributes:
flashCommand 1
initCommands 0xA706h
room system
verbose 5
Stimmt etwas mit der Hardware nicht oder ist immer noch ein Fehler in der Konfiguration?
1. Deine Definition sieht nicht sauber aus, gib uns bitte mal:
ls -lha /dev/serial/by-path
ls /dev/serial/by-id/
Ich glaube, Du hast "by-path" und "by-id" gemischt.
2. Ist Dein FHEM user in der richtigen Gruppe? Gib uns bitte mal:
grep fhem /etc/group
Also mit /dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0
funktioniert es nicht.
flashing JeeLink JeeLink868
detected Firmware: PCA301.hex
hex file: ./FHEM/firmware/JeeLink_PCA301.hex
port: /dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0
log file: ./log/JeeLinkFlash.log
JeeLink868 closed
command: avrdude -p atmega328P -c arduino -P /dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0 -D -U flash:w:./FHEM/firmware/JeeLink_PCA301.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: ser_open(): can't open device "/dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0": No such file or directory
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
JeeLink868 opened
Mit /dev/ttyUSB2
hingegen schon. Allerdings gibt es ein anderes Problem:
flashing JeeLink JeeLink868
detected Firmware: PCA301.hex
hex file: ./FHEM/firmware/JeeLink_PCA301.hex
port: /dev/ttyUSB2
log file: ./log/JeeLinkFlash.log
JeeLink868 closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB2 -D -U flash:w:./FHEM/firmware/JeeLink_PCA301.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
JeeLink868 opened
Hallo Werniemann,
drwxr-xr-x 2 root root 100 Dez 20 14:23 .
drwxr-xr-x 4 root root 80 Dez 20 14:23 ..
lrwxrwxrwx 1 root root 13 Dez 20 14:23 platform-3f980000.usb-usb-0:1.2:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Dez 20 14:23 platform-3f980000.usb-usb-0:1.4:1.0-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Dez 20 14:23 platform-3f980000.usb-usb-0:1.5:1.0-port0 -> ../../ttyUSB2
usb-1a86_USB2.0-Serial-if00-port0
tty:x:5:robby,fhem
avrdude: ser_open(): can't open device "/dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0": No such file or directory
Sagt eigentlich alles. Wie ich geschrieben habe, hast Du "by-path" und "by-id" verwechselt.
also in Deinem Falle müsste es heißen:
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
(Wenn es denn das Gerät ist)
Könntest Du bitte:
ls -lha /dev/serial/by-id/
Ist Dir eigentlich klar, was meine Befehle so machen?
Ja, ich denke schon. Die Id bzw. den Pfad der USB Geräte anzeigen..
drwxr-xr-x 2 root root 60 Dez 20 19:17 .
drwxr-xr-x 4 root root 80 Dez 20 19:17 ..
lrwxrwxrwx 1 root root 13 Dez 20 19:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2
Wenn ich über
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@-b57600
definiere, wird der JeeLink richtig angesprochen. Das sehe daran, dass die rote LED leuchtet, wenn ich die raw definitions editiere.
Bleibt immer noch das Problem, dass wenn ich aus fhem flashe, folgende Meldung kommt:
flashing JeeLink JeeLink868
detected Firmware: PCA301.hex
hex file: ./FHEM/firmware/JeeLink_PCA301.hex
port: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
log file: ./log/JeeLinkFlash.log
JeeLink868 closed
command: avrdude -p atmega328P -c arduino -P /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0 -D -U flash:w:./FHEM/firmware/JeeLink_PCA301.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
JeeLink868 opened
list JeeLink868 ergibt Folgendes:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@-b57600
DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@-b57600
FD 25
NAME JeeLink868
NR 107
PARTIAL �������������������������������������������������������������������������������������������������
STATE opened
TYPE JeeLink
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2017-12-20 21:17:52 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Zitatusb-1a86_USB2.0-Serial
Und Du bist Dir bei dem Namen sicher, das es ein JeeLink ist?
Es ist ein Selbstbau, Nano V3 mit FTDI Chip und ATmega328 mit Funkmodul RFM12B.
Ich vermute ja, dass evtl. mit dem Funkmodul etwas nicht stimmt. Ich habe gelesen, dass die RFM12B teilweise eine große Streuung in der Frequenz aufweisen. Wäre für mich eine Erklärung, dass der Fehler ,,not in sync" beim flashen kommt.
Aber ich dachte, dass man die Frequenz sotwareseitig in fhem anpassen kann...
flashen hat nichts mit dem Funkempfänger zu tun, sondern Programmiert den Microcontroller
Bist Du Dir sicher, das Dein Selberbau funktioniert? Hast DU mal außerhalb von fhem den Stick geflasht?
Sorry aber damit kenne ich mich nicht aus.
1. Das ist kein FTDI, sondern ein CH340G oder eine andere WCH-Variante. Macht aber nix...
2. Wenn das mit der DEF noch so steht, ist es wahrscheinlich falsch:
ZitatDEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@-b57600
Sollte m.E. so lauten:
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600Hast du noch weitere Clone mit dem USB-Chip im Einsatz, oder warum machst du das "by-path"?
Gruß, Beta-User
Hallo Beta User,
Das ist kein FTDI, sondern ein CH340G oder eine andere WCH-Variante. Macht aber nix...
Nein es ist ein FTDI Chip verbaut, nur ohne eine eigene ID.
Ich habe 3 dieser Nano V5 gekauft. 2 als nanoCUL gebaut, laufen parallel und einwandfrei, würde mit einem CH340G so nicht funktionieren.
Die nanoCULs habe ich über /dev/tty/USB0 und 1 definiert.
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600
Das man vor der Baudrate ein ,,-b" setzt habe ich aus dem Wiki, sollte man wohl bei Clonen machen. Hab's aber auch schon ohne den Zusatz versucht.
Bist Du Dir sicher, das Dein Selberbau funktioniert? Hast DU mal außerhalb von fhem den Stick geflasht?
Ich glaube ja, dass mit dem Funkmodul etwas nicht stimmt...
Zitat von: ing.robby am 20 Dezember 2017, 21:20:26
lrwxrwxrwx 1 root root 13 Dez 20 19:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2
1a86 ist die Herstellerkennung von winchiphead, aber egal; du scheinst ja zu wissen, was du tust...
Bei echten FTDI's (und bei eventuellen Klonen, die mit einer "0000000" kamen) kann man mit ein wenig Glück die Seriennummer usw. ändern (bei Klonen evt. nur mit einem Linux-Tool von hier (http://rtr.ca/ft232r/)).
ZitatDas man vor der Baudrate ein ,,-b" setzt habe ich aus dem Wiki, sollte man wohl bei Clonen machen. Hab's aber auch schon ohne den Zusatz versucht.
Danke, wieder was gelernt, habe ich bisher nicht benötigt.
Zitatlaufen parallel und einwandfrei, würde mit einem CH340G so nicht funktionieren.
OK, habe ich noch nicht ausprobiert, aber Otto123 empfiehlt gerade für solche Konstellationen dann die "by-path"-Variante. Hatte bisher keinen Anlaß daran zu zweifeln, dass das auch mit CH340G's funktioniert.
Vielleicht lieferst du uns ein vollständiges ls -l /dev/serial/by-id, dann wissen wir, worüber wir wirklich an der Stelle sprechen ::) .
Zitat1a86 ist die Herstellerkennung von winchiphead, aber egal; du scheinst ja zu wissen, was du tust...
Bei echten FTDI's (und bei eventuellen Klonen, die mit einer "0000000" kamen) kann man mit ein wenig Glück die Seriennummer usw. ändern (bei Klonen evt. nur mit einem Linux-Tool von hier).
Ich bin nicht aus der Mikrocontroller Branche. Ich kann nur sagen, was ich gelesen oder getestet habe. Wenn ich falsch liege, lasse ich mich gern berichtigen.
ls -l /dev/serial/by-id:
lrwxrwxrwx 1 root root 13 Dez 20 19:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2
Gruß Robby
Zitat von: ing.robby am 21 Dezember 2017, 15:19:11
Ich bin nicht aus der Mikrocontroller Branche.
Moi non plus, ist auch alles angelesen und anexperimentiert :) .
Zur Erklärung: anhand der nummerischen Angaben zu Hersteller und Modell erkennen dann die Betriebssysteme, welchen Treiber sie laden müssen (siehe "udev" für aktuelle Linuxe).
Seltsam ist hier aber, dass keine Modellnummer mitgeliefert wird (und du uns die anderen beiden Devices vorenthalten hast).
Könnte ein Stromversorgungsthema sein, sollten die anderen beiden auch noch angestöpselt sein. Klemm' evtl. mal einen aktiven Hub dazwischen (die "by-path"-Definition muß dann aber angepaßt werden). Wenn es das nicht ist, könnte es hier sein, dass schlicht der USB-Wandler kaputt ist (dann muß eben #4 ran...).
Wenn dir der Händler die Dinger als echte FTDI's verkauft hat (und die anderen bei ls -l... auch die WCH-Kennung auswerfen), solltest du den mal drauf ansprechen, dass das Murks ist, was er da erzählt.
ZitatSeltsam ist hier aber, dass keine Modellnummer mitgeliefert wird (und du uns die anderen beiden Devices vorenthalten hast).
Ich habe nichts vorenthalten. Mehr wurde nicht angezeigt.
ls -l /dev/serial/by-id:
root@robby-RasPi:~# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Dez 20 19:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2
root@robby-RasPi:~# ls -lah /dev/serial/by-id/:
root@robby-RasPi:~# ls -lah /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Dez 20 19:17 .
drwxr-xr-x 4 root root 80 Dez 20 19:17 ..
lrwxrwxrwx 1 root root 13 Dez 20 19:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2
root@robby-RasPi:~#
lsusb:
root@robby-RasPi:~# lsusb
Bus 001 Device 007: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 005: ID 1997:2433
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@robby-RasPi:~#
ls -lha /dev/serial/by-path:
root@robby-RasPi:~# ls -lha /dev/serial/by-path
total 0
drwxr-xr-x 2 root root 100 Dez 20 19:17 .
drwxr-xr-x 4 root root 80 Dez 20 19:17 ..
lrwxrwxrwx 1 root root 13 Dez 20 19:17 platform-3f980000.usb-usb-0:1.2:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Dez 20 19:17 platform-3f980000.usb-usb-0:1.4:1.0-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Dez 20 19:17 platform-3f980000.usb-usb-0:1.5:1.0-port0 -> ../../ttyUSB2
root@robby-RasPi:~#
Mehr Befehle fallen mir nicht ein zum Anzeigen der USB Geräte :)
ZitatWenn dir der Händler die Dinger als echte FTDI's verkauft hat (und die anderen bei ls -l... auch die WCH-Kennung auswerfen), solltest du den mal drauf ansprechen, dass das Murks ist, was er da erzählt.
Na das hoffe ich nicht für den Verkäufer! :-\
Zitat von: ing.robby am 21 Dezember 2017, 15:54:51
Mehr Befehle fallen mir nicht ein zum Anzeigen der USB Geräte :)
...mir dann auch nicht, wie gesagt, mehrere von den CH340G-Dingern hatte ich nie gleichzeitig am Laufen...
Zitat von: ing.robby am 21 Dezember 2017, 15:54:51
Na das hoffe ich nicht für den Verkäufer! :-\
Der hat dich definitiv angeschmiert oder es stand da nur was von "kompatibel", diese Angaben sind manchmal sehr bewußt sehr gut versteckt.
Habe zwischenzeitlich auch festgestellt, dass die def bei diesen Arduinos nie eine Seriennummer enthält, das ist also kein Hinweis auf eine Fehlfunktion. Bleibt: Probleme mit der Spannungsversorgung oder eben ein fehlgeschlagener Flashversuch (unterstellt, die Baudrate stimmt für den Gerätetyp jeelink und die firmware).
Gibt's da eigentlich auch Unterschiede bei der zu flashenden firmware zwischen dem Originalen und den Nano-basierten wie beim CUL?
Okay JeeLink funzt jetzt :)
Ich habe nochmal versucht über die Arduino Software unter Linux den JeeLink zu flashen, aber das hat auch nicht mehr funktioiniert.
Beim Kompilieren kam immer folgender Fehler:
pca301.cpp.o:pca301.cpp:422: first defined here
pca301serial/pca301.cpp.o: In function `fillConf()':
/home/robby/sketchbook/libraries/pca301serial/pca301.cpp:422: multiple definition of `loadConf()'
pca301.cpp.o:pca301.cpp:422: first defined here
pca301serial/pca301.cpp.o: In function `fillConf()':
/home/robby/sketchbook/libraries/pca301serial/pca301.cpp:422: multiple definition of `eeprom_crc'
pca301.cpp.o:pca301.cpp:422: first defined here
pca301serial/pca301.cpp.o: In function `fillConf()':
/home/robby/sketchbook/libraries/pca301serial/pca301.cpp:422: multiple definition of `saveConf()'
pca301.cpp.o:pca301.cpp:422: first defined here
pca301serial/pca301.cpp.o: In function `fillConf()':
/home/robby/sketchbook/libraries/pca301serial/pca301.cpp:422: multiple definition of `eraseConf()'
pca301.cpp.o:pca301.cpp:422: first defined here
pca301serial/pca301.cpp.o: In function `fillConf()':
/home/robby/sketchbook/libraries/pca301serial/pca301.cpp:422: multiple definition of `fillConf()'
pca301.cpp.o:pca301.cpp:422: first defined here
collect2: error: ld returned 1 exit status
Keine Ahnung, warum das nicht mehr funktioniert...
Dann mit dem gleichen Sketch unter Windows mit der Arduiono Software und da hat's endlich geklappt --> JeeLink initialized. Anscheinend ist etwas beim ersten Flashen schief gelaufen.
Nun habe ich auch 3 von den nicht FTDI Chips gleichzeitig laufen. Nichts desto trotz werde ich mich an den Verkäufer wenden >:(
ZitatGibt's da eigentlich auch Unterschiede bei der zu flashenden firmware zwischen dem Originalen und den Nano-basierten wie beim CUL?
Die nanoCULs gingen relativ einfach unter Linux zu flashen, da brauchte ich auch die Arduino Software nicht.
Lediglich bei der 868MHz Variante musste in der board.h Datei die Zeile mit den 433MHz auskommentiert werden. Eigentlich alles nach Wiki.
Ist das jetzt anders als bei den fertigen CULs/JeeLinks?
Gruß Robby