temperatures.py

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
- Removed HW flag from broadcast as FW doesn't change broadcast content based on HW flag

  1. … 6 more files in changeset.
Merge branch 'LDT-3214-override-refactor' into staging

  1. … 46 more files in changeset.
Merge branch 'LDT-2980' into staging

Merge branch 'LDT-611-fp-add-ability-to-override-tempe' into staging

  1. … 4 more files in changeset.
Updated

Updated

Updated override range for flow sensors

I didn't added any code for override. I also can't stop anyone to send in an override command with random numbers. The allowing of override should be on the FW part, where sending the override with...

I didn't added any code for override.
I also can't stop anyone to send in an override command with random numbers.
The allowing of override should be on the FW part, where sending the override with (sensor_id, value, no reset) should return false for those that are not accepted.

We should not allow overrides for newly added internal temperatures

We should not allow overrides for newly added internal temperatures

LDT-2980 - Added internal temperature for flow sensors

  1. … 1 more file in changeset.
LDT-2980 - Added Internal temperature for flow sensors

  1. … 1 more file in changeset.
I added the unique decorator back, except for the few that have aliases

I added the unique decorator back, except for the few that have aliases

Renamed, also flagged for future type change.

Renamed, also flagged for future type change.

- Renamed variable

  1. … 9 more files in changeset.
LEAHI-DIALIN-LDT-2980_Request: add ability to get the flowmeter measured internal temperature
LEAHI-DIALIN-LDT-2980_Request: add ability to get the flowmeter measured internal temperature
"No one should interact with it or be aware of it's existence, so the name shouldn't matter." *it matters to those who read the code in inconsistent intervals ( like those who participate in code...

"No one should interact with it or be aware of it's existence, so the name shouldn't matter."

  • it matters to those who read the code in inconsistent intervals ( like those who participate in code review or teaching ).


"As we only have 2 version in test at the same time."

  • Currently. By summer, i'd expect dialin to be considering 1.0's, 1.9s, and 2.0s/DVTs.


We have the choice to handle the redesign effort then or now.


Edit:
Follow up comment.

Looking at the other files. Users of dialin will not be aware of existence, but developers of dialin will as it impacts the behavior of overrides like temp & pressure.

yes. that's the design consideration. Are we okay with our unit tests no longer checking for duplicate values? ( they will currently pass as i remember they expect an exception due to the unique ke...

yes. that's the design consideration. Are we okay with our unit tests no longer checking for duplicate values? ( they will currently pass as i remember they expect an exception due to the unique keyword to fail. These will not trigger an exception ).

I am not sure I can assign unique to the dynamic enums. Also with unique you can't add aliases and some(for example: temperature) overrides use the aliases to determine which msg id to call and how...

I am not sure I can assign unique to the dynamic enums. Also with unique you can't add aliases and some(for example: temperature) overrides use the aliases to determine which msg id to call and how much to shift value for it.
Making an alias is more dynamic and not needing separate variables to be maintained for this.