Rhasspy Home Assistant add-on: is it possible to create skills?

Awesome news!!

If the app isn’t receiving the slot then there may be something wrong with the sentences. Can you share your sentences for grocy?

@JoeSherman issue solved, probably a restart of Rhasspy / Host is needed to execute the slot program and grab its results to the memory, I can’t explain it differently because it’s the only action that worked, at least in my case.

Now I would like to share with you new evidences, hoping these feedbacks could be useful for you to improve your work:

  1. With this sentences linked to the intent [TimeGetTime]:
    “che ore sono a (){timezone} [timezone]” (what time is it, in italian)
    → Rhasspy recognize the time zone slot only if I type on the front end (never with voice, probably for the special character ““) “che ore sono a America New_York” (New York without _ or before America it’s not recognized as slot) → maybe the slot_program can be improved, for example with a replace(””," ") and all the permutation (ie 1 row with America New York and a 2 row with New York America).

  2. The time difference is recognized by Rhasspy (obviously also in this case the time zone must be explicated like above) with the right intent that is sent to the skill but the following error appears in the container log:
    [INFO:2023-04-25 15:47:11,410] TimeApp: Intent: 8d52d9be-62bc-4422-84a6-8cc9d262fb45 | Completed: TimeTzxDiff
    [ERROR:2023-04-25 15:47:11,415] HermesApp: on_raw_message
    Traceback (most recent call last):
    File “/usr/local/lib/python3.8/site-packages/rhasspyhermes_app/init.py”, line 212, in on_raw_message
    await function_i(nlu_intent)
    File “/usr/local/lib/python3.8/site-packages/rhasspyhermes_app/init.py”, line 332, in wrapped
    message = await function(intent)
    File “hermes-app-time.py”, line 91, in get_tz_difference
    hours = diff_hours_tz(timezone1slot.value[‘value’],timezone2slot.value[‘value’])
    File “hermes-app-time.py”, line 40, in diff_hours_tz
    utc_dt = datetime.now(datetime.tzinfo(ZoneInfo(str(from_tz))))
    TypeError: ‘getset_descriptor’ object is not callable

Thanks!

Hey @JoeSherman,
I’ve changed in the hermes-app-time.py:
→ utc_dt = datetime.now(datetime.tzinfo(ZoneInfo(str(from_tz))))
with → utc_dt = datetime.now(ZoneInfo(str(from_tz)))

seems working…difference between NY and Rome:
[INFO:2023-04-25 16:14:43,362] TimeApp: Intent: 2562c452-ce77-440f-ba7f-64a377fd3e31 | Completed: TimeTzxDiff
[INFO:2023-04-25 16:14:43,481] TimeApp: Intent: 2562c452-ce77-440f-ba7f-64a377fd3e31 | Difference in hours: 6
[INFO:2023-04-25 16:14:43,485] TimeApp: Intent: 2562c452-ce77-440f-ba7f-64a377fd3e31 | Completed: TimeTzxDiff

Awesome! And my first bug with the code! This is great! Such a cool feeling.

Tha ks for finding the bug. I will update my code and publish a new version. I will also work on the special character thing. I will probably be ok just replacing those with spaces but I’ll see what makes the most sense.

Thank you again!!

So this gave me a chance to try out the github issues so thank you!

I created 2 issues. And they are both already closed. I wish it was this easy at work.

I found a pretty decent fix for the slot program. I also thought of a way I want to enhance it. I want to make it display the list again but strip off the first “country” word. So, you would be able to say “America New York” or “New York”. It wouldn’t work for every city but the core timezone names.

I suppose a nice next version of this would be to load a city to timezone database and build an intent to translate city/town name to time zone and do the same thing. That could be used for both diff and time in time zone (city) intents.

If you have Home assistant instance, why do you need another app running in another container? Why not use Home Assistant to handle intents or events?

I’m running Home Assistant and Rhasspy on same Raspberry Pi 4 and using events to control my smart devices. For skills I’m using automatons written in yaml. So, what the benefits of using another app?

I am under the belief that Home Assistant is good for somethings and not for others. My work on the Grocy skill is a precursor for my major adventure which is a JellyFin/Media Player skill.

As I sat and started working with Rhasspy connected to my HA instance I found the idea of trying to teach Rhasspy how Home Assistant controls Jellyfin made no sense to me. “Why am I not teaching Rhaspy to talk to Jellyfin?” Home Assistant’s integration to Jellyfin is great and all but lacking buy a ton, I still can’t find a way to get a media listing from their API, so how would I provide Rhasspy a slot program for song names or whatever.

This is when I decided I was going to have HA control HA’s things, and build skills for Rhasspy when it made more sense. I admit this line is gray, and some will differ in opinion.

To that point I have also started building a bunch of media player related event scripts in HA that I plan to share as well, and while these technically could be used to control Jellyfin, the capabilities I plan for my skill are far beyond what the HA integration can provide (I think). So I plan to use those skills to control other media players like my TVs and such. And I use HA to control the IoT “Home Automation” devices.

After writing the Grocy skill I have to admit that I think it is probably possibly to recreate the functionality in HA. But I don’t know if the HA integration to Grocy covers all the objects I did/plan to. But I’m pretty sure I could make a set of intent scripts that would make Grocy very usable through HA.

But as I said before, I mostly did the Gorcy skill as a precursor to the Jellyfin one, just so I could get my feet wet with a well documents python API (pyGrocy), focus on building out the skill, and then take that to the Jellyfin one. While building it I also kept in mind the concepts the HA group is with making it a multi-lingual skill, and while mine is not yet, the additional of the random response sentence started the framework towards it.

The whole thing resulted in a python project template/class that I have shared on my Github which is a wrapper for the Hermes App class the Rhasspy people put out. This is setup to be able to read from a local config file and connect to a Rhasspy config to “install” it’s sentences automatically (does not overwrite existing), and can be used to store connection information for API the skill needs or various other thing. I’ve been trying to make the skills more “deployable”, excuse the term, but more commercialized, polished. My hope is if I can create a nice set of easy to deploy skills that are actually useful. No offense to all the time skills out there (I built one too) but we need our voice assistant to do more than tell the time. For that matter it needs to do more than be able to turn my lights on and off.

And yes I know HA is working on that. The stuff that is coming in the 2023.5 release is potentially game changing. But I am worried it will still be bound by the HA API, and it’s integration’s capabilities. If that’s the case, then to me, it will still be in need of external skill programs to “complete” the eco-system. I may move my work over to the new Wyoming protocol at some point, we’ll see.

I know that was long winded, and I admit this is all just my thoughts and opinions. But I hope you can understand the reasoning for some of it. And I understand this is not a one-size-fits-all type of thing.

1 Like