QUESTION: My SWITCH use below is an absolute hack. I’d like to evaluate expressions inside a SWITCH statement. In the example below for example, I’d really like to use { > 32 } instead of the current hack where I use { 33 - 1000 }. I’ve gone through the docs carefully but I can’t seem to find the proper syntax to do that. Can anyone suggest how to accomplish this? I hate ugly code.
SWITCH case evaluation
bangali
#5
heres another option:
remember to replace the thermostat name simulated thermostat 1 with whatever your thermostat is called.
Jeff1
#6
Thanks, this is a great example of something I’ve been wondering about - how to use values from devices directly inside statements. Super helpful!
Jeff1
#7
@Bengali - any chance I could either get a reference to the docs, or a quick explanation of the ? and : in the sample you posted above?
For example, this works great { ( [My Weather Station : Temperature] > 32 ) } I get the appropriate true/false
However { ( [My Weather Station : Temperature] > 32 ? 45 ) } - Always returns a 0 and doesn’t work.
Changing it to: { ( [My Weather Station : Temperature] > 32 ? 45 : 45 ) } and it works. So I’m not really understanding the ? and : in the syntax. It is that the statement always needs a “if all else fails” value at the end?
Jeff1
#9
Very helpful, thanks so much. So a ternary operator does, in fact, have to have a “last resort” value if I’m reading this correctly.
“Ternary operator ( c ? t : f )
A great tool to simplifying expressions, the ternary operator evaluates c as a boolean, then if that evaluation is true, returns t, otherwise returns f.”
You’ve simply nested these. . . .BUT without that last : value it errors out in effect and returns as zero? Am I reading it right?
Jeff1
#11
Are there limits (practical or stylistically) on the conditions one can have? Example, I’ve enhanced my thermostat controls to more gradually adjust the thermometer in response to changing outdoor conditions. This is to prevent abrupt thermostat changes that kick on emergency heating strips. Or Strip$ as I call them.
Maybe there is a better way to accomplish my goals here vs the below?
michicago
#12
Am I reading this right? Doesn’t feel like it (especially since >15 conflicts with so many other things) but trying to sort through that is a headache in the making when reading it from scratch:
| Outdoor | Indoor |
|---|---|
| 29 | 45 |
| 28 | 46 |
| 27 | 47 |
| 26 | 47 |
| 25 | 48 |
| 24 | 49 |
| >15 | 50 |
| 14 | 51 |
| 13 | 52 |
| 12 | 53 |
| 11 | 54 |
If that isn’t right, can you map out what you’re trying to do? There are a few elegant ways I think we can approach this but I need to understand the numbers first.
Jeff1
#13
Sure thing, and thanks so much for your offer of help. I believe what I have is actually working, it’s just not very elegant and feels like it could be cleaner. I did resolve one error where I had a duplicate thermostat setting. The objective here is to avoid RAISING the thermostat more than a degree at a time based upon outside conditions while still letting the house protect itself from having issues with frozen pipes. Updated snapshot is below, but here’s the logic:
| Outdoor | Indoor |
|---|---|
| >29 | 45 |
| 28 | 46 |
| 27 | 47 |
| 26 | 48 |
| 25 | 49 |
| >14 | 50 |
| 14 | 51 |
| 13 | 52 |
| 12 | 53 |
| 11 | 54 |
| <11 | 55 |
The >14 condition will only trigger if the statement gets all the way through the previous conditions, so basically that is a catch for any outdoor temperature between 15-24 and hold the inside temperature stead at 50 degrees. If things drop below 15, now it’s getting really cold and I want to gradually warm up the house a bit to minimize the possibility of frozen pipes. That will slide up the temperature down to 10 degrees, where the thermostat will stick at 55 degrees.
Thanks again for the offer of help!
-Jeff
michicago
#14
Got it! This one is going to be fun, I’ll post something up in a few hours when I get a break from work.
michicago
#15
I don’t have a thermostat to set, so I’ve just put together the logic I think you’d like for your piston and enabled Log to console to show how it works.
The entire first block is merely there to show you how it works so you can understand the expressions and edit to your liking whenever necessary. You can just delete that entirely when you integrate this (or IF, I should say) with your piston.
Replace “Outdoor_Temp” with your weather station reading; I just needed a number I can manipulate to get this working and prove it out.
If anything is unclear, let me know and I’ll try to explain what this is doing.
Which logs this to the console:
Jeff1
#16
Thanks, I edited the post to include the relevant piston code. Also, I notice that the snapshot isn’t being fully anonymized. I don’t think that’s a major problem, but normally the sensor names are converted to generic values when I click the green snapshot option. That’s not happening inside the embedded logic statements though. Is that a problem?
Jeff1
#17
LOL, wow. . . this is an approach I wasn’t aware of. Thanks so much, I will dissect it and see if I can grasp how you are accomplishing this. 
michicago
#18
Here is the cleaned up version - tried throughout a range of temps and it works perfectly. The key for this to work is to make sure your OTemp and ITemp numbers are in the same position. For example, at 11 degrees you want the heat set to 54, so 11 and 54 need to be in the first position in the variable.
Now all you have to do is change swap out “Outdoor_Temp” in the expressions for your weather station temperature, and replace my “Log to console” commands with an action setting your thermostat temperature.
Hope this helps! Again, if anything is unclear, let me know and I’ll try to explain it. I tried to capture the process in logging above but know it can be a bit much to follow.
Jeff1
#19
Looks like you are matching against the outdoor temperature and then setting the indoor temperature to the correlating value using the array index value. Thus the need for a 1-to-1 correlation on values between the two arrays. And then failing our with a max / min value if we are out of range. Am I reading it right?
michicago
#20
Nailed it!
First we see if the outdoor temp is in our array. If it is, we set its corresponding heat setting. If it isn’t, we check to see if it’s below the minimum value in our array (minimum value needs to be on the far left for this to work).
If it’s not in the array, or below the minimum, it must be above the maximum. So the only thing needed in that is an “else set heat to 45”.
Talking through this, I realized our array won’t handle numbers between 14 and 25. Let me fix that.