Are you using the URI “/hub/messages”? That’s what I used in my custom apps and it worked even with a closed system.
The hub details aren’t strictly necessary for the whole process to work, they just provide an easy way to get the MAC and a unique ID for the hub. I’ll make that optional (in that it will try for it, but won’t break if it can’t access the information).
Regarding that second error, I’ll have to look into that a bit more. There’s probably an ordering issue in the config flow (I haven’t set it up from scratch in a while). It would be mitigated by making the hub info bit optional, though.
1 Like
Awesome. I’m happy to work with you to get it solved.
I think this is the right approach for integration.
Just my opinion.
2 Likes
I hadn’t looked at /hub/messages. I don’t get much from that, though:
{"messages":[],"mode":{"locationId":1,"id":3,"name":"Night"},"hsm":"disarmed","hsmAlert":null}
1 Like
Meh, it used to have more. That’s what I used for my “Is HE alive” scripts from NodeRed.
Ah. The kind of info I was scraping, just because it seemed interesting, was the hardware version, software version, the hub’s UID, and it’s MAC address. I could get the MAC address from the initial connection, though, and use that as a unique ID. The hardware version and software version are less necessary; I had some vague idea of adding HA sensors at some point to notify you of available updates. 
Ok, I see what the issue is with the NotReady error. I’ll get an update out a bit later today.
1 Like
Cool, I’ll keep an eye out.
Whenever I see that statement, I know things must be desperate 
My experience so far:
My plan for a long time was to wait out the stability issues in HE and eventually do as @code-in-progress mentioned, and use my HE hub as a zigbee/zwave controller…but…now that I have all my zigbee devices connected and working, I have to say that I prefer HA’s zha implementation. Wicked fast and consistent and now that someone awesome has shared a mesh visualization component with me…I’m even less likely to revert to HE.
Zwave was a mixed bag. I got all my devices paired and working but as @keithcroshaw mentioned, rebooting could be problematic. I didnt have any devices go dead, but it took about 5 minutes for the zwave component to fully load (on an intel NUC btw). I experienced the same flakiness with my Schlage locks. All in all, I’m fed up with zwave as a whole and have been moving my devices away from that protocol. I bought the schlage zigbee locks and they have been rock solid so far.
Time will tell if I ever start using my HE hub for the radios again (things change fast in the world of automation) but I love to see more options available for integrating platforms. Thanks @jason0x43 for creating this. I just factory reset my C4 and will test this out some time soon. Btw, the mqtt app doesn’t require any other devices if you are using Hassio and have mqtt discovery turned on in HA.
4 Likes
Oh don’t start! I was just trying to get the “Hubitat refugees” club going. 
4 Likes
I’m running a bare home assistant install on a Mac mini, so I’d need to setup an MQTT broker (not that bad, but it’s something else to manage). I was also trying to stick with built-in HE apps as much as possible, and although they have MQTT support, there’s no built-in MQTT equivalent of the Maker API (that I’m aware of).
I can dig my hub out and boot it up to test when the new version is ready. I’d LOVE to see more HE users on HA and this integration is the perfect balance to achieve that.
2 Likes
I worked with kevin on the mqtt app in the alpha stages and it’s just a bit overcomplicated for my needs. It’s designed to cover most scenarios but I wish he had a stripped down version that only worked with HA. Your approach is better for my use case. Removing the need for any 3rd party apps on HE is a DEFINITE plus. Look forward to testing.
2 Likes
Yea I kind of wanted Hubitat to be my Level 1 controller, meaning all essential things like Door Auto-Lock, Light on when Door Open, rudimentary things would go through Hubitat, but it’s really shifting to a Local device that’s good at adding my Z-Wave devices, and that’s it…
Yes! I applaud the efforts being taken to create that mammoth of an app but I kind of wish it were broken into a few more simplified apps that only takes care of one solution at a time and you can pick how much you want to load on your hub.
I know the argument I was given was that it all only runs when you first configure it but something is slowing down my hub, and that’s really all I’ve got installed.
It’s probably the phantom Hubitat memory leak that will be found one day and quietly patched…
I also feel like the excitement around the platform has dissipated lately, but that’s probably me projecting my feelings as I’ve been going all in on HA.
Forgot to include a link to the awesome sauce. For those that have a large zigbee mesh in HA, this tool is freakin awesome:
You can thank @code-in-progress for finding and sharing the above.
4 Likes
Oooooo… See, that’s the kind of thing that may eventually pull me all the way over from Hubitat. I mean, I like how it handles all the zigbee and zwave config without me having to fiddle much with anything, but I don’t like how little information it exposes about the underlying zigbee and zwave communication.
3 Likes
Hey, I’m happy with being able to see anything at this point. Visually seeing a weak link between 2 repeaters can save a lot of troubleshooting down the line. Hopefully we’ll get to see a lot more of the underlying communication as he adds to this component…but for a first draft…I’m very happy with what it already provides.
At a minimum, it has saved me the headache of figuring out how to add the CC2531 sniffer I bought to map my network on Hubitat.
Btw…It’s all zigbee…no zwave.
2 Likes
I like how you broke out each device into it’s own file.
So instead of complaining about wanting to get locks perhaps I could write my own. 
Me too btw.
It’s a 2012 beast upgraded to 16GB and small SSD.
Each of those upgrades made it seem like a new computer.
Sorry about that - I tried to make it as simple possible in that it provides bi-directional realtime status and control between HA and HE and discovery works seamlessly both directions. There’s the minimal to configure, only a couple of essentials. If you have any suggestions for further simplification I’d be happy to consider them.
My app is essentially an HE focused application that supports the two leading discovery protocols HA Disovery and homie3. It works well with HA because HA uses one of those protocols - but even HA doesn’t implement outgoing HA Discovery support. It is not an HA app and I will not be releasing a cut down ‘HA’ only app for HE.
Yes I do use an external man in the middle with MQTT but that is a very powerful open system integration that I think many people will find useful and desireable. Although minimal intermediaries make things simpler , more relaiable , and often faster.
I think a lot of people will find this direct approach via Maker API very appropriate.
That ZigBee node mapping on HA is really nice 
Kevin
4 Likes