Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 24 13:38

    hongquan on development

    Fix coding style (compare)

  • Aug 24 13:32

    hongquan on development

    Fix coding style. (compare)

  • Aug 24 06:08
    norbusan commented #524
  • Aug 24 06:08

    norbusan on development

    build plan action support * Ad… (compare)

  • Aug 24 06:08
    norbusan closed #524
  • Aug 24 06:08
    norbusan closed #521
  • Aug 19 15:04
    alok760 commented #524
  • Aug 19 12:50
    norbusan commented #524
  • Aug 19 12:43
    alok760 commented #524
  • Aug 17 21:04
    alok760 synchronize #524
  • Aug 12 21:34

    norbusan on development

    try rx versions that are availa… (compare)

  • Aug 10 13:37
    alok760 edited #524
  • Aug 10 13:37
    alok760 ready_for_review #524
  • Aug 10 13:36
    alok760 synchronize #524
  • Aug 09 13:55

    norbusan on development

    add restart-on-failure to susi … (compare)

  • Aug 07 09:35
    alok760 synchronize #524
  • Aug 05 15:28
    norbusan commented #521
  • Aug 04 05:22
    alok760 synchronize #524
  • Aug 04 05:18
    alok760 synchronize #524
  • Aug 04 02:58
    alok760 synchronize #524
Norbert Preining
@norbusan
@Orbiter could you give us your input on fossasia/susi_server#1341
The other opion if we don't rely on the susi server doing it, is that we could automatically create a user according to the user/pass saved in the config.json, but that doesn't make much sense either ... being myself unclear...
Mario Behling
@mariobehling
@alok760 The control page functionality is already on the webclient. I don't understand why this is still worked upon in the installer: fossasia/susi_installer#77 Could you explain?
@alok760 According to your scrum this is the main work since the beginning of the week. Could you please help to speed things up? What about the integration of the setup page in the web client? I don't see an issue about this. What are the next steps?
Mario Behling
@mariobehling

@alok760 I understand that your GSoC project is difficult to organize into milestones across repositories, but could you please let us know what you are planning to achieve in the third term? This is usually the term to speed up and finalize things. I am worried about the outcome, cause I don't see a final sprint yet.

Please refer to our meeting notes about open points we need to get skills and connections of the smart speaker working locally, e.g.:

  • Planned Actions implementation to get things like alarms working (I haven't seen any issue from your side opened even though we are discussing this several weeks now)
  • Synchronization of online skills with local device. (Mentioned several weeks. Did you open an issue somewhere?)
  • Make public skills on the device itself not editable (Issue? Idea for approach?)
  • Storing and accessing skills through local webclient - how to do it? How to synchronize? (Issue? Approach?)
  • Documentation: There are a lot of new features. Are there any guides/documentation from your side yet? (Any relevant issues?)

What other points are there, that need to be covered?

Alok Kumar
@alok760

@mariobehling Thanks for pointing out the different issues

@alok760 The control page functionality is already on the webclient. I don't understand why this is still worked upon in the installer: fossasia/susi_installer#77 Could you explain?

The endpoints which were used to control the device were causing SUSI_linux to crash, those were then disabled temporarily and Norbert asked me to disable them on the control template as well() because currently the only way to control the device is through the control page as the webclient is unable to authenticate a user (fossasia/susi_server#1341).

@alok760 According to your scrum this is the main work since the beginning of the week. Could you please help to speed things up? What about the integration of the setup page in the web client? I don't see an issue about this. What are the next steps?

I have now opened an issue for the setup page and adding more options to the control page
fossasia/susi.ai#2743
fossasia/susi.ai#2742
I will work with web client team and add any required changes in the speaker

I will also speed things up from today :)

Alok Kumar
@alok760
I have also created issues in the relevant repositories for the points mentioned
planned action implementation issue is already present - fossasia/susi_linux#521
I will implement planned actions in SUSI_Linux and work with the web client team for the integration of the setup-page this week.
Mario Behling
@mariobehling
@alok760 Thanks! There is a lot of work that we don't see yet entirely, e.g. we still want to give users the option to edit locally stored skills. This needs to be implemented in the web client as well.
Mario Behling
@mariobehling
@alok760 Could you please help to code this for the web client and server as well as the team already has to take care of many issues?
Michael Christen
@Orbiter

@Orbiter could you give us your input on fossasia/susi_server#1341

@norbusan this is complex. We should not go a naive aproach here. Authentication is also then not enough, what we also would need is a process which passes on every request to the local server to the central server. This contradicts the whole idea of having a local server, because we want to be offline and/or fast. Still beeing offline and/or fast would then require a queueing operation which makes things even more complex. Why are we following this requirement at all? What is the benefit?

I believe timed actions are much more important and gives us much more opportnities!
Norbert Preining
@norbusan
@Orbiter ok, thanks for the explanation. On second (or better fifth) thought I actually think that it is not necessary to log into the on-device susi-server at all. The only thing that makes a difference are the (not hitherto implemented) private skills. These skills can be synced/downloaded/uploaded by a separate daemon on the RPi using the config.json data, and just provides these skills to the on device susi-server. That would be enough.
Do you agree with that evaluation?
Mario Behling
@mariobehling
@norbusan @Orbiter There are a few additional questions to consider. There are security relevant changes that should only be accessible for logged in devices. We cannot simply expect that all local devices are behind a firewall and cannot be accessed by others. So, we need an additional level of security for local devices. But, as a first step we could just neglect this in order to make things work. We could also consider to only provide access to the local device with a password set locally.
What do we need login for:
  • Access to play songs and execute skills (we don't want someone else from the outside or who has access to the local network to do this)
  • Creating local (private) skills to be executed on the device (and to upload/sync them to the online server into their own account)
  • Changing device configuration, location, name, used TTS/STT
Alok Kumar
@alok760
I'm trying to implement a scheduler, getting some weird issues, but it should be completed before the meeting
@norbusan I have an idea to make playback controls work again via the control server, i will try to finish that off as well
Akshat Garg
@akshatnitd

@/all I finally made the server implementation for timed action, which I now call „planning“.
See this example: https://api.susi.ai/susi/chat.json?timezoneOffset=-120&q=set+alarm+in+one+minute
This creates three actions and two of them are ‚planned‘, which means they have an execution time attached.

@atm1504 The planned skills should be implemented this way. You have implemented it incorrectly.

Amartya Mondal
@atm1504
SO what the above skill means is that when the query set alarm in one minute is made, we should be setting up the scheduler to play music as per the response of the above query. If so, then I will implement that.
Akshat Garg
@akshatnitd
plan a joke at *
!plan $1$: `tell me a joke`
I will tell a joke at $1$

of course

@atm1504 Something like this

Amartya Mondal
@atm1504
Okk. I will do it. First I will start with basic implement
Implementation, then I will go on for other queries
Mario Behling
@mariobehling
@alok760 We are often trying to showcase the SUSI.AI device at events or different meetups. It is sometimes challenging to configure the WiFI as the time is limited and venue and WiFi credentials can change quickly, e.g. when changing a room. An idea to make the config of the smart speaker easier would be to allow storing of different WiFi credentials, e.g. we could also store a WiFi phone hotspot as a backup. This feature exists on the Linux desktop and Android phones. What are your ideas to make sth. like this happen for the smart speaker?
Alok Kumar
@alok760
@mariobehling great idea, this should be implemented, I'll look into it
Mario Behling
@mariobehling
@alok760 In which repository should an issue about this be opened? For the UI in the web client? Where else?
Alok Kumar
@alok760
@mariobehling https://github.com/fossasia/susi_installer the access point scripts and control server needs to be modified
Mario Behling
@mariobehling
@alok760 Ok, thanks. Please open issues in all relevant repos. So, we can follow up there as well.
Alok Kumar
@alok760
Sure @mariobehling, I'll work on this and see how this should be implemented
Alok Kumar
@alok760
Created the Issue here - fossasia/susi_installer#85
Nguyễn Hồng Quân
@hongquan
Hey, I learnt that you guys are experiencing some random crashes that you cannot catch (it happens when you are not observing it). So I suggest to install Sentry (https://sentry.io/features/) to collect the data at the crash time, for investigation later.
Sentry can be installed on our server https://github.com/getsentry/sentry
Norbert Preining
@norbusan
@hongquan are you talking about the susi linux crashes - yeah, they are consistent, and even with the sound server disabled I see them - yesterday I did a new test build and flashed it.
The problem is in the portaudio library failing an assertion. And snowboy uses pyaudio uses portaudio.
Just yesterday I sent an email to the portaudio mailing list about that.
Michael Christen
@Orbiter
@/all here is now an easy skill in the CMS which starts many actions:
https://susi.ai/Novelty%20and%20Humour/Apollo_Countdown/en
call with: „rocket launch"
https://api.susi.ai/susi/chat.json?timezoneOffset=-120&q=rocket%20launch
Alok Kumar
@alok760
@Orbiter this implementation is great
i see that alarm implementation has also changed
we have separate plan_delay for every action now.
@norbusan
The implementation for planned action will again require changes in susi_python
I'm working on it
Amartya Mondal
@atm1504
@Orbiter it looks great to me. Its much easier to implement on the android client now. I will again re factor the code accordingly.
Michael Christen
@Orbiter
Great! I suggest that the plan_date is used to fire up the action, not the plan_delay because it makes it possible to make more accurate events where the server is sure about the exact time. The plan_delay has more a debugging character to understand better what is going on.
Having plan_date as steering value for the device this would make scientific use possible because then Susi would be able to do accurate measurements.
Akshat Garg
@akshatnitd
The web client feature was designed to use, plan_delay. Will make the change.
Amartya Mondal
@atm1504
I have made the changes in the android client and it make uses of plan_delay. So shall I use plan_date instead?
Norbert Preining
@norbusan
@alok760 great!
Alok Kumar
@alok760

@stealthanthrax @norbusan
In order to implement planned actions correctly, a list of all actions from the server response needs to be sent to the busy state, so that actions which are planned for later execution can be sent to the scheduler and actions which doesn't have any plan_delay or plan_date are executed instantly.

For example:
skill to set alarm in one minute has the following two actions -

  • First

      {
          "language": "en",
          "type": "answer",
          "expression": "alarm set for in one minute"
        },
  • Second

        {
          "expression": "ALARM",
          "language": "en",
          "type": "answer",
          "plan_delay": 60004,
          "plan_date": "2019-08-12T23:45:39.729Z"
        }

here the first action needs to be executed immediately and the second action needs to be sent to the scheduler.

but currently what susi_python does is, it takes the list of actions, parse each action into an object, then go through the objects' attributes and create a result dictionary.
the result dictionary just contains the keys which are to be executed and doesn't have distinguished actions.

So I have a few questions

  • why dont we send the list of action directly to the busy state ?
  • what are the advantages of making objects and creating a result dictionary?

I see two ways of implementing planned actions now-

  • Use the current infrastructure of susi_python and add the plan_delay and plan_date attributes to all the different action type objects and return a list of these objects
  • Just return the list of actions as it is sent by the susi_server

what do you suggest ?
Thank you

Michael Christen
@Orbiter
@/all attention: I removed all dates in format RFC1123 and replaced it with ISO8601. We had some inconsistencies because those formats had been mixed. There should now only be ISO8601. Please check if your code is parsing RFC1123 and replace it with ISO8601!
Alok Kumar
@alok760
@norbusan please review - fossasia/susi_python#13
Norbert Preining
@norbusan
@alok760 merged, thanks
Alok Kumar
@alok760
Thank you :)
Alok Kumar
@alok760
@norbusan please review fossasia/susi_linux#524
Alok Kumar
@alok760
@norbusan I've updated fossasia/susi_installer#97 to use the susi_config module