Test Adapter Devices 0.3.x

[Garfonso]

@siggi85
Das fand ich auch etwas verwirrend, am Anfang... vermutlich ist hier das Ziel, dass die Weiterverarbeitung (also z.B. eine Vis) nicht so viel raten muss, was das Licht nun kann. Ehrlich gesagt, finde ich das auch nicht ganz glücklich und würde dir da zustimmen, dass es eigentlich nur einen Licht-Typ geben müsste und der dann die optionalen States soweit es geht füllt. Damit käme ich z.B. in Lovelace auch besser klar.

Vermutlich spielt aber auch damit rein, dass der type-detector (aktuell) nicht nur die schön aufgeräumten Alias-Geräte erkennen soll, sondern auch Geräte mit verschiedenen States ggf. in unterschiedlichen Channeln... das könnte etwas komplizierter sein...? Ich weiß es nicht.

Der Vorteil vom aktuellen System ist, dass man am Typ direkt erkennen kann, was die Lampe ganz sicher kann (also eine RGB-Lampe kann ganz sicher mit einzelnen States für r/g/b angesprochen werden).

[EdgarM]

Hi,

warum sehe ich die "open" Eigenschaft von einem Deconz Fenstersensor nicht in der Geräteliste?

Bei den awara temp Sensoren sehe ich die temereatur eigenschaft, bei den Fenstersensoren die Haupteigenschaft nicht.

Ich finde auch keine Option um etwas einzublenden.

Bildschirmfoto vom 2020-07-17 07-58-23

grüße
E

[andi2055]

Hallo!
Ich versuche mir gerade ein Thermostat zusammenzubauen mittels Dummy-Werten zum Testen.

nach dem Anlegen sieht das auch gut aus

Wenn ich neu in den Adapter reingehe, dann sind plötzlich die Werte auf 2 Zeilen aufgeteilt

Die Werte vom 2. Eintrag sind auch falsch zugeordnet (Boost doppelt)

Die DP sehen jedoch gut aus

Mache ich was falsch oder ist das ein Bug?

//EDIT 20.07: Ich habe einen Issue auf GitHub angelegt

[siggi85]

@andi2055 sagte in Test Adapter Devices 0.3.x:

Hallo!
Ich versuche mir gerade ein Thermostat zusammenzubauen mittels Dummy-Werten zum Testen.

nach dem Anlegen sieht das auch gut aus

Wenn ich neu in den Adapter reingehe, dann sind plötzlich die Werte auf 2 Zeilen aufgeteilt

Die Werte vom 2. Eintrag sind auch falsch zugeordnet (Boost doppelt)

Die DP sehen jedoch gut aus

Mache ich was falsch oder ist das ein Bug?

Das gleiche Verhalten habe ich mit einem Device vom Typ Dimmer. Sieht für mich nach einem Bug aus.

[siggi85]

Hier auch mal ein Hue Licht, welches kurz nach Anlegen im Device Adpater "zerlegt" wird.

Ich möchte am liebsten alle meine Geräte über den Device Adapter pflegen und damit über Aliase arbeiten. Dafür müsste

1. dieser Bug behoben sein
2. am besten die Möglichkeit bestehen, für jedes Devices noch custom Aliase einzuführen. (bspw. möchte ich bei einigen Lichtern die transitiontime konfigurierbar machen, oder ich möchte den button Type bei einigen shellybasierten Lichtschaltern ändern können um sie zu deaktivieren, etc.)

Es wäre super, wenn der Adapter stable wird, bevor bspw. der deconz Adapter mit Version 2 ins stable kommt. Hier wird die komplette Objektstruktur umgebaut und das wäre ein idealer Zeitpunkt hier auf Aliase des Devices Adapters umzusteigen.

Ich könnte die Aliase auch per Skript anlegen lassen, bin aber von der Grundidee und dem damit einhergehenden Strukturgewinn im ioBroker dieses Adapters sehr überzeugt und hoffe in Zukunft nur noch damit mein iQontrol, Hab Panel und Skripte zu befüllen.

[Neuschwansteini]

@siggi85 @apollon77
Da bin ich ganz bei dir, Siggi, mir hat der Devices-Adapter auch schonmal meine Aliens zerlegt.. seitdem hab ich Ihn wieder verbannt und nutze das Script, aber übersichtlicher wäre natürlich der Adapter.

Wenn man hier noch eine Spalte für "added in IOT" einfügen würde, und damit der Alias gleich im IOT drin wäre, hätte man noch mehr Arbeit gespart.

[Mike Hellracer]

@apollon77
Hi Apollon. Großes Lob für den Adapter. Endlich kann man die Geräte zentral anlegen und Vis sowie alle skripte darauf verweisen lassen. Ich würde gerne mehr testen, doch dazu müsste das Problem mit den unknown Devices, siehe auch Issue auf github, behoben sein.
Wäre.dir sehr dankbar, wenn du die restlichen Devices "bekannt" machen könntest. Ich denke dann kommt auch mehr Feedback was geht und was nicht.

[apollon77]

@Mike-Hellracer Ist Bluefox Werk ... Bitte GtHub Issues anlegen. Kommt dann als nächstes mit dran

[martinschm]

Hi,

über den Zigbee Adapter bekomme ich den Status "available" in den Aliasen ist es aber unreach.

Ich hab jetzt probiert in den Read/Write Eigenschaften den Wert zu invertieren.

Leider klappt das nicht. Mache ich da was falsch?

[martinschm]

Hi,

und noch eine Frage. Warum kann man manchmal nur Read Eingeben und kein Write ?

[apollon77]

@martinschm Was genau macht er denn? Sieht an sich ok aus

[apollon77]

@martinschm Weil States wie UNREACH "read only" sind?

[martinschm]

@apollon77 said in Test Adapter Devices 0.3.x:

@martinschm Weil States wie UNREACH "read only" sind?

Hi,
vielleicht ist ja mein Verständnis falsch. Ich lese den Wert aus dem Datenpunkt des Originalgerätes aus und kann ihn mit Hilfe der Operatoren/Funktionen umwandeln.

Da das Originalgerät die Info als "Verfügbar" zur Verfügung stellt würde ich den Wert gerne invertieren, damit es einen korrekten Unreach Wert im Alias wiedergibt.

Oder hab ich da was falsch verstanden?

[martinschm]

@apollon77 said in Test Adapter Devices 0.3.x:

@martinschm Was genau macht er denn? Sieht an sich ok aus

Hi,

Also das Originalgerät zeigt unter "Available -> true" an

Im Alias Adapter will ich das invertieren und schreibe daher !val rein

Im Objektbaum der Aliase steht dann aber weiter "true" bei unreach anstatt "false".

[martinschm]

Hi,

ich hab auch ein "Zerlegen" von Geräten beobachtet. Allerdings weiß ich noch nicht ganz ob es ein Muster gibt. Ich migriere grade meine ZigBee Geräte zum Zigbee Adapter und lege in dem Zuge auch gleich Aliase an. Für einige Fenstersensoren wurde jetzt ein zweiter Eintrag erstellt. Für manche nicht. Github Issue hab ich erstellt.

Von iQontrol wurden die Aliase zumindest für Fenster schon mal gut erkannt und konnten über die Routine automatisch erkannt und angelegt werden. Vorher mußte ich jeden Datenpunkt einzeln mappen. Ist schonmal ein Gewinn.

NACHTRAG:
Die Dopplung scheint dann zu passieren, wenn ein Gerät zwei Funktionen zu geordnet ist. Es werden pro Zeile zwar beide Funktionen angezeigt, aber das Gerät wird trotzdem doppelt aufgeführt

[martinschm]

@Garfonso said in Test Adapter Devices 0.3.x:

@martinschm
Man kann dem alias sagen er soll die Daten noch manipulieren, bevor er sie in den Alias State schreibt (read logik) oder aus dem alias state in den original state (write logik). Soweit ich weiß geht das bisher nur über die RAW Ansicht des Objekts. Dort dann sowas eintragen:

  "common": {
    "name": "Buero batteryWarning",
    "role": "indicator.lowbat",
    "type": "boolean",
    "read": true,
    "write": false,
    "smartName": false,
    "alias": {
      "id": "zigbee.0.00158d0003f3cea3.battery",
      "read": "val < 20"
    },

Also wichtig die Zeile "read". Hier wird aus einer Batterie % Anzeige eine Batteriewarnung, wenn die Batterie unter 20% fällt. Damit kann man relativ lustige Sachen machen. "val" ist dabei in read der Wert des target state (also hier zigbee.0.00158d0003f3cea3.battery) und bei write der Wert des alias state.

Ich hab das jetzt mal probiert, leider steht bei mir bei LOWBAT immer true drin.
Das hier ist mein raw "Code".

{
  "_id": "alias.0.Fenster.AZ_Links.LOWBAT",
  "native": {},
  "type": "state",
  "common": {
    "alias": {
      "id": "zigbee.0.00158d0001e48a72.battery",
      "read": "val < 20"
    },
    "name": "LOWBAT",
    "role": "indicator.maintenance.lowbat",
    "type": "boolean",
    "read": true,
    "write": false
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1601823158195,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Das val < 20 hab ich hier eingegeben. Das read: true, write: false hab ich in der raw Ansicht reinkopiert.

[apollon77]

@martinschm Und es ist sicher das das "available" ein Boolean ist? Weil wenn es ein String "true" ist dann wäre eine invertierung genau so korrekt. Nur zur Sicherheit!
Im Admin so in der Ansicht kann man zwischen "true" (String) und true (Boolean) nicht wirklich unterscheiden.

Ich habe es bei mir mal mit einem Boolean Wert getestet und da geht es Problemlos!

[martinschm]

@apollon77 said in Test Adapter Devices 0.3.x:

@martinschm Und es ist sicher das das "available" ein Boolean ist? Weil wenn es ein String "true" ist dann wäre eine invertierung genau so korrekt. Nur zur Sicherheit!
Im Admin so in der Ansicht kann man zwischen "true" (String) und true (Boolean) nicht wirklich unterscheiden.

Ich habe es bei mir mal mit einem Boolean Wert getestet und da geht es Problemlos!

Hi Apollon,

ja ist ein boolean, hab es im RAW Modus kontrolliert.

Muß man nach dem Eingeben von !val noch irgendwas aktualisieren oder so damit das übernommen und im Objektbaum so angezeigt wird?

[martinschm]

@apollon77

Hab es jetzt nochmal probiert.
Das RAW des Alias sieht jetzt so aus

{
  "_id": "alias.0.Fenster.GaesteWC.UNREACH",
  "native": {},
  "type": "state",
  "common": {
    "alias": {
      "id": "zigbee.0.00158d0001b7a818.available",
      "read": "!val"
    },
    "name": "UNREACH",
    "role": "indicator.maintenance.unreach",
    "type": "boolean"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1601794464779,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Im Objektbaum steht bei unreach des Alias true:

Bei dem Originalgerät steht bei available auch true:

Also invertiert wird da leider nichts. Hab die Adapterversion 0.3.6, nodejs 12.x

[paul53]

@martinschm sagte:

ist ein boolean, hab es im RAW Modus kontrolliert.

Dann sollte es "boolean" sein, was nicht garantiert ist. Was ergibt in einem Test-Script ?

log(typeof getState('...available').val); // ID anpassen !