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!