Why does a Broadcast take Module ID input but the Broadcast from a "Round-Trip" does NOT take a Module ID input?

[DoctorAutomatic]

I didn't really notice this before and I'm paying the price in a very labor intensive process of removing a bunch of broadcast events that were created using the "Round-Trip" option and re-creating them using the "Broadcast" only option. I need the requesting module to only listen for broadcasts from the specific module it calls and I realized, too late, that there is no identifying info in the broadcasts (eg. no Module ID input) that I created earlier. Why is it that Broadcasts are different depending on which method was used for creation "Broadcast" or "Round-Trip". I certainly like the convenience of the reply and broadcast accepting the same cluster but of course making a stand-alone broadcast (in order to have Module ID) makes it no longer possible to have the same cluster input (the inputs are not "clusterfied") without a bunch more manual revision work. I'd like to understand the thinking behind making the broadcasts different. Anyone?

[joerg.hampel]

What's up, Doc 😉

Thanks for giving feedback. Fixing this nuisance has been reported as a feature request a while back and I'm happy to say that DQMH 7.0 will include this improvement.

As we know, the idea of a roundtrip event is for the broadcast to use the exact same payload as the request's reply.

As the request's reply does not have any need for the clone ID, it's not part of the reply payload. The roundtrip broadcast is using the same type definition as the request's reply - and that's basically it. You'll see that besides the missing Module ID, the roundtrip broadcast also has an error cluster, while the regular broadcast doesn't.

I can understand your frustration, and I apologise for the inconvenience. All I can say is that even though we're working hard on it, DQMH is not perfect. It's thank to feedback like yours that we get a little close to perfection with every new release 😜

[DoctorAutomatic]

---

@joerg.hampel wrote:

What's up, Doc 😉

Thanks for giving feedback. Fixing this nuisance has been reported as a feature request a while back and I'm happy to say that DQMH 7.0 will include this improvement.

As we know, the idea of a roundtrip event is for the broadcast to use the exact same payload as the request's reply.

As the request's reply does not have any need for the clone ID, it's not part of the reply payload. The roundtrip broadcast is using the same type definition as the request's reply - and that's basically it. You'll see that besides the missing Module ID, the roundtrip broadcast also has an error cluster, while the regular broadcast doesn't.

I can understand your frustration, and I apologise for the inconvenience. All I can say is that even though we're working hard on it, DQMH is not perfect. It's thank to feedback like yours that we get a little close to perfection with every new release 😜

---

Thanks for the reply. What I had in mind was that the broadcast accepts the same cluster but it also has a terminal for Module ID (which could then be bundled along with the cluster inside the broadcast VI). 

Is there an ETA for 7.0?

[joerg.hampel]

---

@DoctorAutomatic wrote:
Is there an ETA for 7.0?

---

We don't have an official date yet as we're still in the middle of development. Our target is Q3 2023, but that is really tentative at this point...