@haselchen sagte in Docker - Update vom js-controller?:

pkill -u iobroker

danke dir!

das wäre dann das:
iob backup
pkill -u iobroker
iob update
iob fix
iob upgrade self
iob start

hat bei mir so nun funktioniert.

ich als Kunde war nun komplett aus dem Auto ausgeloggt (keine App, keine API-Abrufe, kein Wächtermodus, neues Passwort im Account) und er ist wieder nicht im deep sleep.
damit kann ich aktuell den Einfluss des Adapters ausschließen, also alles gut hier

@legro hab das Garagentor realisiert, blinkt wunderbar

@negalein nachdem es bei dir wieder läuft, bleib dran!

bei mir ist es nun Grün

wie bekomme ich nun die 2 Kanäle von VZLogger rein?

{
"retry": 0,
"daemon": true,
"verbosity": 10,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": false,
"port": 8080,
"index": true,
"timeout": 0,
"buffer": 0
},
// mqtt client support (if ENABLE_MQTT set at cmake generation)
    "mqtt": {
        "enabled": true,  // enable mqtt client. needs host and port as well
        "host": "192.168.0.153", // mqtt server addr
        "port": 1883, // 1883 for unencrypted, 8883 enc, 8884 enc cert needed,
        "cafile": "", // optional file with server CA
        "capath": "", // optional path for server CAs. see mosquitto.conf. Specify only cafile or capath
        "certfile": "", // optional file for your client certificate (e.g. client.crt)
        "keyfile": "", // optional path for your client certficate private key (e.g. client.key)
        "keypass": "", // optional password for your private key
        "keepalive": 2, // optional keepalive in seconds.
        "topic": "vzlogger/data", // optional topic dont use $ at start and no / at end
        "user": "", // optional user name for the mqtt server
        "pass": "", // optional password for the mqtt server
        "retain": false, // optional use retain message flag
        "rawAndAgg": false // optional publish raw values even if agg mode is used
    },
//Konfiguration der Zähler
"meters": [
{
"enabled": true,
"allowskip": false,
"interval": -1,
"aggtime": -1,
"aggfixedinterval": false,
"channels": [
{
"uuid": "f4bd5310-5be2-11eb-a7f9-8504abf4c6c2",
"identifier": "1.7.0",
"api": "volkszaehler",
"middleware": "http://localhost/middleware.php",
"aggmode": "max",
"duplicates": 40
},
{
"uuid": "031f2460-5be3-11eb-a138-df33cc7e6117",
"identifier": "2.7.0",
"api": "volkszaehler",
"middleware": "http://localhost/middleware.php",
"aggmode": "max",
"duplicates": 40
}
],
"protocol": "oms",
"device": "/dev/ttyUSB0",
"baudrate": 9600,
"key": "mein Code",
"mbus_debug": false
}
]
}

@migoller ich habe die Geo-Zonen nun im Adapter und das fkt. einwandfrei

allerdings ist ein Unterschied von der Reaktionszeit zwischen den Handys erkennbar. iPhone ist schneller als Samsung, Frau steht noch beim öffnenderm Tor, bei mir ist ganz offen.
Habe dazu nun einen zweiten Home-Kreis fürs Samsung gemacht mit mehr Radius, mal sehen ob das die Lösung ist

Auch wenn die die Webpage aufgeben (warum auch immer, Kosten?), dann wird doch hoffentlich die App und API weiter laufen, ist schon eine tolle Sache und eine Alternative hätte ich bisher nicht gefunden, außer Google, aber da muss ein Abbo bezahlt werden.

@goetschhofer habs erst jetzt gelesen, ich habe andere Köpfe im Einsatz, wo ich per Mqtt die Werte bekomme und das funktioniert.

VZLogger habe ich komplett gekillt, das war mir zu sinnlos komplex und unfreundlich.

sollten die Köpfe mal defekt werden oder was anderes sein, kann ich meine Standard USB nehmen und das Script vom Ranzing93

@sneak-l8 der max. Bezug ist mir klar, ich meine die weiteren Einstellung bzgl. Energie-Meter. Oben hat man Bezug und Lieferung eingestellt, für was sind diese?

Name des States für 1. Energy-Meter
Name des States des 1. Energy-Meters, das für die Berechnung des Gesamtverbrauchs für die Leistungsbegrenzung einbezogen wird.

Morgen! Hab versucht das zu verstehen, komme auf den Schluss, dass du damit mehrere Zähler meinst die abgefragt und damit zum Gesamtverbrauch summiert werden, also Bezüge um damit den max. Hausanschluss nicht zu überfahren. Weiteres Indiz dazu ist der letzte Punkt "Verbrauch der WB in keinem der Energie......". Würde heißen, mehrere Zähler die Verbräuche liefern, die WB ist dort aber nicht angehängt, diese ist nur am Netzzähler (ganz oben - Netzbezug / Netzeinspeisung) zu sehen.
Liege ich da richtig?

Wenn ich den Kecontact nun aktiv schalte. Sieht er eine Lieferung und beginnt mit welcher Leistung den Ladevorgang? Meine Zoe nimmt 3P under 8A nichts an. Unterbricht ab eine Netzbezug von 1500W (Wert Ladungsunterschreitung). Regelt bei Überschuss weiter hoch (Schrittweite) und runter.
Mein Amis (Netz-OÖ, Code) Zähler mit WLan-IR Kopf ausgelesen, liefert pro Sekunde die Werte für Bezug und Lieferung. Dh eine Nachregelung erfolgt bei Änderung des Werts, also knapp ne Sekunde, korrekt?

Frage: ist das Hochregeln der Keba-Leistung 1:1 zum Zähler (Lieferung)? Oder hast du eine Drosselung / Verzögerung eingebaut? Mein System mit Amis - WB - Zoe braucht gut 8-10s um eine Änderung umzusetzen - Systemzeit, ca. 18s beim Einschalten bis zur Ladung. Ich habe andere Systeme schon probiert und sehe mich mit einem viel zu starkes Überschwingen (Bezug/Lieferung) konfrontiert. Auch ist die Leistungsaufnahme der Zoe bei 3P nicht linear, dh wenn die Keba 4kW runter soll, geht der Zoe gleich mal 6kW runter usw. Dann habe ich noch starke Verbraucher im Haus (2x Heizung, 2x Boiler, 2x Küche, WM uvm.) die schlagartig draufhämmern. Da muss die Leistung der WB sofort runter, ein kontinuierlicher Anstieg (langsam, verzögert) würde einen Stabilisierung des System bringen und weniger brutale Schwingungen hervorrufen. Etwas mehr ins Netz ist mehr von Vorteil als ein massiv schwingendes System, das mM auch auf die Lebensdauer der jeweiligen Komponenten geht. So meine Überlegung dazu.

@migoller im Adapter sind 15s drin (min.) 0.2.14

mit dem Pro Account ging es jetzt, lt. Anleitung 7 Tage voll dann begrenzt, damit kann ich leben
Danke für den Link!
aber schon lustig, steht ja nirgends dass man Pro braucht und der Adapter iot installiert sein muss...

@wal das Häkchen war schon dran, aber nicht das mqtt.0.*

denke ich habs gefunden, in Node-Red wurde da was falsches aufgerufen, nun ist der Log sauber!

@mickemup sry, war abgelenkt, hatte zuviel zu tun...
ich denke das sind Summen:

getrennt Bezug u Lieferung habe ich

@samson71 komisch ist das schon, OK er liest hier die HW aus, aber die hat 20GB
die Ramriegel wurden nur in der Position getauscht,, da sehe ich einen SW-Fehler bei der Syno, mehr nicht. Der Container im Docker hat nur 4GB zugewiesen, damit denke ich, ist die 23% Auslastung auch nur von den 4GB.

auf der Syno läuft gerade ein Reparieren von einem Speicherpool, daher meine ich sind Buffer (war mal viele GB) und zwischengespeichert so hoch

die Auslastungsanzeige von der Syno und vom ioB haben nichts gemein. oder doch? kA

Heute noch entspannter, das passt jetzt.

es bleibt stabil auf dem Level, denke die Probleme und Ursachen wurden gefunden.
ich werde noch weiter schauen , was ich optimieren kann.

Besten Dank euch!!

die Ram-Ausnutzung wird stetig mehr, ich beobachte es weiter
Ram bis auf 39% hoch und aktuell bei 37%
denke das passt.

@samson71 hab die Speicherriegel der Syno getauscht, da gibt es def. auch SW-Problem, nun sind 16GB Ram wieder verfügbar und das sagt nun der ioB

und alles läuft und ist aktiviert.

@samson71 jap, nur habe ich natürlich mehrere Container im Dock und sogar 20GB sind dann nicht viel.

@samson71 Ja, mehr geht da nicht zum einstellen

kann man noch aus diesen Angaben sagen/erkenne, mehr oder weniger RAM geben?

@thomas-braun OK, danke!

denke das wars für diesen Thread.
JS war überlastet ? durch eine "fehlerhafte" Connection-Abfrage am Mqtt Master.
Ergebnis, zu hohe Auslastung und Ram und Absturtz des übergeorndeten Systems (Docker)

@thomas-braun alles klar, dh ioBroker sieht was da ist an HW (von der Syno) und nimmt was es kriegen kann. Einfluss darauf?

@thomas-braun dh ioBroker hat über den Docker der Syno Zugriff auf die HW der Syno?