MQTT thing with varying topics

  • Platform information:
    • Hardware: RPi 4 4gb
    • OS: OpenHabian image Debian buster
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version: 3.4.0
  • Issue of the topic: No Issue Starting configuration

I am working on getting APRS working with OpenHAB. A project called mqtt-aprs has taken care of most of the heavy lifting of getting APRS Queries onto my MQTT server. The way this works the software connects to the APRS servers and uses some filters to weed out all but the call signs I am looking for. When a message matches the filters it is forwarded to the MQTT server under the call sign of the person who sent it.

In MQTT this looks like:

RF/
aprs/
Callsign1-SSID/
raw = Callsign1-SSID>Routing Info,message type,Callsign1::Callsign2 : This is a test

There are some more elements under the Callsign1 Topic. Callsign1 is the FROM callsign and Callsign2 is the TO callsign.

Because the from callsign can vary greatly even with the same user because of the SSID. I would like to display new messages on my system. Any suggestions on creating an MQTT thing that would be able to display the information from multiple topics whose name may not be known at the time of creation?

So are you saying that messages are published to the MQTT topic

RF/aprs/xxxxxx-yyyyyy/raw

where xxxxxx-yyyyyy contains the from-user’s callsign (xxxxxx) and that user’s WIFI (?) SSID (yyyyyy), both of which will vary infinitely as far as your setup is concerned?

Can you just subscribe to one topic?

RF/aprs/+/raw

or 

RF/aprs/Callsign1+/raw
This will allow you to have different items trigger different things when different people connect to your system.

Like person 1 3 4232 3445 can open gate 

What do you want to do with the message?

Email, Push, Telegram or have google read it out to you

Close Where XXXXXX is their callsign where YY is a 2 digit SSID or an appendix to the callsign to designate what station they are using. But yeah XXXXXX-YY will vary infinitely The only other thing I can think of is to rewrite the mqtt-aprs bridge, I don’t think it would be too difficult but would prefer to avoid it.

That’s the bit I am trying to sort out. subscribing to just one topic is not possible with the schema that I currently have. The messages will likely be displayed on the dashboard. If someone sends APRS messages to me it is never an emergency and if it Is, keeping them in a place that is visible to all is useful.

It might be.

As @denominator has mentioned, MQTT itself allows the use of wildcards. See the below webpage for more info. I’ve never tried it with the MQTT Binding in openHAB though…

Thank you for restating this, the link now makes it all make sense. I will give this a go!

So Yes, this worked. Also for future reference this is the mqtt-aprs program I am using on my system. GitHub - JohnCanty/mqtt-aprs: Connects to the specified APRS-IS server, and posts the APRS output to MQTT. Can parse parameters, or dump the raw JSON from aprslib. It's currently for receive only from APRS-IS and sending to an MQTT server.

If you can, please post your final working configuration for future users!

RF/aprs/+/raw

This is the topic I called. Within the topic the raw contains everything. Some messages are encoded into other formats so using the

RF/aprs/+/message

gets you the message. If you want the call sign, you need to create a new channel in your APRS thing, get the +/raw string, then pass it through REGEX I am figuring that portion out now.

Post your raw data and what you want to do with it.

Can you just dump the raw JSON from aprslib and post example here.

Using JSON is probably easier then REGEX

got it sorted. My pitfall was not installing the REGEX addon.

REGEX:([A-Z0-9]*).*

Thank you for the help!

Its a great feeling when you get "Hello World" working.

If you need help with automations us know. Like when openHAB has detected no one is home at night and the lighs are on send APRS message. This will ask if I want the lights turned off and have openHAB respond to the answer.