Pass Sync intent to MQTT

[glsf91]

I'am (trying) working on a Domoticz plugin to connect to your software. Therefore it is needed that the plugin need to to know when a Sync intent is received from Google.

Can you make it possible that when a Sync intent is done by Google, a MQTT message send ? Preferable in a configurable topic (including root). When not configured in for example google/home/SYNC

[i8beef]

Not a bad idea. I haven't really allowed for configurable MQTT topics (outside the root), but these should now publish on (default topic root "google/home")

1. (topicroot)/sync/lastRequest - A date time offset string of the last sync intent time (not retained)
2. (topicroot)/query/lastRequest - A JSON object containing a date time offset, and the list of device objects sent (not retained).

[glsf91]

This looks fine for me.

Background for the question of a separate configurable root for the intents : After (topicroot)/ the configured device is normally used. So you can just subscribe to topicroot/#. But now also all execution messages are also coming in because it is on the same position as the device. It is a little bit strange (for me) to use on the same position in the topic a different meaning of the topic name. It would be more logically (I think) to use for example google/home/devices/\<device> instead of google/home/\<device>. Then you would get:

• google/home/devices/\<device>
• google/home/execution/..
• google/home/sync/..
• google/home/query/..

Configurable topicroot can be google/home (one topicroot will be enough).

But if it is to much trouble leave it this way.

[i8beef]

I'm NOT published at google/home/<device> though. Commands are at google/home/execution/<deviceId>/<commandName> and that 'level' of the topic already serves the exact purpose you said: it specifies a namespace of usage. You can't really just subscribe to the root topic and assume that all topics are used the same way. As an example, you shouldn't be listening to any topics like google/home/commands/+/set because those are for internal use. You probably need to differentiate your subscriptions a little bit more.

[glsf91]

You are right. I forget something. In a traits I can specify the command (and state) mqtt topic and used for example for a OnOff traits: { "action.devices.commands.OnOff": { "on": "google/home/SHP2_1/onoff/set" } } In this case "SHP_1" is the device. So I did this for all devices and therefore subscribing to google/home/#. Of course I can easily change this to google/home/devices/SHP2_1/onoff/set and subscribing to google/home/devices/#. So then my "problem" is solved I think.

I'am a little confused by your last sentence. Are you now saying that I not should use for example google/home/SHP2_1/onoff/set (or google/home/devices/SHP2_1/onoff/set)?

(at this moment I do not use the google/home/execution/... topics)

[i8beef]

Your MQTT topics for state and command params don't need to be under google/home, although that's fine if they are, and like you said, I'd place them in their own "namespace" topic like google/home/devices/* if you're going to do that. I listen to explicit topics, and the aforementioned google/home/commands/+/set and that's really it, so you're pretty safe there.

My point was if I were you, I wouldn't listen to a wildcard of google/home/#, you are going to capture stuff you shouldn't with that, rather I would listen to the individual topics you need (or google/home/devices/# if I'm understanding the structure you are trying to use here, since you basically "own" that topic root).

Some people like separating command and state by a base topic (e.g. google/home for state and cmd/google/home for commands) so they can listen to wild cards instead of individual topics. There's merit to that, and some days I wish I'd standardized on that, but I use the /set standard where each topic is a "resource" and it exposes functionality off it at known suffixes like 'my/resource/topic' has 'my/resource/topic/set' to set a value, '/get' for requesting publishes, etc. That was why I said IF you are going to listen to the google/home/# wildcard, you may want to specifically ignore anything ending in /set because those are commands TO HomeAutio.Mqtt.GoogleHome, not state publishes FROM it.

[glsf91]

Yes indeed, I'am going to listen to google/home/devices/# (or another totally different root). That will solve "my problem" in my second post. I mixed up because of your use of google/home/ for execution and and the google/home definitions in de device configurations. But it is clear now. Thanks.

[i8beef]

Glad we got it straightened out! Let me know if you have any other questions!