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

[liv-in-sky]

@apollon77

die heißen so

sensate (DIY sensoren)
mytime (countdown)
time-switch (zeitbasiertes schalten)
phantomjs (screenshots from websites)

ich habe viele deaktivierte instanzen und adapter deinstalliert und die oben genannten 4 liefen und die habe ich pausiert

ich teste lieber noch etwas um sicher zu sein - mal sehen, was der programmiertag heute so bringt - werd die adapter wieder einzeln aktivieren und beobachten - habe momentan kein blockly project, daher dauert es etwas, bis ich wieder neuigkeiten habe- ich kann den fehler leider nicht erzeugen - er kommt, wenn er kommt

habe noch zufällig entdeckt, das mein desktop pc und iobroker verschiedene uhrzeiten hatten - unterschied ca 4-5 sekunden - das war das einzige, was ich am desktop pc geändert habe - aber ich denke mal, dies kann wohl keinen einfluss haben

hier ein bild mit time-switch und mytime in der vis umgesetzt

[crunchip]

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

die nicht-aktivierten, die ich gelöscht habe

Die sollten aber doch sowieso gar keinen Einfluss nehmen, da sie deaktiviert sind.
Ich habe auch etliche deaktivieren Adapter, die aber auch schon vor dem Problem vorhanden und deaktiviert waren.
Adapter, die Einfluss nehmen könnten, wären für mich Adapter die in Blockly auftauchen/abgerufen werden, wie z.b. sayit, telegram bzw alles was mit sendto zu tun hat.
Was ich mir auch vorstellen könnte, die neuen Funktionen/Bausteine, die im blockly dazu kamen, dass diese Probleme bereiten.
Wenn ich am WE dazu komme, werde ich mit verschiedenen Admin Versionen mal testen.

[Stormbringer]

Glaub ich hab was gefunden... Aber noch ohne Langzeittest.

An alle die den Speicherfehler haben.. Verwendet ihr den dunklen Anzeigemodus?

[saeft_2003]

@Stormbringer

nein ich verwende den hellen und habe den Speicherfehler. Meinst du es liegt daran?

[Stormbringer]

@saeft_2003 Bei mir tritt er komischerweise nur beim Dunklen bis jetzt auf und den hab ich seit Einführung nur verwendet. Nach Browser Cache leeren und auf Hell stellen gehts, wenn ich wieder auf Dunkel stell spinnt er wieder. Wie gesagt ist noch kein Langzeittest aber momentan wirkt es so.... Allerdings mit Chrome (socketio 3.0.9), Safari mag er gar nicht mehr. Spätestens seit der Beta Version von Soket io 3.0.10 kann ich keine Variablennamen mehr ändern. Da springt der ganze Bildschirm nach oben. Das hat aber sonst keiner oder?

Spoiler

[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...