Just worked that out, I forgot I had to manually add them to the Maker API.
Thanks
Wow when’d you add this!? This is so nice.
So much more official than removing the integration and adding it back.
I really want to thank you again for your dedicated support of this project.
I had to give up on my iBlinds as WAF had dropped to 0% when the unit on the front most important window just completely died.
If Eric the founder of that company is in here sorry to bash your product, it’s just been a slog keeping them working for more than a few months at a time without attention.
Couldn’t agree more.
1 Like
I’ve been looking for switch level capabalities, is this something that is passed through in this integration?
I’ll add I am using a Zooz Zen-72 dimmer with the Zooz Driver, even when swithing the device to a Light in HA, I still do not have the ability to set the dimmer level in HA.
Hey @jason0x43, I just created an integration to sync Mode and HSM from Hubitat where I manage them. Strangely, only 3 entities were created: both a sensor and a selector entity for Hub Mode, but only a sensor for HSM. There’s no selector entity for HSM. Is this intended behavior? Guess I was expecting two pair.
Any idea what might cause this? TIA…
At the moment that’s expected behavior because of how HSM is implemented vs modes. Modes are pretty simple – the integration can request a list of available modes, and can change the mode by simply setting the mode to a different one from the list of modes.
HSM is a bit more complex. Hubitat has a current HSM status, like “armedAway”, or it may be something like “armingAway” if the status is in the process of changing. The set of values used to set the HSM status is also different from the set of possible HSM statuses (“armed away” vs “armedAway”). None of that makes it impossible to make a selector for HSM status, it’s just not as straightforward as a selector for modes, so it hasn’t been implemented yet.
Existing issue: Expose HSM status as an input select · Issue #151 · jason0x43/hacs-hubitat · GitHub
Ah makes sense. Thx for the lesson.
Is there anything I can do if Home Assistant doesn’t get all attributes/entities from Hubitat device?
Hubitat device (OMNI-sensor) has these attributes:
I’m getting all the others but not the “variable” one that is needed:
A good first step is to retrieve the device capabilities from Hubitat to verify that the attribute is being returned. If it is, a new sensor type may need to be added to the extension to expose the attribute.
Checked and this is what maker api says:
"“attributes”:[{“name”:“presence”,“currentValue”:“not present”,“dataType”:“ENUM”,“values”:[“present”,“not present”]},{“name”:“notificationText”,“currentValue”:“klo 18:04 - Pesukone k”…
And the one I would need is the “notificationText” attribute.
At the moment it says:
What is that “extension” part you are referring at?
Sorry, I meant the integration. For a Hubitat attribute to be visible in HA, it needs to belong to an entity. On general, the integration maps individual attributes to specific entity types. For example, if a device has Hubitat’s ‘presence’ attribute, that attribute will be represented by a HubitatPresenceSensor in HomeAssistant.
There isn’t a entity type corresponding to a Hubitat attribute named “notificationText”. The integration will need to be updated with a new entity type for that attribute.
Actually it’s working now. Entity was shown but not enabled. After I enabled it I was able to use that entity. So everything’s fine now
Oh, that’s right. The integration creates generic sensor entities for any “unknown” attributes (ones that don’t belong to some other entity type). I forgot about that. 
1 Like
Is there a specific reason why Hubitat modes and stuff aren’t usable with Home Assistant via Maker API?
I’m using Sharptools and there is a possibility to use all of these:
I started to think what is the main reason for SharpTools integration to do it but Home Assistant not.
When these two are added to dashboard it looks like this:
and when tapping mode:
I’m now using these sharptools dashboards as iframe cards but it would be so much easier if these “mode pickers” would work straight with HA.
See Custom Component: Hubitat - #1242 by jason0x43
Basically, modes do work that way, in that you get a mode selector entity that shows the current mode and lets you pick a new one. HSM isn’t quite as simple as modes, and so it doesn’t have a picker yet. Instead you have a sensor and a service.
Have an Aqara Zigbee button in Hubitat mapped to HA. How can I trigger an automation in HA based on this button being pushed?
sensor.button_front_gate_zb_pushed state changes to 1, but just stays there…
Thank you!
Button controllers are “event emitters”. You use them as device triggers rather than looking at a state attribute. To use one in an automation, create a device trigger and select the device, and you should have some possible triggers available like “Button 1 pushed”.
Thank you, this helped me figure it out!!
Much easier than the virtual switch / button controller tom-foolery I was having to do in Hubitat and push to HA to get the state change.
It seems like after latest update I lost all of my switches from Hubitat. Anyone else noticing same?
1 Like
Yes, happened to me too.