Hi Dojo,
Where a parameter is already defined in a protocol, but not used, under which conditions it is possible to enable that param for alarm/trend templates in a newer version of the protocol?
Are there any restrictions that would rather lead towards the creation of a new parameter in place of the original one?
Thanks
I’m not a hardcore developer (not even softcore 🙄) but you can just add the proper XML tag to the parameter in the driver to flag it to become available for monitoring and/or trending. Risks? Only I guess if this is a protocol driver delivered by Skyline, and you change it, and our source is not changed and you get a new version from us in the future that would revert your change.
This is the tag needed to enable alarming (where you can also specify the default thresholds that appear in the default alarm template called No Monitoring.
Thanks Ben, much appreciated ~ effectively sharing the knowledge is not second to owning it 😉
—
I understand from the squad we’ve hit a very specific case, where also the “Interprete” section will need an update. Wondering if there are any things we can check during the protocol acceptance over key parameters to ensure the change can be as easy as described above – will add a PS to gather some general recommendations (if any).
PS: After checking with Skyline’s squad, I understand we’ve hit a very specific case, where also the section will need an update – and therefore a new parameter id is recommended to avoid potential conflicts in the DB.
Wondering if there are any recommended checks to perform over key parameters (perhaps during protocol acceptance) to ensure the change to enable alarms or trending can be as easy as described in Ben’s feedback below.