Buttons are a fantastic example here.
app:19 2019-04-04 10:04:48.544 am debug Sending DEVICE Event (Office WallSwitch | SWITCH: on) to Homebridge at (:8005) app:41 2019-04-04 10:04:48.515 am info Received event from ZeeRadioUpper/Office WallSwitch: [switch, on null] dev:737 2019-04-04 10:04:48.022 am info rcvd: DEVICE,2,2,4 dev:737 2019-04-04 10:04:47.864 am info rcvd: DEVICE,2,2,3
Pico says, press, release, light switch gets turned on, Hombridge gets informed. No dups.
Is this whilst having HubConnect in debug?
HubConnect doesn't auto disable debugs, as an app, and I haven't turned off debugging in weeks. 
Too many reports to review
Again, I am not arguing, just saying I'm not seeing it as you are. I fully believe you're seeing what you show in the logs.
I'm thinking there's one more hidden clue in this somewhere.
Then I cant explain it then, whilst in websocket this is what I'm seeing.
app:55172019-04-04 06:17:02.805 pm infoReceived event from Hub_1/Office Spots: [switch, on , isStateChange: true]
app:55172019-04-04 06:17:02.732 pm infoReceived event from Hub_1/Office Spots: [switch, on null]
app:55172019-04-04 06:17:02.679 pm infoReceived event from Hub_1/Office Spots: [switch, on null]
app:55172019-04-04 06:17:01.479 pm infoReceived event from Hub_1/Office Dimmer: [pushed, 2 , isStateChange: true]
app:55172019-04-04 06:17:01.423 pm infoReceived event from Hub_1/Office Dimmer: [pushed, 2 null]
I change to HTTP and then just have this.
app:55172019-04-04 06:19:47.314 pm infoReceived event from Hub_1/Office Spots: [switch, on , isStateChange: true]
app:55172019-04-04 06:19:46.625 pm infoReceived event from Hub_1/Office Dimmer: [pushed, 2 , isStateChange: true]
Update to show on again, rather than off. 
@srwhite, I was going to push some more contact sensors from HE to ST today. Whenever I went to the Hubconnect app, I noticed that instead of my ST hub showing Online, it showed Warning.
I have never seen that before and there was nothing in the logs that I could tell. What does that mean?
I reconnected to server from both sides and Online is showing again.
Warning is the intermediate stage between Online and Offline. It occurs when 'pings' from the Remote to the server don't arrive. Those 'pings' are over the LAN from hub to hub so communication should be absolutely solid. I do a LOT of testing, both of my own needs and of reports made here. I have never seen a hub go Offline that wasn't caused by me removing then re-adding (incorrectly) a hub. The recent update of v1.2 included order changes, that removed my tendency to add hubs with the wrong series of mouse clicks.
On my first floor hub one of my Aeotec MS6's is not auto syncing with the controller hub. When I go to the device on the controller and click "sync" it updates. No oddness in either set of logs that I can see. I am using event socket to connect and did do a firmware update yesterday which rebooted both hubs. I am using a custom driver and the omnipurpose HC driver. Further note - set the driver to stock, changed lux reporting to 10 and still no updates (morning here so illuminance is increasing).
Update: Removed device on controller and then went to the client and went into sync devices and clicked done (also unselected/selected device again to be sure). Device recreated and seems to work now.
Are we getting closer to working on user drivers yet? 
I worked on it last night, mostly discovering my 18 attribute test driver needs more focus 
Hi all... I'm back from a very long and grueling conference in Las Vegas. Please allow me to catch up on a few things...
I have not seen this behavior, however I am completely convinced that it's not a HubConnect issue. All that happens when the eventsocket is used is that Hubitat listens for a new event on the socket and calls the parse() function. I have not seen duplicate events at all and I've got hundreds of devices. All of those functions are transparent to HC. Either something on the remote hub is generating duplicate events or creating phantom events on the websocket. It's also possible that something on the receive side of Hubitats socket implementation is causing parse() to be called more than once for the same event.
What I have noticed is that after about a week or so there seems to be a bit of a lag in websocket performance. When I returned from my trip late last night I noticed my cross-hub automations were at least delayed by at least 5 seconds. I plan to add some code to refresh the socket connections at 24 hour intervals in the next release.
It means that there are missed communications between your remote hub and the server hub. Can you check your debug logs to see if any errors are being generated?
That'll be out Q1 2020. 
2 Likes
Now that I think about it, I had just rebooted my HE hub. It may not have had time to reconnect when I saw it. Once I went into the App and reconnected, it was fine, and has been ever since. If I see it again, I will be sure to let you know if I see anything in the logs.
Please do! I’m still going to add the option to refresh the sockets in the next release in response to the lag I saw last night. That was fixed by reconnecting.
But yes if that comes back let me know.
Thanks!
New Ecobee Suite support for HubConnect!
Users of my popular (and FREE) Ecobee Suite for SmartThings can now fully control setpoints, thermostat mode, fan mode and the currently running schedule from the reflected SmartThings device within Hubitat.
Please see the Ecobee Suite Thermostat v1.6.24 update notice (on the SmartThings Community) for more information.
N.B. Currently my Ecobee Suite is only supported on SmartThings. With the impending availability of a Hubitat mobile UI, I do plan to begin natively supporting both platforms.
2 Likes
Ohh .. interesting .
Would love to explore an ‘MQTT online’ option too. I’ve been thinking about that, now I must look into the MQTT HomeBridge plugin capabilities.
1 Like
That's cool.. wonder what else we could connect to...
Your going to tell me it’s just a ‘spoof’ name for a Hubitat Hub now aren’t you ?
No spoofs, although I cannot claim any credit for compatibility other than adding bidirectional mode support...
HubConnect 1.3 will be ready in a couple days.... In addition to the teaser that @csteele provided, there are a few other goodies coming...
New Features:
Bi-Directional Mode Support. Remote hubs can now send mode changes to the server, which then pushes them out to all remotes. This is configurable on a per-hub basis.
Hub Tools. From the server hub web UI, reboot and shutdown Hubitat hubs that are located on the same LAN.
Mode Report. A single view that queries all hubs and displays the available system modes and whether which direction that mode changes can flow.
Custom Driver Enhancement. Custom drivers can now have up to 18 attributes!
BETA: System Version Report. Queries all hubs for all app and driver versions to made updating easier. This is in preparation for update notification that will be coming soon.
Note: The error is because my RV hub is not running the latest remote client. I've left this to demonstrate the behavior for hubs not updated or reachable.
Fixes/Optimizations:
- Switch to faster JSON encoding method throughout.
- Dropped use of JsonSlurper in favor of built-in parseJson methods.
- User-defined driver types work for up to 8 attributes. (Will expand in 1.4)
- SmartThings HTTP errors on attributes containing a % symbol (i.e. battery reports)
- Editing custom device attribute 1 failed to set drop-down to the proper attribute type.
New/Updated Drivers:
- Updated Siren Driver for Hubitat, adding Siren/Strobe/Both commands.
- Native Siren Driver w/tiles for SmartThings
- Native Lock Driver w/tiles for SmartThings
- Native Garage Door Driver w/tiles for SmartThings
7 Likes
I'm not even a month into switching to HE, and I'm already considering getting a second hub.....to be a coordinator hub, to solely run just the apps and wifi/lan/IFTTT devices, and have my current hub solely for zwave/zigbee devices.
My question is what would be the best process to do this with the least amount of frustration, as being I have Schlage locks that were/are a PIA to get paired properly and I really do NOT want to experience that process again, I was thinking this route and tell me what you think or what I may have wrong?
After registering the new second hub, add the apps/wifi/lan/IFTTT devices first on it, then I can delete them from the second hub?
