Well no-one expects the unexpected 
Is there anything useful showing in the logs that appears just before that error ?
app:972020-06-02 08:21:16.409 pm errorgroovy.lang.MissingMethodException: No signature of method: user_app_ukusa_MQTT_122.none() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@173c995] Possible solutions: run(), run(), wipe(), find(), any(), use([Ljava.lang.Object;) (none)
app:972020-06-02 08:21:15.191 pm errorgroovy.lang.MissingMethodException: No signature of method: user_app_ukusa_MQTT_122.none() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@f62656] Possible solutions: run(), run(), wipe(), find(), any(), use([Ljava.lang.Object;) (none)
app:972020-06-02 08:20:35.681 pm errorgroovy.lang.MissingMethodException: No signature of method: user_app_ukusa_MQTT_122.none() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@619a1a] Possible solutions: run(), run(), wipe(), find(), any(), use([Ljava.lang.Object;) (none)
app:972020-06-02 08:20:25.073 pm errorgroovy.lang.MissingMethodException: No signature of method: user_app_ukusa_MQTT_122.none() is applicable for argument types: (com.hubitat.hub.domain.Event) values: [com.hubitat.hub.domain.Event@1ce735b] Possible solutions: run(), run(), wipe(), find(), any(), use([Ljava.lang.Object;) (none)
That's an event being thrown with no matching handler 'none' but I'm not sure what originated it.
When it broke can you remember what virtual device you were currently/last working with and delete it manually ?
Otherwise remove/uninstall the app and then create it again. You will lose all child devices. If any persist then delete them.
If you do find a way that creates this error can you try and give me a step by step to reproduce it.
Update: This is now fixed in next version but it doesn't harm the running of the current version.
Will do
hotfix beta 3b is available with a couple of bugfixes and support for HSM, please update both app and MQTT client driver
BugFixes:
Child client creation now works correctly upon new install
Absent event handler 'none' now fixed
HubName present in MQTT client immediately avoiding 'temporary' name
MQTT client driver updates (please update this too)
Changes to default settings at install
Other minor fixes
Features:
Sunrise and sunset times reported in /hub/... topic
HSM status now reported in /hub/...
HSM Arm status now settable via hub/hsmArm/set
... with enable/disable protect via the configuration menu
App can now be completely 'Removed' from the main menu, this also deletes all child devices (careful - be sure you intend to do this)
Kevin, first of all thanks for your hard work. I look forward to the official and stable version. 
Wanted to ask if you intend to offer your MQTT app via Hubitat Package Manager. I think it would help solve many installation issues and upgrade.
Thanks again.
1 Like
I do indeed. I wanted most people to manually update to beta3 as it requires a deletion and creation of a new MQTT client driver and HPM doesn't handle that automatically. Of course you can delete the old driver manually. Once at a beta 3 the updates will work transparently through HPM and the release version will be in that.
There are only minor issues in the current beta and so, unless something major is found I don't intend a beta 4, going instead to a release. There will still be some features that need expanding like incoming homie discovery but they are incremental improvements. Not long now I hope.
So IIUC, once at beta3, HPM should pick up the MQTT installation? Because right now I upgraded to b3b manually (I deleted everything, app/driver/etc. since I was just testing things) but HPM doesn't detect it when I do the match-up of installed apps/drivers.
Or probably I didn't understand and you are waiting for b3 to be spread before publishing MQTT to HPM.
Great to know we're close to a release version.
exactly - well actually I will probably include it in HPM once it goes to release. If I add it now it will probably pick up beta 2 installs which I don't want it to. (I'll check)
Thanks for clarifying.
So I'm going backwards on this and just realized this is rather recent. So question, does this look correct?
I don't own a Garadget so hopefully @hovee will check them over but
door MQTT command topic
is certainly wrong as [open,close,stop] isn't a topic value
I think your [closed,open] should be [close,open]
PS I know my data field editor has a mind of its own at times - just persevere and they'll become correct - watch out for errant spaces at the beginning of fields.. If Trent can post a screenshot of his Garadget device data values that would help I think.
1 Like
Thanks @kevin!
@jrfarrar I made a post over here that shows screen shots of the correct settings.
Looking at your pictures...
- contact attribute MQTT status topic is correct
- contact MQTT command topic is correct
- MQTT payload for contact is incorrect for your garadget. It should be:
[close,open] - door attribute MQTT status topic is correct. It should be blank
- door MQTT command topic is incorrect. It should be blank as well
- MQTT payload values are correct.
1 Like
I think you meant to put an 'I don't really mean that' emoji by that.
Thank you for the update - I was a bit surprised to see this post in a different thread TBH and, assuming it wasn't working I didn't want to mislead @jrfarrer with incorrect info. Much appreciate your post Trent.
Haha no way! You’ve helped me a ton!
I noticed that, thanks! Had a heck of a time clearing out a field. FYI I think using a space was the way I did it.
Ok I don't know how I manged to get so much wrong with so much info from @hovee that I thought I followed...WOW.
Swear I thought I followed that. Clearly I was tired or drunk or both.
Thanks you both. FYI the status was working...however the commands were hit and miss. Sometimes it would close (or open) and sometimes it wouldn't. We'll see how it goes now.
Haha! What you drinking?
Also, just so you know, pressing open from Hubitat will open the door immediately, but pressing close, there is a 5 second delay before the close command is sent. @kevin is aware of this and this is partially due to the transition time logic for a Virtual Garage Door controller. Make sure you have your transition time set to 5 seconds. (See pic below) I think it'd be great if the Virtual Garage Door Controller would let you select No Transition Time/0 Seconds, but 5 is the best it can do right now. Not a big deal, as the 5 second wait hasn't cause me much annoyance.
Well that's wildly helpful too! As you know in Garadget's terms "transition time" is how long it takes the door to open or close. That might explain my delay. Lots of changes and testing today!
Yesterday was a Dark and Stormy kind of day...
I'm hoping I can work around that 5s delay before the door gets the close command (by watching the door attribute) although in practice I hope it's not an issue. On the list..
I thought that was Jun 23rd .... might have a try..
@kevin Just noticed something you might be interested in. I have 3 of the virtual garage door devices setup with my garadgets (I have 3 doors). All is working great at this point!
However events for virtual door 1 are not showing up in the log. So the door is working and i can see the events on the events page of the device. Like this:
and I have logging turned on for that device:
but in my logs the events never show up....but here's the kicker....just for this 1 door. The other two work as expected. Same settings as above and when the door opens/closes I see the events of that in the log.
