HubConnect Arrival DH is sending 2 present events which can cause a rule action to fire 2 times.
I am running a mimolite as a garage door opener and the "push" function was firing twice which caused the door to stop mid way.
Added a refresh to the open/close in The mimolite custom DH and working fine now.
But HubConnect Arrival DH sending 2 present events may cause issues with other rules.
I having trouble getting fan speed to sync or run correctly? Any idea's on what I can try to get it going? I have a Hampton Bay Zigbee Fan Controller on one hub and on the server I have the device coming up and I get it to the dashboard and I have a Question mark on the icon? I click and can see the off, low, medium , etc but when I click doesn't do anything?
Did you click the "This will create two additional devices, a fan and light that can be used in addition to the controller." on the device settings page. and click Save Preferences. Then use the newly created "child fan" device as your tile selection for a fan tile?
1 Like
I'm thinking of moving my Hue integration from my coordinator hub to my client hub. Is there any easy way to change the current Hue bulbs in the Coordinator hub to their respective (new) devices on the client. My Hue bulbs are in a lot of rules......
For example, will changing (on Coordinator) for hub bulbs the "device type" and "device network ID" to their new records on the client hub work? Or are there more magics behind the scenes that I'm not aware of?
Hue Integration is a LAN function. For me, I do what I can to make the Z-Radio hub purely Z-Radio.
The Zigbee and ZWave radios are already slow, relative to LAN speeds. (ZWave = 100kbit/sec vs LAN at 100mbit/sec -- that's 1000 times slower: kilobit vs megabit.) Those radio queues need to be 0 or 1 to be as speedy as possible. Anytime the queue depth goes above 1 then something is waiting on the previous action. LAN, for all it's speed, have bigger packets and get processed between Z-Radio... which means there's a potential for delaying Z-Radio packet #2 and beyond. That's the precise reason asyncHttpGet is so much better than httpGet was. Z-Radio packet #2 gets attention between the time a http query is made and the response comes back.
I'm guessing that 'coordinator' is defined the same way for you as me.... if not.. ooops. 
Yes, I realise that the Hue integration is a LAN function. But I've got a sneaking suspicion that many of the slowdowns are caused by Hue or Dashboards. They seem to be common among the slowdowns in that slowdown thread.
For example, my system is 1 co-ordinator and 1 client. On my co-ordinator I have almost no user apps. On my client, I have dozens, including cloud connections. Yet it is always the coordinator that slows down. The only user apps I have on the coordinator is SuperTile and HubConnect. There must be more to the story than "user apps". A user reported the other day that a brand new hub without any apps was slowing down. Another user over the weekend reported that their Hue hub caused their HE hub to lockup (flashing lights/color changes for an event). So, to test, I want to move my Hue integration to the client hub to see if it slows down, or speeds up my coordinator hub.
Do you know if it's possible to do what I suggested in my post above? Thinking more, what I'd do is create the devices in the client hub, and get them to flow through to the Coordinator hub, and then delete them in the coordinator hub, change the Hue bulbs on the coordinator hub "Device Type" and "network ID" to match what they were on the now deleted mirrored device. I'm wondering if it will work.
The Slowdown thread is misleading because there are at least three different slowdowns reported, two of which have fixes/workarounds:
- C-5 + NetGear switch can misnegotiate the 100/full network connection. Fix: get Support to patch your Hub to use a fixed 100/full.
- DB Corruption: Fix: DB save, SoftReset, DB restore.
What's left is clumped into "user Apps" and I'm quite ready to believe there's further distinction in that mud puddle 
I know of no way to avoid having to adjust each Rule to use the device with a new DNI.
After doing both of these and thorough rule cleanup (actually several soft resets and restores) and then deleting third party as well as some HE apps including chromecast, ifttt and the dashboard app, I have had 0 issues. I have continued to not have any issues. I have Hue integration, and HubConnect, but my issues resolved without removing them. I have reinstalled Dashboards and added over 100 devices back in so far. I have also added back Echo Speaks when 3.1 was released (with 3 devices only so far) and have not seen any difference in hub performance. I have not added anything else at this point, and will be much more conservative in adding things going forward.
2 Likes
HubConnect Updates:
Oct 1, 2019
SmartThings:
- HubConnect-Remote-Client: added lastCodeName attribute
- HubConnect-Lock: added lastCodeName attribute
Hubitat:
- HubConnect-Server-Instance: added lastCodeName attribute
- HubConnect-Remote-Client: added lastCodeName attribute
- HubConnect-Keypad: added lastCodeName attribute
RE: code name not being passed by HE
Are we closer to the later? 
1 Like
AFAIK lastCodeName works, after upgrading to today's versions.
I only have a single lock to test with, but it worked instantly for me.
Have had a test rule setup just in case for when it was fixed. Updated code this morning but didn't trigger when kids got home from school today. Will have to look into it when I get home today. Thanks!!! Been waiting for this one!
I do see in the logs on the remote that it shows WHO opened the door. But my test rule didn't fire. Will check it out.
dev:806 2019-10-01 01:32:51.623 pm info Yale DoorLock was unlocked by Wife[6:6]
dev:806 2019-10-01 01:32:43.848 pm info Yale DoorLock was manually locked [physical][6:1]
I just tested and got the answers I was expecting:
It's hard to tell the difference but the lock on the other end of HubConnect shows the same...
The "hint" is that the HubConnect driver has Version showing.
I'm getting this error in Smartthings when trying to select a sensor:
java.lang.NullPointerException: Cannot execute null+null @line 1170 (doCall)
The Sensors page isn't coming up at all on Smartthings app.
When I comment out the motion sensors section as shown below, it seems to work fine.
Ok, I am seeing everything you show also. So it does seem to be working. I must be doing something wrong with my rule. This is it:
Apologies if I've missed this but is there a way that one hub can set the HSM status of another hub independent of one-another?
I have a hub in an outbuilding that I want to arm/disarm independently of my main house.
One thought was to create a virtual switch on the outbuilding hub. On the same hub create a Rule Machine that arms/disarm when the switch is toggled. I could then share this to the main hub and toggle the switch as and when I wish to arm/disarm?
the virtual switch can be on either hub, then you mirror it to the other, yes. Then use Rules to set HSM per that switch.
1 Like
Perfect, thank you.
I tested the lock rule above while home. Still not seeing the user come through. Rule never triggers.
I'm having trouble getting events to push automatically from ST devices to my HE hubconnect server. If i hit sync on each virtual device in HE, the device data updates, but I see errors like this in my HE and ST live logs. I don't actually have a ST hub connected on my LAN, but these are virtual devices in ST that should connect through the cloud anyway I think?
I see similar errors from different kinds of ST virtual devices. What can I do to troubleshoot? Thanks.
