I’ve aready created a pull request for the issue above, but afterwards I realized that it might be better to ask if you are interested in a little bit of beautifying the UI. I’ve tinkered a little with the forms and what I can offer you is more or less a improvement of the existing which looks a little bit “bootstrappy” like this:
Ignorant question alert…
How should I go about getting the most recent version(s) of 2.5 Docker?
(I’d want the one for Intel NUC, but I may also give Rhasspy 2.5 a try on a Raspberry 3b+)
Just a heads up: the next Docker image will fix the NLU messages to align correctly again with Snips.
raw_value in slots will now be rawValue
Same thing for raw_start and raw_end
value will be a JSON object with kind and value properties
Rhasspy traditionally hasn’t differentiated between Snips’ entity and slotName fields. In the Rhasspy sentence (some text){tag}, I’d normally set both fields to tag and the value to some text. I’m trying something slightly different with slots now, and looking for feedback.
If you have the sentence ($mySlot){myTag} now, I’m setting the Snips entity to “mySlot” and the slotName to “myTag”. This works really well with numbers, because those are generated with a slot program. So (1..10){myNum} will have rhasspy/number as the entity and myNum as the slotName. Additionally, kind is automatically set to “Number”.
Unfortunately, Rhasspy’s intent JSON format has only ever had entity, so I’d be breaking backward compatibility there. My first attempt has been to leave entity alone, and add two new fields to each entity: source and kind. In the above example, the entity, source, and kind fields will contain “myNumber”, “rhasspy/number”, and “Number” respectively. I don’t like that Snips’ entity and Rhasspy’s entity fields have different values, but that may just be the price to pay.
I think that entities should be placed in slots so I liked the way Snips did it.
The user defines entities (cities for instance that are not related to any specific intent or context) and place them in different slots with custom names depending on Intent context (from, to) that give meaning to the entities.
I think « entities in slots » is clearer than « sources in entities » (which is kind of confusing).
Regarding breaking changes, I think it might be acceptable for 2.5 if it improves clarity in the long term. it might be now or never
Maybe Discourse have a survey plugin to ask the whole community what they prefer?
On example “LightOn” intent triggering I have this error home-assistant side:
File “/usr/src/homeassistant/homeassistant/helpers/intent.py”, line 74, in async_handle
raise InvalidSlotInfo(f"Received invalid slot info for {intent_type}") from err
homeassistant.helpers.intent.InvalidSlotInfo: Received invalid slot info for LightOn
I think the value should just contain the value. Not the kind and the value. I think it was the same with snips earlier. Hence, it used to work directly with HA conversation intent components. Now I have to define separate intents just for Rhasspy. see the issue I raised in the git
correct. Thatswhy I am kind of not in favor of this change as all my intents are defined in HA and I was reusing them until now. With this, I have to do a workaround to define similar intent with slot.value and call the same intent again. Kind of defeats the purpose.
The Raspberry Pi 1 has the same ARMv6 architecture as the Raspberry Pi Zero, it probably has something to do with it, because the images with 2.5.0-pre and latest tags on Docker Hub are only built for ARMv7, ARM64 and AMD64.
@koan is correct. I had tried to bundle the ARMv6 image in with the others, but my Pi Zero kept downloading the ARMv7 image and failing to start it. I’ll revisit this at some point, but you can at least manually specify the image for now