Custom Component: Hubitat

The latest update resolve my issue.

Jason on my current setup I have a 12 zone sprinkler system. Would it be possible to include those into this integration? I have attached the Maker API below. Each valve is listed as its own device.

{
  "id": "323",
  "name": "Orbit Sprinkler Controller Station Component",
  "label": "Station 01 - Front Side",
  "attributes": [
    {
      "name": "valve",
      "currentValue": "closed",
      "dataType": "ENUM",
      "values": [
        "open",
        "closed"
      ]
    }
  ],
  "capabilities": [
    "Refresh",
    "Valve",
    {
      "attributes": [
        {
          "name": "valve",
          "dataType": null
        }
      ]
    }
  ],
  "commands": [
    "close",
    "open",
    "open",
    "refresh"
  ]
}
1 Like

Sure, that should be doable. I opened an issue to keep track of that.

1 Like

So I took some time tonight and setup a round-about way to sync mode manager to HA. It’s a little messy but it works. Sharing for anybody else looking to bring modes over before it get’s added into the integration.

In HE I created a virtual switch for every mode option I had and made a rule in RM to turn on the switch when the mode changes. I loaded all of these into makerapi so they’d be shared through this integration.

In HA I created an input-select with the matching mode names

input_select:
    house_mode:
        name: House mode
        options:
            - Home - Morning
            - Home - Afternoon
            - Home - Evening
            - Home - Night
            - Away
            - Babysitter
            - Vacation

Then I used node-red to tie it all together.

The first flow changes the payload to the friendly name of the switch turned on by the RM rule then sets the input-select. This way the input-select matches any mode changes made by mode manager in HE.

The second flow is for control of the input-select in HA. Any changes made to the input select goes through the function node which will set the location mode ID and then passes that to an http get request which sets the mode on hubitat.

So with this I now have bi-directional mode control between HE and HA which also means I can now start bringing in the rest of my rules. :smiley:

1 Like

Wow that is overly complicated

I just created a Helper in HA and then wired up a few nodes to build a GET call to change the mode over MakerAPI. Works great, I can change the mide in HA or HE and it’s all synced up

How are you getting the modes from HE? Are you just polling the mode every X amount of time?

Ah yes, you ask a valid question

With what I posted if the mode changes in HE, HA doesn’t know about it in my setup. Not a concern with my current arrangement but I could see that being needed during the migration to HA

If you’re fully on boarded into HA, does the mode of HE still matter? I don’t use modes or HSM so genuinely curious.

Hah! Now that I think about it, not at all

The nodes I put together to build GET commands was something I was toying around with. I guess I took it a little too far :slight_smile:

I started off with ST and used webcore to control various things around modes. Moved to HE and the built-in mode manager was great! Then I start with HA and there is no concept of modes at all. So it leaves 3 options.
1: Re-work all my mode based automations around some other concept
2: Build some sort of concept of modes in HA which I had started to do
3: Continue to use HE’s mode manager and sync with HA allowing me to use the same concept for my automations that I’ve been using since day 1

Heh, “modes” were one of the features I’ve always thought was broken in Hubitat, because mode can only easily cover one domain (e.g., time), and usually you want at least two (time and presence). You can work around that by making combination modes like ‘Home - Morning’, but that doesn’t scale very well, even with just two domains.

In any case, you could emulate modes in HA with an input_select and simple automations.

input_select:
  mode:
    name: Mode
    options:
      - 'Home - Night'
      - 'Home - Day'
      - 'Away - Night'
      - 'Away - Day'
    initial: 'Home - Day'

Create one or more automations to update the select’s value, and then use the select’s state as the “mode” in other automations.

If your mode setting logic is simple enough, you could even use a template sensor, which wouldn’t require any automations to update its state.

1 Like

Mode manager on HE has evolved well past just time.
You can configure by day of the week, time of day, presence, buttons and switches or any combination.
So I use day of the week, time and presence for home - morning/afternoon/evening. I use sleep sensors or buttons for home - night and to trigger home - morning again, presence only for away and babysitter and vacation mode are controlled by switches turned on/off based on rules.

I started writing out the automation to control the input-select and then just decided to do it the much quicker and simple way since I know importing modes are on your roadmap at some point.

You can do everything Mode Manager does pretty easily with Rule Machine. The issue (well, my issue :smile:) is the fact that there’s only one mode variable. Hubitat wants that mode to represent multiple things (time and presence), but you can’t easily do that with a scalar, so Hubitat punts: when you’re “away”, your time-based modes disappear. They did finally add global variables to RM, which is great if you’re using RM, but they really should have just had two mode variables. Ah well. <gets off soapbox>

In any case, as you say, mode support will be coming to the integration in the not-too-distant future, so hopefully that will make things a bit simpler. :smiley:

I don’t know what motivated me to try out HA more… The massive slow downs without the daily reboot, or using Rule Machine. I will celebrate the day I never have to use that clunky Rule Machine ever again! LOL

Today has been a good day. I had made an 800 line webcore piston controlling my mini split that I absolutely refused to even attempt in RM, and then 7 RM rules to control baseboard heaters. I’ve been able to combine it all into 1 large node-red flow.The whole experience has been less frustrating than the simple rule I made in RM yesterday for mode changes!

That’s mostly what did it for me. :grin:

I have about 45 devices currently paired to Hubitat, this is what my Apps and custom code pages look like at the moment. No slowdowns, no reboots, no cursing @ rule machine (now it’s cursing at YAML lol)

4 Likes

This is my goal right here!!!

I see you have ikea blinds. That will be my next major project. I had a whole bunch delivered this week. In my head I’m picturing using them to help control temperature as well as privacy of course. I have a wall of windows in the living room. Lean them towards being closed in the summer based on temp and sun position to help keep heat out and have them open more in the winter to let heat in.

I think it would be a safe bet that this is the primary reason at least 95% of the people in this thread are here.

2 Likes

I came here looking to see if the issue with fans no longer having speed control was known. This was working when I set this integration up a month or so ago, but broke somewhere along the way. Looking forward to seeing this fixed.

Thanks for the excellent integration. I had my Hubitat hub sitting on a shelf, waiting for a proper integration to materialize. Once I found this, I moved all of my devices from SmartThings to Hubitat as my Z-Wave radio, and have been loving the instant response that comes from local device handler processing.

I noticed this happening recently and with my automation’s. Whether I do a single press or a double tap my automations run for both. I’m still digging into this but has anyone else seen?

New Automation 1 Trigger
device_id: ba9003207d774e4baa19a52a089d6c5c
domain: hubitat
platform: device
subtype: '1'
type: double_tapped


New Automation 2 Trigger
device_id: ba9003207d774e4baa19a52a089d6c5c
domain: hubitat
platform: device
subtype: '1'
type: pushed
2020-05-29 10:09:57 DEBUG (MainThread) [hubitatmaker.hub] Received event: {'name': 'doubleTapped', 'value': '1', 'displayName': 'Garage Light', 'deviceId': '21', 'descriptionText': 'Garage Light Button 1 doubleTapped', 'unit': None, 'type': 'physical', 'data': None}
2020-05-29 10:09:57 DEBUG (MainThread) [hubitatmaker.hub] Updating doubleTapped of 21 to 1
2020-05-29 10:09:57 DEBUG (MainThread) [custom_components.hubitat.device] Emitted event {'device_id': '21', 'device_name': 'Garage Light', 'attribute': 'double_tapped', 'value': '1', 'description': 'Garage Light Button 1 doubleTapped', 'type': 'physical'}
2020-05-29 10:09:57 INFO (MainThread) [homeassistant.components.automation] Executing New Automation 1
2020-05-29 10:09:57 INFO (MainThread) [homeassistant.components.automation] New Automation 1: Running script
2020-05-29 10:09:57 INFO (MainThread) [homeassistant.components.automation] New Automation 1: Executing step call service
2020-05-29 10:09:57 INFO (MainThread) [homeassistant.components.automation] Executing New Automation 2
2020-05-29 10:09:57 INFO (MainThread) [homeassistant.components.automation] New Automation 2: Running script
2020-05-29 10:09:57 INFO (MainThread) [homeassistant.components.automation] New Automation 2: Executing step call service