Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Matti1104]

@marsmännchen
Danke für dein Feedback. ... ich bin auch auf der Suche nach einem passenden Windows Treiber. Leider scheint dieser RWE Stick aber wirklich ein absoluter Exot zu sein. Hast du ihn auch unter Windows installieren können? Falls ja, welchen Treiber hast du genommen?

[ratte-rizzo]

Moin

Ich musste Heute Morgen mein System neu starten und da habe ich verwundert das im Log gelesen:

wireless-mbus.0	2022-05-17 07:38:13.638	debug	connected set to true
wireless-mbus.0	2022-05-17 07:38:13.631	error	CUL: Failed to init device: Timeout waiting for response
wireless-mbus.0	2022-05-17 07:38:10.630	error	CUL: Error getting CUL version: Timeout waiting for response
wireless-mbus.0	2022-05-17 07:38:07.680	debug	connected set to false
wireless-mbus.0	2022-05-17 07:38:07.625	debug	Created device of type: CUL
wireless-mbus.0	2022-05-17 07:38:07.581	info	starting. Version 0.8.0 (non-npm: lvogt/ioBroker.wireless-mbus#3c8217e899f2d1f1ea43ebf70bf1bf08a2c37715) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.1, js-controller: 4.0.23

Gibts jetzt eine Verbindung, oder nicht?

Werte scheinen bisher keine rein zu kommen...

Danke für einen Tipp
Daniel

[lvogt]

@ratte-rizzo
Hi. Ich denke da besteht keine Verbindung. Das am Ende connected auf true gesetzt wird ist ein Bug...
Evtl. habe ich mit 0.8.0 beim neuschreiben der Kommunikation einen Bug eingebaut oder dein CUL macht gerade einfach Probleme.
Evtl. nochmal Port und Rechte etc prüfen oder ein Downgrade auf 0.7.9 machen, diese Woche habe ich wenig Zeit, um dem auf den Grund zu gehen

[ratte-rizzo]

Moin @lvogt

Ach wie schön, dann hab ich ja noch nen Bug gefunden 🙃 Die "Ampel" bei den Instanzen war auch grün übrigens. Daten kamen nach einer Stunde auch noch keine.

Dann hab ich "irgendwas" gemacht, zig mal gebootet und nun läuft er wieder. Natürlich absolut nicht reproduzierbar. Lag jedenfalls nicht am Adapter (außer der Bug).

Läuft jedenfalls wieder.
Dank & Gruß
Daniel

[ok1]

Hallo @lvogt , eine kurze Frage - ist es möglich, oder wird es in absehbarer Zeit möglich sein, den Adapter auch im C-Mode zu konfigurieren ? Ich betreibe einen CUL 1101 zum Empfang von Qundis HKV, die im C-Mode senden. Vielen Dank !

[lvogt]

@ok1 Gibt es denn für den CUL eine Firmware die den C Mode unterstützt?

[SegaPro]

Hallo zusammen,

ich hänge mich hier mal rein, da ich gerade ebenfalls den Adapter teste.

Mein Stick:

[175697.945786] usb 4-1: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[175697.945789] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[175697.945791] usb 4-1: Product: CP2102 USB to UART Bridge Controller
[175697.945793] usb 4-1: Manufacturer: Silicon Labs
[175697.945794] usb 4-1: SerialNumber: 0001
[175697.951000] cp210x 4-1:1.0: cp210x converter detected
[175697.965458] usb 4-1: cp210x converter now attached to ttyUSB1

Der Stick funktioniert leider nicht:

4467

Log-Größe: 749.3 KB
Zeit
	
Nachricht
wireless-mbus.0
	2022-05-25 11:20:04.436	error	Timeout waiting for response
wireless-mbus.0
	2022-05-25 11:20:04.436	error	Error opening serial port /dev/ttyUSB1 with baudrate 57600
wireless-mbus.0
	2022-05-25 11:20:04.435	error	IMST: Failed to init device: Timeout waiting for response

Was mir direkt auffällt: Bei anderen, die offensichtlich diesen Stick nutzen, steht "Silicon Labs IMST USB-Stick for Smart Meter". Bei mir steht "Silicon Labs CP210x UART Bridge"

Habe ich den falschen Stick? Die falsche Firmware? Kann ich die irgendwie aktualisieren? Entweder ich bin blind, oder stelle mich gerade etwas dumm an. Ich hab zumindest nichts darüber gefunden.

Viele Grüße

[lvogt]

@segapro
Als erste Maßnahme wäre ein Debug Log nötig

[Thomas Braun]

@segapro sagte in Test Adapter wireless-mbus v0.7.x:

Habe ich den falschen Stick? Die falsche Firmware? Kann ich die irgendwie aktualisieren?

Oder eine andere/alte Version der usb-Geräte-ID-Tabelle. Die Namen sind unwichtig, es zählt die USB-Id.

[SegaPro]

Hi zusammen,

sorry - Debug, daran hätte ich denken müssen:

@lvogt :

wireless-mbus.0
	2022-05-26 13:45:14.492	error	Timeout waiting for response
wireless-mbus.0
	2022-05-26 13:45:14.491	error	Error opening serial port /dev/ttyUSB1 with baudrate 57600
wireless-mbus.0
	2022-05-26 13:45:14.490	error	IMST: Failed to init device: Timeout waiting for response
wireless-mbus.0
	2022-05-26 13:45:11.527	debug	connected set to false
wireless-mbus.0
	2022-05-26 13:45:11.474	debug	IMST: TX: a5810306000300030800b8d6
wireless-mbus.0
	2022-05-26 13:45:11.470	debug	Created device of type: IMST iM871A
wireless-mbus.0
	2022-05-26 13:45:11.431	info	starting. Version 0.8.1 (non-npm: lvogt/ioBroker.wireless-mbus#a1e31007c89a6c0b60e468bd901a420b6f890b12) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23
wireless-mbus.0
	2022-05-26 13:45:07.265	error	Serialport error: Port is not open

Ports:

wireless-mbus.0
	2022-05-26 13:44:25.380	info	List of port: [{"path":"/dev/ttyUSB0","manufacturer":"FTDI","serialNumber":"D309V01Y","pnpId":"usb-FTDI_FT230X_Basic_UART_D309V01Y-if00-port0","vendorId":"0403","productId":"6015"},{"path":"/dev/ttyACM0","manufacturer":"Texas Instruments","serialNumber":"__0X00124B0014D9E43B","pnpId":"usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014D9E43B-if00","vendorId":"0451","productId":"16a8"},{"path":"/dev/ttyUSB1","manufacturer":"Silicon Labs","serialNumber":"0001","pnpId":"usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS3"}]

Ich hoffe, dass es nicht am Stick liegt. :(

Viele Grüße

[Thomas Braun]

@segapro

Wie steht der Stick hier drin?

ls -l /dev/serial/by-id

[SegaPro]

@thomas-braun sagte in Test Adapter wireless-mbus v0.7.x:

ls -l /dev/serial/by-id

ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 23. Mai 10:18 usb-FTDI_FT230X_Basic_UART_D309V01Y-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 25. Mai 11:07 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 23. Mai 10:18 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014D9E43B-if00 -> ../../ttyACM0

[ratte-rizzo]

Moin @lvogt und alle, die Verbindungsprobleme mit dem CUL haben, wenn er in eine VM o.ä. durchgereicht wird

Bei mir ist es immer so, dass nach einem Neustart der CUL zwar sichtbar ist, der Adapter aber immer einen Timeout bekommt. Die Lösung scheint (!) bei mir recht einfach: Einmal den Fixer (iob fix) durchlaufen lassen.

Vielleicht hilft es ja jemandem...

Lieben Gruß
Daniel

[ok1]

@lvogt sagte in Test Adapter wireless-mbus v0.7.x:

@ok1 Gibt es denn für den CUL eine Firmware die den C Mode unterstützt?

ja, die Firmware mit Mode C Unterstützung kann man sich aus den Quellen (culfw-code-r568-trunk-culfw) einfach selbst erstellen, in dem man im Verzeichnis CUL das include "board.h" anpasst:

//ok
#define HAS_MBUS        1
#define CUL_V3  1

und nicht benötigte Module wg. geringem Speicherplatz rauskommentiert, z.B.

#if defined(CUL_V3) || defined(CUL_V4)
#  define HAS_FHT_8v                    // PROGMEM:  586b  RAM: 23b
#  define HAS_FHT_TF
#  define FHTBUF_SIZE          174      //                 RAM: 174b
#  define RCV_BUCKETS            4      //                 RAM: 25b * bucket
#  define FULL_CC1100_PA                // PROGMEM:  108b
#  define HAS_RAWSEND                   //
//#  define HAS_ASKSIN                    // PROGMEM: 1314
//#  define HAS_ASKSIN_FUP                // PROGMEM:   78
//#  define HAS_MORITZ                    // PROGMEM: 1696
#  define HAS_ESA                       // PROGMEM:  286
#  define HAS_TX3                       // PROGMEM:  168
//#  define HAS_INTERTECHNO               // PROGMEM: 1352
#  define HAS_TCM97001                  // PROGMEM:  264
#  define HAS_UNIROLL                   // PROGMEM:   92
#  define HAS_MEMFN                     // PROGMEM:  168
//#  define HAS_SOMFY_RTS                 // PROGMEM: 1716
//#  define HAS_BELFOX                    // PROGMEM:  214
#endif

Nach Flashen der Firmware konnte der CUL-Stick Qundis qcaloric 5.5 Telegramme einwandfrei lesen. Geprüft mit wmbusmeters und FHEM-CUL-Modul.

[lvogt]

@ok1
Hi, ich habe gerade v0.8.2 auf npm veröffentlicht die den C Mode für den CUL unterstützen sollte.
Unabhängig davon ob es (hoffentlich) funktioniert oder nicht, wäre es schön wenn du mir ein Debug Log vom Start und evtl 1 oder 2 empfangenen Telegrammen zukommen lassen könntest.

[SegaPro]

Danke für eure Antworten,

ein "iob fix" hat leider nicht geholfen. Hatte es direkt getestet. So recht weiß ich nun auch nicht mehr, wonach ich noch gucken könnte.

Wünsche euch einen schönen Start in die neue Woche.

[lvogt]

@segapro
Was sagt denn

ls -l /dev/ttyUSB*

?

Die Benutzer und Gruppenzugehörigkeit bei den Symlinks ist ja keine verlässliche Aussage.

[SegaPro]

@lvogt sagte in Test Adapter wireless-mbus v0.7.x:

ls -l /dev/ttyUSB*

Hi @lvogt ,

Danke, dass Du mich unterstützt.

ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 27. Mai 15:33 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 30. Mai 11:30 /dev/ttyUSB1

Viele Grüße

[Thomas Braun]

@segapro

sudo -H -u iobroker groups

liefert? Der user muss in der Gruppe 'dialout' drin sein.

[SegaPro]

@thomas-braun sagte in Test Adapter wireless-mbus v0.7.x:

sudo -H -u iobroker groups

@lvogt

sudo -H -u iobroker groups
iobroker tty dialout