I had same with my zigbee2mqtt. Same error message.
Lots of people had issues with MQTT this weeks after an update to v3 of addon.
I had to restart from scratch as my SD got in a right state!
To get around that issue I had to create a MQTT user to connect with in Mosquitto as the anonymous was set to False.
I still have to re-add Smartthings addon, so will no doubt have same issue. But I will again be using a user created as mentioned previously
I’m affected, but I couldn’t get authorization to work. Even a user that OwnTracks uses with my mosquitto broker successfully was refused.
Im thinking of ditching Smartthings altogether as I use zigbee2mqtt and Xiaomi sensors, the Samsung hub was what I bought before I got into HomeAssistant. There is nothing on it that I haven’t done with Xiaomi now… could be time for Ebay I think and no more half measures of 1yr old addons with no updates
Turned out my /opt/mqtt-bridge/config.yml was formatted incorrectly with tabs instead of spaces.
There was an update on the Plugin… it changed something in the authorization. This works for me:
{
"logins": [],
"anonymous": true,
"customize": {
"active": true,
"folder": "mosquitto"
},
"certfile": "fullchain.pem",
"keyfile": "privkey.pem"
}I’m getting the following error log in Mosquitto broker. Anyone have any ideas why? Smartthings bridge appears to be working correctly, but the actions are not being picked up by MQTT:
This is driving me nuts. It simply wont work. Anyone have any idea why?
The MQTT Broker log shows this:
[INFO] Setup mosquitto configuration
[WARN] SSL not enabled - No valid certs found!
[INFO] No local user available
[INFO] Initialize system configuration.
[INFO] Initialize Hass.io Add-on services
[INFO] Initialize Home Assistant discovery
[INFO] Start Mosquitto daemon
Error: Unable to open include_dir ‘/share/mosquitto’.
Error found at /etc/mosquitto.conf:27.
Error: Unable to open configuration file.
What is the correct way to setup a dimmer? If I select them as “switch level” in the ST smartapp, they do not work. They won’t turn on/off and it is not updating the state of the switch. If select them as “switch” the also do not work. This is how I had them set up in the yaml files…
switch.yaml
- platform: mqtt
name: OFC Lights
state_topic: "smartthings/OFC Lights/switch/state,"
command_topic: "smartthings/OFC Lights/switch/cmd,"
payload_on: "on"
payload_off: "off"
retain: false
lights.yaml
- platform: mqtt
name: "Office Lights"
state_topic: "smartthings/OFC Lights/level/state"
command_topic: "smartthings/OFC Lights/level/cmd"
brightness_state_topic: "smartthings/OFC Lights/level"
brightness_command_topic: "smartthings/OFC Lights/level/set"
brightness_scale: 100
payload_on: "on"
payload_off: "off"
retain: falseyou dont need MQTT bridge anymore. Smartthings has been integrated into HA.
“integrated into HA” is a work in progress. Many but not all components are currently represented and there’s an important architectural difference. The SmartThings integration requires your Home Assistant server to be accessible from the internet whereas the MQTT bridge does not. Conversely, the MQTT Bridge requires an MQTT Broker whereas the SmartThings integration does not.
Here is an example of an MQTT light (which is appropriate for a dimmer) in HA that works with SmartThings . makes sure to include in lights.yaml or lights: section to recognize as a dimmer. This only works for white bulbs. If you want color bulbs, let me know.
If you compare with your yaml, you will notice some errors. Also make sure your MQTT bridge SmartApp in SmartThings is configured to send data of all your devices. You have to manually go through and select each device in the settings to have it included by the SmartApp.
- platform: mqtt
name: "Stairs"
command_topic: "smartthings/Stairs/switch/cmd"
brightness_command_topic: "smartthings/Stairs/level/cmd"
state_topic: "smartthings/Stairs/switch/state"
brightness_state_topic: "smartthings/Stairs/level/state"
brightness_scale: 100
payload_on: "on"
payload_off: "off"
Your SmartThingsBridge Hass.io settings should look something like this, specifically the preface, state suffix and command suffix.
{
"broker_host": "172.17.0.1",
"broker_port": 1883,
"preface": "smartthings",
"state_suffix": "state",
"command_suffix": "cmd",
"login": "stbridge",
"password": "passwordhere",
"bridge_port": 2080
}Thank you! I noticed that the other day and got it up and running without issues. Just need to figure out how to excluded some of the items, as I have duplicate devices from running certain apps in both hubs (i.e. harmony, nest, etc.)
Just my opinion and not being rude. This thread started asking for help with the trouble user was having. Instead of wasting time setting up this bridge and have problems, if you have your HA exposed this is the best thing you can do. Also in the future you dont have to worry about any breaking changes
The new SmartThings integration is a welcome addition. However, the need to expose one’s system to the internet is a significant requirement (and a non-trivial undertaking). I agree that for those who already have done it, the new SmartThings integration becomes a more attractive option.
Nevertheless, in terms of functionality and performance, it’s not yet an equivalent replacement for the SmartThings bridge. Anyone currently considering it needs to understand if its limitations impact them.
Yes but there are also threads seeking assistance, and reporting problems, for the SmartThings integration (i.e. it’s not without its own challenges). Currently, the winning solution depends upon the user’s needs and operating environment. Perhaps in the future, the SmartThings integration will become the hands-down winner.
Lol your posting issues if there are non with the bridge. Also there are fixes for the issues you posted. I have been using this bridge since 2 years. I am just saying that use the new integration so you can report problems and it gets fixed.
All I’m saying is there are two solutions available and users need to understand their respective strengths and weaknesses.
Been using the bridge for a LONG time, it has its quirks, that’s for sure, but what I really like is even when Smartthings cloud takes intermittent naps or internet access is cut off, HASS can still treat it like a slave locally.
However, after trying the component, it does seem to control OSRAM Lightify RGBW LED strips properly whereas the bridge could not.
Here is my error, Your configuration contains extra keys that the platform does not support.
Please remove [payload_off].
binary_sensor:
- platform: mqtt
device_class: motion
state_topic: "smartthings/Kitchen Motion Sensor/motion/state"
name: 'Kitchen Motion Sensor'
payload_on: "active"
payload_off: "inactive"
Any ideas on how I can fix this?
That doesn’t seem right. According to the documentation for MQTT Binary Sensor, payload_off is a valid key.
Did you recently upgrade to .89?
I upgraded to the smartthings components on .88 on Tuesday, then upgraded to .89 on Wednesday and laughed because all my smartthings components and tplink components vanished.
Looks like .89 is a shot over the bow of custom components that overlay other components.