[RELEASE] Virtual Switch Universal Device Type (uDTH) - good for Alexa, IFTTT, HSM, and other integrations

The on/off logging would be sufficient and the easiest way to implement.

Curious for Alexa, why do you need the contact capability? Is that so you can TRIGGER routines in Alexa? I so far have only used switch with either motion or presence, but I have either Alexa or HomeKit turn them ON (like a switch), but want it to show as the motion or presence in Hubitat / Homekit.

Only Motion and Contact are Triggers for Alexa. Alexa can use Switches as Actions.

1 Like

I just used HPM to install this bad boy!

1 Like

So this is pretty cool if I am understanding this right. I will be able to clean up a lot of the extra virtual devices and their rules linking them when integrating for alexa IFTTT and other things.

1 Like

Great device drivers, thank you!

This is probably a dumb question, but what is the best way to be able to hit this via a Webhook? I'm struggling in figuring out what I need to do to expose this as a Webhook for an internal need v.s. IFTTT or Alexa which are more straight forward.

See this post here.
Internet Based Webhooks/Endpoints - Get Help / Integrations - Hubitat

also Maker API - Hubitat Documentation

2 Likes

I've added (and subsequently fixed) logging in both versions and updated HPM. Please check for an Update.

1 Like

@scottbarton76 Any chance you could add a Virtual Garage Door - Need a virtual device that has states of Open, Closed, Moving, Stopped, and Other.

GarageDoorControl

Device Selector

capability.garageDoorControl

Driver Definition

capability "GarageDoorControl"

Attributes

door - ENUM ["unknown", "open", "closing", "closed", "opening"]

Commands

close()

open()

1 Like

Oh you say that like I know how to incorporate that into the uDTH... ~sigh

I think I need to take a groovy class

2 Likes

My point really was that the valid values for the door attribute are "unknown", "open", "closing", "closed", and "opening"

1 Like

Ah, gotcha. I originally posted opening & closing, but using contact sensors and a vibration sensor - if it is active, it could be opening or closing... if both sensors are open and it is inactive - the true status is "stopped". And with Liftmaster/Chamberlain from "stopped" the next movement will always be closing.

I can add GarageDoorControl capability. The issue with it is because its a virtual switch, its really only binary. Its either open or closed. I could add some logic that after you hit the close button it will change it to "Closing" for certain duration, and then after that duration, set it to closed. Same thing for Opening/Open. It would obviously be just a guess as to whether it was actually still opening or closing and if it was successfully opened or closed.

What duration would you like me to use for opening and closing?

From the other thread it also sounds like you want it to ignore subsequent open commands while its opening and same for closing. Is that correct or is there some other logic you want built in?

It’s actually @DarellCraighead’s request.

It isn't about the timing, it is about showing the "true" status. A garage door can be closed, opening, open, closing, or "stopped" (if you don't let it open all the way). The problem comes with the logic of how to handle the stopped state. With Liftmaster/Chamberlain the next button push will always be to closing state. The problem then is, if a door is part way open (stopped) and you want to open it, it takes 2 button presses - there is no "open" and "closed" command, simply button presses.

This is a virtual switch that can control other capabilities. It is not actually a device handler for your real device. Using the ability of only buttons for On/Off, how would you handle showing the true state? When you press On, it would represent Opening the garage door. This would change the status to Open. When you press Off it would represent Closing the garage door. Normally, as soon as you hit On it would immediately change the status to Open in the virtual switch device capability.

What I'm suggesting is that when you hit On (or have an app hit On or whatever), that it would change the garagedoor capability status to 'Opening' for a brief duration, and then change it to 'Open' and remain as such until you turn the switch Off. At which point, it would change the garagedoor capability status to 'Closing' for a set period, and then change it to 'Close'.

If there is an issue with multiple On commands while it is Opening, I can ignore further On/Open commands while the status is Opening. Ie if you hit the On button, it would change the status to Opening, if you hit the On/Open button again, it would ignore that until the state changed to Open. However if you hit the Off/Close button while the status was still Opening, it would send the Close command and change the status to closing and then closed.

1 Like

I've updated this device handler to include Garage Door capability. Please update from HPM.

You will need to set doDoorControl = true on line 18 and save.

You can have it to set the door state as closing for a specified duration (Opening Time Preference) when you hit off/close button before it changes the door state to closed.

Let me know if there are any issues, or if you want me to add/change the functionality.

Thanks much!

Is there any reason this doesn't display as a motion sensor in a dashboard? I get a question mark. It works fine if I change it to a contact or a switch. I've tried both the Lite and the Super versions.


In the Current States column of Device Info, I don't see a Motion line. The Dashboard isn't going to make a guess :slight_smile: