matthijskooijman
commented
2 years ago I've given this a bit more thought, and here's my idea of how to classify messages.
Each message is assigned:
- A type, which is primary or secondary
- Whether the message can have secondaries
- A priority (low/medium/high)
The first two determine how to group messages (secondaries with the preceding primary, as long as the timestamp is the same or one second above the previous message and the preceding primary allows secondaries. If either of those is not fulfilled, the secondary is upgraded to a primary). The priority determines how things are displayed/notified. I can imagine "high" has distinguishing markup and includes an @room highlight, while "low" becomes a notice. One thing that is important, is that a low-priority primary is distinguishable from a secondary (i.e. it should be clear where the list of secondaries ends and a new low priority primary starts, even if both use notices, but this is not an issue if we implement editing messages for secondaries).
The latter two are normally useful for primaries only (secondaries can have no further secondaries and follow the priority of their primary), but are also specified for secondaries in case a secondary is received without a preceding primary, in which case the message is "upgraded" to a primary automatically as suggested above.
For the lines in each message I'm using timestamp / status / subject / name in that order.
status == "Alarm"-> High priority primary with secondariesstatus == "Hoofdalarm"-> High priority secondary with secondaries (this one is just to make sure that "Hoofdalarm" becomes high prio, even when not preceded by a regular alarm)status == "Storing"-> High priority primary with secondariesstatus == "Geactiveerd"-> Normal priority secondary without secondaries (without secondaries because I think this is never the cause of something, but I'm not entirely sure)status == "In rust"-> Normal priority secondary with secondaries (this will often be triggered as a secondary, but might also be upgraded to a primary when triggered first)status == "BMC Reset"-> Normal priority primary with secondariesstatus == "Aan" || status == "Uit"-> Normal priority secondary with secondaries (Also expected to occur as primary or secondary, for example when disabling all sounders or all doormeldingen, etc.)status == "Informatie" && subject matches "Ring .. protocol error 0000"-> Low priority primary without secondariesstatus == "Informatie" && subject matches "Ring .. protocol error ...."-> Normal priority primary without secondariesstatus == "Informatie" && subject matches "Tijdprogramma.*"-> Low priority primary with secondariesstatus == "Informatie"-> Normal priority primary without secondaries- All others -> Normal priority primary without secondaries
I think with these rules there is a small chance of misclassifying something (in particuler "In rust") as secondary when it would be primary, but only when two of them occur at pretty much the same moment in time, which seems unlikely enough to be acceptable.
wie-niet
I was thinking a bit on the flood of messages that is currently generated, and I think it would be good if we could add some analysis of primary messages (the causes of things) and secondary messages (effects from a primary message). For example, when some smoke detector becomes faulty, this generates one "Storing" message, which would be the primary message, and a number of "Geactiveerd" messages for outputs (door magnets, fault reporting), which would be the secondaries.
It would be good if we could reflect this in the messages sent, to make it easier to quickly see the primaries, without them being drowned in the secondaries. Ideally, you would use something like
<summary>and<details>to show only the primary initially and allow expanding the message to also show the secondaries, but I'm not sure if Element supports this bit of HTML (it seems there is no matrix-level spec for supported HTML yet...). An alternative would be to add some styling so primary messages are bigger/more colorful/with a border/etc. and secondaries are more muted, so it is easy to quickly scan for primaries.As for deciding what is primary and what is secondary, here's some thoughts:
Examples of a primary followed by secondaries.
Alarm
Reset detector after alarm
This is when the hand detector is reset, or the smoke has cleared from around the smoke detector. It is a primary without any secondaries, since the main alarm is not automatically cleared (that needs a reset).
Recover from alarm
This is a bit special, since the actual primary is "BMC Reset", but somehow the "In rust: Bewaakte uitg" are logged before it. For simplicity, I guess it would be ok to just make that message its own primary then, rather than figure out how this reordering works?
There is also the "Gebruikers code", which was entered to allow the reset to complete (but can also occur by itself). I guess it (and probably all other "Informatie" messages) can be considered primary, but not allow any secondaries (so any secondaries after them would become primary, just like after a timeout).
Programming the BMC
When sending info from the PC, it also re-reads what is sent afterwards, so this then generates two entries, with the second one being secondary. However, when just reading from the PC, the second one will be primary, so the status of the second one would depend on whether the first one is present. In practice, it is probably fine to just make both of these primary to keep things simple.
Toggling fault sending
This is turning the fault sending on, it looks similar for turning it off.
Periodic protocol error logging
These are both primary, but should probably be low urgency/notices or so (though maybe higher urgency when the error count is non-zero?).
Daily doormagnet test
These are two primaries really: Activating and deactivating a timer program daily to detach all door magnets. This entire sequence should really be low-urgency. It is slightly tricky that these are "Informatie", so the earlier idea to make all "Informatie" primary but without allowing secondaries doesn't work, so we do have to also look at the second line (match "Inforatie // Tijdprogramma" probably and then make that a primary with secondaries).
Single detector fault
Recovery is similar, but with "In rust" instead of "Storing" or "Geactiveerd". It is slightly annoying that both of these use "In rust", since then it becomes harder to classify "In rust" as primary (when it clears a fault condition) or secondary (when it clears e.g. a door magnet output). Maybe some tracking of state could help here, or maybe just some simple heurstics, or a prefix in the output name or something like that..
Conclusions
From the above, we should probably draft some heuristics about what to classify as primary or secondary and see if we can find a simple ruleset for this (though as noted in the last section, distinguishing "In rust" might be tricky). No more time now, though :-)