open https://gitlab.synchro.net/main/sbbs/-/issues/625

When the web monitor loads up, the last event of each level for each service gets displayed on the various panels. For the most part that's not a big deal, but a few days ago I had a critical error occur, so seeing that every time I load the monitor is a little off-putting, especially since it's shown with the time the message was received (ie right now) instead of the time the error occurred the other day.I'm wondering if it makes sense to either:- Don't publish to the log topics with the persist flag, so then when web monitor loads up it'll have a clean slate (like when you load sbbsctrl in NT service mode, and all the panels start blank)- Include a timestamp when publishing to the log topics, so then web monitor can display the correct time for the old eventsIf you don't think either option makes sense, or would cause problems for how people are already using mqtt, then I can always make a change on the subscriber side instead of needing one of the above changes on the publisher side (ie ignore the first second's worth of log messages, or don't output a timestamp for the first second's worth of log messages)Tagging @nelgin too since he's the mqtt guy.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/625#note_3937

The only issue I could see here is if you rely on the logs being persistent so you don't actually start with a clean slate when restarting something like a dashboard. I'm not sure I have an opinion either way, to be honest.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/625#note_3942

I'm not opposed to changing how the MQTT log topics work, but I do find it potentially helpful to be able to easily discover using an MQTT browser "What was the last critical error logged?" (as an example). Adding a timestamp (like many other messages have) wouldn't be difficult at all so then you could also easily discover "When was the last critical error logged?"As for the other cosmetic issue, have you considered using the "../log" topic (instead of "../log/+")? If you're using the log severity level (e.g. for colorization) then you can get that from each log message published to that topic via the MQTT v5 "level" property that accompanies each message published. That does require (I'm pretty sure) that Synchronet be configured to use MQTT protocol v5 instead of v3.1.1 (the default). If that's the case, we could maybe change the default MQTT protocol version to v5 too.When using MQTTv5, it's possible that we could include the publish timestamp as a user property (instead of as part of the message text), possibly making it easier for an application to separate the timestamp from the message text more easily and represent the message time if/how it wanted (or not). Perhaps that's a topic better suited for another discussion.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/625#note_3945

Thanks for the heads up on the v5 log behaviour, I didn't realize it was different than v3. Just pushed a change to handle both scenarios.So for what I was originally asking, v5 is perfect. When the web portal starts up only one message per server comes in, not one per level per server, so it's close enough to a clean slate for me.But that means only v3 can answer "what was the last critical error logged", v5 can only answer "what was the last message logged" which is pretty unlikely to be a critical/error (at least I would hope it's unlikely!)So yeah, another discussion on what purposes the log messages are expected to serve, if/how they should be timestamped, what version should be default, etc, would make sense. But I'll close this one since "switch to v5" is the answer I needed. Thanks!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)