I need some great minds to help come up with a solution to an issue

Third party integrations AppDaemon
1

I’m being a bit of a nit pick when it comes to integrating Alexa and home assistant. I use emulated hue for all my lights and it works great. I have AppDaemon handle all my automations and its lightning fast. I like that. So… on to my issue.

In my current setup, I create groups in the Alexa app. I can use phrases to turn the whole group on or off. The unique part about this setup that I love is the following scenario:

I have 4 lights in a group. 2 lights are currently on. With Alexa, I can ask her to turn on the group and the remaining lights will turn on.

This is the same for turning off lights as well. 4 lights, 2 lights are on, 2 are off. I can tell Alexa to turn the lights off.

This is all great, but Alexa can be pretty slow if there is many lights. AppDaemon with Home assistant turning on/off devices is so much faster. So I’d like to emulate this functionality using AppDaemon or a custom component.

The issue I am running into is based on 2 limitations:

In home assistant, if a device is on, you cannot tell it to turn on again. HA will simply ignore the service call. (at least this is what appears to happen)

In Alexa, turn on/ turn off phrasing can only be tied to a single control. You can’t link "Turn on X’ to Script A and “Turn off X” to script B. This would be required if I wanted to fire a turn on script and a turn off script in HA.

So my dilemma is I need a device in HA that is agnostic of a state but acts like a input_boolean. So I can call turn_on/turn_off regardless of it’s state.

I’ve linked input_booleans to a list of entities, but no matter what logic I use i get into one of the following scenarios:

I have 5 lights, 4 are on. I want to turn them all on, but the input_booleans state is already on. Or vice versa with the devices being off.

Does anyone have ideas on skirting around this issue? maybe some other control? maybe I can make a new component for HA (I don’t really know the API yet).

2

And what if you use a http post command to turn on certain device(s)? You can use a IFTT Webhook for instance.

3

I should have specified. I also want to keep the interactions local for speed purposes. When using Emulated Hue, Alexa uses your local network. I was trying to keep that functionality.

4

It sounds like Scenes may be closer to what you want. You can turn a scene on as many time as you like I believe.

5

do scenes work with ‘turn_off’ as well?

6

You can set the desired state per entity. So you can’t turn a scene “off” but you can create a scene and configure the scene to switch every entity to “off” Here is an example of a scene:

  - name: Sleep
    entities:
      light.diner_table:
        state: off
      light.living_room:
        state: off
      light.hall_way:
        state: off
      light.pc:
        state: off
      light.kitchen:
        state: off
      light.bedroom:
        state: off
      light.bathroom:
        state: off
      switch.table_lamps:
        state: off
      light.livingroom_lamp:
        state: off
      switch.tv_lamp:
        state: off
      light.table_l:
        state: off      
      light.table_c:
        state: off   
      light.table_r:
        state: off            
      switch.livingroom_fan:
       state: off
      media_player.home_group:
       state: off 
      climate.family_room_de_residentie:
       state: eco
      switch.air_freshener:
       state: off
      switch.christmas_tree:
       state: off

I’m not sure if it will send another “off” command if a certain entity has allready the desired state.

7

Yes, but that still doesn’t solve the issue of it needing to be 1 entity for Alexa. I would have to create an ‘on scene’ and an ‘off scene’. Then I would have to use the phrase “Alexa, turn on on scene” and “Alexa, turn on off scene”.

It just looks like its not possible at this point.

8

I use node-red as the emulated hue, with the alexa local node and the HomeAssistant node, and have this sending various commands to HA. I guess you should really be able to achieve what you want with a bit of work.

9

you need 2 names but you can make them logical.
“alexa turn on all lights” will turn on the on scene
“alexa turn off every light” will turn off a boolean that activates the off scene and the boolean on again.

10

but using a skill shouldnt make much speed difference.
the alexa-appdaemon-app gives you the option to trigger appdaemonscripts directly with 1 alexa command.
but you need to use: “alexa ask appdaemon to turn off/on the lights.”

11

Yeah, I’m just being a nitpick. I’m trying to get the best of all worlds. Emulated hue makes things pretty easy but its limited to ‘on/off’ phrases and its 100% local.

Does the appdameon skill route in alexa use the internet to handle the transactions or is it local?

12

alexa is never 100% local.

your alexa device can only listen to 1 word local.

the command is handled local, but as soon as you cut the internet, alexa will do absolutely nothing with emulated hue.
so you are wrong in you idea.

13

The emulated hue is local because its built into Alexa without being a skill. All the on/off commands are sent through the local network and never leave, thats why emulated hue is so much faster than hasska or any alternative. It’s the main reason I want to use it.

14

it can never be local.
you can give any name to a device.
only the reaction to the command is local.
all soundrecognition from alexa is online. they made that absolutely clear.
alexa should have a hugh memory available to recognize every command made to hue. and it has not.
the speechrecognition is done online and then send back as command that is dealt with locally.
here is the difference:

you speak to skill > alexa translates to text > text send to AWS > AWS sends command to device
you speak to hue > alexa translates to text > text send as command to device
AWS can be any other kind of in between step also.

alexa appdaemon is almost the same speed.
you speak to appdaemon > alexa translates to text > appdaemon does the work.

i have both and notice no difference.

but i am 100.000% sure that all speechrecognition is done online.
test it and disconnect your router and try to let alexa do anything. she wont do anything, except telling you that she isnt able to help you!

15

you’re correct - that’s exactly how it works.

I’ve found things slower than emulator hue when they rely on other 3rd party clouds, e.g. I’ve tried the Vera Alexa smart skill, and the LightwaveRF one, and they’re both slower than using a local emulated hue, as Alexa invokes the skill in that 3rd party cloud, time/latency gets added in their device’s cloud and then that talks to your device back home - sometimes painfully 5-10 seconds later.

The Alexa-Appdeamon-app you built is running locally - Alexa, responds to that to control the devices, but it does jump via a skill, so it’ll route to the created skill first which will all be in AWS servers, so should only add minimal/unnoticeable delay.

I’ve not used Alexa-Appdaemon-App yet, but as it’ll give much more flexibility than the limited scope provided through the emulated hue function I’ll be giving it a try at some point :slight_smile:.

16

no the skill doesnt use the AWS servers.
i have no AWS account, because it requires a credit card.
the skill is made as custom skill, the disadvantage is that you need to say “alexa ask …”
the advantage is that you can program everything locally, which gives you complete freedom.
and speed.

17

I suspect you miss understand me - there’s a custom skill you create that’s internal to amazon and will reside in AWS servers somewhere, not something you pay for. That skill routes to the HTTPS a-a-a, so when you invoke a command, it’s alexa/echo to AWS for voice recognition, then to the skill definition to determine what to do/where to go, then to a-a-a. With the emulated hue, there’s no separate ‘skill’, so in this scenario, after voice recognition, whilst it might still bounce around AWS, ultimately it will to route back to the echo device and then that will communicate with the emulated hue on the local network to action.

18

smart skills use AWS servers.
custom skills do not.

there is no difference there with hue.

speak to alexa > alexa translates to text > alexa sends text to hue > hue does interprete the text as command
speak to alexa > alexa translates to text > alexa sends text to predefined url > appdaemon interprete the text and does what it want with it.

with smart skills

speak to alexa > alexa translates to text > alexa sends to AWS > AWS skill interprete the text > then a command is send to a predefined point.

AAA doesnt use AWS servers!
thats why commands like “alexa, turn on …” are not possible

i could have used a smart skill, but then i need AWS, and an AWS account only can be created with a credit card.

i think you didnt know that there are 2 options to create a custom skill. with and without AWS

alexa%20tutorial7
alexa%20tutorial71039×961 120 KB

as you can see here AAA does use the HTTPS way and not the AWS way.
thats why its always as fast as possible (same speed as emulated hue)

1 Like
19

I think we digressed a little bit. I’m fairly sure what I want to do is not possible with the phrases that I want to say.

20

your right, not with a simple turn on turn of.