multiAttributeTile : VALUE_CONTROL

Developer Programs Writing Device Types
1

Continuing the discussion from Android 2.1.0 - Release Notes - 3/7/2016:
@Jim, thanks very much for this update. As you undoubtedly know, the Nest is a special case that uses separate actions to command heatingSetpointUp, heatingSetpointDown, coolingSetpointUp, and coolingSetpointDown. Is there any way to have multiple actions for VALUE_UP and VALUE_DOWN?

1 Like
2

why not change the DTH code so that the value_control only changes the set points of the active thermostat mode? wouldn’t work if you use auto though…

3

Yeah, that’s the rub. Nest is nice, but a PITA at times.

4

why use auto?, plenty of other smart apps that can change the mode for you…

5

I’m doing that now with RM, but wife likes auto during cooling season. Maybe if I show her that it won’t make a difference… :slightly_smiling:

I’d still like to hear what @Jim has to say.

6

I’ll pipe in and request that it not max out at 99 — no one likes a warmtub.

2 Likes
7

I’ve reached out to engineering to help answer your question.

1 Like
8

@Mr_Lucky Thanks for the question! @Mike_Maxwell’s first answer is basically what my advice would be. If you modify your DTH to check the mode on the thermostat when its VALUE_UP and VALUE_DOWN actions are called, you should be able to modify the correct setpoints. As for how to handle Auto, you (and your wife) may find it good enough to adjust both the heating AND cooling setpoints—effectively sliding the heat/cool “window” up and down. If you need to make that range larger, you could add some separate standardTiles in the details view to adjust setpoints individually. In a pinch, there’s always the old-fashioned way—walk up to the thing and turn the knob (how barbaric!) :tophat:

1 Like
9

Fair enough. I didn’t mean to imply it was necessarily a problem, but wanted to ask in case it was a simple solution that I was just overlooking.

10

Because we have days in Texas that go from freezing (30 F) in the morning to shorts weather in the afternoon. So auto is the preferred mode in this household.

In my Ecobee DTH I have special handling for “Auto” when the arrows are used and try to intelligently decide which setpoint to change to get the desired impact. But I can’t be right 100% of the time.

I too would like to request the ability to have a second set of controls. One for heat and one for cool. There is plenty of room in the giant tile (IMO).

11

What is the latest behavior? This controls used to work differently for iOS and Android (+1, -1 for iOS and it was cumulative for Android +1, +2, +3, +2, +1, 0, -1, -2 etc)

12

Earlier behavior and workaround:

13

Actually, on iOS it was inconsistent before. Sometimes it was +1, -1 and other times it would send in the setpoint. I have code in my app that handles both.

But now it looks like the original model is depricated and we are supposed to use the new VALUE_UP / VALUE_DOWN handlers.

Let me test to see how it is behaving in the 2.1.0 update.

1 Like
14

Sweet can you post some sample code too for reference.

15

Just checked and so far I’m only getting actual setpoint values. No 0 or 1 yet.

I did find a little bug that I’m fixing up (not related to the checks, related to a “runIn” timer. Will post the code shortly.

1 Like
16

Here is my code. I have special handling for what I call “Smart Auto” mode. It allows the users to still use the arrows even when in auto mode and tries to intelligently (hah!) decide how to change the setpoints.

// Does not set in absolute values, sets in increments either up or down
def setTemperature(setpoint) {
	LOG("setTemperature() called with setpoint ${setpoint}. Current temperature: ${device.currentValue("temperature")}. Heat Setpoint: ${device.currentValue("heatingSetpoint")}. Cool Setpoint: ${device.currentValue("coolingSetpoint")}. Thermo Setpoint: ${device.currentValue("thermostatSetpoint")}", 4)

    def mode = device.currentValue("thermostatMode")
    def midpoint
	def targetvalue

	if (mode == "off" || (mode == "auto" && !usingSmartAuto() )) {
		LOG("setTemperature(): this mode: $mode does not allow raiseSetpoint", 2, null, "warn")
        return
    }

	def currentTemp = device.currentValue("temperature")
    def deltaTemp = 0

	if (setpoint == 0) { // down arrow pressed
    	deltaTemp = -1
    } else if (setpoint == 1) { // up arrow pressed
    	deltaTemp = 1
    } else {
    	deltaTemp = ( (setpoint - currentTemp) < 0) ? -1 : 1
    }
    

    LOG("deltaTemp = ${deltaTemp}")

    if (mode == "auto") {
    	// In Smart Auto Mode
		LOG("setTemperature(): In Smart Auto Mode", 4)

        if (deltaTemp < 0) {
        	// Decrement the temp for cooling
            LOG("Smart Auto: lowerSetpoint being called", 4)
            lowerSetpoint()
        } else if (deltaTemp > 0) {
        	// Increment the temp for heating
            LOG("Smart Auto: raiseSetpoint being called", 4)
            raiseSetpoint()
        } // Otherwise they are equal and the setpoint does not change

    } else if (mode == "heat") {
    	// Change the heat
        LOG("setTemperature(): change the heat temp", 4)
        // setHeatingSetpoint(setpoint)
        if (deltaTemp < 0) {
        	// Decrement the temp for cooling
            LOG("Heat: lowerSetpoint being called", 4)
            lowerSetpoint()
        } else if (deltaTemp > 0) {
        	// Increment the temp for heating
            LOG("Heat: raiseSetpoint being called", 4)
            raiseSetpoint()
        } // Otherwise they are equal and the setpoint does not change

    } else if (mode == "cool") {
    	// Change the cool
        LOG("setTemperature(): change the cool temp", 4)
        // setCoolingSetpoint(setpoint)
        if (deltaTemp < 0) {
        	// Decrement the temp for cooling
            LOG("Cool: lowerSetpoint being called", 4)
            lowerSetpoint()
        } else if (deltaTemp > 0) {
        	// Increment the temp for heating
            LOG("Cool: raiseSetpoint being called", 4)
            raiseSetpoint()
        } // Otherwise they are equal and the setpoint does not change

    }
}
1 Like
17

Thanks I was referring to the code for preferences and you’ve also covered the actual function. (just to check if anything changed).

It looks like it’s still sending 0 or 1 (not the actual setpoint like you mentioned above). Is this on iOS or Android or both?

18

My app is used on iOS and Android, but I only have iOS handy to test with at the moment.

Here is what I’m receiving on my testing in my logs:

2e130cdd-54c6-4120-ac7c-f92485b43c43 11:11:56 PM: debug LOG: setTemperature() called with setpoint 73. Current temperature: 72. Heat Setpoint: 70. Cool Setpoint: 75. Thermo Setpoint: 72

And:

2e130cdd-54c6-4120-ac7c-f92485b43c43 11:08:37 PM: debug LOG: setTemperature() called with setpoint 73. Current temperature: 72. Heat Setpoint: 66. Cool Setpoint: 73. Thermo Setpoint: 72

Which preferences code were you looking for?

1 Like
19

And just like that I’m getting 0 and 1 again:

2e130cdd-54c6-4120-ac7c-f92485b43c43 11:37:13 PM: debug LOG: setTemperature() called with setpoint 0. Current temperature: 72. Heat Setpoint: 66. Cool Setpoint: 73. Thermo Setpoint: 72

(Notice the “called with setpoint 0” in the log entry.)

So still not consistent in what it sends to the app…

1 Like
20

:)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
ROFL - now that’s a fickle minded platform @Jim any thoughts?