NEWS

Super, ich hab einfach beides gemacht und es hat funktioniert.
Vielen Dank für die Hilfe.

@Chris-D , klingt für mich, dass Du wahrscheinlich mit dem Blocky zu viele Web Anfragen hintereinander an den Shelly schickst und Du damit den "kleinen" Webserver auf dem Shelly überlastest und Du dann ein Timeout erhältst.
Wie sieht Dein Blocky Script aus?

https://forum.iobroker.net/post/435884

Moin,

hab unter Instanzen die rpc und rega neugestartet als auch den Pi neugestartet.

Hab auf rpc 2 geräte einmalig neueinlesen gemacht. Nun tut sich was

Ok funkitioniert nun mit dem neu einlesen 🙂

Danke

@leuchtturm

1.JPG
.

2.JPG

Vielen Dank. 😘

Du hast mir sehr geholfen. 👍

Somit kann das hier geschlossen werden. 👌

@Thomas-Braun sagte in info Adapter rot:

@Segway
Die passenden Adapter-Versionen zur laufenden node Instanz wirken manchmal Wunder.

Jau da sagste was. War mir sicher ich hab das neueste, zumal auch nix angezeigt wurde aber gut - länger mal warten nächstes Mal 🙂

Muss mir selbst antworten. Hab es gefunden.

Falls andere es auch suchen:

habe die Startwerte auf 0 gesetzt im Datenpunkt den Adapter gestoppt Werte unter Objects manuell auf 0 gesetzt Adapter wieder gestartet

@Glasfaser sagte in VIS-Editor plötzlich Englisch:

@Conquest

Hast du den Adapter TrashSchedule installiert , denn dort gab es ein Problem damit !?

vis-editor-sprache-und-darstellung

test-adapter-trashschedule

Ja hatte gestern das Update gemacht. Bin zurück auf 0.0.6. Fehler ist weg. Vielen Dank für deine Hilfe.

@Jan1 alles klar gggg

@Thomas-Braun sagte in [Problem] Hohe CPU-Last auf der NUC:

udisksctl dump

Sorry wurde gestern abgerufen. Hier das Ergebnis, ist aber kein Wunder, denn ich habe den Service deaktiviert und die USB-Festplatte manuel gemounted und in der fstab eingebunden:

thomas@pve:~$ udisksctl dump Error connecting to the udisks daemon: Error calling StartServiceByName for org.freedesktop.UDisks2: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit udisks2.service is masked.

CPU ist jettzt zwischen 6 und 15 %. Damit kann ich leben.

War wohl ein Hardwaredefekt. Ein USB Kabel war defekt und hat wohl den USB Hub außer Funktion gesetzt.

Hallo Zusammen
Debugging funktioniert leider auf meinem Win-Rechner noch nicht. Trotzdem konnte ich den Fehler finden.
Da ich einen BYD Speicher betreibe sind hier die Daten nicht vollständig. -> getStorageRealtimeData schaut mit einem BYD Speicher wie folgt aus.
{
"Body" : {
"Data" : {}
},
"Head" : {
"RequestArguments" : {
"DeviceClass" : "Storage",
"DeviceId" : "0",
"Scope" : "Device"
},
"Status" : {
"Code" : 255,
"Reason" : "battery type 'BYD' is not supported",
"UserMessage" : ""
},
"Timestamp" : "2020-05-18T00:49:59+02:00"
}
}

Wie die Anfrage/Meldung beschreibt könnte der SOC noch ausgelesen werden: https://github.com/iobroker-community-adapters/ioBroker.fronius/issues/34

Finde es aber fast besser wenn für den BYD Speicher ein extra Adapter erstellt wird...

Strahler85 created this issue in iobroker-community-adapters/ioBroker.fronius closed [Feature] SOC BYD Akku #34

Ok danke euch für die schnelle Hilfe 👍

Danke für eure Hilfe! Ich hab das Problem jetzt gefunden, es lag daran, dass die Instanzen admin.0 und discovery.0 ein Falscher Hostnamen zugeordnet war. Diesen wie folgt geändert:

iobroker list instances | grep -o -P "system\.adapter\.[^\.]+\.\d+" | awk '{system("iobroker object set " $1 " common.host=iobroker-hostname")}'

Danach konnte ich die zwei Instanzen wieder deinstallieren und neu erstellen!

P.S.: Ausschlaggebend für die Lösung war übrigens dieser Post:
https://github.com/ioBroker/ioBroker.js-controller/issues/286

DANKE „buanet& AlCalzone “

buanet created this issue in ioBroker/ioBroker.js-controller closed iobroker host this not (fully) working #286