Das Problem war wohl die VM auf der IO-Broker lief. Die hat kurze Zeit später die Grätsche gemacht und ich durfte alles neu installieren. Aber jetzt läufts erstmal wieder. Trotzdem Danke!

Also ich habe jeztzt folgendes gemacht und zwar ein Multihostsystem. Der Master hat eine neue sd von sandisk klasse 10 und der slave die alte von intenso mit der ich die Probleme hatte. Natürlich habe ich dann die Adapter etwas zwischen den Hosts verteilt. Seitdem hatte ich den Fehler nicht mehr im log. Ich hoffe stark, dass das so bleiben wird…

ich habe nun ein downgrade auf 3.7.5 probiert cd /opt/iobroker iobroker stopnpm install iobroker.javascript@3.7.5 --production iobroker upload adaptername iobroker start Dieser ist fehlgeschlagen. Habe dennoch den Upload-Befehl durchgeführt und siehe da, jetzt komme ich wieder auf die Skripte.

Hallo Das muß man erstmal wissen. :roll: Danke NetFritz

Die fragendste was genau passiert ist. Ich denke das der locken Adapter wegen den Änderungen die Objekte komplett neu geschrieben hat anstellender zu aktualisieren. Dabei gehen die Custom ggf verloren. Oder er hat sie gelöscht und neu geschrieben. Das wäre der gleiche Effekt. Am besten mal ein GitHub issue anlegen mit so genauen Details und Logs wie möglich. Gesendet vom Handy …

Ok, habe jetzt gesehen, dass im IOBroker log folgendes drin steht. Also, wenn ich richtig verstanden habe, muss ich mich mit Funktionen vertraut machen 10725_log_im_iobroker.png

@J Riemann: Im Skript setzt Du die Helligkeit „bright“ mit einem Textbaustein, also String, der Datenpunkt ist aber vom Typ Zahl und muss dementsprechend auch mit einer Zahl gesetzt werden. Wenn Du die Helligkeit mit einem Mathematikbaustein setzt sollte der Fehler verschwinden. ` Und damit hat sich auch das letzte Problem gelöst! :D Nochmals vielen Dank an alle, die mitgedacht haben und ich wünsch euch ein schönes Wochenende! Gruß Johan

Danke AlCalzone! Dein Code hat geholfen. :)

Hmm… das ist schon immer so bei mir gewesen, dass die Werte, die ich auswähle für Blockly nicht dem echten (synchronisierten) Wert entsprechen. Ich dachte es wäre normal. Fand ich auch nicht so wichtig. Für die Funktion hatte das nie einen Einfluss. Hauptsache man wählt die richtige ID aus, finde ich. Aber natürlich wäre es schön, wenn es anders wäre.

@j.kowi: Für alle die es interessiert oder die das selbe Problem haben: Ich habe den Fehler gefunden. Unter "Systemsteuerung - Sicherheit" muss der im Bild markierte Punkt in der CCU abgewählt werden. Dann müssen die IP's und Ports wieder gesperrt werden! Das ist wichtig. Vielen Dank trotzdem führ die Hilfe! ` Besten Dank! Ich bin schon fast verzweifelt

@apollon77: Wo hast Du den Host gewählt? Im Admin generell Oben über den Listen oder im "Instanz hinzufügen Dialog"? Falls zweiteres ist das ein known Bug, dannn bitte ganz oben den Host wählen! ` Danke, ich hatte beim suchen leider nichts dazu gefunden. Jetzt hat es geklappt.

Hallo, bei mir das gleiche Bild. Habe auch versucht dowzugraden und iobroker komplett neu zu installieren - kein Zugriff mehr auf die Skripte. Das Update hatte ich in der Hoffnung eingespielt, dass der Editor nach dem Update auf 4 wieder besser funktioniert - leider hat es sich verschlimmert. Ich hoffe, jemand findet einen work-a-round oder eine Lösung.

So … Problem gelöst ... es lag tatsächlich an der VM. Obwohl die Kontrolle via Date korrekte Zeiten angezeigt hat war im Hintegrund alles defekt. Die VM hat alle paar Sekunden die Zeit neu synchronisiert und Offsets von mehreren Stunden gemacht. Habe zum Testen noch 3 neue VMs gemacht. Debian: gleiche Fehlerbild. Rpi Image: ok. Win7: ok. Habe jetzt erstmals alles auf den Windows Host portiert via IO Broker Fullbackup (was im übrigen wahnsinnig gut funktioniert) ... jetzt klappts auch ohne Probleme mit Kalender und scheduled Skripten. Achtung an alle die auf alter Mac mini Hardware mit Windows Host eine Virtualbox mit einem Debian drin laufen haben :mrgreen:

@Menne: liegt es an der neuen npm Version. ` npm hat definitiv damit zu tun, da es was Rechte angeht sehr pingelig geworden ist. Wir müssen aber lernen, die Dinge richtig zu machen. Sachdienliche Hinweise sind daher immer willkommen. Ok anders formuliert: sudo und npm sind keine gute Kombination. Siehe viewtopic.php?f=17&p=200327#p200327

Danke jetzt wird einiges klarer. Ich hab bisher immer den Adapter solange gelöscht, bis alles wieder richtig war, wobei ich oft nur ein update hätte machen müssen. wenn ich das also richtig verstehe, kann ich bedenkenlos alles aus home/pi/ rauslöschen, was da falsch hingekommen ist. Oder gibt es da einen Befehl, der solche verwaisten Daten aufräumt? Edit: natürlich nicht alles, WiringPi und 433Utils sind ja bewusst da :lol:

Hallo, Fehler ist bis jetzt nicht mehr aufgetreten. Die Schedule, die im Zeitraum zwischen 23:50Uhr bis 00:10Uhr nicht mehr liefen laufen auch wieder, was aber wohl am Neustart des Rechners liegt, der durch das auslösen einer Sicherung verursacht wurde ;). Gruß Steffen

Update 2 Gestern hats mir im Laufe des Tages dann doch wieder die CCU2 abgeschossen. RPi mit ioBroker lief noch. Hab mir dann mal den Log angesehen. Anfänglich traten nur vereinzelt unreach/timout-Meldungen auf, die aber innerhalb von ca. 2 Stunden immer mehr zunahmen, bis dann irgendwann überhaupt keine Verbindung mehr aufgebaut werden konnte (CCU, Lightify ..). Von der CCU2 wurden Programme nicht mehr ausgeführt und über die Weboberfläche war kein Zugriff mehr möglich. Seit gestern Abend läuft der RPi mit ioBroker dann wieder über LAN. Ich werde denn mal berichten, obs damit endlich fehlerfrei läuft. :roll: Aber schon seltsam, dass das Ganze über WLAN scheinbar solche Probleme macht. Zumal ich auch öfter gelesen habe, dass das eigentlich problemlos funktionieren soll.

Das habe ich gemacht hat aber leider nichts gebracht :| Jemand noch eine andere Idee? __Einmalige Reparatur Möchte man die Root Partition nur einmalig während des nächsten Bootvorgangs checken und reparieren, reicht es, im Hauptverzeichnis eine Datei mit Namen forcefsck anzulegen. Der dazu nötige Befehl lautet 1 sudo touch /forcefsck Das funktioniert natürlich nur, wenn der Pi noch starten konnte und ich das Shell Kommando absetzen kann. Immerhin werde so noch offene Dateien wieder ordnungsgemäß geschlossen.__