[Reactor] Variables not updating correctly in latest-25201-2aa18550

[therealdb]

I'm trying to add dimming and color capabilities to an entity mapped via HASS (it's a Hue dimmable light - I have several I'm moving away from Vera and so I need APIs to integrate them in my existing scenes based on Vera's HTTP APIs - but I digress).

Here's what I have in terms of attributes:

power_switch.state=false
x_hass.domain="light"
x_hass.entity_id="light.luce_call"
x_hass.services=["light"]
x_hass.state="off"
x_hass_attr.brightness=205
x_hass_attr.color_mode="xy"
x_hass_attr.dynamics="none"
x_hass_attr.friendly_name="Luce call"
x_hass_attr.hs_color=[359.765,100]
x_hass_attr.mode="normal"
x_hass_attr.rgb_color=[255,0,1]
x_hass_attr.supported_color_modes=["xy"]
x_hass_attr.supported_features=40
x_hass_attr.xy_color=[0.7004,0.2993]

I'm not sure how to proceed (I've already looked at docs).

The test I've done is to add this to local_hass_devices.yaml:

  "hass>light_luce_call":
    service:
      - color_temperature
      - dimming
      - hs_color
      - rgb_color

But this doesn't seem to have any effect. Thanks!

[toggledbits]

The x_hass.services attribute value clearly shows that your config isn't making it to the Reactor entity. If it was, the services you listed would be listed there as well. So that's our goal: see those services listed on that attribute.

First, just to check the obvious, is your hass>light_luce_call entry under an entities: key in your config? You've cut off whatever comes before so I can't tell... If not, that should be there (fix and restart, then check attribute). And of course, make sure that canonical ID is correct/perfect.

If that's all correct, then try deleting the entity and restarting Reactor. The entity persistence may be keeping its already-constructed version of the entity.

Let's start there are see where we end up.

Edit: hold on!!! your service: line should be services: ! And make sure those enumerated entries are Home Assistant services, not Reactor capabilities. For example, I don't think dimming is right... I think that should be light. And I think that will add the color capabilities automatically, because those are part of the light service in HA. If you mean to extend additional Reactor capabilities, then use a capabilities: section (as shown in the docs). You can use both if that suits your needs.

Sorry for the repeat edits... there's way too much blood in my caffeine system this morning.

[therealdb]

I've added light under services (sorry for the type), restarted the service and the lights got discovered again, but no luck.

Here's the whole config file:

# This file has local definitions for HomeAssistant devices.
---
entities:
  # custom config
  "hass>light_luce_call":
    services:
      - light

Canonical id was cut&paste from the entities pane, so I'm 200% sure this is OK. Thanks @toggledbits. I'll write a small guide after it's all set, so other may benefit from this.

EDIT: so now, services are duplicated:

x_hass.services=["light","light"]

So, dimming e colored light service should be under something else...

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