Enhanced message format
kroseneg opened this issue · 3 comments
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
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?
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:
- add a simple additional timestamp message (this + next)
- switch to one single JSON message
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:
- gps position, if already available
- current WiFi SSID and ESSID
- nearest beacon
- cell tower
- current timestamp
- timestamp of next intended publish
- battery percentage
- battery charging state
- everything else Android tells us ;)
Sounds like a good idea. I'll have a look at supporting configurable message content. Maybe not all new data at once though ;-)