@knusterus Doch, Sentry für die HM Instanzen deaktivieren.

@maximinus Ja, zieh die Version auf den letzten Stand.

@thomas-braun [image: 1690130726728-24ec7a6c-206f-46dd-8d55-045d54cac123-image.png] Herzlichen Dank für die rasche Hilfe!

@tp1de Ja es ist der sql Adapter welche diese Probleme verursacht. Meinen ems-esp Adapter habe ich geändert. Damit tritt das Problem jetzt nicht mehr auf. Wenn aber aus der Admin Oberfläche unter Objekte ein ganzer Objektbaum gelöscht wird ( mit SQl / MariaDB enabled States), dann habe ich das gleiche Problem: Die Admin Oberfläche reagiert nicht mehr. Ich bekomme jede Menge Timeouts. Es werden Unter Adapter die "Verfügbaren Version" nicht mehr angezeigt und die Admin Oberfläche reagiert nicht mehr. Ein iob stop / iob start bringt keine Besserung. Nur ein Reboot der (virtuellen) Maschine löst das Problem.

@segway mach es doch so wie hier gezeigt. Weit oben wie es mit dem nativen Eintrag funktioniert und unten wie es abgefragt wird. Probieren geht über studieren.

@marc-berg Vielen Dank! Ja, tatsächlich wurde bei mir auch fast alles aktualisiert, leider werden die Status "rot"/"gelb"/"grün" nicht sauber abgebildet/gepflegt, daher kam meine Verwirrung!

Guten Morgen, Ich habe auch ein Problem mit dem Backitup adapter und Grafana. Diese Fehlermeldung bekomme ich Per E-mail: BackItUp: Your backup was not completely created. Please check the errors!! grafana: {"message":"Request failed with status code 500","name":"AxiosError","stack":"AxiosError: Request failed with status code 500\n at settle (/opt/iobroker/node_modules/iobroker.backitup/node_modules/axios/lib/core/settle.js:19:12)\n at IncomingMessage.handleStreamEnd (/opt/iobroker/node_modules/iobroker.backitup/node_modules/axios/lib/adapters/http.js:570:11)\n at IncomingMessage.emit (node:events:526:35)\n at IncomingMessage.emit (node:domain:489:12)\n at endReadableNT (node:internal/streams/readable:1359:12)\n at processTicksAndRejections (node:internal/process/task_queues:82:21)","config":{"transitional":{"silentJSONParsing":true,"forcedJSONParsing":true,"clarifyTimeoutError":false},"adapter":["xhr","http"],"transformRequest":[null],"transformResponse":[null],"timeout":0,"xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"maxBodyLength":-1,"env":{},"headers":{"Accept":"application/json, text/plain, /","Authorization":"Bearer ****","User-Agent":"axios/1.4.0","Accept-Encoding":"gzip, compress, deflate, br"},"method":"get","url":"http://192.168.178.211:3000/api/dashboards/uid/sF7d-FHZz","responseType":"json","httpsAgent":{"_events":{},"_eventsCount":2,"_maxListeners":100,"defaultPort":443,"protocol":"https:","options":{"rejectUnauthorized":true,"noDelay":true,"path":null},"requests":{},"sockets":{},"freeSockets":{},"keepAliveMsecs":1000,"keepAlive":false,"maxSockets":null,"maxFreeSockets":256,"scheduling":"lifo","maxTotalSockets":null,"totalSocketCount":0,"maxCachedSessions":100,"_sessionCache":{"map":{},"list":[]}}},"code":"ERR_BAD_RESPONSE","status":500} Nun habe ich heute Morgen nochmal ein Backup von Hand gestartet und habe keine Fehlermeldung mehr. Grafana, IoBroker und InfluxDB laufen auf dem selben system. Nun kann es sein das ich die Meldung morgen wieder haben, ich dachte an eine überlastung des Systems. Jedoch langweilt sich die Kiste 24/7. hat jemand eine idee?

@arteck Danke bloß gut das du dich wenigstens über andere lustig machen kannst. Schönen Sontag

@thomas-braun said in Probleme bei Buster 32bit auf Bullseye 64bit Upgrade: Debian buster's EOL is around 2022-08. ... ich weiss, deshalb wollte ich ja updaten ...

@lessthanmore Danke! Anscheinend kommen wirklich nur wenige Daten aus EVCC raus. Über den ioBroker-Adapter habe ich so immerhin die momentanen Leistungsdaten, damit kann ich arbeiten. Es wäre aber dennoch schön, wenn man mehrere Modbus-Clients mit dem Wechselrichter verbinden könnte. Gibt es da keine Möglichkeit?

@marc-berg großartig! so einfach...da bin ich nicht drauf gekommen! Herausforderung gelöst - Klappt prima! DANKE!

@arteck Vielen Dank. Werde ich demnächst mal probieren. Gruß Yoshi

@steinche Ja den Weg gibt es. Und der ist auch bei der Beschreibung des vis-cloud Adapters aufgeführt: "besser ist es, eine neue Webinstanz zu erstellen, die an localhost gebunden ist, und diese Instanz in den Cloud-Einstellungen auszuwählen." Also eine weitere Webinstanz z.B. "web.1" ohne https und Passwort sowie neuer Portnummer (z.b. 8083) installieren und den Zugriff auf localhost beschränken. Dann kann nur noch jemand auf diese Instanz zugreifen, der lokal am Computer/Raspi angemeldet ist. Ein Zugriff über das lokale Netz ist nicht möglich. Diese Instanz über den Cloud Adapter veröffentlichen und den iobroker.net Cloud Zugang mit einem vernünftigen Passwort absichern.

@jackal sagte in Homematic IP Komponenten schalten: @bahnuhr Dein Tipp mit dem Dummy-script war Gold wert. bitte schön. Hättest press_short halt eher schreiben sollen.

@paul53 said in JSON interpretieren: Das return in Zeile 9 verhindert die weitere Iteration. Jawohl, das war es. (Dieses JavaScript ist vielleicht krümelkackerisch... :-) ) Danke! Und danke an alle beteiligten!

Ja, das ist der beste Weg. Eine einfache direkte Verbindung der 2er Version auf die 1er Version haben die leider nicht hinbekommen.

@sigi234 Danke den neuen installer kenne ich, aber dann muss ich ja alles neu aufsetzen oder kann ich einfach meine alte iobroker config sichern (oder den Data Ordner) und wieder zurückspielen inkl. alles Scripte und Einstellungen jedes Adapters etc?

@homoran Das klingt vernünftig. Ich logge mal eine Weile mit history und gucke, was ich finde oder nicht. Danke soweit, melde mich (hoffentlich zu DEM Thema nicht) wieder!

@fredf sagte in [gelöst] Port Multihost: @bahnuhr Bitte hier hin verweisen https://www.iobroker.net/#de/documentation/config/multihost.md Ha,, hab ich wohl die alte erwischt. ;-)