Any thoughts as to my Sonos question:
I'm having a tough time determining that it would/could make a difference. You really want to put apps and drivers on the hub where the risk is mitigated. For me, I feel my "active Z-radio Hubs" are the very ones that I don't want to add risk. 90% of everything a hub does is local to that hub. All the Switches, dimmers, and sensors for any one room or hallway is on one specific hub. I have exceptions and those exceptions MUST use the server/'coordinator' hub to get the attributes distributed. (Zigbee exists on one hub only and thus those few devices that don't apply to the local switches and dimmers, get distributed.)
With three hubs, I have two "main hubs" -- one for upstairs and one for downstairs. 'Coordinator' is the third hub and is the HubConnect Server in my scenario.
Therefore I agree with your:
All 'real devices' and a big handful of virtual devices are mirrored to 'coordinator' where "everything" gets distributed outwards to Google, Alexa, Homebridge, and Dashboards. That includes Chromecast, which is my stand in for your Sonos... both are native HE apps/drivers.
1 Like
Hi everybody, I'm bringing some Arlo Pro cameras and siren associated with a ST hub to my Hubitat. That's the only use I have for ST Hub right now. Also, I'm using it to turn on and off a Samsung TV.
I'm not so sure if anybody noticed but the motion drivers don't seem to report the right status. The only one that gets through is the Battery Level. Well, I've tested it with my Arlo cameras so far, and although the devices are created with the right driver on my HE, it's not reporting any motion, rssi or sound detection. I can see some values on the events tab but it's not reporting any changes to the right status fields. Is it possible that I'm doing anything wrong? Maybe it's the driver or is it the App? I used the latest version from 4 days ago and I followed the instructions. Also, I don't know how the hub modes Away/Home/Night on a ST hub get synched with the Away/Day/Evening/Night modes from HE.
I don't have an Arlo cam, so I can't offer any specific advice...
Your Arlo(s) are on ST and using a functioning ST driver, I presume. That driver reports Motion as an attribute called "motion" correct?
HubConnect Remote Client on ST will see that attribute and send it to HubConnect Server Instance on your Hubitat. There's no real magic there, although the fact we can do this still feels magical to me. 
The HubConnect Universal Driver for Arlo exposes the following Categories, Attributes and Commands:
If the ST driver isn't manipulating one of those attributes, spelling/case SenSitiVe, then there's nothing for HubConnect to 'Inject' into the Server hub.
I was taking a look into it and apparently Arlo cameras report motion detection ONLY if you have armed them. Sad thing because if you arm them, you'll also be recording a bunch of events that you don't need to. SHM can control the actions like recording and stuff like that only if the Arlo system is configured to use the rule "SmartThings mode", so in conclusion, I'll need to arm the system to see if the reporting system actually works.
Here's how the driver looks in SmartThings:
1 Like
As per this thread:
It seems the lock codes aren't getting passed or logged or something from Hub to Hub. I can post details of whatever is needed.
I do see in the logs of the hubconnect lock device that it seems the control hub is getting passed to it the lock code as referenced in the link above. However no triggers are hitting RM from that device.
These are the events from the HubConnect lock device:
So it seems to be seeing the individual user.
This is the event log from the RM rule:
Nothing.
This is the rule:
I tested with a RM rule on the hub with the zigbee lock device and was able to toggle a bulb based on a specific user unlocking the lock. So it seems something is amiss in hubconnect?
On my "stub hub" (the hub with a stub driver for the lock vs the hub with the real lock 
) I'm seeing the Event(s):
and the Logs show:
app:33 2019-08-30 10:46:34.067 am debug Sending event to ZeeHomebridge: Yale DoorLock [lock: unlocked null] app:2 2019-08-30 10:46:34.030 am info Received event from ZeeRadioLower/Yale DoorLock: [lock, unlocked null]
I'll try creating a similar Rule...
Yes, I'm seeing them there too. But when used in the rule I showed above. Nothing triggers and the rule events show no activity. Curious to see what happens when you create a similar rule.
Duplicated it. Same result as you.
Hi guys.
Just got a second HE hub and using this great app on both hubs.
On my second (slave) hub I have access to my Dimmer switches on my first (master) hub.
With WebCoRe on the slave hub if I use the set level command nothing happens but turn on works OK.
The dimmer on the slave is using the HubConnect dimmer driver.
Is this known issue or am I doing something wrong.
TIA
EDIT. Also seeing this error using RM4.
I'm seeing this in the logs for the dimmer on the master hub.
Tagging @srwhite
In the post above I am getting an error when trying to set the level on a dimmer defined on the master from a rule on the slave/remote.
Is anyone else getting this error when trying to set dimmers?
I don't have that circumstance, personally. All my Rules exist on the hub where the real devices are located.
My 'coordinator' hub gets a ton of event info, largely because I have every real device and many Virtual devices 'mirrored' to 'coordinator.' But all my Rules there are 'coordinator' functions. All my door window sensors are sent to 'coordinator' (for dashboard) and therefore it's the bst place to put a single "perimeter alert" Rule, as one example.
Like a lot of people, I have switches, dimmers and outlets all de/activating from what a Motion Sensor is indicating. Motion = lights on or temp = fan on. Not all Motion Sensors are on the same hub as the switches, dimmers and outlets... but in my case, I always 'mirror' the Motion Sensor, never the switch/dimmer/outlet.
I don't know that it counts BUT the one exception I can find is a Motion Sensor / Hampton Bay Fan Controller Rule. The Rule is on the hub with the Motion sensor and is setting fan Levels on a Fan that has been mirrored from another hub. Thanks for asking, allowing me to find this exception... I'll probably "fix it" so that it follows my pattern. 
Sorry if I'm being dense here but are you saying there is an issue here and you are going to have a look at it?
What I'm trying to do is run webCoRE exclusively on my remote hub to see how it runs. I have RM4 rules on my server hub that I've disabled and can use but I'm playing I suppose. 
Not exactly.
I'm saying I don't have a match on your question. I'm waiting to see if others respond that they have the same circumstances and it's working OR they do and it's failing for them too.
I'm still chasing @jrfarrar issue. What's that make me? 2 behind?
I've probably misunderstood how this set up should work then.
Thanks for the reply.
I don't think so...
A dimmer on one hub should 'mirror' completely to the remote hub.
I'm sure that in the thousands of tests I've done for HubConnect releases, I've done what you're asking. But I can't document it. I know I've done setLevel for fans. I know that setLevel properly mirrors, because of that effort. But Dimmers are one of the very first things I tested and once it worked, and no changes have been made in that area, I've not retested.
I have a dashboard that is on 'coordinator' where there are no "real" devices. Dashboard has a LOT of dimmers. They work.
It's the setLevel command being sent from the remote hub to the server hub where the device is hosted that's not working and throwing the error on the master hub.
yes.
dev:1224 2019-08-31 11:36:39.588 am info Office Ceiling Controller light was set to 20% app:837 2019-08-31 11:36:39.448 am info Received command from server: ["Office Ceiling Light": setLevel] dev:1224 2019-08-31 11:36:38.171 am info Office Ceiling Controller light was set to 43% dev:1224 2019-08-31 11:36:38.168 am info Office Ceiling Controller light was turned on app:837 2019-08-31 11:36:38.133 am info Received command from server: ["Office Ceiling Light": setLevel]
That's all the logs on my hub with the real device caused by clicking the dimmer on Dashboard (which is NOT on this hub)
Hmm. Not sure what to say.
Rule on remote sets the dimmer on the remote using hubConnect dimmer to 20%.
Logs says its set the dimmer on the remote.
On the server the device does nothing and I see this in the logs on the server.
If I use Turn On instead of setLevel then the dimmer turns on OK using the last level that the dimmer was set to.
Looks like I'm not able to use the dimmers this way.
Show me your Rule so I can duplicate the Rule
