[Reactor] Bug when sending MQTT boolean payloads

[kfxo]

Is it possible to have an action for the Hass controller that would allow for defining a service call by inputting the desired service and service data parameters? This would provide an easy way to perform services for entities in Hass that are not mapped.

[toggledbits]

Literally, yes, but I'm afraid if I do it, I'll never get things mapped that need to be mapped: if there's a workaround, everyone will use the workaround and never ask for a formal mapping; when the formal mapping is released, they won't change from the workaround.

At this stage, I'd prefer to run down the mappings that need to be done. It's part of the purpose of this phase of testing. What I would rather do is document how to do mappings and get others to do them and contribute them. Would you be willing to do that?

[kfxo]

@toggledbits said in Feature Request: Hass service call action:

Literally, yes, but I'm afraid if I do it, I'll never get things mapped that need to be mapped: if there's a workaround, everyone will use the workaround and never ask for a formal mapping; when the formal mapping is released, they won't change from the workaround.

The beauty would be you would not have to do mapping for many things, but I understand why you would rather have them formally mapped at this stage. Hass moves so fast with integrating (and they already have so many) things that I fear you will never be able to keep up.

At this stage, I'd prefer to run down the mappings that need to be done. It's part of the purpose of this phase of testing. What I would rather do is document how to do mappings and get others to do them and contribute them. Would you be willing to do that?

Yes. I would be willing to learn how to do the mappings and contribute.

[toggledbits]

@kfxo said in Feature Request: Hass service call action:

I fear you will never be able to keep up.

Exactly why I want others to be able to do it, even if only as a stand-alone in their own configurations.

I'll spend some time on the docs this weekend.

[kfxo]

Bringing this back up as @toggledbits position appears to have somewhat changed. As of 21072, every single one of my Hass devices has available actions. Amazing. However, there are still gaps with specific types of devices. For example, my "Android TV" media_player devices have all of the generic media_player actions, but not the specific "Android_TV" action (ANDROIDTV.ADB_COMMAND). Same with harmony remote, has generic remote actions but not specific harmony actions. An action for the Hass controller that would allow for defining a service call by inputting the desired service and service data parameters would fill these gaps nicely.

[toggledbits]

I'd rather see how Hass defines the services for that device. What MSR is doing is querying Hass for what services it knows how to perform -- all of them. These are then made available in parity with the device's domain. There are two dump files in your logs directory, one called hass_services.json and the other hass_states.json that dump the raw responses from your system. I'd like to take a look at those. Before I break the model, I'm going to run everything down to the very last. In fact, at this point I'm more likely to work on getting user-controlled device exceptions documented than I am to break the model.

[kfxo]

Ok. I will open an issue and attach those files.

[kfxo]

@toggledbits Release 21074 includes a fix to Issue 0000111 raised with respect to this discussion but I am not seeing any additional actions. Is there something that needs to be configured for this, per the note "But, special config seems to be fine. I'll open a discussion later today on SHC for the config details for Hass"?

[toggledbits]

Paste the contents below into a file called local_hass_devices.yaml in reactor/config and restart Reactor:

entities:
  "hass>media_player_lr_mibox":
    services:
      - androidtv

Make sure each level of indent is 2 spaces, no tabs; Unix (LF) line endings.

This is a per-device override/hint. The entities key contains objects identified by the canonical ID of the entity. Within each entity, the subkey services allows you to specify additional services (as an array of service names) to bind to the device that could not be discovered from HomeAssistant's states API. You do not need to specify the service associated with the known domain of the device (media_player in this case); it is always bound.

You can also set the name of the entity if you don't want to use the friendly_name value from Hass, and you can set the primary_attribute to the attribute (which must be set/defined on the entity) to something other than that selected by the default mappings.

entities:
  "hass>media_player_lr_mibox":
    name: "Living Room TV"
    primary_attribute: "x_hass_attr.source"
    # ...etc...

[kfxo]

@toggledbits Success! When pasting into Notepad++ I had to edit the line endings to (LF) and I also had to change the ID from "hass>media_player.lr_mibox" to "hass>media_player_lr_mibox".

[toggledbits]

Apologies. That's correct. I'll change the example.

You should be able to extrapolate this to any other entities. It's akin to doing the configuration on Hass with the "platform" key as you showed me in your config. I do wish they'd expose that data somehow. Hopefully, this will suffice. There are other things you can do in this file, but we'll get to that later.