New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intent JSON has additional key - 'Kind' Its affecting HA (Version 2.5-pre) #25
Comments
Yeah, this doesn't meet hermes spec. I think parsers of hermes should explicitly be tolerant of additional fields (or a standardized I just updated my parser to deal with the change. I'm not married to a protocol from a service that decided to become more closed-- but if the spec is changed it should probably be another major version or forked/renamed. It would give rhasspy more creative freedom to control the spec's future, but not sure who all the consumers of the spec are or if anyone is currently considered an authority on it, and having a shared protocol is really important. If Snips was the only authority and now there's a vacuum, it could make sense to explicitly fork it as a community project and have a github repo for it. @synesthesiam wdyt? Does anyone have a mirror of the protocol link from the old snips wiki? Found it as a dead link when researching this, but not sure if it had a more detailed spec and can't find it in the Wayback Machine. |
I see some fix has been done. However, looks like the fix is partial. The JSON object retrieved from the UI looks okay (does not have Please see both the data JSON from UI
Values from the logs |
I've moved the extra details of the value (kind, unit, etc.) into a "value_details" property. |
Confirm & tested it is working fine. The JSON sent to HA is correct now. However, the debugger logs still seem to show old values value from logs
|
I created a fairly simple sentence. The intents are properly detected. However, the generated JSON now generates a dict for the slot instead of a direct value. meaning has an extra key/value pair Kind:Unknown. This key "Kind" is being sent out along with the proper slot values - state in this case. However, since HA is not expecting this "kind" value, the automation in HA fails. Is this something introduce in past couple of days? I remember this was not the case few days earlier.
This is currently deviated from the 2.4.19. If this is a the new standard, please let us know so that we could change at the HA side
[ControlFan]
turn the fan (on|off|swing) {state}
{
"entities": [
{
"end": 15,
"entity": "state",
"kind": "Unknown",
"raw_end": 15,
"raw_start": 13,
"raw_value": "on",
"source": "state",
"start": 13,
"unit": "",
"value": "on"
}
],
"intent": {
"confidence": 0.9,
"name": "ControlFan"
},
"raw_text": "fan on",
"raw_tokens": [
"fan",
"on"
],
"recognize_seconds": 0.048003378000203156,
"slots": {
"state": "on"
},
"speech_confidence": 1,
"text": "turn the fan on",
"tokens": [
"turn",
"the",
"fan",
"on"
],
"wakewordId": ""
}
The text was updated successfully, but these errors were encountered: