SmartThings gateway transport

  • I have created a gateway transport for the SmartThings hub. It works for me but it's definitely a work in progress. There are two pieces to this:

    • The MySensors gateway transport for SmartThings here.
    • The SmartThings gateway device handler located here.

    This is an Ethernet gateway transport that is designed to run on a Raspberry Pi 3 gateway. I have no plans right now to adapt to other platforms but feel free to contribute and add that support for other gateway devices.

    SmartThings has an API that is called via an http POST method. Right now this is a one way transport and that's from MySensors to SmartThings. It doesn't handle an http request from SmartThings to the MySensors gateway. I have gotten http requests to work from SmartThings to an esp8266 and an arduino with a W5100 though, so I know it can be done. You have to host a webserver and I think it's not working on the pi because the ethernetclient.cpp/ethernetserver.cpp is custom for MySensors on linux.

    You also have to install a SmartThings device handler for the MySensors gateway on SmartThings. The above repo contains the device handler and an example motion sensor device handler.

    I learned a ton about the way that MySensors is working and also the way that SmartThings works. I'm happy to answer questions and share any of that knowledge as I'm able to.

  • I've thought a little bit about the communication coming back from the controller (SmartThings hub) and I don't really need orchestration right now coming back from the controller for a couple reasons. The biggest reason is that the light switches and things I have taking action based on some other sensor (motion turning a light on for example) are all off the shelf switches that don't come through my MySensors gateway they communicate directly with the SmartThings hub. I had bought these before I discovered MySensors and started building my own devices. However, I have plans for other nodes that will need to take action rather than just report data so I'll need to solve it eventually.

    There are a couple of solutions that would work in this instance though. One, is to make the SmartThings gateway transport work for arduino and/or esp8266 (or esp32). I did it on the Raspberry Pi because that's what I wanted to run as my gateway. However, making the transport work on the other hardware platforms would allow for the usage of the standard ethernet libraries and I know that works for bi-directional communication over http because I've done it before on a MySensors node and that's fairly straightforward.

    The second thought if staying with the Raspberry Pi gateway would be to have a node (arduino or esp8266) that is dedicated to receiving http requests and just passing those along to the gateway which in turn could process the message and pass it along to nodes like a light switch, actuator, etc. This would introduce some latency although for me this wouldn't really be a concern because it would be milliseconds and for my use this doesn't matter. It increases complexity slightly as it's adding another hop and therefore another point of potential failure. Again, probably a minor concern but worth noting. The advantage is that it works with the standard ethernet libraries and is well documented and I've got experience doing this so it would be a 'quick win'.

    The other option would be to dig into the Linux versions of the MySensors custom ethernet libraries and change / extend those to make the webserver http communications work. Don't really want to do that though.

    For me at least the easiest, quickest option is probably the second to stand up a node dedicated to receiving http requests. With probably moving more towards the first solution as time allows and moving off the Raspberry Pi as my gateway and going back to an esp8266 or the newer esp32. That would mean modifying the gateway transport I created, which is fine, and putting the code in there to allow for that. I was using an esp8266 before and I moved to the Raspberry Pi because I had one and this seemed like a good use for it. I had problems at times with the esp8266 hanging and then it had to be restarted which was kind of a pain, so I moved to the RPi. My guess was that it wasn't timing out/closing connections from clients and I could probably fix that.

    Just some thoughts on the topic if anyone is looking at how to get orchestration back from the SmartThings hub. It's very doable though and really not too difficult for either option and probably other ways than what I've mentioned. Other thoughts are absolutely welcome on the subject.

  • There doesn't seem to be a ton of interest in this but I wanted to provide an update. After writing the transport and using it for a bit I've decided to go another direction with the integration to SmartThings. I felt like the custom transport would require more maintenance and I wanted more of any option that was configuration rather than coding. Because there was C++ code on the MySensors side of things and then Groovy on the SmartThings side it just seemed like a brittle integration with the design and how I wrote the code. SmartThings is going to be moving in another development platform direction as well at some point.

    I'm working on an MQTT solution with Mosquitto and Node Red (on a Raspberry Pi) and it will also require some Groovy on SmartThings but a much simpler solution IMO. There will be more to come and I'll share here when it's complete but I do have a prototype/proof of concept working. The two way communication is much better/cleaner IMO than how I did it with the transport. If this is something that interests you let me know and I'd be happy to collaborate.

Log in to reply

Suggested Topics

  • 2
  • 5
  • 10
  • 2
  • 17
  • 6