Devices, Alias, Assistenten + Visualisierungen + die Zukunft

Videonisse

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

And 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

da_Woody

@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 ?

Alias anlegen

Garfonso

@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

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:

2020-10-20 12_53_12-OCF Device Type overview - Example Required Resources.png
Source: https://openconnectivityfoundation.github.io/devicemodels/docs/index.html

2020-10-20 13_11_27-OCF_Resource_Type_Specification_v2.2.0.pdf - Example Light Dimming.png
Source: OCF Spec v.2.2.0 Resource Types

Garfonso

@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

(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

bungee71

@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

Messiahs

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.

apollon77

@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

mlengen

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

apollon77

@mlengen Ich hoffe ja ... Das Jahr ist ja noch Jung und der controller 3.2 dann auch bald fertig :-)

Videonisse

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?

https://github.com/ioBroker/ioBroker.devices/issues/55

mlengen

gelöscht

mlengen

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:

apollon77

@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

ple

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

da_Woody

@ple sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:

der Post kann gelöscht werden

warum? du schreibst von vis, homeassistant, lovelace...

kann es für die "rule" eine fest vorgegeben Liste geben?

wenn ich dich nicht komplett falsch verstehe, JSON sollte sein, was du magst...

apollon77

@ple ich denke du meinest role (Rolle) und nicht rule. Wenn du den devices Adapter nutzt zum anlegen der aliase dann erkennt lovelace auch die passenden Typen.

ple

@apollon77 sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:

legen der aliase dann erken

Moin Moin,
ja ich dachte auch, dass es recht einfach mit dem Geräte Adapter geht, um eine saubere Struktur zu haben und auch alle Vorteile nutzen zu können.
Anscheinend ist es aber so, dass die States nur groß geschrieben werden können und es nur eine feste Vorgabe gibt.
Das hätte ich anders erwarten. Ich denke, es wird wohl einen Grund haben, warum das genau so gemacht worden ist, aber wäre vielleicht auch ein anderer Weg gehbar oder für die Zukunft eventuell.

Hier mal ein Beispiel.

Für die Visu ist doch eigentlich nur die Rolle (value.temperatur) + Raum + Datentyp (bool, integar ...) interessant. somit weiß die Visu zB. Lovelace, dass es eine Entität Sensor ist.
In meinen Beispiel könnte der Ordner WW das Device sein, somit wären alle drunterliegenden States, egal ob temp oder switch dem Device WW zugeordnet. Man könnte es auch dreistufig aufbauen.
Heizung = Device
WW =Channel
Kühlung = Channel
Heizen = Channel
und darunter dann die States jedlicher Art.

Für Räume wäre dann
Wohnzimmer = Device
Beleuchtung = Channel
Verbraucher = Channel
Sensoren = Channel
und darunter dann die States jedlicher Art.

damit irgendwelche Adapter die States mappen können und wissen was was ist ( type-detector ) bräuchte man doch nur Rolle, Typ, mappen.

Jetzt wäre es doch gut, wenn der Ordner Alias sowie Userdata nur die Rollen/Typen zulässt, die auch angedacht sind für iobroker, unabhängig welches Gerät verwendet wird. Aktuell ist es so, dass jeder da reinschreiben kann was er möchte.
![0_1662962667851_fb1f178d-641d-4824-b367-b2a8721abe56-image.png](Lade 100% hoch)

Klar liegt die Arbeit bei User, aber das wärs mir Wert, damit nicht alles doppelt gemacht werden muss.

Gruß und Danke für die Infos.

apollon77

@ple type detector nutzt rollen und typen und auch die Strukturierung in Channeln beispielsweise (weil ja zb bei einer Farblampe mehrere States "zusammengehören"). Nur Rolle und Typ ist zu kurz gefasst. Die vorgegebenen "Standardnamen" für relevante States helfen weiter zu wissen was es ist, sind aber nicht sooo wichtig - war nur die Idee es einheitlich zu machen.

Ich würde auch keine Devices oder channels für Dinge "verschwenden" wo man enums nutzen kann . alles voran Räume oder Funktionen. Also wäre das für mich alles "folder".

Community Forum

NEWS

Devices, Alias, Assistenten + Visualisierungen + die Zukunft

Devices, Aliasses, Assistenten und Visualisierungen und die Zukunft

Aktuelle Realität und die Probleme ...

Erste Schritte: Aliasses und der Basis-Devices Adapter

... aber die Zukunft wird besser

Schritt 1: Gerätetypen und "Objekt-Templates"

Schritt 2: Geräte-Guidance durch Adapter

Schritt 3: Der "Geräte-Posteingang"

Schlussworte

Nächste Schritte

Support us

350

32.5k

81.8k

1.3m