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

Fix float32 negative value/ add validation for range limit #7488

Closed
wants to merge 6 commits into from
Closed

Fix float32 negative value/ add validation for range limit #7488

wants to merge 6 commits into from

Conversation

garciaolais
Copy link
Contributor

@garciaolais garciaolais commented May 10, 2020

Required for all PRs:

  • Signed CLA.

  • Associated README.md updated.

  • Has appropriate unit tests.

  • Fix 7317

  • Add test for negative float32 values

  • Updated Readme inside code


  • Fix 7227
  • add validation for range limit

@garciaolais garciaolais changed the title Fix float32 negative value Fix float32 negative value/ add validation for range limit May 10, 2020
{ name = "TankLevel", byte_order = "AB", data_type = "INT16", scale=1.0, address = [0]},
{ name = "TankPH", byte_order = "AB", data_type = "INT16", scale=1.0, address = [1]},
{ name = "Pump1-Speed", byte_order = "ABCD", data_type = "INT32", scale=1.0, address = [3,4]},
]
Copy link
Contributor

Choose a reason for hiding this comment

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

Make sure to preserve 2-space indention of this text. I think we should actually update the README to match the sample configuration, since the sample config is using the preferred Telegraf style for field names.

@@ -513,7 +522,7 @@ func convertDataType(t fieldContainer, bytes []byte) interface{} {
return scaleFloat32(t.Scale, f32)
case "FLOAT32":
if len(bytes) == 2 {
e16 := convertEndianness16(t.ByteOrder, bytes)
e16 := int16(convertEndianness16(t.ByteOrder, bytes))
Copy link
Contributor

Choose a reason for hiding this comment

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

I realize that I'm not sure what the FLOAT32 data_type is supposed to be. It appears that before this PR it was a 2, 4, or 8 byte unsigned integer that is converted to a float64 and scaled. After this pull request it appears that it is two's complement signed integer.

If I'm understanding correctly, the issue I see is that the value could be either of these encodings and there is no way as a user to select which it is. If we apply this change, large positive values will begin being reported as negative values.

Let me know if my understanding is accurate, and we can try to brainstorm a solution.

@danielnelson danielnelson added area/modbus fix pr to fix corresponding bug labels May 15, 2020
@sensor-freak
Copy link
Contributor

The proposed change modifies the conversion of 16 bit values only, However, for 32 bit and 64 bit values the behaviour remains the opposite. This seems to me unexpected behaviour.

It would be better if all cases are handled equally.

@srebhan
Copy link
Member

srebhan commented Nov 10, 2020

@garciaolais:
Isn't this superseeded by the newly added FIXED format? Am I missing something or is FIXED doing exactly what you are proposing? If not, please resolve the merge conflict and also fix 32 and 64-bit versions!?

@garciaolais
Copy link
Contributor Author

Hi @srebhan I need to verify the new terms, maybe this change its not valid anymore.

@srebhan
Copy link
Member

srebhan commented Nov 11, 2020

@garciaolais: Sure. Just compared your code to what is in master and it looks very similar. Just let me know on what you think!

@garciaolais
Copy link
Contributor Author

@srebhan: in a few days I Will have free time, I hope check this issue very soon 👍

@srebhan srebhan self-assigned this Nov 14, 2020
@srebhan
Copy link
Member

srebhan commented Nov 26, 2020

@garciaolais any chance you find some time to look at this?

@garciaolais
Copy link
Contributor Author

Hi @srebhan , Tomorrow I have a free weekend, I will working in this

@garciaolais
Copy link
Contributor Author

Hi @srebhan

Today I checked this and its seems that the #7869 solved the issue #7317

For this reason, I will close this PR

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/modbus fix pr to fix corresponding bug
Projects
None yet
4 participants