@andreas-9
Also so wie ich das sehe ist das Problem doch einfach, dass die Client ID mit dem falschen Wert befüllt ist.
Bei Dir steht dort shellypmmini-3030f9e92d68. Der Adapter nimmt sich den Geräte-Typ aus dem ersten Teil dieses Feldes und erzeugt deshalb die Datenpunkte für einen Shelly PM Mini. Dieser Geräte-Typ enthält kein Relais und somit gibts dann auch keinen Datenpunkt fürs Schalten. Das erklärt auch warum bei Power und Voltage immer 0 steht, denn beim 1PM liegen diese Datenpunkte im Kanal "Relay0" und nicht wie beim PM in "PM1:0".
Ich bin zuversichtlich, dass alles richtig funktioniert wenn Du shelly1pmg3-3030f9e92d68 als Client ID reinschreibst.

@ulofemi sagte in Gibt es einen Adapter für ecoflow PowerOcean ?:

Jetzt habe ich mir innerhalb des ecoflow_catshape entsprechende heartbeat.xxxxx Datenpunkte angelegt.
Also ein Beispiel: Ich will die erzeugte Momentanleistung der PV Anlage sehen, also unter Objekte in den Ordner ecflow_catshape > 0 > HJ31xxxx navigiert, neuen Datenpunkt anlegen mit dem Namen heartbeat.mpptPwr

Mir ist da doch noch etwas aufgefallen, was nicht ideal ist.
Dadurch, dass Du einen Zustand (Datenpunkt) mit dem Namen heartbeat.mpptPwr angelegt hast, wurde zusätzlich zum Zustand "mpptPwr" implizit auch noch das Objekt "heartbeat" mit undefiniertem Typ erzeugt.
Ich denke es ist im ioBroker nicht angedacht, dass Benutzer Objekte auf diese Weise erstellen. Dieses Objekt "heartbeat" ist so nicht vollständig sauber definiert. Man erkennt das auch daran, dass im GUI (im Expertenmodus) bei diesem Objekt das bearbeiten-Symbol fehlt. Da ist nur das löschen-Symbol.
Das könnte unter Umständen irgendwann mal zu Problemen führen. Es sollte prinzipiell nie ein Objekt (Zustand, Kanal, Ordner, Gerät, ...) mit einem "." (Punkt) im Namen angelegt werden.
Wenn man in einem Gerät einen sogenannten Kanal (eine Art Ordner) haben möchte, dann ist der saubere Weg diesen explizit anzulegen, also in Deinem Fall zuerst in ecoflow_catshape.0.HJ31xxxxx einen neuen Kanal mit dem Namen heartbeat anlegen und danach dann in ecoflow_catshape.0.HJ31xxxxx.heartbeat die Zustände (z.B. mpptPwr) anlegen.
Nebenbei: Prinzipiell müssen die Zustände nicht zwingend in Kanälen sein, sie können genauso gut direkt im Gerät sein. Das ist einer der von mir beabsichtigten Vorteile dieses Adapters, dass man die Zustände selber so anlegen, organisieren und benennen kann wie man möchte.

Es gibt eine einfache Möglichkeit Deine bestehende Struktur zu bereinigen, ohne dass Du das "heartbeat"-Objekt löschen musst (wenn Du "heartbeat" löschst werden auch alle darin bereits angelegten Zustände mitgelöscht und Du müsstest die alle neu anlegen):
In ecoflow_catshape.0.HJ31xxxxx einen neuen Kanal mit dem Namen heartbeat anlegen. Obwohl dieses Objekt bei Dir ja bereits (unvollständig) existiert, sollte das klappen, und danach ist es dann eben vollständig und korrekt angelegt.
Danach empfehle ich Dir noch bei allen Zuständen im Namen (common.name) den Teil "heartbeat." rauszulöschen, also z.B. aus "heartbeat.mpptPwr" --> "mpptPwr" zu machen.

Hoffentlich habe ich es einigermassen geschafft mich präzise und trotzdem verständlich auszudrücken

Hallo zusammen

Erstmal vielen Dank @foxthefox für diesen Adapter. Ich benutze ihn um die Einspeisung meiner PowerStream mit Delta Pro als Speicher zu steuern.

Mir ist dabei aufgefallen, dass in 'adapter_utils.js' das Objekt 'info.reconnects' erzeugt wird (Zeile 166 in Version 0.0.33). Auf der anderen Seite wird in 'main.js' das Objekt 'info.msgReconnects' benutzt (Zeilen 42, 826-828 in Version 0.0.33).
Dies führte bei mir zu entsprechenden Fehlermeldungen während der Adapter lief. Ich habe dann als Workaround manuell das Objekt 'info.msgReconnects' angelegt.

Ich wollte das nur mal melden (sorry falls das bereits jemand anderswo vor mir gemacht hat).

@fs1567
Ich würde Dir empfehlen, das zu machen, was in den Adapter-Instanzeinstellungen steht:

Ich vermute, dass der Adapter den jeweiligen "localKey" Deiner Geräte nicht kennt, oder einen veralteten/ungültigen gespeichert hat. Um die aktuellen "localKeys" zu erhalten, musst Du eben in den Instanz-Einstellungen die Geräte einmalig mit der Cloud synchronisieren.
Ich glaube der "localKey" von einem Tuya-Gerät ist nur solange gültig bis Du das Gerät resettest und/oder neu in die Tuya-App einbindest. Beim ausführen einer solchen Aktion bekommt das Gerät einen neuen "localKey". Und deshalb muss sich der Adapter nach einer solchen Aktion diesen neuen "localKey" auch erstmal wieder aus der Cloud besorgen.

@frederik-buss sagte in Wetterdaten abrufen per API-Call mit dem Javascript Adapter:

Geht! Danke für den Javascript Auffrischungskurs

Gern gemacht.

@frederik-buss sagte in Wetterdaten abrufen per API-Call mit dem Javascript Adapter:

>        if ('rain' in weatherData.current)
>        {
>            if ('1h' in weatherData.current.rain)
>            {
>                setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`,  weatherData.current.rain['1h']);
>            }
>            else {
>                setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`, 0);
>            }
>        }
>        else {
>            setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`, 0);
>        }

Ich wollte Dich auch nicht zugunsten von if (_) {_} else {_} von der kompakten (_) ? _ : _ Variante abbringen.

setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`, ('rain' in weatherData.current) ? (('1h' in weatherData.current.rain) ? weatherData.current.rain['1h'] : 0) : 0);

macht exakt dasselbe wie Dein neuer Code.

@ro75 , @frederik-buss
In meiner Erfahrung ist es beim Programmieren wichtig, dass man wirklich möglichst genau das programmiert, was man erreichen will. Wenn man prüfen will, ob ein Objekt eine Eigenschaft besitzt oder nicht, dann wäre das:

if ('Eigenschaft' in Objekt) ...

und nicht

if (Objekt.Eigenschaft != undefined) ...

oder sonst was mit Objekt.Eigenschaft
Denn Objekt.Eigenschaft liefert einfach nur den Wert von Objekt.Eigenschaft und nur weil dieser Wert undefined ist, heisst das nicht zwingend, dass das Objekt die Eigenschaft gar nicht besitzt, wie das folgende Beispiel zeigt:

const objectBsp = {eigenschaft1: undefined, eigenschaft2: 321, eigenschaft3: 'blabla'};

Offensichtlich besitzt "objectBsp" die Eigenschaft "eigenschaft1" obwohl objectBsp.eigenschaft1 == undefined true ist.

@frederik-buss sagte in Wetterdaten abrufen per API-Call mit dem Javascript Adapter:

@catshape Das hatte ich zwar auch probiert, aber einen Fehler bekommen, wenn nicht definiert. Ich kann nicht über xyz.['123'] abfragen, ob der Schlüssel definiert ist
...

Selbstverständlich kannst Du über weather.current.rain['1h'] abfragen ob der Schlüssel "1h" innerhalb von "rain" definiert ist! (Ich gehe jetzt einfach mal davon aus, dass Du statt xyz.['123'] eigentlich xyz['123'] schreiben wolltest.)

Dass das nur funktionieren kann, wenn 1. der Schlüssel "current" innerhalb von "weather" und 2. der Schlüssel "rain" innerhalb von "current" definiert ist, sollte auch klar sein.
Bei Dir scheint der Schlüssel "rain" nicht immer in "current" vorhanden zu sein.

@frederik-buss sagte in Wetterdaten abrufen per API-Call mit dem Javascript Adapter:

       try {
           setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`, weatherData.current.rain !== undefined ? weatherData.current.rain['1h'] : 0);
       } catch (errorRain) {
           setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`, 0);
       }

Ich würde das so programmieren:

let numberRain = 0;
if ('current' in weatherData) {
    if ('rain' in weatherData.current) {
        if ('1h' in weatherData.current.rain) {
            numberRain = weatherData.current.rain['1h'];
        }
    }
}
setState(`${basePathHMIP}HMIP_Wetter_Aktuell_Regen`, numberRain);

Prinzipiell hat alles was Du in diesem Kommentar beschrieben hast, nicht wirklich etwas damit zu tun, ob ein Schlüssel mit einer Zahl anfängt oder nicht; sprich wie Du anstelle von rain.1h auf die Eigenschaft "1h" zugreifen kannst.
Angenommen der Schlüssel hiesse statt "1h" zum Beispiel "onehour", und Du ersetzt in Deinem Code überall rain['1h'] durch rain.onehour. Dann würde das nichts an eventuellen Fehler-Ausgaben ändern.

@frederik-buss
Beispiel:

const stringJson = '{"current": {"rain": {"1h": 0.4}}}';
const objWeather = JSON.parse(stringJson);
let numberRain = 0;
numberRain = objWeather.current.rain['1h'];
// gleichwertige Alternativen:
numberRain = objWeather['current']['rain']['1h'];
numberRain = ((objWeather['current'])['rain'])['1h'];

@mottimuc
Bitte das nächste mal gleich dazuschreiben wo Du diese Bindung konkret verwendest.

Ich versuche jetzt mal wild zu raten: In der Eigenschaft "Object ID" von einem vis oder vis-2 Widget?

Falls ja, dann kann das nicht funktionieren, da dort eben eine gültige Objekt-ID erwartet wird, also z.B. growatt.0..... Deine Bindung liefert aber eine Zahl welche (selbst in einen String umgewandelt) keine existierende/gültige Objekt-ID darstellt.

Du möchtest ja vermutlich mit der Bindung direkt den Wert liefern, den das Widget anzeigen soll.
Das kannst Du zum Beispiel erreichen indem Du (in vis-2) das Basic Widget "String (unescaped)" verwendest und die Eigenschaft "Object ID" leer lässt und in die Eigenschaft "Voranstellen HTML" (oder "HTML anhängen") zum Beispiel folgende Bindung reinschreibst:

<html><body>{wert1:growatt.0.10356946.devices.0PVPQAED265T01MQ.historyLast.pv1Voltage; wert2:growatt.0.10356946.devices.0PVPQAED265T01MQ.historyLast.pv1Current; (Number(wert1)*Number(wert2)).toString()} W</body></html>

Falls die beiden Datenpunkte vom Typ "Zahl (number)" sind, dann kannst Du in der Bindung das Number(...) jeweils weglassen.
Falls Du eine fixe Anzahl Nachkomma-Stellen willst, ersetzt Du .toString() durch z.B. .toFixed(2) oder wendest sonst eine JavaScript-Formatierung an.

@ramses5333 sagte in Shelly via Cloud einbinden:

@catshape Danke, das hatte ich auch schon in der Google Recherche gefunden und probiert - der Fehler dürfte wohl noch woanders liegen

Falls der Blockly-Baustein "Attribut von Objekt" das nicht von sich aus macht, dann schrittweise/geschachtelt. Das heisst zuerst Attribut "data" vom Objekt "result", dann davon das Attribut "device_status", dann davon das Attribut "meters", dann davon das Attribut "0", dann davon das Attribut "power".
Oder anders gesagt:
Attribut "power" vom Objekt (Attribut "0" vom Objekt (Attribut "meters" vom Objekt (Attribut "device_status" vom Objekt (Attribut "data" vom Objekt "result")))).

@ramses5333
data.device_status.meters.0.power

@milo58
Nur um sicher zu sein noch eine Frage: Wenn die App nicht aktiv ist, dann werden bei DIr in quota gar keine Daten aktualisiert? Also auch nicht der Inhalt von mpptHeartBeat ?

@allodo sagte in Gibt es einen Adapter für ecoflow PowerOcean ?:

Komischerweise scheinen die einzelnen Stringdaten aber immer zu stimmen. Zumindest ist mir auf meinem Monitor mit "Energiefluss erweitert " aufgefallen, dass die beiden Werte addiert scheinbar den korrekten Solarertrag ermitteln. Der eigentliche Solarertrag aber erst nach öffnen der App wieder korrekt übertragen wird.

Interessant - könnte es demnach sein, dass die Cloud einen Teil der Daten gar nicht vom PowerOcean-Gerät selbst, sondern von der App übertragen bekommt?
Sprich das Gerät selbst nur gewisse "Rohdaten" (zum Beispiel mpptHeartBeat.mpptPv) an die Cloud liefert, und die App daraus weitere Daten (zum Beispiel mpptPwr) berechnet und diese dann separat an die Cloud überträgt?
Und heisst das dann, dass die "Rohdaten" immer korrekt aktualisiert werden, auch wenn die App nicht aktiv ist?

Falls dem so ist, wäre das ja eine gute Nachricht, weil man dann ja alles was man braucht aus diesen "Rohdaten" rausholen könnte.

Ich hätte in dem Zusammenhang noch eine Bitte:
Könntest Du mal den Wert vom Datenpunkt quota auslesen und hier reinschreiben (die Seriennummer natürlich unkenntlich machen).
Dann wüsste ich endlich welche Daten in welcher Struktur für PowerOceans überhaupt geliefert werden. Die API-Dokumentation von EcoFlow für die PowerOcean ist da leider ziemlich schlecht.
Ich könnte dann eine Vorlage zum Anlegen der Datenpunkte machen. Analog zu https://github.com/CatShape/ioBroker.ecoflow_catshape/blob/main/doc/PowerStream.json