The temperature attributes are in a climate template. See below. For the meanings of the other exposed entities, it’s a case of trying each one to check on their function. Controllers can be a random in how they expose their functions and HA has only a limited number of entity types. For example, the Gecko controller we have exposes the jets with 3 states - OFF, LOW & HIGH, even though ‘LOW’ is never used or exposed. HA doesn’t have a 3-state switch, so Gazoodle has used the ‘Fan’ entity for those. To address them, the code will be something like this:
Personally, I’d use standard mode and create automations to adjust the setpoint as you wish, but that’s just me. I trust Home Assistant more than I trust Gecko!
I upgraded to have HA available through Nabu Casa to override settings wherever I am. Even if an automation goes wrong I can remotely change whatever I need.
Climate template:
sensor:
- platform: template
sensors:
spa_temperature:
friendly_name: Spa Temperature
value_template: '{{ states.climate.ducky_tub_heater.attributes.current_temperature }}'
unit_of_measurement: °C
spa_setpoint:
friendly_name: Spa Setpoint
value_template: '{{ states.climate.ducky_tub_heater.attributes.temperature }}'
unit_of_measurement: °C
Oh - a note on ozone. Very few tubs have an integrated Gecko ozonator. It’s far more likely to be a generic generator linked to the circulation pump. The Gecko controller doesn’t know it’s there. Same with filtering - the majority of tubs have suction through the filter whenever the circulation pump is running.
Thanks for the info. I’m hoping to have a bit more time this weekend to check on these entities.
Yes. I am considering using standard and creating automations if the controls are not working as I expected it to be.
I am not using Nabu Casa but have duckdns and reverse proxy configured for remote connectivity. Apologies, I meant the in-touch android app that stopped working remotely. It’s stuck looking for the spa.
I didn’t know about the ozone. Again, thanks for the info.
More importantly, is it possible to display the state in the card. ie: in the more info it is showing “Cooling to target”. I can’t seem to find a way to display that in the card.
I think having the card look like the popup is still being worked on. In the meantime though, you could create a vertical stack of 2 cards, put the climate card in the top one and then put a template card containing {{(state_attr('climate.hot_tub_heater', 'hvac_action')) }} (Which would give you the word ‘cooling’ here)
Thanks. I used a combination of button card (container) and mushroom climate card instead.
tap action, navigates to another page with all thermostat card and other sensors. Just realised I was using the better thermostat card. the HA thermostat card shows the status now.
You could also try the tile card as they added the ability to show the presets
type: tile
entity: climate.hot_tub_heater
features:
- type: target-temperature
- type: climate-preset-modes
style: dropdown
preset_modes:
- Away From Home
- Standard
- Energy Saving
- Super Energy Saving
- Weekender
I really am lost with all these instructions. I set up HA mainly for spa control, or atleast hoped so. I’m super noob or becoming too old to understand all this.
Spa control is in.touch2 and i have the HACS @gazoodle version. I can fiddle with the temperature but not the way i was dreaming.
I tried to install Nordpool and hoped to make easy automation with HA to follow the price and heat when its cheap. Did not work.
I tried to follow your guidelines here but my basic knowledge is too low for this subject and i get more diizzy everytime I try to start over investigating how to complete this.
So what I thought I could make on my own was:
Easy way to set manual “boost” times just by looking Nordpool (usual times are the night times in Finland when price is at 1-4 cent €)
Easy way to set the temperature of the spa drop to cooling by daytime or the mornings.
My tariff is a time-of-day thing, so it’s very easy, but I’d suggest that if the NordPool pricing is generally low at night, then just use a time based approach. It might not fully optimise things, but heating the tub to maximum overnight and then letting it coast down is a very economical way to run it. We estimate we save around 50% of the cost versus using a single setpoint continuously. We pay 7.5p overnight and 21p during the day.
Hi @RhinoRich
Have you made any updates/improvements to your automation code? This will be the first automation script I’m going to write. I have real time 5-minute pricing integrated into HA from my electricity utility, but I may start with the simple time based approach, as you mentioned.
Thanks
Scott
Curious for your input here. Thank you for providing your scripts. As a newbie, it was very helpful in helping me conceptualize what I’m doing. I used some of your language and combined it with some code from my utility’s real time pricing sensor.
This is what I ended up with:
- alias: hot tub on
trigger:
- platform: numeric_state
entity_id:
- sensor.comed_5_minute_price
below: 1.5
condition: []
action:
- service: climate.set_temperature
target:
entity_id: climate.cedar_tub_heater
data:
temperature: 104
- service: notify.mobile_app_scotts_iphone
data:
message: ComEd prices are below 1.5 cents, Hot Tub is set to 104F.
title: Hot Tub Heater on Cheap Electricity!
mode: single
- alias: hot tub off
trigger:
- platform: numeric_state
entity_id:
- sensor.comed_5_minute_price
above: 3
condition: []
action:
- service: climate.set_temperature
target:
entity_id: climate.cedar_tub_heater
data:
temperature: 98
- service: notify.mobile_app_scotts_iphone
data:
message: ComEd prices are above 3 cents, Hot Tub is set to 98F.
title: Hot Tub Heater off Expensive Electricity!
mode: single
So basically I have a “cheap energy, heat to 104F” command and a “expensive energy, turn down setpoint to 98F” command.
But because 5-minute pricing is so variable from the utility, this is getting triggered A LOT. I’m worried the control board won’t like how often its being told to change its set point, turn on heater, turn off heater, etc.
I have a similar thing with a heat pump I use in my garden pub. It has a thermostat that only goes down to 16. When not in use it runs in a frost-prevention mode I created to prevent the fridge, etc., from becoming inoperable. It works by using a smart switch to fire the heat pump if the temperature gets low.
Heat pumps need to run for a while to be effective, so I didn’t want it to switch on and off too frequently. Same with the hot tub. It has to fire the circulation pump and then stabilise temperature measurement before powering the heater. It will then take at least 30 minutes to have any effect on the water temperature.
My heat pump automation uses a helper called ‘Timer’. The ‘On’ routine sets Timer to 1, waits 2 hours and sets Timer to 0. The ‘Off’ routine checks if the temperature is above the setpoint but has a condition to check that Timer is set to 0.
One thing I learned about our hot tub, which has a 1650 litre capacity, is that it’s not efficient to run the heater for short periods. I studied the effect of continuous heating versus heating to max and ‘coasting’ over 2 cold months 3 years ago. My theory is that a lot of energy is consumed bringing the heater up to temperature. Once it reaches the point where it’s transferring its energy to the water, it’s at its most efficient.
by ‘continuous heating’ what I mean is running it with a fixed setpoint. Sorry for the confusion. In this mode, it would usually heat for about 45 minutes every 3 hours. Not efficient compared to running it for 4 hours overnight and coasting down.
Our tub is super insulated, so I’m guessing your findings would be even more effective for us. I don’t have a lot of data yet, but once up to temperature, we only lose 1-2F across the entire day. The tub is still new to us, and we haven’t hit our typical cold Chicago weather yet, so I’m curious to see how it performs during much colder weather.
I will explore adding a timer condition to the routine!
I think I would specifically want a condition on the ON routine. If tub is heating and elec prices skyrocket, I do want the tub to turn off in those instances. That said, I do not necessarily want it to turn back on again 5 minutes later just because pricing came down, then maybe off again 10 minutes after that.
I’m going to have to think this through in a little more detail. I may revert back to what you have originally designed, which is an ON schedule at night with a pricing spike trigger. Or perhaps an ON trigger with a condition for only if hot tub temp is below a certain threshold, i.e. I do not need the hot tub to bounce between set points if tub is already at 102-103F.
Anyone found a way set/sync the tub’s clock without using the keypad on the tub itself?
Mine still hasn’t adjusted for the end of daylight savings time and has gained about 9 minutes. I don’t think I’ve had to do anything in past years to get it to adjust.
Probably related: Has anyone had problems with the gecko/in.touch communicating with Gecko’s servers?
Mine has a solid green light, which is listed as no internet access. I can see UDP packets for port 10022 going through the firewall to intouch.geckoal.com 13.68.99.102. But it looks like that host is returning an ICMP port unreachable.
The data in the packet from the gecko appears to be <PINGS>1</PINGS> but might be being sent to the wrong destination. The Home Assistant Gecko integration still works fine. Also the in.touch app on iOS still works fine on the local network.
I’ve tried power cycling the network side Gecko in.touch2 unit. Doesn’t seem to help. I haven’t tried powercycling the tub or trying to do a hard reset of the network unit (if there is a reset button).
EDIT/Update - digging into this a little more, the ICMP Port Unreachable response from intouch.geckoal.com doesn’t seem to ever make it back to the gecko/intouch unit. For some reason it looks like the gecko server is indicating in the ICMP response that the host response is coming from 10.0.2.4 rather than intouch.geckoal.com 13.68.99.102. The IP header on the ICMP packet has the right source/dest IP addresses, but the IP header inside of the ICMP response shows the src address as 10.0.2.4 instead of 13.68.99.102. So it looks like my router drops that because it doesn’t match an established connection.
(To be clear I’m not using 10.0.0.0/8 addressing anywhere internally. I think this might be the internal nat address for the gecko server, which isn’t getting corrected on the way back out.)
In case this might help anyone else: I was able to work around my tub’s gecko in.touch2 unit not talking to the gecko servers and get the LED back to solid blue.
As mentioned above, the tub’s gecko unit was looking up the A record for intouch.geckoal.com. Contacting that server would result in an ICMP port unreachable that never made it back, possibly because the NAT wasn’t done correctly on the server side.
I was able to work around that by adding an entry to my router to return the IP address for intouch2.geckoal.com.
I know that’s a bit of a hack. Maybe the root cause is that my gecko unit missed an update. Maybe there is something misconfigured on the gecko cloud server end.
I did capture the request/response packets for doing a time sync to the Gecko server. At some point I need to see if by any chance the gecko unit will accept an unsolicited time response.
