According to https://valetudo.cloud/pages/integrations/mqtt.html#mapsegmentssegments map segment ids should be reported on the topic <TOPIC PREFIX>/<IDENTIFIER>/MapData/segments.
This works well if "Provide map data" is checked in the Valetudo settings and this in line with the description in the docs.
However, when "Provide map data" is unchecked an empty JSON object is published to that topic. This undefined or at least undocumented behavior. Citing from the documentation This handle groups access to map data. It is only enabled if provideMapData is enabled in the MQTT config.
Note that <TOPIC PREFIX>/<IDENTIFIER>/MapData/map-data is still retained in this case if it was previously published.
UPDATE: When pressing "Save Configuration" in the UI switching "Provide map data" to "On" there is a ~30s delay until the segments are published on the topic. When switching from "On" to "Off" state, the message is received almost instantly. This can lead to perception of an intermittend issue if the user doesn't wait long enough for the message to be received before switching the setting back.
Nothing is published on <TOPIC PREFIX>/<IDENTIFIER>/MapData/segments if "Provide map data" is unchecked.
Keep segment ids topic published with content even if "Provide map data" is unchecked and update the documentation accordingly. This is useful for using the MapSegmentationCapability https://valetudo.cloud/pages/integrations/mqtt.html#segmentcleaningmapsegmentationcapability.
- To keep consistency with the HTTP API it would be logical to publish the topic also in the
<TOPIC PREFIX>/<IDENTIFIER>/MapSegmentationCapability/segmentstopic. - Some MQTT clients allow splitting JSON objects into subtopics, e.g.
{"foo": 2, "bar": 3}on topicbla/blitopbla/bli/fooandbla/bli/bar. Therefore, reversing the map segment object key/value order could be useful e.g.{"office": 2, "kitchen": 3}