Getting this error trying to set RGB color on bulbs USING the color dialog box in the driver. Setting the individual HSL values works along with temperature.
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:94, saturation:85, level:94]]
Possible solutions: wait(), any(), trim(), size(), find(), dump() (sendDeviceEvent)
This is using the latest HubConnect RGB Bulb driver.
Otherwise I've worked out most of the bugs of this two hub setup.
A few more custom drivers I might need some help with
I'll need more info I guess, I'm not seeing the error:
on my 'server' using the HubConnect RGB Bulb driver, logs show:
app:33 2019-05-27 07:29:27.464 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [switch: on null]
app:65 2019-05-27 07:29:27.462 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [switch: on null]
app:3 2019-05-27 07:29:27.430 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [switch, on null]
app:3 2019-05-27 07:29:26.977 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [colorName, Orange Red null]
app:65 2019-05-27 07:29:26.959 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [RGB: [255, 77, 0] null]
app:33 2019-05-27 07:29:26.882 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [RGB: [255, 77, 0] null]
app:33 2019-05-27 07:29:26.845 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [color: #ff4d00 null]
app:65 2019-05-27 07:29:26.816 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [color: #ff4d00 null]
app:3 2019-05-27 07:29:26.798 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [RGB, [255, 77, 0] null]
app:65 2019-05-27 07:29:26.735 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [saturation: 100 null]
app:3 2019-05-27 07:29:26.733 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [color, #ff4d00 null]
app:33 2019-05-27 07:29:26.729 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [saturation: 100 null]
app:3 2019-05-27 07:29:26.669 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [saturation, 100 null]
app:33 2019-05-27 07:29:26.656 am debug Sending event to ZeeHomebridge: Hank RGBW LED Bulb [hue: 5 null]
app:65 2019-05-27 07:29:26.650 am debug Sending event to ZeeSmart: Hank RGBW LED Bulb [hue: 5 null]
app:3 2019-05-27 07:29:26.605 am info Received event from ZeeRadioUpper/Hank RGBW LED Bulb: [hue, 5 null]
On the hub with the physical device, using the native Hank RGBW LED Bulb driver, logs show:
dev:582 2019-05-27 07:29:27.393 am info Hank RGBW LED Bulb switch is on
dev:582 2019-05-27 07:29:26.839 am info Hank RGBW LED Bulb colorName is Orange Red
dev:582 2019-05-27 07:29:26.836 am info Hank RGBW LED Bulb RGB is [255, 77, 0]
dev:582 2019-05-27 07:29:26.829 am info Hank RGBW LED Bulb color is #ff4d00
dev:582 2019-05-27 07:29:26.826 am info Hank RGBW LED Bulb saturation is 100
dev:582 2019-05-27 07:29:26.786 am info Hank RGBW LED Bulb hue is 5
I clicked to get the color picker, picked a color and then clicked SetColor. The Hank driver seems to send "everything" according to the logs. Perhaps the driver you are using with the 'real/physical' device isn't?
I know you're seeing the error, this message is saying: I can't duplicate
that error was on the server and the client device driver for that bulb (Sengled) is "Generic ZigBee RGBW light modified" and the other bulbs are "AEON LED Bulb" I need to test with scenes to see if it really matters. I'll do that soon.
Also, one more small problem.. I've had my client hub lockup now twice. I have a LOT of things disabled on it...so I don't know if that causes a problem and I should just delete stuff but my first thought was just to disable in case I run into a problem. However all that's left on that hub is my zwave and zigbee devices along with Hubconnect remote client. The only other apps in total are: Mode Manager (I think I might be able to disable this), Other Hub event pusher (for my ST hub, haven't put hubconnect on it yet), and Rule Machine.
This used to be my main hub and the new one is now my "server" or "controller". The controller hub has not locked up and I have not had any issues with it. The only thing really left to do is disable hubconnect, but then really pretty much the whole house won't function. I haven't looked deeply into the logs to see what's going on yet. Was away today and came home to it locked up. This was the 2nd time.
I have 5 "Hubs" -- One Hubitat Hub is 'server/coordinator' Two more are my radio enabled hubs, one upstairs, one down. Outside of that is a Homebridge "Hub" (running on a Mac Mini) and of course SmartThings Hub. SmartThings is not doing anything but sitting there waiting for me to test something. It has nothing to do with my day-to-day, but every few days I poke a button just to make sure it's all alive.
So far, I've never had a crash. I think we've had 3 HotFixes in 2 days and I've installed them... therefore I have very small uptimes. Is it a factor? No way to tell but I'm certainly able to see how it could be.
Not shown on both is Zwave Poller. ABC is the button (pico) controller.
'coordinator' is certainly doing what I intended with more apps... and just yesterday I removed pushover from both radio hubs, it's only on 'coordinator now'
@dan.t and @csteele
are valves supported for homebridge? I can select it, but I can’t seem to get it to pop up. I haven’t seen anything strange in the logs on hubitat or my server. and after I select a valve in the list, hubconnect does NOT suggest that my homebridge hub needs a driver for a valve - it suggests that it needs drivers for everything else though.
I know, which is why I thought it was weird that it wasn’t listed in the recommended drivers. I wasn’t sure if the two homebridge apps were fully at parity yet.
They are completely on par when it comes to attributes. Just ordered my fourth hub and in the middle of migrating things but I will try tomorrow to add a virtual valve to test it out... it should work just by looking at the code
So I am still stuck understanding this... How does just changing the stub driver make the sending side know to send the new events over?
Ah wait... Are you using the eventsocket connection method, or the original subscription model between the hubs?
I can see how this may work if using the eventsocket method (as all events are coming over whether you ask them to or not), but I don't think just changing the stub driver would work at all in getting attributes over to the virtual device when using the subscription method...
This release fixes three critical issues that were reported in 1.4.1:
Missing Valve device support (regression)
Repetitive system errors generated in Hubitat logs during HubConnect http event processing when a virtual HubConnect device cannot be found on the remote system. (@chuck.schwer)
Additional filtering to fix possible race condition when bi-directional HSM changes are enabled. This was caused by HSM generating duplicate events on calls to setLocationMode() causing events to bounce continuously between server and remote hubs.
Files Changed:
Server Instance
Remote Client (Hubitat & SmartThings)
As always, I employ a team of blind sloths to write my code so please report any issues that are encountered!
For those using the homebridge-hubitat-hubconnect plugin, there is a new corresponding version available that addresses a shortcoming with the valves, a small fix around turning fans on/off and a change in the interaction with HubConnect when sending commands to control a device. So, if you use homebridge and update to HubConnect 1.4 HotFix 2, don't forget to update your homebridge plugin too!
A couple of times (including today) I managed to screw up the communications between hubs and couldn't figure out any way to fix it other than deleting the connection and re-making it.
When one does that, it orphans all of the stub devices that previously were communicating between the hubs.
Is there any way to KEEP the old stub devices and get communication going again after the connection is re-built?
It is a HUGE pain to have to delete the old stub devices, re-add them to HubConnect (thus getting the stub devices rebuilt automatically), and then manually rebuild every RM the devices were in (which is quite a few in my install).
Second issue... I have a dimmer device type going from hub 1 to hub 2.
Changes made on hub 1 show up on hub 2 as expected.
Changes made on hub 2 (the stub driver device) do not get made on the physical device. I see an event on the hub 1 that says: app:10022019-05-28 05:51:10.694 pm infoReceived command from server: ["Music Room Smart Vent": setLevel]
But the level most certainly did not change....
SWITCH on/off events do make it from Hub 2 back to Hub 1, but dimmer setLevel do not.
EDIT: It may be because this is really a vent, and not a bulb... The stub driver forces duration=1, and I'm not sure the smart vent driver has a function for level + duration... Not sure, since it is using an in-box driver.
EDIT 2: Yes, that is the issue. Even on the physical device if I do level + duration it does nothing/rejects it. I guess I'll have to make a custom stub driver.
EDIT 3: Side note, WHY does the dimmer stub driver for duration to 1, anyway? Why not just pass through the duration specified?
I haven't looked deeply into the logs to see what's going on yet. Was away today and came home to it locked up. This was the 2nd time.
