Sonoff DIY + Tasmota flash on ST
They are the ones producing them. Direct link here:

1 Like

Device Kit will support the chipset but custom firmware will need to be baked to flash for each device. It would then speak directly to SmartThings severs via MQTT using our capability models.

The next way to do it would be to host a local endpoint smartapp connector that communicates with our cloud on behalf of your devices as a bridge.

Sounds very cool. Hope capable people will be able to cook up firmware in a hurry :smiley:

@Anders_Dalsgaard docs are live now

If someone wants to take a crack at a sonoff implementation

@jody.albritton, isn’t this a bit of an overkill?

  • Prerequisites

Active enrollment as an organization member in the Developer Workspace

How can be anything developed and tested by simple users? Should anybody who wants to write some code register an Organization?

Have a look at this topic @DrJon

Otherwise this DIY option looks really interesting. From the documentation is not clear, when the DIY activated through the jumper does the eWeLink connection deactivated?! (If the eWeLink connection is still active, then it still runs through China too.) But the whole solution of the DIY LAN access is similar to the Shelly’s LAN API or @erocm1231’s solution, but @erocm1231’s firmware adds password protection of the device too, what is a really good feature.

You can find more topics about some Tasmota integrations too, but if you can flash a firmware try the mentiones topic’s.

You can even use @erocm1231’s Tasmota fork, what is discussed in the topic.

Otherwise, the LAN mode/DIY mode support only local control according this review.

@jody.albritton, the LAN mode provides a REST API almost out of the box for the new Sonoff devices. It would just require a websocket integration with mDNS discovery. It could be even a local DH if someone in Smartthings would write the code for it. You could extend the Sonoff integartion in the new app.

At the moment hub connected devices are being re-designed. Zigbee and ZWave devices will come first followed by Lan connected. I don’t have a timeline but the current groovy implementation is probably not going to be full featured enough to get where you want to go. The links I provided above are a solution for today knowing that down the road we might have something better.

1 Like

I was in your boat a couple of weeks ago. I just posted a revamped MQTT bridge that should work hopefully with most tasmota devices.

From a manufacturer point the SDK and the example is awesome, if you would start to build your device now and want to have easy integration. But we (simple coders) still haven’t got a way to build our ideas in the new development platform and for the new app.
The idea is great, how it should work. But it is still focused only the on the manufacturers/developers. A lot of us would love to rewrite our DHs to be able to integrate into the new app with full features. Even if it be zigbee, Z-wave or LAN connected.

What do you mean when you say simple coders vs developers? The SDK can be flashed to very inexpensive hardware and have a direct connected cloud device in a few minutes. Z-Wave, Zigbee, and Lan improvements are coming in the near future too. As of today you can still port your zigbee and zwave DTH to our new app via the dev workspace.

Any feedback you have would be great.

1 Like

@jody.albritton, finally I have some better internet connection and managed to log in to the developer workspace. My concern was the “organization” assignment. Previously (months ago) when I logged in, I had to assign myself to an organization. I see that restriction has been removed, and I can create project, device profiles etc. It is indeed really impressive. (Maybe we should move this discussion to a different topic.)

By looking through the developer workspace menus and at the functions it makes more sense the integration to the new app. Indeed, I am really impressed. It feels a bit awkward after the groovy way, but makes sense and probably gives at the end a better end user experience. I am away from home, but I have a NodeMCU with me, so I will try to build a basic project with the example what you have linked above.
The only disappointment what I have is the list of capabilities and the documentation. There are capabilities what are in use by some of the official new integrations, ie. Audio Notification, by the new Sonos LAN Websocket DH, but it is neither documented nor listed on the place where the device profile has to be defined.
Actually most of the capabilities of the Sonos DH are not documented in the developer workspace documentation, but listed in the old SmartThings documentation pages only, and that is obsolete, I guess.
And just for @Automated_House, Jimmy, you need to log in and start to build a device profile. It gives you the new UI options how it will look like the integration in the new app. You are going to like it.

Thanks again for the heads up! If you can give some details how is the Zwave/Zigbee integration can be done with the new capabilities and device profiles that would be great. (I had just limited time now, and I would really appreciate a pointer how could I integrate my DH of window shade/rolett controllers and some iTRVs)
Really great work! Thanks! :+1:

now i’m having fun!

1 Like

@jody.albritton what I dont quite understand is that you have MQTT supported as both the broker and the client in Smartthings, but why cant we use MQTT to talk to any MQTT device? why are we restricted to just the specific Device SDK?

I thought the point of MQTT was to be device independant so we can then manage the message and do something with it!

If you are restricting MQTT to just your own client, then your missing the point of it.

Tasmota has MQTT built in, so why couldnt we just use MQTT to talk to it and controll it?

@DrJon there are several solutions to the problem you have. If you have Sonoff switches and dont want to flash them, you can use MQTT as explained by @Tech_GFam

BUT there are other solutions. Many people flash Sonoff with Tasmota, and there are some good videos on how to do this. Along with an extensive community and support. The wiki is very clear on how to do this.

There is also so custom F/W someone wrote with a specific ST application which creates the drivers. I personally didnt like this route because it was only a subset of the devices out there. BUT it might suit some people.

There is also Betts device drivers which some people are happy with… Personally I use this and have it working with touch switches, minis, ifan03, and the shelly 1 which was flashed with tasmota.

BUT if I had found the MQTT solution sooner I might have only used this option. Instead I will be going down this path in the future as I have a Shelly 4 pro which wont work with tasmota.

Our implementation is a direct cloud connection scenario that does not require any middleware. Our design is such that you do not need a cloud based device handler. All of the knowledge of or capabilities is baked into the firmware. This is just one way of using MQTT. I think your broader question, (correct me if I am wrong), is can you subscribe to our MQTT service and get events and then can you send command events in from a non-device source.

Ok so I get what you are saying
And so Yes my question is why can’t you subscribe to topics from Non ask devices to get status and send commands? Which you are implying we can’t.

Therefore isn’t saying you are using mqtt misleading, because all you have done is provided a device client you can easily discover and communicate to; and users have a customisable client they can install. the communication protocol just happens to be mqtt but could have been anything.

From Richard

MQTT is just the transport in any case even Tasmota. Tasmota could be used to create a generic client where you configure the MQTT server of your choice. Our device-sdk is meant specifically for directly connecting devices to the SmartThings cloud in an easy fashion. The SDK is the sum of all of the parts you would otherwise need to assemble yourselves to build the same thing. In the generic messaging scenario you would send arbitrary messages to the bus and then need to interpret them in some handler, our SDK has a specification for pub/sub in a way that is specific to the SmartThings cloud, removing the need for a separate device handler. There is nothing preventing you from making your device available to other systems.

Sorted, bought one, installed and much better than using the tasmota flashed version.

One thing I’m struggling to sort is, I have the sonoff connected to my kitchen Light which is a tube light. I want to set a timer for it so it automatically turns off after a certain time, say 30 mins. How can I do this pls??

I used tasmoata to flash it with this method:

then you need to add this device handler:

then you need to add a virtual device to your smartthing put on your virtual device your device IP address, and the port
then go to your phone add things to discover your device

1 Like