HTTP message does not always include topic

[balloob]

Release notes for 9.5.7 states:

• [NEW] topic in HTTP json payload

With Home Assistant we're relying on this value and somehow we noticed that this topic is not always available. For some people it is, for some people not. Some people think it's related to setting tracker ID but we're still investigating.

I tried to look in the code but my objective-c is not good enough to figure it out where the dictionary is being created.

[balloob]

So topic in HTTP json payload was introduced in commits:

• [NEW] topic in HTTP json payload
• [FIX] correct user in HTTP "topic"

One thing I was thinking it might be, and this is just a hunch, that there are messages queued for delivery before the HTTP endpoint is configured, and that pressing the report button sends the old messages that do not contain the topic key.

[ckrey]

If the queued messages are not acknowledged by HTTP 200, then they will not be deleted from the fifo queue. To clear the queue re-install the app or change your connection settings back and forth

[balloob]

So am I interpreting it correctly that some old messages without topic might end up in the queue before a user configures the HTTP endpoint?

I did change it now to discard them by returning 200 but I wonder if we should ever deliver messages without topic to the HTTP endpoint.

[ckrey]

I don't know what caused the backend to return a non-200 response.
Do you have a log of the messages that caused the problem?

The only example I see is the case when you decide to encrypt the data by the owntracks application:
{'_type': 'encrypted', 'data': '<redacted>'} which is the desired output.

[balloob]

Well the Home Assistant server returned a 400 because it was expecting a topic in the message. This has been fixed now and we return a 200 to discard it (source).

Interesting note about the encryption. I did not think about that. With Android we always get the user and device as headers (if they are configured). I guess we might not handle encrypted iOS payloads correctly, going to test that and will report back.

[jpmens]

@balloob please be aware that our Android app also has optional encryption just like on iOS.

[binarybucks]

In Android you can also just pass the username and device as URL parameters ;)
They're just send as headers if you explicitly specify them in interface.

[balloob]

Alright, did some testing:

• Android, no encryption: request includes X-Limit-U and X-Limit-D headers to recreate topic
• Android, encryption: request includes X-Limit-U and X-Limit-D headers to recreate topic

Still working on getting someone to test the iOS payloads to see if it's the encrypted message that breaks it.

[balloob]

• iOS, no encryption: contains topic
• iOS, encryption: does not contain topic. Decrypted payload does.

Okay, case solved, thanks all !

[jpmens]

@balloob if you feel very brave, would you like to provide a small PR for our Booklet?

https://github.com/owntracks/booklet/tree/master/docs

[balloob]

Sure! owntracks/booklet#37

[jpmens]

Thank you very much!

[jpmens]

We've just discussed this, and we will implement the headers in iOS as well. Reopening.

[ckrey]

Implementation tracked in #560