[Announcement] [Release] [Beta] Version: 2018-10-30 17:30:07


#1

Dear Jeedom users,

I am happy to announce that we just released the latest Snips Plugin on the beta branch. If you stay on beta as well, please go and get the new update on your system!

The latest version contents the following updates:

Added

  • Callback scenario for each intent, this scenario will be called once this intent is detected. So that it’s much easier to have your own way to bind actions
  • Support multi-value for one slot. For example, you can speak turn on the light in the living room and bedroom, then your call back scenario will get the house_room tag as living room&bedroom.
    Then we can use match grammar of the Jeedom expression to check. This function is not yet supported by snips-binding. For example: IF tag(house_room) matches “/living room/” OR “/bedroom/” THEN ...

Changed

  • Display callback scenario status instead of language on the intent pre-view card
  • The intent card is shown in the different color setup

Please feel free to try and give us your feedback!

Thanks


#2

Nice update, not on beta here but will try to test it anyway.

Regarding match multiple slots value, in a scenario, bloc IF/THEN/ELSE:

IF tag(house_room) matches “/living room/” OR “/bedroom/” THEN ...

coorfang:

Callback scenario for each intent, this scenario will be called once this intent is detected. So that it’s much easier to have your own way to bind actions

So we won’t have to create tons of binding in an intent to match exact slots / slots numbers ?
We can now make just one binding to redirect everything from this intent in a scenario, and check slots inside the scenario ? Nice !!


#3

Hi,

Thanks for the correction of my expressing. I will change!

The answers is YES. Snips binding will be still useful if you have only a few simple action to bind. But for some complicated binding, now we can use callback scenario to handle.

Also, I’v submitted a issue about your improvements for tts on your SNIPS-tips repo. How do you think ^^


#4


:wink:


#5

Crap, I’ve just switched to the stable version a few days ago on my jeedom install :sweat_smile:


#6

Ok, sorry for confusion :disappointed:, have installed the beta and here is the correct syntax to test multiples slots value.

  • You can test one word:
    “myword” matches “/word/” -> 1

  • For several words:
    “myword” matches “/word1|word2/” -> 0 (separates words to test with “|”)

Note that matches isn’t IS but CONTAINS

  • So, here with turn on the light in the living room and bedroom:

“living room&bedroom” matches “/living room|kitchen/” -> 1
“living room&bedroom” matches “/bedroom|kitchen/” -> 1
“living room&bedroom” matches “/garage|kitchen/” -> 0

BUT:

“living room&bedroom” matches “/room|kitchen/” -> 1

Hopes is clearer now :face_with_raised_eyebrow:

Also, regarding tts default feedback always played with callback scenario, please consider this:


#7
  • callback scenario without any binding : amazing solution works like a charm with PR
  • duration still works great
  • tags : no more problems with crons
  • probability tag ok
  • multiple slots : works nice, really great.

For me, apart current PR, it’s ready for stable and is a lot more faster/easier to setup (no more tons of bindings matching slots/slot number). :+1:


#8

Now, a thing that could be amazing also : having the wakeword that triggered the comand.

This would make possible to allow or not some operation per user. For example, I could disallow my son to turn his light on at night :grinning:

We are three at home, each one having his own custom wakeword :wink:

Have a look here:

Not to merge like this, read comments.


#9

Hi Kiboost,

I am just back from holiday. Sorry for the delay replay.

1/ Thanks for reporting and fixing the tts bug. I would change it a bit and get it merged.

2/ Supporting multi hotwords is a great idea and not very difficult to realise. Referring to the pull request, I think you are on the right way. The only thing left is giving this variable an option on the configuration page. Since this is not required by everyone, they can enable or disable easily. Just like the two exist variables snipsMsgSession and snipsMsgSiteId.


#10

Hi coorfang,

I would hope you could do it, knowing your code it is a few minutes.
Like I said in comment of the PR:

The best way I think should be to store modelId inside plugin config, and then add it to payload just before starting snips::findAndDoAction($payload)

Maybe with in configuration, an option ‘listen hotword’ that would subscribe or not to ‘hermes/hotword/default/detected’ topic and add it or not to payload.


#11

Yes, sure. I am working on this today.


#12

Nice !! :beers:

Having it in plugin config instead of variable is lot cleaner I think.
Maybe provide it in callback scenario option like others tags, being greyed out if “listen hotword” is unchecked in configuration ?


#13

Ideally we should have something else shown on the plugin page, like an intent card but it should allows user to bind actions/ callback scenarios for snips system event (Such as session started, hotword detected, session ended etc… )

But I am not very sure I have enough time to implement this idea today :joy:


#14

Sincerely I’m not fond of jeedom listening to all topic.
The actual beta of the plugin, with the possibility to listen to hotword to register modelId and serve it to scenarios as a tag is really all I would need (for now ?) on jeedom side.
Other things are done with other app and their own snippet.


#15

I pushed a version that has the option on the configuration page to enable this snipsMsgHotwordId variable. Then user can use it in the scenario. Just like the snipsMsgSiteId and snipsMsgSessionId. You can simply disable it if it’s not required. (This operation will delete the variable from the scenario variable list)

Since it’s not everyone needed and only a few people need it. So I did not add it into the callback scenario tags.


#16

No problem, and that’s great

Thanks :wink:


#17

Hi

How do you prevent your son to not use your wakeword ?
I think it’s something that can’t be prevent without voice recognition.


#18

His voice doesn’t trigger my hotword and vice versa. We are three, each with his own hotword even being the same the voices are different.


#19

Sorry I didn’t try custom hotword right now.

It’s because each one record his own hotword with his voice so no one else can use it?

This custom hotword is well recognize like the default one ?