Trigger "t" (and others) cause Unknown message type on Android

[parkerrsv]

I have just setup owntracks on an AWS VPS through lightsail.
All correct ports are allowed and everything appears to work on the frontend website (positions updated).

Unfortunately on the Android app, the published location of another user(friend) does not show up correctly.
The logs show the following:
I MessageProcessor: Received incoming message: MessageUnknown on owntracks/tim/iphone
W MessageProcessor: Unknown message type received

I assume everything is set up correctly on the VPS side, as it will occasionally work with manual messages. I've seen the friends location pop up if its manually shared on my android.

I am using all the default settings in the OTRC, generated by the frontend website.

[jpmens]

Can you elaborate on "will occasionally work with manual messages" ? Does it work or does it not?

Also, what app (OS, version) is your friend using? What do their logs show?

[jpmens]

and are you both using MQTT?

[parkerrsv]

Thanks for the quick reply.

Can you elaborate on "will occasionally work with manual messages" ? Does it work or does it not?
It works intermittently.

I am using version 2.5, they are using the latest from the apple store (will check exact version tonight).

Both are using MQTT.

I am wondering if there is any additional setup I may be missing, such as TLS certs. At the moment I have TLS on with no cert and that seems to work for Android. Please let me know any more information you need.

[jpmens]

Quicksetup configured TLS for you with Let's Encrypt, unless you disabled that by not specifying an email address in configuration.yml. (Let us know if you disabled TLS.)

Are you seeing the iOS device also work "intermittently"?

@growse can you say what these log entries mean?

I MessageProcessor: Received incoming message: MessageUnknown on owntracks/tim/iphone
W MessageProcessor: Unknown message type received

[parkerrsv]

I added a mail address into the configuration.yaml for letsEncrypt. I have not turned off TLS.

[parkerrsv]

The IOS device also works intermittently, although I have not had the chance to check the logs and exact version today.

[growse]

@growse can you say what these log entries mean?

I MessageProcessor: Received incoming message: MessageUnknown on owntracks/tim/iphone
W MessageProcessor: Unknown message type received

It means the app received the message, but couldn't parse it.

[jpmens]

Intermttently is worrysome and should not be happening. Please check the following:

Tail the Mosquitto logs (tail -f /var/log/mosquitto/mosquitto.log) on the server, and each time you hit "publish location now" you should see a few lines of log appear on the console.

If that isn't the case, it tastes a bit as though there are connectivity problems between the network location of your device(s) and the MQTT broker.

[parkerrsv]

I've checked the messages with mosquito _sub and they appear fine. Albeit different messages coming from the apple and Android devices.
I suspect it's something on the app side that can't parse the message.

The logs show a clean message been published from both devices.
The frontend shows both devices working and publishing when required.

[parkerrsv]

Complete line is the following:
@17:30:50.141 I MessageProcessor: Received incoming message: MessageUnknown on owntracks/tim/iphone with id=0

[jpmens]

You know what comes next, right? ;-)

We're going to need a "broken" message, i.e. one which Android says it cannot parse, but which you see as ok with mosquitto_sub, and we're going to need this message unaltered, please. Send it to support@owntracks.org (specify this issue please), and we'll look at it.

[parkerrsv]

Will do!

[parkerrsv]

Emailed the exact output.

I've noticed it works when the 'created_at' and 't' parts are not included.

[jpmens]

Thank you for the data!

I can reproduce the error, and I'm a) marking this as a bug and b) moving the issue to our Android issue tracker.

The problem arises when in the t element of the JSON payload a t exists. If I replace that by p, say, then the message is accepted.

"t" : "t"

t is a trigger which indicates how a location was reported. Its value may contain t in which case it's an iOS timer-based publish in move mode, and our Android app rejects these messages.

What surprises me very greatly is that nobody's noticed this yet, so congratulations on that! :-)

[parkerrsv]

Thank you for the data!

I can reproduce the error, and I'm a) marking this as a bug and b) moving the issue to our Android issue tracker.

The problem arises when in the t element of the JSON payload a t exists. If I replace that by p, say, then the message is accepted.

t is a trigger which indicates how a location was reported. Its value may contain t in which case it's an iOS timer-based publish in move mode, and our Android app rejects these messages.

What surprises me very greatly is that nobody's noticed this yet, so congratulations on that! :-)

Great! Good to know I'm not going insane :P

[ckrey]

Thank you for the data!
I can reproduce the error, and I'm a) marking this as a bug and b) moving the issue to our Android issue tracker.
The problem arises when in the t element of the JSON payload a t exists. If I replace that by p, say, then the message is accepted.
t is a trigger which indicates how a location was reported. Its value may contain t in which case it's an iOS timer-based publish in move mode, and our Android app rejects these messages.
What surprises me very greatly is that nobody's noticed this yet, so congratulations on that! :-)

Great! Good to know I'm not going insane :P

I can reproduce same behaviour here.

[parkerrsv]

Is there any work around to this that I could implement? Right now the app does not work at all with this bug.
Would it be possible to change the message on the broker side?

[jpmens]

The app should be processing other triggers without a problem. If you wanted to work around this you could create a subscriber to your broker which replaced the trigger and re-published as, say, a different "friend". Not quite for the faint of heart, so if you have a bit of patience you could wait for an official fix. :)

[growse]

Will be fixed in 2.5.1. Thanks for the bug!

[parkerrsv]

Thanks for this. Unfortunetly the 't' trigger seems to be for both 'move' and 'significant', I am rarely seeing positional updates for the people on my server, is there a way around this until the fix is released?

[jpmens]

@parkerrsv version 2.5.1 is now hitting the play stores, and we've confirmed the bug is resolved.

[parkerrsv]

@parkerrsv version 2.5.1 is now hitting the play stores, and we've confirmed the bug is resolved.

Thanks for this jpmens!
I can't see the update in the store yet, any eta on that? Assume it's out of your control

[growse]

It's a staged rollout. We found some issues so halted, 2.5.2 shortly.

[killah78]

I see it's already closed, but not rolled out yet. So a question related to this: I got the "MessageUnknown" also for trigger "v" and "C". This will be solved as well? These are sent from an iphone.

[jpmens]

Are you sure that'a a capital C ?

[killah78]

Yes, it is a capital C
like: {"_type":"location","acc":35,"alt":0,"batt":25,"bs":1,"conn":"m","lat":xx.xxxxxx,"lon":yy.yyyyyy,"m":1,"p":101.182,"t":"C","tid":"MS","tst":1725346660,"vac":3}

[ckrey]

Yes there is a capital C trigger value in iOS. It indicates the location update was triggered by entering/leaving the special +follow region. Documentation in booklet updated

[ckrey]

I think the apps should allow any t (trigger) values as long as they don't evaluate them in a special way.

[killah78]

So will you reopen this topic, or will take care of it in another way?