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.
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.
@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”
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’?
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:
# Specify your MQTT Broker’s hostname or IP address here
# Preface for the topics $PREFACE/$DEVICE_NAME/$PROPERTY
# 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
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"
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
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
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
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
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.
- Is there a way to install yours via NPM in order to run along side the ST one
- Will there be separate config.yml files, or do both use the same one.
- There are NPM install instructions on my copy on github and on the ST MQTT site. I have never done it that way myself.
- 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
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.