NEWS
Maxcul ist komplett unbrauchbar (geloest mit 0.5.2)
-
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!
-
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….?
-
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>
-
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 …
-
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)?
Support us
721
Online32.4k
Benutzer81.6k
Themen1.3m
Beiträge