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

make functionSwitchConfig less cryptic in yaml file #4913

Open
1 task done
arkarkark opened this issue Apr 22, 2024 · 1 comment
Open
1 task done

make functionSwitchConfig less cryptic in yaml file #4913

arkarkark opened this issue Apr 22, 2024 · 1 comment
Labels
enhancement ✨ New feature or request

Comments

@arkarkark
Copy link

Is there an existing issue for this feature request?

  • I have searched the existing issues

Is your feature request related to a problem?

currently parts of the yaml file are easy to understand and even update outside of the radio or companion. One area where they are decidedly complex and cryptic are the switches (like the six above the screen on a t-pro). There is a section titled switchNames which works well, but if you are trying to work out if the switches are 2POS or Toggle then you need to decrpt the functionSwitchConfig integer which is not very intuitive.

Describe the solution you'd like

perhaps ditch switchNames and replace it with a switches: array and each element in the array can have a name and also a type (and add start, group and alwaysOn

I'm not sure how much version downgrading/backward compatibility you are aiming for in the yml files.

Describe alternatives you've considered

you could keep switchNames and functionSwitchConfig and add in the switches section and update BOTH for a while so people can move back a version and then finally remove functionSwitchConfig in a later version.

Additional context

No response

@arkarkark arkarkark added the enhancement ✨ New feature or request label Apr 22, 2024
@raphaelcoeffic
Copy link
Member

I'm not sure how much version downgrading/backward compatibility you are aiming for in the yml files.

The common rule in this project is:

  • you can always upgrade to a newer version, but if you're going to downgrade, you'd better have a backup.
  • Also, we don't do such changes in minor releases.
  • If you're using nightly builds, always keep a backup of your models from the latest stable release.

So, if this is changed, it will be a one-way street only. Otherwise the data model is too hard to maintain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ✨ New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants