I run two hubs, connected through Hub mesh. Hub 1 serves device A, and device A is polled regularly. A's value may stay unchanged for hours. Hub 2 is linked to device A on Hub 1 ("A on 1"), and it runs an app which is subscribed to unfiltered events sent by "A on 1" - meaning it's meant to be notified also by "A on 1" events which don't cause a value change (for the record, that works perfectly fine if everything runs on a single hub).
Unfortunately, it looks like Hub mesh tries to be smart and reduce traffic between hubs, and it doesn't sync "unchanged" device events - even if there are apps on linked hubs subscribed to them.
Anything I can do to work around that limitation?
Ultimately I think it is worth pursuing a question to HE support and/or developers to confirm the behaviour you are seeing and that your assumption around how it is working is indeed correct. If you are right, you could then follow up with a feature request for Hub Mesh.
In the meantime.... In terms of a workaround....
Do you want to provide a bit more background on what you are trying to achieve? It may help in working out what options you may have.
Is there an app / driver on Hub 1 that is instigating the polling of device A?
For the apps on Hub 2 that subscribe to the "changes" in device A, is that essentially to notify those apps of the polling having occurred? Or can the device also report back in an ad-hoc way? What I am wondering is do you have some control / knowledge of this polling occuring?
I guess the more we know about what you are trying to achieve, the easier it may be to consider what other options you may have.
The best I can come up with based on what you have described would be some kind of proxy virtual device on Hub 1, like a switch for example, that gets toggled when something happens for device A, then that switch gets shared with Hub 2 via Hub mesh. You could then use that switch to drive any automations on Hub 2 that need to be triggered by changes in device A.
Thanks @sburke781 .
First, let me preface that this isn't a show stopper for me; it's just a behavior in hub mesh which caught my eye as a discrepancy between how things work on a single hub, and how they work through hub mesh. I can see why the HE developers would have implemented that behavior (network traffic optimization), but it does break application's behaviors when they rely on unfiltered event subscriptions. An annoyance for me; I expect it may be a major problem for others.
About the usecase, it's quite simple: Hub2 is meant to deal with the heavy wifi operations in my system, like dealing with reliably pushing data to influxDB/grafana for monitoring purposes. Hub1 provides primary device connectivity - except for devices which are physically closer and more easily served by Hub2. Hub1 polls some devices which would otherwise go for hours or days without reporting data; many charts in grafana are easier to read if you get regular updated data points (even with the same values); in some other cases - moving averages - charts semantics change/are incorrect if you don't have regular updates.
That's where the scenario I mentioned above comes in place: when device values are unchanged Hub2 is unable to push unchanged values for a device freshly polled by Hub1. Makes sense?
There are of course tricks I could implement to work around this limitation (it's software - anything is possible!); it is just annoying - and not worth the effort in my case; which is why I was trying to understand whether I'm hitting an actual mesh limitation which will never be addressed in HE (works "as designed"), or if there is hope that this changes in time.
Thanks!
1 Like
In general, the Hubitat architectural design is for the the device driver to create an event for newly received data from a device. At that point, the Hubitat Platform normally performs a de-duplication of events, tossing away unchanged values. The only exception to this is if the driver specifically is configured to instruct the platform that this is a new event. You can look for this by searching the driver for "isStateChange: true" in the sendEvent() calls. Normally, that argument is not present, and the platform will automatically de-duplicate the incoming events.
2 Likes
I don't think that's entirely correct.
The subscribe() app API accepts an optional argument where you can ask Hubitat to filter (default) or not device events which don't change values:
subscribe(myDevice, "temperature", handleTemperatureEvent, [filterEvents: false])
So, the HE architecture knows well that events are fired by devices even when values are not changed (it's the device itself that decides, as you mentioned: device.sendEvent(name:"attribute", value: "myValue", isStateChange: true/false)).
There is no question that HE knows an event has been fired, even when isStateChange is false; proof of that is that if I run the solution I mentioned above on a single hub, it works exactly as expected.
I think what @ogiewon is getting at it the recording of the event on the remote hub is not being controlled by the driver, so the choice by the developer in the driver is not the same as what HE is choosing on hub 2.
What driver are you using on the Hub that 'works exactly as expected'?
What driver are you using on the Hub that 'works exactly as expected'?
...driver? This is not a matter of driver, it's a matter of an application using "filterEvents:false" as an argument to subscribe. The device driver is irrelevant (unless, of course, you create a driver which forces isStateChange to true always, in which case the filterEvents value (or lack of) is irrelevant.
I think what @ogiewon is getting at it the recording of the event on the remote hub is not being controlled by the driver, so the choice by the developer in the driver is not the same as what HE is choosing on hub 2.
As mentioned, this is not a choice of the driver; it's a choice of the application - Hub mesh in this case. And, as mentioned in my original post, that choice makes it impossible to honor the choices of applications consuming events from those linked devices on connected hubs.
I am genuinely curious about the driver being used. Please share the driver details so I can further understand the issue. I am only trying to help understand the root cause, and without the full details, it is hard for us as a community to learn.
Event Generation is not a function of any App. It is always a function of the driver. Thus my curiosity. Hub Mesh, which is closed source code, is obviously a unique potential exception to the rule. 
3 Likes
@ogiewon I probably haven't described the situation properly. Let me try it again.
My devices send events, standard drivers; as such, in some case they create events with isStateChange == true, in some others == false. All good. As I mentioned, the specific driver is irrelevant; in my case it applies to any standard temperature sensor driver.
My application subscribes to events from devices; it does so specifying "filterEvents: false", which means it's asking HE to be notified also of events which are flagged with isStateChange==false.
In a single hub scenario, that works as expected - the application does handle all events, changed/unchanged state. In a meshed hub scenario, the application is notified only about events with isStateChange==true - meaning Hub mesh filters out the isStateChange==false ones, ignoring the application desires.
2 Likes
Yes, that definitely is clear now. Thank you for clarifying it. I would recommend reaching out to @gopher.ny from Hubitat, as he is the "Hub Mesh" subject matter expert.
I am still curious, though... 
Are these Hubitat built-in drivers? Or are these Community Drivers? Or are these your own custom drivers?
2 Likes
I am still curious, though...
"standard drivers" - meaning Hubitat built-in drivers.
(if they were my own, the workaround would be trivial...)
1 Like
I'll check that. You're running the latest version, right?
