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

Allow limit frequency plan selection for gateways #3823

Closed
leogaggl opened this issue Feb 18, 2021 · 6 comments
Closed

Allow limit frequency plan selection for gateways #3823

leogaggl opened this issue Feb 18, 2021 · 6 comments
Assignees
Labels
c/console This is related to the Console needs/ux This needs UX design / approval
Milestone

Comments

@leogaggl
Copy link

Summary

When trying to set up a new gateway on the community clusters (AU1 in our case) a user is presented with a massive list of available frequency plans. Whilst this is useful as an Enterprise user or on a self-hosted system where the people setting things up have the necessary skills and knowledge, it will be highly problematic for the community clusters where there is a large number of entry-level users setting up their first gateway. This is especially problematic for us in Australia where we have already been suffering from a split of 2 frequency bands which are legal.

Currently, we already have a problem with rogue gateways (and that is with the current select box for frequency plans only showing a single option for Australia!?!):

  • 653 are on AU915
  • 293 on AS_920-923
  • 30 on AS_923-925
  • 43 on US915 or EU868

This was discussed in a community zoom meeting last night (17th February 2021) with @johanstokking.
...

Why do we need this?

The TTN community in Australia is currently trying to consolidate frequency plans (see https://www.thethingsnetwork.org/forum/t/future-strategies-for-au915-and-as923-in-australia/44218/35).

We have decided to go forward with using the current TTN recommendation of AU915 FSB2 will be the only recommendation for new gateways going forward. For special use-cases (such as dual-head gateways running 2 different forwarders), valid localised exceptions and to assist users of current gateways on the Asian frequency band, AS923 will still be used. However, the use of AS923 only gateways should be actively discouraged going forward as not to fragment the public network further.

Having only the recommended frequency plan shown for users of the Community Clusters would be desperately needed. My initial thoughts would only show the recommended plan(s) and allow an "Advanced User" option with a warning that the use of other frequency plans is discouraged as it fragments the network and limits usefulness for all. Also, a warning that some plans are actually illegal to run and could result in fines.

What is already there? What do you see now?

Current V2 gateway selection:
v2-gateway-create

On V3 currently, all the frequency options are shown to new users that are applicable in Australia

au-cluster-01
au-cluster-02

10 of those could be relevant for AU (but most of them should not be used) and 3 are specifically mentioned as recommended or in use by TTN. Only AU915 FSB2 should be recommended for Australia.
...

What is missing? What do you want to see?

Can we please limit the available options for each community cluster to the relevant regional option(s) only.

...

Environment

https://au1.cloud.thethings.network/console/gateways/add

How do you propose to implement this?

UI change (limit dropdown box selection) per cluster.

...

How do you propose to test this?

The AU community will be more than happy to assist with testing!

...

Can you do this yourself and submit a Pull Request?

We could possibly have a go, but I would assume your UX guys might want to have a say in this. Happy to see if we can assist as it would be a massive problem for TTN in Australia to have further splits rather than a planned consolidation.

@johanstokking johanstokking added needs/discussion We need to discuss this needs/ux This needs UX design / approval labels Feb 18, 2021
@johanstokking johanstokking added this to the Next Up milestone Feb 18, 2021
@johanstokking
Copy link
Member

johanstokking commented Feb 18, 2021

Thanks @leogaggl for filing.

There are two levels of filtering that I propose:

  1. Per country. Here we need to know the country of the gateway (based on the location), and then filter the frequency plans, as we list the supported countries in the index
  2. Recommendations per cluster. Specifically for The Things Network, indeed, we should highlight AU915 FSB 2 and/or bury the others under an Advanced section. This would require cluster configuration because it doesn't apply to open source or private enterprise distributions

@htdvisser
Copy link
Contributor

I don't think we should make it impossible for users to select "special" frequency plans, but we can indeed think about putting the suggested ones at the top of the list.

I also remember that we had the idea that the first step in the registration wizard would let you place the gateway or end device on a map. After that, we can quite easily filter frequency plans that can be used in the country.

Another option would be for the console to remember the "favorite" settings of the user.

@johanstokking johanstokking added the c/console This is related to the Console label Feb 18, 2021
@johanstokking johanstokking changed the title Allow limit frequency plan selection for gateways (UI change) Allow limit frequency plan selection for gateways Feb 18, 2021
@leogaggl
Copy link
Author

leogaggl commented Feb 19, 2021

I agree @htdvisser in regards to not making other choices impossible. My thoughts are similar UX to Github where only the recommended option is shown for the country and clicking into an "advanced" section reveals non-recommended options. There could be a further "danger zone" section that reveals the other options that might not even be legal (such as US915 or EU868 for testing purposes). But personally, I don't think that the third option would be needed. If people really have a need to test 868 sensors in AU (such as a node developer) you're better off to choose the EU cluster with an EU TTIG for example.

The AU example would be as follows:

The default recommended frequency plan (which makes it easy for first-time users without the necessary knowledge - not having all these options).

  • AU_915_928_FSB_2

Advanced section: displaying a warning that these are not recommended for single band plan gateways and will not contribute to a consistent regional public network

  • AS_920_923_TTN_AU
  • AS_923_925_TTN_AU
  • AU_915_928_FSB_1
  • AU_915_928_FSB_3
  • AU_915_928_FSB_4
  • AU_915_928_FSB_5
  • AU_915_928_FSB_6
  • AU_915_928_FSB_7
  • AU_915_928_FSB_8

@johanstokking johanstokking removed the needs/discussion We need to discuss this label Mar 2, 2021
@ama9910
Copy link

ama9910 commented Mar 3, 2021

I agree @htdvisser in regards to not making other choices impossible. My thoughts are similar UX to Github where only the recommended option is shown for the country and clicking into an "advanced" section reveals non-recommended options. There could be a further "danger zone" section that reveals the other options that might not even be legal (such as US915 or EU868 for testing purposes). But personally, I don't think that the third option would be needed. If people really have a need to test 868 sensors in AU (such as a node developer) you're better off to choose the EU cluster with an EU TTIG for example.

The AU example would be as follows:

The default recommended frequency plan (which makes it easy for first-time users without the necessary knowledge - not having all these options).

  • AU_915_928_FSB_2

Advanced section: displaying a warning that these are not recommended for single band plan gateways and will not contribute to a consistent regional public network

  • AS_920_923_TTN_AU
  • AS_923_925_TTN_AU
  • AU_915_928_FSB_1
  • AU_915_928_FSB_3
  • AU_915_928_FSB_4
  • AU_915_928_FSB_5
  • AU_915_928_FSB_6
  • AU_915_928_FSB_7
  • AU_915_928_FSB_8

I think this is a good approach for Australia.

@johanstokking johanstokking modified the milestones: Next Up, v3.12.0 Mar 3, 2021
@johanstokking
Copy link
Member

@kschiffer please coordinate who should implement this.

@johanstokking
Copy link
Member

We'll make this part of #3947 and subsequent work, including adding gateways to the device repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/console This is related to the Console needs/ux This needs UX design / approval
Projects
None yet
Development

No branches or pull requests

5 participants