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
Track printer profile information #4847
base: maintenance
Are you sure you want to change the base?
Track printer profile information #4847
Conversation
Good request. Can I ask someone to develop a Plugin that can auto-set the 3d printer filament setting like TPU filament and ABS filament? |
@huminlian What a great way to make people dislike you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See line comment
for k in ["id", "name", "model"]: | ||
# Scrub these out since they could be identifiable information | ||
profile.pop(k) | ||
args["printer_profile"] = profile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will need a further deep dive to be flattened. We cannot push hierarchical data like this over to the tracking subsystem, it will end up as one repr
string, completely unsearchable or otherwise usable.
I suggest we concentrate on some key infos like extruder count, bed size, presence of heated bed and heated chamber?
Oh shoot I forgot all about this. To be honest the most important data point I was concerned with was how many profiles were defined. I figured it would be worthwhile gathering all the data though for futures inquiries. Anything you think should be left out? Also - I'm wondering if this should be broken out into an independent plugin so it could be updated mid cycle if there was some information needed. Not actionable for this PR but curious what you're thoughts are on that? |
What does this PR do and why is it necessary?
This PR adds printer profile information to anonymous tracking. This can be useful to determine what features/changes to focus on.
How was it tested? How can it be tested by the reviewer?
This was locally tested to ensure the data is compiled and shipped. Data ingestion rules may need to be adjusted to accept the traffic and the dashboard will need to be updated to make use of the data.
Any background context you want to provide?
What are the relevant tickets if any?
Screenshots (if appropriate)
Further notes
Right now the primary reason to gather this info is to see how profiles are used. Initially I think it would be worthwhile to display a profile count as a pie chart in
data.octoprint.org