Holdable and Releasable Button

@bertabcd1234 Do you have any direction on what could be the issue?
Are there other logs to look into?

From the event log you posted, Dashboard appears to be working fine. Is this the same driver as the one that should be sending the "real" commands? If so, you have some problem there. Adding some logging to your app to debug things yourself may help (can't do much without the code).

If not, you must have some other device (and its driver) involved, but from your screenshots, no automation is set up to respond to these button events and do something with a other device. I can say this because there are no "Triggered apps" in your screenshot.

Yes, there is only one drive and one device using this driver ("Projector Screen").
Here is the current driver code (essentially the same as in my original post):

*    iTach iP2CC Driver for Projector Screen Control
*    Screen uses Port 1 for UP trigger and Port 2 for DOWN Trigger
*    To stop the screen both ports must be triggered

static String version() {return "0.0.1"}

metadata {
    definition (
        name: "iTach iP2CC", 
        namespace: "uw", 
        author: "U W",
    ) {
        capability "Telnet"
        capability "Initialize"
        capability "Switch"
        capability "PushableButton"
        attribute "Port1", "ENUM", ["on", "off"]
        attribute "Port2", "ENUM", ["on", "off"]
        attribute "lastMessage", "STRING"
        attribute "pushed", "NUMBER"
        attribute "numberOfButtons", "NUMBER"

        command "connectTelnet"
        command "disconnectTelnet"
        command "p1On"
        command "p1Off"
        command "p2On"
        command "p2Off"
        command "ScreenUP"
        command "ScreenDOWN"
        command "ScreenSTOP"


preferences {

    input(name: "ipAddr", type: "string", title:"IP Address", required: true)
    input(name: "portNum", type: "number", title: "Port Number", required: true)

def installed() {


def initialize(){
    log.debug "----- INITIALIZING TELNET -----"

void updateAttr(String aKey, aValue, String aUnit = ""){
    sendEvent(name:aKey, value:aValue, unit:aUnit)

def connectTelnet(){
        telnetConnect([termChars:[10]], ipAddr, (int)portNum, null, null)
    } catch (ex) {
        updateAttr("lastMessage", ex)
    updateAttr("switch", "on")

def disconnectTelnet() {
    updateAttr("switch", "off")

def sendMsg(message) {
    sendHubCommand(new hubitat.device.HubAction("""$message\r\n""", hubitat.device.Protocol.TELNET))

def p1On(){
    updateAttr("Port1", "On")

def p1Off(){
    updateAttr("Port1", "Off")

def p2On(){
    updateAttr("Port2", "On")
def p2Off(){
    updateAttr("Port2", "Off")

def ScreenUP(){
    log.debug "----- Screen UP -----"

def ScreenDOWN(){
    log.debug "----- Screen DOWN -----"

def ScreenSTOP(){
    log.debug "----- Screen STOP -----"

def push(button){
    if (button == 1){ScreenUP()}
    if (button == 2){ScreenDOWN()}
    if (button == 3){ScreenSTOP()}

def parse(message) {
    updateAttr("parsedMessage", message)

def telnetStatus(message){
        updateAttr("statusMessage", message)

There are no other apps involved in this setup. The Dashboard tile is expected to trigger the device directly.

I don't see anything glaringly obviously wrong, so I'd suggest:

Specifically, you can do things like sprinkle log.trace entries throughout so you can see what is (or isn't) running when, what the values of objects that matter are, or anything else that is helpful, then go from there.

Issue resolved! (with a caveat)

I went ahead and added

    log.trace "----- Push -----"

to the driver 's "push" definition.

The trace did appear in the logs when the tile was triggered, but none of the conditions were executed.

So I tried changing from integer to string values, as such:

    if (button == "1"){ScreenUP()}
    if (button == "2"){ScreenDOWN()}
    if (button == "3"){ScreenSTOP()}

Now the Tiles work.
BUT, the Push command from the Device does not. So the Tile only takes strings, the device Push command only integers.
Smells like a BUG to me.

Sorry, I meant driver (but otherwise the same idea).

Seems like you have a solution now? Not sure about the data types, but I'd always be prepared to handle about anything given how Groovy is. :slight_smile:

I think this is more of a workaround.
The Dashboard code needs to be updated to pass numbers as integers, not strings.

While that may be helpful, with any Hubitat command that accepts numbers, I would also be prepared to parse them out of a string, given both the dynamic nature of Groovy and the fact that sometimes these values will come in via means that do not have any inherent types at all (e.g., as part of a URL query string via Maker API), so you never really know what you're going to get.

1 Like