That’s awesome!
Sounds like with the extra buttons, location modes and hsm the next release will check off all my needs and let me move all automations to HA and use HE only for a zwave/zigbee controller.
It amazes me how the ones I’ve already moved over are noticeably faster than when using built-in HE apps like RM.
First and most: Thank you @jason0x43 for all your fantastic work on this!
I only use it for the z-wave devices. Zigbee is on deconz and all automations are coming along in YAML.
For the ones who are intersted, I’ve tried the new HA Z-wave pre release QT-ozwdaemon yesterday and it is fast! really fast. But, my aeotec siren 6 with chime did not appear in HA so I had to go with the HE route for it.
In this integration I have still two thingies (not really dealbreakers).
Logger: homeassistant.components.switch
Source: helpers/entity_platform.py:435
Integration: Switch (documentation, issues)
First occurred: 12:40:57 PM (1 occurrences)
Last logged: 12:40:57 PM
Entity id already exists - ignoring: switch.begane_kelderkast_sirene. Platform hubitat does not generate unique IDs
New update works great! Getting all 11 buttons from my Inovelli switches now and moved all of my lighting automation into node-red. Thanks!
Hmmm… (1) implies that two switch entities were created for the same device. A switch entity’s unique ID is <hubitat IP>::<Maker app ID>::<device ID>. Does your device have two switches, by chance?
For (2), HA will update whenever HE sends an event. As far as I’ve observed, HE sends events whenever a device’s state changes, so if the device’s state in HE is updating for 1 LUX changes, those changes should be getting sent to HA.
Are the sensors running in batteries? When that’s the case, illuminance updates won’t be sent immediately even if a change crosses the notification threshold. For example, I have an Aeotec TriSensor that’s set to report 10 LUX changes. By default, the sensor will report the light level every 15 minutes or so. However, if a change crosses the notification threshold, the sensor will report sooner (at most every 3 minutes), but not immediately.
Has anybody tested RGB bulb color changes with this?
Trying to automate a color changing bulb to go Magenta at a certain time and Green at another time. When the color change is sent, the bulb flashes the proper color but then changes to a completely random color. I’ve tried using color_name, rgb_color and hs_color and it’s always the same random result.
When setting Magenta it will go Magenta for 1s, then change to red, sometimes blue, yellow, cyan. It seems random. On the HE side, I enabled descriptive and debug logging and it seems to be receiving multiple commands for color changes.
dev:3692020-05-10 09:09:38.944 pm infoLiving Room Fan Bulb 1 color is Cyan
dev:3692020-05-10 09:09:38.909 pm debugcolors: [0, 255, 0]
dev:3692020-05-10 09:09:38.892 pm infoLiving Room Fan Bulb 1 hue is 50
dev:3692020-05-10 09:09:38.872 pm debuggot SwitchColorReport: SwitchColorReport(colorComponent:red, colorComponentId:2, value:0)
dev:3692020-05-10 09:09:38.861 pm debugcolors: [0, 255, 255]
dev:3692020-05-10 09:09:38.841 pm debugparse:zw device: 35, command: 3304, payload: 02 00 , isMulticast: false
dev:3692020-05-10 09:09:38.826 pm debuggot SwitchColorReport: SwitchColorReport(colorComponent:blue, colorComponentId:4, value:255)
dev:3692020-05-10 09:09:38.823 pm debugparse:zw device: 35, command: 3304, payload: 04 FF , isMulticast: false
dev:3692020-05-10 09:09:38.679 pm debugcolors: [0, 255, 0]
dev:3692020-05-10 09:09:38.635 pm debuggot SwitchColorReport: SwitchColorReport(colorComponent:red, colorComponentId:2, value:0)
dev:3692020-05-10 09:09:38.610 pm debugcolors: [5, 255, 0]
dev:3692020-05-10 09:09:38.607 pm debugparse:zw device: 35, command: 3304, payload: 02 00 , isMulticast: false
dev:3692020-05-10 09:09:38.578 pm debuggot SwitchColorReport: SwitchColorReport(colorComponent:green, colorComponentId:3, value:255)
dev:3692020-05-10 09:09:38.576 pm debugparse:zw device: 35, command: 3304, payload: 03 FF , isMulticast: false
dev:3692020-05-10 09:09:38.384 pm infoLiving Room Fan Bulb 1 hue is 33
dev:3692020-05-10 09:09:38.360 pm debugcolors: [5, 255, 0]
dev:3692020-05-10 09:09:38.250 pm debuggot SwitchColorReport: SwitchColorReport(colorComponent:coldWhite, colorComponentId:1, value:0)
dev:3692020-05-10 09:09:38.247 pm debugparse:zw device: 35, command: 3304, payload: 01 00 , isMulticast: false
dev:3692020-05-10 09:09:38.244 pm debugcolors: [5, 255, 0]
dev:3692020-05-10 09:09:38.220 pm debuggot SwitchColorReport: SwitchColorReport(colorComponent:warmWhite, colorComponentId:0, value:0)
dev:3692020-05-10 09:09:38.206 pm debugparse:zw device: 35, command: 3304, payload: 00 00 , isMulticast: false
dev:3692020-05-10 09:09:38.136 pm infoLiving Room Fan Bulb 1 color is Green
You can see here in the log within 1s it goes from green to warm white, cold white, green again, red, blue, red again and finally settles on cyan.
What does the log look like from the HA side?
I just published a pre-release that allows the hub IP to be updated via the integration’s options UI. To make that possible, the integration will migrate all the existing entity unique IDs (used internally, not the ones you normally deal with like sensor.office_door) to a new format that doesn’t involve the IP address. That shouldn’t be noticeable, but if it doesn’t work properly you’ll see a bunch of duplicate devices after updating. (So make a snapshot before updating!)
If anyone wants to install this version and verify that it works (at least that it doesn’t create duplicate devices), I’d be grateful. 
Here’s the event that I see on the HA side.
{
"event_type": "call_service",
"data": {
"domain": "light",
"service": "turn_on",
"service_data": {
"rgb_color": [
255,
0,
238
],
"entity_id": "light.living_room_fan_bulb_1"
}
},
"origin": "LOCAL",
"time_fired": "2020-05-11T11:58:14.633966+00:00",
"context": {
"id": "4bf6878cd3a4437db2e1b3d6d0ca1154",
"parent_id": null,
"user_id": "cc2dd759c1504b57ac6fb1bca1679d85"
}
}
Compared to the HE side
The first thing I notice is I’m sending 255,0,238 but 255,0,245 is what is initially received. Then it starts shuffling the colours around which is likely why I’m seeing the multiple colours.
Try turning on debug logging in HA for custom_components.hubitat and hubitatmaker and check what commands are being sent from HA. In at least one other case, someone with an Inovelli bulb was seeing similar behavior. We never did determine the exact cause, but HA wasn’t sending multiple commands, so it didn’t look like the integration was causing the issue.
In any case, I’d be interested to know what this integration is doing. If it’s stuck in some kind of unstable state where it’s sending a stream of commands to the light, well, that should be fixed. 
I threw the log up in the thread on github. I’m also not seeing multiple commands sent from the HA side.
I posted up the issue on the HE board as well, bcopeland who makes the drivers for these bulbs, is going to release a bandwidth constrained version later today so I’ll give that driver a shot when it’s out to see if it’s any better.
There’s a thread on the Inovelli board that’s got a log similar to what I’m seeing as well.
So I updated to the constrained bandwidth version and still seeing the same random colour. So I started doing some testing using MakerAPI and sending the commands manually.
curl http://IPADDRESS/apps/api/APP-ID/devices/DEVICE-ID/setHue/85?access_token=TOKEN
curl http://IPADDRESS/apps/api/APP-ID/devices/DEVICE-ID/setSaturation/100.0?access_token=TOKEN
What I’ve found, when sending each command individually, the device responds as it should. If I set the hue and then saturation I get a complete random colour. If I set the saturation and then the hue I get the proper colour.
Interesting. Do you still still see excessive updating in Hubitat, or is the issue now just the random color? What happens if you use setColor to change hue, sat, and brightness at the same time (/setColor/85,100.0,255?access_token=TOKEN)?
The integration currently sets the color in one of two ways: if all of hue, sat, and brightness are being changed, the integration uses setColor; if only hue and sat are being changed, the integration updates the hue and then the sat (setHue and then setSat).
If setColor works, it would be most efficient to always use that when updating the color. Otherwise we can try sending hue and sat in the other order, which hopefully won’t break some other bulb.
Yes, still see excessive updating in Hubitat. I believe it’s because the bulb uses transition to change from one color to the next and updates every step of the way.
setColor doesn’t work through MakerAPI as MakerAPI can’t accept the color map.
{“error”:true,“type”:“java.lang.Exception”,“message”:“An unexpected error occurred.”}
The only way is to send the individual commands.
My theory, and it’s just a theory, when the bulb receives the setHue command it starts its colour transition. Then it receives the setSaturation command before that transition is finished. The setSaturation command acts as a second setColor event and wherever that colour transition is when it receives the second command is the end colour of the bulb. The excessive updating is because the 2 commands are having a power struggle over which colour it should be, but ultimately the last issued command wins out. Again, just a theory. I’ve asked the driver creator for his input on the theory.
Ah, that makes sense.
Sounds plausible.
The Maker API actually does support setColor, but with a different syntax than I was using, and only as of a couple of weeks ago (so my existing code wouldn’t have worked even if I had the syntax right).
Their documentation is a bit…lacking. Does this work?
/setColor/%7B%22hue%22%3A85%2C%22saturation%22%3A100.0%2C%22level%22%3A255%7D?access_token=TOKEN
(That’s just a URL-encoded version of /setColor/{"hue":85,"saturation":100.0,"level":255}?access_token=TOKEN)
I was just coming back here to share this update, looks like you already found it 
It doesn’t seem to work though. I get a {“error”:true,“type”:“java.lang.Exception”,“message”:“An unexpected error occurred.”}. I’ll run some more troubleshooting on the HE side and let you know the final result.
With a virtual RGB bulb, this works for me:
curl 'http://10.0.1.99/apps/api/2269/devices/2178/setColor/%7B%22hue%22%3A85%2C%22saturation%22%3A90.0%2C%22level%22%3A255%7D?access_token=TOKEN'
Ignore me, I think I was sending it to the wrong device id when testing the new format. 
After a break from the pc I tried it again and it’s working and the bulb is keeping the right colour.
Great! Ok, so it sounds like the integration could use setColor by default, and could fall back to setting the saturation and hue individually (and in that order) if setColor isn’t supported (it’s pretty new).
Just out of curiosity, when you call setHue and setSaturation in the current order (the one that causes problems), but wait for the bulb to settle between the two calls (rather than making them in quick succession), does the bulb behave?
Yes. If I send a setHue wait a few seconds and then send the setSaturation the bulb behaves.
bcopeland said my theory was possible, Since setSaturation is viewed as a second setColor call, if the bulb is still in transition it could make things unpredictable. I would think it would also apply if the order is reversed, but in my case the Saturation is always at or near 100 so the transition time is very quick.
That makes sense. I was just wondering if it might be possible to listen for events to wait for the bulb to settle before sending a secondary command, but that could end up looking pretty janky even if it did work. Timing issues are annoying.