ostrya / PresencePublisher

An Android MQTT client that regularly publishes messages to notify about the device's presence
MIT License
79 stars 12 forks source link

Enhanced message format #30

Closed kroseneg closed 2 years ago

kroseneg commented 3 years ago

Hi

It would be great if PresencePublisher could publish the timestamp when the presence state was published, and when it intends to republish the state. This makes it possible to check if the retained message on the MQTT server is current, or if it should be considered as outdated and obsolete.

Thank you! :)

Korbi

ostrya commented 3 years ago

Do you mean the timestamps should be published as part of the existing messages, or should they be sent as one or two separate messages, similar to the battery level message?

kroseneg commented 3 years ago

Personally I'm fine with both, as long I can parse it. I'm not 100% sure what would be better. Seperate messages won't affect existing setups, and using them would be easy as you don't have to parse complex formats like JSON. But having the timestamp in the same message would ensure that it gets updated at the same time, if one message should get lost.

Maybe it should be configurable:

I guess I thought about this a little too much, and was about to split my answer into this and a new issue, since i came up with ideas which are more than just a timestamp. But maybe we should just retitle this issue to something like "enhanced message format".

It would also be nice to have variables for all kind of data, like ${WIFI}, ${BEACON}, ${BATTERY}, ${TIMESTAMP}. With a simple and configurable "topic value" list the current presence and battery messages would then become something like this (with WIFI.MESSAGE taken from the Bedingungen-Tab:

presence/my_phone ${WIFI.MESSAGE} battery/my_phone ${BATTERY.LEVEL} timestamp/my_phone/this ${TIMESTAMP.THIS} timestamp/my_phone/next ${TIMESTAMP.NEXT}

The other option would be to send everything as a single JSON.

Some ideas of possible data:

ostrya commented 3 years ago

Sounds like a good idea. I'll have a look at supporting configurable message content. Maybe not all new data at once though ;-)