Mappingstruktur? - Mapping Adapter?

[BBTown]

In Zusammenhang mit der nun verfügbaren Google Home Anbindung und dem teilweise neuen Wording bzw. settings für Google Home, stellt sich für mich - als nichtEntwickler - die Frage, macht es ggf. Sinn über so etwas wie ein grundsätzliches Mapping in ioBroker nachzudenken - ggf. über einen Adapter oder im Hintergrund?!

Wie komme ich darauf: @s-bormann hat in seinem iQontrol Adapter die Erkennung von Datenpunkten eingebaut. Hier kommt es dann z.B vor, dass die "Rollen" ja nach Hersteller entweder unterschiedlich benannt werden, oder aber bei dem einen ein "true/false" beim nächsten aber ein "0/1" erwartet wird. Bei den Rolladen einmal "100" für offen da nächste mal allerdings im Gegenteil eine "0".

Vor der gelichen Herausforderung unetrschiedliche Thermostate einzubinden/zu erkennen stand dann auch @Rene_HM beim Heating Adapter Ich könnte mir vorstellen, dass dies bei lovelace ähnlich sein wird, usw. ...

Daher meine Frage, wie sinnvoll wäre es eventuell zu schauen ob man nicht an einer Stelle versucht auf ein einheitliches Muster zu fallen. Dass nicht in jedem Adapter hierauf Rücksicht genommen werden muss, sondern zentral bspw. ein "0/1" auf ein allgemeingültiges "true/false" gemappt wird ... usw.

Macht es Sinn über so etwas nachzudenken oder gibt es einfach zu viele und zu unterschiedliche Systeme?

[paul53]

@BBTown
Macht das nicht der Adapter LinkedDevices ?

[BBTown]

@paul53
den LinkedDevices-Adapter hatte ich so verstanden, dass es darum geht ein Gerät eines bestehenden Adapters (sagen wir bspw. einen Heizungsthermostat) zu ersetzen und dann diesen "umzulenken"
Ähnlich wie das beim aktuellen Broadlink-Adapter läuft: "NeuerName = AlterName"

Kann man mit dem auch grundsätzliche Umlenkungen einstellen?
Mache aus einem Shelly "0/1" ein "false/true"?

[paul53]

@BBTown sagte:

Kann man mit dem auch grundsätzliche Umlenkungen einstellen?
Mache aus einem Shelly "0/1" ein "true/false"?

Ja, mit Zahlen (0/1) funktioniert es schon. Strings ("off"/"on") sollen in der nächsten Version folgen.

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