[RELEASE] HubConnect - Share Devices across Multiple Hubs (no longer SmartThings!)

mick.baker · November 13, 2019, 8:26pm

Truely outstanding..... code / documentation / implementation: Echo Speaks perfectly.
One little issue, on the slave I am running Netatamo weather station, I can see 2 of the modules indoor & Outdoor but there is no sign of the Rain and Wind modules. Am I missing something? They don't get listed as an option in Huninstance on the slave.

Bago · November 13, 2019, 9:28pm

Thanks, that is what I thought. I’ll turn that on and let you know.

Bago · November 13, 2019, 10:57pm

This is a small example, I turned on the Light - Porch.

The left image is where the Light - Porch lives (Remote Hub App), and the right image (Server Instance) is the server that it is sent to. The server shows nothing in the event logs.

I did find a pattern. Devices mirrored from the server to other hubs always update the event log. Devices mirrored from remote hubs to the server do not.

csteele · November 13, 2019, 11:25pm

The ERROR is saying that you don't have the HubConnect Hub Driver code installed.

github.com

HubitatCommunity/HubConnect/blob/master/Hubitat/drivers/HubConnect-Remote-Hub.groovy

/*
 *	Copyright 2019 Steve White
 *
 *	Licensed under the Apache License, Version 2.0 (the "License"); you may not
 *	use this file except in compliance with the License. You may obtain a copy
 *	of the License at:
 *
 *		http://www.apache.org/licenses/LICENSE-2.0
 *
 *	Unless required by applicable law or agreed to in writing, software
 *	distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 *	WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 *	License for the specific language governing permissions and limitations
 *	under the License.
 *
 *
 */
import hubitat.helper.InterfaceUtils
metadata 
{

This file has been truncated. show original

Bago · November 14, 2019, 12:19am

Thank you. Sorry I missed that. Still doesn't update.

First two images from the server, last two from the remote.

Bago · November 14, 2019, 1:16am

Good news, I hope. Pressing sync on one of the devices generates this:

csteele · November 14, 2019, 1:21am

The first screen cap is the Virtual Hub device.. dev:705 and the most recent line:

"Switching connection to Home1E to socket"

Is about all you should be receiving. Completely normal and matches mine;

The App capture of the server is again, what I'd expect for such a short log, since the Driver was added. You got the lines showing the instance was initialized and that you got a ping. So far so good.

Matches mine, too.

app:3 2019-11-13 12:24:14.224 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [ultravioletIndex, 0 null]
app:3 2019-11-13 12:24:14.039 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [illuminance, 4 lux]
app:3 2019-11-13 12:24:13.646 pm info  Received event from ZeeRadioUpper/KidsRoom Fan Module: [energyDuration, 157.19 Days null]
app:3 2019-11-13 12:24:13.618 pm info  Received event from ZeeRadioUpper/KidsRoom Fan Module: [energyDuration, 157.19 Days null]
app:3 2019-11-13 12:24:10.150 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [battery, 100 %]
app:3 2019-11-13 12:24:09.333 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [humidity, 42 %]
app:3 2019-11-13 12:24:09.271 pm info  Received event from ZeeRadioUpper/KidsRoom Fan Module: [status, off null]
app:3 2019-11-13 12:24:09.183 pm info  Received event from ZeeRadioUpper/KidsRoom Fan Module: [switch, off null]
app:3 2019-11-13 12:24:08.252 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [humidity, 42 %]
app:3 2019-11-13 12:24:07.624 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [lastUpdate, 13-Nov-2019 12:24 PM null]
app:3 2019-11-13 12:24:07.601 pm info  Received event from ZeeRadioUpper/MultiSensor6X (Kids): [temperature, 74.1 °F]
app:3 2019-11-13 12:24:05.275 pm trace Received ping from ZeeRadioUpper.
app:3 2019-11-13 12:23:07.810 pm info  Subscribing to device events..
app:3 2019-11-13 12:23:07.808 pm info  HubConnect Server Instance Initialized
app:3 2019-11-13 12:23:07.791 pm info  HubConnect Server Instance Updated with settings: [enableDebug:false, receiveHSM:false, pushModes:true, receiveModes:false, pushHSM:false, clientName:ZeeRadioUpper, clientIP:192.168.7.68, remoteType:local, localConnectionType:socket, genericMotions:[TestMotion]]
app:3 2019-11-13 12:23:04.111 pm info  Setting event communication status from remote hub: [status: false]

Although I have some follow on.

For your first Remote Client screen cap, I have the following logs:

app:837 2019-11-13 04:17:00.064 pm debug Received mode event from server: Evening
app:837 2019-11-13 03:06:12.754 pm info  Received command from server: ["Hallway Dimmer": off]
app:837 2019-11-13 03:00:05.998 pm info  Received command from server: ["Hallway Dimmer": off]
app:837 2019-11-13 01:45:12.129 pm info  Received command from server: ["Hallway Dimmer": off]
app:837 2019-11-13 01:37:32.466 pm info  Received command from server: ["Hallway Dimmer": off]
app:837 2019-11-13 01:17:07.267 pm info  Received command from server: ["PoolTable Ceiling Fan": setSpeed]
app:837 2019-11-13 12:23:07.359 pm info  Skipping event subscriptions...  Using event socket to send events to server.
app:837 2019-11-13 12:23:07.285 pm info  HubConnect Remote Client Initialized
app:837 2019-11-13 12:23:07.275 pm info  HubConnect Remote Client Updated
app:837 2019-11-13 12:23:03.161 pm info  Received setCommStatus command from server: disabled false]

What we see is that each 'end' of a HubConnect connection describes Events it's receiving, not what it sends.

Combined, there's a round trip shown. A Remote puts an Event into the Event Socket.. that's a platform level stream... HubConnect on the Remote is completely oblivious. The Server, which is listening to the Event Socket, sees the Event and logs that. HubConnect then injects the Event into the Server hub, which is sent (as an acknowledgment) to the Remote, which sees the Event and logs it.

For connections using http (oAuth) then HubConnect must facilitate the platform feature of Event Socket and Send each event. In general, "Sending event to..." logs are for http (oAuth) traffic.

When you put the Driver source on the Server, did you delete each of the virtual devices and recreate them?

When you recreate them, you should see it in the logs:

dev:866 2019-11-13 05:20:43.132 pm info  Switching connection to ZeeRadioFourth to socket
dev:866 2019-11-13 05:20:42.965 pm trace Initialize virtual Hub device...
dev:866 2019-11-13 05:20:42.886 pm trace Initialize virtual Hub device...
app:581 2019-11-13 05:20:42.763 pm trace Creating hub Device ZeeRadioFourth... hub-192.168.7.65...
app:581 2019-11-13 05:20:42.718 pm info  Subscribing to device events..
app:581 2019-11-13 05:20:42.715 pm info  HubConnect Server Instance Initialized
app:581 2019-11-13 05:20:42.704 pm info  HubConnect Server Instance Updated with settings: [enableDebug:true, receiveHSM:false, pushModes:false, receiveModes:false, pushHSM:false, clientName:ZeeRadioFourth, clientIP:192.168.7.65, remoteType:local, localConnectionType:socket, updateDeviceIPs:false]

Bago · November 14, 2019, 2:11am

Thanks for your help!

Yes, I did delete everything. Events are not logged back to the server. This is an error that pops up when I press sync:

srwhite · November 14, 2019, 2:41am

Is sync failing on all devices, a particular driver, or particular device?

I see it's sending the events properly.. "Sending event to Home 1E.. Ambient Weather"
The heartbeat also appears to be working fine as I see pings.

Did you go into the server and enable the master debug switch? Even with a websocket there will be debugging data. Please make sure debug output is on for all hubs.

I'm kind of leaning towards a communication issue. Are all hubs on the same local lan?

Bago · November 14, 2019, 3:06am

Yes, it is failing on all devices (different drivers).

This works from server to remote, but the reverse does not work.

All hubs are on the same LAN, and the same switch.

The weird part, from my perspective, is the device I'm triggering never shows in the logs for HubConnect. One other thing I noticed is that when I only selected one switch in the remote app, the app acted as if I had no devices selected, but once I selected a sensor, then it showed that I had devices selected.

zenblom · November 14, 2019, 1:23pm

I had problems when I was trying to get this to work with my ST hub a while ago which probably only affects a small subset of devices and people.

It turns out that the URLEncoder isn't that great at handling our Swedish characters (ÅÄÖåäö) and then messes up the URL.

Did an EXTREMELY dirty quickfix due to missing groovy apis which solved it for me

def realtimeEventHandler(evt)
{
    ...
    def data = URLEncoder.encode(JsonOutput.toJson(event).replace('\\u00c5','Å').replace('\\u00e5','å').replace('\\u00c4','Ä').replace('\\u00e4','ä').replace('\\u00d6','Ö').replace('\\u00f6','ö'), "UTF-8")
    ...
}

But this could potentially affect others with non standard characters in device names as well so it should be handled in a more correct way.

Bago · November 14, 2019, 1:45pm

One more thing, if I switch direction (by swapping the server and remote), the same problem exists. When the server pushes the changes, it works fine. When any remote pushes changes, they never post. The server can actuate a device shared by a remote, but not visa versa.

Thanks again for your help.

dsaintpaul21 · November 15, 2019, 7:08pm

Wondering if anyone has tried using the 'Sync' command via WebCoRE?
I get a groovy error anytime I try to execute that command in WebCoRE.

murzik · November 15, 2019, 10:05pm

I see error in log
2019-11-15 15:22:04.985 errorhttpGet() request failed with error 400
Any idea what is wrong?

csteele · November 15, 2019, 10:12pm

It's a timeout. The previous attempt failed. Obviously the next attempt worked. I would expect a few of those per day with ST or any "cloud" connection.

Just the one? Or every 3 mins?

murzik · November 15, 2019, 10:15pm

No, not every 3 minutes, less often...

Bago · November 15, 2019, 10:28pm

The only solution that I could find to fix the bi-directional problems with remote hubs (using remote client), was to share devices on remote hubs using the server functionality. Not the most efficient, but it works.

bfara83 · November 18, 2019, 2:05am

@srwhite

Is there anyway to update the Ring Doorbell stub driver to support button presses correctly on the way Hubitat implements support for button presses?

Here's how the button presses for the Ring Doorbell shows on Smartthings:

Smartthing uses Button instead of Pushed that Hubitat uses, not sure if there's a way to convert it so the value of pushed but equal Pushed value of 1 so we can use the correct capability for button presses on Hubitat. Is there a way for the driver to support converting this automatically?

I got this attribute to show so I can use it in RM by adding this so it can be used as a custom attribute and look for pushed for the value.

 attribute "button", "string"

/*
	button
    
    displays button events
*/
def button(value)
{
	// The server will update pushed status
	parent.sendDeviceEvent(device.deviceNetworkId, "button", [value])
}

Thanks

srwhite · November 19, 2019, 12:45am

Are you using websockets? I stumbled on a bug in 1.5 with the remote hub device. If you're using websockets can you post a screenshot of the virtual hub device? I want to see if it is connecting properly.

Bago · November 19, 2019, 1:00am

Yes, I am.