I’m working on creating a couple of simple virtual device drivers for interacting with Alexa, but I’m stuck on what to name these things! So I’m hoping y’all can help guide me
One acts as an actuator on the Alexa side and a sensor on the Hubitat side (for when Alexa wants to tell to Hubitat to do something). The other acts as a sensor on the Alexa side and an actuator on the Hubitat side (for when Hubitat wants to tell Alexa to do something).
For the from-Alexa-to-Hubitat device:
Alexa Button?
Alexa Sender?
Alexa Actuator?
For the from-Hubitat-to-Alexa device:
Alexa Trigger?
Alexa Receiver?
Alexa Sensor?
Or is something else that better conveys their purpose?
(I know there are a bunch of community drivers that already fulfill both capabilities. I have some I wrote myself. But I’m finding it easier to think about certain use cases if I have them clearly segregated.)
Just curious…. How are these two drivers different? The same driver should work for both purposes, correct? I have written a few of these myself. I never found a need to create different drivers.
Alexa routines can only respond to a few triggers from smart home devices, mainly contact sensors and motion sensors. There are a few more, I think, but I haven’t really tried them out (temperature? locks? doorbells? maybe more).
So my from-Hubitat-to-Alexa driver implements the ContactSensor capability (for the Alexa side) and some way to change the contact attribute (for the Hubitat side). Right now, I’m using a custom command, but I may change it to something like a PushableButton.
Additionally, Alexa routines can only control a few different types of smart home devices. I’m not sure exactly what is supported, as I’ve only ever seen and used switches.
So my from-Alexa-to-Hubitat driver implements the Switch capability, which I use on both Alexa and Hubitat (Alexa uses the on and off commands, Hubitat uses the switch attribute).
I could’ve used the existing Virtual Contact Sensor and Virtual Switch drivers, but I wanted to have auto-close/auto-off functionality. The Virtual Switch supports that, but the Virtual Contact Sensor doesn’t. And as long as I’m creating a custom driver for one of them, I might as well do both, right?
Also, you’re absolutely right: I don’t need separate drivers. I’ve used (and created) drivers before that include both the Switch capability and the ContactSensor capability, and they have worked perfectly for both cases. All I’m looking for is a mental separation to help me keep things straight. (I’m currently accomplishing that separation with a simple naming convention, but where’s the fun in that when I can build something new instead? )
Thanks for your explanation. I now understand what you’re goals are. Not sure that I have any additional advice on a naming convention for these, though. I prefer the simplicity of a single driver that includes both the switch + sensor capabilities, but I can appreciate that using a driver with both may lead to a little additional confusion.
In case you are interested, I hacked this together for my personal use (by changing some capabilities on another driver). I use it to do exactly what you described.
Thanks, I have something very similar that I use for other purposes. But for my current use case, there’s a lot of traffic back and forth between Hubitat and Alexa, and I’m finding it easier to keep things straight if I have separate drivers for the separate roles (sender vs. receiver).
On a side note, there may be a bug in your code. For the delayed open and close, the runIn methods are scheduling methods named open (line 40) and closed (line 52). However, there are no methods defined that have those names. There are methods named wet (line 27) and dry (line 31), which seem to have the right functionality, but the wrong names.
