Hubitat Integration testing and feedback request

First time skill writer looking for feedback on this skill that allows voice command from Mycroft to control devices on the Hubitat hub

How to install Hubitat Integration

It uses these Python libraries all of which are specified in the manifest

  1. fuzzywuzzy
  2. requests (network)
  3. json
  • SKILL NAME connects to…
    the Hubitat “maker” app in your own Hubitat. The URL and access token must be specified in a setting. The URL defaults to ‘hubitat.local’ which will work in most cases, but you must get the access token from the hubitat app.

How to test SKILL NAME

  • In your Hubitat hub, add one or more devices that can be turned on or off to the Maker app. Devices that can do “setLevel” like dimmers are also helpful. Note the URL and access token which must be specified in the Mycroft Skill Settings.

  • Configure the Skill Settings in Aside from the access info mentioned above, you can also put a “fuzzy” minimum score. A lower number will accept more (and possibly wrong) variants of devices names. Higher makes it more specific. The score 65 seems to work well for me.

  • Speak Intent phrase ‘Turn on’ followed by a device
    Forms that work include
    Turn on/off
    Power on/off
    Set mode

  • Mycroft should send an “on” command to the device and respond with “Ok” or “Done”. if the device does not accept an on command Mycroft should respond saying that the device does not accept an on command.

Similarly, replacing “on” with “off” should send an off command. An intent similar to “set to 50%” should change the brightness if the device accepts a “setLevel” command. Otherwise, Mycroft should respond that the setLevel command is not supported on that device.

An intent similar to “scan for devices” should pick up any new devices that have been added to the Hubitat app.

If the Hubitat is not accessible, a reasonable error message should be spoken.

If the default error (i.e. an uncaught error) ever happens that is a bug.

Where feedback on SKILL NAME should be directed:

Feel free to leave feedback here or as an issue on the github repo (GitHub - burnsfisher/hubitat-integration-skill: Allow mycroft to send commands to a hubitat zigbee and zwave hub

1 Like

A new feature (from a few weeks ago actually): If you have a thermostat that reports the temperature as a Hubitat device, you should be able to say “What is the inside temperature?” I can only test this on my one thermostat device, though, and that phrase is awfully close to “What is the temperature” which Mycroft already knows and give you the OUTSIDE temperature.

Even if no one is really testing this skill, I’d be interested to know if anyone is using it. I have totally replaced my Alexa with Mycroft because of this skill.

Another new feature: You can now add “do quietly” when you ask to turn a device (or scene) on or off. This is awkward to speak, but I intend it to be used with the routine skill where I can type “do quietly” at the end of the phrase. This works better if I also have a “say” command in the routine.

I wanted to get a development environment going with pycharm remote debugging so I could test code changes and have the debugger connected remotely to my rpi4 arm64 instance of mycroft, but unfortunately I forgot that the pycharm-pydevd remote debugger plugin does not have an arm64 binary.

So I went ahead and installed mycroft on a linux instance, but this morning the mycroft device api endpoint is returning a 500 error, so they’re have an outage apparently. In any event, when the server comes back to working condition, I can register the new linux based mycroft device instance, and I’ll start the Class Based work as described in the hubitat forum.

One thing I wanted to ask you about is the why behind this bit of logic (and this is not criticism I simply wanted to understand the approach), since you can access dicts directly via the keys, what does the search with a for loop and find method on the dev name string with the >= 0 logic do? Is there some hidden functionality there or?

instead of

    def hub_get_device_id(self, device):
        for hub_dev in self.dev_id_dict:
            # self.log.debug("hubDev:"+hubDev+" device="+device)
            if device.find(hub_dev) >= 0:
                hubId = self.dev_id_dict[hub_dev]
                self.log.debug("Found device I said: " + hub_dev + " ID=" + hubId)
                return hubId

Why not just simplify to:

            # self.log.debug("device="+device)
               hubId = self.dev_id_dict[device]
               self.log.debug("Found device I said: " + device + " ID=" + hubId)
               return hubId
except KeyError:
return <device not found etc.>

Just trying to understand the logic of the iteration through all the keys in the device id dict and the ‘>= 0’ test, in case I am missing something.

Incidentally, @burns I just wanted to thank you for this.

With myCroft and hubitat, I am completely cloud free, I can literally get rid of my Alexa devices. I have been trying to decouple myself from any / all cloud based services due to their intrusive nature, (i.e. data collection, their hidden use as state surveillance apparatus, etc.).

Now if only I could get rid of the android smart phone, but alas, the number of useful apps and the complexity of building a pocket sized tightly integrated hardware package is beyond the scope of free software organizations. You need economies of scale to really garner enough financial resources to produce something competitive with the current state of the art in the private sector.

In any event, I digress, but I can’t thank you enough for this!

I don’t have a minute now to look over this code, but is this related to the fuzzy search? It’s also possible that, learning as I went, I just did not come back to clean up. I tend to do some stuff in python, then not do it for a while and forget the tricks.

I’m to hear that this was helpful. Getting out of the cloud was exactly my plan. Feel free to make any changes that seem appropriate to you, and if you like just ask make a pull request against the branch I made in my repo for you. One of these days, I’ll get around to doing the compare and either incorporating your changes (or not :slight_smile: )

Thanks for the kind words.

1 Like

I was able to get the pycharm remote debugger working, it’s not straightforward.
here are the steps

  1. use mycroft-pip to install the pycharm-pydevd package
  2. don’t add the two remote debugger statements into your skill:
import pydevd_pycharm

instead, add the statements to

restart all mycroft services, the remote debugger should connect to pycharm
setup your remote path mappings until you get no more errors when you add breakpoints in your skill.
You’ll need to restart the debugger and mycroft services a few times for the path mappings to take effect ( i believe).

the new dictionary model is complete.

From here, I want to focus on some class based patterns for some basic objects like tstats, switches, and an observer pattern so the hub can automatically poll and keep itself updated with the latest changes for devices when we issue commands.

You can now set thermostats to different modes, and you can set the thermostat temperatures as well.

1 Like

This may be too late, or not really what you want, but I use VNC to connect remotely to the Picroft and then run Thonny (or any other python debugger) locally. Works for me :slight_smile:

Is there a step by step instruction on how to do this with Hubitat? I dabble but this is beyond my skill set at the moment. Any one willing to put something together for us less experienced in the art of programming?


Yes, the pieces are in different places. Since mine is all put together, I can’t easily tell you what to step by step. But I can suggest the pieces that you need:

  1. Put together a PiCroft. I don’t know if this will work on the latest version, but someone did recently post a nice blog about building the latest and greatest: Making a Mycroft from Scratch. Test it with some of the built-in commands. “Hey Mycroft, what time is it?” for example. As part of this you will need to create a account.

  2. Set up your Hubitat with the devices that you want to use, including any scenes (settings for a group of devices). You should be able to turn on your devices and set your scenes from the Hubitat device page.

Go to the “Maker” app and include all the devices/scenes that you want to control with Mycroft. You’ll also need to create an access token. (Keep track of it for later, or create it later).

  1. Install the Hubitat Integration skill on your MyCroft. This is where things may be different with the newer software. I have not tried it yet. But search around through this forum as I will be doing when my MkII arrives in January. When you have this all installed, you will need to login to your account and look under Skill Configuration and you should see Hubitat Integration. Most likely the only thing you need to add is the token that you got in step 2.

I know this is not a lot of detail, but hopefully the outline will help you find details elsewhere. Note in particular within this thread that someone had trouble the first time they used Hubitat Integration because the configuration had not shown up in their account. I don’t remember how they solved this.

I hope this is useful!

1 Like

Ok, @Lcstyle, your changes are now pulled to my repo and merged with master. Thanks!

1 Like

This skill works with Neon now. It really did not require any changes (except possibly to one requirements file), but I’ve updated the readme indicate how to install it. It’s is kind of picky, especially getting the settings.json file with the skill configurations correct!