Ah, cool. So we will add that to the Lutron dimmer driver, for next release.
2 Likes
Is the startLevelChange able to be added to Groups? I have a group of two zigbee bulbs with zigbee group messaging enabled, it does not respond to those commands and I have to list the devices individually (Which is not a big deal other than one usually responds slower than the other and they end up at different levels).
I have noticed the same thing. Also, I think the Alexa Skill properly turns on Group of 2 Zigbee Bulbs with zigbee group messaging enabled and responds with "OK". However, when I tell Alexa to turn off the same group, the bulbs go off, but Alexa never says "OK" and might respond after a while that Hubitat did not respond (or something like that.)
I haven't had the chance to try that out as the Alexa Skill still isn't available in Canada (And neither is their new microwave...darn!).
I know there are workarounds (create a rule to tie one to the other). I am hoping that this can be added as my bulbs were popcorning so much I thought that I was at the movies (sometimes they just didn't respond). The group messaging fixed all of it!
1 Like
I have invested some effort with this, but the outcome so far wasn't so great. startLevelChange depends so much on timing for it to work right, that the intermediate level of loading an app didn't seem to cut it. I haven't abandoned the idea, just saying that first cut at it was disappointing.
2 Likes
Mike,
I have been struggling how to implement a tripletappable button. I currently us one in ST via a handler found on darwinsden.com for a Homeseer ws-100. Having to assign a single button for each action (1-8 for single, double and triple tap) is certainly difficult to remember when creating rules. I therefore think your implantation of actually having the capabilities build into HE is great. I found your driver code example "HubitatPublic/genericZWaveCentralSceneDimmer.groovy at master · hubitat/HubitatPublic · GitHub" and noted you actually have a tripletap scrap of code in there. However, you do not seem to actually have the capability built into HE so i cannot utilize it. I have successfully modified your driver to work and it logs a triple tap. However, i cannot utilize it in rule machine. Is there any chance you can or will implement the tripletap capability so it can be utilized in rule machine?
sure we see the event from the device, but ignore tripple tap.
We drew the line at double tap from a practical perspective.
Personally I couldn't imagine using 3x, 4x, xx taps, much less explaining that to other users within the home.
You could map the triple taps into any of the existing button capabilities by adding a static offset to the captured scene id.
Hey all,
I am getting errors in RM attempting to "push" a button in my driver. Thoughts on what I am doing wrong here?
capability "Battery"
capability "Actuator"
capability "PushableButton"
attribute "cleanStatus", "string"
attribute "RoombaTile", "string"
attribute "bin", "string"
command "start", ["1"]
command "stop", ["2"]
command "pause", ["3"]
command "resume", ["4"]
command "dock", ["5"]I don't understand the commands you have listed, none of the parameter types listed are valid..
Valid parameter types are number, string ect...
You should post the entire driver so folks can see what you're trying to do here...
At a minimum, your driver is going to also need to issue the following two commands.
One time, usually in the updated() function
sendEvent(name:"numberOfButtons", value: numBtns)
Each time you want to create a button event
sendEvent(name:"pushed", value: btnNumber)
Without the rest of the driver, it’s hard to help much more.
/**
*
* Hubitat Import URL: https://raw.githubusercontent.com/PrayerfulDrop/Hubitat/master/Roomba/Roomba-device.groovy
*
* **************** Roomba Device ****************
*
* Design Usage:
* This driver supports the Roomba Scheduler App which is designed to integrate any WiFi enabled Roomba devices to have direct local connectivity and integration into Hubitat. This applicatin will create a Roomba device based on the
* the name you gave your Roomba device in the cloud app. With this app you can schedule multiple cleaning times, automate cleaning when presence is away, receive notifications about status
* of the Roomba (stuck, cleaning, died, etc) and also setup continous cleaning mode for non-900 series WiFi Roomba devices.
*
* Copyright 2019 Aaron Ward
*
* Special thanks to Dominick Meglio for creating the initial integration and giving me permission to use his code to create this application.
*
* This App is free and was designed for my needs originally but has grown for most needs too.
*
*-------------------------------------------------------------------------------------------------------------------
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
* in compliance with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under the License.
*
*
* ------------------------------------------------------------------------------------------------------------------------------
* Donations are always appreciated: https://www.paypal.me/aaronmward
* ------------------------------------------------------------------------------------------------------------------------------
*
* Changes:
*
* 1.1.0 - support for pushable buttons
* 1.0.9 - error in namespace preventing creation of adding device
* 1.0.8 - added logging option
* 1.0.7 - added battery died notifications
* 1.0.6 - cleaning duration
* 1.0.5 - added all possible tile outcomes (cleaning, docking, stopped, error, dead battery)
* 1.0.4 - added dashboard tile updates
* 1.0.3 - moved all notifications back to app
* 1.0.2 - modified how pushover works
* 1.0.1 - added pushover notification capabilities
* 1.0.0 - Inital concept from Dominick Meglio
**/
metadata {
definition (name: "Roomba", namespace: "roomba", author: "Aaron Ward", importUrl: "https://raw.githubusercontent.com/PrayerfulDrop/Hubitat/master/Roomba/Roomba-device.groovy") {
capability "Battery"
capability "Actuator"
capability "PushableButton"
attribute "cleanStatus", "string"
attribute "RoombaTile", "string"
attribute "bin", "string"
command "start", ["1"]
command "stop", ["2"]
command "pause", ["3"]
command "resume", ["4"]
command "dock", ["5"]
}
preferences() {
input("logEnable", "bool", title: "Enable logging", required: true, defaultValue: true)
}
}
def setVersion(){
appName = "RoombaDriver"
version = "1.1.0"
dwInfo = "${appName}:${version}"
sendEvent(name: "dwDriverInfo", value: dwInfo, displayed: true)
}
def updateVersion() {
log.info "In updateVersion"
setVersion()
}
def start() {
parent.handleStart(device, device.deviceNetworkId.split(":")[1])
if(logEnable) log.debug "Roomba is being started through driver"
}
def stop() {
parent.handleStop(device, device.deviceNetworkId.split(":")[1])
if(logEnable) log.debug "Roomba is being stopped through driver"
}
def pause() {
parent.handlePause(device, device.deviceNetworkId.split(":")[1])
if(logEnable) log.debug "Roomba is being paused through driver"
}
def resume() {
parent.handleResume(device, device.deviceNetworkId.split(":")[1])
if(logEnable) log.debug "Roomba is resuming through driver"
}
def dock() {
parent.handleDock(device, device.deviceNetworkId.split(":")[1])
if(logEnable) log.debug "Roomba is being docked through driver"
}
def roombaTile(cleaning, batterylevel, cleaningTime) {
def img = ""
switch(cleaning) {
case "cleaning":
img = "roomba-clean.png"
msg=cleaning.capitalize()
break
case "stopped":
img = "roomba-stop.png"
msg=cleaning.capitalize()
break
case "charging":
img = "roomba-charge.png"
msg=cleaning.capitalize()
break
case "docking":
img = "roombadock.png"
msg=cleaning.capitalize()
break
case "dead":
img = "roomba-dead.png"
msg="Battery Died"
break
case "error":
img = "roomba-error.png"
msg = cleaning.capitalize()
break
default:
img = "roomba-stop.png"
msg=cleaning.capitalize()
break
}
img = "https://raw.githubusercontent.com/PrayerfulDrop/Hubitat/master/Roomba/support/${img}"
if(cleaning.contains("docking") || cleaning.contains("cleaning")) roombaTile = "<div style=font-size:15px align=center><img width:100% max-width=100% height=auto src=${img} border=0><br>${msg} - ${cleaningTime}min<br>Battery: ${batterylevel}%</div>"
else roombaTile = "<div style=font-size:15px align=center><img max-width=100% height=auto src=${img} border=0><br>${msg}<br>Battery: ${batterylevel}%</div>"
sendEvent(name: "RoombaTile", value: roombaTile, displayed: true)
if(logEnable) log.debug "Roomba Status of '${msg}' sent to dashboard"
}Looking through your driver, I don’t see where you’re trying to implement Button functionality. How do you envision the driver using buttons?
I would like to expose those functions (Start, stop, etc) as a pushable button that could accessed in RM.
I added you to private thread that should explain it.
Hmmm... Device drivers don’t typically receive “button requests”, but rather they generate Button Events.
Rule Machine can already call those custom commands via its Custom Action feature.
I added you also to private thread that should explain it.
Just a quick note, button controllers produce button events, they normally don't consume them.
Button controller apps subscribe to button events produced by button controllers. It seems you want to send a button event to this driver as a command shortcut. This is possible using custom commands in rule, but likely more confusing that just implementing each command in rule separately...
1 Like
I was thinking that each button would be an event which could be the sub routines listed accordingly. Thinking more of a virtual button(s) on a single device. I don’t want to create child devices and/or multiple devices for this capability.
Recommendations?
Do you mean that the physical button presses on the Roomba are visible to Hubitat and you want those to be exposed as button events? You could certainly do that. But it sounds like you want something else: you could make the driver expose buttons that can effectively only be "virtually" pressed to trigger some event on the Roomba itself, but I'd agree with the above that a custom command might be the way to go--and certainly more intuitive. (Apps like Button Controller aren't designed to press buttons; they're designed to handle button presses. Some apps are indeed capable of "pressing" buttons as hinted at above, but such behavior is often confusing to users. Rule Machine or a custom app can call custom commands on a device.)
Regardless, there is no reason to create child devices (or multiple standalone devices). You can implement as many custom commands as you want, or if you want to go the button route, you can pretend (I think? still not clear) that the device has so many pushable buttons and make the driver handle these events accordingly [EDIT: not the phrasing I wanted...can you tell I'm an app person?].
