Hub Mesh - Linked devices don't share events - suggest adding to docs

Hi - I'm guessing this is not a bug but rather an expected behavior - but it wasn't obvious and caused me some wasted time trying to figure it out.

It appears that when you create a linked device via Hub Mesh, the event pages are not mirrored. For instance, for a Zooz zwave scene controller, when there are button presses and subsequent button controller actions - these appear on the Events page only of the original device but not the linked one. On the other hand, if I have Maker API actions that act on the linked device to turn it on or off, these appear only on the events page of the linked device - not the original. I imagine there are good reasons for this - but intuitively, I assumed the linked device was a true mirror of everything happening to or caused by the original - and that seems not to be the case.

Worth noting in the docs.

Hub Mesh shares event history in a quick test I just performed. Are you not seeing things like "pushed" or "switch" in the "Name" column (on the "Events" page) on both hubs? These would represent actual events for your Zooz scene controller. What I don't see is command history, which was a relatively recent addition to the "Events" page. These would be things with names like "command-push" or "command-on" and have "command" in the "Type" column (unlike events).

If you're seeing something different, that would be good to know and could be a problem. For the issue I see, could see it either being intentional or just an oversight for the new-ish feature.

Whether this is intentional or not, I don't know, but @gopher.ny would be the one to ask. If it is, then it could find its way to the docs, otherwise hopefully it will just be addressed. :slight_smile:

1 Like

Ah, you're right - it's the command events that are not shared. The pushes are showing in both places.

In the current implementation, commands are always local. An app running commands on hub A with the original device exists is absent from hub B where linked device exists and vice versa.

Commands were added to help trace the source of device state change, with links to what called them. It's possible to expand the command log entries to consider non-local command sources, but such change is not trivial. I'll keep it in mind, but it's definitely not happening in the short term.

3 Likes

I think the issue is that if commands are acting in both places (original and linked), there is no single place to see everything that is acting to cause state changes. As I discovered, you need to be looking in both places to make sense of what's happening.
Knowing this, I'll try to have apps act in only one place, but that kind of forces you to concentrate all the apps and integrations on one hub or the other rather than distributing the potential load.

Unrelated question to OP, but related to hub mesh. Why the removal of UDP and the change to TCP only?

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.