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

Some datapoints are string, but number would be better #123

Open
neunteufels opened this issue Mar 20, 2022 · 6 comments
Open

Some datapoints are string, but number would be better #123

neunteufels opened this issue Mar 20, 2022 · 6 comments

Comments

@neunteufels
Copy link

Datapoints, e.g. battery.voltage, input.voltage,... , are type string, but number would make more sense (IMHO).

Writing datapoints of type string to InfluxDB works, but makes live just complicated.

BR
Stefan

@Apollon77
Copy link
Owner

The problem is that there is no real list of values (yes some are "common" but in fact all depend on the used driver).

So the adapter should just guess ... and guessing means ... meehhhh

Need to think about that

@neunteufels
Copy link
Author

Did have time to think about it already?

BR

@Apollon77
Copy link
Owner

Not really. YOu are free to use aliases or own Javascript states to convert the values as needed in the meantime

@PeterVoronov
Copy link

Not really. YOu are free to use aliases or own Javascript states to convert the values as needed in the meantime

If I prepare the appropriate PR - will you look for approve?

@Apollon77
Copy link
Owner

Sure.
I could think of two options:
A: I would think that a setting like "try to detect numbers and automatically convert" or such would help, but then also needs to remember which fields were then created as numbers for future processing - especially if a field that contains a number is now an empty string or a real string ...
B: simply detect numbers and create additional objects with "name_number" as name or such and write the value as number in there IF parsable ... with this the adapter just needs to remember which "_number" objects where already created

I personally would go with option B because "Not breaking" ... Maybe add an option if such number parsing should be done (but can also be omitted) ...

What do you think? Which ideas you had to do it backward compatible and handle type-issues (honestly I do not trust that all nut "plugins" are developed constistent on the value types?

@neunteufels
Copy link
Author

At the moment I don't know how I could help here.
If I can somehow, please let me know.

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

No branches or pull requests

3 participants