Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)

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

skraw.iobroker

Die Erkenntnisse von heute sind folgende:

Es ist mir jetzt gelungen in einer frischen Installation die Version 0.3.0 von maxcul zu installieren. Ich stelle fest sie geht voellig einwandfrei. Und ich hatte scheinbar mit meiner obigen Analyse recht, die neuen Versionen haben allesamt ein Problem mit dem Senden der Init-Kommandos. Im 0.3.0 erscheinen keinerlei wilde Meldungen im Mehrsekunden-Takt. Es kommen nur die erwuenschten MORITZ-Meldungen und sonst nichts.

Das bedeutet das "neue" Handling der seriellen Schnittstelle ist komplett kaputt.

apollon77

~~@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… `
Ne das passt alles. Bei Github-Installs werden nicht automatisch Adapterinstanzen angelegt wie sonst. Du musst die ggf manuell unter Adapter über den "+"-Button bei entsprechenden Adapter anlegen (lassen).

Das ist "absicht".

Ich schaue nachher nochmal in die Parser-Logik rein und versuche es mal umzubauen. Gibt noch nen zweiten Weg wie es gehen kann

apollon77

So ich habe auf Github nochmal die Parserei umgebaut, wie Sie hoffentlich laut Anleitung gehen sollte. Bitte nochmal testen. Versions nummer bleibt gleich. Kannst den Adapter einfach drüberinstallieren

skraw.iobroker

Also nach 2 Minuten Test kann ich schon mal sagen, dass es sich jedenfalls besser anfuehlt als vorher. Ich sehe keine "unknown data" mehr durchscrollen. Ich lass das jetzt mal 1-2 Tage laufen und geb dann nochmal Bescheid ob noch irgendwas passiert ist. Schaut aber gut aus.

Du kannst Dich noch dran erinnern, dass der CUL-Adapter wahrscheinlich dasselbe Problem hatte?

apollon77

Beim cul Adapter ist das problem vorauss anders gelagert. Da scheint die Kommunikation zu klappen, da ist es scheinbar bei einem nanocul "zu wenig" bei der Initialisierung. Der MaxCul sendet wirklich V, dann X01 und dann T01 als Befehle wie FHEM auch.

Der Cul-Adapter bisher nur "X21". was reichen sollte und auch bei "Normalen CULSticks ausreicht, aber bei nanocul wohl nicht.

Da sind wir noch dran.

apollon77

PS: Wenn besser geht als vorher dann publishe ich das heute Abend und damit ist es wenigstens im "Latest".

skraw.iobroker

Also das geht definitiv viel besser, um nicht zu sagen, es geht ueberhaupt mal :-)

PS: Mir ist immer noch nicht klar woher Du den "Za

apollon77

Ich denke das kommt von "FHEM Research" … tippe jemand hat FHEM geschaut und identisch hier nachgebaut.

Da findet man es auch: https://github.com/mhop/fhem-mirror/blo ... MAX.pm#L63

PS: setzt du bitte ein "gelöst" in den Thread Titel des ersten Posts? :-)!

skraw.iobroker

~~@apollon77:~~

Ich denke das kommt von "FHEM Research" … tippe jemand hat FHEM geschaut und identisch hier nachgebaut.

Da findet man es auch: https://github.com/mhop/fhem-mirror/blo ... MAX.pm#L63 `

Naja, so einfach ists ja nicht. Man kann ja nicht sagen "die machen das auch falsch, deshalb machen wir das auch so".

Fakt ist, CULFW kennt dieses Kommando nach eigener Doku nicht. Vielleicht/Wahrscheinlich wird es einfach ignoriert.

Aber das macht es nicht richtig.

~~@apollon77:~~

PS: setzt du bitte ein "gelöst" in den Thread Titel des ersten Posts? :-)! `

Da wuerd ich erst noch gern 1-2 Tage vergehen lassen. Ich habe zu wenig Equipment um den Adapter richtig zu stressen. Also will ich wenigstens ein wenig Laufzeit sehen.

Ich hab im Forum Screenshots von komplexen CUL-Configs gesehen (dem anderen Adapter), die ich im jetzigen Stand fuer unmoeglich halte. Ich halte den Adapter aber fuer deutlich wichtiger als den maxcul weil er einfach verschiedene Geraetetypen kann. Es waere gut wenn die im maxcul durchgefuehrten Aenderungen auch im CUL getestet wuerden mit Geraeten != MAX!

apollon77

~~@skraw.iobroker:~~

~~@apollon77:~~

Ich denke das kommt von "FHEM Research" … tippe jemand hat FHEM geschaut und identisch hier nachgebaut.

Da findet man es auch: https://github.com/mhop/fhem-mirror/blo ... MAX.pm#L63 `

Naja, so einfach ists ja nicht. Man kann ja nicht sagen "die machen das auch falsch, deshalb machen wir das auch so".

Fakt ist, CULFW kennt dieses Kommando nach eigener Doku nicht. Vielleicht/Wahrscheinlich wird es einfach ignoriert.

Aber das macht es nicht richtig. `

Durchaus wahr. Ich habe nur gesagt wo es vermutlich herkommt.

~~@skraw.iobroker:~~

Ich hab im Forum Screenshots von komplexen CUL-Configs gesehen (dem anderen Adapter), die ich im jetzigen Stand fuer unmoeglich halte. Ich halte den Adapter aber fuer deutlich wichtiger als den maxcul weil er einfach verschiedene Geraetetypen kann. Es waere gut wenn die im maxcul durchgefuehrten Aenderungen auch im CUL getestet wuerden mit Geraeten != MAX! `

Dort sind die Probleme anders gelagert. Aber da ist auch ein User der testen will.

booehmemaik

Moin, hat von euch jemand auch Wandthermostate im Einsatz und die zum laufen gebracht mit nanocul ?

Gruss

Maik

skraw.iobroker

Diese Meldungen jede Stunde sind normal nehm ich an:

maxcul.0 2018-02-20 10:35:38.927 info Packet 0f0104031234561234560012140a239a sent but no response!

maxcul.0 2018-02-20 10:35:26.914 info checkTimeIntervalFired

?

skraw.iobroker

~~@booehmemaik:~~

Moin, hat von euch jemand auch Wandthermostate im Einsatz und die zum laufen gebracht mit nanocul ?

Gruss

Maik `

Was fuer Typen/Hersteller?

apollon77

~~@skraw.iobroker:~~

Diese Meldungen jede Stunde sind normal nehm ich an:

maxcul.0 2018-02-20 10:35:38.927 info Packet 0f0104031234561234560012140a239a sent but no response!

maxcul.0 2018-02-20 10:35:26.914 info checkTimeIntervalFired

? `

Im Code sehe ich das 1x pro Stunde "sendTimeInformation" ausgefürt wird und das sendet einen "generateTimePayload" an die "baseAddress" die man in der Adapter-Konfig einstellt. Was ist diese "Base Adress"? Was habt Ihr da eingefüllt?

Am Ende ist das übrigens auch die Adresse die in dem "ominösen" "Za" genutzt wird.

Dies sendet ein Kommando mit Typ 03 aus und das kann gut das oben stehende sein.

Also ich kann nur raten: Das sind "broadcast Messages an alle Devices die sich dieser Base Address" zugehörig fühlen das die ne aktuelle Zeit bekommen.

Für Tiefer muss jemand der sich mit Max-Kommunikation auskennt reinknien und das rausfinden

skraw.iobroker

Also die Adresse die man ja auch in der Config von maxCUL einstellt ist wohl die eigene (Standard 123456). Ich schliesse das daraus dass diese Adresse in den Paketen vom Tuerkontakt drin steht sobald diese gepairt sind mit dem nanoCUL.

apollon77

Ok, dann sendet der Adapter einmal pro Stunde an sich selbst die Zeit … :-)) und reagiert nicht darauf ...

hm

skraw.iobroker

Leider scheint doch nicht alles so gut zu gehen wie ich gestern dachte.

Zwar scheinen die Fensterkontakte zu gehen, aber Thermostate scheinen ein Problem zu haben. Es sieht so aus als ob man sie pairen koennte, alle Objekte werden angelegt, aber sie liefern keine Werte rein. Das Setzen der Temperatur geht, aber Rueckmeldungen gibt es keine.

Und ich sags nicht gern, aber mit Version 0.3.0 gehen sie …

Community Forum

NEWS

Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)

Support us

739

32.4k

81.5k

1.3m