Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Martin X]

Vielleicht kann mir hier jemand helfen. Ich habe mehrer fragen zu iobroker.devices 0.3.6:

1. Wieso wirft der "Geräte Manager" ohne Fehlermeldung "states" wieder heraus?
2. Soweit ich herausgefunden habe, muss "role" und "type" des Datenpunktes mit der Vorgabe übereinstimmen. Aber z.B. wird unter Thermostate unter BOOST folgendes erwartet: "number, write, role=switch.power". Da kann ich createState() nutzen wie ich möchte diesen Datenpunkt wirft er mir immer wieder heraus. Dabei steht in der Dokumentation von IOBroker das ein "role=switch" ein boolean sein sollte (was aber auch nicht funktioniert). iobroker.Dokumentation
3. Wieso werden Datenpunkt mit vorgegeben smartname (erzeugt durch andere Adapter) nicht durchs hiden (Disable smart) gelöscht?
4. Was darf man alles in den alias Read/Write Funktionen von javascript benutzen? z.B. "Round()" etc. ist klar aber auch ein richtig ausgeschriebene "if else" oder nur das kurze "? :", welche variablen außer "val" sind erlaubt usw.?

[paul53]

@Martin-X sagte:

Was darf man alles in den alias Read/Write Funktionen von javascript benutzen?

Jeden nativen Javascript-Code, den man in eine Zeile packen kann.

[Martin X]

@paul53
Hmm eine Zeile ist relative: "if () {command1;command2;}" oder "getState()"...
Soweit ich es bis jetzt herausgefunden habe, alles was mit nur einem ";" abgeschlossen werden kann bzw. alles ohne ";" und primitive data type operations. Aber danke für die schnell Antwort!

Zumindest kann man "12.34" in "12,34" umwandeln. val.toString().split() usw. geht

[Garfonso]

@Martin-X said in Test Adapter Devices 0.3.x:

1. Wieso wirft der "Geräte Manager" ohne Fehlermeldung "states" wieder heraus?

Verstehe die Frage nicht ganz. Aber ich vermute, dass es daran liegt, dass es keine "festen" Geräte gibt. Sondern die Geräte werden immer dynamisch mit dem iobroker.type-detector angelegt.
Wenn dabei states auf der Strecke bleiben, dann sind sich wohl devices-adapter und type-detector nicht ganz einig, wie das nun sein sollte -> sollte nicht passieren -> am besten möglichst genau eingrenzen und issue aufmachen (falls es noch keins gibt).

2. Soweit ich herausgefunden habe, muss "role" und "type" des Datenpunktes mit der Vorgabe übereinstimmen. Aber z.B. wird unter Thermostate unter BOOST folgendes erwartet: "number, write, role=switch.power". Da kann ich createState() nutzen wie ich möchte diesen Datenpunkt wirft er mir immer wieder heraus. Dabei steht in der Dokumentation von IOBroker das ein "role=switch" ein boolean sein sollte (was aber auch nicht funktioniert). iobroker.Dokumentation

Das halte ich für einen Bug im type-detector. Daher habe ich hier einen PR erzeugt, der das fixt. Leider hat bisher keiner drauf geguckt. @Bluefox scheint im Moment eher wenig Zeit zu haben... :-( Weiß nicht, wer sonst noch beim type-detector mergen würde, ggf. @apollon77 ?

3. Wieso werden Datenpunkt mit vorgegeben smartname (erzeugt durch andere Adapter) nicht durchs hiden (Disable smart) gelöscht?

Vermutlich weil der smartname im ursprünglichen Objekt angelegt ist (wenn du sagst durch "andere Adapter") und es daher keine Rolle spielt ob das Alias-Objekt den smartname disabled oder nicht.
(Auch hier funktioniert es so, dass der iot Adapter alle Objekte anguckt und prüft ob die im common einen Eintrag smartname: { ... } haben. Die aliase und Ursprungsobjekte werden an der Stelle getrennt behandelt, haben beide einen smartnamen, werden auch beide bei iot auftauchen).

Frage dazu noch: Gibt es wirklich adapter, die die Smartnamen direkt im Objekt anlegen? Oder werden die nur automatisch von iot aufgenommen, weil (ggf. vom Adapter) Raum & Funktion belegt werden? Dann könntest du für den Raum & Funktion in den Instanzeinstellungen von iot die automatische Geräteerzeugung deaktivieren -> müsste dann weg sein.

4. Was darf man alles in den alias Read/Write Funktionen von javascript benutzen? z.B. "Round()" etc. ist klar aber auch ein richtig ausgeschriebene "if else" oder nur das kurze "? :", welche variablen außer "val" sind erlaubt usw.?

Du darfst ganz sicher nichts asynchrones machen, also das "getState" (geht im Adapter / Controller eh anders) geht sicherlich nicht (leider).

[paul53]

@Garfonso sagte:

Du darfst ganz sicher nichts asynchrones machen

Ja, setTimeout() und setInterval() werden sicherlich nicht funktionieren, obwohl natives Javascript.

[Martin X]

@Garfonso Vielen Dank!
Zu 1. Die 1. frage war wohl schlecht formuliert aber du hast sie trotzdem richtig verstanden. Was mich stört, ist nicht das der device-adapter sich nicht mit dem typer-detector versteht etc. Sondern das der device-adapter ja ein fertiges Template für ein Geräte anzeigt (eine Eingabemaske die ich gut finde), nur beim bestätigen wird kein Fehler geworfen, wenn einige Datenpunkt nicht dem Template entsprechen. Das wird einfach nur dem type-detector überlassen was der device-adapter dann z.B. idealerweise für ein Geräte hält oder halt für zwei/drei etc. Geräte.
Zu 2. Naja wie du schon im PR schreibst, vielleicht ist das auch kein Fehler, sondern liegt halt an der spärlichen, teils widersprüchlichen Dokumentation etc. Denn ein "Switch" könnte man auch als ein "switch case"/"selector" verstehen. :astonished: Das ist halt in der deutschen Sprache eindeutig und unverwechselbar.
Zu 3. Jaein zu "es daher keine Rolle spielt", denn der Smartname muss eindeutig sein, damit er mit Alexa etc. keine Probleme macht. Nun kann man aber per Adapter ein Smartname z.B. im Yeelight Adapter vergeben, was dann aber ein großes Problem ist wenn auch der Alias-Name wie der vergebenen Smartname (per Adapter) sich gleicht. Das hat mich einige Stunden gekostet um hinter diesen Fehler zu kommen, denn dazu muss man sich mal die RAW Datenpunkt anschauen und verstehen. (Bitte um Doku!)
Zu 4. Leider sieht man dem Funktionsaufruf nicht an ob er asynchron oder synchron funktioniert, was aber leider auch an javascript liegt und ich wahrlich kein javascript "crack" bin. Viel zu viele Möglichkeiten die sich nur durch die Struktur unterscheiden und nicht durch ein Schlüsselwort.

[andi2055]

Ich habe den gerade über Github installiert.
Ich sehe im Admin-Menü aber nichts.

Admin etc. alles aktuell.
Steh ich auf dem Schlauch oder was muss ich tun?

[apollon77]

@andi2055 Hast Du - wenn Du über Github installiert hast ... (warum auch immer weil ist inzwischen im Repo) - auch eine Instanz angelegt? Weil das passiert nicht automatisch bei einem GitHub Install

[andi2055]

@apollon77
Ok, Danke. Wenn man nach "Geräte verwalten" sucht, dann findet man ihn. Ich hatte "Devices" gesucht und daher nicht gefunden. Ich hätte mir den Screenshot oben genauer ansehen sollen. Ich war vom Titel "Test Adapter Devices" zu sehr geprägt.

Daher hatte ich Github verwendet. Das mit Instanz manuell anlegen war mir neu...
Jetzt hat's funktioniert.
Danke!

[Frank579]

Hallo zusammen
nachdem ich nun zum erstem mal ein Gerät tauchen muss und überall Ändern ..... :man-shrugging: habe ich mir gedacht jetzt diesen Adapter zu nutzen ... soweit klappt es auch schon, habe nur ein Problem mit der Gosund Steckdose. Wenn ich sie anlege muss ich Ja die DP wählen, müsste aber auch für mein Trocknerscript die Verbräuche haben wo lege ich die an?? bin ich blind oder geht das (noch) nicht. hoffe jemand weiß rat :)
Danke

[Garfonso]

@Frank579
Ich würde da zwei Dinge sehen:

• Steckdose und Strommessung sehe ich als getrennte Geräte
• Für Strommessung gibt es bisher kein "Gerät" in ioBroker -> also von Hand anlegen (bzw. "info" Gerät geht vermutlich).

[crunchip]

Info habe ich dafür genommen, jedoch muss man von Hand dann noch einiges nachtragen, also noch nicht das optimale.

[Frank579]

@Garfonso ,@crunchip ,

vielen dank schon mal für eure Tipps. :+1:
Dann werde ich die daten wohl weiter direkt aus dem sonoff adapter ziehen, vieleicht wird es ja mal integriert ... :)

[apollon77]

@Garfonso ideal ein device mit mehreren Channeln ;-). Geht alles in Richtung der Geräte templates. ;-))
Würde da eine Steckdose sehen (nur Switch quasi) und eine Steckdose mit messfunktion ;-)

[liv-in-sky]

habe bis jetzt nicht mit alias gearbeitet und wollte mir das mal näher ansehen - mein erster test sollte ein lüfter sein

warum gibt es keinen lüfter als gerätetyp - ich habe 5 stück davon - oder übersehe ich da was ? ein typ anzeige (für wemos mit 7-segment) wäre auch gut

aber dafür gibt es einen gerätetyp hochwasseralarm ?

[apollon77]

Es ist alles noch am Anfang ... weitere Pläne siehe https://forum.iobroker.net/topic/35020/devices-alias-assistenten-visualisierungen-die-zukunft

[liv-in-sky]

@apollon77

ok - danke - war nur verwundert, da es diesen adapter doch schon einige zeit gibt

muss ich morgen mal alles in ruhe durchlesen

[Garfonso]

@apollon77 said in Test Adapter Devices 0.3.x:

@Garfonso ideal ein device mit mehreren Channeln ;-). Geht alles in Richtung der Geräte templates. ;-))
Würde da eine Steckdose sehen (nur Switch quasi) und eine Steckdose mit messfunktion ;-)

Zu meinem Verständnis: Wären das dann zwei verschiedene Geräte Templates?

[siggi85]

@Garfonso sagte in Test Adapter Devices 0.3.x:

@apollon77 said in Test Adapter Devices 0.3.x:

@Garfonso ideal ein device mit mehreren Channeln ;-). Geht alles in Richtung der Geräte templates. ;-))
Würde da eine Steckdose sehen (nur Switch quasi) und eine Steckdose mit messfunktion ;-)

Zu meinem Verständnis: Wären das dann zwei verschiedene Geräte Templates?

Bei Lichtern wird ja unterschieden zwischen Licht, Dimmer, HUE Licht etc.

Allerdings wäre es sicher übersichtlicher und einfacher, wenn es nur Licht geben würde. Dann füllt man alle Parameter aus, die die entsprechende Lampe hat (bspw bei einer Lampe ohne Farben lässt man den HUE Wert einfach weg) und dann wird hierfür auch kein Alias angelegt.
Dieses Vorgehen kenne ich bereits vom iQontrol Adapter. Hier kann man mehrere Datenpunkte zu einem DeviceType (bspw. Licht) befüllen, und nur die ausgefüllten Datenpunkte werden dann auch visualisiert.

EDIT: Gestern hat er mir nur einen Datenpunkt zur Auswahl gegeben, ebend hat es genauso funktioniert wie ich es beschrieben habe (da hat er mir sogar beim Dimmer die Möglichkeit gegeben einen Hue-Wert mitzugeben). Warum gibt es denn mehrere Licht-Typen?

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