Pistons firing on both hubs in a two-hub installation?

#1

We recently got a second hub to provide better coverage to devices in an outbuilding. Ever since, it seems pistons are firing from each hub, regardless of which devices they interact with. This has mostly been noticeable with pistons sending requests to assistant-relay (as it logs incoming commands), but we’ve also had some erratic behavior with motion-triggered lights (set to fade up with motion, since adding the second hub they stutter back and forth until reaching max brightness twice). These issues stop as soon as the second hub is unplugged.

Webcore was initially setup with just the one hub, and wasn’t installed again or anything when we got the second (it simply showed up in the webcore dashboard once added to ST). I can’t seem to find anything within webcore to stop this or even identify which hub is triggering a piston. Is there any way to stop both hubs from triggering a piston without breaking the second hub out into its own location?

#3

Both hubs are setup under the one ST location. The pistons are all working fine, WebCoRE can see both hubs and devices on both hubs - even pistons using devices on both hubs work fine. Would a second WebCoRE instance still be necessary? There still doesn’t seem to be any way to restrict an instance to a particular hub…

#5

I’m struggling to understand what you are seeing. How do you mean pistons are firing from each hub?

#6

Not really sure how else to describe it. Pistons appear to be executing twice, but only when both hubs are active.

I have a piston that POSTS a command to assistant-relay to trigger a device that isn’t directly ST-compatible.
With both hubs on, if the piston triggers, the command is executed twice on assistant-relay, the assistant-relay logs show it receiving two commands.
Unplugging the second hub and triggering the same piston, it executes once and assistant-relay logs show it only receives a single command.

(This is just an example, it seems to be affecting all pistons, incluiding those that don’t interact with assistant-relay at all. This is just the easiest to demonstrate/test given the AR logs show the duplication)

#7

Hmm well seems I was completely wrong about this issue. Changed my assistant-relay pistons from POST-ing the commands, to use a DTH instead… and now even with both hubs on its only sending the command once and working as intended. Not really sure why a POST would be issued twice… and even more confused about why turning the 2nd hub off made any difference, but its working now so that’s the main thing.

#8

I am wondering how a HubAction works when you have two or more hubs in a location. Which one gets the job? The designated default one? Or am I having a brain fart?