NEWS
Möglicher Bug im javascript Adapter bei createState()
-
Wenn ich es richtig verstanden habe sollte sich createState() so verhalten, dass ein State nicht neu angelegt wird, wenn dieser schon existiert. Eine Außnahme ist wenn forceCreate=true verwendet wird.
Bei mir habe ich festgestellt, dass in jedem Fall der ein State neu angelegt wird.
Kann das jemand bestätigen?Hierzu ein kleines Testscript:
createState( '0_userdata.0.test.state1', {name: 'test state1'}, function() { log('created'); }); createState( '0_userdata.0.test.state2', 0, false, // force {name: 'test state2'}, function() { log('created (force:false)'); });Beide createState() Aufrufe sollten m.E. den State nicht neu anlegen - tun sie aber.
@apollon77 Was meinst du dazu?
@BoehserWolf
Das sind zwei unterschiedliche Datenpunkte '0_userdata.0.test.state1' und '0_userdata.0.test.state2'. Man kann mit createState() beliebig viele unterschiedliche Datenpunkte erzeugen.
createState() verhindert nur das Überschreiben eines bereits existierenden Datenpunktes. Wenn innerhalb eines Scripts createState() mit der gleichen ID unmittelbar hintereinander aufgerufen wird, werden wohl die Eigenschaften des zweiten Aufrufs erzeugt, da die Prüfung auf "existiert bereits" negativ ist, denn der erste Aufruf ist noch nicht abgeschlossen (asynchrone Ausführung). -
@BoehserWolf
Das sind zwei unterschiedliche Datenpunkte '0_userdata.0.test.state1' und '0_userdata.0.test.state2'. Man kann mit createState() beliebig viele unterschiedliche Datenpunkte erzeugen.
createState() verhindert nur das Überschreiben eines bereits existierenden Datenpunktes. Wenn innerhalb eines Scripts createState() mit der gleichen ID unmittelbar hintereinander aufgerufen wird, werden wohl die Eigenschaften des zweiten Aufrufs erzeugt, da die Prüfung auf "existiert bereits" negativ ist, denn der erste Aufruf ist noch nicht abgeschlossen (asynchrone Ausführung).@paul53 said in Möglicher Bug im javascript Adapter bei createState():
@BoehserWolf
Das sind zwei unterschiedliche Datenpunkte '0_userdata.0.test.state1' und '0_userdata.0.test.state2'. Man kann mit createState() beliebig viele unterschiedliche Datenpunkte erzeugen.Ja das ist soweit klar.
createState() verhindert nur das Überschreiben eines bereits existierenden Datenpunktes. Wenn innerhalb eines Scripts createState() mit der gleichen ID unmittelbar hintereinander aufgerufen wird, werden wohl die Eigenschaften des zweiten Aufrufs erzeugt, da die Prüfung auf "existiert bereits" negativ ist, denn der erste Aufruf ist noch nicht abgeschlossen (asynchrone Ausführung).
Ok auch klar.
Denke ich habe mich wohl nicht eindeutig ausgedrückt.
Also, ich habe ein selbst erstelltes Script, das beim Start ohne jegliche Abfrage createState() Aufrufe ohne forceCreate enthält. Nachfolgend reagiere ich in dem Script auf HM States mit on(...) und setze vorher erzeugte States entsprechend. Soweit so gut und funktioniert.
Beim Neustart des Scripts bzw. der JS Instanz bzw. des iobrokers ist mir aufgefallen, dass die von mir erzeugten States nicht korrekt gesetzt werden obwohl alle HM states passen und die vorher korrekt gesetzten eigenen States richtig standen.
Dann habe ich angefangen zu suchen und festgestellt, dass die createState() Aufrufe beim Neustart des Scripts die vorhandenen States überschreiben obwohl sie das nicht sollten.Daher habe ich obiges Beispiel zusammen gezimmert um das vermeintliche Problem zu reproduzieren. Das heißt, wird obiges Script 1x ausgeführt, werden beide States erzeugt. Der 1. State ist implizit ohne forceCreate, der 2. State ist explizit ohne forceCreate. Von beiden States erwarte ich, dass die States beim 2. Script NICHT neu gesetzt werden. Das passiert jedoch und sollte nach meinem Verständnis so nicht sein - oder doch?
-
@paul53 said in Möglicher Bug im javascript Adapter bei createState():
@BoehserWolf
Das sind zwei unterschiedliche Datenpunkte '0_userdata.0.test.state1' und '0_userdata.0.test.state2'. Man kann mit createState() beliebig viele unterschiedliche Datenpunkte erzeugen.Ja das ist soweit klar.
createState() verhindert nur das Überschreiben eines bereits existierenden Datenpunktes. Wenn innerhalb eines Scripts createState() mit der gleichen ID unmittelbar hintereinander aufgerufen wird, werden wohl die Eigenschaften des zweiten Aufrufs erzeugt, da die Prüfung auf "existiert bereits" negativ ist, denn der erste Aufruf ist noch nicht abgeschlossen (asynchrone Ausführung).
Ok auch klar.
Denke ich habe mich wohl nicht eindeutig ausgedrückt.
Also, ich habe ein selbst erstelltes Script, das beim Start ohne jegliche Abfrage createState() Aufrufe ohne forceCreate enthält. Nachfolgend reagiere ich in dem Script auf HM States mit on(...) und setze vorher erzeugte States entsprechend. Soweit so gut und funktioniert.
Beim Neustart des Scripts bzw. der JS Instanz bzw. des iobrokers ist mir aufgefallen, dass die von mir erzeugten States nicht korrekt gesetzt werden obwohl alle HM states passen und die vorher korrekt gesetzten eigenen States richtig standen.
Dann habe ich angefangen zu suchen und festgestellt, dass die createState() Aufrufe beim Neustart des Scripts die vorhandenen States überschreiben obwohl sie das nicht sollten.Daher habe ich obiges Beispiel zusammen gezimmert um das vermeintliche Problem zu reproduzieren. Das heißt, wird obiges Script 1x ausgeführt, werden beide States erzeugt. Der 1. State ist implizit ohne forceCreate, der 2. State ist explizit ohne forceCreate. Von beiden States erwarte ich, dass die States beim 2. Script NICHT neu gesetzt werden. Das passiert jedoch und sollte nach meinem Verständnis so nicht sein - oder doch?
@BoehserWolf sagte:
dass die createState() Aufrufe beim Neustart des Scripts die vorhandenen States überschreiben
Das kann ich nicht nachvollziehen, denn bei mir (JS 4.6.17) verändert createState() an einem existierenden Datenpunkt nichts (gerade getestet).
EDIT: Nochmal mit einem Datenpunkt unter "0_userdata.0" getestet: createState() überschreibt den existierenden Datenpunkt.
Erstelle bitte Issue auf Github. -
@BoehserWolf sagte:
dass die createState() Aufrufe beim Neustart des Scripts die vorhandenen States überschreiben
Das kann ich nicht nachvollziehen, denn bei mir (JS 4.6.17) verändert createState() an einem existierenden Datenpunkt nichts (gerade getestet).
EDIT: Nochmal mit einem Datenpunkt unter "0_userdata.0" getestet: createState() überschreibt den existierenden Datenpunkt.
Erstelle bitte Issue auf Github.@paul53 Vielen Dank fürs Bestätigen.
Issue: https://github.com/ioBroker/ioBroker.javascript/issues/597#issue-632406070Bei mir läuft übrigens derzeit noch JS 2.2.9
-
So, wir haben mal ein bissl an den socket.io ping/pong timeouts rumgespielt ... Dazu checkt bitte mal Admin 4.1.6 ... Also: Admin installieren, Javascript am besten so lassen wie es probleme machte. Dann Auf jeden Fall mal im browser reloaden (hart) ode rbrwoser zu und auf und so ... ... Besser?
Die 4.1.6 NICHT auf GitHub installieren, das geht nicht so simpel ... also kurz warten bis es im Latest Repo auftaucht bitte! Repo Update ist angestossen ... kann aber 1-2h dauern
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
So, wir haben mal ein bissl an den socket.io ping/pong timeouts rumgespielt ... Dazu checkt bitte mal Admin 4.1.6 ... Also: Admin installieren, Javascript am besten so lassen wie es probleme machte. Dann Auf jeden Fall mal im browser reloaden (hart) ode rbrwoser zu und auf und so ... ... Besser?
Die 4.1.6 NICHT auf GitHub installieren, das geht nicht so simpel ... also kurz warten bis es im Latest Repo auftaucht bitte! Repo Update ist angestossen ... kann aber 1-2h dauern
@apollon77 sagte in Möglicher Bug im javascript Adapter bei createState():
Die 4.1.6 NICHT auf GitHub installieren, das geht nicht so simpel ... also kurz warten bis es im Latest Repo auftaucht bitte! Repo Update ist angestossen ... kann aber 1-2h dauern
Schon da.
-
So, wir haben mal ein bissl an den socket.io ping/pong timeouts rumgespielt ... Dazu checkt bitte mal Admin 4.1.6 ... Also: Admin installieren, Javascript am besten so lassen wie es probleme machte. Dann Auf jeden Fall mal im browser reloaden (hart) ode rbrwoser zu und auf und so ... ... Besser?
Die 4.1.6 NICHT auf GitHub installieren, das geht nicht so simpel ... also kurz warten bis es im Latest Repo auftaucht bitte! Repo Update ist angestossen ... kann aber 1-2h dauern
@apollon77 sagte:
wir haben mal ein bissl an den socket.io ping/pong timeouts rumgespielt
Was hat das damit zu tun, dass createState('0_userdata.0.xyz', init, common) einen bestehenden Datenpunkt überschreibt ?
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
@apollon77 sagte:
wir haben mal ein bissl an den socket.io ping/pong timeouts rumgespielt
Was hat das damit zu tun, dass createState('0_userdata.0.xyz', init, common) einen bestehenden Datenpunkt überschreibt ?
-
Ok, nächster Versuoch 4.6.20 ...
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@apollon77
4.6.20: createState('0_userdata.0.xyz', init, common) überschreibt bestehenden Datenpunkt nicht mehr.
764
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge