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

Dynamically define source types #39

Open
valterc opened this issue Jan 7, 2025 · 3 comments
Open

Dynamically define source types #39

valterc opened this issue Jan 7, 2025 · 3 comments
Labels
enhancement New feature or request sensors

Comments

@valterc
Copy link

valterc commented Jan 7, 2025

Hi, as a long term item, would it be possible to have an extension sensor as data source for E-Bike data fields?

@brentnd
Copy link
Member

brentnd commented Jan 7, 2025

I haven't checked it myself but I think you could use the Type for LEV to do this right now.

LEV_ASSIST_MODE

There are several other LEV_* types you could support too.

DataType.Source vs DataType.Type was created to give a distinction for the types we'd expect as source but they're just strings. I'll make a note to try this out and add to Source if it works.

@brentnd brentnd added question Further information is requested sensors labels Jan 7, 2025
@valterc
Copy link
Author

valterc commented Jan 7, 2025

I noticed that the string values are identical between the DataType.Source and DataType.Type. I will try that too, thanks for the quick answer!

Btw, unrelated question: Let's say we have an extension sensor that at the time it was added to Karoo it indicated to emit some data types, let's say Device(extension, uid, listof(DataType.Source.SHIFTING_FRONT_GEAR)) and later, in an update to that extension we want to emit more datatypes from that extension sensor. How should that be done? Should we just emit more datatypes, or should we implement different extension sensors per each datatype?

@brentnd
Copy link
Member

brentnd commented Jan 7, 2025

Right now, the sources defined at the time of scan are what that sensor can produce.

Adding an ability to make them dynamic definitely makes sense (we do this internally).

A new DeviceEvent should cover this in a compatible way that is opt-in.

@brentnd brentnd added enhancement New feature or request and removed question Further information is requested labels Jan 7, 2025
@brentnd brentnd changed the title Add data source for E-Bike fields Dynamically define source types Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request sensors
Projects
None yet
Development

No branches or pull requests

2 participants