[JeeLink] fällt zurück in STATE "Opened"

[nesges]

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:

Code Auswählen Erweitern

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

[Morrino]

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

[HCS]

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.

[Jack-Luck]

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ß

[Intruder1956]

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ß

[schka17]

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

[Wzut]

@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

[HCS]

Der state sollte initialized sein.

Interessant ist, dass es ein habes Jahr läuft, und dann ohne jegliche Veränderung nicht mehr.

@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?

[Wzut]

Hat er nun ein Update gemacht oder nicht?

Die Update Sucht ist doch so verbreitet das es für die meisten keine Änderung ist ....

[schka17]

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

[HCS]

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

[schka17]

Mit der Updatesucht?


Sent from my iPad using Tapatalk

[HCS]

Mit der Updatesucht?

Nein, damit, dass er vermutlich das Probelm ausgelöst hat.

[schka17]

Sorry, klar, war nur ein Scherz


Sent from my iPad using Tapatalk

[Jack-Luck]

sollte ich versuchen ein backup zurück zu spielen?

[Wzut]

IMHO ist der Fehler nicht tragisch, der Jee macht was er soll nur das halt eben ein paar Buchstaben der Anzeige nicht ganz stimmen

[Jack-Luck]

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.

[justme1968]

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

[Intruder1956]

state und State beide inizialisiert, nix openend 

[Wzut]

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.

[HCS]

Dann ist STATE jetzt ja state of the art 

[justme1968]

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

[Wzut]

Dann ist STATE jetzt ja state of the art

@HCS, der war gut  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 ....    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"

[HCS]

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

[justme1968]

hab diese version eingecheckt.

gruss
  andre

[schka17]

Hallo Andre,

auch bei mir funktionierts , nur die Umstellung von Status "Initialized" auf "initialized" hat mich ein bischen herausgefordert
Gruß

Karl

[en-trust]

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 ?

[ing.robby]

Hallo,

ich habe versucht einen JeeLink in Betrieb zu nehmen, aber bei mir steht der Status auch nur auf "opened".

Code Auswählen Erweitern

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

[Wzut]

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:

Code Auswählen Erweitern

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

[ing.robby]

Ja USB2 ist richtig. Habe noch 2 CULs.

Code Auswählen Erweitern

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".

Code Auswählen Erweitern

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

[ing.robby]

Hat jemand eine Idee, was bei mir im Argen liegt? 

[Wzut]

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

[ing.robby]

Code Auswählen Erweitern

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?

[Wernieman]

1. Deine Definition sieht nicht sauber aus, gib uns bitte mal:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

grep fhem /etc/group

[ing.robby]

Also mit

Code Auswählen Erweitern

/dev/serial/by-path/usb-1a86_USB2.0-Serial-if00-port0
funktioniert es nicht.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

/dev/ttyUSB2
hingegen schon. Allerdings gibt es ein anderes Problem:

Code Auswählen Erweitern

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

[ing.robby]

Hallo Werniemann,

Code Auswählen Erweitern

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


Code Auswählen Erweitern

usb-1a86_USB2.0-Serial-if00-port0


Code Auswählen Erweitern

tty:x:5:robby,fhem


[Wernieman]

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

ls -lha /dev/serial/by-id/

Ist Dir eigentlich klar, was meine Befehle so machen?

[ing.robby]

Ja, ich denke schon. Die Id bzw. den Pfad der USB Geräte anzeigen..

Code Auswählen Erweitern

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

Code Auswählen Erweitern

/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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern



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]

[Wernieman]

usb-1a86_USB2.0-Serial

Und Du bist Dir bei dem Namen sicher, das es ein JeeLink ist?

[ing.robby]

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...

[Wernieman]

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.

[Beta-User]

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:

DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@-b57600

Sollte m.E. so lauten:

Code Auswählen Erweitern


DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@57600

Hast du noch weitere Clone mit dem USB-Chip im Einsatz, oder warum machst du das "by-path"?

Gruß, Beta-User

[ing.robby]

Hallo Beta User,

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

/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.

Code Auswählen Erweitern

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...

[Beta-User]

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).

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.

Danke, wieder was gelernt, habe ich bisher nicht benötigt.

laufen 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 .

[ing.robby]

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).

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:

Code Auswählen Erweitern

lrwxrwxrwx 1 root root 13 Dez 20 19:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB2


Gruß Robby

[Beta-User]

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.

[ing.robby]

Seltsam 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:

Code Auswählen Erweitern

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/:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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 

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.

Na das hoffe ich nicht für den Verkäufer!

[Beta-User]

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...

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?

[ing.robby]

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:

Code Auswählen Erweitern

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 

Gibt'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