Class objects

Configuration
1

Think this might be a “NO” but just checking…

Upon reading quite a few of the [dev] docs , I cannot ascertain if HA natively supports class objects, objects that can be instantiated to create a specific [derived] device based on the class object , which can then be instantiated to create a reciprocal entity.

For example, if we had10 radiator TRVs all the same model, ijmplemented on the mqtt platform as a sensor device with various entities implementing features of the device. On top of this there are scripts and automation, for each sensor which automate movement of input/output data. That’s a lot of code and maintenance for just one model of device.

Better, would be allow the user to configure a sensor class that can define public/private virtual/concrete configuration. This might be variables, automation, scripts, template etc… This would allow the user, through configuration.yaml (or include/packages) to instaniate the class and provide the required concrete attributess and overrride virtual arrtibutes.
e.g.

class:
  sensor:
    platform: "class" 
      public:
        virtual:
        #-- All required muteablevvariables of the mqtt:class_sensor component 
        #-- must be supplied here, unless they are *private* in which case
        #-- HA forces the instantiated class to provide the attribute key/value pair.
          name: string
          state_topic: string
          command_topic: string
        concrete:
        #-- These variables are available to use in instantiations
        #-- but are immuteable.
          mqtt_broker: mqtt.class_broker
      private:
        #-- These variables are not available to instantiations and are immuteable.
        #-- These would principally be mandated by the platform and would never change.
        automation:
           - alias: xyz
             // code , makes use of virtual and concrete variables //


# create component - Valid
trv:
  name: my test entity
  state_topic: "/mqtt/mytrv/state"
  command_topic: "/mqtt/mytrv/command"

# create component - INVALID
trv:
  #-- missing "name:"
  state_topic: "/mqtt/mytrv/state"
  command_topic: "/mqtt/mytrv/command"

# create component - INVALID
trv:
  #-- missing "name:"
  state_topic: "/mqtt/mytrv/state"
  command_topic: "/mqtt/mytrv/command"
  #-- attempt to override automation
  automation:

# create component - INVALID
trv:
  #-- missing "name:"
  state_topic: "/mqtt/mytrv/state"
  command_topic: "/mqtt/mytrv/command"
  #-- attempt to override mqtt_broker
  mqtt_broker: mqtt.my_broker

you get the idea?

2

No, but you can use yaml anchors to significantly reduce duplication in some such cases.

3

Ah, yes, I suppose it would. Not as flexible as a class , but then it wasnt intended to accomplish that. I will explore yaml anchors and scratch the head for a bit.
Cheers

1 Like
4

There’s a good reference here:

5

Thanks Tom
Ive tried several concepts using anchors but it just doesnt fit the requirement, where I have many sensors in which there are mqtt staste/topics, switches and groups, all the same bar the device OEM ID . Each entity needs to “instantiate” a generic sensor replacing say ABC in mqtt states/topics strings, logging strings, and of course the entityID placeholders.
Ah well,