Hot tub heat control

I was given an old hot tub and spa pack.
Spa pack is from early 90’s with mechanical timer and mechanical temperature control.
Timer no longer spins and there is no manual temperature control.

So i’m using an RPI3 for this now.
I’m using one-wire temp sensors in place of mechanical thermostat switches.
Interfacing the main contactor with a relay board attached to the PI is no issue either.
setting up a not being used temp range is again easy.
But,
I want to have 4 temp ranges.
Idle/no use
101 F
102 F
103 F

How do I control the upper temp limit?

If I have trigger to kill the heater at 101 f won’t that stop the 102 and 103 buttons/triggers from working?

any ideas on how I can do this and still be able to control it via tablet?

Thanks.

Hi @nitrogenwidget,

Welcome to Cayenne communtiy!

So what came to my mind first was enabling/disabling each trigger based on which temperature you are wanting your hot tub to turn off at. Picture uploaded showing how to enable / disable a trigger. Does this meet your need?

-B

I was thinking of that but then it would be simpler to just change the upper temp limit for the tub trigger when nobody is using it.

So i’d normally have the heater turn off at say 100 degrees.
I could just change the temp on the trigger to 101,102,103 on the fly while actually using the tub.
turn the temp up or down depending on how I was feeling and how cold it was outside.

I see there is a temp slider custom widget but it appears i need an arduino to use it.

This will be a lot easier to accomplish in the way you’re looking when we’ve added multiple conditional statements to our Trigger logic, an upcoming feature on the Cayenne Roadmap, as well. Then you’ll be able to define things like “IF temp > 101 AND temp < 103, do X”.

good to hear.
One question, if I have a schedule for a pump to run during the day for a few hrs for filtration purposes and also want to make sure the filter pump runs when the heater pump runs to avoid freezing.
Will the schedule poll the gpio and notice it’s off after the ant-freeze trigger turns it off and resume its normal filter schedule?

I want to make sure it doesn’t stop filtering because the trigger conflicted.

Thanks!

I’m a bit pool-illiterate so I’m going to answer outside the terms of your specific case here because I don’t want to confuse pumps without seeing your various schedules and triggers.

But to answer more generically for the Cayenne platform, the scheduler engine triggers only based off of the Calendar / recurrence settings you chose when creating your event. So it’s not analyzing the GPIO in any sort of way. The Triggers engine is of course, if you base a trigger off of a GPIO setting.

A lot of this will get more powerful as the platform matures and allows you to do things like conditional triggers, and/or logic in trigger events, and features allowing you to trigger based off of clock times, all of which are upcoming planned features.

so if something is turned off via trigger or button manually will the schedule turn it back on if it’s in the middle of a cycle?

I suspect that yes, if the schedule action is: ‘at X time, set widget Y to ON’, then it’s going to try to do that regardless of whether the widget is currently ON or OFF. If it was already ON it just wouldn’t have any effect.

but it looks like if the trigger turns it off when the schedule says it should be on, it stays off.
If I manually turn it off and the trigger says it should be on it stays off.

doesn’t the app do some kind of polling or maint. where it makes sure something is on or off when it’s supposed to be?

I think I figured out a way.
Just have the filter pump run for a few mins every hr. via schedule.

Glad you found a solution that will work for you in the immediate sense. I ended up running a test just to make sure I wasn’t passing you bad information based on assumption.

In my test, I just used a simple LED hooked up to a lightswitch widget. It started as off. I just made non-recurring schedules for it to turn ON at :55 :00, :05. The first time, it turned on, the subsequent times, the scheduler event still fired and the LED remained on. So I’m pretty sure it’s just blindly firing the scheduler event without regard to the state of the GPIO pin.