[Solved] Limit HA Entity in MSR

[gwp1]

I'm posting this question for a couple reasons:
*to show the world that I've probably completely missed the obvious
*just in case I'm not the only one, to share the response with all

@toggledbits - when deploying the latest build you made a point to link to the documents regarding Hubitat and I actually made a point to read them. Something I'd apparently overlooked when configuring my system all that time ago was having a dedicated Maker API for MSR in Hubitat.

Up until last night I'd used the same Maker API for Home Assistant and Hubitat to talk to MSR.

My question: what is the reasoning behind the dedicated Maker API? (ie, what have I been doing to my system all this time....?)

[toggledbits]

@gwp1 That's a remnant of the original version of HubitatController that relied on Maker API exclusively. In these early versions, Reactor had to instruct Maker API to post HTTP status updates to a special endpoint in Reactor — when a device state changed on the hub, Maker API would post the notification to Reactor, and Reactor would respond by updating its entity. Because Maker API allows only one such endpoint per Maker API instance, if you used the same Maker API instance for two subsystems (i.e. Reactor and something else), there was a chance that the two subsystems would fight over who got to be notified when something changed. The fix for this was simply to use one instance per integration.

But for many moons, now, HubitatController has used the (not very) secret, (very) undocumented event websocket for getting update notifications. This works much better, and I wish the folks at Hubitat would just suck it up and say the websocket API is official and supported, because it works so well, and because it's actually widely used by many integrations (i.e. the outcry would be enormous if it went away).

The latest version of HubitatController now only uses Maker API for initial inventory of entities. Prior to build 22067, notice of a device change event on the websocket would cause HubitatController to query Maker API for a full device update. As of 22067, HubitatController instead updates the device with the information given in the event only, no more query to Maker API, so in effeect, Maker API is only used for the initial inventory of devices (that's not true for Modes and HSM currently, but it's likely those, too, will adopt the new approach). This has some potential side-effects, discussed in the documentation, but I think for most users and common use, it's highly unlikely you'll ever run into the cases where such incremental updates cause problems. And they are much faster, because no secondary query is required.

@gwp1 said in Hubitat>MSR and dedicated Maker API:

what have I been doing to my system all this time....?

Nothing, it's fine, at least, it has been since we started using the websocket events. And now that we're doing the abbreviated update, Maker API is used even less. It should be no problem for Reactor to share a Maker API instance with other integrations.

[gwp1]

@toggledbits Thank you, good sir - enjoy your time away!

[wmarcolin]

@gwp1

It would be interesting when the Make Api can do as Hubitat Z-Wave Mesh Details does and give authorization to Extended Device Data, which has very useful information to further augment the Reactor rules.