Hass.io Add-On Request

[makingwilliam]

It's officially here, Hass.io on HassOS: https://www.home-assistant.io/blog/2018/07/11/hassio-images/

Is it now possible to have the installation process moved to a Hass.io Add-On?
Add-on Documentation: https://developers.home-assistant.io/docs/en/hassio_addon_tutorial.html

I have been unable to use the docker install method since I originally started using Hass.io. It would greatly improve the setup and configuration process. I found an example of someone else who has done this, but they are running an outdated version of the bridge. See below:

https://github.com/vkorn/hassio-addons/tree/master/smartthings

Thank you kindly!

[damien67]

I found this:
https://github.com/adamfeldman/hassio-addons

Seems to be a more updated version of the bridge. However, I couldn't install it, When I select "Install" it seems to try but then goes back with the ""Install" button (if successfully installed should say "uninstall").
vkorn's version simply installs without issue...Give it a try!! I am curious if I am isolated or if anyone would get the same result.

[makingwilliam]

I couldn't get it to install either, I have been using vkorns as of recently. But I have also tried installing the newest version myself using NPM and PM2. My problem is that no matter what I do in HA or MQTT it never updates the bridge to tell smartthings what to do. Although it works perfectly the other way around and writes to MQTT with no problem. I just can't figure out what's stopping it from reading the changes made from HA or MQTT. It worked great for months and then just suddenly stopped.

[damien67]

Ha! You're the guy who participated in the other thread related to the Shield TV and the ERCONN 0.0.0.0!
So...I had the shield, and the update broke it. Bought a hub on amazon, finished moving all my devices this morning, and I have no problem whatsoever with ST, mqtt and HA, all functionalities restored.

So your MQTT broker is 10.0.0.199 port 1883?
Your configuration.yaml is properly configured?
What if you manually publish a command to the broker?

Publish:
moquitto_pub -h 10.0.0.199 -u username -P password -t "smartthings/Office Lights/switch/cmd" -m "on"

Subscribe (you can open another putty so that you can pub and sub at the same time):
mosquitto_sub -d -h 10.0.0.199 -u username -P password -t "#"

Looking at the mqtt subscription, the bridge addon log in HA, and the ST IDE log, you may see something!!!

Finally, something very silly that took me a couple hours of head scratching to figure out...
At some point I restarted HA and all automation turned themselves OFF!!! ST was updating HA, but HA wasn't sending any mqtt commands because of the automation being off. It was an easy fix, but definitely took me too much time to figure out!!!

[makingwilliam]

@damien67, the broker ip and port you listed are correct. I have HA talking to MQTT, reading sensors and publishing to non smartthings topics. Here are the results of a manual publish...

Client mosqsub|27-core-ssh received PUBLISH (d0, q0, r0, m0, 'smartthings/Office Lights/switch/cmd', ... (2 bytes))
on

I'm not sure I follow what you mean by automation. Every automation I have, automation_* is set to on.

[stjohnjohnson]

Check that the MAC address of the device is correct in Smart things. To want the one that SmartThings will see (eth0 or en0). Otherwise it drops messages.

…

On Sat, Jul 14, 2018 at 08:01 thewilliambond ***@***.***> wrote: @damien67 <https://github.com/damien67>, the broker ip and port you listed are correct. I have HA talking to MQTT, reading sensors and publishing to non smartthings topics. Here are the results of a manual publish... Client mosqsub|27-core-ssh received PUBLISH (d0, q0, r0, m0, 'smartthings/Office Lights/switch/cmd', ... (2 bytes)) on I'm not sure I follow what you mean by automation. Every automation I have, automation_* is set to on. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAl98WjFomHhQ6oT-21xx5K6uWT2MMXaks5uGge9gaJpZM4VO9AU> .

[makingwilliam]

I've been using the MAC address from eth0 on my raspberry pi 3b+. However, since I am running Hass.io on HassOS now, all dockerized. I'm wondering if I should be using a different mac address.

[makingwilliam]

I solved my problem, posting it back in the other topic as this was more a feature request. I would like to have the newest version of the bridge running versus the one vkorn has installing.

[adamfeldman]

My docker images should be running smartthings-mqtt-bridge 2.1.0.

@thewilliambond: how did you solve your problem? I had success using the MAC address of the physical device running Hass.io (I'm not on HassOS yet as I've just switched to an Intel NUC from RPi).

@damien67: are you running on amd64 (Intel-like) or armvhf (RPi or similar)? I previously had only pushed an arm image to DockerHub, I pushed an amd64 one today. The error you saw may have been because you were on amd64 and not arm, as the config I forked from vkorn is setup to dynamically select the correct processor platform at install-time, and not hard-coded to a specific platform.

[makingwilliam]

@adamfeldman I tried your addon, as well as @damien67 and we both had the same result. When you click install the button turns red and nothing is installed.

It was the mac address. So when I run a non-hassio version of homeassistant, or in my case at the time because I have the raspberry pi 3b+ a forced install of hassio then you use the physical mac address of the device. I had just grabbed this from my router's client list, so I never noticed then when I started running the new Hassio release on HassOS which now works for the 3b+, that mac no longer worked. Instead, I had to login to the ssh with the OpenSSH addon for Hassio, which logs you into the home assistant container. Then when I checked for eth0, the mac address was completely different. That was the require mac address to get the bridge to communicate with the Hassio addon I was using from vkorn, which is outdated.

[damien67]

@adamfeldman Correct, amd64. I am running hassio 0.73 on an Ubuntu 16.04 VM hosted in Win10...

When you say you “pushed an amd64 version today”, does it mean that it is ready to test again from your repository in hassio addons?

[adamfeldman]

@damien67 yes, it is ready to test again. If it doesn't work, please file an issue on my repo and I'll take another look.

I believe the reason it didn't work for you before is that your install was looking for a non-existent amd64 docker image. I built that image today.

[damien67]

@adamfeldman
Ok, I successfully pulled your image this morning.

vkorn's log:
starting version 3.2.2
info: Starting SmartThings MQTT Bridge - v1.3.4

Yours:
starting version 3.2.5
info: Starting SmartThings MQTT Bridge - v3.0.0

Configuration is the same:

{
"broker_host": "localhost",
"broker_port": 1883,
"preface": "smartthings",
"state_suffix": "state",
"command_suffix": "cmd",
"login": "xxx",
"password": "xxx",
"bridge_port": 8084
}

Here is the problem I see: The state_suffix and the command_suffix aren't taken into account!

When I turn a light on with vkorn's:

• From ST to HA: info: Incoming message from SmartThings: smartthings/Moonlight/switch/state = on
• From HA to ST: info: Incoming message from MQTT: smartthings/Moonlight/switch/cmd = on

Same with yours:

• From ST to HA: info: Incoming message from MQTT: smartthings/Moonlight/switch = on (HA doesn't update due to the lack of /state)
• From HA to ST: info: Incoming message from MQTT: smartthings/Moonlight/switch/cmd = on (strangely ST does turn the light on with the /cmd included, but HA's toggle turns on and back off)

Am I missing something?
I will copy this post in your git...
Thanks!!

[makingwilliam]

@damien67 and @adamfeldman, today I pulled them image to raspberry pi 3b+ with the latest Hass.io on HassOS 1.9 (32-bit edition). I was able to install it correctly, but I'm having two issues.

1. I am also having the same problem as @damien67 where the state and cmd suffixes do not seem to be taken into account.

2. I am now back to the nasty problem of one-way communication which I have definitely isolated to a mac address issue. I have tried both the physical mac address of the raspberry pi and the eth0 mac address that shows up when i log into ssh and run ifconfig eth0. So, there must be some other docker host mac address or it needs the mac address of the container running the bridge not Hass.io.

Any help would be greatly appreciated!

[makingwilliam]

@adamfeldman from what I can tell the issue with the read state suffix is in the template.yml file. The following line...

state_suffix: {{state_suffix}}

should read...

state_read_suffix: {{state_suffix}}

I made a clone and then copied it over as a local addon with the above change made and the read state works properly now. I'm just wondering what you are using for the correct mac address? @damien67 what mac address did you end up with?

[makingwilliam]

I was able to get everything working properly finally, and I am slapping myself in the face now and then as to why I've had so many problems with the mac address and one-way communication. So, I would like to point something out to everyone who has a one-way communication problem (especially after an upgrade when you've already had it working before).

EVERY time you change the MAC Address under the device you created in SmartThings Groovy IDE or if you reinstall or upgrade your Home Assistant installation and you only have one-way communication, you absolutely MUST open the SmartApp on your phone, edit it, and save it. You do not need to make any changes in the Smart App, but you must edit it and save it. The reason for this is that it forces the bridge to re-subscribe to the MQTT publications.

The subscription isn't needed for the bridge to publish messages to MQTT, but it is REQUIRED to receive messages published by other connections.

And finally, USE THE PHYSICAL MAC ADDRESS regardless of whether you are running hassio (dockerized) or not. Just remember to follow the instructions above!

[makingwilliam]

If anyone is interested, I have a fully working Add-on for the SmartThings MQTT Bridge by StJohnJohnson. The add-on successfully installs based on the architecture of your machine, per the development documentation of Home Assistant and it corrects the issue with the read state suffix being ignored. It also includes a troubleshooting section for anyone experiencing one-way communication. I'll be adding instructions for logging in and determining the MAC address from the HassOS host itself soon. Thank you to everyone for contributing to this addon and to vkorn and adamfeldman for their initial work on this addon.

https://github.com/thewilliambond/hassio-addons

[m-e-h]

Looks to me like the command_suffix should be 'command' rather than 'cmd' https://github.com/stjohnjohnson/smartthings-mqtt-bridge/blob/master/server.js#L32

I haven't tested it but this might explain the commands not sending.
If this is the case, should probably update the config examples.

[makingwilliam]

@m-e-h, if you are using my addon, the command suffix has already been updated.

[m-e-h]

I actually created my own addon before finding this thread.
But I'm still uncertain whether the proper command_suffix should be 'command' or 'cmd'.

[makingwilliam]

I found the problem is not in the file you mentioned. The original bridge works fine, there inst a problem there. The problem is with spelling in the template file. If you look at the changes I made in my repository, you should see what I'm referring to. https://github.com/thewilliambond/hassio-addons

[m-e-h]

Oh yeah, I see that now. I hadn't even noticed that in vkorn's.
Still curious why the default in this script is command but in the config it's cmd 😃

[john3jo]

Good evening,
For the last 3 days I have been trying to get ST or MQTT to receive the changes from HA and found this thread with great hopes that the add-on provided by @thewilliambond will get me there, but sadly I am still stuck on one-way communication (ST->HA).
Also, when I change the switch toggle in HA it does not "turn the light on" and instead changes back to off state about a second later. On the other hand, HA does update when I turn the light on from ST or via the physical switch.
My setup uses a Rasp_pi using Hassio as the OS.
I did try to use my Rasp_pi physical eth0 MAC address in the MQTT device created via ST IDE, but every time I do so, the MQTT bridge looses connection and no longer listens for changes, no matter how many times I go the the SmartApp, edit and save.
The only way I can make it work (half-way) is by using the eth0 MAC address i get from hassio when running the "ifconfig eth0" command via SSH. As soon as I do that, the bridge starts listing fine and one way communication gets back to work. Sadly though, editing and saving the SmartApp does not trigger the devices responding to HA commands.
I do see the all the ST devices been registered every time I update the smartApp.
Any help will be greatly appreciated. This is driving me nuts!

[romeo80]

Hello
I have the same issue John mentioned above. I have tried using "command" instead of "cmd" as the command_suffix and tried changing the macaddress in the smartthings device but i cant seem to get the communication from Hassio to go to Smartthings. I can only see updates coming from Smartthings. I am using Hassio version 0.90. This problem started with version 0.89. Any help would be appreciated.
Thanks

[damien67]

@romeo80
Is your HASSIO exposed outside you network? (letsencrypt/duckdns for example)
If so, I would highly recommend migrating to the official ST support recently introduced.

I have migrated all my thermostats, switches, lights and sensor and it works absolutely perfect!
I still use mqtt for a few other non ST things.

[romeo80]

@damien67 no it is not. I did no want to expose it or use Hassio Cloud. Wanted to keep everything local. I don't see a way to use the new SmartThings integration without signing up for a cloud account so I am stuck with the old implementation.

[makingwilliam]

@romeo80 I too have migrated to the new ST Integration within Home Assistant. However, I DO NOT use "the cloud" which I think may be referred to incorrectly here. You can expose your HA interface to the WEB, without actually linking your HA instance to "the cloud". In this respect, your information is still all local and maintained by you and your devices, but it is remotely accessible to you anywhere you are in the world using the internet. Considering that you are required to maintain internet for most smart home devices these day, you should be able to do the same as I have.

You can do this be either setting up a DuckDNS address or by, my preferred method of, obtaining a domain name and using lets encrypt. Either method does not place your data and or information held by your instance of HA into the actual 'cloud' which is the online service provided for native HA remote access; instead, you are allowing remote access for yourself directly to your HA instance within your own local network.

[romeo80]

@thewilliambond I wasn't aware of this option. This sounds like exactly what I want to achieve. I will give it a shot. Thanks for all your help. You guys are awesome!