jarvyj / homeintent Goto Github PK

For folks who want to integrate with an already running rhasspy instance (is it a hass os addon?) or a custom mqtt setup within a rhasspy profile

Similar to timer, but instead set an alarm to go off at a certain time. Maybe it should be baked into the timer component.

There were some really nice suggestions from the rhasspy forum thread on some clarifications on setup/microphones that could be made.

This would allow people to override a section of the config as opposed to the entire config, which will make it easier for folks to set custom wake words if desired.

timers respond with "Timer set <time>"
groups respond with "The <group> group has been turned on"
switches respond with "The <switch> switch has been turned on"
shopping lists respond with "Adding <item> to the shopping list"
lights don't respond with anything (#7)

We have different sentences and tenses everywhere!

https://homeintent.jarvy.io/integrations/home-assistant/#lights

Somehow missed the light examples!

They are a little messy and a lot of the static code analysis tools choke.

I almost never use the check/uncheck everything from the shopping list (or even for specific items). I usually just the the add/remove, so it might be worth removing the unused ones to avoid a potential mistrigger.

This is also because I will mark them as completed while shopping. We'll see if anyone else uses those intents, otherwise consider removing them.

we need to fail the build if the unit tests fail

It doesn't register the shopping list as a sentence anymore. I think this might be related to the #34

They aren't quite normal/guessable yet based on how everything else works.

Need the ability to enable/disable intents programmatically.

https://homeintent.jarvy.io/developer-reference/api-reference/#intentson_eventregister-not-yet-implemented

Time for some custom sound beeps!

• beep hi
• beep low
• error
• alarm sound

I think we can make for a more polished experience.

I've been thinking about creating a frontend so people can more easily make modifications to their customizations (and maybe default configs?!).

I might end up changing the deployment strat again if it happens, but we shall see how that goes!

it's a different type of command. You don't need to "to" in the sentence. We'll keep it for now and see if anything breaks. I'll have to do some more testing.

If I enabled the following customization:

other unit tests break because they see one more method in the sentences, even though it's not referenced there. I played around with fixtures, which fixed some of these sorts of problems, but it didn't quite work for me in the end.

I think it has something to do with how python/pytest work and the imports. I will have to do some digging at some point.

I tried adding raspberry jam to the shopping list and it just added "jam". I noticed that if i put parens around raspberry jam in the list it would work correctly.

Still need to do some testing if it's also needed for dictionary lists, but I bet it is.

Home Assistant will list all the supported features for the different entities. There's no point in allowing a light to change color if the light doesn't support changing color.

Right now, with the "Text FST" settings, it will try to set a 0 second timer frequently (likely because it has a lot of options for text) if it doesn't hear the text clearly enough. Planning to just error out and call it a day. It might make the overall experience a little better.

It's a bit of a workaround, but not too bad imo.

Let people do some amount of custom configuration in /config/customizations/<component_name>.yaml
https://homeintent.jarvy.io/getting-started/customization/

We should probably also tell people the name of the component in someplace that's not just the log output!

• slot update/remove
• sentence update/remove
• sentence alias
• disable all
• disable intent
• refactor
• document what the component (or customization file) names are

There's a lot of fun options here for sentences here!

"What's the forecast"
"What's the weather going to be on "
"When is it going to <rain/snow>"
"How is the temperature outside"

and I'm sure plenty more. We will also need to figure out a response sentence structure for returning attributes.

Right now it is always enabled, with no real way to turn it off.

https://homeintent.jarvy.io/integrations/home-assistant/#on-prefer_toggle

Waiting on #3

The extrahead blocks don't get built into the docs. Couldn't figure it out, so creating an issue for now to look into later.

The user should get an auditory error if something has gone wrong during intent handling.

maybe remove the chicken nuggies and motz. I can add it back to my own configuration using customization! :P

I wanted to get some of these in for #17, but ran into some fun issues when writing the tests yesterday (#55).

So, some of this stuff will have to come later.

Something is up. When I ask it to "turn off the kitchen light" it'll take a bit longer. I know once or twice it's gotten that intent confused with "check off the kitchen lime" (which then errors out).

Maybe disable some of the "check off" things from the shopping intent? or change the sentence structure?

Support climate controls from Home Assistant.

This really relies on #15 to be in place, as there are a lot of different climate options.

Try loading from components, then fallback to the /config/custom_components directory so folks can make their own components.

https://homeintent.jarvy.io/getting-started/advanced-features/custom-components/

This will likely be setup like:

• set kitchen to [daylight]

with daylight, bright white, natural white associated with the kelvin. Will probably set them up as a yaml key/value pair that is user customizable.

So now we change lights to a cool color and then also set them back to a cool white!

alright, we should probably have some sort of unit tests around this.

Originally posted by @JarvyJ in #6 (comment)

Write a bunch of unit tests to actually test all the different customizations and ensure they do what they claim to do.

This should be done after the unit tests (#17) are in place.

It's over 350 lines and some of the methods are getting quite large.

Maybe have the "happy path" of disabling intents holistically by creating a /config/customizations/home_assistant.yaml or maybe in the home assistant settings in the config. But basically just having one spot for folks to disable entities. Otherwise there could be a lot of jumping around to different files to disable specific intents.

Maybe this wont matter after the UI is in place. It sort of relates back to #15

It just sounds weird. I might also remove the word "lock", as it too sounds weird.

Currently the timer allows you to set a max_time_days but does nothing with it. It existed around the idea of Home Intent auto-restarting daily to pull new Home Assistant devices, but that is likely going to be a webhook at some point.

Regardless it should either be supported in the code or removed from the docs

Unfortunately i think this will fall on the user for now. Maybe one day in the future with a web frontend, we can do some playback/microphone tests to ensure the correct one is picked.

If a component or custom component tries to make an import and it fails, it'll always throw a

Example:

import non_installed_module

__main__.HomeIntentImportException: Unable to load custom component 'component_name from /config/custom_components. Ensure the filename and config value match up.

While the error message is true, it's also very misleading. It would be better if it returned a more familiar python error.

I think this update is not doing a deep merge as the system field disappears in the profile after setting it up.

The general idea is the user can add a sentence that triggers a series of intents from across Home Intent.

It would operate similar to sentence aliasing (https://homeintent.jarvy.io/getting-started/customization/#intent-aliasing-with-slot-entities), just across even more intent types. The files could live in /config/scripts/<script_name>.yaml and just have a series of intents and what to pass them.

It's a little bit of a weird idea, as you could also just setup a script in Home Assistant and then maybe we could enable script component and you can trigger it from there. I dunno, we'll think about it.

I'll have to spend a bit of time with GitHub Actions to make this happen!

Open/close and tilt covers!

Currently they don't say anything and just quietly make the change

Have the ability to pull new components from Home Assistant without restarting the entire service. This gets a little finicky as it introduces weird situations of what to do when devices are temporarily out of action in HA.

This might come a bit later as Home Intent currently doesn't really have its own state system, and will likely need one to get something like this working reliably.

It really shouldn't... I'm sure there's something we can do to make the experience better and more plug 'n play!

Humans will definitely say "tomorrow" at times, especially when trying to get the weather! Also "evening"

Currently the timers all break when upgrading to 2.5.11, the intent is recognized correctly, but the times are not parsed from the sentence. Going to have to figure that one out before upgrading.

Values are no longer loading form the customization files

This might just be easier to get people to wrap their heads around. It also makes it easier to handle #10 as there's only one "system" and moving files around would be easier. It could also let people provide their own custom sounds (if wanted).

I think I should be able to just build Home Intent from the rhasspy base and then start both processes. Might also explore some other options.

sometimes intents cause more system confusion and aren't heavily used. Turning your living room to aquamarine might be a cool party trick, but is likely not used heavily in day-to-day.

These could be easily disabled with customizations (#6), but perhaps they could also be enabled in the same way. Maybe set this up whenever the frontend gets built out.