Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)

skraw.iobroker

Ich weiss nicht was da zusammenprogrammiert wurde, aber seit Tagen probiere ich auf einer einfachen Raspi3 Konfiguration den maxcul Adapter vernuenftig zum Laufen zu bekommen. Basis ist das Downloadimage das die meisten benutzen (stretch), und dann einfach den Adapter dazugefuegt. Was im Logfile passiert ist folgendes:

maxcul.0 2018-02-17 14:29:59.243 info received unknown data: 20 900
maxcul.0 2018-02-17 14:29:54.241 info received unknown data: 0 900
maxcul.0 2018-02-17 14:29:54.227 info received unknown data: 2
maxcul.0 2018-02-17 14:29:49.239 info received unknown data: 20 900
maxcul.0 2018-02-17 14:29:44.220 info received unknown data: 20 900
maxcul.0 2018-02-17 14:29:39.218 info received unknown data: 20 900
maxcul.0 2018-02-17 14:29:34.217 info received unknown data: 20 900
maxcul.0 2018-02-17 14:29:29.214 info received unknown data: 20 895
maxcul.0 2018-02-17 14:29:24.211 info received unknown data: 20 890
maxcul.0 2018-02-17 14:29:19.209 info received unknown data: 20 885
maxcul.0 2018-02-17 14:29:14.207 info received unknown data: 20 880
maxcul.0 2018-02-17 14:29:09.207 info received unknown data: 875
maxcul.0 2018-02-17 14:29:09.190 info received unknown data: 20
maxcul.0 2018-02-17 14:29:04.204 info received unknown data: 870
maxcul.0 2018-02-17 14:29:04.196 info received unknown data: 20
maxcul.0 2018-02-17 14:28:59.201 info received unknown data: 865
maxcul.0 2018-02-17 14:28:59.195 info received unknown data: 20
maxcul.0 2018-02-17 14:28:54.186 info received unknown data: 20 860
maxcul.0 2018-02-17 14:28:49.184 info received unknown data: 20 855
maxcul.0 2018-02-17 14:28:44.183 info received unknown data: 20 850
maxcul.0 2018-02-17 14:28:39.179 info received unknown data: 20 845

Das geht ewig so weiter. Der Gegencheck mit dem nanoCUL per screen sagt mir jedoch dass die Hardware und die MAX Fensterkontakte voellig einwandfrei funktionieren und lesbare Events von sich geben.

Nach Lesen vieler obiger Zeilen stelle ich fest, dass dieser Adapter nicht in der Lage ist einen einfachen String vom USB-Serial zu lesen. Was ausgegeben wird sind immer nur halbe Strings als "unknown data".

Ich kann kein Java, waers C waers ein Klacks. Was ist so schwer dran in Java einen String von einer Seriellen zu lesen (also GANZ mein ich)… ???

Der CUL-Adapter hat uebrigens sehr wahrscheinlich dasselbe Problem. Das ganze ist getestet mit mehreren nanoCUL die alle per screen voellig einwandfrei gehen und mehreren Fensterkontakten die ebenfalls alle einwandfrei gehen.

Geht USB-Serial in diesem Download-Image (vom iobroker) vielleicht ueberhaupt nicht richtig? Auf der Console geht ja alles ...

LG

Homoran

Hast du einen Busware CUL?

apollon77

<ironiemodus>Natürlich machen die adapterentwickler absichtlich Adapter die nicht funktionieren nur um die User maximal zu ärgern. Und JavaScript als Programmiersprache kann gar nichts.</ironiemodus>

Ließ dir deinen Text nochmal bitte durch und überlege ob man wirklich so schreiben sollte. Ich als Entwickler des Adapters würde mich ziemlich angepisst fühlen.

Kannst du verifizieren das der Adapter den korrekten initialisierungsstring sendet? Such mal im Forum, es gab vor ein paar Tagen noch einen Thread mit ähnlichen Problemen.

Bluefox

~~@skraw.iobroker:~~

Ich weiss nicht was da zusammenprogrammiert wurde, aber seit Tagen probiere ich auf einer einfachen Raspi3 Konfiguration den maxcul Adapter vernuenftig zum Laufen zu bekommen. Basis ist das Downloadimage das die meisten benutzen (stretch), und dann einfach den Adapter dazugefuegt. Was im Logfile passiert ist folgendes:

maxcul.0 2018-02-17 14:29:59.243 info received unknown data: 20 900

maxcul.0 2018-02-17 14:29:54.241 info received unknown data: 0 900

maxcul.0 2018-02-17 14:29:54.227 info received unknown data: 2

maxcul.0 2018-02-17 14:29:49.239 info received unknown data: 20 900

maxcul.0 2018-02-17 14:29:44.220 info received unknown data: 20 900

maxcul.0 2018-02-17 14:29:39.218 info received unknown data: 20 900

maxcul.0 2018-02-17 14:29:34.217 info received unknown data: 20 900

maxcul.0 2018-02-17 14:29:29.214 info received unknown data: 20 895

maxcul.0 2018-02-17 14:29:24.211 info received unknown data: 20 890

maxcul.0 2018-02-17 14:29:19.209 info received unknown data: 20 885

maxcul.0 2018-02-17 14:29:14.207 info received unknown data: 20 880

maxcul.0 2018-02-17 14:29:09.207 info received unknown data: 875

maxcul.0 2018-02-17 14:29:09.190 info received unknown data: 20

maxcul.0 2018-02-17 14:29:04.204 info received unknown data: 870

maxcul.0 2018-02-17 14:29:04.196 info received unknown data: 20

maxcul.0 2018-02-17 14:28:59.201 info received unknown data: 865

maxcul.0 2018-02-17 14:28:59.195 info received unknown data: 20

maxcul.0 2018-02-17 14:28:54.186 info received unknown data: 20 860

maxcul.0 2018-02-17 14:28:49.184 info received unknown data: 20 855

maxcul.0 2018-02-17 14:28:44.183 info received unknown data: 20 850

maxcul.0 2018-02-17 14:28:39.179 info received unknown data: 20 845

Das geht ewig so weiter. Der Gegencheck mit dem nanoCUL per screen sagt mir jedoch dass die Hardware und die MAX Fensterkontakte voellig einwandfrei funktionieren und lesbare Events von sich geben.

Nach Lesen vieler obiger Zeilen stelle ich fest, dass dieser Adapter nicht in der Lage ist einen einfachen String vom USB-Serial zu lesen. Was ausgegeben wird sind immer nur halbe Strings als "unknown data".

Ich kann kein Java, waers C waers ein Klacks. Was ist so schwer dran in Java einen String von einer Seriellen zu lesen (also GANZ mein ich)… ???

Der CUL-Adapter hat uebrigens sehr wahrscheinlich dasselbe Problem. Das ganze ist getestet mit mehreren nanoCUL die alle per screen voellig einwandfrei gehen und mehreren Fensterkontakten die ebenfalls alle einwandfrei gehen.

Geht USB-Serial in diesem Download-Image (vom iobroker) vielleicht ueberhaupt nicht richtig? Auf der Console geht ja alles ...

LG `

Das gleiche sage ich auch immer: es ist doch nicht schwierig einen String zu parsen. Besonders wenn man den Fehler reproduzieren kann. Aber Motivation was zu machen habe ich kaum. Da ich HW nicht besitze und den Fehler nicht reproduzieren kann.

carsten04

Du musst gar kein Java können, Javascript reicht schon. Einfach den Adapter forken und dann Deine Codeänderung vornehmen. Ich schau dann auch mal drüber.

skraw.iobroker

Hier kann man mal sehen dass das Problem bereits ganz am Anfang existiert. Ich halte es fuer unmoeglich dass das nicht schon vor mir jemand beim Ausprobieren gesehen hat:

maxcul.0 2018-02-18 13:51:44.129 info received unknown data: 00 453
maxcul.0 2018-02-18 13:51:41.188 info received unknown data: 7 nanoCUL868
maxcul.0 2018-02-18 13:51:41.175 info CUL FW Version: V 1.6
maxcul.0 2018-02-18 13:51:39.159 info serialPort /dev/ttyUSB0 is open!
maxcul.0 2018-02-18 13:51:39.101 info using serial device /dev/ttyUSB0@38400
maxcul.0 2018-02-18 13:51:38.503 info starting. Version 0.4.1 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.13.0
maxcul.0 2018-02-18 13:51:38.428 info States connected to redis: 127.0.0.1:6379

Schon die allererste Rueckmeldung von dem Adapter kann nicht korrekt eingelesen werden, das Interface gibt natuerlich auf die V Frage zurueck:

V 1.67 nanoCUL868

maxcul macht daraus das Obige und sieht zwischen "6" und "7" irgendwas unerklaerliches.

Nach Init per "X20" und "Zr" erscheint im screen:

Z0B1E06301337CC123456001255
Z0B1E06301337CC123456001251
Z0B1F06301337CC123456001054
Z0B1F06301337CC123456001055
Z0B1F06301337CC123456001063
Z0B1F06301337CC123456001063
Z0B1F06301337CC123456005062

Das stimmt offensichtlich.

Was bleibt ist die Frage nach der Ursache fuer den zerhackten Version-String. Was mir auffaellt ist das Changelog von maxcul:

0.3.0 (2018-01-23)

(Apollon77) Upgrade Serialport Library

(bluefox) ready for Admin3

Hat den Adapter vielleicht jemand "kaputtgeupdatet" ? Denn das ganze sieht schon ziemlich nach einem Problem mit dem seriellen Handling aus.

Leider laesst sich die Vor-Version 0.2.2 nicht installieren mit den ueblichen Methoden. Zwar wird der Adapter angelegt, aber bricht beim Upload ab mit einer Fehlermeldung wegen irgendwas was im "admin" fehlt. Folgerichtig erscheint er dann auch nicht in der Oberflaeche.

skraw.iobroker

PS: Das obige Changelog ist vom CUL Adapter, der ebenfalls nicht geht, also gar nicht mehr. Der gibt nicht mal mehr irgendwas aus.

Das Changelog vom maxcul zeigt wohl denselben Eingriff:

Changelog

0.4.1 (2018-02-15)

(Apollon77) Upgrade dependencies

0.4.0 (2018-01-24)

(Apollon77) Upgrade Serialport and cul library

skraw.iobroker

Und hier noch kurz die Ursache warum eine aeltere Version nicht installierbar ist:

root@ioBroker-Pi:/opt/iobroker# ./iobroker upload maxcul
got /opt/iobroker/node_modules/iobroker.maxcul/admin
upload [1] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/maxcul.png maxcul.png image/png
upload [0] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/index.html index.html text/html
system.adapter.maxcul does not exist

Die letzte Zeile bedeutet scheinbar dass der Adapter dann auch nicht im Admin-Web sichtbar ist.

apollon77

Für cul Adapter hat in einem anderen Thread einnistet folgendes mit nanocul herausgefunden: http://forum.iobroker.net/viewtopic.php?t=9286

Jetzt ist die Frage ob das was ist was speziell der nanocul befindet Initialisierung braucht …

Ich schaue mir das heute Abend beides mal an.

Es gab für beide Adapter bei den letzten Updates entsprechende Threads im Tester Forum aber keiner hat dort getestet. Da ich selbst die Hardware nicht habe Ist es damit dann schwierig.

Da wir aber immer alles versuchen was wir können bin ich sicher das wir das, wenn Nutzer mithelfen beim testen, alles GEMEINSAM hinbekommen.

skraw.iobroker

Ich habe den Code mittlerweile etwas gelesen und verstehe nicht woher Du das Kommando "Za

<address>" hast. Im Command Ref von CULFW kommt das nicht vor:

http://culfw.de/commandref.html

Da gibts nur Zr Zs Zx</address>

skraw.iobroker

Ich habe jetzt mal testweise den Code so geaendert:

 env.logger.debug('enable MAX! Mode of the CUL868');
                            return _this._serialDeviceInstance.writeAsync('X20\r\n').then(function() {
                                return _this._serialDeviceInstance.writeAsync('Zr\r\n').then(function() {
                                    // return _this._serialDeviceInstance.writeAsync('Za' + _this._baseAddress + '\n');
                                });
                            })['catch'](reject);

Aber ich glaube dass die "\r" nichts bringen, der macht den "V\n" vorher ja auch, das Ergebnis kommt ja, aber halt in Teile zerhackt. Das Problem liegt ziemlich sicher im Handling der seriellen Schnittstelle. Sowas simples wie einen fgets() gibts hier wohl nicht (liest so lange Zeichen bis ein [<cr>][<lf>] kommt, oder EOF)?</lf></cr>

skraw.iobroker

Um die Frage mit dem Init des nanoCUL zu beantworten. Mir scheint dass man ausser dem "Zr" fuer MORITZ praktisch nichts tun muss. Gut, wenn man die RSSI will, dann vorher ein "X20", aber das sollte auch schon genuegen…

skraw.iobroker

Hier ist der Hund begraben (communication-layer.js):

                return function() {
                    var resolver, timeout;
                    resolver = null;
                    timeout = 30000;
                    env.logger.info('serialPort ' + _this.serialPortName + ' is open!');
                    _this._serialDeviceInstance.on('data', function(data) {
                        var dataString;
                        dataString = '' + data;
                        dataString = dataString.replace(/[\r]/g, '');
                        if (/^\d+\s+\d+$/.test(dataString)) {
                            var m = dataString.match(/^(\d+)\s+(\d+)$/);
                            return _this.emit('creditsReceived', m[2], m[1]);
                        }
                        env.logger.debug('incoming raw data from CUL: ' + data);

                        if (/^V(.*)/.test(dataString)) {
                            _this.emit('culFirmwareVersion', dataString);
                            _this.ready = true;
                            return _this.emit('ready');
                        } else if (/^Z(.*)/.test(dataString)) {
                            return _this.emit('culDataReceived', dataString);
                        } else if (/^LOVF/.test(dataString)){
                            return _this.emit('LOVF', true);
                        } else {
                            return env.logger.info('received unknown data: ' + dataString);
                        }
                    });

Dieser ganze Code geht nur wenn die Daten tatsaechlich als komplette Zeilen mit "\r" am Ende ankommen. Wenn das serielle Interface das nicht macht, geht davon nichts mehr.

Die Tests testen alle nur den String-Anfang, das Loeschen des "\r" geht nur korrekt, wenn das das letzte Zeichen ist. Wenn kein "\r" vorkommt ist der String zerhackt und wird von der naechsten Schicht nicht mehr erkannt. Noch schlimmer waere der Fall wenn der gelieferte String den letzten Teil von Zeile X und den ersten Teil von Zeile X+1 enthaelt. Dann gehen gleich zwei Zeilen vom CUL baden. Durch den Replace werden die beiden einfach zusammengehaengt.

Mir scheint die alten serialport Routinen funktionierten gaenzlich anders als die neu in V0.4.0 ge-upgrade-ten.

apollon77

Ich hab eine Idee. Ja es hat sich beim serialport Update was geändert, dachte habe es korrekt umgestellt. Checke es heute Abend und melde mich ggf mit einer Version zum testen auf github. Denke das der Readline parser die Ursache ist.

skraw.iobroker

Ich moechte darauf hinweisen dass ich glaube dass auch das Schreiben auf das Device nicht korrekt geht.

Mir fallen diese staendigen Zeilen auf:

maxcul.0 2018-02-18 18:32:12.720 info received unknown data: 20 531
maxcul.0 2018-02-18 18:32:12.719 debug incoming raw data from CUL: 20 531
maxcul.0 2018-02-18 18:32:07.717 info received unknown data: 20 526
maxcul.0 2018-02-18 18:32:07.716 debug incoming raw data from CUL: 20 526
maxcul.0 2018-02-18 18:32:02.715 info received unknown data: 20 521
maxcul.0 2018-02-18 18:32:02.714 debug incoming raw data from CUL: 20 521
maxcul.0 2018-02-18 18:31:57.712 info received unknown data: 20 516
maxcul.0 2018-02-18 18:31:57.711 debug incoming raw data from CUL: 20 516
maxcul.0 2018-02-18 18:31:52.708 info received unknown data: 20 511
maxcul.0 2018-02-18 18:31:52.708 debug incoming raw data from CUL: 20 511
maxcul.0 2018-02-18 18:31:47.704 info received unknown data: 0 506
maxcul.0 2018-02-18 18:31:47.704 debug incoming raw data from CUL: 0 506
maxcul.0 2018-02-18 18:31:47.690 info received unknown data: 2
maxcul.0 2018-02-18 18:31:47.690 debug incoming raw data from CUL: 2

Es sind Zeilen ala " 20 526". Ich weiss nicht was das ist, ich kenn CUL zuwenig. Aber ich wuerde sagen das ist etwas was nach "Zr" gar nicht kommen duerfte.

Deshalb ist meine Vermutung dass in Wirklichkeit nur das Schreiben von "V\n" geht und die Version kommt, aber die Kommandos danach "X20\nZr\n" gar nicht mehr beim nanoCUL ankommen und deshalb diese Daten im Sekundentakt erscheinen…

skraw.iobroker

… und wenn Du schon mal am Code-Aendern bist, "Received" schreibt man nicht "Recieved" Kommt 4-5 Mal vor im Code ...

Ist mir in der Ausgabe aufgefallen, kommt aber als Token auch vor.

apollon77

;-)) fixe ich gern mit. Der Adapter ist auch nicht von mir von daher kann ich noch mehr blind Änderungen machen. Aber mit Testern geht alles

apollon77

So, jetzt dann hier mal als ersten Schritt eine 0.4.2 auf GitHub. Diese sollte das vollständige Zeilenlesen fixen und damit genau so funktionieren wie vorher. Weiterhin sind die "Recieved" in "Received" geändert … Hoffe es sind wirklich die Nachrichten falsch.

Bitte testen und berichten.

skraw.iobroker

Geht nicht. wie man hier sieht sind die Zeilen immer noch zerhackt, schon die erste Ausgabe der Version ist zerteilt:

maxcul.0 2018-02-19 02:18:26.723 info received unknown data: 20 465
maxcul.0 2018-02-19 02:18:21.691 info received unknown data: 20 460
maxcul.0 2018-02-19 02:18:17.417 info received unknown data: CC123456001064
maxcul.0 2018-02-19 02:18:16.690 info received unknown data: 20 464
maxcul.0 2018-02-19 02:18:11.690 info received unknown data: 20 459
maxcul.0 2018-02-19 02:18:11.607 info received unknown data: Z0B4106301337CC123456001263
maxcul.0 2018-02-19 02:18:06.686 info received unknown data: 20 463
maxcul.0 2018-02-19 02:18:01.687 info received unknown data: 20 458
maxcul.0 2018-02-19 02:17:56.680 info received unknown data: 00 453
maxcul.0 2018-02-19 02:17:53.737 info received unknown data: anoCUL868
maxcul.0 2018-02-19 02:17:53.719 info CUL FW Version: V 1.67 n
maxcul.0 2018-02-19 02:17:51.697 info serialPort /dev/ttyUSB0 is open!
maxcul.0 2018-02-19 02:17:51.670 info using serial device /dev/ttyUSB0@38400
maxcul.0 2018-02-19 02:17:51.198 info starting. Version 0.4.2 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.13.0

skraw.iobroker

Und es gibt noch ein Problem. Der Adapter laesst sich eigentlich nicht aus dem Github installieren. Ich habe ein frisches Image verwendet und versucht maxcul aus dem github zu installieren. Zwar installiert scheinbar der Adapter irgendwie/irgendwo, aber die Konfiguration springt nicht an und er erscheint auch nicht in der Instanzliste, obwohl er in der Adapterliste mit Version 0.4.2 und Status "installiert" steht.

Da geht wohl was waehrend der Installation nicht…

Hier das Logfile:

host.ioBroker-Pi 2018-02-19 03:35:37.807 info Update repository "default" under "[http://download.iobroker.net/sources-dist.json](http://download.iobroker.net/sources-dist.json)"
iobroker 2018-02-19 03:35:36.910 info exit 0
iobroker 2018-02-19 03:35:36.788 info upload [0] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/index.html index.html text/html
iobroker 2018-02-19 03:35:36.654 info upload [1] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/maxcul.png maxcul.png image/png
iobroker 2018-02-19 03:35:36.625 info got /opt/iobroker/node_modules/iobroker.maxcul/admin
iobroker 2018-02-19 03:35:10.080 info prebuild-install WARN install No prebuilt binaries found (target=6.13.0 runtime=node arch=arm platform=linux)
iobroker 2018-02-19 03:35:10.057 info prebuild-install http 404 [https://github.com/node-serialport/node … arm.tar.gz](https://github.com/node-serialport/node-serialport/releases/download/v6.0.5/serialport-v6.0.5-node-v48-linux-arm.tar.gz)
iobroker 2018-02-19 03:35:09.339 info prebuild-install http request GET [https://github.com/node-serialport/node ... arm.tar.gz](https://github.com/node-serialport/node-serialport/releases/download/v6.0.5/serialport-v6.0.5-node-v48-linux-arm.tar.gz)
iobroker 2018-02-19 03:35:09.336 info prebuild-install info looking for cached prebuild @ /root/.npm/_prebuilds/https-github.com-node-serialport-node-serialport-releases-download-v6.0.5-serialport-v6.0.5-node-v48-linux-arm.tar.gz
iobroker 2018-02-19 03:35:09.328 info prebuild-install info looking for local prebuild @ prebuilds/serialport-v6.0.5-node-v48-linux-arm.tar.gz
iobroker 2018-02-19 03:35:09.315 info info begin Prebuild-install version 2.5.1
iobroker 2018-02-19 03:35:09.313 info
iobroker 2018-02-19 03:35:09.307 info prebuild-install
iobroker 2018-02-19 03:34:04.462 info npm install [https://github.com/ioBroker/ioBroker.ma ... all/master](https://github.com/ioBroker/ioBroker.maxcul/tarball/master) --production --prefix "/opt/iobroker" (System call)
iobroker 2018-02-19 03:34:03.895 info install [https://github.com/ioBroker/ioBroker.ma ... all/master](https://github.com/ioBroker/ioBroker.maxcul/tarball/master)
iobroker 2018-02-19 03:34:02.656 info url "[https://github.com/ioBroker/ioBroker.ma ... all/master](https://github.com/ioBroker/ioBroker.maxcul/tarball/master)" maxcul

NEWS

Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)

Changelog

0.4.1 (2018-02-15)

0.4.0 (2018-01-24)

Support us

840
Online

31.8k
Users

80.0k
Topics

1.3m
Posts

NEWS

Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)

Changelog

0.4.1 (2018-02-15)

0.4.0 (2018-01-24)

Support us

840Online

31.8kUsers

80.0kTopics

1.3mPosts

840
Online

31.8k
Users

80.0k
Topics

1.3m
Posts