Yes, enabling that should help. Hub mode events count as “location” events, so if that setting is disabled, Hubitat won’t send them.
I’m not sure if that helps. I need to test. Even though it was disabled before HA still logged mode changes (day, away, night) as well as hub hsm status but I’m going to test.
Hello,
I have just started testing out the HE to HA integration and I have imported all my Huibitat devices and entities.
I have also enabled all the options on the HE Maker API APP so that I can get a bidirectional sync.
The issue I am facing is that when I change a device status or get new values like voltage or temperature values in HE, I don’t see them in the HA devices.
I also don’t see any entries in the HA Logbook.
Is there some sort of poll time (sync) that needs to be configured in the HA/Hubitat integration?
HE: C8 v2.3.5.113
HA: 2023.3.5 / Hubitat (eaa2d26d)
Thanks in advance for the help,
Seb
Is there some way for a device to marked as unavailable in Home Assistant if it’s, you know, unavailable? I was testing some new Zigbee bulbs that I added to my Hubitat, and everything works fine to control them. I unplugged them (waiting for some other hardware to come to finish the actual project), and I noticed they are still showing as available in Home Assistant. If I try and change their state (i.e. on/off, change dimming level), HA just pops them back to the last state they were in when they were unplugged.
I have some other devices that I only use during the holidays, and I was thinking about writing some logic in HA that would only show those controls if they’re available. But I can’t do that if the integration doesn’t flag Hubitat devices as unavailable when they’re offline.
I have finally resolved the issue 
It was that I was not using the same port nor exposing it in the docker in the Maker API
2 Likes
Hi
Just getting started on HA, and keen to keep deives on HE until I’m confident with HA - so this integration is awesome.
Got a problem with Ikea blinds -
I have Webcore pistons to open/close the blinds at certain times.
Before I set up this integration, the Webcore pistons worked perfectly for the blinds.
But now it’s a bit hit and miss… sometimes they work, and sometimes the blinds only half close (strange!).
However - the devices seem to work ok when actioning from HA. I can control the blinds.
I deleted the integration and started again, and in the Home Assistant logs, I see this -
Platform hubitat does not generate unique IDs ID [long id number]::359::cover::windowShade already exists - ignoring cover.office_blinds_right
I get the same message for 5 different Ikea blinds we have.
I think it could be some kind of ping pong effect, where the Webcore command is somehow challenged by whats in HA, causing it to no open/close, or stop mid action (hence closing half way).
(I see this effect in dimmers too, when adjusting the dimmer in HA, it often jumps up for a brief second and then back to where I set it).
I’m using this device code in HE - Ikea/IKEA-window-blinds at 0e6073850b781ee8570d6c347b31e9c7743e44c0 · a4refillpad/Ikea · GitHub
Any thoughts / ideas / resolutions?
Thanks in advance
I’d recommend picking one platform or the other to do your automations. I have three ikea blinds connected to my Hubitat, and they work flawlessly in HA using this integration. I ONLY use the Hubitat to connect devices. I don’t do any automations (WebCore, rules, or otherwise) on the Hubitat at all. I basically jus use the Hubitat as a Z-wave/Zigbee bridge and that’s it.
1 Like
Hmmm…how does the integration fit in here? I mean, if the blinds are managed by Hubitat, and Webcore is running on Hubitat, it doesn’t seem like the integration would be involved, unless maybe an automation in HA is being triggered when the blinds start opening or closing.
A recent update to the integration added support for a number of new entity types, and it’s possible your there’s some duplication happening when setting up your devices. I’ll look into that.
That’s right - 100% of my automations/scenes/routines are done in Webcore.
At this stage (just getting started), I am only using HA for dashboard purposes, and other integrations not available in HE (but those devices are not involved in any routines as yet).
So…
Could be true. But… this is why I compare it to the effect seen when adjusting a Hubitat dimmable light on a HA dashboard. For example, if I use the dashboard slider to dim down from 80% to 50%, I often see the slider jump back to 80% (or near to), then settle back at the intended 50%, as though there is some kind or negotiation/conflict going on.
I wonder if the WC piston is commanding the blinds to close, but the HA state is somehow overruling that in some instances… And whether the error around unique IDs is related or not, I have no idea!
Thanks for your help.
That’s happening because Hubitat is a bit slow to respond, not due to any sort of conflict. When you adjust the dimmer in HA, HA sends a command to Hubitat and waits for a response confirming that the light was dimmed. If Hubitat takes too long to respond, HA assumes the command didn’t work and restores the previous state of the device (in HA). A little while later, when the light does dim, Hubitat sends a state update event back to HA, and HA sets the dimmer widget to its proper value.
When a WebCore piston is adjusting your blinds, everything is happening in Hubitat — HA isn’t in that path. Hubitat will send state updates to HA as the blinds open and close, and HA will update its view of the blinds’ state, but that by itself shouldn’t cause HA to send any commands back to Hubitat (and sending commands is the only way that HA will affect devices in Hubitat).
I do see where duplicate entities are being created for window shades. I’ll have a fix out for that a bit later today. That will get rid of the non-unique entity ID warnings in the log, although I’m not sure if it’ll help the slowness.
2 Likes
Ok - thanks for the info.
I’ll do some testing and see if I can work out what’s going on
This is amazing. Thank you so much
1 Like
Hmmm…does anyone, by chance, have an old hub they’d be interested in selling? My cat decided to claim mine (by marking it), and although the hub appears to boot, its ethernet port is no longer functional. It’s a C7, but I hadn’t installed the Wifi drivers on it, so I can’t (as far as I’m aware) plug a USB WiFi dongle into it and have that work.
I’d buy a new one, but maintaining this extension is the only thing I’m using the hub for any more (I got a Skyconnect and moved all my zigbee devices over a few months ago), so I don’t really need a new one. I figured I’d check here first, then hit ebay. 
1 Like
Sending PM
Thanks everyone! I have one on the way. 
2 Likes
Oh thank god. This integration is key to how all my systems tie together. I would be sad if/when you decide to retire from supporting this.
oh no we are about to return to cat keeping for my daughter and this is my biggest fear, thanks for reminding me it’s a thing they do lol. Already looking at $700 smart litter boxes so I don’t have to do that and there’s a one star review about how their cat did what yours did and bypassed the $700 litter box right onto the floor… lol fun…
This is the first cat we’ve ever had that’s marked things. He uses the litter box most of the time, but every now and then he decides he needs to claim some territory. My wife has started refering to him as “pee cat” all the time. 
I have a couple smart litter boxes, a Litter Robot 3 and a 4. They’re pretty good. If you’re going to get a Litter Robot, I’d highly recommend the 4. It’s significantly quieter than the 3, it’s bin is better designed, it’s emptying function works better (the rubber liner flexes more easily which helps unstick things), and it’s firmware is upgradeable through HA.
1 Like
I have been using this integration and generally liked it. Thank you very much for your work. I just set it up again at another location and am having trouble with sensors not updating in HA. If I manually force a reload, the sensors will update. Is there a way to fix this? Is there a way to automatically force an update on either the Hubitat side or HA side? EDIT: I did setup an automation using the “Reload Config Entry” under “Call Service” on the sensors that were not updating. It seems to have worked. Not sure if that is the right/best way or why I have to do that in the first place.