Closed kroseneg closed 2 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?
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:
Sounds like a good idea. I'll have a look at supporting configurable message content. Maybe not all new data at once though ;-)
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