@arteck danke für den Wink mitdem Kirchturm. Hab vor lauter Wald den Baum nicht gesehen zu später Stunde 🤐🙈 damit gelöst 😉 VG

So additional color.... It is for Loxone - I discover the service and it adds fine before I upgrade the Discovery adapter. But after when I go to add my second miniserver, it pops up a 404 on the license agreement.

@apollon77 Danke schneller wärs schon aber dann kann ich nicht mehr zuverlässig speichern. Aber das haben wir ja grad auch auf github 😉

@PatrickFro Wenn Du die Doku mal angesehen hättest, dann wäre Dir auch aufgefallen was Du falsch machst. Befehle einfach abzutippen führt eben nicht immer zum Ziel. @TorstenU Das was Du schreibst ist richtig, steht aber exakt so in der Doku und somit für jeden sofort oben mit dem Link im Forum erreichbar😉

Ich ziehe ein fazit: Also das Kernproblem dieses Themas ist ein Fehler im hosts System. Ich kann nicht sagen wo genau ob es im NPM, Node oder im iobroker selbst ist. Bei mir hat ein Backup > fresh install > restore für die Lösung des Problems gesorgt. Fehler die bei der Prozedur aufgetreten sind: Bei einem manuellen Backup ist drauf zu achten das die sql datein händisch gesichert werden müssen und auf dem neuen System muss natürlich das subsystem mariadb installiert werden sonst mukt der sql Adapter nach dem Backup. Gennerel ist nach dem restore dem iobroker ein wenig zeit zugeben da er sich die Adapter nach und nach aktiv macht wenn alle Pakete vollständig sind. Das kann je nach Hardware ein wenig dauern bei mir ca 20 min. Bei einem automatischen Backup muß nur auf mariadb und letzteres geachtet werden. Ein weiterer (nicht)Fehler: Aufpassen das, dass iobroker System inklusive subsystem nicht zu über züchtet ist und entsprechend der Hardware. Bei einem rest RAM von 15% wird das System instabile und stürzt bei wachsender Anforderungen ab. Das zeichnet sich dann durch ein einfrieren der admin Oberfläche während einer de- oder Installation aus. Auch die ssh Verbindung ist dann nicht möglich. Tip: Bei Usern mit schwachem System empfehlt es sich zur Bearbeitung des Broker vorübergehend nicht gebrauchte Adapter abzuschalten wie MoMa, Info oder Ping. Eine sterbende SD karte mit hoher lesezeit verursacht das gleich Problem. Hier hilft nur eine neue sd karte oder der umstieg auf ein System mit (e)mmc. Mein System ist wieder im gewohnten Umfang fehlerfrei und Einsatz bereit ich habe sogar jetzt das Update auf node 12 und den neusten npm. Top Arbeit. Danke

Problem gelöst. AlCalzone hat darüber hier schon mal letztes Jahr geschrieben. cd /opt/iobroker/node_modules/openzwave-shared sudo -H npm i --production --unsafe-perm nach reboot läuft zwave wieder.

@dslraser Recht schönen Dank an dich! Das war das Problem. ioBroker.iot skill einmal Deaktiviert und dann wieder Aktiviert und Alexa hört wieder auf mich :-)

Danke schon mal für den Input, ist auch eine Option, werde ich als nächstes in Betracht ziehen. @mickym said in MQTT-Client Adapter - Werte irgendwann nicht mehr aktuell: Bist Du Dir denn sicher, dass die Werte auch auf Deinen MQTT-Broker geschrieben werden? - Lösch doch mal Deine mosquitto.db und schau, ob sich dann die Werte wieder aktualisieren. Ja die kommen an, da ich aktuelle werde mit einem anderen MQTT Client (Android) abgreifen kann und bekomme diese aktuell serviert. Ich halte den Threat mal aktuell...

@sigi234 said in WARUM? 1 Adapter löschen - 3 ändern sich: @JB_Sullivan Kann ich bestätigen, es tritt aber nur auf wenn man im Reiter Adapter mit dem Papierkorb-Symbol löscht. Im Reiter Instanzen aber nicht. weil Du dann auch nur die Instanz löschst und nicht den Adapter. Selbst wenn Du keine Instanzen hast - ist der Adapter noch installiert. Es gab wenn man best. Updates gemacht hatte - den Zwang auch Admin, Info, Dev. Disc. upzugraden. Ich kann mir nur vorstellen, dass diese Abhängigkeiten bei Löschen des Adapters auch wieder rückgängig gemacht werden

@janachti sehr gut

@OliverIO Ist allerdings schon an einigen anderen Stellen schon länger (schon immer?) so gewesen. Zumindest stammt der widget-Code aus Zeiten, als es ein separates Widget-Template gab. Die Änderung macht es nur einheitlich an der einen Stelle, wo es noch nicht so war.

warum verwendest du nicht die aktuelle Zigbee Adapter Version 1.0.2 und mach auch noch einen Hardreset in der Instanz, die DB der Geräte befindet sich ebenfalls am Stick! mach als erstes den Hardreset und wenn das nichts hilft probier mal die Version 1.0.2 [image: 1584463884485-c6c742cf-287a-45dc-a63b-1bc7d7ae63c7-grafik.png]

@R1Snake Hast du den Ricksaw Adapter installiert? Den braucht's dazu wenn ich mich recht erinnere

Ja Danke für die Unterstützung. Ich habe erst mal unterschiedliche IDs verwendet.

@ilovegym sagte in Alexa2.0 Absturz nach ioB Neustart: @JB_Sullivan ihr habt aber gelesen, dass die git Version unter Entwicklung ist und daher noch viele Fehler hat?? Die Kategorie heißt ja Error/Bug - also es geht nicht darum, das ich ein produktives System nicht stabil betreiben kann, sondern das ich einen Fehler mit einer bestimmten Version habe, was ja für den Entwickler durchaus interessant sein könnte. .... und da es offensichtlich ja noch jemanden gibt, der das gleiche Problem hat, muss es ggf. in dem Adapter selber, etwas geben, was noch nicht so rund läuft.

@foxriver76 Danke für Deine Antwort Es stört halt nur etwas wenn so eine Warnung auftritt. Wenn man es aber weiß ist ja alles gut. Gruß TM

Hier noch meine finale Antwort: Ich bin von meinem PI3 auf einen PI4 mit 4GB Ram umgezogen (ohne Neuinstallation). Seit dem ist dieses Problem nicht mehr aufgetreten, daher war die Vermutung von @Homoran goldrichtig, dass dem System der RAM in diesen Situationen ausgegangen ist und das System daher nicht mehr reagiert hat.

.kurze Info...habe jetzt den Raspi mangels Zeit einfach mal ein paar Tage in Ruhe gelassen.. Letzter Stand war, dass der Javascriptadapter sich mit Fehlern installieren ließ, aber nicht bei den Adaptern erschien. Eben Interface aufgerufen...siehe da er ist da und grün....Script gestartet...geht Verrückt....selbstheilende Technik.....klasse