[feat] change entity type sent to hass - for example a switch becomes a light

[scyto]

I am new to hass, apologies if I get terminology wrong.

Is your feature request related to a problem? Please describe.
I have jasco in wall z-wave switches that control a load that is only a light.
These get called switch.name in entity, i think this means they are in the switch domain.
I downloaded a blue print that turns lights on at sunset for a defined area and all devices in it that are lights.
It doesn't work with my switches and my switches cannot be added as the blue print is looking only for entities with the domain of light.

Describe the solution you'd like
I would like an easy way in zwavejs.mqtt has discoverabilty to change the device/entity/domain type (sorry not sure what word to use, but i think it is domain) so that the device/enitiy would be see by HAAS as a light. I assume I can do this in the json and republish but I am unclear what i should change. This scenario seems like it would be quite common - aka the zwave node makes more sense to refer to what it controls, not what it is. In terms of easy a drop down of supported domains would be nice :-)

Describe alternatives you've considered
I think i can edit the blue print - but then if the community owner revises the blueprint i am on the hook for doing that to my 'fork'.
I think i can edit the hass discovery json - but i have no idea which of those things that say switch i should change to light?

Additional context
this is the blue print in question, i don't want to fork community blue prints if i can avoid it!

  name: Lights On At Sunset
  description: Turn on the following lights shortly after sunset
  domain: automation
  input:
    target_light:
      name: Lights
      description: This is the light (or lights) that will be activated at sunset
      selector:
        target:
          entity:
            domain: light
    target_brightness:
      name: Brightness
      description: Brightness of the light(s) when they're activated
      default: 50
      selector:
        number:
          min: 5.0
          max: 100.0
          mode: slider
          step: 5.0
          unit_of_measurement: '%'
  source_url: https://community.home-assistant.io/t/activating-lights-at-sunset/261814
mode: single
variables:
  target_brightness: !input 'target_brightness'
  target_light: !input 'target_light'
trigger:
  platform: state
  entity_id: sun.sun
  to: below_horizon
action:
- service: light.turn_on
  target: !input 'target_light'
  data_template:
    brightness_pct: '{{ target_brightness | int }}'``

[scyto]

this is the hass json created by zwavejs2mqtt
is one of the value pairs in this json the same as domain?

{
  "type": "switch",
  "object_id": "switch",
  "discovery_payload": {
    "payload_off": false,
    "payload_on": true,
    "value_template": "{{ value_json.value }}",
    "command_topic": "zwavejs2mqtt/BackBalcony/Lights/37/0/targetValue/set",
    "state_topic": "zwavejs2mqtt/BackBalcony/Lights/37/0/currentValue",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xff96f705_node8"
      ],
      "manufacturer": "Jasco Products",
      "model": "On/Off Relay Switch (ZW4005, 12722)",
      "name": "BackBalcony-Lights",
      "sw_version": "3.29"
    },
    "name": "BackBalcony-Lights_switch",
    "unique_id": "zwavejs2mqtt_0xff96f705_8-37-0-currentValue"
  },
  "discoveryTopic": "switch/BackBalcony-Lights/switch/config",
  "values": [
    "37-0-currentValue",
    "37-0-targetValue"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "switch_switch"
}

[scyto]

and extra credit - does hass differentiate lights that support only binary state vs can be dimmed - if so i would want hass to see this as a binary light.

[chilicheech]

@scyto, zjs2m is reporting it correctly to HASS. The device you have is a switch. I also have a switch that I use to control a light. To get around that issue I used the HASS light switch integration. https://www.home-assistant.io/integrations/light.switch/ .. It creates a light in HASS that is controlled by a switch. So, you can use that light switch integration to create a "light" device that uses the "switch" that zjs2m created in HASS. Then you can use that new "light" in the blueprint you mentioned.

[scyto]

@chilicheech looks like that integration isn't one of the in UI ones? I tend to stay away from the ones I manually have to do in YAML as I see they keep deprecating them. Either way this seems like a double hop of manual effort not to mention won't this result in a duplicative entity or device? I am already struggling with entity / device sprawl in the UI :-(

Another question that springs to mind is that integration only supports a binary switch, what about z-wave dimmers - is there a similar integration?

I can see how someone old to hass is ok doing everything via yaml I still maintain this is a useful feature - it isn't important that it reports correctly in my mind but that it reports in the most useful way possible.

I see no issue with allowing an optional abstraction like this (other than opportunity cost wrt other features).

[scyto]

i guess my real issue here is hass inability to differentiate outlet switch, in-wall light switch, bulb, light with switch (like a table lamp)

The in-wall switch example i gave is just one of a few scenarios based on my experience with other home automation systems reclassification is a useful feature. I note hass has such a feature https://www.home-assistant.io/docs/configuration/customizing-devices/#device-class but doesn't seem like it is supported for many entity types.

For now i can use the integration you suggest as it solves my immediate problem.

[scyto]

extra data on my confusion - the ISY integration sends wall switches (dimmers) as lights :-) which is why I (wrongly?) had a mind state that in-wall light switches should be represented as lights...

[chilicheech]

I think the ability to optionally classify it as either a light switch or a switch (a.k.a, light vs switch domain in HASS) would be an awesome feature to add. I think z2m can't assume by default that all in-wall switches are light switches, as some folks may be switching other types of loads with them. The option to have HASS discover it as a light or a switch would solve the issue.

[scyto]

Totally agree on the assumption part, assuming it is switch makes total sense, letting one override that in z2m would be sweet.
If i could code i would contribute, but i am just one of those annoying product managers who thinks "its code, it's all doable" ;-)

For example if the drop down to override was light, fan, etc (other domains basically) it would give a lot of flexibility (i have a switch unit - the little black things that have no actual physical switch on them controlling a fan load in my attic; the one in the picture above is a paddle switch).

BTW thanks for the workaround you gave me, it will do for now :-)

[robertsLando]

@scyto You should be able to change the default device class by adding that value to gateway values table and set a custom device class.

[scyto]

@scyto You should be able to change the default device class by adding that value to gateway values table and set a custom device class.

i tried and never managed to figure it out, the device class IIRC kept changing, i will try again

[scyto]

I had assumed i would edit the config here to redefine the device.

but i think you mean here?

If i am supposed to write the parse function, i don't even know where to start.

[robertsLando]

@scyto You can change the device class in both ways, if you do it directly by editing the discovery json remember to press the store button to store the configuration so it will not be overwritten on next startup

[scyto]

thanks, on the 'new item' i can't populate the device class - it just says no data available.

I can try the store, i think i understand the logic of that now (i read the docs more carefully tonight)

[robertsLando]

thanks, on the 'new item' i can't populate the device class - it just says no data available.

@scyto Could you retry with the master? in my last commit I have fixed an issue that caused that select to be always empty

[scyto]

i just pulled :master and used that container, assuming it has latest commit then it doesn't seem fixed?

--edit-- i have the new movie icon from 42 minutes ago, so yeah is latest and for me exhibits the same behavior as dev

[scyto]

just to make sure i am on same page - that error in the picture is for device class
value was populating with stuff

[robertsLando]

pulled :master

What you mean exactly? Are you using docker?

[scyto]

pulled :master

What you mean exactly? Are you using docker?

yes i pulled the tag master from docker bub and switched to that image on my container.

[robertsLando]

@scyto Use dev tag

[scyto]

i removed all the docker images to make sure i got latest dev and repulled dev.
still same unless i am being real dumb :-(
1am, gotta go to bed

[robertsLando]

@scyto Please send me the export of that node when you can (go to control panel select the node and click on export)

[scyto]

as requested

Downloads.zip

(interestingly if i open the node and use the export from within the nodes details pane, i get the two json files in the attached zip; but if i select the check-box for the node and use the export at the top of the nodes table one of the json files just contains undefined)

[scyto]

also to add, every single node I have shows as no data available for device class

[robertsLando]

@scyto AFAIK switch doesn't support device_class: https://www.home-assistant.io/integrations/switch.mqtt/

[scyto]

indeed that's why i wanted to be able to surface this as light device to HAAS, it only operates as a light (on / off), the feature would be to allow this binary switch to be added to the hassprefix/light topic instead of the hassprefix/switch topic - though i realize the heavy lift that would be.

I have a workaround using the switch to light integration in configuration.yaml so no need to go any further at this juncture unless i find other uses cases for the ability to reclassify (aka lie to HA).

[robertsLando]

@billiaz Thoughts?