Skip to content

Reading some parameters return 'None' rather than the correct value #9

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.

Sign up for GitHub

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

Jump to bottom
Open
krcook opened this issue Jan 29, 2025 · 2 comments · May be fixed by #10
Open

Reading some parameters return 'None' rather than the correct value #9

krcook opened this issue Jan 29, 2025 · 2 comments · May be fixed by #10

Comments

@krcook
Copy link

krcook commented Jan 29, 2025 •
edited
Loading

Version 1.4.0 (latest on PyPi)

When I read some parameters via pyebus they return a value on 'None' rather than the correct value. Reading the same parameter via ebusctl works correctly.

For example 'WaterPressure' should return a value in this example of 1.951 (bar)

I've narrowed it down to the decode() function in the IntType class (types.py)

    def decode(self, value):
        """Decode `value`."""
        if value not in ("-", ""):
            if self.divider and self.divider > 0:
                value = float(value)
            else:
                value = int(value)
            if value < self.min_:
                raise ValueError(f"Value {value} deceeds lower limit of {self.min_}")
            if value > self.max_:
                raise ValueError(f"Value {value} exceeds upper limit of {self.max_}")
            return value
        else:
            return None

In this case:
value = '1.951'
self.divider = 1000000
self.min_ = -3.2767e-5
self.max_ = 3.2767e-5

So clearly here the problem is that value is greater than self.max_ and the result is rejected.

I'm not certain how this is supposed to work - but I would speculate that self.min_ and self.max_ should be multiplied by self.divider before the bounds are checked as follows:

            if value < self.min_ * self.divider:
                raise ValueError(f"Value {value} deceeds lower limit of {self.min_ * self.divider}")
            if value > self.max_ * self.divider:
                raise ValueError(f"Value {value} exceeds upper limit of {self.max_ * self.divider}")
            return value

But I don't know if that's how it's supposed to work, or what the side effects of that change might be.
@krcook
Copy link
Author

krcook commented Jan 29, 2025

Further information on the issue having dug a bit deeper. The WaterPressure field is coming back with type 'FLT' and a divider value of 1000. So I'm now thinking that the problem might lie in the IntType with_divider() function.

The existing definition looks like:

    def with_divider(self, divider):
        """Return copy and apply `divider`."""
        divider = _try_int(divider * (self.divider or 1))
        min_ = _try_int(self.min_ / divider)
        max_ = _try_int(self.max_ / divider)
        return IntType(min_, max_, divider=divider)

FLT type has max/min limts of +/ 32.767 and a divider of 1000
This results in the new divider being calculated as 1000 * 1000 = 1000000 and the max/mins are converted from +/- 32.7 to +/- 3.27e-5
I suspect that the new divider is being calculated incorrectly and the line should read:

divider = _try_int(divider / (self.divider or 1))

So that the new divider becomes 1000 / 1000 = 1 and the max/min limits are left unchanged at +/- 32.7

@krcook krcook linked a pull request Jan 30, 2025 that will close this issue
Open
@krcook
Copy link
Author

krcook commented Jan 30, 2025

Pull request created to resolve this issue #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@krcook