Skip to content
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

feat/captor data periodic flux #20

Open
wants to merge 13 commits into
base: develop
Choose a base branch
from

Conversation

RyanIkhlef
Copy link
Contributor

@RyanIkhlef RyanIkhlef commented Feb 23, 2022

Live data transmission mode replaced by a periodic data transmission mode.

  1. Every 5 minutes, we ask to the sensor to give us the data collected.
  2. Computes average value of these data.
  3. Deletes old data (to avoid reading data already collected).

Warning: during the time between step 2 and 3 we can loose 1 or 2 seconds of data.

@Alystrasz Alystrasz self-requested a review February 23, 2022 15:06
@RyanIkhlef RyanIkhlef marked this pull request as ready for review February 23, 2022 16:03
Copy link
Member

@Alystrasz Alystrasz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current UI is adapted to live data transmission, not at all to periodic transmission:

  • on first connection, application displays "waiting for data" while it's downloading history from sensor;
  • once history download is done, indicators appear on screen, but they don't move (since there's no live data reception)

I feel like user should have the choice between live and periodic transmission; I'm open to chat about this.

@Alystrasz
Copy link
Member

It seems that data is not sent to grafana correctly.

Capture d’écran de 2022-02-24 14-12-52

@RyanIkhlef
Copy link
Contributor Author

It seems that data is not sent to grafana correctly.

Capture d’écran de 2022-02-24 14-12-52

I don't have this problem, my data are sent to my influxDB :
image
my db :
image

@RyanIkhlef
Copy link
Contributor Author

Current UI is adapted to live data transmission, not at all to periodic transmission:

* on first connection, application displays "waiting for data" while it's downloading history from sensor;

* once history download is done, indicators appear on screen, but they don't move (since there's no live data reception)

I feel like user should have the choice between live and periodic transmission; I'm open to chat about this.

I'm agree with this, I think we can add a button in settings view to change the transmission mode.
But I don't know how to represents fixed data from periodic mode ?

@Alystrasz
Copy link
Member

I don't have this problem, my data are sent to my influxDB :

Are you using same influxDB version as Apolline backend: https://github.com/Apolline-Lille/apolline-backend-ng ?

But I don't know how to represents fixed data from periodic mode ?

To begin, we can display last data point on screen; we should display a message that tells that we're waiting X minutes to sync with sensor, so that people do not think the app crashed.

@RyanIkhlef
Copy link
Contributor Author

Are you using same influxDB version as Apolline backend: https://github.com/Apolline-Lille/apolline-backend-ng ?

Yes I am using it and I didn't change anything from the docker image.

To begin, we can display last data point on screen; we should display a message that tells that we're waiting X minutes to sync with sensor, so that people do not think the app crashed.

I see, I'll try to do this.

@RyanIkhlef
Copy link
Contributor Author

Here some screenshots of the new feature:

The button to switch between live data transmission and periodic data transmission in the settings view:

Screenshot_20220228_135153_com science apollineflutter

The data view when the app get data periodically:

Screenshot_20220228_135240_com science apollineflutter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants