i8beef
commented
3 years ago - No, this node's input and output are disconnected on purpose. The other node is more of a generic request/response style, and while most commands WILL return a response here, its designed on purpose to allow unsolicited pub/sub from the cast device as well. Its closer to the Google spec, but comes with its own trade offs.
- Executing multiple commands from a single input is out of scope for setting volume at the same time right now. On a VOLUME command, it SHOULD always return a status response, OR throw an exception. I receive an output (two in fact, one for the command response and one for the published cast device state update) on every command for that in testing.
I'd probably just trigger both the volume change and the cast command directly from whatever the source input is, but just shove a wait node in front of the cast command for 10ms or so (guessing in timing, but 10ms should be fine).
1) is it possible to carry over original message in output of this node ? I have some flows where I need original message after it has finished casting. I could use flow context but would prefer if it was directly in message object 2) currently if i send a volume change command and volume is not changed, then there is no output from node. I have different flows which use different volumes, I was planning chaining volume command first and then sending my TTS/media after that. However if volume is already set to correct value, then there is no output and hence my actual TTS/media is not triggered. Ideally in your node if you can internally call the volume first and then send the TTS/media after that , that will be great (roughly emulating to other cast nodes ).