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

Support SG on BierBot Bricks #559

Merged
merged 5 commits into from
Feb 4, 2022
Merged

Conversation

BernhardSchlegel
Copy link
Contributor

If iSpindel transmits SG (and not °P) 1 decimal (1.0, round(x*10)/10) is not sufficient. This PR ensures, that 4 decimals are send to the BierBot Bricks backend. This way, gravity values like SG=1.0482 can be transmitted to the BierBot Bricks backend without loss of information.

If iSpindel transmits SG (and not °P) 1 decimal (1.0, `round(x*10)/10`) is not sufficient.
Copy link

@jonathanschneider jonathanschneider left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commit changes decimal point of gravity measurement sent to BierBot bricks to support SG and has no effect on the rest of the firmware.

@pppedrillo
Copy link
Contributor

4 decimals in SG can be a bit of overshoot.

@BernhardSchlegel
Copy link
Contributor Author

That's one more than actually needed to be able to round backend-wise and enable data freshness checks. I'm happy to change it if really necessary. But IMHO it should not hinder the merge.

WireTownMan
WireTownMan previously approved these changes Jan 8, 2022
Copy link

@WireTownMan WireTownMan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change corrects a defect that allows bierbots to use Plato or SG. Does not impact anything other than number of decimal places transmitted

@thegreatgunbantoad
Copy link
Contributor

API_BRICKS seems to be the only API that does this. It this truncation needed at all?

@BernhardSchlegel
Copy link
Contributor Author

I'm personally a fan of a deterministic memory footprint in non-garbage collected environments and deterministic POST payloads. But: I don't want to force other APIs to follow this approach.

Is a discussion about one decimal more or less really worth our time? I would really appreciate if we come to an agreement :) If that's the only concern hindering the merge, I'm happy to change it to avoid further waste of time and energy on all sides.

@pppedrillo
Copy link
Contributor

Is a discussion about one decimal more or less really worth our time? I would really appreciate if we come to an agreement

This discussion at least can help to save this pull request from the stale bot's shredder :) Apparently, you haven't looked at these things from this point of view :)

@BernhardSchlegel
Copy link
Contributor Author

hehe, that's indeed correct. So how do we proceed? Can someone with the necessary rights to merge a PR make a clear statement ("remove truncation"/ "truncation to three decimals is fine" / "trundcation to four decimals is fine")?

Thanks in advance!

@WireTownMan
Copy link

Is a discussion about one decimal more or less really worth our time? I would really appreciate if we come to an agreement

This discussion at least can help to save this pull request from the stale bot's shredder :) Apparently, you haven't looked at these things from this point of view :)

It is all about decimal places. With 1 decimal place bierbots will only support Plato units, with 3 or more decimal places it will support Plato and Specific Gravity (SG). So, yes this discussion is all about one the number of decimal places transmitted to the bierbots API

@pppedrillo
Copy link
Contributor

pppedrillo commented Jan 9, 2022

It is all about decimal places. With 1 decimal place bierbots will only support Plato units, with 3 or more decimal places it will support Plato and Specific Gravity (SG). So, yes this discussion is all about one the number of decimal places transmitted to the bierbots API

But still 4 decimals doesnt make any sense because you simply dont have an instrument to measure with such precision (I believe you need a device that can measure gravity up to 5 decimals to get reliable 4 decimals result).

Overall, to me it sounds like an attempt to fix bierbots issue (eg unable to configure gravity units in bierbots) on the iSpindel side? Why dont fix it on bierbots side?

@WireTownMan
Copy link

It is all about decimal places. With 1 decimal place bierbots will only support Plato units, with 3 or more decimal places it will support Plato and Specific Gravity (SG). So, yes this discussion is all about one the number of decimal places transmitted to the bierbots API

To me it sounds like an attempt to fix bierbots issue (eg unable to configure gravity units in bierbots) on the iSpindel side? Why dont fix it on bierbots side?

Fixing on the Bierbots side would force ispindel to be a device that is setup for Plato units. This is inconsistent with other interfaces that allow the gravity to be either P or SG.

@BernhardSchlegel
Copy link
Contributor Author

BernhardSchlegel commented Jan 9, 2022

Overall, to me it sounds like an attempt to fix bierbots issue (eg unable to configure gravity units in bierbots) on the iSpindel side? Why dont fix it on bierbots side?

Nope, BierBot Bricks backend can't do much if the iSpindle user decided to go with SG and sends a 1.0 reading...

But again: I'm happy to fullfill any request to be able to merge. Please just tell me what you want.

@pppedrillo
Copy link
Contributor

pppedrillo commented Jan 9, 2022

@BernhardSchlegel
Sorry I feel I still missing something (sorry, I'm not familiar with bierbots API).
Putting aside deterministic things, what if there would be no truncation at all?
I mean from the very beginning - in your very first bierbots support version. If all the data which currently truncated (SG, Temp, Voltage and tilt) would be sent as is (eg their "raw" values), as all the other APIs do?
If truncation (or any other conversion) need, it must be done on the bierbots side?
And no need to put a magic numbers 10, 10000 etc and change them to "fix" something later?

@thegreatgunbantoad
Copy link
Contributor

I think it may be worth splitting this into two items. One quick and easy fix as this current request has. And then maybe open a discussion point as to whether or not the truncation can be removed altogether.
From what I can see the current correction looks fine, and I don't see a reason not to merge it.
Long term I do think we need to answer whether or not the raw value could be used.

Copy link
Contributor

@thegreatgunbantoad thegreatgunbantoad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine, but please open a discussion point to raise the issue of whether or not BierBot Bricks could simply accept the raw untruncated value.

@pppedrillo
Copy link
Contributor

pppedrillo commented Jan 10, 2022

From what I can see the current correction looks fine, and I don't see a reason not to merge it.

This merge can potentially cause future "fixes" in the same style.
The problem was with initial implementation which had such truncation from the beginning.

If there is no technical showstoppers for sending raw values without truncation, I'd propose change values to raw now and forget about bierbots fixing for a while. @thegreatgunbantoad

Copy link
Contributor

@pppedrillo pppedrillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd propose to get rid of truncation and send a raw values in the same way as the other APIs do.

@@ -788,7 +788,7 @@ bool uploadData(uint8_t service)
sender.add("brand", "wemos_d1_mini");
sender.add("version", FIRMWAREVERSION);
sender.add("chipid", chipidHashed);
sender.add("s_number_wort_0", (float)(round(Gravity * 10) / 10));
sender.add("s_number_wort_0", (float)(round(Gravity * 10000) / 10000));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we consider to send a raw values (without truncation) instead of such fixes with changing a magic numbers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done! 👍

pppedrillo
pppedrillo previously approved these changes Jan 10, 2022
Copy link
Contributor

@pppedrillo pppedrillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM @BernhardSchlegel
Clang format has to be run onto iSpindel.cpp to get rid of lint errors. Format Document or Shift+Alt+F in VC Code

Capture

Copy link
Contributor

@pppedrillo pppedrillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be merged as soon as build gets fixed,

EDIT: fix #566

@thegreatgunbantoad
Copy link
Contributor

From what I can see the current correction looks fine, and I don't see a reason not to merge it.

This merge can potentially cause future "fixes" in the same style. The problem was with initial implementation which had such truncation from the beginning.

If there is no technical showstoppers for sending raw values without truncation, I'd propose change values to raw now and forget about bierbots fixing for a while. @thegreatgunbantoad

The sort of point I was going for was that this was a fix in the style of the original code which I can't see any major issue with.

Secondary to that was the query of weather the original should have been coded that way which is a bit of a different issue and could have been made it's own pull request in order to keep the two issues segregated.

@pppedrillo
Copy link
Contributor

pppedrillo commented Jan 10, 2022

Secondary to that was the query of weather the original should have been coded that way which is a bit of a different issue and could have been made it's own pull request in order to keep the two issues segregated.

Looks like this is not "two issues" (which should be kept segrregated) but the only one and the same. Nevertheless, @BernhardSchlegel already removed truncation. @thegreatgunbantoad

@thegreatgunbantoad
Copy link
Contributor

thegreatgunbantoad commented Jan 10, 2022

Secondary to that was the query of weather the original should have been coded that way which is a bit of a different issue and could have been made it's own pull request in order to keep the two issues segregated.

Martin, looks like this is not "two issues" (which should be kept segrregated) but the only one and the same. Nevertheless, @BernhardSchlegel already removed truncation. @thegreatgunbantoad

Indeed. I still don't think they needed to be the same problem (solve one thing at at time or you'll never get anywhere), but one did certainly raise the other. But that looks moot now anyway. Cheers to @BernhardSchlegel for not losing his mind while we all discuss the awkwardness.

@thegreatgunbantoad
Copy link
Contributor

@pppedrillo huh, didn't realise git hub knew my name.

@thegreatgunbantoad
Copy link
Contributor

@BernhardSchlegel, oh cool are you the BierBot-Bricks developer, didn't realise that. That's cool.

@BernhardSchlegel
Copy link
Contributor Author

Can we please merge this?

Copy link
Owner

@universam1 universam1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

@universam1 universam1 merged commit a66ba1d into universam1:master Feb 4, 2022
@BernhardSchlegel BernhardSchlegel deleted the patch-1 branch February 4, 2022 16:05
@BernhardSchlegel
Copy link
Contributor Author

Thanks!

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

Successfully merging this pull request may close these issues.

6 participants