@StrathCole stellt sich immer die Frage, was man eigentlich ausdrücken will:

• Rolladenöffnung / Behanghöhe: klare Bedeutung, je größer dieser Wert desto offener / weiter oben ist der Rolladen oder die Jalousie

• Rolladenposition: keine klare Bedeutung, denn hier muss man definieren wo der Nullpunkt liegt, oben oder unten

• Rolladenverschluss / Verschattungsgrad: klare Bedeutung, denn diese Begriffe sind das genaue Gegenteil von Rolladenöffnung / Behanghöhe, also je größer dieser Wert ist, desto geschlossener / weiter unten ist der Rolladen / die Jalousie

Ich wäre dafür, statt des unklaren / umstrittenen Begriffs "Rolladenposition" im Zuge einer Vereinheitlichung lieber einen klaren Begriff wie "Rolladenöffnung" zu nehmen. Versteht jeder und führt nicht zur Verwirrung.

Allerdings bin ich dafür, bei den Adaptern sowohl den nativen, als auch den Iobroker spezifischen Wert als eigenen Datenpunkt zu haben, denn wenn man jetzt die Vorgaben an eine Vielzahl von Adaptern ändert, müssen auch viele Skripte / Blocklys wieder angepasst werden.

Hallo zusammen,

entschuldigt die vielleicht doofe Frage: Kann man mit dem ioBroker‑Adapter „ioBroker.ankersolix2“ eine Anker Solarbank 3 E2700 steuern, ohne ein zusätzliches Anker‑Smartmeter verbauen zu müssen?

Hintergrund:
Ich habe bereits eine bestehende PV‑Anlage mit 18,21 kWp (ohne Speicher) und denke über eine Nachrüstung nach.

Ich möchte aber keinen großen Installations‑ bzw. Elektriker‑Aufwand machen, und dachte da an ein Steckerfertiges Gerät wie die Solarbank 3.

Da ich meine Energieflussdaten ohnehin schon in ioBroker habe (über mein Fronius Smartmeter), war meine Idee, die Solarbank einfach per Adapter anzusteuern – also vorzugeben, mit welcher Leistung sie gerade lädt oder entlädt (automatisiert per Javascript).

Ist mein Vorhaben mit diesem Adapter möglich?

Dankeschön und viele Grüße,
Marco

Verstehe nicht, was das Problem daran wäre, den Adapterentwicklern zusätzlich zum Datentyp level.blind noch 2 weitere Datentypen level.opened sowie level.closed zur Verfügung zu stellen.

Dann könnten sie den bestehenden Datenpunkt vom Typ level.blind, auf dem sie derzeit ihre Implementierung aufgebaut haben, in einer späteren Adapter-Version auf level.opened oder level.closed umziehen.

Man kann die Entwickler, die derzeit level.blind verwenden ja auch explizit darüber informieren, dass sich hier Schnittstellen ändern und sie ihre Implementierung bitte darauf anpassen sollen, um auch weiterhin kompatibel zu sein.

Das Vorgehen hätte folgende Vorteile:

• Die Semantik des Datenpunkts im Adapter bleibt dieselbe (bei Homematic entspricht ein Wert von 100 % immer noch offen und bei KNX entsprechend geschlossen), man muss sich nicht umgewöhnen, man hat keine Unterschiede des Wertes zwischen Iobroker und der SmartHome-Zentrale (z. B. CCU2) es müssen keine Scripte / Blocklys vom Anwender angepasst werden, Änderung ist für den Anwender schmerzfrei und völlig transparent
• Nach Umzug des Datenpunkts auf level.opened oder level.closed ist auch eine einheitliche Darstellung in der VIS sowie eine einheitliche Steuerung von Rolladensystemen verschiedener Hersteller durch übergeordnete Adapter wie Shuttercontrol möglich, ohne dort zusätzlich definieren zu müssen, wie der Prozentwert zu interpretieren ist, denn der Adapter weiß ja aufgrund des Datentyps, wie er mit diesem umzugehen hat oder was ein Wert von 100 % bedeutet
• Es ist keine Migration mit der Brechstange, der Datentyp level.blind kann ja noch bestehen bleiben, solange noch nicht alle umgezogen sind, er bekommt erstmal nur den Status deprecated und sollte nicht mehr für Neuentwicklungen verwendet werden, denn das Ziel ist ja, ihn irgendwann los zu werden

Danke für die vielen hilfreichen Antworten! Ok, dann weiß ich Bescheid: Ladeleistung per AC ist fix – macht aber nichts, weil mein Überschuss bei der großen PV-Anlage eh meistens deutlich über 800 bzw. 1200 Watt liegt.

Und beim Entladen kann ich ja die Abgabe-Leistung fein steuern, genau das brauche ich, um möglichst das Haus zu versorgen und keinen Strom aus dem Speicher versehentlich einzuspeisen.

Somit wird das Gerät richtig interessant für mich – ich warte dann mal entspannt auf den Black Friday!

@hacki11 Vielen Dank, super, dass die Grundidee so schön umsetzbar ist! Ich glaube, dann warte ich mal auf den Black Friday und werde mir einen Anker Solarbank 3 mit 5,4 kWh zulegen und das versuchen, so umzusetzen.

Nochmal gezielt zur Steuerung:
Heißt das, ich kann im etwa Minutentakt wirklich beides dynamisch steuern – also sowohl, mit welcher Ladeleistung der Speicher auflädt (um Überschuss einzufangen), als auch mit welcher Leistung er entlädt und ins Hausnetz einspeist, wenn kein PV-Überschuss da ist?
Oder geht das nur für die Entladung und das Laden läuft quasi nur als „on (800 Watt) / off (0 Watt)“?

Das mit der Verzögerung finde ich ehrlich gesagt nicht dramatisch, gerade nachts ist der Standby-Verbrauch ja eh ziemlich konstant. Ich würde dann einfach den gleitenden Mittelwert der Einspeisung/Bezug meines Smartmeters berechnen und den Sollwert im Anker-System regelmäßig daran anpassen, mit dem Ziel, den Netzbezug auf null zu bringen.

Ein wenig Reststrombezug nachts ist ja nicht schlimm, ich dimensioniere den Speicher eh sehr klein, damit ich ihn zuverlässig auch an Sommernächten auf jeden Fall leer bekomme, um die Wirtschaftlichkeit zu maximieren. Mir ist nur wichtig, zu vermeiden, dass Strom aus dem Speicher ins Netz eingespeist wird – dafür würde ich zwar 9 Cent/kWh EEG bekommen, aber im Haus ist mir die kWh deutlich mehr wert, weil sie 26 Cent Netzbezug verhindert. Vielleicht schreibe ich das ioBroker-Script einfach etwas konservativer, sodass ein kleiner Netzbezug von etwa 50 Watt konstant gewollt ist – also lieber etwas Bezug als versehentliche Einspeisung durch die Trägheit des Systems.

@uwerlp Vielen Dank für die Info, das hilft mir schon mal enorm weiter! Dann kann ich immerhin schon die Entladeleistung auf meinen aktuellen Stromverbrauch setzen bzw. immer um den Wert korrigieren, der gerade aus dem Haus oder ins Haus fließt.

Ich möchte den Anker Speicher tatsächlich erstmal nur AC-gekoppelt laden, also ohne direkt angeschlossene PV-Module. Laut technischer Daten sollte das ja auch gehen, auch wenn in der Doku meist das klassische Balkonsolar-Szenario (mit PV direkt am Speicher) beschrieben wird. Gerade das Thema mit dem Smartmeter macht mir aber Hoffnung, weil das ja eigentlich auch eine dynamische Steuerung der Ladeleistung ermöglichen sollte – und dann müsste das ja im Idealfall auch mit dem ioBroker-Adapter klappen.

Vielleicht hole ich mir einfach mal so einen Speicher zum Testen. Falls es entgegen meiner Erwartung doch nicht so funktioniert, schicke ich ihn halt innerhalb der 14 Tage wieder zurück. Danke nochmal für den Hinweis!

Hallo zusammen,

entschuldigt die vielleicht doofe Frage: Kann man mit dem ioBroker‑Adapter „ioBroker.ankersolix2“ eine Anker Solarbank 3 E2700 steuern, ohne ein zusätzliches Anker‑Smartmeter verbauen zu müssen?

Hintergrund:
Ich habe bereits eine bestehende PV‑Anlage mit 18,21 kWp (ohne Speicher) und denke über eine Nachrüstung nach.

Ich möchte aber keinen großen Installations‑ bzw. Elektriker‑Aufwand machen, und dachte da an ein Steckerfertiges Gerät wie die Solarbank 3.

Da ich meine Energieflussdaten ohnehin schon in ioBroker habe (über mein Fronius Smartmeter), war meine Idee, die Solarbank einfach per Adapter anzusteuern – also vorzugeben, mit welcher Leistung sie gerade lädt oder entlädt (automatisiert per Javascript).

Ist mein Vorhaben mit diesem Adapter möglich?

Dankeschön und viele Grüße,
Marco

@simatec ah, jetzt verstehe ich, vielen Dank.

Es geht um den Parameter "Automatikbetrieb bei Triggerabweichung", wenn ich den auf "nur Auf" setze, erlaube ich Shuttercontrol nur eine Fahrt nach oben, falls das Rollo gerade in Sonnenschutz-Posotion bei geöffnetem Fenster ist.

Ich verbiete aber umgekehrt dadurch eine Fahrt nach unten in die Sonnenschutz-Posotion, falls das Rollo gerade offen ist bei geöffnetem Fenster.

Habe ich das so richtig verstanden? Dann werde ich das heute mal testen.

Und setzt denn die Automatik auch bei dieser Einstellung wieder ein, nachdem ich das Fenster schließe? Also fährt er dann erneut in die Sonnenschutz-Posotion oder verbleibt er dann bis zum Tagesende in der manuellen Steuerung, nachdem das Fenster einmalig manuell oder durch Öffnen des Drehgriffs hochgefahren wurde?

@simatec ok vielen Dank für die Antwort, ich werde das mal ausprobieren.

Aber laut der Beschreibung zu diesem Parameter finde ich in der Doku folgendes:

Fahren bei Änderung: Pulldown zur Auswahl der Funktion, die bei Bewegung des Griffs durchgeführt werden soll

Aus: keine Bewegung
nur Auf: Beim Öffnen der Tür fährt der Rollladen auf und verbleibt dort
nur Ab: Nach Schließen der Tür fährt der Rollladen auf die Verdunklungsposition
Auf und Ab: Der Rollladen öffnet sich mit der Tür und fährt mit dem Schließen wieder runter

Bin daher nur davon ausgegangen, dass wenn ich "Auf und Ab" verwende das Rollo nur hochfährt, wenn ich den Drehgriff öffne und das Rollo gerade zu war und umgekehrt dass das Rollo runter fährt, aber erst dann wenn ich den Drehgriff wieder schließe.

Dass es aber schließen darf, obwohl der Drehgriff auf offen steht, erschließt sich mir jetzt nicht aus der Beschreibung, im Gegenteil es widerspricht der Beschreibung bei "Auf und Ab", nun verstehe ich ein wenig Bahnhof. Ich probiere es trotzdem mal aus.

Was ich gerne hätte ist, dass das Rollo immer dann auf 30% fährt, wenn die Sonnenachutz-Bedingungen (Innentemperatur, Außentemperatur, Helligkeit und Sonnenstand) alle erfüllt sind UND wenn zusätzlich der Drehgriff geschlossen ist.

Wird der Drehgriff geöffnet soll der Aussperrschutz greifen und es soll jegliche Automatik aussetzen und das solange, wie der Drehgriff geöffnet ist.

Wird der Drehgriff wieder geschlossen, soll der Aussperrschutz deaktivieren und die Automatik soll wieder wie zuvor greifen, das heißt der Sonnenachutz soll wieder aktiv werden.

Wenn beim Öffnen des Drehgriffs auch direkt das Rollo hochgeht ist "nice to have" aber kein Muss.

An welchen Einstellungen muss ich drehen, um diese Anforderungen möglichst gut umzusetzen?

Hallo,

leider haben Shuttercontrol und ich ein paar Anlaufschwierigkeiten:

Und zwar hat heute der Aussperrschutz versagt, der eigentlich aufgrund des geöffneten Fensters den Sonnenschutz aussetzen sollte. Und ich frage mich, war das ein Anwenderfehler von mir oder ein Bug?

Der Fehler ist folgendermaßen entstanden:

• Ausgangssituation: Rolladen der Küchenbalkontür war in Sonnenschutz-Position (30 % Behanghöhe)
• 18:51 Uhr: Frau fuhr manuell (über Taster am Aktor) das Küchenrollo hoch und öffnete die Balkontür (Position vom Drehgriff mit Homematic Fensterdrehgriffsensor von geschlossen auf offen gedreht)
• 18:55 Uhr: Ohne Zutun fuhr der Rolladen wieder auf 30 % Behanghöhe
• 18:58 Uhr: Ich schloss und öffnete anschließend das Küchenfenster -> Folglich öffnete der Rolladen wie gewünscht auf 100 % Behangöhe wegen der Statusänderung am Fensterdrehgriffsensor (vgl. Config "autoDrive": "upDown")
• 19:00 Uhr Ohne etwas geändert zu haben, fuhr erneut der Rolladen wieder auf 30 % Behanghöhe und sperrte meine Frau, die inzwischen auf den Balkon gelaufen war aus, die sich sehr darüber freute, zum Glück war ich noch drinnen und konnte eingreifen

Ich poste mal das zugehörige Log (habe den Adapter anschließend runter gefahren, damit der Haussegen nach diesem Negativerlebnis nicht weiter schief hängt):

2020-06-02 18:51:52.704  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:51:59.036  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) TriggerID changed: hm-rpc.1.LEQ1251236.1.STATE
2020-06-02 18:51:59.039  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) save trigger height: 42%
2020-06-02 18:51:59.039  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Set ID: Rolladenaktor Küche.LEVEL value: 100%
2020-06-02 18:51:59.041  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:51:59.307  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:52:12.194  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:55:00.003  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Sun Azimut: 282.1°
2020-06-02 18:55:00.003  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Sun Elevation: 19°
2020-06-02 18:55:02.009  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Sunprotect for Rolladenaktor Küche.LEVEL is active
2020-06-02 18:55:02.009  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Set ID: Rolladenaktor Küche.LEVEL value: 30%
2020-06-02 18:55:02.009  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) save current height: 30% from Rolladenaktor Küche.LEVEL
2020-06-02 18:55:02.011  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:55:02.199  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:55:21.365  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:58:36.053  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) TriggerID changed: hm-rpc.1.LEQ1251236.1.STATE
2020-06-02 18:58:40.303  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) TriggerID changed: hm-rpc.1.LEQ1251236.1.STATE
2020-06-02 18:58:40.305  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) save trigger height: 30%
2020-06-02 18:58:40.305  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Set ID: Rolladenaktor Küche.LEVEL value: 100%
2020-06-02 18:58:40.306  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:58:40.573  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 18:59:02.912  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 19:00:00.003  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Sun Azimut: 283.1°
2020-06-02 19:00:00.004  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Sun Elevation: 18.2°
2020-06-02 19:00:02.007  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Sunprotect for Rolladenaktor Küche.LEVEL is active
2020-06-02 19:00:02.008  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) Set ID: Rolladenaktor Küche.LEVEL value: 30%
2020-06-02 19:00:02.008  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) save current height: 30% from Rolladenaktor Küche.LEVEL
2020-06-02 19:00:02.009  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 19:00:02.184  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 19:00:10.164  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 19:00:18.365  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) shutter state changed: hm-rpc.1.LEQ0606830.1.LEVEL
2020-06-02 19:00:54.240  - ESC[34mdebugESC[39m: shuttercontrol.0 (16190) system.adapter.admin.0: logging true
2020-06-02 19:02:46.625  - ESC[32minfoESC[39m: shuttercontrol.0 (16190) Adapter is disabled => stop
2020-06-02 19:02:46.626  - ESC[32minfoESC[39m: shuttercontrol.0 (16190) cleaned everything up...
2020-06-02 19:02:46.627  - ESC[32minfoESC[39m: shuttercontrol.0 (16190) terminating
2020-06-02 19:02:46.628  - ESC[32minfoESC[39m: shuttercontrol.0 (16190) Terminated (NO_ERROR): Without reason
2020-06-02 19:02:46.629  - ESC[32minfoESC[39m: host.iobroker "system.adapter.shuttercontrol.0" disabled
2020-06-02 19:02:46.629  - ESC[32minfoESC[39m: host.iobroker stopInstance system.adapter.shuttercontrol.0 (force=false, process=true)
2020-06-02 19:02:46.631  - ESC[32minfoESC[39m: shuttercontrol.0 (16190) Got terminate signal TERMINATE_YOURSELF
2020-06-02 19:02:46.633  - ESC[32minfoESC[39m: host.iobroker stopInstance system.adapter.shuttercontrol.0 send kill signal
2020-06-02 19:02:47.135  - ESC[32minfoESC[39m: host.iobroker instance system.adapter.shuttercontrol.0 terminated with code 0 (NO_ERROR)

Und hier ist meine Konfiguration, habe als Einstellung "triggerChange": "upDown" gewählt, da man hierdurch ja laut Beschreibung in der Doku den Aussperrschutz aktiviert und natürlich habe ich mit "triggerID": "hm-rpc.1.LEQ1251236.1.STATE" auch meinen Homematic Drehgriffkontakt in die Steuerung eingebunden:

{
  "_id": "system.adapter.shuttercontrol.0",
  "common": {
    "name": "shuttercontrol",
    "version": "0.4.3",
    "title": "shuttercontrol",
    "authors": [
      "simatec <nais@gmx.net>"
    ],
    "keywords": [
      "ioBroker",
      "Smart Home",
      "home automation",
      "Rollladen",
      "Jalousie",
      "Rollladensteuerung"
    ],
    "license": "MIT",
    "platform": "Javascript/Node.js",
    "main": "main.js",
    "icon": "shuttercontrol.png",
    "enabled": false,
    "extIcon": "https://raw.githubusercontent.com/simatec/ioBroker.shuttercontrol/master/admin/shuttercontrol.png",
    "readme": "https://github.com/simatec/ioBroker.shuttercontrol/blob/master/README.md",
    "loglevel": "debug",
    "mode": "daemon",
    "type": "climate-control",
    "compact": true,
    "materialize": true,
    "stopBeforeUpdate": true,
    "dependencies": [
      {
        "admin": ">=3.0.0"
      }
    ],
    "installedFrom": "iobroker.shuttercontrol@0.4.3",
    "installedVersion": "0.4.3",
    "host": "iobroker"
  },
  "native": {
    "livingAutomatic": "livingSunriseSunset",
    "W_shutterDownLiving": "22:00",
    "WE_shutterDownLiving": "22:00",
    "WE_shutterUpLiving": "08:00",
    "W_shutterUpLivingMin": "06:30",
    "W_shutterUpLivingMax": "07:00",
    "driveDelayUpLiving": "0",
    "sleepAutomatic": "sleepSunriseSunset",
    "W_shutterDownSleep": "20:00",
    "WE_shutterDownSleep": "21:00",
    "WE_shutterUpSleep": "10:30",
    "W_shutterUpSleepMin": "06:00",
    "W_shutterUpSleepMax": "06:30",
    "driveDelayUpSleep": "10",
    "latitude": "52.520007",
    "longitude": "13.404954",
    "astroDelayUp": "30",
    "astroDelayDown": "30",
    "driveDelayUpAstro": "10",
    "sunProtEndElevation": "8",
    "currentShutterState": false,
    "publicHolidays": true,
    "publicHolInstance": "",
    "triggerAutoSleep": "hm-rpc.0.MEQ1234567.2.STATE",
    "triggerAutoLiving": "hm-rpc.0.MEQ1234567.2.STATE",
    "heightDownSun": "30",
    "direction": "300",
    "type": "in- & outside temperature and direction",
    "directionRange": "60",
    "actualValueTemp": "openweathermap.0.forecast.current.temperature",
    "actualValueLight": "javascript.0.Sonnenverschattung.SonnigInt",
    "actualValueTempInside": "hm-rpc.1.LEQ0997348.1.TEMPERATURE",
    "typeDown": "off",
    "typeUp": "living",
    "triggerStateShutter": "0",
    "triggerChangeShutter": "upDown",
    "triggerDriveShutter": "100",
    "autoDriveShutter": "upDown",
    "heightDownShutter": "0",
    "heightUpShutter": "100",
    "triggerID": "hm-rpc.1.LEQ1251236.1.STATE",
    "events": [
      {
        "enabled": true,
        "shutterName": "Rolladenaktor Küche.LEVEL",
        "name": "hm-rpc.1.LEQ0606830.1.LEVEL",
        "triggerID": "hm-rpc.1.LEQ1251236.1.STATE",
        "typeUp": "living",
        "typeDown": "off",
        "type": "in- & outside temperature and direction",
        "heightDownSun": "30",
        "direction": "300",
        "directionRange": "60",
        "tempInside": "19",
        "tempSensor": "hm-rpc.1.LEQ0997348.1.TEMPERATURE",
        "outsideTempSensor": "openweathermap.0.forecast.current.temperature",
        "tempOutside": "20",
        "lightSensor": "javascript.0.Sonnenverschattung.SonnigInt",
        "valueLight": "100",
        "heightUp": "100",
        "heightDown": "0",
        "triggerState": "0",
        "triggerDrive": "100",
        "triggerChange": "upDown",
        "elevation": "8",
        "autoDrive": "upDown",
        "hysteresisOutside": "10",
        "hysteresisInside": "5",
        "hysteresisLight": "5",
        "currentAction": "",
        "currentHeight": "",
        "triggerHeight": ""
      }
    ]
  }
}

Und außerdem sollte doch eigentlich auch nach dem manuellem Fahren des Rolladens die Automatik deaktiviert sein, war sie aber in diesem Fall nicht.

Könnte mir bitte jemand helfen, ob ich hier noch irgendwo einen (Denk-)fehler bei der Konfiguration habe? Oder liegt hier möglicherweise noch ein Bug in dem Adapter vor?

Vielen Dank!

Verstehe nicht, was das Problem daran wäre, den Adapterentwicklern zusätzlich zum Datentyp level.blind noch 2 weitere Datentypen level.opened sowie level.closed zur Verfügung zu stellen.

Dann könnten sie den bestehenden Datenpunkt vom Typ level.blind, auf dem sie derzeit ihre Implementierung aufgebaut haben, in einer späteren Adapter-Version auf level.opened oder level.closed umziehen.

Man kann die Entwickler, die derzeit level.blind verwenden ja auch explizit darüber informieren, dass sich hier Schnittstellen ändern und sie ihre Implementierung bitte darauf anpassen sollen, um auch weiterhin kompatibel zu sein.

Das Vorgehen hätte folgende Vorteile:

• Die Semantik des Datenpunkts im Adapter bleibt dieselbe (bei Homematic entspricht ein Wert von 100 % immer noch offen und bei KNX entsprechend geschlossen), man muss sich nicht umgewöhnen, man hat keine Unterschiede des Wertes zwischen Iobroker und der SmartHome-Zentrale (z. B. CCU2) es müssen keine Scripte / Blocklys vom Anwender angepasst werden, Änderung ist für den Anwender schmerzfrei und völlig transparent
• Nach Umzug des Datenpunkts auf level.opened oder level.closed ist auch eine einheitliche Darstellung in der VIS sowie eine einheitliche Steuerung von Rolladensystemen verschiedener Hersteller durch übergeordnete Adapter wie Shuttercontrol möglich, ohne dort zusätzlich definieren zu müssen, wie der Prozentwert zu interpretieren ist, denn der Adapter weiß ja aufgrund des Datentyps, wie er mit diesem umzugehen hat oder was ein Wert von 100 % bedeutet
• Es ist keine Migration mit der Brechstange, der Datentyp level.blind kann ja noch bestehen bleiben, solange noch nicht alle umgezogen sind, er bekommt erstmal nur den Status deprecated und sollte nicht mehr für Neuentwicklungen verwendet werden, denn das Ziel ist ja, ihn irgendwann los zu werden

@mjaehrling direkt geht das nicht, aber über einen kleinen Umweg schon:

Setze den Bot mal dorthin, wo er parken soll, dann mach ein relocate, dann merk dir die Koordinaten die in deebotPosition stehen.

Wenn du ihn nun dorthin fahren lassen möchtest, dann errechne dir ein Rechteck ein paar Zentimeter um die gewünschte Parkposition herum, also deebotPosition sei (x, y) dann errechne dir ein Rechteck (x+500, y+500, x, y) und dieses Rechteck schreibst du in den Datenpunkt customArea.

Der Deebot fährt nun dorthin und reinigt diesen 50x50 cm Bereich, sobald der Datenpunkt von cleaning auf Idle wechselt machst du ein pause oder stop und der Deebot wird das zurückfahren an die Ladestation abbrechen und dort in der Nähe des gewünschten Bereichs stehen bleiben.

@StrathCole und meine Idee wäre, dass dieser Datenpunkt im Somfy-Adapter eben genauso bleibt wie er ist, denn dann bricht man auch nicht die Logik bestehender Scripte / Blocklys.

Zusätzlich kann es aber in jedem Adapter Herstellerübergreifend einen Datenpunkt mit einheitlichem Namen und einheitlicher Bedeutung geben, über den man optional den Rolladen steuern kann oder den andere Adapter wie Shuttercontrol, die eine einheitliche Bedeutung von offen und geschlossen erfordern, zur Steuerung nutzen können.

Wäre aus meiner Sicht die eleganteste Lösung eine klare Trennung von Hersteller spezifischen Datenpunkten und vereinheitlichten / Iobroker spezifischen Datenpunkten.