NEWS
Devices, Alias, Assistenten + Visualisierungen + die Zukunft
-
@apollon77 Es ist hier so still geworden. Geht es hier noch weiter oder ist dieser Weg eine Sackgasse?
-
@apollon77 Es ist hier so still geworden. Geht es hier noch weiter oder ist dieser Weg eine Sackgasse?
-
Devices, Aliasses, Assistenten und Visualisierungen und die Zukunft
Die Einführung von Aliasses in den js-controller und die ersten Versionen des "Devices"-Adapters waren nur der Anfang. WIr haben einiges damit vor.
Dieser Beitrag soll einige der Ideen und Gründe darstellen und zur Diskussion einladen. Noch ist nichts in Stein gemeisselt und das alles umzusetzen wird auch nicht wenig Aufwand, aber gemeinsam können wir in diese Richtung arbeiten.
Aktuelle Realität und die Probleme ...
Ein grosser Vorteil von ioBroker ist seine Flexibilität. Jeder Adapter kann seine Objekte und Zustände frei strukturieren. Das wird auch fleissig angewendet :)
Die Große Herausforderung ist allerdings, das Visualisierungs-Adapter und auch die Assistenzsystem-Adapter - iot vor allem für Amazon Alexa und Google/Next Home, aber auch yahka für Homekit - Informationen brauchen was einzelne Zustände darstellen und ob/wie mehrere Zustände zusammengehören. Ziel ist ja, dass diese Adapter mit wenig zusätzlichem Aufwand für den User Ihr Arbeit verrichten und die Geräte bedienbar machen.
Über Objekttypen wie "device" und "channel" oder im Notfall "folder" kann ein Adapter Zustände gruppieren und do dem User und auch anderen Adaptern mehr Informationen zu den Zuständen geben. Die Idee von "device" und "channel" kommt aus der Homematic Ecke und funktioniert dort recht gut. Ob ein Adapter das nutzen kann hängt aber stark von den Geräten und Kommunikationsprotokollen ab. Auch Adapter wo eine Instanz nur ein Gerät anbindet hat üblicherweise dann kein "device" Objekt.
Die Rollenangabe bei den Zuständen sind ein weiterer Weg Informationen darüber bereitzustellen was ein Zustand darstellt und bedeutet. Wir ersuchen bei allen Adaptern darauf zu achten das die Rollen Sinn machen. Ob aber eine Rolleninformation zur Verfügung steht ist auch eine Frage des Kommunikationsprotokolls. Der mqtt Adapter könnte gar keine Rollen für die Zustände bereitstellen, weil er es selbst nicht weiss.
Die aktuellen Visualisierungs- bzw. Assistenten-Adapter benötigen daher aktuell entweder umfangreiche Konfiguration oder können immer nur einen einzelnen State steuern oder müssen "Zusammenhänge erraten". Material als Beispiel nutz eine sog. "type detector" Library die versucht anhang von Rollen UND Device/Channel Strukturen zu erkennen was zusammen gehört und wie man es sinnvoll darstellen kann. Damit das aber immer funktioniert müssen die Zustände auch eine entsprechenden Aufbau haben - im Zweifel müssen also Adapter aufwändig angepasst werden.
Bei Amazon Alexa gibt es inzwischen für die Smart-Home-Skills die Version 3 (ioBroker nutzt noch Version 2) - hier sind es anstelle der ca. 10 Gerätetypen von v2 plötzlich ca. 60! Das ganze auf die gleiche Weise zu Mappen wir aktuell ist unmöglich. Daher müsste man die ganze Arbeit auf den user abwälzen.Weiterhin war es bisher auch beim Tausch von Geräten (z.B. wegen Defekten) immer schwierig in Bezug auf eigene Skripte oder z.B. Szenen. Meist ändert sich mit der Seriennummer des Geräts auch die Objekt-ID - oder Sie ändert sich beim Wechsel des Protokolls ganz. Dann muss man alle Skripte und auch die Visualisierungen bzw. andere betoffenen Adapter raussuchen und anpassen. Das ist recht aufwändig.
Erste Schritte: Aliasses und der Basis-Devices Adapter
Bei der Einführung der Aliasse haben wir bisher primär den einfachen Gerätetausch und weniger nötige Anpassungen an Skripten oder Visualisierungs-Adaptern propagiert. Und ja, diese Themen können damit bereits umgangen werden.
Unter dem reservierten Namensbereich alias.0 können Objekte angelegt werden, die auf ein anderes Objekt vom Type "state" verweisen. Dabei kann das neue Objekt auch einen anderen Datentyp o.ä. anbieten und auch Werte in beide Richtungen umrechnen. Der Zustand dieses Alias-Objekts hängt immer an dem Zustand des entsprechenden Quell-Objekts.
So weit so gut.
Um das wenigstens rudimentär zu bearbeiten wurde der Devices-Adapter programmiert, der versucht Geräte im System zu finden. Er beachtet dabei "device" Objekte und unterstützt auch Quasi-Aliasse vom "linkeddevices"-Adapter. Das ganze wirkt etwas Chaotisch und da muss garantiert noch viel dran getan werden.Beim Anlegen eines neuen Geräts wird dieses in alias.0 angelegt und man kann den Gerätetyp wählen. Passed zu diesem werden dann eine Liste von "Standard"-Objekten/Zuständen angezeigt die man mit den verlinkten IDs füllt. Diese Standard-Objekte haben das Ziel das am Ende alle über Devices angelegten "Schalter" bzw. "Lampen" o.ä. identisch aussehen, die korrekten Rollen und Datentypen haben. Somit kann man auch ein Licht welches zB per mqtt angebunden ist eine Definition verpassen, sodass Visualisierungs- bzw. Assistenz-Adapter wissen was es ist und wie es dann angezeigt werden muss.
Aktuell ist die Anzahl der Gerätetypen noch eher überschaubar, aber es ist ja auch nur der Anfang. Es gibt auch Helfer-Skripte im Forum die in alias.0 einfach Erlauben verknüpfte Objekte anzulegen.
Aber ja, so richtig gross ist der Mehrwert aktuell noch nicht, das ist uns bewusst.... aber die Zukunft wird besser
In den nächsten Abschnitten möchte ich Euch so ein bisschen über die Pläne und Ideen erzählen die wir auf dieser Basis angehen wollen.
Schritt 1: Gerätetypen und "Objekt-Templates"
Wie oben schon erwähnt, definiert Amazon für die Alexa Welt aktuell über 60 Gerätetypen, die alle unterschiedliche Werte als nötige bzw. optionale Felder haben. Bei Google gibt es ähnliches. Viele davon sind auch für Visualisierungen interessant, weil man am "Typ" eines Geräts sehr gut entscheiden kann wie man es anzeigen und bedienen sollte - und das viel besser als zu raten :-)
Daher ist die Idee das wir, angefangen mit den Amazon- und Google Objekttypen den Devices Adapter um diese erweitern und in diesem Zuge für ioBroker Standardisieren - Standard bezüglich Pflicht und Standard-optionalen States(z.B. SET, ACTIUAL, COLOR, STATE ...). Gern kann man überlegen dazu weitere States "nutzerdefiniert" hinzufügen zu lassen, die aber dann von den ganzen nutzenden Adaptern ignoriert werden!
Das ganze wird dann als alias angelegt. Zusätzlich speichern wir im "device"-Objekt die Information zum genutzten Template. Dann muss man das danach nicht nochmals raussuchen.
Das bringt uns schon mal einen großen Schritt weiter: In Adaptern wählt man das "Device" Objekt aus und alle Informationen sind bekannt und ebenso welcher State-Name in dem Device Objekt was bedeutet. So muss kein Adapter mehr raten. Dem Type-Detector können wir auch so beibringen alles viel besser zu erkennen. Der grosse Vorteil ist aber das Adapter wie z.B. iot das ganze dann auch sehr gut zu den relevanten Amazon bzw Google-typen zuordnen können.
Die "Magie" liegt nur darin die Templates sinnvoll zu defineren. (Und natürlich muss iot irgendwie noch Rückwärts-Kompatibel bleiben damit alles noch so funktioniert wie aktuell - aber hier könnte man durchaus einmalig mit einer neuen Version automatisch aus allen zugeordneten Smart-Devices einmalig kompatible ALias Objekte anlegen, sodass iot danach direkt damit arbeiten kann).Weiterhin sind so angelegte Aliasse unabhängig von den originalen Objekten und ein solches Alias-Gerät kann bei einem Gerätewechsel einfach mit einem neuen Objekt-Mapping versehen werden und schon ist das Gerät getauscht - ohne das sich die Objekt-IDs des Alias-Geräts ändern.
Auch könnte man in den Templates (oder auch so generell) Objekte die im Admin nicht für "jedermann" angezeigt werden sollen über "common.expert=true" verstecken. Ein Objekt mit dieser Information wird seit Admin 3.4.8 nur noch im Expertenmodus angezeigt.
Schritt 2: Geräte-Guidance durch Adapter
Wenn das alles mal implementiert ist kann man Adapter-Entwicklen anbieten Ihre "device"/"channel"-Objekte um Meta-Daten zu erweitern. So könnte man zB seinen Geräten mitgeben was Sie für ein Gerätetype sind und wie die eigenen States zugeordnet sind zu den States die das Geräte-Template bietet. Das ist natürlich optional, aber bietet die Möglichkeit bei der Zuordnung direkt ein sinnvoll passende vorausgefüllte Maske anzubieten.
Zum Beispiel im "common" Bereich des Objekts sowas (am Beispiel einer Daikin-Adapter Objekts, State angaben relativ zum Device-Objekt):
"deviceMapping": { "template": "thermostat", "fields": { "SET": "control.targetTemperature", "ACTUAL": "sensorInfo.indoorTemperature", "HUMIDITY": "sensorInfo.indoorHumidity", "BOOST": "control.specialPowerful", "POWER": "control.power" } }Mit so einer Definition könnte müsste ein User sogar nicht einmal Alias-Geräte nutzen, weil auch hier alle Informationen für Visualisierungs- oder Assistenten-Adapter vorhanden wären. Dann könne auch das State direkt genutzt werden.
Schritt 3: Der "Geräte-Posteingang"
Aktuell haben wir 40k ioBroker Installationen, die alle noch keine solchen Gerätedefinitionen und Aliasse haben. Ebenso neue User kenne sich mit der Idee noch nicht so aus.
Die Idee wäre also hier, dass der Geräte Adapter mittelfristig standardmäßig mit installiert wird. Und wir ändern die UI: Die Standard-Ansicht zeigt nur Aliasse an und alles was keine Aliasse sind landet in einer zweiten Ansicht ... einer Liste wie ein Posteingang. Alle neuen "Device Objekte" von Adaptern werden dort aufgelistet und können zu einem Alias-Gerät gemacht werden. Am Ende ist das natürlich kein "muss" sondern ein Kann ... vllt finden wir auch einen neutraleren Namen als "Posteingang" ;-) Aber alles was hier drin ist kann man auf Klick und mit Wahn eines Gerätetyps und dann zuordnen von States in ein neues Alias-Gerät überführen. Ja die UI wird etwas Tricky das das sinnvoll bedienbar wird, da muss etwas Gehirnschmalz rein. Für einen neuen User kann man das in den Standardprozess mit einbauen: Adapter findet neues Gerät, gehe zu "Geräte" und ordne es zu (wenn er will). :-)
Schlussworte
So, das wäre die große Idee. Jetzt kommt Ihr? Macht das sinn? Ist das eine sinnvolle Richtung?
Bevor wir jetzt aber beginnen über Namen von States o.ä. zu diskutieren, lasst mal mit dem generellen Konzept beginnen. :-) Also bitte diskutiert (noch) nicht zu "Kleinteilig" ...
Nächste Schritte
Sinnvolle nächste Schritte wären genau das erste Set von Gerätetypen und deren States, Pflicht oder Optional und Bezeichnungen zu diskutieren. In meinen Augen sollten wir hier, auch in Richtung des grossen Amazon-v3-Skill-Vorhabens, mit den Geräte-Definitionen von Amazon und Google starten. Im Devices Adapter können wir ein Projekt anlegen. Pro Gerätetype ein Issue und dort einzeln finalisieren. Danach kann man die Implementieren.
Danach würde man die nächsten Schritte finalisieren.
So, jetzt... viel Spass beim (konstruktiven) Feedback geben und mitdiskutieren!
Ingo
Sorry for late feedback but I just found this thread. I hope it's okey that I write in english as mein deutch ist leider nicht sehr gut (ich kann aber deutch gut lesen).
I'm thrilled to read about the enhancements in this area! This enables ioBroker to become smart :-)
However, I would not use the Alexa Skills as a great Taxonomy for how to implement the metadata in ioBroker. Alexa is great and very flexible, but it lacks a good structure. For example, it only specifies 15 different Device types (Skill Device Templates). Google Assistant is much better; they have currently 78 Devices types for smart home area. Apple HomeKit has 23 (Accessory types).
Have I understood the proposed structure correctly that the Device top level will be called "Alias" and an alias then has a "Function", and below this, it will have one or more "Roles/Types" and these have different "States"?
Could you share how those different levels map to the Taxonomy used by, for example Alexa and Google?
Something else I would suggest is to not focus too much on Alexa and Google but use as much as possible from the already standardized and open framework from OpenConnectivity Foundation, the OCF Specification. The latest release is from July this year. They have already a huge amount of Devices types specified, 54 types for smart home and another 127 for appliances and other IoT devices. For the next level, they call it "Resource Types", they have specified 169 types. Most of the big players are members of OCF. Have you guys already looked at this spec and if so, what is your opinion about it?
For my own benefit, I have put a table together with how I understand the used Taxonomy and how they map. I also counted all the standardized types they currently have officially documented. Please, let me know if I misunderstood something.
Many thanks for the impressive work with ioBroker and all of the adapters!
ioBroker v3.3.18, Debian 10 Buster 64-bit (Vmware 6.5 VM), Node.js: v12.22.6, NPM: 6.14.15
Most important Device Adapters: KNX, Trådfri, Homekit/Yahka -
Sorry for late feedback but I just found this thread. I hope it's okey that I write in english as mein deutch ist leider nicht sehr gut (ich kann aber deutch gut lesen).
I'm thrilled to read about the enhancements in this area! This enables ioBroker to become smart :-)
However, I would not use the Alexa Skills as a great Taxonomy for how to implement the metadata in ioBroker. Alexa is great and very flexible, but it lacks a good structure. For example, it only specifies 15 different Device types (Skill Device Templates). Google Assistant is much better; they have currently 78 Devices types for smart home area. Apple HomeKit has 23 (Accessory types).
Have I understood the proposed structure correctly that the Device top level will be called "Alias" and an alias then has a "Function", and below this, it will have one or more "Roles/Types" and these have different "States"?
Could you share how those different levels map to the Taxonomy used by, for example Alexa and Google?
Something else I would suggest is to not focus too much on Alexa and Google but use as much as possible from the already standardized and open framework from OpenConnectivity Foundation, the OCF Specification. The latest release is from July this year. They have already a huge amount of Devices types specified, 54 types for smart home and another 127 for appliances and other IoT devices. For the next level, they call it "Resource Types", they have specified 169 types. Most of the big players are members of OCF. Have you guys already looked at this spec and if so, what is your opinion about it?
For my own benefit, I have put a table together with how I understand the used Taxonomy and how they map. I also counted all the standardized types they currently have officially documented. Please, let me know if I misunderstood something.
Many thanks for the impressive work with ioBroker and all of the adapters!
EDIT: I found an online tool showing all the device and resource types as well as enumerations: https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
Here is the list of OCF Universal Device types (Source: OCF spec Annex A)
Device Category / Device Type / Normative Space Conditioning Air Conditioner oic.d.airconditioner Water Heater oic.d.waterheater Furnace oic.d.furnace Pump oic.d.pump Fan oic.d.fan Condensing Unit oic.d.condensingunit Condenser oic.d.condenser Humidifier oic.d.humidifier Dehumidifier oic.d.dehumidifier Thermostat oic.d.thermostat HVAC oic.d.hvac Air Purifier oic.d.airpurifier Air Quality Monitor oic.d.airqualitymonitor Lighting Lighting Controls oic.d.lightingcontrol Light oic.d.light Appliance Airer oic.d.airer Dryer (Laundry) oic.d.dryer "Washer (Laundry)" oic.d.washer Clothes Washer Dryer oic.d.washerdryer Dishwasher oic.d.dishwasher Freezer oic.d.freezer Ice Machine oic.d.icemachine Indoor Garden oic.d.indoorgarden Mattress oic.d.mattress Oven oic.d.oven Range oic.d.range Refrigerator oic.d.refrigerator Water Heater oic.d.waterheater Water Purifier oic.d.waterpurifier Cooker Hood oic.d.cookerhood Cooktop oic.d.cooktop Steam Closet oic.d.steamcloset Electronics Audio System oic.d.audiosystem AV Player oic.d.avplayer Camera oic.d.camera Desktop PC oic.d.desktoppc Notebook PC oic.d.notebookpc Server oic.d.server Computer oic.d.pc Data Storage Unit oic.d.datastorageunit Display oic.d.display Portable Electronics oic.d.portableelectronics Game Console oic.d.gameconsole 3D Printer oic.d.3dprinter Printer oic.d.printer Printer Multi- Function oic.d.multifunctionprinter Scanner oic.d.scanner Musical Instrument oic.d.musicalinstrument Networking Equipment oic.d.networking Handset oic.d.handset Receiver oic.d.receiver Set Top Box oic.d.stb Telephony oic.d.telephonydevice Television oic.d.tv Active Speaker oic.d.speaker Electronics oic.d.smallelectrical Miscellaneous Air Compressor oic.d.aircompressor Bathroom General oic.d.bathroomdevice Battery Charger oic.d.batterycharger Business Equipment oic.d.businessequipment Robot Cleaner oic.d.robotcleaner Portable Stove oic.d.portablestove Exercise Machine oic.d.exercisemachine Portable HVAC oic.d.hvacportable Optical augmented RFID Reader oic.d.orfid Coffee Machine oic.d.coffeemachine Food Probe oic.d.foodprobe Grinder oic.d.grinder Kettle oic.d.kettle Decorative Lighting oic.d.lightdecorative Emergency Lighting oic.d.lightemergency Microwave Oven oic.d.microwave Vending Machine oic.d.vendingmachine Water Dispenser oic.d.waterdispenser Battery oic.d.battery Infrastructure Water Valve oic.d.watervalve Blind oic.d.blind Door oic.d.door Garage Door oic.d.garagedoor Smart Lock oic.d.smartlock Window oic.d.window Fireplace oic.d.fireplace Pump oic.d.pump Energy Generator oic.d.energygenerator Smart Plug oic.d.smartplug Arc Fault Circuit Interrupter oic.d.afci Circuit Breaker oic.d.circuitbreaker Ground Fault Circuit Interrupter oic.d.gfci Inverter oic.d.inverter PV Array System oic.d.pvarraysystem Switch oic.d.switch Security Panel oic.d.securitypanel Generic Sensor oic.d.sensor Electric Meter oic.d.electricmeter Energy Monitor oic.d.energymonitor Transportation Electric Vehicle Charger oic.d.electricvehiclecharger Fitness Fitness Device oic.d.fitnessdevice Activity Tracker oic.d.activitytracker Blood Pressure Monitor oic.d.bloodpressuremonitor Body Thermometer oic.d.bodythermometer Cycling Power Meter oic.d.cyclingpowermeter Cycling Speed Sensor oic.d.cyclingspeedsensor Cycling Cadence Sensor oic.d.cyclingcadencesensor Heart Rate Monitor oic.d.heartratemonitor Muscle Oxygen Monitor oic.d.muscleoxygenmonitor Medical Blood Pressure Monitor oic.d.bloodpressuremonitor Body Scale oic.d.bodyscale Body Thermometer oic.d.bodythermometer CGM oic.d.cgm Glucose Meter oic.d.glucosemeter Heart Rate Monitor oic.d.heartratemonitor Medical Device oic.d.medicaldevice Pulse Oximeter oic.d.pulseoximeter Sleep Monitor oic.d.sleepmonitor Personal Health Activity Tracker oic.d.activitytracker Blood Pressure Monitor oic.d.bloodpressuremonitor Body Composition Analyser oic.d.bodycompositionanalys er Body Scale oic.d.bodyscale Body Thermometer oic.d.bodythermometer CGM oic.d.cgm Glucose Meter oic.d.glucosemeter Heart Rate Monitor oic.d.heartratemonitor Personal Health Device oic.d.personalhealthdevice Pulse Oximeter oic.d.pulseoximeter Sleep Monitor oic.d.sleepmonitor Other oic.d.unknown Access Management Service oic.d.ams Credential Management Service oic.d.cms Device Ownership Transfer Service oic.d.dotsAnd a list with the 169 Resource Type definitions
Friendly Name (informative) Resource Type (rt) 3D Printer oic.r.printer.3d Acceleration Sensor oic.r.sensor.acceleration Activity oic.r.activity Activity Count oic.r.sensor.activity.count Activity Tracker Atomic Measurement oic.r.activitytracker-am Air Flow oic.r.airflow Air Flow Control oic.r.airflowcontrol Air Quality oic.r.airquality Air Quality Collection oic.r.airqualitycollection Alarm oic.r.alarm Altimeter oic.r.altimeter Atmospheric Pressure oic.r.sensor.atmosphericpressure Audio Controls oic.r.audio Auto Focus oic.r.autofocus Automatic Document Feeder oic.r.automaticdocumentfeeder Auto White Balance oic.r.colour.autowhitebalance Battery oic.r.energy.battery Battery Material oic.r.batterymaterial Body Composition Analyser Atomic Measurement oic.r.bodycompositionanalyser-am Binary switch oic.r.switch.binary Blood Pressure oic.r.blood.pressure Blood Pressure Monitor Atomic Measurement oic.r.bloodpressuremonitor-am BMI oic.r.bmi Body Fat oic.r.body.fat Body Fat Free Mass oic.r.body.ffm Body Location Temperature oic.r.body.location.temperature Body Scale Atomic Measurement oic.r.body.scale-am Body Soft Lean Mass oic.r.body.slm Body Thermometer Atomic Measurement oic.r.bodythermometer-am Body Water oic.r.body.water Brewing oic.r.brewing Brightness oic.r.light.brightness Button Switch oic.r.button Cadence oic.r.cadence Calibrate for Continuous Glucose Meter (CGM) oic.r.cgm.calibrate Calorific Value oic.r.calorificvalue Carbon Dioxide Sensor oic.r.sensor.carbondioxide Carbon Monoxide Sensor oic.r.sensor.carbonmonoxide Circuit Breaker (IEC 61850) oic.r.circuitbreaker Clock oic.r.clock Colour Chroma oic.r.colour.chroma Colour Hue Saturation oic.r.colour.hs Colour RGB oic.r.colour.rgb Colour Saturation oic.r.colour.saturation Colour Space Coordinates oic.r.colour.csc Colour Temperature oic.r.colour.colourtemperature Consumable oic.r.consumable Consumable Collection oic.r.consumablecollection Contact Sensor oic.r.sensor.contact Continuous Glucose Meter (CGM) Atomic Measurement oic.r.cgm-am Conversion Factor oic.r.conversionfactor Cycling Power oic.r.cyclingpower Delay Defrost oic.r.delaydefrost Demand Response Load Control (DRLC) oic.r.energy.drlc Deodorization oic.r.deodorization Device Settings - Accessibility oic.r.settings.accessibility Device Settings - Broadcasting oic.r.settings.broadcasting Device Settings - Picture oic.r.settings.picture Device Settings - Sound oic.r.settings.sound Device Settings - Support oic.r.settings.support Device Settings - System oic.r.settings.system Dimming oic.r.light.dimming Door oic.r.door Ecomode oic.r.ecomode Electric Vehicle Connector oic.r.vehicle.connector Electrical Energy oic.r.energy.electrical Energy Consumption oic.r.energy.consumption Energy Generation oic.r.energy.generation Energy Overload/Circuit Breaker oic.r.energy.overload Energy Usage oic.r.energy.usage Gas Consumption oic.r.gas.consumption Gas Usage oic.r.gas.usage Fault Interrupter Switch oic.r.switch.fault Foaming oic.r.foaming Generic Sensor oic.r.sensor Geolocation Sensor oic.r.sensor.geolocation Glass Break Sensor oic.r.sensor.glassbreak Glucose oic.r.glucose Glucose Meter Complex Carbohydrates oic.r.glucose.carb Glucose Meter Exercise oic.r.glucose.exercise Glucose Meter HbA1c oic.r.glucose.hba1c Glucose Meter Context Health oic.r.glucose.health Glucose Meter Context Meal oic.r.glucose.meal Glucose Meter Context Medication oic.r.glucose.medication Glucose Meter Atomic Measurement oic.r.glucosemeter-am Glucose Meter Context Sample Location oic.r.glucose.samplelocation Glucose Meter Context Tester oic.r.glucose.tester Grinder oic.r.grinder HVAC Capacity Oic.r.hvac.capacity 6.157 Heart Rate oic.r.heartrate Heart Rate Monitor Atomic Measurement Representation oic.r.heartratemonitor-am Heart Rate Zone Sensor oic.r.sensor.heart.zone Heating Zone oic.r.heatingzone Heating Zone Collection oic.r.heatingzonecollection Height oic.r.height Humidity oic.r.humidity IAS Zone Info oic.r.iaszoneinfo IAS Zone Collection oic.r.iaszone Icemaker oic.r.icemaker Illuminance Sensor oic.r.sensor.illuminance Impact Sensor oic.r.impactsensor Inverter (IEC 61850) oic.r.inverter KeyCard Switch oic.r.keycardswitch Keypad Character oic.r.keypadchar Liquid Level oic.r.liquid.level Lock oic.r.lock.status Lock Code oic.r.lock.code Magnetic Field Direction oic.r.sensor.magneticfielddirection Media oic.r.media Media Audio oic.r.media.audio Media Core oic.r.media.core Media Image oic.r.media.image Media Source oic.r.mediasource Media Source List oic.r.mediasourcelist Media Source Input oic.r.media.input Media Source Output oic.r.media.output Media Text oic.r.media.text Media Video oic.r.media.video Mode oic.r.mode Movement oic.r.movement.linear Motion Sensor oic.r.sensor.motion Muscle Oxygen Saturation oic.r.muscleoxygensaturation Night Mode oic.r.nightmode Opaque Data oic.r.opaquedata Open Level oic.r.openlevel Operational State oic.r.operational.state Optical RFID Station oic.r.orfid.station Optical RFID Tag oic.r.orfid.tag Pan Tilt Zoom Movement oic.r.ptz Power Source oic.r.powersource Presence Sensor oic.r.sensor.presence Print Queue oic.r.printer.queue Pulsatile Characteristic for Pulse Oximeter oic.r.pulsatilecharacteristic Pulsatile Occurrence for Pulse Oximeter oic.r.pulsatileoccurrence Pulse Oximeter Atomic Measurement Representation oic.r.pulseoximeter-am Pulse Rate oic.r.pulserate PV array system connection terminal (IEC 61850) oic.r pvconnectionterminal Ramp Time oic.r.light.ramptime Refrigeration oic.r.refrigeration Restricted Switch oic.r.switch.restricted Sampling Interface for Continuous Glucose Meter (CGM) oic.r.cgm.samplinginterval Selectable Levels oic.r.selectablelevels Sensor for Continuous Glucose Meter (CGM) oic.r.cgm.sensor Sensor Properties oic.r.sensor.props Signal Strength oic.r.signalstrength Sleep oic.r.sleep Sleep Monitor Atomic Measurement Batch Representation oic.r.sleepmonitor-am Sleep Sensor oic.r.sensor.sleep Smoke Sensor oic.r.sensor.smoke Speech Synthesis oic.r.speech.tts Speed oic.r.speed SpO2 for Pulse Oximeter oic.r.spo2 Status for Continuous Glucose Meter (CGM) oic.r.cgm.status Temperature oic.r.temperature Three Axis Sensor oic.r.sensor.threeaxis Threshold for Continuous Glucose Meter (CGM) oic.r.cgm.threshold Time Period oic.r.time.period Time Stamp oic.r.time.stamp Torque oic.r.torque Touch Sensor oic.r.sensor.touch UV Radiation oic.r.sensor.radiation.uv User ID oic.r.userid User Info for Application Layer oic.r.userinfo Value Conditional oic.r.value.conditional Water Info oic.r.waterinfo Water Sensor oic.r.sensor.water Weight oic.r.weight Window Covering oic.r.windowcovering -
@kubi said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Ich habe mal eine Frage zum Adapter Devices, wie kann ich selbst Aliase zusätzlich anlegen ?
-
Sorry for late feedback but I just found this thread. I hope it's okey that I write in english as mein deutch ist leider nicht sehr gut (ich kann aber deutch gut lesen).
I'm thrilled to read about the enhancements in this area! This enables ioBroker to become smart :-)
However, I would not use the Alexa Skills as a great Taxonomy for how to implement the metadata in ioBroker. Alexa is great and very flexible, but it lacks a good structure. For example, it only specifies 15 different Device types (Skill Device Templates). Google Assistant is much better; they have currently 78 Devices types for smart home area. Apple HomeKit has 23 (Accessory types).
Have I understood the proposed structure correctly that the Device top level will be called "Alias" and an alias then has a "Function", and below this, it will have one or more "Roles/Types" and these have different "States"?
Could you share how those different levels map to the Taxonomy used by, for example Alexa and Google?
Something else I would suggest is to not focus too much on Alexa and Google but use as much as possible from the already standardized and open framework from OpenConnectivity Foundation, the OCF Specification. The latest release is from July this year. They have already a huge amount of Devices types specified, 54 types for smart home and another 127 for appliances and other IoT devices. For the next level, they call it "Resource Types", they have specified 169 types. Most of the big players are members of OCF. Have you guys already looked at this spec and if so, what is your opinion about it?
For my own benefit, I have put a table together with how I understand the used Taxonomy and how they map. I also counted all the standardized types they currently have officially documented. Please, let me know if I misunderstood something.
Many thanks for the impressive work with ioBroker and all of the adapters!
@Videonisse said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Have I understood the proposed structure correctly that the Device top level will be called "Alias" and an alias then has a "Function", and below this, it will have one or more "Roles/Types" and these have different "States"?
That is not how I understood it. It is more flexible and linked to the ioBroker way to do things. Currently all aliases have an ID that starts with alias.0. That probalby will stay that way.
The proposed device templates are a thing of an object of type "device", i.e. it describes one physical / logical device. The devices in ioBroker usually have multiple states (which can be sensor readings or ways to control the device). Currently this is all very loose and very different for different device types / manufacturers. The idea of the device templates is to have, as an attribute of the device itself, a list of possible "functions" that such a device can have and with that create a mapping from function to existing states in ioBroker. So that an adapter that creates a visualisation or device for alexa / google home or similar can determine from the device object which states to use to control the device. -
@Videonisse said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Have I understood the proposed structure correctly that the Device top level will be called "Alias" and an alias then has a "Function", and below this, it will have one or more "Roles/Types" and these have different "States"?
That is not how I understood it. It is more flexible and linked to the ioBroker way to do things. Currently all aliases have an ID that starts with alias.0. That probalby will stay that way.
The proposed device templates are a thing of an object of type "device", i.e. it describes one physical / logical device. The devices in ioBroker usually have multiple states (which can be sensor readings or ways to control the device). Currently this is all very loose and very different for different device types / manufacturers. The idea of the device templates is to have, as an attribute of the device itself, a list of possible "functions" that such a device can have and with that create a mapping from function to existing states in ioBroker. So that an adapter that creates a visualisation or device for alexa / google home or similar can determine from the device object which states to use to control the device.Isn't "Device templates" and (partly) "Alias" just a technical way how to implement the standardized metadata for a Device into ioBroker? I'm not a developer so I don't fully understand what's the best way forward on the technical level. But what I try to understand is the needs of the standardized data; What data and How will this be structured. I'm not sure what has been decided upon already and if the team still wants some feedback. What is the status?
Currently several of mine Adapters has structured the ioBroker Objects into "Devices" and "Channels". Devices and channels can also be tagged with metadata "Roles" and "Functions". Also, the objects for "States" can/shall be tagged with those. So already, a lot of the technical structure is implemented.
As I understand it, currently both Roles and Functions, however, lack details of which group of states that are mandatory as well as are optional to represent, for example, a Light. If this was standardized on all three levels; Device, Channel and State, it should be much easier to programmatically interact with other adapters for automation and visualisation.
An important question must be how to standardize all of those possible Device types and the required data they must include as well as suggested additional Objects/States they may have and in which formats. To use a common Taxonomy and have agreed on a Semantic model should be very important. A lot of work is already invested in the ecosystems from Amazon Alexa, Apple HomeKit and Google Assistant and of course, it's a good idea to copy as much as possible from them. But as they are not complete, I think it would be even more important to use a more open and standardized data model to achieve Semantic interoperability. So far I can see, the most advanced and promising model for the Smart Home is today what OpenConnectivity Foundation can offer as part of their OCF Specification. Of course, if the Working Group Project Connected Home over IP would publish a Semantic specification it would perhaps be even greater, or? But if and when this will happen is hard to tell.
Regarding Semantic model, here is some example from the OCF spec of Device Types and Resource Types respectively:
Source: https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
Source: OCF Spec v.2.2.0 Resource TypesioBroker v3.3.18, Debian 10 Buster 64-bit (Vmware 6.5 VM), Node.js: v12.22.6, NPM: 6.14.15
Most important Device Adapters: KNX, Trådfri, Homekit/Yahka -
Isn't "Device templates" and (partly) "Alias" just a technical way how to implement the standardized metadata for a Device into ioBroker? I'm not a developer so I don't fully understand what's the best way forward on the technical level. But what I try to understand is the needs of the standardized data; What data and How will this be structured. I'm not sure what has been decided upon already and if the team still wants some feedback. What is the status?
Currently several of mine Adapters has structured the ioBroker Objects into "Devices" and "Channels". Devices and channels can also be tagged with metadata "Roles" and "Functions". Also, the objects for "States" can/shall be tagged with those. So already, a lot of the technical structure is implemented.
As I understand it, currently both Roles and Functions, however, lack details of which group of states that are mandatory as well as are optional to represent, for example, a Light. If this was standardized on all three levels; Device, Channel and State, it should be much easier to programmatically interact with other adapters for automation and visualisation.
An important question must be how to standardize all of those possible Device types and the required data they must include as well as suggested additional Objects/States they may have and in which formats. To use a common Taxonomy and have agreed on a Semantic model should be very important. A lot of work is already invested in the ecosystems from Amazon Alexa, Apple HomeKit and Google Assistant and of course, it's a good idea to copy as much as possible from them. But as they are not complete, I think it would be even more important to use a more open and standardized data model to achieve Semantic interoperability. So far I can see, the most advanced and promising model for the Smart Home is today what OpenConnectivity Foundation can offer as part of their OCF Specification. Of course, if the Working Group Project Connected Home over IP would publish a Semantic specification it would perhaps be even greater, or? But if and when this will happen is hard to tell.
Regarding Semantic model, here is some example from the OCF spec of Device Types and Resource Types respectively:
Source: https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
Source: OCF Spec v.2.2.0 Resource Types@Videonisse said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
As I understand it, currently both Roles and Functions, however, lack details of which group of states that are mandatory as well as are optional to represent, for example, a Light. If this was standardized on all three levels; Device, Channel and State, it should be much easier to programmatically interact with other adapters for automation and visualisation.
That is exactly the current situation, we have states in some structure of devices and channels associated with roles and they have types and flags of read/write. From all this the type-detector tries to derive a device type. This is quite brittle.
So I understood the proposal to add a description of the device to the device object meta data where a developer can define a device type for the device in question and which states of the device offer which functionality of the device type. So the device-object would describe which device type it is and how to control it / read data from it.Of course those device templates need to be defined, collected and described somewhere. From what I understood, when there is talk about Alexa devices or Google home, then that is not exclusive but a "base set" of devices that should be somehow supported (because integration of those services currently is an important freature for iobroker). If there are definitions of device templates that are a superset of those, then it might be worth having a look.
From what I understood this still is a proposal and has not been decided upon (but I could be wrong there).
-
@Videonisse said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
As I understand it, currently both Roles and Functions, however, lack details of which group of states that are mandatory as well as are optional to represent, for example, a Light. If this was standardized on all three levels; Device, Channel and State, it should be much easier to programmatically interact with other adapters for automation and visualisation.
That is exactly the current situation, we have states in some structure of devices and channels associated with roles and they have types and flags of read/write. From all this the type-detector tries to derive a device type. This is quite brittle.
So I understood the proposal to add a description of the device to the device object meta data where a developer can define a device type for the device in question and which states of the device offer which functionality of the device type. So the device-object would describe which device type it is and how to control it / read data from it.Of course those device templates need to be defined, collected and described somewhere. From what I understood, when there is talk about Alexa devices or Google home, then that is not exclusive but a "base set" of devices that should be somehow supported (because integration of those services currently is an important freature for iobroker). If there are definitions of device templates that are a superset of those, then it might be worth having a look.
From what I understood this still is a proposal and has not been decided upon (but I could be wrong there).
(feel free to write in German, this is still the Deutsche Abteilung :slightly_smiling_face: )
I believe that the proposed Device Templates are similar to what OCF has defined with their Device Types and the mandatory, as well as optional, Resource Types. For example, the Device Type Light that has 1 mandatory and 5 optional Resource Types. Each of them has a machine-readable template available.
Would be interesting to hear if @apollon77, or the other core developers, thinks this is something interesting for ioBroker or a plan is already set?
Example
{ "devicename": "Light", "devicetype": "oic.d.light", "vertical": "Smart Home", "resources": [ {"resourcetypetitle": "Binary Switch", "resourcetypeid": "oic.r.switch.binary"} ], "recommendedresources": [ {"resourcetypetitle": "Colour Hue Saturation", "resourcetypeid": "oic.r.colour.hs"}, {"resourcetypetitle": "Colour Space Co-ordinates", "resourcetypeid": "oic.r.colour.csc"}, {"resourcetypetitle": "Colour Temperature", "resourcetypeid": "oic.r.colour.colourtemperature"}, {"resourcetypetitle": "Dimming", "resourcetypeid": "oic.r.light.dimming"}, {"resourcetypetitle": "Ramp Time", "resourcetypeid": "oic.r.light.ramptime"} ] }Source: https://github.com/openconnectivityfoundation/devicemodels/blob/master/oic.devicemap-content.json
Example oic.r.light.dimming:
{ "swagger": "2.0", "info": { "title": "Dimming", "version": "2019-02-15", "license": { "name": "OCF Data Model License", "url": "https://github.com/openconnectivityfoundation/core/blob/e28a9e0a92e17042ba3e83661e4c0fbce8bdc4ba/LICENSE.md", "x-copyright": "copyright 2016-2017, 2019 Open Connectivity Foundation, Inc. All rights reserved." }, "termsOfService": "https://openconnectivityfoundation.github.io/core/DISCLAIMER.md" }, "schemes": ["http"], "consumes": ["application/json"], "produces": ["application/json"], "paths": { "/DimmingResURI" : { "get": { "description": "This Resource describes a dimming function.\nThe Property \"dimmingSetting\" is an integer showing the current dimming level.\nIf Property \"step\" is present then it represents the increment between dimmer values.\nWhen the Property \"range\" is omitted, then the range is [0,100].\nA value of 0 means total dimming; a value of 100 means no dimming.", "parameters": [ {"$ref": "#/parameters/interface"} ], "responses": { "200": { "description" : "", "x-example": { "rt": ["oic.r.light.dimming"], "if": ["oic.if.a", "oic.if.baseline"], "dimmingSetting": 30, "step": 5, "range": [0, 100] }, "schema": { "$ref": "#/definitions/Dimming" } } } }, "post": { "description": "Sets the desired dimming level.\n", "parameters": [ {"$ref": "#/parameters/interface"}, { "name": "body", "in": "body", "required": true, "schema": { "$ref": "#/definitions/Dimming" }, "x-example": { "dimmingSetting": 40 } } ], "responses": { "200": { "description" : "Indicates that the dimming was changed.\nThe new dimming level is provided in the response.\n", "x-example": { "dimmingSetting": 40 }, "schema": { "$ref": "#/definitions/Dimming" } }, "403": { "description": "This response is generated by the OCF Server when the client sends:\n An update with an out of range property value for dimmingSetting.\nThe server responds with the current resource representation.\n", "x-example": { "dimmingSetting": 40 }, "schema": { "$ref": "#/definitions/Dimming" } } } } } }, "parameters": { "interface": { "in": "query", "name": "if", "type": "string", "enum": ["oic.if.a", "oic.if.baseline"] } }, "definitions": { "Dimming" : { "properties": { "rt": { "description": "The Resource Type.", "items": { "enum": ["oic.r.light.dimming"], "maxLength": 64, "type": "string" }, "minItems": 1, "uniqueItems": true, "readOnly": true, "type": "array" }, "dimmingSetting": { "description": "The current dimming value.", "type": "integer" }, "n": { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.common.properties.core-schema.json#/definitions/n" }, "id": { "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.common.properties.core-schema.json#/definitions/id" }, "range": { "$ref": "https://openconnectivityfoundation.github.io/IoTDataModels/schemas/oic.baseresource.properties-schema.json#/definitions/range_integer" }, "step": { "$ref": "https://openconnectivityfoundation.github.io/IoTDataModels/schemas/oic.baseresource.properties-schema.json#/definitions/step_integer" }, "if": { "description": "The OCF Interface set supported by this Resource.", "items": { "enum": [ "oic.if.a", "oic.if.baseline" ], "type": "string" }, "minItems": 2, "uniqueItems": true, "readOnly": true, "type": "array" } }, "type": "object", "required": ["dimmingSetting"] } } }Source: https://openconnectivityfoundation.github.io/IoTDataModels/DimmingResURI.swagger.json
-
Devices, Aliasses, Assistenten und Visualisierungen und die Zukunft
Die Einführung von Aliasses in den js-controller und die ersten Versionen des "Devices"-Adapters waren nur der Anfang. WIr haben einiges damit vor.
Dieser Beitrag soll einige der Ideen und Gründe darstellen und zur Diskussion einladen. Noch ist nichts in Stein gemeisselt und das alles umzusetzen wird auch nicht wenig Aufwand, aber gemeinsam können wir in diese Richtung arbeiten.
Aktuelle Realität und die Probleme ...
Ein grosser Vorteil von ioBroker ist seine Flexibilität. Jeder Adapter kann seine Objekte und Zustände frei strukturieren. Das wird auch fleissig angewendet :)
Die Große Herausforderung ist allerdings, das Visualisierungs-Adapter und auch die Assistenzsystem-Adapter - iot vor allem für Amazon Alexa und Google/Next Home, aber auch yahka für Homekit - Informationen brauchen was einzelne Zustände darstellen und ob/wie mehrere Zustände zusammengehören. Ziel ist ja, dass diese Adapter mit wenig zusätzlichem Aufwand für den User Ihr Arbeit verrichten und die Geräte bedienbar machen.
Über Objekttypen wie "device" und "channel" oder im Notfall "folder" kann ein Adapter Zustände gruppieren und do dem User und auch anderen Adaptern mehr Informationen zu den Zuständen geben. Die Idee von "device" und "channel" kommt aus der Homematic Ecke und funktioniert dort recht gut. Ob ein Adapter das nutzen kann hängt aber stark von den Geräten und Kommunikationsprotokollen ab. Auch Adapter wo eine Instanz nur ein Gerät anbindet hat üblicherweise dann kein "device" Objekt.
Die Rollenangabe bei den Zuständen sind ein weiterer Weg Informationen darüber bereitzustellen was ein Zustand darstellt und bedeutet. Wir ersuchen bei allen Adaptern darauf zu achten das die Rollen Sinn machen. Ob aber eine Rolleninformation zur Verfügung steht ist auch eine Frage des Kommunikationsprotokolls. Der mqtt Adapter könnte gar keine Rollen für die Zustände bereitstellen, weil er es selbst nicht weiss.
Die aktuellen Visualisierungs- bzw. Assistenten-Adapter benötigen daher aktuell entweder umfangreiche Konfiguration oder können immer nur einen einzelnen State steuern oder müssen "Zusammenhänge erraten". Material als Beispiel nutz eine sog. "type detector" Library die versucht anhang von Rollen UND Device/Channel Strukturen zu erkennen was zusammen gehört und wie man es sinnvoll darstellen kann. Damit das aber immer funktioniert müssen die Zustände auch eine entsprechenden Aufbau haben - im Zweifel müssen also Adapter aufwändig angepasst werden.
Bei Amazon Alexa gibt es inzwischen für die Smart-Home-Skills die Version 3 (ioBroker nutzt noch Version 2) - hier sind es anstelle der ca. 10 Gerätetypen von v2 plötzlich ca. 60! Das ganze auf die gleiche Weise zu Mappen wir aktuell ist unmöglich. Daher müsste man die ganze Arbeit auf den user abwälzen.Weiterhin war es bisher auch beim Tausch von Geräten (z.B. wegen Defekten) immer schwierig in Bezug auf eigene Skripte oder z.B. Szenen. Meist ändert sich mit der Seriennummer des Geräts auch die Objekt-ID - oder Sie ändert sich beim Wechsel des Protokolls ganz. Dann muss man alle Skripte und auch die Visualisierungen bzw. andere betoffenen Adapter raussuchen und anpassen. Das ist recht aufwändig.
Erste Schritte: Aliasses und der Basis-Devices Adapter
Bei der Einführung der Aliasse haben wir bisher primär den einfachen Gerätetausch und weniger nötige Anpassungen an Skripten oder Visualisierungs-Adaptern propagiert. Und ja, diese Themen können damit bereits umgangen werden.
Unter dem reservierten Namensbereich alias.0 können Objekte angelegt werden, die auf ein anderes Objekt vom Type "state" verweisen. Dabei kann das neue Objekt auch einen anderen Datentyp o.ä. anbieten und auch Werte in beide Richtungen umrechnen. Der Zustand dieses Alias-Objekts hängt immer an dem Zustand des entsprechenden Quell-Objekts.
So weit so gut.
Um das wenigstens rudimentär zu bearbeiten wurde der Devices-Adapter programmiert, der versucht Geräte im System zu finden. Er beachtet dabei "device" Objekte und unterstützt auch Quasi-Aliasse vom "linkeddevices"-Adapter. Das ganze wirkt etwas Chaotisch und da muss garantiert noch viel dran getan werden.Beim Anlegen eines neuen Geräts wird dieses in alias.0 angelegt und man kann den Gerätetyp wählen. Passed zu diesem werden dann eine Liste von "Standard"-Objekten/Zuständen angezeigt die man mit den verlinkten IDs füllt. Diese Standard-Objekte haben das Ziel das am Ende alle über Devices angelegten "Schalter" bzw. "Lampen" o.ä. identisch aussehen, die korrekten Rollen und Datentypen haben. Somit kann man auch ein Licht welches zB per mqtt angebunden ist eine Definition verpassen, sodass Visualisierungs- bzw. Assistenz-Adapter wissen was es ist und wie es dann angezeigt werden muss.
Aktuell ist die Anzahl der Gerätetypen noch eher überschaubar, aber es ist ja auch nur der Anfang. Es gibt auch Helfer-Skripte im Forum die in alias.0 einfach Erlauben verknüpfte Objekte anzulegen.
Aber ja, so richtig gross ist der Mehrwert aktuell noch nicht, das ist uns bewusst.... aber die Zukunft wird besser
In den nächsten Abschnitten möchte ich Euch so ein bisschen über die Pläne und Ideen erzählen die wir auf dieser Basis angehen wollen.
Schritt 1: Gerätetypen und "Objekt-Templates"
Wie oben schon erwähnt, definiert Amazon für die Alexa Welt aktuell über 60 Gerätetypen, die alle unterschiedliche Werte als nötige bzw. optionale Felder haben. Bei Google gibt es ähnliches. Viele davon sind auch für Visualisierungen interessant, weil man am "Typ" eines Geräts sehr gut entscheiden kann wie man es anzeigen und bedienen sollte - und das viel besser als zu raten :-)
Daher ist die Idee das wir, angefangen mit den Amazon- und Google Objekttypen den Devices Adapter um diese erweitern und in diesem Zuge für ioBroker Standardisieren - Standard bezüglich Pflicht und Standard-optionalen States(z.B. SET, ACTIUAL, COLOR, STATE ...). Gern kann man überlegen dazu weitere States "nutzerdefiniert" hinzufügen zu lassen, die aber dann von den ganzen nutzenden Adaptern ignoriert werden!
Das ganze wird dann als alias angelegt. Zusätzlich speichern wir im "device"-Objekt die Information zum genutzten Template. Dann muss man das danach nicht nochmals raussuchen.
Das bringt uns schon mal einen großen Schritt weiter: In Adaptern wählt man das "Device" Objekt aus und alle Informationen sind bekannt und ebenso welcher State-Name in dem Device Objekt was bedeutet. So muss kein Adapter mehr raten. Dem Type-Detector können wir auch so beibringen alles viel besser zu erkennen. Der grosse Vorteil ist aber das Adapter wie z.B. iot das ganze dann auch sehr gut zu den relevanten Amazon bzw Google-typen zuordnen können.
Die "Magie" liegt nur darin die Templates sinnvoll zu defineren. (Und natürlich muss iot irgendwie noch Rückwärts-Kompatibel bleiben damit alles noch so funktioniert wie aktuell - aber hier könnte man durchaus einmalig mit einer neuen Version automatisch aus allen zugeordneten Smart-Devices einmalig kompatible ALias Objekte anlegen, sodass iot danach direkt damit arbeiten kann).Weiterhin sind so angelegte Aliasse unabhängig von den originalen Objekten und ein solches Alias-Gerät kann bei einem Gerätewechsel einfach mit einem neuen Objekt-Mapping versehen werden und schon ist das Gerät getauscht - ohne das sich die Objekt-IDs des Alias-Geräts ändern.
Auch könnte man in den Templates (oder auch so generell) Objekte die im Admin nicht für "jedermann" angezeigt werden sollen über "common.expert=true" verstecken. Ein Objekt mit dieser Information wird seit Admin 3.4.8 nur noch im Expertenmodus angezeigt.
Schritt 2: Geräte-Guidance durch Adapter
Wenn das alles mal implementiert ist kann man Adapter-Entwicklen anbieten Ihre "device"/"channel"-Objekte um Meta-Daten zu erweitern. So könnte man zB seinen Geräten mitgeben was Sie für ein Gerätetype sind und wie die eigenen States zugeordnet sind zu den States die das Geräte-Template bietet. Das ist natürlich optional, aber bietet die Möglichkeit bei der Zuordnung direkt ein sinnvoll passende vorausgefüllte Maske anzubieten.
Zum Beispiel im "common" Bereich des Objekts sowas (am Beispiel einer Daikin-Adapter Objekts, State angaben relativ zum Device-Objekt):
"deviceMapping": { "template": "thermostat", "fields": { "SET": "control.targetTemperature", "ACTUAL": "sensorInfo.indoorTemperature", "HUMIDITY": "sensorInfo.indoorHumidity", "BOOST": "control.specialPowerful", "POWER": "control.power" } }Mit so einer Definition könnte müsste ein User sogar nicht einmal Alias-Geräte nutzen, weil auch hier alle Informationen für Visualisierungs- oder Assistenten-Adapter vorhanden wären. Dann könne auch das State direkt genutzt werden.
Schritt 3: Der "Geräte-Posteingang"
Aktuell haben wir 40k ioBroker Installationen, die alle noch keine solchen Gerätedefinitionen und Aliasse haben. Ebenso neue User kenne sich mit der Idee noch nicht so aus.
Die Idee wäre also hier, dass der Geräte Adapter mittelfristig standardmäßig mit installiert wird. Und wir ändern die UI: Die Standard-Ansicht zeigt nur Aliasse an und alles was keine Aliasse sind landet in einer zweiten Ansicht ... einer Liste wie ein Posteingang. Alle neuen "Device Objekte" von Adaptern werden dort aufgelistet und können zu einem Alias-Gerät gemacht werden. Am Ende ist das natürlich kein "muss" sondern ein Kann ... vllt finden wir auch einen neutraleren Namen als "Posteingang" ;-) Aber alles was hier drin ist kann man auf Klick und mit Wahn eines Gerätetyps und dann zuordnen von States in ein neues Alias-Gerät überführen. Ja die UI wird etwas Tricky das das sinnvoll bedienbar wird, da muss etwas Gehirnschmalz rein. Für einen neuen User kann man das in den Standardprozess mit einbauen: Adapter findet neues Gerät, gehe zu "Geräte" und ordne es zu (wenn er will). :-)
Schlussworte
So, das wäre die große Idee. Jetzt kommt Ihr? Macht das sinn? Ist das eine sinnvolle Richtung?
Bevor wir jetzt aber beginnen über Namen von States o.ä. zu diskutieren, lasst mal mit dem generellen Konzept beginnen. :-) Also bitte diskutiert (noch) nicht zu "Kleinteilig" ...
Nächste Schritte
Sinnvolle nächste Schritte wären genau das erste Set von Gerätetypen und deren States, Pflicht oder Optional und Bezeichnungen zu diskutieren. In meinen Augen sollten wir hier, auch in Richtung des grossen Amazon-v3-Skill-Vorhabens, mit den Geräte-Definitionen von Amazon und Google starten. Im Devices Adapter können wir ein Projekt anlegen. Pro Gerätetype ein Issue und dort einzeln finalisieren. Danach kann man die Implementieren.
Danach würde man die nächsten Schritte finalisieren.
So, jetzt... viel Spass beim (konstruktiven) Feedback geben und mitdiskutieren!
Ingo
@apollon77
Hallo, ich habe Anfang Dezember 2020 mit ioBroker begonnen und seit dem einiges getestet. Den Ansatz mit den Alias finde ich sehr gut, ähnlich einer Variablentabelle, allerdings habe ich noch einige Lücken im Verständnis der Philisophie des Adapters. :confused:
Soweit ich es bisher Verstanden habe erstellt man unter "Geräte" ein Alias Gerät (Geräte denen ich vorher schon Raum und Funktion zugeordnet hatte erscheinen automatisch in der Liste - allerdings nicht als Alias - was hat es damit auf sich wie sieht der Use case aus ?) hierbei kann man sich einen vorgefertigen Typ aussuchen.
Wenn man das neue Alias Gerät editiert sieht man, dass es eine vorgefertigte Struktur hat - welche sicherlich von dem zuvor gewaehlten Typ kommt.
Leider kann man in diesem Fenster nur die Quellen zu den einzelnen Tags/Members editieren, die Struktur selbst lässt sich hier nicht ändern genauso wie andere Parameter wie z.B. eine Konvertierung des Wertes.
Anpassungen der Struktur (Member hinzufügen) konnte ich nur unter Objekte durchführen und dort auch nur mit manuellen Anpassungen z.B. um diesen Fehler beim Anlagen eines neuen Datenpunkt unter dem Gerät zu lösen
erst wenn man den alias Parameter einfügt wird der Datenpunkt erkannt.
Legt man nun auf diese Weise mehrere Datenpunkte an funktionieren Sie in Objekte unter alias.0 auch wunderbar. Wenn man aber jetzt ein Geräte das entsprechende Gerät editiert sind die neuen Member zwar in dargestellt aber alle sind "scheinbar" mit der gleichen Quelle verbunden --> Darstellungsproblem ?
wie gesagt die Datenpunkte funktionieren.Ok jetzt zu meinem Problem bzw. Verbesserungsvorschlag.
Die Vorgegebenen Typen finde ich gut jedoch sehe ich hier den generischen Ansatz als problematisch. Z.B. passt der Typ Jalousie von der Struktur her nicht zu meinen HomePilot20 RademacherGeräten. So wie ich das bis jetzt verstanden habe werden diese Typen Entwicklerseitig zur Verfügung gestellt ? Was im Grunde sehr gut ist da so eine gewisse Standardisierung rein kommt.-
Vorschlag:
Der Adapterhersteller z.B. hier Homepilot20 liefert den GeräteTyp mit - er weiss am besten wie dieser auszusehen hat. -
Vorschlag:
Der User sollte seine eigenen Typen erstellen können evtl. in einem Editor. In dem Editor können auch die Systemseitig gelieferten Typen dargestellt und verwaltet werden. Ich denke da an ein Typ --> Instanz Konzept. Das Gerät arbeitet nur mit der Instanz somit haben ich die Möglichkeit zentral den Typ zu editieren (single point of change)
Die Verknüpfung der Quellen mit den einzelnen Member des Gerätes muss mit jedem neuen Gerät (für jeden Member) auch neu durchgeführt werden. Man kann es etwas schneller gestalten indem man das Gerät unter Objekte als JSON exportiert und nach Anpassung wieder importiert, ist aber alles nicht sehr effektiv.
Beispiel: Ich habe 10 Rollos vom gleichen Hersteller somit haben alle die selbe Struktur
und ein möglicher Typ "Rademacher_Rollo" hat die Parameter des Gerät ("Position"; "Action"; etc ) schon vorverbunden da diese ja bekannt sind, Somit muss ich nach anlegen eines neuen Gerätes nur noch den richtigen Pfad auswählen.
- Vorschlag: Zweistufige Projektierung
Stufe Eins:
Zuordnen eines GeräteTyp (oder User Defined Datatyp UDT) zu dem neu erstellten Alias Gerät.
Stufe Zwei:
Verschalten des Alias Gerät mit dem Pfad des realen Geräts.
Vorteil ist ich muss nur noch eine Verbindung herstellen und nicht jeden einzelnen Member einzeln verbinden. Diese spart sehr viel Zeit und ist weniger Fehleranfällig.
Ich hoffe ich habe es einigermaßen nachvollziehbar ausgedrückt sonst bitte einfach nachfragen. Gerne kann ich das auch in Github eintragen, möchte aber erst mal ein gemeinsames Verständnis und Wording finden.
Gruß Bungee
-
-
@apollon77
Hallo, ich habe Anfang Dezember 2020 mit ioBroker begonnen und seit dem einiges getestet. Den Ansatz mit den Alias finde ich sehr gut, ähnlich einer Variablentabelle, allerdings habe ich noch einige Lücken im Verständnis der Philisophie des Adapters. :confused:
Soweit ich es bisher Verstanden habe erstellt man unter "Geräte" ein Alias Gerät (Geräte denen ich vorher schon Raum und Funktion zugeordnet hatte erscheinen automatisch in der Liste - allerdings nicht als Alias - was hat es damit auf sich wie sieht der Use case aus ?) hierbei kann man sich einen vorgefertigen Typ aussuchen.
Wenn man das neue Alias Gerät editiert sieht man, dass es eine vorgefertigte Struktur hat - welche sicherlich von dem zuvor gewaehlten Typ kommt.
Leider kann man in diesem Fenster nur die Quellen zu den einzelnen Tags/Members editieren, die Struktur selbst lässt sich hier nicht ändern genauso wie andere Parameter wie z.B. eine Konvertierung des Wertes.
Anpassungen der Struktur (Member hinzufügen) konnte ich nur unter Objekte durchführen und dort auch nur mit manuellen Anpassungen z.B. um diesen Fehler beim Anlagen eines neuen Datenpunkt unter dem Gerät zu lösen
erst wenn man den alias Parameter einfügt wird der Datenpunkt erkannt.
Legt man nun auf diese Weise mehrere Datenpunkte an funktionieren Sie in Objekte unter alias.0 auch wunderbar. Wenn man aber jetzt ein Geräte das entsprechende Gerät editiert sind die neuen Member zwar in dargestellt aber alle sind "scheinbar" mit der gleichen Quelle verbunden --> Darstellungsproblem ?
wie gesagt die Datenpunkte funktionieren.Ok jetzt zu meinem Problem bzw. Verbesserungsvorschlag.
Die Vorgegebenen Typen finde ich gut jedoch sehe ich hier den generischen Ansatz als problematisch. Z.B. passt der Typ Jalousie von der Struktur her nicht zu meinen HomePilot20 RademacherGeräten. So wie ich das bis jetzt verstanden habe werden diese Typen Entwicklerseitig zur Verfügung gestellt ? Was im Grunde sehr gut ist da so eine gewisse Standardisierung rein kommt.-
Vorschlag:
Der Adapterhersteller z.B. hier Homepilot20 liefert den GeräteTyp mit - er weiss am besten wie dieser auszusehen hat. -
Vorschlag:
Der User sollte seine eigenen Typen erstellen können evtl. in einem Editor. In dem Editor können auch die Systemseitig gelieferten Typen dargestellt und verwaltet werden. Ich denke da an ein Typ --> Instanz Konzept. Das Gerät arbeitet nur mit der Instanz somit haben ich die Möglichkeit zentral den Typ zu editieren (single point of change)
Die Verknüpfung der Quellen mit den einzelnen Member des Gerätes muss mit jedem neuen Gerät (für jeden Member) auch neu durchgeführt werden. Man kann es etwas schneller gestalten indem man das Gerät unter Objekte als JSON exportiert und nach Anpassung wieder importiert, ist aber alles nicht sehr effektiv.
Beispiel: Ich habe 10 Rollos vom gleichen Hersteller somit haben alle die selbe Struktur
und ein möglicher Typ "Rademacher_Rollo" hat die Parameter des Gerät ("Position"; "Action"; etc ) schon vorverbunden da diese ja bekannt sind, Somit muss ich nach anlegen eines neuen Gerätes nur noch den richtigen Pfad auswählen.- Vorschlag: Zweistufige Projektierung
Stufe Eins:
Zuordnen eines GeräteTyp (oder User Defined Datatyp UDT) zu dem neu erstellten Alias Gerät.
Stufe Zwei:
Verschalten des Alias Gerät mit dem Pfad des realen Geräts.
Vorteil ist ich muss nur noch eine Verbindung herstellen und nicht jeden einzelnen Member einzeln verbinden. Diese spart sehr viel Zeit und ist weniger Fehleranfällig.
Ich hoffe ich habe es einigermaßen nachvollziehbar ausgedrückt sonst bitte einfach nachfragen. Gerne kann ich das auch in Github eintragen, möchte aber erst mal ein gemeinsames Verständnis und Wording finden.
Gruß Bungee
Einfach mal über den Tellerrand geschaut:
Habt Ihr mittlerweile eine Roadmap zu diesem Thema oder zumindest eine allgemeine Roadmap 2021 für uns ?Gefühlt wurde in letzter Zeit viel am "Haus" gestrichen und auch das Dach mit einer Solaranlage ausgestattet ("Alexa Custom Skill") und sogar eine neue Dachterrasse geplant ("Text Kommandos für Alexa" ,... ) .
Aber gefühlt ist erstmal die Sanierung des Kellers notwendig, sonst bricht in den nächsten Jahren das Haus zusammen.Neue Anforderungen/UserStorys bzgl. Alexa-Unterstützung machen zurzeit keinen Sinn (wg. ausstehendem Update auf V3-AlexaApi).
Selbst für simple Grundfunktionen fehlt anscheinend das Grundgerüst (Temperatur_Steuerung/_Sensor über Alexa-App, Rolladensteuerung, usw. ).Das Basement bzgl. V3-AlexaApi sollte man schnellstens mit hoher Priorität angehen.
-
-
Einfach mal über den Tellerrand geschaut:
Habt Ihr mittlerweile eine Roadmap zu diesem Thema oder zumindest eine allgemeine Roadmap 2021 für uns ?Gefühlt wurde in letzter Zeit viel am "Haus" gestrichen und auch das Dach mit einer Solaranlage ausgestattet ("Alexa Custom Skill") und sogar eine neue Dachterrasse geplant ("Text Kommandos für Alexa" ,... ) .
Aber gefühlt ist erstmal die Sanierung des Kellers notwendig, sonst bricht in den nächsten Jahren das Haus zusammen.Neue Anforderungen/UserStorys bzgl. Alexa-Unterstützung machen zurzeit keinen Sinn (wg. ausstehendem Update auf V3-AlexaApi).
Selbst für simple Grundfunktionen fehlt anscheinend das Grundgerüst (Temperatur_Steuerung/_Sensor über Alexa-App, Rolladensteuerung, usw. ).Das Basement bzgl. V3-AlexaApi sollte man schnellstens mit hoher Priorität angehen.
@messiahs Hi, das Thema steht immer noch auf der Roadmap. Dein Vergleich mischt ein bissl ziemlich verschiedene Dinge. Der Custom SKill existiert seid über 2 Jahren quasi "ungeändert" und textCommands in Alexa2 ist ein Adapter Feature.
Aber ja, dieses Thema steht recht weit oben auf der Todo Liste ... so wie Zeit ist
-
@messiahs Hi, das Thema steht immer noch auf der Roadmap. Dein Vergleich mischt ein bissl ziemlich verschiedene Dinge. Der Custom SKill existiert seid über 2 Jahren quasi "ungeändert" und textCommands in Alexa2 ist ein Adapter Feature.
Aber ja, dieses Thema steht recht weit oben auf der Todo Liste ... so wie Zeit ist
-
@apollon77 Besteht den die Chance das dieses Jahr Zeit dafür ist?
Ohne Unterstützung der V3-Api fehlt einfach ein essenzieller Bestandteil bei Alexa. -
I added an Issue as a Feature Request for the Devices Adapter regarding enhancements in the GUI. It relates to this topic as well. I hope that the GUI for Devices, in the long run, will be as great as the rest of ioBroker. You guys are doing an amazing job with js 3.2.x and the maturity of the core features! :)
Are the suggestions useful?
-
Hallo,
ich habe mal wieder ein Frage.
Nachdem es hier ja in letzter Zeit so einige Fortschritte gab und man nun auch beim anlegen eines Devices sehen kann ob Alexa unterstützt wird habe ich das mal versucht und es klappt auch alles soweit.
Nur in der Alexa App erscheint immer noch nicht z.B. bei einem Dimmer der Slider zum Einstellen der Helligkeit.
Mache ich hier etwas Falsch oder wird aktuell die Alexa v3 API noch nicht unterstützt?Auf alle Fälle sieht das ganze jetzt schon deutlich besser aus, weiter so :+1:
-
Hallo,
ich habe mal wieder ein Frage.
Nachdem es hier ja in letzter Zeit so einige Fortschritte gab und man nun auch beim anlegen eines Devices sehen kann ob Alexa unterstützt wird habe ich das mal versucht und es klappt auch alles soweit.
Nur in der Alexa App erscheint immer noch nicht z.B. bei einem Dimmer der Slider zum Einstellen der Helligkeit.
Mache ich hier etwas Falsch oder wird aktuell die Alexa v3 API noch nicht unterstützt?Auf alle Fälle sieht das ganze jetzt schon deutlich besser aus, weiter so :+1:
@mlengen sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Mache ich hier etwas Falsch oder wird aktuell die Alexa v3 API noch nicht unterstützt?
Ne dazu kamen wir noch nicht. Die neue Version des Devices Adapters ist eine vorarbeit dazu
-
Moin Moin zusammen.
So nach 8 Jahren fange ich auch mal mit Alias an, die Sanierung ist fast fertig und das KNX geraffel läuft soweit.
Nun sollte auch mal eine Vis her. Meine alte aus Material Design Widget sollte nun abgelöst werden.
Also habe ich mal geschaut, was sich so getan hat in den letzten Jahren.
Zwischenzeitlich habe ich mal Homeassistant ausprobiert, Vis und App sind Top, der Rest ist viel Aufwand.
Gira X1 dümpelt hier auch noch rum, aber naja.
Lovelace hat mich bisher komplett überzeugt, eigene Cards können einfach importiert werden und sieht schick aus. Entitäten können auch automatisch gefunden werden, und da komm ich nun zum Problem.Da ich all meine Datenpunkte, die ich brauche als Alias ausführen möchte, kann ich diese auch jetzt mit allen Daten füllen. Rule, Datentyp, Einheiten, Read, Write usw.
Auch das Verrechnen des Alias ist ne geniale Sache.Ein kleiner Vorschlag, falls der überhaupt umsetzbar ist.
In den Ordner Alias und Userdata,
kann es für die "rule" eine fest vorgegeben Liste geben? Der Vorteil wäre dann, dass man für die Vis Adapter ein mapping machen kann und nicht gleich jeder sein eigenes Süppchen kocht. Somit würden die entitäten beim Lovelace auch autmatisch gemappt werden können, aktuell ist unklar, welche rule man da haben muss.
Das man nicht alle Adapterentwickler dahinbekommt ist mir schon klar und das die Arbeit beim User ist finde ich auch in Ordnung.Oder ist mein Ansatz total über und der Post kann gelöscht werden :-)
Gruß und Danke
Intel Nuc + Proxmox
Support us
862
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge