Hallo,
Fehler ist behoben. Habe im Forum recherchiert und dort gelesen, dass Anwender das gleiche Problem hatten und daraufhin einen neuen APK-Key erstellt haben
Mit dem neuen Key funktionierte der Zugang auch bei mir wieder.
Vielen Dank an das Forum
Gruß
Thomas Adamski
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.
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
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 :cry:
@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
