UNSOLVED Javascript - Blockly wird oft nicht gespeichert

[apollon77]

Noch eine Frage: Wenn Ihr das Problem habt, habt ihr mehrere Tabs auf? Wenn ihr Adapter habt die veiel Object/State changes generieren kann es natürlich ggf im Browser zu engpässen kommen wiel am Ende ja alle relevanten State changes da hin gemeldet werden ...

[saeft_2003]

@apollon77

Bei mir tritt der Fehler auch auf wenn keine weiteren Tabs offen sind.

Aber... wenn mehrere Tabs im selben Fenster offen sind, tritt es meiner Meinung nach häufiger auf!

[sigi234]

@Holger76 sagte in Javascript - Blockly wird oft nicht gespeichert:

Bei mir kommt es ziemlich oft vor, dass wenn ich nach Änderungen in Blockly - Scripten auf SPEICHERN drücke, alle Änderungen rückgängig gemacht werden. Die Werte springen dann direkt zurück. Wenn ich dann das script schließe und wieder öffne, ist die Änderung auch tatsächtlich nicht durchgeführt.

Kann ich jetzt auch auf Windows bestätigen.
Ebenso das wenn ich ein Blockly neu anlegen will wird es als JS gespeichert.

Platform: Windows
RAM: 7.9 GB 
Node.js: v12.18.0
NPM: 6.14.4
JS Controler: 3.1.6
Admin: 4.1.1
Web: 3.0.9
Script Engine: 4.6.17

[liv-in-sky]

also thema "evtl haben andere adapter einfluß"

wohl eher nicht - es kommt seltener vor - aber es kommt noch vor - hatte es heute schon 2 mal, dass nicht gespeichert wird

ich arbeite immer mit mehreren offenen admin tabs - es fällt auf, dass wenn z.b der object-tab einen kleinen "hänger" hat, dann auch der script-tab das speicher problem hat

@apollon77
die these, das bei vielen object/states anderungen ein problem kommt hört sich für mich ganz gut an

ich würde gerne mal testen, ob mit weniger objecten, das ganze flüssiger läuft - momentan fast 30 000 objecte und 25 000 states

daher wollte ich mal anfragen um die object anzahl zu veringern: ich habe über 5000 objete in meinen 3 javascript instanzen.
die sammeln sich alle in script_enabled. dort sind massig datenpunkte von scripten, die unter einen anderen instanz laufen (evtl durch kopieren von scripten in andere instanzen,...). ist es möglich die javascript instanzen zu stoppen, die script_enabled ordner zu löschen und die javascript instanzen wieder zu starten oder erzeugt das ein totales chaos ?

[apollon77]

@liv-in-sky Hm ... Naja wenn liegt es nicht an der reinen Objektanzahl sondern an Änderungen meistens bei states.

Also man könnte mal versuchen die Skripte die viele Daten aktualisieren zu deaktivieren das da die "Änderungs-Last" zurückgeht ... so würde ich mal anfangen

[liv-in-sky]

@apollon77 ich habe einige scripte, die durch adapter ordner durchlaufen und daten lesen - sind die auch gemeint ?

mir ist kein script bekannt, das viele states setzen würde - aber ich suche nochmal

eigentlich dachte ich, am meisten werden die states von den adaptern gesetzt (z.b mein alexa2.0 hat 2281 datenpunkte oder der unufi adapter fast 1000 - läuft jede minute) - das hat kein script

was definitiv auffällt - der admin hat große probleme , wenn man zu viel und zu oft logs schreibt - z.b. beim scannen einen ordners und sich dort dann alle gescannten datenpunkte loggen läßt - dann steht der script-tab erstmal solange, bis man das log löscht und das script stoppt

[liv-in-sky]

@apollon77

noch eine andere frage - wenn ich die redis datenbank (nur states) öffne werden mir dort 33000 states angezeigt - im iobroker zeigt er jetzt 20 000 (habe mal einige adapter datenpunkte gelöscht(z.b plex, unifi,,...)

ist das normal ?

[liv-in-sky]

@apollon77 was auch immer mal passiert ist der anstieg des speicherverbrauches des object tabs

normal um die 500 aber wenn das system "ziggt" werden es 2000 und die cpu geht auch hoch- nach tab refresh wird es wieder weniger

hier im beispiel gerade geöffnet

[SBorg]

"Wer" ist denn für das speichern generell verantwortlich? Es ist ja nicht nur JS/Blockly. Ich hatte eben wieder den Fall in meiner noch Recht bescheidenen View, dass ich nur ein Widget "Basic Number" hinzufügen wollte. Nach der Auswahl des DPs wollte er wegen der Änderung wieder speichern, was unüblich lange dauerte. Danach war zwar noch das Widget in den Eigenschaften unter W...xyz ausgewählt, aber gänzlich ohne Inhalt und in der Preview war das Widget kpl. weg. Das trat beim frisch gestarteten System/Browser auf. Danach habe ich nur die Seite refresht (also mal kein Cache etc. geleert) und es noch einmal probiert. Funktionierte anstandslos.
Mir sieht das fast so aus, dass man ein Problem bekommt wenn man genau im "falschen" Augenblick speichert...

[liv-in-sky]

@SBorg den eindruck des falschen augenblicks beim speicher kann ich bestätigen

[saeft_2003]

Habt ihr auch das blockly nach dem speichern in die erste Zeile springt, aber trotzdem gespeichert wurde?

Das kommt seit neustens ab und zu bei mir vor...

[liv-in-sky]

@saeft_2003

ob es die erste zeile ist, weiß ich nicht - aber blockly springt bei mir auch

[saeft_2003]

@liv-in-sky

Und ist dann bei dir immer nicht gespeichert?

[liv-in-sky]

@saeft_2003 nein - interessanterweise : wenn es springt kann ich speichern -das springen hat ausser "nerven", weil man wieder zur alten stelle im script zurück muss, keine auswirkung

[saeft_2003]

@liv-in-sky

Ich habe das springen gelegentlich nur direkt nach dem speichern. Zu 80% wurde nicht gespeichert und zu 20% wurde trotz dem springen gespeichert...

[liv-in-sky]

@saeft_2003 stimmt - das springen kommt eigentlich immer nach dem speichern - ob dann nicht gespeichert wird, kann ich dir garnicht sagen - ist mir noch nicht aufgefallen

[dslraser]

@liv-in-sky sagte in Javascript - Blockly wird oft nicht gespeichert:

ich arbeite immer mit mehreren offenen admin tabs

Das mach ich absichtlich nie. (aus Angewohnheit, da es mit einem online Programm, was ich für die Arbeit täglich nutze auch nicht funktioniert)

Wenn ich das mit besagten Programm von meiner Arbeit vergleiche....dort wird mit Sessions gearbeitet, das heißt, ich müsste mich in zwei Fenstern (nicht nur Tabs) separat anmelden, dann funktioniert es. Wenn ich da Tabs nehme und in einem arbeite und dann im zweiten was tun möchte, dann nimmt nach dem nächsten Klick im zweiten Tab dieser den Zustand des anderen an.
Wie sich an dieser Ecke ioBroker verhält weiß ich nicht.

[liv-in-sky]

@dslraser kann ich absolut nachvollziehen

hatte aber vorher nie probleme damit - da das script tab immer lange braucht, bis es öffnet, wäre ein flüssiges arbeiten gar nicht möglich - ich brauche oft den object-tab und den log tab(hab ich mittlerweile in anderen browser) dazu um zu programmieren

wenn ich nur noch mit einem tab arbeiten dürfte, wäre das eine echt immense verschlechterung für mich

aber ich glaube, es wurden schon viele browser getestet und da wird wohl meist nur ein tab auf sein - vermute ich - und die probleme waren auch da

[apollon77]

@liv-in-sky Ja, keiner hat gesagt das in Redis ein Objekt nur einen Key hat Files haben zwei - und werden in Admin nicht angezeigt ... Was mehr ist sind also eher deine Files

[apollon77]

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!