Modes not working for my app

I ported this app over from smartThings and it's not honoring the restriction of which mode to run in. What I've done is installed the app multiple times I set one install to Day and one install set to night. When I run one they both end up running. Any ideas as to why?

/**
 *  Send HAM Bridge Command When…
 *  
 *  For more information about HAM Bridge please visit http://solutionsetcetera.com/about-ham-bridge.html
 *
 *  Copyright 2016 Scottin Pollock
 */
definition(
    name: "Send HAM Bridge Command When…",
    namespace: "HAM Bridge",
    author: "Scottin Pollock",
    description: "Sends a command to your HAM Bridge server when various SmartThings are activated.",
    category: "My Apps",
    iconUrl: "http://scottinpollock.us/stuff/STIcons/HB.png",
    iconX2Url: "http://scottinpollock.us/stuff/STIcons/HB@2x.png"
)


preferences {
	section("Choose one or more, when..."){
		input "motion", "capability.motionSensor", title: "Motion Here", required: false, multiple: true
		input "contact", "capability.contactSensor", title: "Contact Opens", required: false, multiple: true
		input "contactClosed", "capability.contactSensor", title: "Contact Closes", required: false, multiple: true
		input "acceleration", "capability.accelerationSensor", title: "Acceleration Detected", required: false, multiple: true
		input "mySwitch", "capability.switch", title: "Switch Turned On", required: false, multiple: true
		input "mySwitchOff", "capability.switch", title: "Switch Turned Off", required: false, multiple: true
		input "arrivalPresence", "capability.presenceSensor", title: "Arrival Of", required: false, multiple: true
		input "departurePresence", "capability.presenceSensor", title: "Departure Of", required: false, multiple: true
		input "smoke", "capability.smokeDetector", title: "Smoke Detected", required: false, multiple: true
		input "water", "capability.waterSensor", title: "Water Sensor Wet", required: false, multiple: true
	}
	section("Send this command to HAM Bridge"){
		input "HAMBcommand", "text", title: "Command to send", required: true
	}
	section("Server address and port number"){
		input "server", "text", title: "Server IP", description: "Your HAM Bridger Server IP", required: true
		input "port", "number", title: "Port", description: "Port Number", required: true
	}
}

def installed() {
	log.debug "Installed with settings: ${settings}"
	subscribeToEvents()
}

def updated() {
	log.debug "Updated with settings: ${settings}"
	unsubscribe()
	subscribeToEvents()
}

def subscribeToEvents() {
	subscribe(contact, "contact.open", eventHandler)
	subscribe(contactClosed, "contact.closed", eventHandler)
	subscribe(acceleration, "acceleration.active", eventHandler)
	subscribe(motion, "motion.active", eventHandler)
	subscribe(mySwitch, "switch.on", eventHandler)
	subscribe(mySwitchOff, "switch.off", eventHandler)
	subscribe(arrivalPresence, "presence.present", eventHandler)
	subscribe(departurePresence, "presence.not present", eventHandler)
	subscribe(smoke, "smoke.detected", eventHandler)
	subscribe(smoke, "smoke.tested", eventHandler)
	subscribe(smoke, "carbonMonoxide.detected", eventHandler)
	subscribe(water, "water.wet", eventHandler)
}

def eventHandler(evt) {
	sendHttp()
}

def sendHttp() {
	def ip = "${settings.server}:${settings.port}"
    log.debug "${ip}"
	sendHubCommand(new hubitat.device.HubAction("""GET /?${settings.HAMBcommand} HTTP/1.1\r\nHOST: $ip\r\n\r\n""", hubitat.device.Protocol.LAN))
}

Please report this to support@hubitat.com. We will look into it. I don’t see anything about your app that would explain it. Could you post a screen shot of the app while it is open for configuration, with your mode restriction setting, or send it to support. That would be helpful


Here's how it looks when being configured.

We’ve determined there is a bug for sure. Will be addressed.

In the meantime, you could put in your own mode test for a restriction.

So I am more of a hacker than a developer. Would you happen to know how I check for the mode?

                input(
                    name		: "modes"
                    ,type		: "mode"
                    ,title		: "Set for specific mode(s)"
                    ,multiple	: true
                    ,required	: false
                )

And then:

def modeIsOK() {
	def result = !modes || modes.contains(location.mode)
    return result
 }
1 Like

Using Mike’s code above, you would test like this:

if(modeIsOk()) {

......  the code that does what you want ....

}
2 Likes

Hello,

I am resurrecting this thread because it appears that the bug were fixed for subscribe but not for schedule nor runOnce. The SmartThings docs do not necessarily specify (mirror link, since the original Samsung docs are gone now), so is this expected?

This can be reproduced by creating and installing an app with the following code (please change the time on line 29 to an appropriate time) (please also see the attached screenshot):

definition(
    name: "Test",
    author: "Azfar Khandoker",
    description: "",
    iconUrl: "",
    iconX2Url: "",
    namespace: "com.azfarandnusrat.test"
)

preferences {
	section {
		input "mySwitch", "capability.switch"
	}
}

def installed() {
	subscribeToEvents()
}

def updated() {
	unsubscribe()
	subscribeToEvents()
}

def subscribeToEvents() {
    log.debug "Hub mode: ${location.mode}"
    
    // does not respect selected modes
    def scheduleTime = toDate("16:13")
    schedule(scheduleTime, eventHandler)
    //runOnce(scheduleTime, eventHandler)
    
    // -----------------------------------------
	
    // respects the selected modes
    //subscribe(mySwitch, "switch.on", eventHandler)
}

def eventHandler(evt) {
    log.debug "event handled: ${evt}"
}

def toDate(time) {
    def hour = Integer.parseInt(time.substring(0, time.indexOf(':')))
    def min = Integer.parseInt(time.substring(time.indexOf(':') + 1))
    def cal = Calendar.getInstance()
    cal.set(Calendar.HOUR_OF_DAY, hour)
    cal.set(Calendar.MINUTE, min)
    cal.set(Calendar.SECOND, 0)
    cal.getTime()
}

I will send an email to support as requested earlier:

Without arguing the merits of doing it either way, there are implicit dependencies on this behavior 4 years later. Making this change now will cause breaks in existing apps.

That's fair. Thank you for the response.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.