TxLog property should be TRUE. NoDRcr property is FALSE in arterial/venous alarms - is there a reason why TMP is different? Priority should be HIGH. Rank should be somewhere around 200 (see if PRS specifies or ask Eliza what it should be).
Enum content of Beta 1.0 and Beta 1.9 is different. The new sensors messing up the order for the old HW's override and broadcast data allocation. Making it dynamic makes it that when the beta test config is called the enums are switching content to reflect that.
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 ).
"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.
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.
No one should interact with it or be aware of it's existence, so the name shouldn't matter.
As we only have 2 version in test at the same time, I am making an internal variable name that I don't need to rename every 3 months or so. Needing to make a review smaller with editing less thing makes it faster to be completed...
In case a situation arrives when we will test more version at the same time Alpha, Beta, Beta 1.9, it will require a redesign on the part of enum generation too.
I got error for 3 variations, So I kept 4 variations and error was Detail IndexError: tuple index out of range /home/denali/Public/leaDevTest/leahi-testsuites/suite_leahi/tst_general_alarm_requirements_instruction/test.py:267
The naming of this method is misleading as it sends the message to request defeatured status and it is retrieved in a separate callback. The 'get' implies that the value returned from this method is the defeatured status. The value returned is not the defeatured status but rather a T/F condition on if the FW replied back to dialin successfully.
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.
Can you capture intent to resolve my comment in a TODO so we don't lose track of it? (General recommendation for all comments that we are postponing resolution for).
