Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[CatShape]

@allodo Danke für den Hinweis. Diese Abhängigkeit hat mir der Adapter-Creator automatisch reingeschrieben. Sorry, ich hatte das bisher gar nicht gesehen. Mein Adapter sollte natürlich auch mit älteren Node Versionen laufen.
Ich habe das nun angepasst --> kannst das installieren nochmals versuchen, müsste jetzt funktionieren.

[Thomas Braun]

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

Bekomme immer diese Fehlermeldung beim installieren

Unabhängig von der Anpassung ist es so langsam an der Zeit die nodejs v18 hinter sich zu lassen.
20 ist schon geraume Zeit die vorgesehene Version und es gibt mittlerweile einige Adapter, die 20 als Mindestversion haben.
Also updaten... Geht mit

iob nodejs-update

ja auch leicht von der Hand.

[Allodo]

@thomas-braun
Ehrlich gesagt habe ich gar nicht auf die Node-js-Version geachtet, da iobroker einen ja immer informiert, wenn etwas aktualisiert werden sollte. Dachte das wäre bei node-js auch der Fall, scheint aber wohl nicht so zu sein :(

[Thomas Braun]

@allodo

Natürlich gibt es Hinweise.

1.)

npm ERR! notsup Not compatible with your version of node/npm: iobroker.ecoflow_catshape@0.0.6
npm ERR! notsup Required: {"node":">= 20"}npm ERR! notsup Actual: {"npm":"9.6.7","node":"v18.17.1"}

2.)

3.) In iob diag

Nodejs-Installation:
/usr/bin/nodejs         v20.18.1
/usr/bin/node           v20.18.1
/usr/bin/npm            10.8.2
/usr/bin/npx            10.8.2
/usr/bin/corepack       0.29.4

Recommended versions are nodejs 20.18.1 and npm 10.8.2
nodeJS installation is correct

4.) Im Forum wird es auch immer angekündigt:
https://forum.iobroker.net/topic/74831/wir-empfehlen-node-js-20-x

[Ralf 8]

Vielen Dank für Deinen Adapter.

Da der ecoflow-mqtt Adapter bei mir nur Daten liefert, wenn ich vorher die Ecoflow-App auf dem Handy aufgerufen hatte, bin ich dafür sehr dankbar.

Kann man auch Daten ändern?

Um Energie-Abgabe aus dem Akku zu regeln,
muss ich am PowerStream den Wert für den Haushaltsstrom
heartbeat.permanentWatts
dynamisch verändern, je nachdem wieviel Strom verbraucht wird.

Leider stellt der Wert sich wieder zurück wenn ich dort einen Wert eintrage.

Gruß
Ralf

[CatShape]

@ralf-8
Ja, dort wo die EcoFlow API das zulässt, lassen sich Werte auch ändern.
permanentWatts ist einer der Werte die sich mittels API ändern lassen.
Damit dies mit meinem Adapter funktioniert, muss der Zustand entsprechend konfiguriert sein:
Wenn Du im ioBroker GUI beim Zustand auf Objekt bearbeiten gehst und dann auf den Reiter OBJEKTDATEN, sollte der Abschnitt native folgendermassen aussehen:

  ...
  "native": {
    "ecoflowApi": {
      "quotaValueKey": "20_1.permanentWatts",
      "valueFactor": 0.1,
      "setValueKey": "params.permanentWatts",
      "setValueData": {
        "sn": "",
        "cmdCode": "WN511_SET_PERMANENT_WATTS_PACK",
        "params": {
          "permanentWatts": 0
        }
      }
    }
  },
  ...

Dann müsste es gehen (Adapter-Instanz neu starten nachdem Du dort etwas änderst).

Wenn es nicht geht, obwohl der Zustand so definiert ist, könnte es daran liegen, dass Du die Adapter-Instanz nicht neu gestartet hast, nachdem Du diesen Zustand angelegt/importiert hast.

[Ralf 8]

@catshape

Habe heute früh versucht, permanentWatts (= Haushaltsstrom) einzustellen:
es benötigt mehrere Versuche, damit der Wert nicht wieder zurückgestellt wird

Muss die Änderung mit der Daten-Aktualisierung des Adapters zusammentreffen?.

Meine Einstellung für
node-cron Zeitplan für die Abfrage der Daten von EcoFlow
ist wie bei Installation auf alle 10 sec. eingestellt.

Wenn ich das per Javascript einstellen möchte, müsste ich den Wert für permanentWatts also mehrmals innerhalb von 10 sek. umstellen und überprüfen, ob der Wert auch dauerhaft geändert wurde. Oder kann man den Adapter per JS steuern, um die Daten sofort zu aktualisieren?

[CatShape]

@ralf-8
Es ist ja so: Der Adapter (die API) kann nicht direkt mit den Geräten kommunizieren sondern nur mit der EcoFlow-Platform. Die eigentliche Kommunikation mit den Geräten macht dann eben die EF-Platform.
In meiner Erfahrung werden Wertänderungen von der Platform sofort an das Gerät weitergegeben - normalerweise dauert das weniger als eine Sekunde. Man kann das testen, indem man im ioBroker etwas ändert, dessen Effekt am Gerät selber direkt sichtbar ist. Zum Beispiel bei einer Power-Station den AC-Ausgang ein- und ausschalten, oder beim PowerStream die Helligkeit des LED-Indikators ändern.
Jetzt kommt aber das, was vielleicht für Verwirrung sorgen kann: Auf der EF-Platform selber werden ja die "aktuellen" Werte des Geräts auch gespeichert. Und nachdem ein Wert auf dem Gerät geändert wurde, meldet das Gerät diesen neuen Wert an die Platform und überschreibt dort den alten Wert. Diese Aktion erfolgt jedoch leider mit etwas Verzögerung. Nach meiner Erfahrung dauert es normalerweise etwa 3 bis 4 Sekunden bis der gespeicherte Wert auf der EF-Platform auf den neuen Wert gesetzt ist. (Ich könnte mir aber durchaus vorstellen, dass das z.B. bei Server-Problemen auch noch länger dauern kann.)

Immer wenn der Adapter die Daten des Geräts von der EF-Platform anfordert, liefert die Platform diejenigen Werte, die in dem Moment dort gerade gespeichert sind. Das ist dann halt kurz nach einer Wertänderung leider immer noch der alte Wert und deshalb siehst Du im ioBroker den Wert auf alt zurückspringen. Spätestens bei der nächsten Daten-Aktualisierung (10 Sekunden später) wird dann aber der "korrekte" neue Wert geliefert und angezeigt. Du musst den Wert im ioBroker also definitiv nur einmal ändern.

[Ralf 8]

@catshape
Vielen Dank. Funktioniert. Zuerst sieht es so aus, als ob der Wert nicht geändert werde.
Nach 10 sec erscheint aber tatsächlich der neu eingestellte Wert!

Darf ich noch eine allgemeine Anfänger-Frage stellen:

Ich habe versucht, für pvToInvWatts einen Alias anzulegen, einfach wegen der Übersichtlichkeit.
In ecoflow_catshape.0.HW51Zxxxxxx.quota stehen ja alle Werte zur Verfügung.

Das klappt für JSON.parse(val).deviceName auch problemlos.

Aber für pvToInvWatts steht in Quota "20_1.pvToInvWatts"
Mit dem Punkt komme ich aber nicht klar, egal wie ich Klammern oder "" oder '' setze:

"alias": {
"read": "JSON.parse(val).['20_1.pvToInvWatts']",
"id": "ecoflow_catshape.0.HW51ZOH4SF6T4876.quota"
}

JSON.parse(val).20_1.pvToInvWatts
JSON.parse(val).[20_1.pvToInvWatts]
JSON.parse(val).['20_1.pvToInvWatts']
JSON.parse(val).'20_1.pvToInvWatts'

alle Versionen funktionieren nicht

[Ralf 8]

@ralf-8 Anfänger-Frage [GELÖST]

Der Punkt musste weg:

falsch: JSON.parse(val).['20_1.pvToInvWatts']

richtig: JSON.parse(val)['20_1.pvToInvWatts']

Hier die vollständigen Objektdaten des Alias

{
  "common": {
    "name": "Test",
    "desc": "Manuell erzeugt",
    "role": "state",
    "type": "json",
    "read": true,
    "write": true,
    "alias": {
      "id": "ecoflow_catshape.0.HW51Zxxxxx.quota",
      "read": "JSON.parse(val)['20_1.pvToInvWatts']"
    }
  },
  "type": "state",
  "native": {},
  "_id": "alias.0.catshape.Test",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1741699783228
}

[CatShape]

@ralf-8
Das wäre dann (EDIT: sehe gerade, dass Du das bereits selber herausgefunden hast)

JSON.parse(val)['20_1.pvToInvWatts']

Prinzipiell wäre die Idee bei diesem Adapter eigentlich für alle Werte die Dich interessieren einen eigenen "gewöhnlichen" Zustand im Gerät anzulegen, also in diesem Fall so etwas:

"ecoflow_catshape.0.HW51ZXXXXXXXXXXX.heartbeat.pvToInvWatts": {
    "type": "state",
    "common": {
      "type": "number",
      "unit": "W",
      "name": "PV to inverter power",
      "desc": "PV to inverter power",
      "read": true,
      "write": false,
      "def": 0
    },
    "native": {
      "ecoflowApi": {
        "quotaValueKey": "20_1.pvToInvWatts",
        "valueFactor": 0.1
      }
    },
    "_id": "ecoflow_catshape.0.HW51ZXXXXXXXXXXX.heartbeat.pvToInvWatts",
    "acl": {
      "object": 1636,
      "state": 1636,
      "owner": "system.user.admin",
      "ownerGroup": "system.group.administrator"
    },
    "from": "system.adapter.admin.0",
    "user": "system.user.admin",
    "ts": 1732458125426
  }

Darauf kannst Du dann bei Bedarf ja noch einen Alias anlegen.

Versteh mich nicht falsch, wenn Du z.B. Zustände "einsparen" willst, kannst Du das natürlich so machen und Dir die Infos direkt aus dem quota-Zustand holen :+1:
Vergiss nicht bei den Instanz-Einstellungen den Haken bei "Update quota state" zu setzen, denn sonst wird dieser Zustand gar nicht aktualisiert.

[ulofemi]

@catshape
Hallo in die Runde,

besten Dank für den Adapter! Ich habe ihn die Woche in der Version 0.0.6 installiert und es hat soweit problemlos geklappt.
Jetzt eine Frage zum PowerOcean, dem WR von EcoFlow. Sehe ich das richtig, dass im quota die Energieerzeugung nicht enthalten ist? Ich versuche die Solarstromerzeugung über das Integral der Leistungsmessungen über den Tag zu berechnen, aber da sind deutliche Abweichungen gegenüber den Daten, die ich in der EcoFlow App sehe. 2 Beispiele:

• Laut App 62.81kWh laut meiner Berechnung 80.4 kWh
• Laut App 43.21kWh laut meiner Berechnung 50.6 kWh

Hat hier jemand Erfahrung mit dem PowerOcean? Wenn ich die Tagesverläufe meiner aufgezeichneten Daten und denen aus der EcoFlow App vergleiche sehen die sehr ähnlich aus, daher würde ich mal annehmen, dass die Datengrundlage dieselbe ist.

Danke für euer Feedback.

[CatShape]

@ulofemi
Ich habe selber keinen PowerOcean, deshalb kann ich da nichts ausprobieren oder testen. Gemäss der API-Dokumentation von EcoFlow (https://developer-eu.ecoflow.com/us/document/powerocean) sind in GetAllQuotaResponse tatsächlich keine Energiewerte enthalten, sondern nur Leistungswerte.
Weil das auch bei all meinen EcoFlow-Geräten (PowerStream, Delta Pro, River Pro) der Fall ist, habe ich im Adapter die Möglichkeit eingebaut, Leistungswerte über den Tag aufzukumulieren, um so (näherungsweise) die entsprechenden Energiewerte zu erhalten ("cumulateDailyByTimeId"-Mechanismus).
Je kleiner das Abfrage-Intervall in der Adaptereinstellung gewählt wird, desto näher müsste dieser kumulierte Wert normalerweise am tatsächlichen Wert dran sein.

Nachfolgend ein paar Beispiele der letzten Tage von meinen Geräten. Mein Abfrage-Intervall der Daten ist */10 * * * * * (alle 10 Sekunden).
Man sieht im letzten Block (Stromverbrauch Kaffeemaschine), dass die Abweichungen durchaus recht gross sein können. Ich erkläre mir diese grösseren Abweichnungen damit, dass die Leistung über den Tag gesehen auf einen sehr kurzen Zeitraum konzentriert ist.

Solar-Ertrag EcoFlow PowerStream (ich benutze im Adapter den eingebauten "cumulateDailyByTimeId"-Mechanismus):

• Wert gemäss EF-App: 3.86 kWh, Adapter: 3.8599 kWh
• Wert gemäss EF-App: 2.72 kWh, Adapter: 2.7067 kWh
• Wert gemäss EF-App: 3.90 kWh, Adapter: 3.8944 kWh
• Wert gemäss EF-App: 3.82 kWh, Adapter: 3.8081 kWh
• Wert gemäss EF-App: 3.79 kWh, Adapter: 3.7745 kWh
• Wert gemäss EF-App: 3.81 kWh, Adapter: 3.8081 kWh
• Wert gemäss EF-App: 3.90 kWh, Adapter: 3.8940 kWh
• Wert gemäss EF-App: 3.96 kWh, Adapter: 3.9594 kWh
• Wert gemäss EF-App: 1.40 kWh, Adapter: 1.3944 kWh
  .

Verbrauchsdaten Shelly PM Mini Gen3 (Kühlschrank) (ich benutze im Adapter den eingebauten "cumulateDailyByTimeId"-Mechanismus):

• Wert gemäss Shelly-App: 626.89 Wh, Adapter: 626.1 Wh
• Wert gemäss Shelly-App: 684.49 Wh, Adapter: 684.5 Wh
• Wert gemäss Shelly-App: 720.28 Wh, Adapter: 722.4 Wh
• Wert gemäss Shelly-App: 760.94 Wh, Adapter: 766.1 Wh
  .

Verbrauchsdaten Shelly PM Mini Gen3 (Kaffeemaschine) (ich benutze im Adapter den eingebauten "cumulateDailyByTimeId"-Mechanismus):

• Wert gemäss Shelly-App: 160.21 Wh, Adapter: 172.3 Wh
• Wert gemäss Shelly-App: 65.92 Wh, Adapter: 92.2 Wh
• Wert gemäss Shelly-App: 131.62 Wh, Adapter: 160.3 Wh
• Wert gemäss Shelly-App: 125.44 Wh, Adapter: 139.7 Wh
• Wert gemäss Shelly-App: 59.30 Wh, Adapter: 57.1 Wh

[ulofemi]

@catshape
Ah, jetzt verstehe ich ein wenig mehr, wie ich die Datenpunkte anzulegen habe. Ich bin was den iobroker angeht noch eher ein Neuling.

Was ich bisher getan habe (mit der Hilfe von GPT): Ich habe unter userdata Datenpunkte angelegt, die ich dann wiederum mit dem Javascript Adapter bespielt habe und das immer, wenn sich quota verändert. Es hat erstmal das getan, was es sollte war aber durchaus umständlicher.

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. Das sieht dann so aus

{
  "common": {
    "name": "heartbeat.mpptPwr",
    "desc": "Manuell erzeugt",
    "role": "state",
    "type": "number",
    "unit": "W",
    "read": true,
    "write": false,
    "def": 0,
    "color": "#ffff00",
    "custom": {
      "influxdb.0": {
        "enabled": true,
        "storageType": "",
        "aliasId": "",
        "debounceTime": 0,
        "blockTime": 0,
        "changesOnly": true,
        "changesRelogInterval": 0,
        "changesMinDelta": 0,
        "ignoreBelowNumber": "",
        "disableSkippedValueLogging": false,
        "enableDebugLogs": false,
        "debounce": 1000
      }
    }
  },
  "type": "state",
  "native": {
    "ecoflowApi": {
      "cumulateDailyByTimeId": "heartbeat.mpptEnergyToday",
      "quotaValueKey": "mpptPwr",
      "valueFactor": 1
    }
  },
  "_id": "ecoflow_catshape.0.HJ31xxxxx.heartbeat.mpptPwr",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1744571910973
}

Als nächstes einen weiteren Datenpunkt anlegen, der in diesem Fall dann "heartbeat.mpptEnergyToday" heißt:

{
  "common": {
    "name": "heartbeat.mpptEnergyToday",
    "desc": "Manuell erzeugt",
    "role": "state",
    "type": "number",
    "unit": "Wh",
    "read": true,
    "write": false,
    "def": 0,
    "color": "#ffff00",
    "custom": {
      "influxdb.0": {
        "enabled": true,
        "storageType": "",
        "aliasId": "",
        "debounceTime": 0,
        "blockTime": 0,
        "changesOnly": true,
        "changesRelogInterval": 0,
        "changesMinDelta": 0,
        "ignoreBelowNumber": "",
        "disableSkippedValueLogging": false,
        "enableDebugLogs": false,
        "debounce": 1000
      }
    }
  },
  "type": "state",
  "native": {},
  "_id": "ecoflow_catshape.0.HJ31xxxxx.heartbeat.mpptEnergyToday",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1744571906335
}

Leider bleibt der Wert der erzeugten Energie noch auf 0 stehen. Falls ich etwas falsch gemacht habe, lasst es mich wissen - oder wird der Wert nur einmal pro Tag geschrieben?

Wenn ich alles richtig gemacht habe und es alles funktioniert, stelle ich meine config gerne dem github Repo zur Verfügung.

[CatShape]

@ulofemi
Alles richtig bis auf ein Detail: Die Eigenschaft "cumulateDailyByTimeId" soll nicht in "ecoflowApi" stehen, sondern direkt in "native". Es sollte so aussehen:

  "native": {
    "cumulateDailyByTimeId": "heartbeat.mpptEnergyToday",
    "ecoflowApi": {
      "quotaValueKey": "mpptPwr",
      "valueFactor": 1
    }
  },

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

Wenn ich alles richtig gemacht habe und es alles funktioniert, stelle ich meine config gerne dem github Repo zur Verfügung.

Das wäre willkommen als Vorlage für andere PowerOcean Besitzer.

[ulofemi]

@catshape
Perfekt, jetzt kommen Daten an, danke.
Ich beobachte es mal ein paar Tage und vergleiche die Werte mit der App.

Eine Sache die mir noch aufgefallen ist beim Starten des Adapters bekomme ich diese Warnmeldung:

ecoflow_catshape.0.HJ31xxxxx.name: native.ecoflowApi.quotaValueKey=deviceName not found in quota received from EcoFlow

Müsste aus der Datei ioBroker.ecoflow_catshape/lib/ecoflow_utils.js aus Zeile 380 stammen

stringA = stringId + ': native.ecoflowApi.quotaValueKey=' + objStateObj.native.ecoflowApi.quotaValueKey + ' not found in quota received from EcoFlow';

Der PowerOcean scheint keinen Key "deviceName" zu enthalten. Ist damit vielleicht sn gemeint? Oder bin ich da auf dem falschen Dampfer?

   "sn":"HJ31xxxx",
   "online":1,
   "productName":"PowerOcean",

[CatShape]

@ulofemi
Ok, werde mir das anschauen.
Gemäss der API-Doku von EcoFlow, wird für jeden Geräte-Typ der Key "deviceName" geliefert. Aber anscheinend stimmt das beim PowerOcean nicht.

Edit:
Ich habe im Adapter jetzt eine kleine Anpassung gemacht, so dass keine Log-Meldungen geschrieben werden, wenn die Keys "deviceName" oder "productName" im quota-JSON fehlen.

Du kannst den Adapter einfach nochmals installieren. Es ist nicht notwendig den Adapter zuvor zu löschen. Auch die bestehende Instanz muss nicht gelöscht und nicht mal gestoppt werden. (Beim Installieren werden bestehende Instanzen automatisch gestoppt und neu gestartet.)

[CatShape]

@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 :-)

[mcm1957]

@catshape

Wenn dein Adapter funktioniert, dann lass ihn bitte in die Repositories aufnehmen. Bis dies erfolgt ist eine Info an alle interessierten User

Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten.

GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird.

Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen.

Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird.

[CatShape]

@mcm1957
Ich habe vor das zu machen.
Im Moment erfüllt mein Adapter noch nicht alle Voraussetzungen dafür. Insbesondere was npm betrifft. Da ich mich bisher noch nie mit npm befasst habe, muss ich mich da erst mal schlau machen.