I’ve been working on my own version of the Lutron Aurora dimmer.
My goal is a driver that can eradicate an insane amount of rules by only setting up one “follow me” rule for each dimmer.
So far I’ve got the color temperatures and light levels I want for certain times of day established as presets. I also added motion, and methods to activate and deactivate, as an indicator of whether or not a group of lights is currently accepting motion activated lighting. I have each button press and knob turn registered as a physical action, which tells my system that someone is “Present” in that room, turning off motion lighting. Any digital command is registered as such and does not impact the “presence.”
I am not quite sure yet if I correctly coded a timeout in response to a presence event; the goal here is to reactivate motion lighting when the presence times out (unless it is night). I may have further questions of I didn’t get that right.
Where I’m really struggling, is time restrictions.
I’d like to write a schedule directly into the driver that indicates what color temperature and light level the device should be at when pressed throughout the day. Is this possible?
Somewhat unrelated, and more irritating, is the groovy expectations when trying to write a json body being sent to a third party server. I’ll post a snippet when I get home, but essentially writing something like this {“name”: “some name”, “devices” : {1, 2}} always results in an error. The API receiving the data is insistent that it comes formatted exactly like that, and I can’t save it like that. Any suggestions?
This is technically possible in that drivers do have access to hub time. Here's an example of what you can do:
metadata {
definition (name: "Testing Date/Time", namespace: "Test", author: "Test") {
capability "Actuator"
command "myCommand"
}
}
void myCommand() {
Date currTimeD, startTimeD, endTimeD
currTimeD = new Date()
log.trace "current time and date = ${currTimeD}"
startTimeD = timeToday("08:00", location.timeZone)
endTimeD = timeToday("17:00", location.timeZone)
log.trace "between 8 AM and 5 PM? = ${timeOfDayIsBetween(startTimeD, endTimeD, currTimeD, location.timeZone)}"
}
These methods are from the Common Methods docs, which means methods that are available to both apps and drivers. There is also driver documentation, which you may want to know in general but doesn't have anything you could specifically use here.
However, this really seems like a better place for an app to fit into things. First, inputs/preferences in drivers are more limited compared to apps: apps let you use multiple pages, dynamic inputs, and are this much more flexible in what you can implement. Driver preferences are flat (single-page) and static (though you can cheat this a bit with conditionals around inputs, keeping in mind that there id still no dynamic refresh/submitOnChange functionality and so the page must be saved and thus reloaded before these may take effect). I think"time" is still a valud input type in drivers like it is in apps, but if not, that's probably the biggest nail in this coffin. It sounds like you're already trying to handle this at the app (rules are apps) level and don't like the results, so perhaps you've already given this some thought, though a custom app might be able to do things more easily than a rule (and will spare you from needing to write a driver for the device on top of all of this).
Sorry for the late response. This is however the second time you have (seemingly at this point) answered my question very quickly, so much thanks. I have not yet had a chance to implement your solution. A limited input driver, with static settings, is what I'm looking for. There are an insane amount of lighting apps and drivers to choose from; it just so happens, not a single one I have found does what I want. I figure if most of the complexities of my ideal lighting situation are being dealt with at the driver level, it will hopefully be as solid as possible.
