The motion sensor I’m using is an Ecolink PIR Motion Detector (PIRZWAVE2-ECO). How do I check if it’s using motion or motion1?
I also have a lock being presented to HA that is working as expected.
Ah, I actually use a couple of those Ecolink sensors myself.
You can see what attribute names are used in the Hubitat UI under “Current States” for the device. You should have a “motion” attribute, and its value should be “inactive” or “active”.
What driver are you using for the motion sensors in Hubitat? I’m using Generic Z-Wave Motion Sensor.
Yeah this is interesting, it shows as “motion” and I’m using the same driver you are.
Do you have any Hubitat devices that are working properly in HA?
Yeah, I have a lock that is reporting state back properly. I can see it go from locked to unlocked as expected.
Maybe it’s the motion sensor, might try removing and adding back to see if it helps…
If the state is updating in Hubitat and it shows up in HA (and isn’t marked as “unavailable”), it should be working.
Next diagnostic step: enable debug logging for the integration in HA and see what messages show up. Edit your configuration.xml and add some logger config:
logger:
default: info
logs:
custom_components.hubitat: debug
hubitatmaker: debug
Restart HA, then try triggering the motion sensor and see what the log shows. It should show that an event is received
Fyi,
As of 109 update:
hubitat: the ‘.translations’ directory has been moved, the new name is ‘translations’, starting with Home Assistant 0.111 your translations will no longer load if you do not move/rename this
Good catch! I saw the bit about translation updates in the 0.109 release post, but I hadn’t looked at the HA logs since I updated. So many warnings…
Oh yeah…sorting through them as I type this.
Fyi…updated to 109.1 and most logs went away.
Strangely enough after enabling logging and rebooting the motion started getting detected in HA. Might have been the reboot. 5th times the charm!
1 Like
I might just be missing this, but are hub modes brought in from Hubitat?
I use a combination of presence, time of day, and switches to set hub modes with mode manager, and rather than re-invent the wheel it’d be nice if I could sync those modes with an input select or similar.
Modes aren’t part of the Maker API (as far as I’m aware), so they’re not handled at the moment. I believe mode change events are emitted in a way that the integration could pick up, so it could see changes, but it wouldn’t have any way to make changes.
At the moment, the best way to handle this would probably be with virtual switches exported from Hubitat. In the long run, the cleanest solution would be to add a simple device to Hubitat that exported the current mode as an attribute and allowed the mode to be updated directly via a command.
Not sure if this is helpful but modes are part of the api…just not properly documented. It was added a while back
See in particular, the New App Features
2 Likes
Modes and HSM through Maker API have been active for a little while now. I don’t think they were about a year ago. Both would be amazing additions.
Modes:
Read Modes:
http://[your hub ip]/apps/api/[maker api id]/modes?access_token=[your token]
Set Modes:
http://[your hub ip]/apps/api/[maker api id]/modes/[mode id]?access_token=[your token]
HSM
Read HSM
http://[your hub ip]/apps/api/[maker api id]/hsm?access_token=[your token]
Set HSM
http://[your hub ip]/apps/api/[maker api id]/hsm/[hsm status]?access_token=[your token]
1 Like
That should definitely be doable.
1 Like
There’s even a prettyPrint param. And here I’ve been piping my curl output through a prettifier like a chump.
1 Like
Is the button limit still 8 or has that increased since then?
The drivers I use for my Inovelli switches exposes 11 buttons. Haven’t gotten to the point of doing anything with them yet, just starting to plan ahead.