Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WallThermostat zeigt falschen Wert #30

Closed
guergen1 opened this issue Aug 25, 2019 · 68 comments
Closed

WallThermostat zeigt falschen Wert #30

guergen1 opened this issue Aug 25, 2019 · 68 comments

Comments

@guergen1
Copy link

guergen1 commented Aug 25, 2019

Hallo,
nachdem der WallThermostat jetzt im Broker eingelesen wurde nd auch eine Zeit lang funktioniert hat, zeigt er jetzt die falsche measuredTemperatur an.
grafik
Im Log scheint aber die richtige anzukommen:
grafik

Auch wenn ich ihn neu einlese, bekommt er den falschen Wert!

@bowao
Copy link
Contributor

bowao commented Aug 25, 2019

Ich denke ich hab das Problem gefunden.
Aber da ich, wie bereits gesagt diese Geräte nicht besitze, würde ich das gerne, bevor ich den pullrequest mache mal mit dir testen.

@guergen1
Copy link
Author

OK, bin allerdings grade nicht daheim…
Müssen wir mal einen Termin machen; oder du sendest mir die zu ändernden Zeilen… Ich denke das bekomme ich hin!

@bowao
Copy link
Contributor

bowao commented Aug 25, 2019

OK. Das Problem ist wieder in Datei maxcul.js. Also auf den raspi verbinden,
ins Verzeichnis /opt/iobroker/node_modules/iobroker.maxcul/lib
und dort wieder:
sudo nano maxcul.js
ausführen.

Wenn sich der Editor geöffnet hat, wieder die escape-taste drücken und danach 'c', damit wird die courser-position (Zeile / Spalte usw.) immer im untere Bildschirmbereich eingeblendet.
Dann wieder 'STRG' und 'w' gleichzeitig. (Suchfeld).
Da trägst du folgendes ein 'desired :' (ohne Anführungszeichen)
Dann auf return.
Dann bist du bei dem ersten Eintrag der geändert werden muss. Zeile 779

Hier bitte das Wort 'desired' nur vor dem Doppelpunkt in 'desiredTemperature' ändern.
In der nächsten Zeile (780) das Wort 'measured' nur vor dem Doppelpunkt in 'measuredTemperature' ändern.

ALT:

                desired : desired,
                measured : measured,

NEU:

                desiredTemperature : desired,
                measuredTemperature : measured,

Speichern und Adapter neustarten.

Da sind noch ein paar andere Schnitzer drin, aber das ist erstmal das wichtigste.

@bowao
Copy link
Contributor

bowao commented Aug 25, 2019

Achja, wenn du schon dabei bist, kannst du mir bitte aus dem debug-log noch die Einträge 'incoming raw data from CUL: ...' posten? Und zwar immer kurz bevor jeweils ein 'WallThermostatControllReceived: ...' und wenn ein 'WallThermostateStateReceived: ...' in den debug-logs auftaucht. Mich würde interressieren wie die rohdaten aussehen und welche informationen da evtl. noch drinstecken, die man verwerten kann. Ein oder zwei Datensätze sollten erstmal ausreichen.

@StenmannsAr
Copy link
Contributor

Hi bowao,
dein fix funktioniert, wenn man den "heaterTemperature" Wert in der größe anpasst. Als ich das ganze damals implementiert habe war das immer so schön kalt, dass das nie aufgefallen ist :-)
Ich habe deine Änderung mit im push #31 eingebaut damit ich den ganze fix testen konnte. Ich hoffe du bist mir nicht böse.

@bowao
Copy link
Contributor

bowao commented Aug 25, 2019

Hi StenmannsAR,

kein Problem, besser es kümmern sich zwei als keiner.
Und ich kann das ja leider, mangels Hardware, nicht final testen.

Ich hab da noch ein paar Kleinigkeiten bei 'MaxDriver.prototype.WallThermostatState' in der maxcul.js gesehen, vielleicht kannst du das direkt in den pullrequest einbauen.

Hier mal der diff:

@@ -750,10 +750,10 @@ module.exports = function (env) {
                 desiredTemperature : rawData.desiredRaw / 2.0,
                 measuredTemperature : rawData.heaterTemperature / 10.0,
                 dstSetting : rawBitData.get(3),
-                langateway : rawBitData.get(4),
+                lanGateway : rawBitData.get(4),
                 panel : rawBitData.get(5),
-                rferror : rawBitData.get(6),
-                batterylow : rawBitData.get(7),
+                rfError : rawBitData.get(6),
+                batteryLow : rawBitData.get(7),
               }
               return this.emit('WallThermostatStateReceived',WallthermostatState);
             } else {

Hatte im Screenshot von guergen1 gesehen das die Datenpunkte rfError und batteryLow auch keine Werte enthalten.

@StenmannsAr
Copy link
Contributor

StenmannsAr commented Aug 25, 2019

Baue ich ein und werde es testen. Sehe ich ähnlich hauptsache es geht voran.

Update:
Bei mir aktualisert er dann garkeine Werte mehr. Das muss ich mir morgen einmal genauer anschauen. Ich lasse den Pull Request erst einmal so.

@guergen1
Copy link
Author

So, die Temperatur hat er jetzt passend eingelesen, auf den Befehl batteryLow und rfError zu aktualisieren warte ich noch

@guergen1
Copy link
Author

Hier die Log-Einträge.... aber ein StateReceived kommt nicht, nur das Control.
Und rfError undbatteryLow war auch noch nicht dabei:

maxcul.0 2019-08-26 16:12:56.414 debug WallThermostatControlReceived: {"src":"079550","desiredTemperature":17,"measuredTemperature":26.3}
maxcul.0 2019-08-26 16:12:56.414 debug got data from wallthermostat 079550 desired temp: 17 - measured temp: 26.3
maxcul.0 2019-08-26 16:12:56.414 debug RSSI for Message: -40.5
maxcul.0 2019-08-26 16:12:56.414 debug decoding Message Z0C7C044207955000000000A20743
maxcul.0 2019-08-26 16:12:56.413 debug incoming raw data from CUL: Z0C7C044207955000000000A20743
maxcul.0 2019-08-26 16:12:53.023 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 900)

@guergen1
Copy link
Author

guergen1 commented Aug 26, 2019

Habe garde mal dem Thermostat eine neue week-Temp gesendet, dann hat er kurz die 25 vor 25.8°C vergessen. ist aber mit der nächste Contorl Ceceived wieder auf die richtige gegangen. Hier das log vom umstellen der Temperatur: und dann kan doch ein State....
Zuerst habe ich die anzuzeigende Temperatur auf "aus" und wieder zurück gestellt. daher sende ich hier mal eine lange Log-Datei:

maxcul.0 2019-08-26 16:27:45.792 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 227)
maxcul.0 2019-08-26 16:27:45.789 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:27:45.787 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:27:45.786 debug delayed next send by 2000ms (Queue length left = 1, Current Credit = 345)
maxcul.0 2019-08-26 16:27:44.863 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 16:27:44.863 debug RSSI for Message: -40
maxcul.0 2019-08-26 16:27:44.863 debug decoding Message Z0E010202079550123456000118001E44
maxcul.0 2019-08-26 16:27:44.862 debug incoming raw data from CUL: Z0E010202079550123456000118001E44
maxcul.0 2019-08-26 16:27:43.784 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:27:43.784 debug Send Packet to CUL: Zs170100101234560795500012452045204520452045204520, awaiting drain event
maxcul.0 2019-08-26 16:27:43.783 debug delayed next send by 0ms (Queue length left = 1, Current Credit = 345)
maxcul.0 2019-08-26 16:27:43.782 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:27:43.780 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:27:43.779 debug delayed next send by 2000ms (Queue length left = 2, Current Credit = 461)
maxcul.0 2019-08-26 16:27:43.481 debug Ignore command because already in queue X
maxcul.0 2019-08-26 16:27:42.848 debug Queued send for Zs170100101234560795500012452045204520452045204520 (Queue length = 2)
maxcul.0 2019-08-26 16:27:42.848 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 16:27:42.848 debug RSSI for Message: -40
maxcul.0 2019-08-26 16:27:42.848 debug decoding Message Z0E010202079550123456000118002244
maxcul.0 2019-08-26 16:27:42.847 debug incoming raw data from CUL: Z0E010202079550123456000118002244
maxcul.0 2019-08-26 16:27:41.778 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:27:41.777 debug Send Packet to CUL: Zs1901001012345607955000023d203d203d203d203d203d203d20, awaiting drain event
maxcul.0 2019-08-26 16:27:38.484 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 461)
.... hier habe ich einige Zeilen gelöscht
Current Credit = 551)
maxcul.0 2019-08-26 16:27:21.849 debug WallThermostatStateReceived: {"src":"079550","mode":"0","desiredTemperature":17,"measuredTemperature":0.8,"dstSetting":1,"lanGateway":1,"panel":0,"rfError":0,"batteryLow":0}
maxcul.0 2019-08-26 16:27:21.849 debug got data from wallthermostat state 079550 with payload 1800220108
maxcul.0 2019-08-26 16:27:21.849 debug RSSI for Message: -40
maxcul.0 2019-08-26 16:27:21.849 debug decoding Message Z0F5C047007955000000000180022010844
maxcul.0 2019-08-26 16:27:21.849 debug incoming raw data from CUL: Z0F5C047007955000000000180022010844
maxcul.0 2019-08-26 16:27:21.012 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 16:27:21.012 debug RSSI for Message: -40
maxcul.0 2019-08-26 16:27:21.012 debug decoding Message Z0E010202079550123456000118002244
maxcul.0 2019-08-26 16:27:21.011 debug incoming raw data from CUL: Z0E010202079550123456000118002244
maxcul.0 2019-08-26 16:27:19.944 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:27:19.943 debug Send Packet to CUL: Zs0b0104821234560795500000, awaiting drain event
maxcul.0 2019-08-26 16:27:19.942 debug sendSetDisplayActualTemperature(maxcul.0.KEQ0062305, false)
maxcul.0 2019-08-26 16:27:18.482 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 551)

...hier fehlen auch Zeilen

Current Credit = 541)
maxcul.0 | 2019-08-26 16:27:08.473 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:27:08.470 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:27:04.165 | debug | WallThermostatControlReceived: {"src":"079550","desiredTemperature":17,"measuredTemperature":26.4}
maxcul.0 | 2019-08-26 16:27:04.165 | debug | got data from wallthermostat 079550 desired temp: 17 - measured temp: 26.4
maxcul.0 | 2019-08-26 16:27:04.165 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:27:04.165 | debug | decoding Message Z0C81044207955000000000A20844
maxcul.0 | 2019-08-26 16:27:04.164 | debug | incoming raw data from CUL: Z0C81044207955000000000A20844
maxcul.0 | 2019-08-26 16:27:03.470 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 536)
maxcul.0 | 2019-08-26 16:27:03.469 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:27:03.467 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:27:03.340 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 536)
maxcul.0 | 2019-08-26 16:27:03.339 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:27:03.337 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:27:03.336 | debug | delayed next send by 2000ms (Queue length left = 1, Current Credit = 641)
maxcul.0 | 2019-08-26 16:27:02.404 | debug | got OK-ACK Packet from 079550
maxcul.0 | 2019-08-26 16:27:02.404 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:27:02.403 | debug | decoding Message Z0E010202079550123456000118002244
maxcul.0 | 2019-08-26 16:27:02.402 | debug | incoming raw data from CUL: Z0E010202079550123456000118002244
maxcul.0 | 2019-08-26 16:27:01.335 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:27:01.335 | debug | Send Packet to CUL: Zs0b0104821234560795500000, awaiting drain event
maxcul.0 | 2019-08-26 16:27:01.334 | debug | sendSetDisplayActualTemperature(maxcul.0.KEQ0062305, false)
maxcul.0 | 2019-08-26 16:26:58.470 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 636)

... hier fehlen auch Wartezeiten

Current Credit = 684)
maxcul.0 | 2019-08-26 16:25:49.550 | debug | got OK-ACK Packet from 079550
maxcul.0 | 2019-08-26 16:25:49.550 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:25:49.550 | debug | decoding Message Z0E010202079550123456000118042244
maxcul.0 | 2019-08-26 16:25:49.549 | debug | incoming raw data from CUL: Z0E010202079550123456000118042244
maxcul.0 | 2019-08-26 16:25:48.480 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:48.478 | debug | Send Packet to CUL: Zs0f01040312345607955000131a109930, awaiting drain event
maxcul.0 | 2019-08-26 16:25:48.433 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 684)
maxcul.0 | 2019-08-26 16:25:48.431 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:48.431 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:25:48.431 | debug | Updating time information for deviceId 079550
maxcul.0 | 2019-08-26 16:25:48.431 | info | deviceRequestTimeInformation: "079550"
maxcul.0 | 2019-08-26 16:25:48.431 | debug | got time information request from device 079550
maxcul.0 | 2019-08-26 16:25:48.431 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:25:48.431 | debug | decoding Message Z0F5B050307955012345600131A10992E44
maxcul.0 | 2019-08-26 16:25:48.431 | debug | incoming raw data from CUL: Z0F5B050307955012345600131A10992E44
maxcul.0 | 2019-08-26 16:25:45.485 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 681)
maxcul.0 | 2019-08-26 16:25:45.485 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:45.482 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:25:45.480 | debug | delayed next send by 2000ms (Queue length left = 1, Current Credit = 792)
maxcul.0 | 2019-08-26 16:25:44.550 | debug | got OK-ACK Packet from 079550
maxcul.0 | 2019-08-26 16:25:44.550 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:25:44.550 | debug | decoding Message Z0E010202079550123456000118042244
maxcul.0 | 2019-08-26 16:25:44.549 | debug | incoming raw data from CUL: Z0E010202079550123456000118042244
maxcul.0 | 2019-08-26 16:25:43.479 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:43.478 | debug | Send Packet to CUL: Zs0f01040312345607955000131a10992b, awaiting drain event
maxcul.0 | 2019-08-26 16:25:43.433 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 792)
maxcul.0 | 2019-08-26 16:25:43.430 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:43.430 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:25:43.430 | debug | Updating time information for deviceId 079550
maxcul.0 | 2019-08-26 16:25:43.430 | info | deviceRequestTimeInformation: "079550"
maxcul.0 | 2019-08-26 16:25:43.430 | debug | got time information request from device 079550
maxcul.0 | 2019-08-26 16:25:43.430 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:25:43.430 | debug | decoding Message Z0F5A050307955012345600131A10992944
maxcul.0 | 2019-08-26 16:25:43.430 | debug | incoming raw data from CUL: Z0F5A050307955012345600131A10992944
maxcul.0 | 2019-08-26 16:25:40.483 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 789)
maxcul.0 | 2019-08-26 16:25:40.482 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:40.480 | debug | Send Packet to CUL: X, awaiting drain event
maxcul.0 | 2019-08-26 16:25:40.479 | debug | delayed next send by 2000ms (Queue length left = 1, Current Credit = 900)
maxcul.0 | 2019-08-26 16:25:39.553 | debug | got OK-ACK Packet from 079550
maxcul.0 | 2019-08-26 16:25:39.553 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:25:39.553 | debug | decoding Message Z0E010202079550123456000118042244
maxcul.0 | 2019-08-26 16:25:39.553 | debug | incoming raw data from CUL: Z0E010202079550123456000118042244
maxcul.0 | 2019-08-26 16:25:38.477 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:38.476 | debug | Send Packet to CUL: Zs0f01040312345607955000131a109926, awaiting drain event
maxcul.0 | 2019-08-26 16:25:38.445 | debug | delayed next send by 0ms (Queue length left = 0, Current Credit = 900)
maxcul.0 | 2019-08-26 16:25:38.445 | debug | serial port buffer have been drained
maxcul.0 | 2019-08-26 16:25:38.445 | debug | Updating time information for deviceId 079550
maxcul.0 | 2019-08-26 16:25:38.445 | info | deviceRequestTimeInformation: "079550"
maxcul.0 | 2019-08-26 16:25:38.445 | debug | got time information request from device 079550
maxcul.0 | 2019-08-26 16:25:38.445 | debug | RSSI for Message: -40
maxcul.0 | 2019-08-26 16:25:38.445 | debug | decoding Message Z0F59050307955012345600131A10992444
maxcul.0 | 2019-08-26 16:25:38.444 | debug | incoming raw data from CUL: Z0F59050307955012345600131A10992444

@guergen1
Copy link
Author

Die mesuredTemp hat sich wieder verändert:
grafik

maxcul.0 2019-08-26 16:42:33.950 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:42:28.951 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 553)
maxcul.0 2019-08-26 16:42:28.950 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:42:28.949 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:42:23.955 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 548)
maxcul.0 2019-08-26 16:42:23.954 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:42:23.947 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:42:22.745 debug WallThermostatStateReceived: {"src":"079550","mode":"0","desiredTemperature":18,"measuredTemperature":0.8,"dstSetting":1,"lanGateway":1,"panel":0,"rfError":0,"batteryLow":0}
maxcul.0 2019-08-26 16:42:22.745 debug got data from wallthermostat state 079550 with payload 1800240108
maxcul.0 2019-08-26 16:42:22.744 debug RSSI for Message: -40
maxcul.0 2019-08-26 16:42:22.744 debug decoding Message Z0F61047007955000000000180024010844
maxcul.0 2019-08-26 16:42:22.744 debug incoming raw data from CUL: Z0F61047007955000000000180024010844
maxcul.0 2019-08-26 16:42:18.948 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 543)

Und hat sich hier wieder richtig eingetragen:

maxcul.0 2019-08-26 16:44:39.029 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:44:34.025 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 673)
maxcul.0 2019-08-26 16:44:34.024 debug serial port buffer have been drained
maxcul.0 2019-08-26 16:44:34.023 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 16:44:30.914 debug WallThermostatControlReceived: {"src":"079550","desiredTemperature":18,"measuredTemperature":26.3}
maxcul.0 2019-08-26 16:44:30.914 debug got data from wallthermostat 079550 desired temp: 18 - measured temp: 26.3
maxcul.0 2019-08-26 16:44:30.914 debug RSSI for Message: -40
maxcul.0 2019-08-26 16:44:30.913 debug decoding Message Z0C87044207955000000000A40744
maxcul.0 2019-08-26 16:44:30.913 debug incoming raw data from CUL: Z0C87044207955000000000A40744
maxcul.0 2019-08-26 16:44:29.024 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 673)
maxcul.0 2019-08-26 16:44:29.023 debug serial port buffer have been drained

@guergen1
Copy link
Author

guergen1 commented Aug 26, 2019

habe grade mal in Zeile 750++ nach der batteryLow,-Zeile noch ein rssi: packet.rssi eingefügt
Aber ohjne komma am Ende, da ich glaube dass da keins hin darf, da die geschweifte Klammer ja zu geht-... bin aber kein Fachmann was java angeht....
Ich lasse das mal so laufen, bin in einer halben Stunde wieder da

@StenmannsAr
Copy link
Contributor

Hallo,

bitte auch die Zeile 741 ändern:
payloadParser = new BinaryParser().uint8('bits').uint8('displaymode').uint8('desiredRaw').uint16('heaterTemperature')

@guergen1
Copy link
Author

Hier jetzt das aktuelle Schnipsel:

maxcul.0 2019-08-26 17:25:51.783 debug got data from shutter contact 025882 10010
maxcul.0 2019-08-26 17:25:51.783 debug RSSI for Message: -54
maxcul.0 2019-08-26 17:25:51.783 debug decoding Message Z0B360630025882123456001228
maxcul.0 2019-08-26 17:25:51.783 debug incoming raw data from CUL: Z0B360630025882123456001228
maxcul.0 2019-08-26 17:25:51.783 debug ignored auto-ack packet
maxcul.0 2019-08-26 17:25:51.783 debug RSSI for Message: -74
maxcul.0 2019-08-26 17:25:51.783 debug decoding Message Z0B360002123456025882000000
maxcul.0 2019-08-26 17:25:51.783 debug incoming raw data from CUL: Z0B360002123456025882000000
maxcul.0 2019-08-26 17:25:51.691 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 573)
maxcul.0 2019-08-26 17:25:51.691 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:51.689 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:25:51.688 debug delayed next send by 2000ms (Queue length left = 1, Current Credit = 683)
maxcul.0 2019-08-26 17:25:50.760 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 17:25:50.760 debug RSSI for Message: -39.5
maxcul.0 2019-08-26 17:25:50.760 debug decoding Message Z0E010202079550123456000118002445
maxcul.0 2019-08-26 17:25:50.759 debug incoming raw data from CUL: Z0E010202079550123456000118002445
maxcul.0 2019-08-26 17:25:49.686 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:49.686 debug Send Packet to CUL: Zs0f01040312345607955000131a119931, awaiting drain event
maxcul.0 2019-08-26 17:25:49.686 debug Updating time information for deviceId 079550
maxcul.0 2019-08-26 17:25:49.686 info deviceRequestTimeInformation: "079550"
maxcul.0 2019-08-26 17:25:49.686 debug got time information request from device 079550
maxcul.0 2019-08-26 17:25:49.686 debug RSSI for Message: -40.5
maxcul.0 2019-08-26 17:25:49.686 debug decoding Message Z0F72050307955012345600131A11992F43
maxcul.0 2019-08-26 17:25:49.686 debug incoming raw data from CUL: Z0F72050307955012345600131A11992F43
maxcul.0 2019-08-26 17:25:48.366 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 683)
maxcul.0 2019-08-26 17:25:48.365 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:48.363 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:25:46.688 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 681)
maxcul.0 2019-08-26 17:25:46.688 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:46.686 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:25:46.685 debug delayed next send by 2000ms (Queue length left = 1, Current Credit = 791)
maxcul.0 2019-08-26 17:25:45.758 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 17:25:45.758 debug RSSI for Message: -40.5
maxcul.0 2019-08-26 17:25:45.757 debug decoding Message Z0E010202079550123456000118002443
maxcul.0 2019-08-26 17:25:45.757 debug incoming raw data from CUL: Z0E010202079550123456000118002443
maxcul.0 2019-08-26 17:25:44.684 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:44.684 debug Send Packet to CUL: Zs0f01040312345607955000131a11992c, awaiting drain event
maxcul.0 2019-08-26 17:25:44.684 debug Updating time information for deviceId 079550
maxcul.0 2019-08-26 17:25:44.684 info deviceRequestTimeInformation: "079550"
maxcul.0 2019-08-26 17:25:44.684 debug got time information request from device 079550
maxcul.0 2019-08-26 17:25:44.684 debug RSSI for Message: -39.5
maxcul.0 2019-08-26 17:25:44.684 debug decoding Message Z0F71050307955012345600131A11992A45
maxcul.0 2019-08-26 17:25:44.684 debug incoming raw data from CUL: Z0F71050307955012345600131A11992A45
maxcul.0 2019-08-26 17:25:43.366 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 791)
maxcul.0 2019-08-26 17:25:43.364 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:43.363 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:25:41.718 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 789)
maxcul.0 2019-08-26 17:25:41.716 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:41.715 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:25:41.714 debug delayed next send by 2000ms (Queue length left = 1, Current Credit = 900)
maxcul.0 2019-08-26 17:25:40.802 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 17:25:40.802 debug RSSI for Message: -39.5
maxcul.0 2019-08-26 17:25:40.802 debug decoding Message Z0E010202079550123456000118002445
maxcul.0 2019-08-26 17:25:40.802 debug incoming raw data from CUL: Z0E010202079550123456000118002445
maxcul.0 2019-08-26 17:25:39.712 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:25:39.712 debug Send Packet to CUL: Zs0f01040312345607955000131a119927, awaiting drain event
maxcul.0 2019-08-26 17:25:39.712 debug Updating time information for deviceId 079550
maxcul.0 2019-08-26 17:25:39.712 info deviceRequestTimeInformation: "079550"
maxcul.0 2019-08-26 17:25:39.712 debug got time information request from device 079550
maxcul.0 2019-08-26 17:25:39.712 debug RSSI for Message: -40
maxcul.0 2019-08-26 17:25:39.712 debug decoding Message Z0F70050307955012345600131A11992444
maxcul.0 2019-08-26 17:25:39.712 debug incoming raw data from CUL: Z0F70050307955012345600131A11992444
maxcul.0 2019-08-26 17:25:38.363 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 900)

@bowao
Copy link
Contributor

bowao commented Aug 26, 2019

Denn rssi Eintrag zwischen Zeile 756 und 757 kannst du so machen. Und ja, das komma gehört da eigentlich nicht hin, allerdings stört es auch nicht.
Theoretisch kannst du diesen rssi Eintrag ebenfalls zwischen Zeile 780 und 781 einfügen.
Ich schaue mal in die rohdaten ob in der 'WallThermostatControl'-Nachricht noch irgendwas von interresse steckt. Kann aber etwas dauern.
Hast du schon die Zeile 741 wie StenmannsAR beschrieben hat geändert?
Kommen jetzt die Werte immer korrekt?

@StenmannsAr
Ist das normal das das WallThermostat ständig nach der Uhrzeit fragt?

@guergen1
Copy link
Author

OK hab das "stücken" mit uint8(nulll) rausgeschmissen

@bowao
Copy link
Contributor

bowao commented Aug 26, 2019

Und dahinter auf uint16 geändert?

@guergen1
Copy link
Author

Im Moment kommen die Daten passend, ich stell mal am Weekprofil rum...

@StenmannsAr
Copy link
Contributor

bitte auch .uint8('heaterTemperature') auf .uint16('heaterTemperature') ändern

@bowao
Copy link
Contributor

bowao commented Aug 26, 2019

@StenmannsAr
Du hattest gestern in deiner letzten Nachricht geschrieben, das bei dir keine Werte mehr aktualisiert werden.
Hast du dazu schon was herausgefunden?

@guergen1
Copy link
Author

Ja, da steht jetzt uint16
die rssi-Daten sind auch grade gekommen

@guergen1
Copy link
Author

Jetzt ist nach dem ändern des Wocheplans die Temperatur die richtige geblieben!

@guergen1
Copy link
Author

Das ist das Log nach einem Boost:

maxcul.0 2019-08-26 17:41:31.829 debug got OK-ACK Packet from 079550
maxcul.0 2019-08-26 17:41:31.829 debug RSSI for Message: -40
maxcul.0 2019-08-26 17:41:31.829 debug decoding Message Z0E010202079550123456000119002444
maxcul.0 2019-08-26 17:41:31.829 debug incoming raw data from CUL: Z0E010202079550123456000119002444
maxcul.0 2019-08-26 17:41:30.762 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:41:30.760 debug Send Packet to CUL: Zs0b0100401234560795500064, awaiting drain event
maxcul.0 2019-08-26 17:41:30.759 debug sendTemperature(maxcul.0.KEQ0062305, 18, 1)
maxcul.0 2019-08-26 17:41:26.488 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 777)

@guergen1
Copy link
Author

Und hier das State innerhalb des Boostes:

maxcul.0 2019-08-26 17:42:26.517 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:42:26.515 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:42:21.931 debug WallThermostatStateReceived: {"src":"079550","mode":"3","desiredTemperature":18,"measuredTemperature":26.2,"dstSetting":1,"lanGateway":1,"panel":0,"rfError":0,"batteryLow":0,"rssi":-40}
maxcul.0 2019-08-26 17:42:21.931 debug got data from wallthermostat state 079550 with payload 1B00240106
maxcul.0 2019-08-26 17:42:21.931 debug RSSI for Message: -40
maxcul.0 2019-08-26 17:42:21.931 debug decoding Message Z0F780470079550000000001B0024010644
maxcul.0 2019-08-26 17:42:21.930 debug incoming raw data from CUL: Z0F780470079550000000001B0024010644
maxcul.0 2019-08-26 17:42:21.515 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 612)

@guergen1
Copy link
Author

So sah die Kurve kurzzeitig aus; jetzt nicht mehr:
grafik

@guergen1
Copy link
Author

Allerdings bleibt im Moment noch Boost im broker stehen, ich denke der geht beim State wieder auf MAnu oder Auto zurück

@guergen1
Copy link
Author

Jawoll: ist er:

maxcul.0 2019-08-26 17:48:31.687 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:48:31.684 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:48:26.686 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 900)
maxcul.0 2019-08-26 17:48:26.684 debug serial port buffer have been drained
maxcul.0 2019-08-26 17:48:26.682 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2019-08-26 17:48:21.927 debug WallThermostatStateReceived: {"src":"079550","mode":"1","desiredTemperature":18,"measuredTemperature":26.1,"dstSetting":1,"lanGateway":1,"panel":0,"rfError":0,"batteryLow":0,"rssi":-40.5}
maxcul.0 2019-08-26 17:48:21.927 debug got data from wallthermostat state 079550 with payload 1900240105
maxcul.0 2019-08-26 17:48:21.927 debug RSSI for Message: -40.5
maxcul.0 2019-08-26 17:48:21.927 debug decoding Message Z0F7A047007955000000000190024010543
maxcul.0 2019-08-26 17:48:21.926 debug incoming raw data from CUL: Z0F7A047007955000000000190024010543
maxcul.0 2019-08-26 17:48:21.681 debug delayed next send by 0ms (Queue length left = 0, Current Credit = 900)
maxcul.0 2019-08-26 17:48:21.679 debug serial port buffer have been drained

@bowao
Copy link
Contributor

bowao commented Aug 26, 2019

Ja das macht er normalerweise, kann aber im ioBroker ein bischen dauern, da die Geräte ja erst nach ca. Minuten ihren Status senden.

@Apollon77
Copy link
Collaborator

Sollten einige der erkenntnisse ggf noch in die readme?

@guergen1
Copy link
Author

Zu früh gefreut: wenn ich jetzt ein Fenster aufmache reagiert der Wallthermostat nicht... der Fensterkontakt kann das Signal nicht absetzen... blinkt drei mal...

@guergen1
Copy link
Author

Vielleicht, dass die Geräte (falls gewünscht) zuerst untereinander gepaired werden müssen, da der maxcul das Pairing schneller bestätigt wie man am anderen Gerät eine Taste drücken kann...

@guergen1
Copy link
Author

Ja, hier ist nach den pairen mit Maxcul nix mehr verheiratet... Fenster und Thermostate sind nicht mehr gekoppelt, scheint wohl nix gewesen zu sein. Die reden nicht mehr miteinander..:
grafik

@guergen1
Copy link
Author

Muss jetzt weg, paire das morgen alles noch einmal neu... werde hier berichten!

@StenmannsAr
Copy link
Contributor

Ich hoffe ihr habt euch alles aufgeschrieben was wir (ich ja diesmal auch :-) ) zusammengebastelt haben!
Sage schonmal lieben Dank!

Das meiste ist schon im push und sollte in die nächste Version fließen.

Ich fande das associate Feature was FHEM und der max cul beherschen immer sehr intressant.

@bowao
Copy link
Contributor

bowao commented Aug 26, 2019

Wenn diese pairing-Orgie so komplex ist, dann wäre es sicher sinnvoll wenn die genaue Vorgehensweise in der README steht. Vielleicht könnt ihr beiden da mal was zusammenschreiben?
Vielleicht komme ich ja auch noch mal zu einem WallThermostat und dann weiss ich schon mal wie es geht ;-)

@StenmannsAr
Was genau ist dieses associate Feature bei FHEM?
Aktualisieren die Werte bei dir jetzt auch wieder?

@guergen1
Copy link
Author

Ich will mal erklären, was "accociate" bei Fhem macht; komme ja als mehrjähriger Fhem-Nutzer daher: Im Fhem kennt das System keinen und nichts: Zuerst wird der cul mittels Angaben der Schnittstelle und der Geschwindigkeit mit Fhem vebunden. Danach werden die Geräte mit Fhem bekannt gemacht z.B.: "definiere 079550 als WZ_Wandthermostat" und "definiere 025882 als ShutterContact", ab dem Zeitpunkt kennt das System das Gerät und kann es steuern, als auch die Zustände der Fenster erkennen. Als Sender dient in dem Fall der Cul: "sag dem Gerät 079550 desiredTemp 19". Die Kopplung der Geräte untereinander kann auf 2 Weisen erfolgen: entweder ich kopple den ShutterContact per "Lern-Taste" mit dem Thermostat, oder aber ich benutze den "associate-Befehl", muss diesen aber in beide Richtungen durchführen, also Shutter mit Wand-TH und Wand-TH mit Shutter.
Der grosse Unterschied zum Maxcul-Adapter ist, wenn ich die Lern-Taste am Gerät drücke, wird bei Fhem nichts bestätigt, wenn ich dem System nicht einen "associate"-Befehl gebe, bei Maxcul greift das System die Lern-Anfrage direkt ab und das Gerät schaltet wieder in den Normalbetrieb.
Mit andere Worten: um ein MAX-System autark wie ich es nutze zu initialisieren, muss ich den maxcul ausschalten.

@guergen1
Copy link
Author

Vielleicht habe ich gestern auch einen kleinen, aber entscheidenden Fehler gemacht: ich hatte die Geräte nicht aus der Objektliste ausgetragen; werde das aber später testen und meine WZ-Installation noch einmal einlernen (s.o.)

@guergen1
Copy link
Author

Mein Plan für heute: alles Resetten, Objekte löschen, Maxcul abschalten. 2 HZ-Th an den Wall-TH anlernen, die beiden shutter auch an den Wall-TH anlernen. damit wäre mein System unabhängig steuerbar wie eh uns jeh.
Dann den Maxcul aktivieren und parallel debuggen. Leider frisst das Anlernen der Geräte etliche Credits, es werden ja die Standart-Weekprofiles übertragen, aber nicht eingetragen (wundert mich grade an dieser Stelle). Ich werde etwas geduldiger sein und jedem Schritt ausreichend Zeit geben um die Credits wieder zu sammeln. Gestern habe ich das meiner Meinung nach etwas zu schnell hintereinander gemacht, werde auch für alles ein eigenes Log-schreiben, vielleicht hilft euch das ja beim implementieren einiger Funktionen!

@guergen1
Copy link
Author

So, die 5 Geräte sind aus IoBroker raus und funktionieren jetzt autark.
Als erstes wird jetzt der Wall-Thermostat eingelernt.
Ich habe alle möglichen Reihenfolgen ausprobiert, sobald der Wall-Thermostat mit dem Broker ins spiel kommt, geht nichts mehr.
Wenn jemand Debug-Log haben möchte... Mail

@bowao
Copy link
Contributor

bowao commented Aug 27, 2019

Die standard-Wochenprogramme der Thermostate sind auf den Geräten ab Werk vorprogrammiert.
Diese werden zu keiner Zeit über Funk vom Thermostat gesendet und soweit mir bekannt, ist es auch nicht möglich diese über Funk auszulesen.
Daher sind die Datenpunkte im ioBroker solange leer, bis man dort etwas zum senden einträgt.
Ich hatte damals überlegt, das mir bekannte standard-Wochenprogramm als default Werte einzutragen, jedoch ist mir nicht klar, ob das bei allen Gerätetypen das gleiche ist, bzw. vom Hersteller mal geändert wird und die Werte dann nicht mehr stimmen. Deshalb sind die Datenpunkte nach dem pairing erstmal leer.
Über den ioBroker kann man das Wochenprogramm tageweise ändern und die geänderten Werte bleiben dann in den Datenpunkten gespeichert. Erst wenn man den Datenpunkt 'send_...' aktiviert, werden die Daten des jeweiligen Tages an das Thermostat einmalig gesendet.
Da für jeden Wochentag jeweils zwei Nachrichten gesendet werden (Eintrag 1-7 und Eintrag 7-13), macht das für ein Thermostat für ein komplettes Wochenprogramm dann 14 Nachrichten die versendet werden müssen. Bei meinen 8 Thermostaten kann das dann sehr lange dauern (credits) bis alles eingestellt ist. Ich vermute genau aus diesem Grund hat der Hersteller es nicht vorgesehen, das komplette Wochenprogramm über Funk auslesen zu können.

PS:
Die Credits oder auch der Duty Cycle ist eine gesetzlich geregelte Begrenzung der Sendezeiten von 868Mhz Geräten.
Und deshalb wäre es natürlich auch höchst illegal, wenn man z.B. den quellcode der culfw Firmware so abändern würde, das dieser keine credits mehr zählen könnte und diesen dann auch noch auf github öffentlich zugänglich machen würde.

@guergen1
Copy link
Author

Ja, das mit den Wochenprogrammen hatte ich bei Fhem schon beobachtet.
Ich werde mir wohl jetzt ein Script basteln was die Steuerung meines Wohnzimmers vornimmt.
Das das eigentliche Problem mit den falschen Werten vom Thermostat jetzt gelöst ist, wird es wohl sinnvoll sein, dass dieses Issue geschlossen wird...
Macht es jemand zu, oder soll ich es machen?

@guergen1
Copy link
Author

Bin aber auch gerne zu weiteren Schandtaten bereit! Wie gesagt, alles was ich gemacht habe habe ich im Debuglog mitgeschnitten

@bowao
Copy link
Contributor

bowao commented Aug 27, 2019

Ich habe alle möglichen Reihenfolgen ausprobiert, sobald der Wall-Thermostat mit dem Broker ins spiel kommt, geht nichts mehr.

Ich denke da kann dir nur StenmannsAR helfen.
Da es bei ihm funktioniert, sollte er wissen, in welche Reihenfolge und bei welche Mondphase oder Sternenkonstelation die Dinger gepairt werden müssen.

@guergen1
Copy link
Author

Vielleicht liegt es da aber auch an der Firmware der Geräte; meine HZ-Thermostate sind 1.0 und der Wall-TH 1.2 oder so

@guergen1
Copy link
Author

Mein Wall-TH vergisst nach einem accociate sogar die Uhrzeit....

@bowao
Copy link
Contributor

bowao commented Aug 27, 2019

Meinst du damit das pairing mit dem ioBroker?

@guergen1
Copy link
Author

Ja, habe den Wall-TH grade noch einmal resettet und die Uhrzeit und das Datum eingestellt. Pairing gedrückt und schwupp war sie weg. Kome jetzt auch nicht mehr in das Menue zum Einstellen der Uhrzeit, da der ja weiss, dass es eine übergeordnete Stelle gibt und man das darüber macht. Könnte meinen Cube ja auch noch aus der Ecke kramen... :-)

@bowao
Copy link
Contributor

bowao commented Aug 27, 2019

Das kann ich mir evtl. damit erklären, das das Wall-TH denkt es wäre mit einem MAX CUBE gepaired worden und vertraut dessen Uhr, die ja über ntp syncronisiert wird, mehr als seiner eigenen Uhr. Daher auch die dauernden Anfrage an den ioBroker nach der Uhrzeit. Würde also Sinn machen.
Aber nach kurzer Zeit sollte der Wall-TH die Uhrzeit vom ioBroker bekommen.

@guergen1
Copy link
Author

guergen1 commented Aug 27, 2019

jetzt sind 10 Minuten um... Ich bin geduldig
Hatte am Freitag nur die Temperatur im Auge, nicht die Uhrzeit

@bowao
Copy link
Contributor

bowao commented Aug 27, 2019

Nee. Sollte relativ schnell passieren.
Kanst du den in den logs sehen, ob der ioBroker die 'request Time Information' bekommt und darauf die Uhrzeit sendet?

@guergen1
Copy link
Author

Bisher nix...

@bowao
Copy link
Contributor

bowao commented Aug 27, 2019

Gestern hab ich in den logs aber ständig diese Anfrage gesehen.

maxcul.0 | 2019-08-26 17:25:39.712 | debug | Send Packet to CUL: Zs0f01040312345607955000131a119927, awaiting drain event
maxcul.0 | 2019-08-26 17:25:39.712 | debug | Updating time information for deviceId 079550
maxcul.0 | 2019-08-26 17:25:39.712 | info | deviceRequestTimeInformation: "079550"
maxcul.0 | 2019-08-26 17:25:39.712 | debug | got time information request from device 079550

Vielleicht hat das pairing mit dem ioBroker nich funktioniert?

@guergen1
Copy link
Author

Ich musste dann los, habe debug angelassen , werde es heute Nachmittag sehen, ob die Uhrzeit passt.
Das Pairing hat aber funktioniert, diverse Werte konnte ich am Rechner durchführen, der Thermostat hat diese dann auch ausgeführt.

@guergen1
Copy link
Author

Er hat die aktuelle Zeit irgendwann übernommen... soweit so gut.
Muss mich mal mit dem Kollegen StenmannsAR kurzschliessen....

@StenmannsAr
Copy link
Contributor

@guergen1 wir können uns gerne kurzschließen, aber bei mir funktionieren die Thermostate auch nicht mehr sobald ich sie mit einem mit iobroker gepaireten wandthermostat verbinde. Es gibt glaube ich die Möglichkeit über einen AddLinkPartner Command das wandthermostat und die Thermostate bzw Fenstersensoren zu linken, so dass man die Wandthermostate per iobroker und auch autark betreiben kann. Das AddLinkPartner-Command ist aber noch nicht implementiert.

@guergen1
Copy link
Author

Das eigentliche Problem ist ja erledigt, die Werte stimmen jetzt!
Ich mach das hier mal zu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants