New Homebridge Plug-in via MakerAPI

@dan.t I have updated to the latest release and firmware and am getting more frequent errors:
java.lang.NumberFormatException: null on line 626 (listDevices)

Do you know how to solve this or should I pursue opening a support ticket? Patrick had mentioned a long while ago that it may be querying for a value that is null thus throwing the error but unsure how to even determine which device out of the many would cause this. I cannot reproduce this by just using the Get All Devices or Get All Devices with Full Details URLs so unsure what additional Homebridge may be calling.

The MakerAPI logging is not really helpful. I wish it would at least spit out the request URL that failed or the device ID it failed on....
Do you see any errors or warnings in the Homebridge logs? That could give us an indication which device is causing it

I'm getting the same error

java.lang.NumberFormatException

Hey all, I managed to link the MakerAPI with Homebridge (running via Hoobs on a pi4) and have gotten devices to show up. However, my Lutron pico remote shows up as a 1 button device in homekit. Any ideas why that would be or how I could modify the behavior?

Edit: Upon further testing, any of the 5 buttons registers as the same button press in homekit. Double press and long press also don't work.

That is a HomeKit limitation. HomeKit doesn’t support buttons per se, as a workaround, the plugin exposes a button device as a switch, however, it is limited to one button only

Oh I see, thanks for the quick reply. Was hoping to use homebridge to bring the picos to homekit natively but I guess no dice. Rats.

It’s not only the number of buttons.. Picos are great and they support the “push”, “held” and “released”. There is nothing like that in HomeKit, so even if you had all buttons, you would still be limited....

It much more flexible to setup the Pico in HE and map the button function to a virtual switch you expose to HomeKit via Homebridge. Then map the virtual switch to a HomeKit device via HomeKit automations.

It sounds slow, but it really isn’t bad. However you do need the Lutron Caséta Pro Bridge to get the Picos into HE. Worth the investment though. Picos are great button controllers, versatile, inexpensive and have 10 year battery life.

Ooh now this I'll have to try. If you think there's not much lag I'll try this out. Thanks, very helpful.

About 1 sec typically for me. Everything local is pretty much instant. This is the slowest of my local device setups.

Thanks for that hint as I hadn't checked the logs on my docker container. I did find this:
[1/16/2020, 1:01:36 PM] [Hubitat MakerAPI hhm:0.4.10] GET ERROR: { path: '/devices/354', method: 'GET' } IncomingMessage {...}

I looked at device 354 and it was an AV receiver that I removed from MakerAPI to see if that solves it. Honestly not sure why I added that device to Maker in the first place. But the above error was pretty consistent and I would see it in the log every 5 minutes and this error seems to have tapered off since removing this device from the MakerAPI app's device selection. But Patrick had mentioned this error was caused by the fact that some state was NULL that MakerAPI was expecting to be populated.

@dan.t thank you for your continued support in this Community!

@DaisyLee I would suggest you telnet into your homebridge "server" and look at the "homebridge-hubitat.log" and search for "GET ERROR" as you may also have many of these that correlate with the error timings in your logs. Removing that device may solve it.

Removing that device may solve it.

On the money my friend. I had apparently checked a device that I didn't mean to.

Now I need to figure out what is going on with the lights. Cause the little color shortcuts "wig out" on the bulbs I have from HE but not from official Homekit bulbs.

@dan.t have you ever seen that? I'll upload a video to youtube here shortly to show you what I mean.

Video: https://youtu.be/lk7aUn3lneU

2 Likes

@dan.t Hey. I posted a comment on your Github but it doesn't look like you have been really active over there. So I figured I would reach out to here as well. Does your plugin check on start to see if the list of devices it has access to through the makerapi has changed? Like if a device is removed from the maker api, does your plugin remove the accessory from the cached accessory database? Or is there some way to manually trigger that update to occur?

Hey Jacob, yes it does. It does this on start and by default every 5 minutes. No need to restart Homebridge. You can add/remove devices and they will automatically be added/removed from Homebridge

Oh awesome. Thanks for the response.

@DaisyLee, I can reproduce that and I am going to take look what is happening here

1 Like

I’ve always had trouble with trying to control CT or color bulbs integrated through Homebridge. I figured it was something that I would have to deal with and just use Dashboard for adjusting CT or color 🤦🏼

Awesome! You are too cool man.

If there is anything you need from me let me know.

Hey, are you sure that this doesn't happen with the native HomeKit integration? I just added my Hue Bridge directly to HomeKit, and I do see the same result..... Meaning it might not be Homebridge issue... What type of bulbs are you using?

Here is what I have found so far: I do think that there is an issue in HomeKit. When the wig out color changes, HomeKit sends a "set Color Temperature" command instead of a "set Hue and Saturation" command. That in turn changes the wig out color. Every once in a while Homekit sends the right command and the wig out color doesn't change.

EDIT: I take it all back, was playing with the wrong bulb.... I keep looking

@dan.t @DaisyLee

I am experiencing the same here with a new Zigbee Generic RGBW bulb. Every time I tap a color it just overwrites it with the same color.