alarm: trigger alarm when pressure is out of range #23
Conversation
| elif msg['type'] == "PRES": | ||
| if ((msg['val'] > proto.settings_values['PK'] + proto.settings_values['ADPK']) or | ||
| (msg['val'] < proto.settings_values['PK'] - proto.settings_values['ADPK'])): | ||
| self.request_queue.put({'type': 'alarm', 'priority': 42, 'value': 5}) |
There was a problem hiding this comment.
how is the priority used? Does this make sense given that priority queues are not available for multiprocessing?
There was a problem hiding this comment.
In my opinion the priority can have a sense. But it depends on what is the final design around alarm. We can imagine a design where a alarm code has its own sound or visual and if several alarms are triggered at the same time, the higher priority can be played first, and when it is fixed the second one, etc.
At least it is easy to remove.
For the value, yes it is just for test, ideally we should assign a name to a value and having a list of alarms somewhere (in protocol.py ?). I made the pull request to get a feedback and not really to merge it yet, just to define a bit more what is expected and if the concept is right.
| elif msg['type'] == "PRES": | ||
| if ((msg['val'] > proto.settings_values['PK'] + proto.settings_values['ADPK']) or | ||
| (msg['val'] < proto.settings_values['PK'] - proto.settings_values['ADPK'])): | ||
| self.request_queue.put({'type': 'alarm', 'priority': 42, 'value': 5}) |
There was a problem hiding this comment.
5 seems a strange value if we're still using bit field alarms. Ideally we'd have a list of the definitions available somewhere. Is this a placeholder?
TomBruyneel
left a comment
TomBruyneel
left a comment
There was a problem hiding this comment.
Not complete yet, it's a bit more complicated than this. It's only the peak value that has to be in the threshold. So you need to do a function analysis on the last N points to achieve this. Align with @Merwanski on this problem, he started working on the thread needed to do this here: #22
Issue: #12