Okay, so after struggling for a while to get any functionality between the Hubitat and Home Assistant via MQTT (using the Generic MQTT Driver), I have finally gotten it to work! Yassss From a device created as a Generic MQTT Driver, I can subscribe/publish to topics from Hubitat and from Home Assistant (via Node-Red). I am seeing updates on the Hubitat side after injecting strings/values from Node-Red. Similarly, in Hubitat, the device added as a Generic MQTT Driver has a Publish MSG command which I am able to use to send custom strings (published to topic in the MQTT Broker) successfully. By doing this, I am able to receive the string in Node-Red and use the message to trigger certain events on the Home Assistant side.
Now, although this is a big step and I am satisfied with my progress, my end goal is to use the Samsung Multipurpose V5 sensor (paired in Hubitat) to trigger effects to my WLED app (in Home Assistant) when acceleration becomes active. This is where I am now running into problems, as I have spent most of the night into this morning attempting every conceivable method (albeit being a complete newb to this) to use the acceleration active status as a trigger to either publish a state or MSG to the MQTT Broker. I have tried using Rule Machine and Modes but have found no way to achieve this.
Does anyone have any idea or known method of doing this? Do I need to be using a certain community app or is this something that should be done by editing the actual MQTT Driver code, as I have tried playing around with the Salt Tank MQTT Driver .groovy file(published by developer Aaron - [PROJECT] Salt Tank monitor using Arduino & MQTT ) where he implemented a switch into the Driver but it appears to be taking events in to the Hubitat to control the switch, which I'm trying to do the opposite? If anyone has any experience or could point me in the right direction, it would be greatly appreciated as I don't have experience writing/editing .groovy files and my next step was to just blindly start modifying the .groovy MQTT Driver code.
I have written an extensive MQTT app that is currently available 'on request' in an alpha version. I am just finishing another release which has some major revision to the way virtual device drivers are implemented. It will be available as alpha5 and then assuming there are no issues it will become beta1 which I'm trying to make available before Xmas.
It will do what you need.. and additionally supports auto discovery of HE devices into HA and HA devices into HE.
I would suggest waiting a couple more weeks and then trying out the beta app...
Kevin
PS The alpha version is aimed at existing competent MQTT users with devices already using a broker who can provide feedback and bug testing rather than people just venturing into the MQTT world who might need more general help.
Since I am a noob when it comes to MQTT, I'll wait.
I do have an application. I now have a generator monitoring and control app, GenMon (GitHub - jgyates/genmon: Generac Generator Monitoring using a Raspberry Pi and WiFi), running on a raspberry pi and connected to my Generac. I have another pi now running Mosquitto and I am able to pass generator events over to the Mosquitto server and see them there with MQTT-Viewer. Logical next step is to extend this over to Hubitat.
Looking through this thread and various code examples, I don't see anybody handling re-connections if the connection is lost. Can anyone point to code examples of handling connection drops and auto-reconnecting with this mqtt client?
My alpha code does handle reconnects - but more by implementing something that seems to work than design. The people who had early issues now seem happy with later versions. I havenât seen any other code examples anywhere. Public beta soon although currently under a restrictive licence.
Does this api support tls? I want to try to reverse engineer something using azure iothub which requires tls for mqtt. @chuck.schwer I want to make sure itâs even possible before I start trying to figure out all of Microsoftâs over engineered requirements!
I wouldn't call requiring tls "over engineering". I would call that good basic security when the traffic is leaving a trusted network.
That isn't the part that is overengineering. They require you to jump through a lot more hoops than anything I've ever looked at. If Hubitat doesn't support TLS, there is no reason for me to investigate all of the other things (you have to do a multi-step OAuth 2, plus shared secrets, plus X.509 certs, plus HMAC256 hashes, etc.) since I'd be dead in the water if TLS over MQTT doesn't work. I agree TLS is important here... It's everything else that's killing me!
Yowza. That does sound a little over the top/over zealous/over engineered... Over SOMETHING anyway. 
Yeah it's fun... I've been trying to reverse engineer the Kohler Konnect app. I'm close, I just can't figure out how to get the shared secret. Unfortunately their android app is pretty heavily obfuscated making it hard to just decompile it and find out what it's doing. I'm in it for about a hundred hours so far 
Have you tried past versions of the app to see if they are also obfuscated? I've found in some cases the first versions of some apps aren't obfuscated (like Rapid Ring).
Just install Webscarab on a laptop and point your phone at it as a proxy. Then intercept all of the communication.
That wonât work. The app has the api websites https certificate embedded to prevent mitm attacks. So unfortunately I canât use a proxy
You still can MITM but it becomes much harder. If you are lucky the certificate is not in compiled into code and it's just a resource. You replace it which breaks the signature on the apk but then you run the app in a phone where you can tell it to ignore signatures or you resign it.
If the certificate is embedded in code (those devils) then you can decompile, replace it and recompile. This is a giant headache so you have to decide how bad you want it.
Another fun option is if they use one of the recommended methods of certificate pinning... you can install the Xposed framework and then use one of the unpinning modules. I've had mixed success with this.
If you don't have an Android phone anybody can have an Android emulator.
Good ideas but I got stuck a bit trying to do this. Their app doesn't work in an x86 emulator, It has to be the arm version. I could not get the arm version to run on my laptop, it froze and crashed so I gave up eventually.
As I'm sure you know even if you had the arm emulator working there's no gaurantee it will work for a MITM. They may obfuscate and make decompilation and recompilation really hard. They might have nonsense in code you would have to rewrite because it checks for a given code signature or apk size or who knows what other things... There's no guarantee. You might be able to get a pretty good idea of what the code is doing by looking at the source though if it was all done in Java (as long as they aren't invoking a C++ binary within the Java).
As far as the arm architecture, yeah, that can happen sometimes. If they only compile for arm then it's best to have an arm device. I've never tried to get the arm emulator to run on x86/x64 because it's so easy to come by Android devices. I have tens of them. Old Android phones are a dime a dozen. If you want a suggestion, buy an old Nexus 4 or 5 on the eBay on the cheap. They are ridiculously easy to root and have tons of flexibility for this type of haxz0rxing.
Even if you miss on this project you might be able to use it on another project. I did this type of thing to figure out the Ring private APIs but that's not why I had any of it setup. I first tried to use it to understand what Wink was doing to control their relay. Then I messed around with the Anova sous vide cooker and their cloud and local communication protocol. Now, I just have it available anytime I want to try and get an idea of what's going on in somebody's app. So, if it's a hobby like it is for me, I think a Nexus 4 or Nexus 5 is definitely worth having around.
@chuck.schwer @mike.maxwell @bravenel any chance someone can respond on whether or not the MQTT client in hubitat supports TLS?
It does not.
... but I guess you could use a local private (not accessible/exposed/TLS) broker and then bridge that securely within MQTT to another TLS secured broker...
