I have been using the Generic Z-Wave Valve driver.
I have had issues when I reboot hubs and losing the reporting from the hub the device is connected to and the coordinator (main) hub. I have found that if I go into devices in my main hub and find the device for the remote hub, click off, then click on, and sometimes the initialize button, all communication is good again.
Yeah, I forgot to do that. I pushed the update between meetings, ran out of time, and of course completely forgot before I had another free minute. It has been updated.
I believe I’ve “complemented” your git skills a few times. 
If that happens when using the Eventsoket connection, clicking initialize should be sufficient.
2 Likes
Did some more testing on my RGBW problem. Still getting this error:
groovy.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:814, setColor, [hue:10, saturation:100, level:100]]
Possible solutions: wait(), any(), trim(), size(), find(), dump() (sendDeviceEvent)
Using built in "Generic Zigbee RGBW light" driver on hub that is connected to device. Using HubConnect RGB bulb driver on server.
From the device page on the server I can input Hue, level, Saturation values and it all works. If I use the "Set Color" dialog I get the above errors in the server log. Also If I create a scene and capture that bulb on the server. Then try to set that scene. I get the same error above in the server log.
I don't have a Zigbee bulb, color or not. I do have several ZWave RGBW devices. Aeon Bulbs, Hank bulb, Qubino and Fibaro RGBW controllers for LED strips.
I pasted the Hank results last time, I just tried it with the Aeon driver.. both builtin.
Unable to duplicate. I'll check Hubitat's driver attributes to see if they present differently.
Glad to send you a zigbee Sengled bulb if you would like 
EDIT: Getting the exact same message with my AEON zwave bulb:
groovy.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:-3, saturation:91, level:95]]
Possible solutions: wait(), any(), trim(), size(), find(), dump() (sendDeviceEvent)
possible because I'm using http method?
using build in AEON LED bulb driver
I switched one of my hubs to use http (oAuth) no change for me. Logs show no errors.
That shouldn't have any impact. All commands are handled via http actually.
I see why you're getting an error... Hue is somehow being set to negative 3 (-3). That's not a valid Hue value. Hue values must be 0-100. Need to figure out where that negative value is coming from.
Device Selector
capability.colorControl
Commands
setColor(colormap)
colormap required (COLOR_MAP) - Color map settings [hue*:(0 to 100), saturation*:(0 to 100), level:(0 to 100)]
setHue(hue)
hue required (NUMBER) - Color Hue (0 to 100)
Well that stands out like a sore thumb... once you point it out!! 
1 Like
So clicked around in that color picker to make sure there were no - values:
groovy.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:2, saturation:91, level:95]]
Possible solutions: wait(), any(), trim(), size(), find(), dump() (sendDeviceEvent)
Also was able to go back to event sockets (all seems to be working) still getting the above even without the - value
that's what I'm doing
me too.. in fact I picked darn near the same color! The bulb in my living room is still that color, forgot to turn it off.
Confirmed, it does the same thing when trying to change the color in RM3.0
groovy.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:814, setColor, [hue:35, saturation:100, level:99]]
So the only thing I've confirmed that works for me is setting the Hue,Saturation or Level directly from the device page on the server. Anything else that tries to set it throws the error.
Am I seriously the only one? 
lol, figures...
Need some advice. @csteele will probably know...
I have 3 hubs
A - no radio, coordinator/user code/lan driver hub (HubConnect Remote Server installed)
B - C4 zigbee + zwave (HubConnect Remote Client installed)
C - C5 zigbee + zwave (HubConnect Remote Client installed)
So far I've been replicating devices from:
B --> A
C --> A
A --> B
I really need to get a few devices from B --> C, though.
Is there a way to do that directly, or would I need to go B --> A and then A --> C?
I'm doing pretty much what you want to do: a device on B (SmartThings) getting shared to A (Hubitat Coordinator) and then to C (Hubitat ZHA), where A is the server.
However, I just added a fourth hub (no, I don't have a problem...really, I'm just trying out that thing where you use another hub instead of a Hue Bridge) and am thinking about ways I could make C talk to D directly without needing to go through A. My concern is that everything where I care about speed is kept away from Hub A (which does have Z-Wave but also has most of my custom code; hub C has my ZHA devices, most importantly motion sensors I use for lighting--so making things from C to D, which would now be my bulbs, go through A first, where possibly "naughty" apps or chatty Z-Wave devices live, would not be conducive to that goal). Can the same hub run both the client and server apps? 
That's the way to do it. HubConnect is not a Mesh builder. It is exactly what I do.
I have all my Zigbee devices on a single hub and some of those would more correctly be paired with the other hub... so the Iris motion sensors are 'real' on C and need to be used in Rules on B. So they go C --> A --> B
Amazingly fast.
Yup, I set it up that way right after posting, as I needed to get things back to 'working'.
B --> A then A --> C works just fine. And as you say, it is very fast.
It occurs to me, after posting, I did put the Remote-Client on SmartThings twice. That allowed me to use my 4th hub as a Server.
A - no radio, coordinator/user code/lan driver hub (HubConnect Server installed)
B - C4 zwave (HubConnect Remote Client installed)
C - C4 zigbee + zwave (HubConnect Remote Client installed)
D - SmartThings (HubConnect Remote Client installed twice)
E - C5 zigbee + zwave (HubConnect Server installed)
B --> A
C --> A
D --> A
A --> B
A --> D
E --> D
Two Server hubs. One server is connected to all the Remotes. The second hub (development) is only connected to SmartThings.
Not mentioned above are the Homebridge instances... F & G
2 Likes
You have a sickness. 
Just a few days ago I split my primary Homebridge (Mac Mini) into two instances. It was pretty much just an exercise in order to answer some questions here...
But I have left it that way. Now the Homebridge Instances are 'pure' in the sense of what were two platforms in Homebridge's config.json, there's now only one platform per instance. That was done to remind myself that the HomeKit limit on devices per Accessory can be overcome via multiple Homebridge instances.
Another dopey question...
Can you initiate mode changes from multiple hubs and have it go to other hubs? Example:
- Hub A changes mode to Home, send that to Hub B (I have that today, works fine)
- Rule on Hub B changes mode to away (based on presence, or whatever), update mode on Hub A.
Is the second part possible, or will 'bad things happen' since it is making a loop, of sorts?
It let me set it up that way on the server, so we'll see I guess. 
