https://gitlab.synchro.net/main/sbbs/-/commit/bacc2eb16553c883400b3bf5
Modified Files:
src/sbbs3/mqtt.c
Log Message:
New MQTT topics that the terminal server will subscribe to for node changes

<nelgin> can I push an intr instruction to a node with mqtt?

node/#/set/status - set the node status value (to an integer)
node/#/set/errors - set the node error counter (to an integer, e.g. "0") node/#/set/misc - set the node's miscellaneous attributes/flags value
(hexadecimal values can be set by including "0x" prefix)

The message (payload) doesn't matter for the following topics:
node/#/set/lock - lock a node (no one but sysop can login)
node/#/set/intr - interrupt a node (disconnect a user)
node/#/set/down - down a node (not available for connections)
node/#/set/rerun - rerun a node (reload config upon next connection)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e7b1b02ea4167743a8fa6b22
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Allow a msg value of "0" to clear/unset the node/+/set/# topics/flags

e.g. publishing "0" to node/#/set/intr will clear the node-interrupt flag.
Any non-zero message value will "set" the flag. Same is true for the
lock, down, and rerun topics/flags.

These node attributes (misc) flags could be cleared previously
by setting the 'misc' topic (e.g. to 0), but since that's not an atomic read/modify/write operation, other set misc flags could be lost clearing flags in that manner.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7ae65021a8f4ffe3b47371ad
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Prioritize the node/+/input topics over the node/+/set/+ topics

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/64d5e8d6623ea3c09fe8319f
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Allow triggering timed event or QWKnet call-out by publishing to MQTT topic

- sbbs/BBSID/exec (publish the timed event's internal code)
- sbbs/BBSID/call (publish the QWKnet hub's ID)

The message contents are not case-sensitive.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/42dc70557ff497584096de22
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Add a connect callback handler.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/49e007b73339cd3c6300959c
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Merge branch 'Ree/mqtt-connect-callback' into 'master'

Add a connect callback handler.

See merge request main/sbbs!320

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/622ffe3dceb089de77078f4d
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Remove MQTT message publishing from mqtt_connect_callback()

A follow-up to commit 81d4575e

Although I was not able to successfully reproduce the problem that Ree
reported with his commit (even when changing the SCFG->Networks->MQTT->Publish QOS to 1: At least once) on Windows, I do see how this problem could theoretically happen. And like Ree said in the follow-up comment on the MR "maybe these two lines should have stayed in mqtt_startup", they don't really belong in the connection callback.

The "client" topics only needs to be cleared upon startup or recycle (by publishing a null message) and it would be bad to clear these topics whenever the broker was reconnected (the server's clients didn't magically disconnect). So these "client" topic-clearing publishes are now only done during startup (again).

The "recycle" topics don't really need to be published to here at all. I
think I only did this for cases where someone published a non-null message to the topic and its stale message would remain afterward, appearing in MQTT browsers (like MQTT explorer) long after the server had recycled. The real solution to this cosmetic issue is to only publish null (0-length) messages to the "recycle" topics in the first place.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/789c71cd62692820df80c24d
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Add ability to send a node message via MQTT (to sbbs/+/node/+/msg topic)

The node message should be terminated with a newline character.

e.g.
$ echo "Hey you" | mosquitto_pub -s -t sbbs/VERT/node/1/msg

I'm considering the ability to send user message (telegrams) via MQTT too.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/207ed413b77f6f8025b130d5
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Always publish log messages to both .../logs and .../logs/<level> topics

... regardless of the configured MQTT protocol version (v5 or v3.x).

Also include an MQTT v5 user-property ("time") with the message's origination time/date stamp in ISO-8601 format in all log messages (to both topics).

This will at least double the amount of MQTT log traffic to the broker. When MQTT v5 is used, the additional user-properties will increase it even a little more.

Is this what you were suggesting Ree?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5cb96ad3b35e851222452b86
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Fix log topic publishing when using MQTT v3

Apparently if you call mosquitto_publish_v5() with a non-NULL properties pointer, it'll only publish via protocol v5 and doesn't work if you're using protocol v3 connection.

Thanks Ree.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6abee6374eb0967feb398643
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Fix crash after failing to connect to MQTT broker

We need to call mqtt_shutdown() instead of mqtt_close() to have the mosquitto (loop) thread stopped.

Upon connect failure, call the mqtt_shutdown() *before* calling lprintf->lputs, which would eventually try to MQTT-publish the log message.

The call to mqtt_connect() can block for a while, so raise the log severity
of the "connecting to broker" message from DEBUG to INFO. Otherwise, a bad
MQTT broker address or port would make the servers just appear to hang during initialization, for no reason.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1bc971266525652be3def0a6
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Change the MQTT broker-connect ... successful log message to DEBUG-level

Since we're logging at INFO level when the connect is attempted, we can assume success when we start logging additional init messages.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f8f85f1e4ae337d9fbbc0caa
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Fix CID 493283: Incorrect expression (NO_EFFECT)
Comparing an array to null is not useful: "client->protocol == NULL",
since the test will always evaluate as true.

or will always evaluate as *false* (the array won't ever be NULL). <shrug>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6d01d683c9a87a909bfae902
Modified Files:
src/sbbs3/mqtt.c
Log Message:
Clear (set to 0) each server's "highwater" topic upon startup

The other server stats (e.g. error_count, served) are zeroed upon startup, so the highwater mark should be zeroed too.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net