Set Reaction > Script Action

[toggledbits]

OK. That's an improvement. You should now have x_hass_light capability on the Reactor entity, and that should have a turn_on action that will accept dimming and color values. This is derived from what information Hass does make available about the service (generically). Mapping to specific native Reactor services is going to take more work on my part... I'll send you an upload link, and if you would, please upload your hass_services and hass_states.json files (in logs) there. But go ahead and starting working with x_hass_light... that should be fine.

[therealdb]

Yeah, I'm already doing that, but I'm writing a new bridge from my own code to call actions based on standard Reactor capabilities via HTTP and that's easier than using x_hass_light. I'll test the new bits as soon as I'll be back home. Thanks!

[toggledbits]

You won't get much out of it yet, then... I need to grab your uploaded data and create the mapping.

[toggledbits]

OK. Got your data. It looks like issue is pretty simple, actually, and you shouldn't need any local customization once I get a fix to you: the xy_color model isn't yet supported in MSR. And since that's the only color mode that Hue device supports, it comes up dry. I've got some construction projects I'm working on this afternoon, but will bundle an update to the device mappings file for you later today. This should be easy to address.

[therealdb]

Many thanks! The fix seems to work. However, I've both RGB and HS colors as attributes and I'm sure both are supported as well. This is the same for brightness, but maybe that's HASS not correctly reporting all the supported modes from the Hue integration, because these are supported by HASS.

service: light.turn_on
data:
  rgb_color:
    - 255
    - 0
    - 0
target:
  entity_id: light.luce_call

This is working 100%, as well as the HLS, rgbww and transitions.

EDIT: forgot the attachment.

[toggledbits]

Here's what Hass reported for light.luce_call:

        {
            "entity_id": "light.luce_call",
            "state": "off",
            "attributes": {
                "supported_color_modes": [
                    "xy"
                ],

There are other devices for which brightness is a separately declared feature/mode, but not on this device. Others, like piscina_led declare xy and color_temp, but not brightness, rgb, etc. At the moment, HassController will support what is declared. I don't think it can reasonably guess brightness if it's not declared; that seems dangerous. I could see providing mappings between rgb, hs and xy color modes, making all available and translating as needed into what's supported, but that would take a little longer to implement.

[therealdb]

Looking at the code, it's declaring brightness only when color modes are not supported:

core/homeassistant/components/hue/v2/light.py at 115a1ceea0c568ffb466e03b4ab322f253ccf151 · home-assistant/core

:house_with_garden: Open source home automation that puts local control and privacy first. - home-assistant/core

HASS is weird, because looking at dev docs:

Light entity | Home Assistant Developer Docs

A light entity controls the brightness, hue and saturation color value, white value, color temperature and effects of a light source. Derive platform entities from homeassistant.components.light.LightEntity.

When a color mode as hs or rgb is supported, The light can be dimmed and its color can be adjusted.
So, brightness is implicit.

More weirdness incoming.

If I call the set rgb color service, the color Will be removed from the service call if not supported and translated to rgbw_color, rgbww_color, hs_color or xy_color if supported by the light.

So, I could set rgb (as I’m doing via the service call) and HAAS will convert for me if not supported.

Long story short: I’m ok with HASSController not discovering, but I’d like a way to force at my own expenses. Thanks!

[toggledbits]

I'll adjust the mappings to take this into account. You could also do it yourself using the local_hass_devices mechanism (forcing the brightness service in the services section, or the dimming capability in the capabilities section), but that would be tedious because it's per-entity, and if that's what HA does the built-in mappings should reflect that.

Updated mappings file has been posted. Download it and give it a try.

When the ZIP file version and placement are correct, you'll also find these entries in your log file:

[###BUILDVERSION###]2022-11-09T12:37:55.829Z <Controller:INFO> HassController#hass ZIP data update found (/home/patrick/Documents/reactor/src/config/hass_data.zip)

...

[###BUILDVERSION###]2022-11-09T12:37:55.986Z <Controller:INFO> HassController#hass loaded hass capabilities ver 22312 rev 2 format 1 

...

[###BUILDVERSION###]2022-11-09T12:37:55.996Z <Controller:INFO> HassController#hass loaded implementation data ver 22312 rev 3 format 1 

Notice it says rev 3 for the implementation data file.

[therealdb]

At work with spotty internet. As soon as I'll be back home, I'll try it. Thanks!

[therealdb]

So, it's working perfectly now! Thanks!

[therealdb]

I've also updated https://github.com/dbochicchio/vera-VirtualDevices if anyone is still using it. I've added specific support for MSR dimming (0/1) and RBG endpoints. I've also added a couple of examples.

I'm still using the old devices on my Vera, because I have some code still calling the Vera's endpoint and no time to replace it. I'll eventually remove the virtual devices, but right now it's serving me well, so why not. Status is keep in sync by MSR rules.