Release of new Bridge based on smartthings-mqtt-bridge

[sgupta999]

I have significantly refactored and update the old smartthings MQTT bridge. Please find it at

https://github.com/sgupta999/mqtt-bridge-smartthings 1

This is really beta version 1.0 as nobody besides myself has tested it outside my development environment

I am using it to integrate my Tasmota flashed devies, Custom MQTT devices and Sonoff RF devices using RF bridge.

They have been working flawlessly for me so far.

My hope is that if you have an MQTT broker already running you can get up and running in less than 15 minutes with working devices etc.

Please leave any issues and comments on github. I can’t promise how soon i will be able to get to them but I will try my best. I really could not find any things like this so for anyone using Tasmota this hopefully will be helpful.

[raisingskell]

Very nice to see work continuing on the bridge. Thanks. On Windows 10, installed mqtt-bridge-smartthings but running it throws an error. I'm sure I've done something wrong. The gist of the error is:

No previous configuration found, creating one internal/fs/utils.js:525 throw new ERR_INVALID_ARG_TYPE(propName, ['string', 'Buffer', 'URL'], path); ^ TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be one of type string, Buffer, or URL. Received type undefined

Thoughts? Thanks

[sgupta999]

raisingkell,

You need to create a config.yml and devices.yml (devices.yml is optional) to configure your MQTT broker address and other parameters relevant to your local environment. Use the example files, edit them and save them as config.yml and devices.yml respectively.

Since it did not find a config file it tried to load the default sample and there was a small bug I found since I had never tested it without a config file.

Either way without an MQTT broker address specified in the config the server will not operate.

I have updated the mbs-server.js on my github page.

You can

1. Specify a config file - and server will run
2. download the latest mbs-server from github and run - server will run but without mqtt broker address eventually fail.

could you please enter this as in issue under the current project as I will be tracking there

https://github.com/sgupta999/mqtt-bridge-smartthings/issues

[rct]

@sgupta999 - just looking at this. On your README it says

Unfortunately, the old solution was more targeted towards HASS-IO integration.

I'm a Home Assistant user, which version is more appropriate for Home Assistant users? What is the downside or being targeted to HASS?

(I haven't installed either version yet. It is on my list of things to do.)

[sgupta999]

rct,

Like I mentioned although I have refactored and updated a lot of the original code all the original functionality is maintained as before. I have introduced significant new functionality.

Since the original package was designed for HassIO integration my assumption is the new package should also work with Hass-IO. so if you have been using the original package everything should remain the same.

Since I do not have HassIO installed I have no idea what kind of topics Hass sends. You would be ideal to test, if you are game, if any of my refactoring has broken any Hass IO integration.

the new functionality I added has a lot more flexibility and I have no doubt if you know what you are doing you should be able to integrate to Hass using just the config files.

The legacy functionality made assumptions about how Hass and smartthings topics are structured so you didn't need any config files -

The new code is essentially allowing you to map any MQTT topic to a smartthings compatible topic (which is still very flexible and can generate events on ST capabilties/attributes as well as custom attributes).

So if the old structured and constrained topic format worked for you this should too

reading your comment since you didn't install either version what you would use will depend on your environment.

1. If you are using standard ST devices with standard attributes controlling basic operations the older stjohn library would suffice.
2. If you are using custom ST devices with custom attributes (for e.g i am using Tasmota flashed sonoff devices) or you are trying to integrate devices from Hassio and say other MQTT devices then the new packages would allow you to do that.

for e.g. in the old package one topic was mapped to one attribute, in a predefined format. as long as you followed that format you were good.

In the new package a device can subscribe to multiple topics from multiple devices - so you could create a composite device that would say report switch status from one devices, sensor status from another etc.

[jmcclure0921]

@sgupta999 You didn't happen to add MQTT discovery for home assistant did you?