I'm trying to set up a virtual device to control my Garadget MQTT door opener. I may be missing something basic. It uses json to get back the status of the door. The command is basic with just open or close. However when I try and open or close the door in Hubitat I don't see the command make it to that device in my mqtt broker.
I do have MQTT set up properly as I have all my devices in Hubitat accessible and controllable in Home Assistant.
Just got a chore to finish and will take a look after but try taking the leading and trailing ‘ off the values.
What is 'get-status' in the command payload.. I've just just read the doc so, in this implementation you're only going to be able to use 'open' or 'closed' as status and open/close as commands.
Thanks! That unfortunately didn't make a difference removing the quotes.
'get-status' is a command you can send to it for it to refresh the status of the door, wifi signal strength, and light level in the garage. I have an automation in homeassistant to send get-status every 2 minutes to it.
Really, it should have done? So still nothing on the command topic and doesn't update status ?
I'll set it up here and check it..
I'm sure you're aware but you could also set the garage door control up in HA and then import that device into HE for control. But the other way you're trying should work too.
Correct, still nothing on the command and status doesn’t update.
Thanks for the recommendation on home assistant import. I tried to import the cover into hubitat from homeassistant with your app, but that was unable to control the garage door as well. The new device showed up in hubitat, but the status and control didn’t work. I then verified in homeassistant that control of the garage door (cover) worked successfully.
Then I decided I would just try and do straight mqtt control rather than hopping through homeassistant.
I tried to set up the device again, but this time create a virtual garage controller from inside the MQTT app. I named it MQTTGaradget. I configured it the same way, but still am having issues with none of the commands getting through to the MQTT Broker.
I also saw a new warning message pop up in the logs this time about no attributes.
All MQTT virtuals must be created within my app. Otherwise they can’t be child devices. However there is still a issue I think but will report back ASAP.
@hovee This was a missing attribute check for 'contact' in the code. It's now added and will be in hotfix beta3a I just want to check there aren't any others before posting.
Control of the 'door' attribute wants removing from configurable topics too.
Anyone else anything to report (apart from above) before I post the hotfix ?
@hovee Not quite there on this yet - having a bit of think on this one ..
The status reported is open or closed but the commands used are open and close. I currently have only one _Map value where I store these, shared between the _Cmd and _Topic. Hmm
I could 'kludge' it and convert closed to close in the command or probably better you enter [close,open] and I recognise close as closed which is sort of right because it's a device.close() command but there are probably a few similar treatments to this for other devices.. I don't really want two _Map value fields.
Thanks @kevin! I understand your issue with this. I agree that you don't necessarily want two _Map value fields, but would that provide the most flexibility? However, I like the idea of recognizing either close or closed and maybe do the same for open and opened? Trying to think what would give the best options for you in the future so you don't have to modify it again.
It would but it alienates users who are venturing into MQTT and I want to make it as friendly and easy as possible.
I have a workable solution for you which will be in next version. If you can think of other attributes like this I'd like to hear. open/opened doesn't cause the same problem here as close/closed. The virtual garage door controller operates unusually in that a 'closed' command doesn't send the 'close' event to the handler immediately but instead after a simulated delay whilst 'closing'. I think I've worked around that too for you though.
What I have found is there are a number of virtual devices that need some TLC here to work functionally with _MAP values. I'll address a couple for the next hotfix and more if people need them. I will probably give virtual thermostats a miss for the time being though.
Just starting to play with this a little and getting stuck on discovery in HA. I'm using mosquito installed through supervisor with auto discovery enabled.
On the MQTT app, under publish formats I turned on all 4 toggles, set discovery topic to homeassistant (also tried /homeassistant), and selected remember.
In the logs for mosquito I see
1590585092: New client connected from 192.168.2.12 as Hubitat_hubitat-mqtt (p2, c1, k60, u'mqtt').
When I connect to the mosquito broker through mqtt explorer I can see hubitat-mqtt there.
Hi Mike, should work... , there is a minor update coming in beta3a that helps with multiple entities but that won't be an issue here.
Have you published some devices from Hubitat ? I think I see one the 'closet-light'. It also looks like payloads are being published to your homeassistant topic. The closet light should be in there like my counter-far-test
Have you checked in HA under the : 'Configure UI' .. 'Unused entities' as it typically shows up there ?
I have heard of 'issues' with this setup and it's now deprecated by HA I believe - however as my topics are all showing as populated on MQTT and assuming HA itself is accessing the broker OK (do you know it is ?) all should be OK.
That makes sense to make it user friendly as possible, and that is something I appreciate your solution you've created. Really appreciate your hard work!
I came down today to a crashed 'development' hub. No web access or :8081. Even worse I hadn't backed up beta3a for a couple of days work on the next release. I was so hacked off with myself as I am normally more careful re backups.
After contacting @bobbyD rather hoping he had access enough to recover my app code as the hub could still be pinged (they dont), he went through some basic troubleshooting, the sort of thing that as a knowledgeable user you hate, and then we pronounced it dead.
However as a last resort while laying it to rest he suggested swapping the hub port and bingo it worked. So big kudos to @bobbyD who has just brightened my day, and readers yours too, considerably.
