@mike.maxwell So could this be the encryption that is causing this? Any way I can setup testing to determine this?
Sure just turn encryption off on the lock.
Data encrypted on one hub cannot be decrypted on a different hub.
Yes that is true.
@mike.maxwell So this could be a Schlage problem then and the lock driver needs to return back something so that lock manager doesn't bomb?
To clarify. LCM reads the lock codes from the lockCode attribute in the driver it does not read them directly from the lock, that is the drivers job
Lock Code Attribute on HubConnect (server) looks like:
app:33 2019-07-07 03:13:14.190 pm debug Sending event to ZeeHomebridge: Yale DoorLock [lockCodes: {"1":{"name":"Wife","code":"13579"}} null]
Do you see malformed?? (the Null is 'units' aka 'kg' :: n/a for a lock)
Ok, so removing the encryption fixes the issue with lock manager. I do wish encryption would work between the hubs but ill live with this.
HubConnect acquires the attributes from the "real/physical" driver via Event Socket or http (cloud).. but both are after the driver has converted Z-radio into Attributes.
My Yale is securely connected too, but (obviously) I don't see 'malformed' data.
I was showing encrypted strings in the hubConnect device driver and they were not malformed but as @mike.maxwell said the other Hub cannot decrypt the codes so Lock manager failed. Now that the Codes are not encrypted in the original lock device driver the Remote Lock Manager can now read all the information. Works great. Thank you to everyone that got involved and helped to correct this issue.
Ohhhh..
That toggle.. [sigh] been so long since I looked AT my real lock Device page... I forgot all about that option.
Good to get that documented.. although I imagine Lock Code Manager might want to use a different error message than "crash" 
1 Like
Any chances of an A/V Receiver driver that would give us the same options as the original driver? For example the "Denon AVR" driver has input selection, volume up/down, mute/unmute, etc but in order for the device to show up on the coordinator it's just an on/off switch.
Sure... just one tiny problem... I don't have one.. can't test. 
I've created a Universal Driver and 'log surfing' I can see the data/commands comes and goes TO a Virtual Denon AVR (built in) driver FROM a Universal Driver. I also updated Server Instance and Remote Client to allow for selection.
But without a responding device, I can't truly test.
[ in a lot of these circumstances previously, I create my own virtual driver, but that presupposes I know what the device is supposed to do. I could take a rPi and have it be the IP address of a fake AVR, but I don't know what responses to give for login, etc. ]
@damon.dinsmore mine works now too. I've been struggling for more than a week on my migration and I want it to be as complete as possible. Twikset lock works too.
Any ideas? No answer yet. Thanks
hah, yeah I can see where not having one would be an issue.
I'd be willing to test anything you could come up with.
Please post a screen shot of the hub connect thermostat current states. GH will not accept them if one or more of the standard thermostat attributes are null.
Getting this error when trying to change the color for an RGB light. It's doing this on ALL my RBG lights (Phillips, sylvania, aeon, sengled etc)
app:342019-07-08 10:44:45.115 am errorgroovy.lang.MissingMethodException: No signature of method: java.lang.String.call() is applicable for argument types: (java.lang.String, java.lang.String, java.util.LinkedHashMap) values: [192.168.13.46:106, setColor, [hue:1, saturation:100, level:99]] Possible solutions: wait(), any(), trim(), size(), find(), dump() (sendDeviceEvent)
That app is the server instance. Command never makes it to the client.
It only does this when trying to send the full HSL map. Hue, Sat, Level work fine independently. Scene's give same error as above. Happy to do any troubleshooting. Evrrything else is working great.
please re-import the rgb driver to your 'server hub'
