Closed bardram closed 5 months ago
The full protocols are included below.
Actually - taking a closer look, it seems to not only be a problem with OneTimeTriggers. In the original protocol there are 22 unique triggers whereas in the downloaded study deployment, there are only 16. So - 6 triggers have "disappeared" (i.e., one other than the 5 OneTimeTriggers).
I don't immediately know what could explain this, but some observations:
- Identical triggers don't make sense in CARP core. Simply let the same trigger launch multiple tasks (assuming this is why you have multiple).
Hm... I do need 6 triggers to trigger 6 tasks. But if this is how CARP Core works, I can adjust the trigger execution runtime on CAMS to adhere to this.
- a device deployment only receives that part of the protocol it needs to execute. Maybe it gets filtered out in that transformation. Is the trigger configured to start a task?
Yes - I do get it down to the client.
I've addressed this behavior in CAMS v. 1.6.1.
I have a study protocol (the Demo protocol) which has a set of
OneTimeTriggers
like this:But when I download the study deployment from CAWS, these 6 OneTimeTriggers are reduced to only one (1)....:
This causes problems on the client-side, since when there is only one OneTimeTrigger, this will trigger only once and the other 5 will NOT trigger.
I don't know if this is a CAWS or CARP Core problem – @Whathecode; please chip in if you know this.