When comment is above, use /// instead of ///<. And add blank lines before/after - doxygen seems to get confused about where to apply the comment without clear separation.
Teensy will want to parse the commands as a string when it has >1 parameters in the command. Not every command has a parameter with it. it is copied over to condWriteCmdBuffer once we get the length from snprint()
Both of you are correct, the generic override can be used.
Since we pack the payload outside of the generic override, for this situation we don't pack the reset byte and therefore will stay as a U32 which satisfies the FW constraint. The other concern I had was that the FW would not reply back with a test ACK back to dialin with this cmd, thus causing a timeout in the generic override function. This is address as all messages in the lookup table in FW will reply back with a test ACK.
Therefore im okay using the generic override method
teensy wants to parse commands with a , when it has parameters. Lots of string searching with length(), startsWith(), readStringUntil(), and indexOf(). We needed to keep it a char array sowe dont have to refactor the command handler in teensy.
Removed the ifdef here as these overrides still be used without breaking the teensy driver. I can add it on request. Unsure if teensy will be tested long enough for them to use those overrides.
In the meantime,
MSG_ID_DD_FILTERED_COND_SENSOR_READINGS_OVERRIDE_REQUEST and MSG_ID_FP_FILTERED_COND_SENSOR_READINGS_OVERRIDE_REQUEST are still available to override the monitor/filtered data.
we need filtered values for various applications in the system. My question is should we be checking dialysate temperature using a filtered value or a sample point? This version showed that we want a sample point.
in Denali, looks like the HD got the filtered temperature value from the DG for checking dialysate temp alarms. Are we upholding that same design of using a filtered value for leahi dialysate temp?
