Selbstbau CUL - alle FTDI Chips mit gleicher Seriennummer

Begonnen von MarkusDssd, 20 November 2015, 23:13:58

Vorheriges Thema - Nächstes Thema

MarkusDssd

Hallo zusammen,

als anonymer Gast Leser schon länger im Forum unterwegs habe ich mir nach genauem Studium beim China Mann einiges zum Basteln bestellt.
Und damit komm ich auch gleich zum Problem warum lesen jetzt nicht mehr reicht und ich mich angemeldet habe um euch meine Frage zu stellen.

Ich habe 5x Original Arduino Nano 3.0 atmega328 mini version FT232RL bestellt. Flashen war zwar ein Geduldsspiel aber hat auch einwandfrei funktioniert.
Leider haben alle 5 Stück die gleiche Seriennummer A50285BI (wenn man die googelt kommen da einige Betroffene) und damit ist mein Traum von 3 CULs am Pi jetzt erst einmal dahin.
Ich würde gern Homematic, Techem und Intertechno steuern/auslesen. Wenn ich das richtig sehe brauche ich dafür 3 CULs (korrigiert mich gerne nach unten :-) )

Aber nun zu meinen Fragen:
- Kann mir jemand eine Bezugsquelle für Nanos mit echten FTDIs nennen? (preislich bitte im Rahmen bleiben)
- Den Techem CUL könnte ich mir vielleicht ausreden, kann ich dann vielleicht einen CH340 für Intertechno nehmen und den Fake FTDI für Homematic oder kann ich den CH340 nicht definitiv ansteuern?

Ich hoffe jemand kann mir helfen damit mein Einstieg in FHEM nicht allzu schnell endet...

Danke!
Markus


rudolfkoenig

ZitatLeider haben alle 5 Stück die gleiche Seriennummer A50285BI (wenn man die googelt kommen da einige Betroffene) und damit ist mein Traum von 3 CULs am Pi jetzt erst einmal dahin.

Ich verstehe den kausalen Zusammenhang noch nicht.
Koennte man nicht /dev/serial/by-path/... zum einbinden verwenden?

MarkusDssd

Hallo Rudolf,

ich hatte immer gelesen das sich die Zuordnung by-path nach einem Neustart verändern kann und die Adressierung über die eindeutigen Seriennummern die sichere Variante wäre. Lasse mich das aber gerne korrigieren und ändere das gleich mal und starte den Pi mal mehrmals neu. Verstehe dann aber den Hinweis im Wiki nicht.

"Es sollte aber darauf geachtet werden, dass als USB-seriell Wandler auf dem nano ein FTDI FT232RL Chip oder ein anderer Chip mit eindeutiger ID verwendet wird. Nur dann sind mehrere CULs gleichzeitig ohne Probleme in Fhem nutzbar."

bloodybeginner

Hi Markus,

Ich habe das gleiche Problem. Allerdings nur mit zwei Nanos. Immerhin habe ich vom China Mann das Geld zurück bekommen nachdem ich höflich gefragt habe wie es sein kann das zwei original FTDI Chips die gleiche serial haben.
Du könntest noch versuchen die serial neu zu schreiben im EEprom. Bei mir hat es leider nicht funktioniert.
Mittlerweile habe ich die nächste China Bestellung ausgelöst in der Hoffnung eine andere serial zu erwischen.

Einen der gefakten ftdi könntest du gegen einen CH340G austauschen. Die sind auch zwar auch untereinander nicht eindeutig aber eindeutig gegenüber dem fake FTDI.

Als nächste Möglichkeit bleibt noch einen Max Cube oder hm-usb zum cul zu machen.

//bb

Gesendet von meinem SM-G901F mit Tapatalk


gero

Es sollte doch kein Problem sein, die Firmware derart zu erweitern, dass eine eindeutige vorher gesetzte ID von Stick abgefragt werden kann. Damit könnte z.B. über udev ein eindeutiger symbolic Link erzeugt werden.

Nur so eine Idee.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

bloodybeginner

Mhhhh. Kommt denn udev an die Infos in der Firmware dran?

Ich habe bisher nur gesehen das die usb Infos abgefragt werden können.

Gesendet von meinem SM-G901F mit Tapatalk


gero

Du kannst über udev ein Shellscript starten. Dort könnte man über die serielle Schnittstelle Informationen abfragen und einen entsprechenden Link erzeugen.
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

JoeALLb

Du kannst doch wie oben erwähnt den USB Port als eindeutige Referenz nehmen. Dann darfst du nur nicht umstecken!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

rudolfkoenig

ZitatEs sollte doch kein Problem sein, die Firmware derart zu erweitern, dass eine eindeutige vorher gesetzte ID von Stick abgefragt werden kann.
Dann wird wohl ein Patch fuer culfw auch kein Problem sein, ich kann das gerne einchecken.

Im "richtigen" CUL ist das kein Hardware-Problem, sondern "nur" Zeit- und Testaufwand.  Bei einem FTDI Chip ist USB mWn nicht beeinflussbar. Aber eindeutige USB-IDs helfen nur dem Erfahrenen, da man dafuer udev konfigurieren muss.

Theoretisch koennte auch FHEM ein culfw-ID abfragen (und das waere Anfaenger-freundlich), allerdings  ist ein Umsortierern der CULs in FHEM aufwendig, weil die Initialisierungsreihenfolge "falsch" ist.

Mein Vorschlag: die CULs nicht dauernd umstecken, dann muesste das definieren via /dev/serial/by-path/... reichen.

Wichtel

Mein Vorschlag: mit FTprog/Mprog einfach die IDs nach Wunsch neu vergeben. Diese Möglichkeit macht den FTDI doch gerade so praktisch.

bloodybeginner

@Wichtel

Geht net. Die fake ftdi machen da nicht mit

Gesendet von meinem SM-G901F mit Tapatalk


herrmannj

#11
Hi,
ZitatWenn ich das richtig sehe brauche ich dafür 3 CULs (korrigiert mich gerne nach unten :-) )
ZitatDen Techem CUL könnte ich mir vielleicht ausreden
das ist korrekt. Du kannst einen anderweitig beschäftigten CUL irgendwann Nachts für 20-60min auf rfmode WMBUS_T setzen (und danach zurück). Das geht per "at" und "attrib".

Das genügt um die Werte auf täglicher Basis zu loggen. Die beiden Techem module kommen damit klar und Du sparst einen CUL

vg
joerg

gero

Zitat von: rudolfkoenig am 21 November 2015, 10:11:38
Theoretisch koennte auch FHEM ein culfw-ID abfragen (und das waere Anfaenger-freundlich), ...
Das hatte ich gemeint. Ein Patch dafür sollte nicht wirklich ein Problem sein. Allerdings bin ich nicht betroffen, sondern wollte nur eine weitere Idee nennen, wie man mit den FTDIs mit gleicher Seriennummer umgehen könnte. Falls aber wirklich niemand anderes dazu in der Lage ist, kann ich gerne einen Patch machen.
Die Zuordnung aufgrund einer Firmware-ID in fhem wäre natürlich die beste Lösung. Aber das lässt sich wie geschrieben auch extern unter udev regeln. Hätte ich mehrere CULs würde ich auch den Patch für fhem beisteuern.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

bloodybeginner

Hi  Gero,
Leider fehlt mir für einen fhem Patch das wissen über die Interna.
Ich werde mal versuchen über udev etwas zu machen, wobei der fhem Patch eindeutig eleganter ist.

//bb

Gesendet von meinem SM-G901F mit Tapatalk


spel

Hallo,

auch wenn dieser Thread schon sehr alt ist...

Ich habe nun auch das Problem mit 2x der gleichen Seriennr. Gibt es mittlerweile eine Lösung oder ein Howto wie man die Seriennummer ändern kann?

Ich habe zur Zeit:
- Original Jeelink mit LaCrosse
- Selbstbau Jeelink mit PCA301
- Selbstbau CUL

Leider scheint mir der 2. Selbstbau CUL (2x Arduino Nano bei eBay bestellt - die mit dem FTDI-Fehler, wo nachgelötet werden muss) die gleiche Seriennummer zu haben und wird vom Raspberry PI wieder ausgeworfen...

Danke für Hilfe!

MadMax-FHEM

Hallo,

dann nach all der Zeit...

Ob es besagten Patch oder FW-Anpassung gibt weiß ich nicht...

Aber wie schon mehrfach genannt:

/dev/serial/by-path/...

funktioniert bei mir prima.

Solange man nicht umsteckt...
...wie der Name sagt: by-path -> da wo's drin steckt ;-)

Booten ist kein Problem...

Nur beim Flashen halt entsprechend beachten auch dabei den jeweils richtigen zu "erwischen"...
(habe schon aus versehen meinen eigentlichen mySensor Gateway mit der CUL-FW geflasht... ;-)   )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Kleiner Nachtrag:

was meinst du mit "wieder ausgeworfen"??
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

spel

Danke für den Tipp. Nein, das "Ausgeworfen" war mein Fehler. Es werden halt nur keine doppelten Serien-Nr. angezeigt...

MadMax-FHEM

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Wernieman

Zitatwird vom Raspberry PI wieder ausgeworfen...
Dann hast Du ein HW-Problem. Auch bei gleicher Seriennummer muß der Pi beide Geräte akzeptieren. Wenn eines Rausfliegt, dürfte es an anderen Quellen, z.B. Stromvrsorgung liegen.

Alternativ kannst Du über "/dev/serial/by-path gehen ..
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

phil1283

Hallo, hatte das selbe Problem.
2 Stück gekauft- selbe Seriennummer.
Das dumme war auch noch, dass die Teile sich zwar flashen ließen aber unter fhem nicht ansprechbar waren.
Sie wurden ständig neu gestartet. Uptime max. 6 Sekunden und sonst nur "no answer" bei get Befehlen.
Kommunikation nicht möglich.
Hab mich beim Händler beschwert, mal sehen was da zurück kommt.
Zur Problemlösung hab ich einfach zwei original FTDI Chips aufgelötet - Jetzt funktioniert es bestens!

RaspiLED

Hi,
wo hast Du die FTDIs bezogen und wie schwer war das Löten?
Gruß Arnd


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

phil1283

Hallo RaspiLED,

hab die Chips aus einem DFRobot Mega 2010 augelötet und aus einem Mega 2510 board auch aus China.
beim Auslöten hat man dann schon gesehen wo der unterschied liegt. Die Fälschungen sind auf der Rückseite glatt.
Das Original hat eine keine Einbuchtung in der Indonesia drin steht.
das Löten ist relativ einfach mit einer Heißluftlötstation, geht aber auch mit nem normalen Lötkolben.
Man braucht aber einen kleinen Draht, den man unter die eine reihe Beinchen schiebt, damit kann man de Chip auf einer Seite anheben.
Und dann die andere Seite auslöten.
Beim einlöten ist es wichtig, dass man Flussmittel und Entlötlitze zur Hand hat.
Hab so circa 15 mit gebraucht. Wichtig, nochmal nachmessen, dass keine Lötbrücken entstanden sind.
Wobei an zwei stellen zwei nebeneinander liegende Pins verbunden sind. einmal 25 und 26 (gnd und Test Pin) und dann noch der Reset und 5v, die Pin nummern weiß ich gerade nicht.
Den FTDI gibt's unter anderem auch bei Reichelt als Original.

RaspiLED

Hi,
Danke für die ausführliche Info!

Ja, die Brücke zwischen Debug und Ground wird ja häufig ab Werk vergessen ;-) Dann gibt es nach einem Raspi Reboot keine Chance den CUL anzusprechen, bevor man ihn nicht stromlos macht (also raus, warten und wieder rein)

Haben die Fake FTDIs eigentlich alle die gleiche Nummer oder wäre auch ein Ringtausch über diesen Forenstream möglich *lol* ?

Gruß Arnd


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

Beta-User

Hat eigentlich schon mal jemand versucht, die Seriennnummern zu ändern?

Bei den paar China-"FTDI"-Nanos, die mir bisher in die Hände gefallen sind, ging das Ändern der SN problemlos mit diesem Tool unter Linux: http://rtr.ca/ft232r/
Allerdings kann ich nicht sagen, ob fake oder Original, alle hatten aber den Test-PIN nicht auf Ground.

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

gloob

Ich habe erst gestern wieder Nanos mit FTDI mit einer neuen Seriennummer bespielt. Ich habe dafür das weiter oben erwähnte Windows-Tool genutzt. Geht ohne Probleme.
Angeblich sollten es originale FTDIs gewesen sein, allerdings standen 3/5 auf 0000000.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Ranseyer

FTDI Chips mit der Seriennummer 00000000 12345678 oder doppelte sind wohl kaum echt.

Ich habe fast immer bei AliExpress bei einem Dispute das Geld zurückbekommen, auch wenn der Händler behautet er versendet Originale.

Bis auf einen Chip konnte ich die Serien-Nummer mit "ft232r_prog" ändern. (Ich nutze privat+nativ nur Linux)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Wichtel

Dass bei einem Arduino für 5-6 Euro der FTDI kein Original ist, davon gehe ich praktisch aus.
Ich wäre froh dann sicher von einem originalen Atmel ausgehen zu können, auch das ist nicht gegeben.

Schade finde ich am Ende, dass die vielen Chinesen die einst diese Nanos mit Fake-FTDI verkauften, jetzt fast nur noch diese CH340er verkaufen.
Der Fake-FTDI ist inzwischen ebenfalls ein quasi "bewährtes Produkt", das ich zum gewohnten Preis gern auch weiter verwenden würde.

In der angewandten Praxis bietet ein Fake-FTDI dann IMHO noch mehr Nutzwert als ein evtl. originaler CH340. Ich hatte tatsächlich nie ein Problem mit denen.

Beta-User

Habe bislang auch noch keine wirklich schlechten Erfahrungen, aber den Verdacht, dass uU. deswegen meine MySensors-GW's nicht mehr auf "connected" gehen, sondern sich mit "Startup complete" begnügen...

Was als Alternative noch in Frage käme:

Man könnte statt des 328 auch die Leonardo-Variante ATmega32u4 nehmen.
Da kann man ja auch die USB-Kennung selbst festlegen (im Sketch), da habe ich allerdings noch keine eigene Erfahrung (habe neulich mal testweise 2 Boards bestellt, kosten so um die 3,50 Euro, sind aber noch unterwegs).

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

Wichtel

Ich kann meine Befürchtung auch zurückziehen..Ich bin mir sicher vor einigen Monaten, als der Originaltreiber plötzlich die Fakes reprogrammiert hat, kaum noch welche gefunden zu haben.

Jetzt gibt es aber wieder jede Menge Angebote der Art "2 Stück für 9,99, portofrei".

phil1283

Naja solange die Dinger funktionieren kann man ja versuchen die Seriennummer zu ändern, aber bei mir gingen die gar nicht als sie am FHEM - Server hingen. Mich wundert es aber dass ich sie flashen konnte.

Beta-User

Zitat von: phil1283 am 16 Februar 2017, 12:39:24
aber bei mir gingen die gar nicht als sie am FHEM - Server hingen. Mich wundert es aber dass ich sie flashen konnte.
Bist Du sicher, dass das nicht evtl. ein anderes Problem war, insbesondere der user "fhem" Mitglied in "dialout" ist?
Den Fehler eher in die Richtung zu suchen, wäre insbesondere dann naheliegend, wenn der Nano an dem anderen Rechner z.B. im seriellen Monitor der Arduino-IDE etwas ausgegeben hätte, etwa beim Starten, beim Empfang irgendwelcher Nachrichten oder bei Anfragen nach der Konfiguration (=>commandref zur culfw).

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

phil1283

geflasht hab ich die beiden auf meinem mpd-raspi, da dort keine anderen seriellen Schnittstellen laufen.
Am FHEM-Server haben sich beide Boards nach wenigen Sekunden aufgehängt (FHEM konnte gerade noch die Command-List abrufen, danach keine Antwort vom Board mehr). Seit einlöten der original FTDI Chips laufen beide Boards ohne weitere Änderung.

peterchen88

Würde gern welche tauschen 5-10 stück meine haben die Seriennummer A9M9DV3R
Falls jemand andere hat.

gloob

Überschreib doch einfach die Seriennummer. Weiter oben sollte stehen, wie es geht.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

peterchen88

hab ich versucht mit dem Tool FT_prog . aber geht irgendwie nicht. jemand einen Tip.

Ranseyer

Ich habe das immer damit gemacht: https://forum.fhem.de/index.php/topic,44379.msg585064.html#msg585064

Was bedeutet "geht nicht" ? Wenn du das unter Linux machst brauchst Du Zugriffsrechte auf das Device. Du musst also genauer schreiben was du gemacht hast und welches Ergebnis / Meldungen kamen.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

peterchen88

hab es mit den Windows Tool versucht.
da wird die neue Seriennummer nicht gespeichert.
Über Linux das selbe.

Ranseyer

Schreib doch mal ein sudo davor.

Das Device darf außerdem während dem Aufruf nicht in Benutzung sein.
Auf meinem Odroid brauche ich dazu: "sudo apt-get remove modemmanager"


ed: oldserial sollte unnötig sein wenn nur ein FTDI Chip angeschlossen ist (vorher mal ein lsusb machen!)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

peterchen88

sudo steht davor. in Benutzung ist er eigentlich hauch nicht.
wie nutzt du remove modemmanager

Ranseyer

Ich nutze den Modem-Manager gar nicht. Wenn du nichts davon weisst: runter damit falls vorhanden, bei mir hat dieser sich einige TTY-Devices gekrallt. (im speziellen die *ACM*)

PS: Allerdings würde ich mit anderem Fehler rechnen falls die Devices gerade im Zugriff sind.

PPS: Meine Version:
Zitat./ft232r_prog
ft232r_prog: version 1.25, by Mark Lord.
Usage:  ft232r_prog [<arg> <val>]..
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

peterchen88

Hab mir die selbe version geladen. leider immer noch das selbe kein ändern Möglich.
Noch einen TIP?

Ranseyer

Leider keinen ordentlichen Tipp mehr. (Natürlich Geld zurückverlangen wegen Fälschung)

-Ist der Modem-Manager installiert ? ("dpkg -l|grep modem"; immer noch runterwerfen siehe oben)

-anderes Tool verwenden
-auf andere Ideen warten
-mir zusenden mit Rückporto (wenn du sauber gearbeitet hast in korrekter Umgebung nur wenig Erfolgsaussichten)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Wichtel

Ich habe auch wieder bestellt...und "A9M9DV3R"-Exemplare erhalten.

FT-prog akzeptiert eingebene Änderungen anstandslos, sie landen aber im Nirwana. Nach neuem Anstecken/Auslesen sind die Werte wie gehabt.
Einer meiner vor 2 Jahren aus China bezogenen Nanos lässt sich auf diese Weise problemlos anpassen.

peterchen88



peterchen88

Die habe ich auch. Vereinzelt sind welche mit andere seriennummer bei.

Beta-User

Habe auch den Verdacht, dass ich hier 2 Nanos aus genau der Quelle liegen habe, die nach kurzer Zeit Probleme gemacht haben, die hatten aber vermutlich andere Seriennummern und ließen sich unter Linux auch umbenennen.

Leider ist mit der Quellenzuordnung das nicht ganz eindeutig, da ich 2*2 (das andere Paar woanders) bestellt hatte, und 2 einwandfrei ihren Dienst tun, diese zwei aber eben gar nicht (vielleicht sollte ich die PINs wieder ungrounden).

Einer reagiert gar nicht mehr (nicht mal USB-Aktivität), der andere bringt keine Reaktion am seriellen Monitor (sollte als Signalduino eingesetzt werden).

Mal sehen, ob ich die wiederbeleben kann, um den Seller Modul-Technik mache ich erst mal arduinomäßig einen Bogen.

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

Hi Beta-User,
Probier die mal per Arduino ISP mit einem neuen Bootloader auszustatten!
Hier ist eine Anleitung dazu:
http://www.instructables.com/id/How-To-Burn-a-Bootloader-to-Clone-Arduino-Nano-30/?ALLSTEPS
Aber hier findest Du noch mehr:
https://www.google.de/search?q=arduino+nano+bootloader+isp
Gruß Arnd


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

Beta-User

Danke für den Link, ich teste das mal.

Den einen habe ich vorhin mal mit einem anderen Sketch befüllt, da hat er ordnungsgemäß reagiert; ist evtl. doch was anderes. Aber zum CC1101-Signalduino kann ich derzeit keinen der beiden umfunktionieren.

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

Christian.

#50
Ich habe hier einen Arduino Nano mit der Aufschrift "Nano V4.0", Seriennummer A50285BI. Die Seriennummer lässt sich weder mit FT_PROG noch mit ft232r_prog verändern. Ich habe Interesse an einem Tausch gegen ein Modell mit abweichender Seriennummer. Der Tausch hat stattgefunden.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Ronn

Hallo, ich habe einen A9M9DV3R doppelt. Hat jemand Interesse an einen Tausch? Grüße


thgorjup

#53
Schon alt dieses Thema, aber hier ein Script, welches bei gleichen Seriennummern Abhilfe schafft.
Das Script sollte per cronjob minütilich ausgeführt werden. Es prüft, ob CUL's eingesteckt sind und legt automatisch SymLinks unter /dev/serial/by-id/ an.
Wird ein CUL ausgesteckt, wird auch der Symlink wieder gelöscht.

ch340_symlink.sh:

#!/bin/bash

BY_ID=/dev/serial/by-id
BY_PATH=/dev/serial/by-path

if [ -d "${BY_PATH}" ]; then

   cd ${BY_ID}
   find -L . -name . -o -type d -prune -o -type l -exec unlink {} \;

   cd ${BY_PATH}
   for i in `ls`
   do
        port=$(echo $i|sed 's/.*usb-0\:1\.//g'|sed 's/\:.*//g')
        if [ ! -L "${BY_ID}/usb-ch340_USB2.0-FHEM_cul-port${port}" ]; then
                ln -s ${BY_PATH}/$i ${BY_ID}/usb-ch340_USB2.0-FHEM_cul-port${port}
        fi
   done

fi


Cronjob:

# CH340 SymLink
* * * * *  ~/bin/ch340_symlink.sh
FHEM auf Ubuntu 18.04LTS, 2x nanoCUL, JeeLink, nanoPIR, MQTT, ESP-Easy, HUE.
Sensoren+Aktoren: HM, IT, Lacrosse, Multitrade-PIR, VU+, Somfy