UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[hg6806]

@glasfaser
Habe ich gerade ausprobiert. Fehler ist noch immer da.

Ich denke dann liegt es an meinem System.

[Glasfaser]

@hg6806

Teste mal mit einem Browser , den du noch nie mit ioBroker genutzt hast .

bzw. öffne den Admin im Privatmodus mal .

[Homoran]

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

Ich denke dann liegt es an meinem System.

hatten wir schon die Browserkonsole befragt?

[Glasfaser]

@Homoran

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

Was steht in der Browser-Konsole dazu .
bzw. etwas im ioBroker Log.

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

Browser-Konsole muss ich schauen wie und woher man das bekommt, ebenso iobroker-Log.

[hg6806]

@glasfaser

Da kommt folgendes als Fehler:

DevTools failed to load source map: Could not load content for http://192.168.178.18:8081/static/css/5710.41ed5ace.chunk.css.map: Load canceled due to load timeout
DevTools failed to load source map: Could not load content for http://192.168.178.18:8081/adapter/javascript/static/css/62.6133d7c1.chunk.css.map: Load canceled due to load timeout
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_2_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_2_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_3_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_3_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_4_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_4_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_5_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_5_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_6_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_6_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_7_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_7_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_8_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_8_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_9_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Garagenstrom.vor_9_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_2_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_2_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_3_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_3_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_4_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_4_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_5_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_5_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_6_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_6_Wochen
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_7_Monaten
793.b25dfbc1.chunk.js:61 > stateChange 0_userdata.0.Sourceanalytix.Gartenstrom.vor_7_Wochen

[Glasfaser]

@hg6806

Teste mal so mit der Browser-Konsole :
.

[hg6806]

Das ist einiges, deshalb wieder als Text File

Browser-Konsole.txt

[Homoran]

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

Das ist einiges,

alles ERROR?

[hg6806]

@homoran
Nein, nicht ein Fehler.
Nur ein paar Warnings

[Glasfaser]

@hg6806

Dein Log ist überfüllt von

subscribe

Bei der Auswahl des Objekts im Blockly Baustein ,

klapp mal hier alle Ordner zu :

und dann nur als Test den Ordner 0_userdata aufklappen , z.b einen Testdatenpunkt anwählen .

[hg6806]

@glasfaser

Ich habe es jetzt hinbekommen.

Wahrscheinlich war tatsächlich zuviel aufgeklappt, dadurch war das System überlastet.
Kann das sein?

[Glasfaser]

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

Kann das sein?

Meine große Vermutung ist ... ja.
Also nach deinem Log sieht es so aus.
.

@apollon77 dann wäre es auch im javascript Adapter die Begrenzung mit dem Objektbaum !?
oder gehört das Popup zum Admin !?
.

https://github.com/ioBroker/ioBroker.admin/issues/1656

[apollon77]

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

oder gehört das Popup zum Admin !?

Kommt quasi vom Admin ... am besten das Issue erweitern

[Glasfaser]

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

am besten das Issue erweitern

Erledigt .

[apollon77]

@glasfaser Danke!

[hg6806]

OK, danke allen für den super Support!

Quintessenz, also zumindest für meinen Fall, Systemüberlastung durch zuviele offene Datenpunkte und Laden der Werte.

[D-H-H]

@hg6806 said in Javascript - Blockly wird oft nicht gespeichert:

OK, danke allen für den super Support!

Quintessenz, also zumindest für meinen Fall, Systemüberlastung durch zuviele offene Datenpunkte und Laden der Werte.

Scheint mir mir ebenfalls gelegentlich die Ursache gewesen zu sein.

Folgendes löst das Problem bei mir das Kernproblem allerdings sofort und final:

\opt\iobroker\iobroker-data\iobroker.json
"noFileCache" = true

Die darunter liegende Hardware hat 64GB RAM, Intel I7 und SSD. System läuft auf Ubuntu Linux und langweilt sich die meiste Zeit.
Dennoch geschehen diese Speicherfehler unabhängig vom Browser und Plattform, von der aus aufgerufen wird.

Für eine Weile konnte ich den Objektbaum minimieren und die Speicherung funktioniert wieder. Aber bei nun 300+ Skripten (allesamt recht minimalistisch, keine großen dabei) und einem großen KNX System, dass darüber angesteuert wird, half nur noch das Setzen des o.g. Parameters.

Was nun bleibt, ist dass das System nach und nach immer träger wird und das speichern langsam länger dauert. Aber es speichert erstmal wieder und setzt mir die Skripte nicht während der Bearbeitung wieder zurück.

[apollon77]

@d-h-h Hm ... also jetzt müssten wir mal ganz tief schauen ...

noFileCache=true hat ausschliesslich eine Auswirkung auf Server-Seite und auch nur beim Zugriff auf Dateien aus dem iobroker Storage. Alles ist hier nicht relevant.

Bei die r ist auch die Frage ob es im Browser langsam wird oder auf Server seite. ALso du müsstest jetzt mal gaaanz viele Infos, beschreibungen was diu genau meinst , ggf ein Video und sowas bereistellen das wir helfen können.

Fakt ist für mich: Dieses Setting kann an sich für das hier beschriebene Theme KEINE Auswirkung haben

[D-H-H]

@apollon77 Hat es aber. Ohne die beschriebenen Einstellungen werden die verwendeten Browser - Chrome, Vivaldi und Edge - gleichermaßen langsamer. Ein Neustart des ioBroker Servers behebt jedoch alle Speicherprobleme - für eine gewisse Zeit. Egal welcher Laptop, egal welches OS, egal welcher Browser.

Der Server läuft derzeit wieder einige Tage - ich kann nach wie vor Speichern. Der Zeitraum, bis der Speichern Button erscheint, ist nach Änderungen ca. 1-2 Sekunden. Der Zeitraum vom drücken des Speicherbuttons bis zum erfolgreichen speichern ist wieder 1-2 Sekunden. Es geht also nicht "biltzschnell" aber man kann damit arbeiten.

Ohne die o.g. Änderung erscheint der Speichern Button erst gar nicht oder erst nach 1-2 MINUTEN. Teilweise werden Änderungen im Skript einfach wieder rückgängig gemacht und auf den Zustand zurückgesetzt, als das Skript aufgerufen wurde.
Den Speichern Button zu drücken hat manchmal Erfolg - nach 1-5 Minuten - manchmal passiert auch gar nichts. Manchmal setzt er auf Start zurück.

Ich besitze eine eigene Software Entwicklungsfirma - bins ja gewohnt, dass mir Devs sagen "das kann gar nicht sein" und dann in voller Bewunderung selbst vor dem Problem stehen ;)
Vielleicht ist es bei mir ja was anderes als bei den anderen Betroffenen hier - aber die anderen Beschreibungen hören sich für mich stark nach dem gleichen Problem an. Ein immer langsamer werdender Server, bis irgendwann der Cache voll ist.
Unter dem ioBroker liegt bei mir eine High Performance Maschine. Serverplatten im RAID 10. Linux Ubuntu Server 22.x. 64 GB RAM. i7 mit 3,8Ghz. Derzeit keine andren VMs am laufen.
Die Hardware langweilt sich - während das Speichern der Skripte scheinbar in Timeouts läuft.

Das hat mit dem Browser nix zu tun. Fehlermeldungen im Browser sind lediglich, dass die Gegenseite nicht mehr antwortet.
Könnte es sein, dass der Server etwas aus dem Cache laden will und es dort nicht findet? Oder beim Schreibvorgang in den Cache schreibt und der nichts mehr aufnimmt?
Ich kann gern mal einen meiner Frond-End Devs dransetzen.

[DJMarc75]

@d-h-h bin jetzt nicht grad ein Guru oder Developer aber ein Poweruser und kann da nur sagen dass Dein Problem wohl an einem/mehreren "faulen" Skripten liegen könnte... Schleife, Cron,... Hatte Ähnliches Verhalten auch schon und nachdem ich meine Skripte kontrolliert und bereinigt hatte war dieses Verhalten verschwunden. Kann mich aber auch mal wieder täuschen.
VG