NEWS
Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)
-
Hier ist das Logfile. Es gibt ein Problem. Man sieht dem Logfile nicht mehr an, dass der nanoCUL effektiv tot ist.
Ich sehe es an der schnell blinkenden LED. Das Ding ist tot seit der schnellen Uebertragung der Kommandos
nach den Send Packet bei "2018-03-05 00:22:04.". Ich empfehle dringend diese Sends so zu gestalten, dass nur ein Send pro 5 Sekunden stattfindet.
maxcul.0 2018-03-05 00:23:58.715 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:53.710 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:53.710 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:48.710 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:48.703 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:43.707 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:43.703 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:38.699 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:38.697 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:33.693 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:33.691 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:28.710 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:28.709 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:23.664 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:23.660 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:18.658 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:18.654 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:13.654 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:13.653 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:08.648 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:08.647 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:23:03.645 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:23:03.644 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:58.643 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:58.642 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:53.638 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:53.637 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:48.646 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:48.628 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:43.631 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:43.630 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:38.630 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:38.629 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:33.628 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:33.626 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:28.621 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:28.620 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:23.617 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:23.616 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:18.608 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:18.608 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:13.602 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:13.602 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:08.596 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:08.595 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:04.748 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.746 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:22:04.745 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.728 debug Send Packet to CUL: Zs0b0100401234561b7bbd0065, awaiting drain event
maxcul.0 2018-03-05 00:22:04.726 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.710 debug Send Packet to CUL: Zs0b0100401234561b7e310063, awaiting drain event
maxcul.0 2018-03-05 00:22:04.708 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.690 debug Send Packet to CUL: Zs0b0100401234561b7e34006a, awaiting drain event
maxcul.0 2018-03-05 00:22:04.689 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.672 debug Send Packet to CUL: Zs0b0100401234561b7d410063, awaiting drain event
maxcul.0 2018-03-05 00:22:04.670 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.656 debug Send Packet to CUL: Zs0b01004012345616fbae0063, awaiting drain event
maxcul.0 2018-03-05 00:22:04.656 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:04.655 debug Send Packet to CUL: Zs0b01004012345616fb8f0071, awaiting drain event
maxcul.0 2018-03-05 00:22:04.655 debug Queued send for X
maxcul.0 2018-03-05 00:22:04.655 debug Queued send for Zs0b0100401234561b7bbd0065
maxcul.0 2018-03-05 00:22:04.655 debug Queued send for Zs0b0100401234561b7e310063
maxcul.0 2018-03-05 00:22:04.654 debug Queued send for Zs0b0100401234561b7e34006a
maxcul.0 2018-03-05 00:22:04.654 debug Queued send for Zs0b0100401234561b7d410063
maxcul.0 2018-03-05 00:22:04.654 debug Queued send for Zs0b01004012345616fbae0063
maxcul.0 2018-03-05 00:22:04.653 debug got OK-ACK Packet from 16e328
maxcul.0 2018-03-05 00:22:04.653 debug RSSI for Message: -45.5
maxcul.0 2018-03-05 00:22:04.647 debug decoding Message Z0E01020216E328123456000139643139
maxcul.0 2018-03-05 00:22:04.647 debug incoming raw data from CUL: Z0E01020216E328123456000139643139
maxcul.0 2018-03-05 00:22:03.555 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:22:03.553 debug Send Packet to CUL: Zs0b01004012345616e3280071, awaiting drain event
maxcul.0 2018-03-05 00:22:03.552 info Poll device1 : 1, 18.5
maxcul.0 2018-03-05 00:22:03.551 info Poll device1 : 1, 17.5
maxcul.0 2018-03-05 00:22:03.550 info Poll device1 : 1, 21
maxcul.0 2018-03-05 00:22:03.550 info Poll device1 : 1, 17.5
maxcul.0 2018-03-05 00:22:03.549 info Poll device1 : 1, 17.5
maxcul.0 2018-03-05 00:22:03.548 info Poll device1 : 1, 24.5
maxcul.0 2018-03-05 00:22:03.548 info Poll device1 : 1, 24.5
maxcul.0 2018-03-05 00:21:58.611 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":503,"ack":true,"ts":1520205718601,"q":0,"from":"system.adapter.maxcul.0","lc":1520205718601}
maxcul.0 2018-03-05 00:21:58.590 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:58.583 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:53.594 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":498,"ack":true,"ts":1520205713586,"q":0,"from":"system.adapter.maxcul.0","lc":1520205713586}
maxcul.0 2018-03-05 00:21:53.582 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:53.581 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:48.618 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":493,"ack":true,"ts":1520205708601,"q":0,"from":"system.adapter.maxcul.0","lc":1520205708601}
maxcul.0 2018-03-05 00:21:48.584 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:48.582 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:43.584 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":488,"ack":true,"ts":1520205703578,"q":0,"from":"system.adapter.maxcul.0","lc":1520205703578}
maxcul.0 2018-03-05 00:21:43.573 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:43.572 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:38.566 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":483,"ack":true,"ts":1520205698560,"q":0,"from":"system.adapter.maxcul.0","lc":1520205698560}
maxcul.0 2018-03-05 00:21:38.562 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:38.561 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:33.567 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":478,"ack":true,"ts":1520205693561,"q":0,"from":"system.adapter.maxcul.0","lc":1520205693561}
maxcul.0 2018-03-05 00:21:33.554 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:33.553 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:31.714 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.rssi {"val":-65.5,"ack":true,"ts":1520205691709,"q":0,"from":"system.adapter.maxcul.0","lc":1520205691709}
maxcul.0 2018-03-05 00:21:31.706 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.batteryLow {"val":false,"ack":true,"ts":1520205691703,"q":0,"from":"system.adapter.maxcul.0","lc":1519668132799}
maxcul.0 2018-03-05 00:21:31.700 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.rfError {"val":false,"ack":true,"ts":1520205691695,"q":0,"from":"system.adapter.maxcul.0","lc":1519668132793}
maxcul.0 2018-03-05 00:21:31.690 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.measuredTemperature {"val":21,"ack":true,"ts":1520205691683,"q":0,"from":"system.adapter.maxcul.0","lc":1520205691683}
maxcul.0 2018-03-05 00:21:31.684 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.valvePosition {"val":23,"ack":true,"ts":1520205691672,"q":0,"from":"system.adapter.maxcul.0","lc":1520205691672}
maxcul.0 2018-03-05 00:21:31.667 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.desiredTemperature {"val":20,"ack":true,"ts":1520205691658,"q":0,"from":"system.adapter.maxcul.0","lc":1519684773078}
maxcul.0 2018-03-05 00:21:31.655 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605599.mode {"val":null,"ack":true,"ts":1520205691634,"q":0,"from":"system.adapter.maxcul.0","lc":1520205691634}
maxcul.0 2018-03-05 00:21:31.644 debug ThermostatStateReceived: {"src":"1b7edc","desiredTemperature":20,"valvePosition":23,"measuredTemperature":21,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rssi":
maxcul.0 2018-03-05 00:21:31.642 debug got data from heatingelement 1b7edc with payload 39172800D2
maxcul.0 2018-03-05 00:21:31.641 debug RSSI for Message: -65.5
maxcul.0 2018-03-05 00:21:31.637 debug decoding Message Z0F0004601B7EDC0000000039172800D211
maxcul.0 2018-03-05 00:21:31.636 debug incoming raw data from CUL: Z0F0004601B7EDC0000000039172800D211
maxcul.0 2018-03-05 00:21:28.563 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":473,"ack":true,"ts":1520205688556,"q":0,"from":"system.adapter.maxcul.0","lc":1520205688556}
maxcul.0 2018-03-05 00:21:28.553 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:28.552 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:23.555 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":468,"ack":true,"ts":1520205683552,"q":0,"from":"system.adapter.maxcul.0","lc":1520205683552}
maxcul.0 2018-03-05 00:21:23.547 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:23.546 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:18.556 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":463,"ack":true,"ts":1520205678550,"q":0,"from":"system.adapter.maxcul.0","lc":1520205678550}
maxcul.0 2018-03-05 00:21:18.546 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:18.542 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:13.552 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":458,"ack":true,"ts":1520205673547,"q":0,"from":"system.adapter.maxcul.0","lc":1520205673547}
maxcul.0 2018-03-05 00:21:13.538 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:13.535 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:09.569 debug Za drained
maxcul.0 2018-03-05 00:21:09.566 debug Za written
maxcul.0 2018-03-05 00:21:09.563 debug Zr drained
maxcul.0 2018-03-05 00:21:09.558 debug Zr written
maxcul.0 2018-03-05 00:21:09.554 debug X20 drained
maxcul.0 2018-03-05 00:21:09.549 debug X20 written
maxcul.0 2018-03-05 00:21:09.545 debug enable MAX! Mode of the CUL868
maxcul.0 2018-03-05 00:21:08.552 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":453,"ack":true,"ts":1520205668543,"q":0,"from":"system.adapter.maxcul.0","lc":1520205668543}
maxcul.0 2018-03-05 00:21:08.552 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1520205668539,"q":0,"from":"system.adapter.maxcul.0","lc":1520196435104}
maxcul.0 2018-03-05 00:21:08.538 debug serial port buffer have been drained
maxcul.0 2018-03-05 00:21:08.530 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 00:21:05.585 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":true,"ack":true,"ts":1520205665573,"q":0,"from":"system.adapter.maxcul.0","lc":1520205665573}
maxcul.0 2018-03-05 00:21:05.585 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.version {"val":"V 1.67 nanoCUL868","ack":true,"ts":1520205665568,"q":0,"from":"system.adapter.maxcul.0","lc":1519041256179}
maxcul.0 2018-03-05 00:21:05.579 info CUL FW Version: V 1.67 nanoCUL868
maxcul.0 2018-03-05 00:21:05.579 debug incoming raw data from CUL: V 1.67 nanoCUL868
maxcul.0 2018-03-05 00:21:05.541 debug Requested CUL Version…
maxcul.0 2018-03-05 00:21:05.536 debug check CUL Firmware version
maxcul.0 2018-03-05 00:21:03.543 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":false,"ack":true,"ts":1520205663531,"q":0,"from":"system.adapter.maxcul.0","lc":1520197165821}
maxcul.0 2018-03-05 00:21:03.543 info serialPort /dev/ttyUSB0 is open!
maxcul.0 2018-03-05 00:21:03.516 info using serial device /dev/ttyUSB0@38400
maxcul.0 2018-03-05 00:21:02.954 info starting. Version 0.5.1 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0
-
Hier ist das Logfile. Es gibt ein Problem. Man sieht dem Logfile nicht mehr an, dass der nanoCUL effektiv tot ist.
Ich sehe es an der schnell blinkenden LED. Das Ding ist tot seit der schnellen Uebertragung der Kommandos
nach den Send Packet bei "2018-03-05 00:22:04.". Ich empfehle dringend diese Sends so zu gestalten, dass nur ein Send pro 5 Sekunden stattfindet. `
5s beisst sich aber mit dem aktuellen "retry nach 3 Sekunden wenn kein Ack angekommen ist" … Mist ... ich würde erstmal 200ms oder so einbauen als Delay und dann tasten wir uns ran.
Oder kommen die 5s von irgendwo her?
-
Ich wuerde die Sache so versuchen zu schreiben, dass nach dem Send Zeit fuer eine Antwort vom Geraet drin ist. So dass man im Endeffekt endet bei
Send
Receive ACK
Send
Receive ACK
usw
-
Ich hab die betreffende Routine jetzt so veraendert:
CommunicationServiceLayer.prototype.writeQueue = function() {
if (!this._queuedWrites.length) return Promise.resolve(true);
var command = this._queuedWrites.shift();
this._queueSendInProgress = true;
return this._serialDeviceInstance.writeAsync(command).then(() => {
env.logger.debug('Send Packet to CUL: ' + command.trim() + ', awaiting drain event');
return this._serialDeviceInstance.drainAsync()
}).then(() => {
env.logger.debug('serial port buffer have been drained');
this._queueSendInProgress = false;
Promise.delay(4000).then(() => {
env.logger.debug('delayed 4s');
return this.writeQueue();
});
});
};
Ich kann diese Sprache nicht wirklich, ich versuch mir nur zu denken was die Codeteile bedeuten koennten…(daher dieses Promise Statement)
Das fuehrt zu folgendem Logfile und keinem Absturz:
maxcul.0 2018-03-05 01:13:22.238 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:13:22.230 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:13:21.219 debug delayed 4s
maxcul.0 2018-03-05 01:13:17.228 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":105,"ack":true,"ts":1520208797225,"q":0,"from":"system.adapter.maxcul.0","lc":1520208797225}
maxcul.0 2018-03-05 01:13:17.219 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:13:17.212 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:13:16.216 debug delayed 4s
maxcul.0 2018-03-05 01:13:12.226 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":100,"ack":true,"ts":1520208792223,"q":0,"from":"system.adapter.maxcul.0","lc":1520208792223}
maxcul.0 2018-03-05 01:13:12.211 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:13:12.209 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:13:11.215 debug delayed 4s
maxcul.0 2018-03-05 01:13:07.224 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":95,"ack":true,"ts":1520208787221,"q":0,"from":"system.adapter.maxcul.0","lc":1520208787221}
maxcul.0 2018-03-05 01:13:07.209 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:13:07.208 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:13:06.213 debug delayed 4s
maxcul.0 2018-03-05 01:13:03.398 debug delayed 4s
maxcul.0 2018-03-05 01:13:02.257 debug delayed 4s
maxcul.0 2018-03-05 01:13:02.225 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":90,"ack":true,"ts":1520208782219,"q":0,"from":"system.adapter.maxcul.0","lc":1520208782219}
maxcul.0 2018-03-05 01:13:02.209 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:13:02.207 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:59.422 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":88,"ack":true,"ts":1520208779397,"q":0,"from":"system.adapter.maxcul.0","lc":1520208779397}
maxcul.0 2018-03-05 01:12:59.398 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:59.390 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:59.385 debug delayed 4s
maxcul.0 2018-03-05 01:12:58.275 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":86,"ack":true,"ts":1520208778270,"q":0,"from":"system.adapter.maxcul.0","lc":1520208778270}
maxcul.0 2018-03-05 01:12:58.257 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:58.253 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:58.251 debug delayed 4s
maxcul.0 2018-03-05 01:12:57.199 debug Queued send for X
maxcul.0 2018-03-05 01:12:55.390 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":84,"ack":true,"ts":1520208775383,"q":0,"from":"system.adapter.maxcul.0","lc":1520208775383}
maxcul.0 2018-03-05 01:12:55.380 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:55.375 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:55.368 debug delayed 4s
maxcul.0 2018-03-05 01:12:54.269 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":82,"ack":true,"ts":1520208774259,"q":0,"from":"system.adapter.maxcul.0","lc":1520208774259}
maxcul.0 2018-03-05 01:12:54.252 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:54.246 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:54.242 debug delayed 4s
maxcul.0 2018-03-05 01:12:52.193 debug Queued send for X
maxcul.0 2018-03-05 01:12:51.373 debug LOVF: credits=503
maxcul.0 2018-03-05 01:12:51.370 debug incoming raw data from CUL: LOVF
maxcul.0 2018-03-05 01:12:51.365 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:51.349 debug Send Packet to CUL: Zs0b0100401234561b7bbd0065, awaiting drain event
maxcul.0 2018-03-05 01:12:51.345 debug delayed 4s
maxcul.0 2018-03-05 01:12:50.243 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":true,"ack":true,"ts":1520208770234,"q":0,"from":"system.adapter.maxcul.0","lc":1520208770234}
maxcul.0 2018-03-05 01:12:50.243 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:50.242 debug LOVF: credits=503
maxcul.0 2018-03-05 01:12:50.241 debug incoming raw data from CUL: LOVF
maxcul.0 2018-03-05 01:12:50.220 debug Send Packet to CUL: Zs0b0100401234561b7e34006a, awaiting drain event
maxcul.0 2018-03-05 01:12:50.217 debug delayed 4s
maxcul.0 2018-03-05 01:12:48.426 debug got OK-ACK Packet from 1b7d41
maxcul.0 2018-03-05 01:12:48.422 debug RSSI for Message: -45.5
maxcul.0 2018-03-05 01:12:48.418 debug decoding Message Z0E0102021B7D41123456000139642339
maxcul.0 2018-03-05 01:12:48.414 debug incoming raw data from CUL: Z0E0102021B7D41123456000139642339
maxcul.0 2018-03-05 01:12:47.340 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:47.316 debug Send Packet to CUL: Zs0b0100401234561b7d410063, awaiting drain event
maxcul.0 2018-03-05 01:12:47.313 debug delayed 4s
maxcul.0 2018-03-05 01:12:47.299 debug got OK-ACK Packet from 16fbae
maxcul.0 2018-03-05 01:12:47.298 debug RSSI for Message: -72
maxcul.0 2018-03-05 01:12:47.298 debug decoding Message Z0E01020216FBAE123456000139002304
maxcul.0 2018-03-05 01:12:47.297 debug incoming raw data from CUL: Z0E01020216FBAE123456000139002304
maxcul.0 2018-03-05 01:12:47.190 debug Queued send for X
maxcul.0 2018-03-05 01:12:46.215 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:46.202 debug Send Packet to CUL: Zs0b01004012345616fbae0063, awaiting drain event
maxcul.0 2018-03-05 01:12:46.198 debug delayed 4s
maxcul.0 2018-03-05 01:12:44.399 debug got OK-ACK Packet from 16fb8f
maxcul.0 2018-03-05 01:12:44.398 debug RSSI for Message: -46.5
maxcul.0 2018-03-05 01:12:44.393 debug decoding Message Z0E01020216FB8F123456000139643137
maxcul.0 2018-03-05 01:12:44.392 debug incoming raw data from CUL: Z0E01020216FB8F123456000139643137
maxcul.0 2018-03-05 01:12:43.314 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:43.313 debug Send Packet to CUL: Zs0b01004012345616fb8f0071, awaiting drain event
maxcul.0 2018-03-05 01:12:43.312 debug Queued send for X
maxcul.0 2018-03-05 01:12:43.312 debug Queued send for Zs0b0100401234561b7bbd0065
maxcul.0 2018-03-05 01:12:43.311 debug Queued send for Zs0b0100401234561b7e34006a
maxcul.0 2018-03-05 01:12:43.310 debug Queued send for Zs0b0100401234561b7d410063
maxcul.0 2018-03-05 01:12:43.309 debug Queued send for Zs0b01004012345616fbae0063
maxcul.0 2018-03-05 01:12:43.309 debug got OK-ACK Packet from 16e328
maxcul.0 2018-03-05 01:12:43.308 debug RSSI for Message: -44
maxcul.0 2018-03-05 01:12:43.307 debug decoding Message Z0E01020216E32812345600013964313C
maxcul.0 2018-03-05 01:12:43.307 debug incoming raw data from CUL: Z0E01020216E32812345600013964313C
maxcul.0 2018-03-05 01:12:42.204 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:42.202 debug Send Packet to CUL: Zs0b01004012345616e3280071, awaiting drain event
maxcul.0 2018-03-05 01:12:42.201 info Poll device1 : 1, 18.5
maxcul.0 2018-03-05 01:12:42.200 info Poll device1 : 1, 21
maxcul.0 2018-03-05 01:12:42.199 info Poll device1 : 1, 17.5
maxcul.0 2018-03-05 01:12:42.198 info Poll device1 : 1, 17.5
maxcul.0 2018-03-05 01:12:42.197 info Poll device1 : 1, 24.5
maxcul.0 2018-03-05 01:12:42.196 info Poll device1 : 1, 24.5
maxcul.0 2018-03-05 01:12:41.181 debug delayed 4s
maxcul.0 2018-03-05 01:12:37.187 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":503,"ack":true,"ts":1520208757179,"q":0,"from":"system.adapter.maxcul.0","lc":1520208757179}
maxcul.0 2018-03-05 01:12:37.172 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:37.168 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:36.174 debug delayed 4s
maxcul.0 2018-03-05 01:12:32.181 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":498,"ack":true,"ts":1520208752172,"q":0,"from":"system.adapter.maxcul.0","lc":1520208752172}
maxcul.0 2018-03-05 01:12:32.168 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:32.166 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:31.181 debug delayed 4s
maxcul.0 2018-03-05 01:12:27.187 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":493,"ack":true,"ts":1520208747176,"q":0,"from":"system.adapter.maxcul.0","lc":1520208747176}
maxcul.0 2018-03-05 01:12:27.172 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:27.169 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:26.174 debug delayed 4s
maxcul.0 2018-03-05 01:12:22.176 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":488,"ack":true,"ts":1520208742168,"q":0,"from":"system.adapter.maxcul.0","lc":1520208742168}
maxcul.0 2018-03-05 01:12:22.165 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:22.163 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:21.168 debug delayed 4s
maxcul.0 2018-03-05 01:12:17.174 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":483,"ack":true,"ts":1520208737165,"q":0,"from":"system.adapter.maxcul.0","lc":1520208737165}
maxcul.0 2018-03-05 01:12:17.163 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:17.161 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:16.172 debug delayed 4s
maxcul.0 2018-03-05 01:12:12.174 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":478,"ack":true,"ts":1520208732166,"q":0,"from":"system.adapter.maxcul.0","lc":1520208732166}
maxcul.0 2018-03-05 01:12:12.164 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:12.159 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:11.163 debug delayed 4s
maxcul.0 2018-03-05 01:12:07.181 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":473,"ack":true,"ts":1520208727176,"q":0,"from":"system.adapter.maxcul.0","lc":1520208727176}
maxcul.0 2018-03-05 01:12:07.158 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:07.157 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:06.161 debug delayed 4s
maxcul.0 2018-03-05 01:12:02.177 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":468,"ack":true,"ts":1520208722173,"q":0,"from":"system.adapter.maxcul.0","lc":1520208722173}
maxcul.0 2018-03-05 01:12:02.156 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:12:02.155 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:12:01.167 debug delayed 4s
maxcul.0 2018-03-05 01:11:57.178 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":463,"ack":true,"ts":1520208717172,"q":0,"from":"system.adapter.maxcul.0","lc":1520208717172}
maxcul.0 2018-03-05 01:11:57.157 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:11:57.153 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:11:56.157 debug delayed 4s
maxcul.0 2018-03-05 01:11:52.161 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":458,"ack":true,"ts":1520208712154,"q":0,"from":"system.adapter.maxcul.0","lc":1520208712154}
maxcul.0 2018-03-05 01:11:52.150 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:11:52.147 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:11:51.153 debug delayed 4s
maxcul.0 2018-03-05 01:11:48.183 debug Za drained
maxcul.0 2018-03-05 01:11:48.180 debug Za written
maxcul.0 2018-03-05 01:11:48.177 debug Zr drained
maxcul.0 2018-03-05 01:11:48.173 debug Zr written
maxcul.0 2018-03-05 01:11:48.168 debug X20 drained
maxcul.0 2018-03-05 01:11:48.164 debug X20 written
maxcul.0 2018-03-05 01:11:48.161 debug enable MAX! Mode of the CUL868
maxcul.0 2018-03-05 01:11:47.169 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":453,"ack":true,"ts":1520208707158,"q":0,"from":"system.adapter.maxcul.0","lc":1520208707158}
maxcul.0 2018-03-05 01:11:47.168 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1520208707155,"q":0,"from":"system.adapter.maxcul.0","lc":1520196435104}
maxcul.0 2018-03-05 01:11:47.148 debug serial port buffer have been drained
maxcul.0 2018-03-05 01:11:47.145 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 01:11:44.193 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":true,"ack":true,"ts":1520208704180,"q":0,"from":"system.adapter.maxcul.0","lc":1520208704180}
maxcul.0 2018-03-05 01:11:44.192 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.version {"val":"V 1.67 nanoCUL868","ack":true,"ts":1520208704179,"q":0,"from":"system.adapter.maxcul.0","lc":1519041256179}
maxcul.0 2018-03-05 01:11:44.187 info CUL FW Version: V 1.67 nanoCUL868
maxcul.0 2018-03-05 01:11:44.186 debug incoming raw data from CUL: V 1.67 nanoCUL868
maxcul.0 2018-03-05 01:11:44.158 debug Requested CUL Version...
maxcul.0 2018-03-05 01:11:44.153 debug check CUL Firmware version
maxcul.0 2018-03-05 01:11:42.160 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.connection {"val":false,"ack":true,"ts":1520208702148,"q":0,"from":"system.adapter.maxcul.0","lc":1520208644510}
maxcul.0 2018-03-05 01:11:42.160 info serialPort /dev/ttyUSB0 is open!
maxcul.0 2018-03-05 01:11:42.135 info using serial device /dev/ttyUSB0@38400
maxcul.0 2018-03-05 01:11:41.568 info starting. Version 0.5.1 in /opt/iobroker/node_modules/iobroker.maxcul, node: v6.12.0
Wie man sieht kommt nach dem Send Packet jeweils das ACK.
delay(2000) funktioniert nicht, hab ich probiert. delay(4000) geht scheinbar...
-
Ich habe da noch ein neues Problem mit maxcul.
Es geht um das mode Feld eines Thermostat Objekts. Man kann dieses Setzen und es wird zum Thermostat uebertragen. Aber danach wird das Feld scheinbar geloescht oder undefiniert hinterlassen. Es kommt mir so vor, als ob danach bei der naechsten Einstellungs-Sendung des Thermostats dieses immer auf "Auto" sprich "0" gesetzt wird. Aber genau das will man eigentlich nicht. Die ioBroker Einstellungen funktionieren nur korrekt wenn das Thermostat auf "Manual" (1) steht.
Ich glaube mich zu erinnern dass das im 0.3.0 anders war…
-
Wie man sieht kommt nach dem Send Packet jeweils das ACK.
delay(2000) funktioniert nicht, hab ich probiert. delay(4000) geht scheinbar… `
Was genau geht bei einem kleineren Delay nicht? Crasht er immer noch? 4s kann halt wenn viel los ist zu eeecht langen Reaktionszeiten führen … und ich kapiere nicht warum das so ist wie es ist.
wenn er crasht weil zu schnell gesendet wird dann sollte eigentlich ein weit kleinerer Delay reichen. Und es ist ja ok wenn schneller gesendetwird die Ack sollten dann immer noch entsprechend reinkommen und verarbeitet werden ...
-
Ich habe da noch ein neues Problem mit maxcul.
Es geht um das mode Feld eines Thermostat Objekts. Man kann dieses Setzen und es wird zum Thermostat uebertragen. Aber danach wird das Feld scheinbar geloescht oder undefiniert hinterlassen. Es kommt mir so vor, als ob danach bei der naechsten Einstellungs-Sendung des Thermostats dieses immer auf "Auto" sprich "0" gesetzt wird. Aber genau das will man eigentlich nicht. Die ioBroker Einstellungen funktionieren nur korrekt wenn das Thermostat auf "Manual" (1) steht.
Ich glaube mich zu erinnern dass das im 0.3.0 anders war… `
Ich habe sonst nichts an der "Logik" geändert
-
Erst mal zu einem Vorgang der die Sache mit dem mode beweist:
maxcul.0 2018-03-05 10:02:34.372 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.rssi {"val":-69.5,"ack":true,"ts":1520240554367,"q":0,"from":"system.adapter.maxcul.0","lc":1520240554367}
maxcul.0 2018-03-05 10:02:34.366 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.batteryLow {"val":false,"ack":true,"ts":1520240554361,"q":0,"from":"system.adapter.maxcul.0","lc":1519978554323}
maxcul.0 2018-03-05 10:02:34.360 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.rfError {"val":false,"ack":true,"ts":1520240554356,"q":0,"from":"system.adapter.maxcul.0","lc":1519978554318}
maxcul.0 2018-03-05 10:02:34.355 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.measuredTemperature {"val":18.6,"ack":true,"ts":1520240554349,"q":0,"from":"system.adapter.maxcul.0","lc":1520240309909}
maxcul.0 2018-03-05 10:02:34.348 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.valvePosition {"val":8,"ack":true,"ts":1520240554342,"q":0,"from":"system.adapter.maxcul.0","lc":1520240554342}
maxcul.0 2018-03-05 10:02:34.341 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.desiredTemperature {"val":18,"ack":true,"ts":1520240554336,"q":0,"from":"system.adapter.maxcul.0","lc":1520236920388}
maxcul.0 2018-03-05 10:02:34.335 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.mode {"val":null,"ack":true,"ts":1520240554328,"q":0,"from":"system.adapter.maxcul.0","lc":1520240554328}
maxcul.0 2018-03-05 10:02:34.335 debug ThermostatStateReceived: {"src":"1b7bbd","desiredTemperature":18,"valvePosition":8,"measuredTemperature":18.6,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rssi"
Man sieht hier dass der Received keinerlei "mode" enthaelt. Aber das erste was als Message generiert wird ist ein mode mit "null".
Hier noch mal die komplette Zeile aus dem logfile:
2018-03-05 10:02:34.327 - debug: maxcul.0 ThermostatStateReceived: {"src":"1b7bbd","desiredTemperature":18,"valvePosition":8,"measuredTemperature":18.6,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rssi":-69.5}
-
bzgl. delay:
was crasht ist der nanoCUL. Der Adapter denkt weiterhin er koennte mit dem nanoCUL reden, aber der blinkt sich zu Tode und schickt keine Pakete mehr ueber Funk. Receive geht, aber kein Send.
Dieser Status laesst sich nicht mehr korrigieren wenn er eingetreten ist, da hilft nur noch ausstecken des nanoCUL.
Nachtrag:
ich hab mir das jetzt nochmal ganz genau angeschaut. Das Problem koennte auch am Aufruf des Codes liegen der die Queue ausleert, denn wenn das Flag gleich wieder auf false gesetzt wird kann ein folgender Aufruf vor Ablauf des Delays nochmal zu einem Send fuehren, daher:
CommunicationServiceLayer.prototype.writeQueue = function() {
if (!this._queuedWrites.length) return Promise.resolve(true);
var command = this._queuedWrites.shift();
this._queueSendInProgress = true;
return this._serialDeviceInstance.writeAsync(command).then(() => {
env.logger.debug('Send Packet to CUL: ' + command.trim() + ', awaiting drain event');
return this._serialDeviceInstance.drainAsync()
}).then(() => {
env.logger.debug('serial port buffer have been drained');
Promise.delay(2000).then(() => {
env.logger.debug('delayed 2s');
this._queueSendInProgress = false;
return this.writeQueue();
});
});
};
Jetzt mit "this._queueSendInProgress = false;" ganz am Schluss…
Wenn man genau darueber nachdenkt sollte man das false auch gar nicht am Ende setzen, sondern ganz oben eine Abfrage auf length==0 und dann auf false und exit. Wenn diese Routine "zweimal" parallel laeuft gibts sicher ein Problem...
Das Problem mit dem Locking ist jetzt halt hier konzentriert anstatt bei jedem SendPacket Aufruf wie frueher.
-
bzgl. delay:
was crasht ist der nanoCUL. `
Sorry, aber einmal muss ich es sagen: Dann ist der nanocul "Schrott" und ein echter cul besser ;-)) Dann gäbe es diese ganzen Probleme nicht.
Nachtrag:
ich hab mir das jetzt nochmal ganz genau angeschaut. Das Problem koennte auch am Aufruf des Codes liegen der die Queue ausleert, denn wenn das Flag gleich wieder auf false gesetzt wird kann ein folgender Aufruf vor Ablauf des Delays nochmal zu einem Send fuehren, daher:
Jetzt mit "this._queueSendInProgress = false;" ganz am Schluss… `
Jupp, so war es auch in meinem Code :-)
Wenn man genau darueber nachdenkt sollte man das false auch gar nicht am Ende setzen, sondern ganz oben eine Abfrage auf length==0 und dann auf false und exit. Wenn diese Routine "zweimal" parallel laeuft gibts sicher ein Problem…
Das Problem mit dem Locking ist jetzt halt hier konzentriert anstatt bei jedem SendPacket Aufruf wie frueher. `
Nein. Das ist alles so korrekt.
Das "Locking" passiert in der Kombination aus "Länge der Queue" und "wird gerade gesendet". Das passt alles so wie es ist.
Du darfst das _queueSendInProgress erst nach deinem delay zurücksetzen. Vollkommen korrekt.
Jetzt kannst Du mal am Delay drehen und die "Minimale" Wartezeit zwischen dem Senden herausfinden. Ich würde bei 200ms anfangen und in 200ms Schritten erhöhen. Wenn es klappt nochmal 100ms weniger versuchen und wenn das noch klappt wieder zurück. Wenn nicht nochmal sicherheitshalber 100ms drauf und gut :-)
-
Erst mal zu einem Vorgang der die Sache mit dem mode beweist:
maxcul.0 2018-03-05 10:02:34.335 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.mode {"val":null,"ack":true,"ts":1520240554328,"q":0,"from":"system.adapter.maxcul.0","lc":1520240554328}
maxcul.0 2018-03-05 10:02:34.335 debug ThermostatStateReceived: {"src":"1b7bbd","desiredTemperature":18,"valvePosition":8,"measuredTemperature":18.6,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rssi"
Man sieht hier dass der Received keinerlei "mode" enthaelt. Aber das erste was als Message generiert wird ist ein mode mit "null".
Hier noch mal die komplette Zeile aus dem logfile:
2018-03-05 10:02:34.327 - debug: maxcul.0 ThermostatStateReceived: {"src":"1b7bbd","desiredTemperature":18,"valvePosition":8,"measuredTemperature":18.6,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rssi":-69.5} `
Im Code wird "mode" immer gesetzt und ist auch als Key faktisch im Objekt da. Ich denke das es ggf "undefined" ist und daher in der Ausgabe fehlt und auf null gesetzt wird.
Mach mal diese Änderung bei Dir und sag ob es hilft:
-
Thema mode:
es scheint jetzt die Aenderung zu geben, dass das Feld jetzt von "Manual" nicht auf <leer>wechselt sondern auf "null".
Warum das so ist kann ich im log nicht sehen …
Nochmal kontrolliert: Der Patch bringt ... naja, also der Wert ueberlebt den naechsten Receive, ist aber rot und "bestätigt:" zeigt "false".
Wie wuerde denn dieser Wert bestaetigt werden? Wenn das Thermostat ihn einmal zurueckschickt?
Das Problem im ungepatchten Code ist wohl ganz einfach dass aus "undefined" erst "null" wird und dann beim naechsten Send am Thermostat "auto", da "null" numerisch "0" ist, ebenso wie "auto".</leer>
-
Thema delay usw:
ich nehme an Du meinst mit Laenge und flag so eine Stelle hier (Z 186 ca)
this._queuedWrites.push(command);
env.logger.debug('Queued send for ' + command.trim());
if (this._queuedWrites.length === 1 && !this._queueSendInProgress) {
return this.writeQueue();
}
return Promise.resolve();
Das Problem an diesem Vergleich ist, dass er in einer Multitasking-Umgebung klar failed. Genau diese Stelle war vormals dafuer verantwortlich dass der Delay im writeQueue nicht ging wenn das Flag irgendwann auf false gesetzt wird. Mit dem Setzen am Ende von writeQueue wird zwar das Zeitfenster kleiner, aber es ist nicht weg. Genau deshalb meinte ich ja, dass das false-Setzen oben bei einem Vergleich auf "0" der Queue-Laenge gemacht werden sollte. Da ist das Fenster immer noch nicht weg, aber sicherlich noch viel kleiner (auf die Laufzeit eines Vergleichs und ein paar Zyklen beschraenkt).
Wenn in writeQueue erst mal zweimal "eingesprungen" wurde ists verloren, weil innerhalb dieser Routine kein Ausschluss des anderen Laufs erfolgen kann.
Mit dem Delay haben wir wenigstens irgendeine halbe Loesung. Ich wuerde mich daher jetzt erst mal auf den klaren Mode-Bug beschraenken…
-
Hier wieder ein Logfile des kuerzesten funktionierenden Delays (1s):
!
maxcul.0 2018-03-05 19:49:29.734 debug delayed 1s maxcul.0 2018-03-05 19:49:28.752 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":89,"ack":true,"ts":1520275768748,"q":0,"from":"system.adapter.maxcul.0","lc":1520275768748} maxcul.0 2018-03-05 19:49:28.732 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:28.729 debug Send Packet to CUL: X, awaiting drain event maxcul.0 2018-03-05 19:49:28.728 debug Queued send for X maxcul.0 2018-03-05 19:49:27.758 warn Not enough credits. Wait for more... maxcul.0 2018-03-05 19:49:26.140 warn Not enough credits. Wait for more... maxcul.0 2018-03-05 19:49:24.732 debug delayed 1s maxcul.0 2018-03-05 19:49:23.753 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":84,"ack":true,"ts":1520275763748,"q":0,"from":"system.adapter.maxcul.0","lc":1520275763748} maxcul.0 2018-03-05 19:49:23.753 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":true,"ack":true,"ts":1520275763746,"q":0,"from":"system.adapter.maxcul.0","lc":1520275763746} maxcul.0 2018-03-05 19:49:23.730 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:23.729 debug Send Packet to CUL: X, awaiting drain event maxcul.0 2018-03-05 19:49:23.727 debug Queued send for X maxcul.0 2018-03-05 19:49:22.797 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.rssi {"val":-71.5,"ack":true,"ts":1520275762792,"q":0,"from":"system.adapter.maxcul.0","lc":1520275762792} maxcul.0 2018-03-05 19:49:22.794 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.batteryLow {"val":false,"ack":true,"ts":1520275762787,"q":0,"from":"system.adapter.maxcul.0","lc":1519978554323} maxcul.0 2018-03-05 19:49:22.789 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.rfError {"val":false,"ack":true,"ts":1520275762781,"q":0,"from":"system.adapter.maxcul.0","lc":1519978554318} maxcul.0 2018-03-05 19:49:22.783 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.measuredTemperature {"val":19,"ack":true,"ts":1520275762777,"q":0,"from":"system.adapter.maxcul.0","lc":1520275762777} maxcul.0 2018-03-05 19:49:22.774 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2604801.valvePosition {"val":4,"ack":true,"ts":1520275762755,"q":0,"from":"system.adapter.maxcul.0","lc":1520275762755} maxcul.0 2018-03-05 19:49:22.771 warn Not enough credits. Wait for more... maxcul.0 2018-03-05 19:49:22.771 debug ThermostatStateReceived: {"src":"1b7bbd","desiredTemperature":18,"valvePosition":4,"measuredTemperature":19,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rssi":- maxcul.0 2018-03-05 19:49:22.771 debug Ignore desiredTemperature: 18 maxcul.0 2018-03-05 19:49:22.767 debug got data from heatingelement 1b7bbd with payload 39042400BE maxcul.0 2018-03-05 19:49:22.766 debug RSSI for Message: -71.5 maxcul.0 2018-03-05 19:49:22.759 debug decoding Message Z0F0004601B7BBD0000000039042400BE05 maxcul.0 2018-03-05 19:49:22.759 debug incoming raw data from CUL: Z0F0004601B7BBD0000000039042400BE05 maxcul.0 2018-03-05 19:49:21.167 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605190.rssi {"val":-54,"ack":true,"ts":1520275761164,"q":0,"from":"system.adapter.maxcul.0","lc":1520275761164} maxcul.0 2018-03-05 19:49:21.163 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605190.batteryLow {"val":false,"ack":true,"ts":1520275761159,"q":0,"from":"system.adapter.maxcul.0","lc":1519666999043} maxcul.0 2018-03-05 19:49:21.158 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605190.rfError {"val":false,"ack":true,"ts":1520275761149,"q":0,"from":"system.adapter.maxcul.0","lc":1519666999039} maxcul.0 2018-03-05 19:49:21.149 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605190.measuredTemperature {"val":27.3,"ack":true,"ts":1520275761145,"q":0,"from":"system.adapter.maxcul.0","lc":1520275761145} maxcul.0 2018-03-05 19:49:21.144 debug redis pmessage io.maxcul.0.* io.maxcul.0.OEQ2605190.valvePosition {"val":69,"ack":true,"ts":1520275761137,"q":0,"from":"system.adapter.maxcul.0","lc":1520275761137} maxcul.0 2018-03-05 19:49:21.143 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":false,"ack":true,"ts":1520275761137,"q":0,"from":"system.adapter.maxcul.0","lc":1520275761137} maxcul.0 2018-03-05 19:49:21.139 warn Not enough credits. Wait for more... maxcul.0 2018-03-05 19:49:21.139 debug ThermostatStateReceived: {"src":"1b7d41","desiredTemperature":24.5,"valvePosition":69,"measuredTemperature":27.3,"dstSetting":1,"lanGateway":1,"panel":1,"rfError":0,"batteryLow":0,"untilString":"","rs maxcul.0 2018-03-05 19:49:21.139 debug Ignore desiredTemperature: 24.5 maxcul.0 2018-03-05 19:49:21.139 debug got data from heatingelement 1b7d41 with payload 3945310111 maxcul.0 2018-03-05 19:49:21.138 debug RSSI for Message: -54 maxcul.0 2018-03-05 19:49:21.138 debug decoding Message Z0F0004601B7D4100000000394531011128 maxcul.0 2018-03-05 19:49:21.138 debug incoming raw data from CUL: Z0F0004601B7D4100000000394531011128 maxcul.0 2018-03-05 19:49:19.955 debug delayed 1s maxcul.0 2018-03-05 19:49:18.973 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":80,"ack":true,"ts":1520275758969,"q":0,"from":"system.adapter.maxcul.0","lc":1520275758969} maxcul.0 2018-03-05 19:49:18.954 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:18.950 debug Send Packet to CUL: X, awaiting drain event maxcul.0 2018-03-05 19:49:18.948 debug delayed 1s maxcul.0 2018-03-05 19:49:18.721 debug Queued send for X maxcul.0 2018-03-05 19:49:17.962 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":79,"ack":true,"ts":1520275757960,"q":0,"from":"system.adapter.maxcul.0","lc":1520275757960} maxcul.0 2018-03-05 19:49:17.946 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:17.943 debug Send Packet to CUL: X, awaiting drain event maxcul.0 2018-03-05 19:49:17.942 debug delayed 1s maxcul.0 2018-03-05 19:49:16.949 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":78,"ack":true,"ts":1520275756943,"q":0,"from":"system.adapter.maxcul.0","lc":1520275756943} maxcul.0 2018-03-05 19:49:16.940 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:16.930 debug Send Packet to CUL: X, awaiting drain event maxcul.0 2018-03-05 19:49:16.928 debug delayed 1s maxcul.0 2018-03-05 19:49:15.933 debug LOVF: credits=503 maxcul.0 2018-03-05 19:49:15.932 debug incoming raw data from CUL: LOVF maxcul.0 2018-03-05 19:49:15.925 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:15.914 debug Send Packet to CUL: Zs0b0100401234561b7c2e0067, awaiting drain event maxcul.0 2018-03-05 19:49:15.909 debug delayed 1s maxcul.0 2018-03-05 19:49:14.914 debug LOVF: credits=503 maxcul.0 2018-03-05 19:49:14.913 debug incoming raw data from CUL: LOVF maxcul.0 2018-03-05 19:49:14.905 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:14.894 debug Send Packet to CUL: Zs0b0100401234561b7bbd0065, awaiting drain event maxcul.0 2018-03-05 19:49:14.893 debug delayed 1s maxcul.0 2018-03-05 19:49:13.891 debug LOVF: credits=503 maxcul.0 2018-03-05 19:49:13.890 debug incoming raw data from CUL: LOVF maxcul.0 2018-03-05 19:49:13.884 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:13.880 debug Send Packet to CUL: Zs0b0100401234561b7e310067, awaiting drain event maxcul.0 2018-03-05 19:49:13.866 debug delayed 1s maxcul.0 2018-03-05 19:49:13.718 debug Queued send for X maxcul.0 2018-03-05 19:49:12.936 debug got OK-ACK Packet from 1b7edc maxcul.0 2018-03-05 19:49:12.935 debug RSSI for Message: -62.5 maxcul.0 2018-03-05 19:49:12.935 debug decoding Message Z0E0102021B7EDC123456000139162517 maxcul.0 2018-03-05 19:49:12.930 debug incoming raw data from CUL: Z0E0102021B7EDC123456000139162517 maxcul.0 2018-03-05 19:49:12.896 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":true,"ack":true,"ts":1520275752880,"q":0,"from":"system.adapter.maxcul.0","lc":1520275752880} maxcul.0 2018-03-05 19:49:12.893 debug LOVF: credits=503 maxcul.0 2018-03-05 19:49:12.892 debug incoming raw data from CUL: LOVF maxcul.0 2018-03-05 19:49:12.865 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:12.850 debug Send Packet to CUL: Zs0b0100401234561b7e34006b, awaiting drain event maxcul.0 2018-03-05 19:49:12.846 debug delayed 1s maxcul.0 2018-03-05 19:49:11.845 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:11.820 debug Send Packet to CUL: Zs0b0100401234561b7edc0065, awaiting drain event maxcul.0 2018-03-05 19:49:11.817 debug delayed 1s maxcul.0 2018-03-05 19:49:10.815 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:10.796 debug Send Packet to CUL: Zs0b0100401234561b7d410071, awaiting drain event maxcul.0 2018-03-05 19:49:10.793 debug delayed 1s maxcul.0 2018-03-05 19:49:09.796 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:09.795 debug Send Packet to CUL: Zs0b01004012345616fb8f0072, awaiting drain event maxcul.0 2018-03-05 19:49:09.795 debug Queued send for X maxcul.0 2018-03-05 19:49:09.795 debug Queued send for Zs0b0100401234561b7c2e0067 maxcul.0 2018-03-05 19:49:09.794 debug Queued send for Zs0b0100401234561b7bbd0065 maxcul.0 2018-03-05 19:49:09.793 debug Queued send for Zs0b0100401234561b7e310067 maxcul.0 2018-03-05 19:49:09.793 debug Queued send for Zs0b0100401234561b7e34006b maxcul.0 2018-03-05 19:49:09.792 debug Queued send for Zs0b0100401234561b7edc0065 maxcul.0 2018-03-05 19:49:09.792 debug Queued send for Zs0b0100401234561b7d410071 maxcul.0 2018-03-05 19:49:09.791 debug Queued send for Zs0b01004012345616fb8f0072 maxcul.0 2018-03-05 19:49:09.791 debug got OK-ACK Packet from 16e328 maxcul.0 2018-03-05 19:49:09.790 debug RSSI for Message: -52 maxcul.0 2018-03-05 19:49:09.790 debug decoding Message Z0E01020216E32812345600013964312C maxcul.0 2018-03-05 19:49:09.789 debug incoming raw data from CUL: Z0E01020216E32812345600013964312C maxcul.0 2018-03-05 19:49:09.719 debug delayed 1s maxcul.0 2018-03-05 19:49:08.718 debug serial port buffer have been drained maxcul.0 2018-03-05 19:49:08.708 debug Send Packet to CUL: Zs0b01004012345616e3280071, awaiting drain event maxcul.0 2018-03-05 19:49:08.706 info Poll device1 : 1, 19.5 maxcul.0 2018-03-05 19:49:08.703 info Poll device1 : 1, 18.5 maxcul.0 2018-03-05 19:49:08.701 info Poll device1 : 1, 19.5 maxcul.0 2018-03-05 19:49:08.696 info Poll device1 : 1, 21.5 maxcul.0 2018-03-05 19:49:08.694 info Poll device1 : 1, 18.5 maxcul.0 2018-03-05 19:49:08.689 info Poll device1 : 1, 24.5 maxcul.0 2018-03-05 19:49:08.689 info Poll device1 : 1, 25 maxcul.0 2018-03-05 19:49:08.681 debug Queued send for Zs0b01004012345616e3280071 maxcul.0 2018-03-05 19:49:08.680 info Poll device1 : 1, 24.5 maxcul.0 2018-03-05 19:49:04.715 debug delayed 1s maxcul.0 2018-03-05 19:49:03.727 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":503,"ack":true,"ts":1520275743722,"q":0,"from":"system.adapter.maxcul.0","lc":1520275743722} maxcul.0 2018-03-05 19:49:03.719 debug serial port buffer have been drained !
Was bedeutet LOVF als Antwort? -
bzgl. delay:
was crasht ist der nanoCUL. `
Sorry, aber einmal muss ich es sagen: Dann ist der nanocul "Schrott" und ein echter cul besser ;-)) Dann gäbe es diese ganzen Probleme nicht. `
Tja, ich glaube das ist nicht richtig. Ich hab grad etwas im FHEM Forum quer gelesen. Dort sagte jemand dass ein MAX CUBE hoechstens 5-6 Geraete handeln koennte. Ich nehme an dass bei mehr genau die hier diskutierten Kollisionen beim Senden ebenfalls auftreten, da einer der Tipps darin bestand die Geraete zu verschiedenen Zeiten zu Pairen, wohl damit das Senden zu diesen wenn moeglich nicht dieselbe Zeitscheibe trifft.
Ich betreibe dagegen gerade 10 Thermostate und 13 Fensterkontakte zeitgleich.
Ich glaube es waere viel schlauer anstatt den Delay so klein wie moeglich zu machen ihn wirklich auf 5-10 Sekunden zu ziehen. Es spielt keine grosse Rolle ob man in derselben Minute wirklich alle Geraete erreicht, Hauptsache sie gehen wirklich verlaesslich.
PS: Wofuer sind eigentlich die staendigen X Kommandos gut?
-
Thema mode:
es scheint jetzt die Aenderung zu geben, dass das Feld jetzt von "Manual" nicht auf <leer>wechselt sondern auf "null".
Warum das so ist kann ich im log nicht sehen …
Nochmal kontrolliert: Der Patch bringt ... naja, also der Wert ueberlebt den naechsten Receive, ist aber rot und "bestätigt:" zeigt "false".
Wie wuerde denn dieser Wert bestaetigt werden? Wenn das Thermostat ihn einmal zurueckschickt?</leer> `
Korrekt. Er wird nur vom Gerät bestätigt. Was passiert denn wenn Du nur den Mode am Gerät änderst ? Wird er dann mitgeliefert?
Ich habe den Codeteil nochmal mit "der Quelle" verglichen und da war wohl was geändert worden. Habe es auf Github gleich gezogen. Bitte mal versuchen.
https://github.com/ioBroker/ioBroker.ma … 61205df5c4
Thema delay usw:
Das Problem an diesem Vergleich ist, dass er in einer Multitasking-Umgebung klar failed. `
Wenn nodejs "multitasking" arbeiten würde hättest Du recht. Tut es aber nicht!!Die asynchrone bzw. "Eventgesteuerte" Logik in node bzw JavaScript allgemein ist Single-Threaded.
Von daher: Das ist korrekt so und macht man so in Nodejs/JavaScript.
Den Fall das "während" einmal "writeQueue" abgearbeitet wird ein zweiter Aufruf erfolgt existiert schlichtweg nicht. Das ist alles streng nacheinander.
Durch das asynchrone "send" und "drain" (wo anderer Code" zwischenrein" laufen kann muss man nur sicherstellen das das writeQueue nicht aufgerufen wird. Daher: Wenn ein neues Kommando in das Array eingefügt wird und damit die Länge 1 ist UND es gerade nicht noch auf send/drain wartet kann sichergestellt writeQueue aufgerufen werden.
Von daher ist der code der das "sendInProgress" nach dem drain und deiner neuen Wartezeit zurücksetzt genau richtig.
Genau diese Stelle war vormals dafuer verantwortlich dass der Delay im writeQueue nicht ging wenn das Flag irgendwann auf false gesetzt wird. Mit dem Setzen am Ende von writeQueue wird zwar das Zeitfenster kleiner, aber es ist nicht weg. Genau deshalb meinte ich ja, dass das false-Setzen oben bei einem Vergleich auf "0" der Queue-Laenge gemacht werden sollte. Da ist das Fenster immer noch nicht weg, aber sicherlich noch viel kleiner (auf die Laufzeit eines Vergleichs und ein paar Zyklen beschraenkt).
Wenn in writeQueue erst mal zweimal "eingesprungen" wurde ists verloren, weil innerhalb dieser Routine kein Ausschluss des anderen Laufs erfolgen kann. `
Siehe oben: kann nicht passieren bzw wird vom code korrekt abgefangen wenn das "sendInProgress" skorrekt zurückgesetzt wird "am Ende" wenn der nächste Call kommen darf.Mit dem Delay haben wir wenigstens irgendeine halbe Loesung. Ich wuerde mich daher jetzt erst mal auf den klaren Mode-Bug beschränken…
Hier wieder ein Logfile des kuerzesten funktionierenden Delays (1s):
...
Was bedeutet LOVF als Antwort? `
Na dann haben wir es mit 1s als Delay.Ok. Übernehme nachher deinen Delay code mit 2s ins Github, dann kannst Du nochmal testen. Mit 2s sollte auch ggf eine bessere Verteilung der Kommunikation stattfinden und vllt weniger LOVF (siehe unten).
https://wiki.fhem.de/wiki/LOVF
… dere Stick sagt das er zu schnell zuviel gesendet hat
PS: Wofuer sind eigentlich die staendigen X Kommandos gut? `
Mit dem Kommando fragt man beim CUL den Stand des Sendelimits ab. Hab aber noch nicht geschaut was der Adapter/Code damit tut. Ich denke Requests selbst delayen oder so -
Kann das Problem an der deutlich höheren BaudRate des nanoCUL im Vergleich zum Original liegen?
Gruß
Rainer
-
Thema mode:
es scheint jetzt die Aenderung zu geben, dass das Feld jetzt von "Manual" nicht auf <leer>wechselt sondern auf "null".
Warum das so ist kann ich im log nicht sehen …
Nochmal kontrolliert: Der Patch bringt ... naja, also der Wert ueberlebt den naechsten Receive, ist aber rot und "bestätigt:" zeigt "false".
Wie wuerde denn dieser Wert bestaetigt werden? Wenn das Thermostat ihn einmal zurueckschickt?</leer> `
Korrekt. Er wird nur vom Gerät bestätigt. Was passiert denn wenn Du nur den Mode am Gerät änderst ? Wird er dann mitgeliefert?
Ich habe den Codeteil nochmal mit "der Quelle" verglichen und da war wohl was geändert worden. Habe es auf Github gleich gezogen. Bitte mal versuchen.
Hab das grade probiert. Das geht! Jetzt werden die Modes bestaetigt. Die Received Messages setzen komischerweise jetzt fast alle den Mode (auf 1).
Thema delay usw:
Das Problem an diesem Vergleich ist, dass er in einer Multitasking-Umgebung klar failed. `
Wenn nodejs "multitasking" arbeiten würde hättest Du recht. Tut es aber nicht!!Die asynchrone bzw. "Eventgesteuerte" Logik in node bzw JavaScript allgemein ist Single-Threaded.
Von daher: Das ist korrekt so und macht man so in Nodejs/JavaScript.
Den Fall das "während" einmal "writeQueue" abgearbeitet wird ein zweiter Aufruf erfolgt existiert schlichtweg nicht. Das ist alles streng nacheinander.
Durch das asynchrone "send" und "drain" (wo anderer Code" zwischenrein" laufen kann muss man nur sicherstellen das das writeQueue nicht aufgerufen wird. Daher: Wenn ein neues Kommando in das Array eingefügt wird und damit die Länge 1 ist UND es gerade nicht noch auf send/drain wartet kann sichergestellt writeQueue aufgerufen werden.
Von daher ist der code der das "sendInProgress" nach dem drain und deiner neuen Wartezeit zurücksetzt genau richtig.
Genau diese Stelle war vormals dafuer verantwortlich dass der Delay im writeQueue nicht ging wenn das Flag irgendwann auf false gesetzt wird. Mit dem Setzen am Ende von writeQueue wird zwar das Zeitfenster kleiner, aber es ist nicht weg. Genau deshalb meinte ich ja, dass das false-Setzen oben bei einem Vergleich auf "0" der Queue-Laenge gemacht werden sollte. Da ist das Fenster immer noch nicht weg, aber sicherlich noch viel kleiner (auf die Laufzeit eines Vergleichs und ein paar Zyklen beschraenkt).
Wenn in writeQueue erst mal zweimal "eingesprungen" wurde ists verloren, weil innerhalb dieser Routine kein Ausschluss des anderen Laufs erfolgen kann. `
Siehe oben: kann nicht passieren bzw wird vom code korrekt abgefangen wenn das "sendInProgress" skorrekt zurückgesetzt wird "am Ende" wenn der nächste Call kommen darf.Mit dem Delay haben wir wenigstens irgendeine halbe Loesung. Ich wuerde mich daher jetzt erst mal auf den klaren Mode-Bug beschränken…
Hier wieder ein Logfile des kuerzesten funktionierenden Delays (1s):
...
Was bedeutet LOVF als Antwort? `
Na dann haben wir es mit 1s als Delay.Ok. Übernehme nachher deinen Delay code mit 2s ins Github, dann kannst Du nochmal testen. Mit 2s sollte auch ggf eine bessere Verteilung der Kommunikation stattfinden und vllt weniger LOVF (siehe unten).
https://wiki.fhem.de/wiki/LOVF
… dere Stick sagt das er zu schnell zuviel gesendet hat
Also ich wuerde daraus schliessen dass wir das Delay wirklich groesser machen sollten. Ich nehm jetzt mal 5 Sekunden...
PS: Wofuer sind eigentlich die staendigen X Kommandos gut?
Mit dem Kommando fragt man beim CUL den Stand des Sendelimits ab. Hab aber noch nicht geschaut was der Adapter/Code damit tut. Ich denke Requests selbst delayen oder soMir faellt nur auf dass es jede Menge X Kommandos gibt, wohl ca alle 5 Sekunden eins.
-
Also der Patch fuer den Mode (ToString usw) ist auf jeden Fall zu machen. Der funktioniert!
Support us
428
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge