Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)
-
Das ist der Teil der mir noch nicht gefällt. In jedem Fall braucht man nach einem "X" keine x Sekunden warten weil dieser befehl keine Kommunikation auslöst … oder doch ?! Ich weiss ja nicht warum das Ding crasht
-
Also der Patch fuer den Mode (ToString usw) ist auf jeden Fall zu machen. Der funktioniert!
-
Also im Github ist jetzt folgendes drin:
-
Änderungen für Thermostat Mode …
-
Delays nach dem senden. Bei Kommando "X" 500ms, sonst 2000ms (mal so versuchen)
-
Code der vor dem reinlegen in die Queue schaut ob das gleiche Kommando schon drin ist - wenn nein wird es nicht nochmal reingelegt. SOllte vor allem mehrere "X" verhindern.
Please try
-
-
Also man koennte ja den Delay setzen je nachdem ob das Kommando mit X anfaengt oder nicht….?
-
Die neue Version auf Github macht genau das (Version von nach 22:13 Uhr!!!) siehe letzter Post … Sorry, ggf nochnal updaten bitte
-
Ich glaube der Vergleich mit Kommando X geht nicht:
maxcul.0 2018-03-05 22:13:56.910 debug serial port buffer have been drained
maxcul.0 2018-03-05 22:13:56.909 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 22:13:53.905 debug delayed 2000ms
maxcul.0 2018-03-05 22:13:51.923 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":483,"ack":true,"ts":1520284431918,"q":0,"from":"system.adapter.maxcul.0","lc":1520284431918}
maxcul.0 2018-03-05 22:13:51.905 debug serial port buffer have been drained
maxcul.0 2018-03-05 22:13:51.905 debug Send Packet to CUL: X, awaiting drain event
maxcul.0 2018-03-05 22:13:48.901 debug delayed 2000ms
maxcul.0 2018-03-05 22:13:46.905 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.quota {"val":478,"ack":true,"ts":1520284426898,"q":0,"from":"system.adapter.maxcul.0","lc":1520284426898}
maxcul.0 2018-03-05 22:13:46.904 debug serial port buffer have been drained
maxcul.0 2018-03-05 22:13:46.904 debug Send Packet to CUL: X, awaiting drain event
Der Delay 2000 sollte da nicht stehen, oder?
Habs probiert: Du musst das Kommando trimmen …
Noch was: es waere vielleicht schoen zu sehen wie lang die Queue ist (vielleicht in der delay ausgabe ala delayed 2000ms, 5 in queue)
-
Mein Vorschlag:
CommunicationServiceLayer.prototype.writeQueue = function() {
if (!this._queuedWrites.length) return Promise.resolve(true);
this._queueSendInProgress = true;
var command = this._queuedWrites.shift();
var cmd = command.trim();
var len = this._queuedWrites.length;
return this._serialDeviceInstance.writeAsync(command).then(() => {
env.logger.debug('Send Packet to CUL: ' + cmd + ', awaiting drain event');
return this._serialDeviceInstance.drainAsync()
}).then(() => {
env.logger.debug('serial port buffer have been drained');
var delay = 3000;
if (cmd === 'X') delay = 0;
Promise.delay(delay).then(() => {
env.logger.debug('delayed ' + delay + 'ms, ' + len + ' in queue');
this._queueSendInProgress = false;
return this.writeQueue();
});
});
};
Delay = 0 bei X geht, hab ich probiert.
Fuer mich sehen die Antworten auf die Delays deutlich weniger kritisch aus wenn sie groesser sind, da X jetzt nicht mehr drin ist verzoegert das auch nicht wirklich was. Bei vielen Kommandos bekommt man sowieso per LOVF eins auf die Muetze, da kann man gleich von Haus aus laenger warten.
Meine Idee vom Anfang bestaetigt sich irgendwie, Kommando schicken, dann warten (zwischendrin ACK bekommen), dann naechstes Kommando schicken.
Laut irgendeinem Artikel ist die laengste Zeit fuer ein Kommando + ACK bei ca 2,1 Sekunden. Also sollten wir wenigstens 3 Sekunden warten (als Puffer).
-
Hi,
dann hast Du zu früh installiert gehabt
Seit der "Version von nach 22:13 Uhr!!!" vergleiche ich einfach das erste Zeichen Habe jetzt Delay auf 0 gesetzt.
Habe Queue längen-Logging an mehreren Stellen eingebaut.
3000ms als Standard Delay übernommen.
AN sich sollte es nicht nötig sein auf das Ack zu warten … aber ehrlich: Mir egal :-))
Wenn andere User damit Probleme haben melden Sie sich (hoffentlich).
Please try Github version.
-
Bin leider erst jetzt dazu gekommen.
Wenn ich das richtig sehe ignorierst Du auch Zs Kommandos wenn sie schon in der Queue sind?
Jetzt die Frage die kommen musste:
Waere es kompliziert den Delay-Wert in der Konfiguration fuer den User einstellbar zu machen? Ich meine ich kann einfach die Stelle im Code editieren, aber das ist ja eigentlich nicht wirklich der Weg von ioBroker …
Ausserdem koennte es ja verschiedene Hardware geben die auch komplett unterschiedlich reagiert. Irgendwas braucht vielleicht gar kein Delay...
-
Bin leider erst jetzt dazu gekommen.
Wenn ich das richtig sehe ignorierst Du auch Zs Kommandos wenn sie schon in der Queue sind? `
Ich ignoriere alles was schon in der Queue ist - damit auch Zs Kommandos, aber nur wenn die komplette Message schon drin ist. Am Ende will ich nur sicherstellen das ggf retries oder nicht rausgehen wenn die originale Message noch nicht mal draussen ist
Jetzt die Frage die kommen musste:
Waere es kompliziert den Delay-Wert in der Konfiguration fuer den User einstellbar zu machen? Ich meine ich kann einfach die Stelle im Code editieren, aber das ist ja eigentlich nicht wirklich der Weg von ioBroker …
Ausserdem koennte es ja verschiedene Hardware geben die auch komplett unterschiedlich reagiert. Irgendwas braucht vielleicht gar kein Delay... `
Geht grundsätzlich, würde jetzt das mal so releasen und auf weiteres Feedback anderer User warten -
Die Idee warum ich das mit der User-Config auch frage liegt auch darin, dass man in dem Dropdown Menu dann verschiedene Standard-Werte fuer verschiedene Hardware vorgeben koennte.
Wenn ein nicht-nanoCUL beispielsweise kein Delay braeuchte koennte man:
<delay-feld>0 (supercoole Hardware)
5000 (nanoCUL)
machen…
PS: Bisher laeuft alles gut.
Ich betreibe jetzt 15 Thermostate und 13 Fensterkontakte ziemlich problemlos.
Was mir fehlt ist eine Statistik wo ich ueber die Zeit (sagen wir 24h) sehen kann wie hoch die Credits sind. Das wuerde es ermoeglichen konkret festzustellen wenn man wirklich keine Zeitslots mehr hat oder wann es sich etwas staut...</delay-feld>
-
So, ich habe die Änderungen jetzt als 0.5.2 veröfentlicht. Ist morgen im "Latest".
Für die "Konfigurieren des Delays würde ich Dich bitten noch ein Github Issue anzulegen. Danke!
-
Hinsichtlich der Delays gaebe es da noch eine Frage:
Wenn im Moment ein Kommando gesendet wird und als Antwort ein LOVF kommt bedeutet das ja, dass das Kommando effektiv weggeworfen wurde. Koennte man aus den sonstigen uebergebenen Werten beim LOVF nicht erkennen wie lange man eigentlich warten muesste bevor ueberhaupt wieder ein Kommando tatsaechlich gesendet werden kann? Jetzt wo die Delay-Funktion da ist koennte man diese ja auch nutzen um in diesem Fall zu warten bis tatsaechlich wieder ein Kommando absetzbar ist… ?
-
Wie kann ich im lib/communication-layer.js den Wert von info.quota rausfinden?
Ich moechte beim Warten in der Queue zumindest ausgeben wie der aktuelle Credit steht …
-
In Zeile 86 kommen die an und werden dann als Event "creditsReceived" zu maxcul.js gegeben und der gibt es weiter an iobroker-Adapter.
Also wenn dort in Zeile 86 im communication-layer.js
-
Wuerdest Du zustimmen, dass es gar keinen Sinn macht ein gequeuetes Paket zu senden wenn die Credits nicht reichen (also wahrscheinlich unter ca 220 sind)?
-
Also zu den "credits" was ich von FS20 und CUL weiss ist:
900 ist glaube die ms pro 15 Minuten die erlaubt sind (4*900=3600=36s was 1% der Stunde sind).
Eine FS20 nachricht dauert mindestens 220ms, also ja unter 220 macht keinen Sinn.
Wenn man das mal für Max! googelt dann finde ich z.B. das hier: https://groups.google.com/d/msg/CUL-fan … pJu9Uy9GEJ
Das würde bedeuten das eine Max!-Nachricht 109ms dauert/kostet ... denke die Wahrheit liegt irgendwie dazwischen :-)) kannst ja mal explizit einwas senden und schauen wie sich das Limit verhält.
-
Das hier verstehe ich nicht:
maxcul.0 2018-03-12 19:13:56.476 debug LOVF: credits=503 maxcul.0 2018-03-12 19:13:56.475 debug incoming raw data from CUL: LOVF maxcul.0 2018-03-12 19:13:56.474 debug serial port buffer have been drained maxcul.0 2018-03-12 19:13:56.455 debug Send Packet to CUL: Zs0b0100401234561b7e310067, awaiting drain event maxcul.0 2018-03-12 19:13:56.448 debug delayed next send by 5000ms (Queue length left = 7, Current Credit = 503) maxcul.0 2018-03-12 19:13:56.383 debug Ignore command because already in queue X maxcul.0 2018-03-12 19:13:51.451 debug redis pmessage io.maxcul.0.* io.maxcul.0.info.limitOverflow {"val":true,"ack":true,"ts":1520878431441,"q":0,"from":"system.adapter.maxcul.0","lc":1520878431441} maxcul.0 2018-03-12 19:13:51.450 debug serial port buffer have been drained maxcul.0 2018-03-12 19:13:51.443 debug LOVF: credits=503 maxcul.0 2018-03-12 19:13:51.442 debug incoming raw data from CUL: LOVF maxcul.0 2018-03-12 19:13:51.422 debug Send Packet to CUL: Zs0b0100401234561b7edc0067, awaiting drain event maxcul.0 2018-03-12 19:13:51.416 debug delayed next send by 5000ms (Queue length left = 8, Current Credit = 503) maxcul.0 2018-03-12 19:13:51.379 debug Ignore command because already in queue X maxcul.0 2018-03-12 19:13:47.498 debug got OK-ACK Packet from 1b7d41 maxcul.0 2018-03-12 19:13:47.497 debug RSSI for Message: -54 maxcul.0 2018-03-12 19:13:47.495 debug decoding Message Z0E0102021B7D41123456000139643128 maxcul.0 2018-03-12 19:13:47.494 debug incoming raw data from CUL: Z0E0102021B7D41123456000139643128 maxcul.0 2018-03-12 19:13:46.413 debug serial port buffer have been drained maxcul.0 2018-03-12 19:13:46.410 debug Send Packet to CUL: Zs0b0100401234561b7d410071, awaiting drain eventWarum bekommt man bei 503 credits einen LOVF zurueck?
geändert: Code in Code-Tags! Homoran(Mod)
-
Also ich sehe da vor allem ein "Ignore command because already in queue X" … also wie lange ist denn das letze "X" Kommando her und wieviel ging danach schon an Kommandos raus? Damit die Frage "wie alt ist das 503" ...
Meine Annahme ist das es mal 503 war dann mehreres gesendet wurde und der CUL ein "LOVF" zurückliefert ... also die 503 ist aaaalt weil zu viel nach dem letzten X kam und damit ist das Logging müll. Man müsste nach jedem Kommando immer ein "X" senden um den aktuellen Status zu bekommen. Wie wäre es damit?
-
So einfach ist das ja nicht. Das LOVF zeigt ja selbst 503 credits. Und daran haengt meine Verwunderung. wie kann das denn sein, dass ein LOVF zurueckkommt und man gleichzeitig 503 credits haette … ?
