Wow, sorry folks, This looks like it was my fault. Initially I installed the SmartApp as Published instead of Self Published. When I corrected it, the problem stayed with the Server 1 MAC address. Server 1 can receive from the hub, but it can’t talk to the hub (I’ll sniff it out later to see if it’s a server or hub problem). So I decided to try it on another server. This time I added the new MAC after I made sure the SmartApp was self published. The new server works perfect. I can turn on the outlet from a curl command (same command fails on Server 1) or from the MQTT topic (Yea!).
And, yes I skipped mentioning reconfiguring the SmartApp to point to the correct server when working with Server 1 or 2. The iterations were many and the problem now obvious.
Now I’ll clean up my code, add the rest of the missing devices and then do a pull request. I see I messed up the readme (Sorry St. John).
I may attempt to add a virtual device for world domination.
Hehe, yes went a bit OCD on the code last night. I’m still a bit lost on why 2 out of 3 of my virtual devices are not working but I’ll look at that later.
I’ll make the PR (pull request, I’m learning ) in a day or two. I’ve added a bunch of log code that needs to come out and I’ve added even more devices (the stuff in the comments. I don’t have all these things so I won’t be able to test them.
Forgive my ignorance, but I’m pretty new at this. I’m trying to apply this to a ST/8266 project I’m working on, and want to understand all the steps.
I’ve created (In the ST IDE) and privately published StJohn’s MQTT bridge Smart App and Device Handler. I’ll customize and load the .ino file into my ESP8266. I think what’s missing is a ST new device handler for the 8266 switch. I assume that new device would be selected in the MQTT Smartapp.
Are you willing to share your device handler groovy code?
With that, I assume I can discover the device and specify it in the MQTT Smartapp under settings “Switches” and “Notify this Bridge.”
Any other pieces I’m missing that are required to make things work?
Also, please confirm my understanding that I don’t need a separate MQTT server running, and that it’s all on the 8266.
I’m just using the “On/Off Button Tile” device type. It can be anything with a switch attribute because the MQTT bridge will send on/off commands from the ESP to the device specified in the code, in this case it was hard coded as “Virtual Test Switch”. So create a new switch device, give it a name, then put that name in the ESP8266 code.
You do still need an MQTT broker for this to work - the ESP8266 is a client, and this bridge is also a client. Mosquitto is a popular open-source option that works on several platforms.
@looie53, you can also play with the simulated devices. I’m trying to get some virtual device handler code working but for the life of me I can’t get that working. At the moment I have a Fubarino talking to MQTT. I had this working with one simulated device (temperature).
Just to clear things up, simulated is a built int device handler, the virtual is device handler code I’ve downloaded. I think half my problem is that I haven’t fully read the docs and I’m trying to do more than I know. Eventually I’ll share all my code. I’m pretty sure someone else may have better examples.
Thanks everyone. I got Mosquitto running on a spare Raspberry Pi last night, and plan to load Home Assistant on it today. This should be a nice solution – better than leaving one of my desktops awake 24/7.
For those nervous re Linux I am using the ThingBox Raspberry Pi image v( v1.8.6) based on Rasbian Wheezy and that already includes the MQTT Mosquitto server, Node.js, Node-RED. Really easy - no Docker - all I did was NPM install the web bridge service as shown in post #46 and the ST app and device handler and away you go. There were a few dependency warnings for older versions but it still seems to be working fine.
The really useful aspect for me here is converging my existing HA system with SmartThings. I can include my existing HA devices in SmartThings and also expose ST devices back to my existing HA system with near instant updates and bi-directional control. This of course assumes you can connect your external devices to MQTT which fortunately is really easy for me and most HA software now seems to offer an MQTT plugin.
This opens ST up to almost any device and works really well for supporting locally connected IP devices like my C-Bus lighting system plus heating, telephony and security. MQTT is the middleware connecting everything allowing you to get around the local processing and IP comms side (even UDP in my case with xAP). Of course it’s still cloud dependent but loads of things are now possible. There’s Node-RED on the Pi too - to interact with your ST things.
Thanks once again…
K
PS One thing I have to think through is how to map an existing device topic on MQTT to the smartthings/thing name/attribute topic hierarchy or vica versa such that the linkage works and can be maintained at either end … e.g. Creating a virtual device in ST that watches a specific arbitrary topic on MQTT representing the real device. What would be useful it appears is a sort of topic ‘alias’ feature where the MQTT server treated the two topics as if they were one and the same. I’m thinking this probably is a frequent need and so some standard solution might exist.
In my home I’ve been using an event-management platform called EventGhost for well over a decade, going back to the X10 days. While it has it’s problems, it’s a fast, reliable, and simple-to-use platform for automation and I still rely on it for a lot of my home use cases. A while back I wrote a SmartApp to publish ST events to my EventGhost server which has been working reliably.
Since getting this MQTT bridge setup I’ve gone and tied EventGhost to my new MQTT broker using the EventGhost MQTT client. There I ran into the same problem as I did here - the plugin wouldn’t work without a leading slash (seems to be a common misunderstanding!) The author has modified the plugin to support standard topic names and now I am able to pass events back and forth between EG and ST (and any other MQTT-compatible platform).
Having a universal event message bus at home is turning into a huge benefit for me. Instead of hacking together REST commands between n-different platforms, I can now throw messages onto a single universal bus and react to them from any device or platform. I’m just beginning to scratch the surface of what is possible and the potential use cases keep piling up. Thanks to everyone that has contributed to this bridge!
Are you integrating any existing MQTT linked devices from your other HA projects in SmartThings, say via a virtual device ? If so how do you get it to be linked to ST as those devices will not have the smarthings/label/attribute topic hierarchy ? I’m still thinking about how best to structure my topics as I have a lot of other projects.
At the moment I have kludged a scripted MQTT client in node-RED that simply subscribes to say topic a/b/c/d and publishes it as smarthings/xxx/yyy and the reverse so it mirrors the topics but that seems rather punitive on the MQTT broker. I may even use a pair of Pi MQTT brokers for this if necessary.
The MQTT bridge at the moment is more suited to exposing internal ST devices to others rather than the reverse.
P.S. Hmm - I wonder if the ST label might allow for an ‘a/b/c’ style of entry - effectively creating more levels in the topic hierarchy for the ST devices - and then I could effectively just strip or ignore (*) the top smarthings level. I’ll investigate… (it will likely break the existing code mapping back from MQTT to ST though)
Though I don’t actual have the devicehandler part working yet. I see the information going though the smartapp but I never see anything in the logs about the device handler getting them. I’m currently reading the documentation to get an understanding of how smartthings works.
On the subject of topics, the smarttthings topics are in the format of
smartthings/ label / attribute
I don’t think that format will change to anything else. Of course I haven’t given it much thought.
Understand I currently have Misterhouse, Node-Red, scripts (Perl, Python & Bash) and some other things banging away at MQTT. Other than MQTT locking up from time to time (grrr, need to see if the latest fixes that) it works perfect. Though I’d better start documenting this mess.
I feel like this approach (or something like it) is the best solution for translating between different topic/message formats. While it might be possible to shoehorn in some setting into the MQTT bridge here, there is very little chance that you’ll arrive at a general-purpose approach that will fit all use cases. For example, Domoticz sends all events to a single topic as JSON objects which makes a straight translation difficult without resorting to something like Node-RED anyway.
I feel like it’s best to use the right tool for the right job, and tools like Node-RED are custom-made for handling this kind of translation.
We could probably move the server.js into a node-red flow (not a bad idea really). So that those of us already running node-red can just add it there rather than start a new server. It seems that the server.js is already written like a node-red flow.
Yes … I think Node-RED is the most flexible approach. The JSON payload is another aspect that I have used Node-RED to get around before and so as it’s available and capable it’ll do nicely.
Interestingly the MQTT plugin for another HA app (HomeSeer) creates it’s own fixed topic hierarchy for devices it ‘owns’ but allows you to predefine any topic construct for virtual devices, as it assumes their topic hierarchy will be already defined. Such an approach would be difficult to implement on ST probably and as mentioned above virtual devices with several attributes get handled by multiple topics so there’s always going to be awkward cases as well as payloads with multiple values that may or may not be JSON objects.
) in a day or two. I’ve added a bunch of log code that needs to come out and I’ve added even more devices (the stuff in the comments. I don’t have all these things so I won’t be able to test them.