@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.

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

@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.

@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.

@paul53 nö, die Frage bennent immer noch den Begriff "Rolladenöffnung in %", genauso wie in Facebook der Titel.

Und was macht es für einen Sinn, den Titel einer laufenden Umfrage zu ändern? Diejenigen vor der Änderung beantworten die Frage dann noch anhand des Begriffs "Rolladenöffnung" die anderen anhand des Begriffs "Rolladenposition".

Das Ergebnis ist ein verwaschenes Stimmenbild, bringt euch nicht wirklich weiter.

Alleine schon der Titel der Frage benennt ja den Begriff "Rolladenöffnung in %".

Also ist es aus meiner Sicht klar, je geöffneter der Rolladen ist, desto größer muss auch der Wert der Prozentzahl sein.

Anders wäre es, wenn man nach Begriffen wie "Behanghöhe", "Rolladenposition" usw. fragen würde, da wäre es eben nicht so eindeutig, aber der Begriff "Rolladenöffnung" beschreibt ja eindeutig einen Zustand, nämlich geöffnet.

Hallo zusammen,

Vielen Dank an die Entwickler für diesen tollen Adapter. Ich nutze ihn schon seit Februar 2020 erfolgreich mit meinem Deebot 950 Ozmo und bin sehr zufrieden mit dem Funktionsumfang und der Stabilität des Adapters.

Ich habe im Nachbarforum diesen Thread hier initiiert https://www.roboter-forum.com/index.php?thread/40850-deebot-ozmo-950-lässt-sich-jetzt-auch-per-iobroker-steuern-smarthome/ und dort habe ich auch Blockly Scripte zur Integration mit Alexa unter Nutzung dieses Adapters entwickelt und veröffentlicht.

Diese Scripte nutze ich täglich und steuere ausschließlich damit meinen Deebot und das funktioniert sehr zuverlässig, sogar dann noch, wenn ein Teil der Ecovacs Server Infrastruktur ausfällt, so dass man mit der App keine Verbindung zum Deebot aufbauen kann.

Im Prinzip nutze ich die folgenden Datenpunkte erfolgreich: relocate, spotArea, customArea, currentMapIndex, deebotPosition, relocationState und cleanstatus.

spotArea funktioniert wunderbar mit den per Komma getrennten Raumnummern. Eine einzige Sache ist mir hier aufgefallen:

Wenn man den Deebot in die andere Etage stellt und man kein relocate durchführt. Das heißt der currentMapIndex verweist noch auf die Karte der vorherigen Etage und man gibt nur eine Raumnummer bei spotArea an, dann reinigt der Deebot trotzdem alle Räume. Macht man jedoch vorher ein relocate und wartet, bis im Datenpunkt currentMapIndex die richtige Karte erscheint und füllt erst dann die spotArea mit der Raumnummer, funktioniert alles perfekt, es wird nur dieser Raum gereinigt. Vielleicht wäre hier noch ein Fix möglich.

relocate funktioniert sehr zuverlässig, ortet die aktuelle Position des Bots und befüllt currentMapIndex und deebotPosition erfolgreich mit den aktuellen Koordinaten des Bots.

customArea funktioniert auch perfekt, ich habe auch eine Spotreinigung in mein Blockly gebaut, also man stellt den Bot an eine beliebige Position im Haus und sagt "Alexa, Spotreinigung" und der Deebot reinigt dann ein Rechteck von 4 qm um den aktuellen Standort herum. Hierzu stoße ich ein relocate an, prüfe ob relocationState of OK geht und berechne dann aus den Koordinaten in deebotPosition die Eckpunkte des zu reinigenden Rechtecks und übertrage sie in customArea, daraufhin reinigt der Deebot genau das gewünschte Rechteck, echt top!

cleanstatus funktioniert auch zuverlässig, verwende ich dafür um falls gewünscht den Deebot mehrfach hintereinander ein und dieselbe Reinigungsaufgabe durchführen zu lassen, denn wenn der Status nicht mehr cleaning ist weiß ich, dass die aktuelle Reinigungsaufgabe beendet ist und ich eine neue Reinigungsaufgabe erteilen kann. Funktioniert übrigens sogar dann, wenn der Bot gerade seine Basis sucht.

Was ich cool fände bzw. mir noch aus Programmierer Sicht wünschen würde wäre es, wenn solche Felder wie cleanstatus oder relocationState Enums mit fest definierten Werten wären und keine Strings. Denn dann wüsste man gleich, welche Stati alles möglich sind und man eventuell bei der Programmierung berücksichtigen muss und müsste nicht erst durch ausprobieren recherchieren, welchen Wert die Felder haben, wenn der Bot gerade etwas bestimmtes tut.

Aus meiner Sicht funktioniert aber Version 0.6 so stabil, dass sie bedenkenlos auf den stable Branch gemerged werden kann.