@docadams Die Glaskugel hat 3 mögliche unabhängige Ursachen gezeigt. Es m6ss nur eine davon zutreffen. In deinem Fall gehe ich von der Einstellung in der Instanz mit den null-Werten aus. die anderen würden Werte erzeugen

@bananajoe Ja, sonoff-Adapter. Aber über PulseTime ist völlig egal was in der Zwischenzeit passiert, selbst der ioB kann sich verabschieden, die Phosphorsäure bleibt schön dosiert 😉 Ich mache eh immer nur 30Sekunden und warte dann 15min bevor ein neues Dosieren möglich ist, falls noch nötig. Ist jetzt im Nachgang Glaskugel gucken was los war, aber anscheinend hat 15min lang die Pumpe Phosphor dosiert 🤬war etwas heftig.

Ist doch alles vollkommen egal. Es geht doch um Info nicht um "wer hat recht".

@ro75 Da bin ich mal gespannt was @emblitz berichtet. Diese enorme Steigerung der vis Darstellung kann nach meinem Verständnis nicht bei historisierten Daten passieren. nur bei States, die durch Redis noch im RAM hängen.

@thomas-braun Vielen Dank!!! Hat funktioniert.

Überzeugt, ist installiert. Damit geht wie erwartet der zigbee2mqtt Adapter. Den habe ich jetzt mit eigenen Dummy MQTT Server eingerichtet, aber ganz richtig ist das jetzt immer noch nicht, denn in meinem zigbee2mqtt docker container habe ich ja immer noch den "alten MQTT server" eingestellt. [image: 1725611463535-d9c06fa8-e036-43d0-a045-8da240b240bb-image.png] Muss ich in zigbee2mqtt nun auf diesen DummyMQTT Server wechseln und kann den anderen MQTT server adapter im Iobroker abschalten? [image: 1725611507595-3ccefd50-0fa3-4eb0-8ea1-f3961bdc47e0-image.png] Das ist die Sicher auf zigbee entities. Die gelbe Schrift soll so nicht oder?

@martinp das deine Kiste kein Tanzboden ist ist dir ja klar. Ich werkel seit 4 Jahren direkt am offenen Herzen. Alles latest. Immer mit Backup im Hintergrund. Extern. Als Jahrzehnte länger winuser wollte ich das auch nicht glauben. Schnell bekehrt. Wie auch Root Zugriff.

@thomas-braun upgrade mit: iobroker upgrade self oder iobroker upgrade all ?

@beowolf Das wäre ein mehrschrittiges Verfahren ... Im Zentrum einen bool - Userdata-Datenpunkt, den man per MQTT-Client-Adapter zugänglich macht... Und dann z. B. bei Setzen auf "true" den Datenpunkt per Blockly wieder zurücksetzen, und mit "exec" den Raspberry herunterfahren ... "shutdown -h" oder "shutdown -h now" wenn man die übliche Wartezeit umgehen will https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/de/blockly.md#exec---kommando Würde vorher in der Konsole testen, ob man sudo braucht - das würde die Sache kniffliger machen....

jetzt läuft der adapter wie es soll, geräte werden eingefügt und in der phoscon app erkannt !!!an und aus , aber zum iobroker nicht gesendet ortner werden nicht erstellt und vorhandene geräte nicht aktualisiert und erstellt .. neues problem ....muss ich mal das nächste problem lösen

@mediastudio Wer ist an deiner bisherigen Lösung der Master? Vermutlich der Gen24, der die beiden Smartmeter abfragt. Das Gateway ist nun ein zweiter Mater, der auch die SM abfragen will. Der Modbus RTU ist aber nicht Multimaster fähig. Du kannst aber evtl. die benötigten Daten per Modbus TCP aus dem Gen24 lesen, wobei ich nicht weiß wie das 2. SM in Gen24 verrechnet wird.

@hansmeier Nein nicht zwingend, kommt drauf an, wohin Du in den Scripten verweist bzw welche Datenpunkte Du benutzt hast (betrifft ja nur Efficiency, YieldTotal, YieldDay und DC Power aus dem AC-Verzeichnis). Beispiel: Du hast ein Wechselrichter Seriennummer 1234567890, dann gibt es ja den Datenpunkt: opendtu.0.1234567890. Und darunter die Verzeichnisse ac, dc, power_control und einige Datenpunkte direkt. Löscht Du die alle und startest die Instanz neu (egal ob durch das Update oder so), dann werden alle Datenpunkt (wie bei einer Neuinstallation) neu angelegt. Da Dein Wechselrichter ja immer noch die Seriennummer 1234567890 hat, wird es auch wieder genauso aussehen wie vorher ;-) Solltest Du also zB in Deinem Script auf opendtu.0.1234567890.ac.power schauen, um die Leistung des WR zu bekommen, dann ändert sich bei Dir nichts. Unterschied ist nur, wenn Du unter dem Punkt opendtu.0.1234567890.ac. die Datenpunkte yieldtotal, yieldday ... ausgewählt hast, dann liegen die jetzt direkt unter opendtu.0.1234567890. Efficiency, YieldTotal, YieldDay and DC Power moved from the AC section to the INV (old data points must be removed manually) Die musst Du natürlich in Deinen Scripten anpassen. Sprich aus opendtu.0.1234567890.ac.yieldday wird opendtu.0.1234567890.yieldday Kleiner Tipp am Rande, eventuell Gedanken über Aliase machen, die Werte die Interessant sind, als Alias anlegen und darauf die Scripts, History, influxdb oder was auch immer schauen lassen. Hat den Vorteil, wenn Du mal (in diesem Fall) den Wechselrichter auswechseln musst, musst Du überall wo Du ihn verwendest die Seriennummer ändern, also den Zugriff anpassen, mit Alias musst nur den Alias einmal anpassen auf den neuen Datenpunkt (neuen Wechselrichter) und alles andere schaut ja auf den Alias-Datenpunkt ;-) Erspart Dir viel Arbeit manchmal...

@djmarc75 Hi DJMarc75, vielen Dank für den hilfreichen Tipp! Da ich bereits SMS-Benachrichtigungen von Amazon erhalten habe, bin ich davon ausgegangen, dass dies bereits die Multi-Factor Authentication oder Zwei-Schritt-Verifizierung gewesen sei und ich dahingehend nicht weiter geschaut habe. Nachdem ich nun die Zwei-Schritt-Verifizierung (wirklich) im Amazon-Konto konfiguriert habe, hat es dann geklappt. Vielen Dank :-) [image: 1725434049768-62c5945f-53ef-465a-9ff0-058ce188616d-image.png] Zwei-Schritt-Verifizierung

Es macht zudem keinen Sinn alles zu zerlegen, wenn man nicht alle Daten braucht. Im Gegenteil manchmal ist es sogar besser zur Weiterverarbeitung, wenn man alle Eigenschaften in einem Objekt hat. Wenn Du aber auf einzelne Datenpunkte beharrst, dann kannst Dir ja meinen NodeRed Flow ansehen, der zerlegt Dir alles in einzelne Datenpunkte:

@thomas-braun und @simatec , vielen Dank Euch beiden und einen schönen Abend. Gruß

@homoran @Thomas-Braun @bahnuhr Vielen, vielen Dank für die tolle Hilfe. Gruß Ralf

@crunchip said in Skripte Error 404: eventuell hilft schon ein iobroker upload javascript Vielen Dank euch. Läuft wieder.

Update: Trockner hat mit eingegebener Uhrzeit gestartet! Danke an alle!

@homoran Sorry, habe dein Edit erst jetzt gesehen. Das ist schon krass. Bei mir läuft IOBroker über x Versionen hinweg und auch auf mehreren Versionen von Node und auf mittlerweile dem dritten OS ohne diese Effekte. Eventuell waren da nur bestimmte Modelle betroffen oder so. Über eine allgemeine Instabilität kann ich zumindest nicht klagen. Das ursprüngliche Problem scheint nach Deinstallation vom Kostal Adapter behoben zu sein. Hab seitdem mehrere Update für Adapter durchgeführt und IOBroker läuft problemlos. Keine Ahnung, was da ursprünglich schiefgelaufen ist. Root-Rechte als Ursache kann ich mir immer noch nicht vorstellen, weil ich eigentlich nie über die Shell etwas an IOBroker geänndert habe, sondern immer nur über den Admin. Erst als das Kind im Brunnen lag kam dann die Shell dazu. ;)