Neuer Bewegungsmelder REST-API Wert multilevelsensor + illuminance

[Stefan71242]

Beim neuen Bewegungsmelder II (Modell MD2) wird per REST-API für multilevelsensor > illuminance auf einmal ein Wert bis 1000 ausgegeben, statt wie beim Bewegungsmelder I (Modell MD) bis 100.

Warum kommt beim neuen Modell für den gleichen Key+Wert die Range 0...1000 statt für Helligkeit in % korrekt 0...100?

Bug oder Feature?

Auszug Postman für MD2:

{

    "@type": "DeviceServiceData",

    "id": "MultiLevelSensor",

    "deviceId": "hdm:ZigBee:348d13fffe1d1f35",

    "state": {

        "@type": "illuminanceLevelState",

        "illuminance": 1000 = 100% ???

    },

    "path": "/devices/hdm:ZigBee:348d13fffe1d1f35/services/MultiLevelSensor"

}

Auszug für Postman MD1:

{

    "@type": "DeviceServiceData",

    "id": "MultiLevelSensor",

    "deviceId": "hdm:ZigBee:000d6f0011fb5c55",

    "state": {

        "@type": "illuminanceLevelState",

        "illuminance": 12 = 12%

    },

    "path": "/devices/hdm:ZigBee:000d6f0011fb5c55/services/MultiLevelSensor"

}

[Geomo]

@Stefan71242 ich würde einfach durch 10 teilen und dann die tatsächlichen Werte mal auf Plausibilität prüfen.

[STdesign]

Das dürfte die Helligkeit in Lux sein, welche noch in Prozent umgerechnet werden muss.

Für den Bewegungsmelder I gibt es dafür diese Tabelle.

Der dort im Thema adressierte Wunsch die Helligkeitswerte in der Rest-API bereitzustellen wurde scheinbar für den Bewegungsmelder II umgesetzt. Evtl. ist die Skalierung aufgrund des Messbereichs anders 

[Maurice]

Sollte in der Tat die Helligkeit in Lux sein. Beim Bewegungsmelder geht der Messbereich bis 10000 Lux, beim Bewegungsmelder II [+M] leider nur noch bis 1000 Lux.

Allerdings wurde hier berichtet, dass auch beim alten Bewegungsmelder der Wert direkt in Lux über die API kommt. Und auch im von @STdesign verlinkten Thread mit der Tabelle wird das so beschrieben. Es scheint mir daher nicht plausibel, dass da beim alten Bewegungsmelder ein Prozentwert kommt. @Stefan71242, das solltest Du vielleicht nochmal prüfen.

[Stefan71242]

Hallo @Maurice,

um 07.30 Uhr habe ich in der App für einen Bewegungsmelder I (Küche, hdm:ZigBee:000d6f001089eab1) die folgende Anzeige (Helligkeit fast "100%"):

In Postman bekomme ich um 07.30 Uhr aber den Wert 441, was um die 52% ist:

{

    "@type": "DeviceServiceData",

    "id": "MultiLevelSensor",

    "deviceId": "hdm:ZigBee:000d6f001089eab1",

    "state": {

        "@type": "illuminanceLevelState",

        "illuminance": 441

    },

    "path": "/devices/hdm:ZigBee:000d6f001089eab1/services/MultiLevelSensor"

}

{

    "@type": "device",

    "rootDeviceId": "64-da-a0-40-93-e2",

    "id": "hdm:ZigBee:000d6f001089eab1",

    "deviceServiceIds": [

        "LatestMotion",

        "CommunicationQuality",

        "WalkTest",

        "BatteryLevel",

        "DeviceDefect",

        "MultiLevelSensor"

    ],

    "manufacturer": "BOSCH",

    "roomId": "hz_2",

    "deviceModel": "MD",

    "serial": "000D6F001089EAB1",

    "profile": "GENERIC",

    "name": "Bewegungsmelder Küche",

    "status": "AVAILABLE",

    "childDeviceIds": [],

    "supportedProfiles": [],

    "installationTimestamp": 1701196681855

}

Um 07:44 erhalte ich für den Bewegungsmelder Küche (MD) den Wert 648 (ca. 60% laut Tabelle) und in der App bereits Vollausschlag, also Aktuelle Helligkeit ganz oben ("100%"). 

Beim Bewegungsmelder II (MD2, Terasse) erhalte ich um 07:45 Uhr den Wert 1000, aber genau wie beim Bewegungsmelder I in der App den Vollausschlag, also Aktuelle Helligkeit ganz oben ("100%"). 

Zwei derart unterschiedliche Werte können in der App nach meinem Verständnis nicht beide beim Vollausschlag landen; daher warte ich jetzt Mal gespannt auf eine Antwort von BOSCH 😊.

[SebastianHarder]

Der Screenshot ist vom Bewegungslicht, welches seine eigene Umrechnung macht. Probier mal die API /motionlights/<mdID>. 

Außerdem ist die abgebildete Skala des Sliders dort logarithmisch. 

[Stefan71242]

Hallo Sebastian, danke für die schnelle Antwort und erstaunlich, was die REST-API beim BSH alles liefern kann 😮.

Das sieht schon deutlich informativer und detaillierter aus:

{

    "@type": "motionlight",

    "id": "hdm:ZigBee:348d13fffe1d1f35",

    "enabled": true,

    "brightness": 100,

    "darknessThresholdLux": 7,

    "lightsOffDelay": 5,

    "illuminanceLux": 1000,

    "lightIds": [

        "hdm:PhilipsHueBridge:HueLight_001788010ca395bf-0b_ecb5faa743e2",

        "hdm:PhilipsHueBridge:HueLight_001788010d314000-0b_ecb5faa743e2"

    ],

    "motionDetectorId": "hdm:ZigBee:348d13fffe1d1f35"

}

Das werde ich mir in Ruhe mal anschauen und dann im SHC implementieren.
Ich wünsche mir weiterhin eine ausführlichere Doku (ich weiß, soll kommen 🤗) und würde dafür sogar glatt was zahlen 😄.  Schönes Wochenende 👋🤓

[Maurice]

Ergänzend zur Antwort von Sebastian: Die Prozentwerte aus der Tabelle finden sich in der App z. B. auf der Detailseite des Bewegungsmelder II [+M] (den alten habe ich nicht, keine Ahnung ob es da auch so ist) und bei der Helligkeit als Auslöser einer Automation.

[Stefan71242]

Na ja, alles gute Erklärungen, aber sauberes einheitliches Design sieht in der Entwicklung definitiv anders aus 🙄. Denn jetzt hat der Key multilevelsensor + illuminance auf einmal zwei verschiedene Inhalte und man muss bei einer Softwareseitigen Umsetzung jetzt immer noch zusätzlich auf das Modell prüfen = zusätzlicher Entwicklungsaufwand + zusätzliche Fehlerquelle. Und wer weiß, was dann beim nächsten Modell kommt?  

[STdesign]

Du kannst ja mal versuchen eine Messereihe zu machen mit den Prozentwerten in der App und den ausgelesenen illuminance Werten der Rest-API. Dann wirst du vermutlich einen Zusammenhang erkennen.

Zum Software Design. Ja, unterschiedliche Begriffe wären wohl eingängiger.