Mappingstruktur? - Mapping Adapter?

[Homoran]

@BBTown
Wurde damals nicht ein Adapter"wrapper", der so etwas machen sollte entwickelt?

[BBTown]

@Homoran
Ich meine auch beim Wrapper ging es darum einen einzelnen Datenpunkt umzulenken und nicht um ein grundsätzliches Gerätemapping, oder täusche ich mich?

[paul53]

@Homoran sagte:

Wurde damals nicht ein Adapter"wrapper", der so etwas machen sollte entwickelt?

Im Prinzip schon, aber das Konzept war wenig tauglich. Der Adapter wird auch nicht weiter entwickelt.

[paul53]

@BBTown sagte:

nicht um ein grundsätzliches Gerätemapping

Das macht "LinkedDevices" auch nicht, obwohl der Name es suggeriert. Ein Gerätemapping hat man nur, wenn jeder Datenpunkt eines Gerätes verlinked wird. Allerdings: Wozu soll man Datenpunkte, die nirgends (JS, Vis, History, ...) verwendet werden, verlinken.

[BBTown]

@paul53
Ich hatte an etwas generelleres gedacht.

In der aktuellen Google Home Anbindung muss ich derzeit eine manuelle Zuweisung vornehmen
z.B, bei einen "HomeMatic wired Dimmer" - Datenpunkt "level.dimmer"
Nun muss ich als type "Light" auswählen und anschließend als trait "Brightness"
Wenn aber irgendwo definiert wäre, dass "level.dimmer" = eine dimmbare Lampe ist und typ = "Light" und trait "Brightness" auch, dann müßte dieses nun nicht im Adapter definiert und abgefangen/erkannt werden. Nun müßte dies @tombox implementieren.

Bei einem nichtHomeMatic Dimmer heisst dieser Datenpunkt aber ggf. nicht "level.dimmer".
Wenn dieser nun bspw. "level.light" heissen würde, dann könnte man über ein zentrales Mapping sagen: "level.light" = "level.dimmer" und alle VIS oder Adapter müssten nur auf "level.dimmer" reagieren.

[AlCalzone]

Interessante Diskussion. Wenn ich mir das Rollen-Schema anschaue, ist mir auch nicht 100% klar, wo der Unterschied light.dimmer und level.dimmer liegt.

Ich vermute, dass light.dimmer ein Gerät bzw. einen Channel bezeichnet und level.dimmer einen (von möglicherweise mehreren) dimmbaren Datenpunkten in diesem Channel.

Grundsätzlich würde ich statt Mapping (nachträgliche Behebung von Unsauberheiten) aber eher dazu tendieren, die Objektdefinitionen der Adapter zu vereinheitlichen, damit sie sich an die Vorschriften halten.

[Bluefox]

Rollen

Es gibt diese Liste von möglichen Rollen:
https://www.iobroker.net/#en/documentation/dev/stateroles.md

Alles was nicht da steht konnte eventuell nicht unterstütz werden.

Unterschied zwischen light.dimmer und level.dimmer ist: dass erste Rolle invalid ist und die zweite ist richtig.

Falls irgendein Adapter light.dimmer setzt, dann muss es pull request dagegen erstellt werden, was das behebt.

Werte

Die Adapter sind dazu verpflichtet die Werte richtig zu mappen.
D.h. die boolean Werte (0/1, on/off, an/aus) müssen IMMER auf true/false gemapped werden. So dass in ioBroker nur true/false zu sehen ist.

Das gleiche ist mit dimmer und Rollladen: 0 ist aus, kein Licht und das Rollladen ist voll geschlossen und 100 ist voll Licht und Rollladen ist geöffnet.
Es darf aber 0-255 oder 0-1000 sein aber 0 ist immer kein Licht. Natürlich das Objekt muss dann als common.max=1000 oder so haben.

[Jey Cee]

Man könnte einen Check (Adapter Checker) auf Plausibilität der Objekte im Adapter machen.

1. existiert die Definition in der Liste
2. passt der Typ zur Definition

Beispiel level.Dimmer:
Typ muss zwingend number sein, min/max muss definiert sein.

Die Liste sollte dann sinnvoller weise als JSON geführt werden.
Jeder kann Definitionen einreichen, die dann geprüft und bei bedarf Diskutiert werden.

[paul53]

@Jey-Cee sagte:

Man könnte einen Check (Adapter Checker) auf Plausibilität der Objekte im Adapter machen.

Was passiert, wenn der Check negativ ausfällt ?

[Jey Cee]

@paul53 wird der Adapter nicht in stabile aufgenommen, so wie bei den anderen Fehlern auch die er findet.

[paul53]

@Jey-Cee
Und was passiert mit den vielen schon existierenden Adaptern ?

[Bluefox]

@paul53 Die werden nicht mehr in repo upgedatet, bis die Fehler gefixt sind.