[SOLVED] reactor_inet_check script... and containers

[Fanan]

@toggledbits, I wounder if it's possible to use the "PlayURI" command, as in the Reactor in Vera. The aim is to play a certain Sonos playlist. My Sonos is visible both as a Vera integration and a HA integration. The Vera integration shows up as an option, but doesn't work. The HA integration don't seem to have that option in MSR. I tried to add it using the same method as you descriped above, but that didn't work. Do you know how to fix this?
Best regards,
/Fanan

[Matohl]

@fanan To play a Sonos-playlist I use the SQ:xxx command and it works well.

[toggledbits]

For Hass, the x_hass_media_player.play_media action is the one to use, but the parameters are platform (Sonos) dependent and you need to figure them out. The Hass documentation for the Sonos component has some information, but it's anything but user-friendly. Google is your friend.

For Hubitat, I've never had any luck getting Sonos to play queues, even from the Hubitat's own UI.

I will say, this is a reflection of how much the Sonos plugin on Vera simplifies the use of the zone player, because the Hass and Hubitat interfaces are pretty raw/low-level, and Sonos is complex.

[Matteburk]

@toggledbits And in Hubitat?

[toggledbits]

I think I answered that.

[Matteburk]

@matteburk sorry missed your last post

[Fanan]

Thanks everyone - I'll give it a try in the weekend!

[LibraSun]

This news just in from Microsoft:

"Thanks for using Azure Text-to-Speech. We would like to share the great news that we have recently released 12 new regions. We also released neural Text-to-Speech in 10 more languages, a new neural voice (Jenny Multilingual) that speaks 14 languages, 11 more neural voices in American English and 5 more neural voices in Chinese. When using neural voice, synthesized speech is nearly indistinguishable from human recordings."

[Fanan]

@librasun . I'm trying to add Microsofts TTS service, but it doesn't work. I got a API key and everything. Still doesn't work. My aim is to use a swedish neural voice instead of Googles voices. Is it working for you?

EDIT: I got it working! The neural voices don't support my region, so I had to change the region (created a new service), when I was logged in at Azure.

[Tom_D]

I am trying to enable MSR TTS on Google home devices. I found the local_hass_devices.yaml file already existed with the above example.
So in the true spirit of cutting and pasting while not knowing what I am doing I ended up with the following file:

# This file has local definitions for HomeAssistant devices.
---
entities:
  # Entry shows how an entity can have a service added and its name forced
  "hass>sensor_connected_clients":
    name: "WebSocket Clients"
    services:
      - homeassistant
  # Sample Sonos device, add the Hass "tts" service for text-to-speech capability
  "hass>media_player_sonos_living_room":
    service:
      - tts
  # Sample Sonos device, add the Hass "tts" service for text-to-speech capability
  "hass>media_player.family_room_speaker":
    service:
      - tts

[toggledbits]

What you've done here (correct approach, one little error, see below) is declare that those two media_player devices have the tts service as an additional declared service. That will cause MSR to bring in the attributes and actions of that service as supported for the device.

Hass doesn't publish what Hass services a Hass entity supports through its API. The only service that can be known for certain is the one that is part of the Hass entity ID (e.g. the Hass entity ID media_player.family_room_speaker tells you that it will support the media_player service). Any other supported services (like tts) aren't enumerated by the API, sadly (in a few cases, they can be inferred as related in a bit mask, but this is an extension and highly implementation/component dependent, not consistent at all, but I try to pick this up when known). This manual way of connecting additional services/capabilities to the entities is the best I could do at the moment.

Other things you can do in this file are override the name of the device (by supplying name: "myoverridename" at the same indent level as service:), and change the primary attribute (primary_attribute: "servicename.attributename"). When setting/overriding the primary attribute, the service must be supported by the device (so known by the device ID or added via services: in this file).

One small correction, though: the canonical ID for the third entry hass>media_player.family_room_speaker -- the dot (.) should probably be an underscore (_). Confirm on the Entities list.

[Fanan]

Picking up on my old thread. I just got Alexa working with tts in Home Assistant. Is it possible to get it to work with MSR as well? I added the speakers to my local_hass_devices.yaml, and then I got the same tts options as with google speakers. But that don't work for sending tts messages. In HA I have to add "Type: tts" for it to work. I also don't see the native Alexa voice as an option, only the same as the google speakers. It's not a personal big deal, but would be a fun and maybe useful feature in the future.

[toggledbits]

Let me play around with this a bit. You can add the notify service to the entity (have you done this?), but I'm not sure about the rest of the parameters. Some are tricky. But I want to get something like this going in my house, so good excuse to figure it out...

[Fanan]

@toggledbits said in TTS in MSR?:

You can add the notify service to the entity (have you done this?)

@toggledbits No, I haven't used the notify service. I might give it a try later this week. If you (or anyone else) figure it out, please share!

[Buxton]

@fanan Per this topic https://smarthome.community/topic/744/sending-a-service-request-to-home-assistant?_=1638829172919 I couldn't get Alexa tts to work in MSR, but I do have it working in openLuup with the following code that sits inside a simple plugin:

myEchoDevice = "alexa_media_".. myEchoDevice
myEchoMessage = table.concat(myEchoMessage)
	
local request_body = json.encode {message = myEchoMessage, data = {["type"] = "announce",method = "all"}}

local response_body = {}
	
local theURL = 'http://'..HomeAssistantIP..':'..HomeAssistantPort..'/api/services/notify/'..myEchoDevice  
	
r, c, h = http.request {
   url = theURL,
   method = "POST",
   headers = {
   ["Content-Type"]   = "application/json",
   ["Authorization"] = "Bearer ".. HomeAssistantToken,
   ["Content-Length"] = request_body:len()
   },
source = ltn12.source.string(request_body),
sink   = ltn12.sink.table(response_body)
}

The variable "myEchoDevice" is the exact name of the specific echo device (or device group) as presented in the Amazon Alexa app. I typically broadcast to all my devices via a group, intercom style, so I catch the message wherever I am in my home. The variable "HomeAssistantToken" needs to be created in HA. "myEchoMessage "is a lua table in the above code, but you could just as easily capture the message as a string, and then trim the string prior to sending it to the HTTP post request.

[toggledbits]

@fanan OK. So it turns out that this has (much) more to do with the way the Alexa Media Player service works than anything. You can simply use the call_service action on the controller's system object to call the notify.alexa_media service (or its variants, more on that below). If you do it through the system entity, you don't need to make exceptions in your local configuration to add the service -- you can run a service against any entity from the system entity, and if it's not supported, the (Hass) entity will either ignore it or log an error, but nobody dies, missiles do not launch, gravity still works, the sun continues to rise and set, etc.

Above are two different versions of the service call that do about the same thing. I'll work backwards because that's the way I figured it out...

The green-circled "short" version of the service name requires that you specify the target in the service data. The service data is a structure as shown (always). Also see the docs for the component for more info about this service and its data. The target field must be specified when using this short form of the service name, and its value is an array of HomeAssistant entity IDs (not Reactor entity IDs) for the players (Dots and Echos) that will speak the phrase. The data substructure must be given as shown.

The red-circled variant uses a longer service name that includes the Amazon device's name. Apparently the component creates a set of aliased services, each with the device name appended to the base service name. I find this annoying, because I have over a dozen Dots/Echos, so and it creates a bunch of data pollution. But, it's there, and it's usable. When you use a "long" service name, you don't need to specify target in the data, but it's otherwise the same, as shown.

[therealdb]

@toggledbits Speaking of that, is there a way to easily compose re-usable actions, so I could just pass the arguments (message and device) and call the same function? I'll use for the very same purpose, since I have a couple of endpoints doing notifications/TTS. Thanks!

[Fanan]

@toggledbits That's great news! My only problem is that my Hass entity don't have any actions... :
I don't know how you activated the x_hass_system.call_service?

Do I have to change anything in my reactor.yaml?

  - id: hass
    enabled: true
    implementation: HassController
    name: Home Assistant
    config:
      source: 'wss://f_______'
      access_token: "eyJ0eXAi_______________________________________________________________________________________________________________________________2-nLoI369-iYcJf9z_3sviSiWA"
      #
      # ignore_cert - If true, suppresses certificate validation when using wss:// (Websocket
      #               with SSL/TLS) and thus allows a self-signed certificate to be used on
      #               the Hass system.
      #ignore_cert: false
      #
      # dump_all_states - This is for troubleshooting. Do not enable unless asked.
      #dump_all_states: false
      log_events: false

[toggledbits]

@fanan That's not the system entity. It's probably named "Home Assistant" based on your configuration, and you can also filter by the sys_system capability.

[Fanan]

@toggledbits Ahh..! I see it now. Thanks! I'm struggeling with the indentation, but I guess it will come around after a few tries...
The best of all is as you so well put it: "...and if it's not supported, the (Hass) entity will either ignore it or log an error, but nobody dies, missiles do not launch, gravity still works, the sun continues to rise and set, etc."
Even Shakespeare him self would be impressed!