Hubitat MQTT Integration

I have a working bi-directional mqtt implementation for Hubitat working. This is a port of the SmartThings MQTT implementation so it was really easy to get working. I have it currently setup and using Home Assistant to provide a nicer Dashboard and Control interface.

Hubitat MQTT Bridge

3 Likes

First of all, Thanks!
Iā€™ve installed your dth and the app and was able to connect it to the same Bridge that is used by Smartthings.

Now, my problem is that I could not make the connection bi-directional.
It works in both directions for Smartthings but not for Hubitat.
Whatā€™s interesting is that, although the Bridge seems to be subscribing to the correct topics, the command messages do not appear in the Bridge.

Any clues?

Thanks!

@mag, You will need to have two instances of the bridge running. One accepts the entries from SmartThings and in the configuration file you will see a ā€œprefaceā€ for SmartThings. This is what then processes the entry and sends it to the MQTT Server. You will need another bridge instance for hubitat and in itā€™s configuration file there will be a ā€œprefaceā€ hubitat.

The entries for hubitat will look like similar to:

ā€œhubitat/Fibaro Motion Sensor/motion/stateā€

///

ie

hubitat/Living Room Lights/switch/state

I did try changing the config file and even turned Smartthings off completely.
When I update Hubitat App (to change subscriptions), a new state.json file is created and its content looks like the subscriptions created correctly. Nevertheless, the connection is unidirectional, no matter what I do.

On the Hubitat side, is there anything that requires the ā€˜prefaceā€™ to be ā€˜hubitatā€™?

@mag

What are you using for the "controller"? Using Home Assistant? If so in the configuration file there's the "state" and "cmd" topics. And you have to use them as well.

Example MQTT Bridge Config:

mqtt:
# Specify your MQTT Broker's hostname or IP address here
host: 192.168.254.10
# Preface for the topics $PREFACE/$DEVICE_NAME/$PROPERTY
preface: hubitat

# The write and read suffixes need to be different to be able 
# to differentiate when state comes from SmartThings or when its 
# coming from the physical device/application

# Suffix for the topics that receive state from 
# SmartThings $PREFACE/$DEVICE_NAME/$PROPERTY/$STATE_READ_SUFFIX
# Your physical device or application should subscribe to this topic 
# to get updated status from SmartThings
state_read_suffix: state

# Suffix for the topics to send state back to 
# SmartThings $PREFACE/$DEVICE_NAME/$PROPERTY/$STATE_WRITE_SUFFIX
# your physical device or application should write to this topic to 
# update the state of SmartThings devices that support setStatus
state_write_suffix: set_state

# Suffix for the command topics $PREFACE/$DEVICE_NAME/$PROPERTY/$COMMAND_SUFFIX
command_suffix: cmd

# Other optional settings from https://www.npmjs.com/package/mqtt#mqttclientstreambuilder-options
# username: AzureDiamond
# password: hunter2

Port number to listen on

port: 8081

If running with a SmartThings as well they need to be on different ports. I have my SmartThings on port 8080 and Hubitat on 8081

Device entry for Home Assistant

  • platform: mqtt
    name: "Family Room Lights"
    state_topic: "hubitat/Family Room Lights/switch/state"
    command_topic: "hubitat/Family Room Lights/switch/cmd"
    brightness_state_topic: "hubitat/Family Room Lights/level/state"
    brightness_command_topic: "hubitat/Family Room Lights/level/cmd"
    brightness_scale: 100
    payload_on: "on"
    payload_off: "off"
    retain: true

There's a full definition for my Family Room Lights. There's the state and cmd lines. FYI, the level commands aren't working for me either. Just on/off. I haven't had time to really dig into that.

@mag as for the ā€œrequirement to be hubitatā€ for the preface. I donā€™t know. I just tried that and it worked :smile:

Have to ask the dev team about that one.

BTW thanks for testing this as well. It would be nice to get it integrated more completely. I would like to get an MQTT client setup on the Hubitat side more completely to be able to process things from external systems easier. Currently the device must exist first in Hubitat and then it is controllable. I would like to get to the point where it first exists somewhere else and is presented to Hubitat to then utilize and control, through rules and such.

I think Iā€™ve figured it out.
The preface does not seem to matter, it can be anything.
For Hub-to-Server connection, the hubs coexist peacefully.
Server-to-Hubs is not going to work. The bridge updates subscriptions at random times; and updates from Smarttings hub are more random :slight_smile:
As a result, at any time, only one hub can be controlled; and often Smartthings prevails.

You were right, I need a second instance of npm install (but have no idea if thatā€™s doable on Windows).

The possible limitations and what not is why I packaged things into a docker container. If you install docker on Windows (I canā€™t help there) you may be able to run the docker container. With the docker container you can have as many as you want.

Iā€™m not fully clear on your setup. However in my setup, I have both running and controllable in decent timing. The updates through MQTT are almost instant in most cases. There are times when things get back logged and then a flood of events comes through. Which is not good. But if youā€™re not hitting every device (like I was) then under normal circumstances things should work. But, this is not a ā€œsolutionā€ per se, but a bridge for migrations or experimentation. At least thatā€™s what I use it for.

I have the bridge installed via NPM but with your release, I took a plunge and attempted to install docker (on Windows). Long story short, I could not make it work, and the setup badly conflicted with my VMWare.

I have Homeseer + HASS + Smarthings (with the bridge) communicating via MQTT.
My Z-wave devices are connected to Homeseer and ZigBee - to HASS and Smartthings.
With the Hubitat hub, I am hoping to drop HASS completely or maybe, only keep it for entertainment purposes.

So, I guess Iā€™ll need to figure out how to do an npm install for the second instance of the bridge.

If you are running VMware you could create a Linux VM to use for containers and for other things like npm modules etc.

Iā€™ve managed to install second npm package; and so, it is all working now.

Thanks a lot!

BTW, my plans to get rid of HASS have materialized; well, a little sooner that I expected. Somehow, HASS thought that Hubitat and Hue are the same and changed config files. And of course, it would not even start because of ā€˜unknown API errorsā€™.
it is very easy to delete a virtual machine :slight_smile:

Easy fix before you delete the VM.

Edit your configuration.yaml file.

Find the ā€œdiscovery:ā€ section and comment it out. Then restart HASS.

If you know the IP for the Hue Bridge you can add that in manually if you still want it. Youā€™re Hue configuration will still be in the config directory as well.

Commenting out the Discovery section did fix the Hue/Hubitat issue.
But then HASS complained about something else. In the end, with all optional sections removed, it still wanted a password and something else.

I strongly believe that Linux just does not like me. And now, with my ZigBee stuff connected to Hubitat, I have every right not to like Linux :slight_smile:

2 Likes

Thanks for porting this. Iā€™m currently running home assistant , mosquitto, and the ST MQTT bridge on a RasPi running hassbian.

Couple of questions for you.

  1. Is there a way to install yours via NPM in order to run along side the ST one
  2. Will there be separate config.yml files, or do both use the same one.
  1. There are NPM install instructions on my copy on github and on the ST MQTT site. I have never done it that way myself.
  2. Yes there are seperate config.yml files as they need their own port and the preface is different for each. This could probably be done all through a single bridgeā€¦ have to think on that, never thought of it because to me it was ā€œtemporaryā€.

OK. Figured out how to install your version via npm

sudo npm install -g jeubanks/hubitat-mqtt-bridge

When running it this way (via node vs docker), the problem is it's using the same config/log files as the st-mqtt file. I'm not too familiar with node. If I can't figure out another way, I may just fork yours and modify this section in server.js to have unique file names

image

I have both running via node (PM2 to keep persisted) w/o containers.

I cloned them into separate directories - left my ST config.yml untouched then changed the preface and port number in the habitat config.yml - each uses a different MQTT login (optional) but you will want to make sure you have separate client ids to avoid constant competition - one will drop.

I have been running since I received my hub over a month ago

I was finally able to get this to work alongside my ST mqtt install

1. Install bridge from jeubank's github


        sudo npm install -g jeubanks/hubitat-mqtt-bridge


2. Create new directory


    mkdir hubitat


3. Start bridge from new directory


    cd hubitat
    hubitat-mqtt-bridge


4 .Edit Config (prefix is already updated to hubitat in his version)


        sudo nano config.yml
        edit port (8081)



5. PM2 to run at startup


    sudo pm2 start hubitat-mqtt-bridge --cwd ~/hubitat
    pm2 save
    pm2 startup


6. Reboot

Man, I really want MQTT for local wifi device communications, but it seems like things are very difficult still. It's no wonder nothing other than DIY stuff uses MQTT.

I agree. I've got Hubitat talking to Home Assistant and can see status updates in HA but for the life of me, I can't get HA to talk to Hubitat. I can see the MQTT messages in the logs for the bridge but Hubitat doesn't respond. I'll give it another go this weekend.

1 Like