NEWS
Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)
-
Was ist diese "Base Adress"? Was habt Ihr da eingefüllt? `
die Base Address ist gleich maxcube.0.info.rf_address
Wenn du alle Thermostate am Cube angelernt hast, stellt diese Adresse die kommunikation sicher.
Wenn du also beim nanocul mit maxcul diese Adresse hinterlegst, funktioniert auch die Kommunikation ohne weiteres includieren.
Gruss
Maik
-
Ok, ich habe mal in der Github Version (jetzt 0.5.0) wieder die alte Serialport Version eingebaut … Bitte checken.
-
Startet nicht mal:
maxcul.0 2018-02-22 09:03:29.029 error TypeError: Cannot read property 'removeAllListeners' of undefined at CommunicationServiceLayer.connect (/opt/iobroker/node_modules/iobroker.maxcul/lib/communication-layer.js:49:37) at MaxDrive maxcul.0 2018-02-22 09:03:29.029 error uncaught exception: Cannot read property 'removeAllListeners' of undefined maxcul.0 2018-02-22 09:03:29.028 info using serial device /dev/ttyUSB0@38400 maxcul.0 2018-02-22 09:03:28.550 info starting. Version 0.5.0 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0 host.ioBroker-Pi 2018-02-22 09:03:26.689 info instance system.adapter.maxcul.0 started with pid 872
geändert: Code in Code-Tags; Homoran (Mod)
-
Danke, naja die Tests sind nicht vollständig
Fixed. Bitte nochmals versuchen
-
Mal was neues, der Adapter haengt, nach dem hier gehts nicht mehr weiter und man kann auch nichts tun. Die "Statusled" steht auf rot und alle drei Punkte auf "falsch"
maxcul.0 2018-02-22 10:13:30.797 debug enable MAX! Mode of the CUL868 maxcul.0 2018-02-22 10:13:29.800 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":453,"ack":true,"ts":1519290809793,"q":0,"from":"system.adapter.maxcul.0","lc":1519290809793} maxcul.0 2018-02-22 10:13:29.797 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1519290809791,"q":0,"from":"system.adapter.maxcul.0","lc":1519208208071} maxcul.0 2018-02-22 10:13:26.824 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":true,"ack":true,"ts":1519290806814,"q":0,"from":"system.adapter.maxcul.0","lc":1519290806814} maxcul.0 2018-02-22 10:13:26.822 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.version {"val":"V 1.67 nanoCUL868","ack":true,"ts":1519290806812,"q":0,"from":"system.adapter.maxcul.0","lc":1519041256179} maxcul.0 2018-02-22 10:13:26.805 info CUL FW Version: V 1.67 nanoCUL868 maxcul.0 2018-02-22 10:13:26.801 debug incoming raw data from CUL: V 1.67 nanoCUL868 maxcul.0 2018-02-22 10:13:26.792 debug Requested CUL Version... maxcul.0 2018-02-22 10:13:26.784 debug check CUL Firmware version maxcul.0 2018-02-22 10:13:24.788 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":false,"ack":true,"ts":1519290804785,"q":0,"from":"system.adapter.maxcul.0","lc":1519290691619} maxcul.0 2018-02-22 10:13:24.776 info serialPort /dev/ttyUSB0 is open! maxcul.0 2018-02-22 10:13:24.755 info using serial device /dev/ttyUSB0@38400 maxcul.0 2018-02-22 10:13:24.245 info starting. Version 0.5.0 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0 maxcul.0 2018-02-22 10:13:24.188 info States connected to redis: 127.0.0.1:6379 maxcul.0 2018-02-22 10:13:24.177 debug statesDB connected maxcul.0 2018-02-22 10:13:24.124 debug objectDB connected host.ioBroker-Pi 2018-02-22 10:13:22.503 info instance system.adapter.maxcul.0 started with pid 3997
Zur Sicherheit hab ich jetzt das Setup nochmal gebootet. Nunmehr ist zwar der Status der Instanz gruen. Aber zu Objekten wird nichts mehr gesendet bzw von diesen empfangen. Das ganze steht einfach.
geändert: Code in Code-Tags; Homoran (Mod)
-
Hab nochmal was geändert und ne zeile von früher entfernt. Jetzt?
-
Wieder tot… auch nach Reboot das gleiche Bild
maxcul.0 2018-02-22 12:42:45.424 debug enable MAX! Mode of the CUL868 maxcul.0 2018-02-22 12:42:44.402 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":453,"ack":true,"ts":1519299764396,"q":0,"from":"system.adapter.maxcul.0","lc":1519299764396} maxcul.0 2018-02-22 12:42:44.399 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1519299764393,"q":0,"from":"system.adapter.maxcul.0","lc":1519208208071} maxcul.0 2018-02-22 12:42:41.460 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":true,"ack":true,"ts":1519299761449,"q":0,"from":"system.adapter.maxcul.0","lc":1519299761449} maxcul.0 2018-02-22 12:42:41.454 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.version {"val":"V 1.67 nanoCUL868","ack":true,"ts":1519299761447,"q":0,"from":"system.adapter.maxcul.0","lc":1519041256179} maxcul.0 2018-02-22 12:42:41.441 info CUL FW Version: V 1.67 nanoCUL868 maxcul.0 2018-02-22 12:42:41.437 debug incoming raw data from CUL: V 1.67 nanoCUL868 maxcul.0 2018-02-22 12:42:41.418 debug Requested CUL Version... maxcul.0 2018-02-22 12:42:41.410 debug check CUL Firmware version maxcul.0 2018-02-22 12:42:39.415 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":false,"ack":true,"ts":1519299759411,"q":0,"from":"system.adapter.maxcul.0","lc":1519299153998} maxcul.0 2018-02-22 12:42:39.404 info serialPort /dev/ttyUSB0 is open! maxcul.0 2018-02-22 12:42:39.371 info using serial device /dev/ttyUSB0@38400 maxcul.0 2018-02-22 12:42:38.789 info starting. Version 0.5.0 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0 maxcul.0 2018-02-22 12:42:38.725 info States connected to redis: 127.0.0.1:6379
Meinst Du nicht es waere einfacher den ganzen "neuen" Code wegzuwerfen und mit dem 0.3.0 einfach nochmal anzufangen?
Was fuer Aenderungen brauchen wir denn in dem Adapter unbedingt? 0.3.0 geht echt gut bei mir und auch anderen die ich kenne…
geändert: Code in Code-Tags; Homoran (Mod)
-
Was fuer Typen/Hersteller? `
eq-3 MAX! Wandthermostat….. ich bekomme meine nicht über den nanocul (bus) + maxcul ausgelesen, bzw angelernt.
Gruß
Maik `
Ich hab mir jetzt mal so ein Ding bestellt, mal sehen wie das geht wenns da ist …
Das Wandthermostat ist heute gekommen. Es kann nicht so viel, aber was es kann kann der maxcul Adapter leider nicht, naemlich dieses Kommando:
A 0C 5804 42 029D99 000000 00 A2 22 -> SetPointAndCurrentTemperature
42 - SetPointAndCurrentTemperature
029D99 - eigene Adresse
000000 - Zieladresse == Broadcast
00 - Zielraum
A2 - Aktuelle Temperatur ? hex(A2) = 162 / 8 = 20,25°C? oder 162 /10 + 4,5(festes Offset) = 20,7°C
22 - Sollwert 17°C (hex(22)/2) eingestellt
Bei mir saehe ein solches Kommando wie folgt aus:
2018-02-23 19:49:25.094 - [[34mdebug[[39m: maxcul.0 incoming raw data from CUL: Z0C07044217FAB200000000A80342M
2018-02-23 19:49:25.094 - [[34mdebug[[39m: maxcul.0 decoding Message Z0C07044217FAB200000000A80342
2018-02-23 19:49:25.095 - [[34mdebug[[39m: maxcul.0 RSSI for Message: -41
2018-02-23 19:49:25.095 - [[34mdebug[[39m: maxcul.0 received unknown command id 42
-
Wo wir gerade beim CUL sind:
Wie sieht's mit einem funktionierenden Adapter für den Cube aus?
Ich hatte mal einen über einen Github-Link installiert, aber der lies permanent meinen ioBroker abstürzen…
-
Wo wir gerade beim CUL sind:
Wie sieht's mit einem funktionierenden Adapter für den Cube aus? `
Wo ist denn da der Zusammenhang??Dies ist ein Thread zu MaxCul.
-
und der verbindet sich über einen Busware Cul zu den Max-Geräten
-
die einbindung eines Selbstbau-CUL wird gerade versucht zu implementieren.
Gruß
Rainer
-
-
Wo wir gerade beim CUL sind:
Wie sieht's mit einem funktionierenden Adapter für den Cube aus?
Ich hatte mal einen über einen Github-Link installiert, aber der lies permanent meinen ioBroker abstürzen… `
der Maxcube adapter funktioniert auf meine Pi ohne Problem. Das einzige Problem ist der Cube selbst
wenn man ihn fremd steuert. aber auch das ist gelöst mit einiger hilfe von leute aus dem Forum oder der FB Gruppe.
-
Wo wir gerade beim CUL sind:
Wie sieht's mit einem funktionierenden Adapter für den Cube aus?
Ich hatte mal einen über einen Github-Link installiert, aber der lies permanent meinen ioBroker abstürzen… `
Es gibt wohl einen ioBroker.maxcube Adapter … mehr weiss ich aber nicht.
Gff testen und neuen Thread mit genauen Fehlerinfos auf machen. "ioBroker abstützen lassen" kann ich nicht glauben
-
Meinst Du nicht es waere einfacher den ganzen "neuen" Code wegzuwerfen und mit dem 0.3.0 einfach nochmal anzufangen?
Was fuer Aenderungen brauchen wir denn in dem Adapter unbedingt? 0.3.0 geht echt gut bei mir und auch anderen die ich kenne… `
Es gibt ausser Serial Kommunikationsupdate und andere Library/Dependency-Updates keinerlei Änderungen. Ich hab jetzt den Kommunikationscode von 0.3.0 wiederhergestellt in der 0.5.0. Bitte nochmal versuchen.
Wenn es immer noch nicht tut muss ich noch mehr reverten …
Das Problem daran alles wieder zurückzustellen ist das wir im Notfall an einem Punkt landen wo wir keine Updates mehr machen können. Das wäre schlecht.
-
A 0C 5804 42 029D99 000000 00 A2 22 -> SetPointAndCurrentTemperature
42 - SetPointAndCurrentTemperature
029D99 - eigene Adresse
000000 - Zieladresse == Broadcast
00 - Zielraum
A2 - Aktuelle Temperatur ? hex(A2) = 162 / 8 = 20,25°C? oder 162 /10 + 4,5(festes Offset) = 20,7°C
22 - Sollwert 17°C (hex(22)/2) eingestellt
Bei mir saehe ein solches Kommando wie folgt aus:
2018-02-23 19:49:25.094 - [[34mdebug[[39m: maxcul.0 incoming raw data from CUL: Z0C07044217FAB200000000A80342M
2018-02-23 19:49:25.094 - [[34mdebug[[39m: maxcul.0 decoding Message Z0C07044217FAB200000000A80342
2018-02-23 19:49:25.095 - [[34mdebug[[39m: maxcul.0 RSSI for Message: -41
2018-02-23 19:49:25.095 - [[34mdebug[[39m: maxcul.0 received unknown command id 42 `
Also ich habe Code gefunden der das implementieren würde … aber bevor nicht die kommunikation nicht sauber läuft mach ich gar nix. `
-
Meinst Du nicht es waere einfacher den ganzen "neuen" Code wegzuwerfen und mit dem 0.3.0 einfach nochmal anzufangen?
Was fuer Aenderungen brauchen wir denn in dem Adapter unbedingt? 0.3.0 geht echt gut bei mir und auch anderen die ich kenne… `
Es gibt ausser Serial Kommunikationsupdate und andere Library/Dependency-Updates keinerlei Änderungen. Ich hab jetzt den Kommunikationscode von 0.3.0 wiederhergestellt in der 0.5.0. Bitte nochmal versuchen.
Wenn es immer noch nicht tut muss ich noch mehr reverten …
Das Problem daran alles wieder zurückzustellen ist das wir im Notfall an einem Punkt landen wo wir keine Updates mehr machen können. Das wäre schlecht. `
gab noch einen Fehler. Aber ab jetzt (0:42 Uhr) bitte nochmal versuchen.PS: DIe kommunikation war in der 0.3.0 auf "serialport 3.0". Das ist offiziell nur bis nodejs 4 unterstützt. Ich habe es jetzt auf "Serialport 4", wodurch grundsätzlich bis nodejs 8.x unterstützt ist.
-
Es tut mir leid, aber:
maxcul.0 2018-02-24 01:25:43.593 debug enable MAX! Mode of the CUL868 maxcul.0 2018-02-24 01:25:42.593 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":453,"ack":true,"ts":1519431942588,"q":0,"from":"system.adapter.maxcul.0","lc":1519431942588} maxcul.0 2018-02-24 01:25:42.591 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1519431942585,"q":0,"from":"system.adapter.maxcul.0","lc":1519431770879} maxcul.0 2018-02-24 01:25:39.631 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":true,"ack":true,"ts":1519431939624,"q":0,"from":"system.adapter.maxcul.0","lc":1519431939624} maxcul.0 2018-02-24 01:25:39.629 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.version {"val":"V 1.67 nanoCUL868","ack":true,"ts":1519431939622,"q":0,"from":"system.adapter.maxcul.0","lc":1519041256179} maxcul.0 2018-02-24 01:25:39.614 info CUL FW Version: V 1.67 nanoCUL868 maxcul.0 2018-02-24 01:25:39.611 debug incoming raw data from CUL: V 1.67 nanoCUL868 maxcul.0 2018-02-24 01:25:39.589 debug Requested CUL Version... maxcul.0 2018-02-24 01:25:39.581 debug check CUL Firmware version maxcul.0 2018-02-24 01:25:37.585 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":false,"ack":true,"ts":1519431937582,"q":0,"from":"system.adapter.maxcul.0","lc":1519431809659} maxcul.0 2018-02-24 01:25:37.575 info serialPort /dev/ttyUSB0 is open! maxcul.0 2018-02-24 01:25:37.554 info using serial device /dev/ttyUSB0@38400 maxcul.0 2018-02-24 01:25:37.025 info starting. Version 0.5.0 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0 maxcul.0 2018-02-24 01:25:36.967 info States connected to redis: 127.0.0.1:6379 maxcul.0 2018-02-24 01:25:36.955 debug statesDB connected maxcul.0 2018-02-24 01:25:36.903 debug objectDB connected host.ioBroker-Pi 2018-02-24 01:25:35.225 info instance system.adapter.maxcul.0 started with pid 25975 host.ioBroker-Pi 2018-02-24 01:25:35.171 info object change system.adapter.maxcul.0
und steht …
Auch nach einem Reset das gleiche Bild. Nach dem "enable MAX mode" ists aus ...
geändert: Code in Code-Tags; Homoran (Mod)
-
ich kapiere es nicht … Ich hab nochmal Debug eingebaut. Bitte schick nochmal log.
Ansonsten muss ich wirklich auf serialport 3 zurück und verlieren damit halt node8 support ...
-
Ok, da geht mehr. Das hat es bisher noch nie getan. Hast Du ausser dem Debug noch was geaendert?
Ich bin erst morgen wieder zum Testen in der Lage, Du kannst noch ueberlegen
maxcul.0 2018-02-24 12:58:17.516 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":383,"ack":true,"ts":1519473497506,"q":0,"from":"system.adapter.maxcul.0","lc":1519473497506} maxcul.0 2018-02-24 12:58:12.494 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":378,"ack":true,"ts":1519473492488,"q":0,"from":"system.adapter.maxcul.0","lc":1519473492488} maxcul.0 2018-02-24 12:58:07.858 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":374,"ack":true,"ts":1519473487853,"q":0,"from":"system.adapter.maxcul.0","lc":1519473487853} maxcul.0 2018-02-24 12:58:07.840 debug got OK-ACK Packet from 16fb8f maxcul.0 2018-02-24 12:58:07.840 debug RSSI for Message: -40.5 maxcul.0 2018-02-24 12:58:07.839 debug decoding Message Z0E01020216FB8F123456000139643443 maxcul.0 2018-02-24 12:58:07.839 debug incoming raw data from CUL: Z0E01020216FB8F123456000139643443 maxcul.0 2018-02-24 12:58:06.739 debug serial port buffer have been drained maxcul.0 2018-02-24 12:58:06.723 debug Send Packet to CUL: 0b01004012345616fb8f0074, awaiting drain event maxcul.0 2018-02-24 12:58:06.701 debug sendTemperature(maxcul.0.NKF0003406, 26, 1) maxcul.0 2018-02-24 12:58:05.686 debug redis pmessage io.maxcul.0.* io.maxcul.0.NKF0003406.desiredTemperature {"val":26,"ack":false,"ts":1519473485684,"q":0,"from":"system.adapter.admin.0","lc":1519473485684} maxcul.0 2018-02-24 12:58:02.494 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":478,"ack":true,"ts":1519473482490,"q":0,"from":"system.adapter.maxcul.0","lc":1519473482490} maxcul.0 2018-02-24 12:57:57.507 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":473,"ack":true,"ts":1519473477499,"q":0,"from":"system.adapter.maxcul.0","lc":1519473477499} maxcul.0 2018-02-24 12:57:52.480 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":468,"ack":true,"ts":1519473472478,"q":0,"from":"system.adapter.maxcul.0","lc":1519473472478} maxcul.0 2018-02-24 12:57:47.478 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":463,"ack":true,"ts":1519473467475,"q":0,"from":"system.adapter.maxcul.0","lc":1519473467475} maxcul.0 2018-02-24 12:57:42.476 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":458,"ack":true,"ts":1519473462474,"q":0,"from":"system.adapter.maxcul.0","lc":1519473462474} maxcul.0 2018-02-24 12:57:38.502 debug Za drained maxcul.0 2018-02-24 12:57:38.496 debug Za written maxcul.0 2018-02-24 12:57:38.492 debug Zr drained maxcul.0 2018-02-24 12:57:38.488 debug Zr written maxcul.0 2018-02-24 12:57:38.485 debug X20 drained maxcul.0 2018-02-24 12:57:38.481 debug X20 written maxcul.0 2018-02-24 12:57:38.477 debug enable MAX! Mode of the CUL868 maxcul.0 2018-02-24 12:57:37.484 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":453,"ack":true,"ts":1519473457478,"q":0,"from":"system.adapter.maxcul.0","lc":1519473457478} maxcul.0 2018-02-24 12:57:37.482 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1519473457475,"q":0,"from":"system.adapter.maxcul.0","lc":1519464560648} maxcul.0 2018-02-24 12:57:34.510 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":true,"ack":true,"ts":1519473454502,"q":0,"from":"system.adapter.maxcul.0","lc":1519473454502} maxcul.0 2018-02-24 12:57:34.508 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.version {"val":"V 1.67 nanoCUL868","ack":true,"ts":1519473454500,"q":0,"from":"system.adapter.maxcul.0","lc":1519041256179} maxcul.0 2018-02-24 12:57:34.492 info CUL FW Version: V 1.67 nanoCUL868 maxcul.0 2018-02-24 12:57:34.489 debug incoming raw data from CUL: V 1.67 nanoCUL868 maxcul.0 2018-02-24 12:57:34.473 debug Requested CUL Version... maxcul.0 2018-02-24 12:57:34.465 debug check CUL Firmware version maxcul.0 2018-02-24 12:57:32.470 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":false,"ack":true,"ts":1519473452466,"q":0,"from":"system.adapter.maxcul.0","lc":1519473339719} maxcul.0 2018-02-24 12:57:32.458 info serialPort /dev/ttyUSB0 is open! maxcul.0 2018-02-24 12:57:32.438 info using serial device /dev/ttyUSB0@38400 maxcul.0 2018-02-24 12:57:31.923 info starting. Version 0.5.0 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0 maxcul.0 2018-02-24 12:57:31.862 info States connected to redis: 127.0.0.1:6379 maxcul.0 2018-02-24 12:57:31.850 debug statesDB connected maxcul.0 2018-02-24 12:57:31.796 debug objectDB connected
Nachtrag Thema Wandthermostat:
Abgesehen von dem Kommando 42 habe ich noch nicht verstanden wie man dieses Thermostat mit dem Broker pairt. Mir scheint naemlich diese Broadcasts an "000000" bringen die in der Naehe befindlichen Heizungsthermostate durcheinander, die versuchen dann dieser Anweisung zu folgen und nicht den Broker-Einstellungen…
geändert: Code in Code-Tags; Homoran (Mod)
-
Jetzt ist was passiert, das hatten wir noch nie:
host.ioBroker-Pi 2018-02-24 13:02:36.028 error instance system.adapter.maxcul.0 terminated with code 0 (OK) host.ioBroker-Pi 2018-02-24 13:02:36.028 error Caught by controller[0]: at FSReqWrap.wrapper [as oncomplete] (fs.js:683:17) host.ioBroker-Pi 2018-02-24 13:02:36.028 error Caught by controller[0]: at SerialPort. (/opt/iobroker/node_modules/serialport/lib/serialport.js:306:7) host.ioBroker-Pi 2018-02-24 13:02:36.027 error Caught by controller[0]: at SerialPort. (/opt/iobroker/node_modules/serialport/lib/serialport.js:293:14) host.ioBroker-Pi 2018-02-24 13:02:36.027 error Caught by controller[0]: at SerialPort._emitData (/opt/iobroker/node_modules/serialport/lib/serialport.js:313:18) host.ioBroker-Pi 2018-02-24 13:02:36.027 error Caught by controller[0]: at SerialPort. (/opt/iobroker/node_modules/serialport/lib/parsers.js:23:13) host.ioBroker-Pi 2018-02-24 13:02:36.026 error Caught by controller[0]: at Array.forEach (native) host.ioBroker-Pi 2018-02-24 13:02:36.025 error Caught by controller[0]: at /opt/iobroker/node_modules/serialport/lib/parsers.js:24:17 host.ioBroker-Pi 2018-02-24 13:02:36.025 error Caught by controller[0]: at SerialPort.emit (events.js:188:7) host.ioBroker-Pi 2018-02-24 13:02:36.025 error Caught by controller[0]: at emitOne (events.js:96:13) host.ioBroker-Pi 2018-02-24 13:02:36.025 error Caught by controller[0]: at SerialPort. (/opt/iobroker/node_modules/iobroker.maxcul/lib/communication-layer.js:93:42) host.ioBroker-Pi 2018-02-24 13:02:36.024 error Caught by controller[0]: at CommunicationServiceLayer.emit (events.js:188:7) host.ioBroker-Pi 2018-02-24 13:02:36.024 error Caught by controller[0]: at emitOne (events.js:96:13) host.ioBroker-Pi 2018-02-24 13:02:36.024 error Caught by controller[0]: at CommunicationServiceLayer. (/opt/iobroker/node_modules/iobroker.maxcul/lib/maxcul.js:46:34) host.ioBroker-Pi 2018-02-24 13:02:36.024 error Caught by controller[0]: at MaxDriver.handleIncommingMessage (/opt/iobroker/node_modules/iobroker.maxcul/lib/maxcul.js:151:57) host.ioBroker-Pi 2018-02-24 13:02:36.024 error Caught by controller[0]: at MaxDriver.ThermostatState (/opt/iobroker/node_modules/iobroker.maxcul/lib/maxcul.js:486:38) host.ioBroker-Pi 2018-02-24 13:02:36.023 error Caught by controller[0]: TypeError: rawBitData.getRange is not a function maxcul.0 2018-02-24 13:02:35.969 error TypeError: rawBitData.getRange is not a function at MaxDriver.ThermostatState (/opt/iobroker/node_modules/iobroker.maxcul/lib/maxcul.js:486:38) at MaxDriver.handleIncommingMessage (/opt/iobrok maxcul.0 2018-02-24 13:02:35.969 error uncaught exception: rawBitData.getRange is not a function maxcul.0 2018-02-24 13:02:35.968 debug got data from heatingelement 16fbae with payload 39002D00FB maxcul.0 2018-02-24 13:02:35.967 debug RSSI for Message: -80 maxcul.0 2018-02-24 13:02:35.967 debug decoding Message Z0F00046016FBAE0000000039002D00FBF4 maxcul.0 2018-02-24 13:02:35.966 debug incoming raw data from CUL: Z0F00046016FBAE0000000039002D00FBF4
geändert: Code in Code-Tags; Homoran (Mod)
-
Ok, da geht mehr. Das hat es bisher noch nie getan. Hast Du ausser dem Debug noch was geaendert?
Ich bin erst morgen wieder zum Testen in der Lage, Du kannst noch ueberlegen
`
Ja ich habe noch ein was geändert: Es wird jetzt bei der Initialisierung nach jedem senden einer Nachricht gewartet das die auch wirklich gesendet wurde (draining). Das war vorher nicht so. Da wurde einfach alles direkt nacheinander gesendet.
Jetzt ist was passiert, das hatten wir noch nie: `
Da ist scheinbar ein Bug im Code der eine Funktion aufruft die es nicht gibt. Habe bei der "Quelle" (ja habe inzwischen gefunden wo die Logik herkommt und könnte daher auch auf die aktuellste Version updaten) nachgesehen und fix ist auf Github.Bitte versuchen und mal laufen lassen. Wenn das erstmal wieder so tut wie in der 0.3.0 dann machen wir es erstmal so live.
Dann kann ich in einer 0.6 mal die Logik aktualisieren auf den aktuellen Stand (Kommunikation nicht anfassen) und wir sehen was da so geht