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.
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!
You could also use this setup but connect your servo using the Hubduino project and an esp8266 board. I am using that for all my blinds. Direct control form HE through LAN. No broker or MQTT needed.
All are controlled with ESP8266 boards (mostly Wemos D1 Mini). Some of them are using a custom driver and software. I have a couple copies of the Arduino sketch in here cause I made some modifications from the original. Also, the driver has the switch function added but "off" for this version was 180 (all the way up). You'd just have to modify the driver to order 0 instead of 180 for off. https://github.com/ryancasler/Hubitat_Ryan/tree/master/ESP%20Blinds
Now, what I've since done with most of my blinds, since it's silly having this board only doing one thing, is integrate them with the Hubduino project. This allows me to have a contact sensor and blinds control all in one board. Now, the driver for the servo component no longer has the on-off function but it still works. And it controls them faster than the old program did.
Be very careful of what type of power supply you choose. Don't try and power the servo off of the board. It won't have enough current in most cases to get you enough torque. For my living room. i actually bought a more expensive servo that requires 7v as opposed to 5. The wiring on that on was a PITA (I have a 12v supply that i regulate down to 5v for the board and 7v for the servo) but the servo is able to close my 8' blinds, no problem.
I can say this...this is was one of the most difficult projects I've done since I started home automation but it is definitely the one that I enjoy the most and am the most proud of. I had no experience with 3d printing before this and very little coding in the arduino IDE. Hut they came out great!
Interesting. I've been powering my servos with my Particle Photons. I wonder if they're just better. I don't have a lot of run hours logged with the things so maybe it would have killed the boards if I let it run for a year or so..
I've almost exclusively using photons - the ability to OTA program, or rather, the way particle does it, its just hard to pass up (though I'd love it if they had an ethernet version - 2.4ghz is getting pretty darn crowded...)
Back to mqtt - I didn't actually try it till now as I was looking to grab power meter readings (for my particle photon project!), but I just noticed that I can't actually control anything over mqtt, just read. The events get published when devices are interacted with via non-mqtt, and my 'pub's are published, but none of the same commands actually do anything when sent via mqtt.
I don't think I broke it when trying to get it installed, but I can't rule it out... not sure where to start troubleshooting this - more importantly, has this come up already and I just completely missed it? (I'm only human!)
Yes.. I know I can program an esp8266 with ota - I even got ota working with a bluetooth dongle on a mega2560.. but, this is prettier. Also, (yes yes, I know, there espxxxx's with it too), I'm a big fan of the u.fl connector - or rather, the ability to have an external antenna (u.fl's are actually pretty annoying, but in principal..) I really quite like the nodeMCU form factor, but its slim pickins when you need/want an external antenna. As for price, I hadn't really thought about it in a while - I've got a hand-full from work and they've kept me busy enough, but you're right, comparatively they are pricey.
But.. that's a topic for another forum Any thoughts on what I might be missing with the MQTT stuff? I'm assuming that its either not been a problem for anyone else, or they figured it out themselves? I'm grasping at straws - I don't even know which end to go looking for a log.. nothing shows up in the hubitat events, and I think mqtt/mosquitto is working fine, though I haven't actually gone after the mqtt bridge package, I guess I was expecting something to stand out.
Commands not working is usually with the MQTT payload difference of it being a /cmd or /state and it's different between ST and Hubitat. I haven't messed with this in a long time but if I remember that was generally the problem.
if there weren't sharp objects on my desk, I'd be banging my head on it... talk about the devil in the details, I was missing a 'space' in the topic..
To be fair (to myself), for some reason, the lutron dimmer I'm playing with is picky about the level being set.. so you can set the level without the switch being on, but if you set the level to 0 with the switch on, it will turn off... *sigh*
Thanks for the MQTTfx suggestion - that's where I found my missing space.
Going to move sideways a little bit here. I have been using the smartthings/hubitat-mqtt-bridge for some time on both platforms to interface SmartThings/Hubitat to Home Assistant.
However - I just found the Hubitat Maker API...
Has anyone seen any 3rd-party platform integrations based on this API? Seems way more straight forward and powerful. Discovery, enumeration, control, interaction. Appears to be all there.
I need to find someone with far better HA architecture and python knowledge than I to consider a Hubitat integration via Maker API. Would absolutely tie all my home automation dilemmas up and probably bring world peace upon us.
Anyone else having issue with running VIM or Nano on the container included? I always get command not found. I even installed Nano, watched it install and still it won't let me open _config.yml .
EDIT: OK I was able to copy a new config.yml into the docker container directly but I still keep getting warnConnection refused (Connection refused)
EDIT2: Is this not a broker itself just a middleman?
I don't know how if there's no authentication options in the device driver?
Containers are not meant to be edited. By design they are immutable. The source and information is in the github. Changes are made at the source level or in the dockerfile then you build/deploy the container.
With that said you can edit the container but the changes are ephemeral and will not exist after a restart of the container. Vim, nano probably won't install because the dependencies are not available inside the container.
No it's not a broker itself it's a translator between what ST/Hubitat understand and MQTT.
I'll try to make some time this weekend and pull down and update the container and document any changes.