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

storageanarchy · October 3, 2019, 3:25pm

I am getting the same error, except @line 1164 in the latest code on GitHub.

That line is erroneously trying to add null?.size() values because genericMotions, irisV3Motions and domeMotions are all null lists, and you can't add null+null+null:

		section("-= Select Motion Sensors (${genericMotions?.size() + irisV3Motions?.size() + domeMotions?.size() ?: "0"} connected) =-")

The fix is to replace that line with:

		section("-= Select Motion Sensors (${((genericMotions?.size() ?: 0) + (irisV3Motions?.size() ?: 0) + (domeMotions?.size() ?: 0)) ?: "0"} connected) =-")

csteele · October 3, 2019, 3:55pm

github updated. Thanks!!

storageanarchy · October 3, 2019, 4:20pm

Thanks for the fix!

Here's another for you, also in HubConnect-Remote-Client.groovy in remoteDeviceCommand() in both Hubitat and SmartThings versions...

Current:

	if (!device)
	{
		log.error "Could not locate a device with an id of ${device.deviceId}"
		return jsonResponse([status: "error"])
	}

The problem is that if device == null, then the log.error will throw an error because there's no such thing as null.deviceId.

I'm still trying to figure out why I'm getting here in the first place...

csteele · October 3, 2019, 4:50pm

The code is fractionally different.. ST has:
if (!device)

while the Hubitat instance has:
if (device == null)

Therefore, neither should "work" -- but their "job" is to throw an error message and they are indeed doing that

storageanarchy · October 3, 2019, 5:05pm

Yes, but they throw an error message and then stop execution, so the return jsonResponse(...) is never called.

There is an occurrence in the HubConnect Server Instance as well...

csteele · October 3, 2019, 5:21pm

yea, it's 4 month old and I was trying to be humorous about THAT.

I'm also wondering how to get there.. so I can test some fixes.

jrfarrar · October 3, 2019, 5:24pm

@csteele I'm a bit confused on what I might be doing wrong or what else I can look into to make this work.

The remote hub (which has the actual zigbee lock attached) shows the correct entries in the log for a user unlocking the door. The server hub which has the hubconnect driver and is getting information from remote is showing the correct logs. Or so I think. here is an example from the events for the stub device:

However I just created a simple rule:

and it never get triggered to run at all on the unlock code.

I'm assuming this would work just like it would if I were to create the rule on the hub that is actually connected to the device? Or is there a different way?

Sorry and thanks.

csteele · October 3, 2019, 5:27pm

I have begun a conversation with Staff on this. The Attribute is new, as you know, and although it's making it from "real Lock" to "virtual Lock", it's not visible to RM.

I've tested the Rule on the hub with a "Real Lock" and it does work, so yes, there's probably a workaround.

jrfarrar · October 3, 2019, 5:30pm

Thanks for the update!

jrfarrar · October 3, 2019, 5:35pm

Ok your last message about "attribute" got me to thinking....so I tried something:

and it worked! It even worked when the same code as the previous code was entered again. So I'd at least call that a workaround.

EDIT: So that the above rule is clear. I used Custom Attribute as the trigger. Choose "LastCodeName" from the list for that lock and the condition of "Changed"

storageanarchy · October 3, 2019, 5:48pm

@csteele -

Curious: is there any chance of you implementing "delete device" in the Remote Client and Server Instance, such that "remote"/"slave" devices that were once linked but are no longer linked are actually deleted?

The problem is that if the hubConnect devices are left around (at least on SmartThings, and probably on HE too), they will continue to make command calls into their parent, which will result in commands being sent to (possibly nonexistent) devices on the other end of the link.

Also, any lingering children will also inhibit (again, on ST) being able to remove the HubConnect Remote Client instance, at least until all its' children are deleted...

csteele · October 3, 2019, 6:31pm

I'll add it to the list. but before Steve @srwhite left for wherever it is he goes he hinted at some v1.5 items he was working on. I'd like to give him just a bit more time to be done camping before I step all over his code.

But that's mostly about Release.. I'll see if I can implement, or what percentage I can implement, ready to be merged back into Steve's code. Or, said another way.. Steve writes code about 10x my speed and it's embarrassingly better. You want HIS code.

csteele · October 3, 2019, 7:21pm

@jrfarrar
Agreed.. using a Custom Attribute works!

It's a great clue I imagine.

app:549 2019-10-03 12:16:31.029 pm info  Wife unlocked Yale DoorLock
app:33  2019-10-03 12:16:30.911 pm debug Sending event to ZeeHomebridge: Yale DoorLock [lock: unlocked null]
app:2   2019-10-03 12:16:30.798 pm info  Received event from ZeeRadioLower/Yale DoorLock: [lock, unlocked null]
app:2   2019-10-03 12:16:30.767 pm info  Received event from ZeeRadioLower/Yale DoorLock: [lastCodeName, Wife null]

App:549 is my Rule that mimics yours.

It's a usable workaround, in my opinion (unlike my opinion of the failing log.error - which was supposed to be funny, not an actual opinion )

storageanarchy · October 3, 2019, 8:22pm

Two questions:

Is it possible to define a Custom Device to be sent from an HE-based Remote Client to the (HE-based) Server Instance?
If so, is it then possible to define said Custom Device to be sent/linked from the Server to a different (ST-based) Remote Client?

I have a custom EcoNet Vent driver running on my "slave" HE hubs that I would like to link into my ST "slave" hub. I can define the custom driver on the HubConnect Server, but I can't see any way to define its use from a device running on a HubConnect Remote Client.

TIA!!!

csteele · October 3, 2019, 8:29pm

Custom Drivers are managed on HubConnect server but then are distributed to all connected Hubs. Your "real device" can be on any hub and then 'mirrored" to the interconnected hub.

Custom Devices are in the device selection section of ST HubConnect Remote Client. I have one Custom Device at this time and it shows as an available selector on ST, but for me, I haven't mirrored it over. (It's my test device for the Global Variable Connector driver.)

storageanarchy · October 3, 2019, 9:41pm

When/how do they get copied over to the Remotes? Perhaps I've done something wrong...

I've created the Custom Device on my master, but on all 3 of my Remote Clients I get a hard error when I select "Select devices to synchronize..." and then "Custom devices".

The error is:

Unexpected Error

An unexpected error has occurred trying to load the app. Check Logs for more information.

There is nothing relevant in the logs...

csteele · October 3, 2019, 10:54pm

I just redid a very simple one...

Again, it's a Global Variable Connector device... so a virtual device already

I gave it a random name, then picked an already existing HubConnect Stub driver (OmniPurpose) that had the attribute I wanted: temperatureMeasurement and then made that the 1st and only Attribute.

Scrolled to the bottom and clicked Save. It goes back to allow you to create another.

Logs show:

app:1 2019-10-03 03:44:19.519 pm debug Saving custom driver map: [tempGV:[driver:HubConnect Omnipurpose Sensor, selector:2C4FDBBB9B4A772A_temperatureMeasurement, attr:[temperature]]]
app:1 2019-10-03 03:44:17.994 pm debug [tempGV:[driver:HubConnect Omnipurpose Sensor, selector:2C4FDBBB9B4A772A_temperatureMeasurement, attr:[temperature]]]

And on one of my other 4 hubs:
55%20PM

It's there.
ST has it too.. but it looks exactly the same, so it's not solid proof.. like if it had a different name.

storageanarchy · October 4, 2019, 11:39am

OK, so I tried the same thing using a slightly modified version of the HubConnect Dimmer driver (I only added Refresh() capability/command plus Open() and Close() commands):

And the logs show:

[app:35](http://192.168.1.77/logs#app35)2019-10-04 07:23:44.725 am [debug](http://192.168.1.77/installedapp/configure/35)Saving custom driver map: [EcoVent:[driver:HubConnect EcoVent, selector:CBC731117C74ECF1_switchLevel, attr:[level]]]
[app:35](http://192.168.1.77/logs#app35)2019-10-04 07:23:43.542 am [debug](http://192.168.1.77/installedapp/configure/35)[EcoVent:[driver:HubConnect EcoVent, selector:CBC731117C74ECF1_switchLevel, attr:[level]]]

But when I try to open Custom Devices on any of my 4 other hubs, I get:

This happens whether or not I have installed a copy of the HubConnect EcoVent driver on the Remote Client hubs. And again, there are no new entries in the logs on either the Server or Remote Client hubs...

Tony · October 4, 2019, 3:41pm

I see that SpeechSynthesis was removed from the ST HubConnect Remote Client 'native devices' section in the post HF3 versions. I had managed to hack the SpeechSynthesis universal driver to enable HE to use a Speak command to activate my Aeotec Doorbell on SmartThings; this worked well (amazingly so since my hacking skills are nonexistent). However, it stopped working with hotfix 4 & 5. Is there a recommended way of accomplishing the same thing with the current Remote Client versions?

csteele · October 4, 2019, 5:01pm

Released SmartThings Remote Client - HF6

@Tony restore SpeechSynthesis, Audio and MobileApp dropped at HF3.
@storageanarchy Null exception corrected