This release changes how RGB colors are updated to address the issue with innovelli lights not updating consistently.
Also, don’t forget about v0.5.0-pre if you’re feeling adventurous! I’d like to hear about at least one other person installing that successfully before calling it good. If you do give it a try, remember to back up your config directory! Once you install v0.5.0-pre, you can’t just switch back to a previous version or you’ll end up with duplicate devices.
Checked the json to make sure the duplicate ID’s don’t exist:
{
"capabilities": {},
"config_entry_id": "8b7f84084f454387a8fabeddd043cef0",
"device_class": "outlet",
"device_id": "193a7e59a0514e628ffc32de59b07b34",
"disabled_by": null,
"entity_id": "switch.begane_kelderkast_sirene",
"icon": null,
"name": null,
"original_icon": "mdi:alarm-bell",
"original_name": "Begane kelderkast sirene alarm",
"platform": "hubitat",
"supported_features": 0,
"unique_id": "192.168.10.10::961::898",
"unit_of_measurement": null
},
{
"capabilities": {},
"config_entry_id": "8b7f84084f454387a8fabeddd043cef0",
"device_class": "outlet",
"device_id": "8055d9f415774060b3238555c569c12d",
"disabled_by": null,
"entity_id": "switch.begane_kelderkast_deurbel",
"icon": null,
"name": "Begane kelderkast deurbel",
"original_icon": null,
"original_name": "Aeotec Siren 6 Component Chime",
"platform": "hubitat",
"supported_features": 0,
"unique_id": "192.168.10.10::961::899",
"unit_of_measurement": null
}
Besides the config_entry_id everything is unique.
About the update polling of the sensor, I haven’t got time yet to investigate it any further. Getting back to that later. The senors are all mains powered. The updates are shown in the HE device page directly on change, just not in the HA entity popup
The duplicate IDs are only an issue if you install v0.5.0-pre. It will update all the unique_id fields to use the hub’s MAC address rather than its IP address, so they’ll look like ab:cd:ef:12:34:56::2269::2146 rather than including an IP address. If you did install v0.5.0-pre and your ID’s are still looking like 192.168.10.10::961::898, well, that would be bad. But good to know.
Hmmm…enable debug logging for custom_components.hubitat and hubitatmaker in HA, and check the log after you see an update in HE to see if a corresponding event was received in HA.
Just checked, I was on version v0.4.21 and just installed version v0.4.22. Both have the same error about the duplicate ID. So I updated to v0.5.0-pre. Still same error. Looked in the entity json everything changed nicely to mac address unique_id’s. I’ll leave it for now like this. One sidenote, it is an enity which has a parent/child device in HE. If I have more time to spend on this this week, I’ll try removing the devices completely from HE and HA and let it all reconnect/rediscover.
Oh, sorry, I forgot what your original problem was. 
I thought you were referring to the duplicate ID’s that can occur when installing the pre-release v0.5.0-pre; I forgot about your particular error.
In any case, given the error, I wouldn’t expect you to end up with duplicate IDs in the entity registry. It sounds like the integration tried to register an entity with an already-registered ID and HA raised an exception. So, the trick is to figure out why it tried to register a non-unique ID.
If you enable debug logging and restart HA, you should see more information about what the integration is registering. Hopefully that will help pinpoint where the issue is occuring.
Great, thanks for checking that out!
This release supports changing the IP address HA uses to access your hub. It makes some under-the-hood changes to the Hubitat-related entities, so once you install this version you can’t easily move back to < 0.5.0. Not that you’d want to. 
Jason, I updated to v0.5.0 and the new version broke the connection to some of my entities. It also slowed down my system considerably so I decided to roll back to v0.4.22. As you probably know this caused the integration to duplicate all of my Hubitat devices and broke all of the entity registrations. To fix this I removed all of the original entities and renamed the duplicates with their original names.
Hmmm…The only changes between 0.4.22 and 0.5.0 are the renaming of entity unique IDs and the option to set the hub address, neither of which should be causing slowdowns.
Did switching back to 0.4.22 fix the issue? If you happen to update to 0.5.0 again, do you see the same problem? HA’s initialization process isn’t deterministic; I’ve had a number of occasions where something (usually my Dyson fan) doesn’t initialize properly and won’t work, but it’s fine after another restart. It’s possible that there was just some temporary issue after updating.
If you do happen to try the update again (because I’d love to know what broke), make sure to take a snapshot or make a copy of your config/ directory; the quickest way to downgrade is to just restore the config/ directory.
Yes, switching back to 0.4.22 fixed the slowdown issue and restored the missing devices. I had tried restarting several times while on 0.5.0 before downgrading to see if the missing devices would initialize, but that didn’t help. Give me a couple of days and I’ll try to update again. I just need some time to recover from having to fix 359 entity registrations. 
Yikes! Yeah, I only have 120 entities or so, and I would not be excited about having to manually fix all of those.
While backing up just before updating is the easiest way to avoid that pain, another way to fix things that isn’t quite so tedious is to:
config/.storage/core.entity_registry and do a search and replace for all "unique_id": "hub_mac_address:: with "unique_id": "hub_ip_address:: (hub_ip_address should be whatever you originally gave as the address or hostname for your hub)So I updated to 0.5.1 and didn’t see any performance issues, However, I was still missing 65 entities. To resolve this I removed the Hubitat integration and then re-added it. All my entities are back now and everything is good.
Thanks for your help and this awesome integration!
Glad to hear things are working!
Did you happen to notice anything about the missing entities? Like, were they related in some way? (All lights, all sensors, etc.)
They were all related to lighting.
Hmmm… I fixed a pre-existing issue where light entities were being created for some “cover” (garage door openers, window shades) devices, but if removing and re-adding the integration restored the entities, that probably wasn’t related.
Hopefully it was a fluke.
Updated to 0.5.1 and all seems well on this end.
Any reason I can’t setup another Maker API app in Hubitat and connect to another HA Instance?
I’m trying to transition to a new HASS OS VM, but I want to do it slowly.
There’s also lots of cobwebs and crud in my existing system so I kind of want to start fresh, but recreate everything cobweb free.
One thing that would help would be if both systems could use my Hubitat devices.
When I set up the new instance of HA and connected to my new Maker API app it worked fine but the old one lost it’s connection. Then I re-installed the custom component on the old OS and that one started working and then the new one stopped working.
Strange, maybe there’s something in the backend that knows to bugger me.
Thanks for any info.
Ok, so weird, after I restarted the new OS both systems are now responding, which is weird because I booted it this evening…
I’ll take it if I can limp through like this until I can put the old one on ice.
Yup, that should work fine, as long as each instance of HA is using a separate Maker API instance on Hubitat. A single instance of Maker API will only send updates to one instance of HA, but if you create multiple Maker API installs you should be fine.
Yeah like I said it wasn’t working at first. A HASS OS reboot fixed it, even though before I experienced the issue it was freshly booted. I’m sure it’s not your issue, I’m getting closer to transitioning permanently. I haven’t said thank you in a while, so thanks for this amazing integration @jason0x43 .
How do I use the “unlocked_with_code” trigger for locks?
Message malformed: required key not provided @ data['subtype']