Oolite Bulletins

hiran wrote: ↑Sat Jun 15, 2024 9:26 pm

hiran wrote: ↑Sat Jun 15, 2024 9:16 pm

MrFlibble wrote: ↑Sat Jun 15, 2024 8:18 pm

What if starter were able to subscribe to a topic, and send anything published there back to Oolite, with filtered responses published. That would allow a kludgy debug console, and also facilitate instruments sending commands to oolite (pause on red alert if bridge empty).

An excellent idea to reuse the existing tech stack. So the Oolite Debug Console could preserve it's use to alternatively show/produce MQTT messages while at the same time more and more instruments could be developed and attached. Which would again encourage others to take that route.
That's a win-win situation.

Thinking about this:

OoliteStarter should then forward all messages from Oolite. If it is not meant for a special topic (e.g. oolite/comms) it should go to a default topic like oolite/debugConsole. This way an MQTT oriented debug console could still decide which messages to react on.

At the same time I will introduce a topic like oolite/input. Messages here will be forwarded to Oolite on the debug console interface - which means they need to contain some JavaScript command. And again this would allow Oolite to react.

I was experimenting in that respect and created this code:
https://github.com/OoliteProject/Oolite ... r.java#L78
But that one is too ship speed oriented. We will need something more generic.

MrFlibble wrote: ↑Sat Jun 15, 2024 9:56 pm

One for the back burner: Could the toplevel topic be configurable in some way, perhaps with an mqtt prefix field per installation in starters 'Oolite versions'? Multiple Oolites could share one MQTT server nicely.

My thinking goes something like this:
Arnold and I have installations sharing an MQTT server. I have two versions of Oolite running from starter, he has one. He sets Arnold/oolite as the prefix in his one, and I set flibble/oolite/dev and flibble/oolite/fun as my two. I'd only have to tweak the prefix on any client devices to switch versions, and all will remain sane. If Arnold decides to set up another one, with a different set of "remote instrumentation" he could use Arnold/otheroolite. Any prefix could be used, potentially allowing even online MQTT servers to be involved (I know.. glaring security hole!, ssl required).

A dev might be able to directly debug a user's Oolite on the other side of the planet by asking them to connect to an MQTT server with starter!

hiran wrote: ↑Sat Jun 15, 2024 10:27 pm

MrFlibble wrote: ↑Sat Jun 15, 2024 9:56 pm

One for the back burner: Could the toplevel topic be configurable in some way, perhaps with an mqtt prefix field per installation in starters 'Oolite versions'? Multiple Oolites could share one MQTT server nicely.

Do we need separate topics for all the Oolites on this world, or would be a filtering on the publisher be sufficient? Probably depends if you can subscribe to specific publishers only. Will have to dig into MQTT features.

MrFlibble wrote: ↑Sun Jun 16, 2024 2:46 am

Apologies. The android app I'd not used for a long time was in fact net.routix.mqttdash. The json stuff I'm struggling to fathom in that, but hope someone else will clarify hereabouts. Works without google play services (installed using e.g. aurora store).

The one I'd posted earlier is not working, at least with authentication, for me.

hiran wrote: ↑Sun Jun 16, 2024 6:33 am

hiran wrote: ↑Sat Jun 15, 2024 10:27 pm

MrFlibble wrote: ↑Sat Jun 15, 2024 9:56 pm

One for the back burner: Could the toplevel topic be configurable in some way, perhaps with an mqtt prefix field per installation in starters 'Oolite versions'? Multiple Oolites could share one MQTT server nicely.

Do we need separate topics for all the Oolites on this world, or would be a filtering on the publisher be sufficient? Probably depends if you can subscribe to specific publishers only. Will have to dig into MQTT features.

I checked some MQTT documentation and could not find anything related to filtering messages within a topic. The most concise answer I found is on StackOverflow.
That means we have to setup the topic structure wisely.

T="student/fred/oolite/debugtest"
mosquitto_sub -t "$T/controls/#" -h <hostname> -u <user> -P <password>

MrFlibble wrote: ↑Sun Jun 16, 2024 11:45 pm

hiran wrote: ↑Sun Jun 16, 2024 6:33 am

hiran wrote: ↑Sat Jun 15, 2024 10:27 pm

Do we need separate topics for all the Oolites on this world, or would be a filtering on the publisher be sufficient? Probably depends if you can subscribe to specific publishers only. Will have to dig into MQTT features.

I checked some MQTT documentation and could not find anything related to filtering messages within a topic. The most concise answer I found is on StackOverflow.
That means we have to setup the topic structure wisely.

Feels like the wrong end of a stick is being grasped somewhere here.

MrFlibble wrote: ↑Sun Jun 16, 2024 11:45 pm

P.S. input's working nicely for me. Thanks!!

hiran wrote: ↑Mon Jun 17, 2024 9:54 am

...
Or I stop thinking and follow your example not limiting anything.

user flibble
topic readwrite oolite/#
topic readwrite kabOodle/#
topic readwrite student/fred/#

user tablet
topic read oolite/#
topic read kabOodle/#
topic read student/fred/#

mosquitto_sub -h localhost -p 1883 -u tablet -P "$tabpass" \
  -t 'student/fred/deeppath/oolitetest/input' -v

mosquitto_pub -h localhost -p 1883 -u flibble -P "$flibpass" \
  -t 'student/fred/deeppath/oolitetest/input' -m '{"command": "player.ship.fuel=7"}'

student/fred/deeppath/oolitetest/input {"command": "player.ship.fuel=7"}

MrFlibble wrote: ↑Mon Jun 17, 2024 11:59 am

The way I see it, the 'parent' topic (currently oolite/) could be 1/2/3/4/flibblydoodah/ for all it matters, as long as all parties involved (oolite, dashboard) use the same. Limiting the 'root' to anything would make it difficult to use exisiting MQTT servers where access to topics can be restricted.

[...]

So if T is topic, T=oolite, T=student/fred/deeppath/oolitetest or T=1/2/3/4/5 makes no odds as long as sub and pub use the same.

If there's a field per installation in "Oolite Installations" of starter for MQTT topic, set as oolite by default for ALL installations, nobody need care unless they want to customise the topic to suit their desires/needs. They can use the same or different per installed Oolite as they please.

If you wanted to group stuff a bit and ensure a topic 'wrapper' for all this, maybe make the topic ${T}[/]oolite, where the user can prepend a topic (any depth) if they need/want, and if they don't, it's simply 'oolite' (top level). This might need string 'preening' to ensure there's a slash between the optional bit and the trailing 'oolite'. IMO this would cover both default and custom, with the least amount of help-bait. All client tools will need the same mechanism, but it's fairly standard on MQTT stuff to be able to tweak the topic 'root'.

Cholmondely wrote: ↑Wed Jun 19, 2024 5:26 am

Any chance of some sort of a picture showing what either of you have managed so far?

#!/bin/bash

broker=localhost

#Read speed published by Oolite, stream as integer into a different topic.

port=1883
user=inuser
pass='inpass'
intopic='oolite/#'

outbroker=$broker
outport=$port
outuser=$user
outpass=$pass
outtopic='kabOodle'

mosquitto_sub -h $broker -p $port -u $user -P "$pass" -t "$intopic" -v |\
sed -u '
  s@^oolite/controls {"msgType":"controls","speed":\([0-9]*\).*$@speed=\1@
' | while read; do
 [ "x${REPLY%=*}" = "xspeed" ] && echo ${REPLY#speed=}
 echo "$REPLY" >&2
done |\
  mosquitto_pub -h $outbroker -p $outport -u $outuser -P "$outpass" |\
 -t "${outtopic}/controls/speed" -l

hiran wrote: ↑Mon Jun 17, 2024 8:47 pm

Ok, you gave me good answers here. I will follow your suggestion, and I also change the MQTT configuration from one global to one per installation.
The next build should make that available.

Cholmondely wrote: ↑Wed Jun 19, 2024 5:26 am

Any chance of some sort of a picture showing what either of you have managed so far?