ditto
Hi!
Here are two different solutions to the problem, I believe either would work:
Yes I know...one of them is mine. 
1 Like
Yes, probably bad posting on my part. The response was really for @variable who just stated he had the same issue as you - but I quoted you so my post would include the issue he was having.
Were you able to keep the MQTT connection working? I had it set up, but probably didn't have it running on the best devices - the MQTT Broker as a windows service and the bridge in Docker for Windows on the same machine. If the windows machine rebooted the connection between the three (Hubitat Hub, Bridge, and MQTT broker) wouldn't reset on its own so I gave up due to it being unreliable. But when it was working, it was great. Currently waiting for someone smart to create an app that doesn't need the bridge.
The removal of the capability let me proceed - though I'm not quite up yet. I had this going on Smartthings a while ago on a raspberry pi with home assistant, but this time I'm on an odroid and I probably won't install it this time - just want mqtt working. Having some confusion in my head with the ports..
EDIT: Wanted to mention, I had some trouble getting it installed (I didn't use docker - for some reason I always have trouble with it). The Node dependencies seemed to be picky for whatever reason - went with nodejs 8 (though had nodejs 7 when I was using the RPI). Had to go through all the dependencies in the package file and install those specific versions. I'm sure there's a more better-er way, but I didn't want to think that hard 
Going to be a long wait. Until there's a MQTT client that can (read allowed) to run within Hubitat there will be a need for a bridge of some form to interface with MQTT.
What's preventing that from happening now, besides the lack of such a client? (EDIT: I mean "app functioning as a client.") I haven't thought this fully through yet, so I might be missing something, but shouldn't it be possible to write the equivalent of a "service manager SmartApp" (like the native Lutron or Hue integrations, which I realize may be able to pull some tricks user apps can't...or even the new ported Hue B Smart app), which can run in response to network events? The lifecycle of an app (it's not always literally running, just waiting to respond to events) doesn't immediately seem like a problem to me--but again, there may be considerations I'm not thinking about. (As I type this, I realize there might be problems with the MQTT broker sending the messages in a format Hubitat can "see"...)
Eliminating the need for a "bridge" would definitely make this a bit easier and a bit less fragile, though I have to say I really didn't have much problems setting the bridge up and running it on the same server (a Pi) as my MQTT broker. That--the broker--is definitely a part you'll always need running somewhere else, at least without drastic changes from Hubitat.
On the other hand, I wonder what other people are using MQTT for. I'm only using it to integrate with Home Assistant. It would certainly be possible to develop a "native" integration with Home Assistant by creating a Hubitat component for HASS, which I've thought about before realizing the MQTT is supposed to give me basically the same thing (albeit with a bit more setup).
Even Home Assistant itself is something I'm mostly still using it because I got used to their device/event history graphs. I know there are other, also-unofficial solutions for Hubitat--including the Grafana one I'm keeping an eye on--but this seems a bit easier, though maybe because I already have it set up. (All my logic was moved off it shortly after I got Hubitat, so most devices I have in it now are just to see their history or current state.)
That's it. The client.
The bridge is a "translator". It takes the MQTT message and transforms it into a format that the "Smart App" understands which then performs the action at the hub level.
If there was a MQTT client on the hub that could sub to the messages directly then an app could be written to translate them locally.
Sorry to side-track, got everything working(sweet!), just one question - how do you send a 'refresh' command? Am using mosquitto and have tried every combination of refresh I can think of:
mosquitto_pub -t 'hubitat/SomeLight/refresh' -m refresh
mosquitto_pub -t 'hubitat/SomeLight/' -m refresh
mosquitto_pub -t 'hubitat/SomeLight/refresh' -n
And tried different cases, quotes on the message, and got nothing. Most devices seem to be pretty quick about updating themselves, but of course the one I want to use doesn't until the hub does it on whatever timer it uses.
Ideas? Is that command not implemented because I found a fringe case(I'm good at that..)?
EDIT: The device is also in the 'Refresh' capability configuration of the app - not sure if thats the best way to word that..
I think I just answered my own question - the driver has a 'refresh' capability, but no matching action (Poll does, but 'SomeLight' doesn't support polling of course..)
Tried adding:
def actionRefresh(device, attribute, value) {
device.refresh()
}
But no joy.
What is actionRefresh? I haven't read the Hubitat docs if they've even documented this yet, but on ST, the command that Refresh must implement is refresh (if it doesn't exist, your code should break when your actionRefresh method is called since it just calls refresh and that's not defined). If your driver doesn't have a refresh method but does have a poll method, try renaming your method above to refresh and making it just call poll (which I think a lot of ST DTHs and some Hubitat drivers really do). This is, of course, assuming that poll does what you want--and that the MQTT bridge will call the refresh method when that command is sent, which I've never tried (didn't even see it was an option, nor did I look for it since I don't have a use for it).
I don't write a lot of drivers, so I could be totally wrong here. But from another platform's docs, I think that's right.
I thought the bridge was created to overcome the lack of local network connectivity that ST provided ? Although it does serve also as accessible code to tweak MQTT topics and payloads.
I don’t see any reason why a Hubitat app couldn’t be written to talk to a MQTT broker directly. You still have to handle topic and payload transformations somewhere (maybe Node-RED) but at least it would do away with the bridge, which is an obstacle to many.
ST has local capability like Hubitat with the provided libraries (telnet, http). Same limitations though with no ability to load external libraries outside of the sandbox provided. No MQTT library means no local MQTT capability. Without the library one would have to write their own entire client stack in groovy. I've asked before about getting an MQTT library native to Hubitat. I asked a bunch for the HTTP capability and the integrations and we finally got those because plenty of other people asked.
First was RM with HTTP post... then came Maker API.... make a push for Hubitat MQTT 
1 Like
Sorry - forgot to reply. I made some guesses from a line in the app code where the line in the capabilities section says:
"refresh": [
name: "Refresh",
capability: "capability.refresh",
attributes: [
],
action: "actionRefresh"
],
and copied from the 'action' section, the polling action and just figured I'd see what happens (nothing)
def actionPolling(device, attribute, value) {
device.poll()
}
Figured it was worth a try. The response to commands it doesn't recognize across MQTT appears to be 'do nothing' - an error would have been nice, but I didn't really expect this to work anyway. Though I know the device does have a refresh command. I'll have to spend some more time thinking about it.
I would like to start using mqtt. There is a very affordable blinds project that uses mqtt. Really would like HE to control them but it is looking to not be possible.
1 Like
Why is this not already possible with the community Hubitat MQTT app, the hubitat-mqtt-bridge node.js app, and an MQTT broker (which you'd need anyway)? If you only control the blinds from Hubitat (or don't care to read their status), you could probably also get away with just the broker and a Hubitat app or driver that sends the MQTT payloads (assuming that's possible to do directly from Hubitat--don't know if enough is exposed in the Groovy sandbox to allow this).
That is the issue. In order to do automation you really need to maintain the status of the position of the blinds. Though there is a possibility to blindly do this but you COULD get into a problem with sending commands that extends the motor beyond its limits and potentially causing issues. Not sure as of yet but will know as soon as I get my test unit.
OK, so then scrap the second part of what I said and use the full Hubitat app + node.js app + MQTT broker, so anything that changes or reports the status will be known to all. I'd be curious what you discover in testing, though!
