98_autocreate ergänzen (SIGNALduino, MYSENSORS, ArduCounter...)

[Beta-User]

Hallo Rudi,
hallo zusammen,

nachdem wir neulich diese nette Diskussion über initialUsbCheck hatten, wollte ich jetzt usb scan um ein paar m.E. einigermaßen verbreitete Geräte erweitern, komme damit aber nicht so recht voran. An sich müßte es eine Kleinigkeit sein, für einen Schubs in die richtige Richtung wäre ich daher dankbar, wenn überhaupt Interesse an dem Thema besteht...

Vorab mal der aktuelle Codestand (98_autocreate.pm, einzufügen z.B. nach ZWDongle ab Zeile 502):

Code Auswählen Erweitern

    { NAME      => "SIGNALDuino",
      matchList => ["cu.usbserial(.*)", "cu.usbmodem(.*)",
                    "ttyUSB(.*)", "ttyACM(.*)", "ttyAMA(.*)"],
      DeviceName=> "DEVICE\@57600",
      flush     => "\n",
      request   => "V\n",                # request firmware version
      #response  => "^V .* SIGNALduino.*",# response must begin with V and contain string SIGNALduino
      response  => "^;S.*",# response must begin with V and contain string SIGNALduino
     
      define    => "SIGNALDUINO_PARAM SIGNALduino DEVICE\@57600", },

    { NAME      => "MYSENSORS",
      matchList => ["cu.usbserial(.*)", "cu.usbmodem(.*)",
                    "ttyUSB(.*)", "ttyACM(.*)", "ttyAMA(.*)"],
      DeviceName=> "DEVICE\@115200",
      flush     => "\n",
      request   => "0;255;3;0;18\n",   # send heartbeat request
      response  => "^0;255;3;0;22.*",  # heartbeat response
      define    => "MYSENSORS_PARAM MYSENSORS DEVICE\@115200", },

    { NAME      => "ArduCounter",
      matchList => ["cu.usbserial(.*)", "cu.usbmodem(.*)",
                    "ttyUSB(.*)", "ttyACM(.*)", "ttyAMA(.*)"],
      DeviceName=> "DEVICE\@38400",
      flush     => "\n",
      request   => "h\n",   # send firmware version request
      response  => "^ArduCounter V.*",  # response is two lines
      define    => "ArduCounter_PARAM ArduCounter DEVICE\@38400", },

Leider funktioniert keines der Geräte, die diversen Arduinos blinken zwar vor sich hin, die Anfragen scheinen also zu funtionieren, aber die Auswertung paßt nicht, das sieht auszugsweise so aus (hier war tatsächlich ein ArduCounter dran):

Code Auswählen Erweitern

### ttyUSB1: checking if it is a TRX
got wrong answer for a TRX
### ttyUSB1: checking if it is a ZWDongle
got wrong answer for a ZWDongle
### ttyUSB1: checking if it is a SIGNALDuino
got wrong answer for a SIGNALDuino
### ttyUSB1: checking if it is a MYSENSORS
got wrong answer for a MYSENSORS
### ttyUSB1: checking if it is a ArduCounter
got wrong answer for a ArduCounter
### ttyUSB1: checking if it is a FRM
got wrong answer for a FRM
ArduCounter und SIGNALduino haben mehrzeilige Rückgaben, der MYSENSORS-heartbeat-Request liefert eine einzeilige Antwort.
Im Detail (durchgeführt mit dem seriellen Monitor der Arduino-IDE):
Arducounter: "h+Enter" ergibt (2 Zeilen):

Code Auswählen Erweitern

ArduCounter V2.36 on UNO compiled May 14 2018 19:11:09 Hello, pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21 available T330620,0 B271958,0
I30 60 2 2
MySensors-GW: "0;255;3;0;18+Enter" ergibt (der letzte Wert ist m.E. die uptime):

Code Auswählen Erweitern

0;255;3;0;22;4596
SignalDuino: "V+Enter" ergibt (2 Zeilen):

Code Auswählen Erweitern

V 3.3.1-RC-nightly SIGNALduino cc1101 (chip CC1101) - compiled at Jan 25 2019 23:57:09

;S%X;


An sich würde ich dann gerne noch das/die Pi-PCB's ergänzen, aber das könnte auch zu Problemen führen, wenn jemand eine (virtualisierte) CCUx damit betreiben wollte. Und da die "einfachen" Dinge schon nicht wollen, will ich das Servergehäuse auch nicht unnötig aufmachen (das Teil hängt an einem USB-seriell-Wandler und ist vielleicht eh' nicht typisch), vielleicht hat ja jemand auch so die notwendigen Infos parat?

Der CC2531-Stick, der neulich wohl versehentlich als CUL eingebunden wurde, liefert übrigens folgende Infos, ls -l /dev/serial/by-id:

Code Auswählen Erweitern

lrwxrwxrwx 1 root root 13 Feb 23 07:17 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014BDEC02-if00 -> ../../ttyACM3

dmesg:

Code Auswählen Erweitern


[31759.556341] usb 2-1.3: New USB device found, idVendor=0451, idProduct=16a8
[31759.556347] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[31759.556350] usb 2-1.3: Product: TI CC2531 USB CDC
[31759.556354] usb 2-1.3: Manufacturer: Texas Instruments
[31759.556357] usb 2-1.3: SerialNumber: __0X00124B0014BDEC02

Und nun?

[rudolfkoenig]

Vorab mal der aktuelle Codestand (98_autocreate.pm, einzufügen z.B. nach ZWDongle ab Zeile 502):

Habs hinzugefuegt, bis auf den irrefuehrenden Kommentar fuer SIGNALDuino response.
Klarstellung: ich habe keine dieser Geraete, konnte sie also alle nicht testen.

Und nun?

Nun habe ich mehr debugging in autocreate.pm eingebaut fuer "attr global verbose 5", damit man sieht, was die Geraete zurueckliefern.
Weiterhin habe ich versucht die Ausgaben etwas sinnvoller zu gestalten.

[Beta-User]

Wow, das ging ja mal wieder schnell!

Leider bisher immer noch kein Glück:

ttyUSB0 ist der Signalduino, (Nano mit Prolific-Wandler)
ttyUSB1 das MySensors-Gateway (FTDI-Nano) und
ttyUSB2 der ArduCounter (WCH340-Nano)

Das verbose 5 - log dazu:

Code Auswählen Erweitern

2019.02.23 14:20:55 3: Probing TCM_ESP3 device /dev/ttyUSB0
2019.02.23 14:20:56 5: SW: 5500010005700838
2019.02.23 14:20:56 5:   answer:
2019.02.23 14:20:56 4:   wrong answer
2019.02.23 14:20:56 3: Probing TCM_ESP2 device /dev/ttyUSB0
2019.02.23 14:20:56 5: SW: a55aab5800000000000000000003
2019.02.23 14:20:56 5:   answer:
2019.02.23 14:20:56 4:   wrong answer
2019.02.23 14:20:56 3: Probing FHZ device /dev/ttyUSB0
2019.02.23 14:20:56 5: SW: 8105044fc90185
2019.02.23 14:20:56 5:   answer:
2019.02.23 14:20:56 4:   wrong answer
2019.02.23 14:20:56 3: Probing TRX device /dev/ttyUSB0
2019.02.23 14:20:56 5: SW: 0d00000000000000000000000000
2019.02.23 14:20:57 5: SW: 0d00000102000000000000000000
2019.02.23 14:20:57 5:   answer: (237)(6)>(129)(237)(6)>(129)(237)(6)>(129)(237)(6)>(129)(237...
2019.02.23 14:20:57 4:   wrong answer
2019.02.23 14:20:57 3: Probing ZWDongle device /dev/ttyUSB0
2019.02.23 14:20:57 5: SW: 01030020dc06
2019.02.23 14:20:58 5:   answer:
2019.02.23 14:20:58 4:   wrong answer
2019.02.23 14:20:58 3: Probing SIGNALDuino device /dev/ttyUSB0
2019.02.23 14:20:58 5: SW: 0a
2019.02.23 14:20:58 5: SW: 560a
2019.02.23 14:20:58 5:   answer:
2019.02.23 14:20:58 4:   wrong answer
2019.02.23 14:20:58 3: Probing MYSENSORS device /dev/ttyUSB0
2019.02.23 14:20:58 5: SW: 0a
2019.02.23 14:20:58 5: SW: 303b3235353b333b303b31380a
2019.02.23 14:20:58 5:   answer:
2019.02.23 14:20:58 4:   wrong answer
2019.02.23 14:20:58 3: Probing ArduCounter device /dev/ttyUSB0
2019.02.23 14:20:58 5: SW: 0a
2019.02.23 14:20:58 5: SW: 680a
2019.02.23 14:20:58 5:   answer:
2019.02.23 14:20:59 4:   wrong answer
2019.02.23 14:20:59 3: Probing FRM device /dev/ttyUSB0
2019.02.23 14:20:59 5: SW: f9
2019.02.23 14:21:04 5: SW: f079f7
2019.02.23 14:21:04 5:   answer:
2019.02.23 14:21:04 4:   wrong answer
2019.02.23 14:21:04 3: Probing TCM_ESP3 device /dev/ttyUSB1
2019.02.23 14:21:04 5: SW: 5500010005700838
2019.02.23 14:21:04 5:   answer:
2019.02.23 14:21:04 4:   wrong answer
2019.02.23 14:21:04 3: Probing TCM_ESP2 device /dev/ttyUSB1
2019.02.23 14:21:04 5: SW: a55aab5800000000000000000003
2019.02.23 14:21:04 5:   answer:
2019.02.23 14:21:04 4:   wrong answer
2019.02.23 14:21:04 3: Probing FHZ device /dev/ttyUSB1
2019.02.23 14:21:04 5: SW: 8105044fc90185
2019.02.23 14:21:05 5:   answer:
2019.02.23 14:21:05 4:   wrong answer
2019.02.23 14:21:05 3: Probing TRX device /dev/ttyUSB1
2019.02.23 14:21:05 5: SW: 0d00000000000000000000000000
2019.02.23 14:21:05 5: SW: 0d00000102000000000000000000
2019.02.23 14:21:05 5:   answer: (26)(181)(163)(26)(168)(145)!(168)(17))%D%(252)(26)(181)(163...
2019.02.23 14:21:05 4:   wrong answer
2019.02.23 14:21:05 3: Probing ZWDongle device /dev/ttyUSB1
2019.02.23 14:21:05 5: SW: 01030020dc06
2019.02.23 14:21:06 5:   answer:
2019.02.23 14:21:06 4:   wrong answer
2019.02.23 14:21:06 3: Probing SIGNALDuino device /dev/ttyUSB1
2019.02.23 14:21:06 5: SW: 0a
2019.02.23 14:21:06 5: SW: 560a
2019.02.23 14:21:06 5:   answer:
2019.02.23 14:21:06 4:   wrong answer
2019.02.23 14:21:06 3: Probing MYSENSORS device /dev/ttyUSB1
2019.02.23 14:21:06 5: SW: 0a
2019.02.23 14:21:06 5: SW: 303b3235353b333b303b31380a
2019.02.23 14:21:06 5:   answer:
2019.02.23 14:21:06 4:   wrong answer
2019.02.23 14:21:06 3: Probing ArduCounter device /dev/ttyUSB1
2019.02.23 14:21:06 5: SW: 0a
2019.02.23 14:21:06 5: SW: 680a
2019.02.23 14:21:06 5:   answer:
2019.02.23 14:21:06 4:   wrong answer
2019.02.23 14:21:06 3: Probing FRM device /dev/ttyUSB1
2019.02.23 14:21:06 5: SW: f9
2019.02.23 14:21:13 5: SW: f079f7
2019.02.23 14:21:13 5:   answer:
2019.02.23 14:21:13 4:   wrong answer
2019.02.23 14:21:13 3: Probing TCM_ESP3 device /dev/ttyUSB2
2019.02.23 14:21:13 5: SW: 5500010005700838
2019.02.23 14:21:13 5:   answer:
2019.02.23 14:21:13 4:   wrong answer
2019.02.23 14:21:13 3: Probing TCM_ESP2 device /dev/ttyUSB2
2019.02.23 14:21:13 5: SW: a55aab5800000000000000000003
2019.02.23 14:21:13 5:   answer:
2019.02.23 14:21:13 4:   wrong answer
2019.02.23 14:21:13 3: Probing FHZ device /dev/ttyUSB2
2019.02.23 14:21:13 5: SW: 8105044fc90185
2019.02.23 14:21:14 5:   answer:
2019.02.23 14:21:14 4:   wrong answer
2019.02.23 14:21:14 3: Probing TRX device /dev/ttyUSB2
2019.02.23 14:21:14 5: SW: 0d00000000000000000000000000
2019.02.23 14:21:14 5: SW: 0d00000102000000000000000000
2019.02.23 14:21:14 5:   answer:
2019.02.23 14:21:14 4:   wrong answer
2019.02.23 14:21:14 3: Probing ZWDongle device /dev/ttyUSB2
2019.02.23 14:21:14 5: SW: 01030020dc06
2019.02.23 14:21:14 5:   answer:
2019.02.23 14:21:14 4:   wrong answer
2019.02.23 14:21:14 3: Probing SIGNALDuino device /dev/ttyUSB2
2019.02.23 14:21:14 5: SW: 0a
2019.02.23 14:21:15 5: SW: 560a
2019.02.23 14:21:15 5:   answer:
2019.02.23 14:21:15 4:   wrong answer
2019.02.23 14:21:15 3: Probing MYSENSORS device /dev/ttyUSB2
2019.02.23 14:21:15 5: SW: 0a
2019.02.23 14:21:15 5: SW: 303b3235353b333b303b31380a
2019.02.23 14:21:15 5:   answer:
2019.02.23 14:21:15 4:   wrong answer
2019.02.23 14:21:15 3: Probing ArduCounter device /dev/ttyUSB2
2019.02.23 14:21:15 5: SW: 0a
2019.02.23 14:21:15 5: SW: 680a
2019.02.23 14:21:15 5:   answer:
2019.02.23 14:21:15 4:   wrong answer
2019.02.23 14:21:15 3: Probing FRM device /dev/ttyUSB2
2019.02.23 14:21:15 5: SW: f9
2019.02.23 14:21:22 5: SW: f079f7
2019.02.23 14:21:22 5:   answer:
2019.02.23 14:21:22 4:   wrong answer
2019.02.23 14:21:22 1: usb scan end
Man sieht, es kommt was zurück, ich habe eben auch alle drei nochmal getestet (mußte sie zur gleichzeitigen Verwendung an einen Hub anschließen, der Signalduino hat zwischenzeitlich noch ein update erhalten, aber auch der einzelne Testlauf war erfolglos...).

Die Antwort kommt in allen drei Fällen ohne Verzögerung.

Und nun?

Nochmal zur Klarstellung: in die erste Fassung hatte nur reingewurstelt, was mir sinnvoll erschien. Das muß keineswegs richtig gewesen sein, allerdings kann ich auch keinen struktuellen Unterschied zum CUL erkennen. Der liefert:

Code Auswählen Erweitern

2019.02.23 14:43:34 3: Probing CUL device /dev/ttyACM3
2019.02.23 14:43:34 5: SW: 0a
2019.02.23 14:43:34 5: SW: 560a
2019.02.23 14:43:34 5:   answer: V 1.61 CUL868(13)(10)
2019.02.23 14:43:34 4:   matching answer, create it with: define CUL_3 CUL /dev/ttyACM3@9600 1334

Btw: Wäre es nicht eine Idee, zukünftig entweder "by-id" zu definieren (oder, (nur) wenn das nicht eindeutig ist, by-path)? Die Krux ist bei der Sache, dass die "Wissenden" autocreate eigentlich an der Stelle nicht brauchen, und die "Unwissenden" völlig durcheinander sind, wenn sich die Nummerierung bei einem Umstöpseln/Neustart/Nacheinander anstöpseln scheinbar willkürlich ändert.

[Ralf9]

V 3.3.1-RC-nightly SIGNALduino cc1101 (chip CC1101) - compiled at Jan 25 2019 23:57:09

;S%X;

Die nightly ist ein schlechtes Beispiel, dies ist eine debug version
https://github.com/RFD-FHEM/SIGNALDuino/releases/tag/nightly

Hast Du schon eine normale Version versucht?
Normalweise ist die Versionsausgabe einzeilig.

Gruß Ralf

[Beta-User]

Die nightly ist ein schlechtes Beispiel, dies ist eine debug version
https://github.com/RFD-FHEM/SIGNALDuino/releases/tag/nightly

Hast Du schon eine normale Version versucht?
Normalweise ist die Versionsausgabe einzeilig.

Gruß Ralf

Hatte ich zugegebenermaßen nicht, der Unterschied in dem Punkt war mir bis dato nicht bewußt.

Jetzt wollte ich "eben mal" das passende flashen, aber das ist gar nicht so einfach .
version SIGNALduino auf meinem Hauptsystem, mit dem ich flashen wollte, liefert:
00_SIGNALduino.pm    18693 2019-02-22 23:26:20Z Sidey
90_SIGNALduino_un.pm 18676 2019-02-20 21:46:10Z Sidey.
Erst mal den updateVersionChanel testing auf stable umgeschaltet => keine Auswahl mehr (auch nach , also irgendwas auf der Platte gesucht. Da sind aber auch nur Testversionen... (von anno dunnemals). Also im svn was passendes gesucht => Fehlanzeige
Ne' Testversion aus 2017 draufgehauen. Die ist 0 gesprächig...

Also wieder zurück zu testing, die RC10 drauf. Ausgabe ist anders, aber zweizeilig:

Code Auswählen Erweitern

V 3.3.1-RC10 SIGNALduino cc1101  - compiled at Dec 29 2018 01:43:10
Unsupported short command

Hast du mir mal einen Link...?

@Rudi:
Die anderen beiden sind (fast) "reguläre" Geräte, der ArduCounter ist die firmware aus dem svn, das MySensors-GW eines mit Version 2.3.0-alpha. Bei MySensors bin ich aber sicher, dass da hinsichtlich der sieriellen Verhaltensweise 0 Änderungen zwischen V2.0 und V2.3.1 liegen, der heartbeat-request ist für den regulären Betrieb gemacht.

[rudolfkoenig]

Soweit ich sehe:
- ttyUSB0 (signalduino) antwortet nur auf die TRX Aufforderung mit was komisches, evtl. ist der auch beleidigt, jedenfalls kommt auf die "V\n" (560a) innerhalb von 0.5s (default timeout) nichts zurueck.
- ttyUSB1 (MYSENSORS) und ttyUSB2 (ArduCounter) genauso
Evtl. hilft es deine Eintraege nach oben zu packen, damit die Geraete von TRX nicht verwirrt werden.

Wäre es nicht eine Idee, zukünftig entweder "by-id" zu definieren (oder, (nur) wenn das nicht eindeutig ist, by-path)?

by-id ist mindestens beim CUL sinnlos.
by-path habe ich nicht eingebaut, weil frueher nicht alle Linux Distros "by-path" dringehabt haben. Keine Ahnung, ob es inzwischen anders ist.
Wenn jemand Energie hat, es zu testen, koennen wir es gerne aendern.

[Ralf9]

Erst mal den updateVersionChanel testing auf stable umgeschaltet => keine Auswahl mehr

Bei stable gibt es nur die V 3.3.0, dafür gibt es aber keine firmware für den cc1101.
Da es für den cc1101 z.Zt. keine stable firmware gibt, mußt Du eine von testing verwenden.

V 3.3.1-RC10 SIGNALduino cc1101  - compiled at Dec 29 2018 01:43:10
Unsupported short command

Das Unsupported bekommst Du, da Du mit der IDE wahrscheinlich "V\r\n" sendest,
Mit "V\n" oder "V\r" dürfte kein Unsupported kommen.

[Beta-User]

Hm, also, vorab mal Danke für die Schubser:

jetzt habe ich das mal nach oben gepackt (ab L465), die Regex für den Signalduino (nach dem ersten erfolglosen Durchlauf) wieder auf 'response  => "^V .* SIGNALduino .*",' gestellt. Leider immer noch kein match, und im log auch weiterhin "nix gscheits" (da sollte doch eine Response stehen, wenn sie denn kommt, oder)....

In der IDE habe ich mit dem RC10-Signalduino getestet; wenn man in der Arduino-IDE entweder Newline oder CR unten als Zeilenende auswählt (stand zunächst auf "und"), kommt jeweils nur eine einzeilige Ausgabe raus ('V 3.3.1-RC10 SIGNALduino cc1101  - compiled at Dec 29 2018 01:43:10 '), das müßte also eigentlich passen, und länger wie einige Millisekunden dauert das auch nicht (dto. für die anderen beiden)

Aber irgendwie habe ich den Eindruck, dass das jedenfalls teilweise mit der Frage Neue Zeile und CR zusammenhängt und damit wie das dann ganz am Ende zusammengebaut wird und habe daher mal zum einen in der IDE und zum anderen im Modul noch ein paar Varianten ausgetestet, leider immer noch ohne Erfolg.
Jetzt aber der Reihe nach:
- Der Signalduino mag - wie von Ralf9 schon ausgeführt - nur ein Newline _oder_ ein CR, sonst kommt das "unsupported command", ohne Zeilenende passiert nichts.
- Der Arducounter ist weniger wählerisch: der braucht nicht mal eine neue Zeile nach "h"
- Das MySensors-GW ist empfindlich: das mag _fast nur_ NL+CR; testweise hatte ich mal den String in alle möglichen Varianten geändert. Was geht, ist 0;255;3;0;18\r und dann nur NL als Sende-Option (andersrum geht's nicht, als mit \n am Ende und CR als Sende-Option).

Die seltsamen Rückmeldungen würde ich eher als Reaktion auf "seltsame Zeichen" wegen der falschen Baudrate interpretieren, aber ihr merkt ja, ich tappe da ziemlich im Dunkeln. Signalduino und Arducounter reagieren aber auf recht viele Einzelbuchstaben, das MySensors-GW dagegen ist stumm wie ein Fisch, wenn man es mit Rubbisch füttert. Ob es abschmiert, kann ich nicht beurteilen, vom Geblinke her verhalten sich alle drei (nacheinander) - soweit oberflächlich wahrnehmbar - gleich.

Jetzt bin ich wieder mit meinem Latein am Ende...

Was by-id angeht:
Mit-testen würde ich für den (Debian-) Linux-Teil, und m.E. lohnt sich das auch mit dem busware-CUL mit by-path. Sind zwar Sonderfälle, aber neulich hatte einer die 433- und 868-er Variante vertauscht. by-id kein Problem, aber so hat nur ein wenig 433-er Geschalte funktioniert, was natürlich dann für komplettes Unverständnis gesorgt hat, als ich das Thema angesprochen habe.

Schon bei der ACM-Variante können sich Dinge ergeben, die ggf. unverständlich sind (habe hier einen Leonard als MySensors-GW; auch die Maples gehören uU. hierher und käme sich mit dem CUL ins Gehege).

by-id ist eigentlich von dem halbwegs gängigen Zeug nur sowas potentiell problematisch, und auch nur dann, wenn man mehrere gleiche hat:
067b:2303 Prolific Technology, Inc. PL2303 Serial Port
1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
2341:8036 Arduino SA Leonardo (CDC ACM, HID)03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project

Also billigst-Nanos (WCH-Chip), 2 CUL (selbe Frequenz), mehrere unnummerierte CP2102 (änderbar!) oder 2 von den Prolific, mehrere ATMega32U (firmware/BL-abhängig).
Dazu kommen dann noch fake-FTDI's, wenn jemand soviel Glück hat, auch noch dieselbe Seriennummer 2x zu ziehen.
Sollte eigentlich kein Hexenwerk sein.

[Beta-User]

Kurzer Zwischenstand zum Thema:

M.E. ist das eigentliche Problem - jedenfalls zum Teil - der Umstand, dass die mit USB-Seriell-Wandler angeschlossenen Geräte mit der richtigen Baudrate angesprochen werden müssen. Die Arduino-IDE veranlaßt daher bei jeder Umstellung der Baudrate bei diesen Geräten einen Reboot, ich vermute, das war der Hintergrund des timeouts bei Firmata?
Wenn ja, braucht das ganze mit noch mehr Varianten zukünftig nochmal deutlich länger, wenn wir nicht was an der Logik an sich ändern...

Aber erst mal die Info, dass ich zwei neue Geräte erkennen kann , nämlich solche, die den Reboot bei der Umstellung nicht brauchen:
- Einen MapleCUN, angeschlossen über USB (die Rückmeldung ist 2-Zeilig):

Code Auswählen Erweitern

Probing CUL-a-firmware device ttyACM3
  matching answer, create it with: define CUL_3 CUL /dev/ttyACM3@38400 1334 - Ein MySensors-Gateway auf Basis eines Arduino Pro Micro (ATMega32U4-basiert):

Code Auswählen Erweitern

Probing MYSENSORS device ttyACM6
matching answer, create it with: define MYSENSORS_6 MYSENSORS /dev/ttyACM6@115200 
Das ttyUSB0-MySensors-GW wird dagegen nicht erkannt...

Den code, den ich dazu verwendet habe, hänge ich mal an.

Wenn das mit dem Rebooten stimmt, würde ich folgendes Prinzip vorschlagen:
- erst an alle verfügbaren ttyUSBx-Schnittstellen den Reboot/reset-Befehl absetzen (der beinhaltet eine bestimmte Baudrate, oder?), dann einmalig den timeout abwarten (5 Sek. scheint mir lang zu sein)
- Dann mit dieser Baudrate alle passenden Geräte testen (also z.B. @57600: Signalduino und Firmata), gleich alle Schnittstellen nacheinander (es wird ja kein Reboot mehr benötigt und der timeout ist durch)
- Dann die nächste Baudrate

Oder bin ich da gedanklich auf dem Holzweg? Eine Ladung Nanos usw. habe ich da liegen, wenn ich noch andere Firmwares testen soll.

[rudolfkoenig]

Wenn das mit dem Rebooten stimmt, würde ich folgendes Prinzip vorschlagen:

Autocreate soll dem Anfaenger, der keine Ahnung hat, helfen, deswegen wird es unkonditional beim Programmstart ausgefuehrt.
Wenn dieser Vorgang mehrere Minuten dauert, dann ist das aber kontraproduktiv, aus diesem Grund wollte ich FIRMATA auch entfernen.
Evtl. hilft eine "usb longScan / longCreate" Version, die man explizit absetzen kann.
Aber wer soweit in der Doku vorgedrungen ist, der kann vmtl. die richtige Definition selbst eingeben.Oder wir packen das irgendwo prominent auf der FHEMWEB Seite, was aber auch Widerstand erzeugen wird.
Bin noch unschluessig.

[Beta-User]

Hmm,

wie implizit angedeutet: eine deutliche Verlängerung der Zeiten ist auch nach meiner Ansicht nicht gut, daher ja der Vorschlag,
a) alle ttyUSBx-Ports jeweils gleichzeitig mit der neuen Baudrate zu öffnen (nur eine Wartezeit pro baudrate für alle Geräte, das ganze begrenzt auf die Baudraten, die überhaupt bei potentiellen Geräten definiert sind),
b) nur zu warten, wenn es der richtige Adress-Typ ist (ttyUSBx), sonst direkt weiter (ich vermute hinter der heutigen langen Wartezeit, dass alle potentiellen Adressen den Firmata-Timeout nehmen? Macht das Sinn? Vermutlich dann, wenn ein ACM-Gerät (kleiner ATMega) als USB-Seriell Wandler in Spiel kommt, was bei den größeren Boards ggf, der Fall ist? Da wäre dann die Frage, ob der Reset da notendig ist, was ich mangels Hardware aber nicht testen kann), und
c) dann alle Geräte mit der entsprechenden Baudrate (dann selbstredend ohne neurlichen Reboot) durchtesten.

Vielleicht kann ich das mal für die "normalen" Nanos/Unos testen, bräuchte dazu aber etwas Info, wie ein "globaler reset" aussehen müßte. Die Arduino-IDE "weiß" das ja auch irgendwoher. Leider ist das, was als "reset" im code unter "init" zu finden ist (TRX und Firmata), nicht besonders aufschlußreich, jedenfalls für mich.

Aber m.E. macht initalUsbCheck ohne die Erkennung halbwegs gängiger Geräte (einschl. HM-Mod-RPI-PCB & Co, über meine Auswahl kann man trefflich streiten, aber auch der CUL ist eigentlich überholt...) dann eigentlich gar keinen großen Sinn mehr. Jedenfalls spontan würde ich dann auch eher dafür pladieren, einen short- und longScan (bzw. create) irgendwo prominent nach dem ersten Start (oder danach) anzubieten, den der geneigte User dann ausführen kann oder es eben lassen.

usb scan (etc.) ist allerdings andererseits auch sehr versteckt. Wie wäre es, diese ggf. noch als "set" beim autocreate-Gerät anzubieten?

(Wenn wir grade bei Vorschlägen sind: evtl. würde es eh' Sinn machen, da etwas mehr "Benutzerführung" reinzubringen nach dem ersten Start, um intuitiver die erste Einrichtung vorzunehmen? Ist aber eine andere Diskussion...)