1) Give a description of the problem
I have a very simple piston I’m using to test Thermostat
function. I have tried a lot of possibilities and it is unreliable.
2) What is the expected behavior?
To execute every time the HVAC turns on and off.
3) What is happening/not happening?
It does it once then stops
**4) Post a Green Snapshot of the piston. In fact, I have IDLE, Heat and Cool OR-ed combined instead of just IDLE (which seems sufficient) just to see if it would be more reliable.
Cheers,
Ray
So then triggers of “changes to heating” and “changes to cooling” are insufficient to turn on outlet 4?
Likewise, then “changes to idle” is insufficient to turn the outlet off?
I would set it up as follows:
if operatingstate changes to (heating or cooling)
Or
operatingstate is (heating or cooling)
Turn on switch 4
If operatingstate changes to idle
Or
opreatingstate is idle
Turn off switch 4
In the logs you posted, it appears to do what you want. What are you seeing in practice that you don’t like?
At 11:36:23 the thermostat reported it was heating, and the bedroom light was turned on.
About 11 minutes later, at 11:45:53 the thermostat reported it was idle, and your piston turned the bedroom light off.
Can you elaborate on this? Does this mean a few minutes later, the heat came back on but your light didn’t switch on again? Is there anything in the logs from an event like this happening?
When you say it only happens once - do you mean once after you edit and save the piston, then it never triggers again?
Sorry for all the questions - trying to sort out what might be happening. It’s a simple piston and should work reliably the way you have it set up.
Edit to add: If there isn’t anything in the logs at a time the heat turns on/off, the piston has nothing to trigger against and nothing you can write in the piston will work around that. Then you’re looking at a device/network matter to sort out.
It is VERY unreliable. The HVAC is running every 1/2 hour or so. The Log shows 11:47 AM event completed successfully and then no other triggers . . .wait for it . . until 6:18 PM. So I have to change my only once but twice so far notwithstanding that it failed about 12 times in between.
One trigger for IDLE and no IDLE as a condition or trigger should be sufficient - shouldn’t it?
The log is below:
2/6/2018, 6:32:53 PM +660ms
+1ms ╔Received event [Thermostat].thermostatOperatingState = idle with a delay of 61ms
+85ms ║RunTime Analysis CS > 16ms > PS > 41ms > PE > 27ms > CE
+87ms ║Runtime (39271 bytes) successfully initialized in 41ms (v0.2.102.20180116) (85ms)
+88ms ║╔Execution stage started
+97ms ║║Comparison (enum) idle is_not (string) idle = false (1ms)
+99ms ║║Cancelling condition #4’s schedules…
+100ms ║║Condition #4 evaluated false (6ms)
+105ms ║║Comparison (enum) idle is (string) heating = false (1ms)
+106ms ║║Condition #14 evaluated false (5ms)
+110ms ║║Comparison (enum) idle is (string) cooling = false (1ms)
+112ms ║║Condition #16 evaluated false (5ms)
+113ms ║║Condition group #13 evaluated false (state did not change) (12ms)
+114ms ║║Cancelling condition #1’s schedules…
+114ms ║║Condition group #1 evaluated false (state changed) (21ms)
+120ms ║║Comparison (enum) idle is (string) idle = true (1ms)
+122ms ║║Condition #10 evaluated true (5ms)
+123ms ║║Condition group #7 evaluated true (state did not change) (7ms)
+125ms ║║Cancelling statement #8’s schedules…
+146ms ║║Executed physical command [Bedroom Light].off() (18ms)
+147ms ║║Executed [Bedroom Light].off (20ms)
+150ms ║╚Execution stage complete. (62ms)
+151ms ╚Event processed successfully (151ms)
2/6/2018, 6:18:22 PM +564ms
+1ms ╔Received event [Thermostat].thermostatOperatingState = heating with a delay of 69ms
+89ms ║RunTime Analysis CS > 21ms > PS > 42ms > PE > 25ms > CE
+91ms ║Runtime (39276 bytes) successfully initialized in 42ms (v0.2.102.20180116) (89ms)
+92ms ║╔Execution stage started
+101ms ║║Comparison (enum) heating is_not (string) idle = true (1ms)
+102ms ║║Cancelling condition #4’s schedules…
+103ms ║║Condition #4 evaluated true (6ms)
+104ms ║║Cancelling condition #1’s schedules…
+104ms ║║Condition group #1 evaluated true (state changed) (8ms)
+106ms ║║Cancelling statement #2’s schedules…
+129ms ║║Executed physical command [Bedroom Light].on() (19ms)
+130ms ║║Executed [Bedroom Light].on (20ms)
+132ms ║╚Execution stage complete. (40ms)
+133ms ╚Event processed successfully (133ms)
2/6/2018, 11:47:53 AM +716ms
+0ms ╔Received event [Thermostat].thermostatOperatingState = idle with a delay of 73ms
+58ms ║RunTime Analysis CS > 16ms > PS > 27ms > PE > 16ms > CE
+60ms ║Runtime (39271 bytes) successfully initialized in 27ms (v0.2.102.20180116) (59ms)
+61ms ║╔Execution stage started
+68ms ║║Comparison (enum) idle is_not (string) idle = false (1ms)
+70ms ║║Cancelling condition #4’s schedules…
+70ms ║║Condition #4 evaluated false (5ms)
+75ms ║║Comparison (enum) idle is (string) heating = false (1ms)
+76ms ║║Condition #14 evaluated false (4ms)
+79ms ║║Comparison (enum) idle is (string) cooling = false (1ms)
+80ms ║║Condition #16 evaluated false (4ms)
+81ms ║║Condition group #13 evaluated false (state did not change) (10ms)
+82ms ║║Cancelling condition #1’s schedules…
+83ms ║║Condition group #1 evaluated false (state changed) (17ms)
+88ms ║║Comparison (enum) idle is (string) idle = true (1ms)
+89ms ║║Condition #10 evaluated true (4ms)
+89ms ║║Condition group #7 evaluated true (state did not change) (5ms)
+91ms ║║Cancelling statement #8’s schedules…
+110ms ║║Executed physical command [Bedroom Light].off() (16ms)
+110ms ║║Executed [Bedroom Light].off (17ms)
+113ms ║╚Execution stage complete. (52ms)
+114ms ╚Event processed successfully (114ms)
2/6/2018, 11:36:23 AM +623ms
+1ms ╔Received event [Thermostat].thermostatOperatingState = heating with a delay of 146ms
+90ms ║RunTime Analysis CS > 21ms > PS > 44ms > PE > 26ms > CE
+92ms ║Runtime (39277 bytes) successfully initialized in 44ms (v0.2.102.20180116) (90ms)
+93ms ║╔Execution stage started
+100ms ║║Comparison (enum) heating is_not (string) idle = true (1ms)
+101ms ║║Cancelling condition #4’s schedules…
+101ms ║║Condition #4 evaluated true (4ms)
+102ms ║║Cancelling condition #1’s schedules…
+103ms ║║Condition group #1 evaluated true (state changed) (7ms)
+104ms ║║Cancelling statement #2’s schedules…
+128ms ║║Executed physical command [Bedroom Light].on() (21ms)
+129ms ║║Executed [Bedroom Light].on (21ms)
+131ms ║╚Execution stage complete. (37ms)
+131ms ╚Event processed successfully (132ms)
Thanks for your thoughts.
Cheers,
Ray
Wow, that’s a lot of missed triggers! The good news is your piston is written perfectly well (it should actually work with just your idle vs no idle condition, no need for the redundancy of the others).
The bad news is the problem is either your thermostat is not always reporting its activity, or your network isn’t carrying its activity all the way back to SmartThings.
A couple quick questions - has this worked reliably in the past? New thermostat? Any internet connections at home? What about devices near your thermostat? Are they communicating reliably?
Sorry for the barrage of questions again, but those are the things that need to be worked through to figure out a culprit.
Yes it should!
I started using triggers and that didn’t work any better. If you see my post below. I get huge gaps of noncompliance to a trigger/condition. The furnace is cycling every 1/2 hour and I can get a 6-hour block of time w/o a response of the piston.
To add redundant triggers doesn’t seem to be a solution. I only did that to try to figure out what was happening.
Unless I’m missing something it is miss-firing and frequently.
Thanks for your thoughts. This is a bit of a head-scratcher?
Cheers,
Ray
You only need two conditions to do what you’re trying to do:
If thermostat is idle, do this
If thermostat is not idle, do this
You could actually simplify it a step further and say “if thermostat is idle, do this, else do this”, covering it off in one condition.
But the problem isn’t your piston; it’s written perfectly fine. If the logs are not showing activity for hours at a time when you know your thermostat is cycling on and off every ~30 minutes, the problem is with your thermostat or your network (communication between your thermostat and ST hub).
There’s absolutely nothing you can put in a piston to make it trigger if the event isn’t being report to your ST hub. That’s why I asked these questions:
I don’t know if this is a new piston you wrote or one that was working but you started tweaking because it wasn’t working reliably.
Thanks for your thoughts.
I agree 100% with the simplifications of: If then else structure around a simple IDLE. All other interactions were tried by me to better understand and diagnose the problem. They surely should not be needed…
It is a relatively new thermostat (months) and the piston is just a few days old. The thermostat does its job “as a thermostat” it is still in dispute whether it is a “smart” thermostat or not. For the record, it is an Ecobee3 Lite. Its Internet connectivity to the App has been just fine.
How then to approach a solution? Do you think Ecobee Tech support will have the know how to do this?
Are there any trace tools that can determine how the trigger is formed, or not, so that I have diagnostic evidence when approaching Ecobee?
Has anyone else reported this problem?
Can anyone who reads this post try this simple piston to see if their smart thermostat is actually smart?
Thanks again.
Be well.
Cheers,
Ray
I would start by calling SmartThings and having them look at what’s available on their end. They’ve always been extremely helpful when I’ve contacted them, and can give you some data to take to Ecobee should it start to look more like a device issue.
Do you have any other devices near your thermostat? If you do, and they’re reaching your hub without issue, then it starts to narrow down the scope of possible culprits.
I will try contacting them (SmartThings/Samsung). They seem to have both email and 1-800 contacts. Thanks for the suggestion.
My thermostat is about 12’ from the hub. I have devices closer and farther, including one in my garage and I live on the 4th floor. All have worked well.
It sure seems like a SmartThings network communication problem. It is, however, complex so I do appreciate all the help that I can get.
Just to set the background. The objective of the piston is to, once I’m on solid ground, build an energy demand piston that will control all of the high energy appliances: HVAC, Electric Water Heater, Dryer, etc. to flatten the on-peak demand (kWatts). This will allow me to get a Demand Time Of Use (TOU) electric meter, and, in combination with my future EV (Tesla M3) save $ on electricity. It can be substantial circa $35/month per my preliminary calculations.
Be well.
Cheers,
Ray
P.S. It would sure be helpful if someone could run my piston with their Ecobee3 Lite thermostat and see if the same thing occurs.
Did you ever solve this problem? I’m trying to do something similar with an Ecobee4, and unfortunately I’ve run into the same lack of reliability.
I’m trying to supplement my furnace with some extra heat in a cold room. The logic is pretty simple -
when the thermostat is on, and the ColdRoomTemp < WarmRoomTemp, turn on the electric heater
–> else, turn off the electric heater
when the thermostat is off, turn off the electric heater
My code worked last night, and in the morning when the furnace kicked on, the heatingstate was always reported as off.
I could simplify it considerably by taking the thermostat out of the equation and just base on the temp sensors. I have 1 for each room, so I could just as easily say
If ColdRoomTemp < WarmRoomTemp, turn on electric heater, otherwise off.
This logic would keep the rooms in sync - regardless of the thermostat wants heat in that room, but presumably if the thermostat is off, the WarmRoomTemp would be cold, and the electric heat wouldn’t come on regardless.
Thoughts?
-Dan
Here’s my simplified version, adding a check to make sure the room sensor is at least online (can’t prevent someone from moving it, covering it, etc…)
