I'm looking to get a Hubitat setup.
I need to be able to control the devices through Bitfocus Companion.
However, I don't see there are any plugin available.
Does anyone here use Companion with Hubitat? If so, how do you work with the two?
Can’t say I’ve heard anyone mention it here previously, but a quick search revealed only one other topic from a few years ago with no responses, so there’s probably not much already developed.
Looking at the “generic” section of their integrations list, it certainly should be possible for a developer to integrate with Hubitat, possibly through HTTP requests or MQTT. If the system has a REST API (which some of the integrations in that list would suggest), that could probably work too.
3 Likes
@marktheknife I am now able to control devices using the Maker API and http requests, using the "http Generic" module from Companion.
However, the trouble comes with isolating the different parameters for feedback status.
For example, I need to be able to get the on/off status of a switch. Maker API gives back:
{"id":"8","name":"Zooz ZEN04 Smart Plug","label":"Projector - Power","type":"Zooz ZEN04 Smart Plug","room":"Main Hall","attributes":[{"name":"power","currentValue":19,"dataType":"NUMBER"},{"name":"voltage","currentValue":122,"dataType":"NUMBER"},{"name":"amperage","currentValue":0,"dataType":"NUMBER"},{"name":"energy","currentValue":0,"dataType":"NUMBER"},{"name":"frequency","currentValue":null,"dataType":"NUMBER"},{"name":"switch","currentValue":"on","dataType":"ENUM","values":["on","off"]}],"capabilities":["Configuration","Actuator","VoltageMeasurement",{"attributes":[{"name":"voltage","dataType":null},{"name":"frequency","dataType":null}]},"CurrentMeter",{"attributes":[{"name":"amperage","dataType":null}]},"Refresh","PowerMeter",{"attributes":[{"name":"power","dataType":null}]},"EnergyMeter",{"attributes":[{"name":"energy","dataType":null}]},"Switch",{"attributes":[{"name":"switch","dataType":null}]}],"commands":["configure","off","on","refresh"]}
Is there any way to be able to either parse this string or change the http command to only receive back the "switch" state?
Was able to get this resolved by using "internal: Custom Variable: Set from a stored JSONresult via a JSONpath expression" as an action in Companion.
2 Likes
Glad to hear you found something that’s working for you.
I’m not a developer so probably wouldn’t be able to help further.
@jtp10181 or @bertabcd1234 might have more informed opinions if you have additional questions.
Now I'm having another issue.
The JSON structure order keeps changing, so the location of the on/off state keeps moving around. Initially it was:
$.[5].currentValue
Then I had to change it to:
$.[2].currentValue
Now the on/off state is at:
$.[0].currentValue
Is there any way to lock this in?
Maker API simply puts all the parameters under "Attributes," so it does not seem possible to reference the on/off state by name.
Yeah I agree. I do not know a ton about JSON but this looks to not be formatted that great.
There a list of capabilities further down and it breaks it out for Switch, but then the data is in a separate element it looks like, so not easily referenced I assume?
Using your sample above run through a formatter:
Tree view looks like this:
Also just noticed this does not have the value in it, just info about the capability
Other people are using this info, so there should be a way to traverse to the correct record using the "switch" name to find it? Instead of referencing it by the element number like you did.
Is there any way to reference an attribute based on one of the value names?
Or could the Maker API code be updated to provide consistent JSON structures?
Anyone out there with a solution for this?
I was going to look into it when I had a chance, but I do not do a lot with JSON or Maker API.
@JasonJoel I think you use MakerAPI a lot, maybe you would know how to do this better? See above.
Not that I know of, no.
Typically integrations with Maker API use the urls for setting commands and sometimes for populating the 1-time device config data (typically on load/initialization), but use the device POST events the hub will create on an event generation to update status on the remote side.
I don't know of any Maker API integration that needs to poll status of attributes like that (at least not without being able to parse the structure in code).
@bravenel It may be an interesting feature to add in Maker API version.future if there ever is one - URLs to request specific attribute value(s) on a device.
Or maybe instead of returning the attribute list as an indexed map/structure thingie, just make the attribute name the leaf name... So instead if referring to it by index (attributes.[indexNumber].currentValue) something like "attributes.switch.currentValue" or attributes.level.currentValue,m etc.
So for this:
Instead of needing to wade through attributes blob to figure out this is "switch" (as the attrivutes map/struct isn't always in the same order):
attributes.[4].name
attributes.[4].currentValue
just make it:
attributes.switch.currentValue
I dunno. Just thinking out loud.
Just looking at the JSON structure in the formatter tool I used, to me it looks like it is currently very poorly formatted. FWIW though, I do not work with JSON very often so maybe that is normal? 
Seems like it sort of defeats the purpose of a structured layout when everything is just nested inside of un-named groups that change index numbers.
Agreed. It is definitely a funky format, in my opinion. My guess is that they wouldn't do it that way if they were to make a new version now.
I'm not so secretly holding out hope that they do make a new version (probably can't 'fix' the existing without breaking things significantly).
An end user might be able to make a community developed one - I've looked into this a few times, with some success, but the limitations of user space apps for something like this make it of questionable use.
Really, Maker API is very good overall currently. Data structure and call limitations aside, it is quite performant and reliable. I don't think it needs to be completely scrapped to go from good to great - just some structure improvements, a few more supported calls, etc.
1 Like
Maker API was thrown together quickly early on, before we had experience with how people might want to use it -- a stab in the dark. Only small changes have been made since, except for adding POST events. Obviously, any changes need to be backwards compatible. I'm sure if we were to create a new version it would be more thought out. But,
The need for improvement is a bit marginal, especially in an overall resource allocation view of things.
Not completely, as there are inside calls made that aren't available to user code (security driven).
If one of you wants to propose very specific additions, specific methods and object formats to return, I'd be willing to add them. I don't have a lot of time to spend on it or to think about it. Make it obvious what you want, and I'll do it.
4 Likes
There seem to be a few other possibilities:
(1) spin up a Home Assistant instance, use the Bitfocus Companion integration with Home Assistant, then bring Bitfocus Companion into Hubitat from Home Assistant through the HADB integration on Hubitat. The Bitfocus Companion integration for Home Assistant is here:
https://bitfocus.io/connections/homeassistant-server
The HADB integration, which is very nice, is here:
(2) use the Bitfocus Companion ESP Home API to bring Bitfocus Companion into the Home Assistant ESP Home integration.
https://bitfocus.io/connections/esphome-api
then bring the ESP Home Bitfocus Companion device into Hubitat through HADB,
(3) use the Hubitat ESP Home integration to bring Bitfocus Companion directly to Hubitat through the Bitfocus Companion ESP Home API.
I believe that #2 should be the most straightforward.
I use Home Assistant to handle devices for which a Hubitat integration does not exist (Litter Robot, Sure Pet Cat Door). I used #2, above (not with Bitfocus Companion, but with the RatGDO ESP Home integration) to bring the RatGDO garage door integration into Hubitat, works great, very reliable.
Thank you for all the suggestions, but I need to keep the setup as simple as possible, without the need to run an instance of HA or some other third party automation software, as this setup is not for personal use.
@bravenel I would propose this specific addition/change:
As suggested by @JasonJoel, in the JSON response, please move/copy the "name" field up a level so that individual parameters can be reference by attribute name.
e.g.:
from this:
"attributes": [
{
"name": "switch",
"currentValue": "on",
"dataType": "ENUM",
"values": [
"on",
"off"
]
},
{
"name": "energy",
"currentValue": 4,
"dataType": "NUMBER"
},
{
"name": "power",
"currentValue": 346,
"dataType": "NUMBER"
}
],
to this:
"attributes": {
"switch": {
"currentValue": "on",
"dataType": "ENUM",
"values": [
"on",
"off"
]
},
"energy": {
"currentValue": 4,
"dataType": "NUMBER"
},
"power": {
"currentValue": 346,
"dataType": "NUMBER"
}
},
The switch state can then be called directly by the following JSONpath expression:
$.attributes.switch.currentValue
Can't make this change without blowing up every user that relies on the current format.
We are going to add this:
Get Device Attribute (replace [Device ID] with actual subscribed device id and [Attribute] with a supported device attribute)
http://192.168.0.66/apps/api/32856/devices/[Device ID]/attribute/[Attribute]?access_token=xxx
And that will return something like this:
{"id":"10513","attribute":"windowShade","value":"closed"}
2 Likes
That works as well!
Any timeframe on this?
Next release.... Quite soon.
3 Likes
