Test Adapter wireless-mbus v0.9.x
-
@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 -
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 -
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 !
-
@ok1 Gibt es denn für den CUL eine Firmware die den C Mode unterstützt?
-
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 ttyUSB1Der 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 responseWas 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
-
@segapro
Als erste Maßnahme wäre ein Debug Log nötig -
@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.
-
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 openPorts:
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 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 -
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 -
@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 1und 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 #endifNach Flashen der Firmware konnte der CUL-Stick Qundis qcaloric 5.5 Telegramme einwandfrei lesen. Geprüft mit wmbusmeters und FHEM-CUL-Modul.
-
@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. -
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.
-
@segapro
Was sagt dennls -l /dev/ttyUSB*?
Die Benutzer und Gruppenzugehörigkeit bei den Symlinks ist ja keine verlässliche Aussage.
-
@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/ttyUSB1Viele Grüße
-
-
@thomas-braun sagte in Test Adapter wireless-mbus v0.7.x:
sudo -H -u iobroker groups
sudo -H -u iobroker groups iobroker tty dialout -
@segapro
Tja...
Evtl mal noch Baudraten durchprobieren. Und sonst mal mit irgendwelcher IMST Software versuchen das Ding zu testen? -
@lvogt sagte in Test Adapter wireless-mbus v0.7.x:
@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.vielen Dank für den schnellen Einbau des C-Modes !
Gerne das debug-Log vom Start:wireless-mbus.1 2022-05-30 23:44:28.281 debug connected set to true wireless-mbus.1 2022-05-30 23:44:28.221 debug connected set to true wireless-mbus.1 2022-05-30 23:44:28.206 info CUL: Receiver set to C-MODE and data reporting with RSSI wireless-mbus.1 2022-05-30 23:44:28.204 debug CUL: RX: 434d4f44450d0a wireless-mbus.1 2022-05-30 23:44:28.194 debug CUL: TX: 5832310d0a6272630d0a wireless-mbus.1 2022-05-30 23:44:28.193 info CUL: Version: V 1.67 CUL868 wireless-mbus.1 2022-05-30 23:44:28.190 debug CUL: RX: 5620312e36372043554c3836380d0a wireless-mbus.1 2022-05-30 23:44:28.173 debug CUL: TX: 560d0a wireless-mbus.1 2022-05-30 23:44:28.163 debug Created device of type: CUL wireless-mbus.1 2022-05-30 23:44:27.988 info starting. Version 0.8.2 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.18.4, js-controller: 4.0.23 wireless-mbus.1 2022-05-30 23:44:18.940 info Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason wireless-mbus.1 2022-05-30 23:44:18.936 info terminating wireless-mbus.1 2022-05-30 23:44:18.928 info Got terminate signal TERMINATE_YOURSELF wireless-mbus.1 2022-05-30 23:42:44.129 info List of port: [{"path":"/dev/ttyAMA0"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyACM0","manufacturer":"busware.de","pnpId":"usb-busware.de_CUL868-if00","vendorId":"03eb","productId":"204b"}] wireless-mbus.1 2022-05-30 23:42:27.170 info CUL: Receiver set to C-MODE and data reporting with RSSI wireless-mbus.1 2022-05-30 23:42:27.110 info CUL: Version: V 1.67 CUL868 wireless-mbus.1 2022-05-30 23:42:26.921 info starting. Version 0.8.2 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.18.4, js-controller: 4.0.23und das erste Telegramm:
wireless-mbus.1 2022-05-30 23:48:43.943 debug Value QDS-29435752.data.7-0-VIF_TIME_POINT_DATE_TIME: 2022-05-30 22:48 wireless-mbus.1 2022-05-30 23:48:43.921 debug Value QDS-29435752.data.6-0-VIF_TIME_POINT_DATE: 2022-05-18 wireless-mbus.1 2022-05-30 23:48:43.897 debug Value QDS-29435752.data.5-17-VIF_TIME_POINT_DATE: 2022-04-30 wireless-mbus.1 2022-05-30 23:48:43.873 debug Value QDS-29435752.data.4-17-VIF_HCA: 0 wireless-mbus.1 2022-05-30 23:48:43.846 debug Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31 wireless-mbus.1 2022-05-30 23:48:43.822 debug Value QDS-29435752.data.2-1-VIF_HCA: 0 wireless-mbus.1 2022-05-30 23:48:43.802 debug Value QDS-29435752.data.1-0-VIF_HCA: 5 wireless-mbus.1 2022-05-30 23:48:43.543 debug Updating device: QDS-29435752 wireless-mbus.1 2022-05-30 23:48:43.076 debug Creating device: QDS-29435752 wireless-mbus.1 2022-05-30 23:48:43.072 debug VIF_TIME_POINT_DATE_TIME: Value raw 635311664 value calc 2022-05-30 22:48 wireless-mbus.1 2022-05-30 23:48:43.070 debug DIB dataField 4 wireless-mbus.1 2022-05-30 23:48:43.068 debug VIF_TIME_POINT_DATE: Value raw 9682 value calc 2022-05-18 wireless-mbus.1 2022-05-30 23:48:43.067 debug DIB dataField 2 wireless-mbus.1 2022-05-30 23:48:43.066 debug VIF_TIME_POINT_DATE: Value raw 9438 value calc 2022-04-30 wireless-mbus.1 2022-05-30 23:48:43.064 debug DIB dataField 2 wireless-mbus.1 2022-05-30 23:48:43.063 debug VIF_HCA: Value 0 wireless-mbus.1 2022-05-30 23:48:43.062 debug DIB dataField 11 wireless-mbus.1 2022-05-30 23:48:43.059 debug VIF_TIME_POINT_DATE: Value raw 11455 value calc 2021-12-31 wireless-mbus.1 2022-05-30 23:48:43.057 debug DIB dataField 2 wireless-mbus.1 2022-05-30 23:48:43.054 debug VIF_HCA: Value 0 wireless-mbus.1 2022-05-30 23:48:43.053 debug DIB dataField 11 wireless-mbus.1 2022-05-30 23:48:43.051 debug VIF_HCA: Value 5 wireless-mbus.1 2022-05-30 23:48:43.049 debug DIB dataField 11 wireless-mbus.1 2022-05-30 23:48:43.038 debug Short header wireless-mbus.1 2022-05-30 23:48:43.027 debug 3144934452574329350830a97a641800200b6e0500004b6e00000042e03e6cbf2ccb086e000000c2086cde24326c1c3ed225046d3016de25803580 wireless-mbus.1 2022-05-30 23:48:43.019 debug CUL: Message received: 3144934452574329350830a97a641800200b6e0500004b6e00000042e03e6cbf2ccb086e000000c2086cde24326c1c3ed225046d3016de258035803b wireless-mbus.1 2022-05-30 23:48:43.014 debug CUL: RX: 623331343439333434353235373433323933353038333041393741363431383030323030423645303530303030344236453030303030303432453033453643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333031364445323538303335383033420d0adie beiden wichtigsten Nutzdaten "aktueller Wert HKV"
2022-05-30 23:48:43.051 debug VIF_HCA: Value 5und Vorjahreswert
2022-05-30 23:48:43.054 debug VIF_HCA: Value 0werden korrekt erkannt.
Und das 2. Telegramm:
wireless-mbus.1 2022-05-30 23:56:05.325 debug Value QDS-29435752.data.7-0-VIF_TIME_POINT_DATE_TIME: 2022-05-30 22:55 wireless-mbus.1 2022-05-30 23:56:05.287 debug Value QDS-29435752.data.6-0-VIF_TIME_POINT_DATE: 2022-05-18 wireless-mbus.1 2022-05-30 23:56:05.238 debug Value QDS-29435752.data.5-17-VIF_TIME_POINT_DATE: 2022-04-30 wireless-mbus.1 2022-05-30 23:56:05.199 debug Value QDS-29435752.data.4-17-VIF_HCA: 0 wireless-mbus.1 2022-05-30 23:56:05.163 debug Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31 wireless-mbus.1 2022-05-30 23:56:05.129 debug Value QDS-29435752.data.2-1-VIF_HCA: 0 wireless-mbus.1 2022-05-30 23:56:05.092 debug Value QDS-29435752.data.1-0-VIF_HCA: 5 wireless-mbus.1 2022-05-30 23:56:05.000 debug Updating device: QDS-29435752 wireless-mbus.1 2022-05-30 23:56:04.998 debug VIF_TIME_POINT_DATE_TIME: Value raw 635311671 value calc 2022-05-30 22:55 wireless-mbus.1 2022-05-30 23:56:04.997 debug DIB dataField 4 wireless-mbus.1 2022-05-30 23:56:04.996 debug VIF_TIME_POINT_DATE: Value raw 9682 value calc 2022-05-18 wireless-mbus.1 2022-05-30 23:56:04.995 debug DIB dataField 2 wireless-mbus.1 2022-05-30 23:56:04.993 debug VIF_TIME_POINT_DATE: Value raw 9438 value calc 2022-04-30 wireless-mbus.1 2022-05-30 23:56:04.992 debug DIB dataField 2 wireless-mbus.1 2022-05-30 23:56:04.991 debug VIF_HCA: Value 0 wireless-mbus.1 2022-05-30 23:56:04.990 debug DIB dataField 11 wireless-mbus.1 2022-05-30 23:56:04.989 debug VIF_TIME_POINT_DATE: Value raw 11455 value calc 2021-12-31 wireless-mbus.1 2022-05-30 23:56:04.987 debug DIB dataField 2 wireless-mbus.1 2022-05-30 23:56:04.986 debug VIF_HCA: Value 0 wireless-mbus.1 2022-05-30 23:56:04.985 debug DIB dataField 11 wireless-mbus.1 2022-05-30 23:56:04.984 debug VIF_HCA: Value 5 wireless-mbus.1 2022-05-30 23:56:04.982 debug DIB dataField 11 wireless-mbus.1 2022-05-30 23:56:04.981 debug Short header wireless-mbus.1 2022-05-30 23:56:04.978 debug 3144934452574329350830a97a651800200b6e0500004b6e00000042fec66cbf2ccb086e000000c2086cde24326c1c3ed225046d3716de2521a580 wireless-mbus.1 2022-05-30 23:56:04.977 debug CUL: Message received: 3144934452574329350830a97a651800200b6e0500004b6e00000042fec66cbf2ccb086e000000c2086cde24326c1c3ed225046d3716de2521a5803b wireless-mbus.1 2022-05-30 23:56:04.975 debug CUL: RX: 623331343439333434353235373433323933353038333041393741363531383030323030423645303530303030344236453030303030303432464543363643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333731364445323532314135383033420d0aEine Besonderheit der Qundis HKV ist der Versand von Zwischen-Telegrammen mit Qundis-internen Daten.
Beim FHEM Adapter hat man das über ein zusätzliches Attribut "ignoreUnknownDataBlocks" gelöst. Ist das Attribut gesetzt werden die internen Telegramme verworfen und nicht in den Datenpunkt geschrieben. In diesem kurzen Test habe ich noch kein derartiges Telegramm gefangen, lasse den Adapter weiterlaufen und füge es hier umgehend an wenn eins vorliegt.EDIT 31.05.
Erste interne Telegramme liegen vor. Nachfolgend ein Beispiel:wireless-mbus.1 2022-05-31 16:29:41.748 debug Value QDS-29435752.data.2-0-VIF_TIME_POINT_DATE_TIME: 2022-05-31 15:29 wireless-mbus.1 2022-05-31 16:29:41.711 debug Value QDS-29435752.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: /$^,?%Rn0j wireless-mbus.1 2022-05-31 16:29:41.673 debug Updating device: QDS-29435752 wireless-mbus.1 2022-05-31 16:29:41.672 debug VIF_TIME_POINT_DATE_TIME: Value raw 635375389 value calc 2022-05-31 15:29 wireless-mbus.1 2022-05-31 16:29:41.672 debug DIB dataField 4 wireless-mbus.1 2022-05-31 16:29:41.671 debug VIF_TYPE_MANUFACTURER_UNKOWN: Value "/\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000$^\u0000\u0000\u0000\u0000,?\u0000\u0000\u0000\u0006%Rn0\u0007\u0000\u0000\u0000\u0018j\u0002\u0000" wireless-mbus.1 2022-05-31 16:29:41.671 debug DIB dataField 13 wireless-mbus.1 2022-05-31 16:29:41.670 debug Unknown manufacturer specific vif: 0x5f wireless-mbus.1 2022-05-31 16:29:41.669 debug No header wireless-mbus.1 2022-05-31 16:29:41.668 debug 494493445257432935085243780dff5f350082ea1800800007b06ed2bbe12506000000bf2c00000000de240000005eb7000080008000800080008000800080009b248000000000000000002f046d1d0fdf25620780 wireless-mbus.1 2022-05-31 16:29:41.667 debug CUL: Message received: 494493445257432935085243780dff5f350082ea1800800007b06ed2bbe12506000000bf2c00000000de240000005eb7000080008000800080008000800080009b248000000000000000002f046d1d0fdf256207803a wireless-mbus.1 2022-05-31 16:29:41.666 debug CUL: RX: 62343934343933343435323537343332393335303835323433373830444646354633353030383245413138303038303030303742303645443242424531323530363030303030304246324330303030303030304445323430303030303035454237303030303830303038303030383030303830303038303030383030303830303039423234383030303030303030303030303030303030324630343644314430464446323536323037383033410d0aIn welche Datenpunkte werden die Werte vom Adapter eingetragen ?
Unter wireless-mbus.1 sind sie noch nicht vorhanden:
EDIT 31.05.
Die Datenpunkte sind jetzt auch da:
