2021-11-11 17:13:06 ERROR (Thread-6) [geckolib.driver.accessor] Enum accessor inFloErrorType out-of-range for ['FLOW_OK', 'MODE_1_FAIL', 'MODE_1_AND_2_FAIL', 'MODE_1_AND_HEATING_FAIL', 'HEATING_FAIL']
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/geckolib/driver/accessor.py", line 124, in _get_value
data = self.items[data]
IndexError: list index out of range
2021-11-11 17:13:06 ERROR (Thread-6) [geckolib.driver.accessor] Enum accessor inFloErrorType out-of-range for ['FLOW_OK', 'MODE_1_FAIL', 'MODE_1_AND_2_FAIL', 'MODE_1_AND_HEATING_FAIL', 'HEATING_FAIL']
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/geckolib/driver/accessor.py", line 124, in _get_value
data = self.items[data]
IndexError: list index out of range
2021-11-11 17:13:21 ERROR (Thread-6) [geckolib.driver.accessor] Enum accessor inFloErrorType out-of-range for ['FLOW_OK', 'MODE_1_FAIL', 'MODE_1_AND_2_FAIL', 'MODE_1_AND_HEATING_FAIL', 'HEATING_FAIL']
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/geckolib/driver/accessor.py", line 124, in _get_value
data = self.items[data]
IndexError: list index out of range
2021-11-11 17:13:21 ERROR (Thread-6) [geckolib.driver.accessor] Enum accessor inFloErrorType out-of-range for ['FLOW_OK', 'MODE_1_FAIL', 'MODE_1_AND_2_FAIL', 'MODE_1_AND_HEATING_FAIL', 'HEATING_FAIL']
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/geckolib/driver/accessor.py", line 124, in _get_value
data = self.items[data]
IndexError: list index out of range
starting with the latest HA version (running core-2021.12.8) I’ve noticed the blower being switch on and off on their own.
Every X hours the blowers turn on for exactly 1 min and then they turn off. As per the logger it’s not really an automation or a user command enabling (and disabling it):
For anyone who has a newer spa that is having problems setting up this integration, I made a slight tweak to it. The way the original code works is it asks the spa for its model and version and then looks for that in the file downloaded from gecko. In my case it found the spa model but only an earlier version. I tweaked it to remove the version check and it worked fine for me. I had to manually tweak the pump levels in fan.py to only OFF and HI for my model, but that all sorted it. I also bundled in the library in the directory to make it easier to install. You can find the updated code here;
For what it is worth, My controller cycles through all of the pumps and speeds everyday at 3pm. I believe it is dependent on “water care” settings and has nothing to do with the integration and gecko unit. It runs for a total of 20 minutes. I think ensures there isn’t any static water to help with sanitizing.
All tub devices are passive, so anything that happens is from the Gecko spa pack. Attached to the inside of the spa pack lid is a sheet showing the configured set-up (or should be). The standard setup is for each of the devices attached (jets, blowers, waterfalls) to be cycled in sequence each for a minute at the beginning of each filter cycle. Other than that the only thing to be actuated is the circulation pump when the temperature is checked (a frequency that varies according to configuration) and the heater if the temperature falls below the setpoint. Once the heater is on, it runs the circ pump continuously until the setpoint is reached.
As far as I know, there isn’t a configuration that allows for the blower to run periodically, but I’m happy to learn!
Hi rhino rich.
What is required to get this working?
This is exactly what I was hoping to find when I started my Google on the subject?
I ton am on octopus go and want to ramp temp to 40 by 0430. Then revert to 37. Manual testing of this has shown in spring time the heater won’t kick in again until 1300 so should be a good saving.
(I’m fairly green this sort of thing but recently managed to get a rpi working on my batter storage - using Google and a helpful Facebook community)
type: entities
entities:
- entity: input_datetime.pm_on_time
name: Boost On Time
- entity: input_number.pm_on_temp
name: Evening Temperature
- entity: input_datetime.pm_off_time
name: Boost Off Time
- entity: automation.pm_setpoint_change_1
name: Enable Evening Boost On
- entity: automation.pm_setpoint_2
name: Enable Evening Boost Off
- entity: automation.heat_boost_on
name: Enable Octopus Overnight Heat On
- entity: automation.heat_boost_off
name: Enable Octopus Overnight Heat Off
- entity: input_datetime.octopus_on_time
name: Time to Start Octopus Heating
- entity: input_number.octopus_on_temp
name: Target temperature
There are 4 automations that change the setpoint. 2 for the overnight heat, 2 for the afternoon boost. The high temperatures are settable, along with the on-off times for the afternoon boost and finally the on-time for the overnight boost. This is because in the summer it can heat too quickly, leaving a longer cooldown period before the afternoon boost, which can increase the off-tariff heating time. I’ve thought about an algorithm to auto set the on-time, but I’m too lazy.
Here’s what the automations look like. All 4 are basically the same, using the appropriate time or temperature:
alias: Heat Boost On
description: ''
trigger:
- platform: time
at: input_datetime.octopus_on_time
condition: []
action:
- service: climate.set_temperature
target:
entity_id: climate.ducky_tub_heater
data:
temperature: '{{states(''input_number.octopus_on_temp'')}}'
mode: single
the datetime and temperature entities are all ‘helpers’.
Yes, this is HA running on a rpi but that’s only because I have lots of other home automation, too. It isn’t essential as long as you have a computer that can be left running.
The In.Touch2 module is absolutely necessary, as is gazoodle’s integration.
Anyone getting their heater turning on when it shouldn’t ?
The past couple of weeks, I’ve set the mode on weekdays (via Gecko app) to ‘Away from home’ which has constant eco mode. I realise if theytemp drops below 26.5 then the heater will come on. However a few midweek mornings I’ve woken to find the heater is on. If I toggle the mode to another one and back, the heater goes off. I contacted Gecko who told me it was probably the frost prevention thing but I know it’s not as the temp was no where near that low and besides, it should only heat enough to get above 26.5 right ?
Well that was a experience. Thanks for everyone’s tips above .
18hrs on sat and 5 on sun and I’ve figured out how it all works (kind off) and we’re up and running.
Not sure if anyone else has a similar issue.
It doesn’t do the temp settings every time.
Tuesday night it boosted temp when cheap electric came on but didn’t turn temp back down.
A bit of testing and I found if I watch the temp display in HA the set point does move but then quickly reverts as if it is still getting a temp setting from elsewhere.
This never happens if I force the run actions.
I have even put in the automation a ‘set temp—- delay —- set temp again —- delay —- set temp again’ action but it is still hit and miss.
What I found is now I’m on HA and that is now linked to my apple home. Where I can run similar automations although it’s a lot more limited by what automations you can put together that’s what I’m using until i figure the HA issue out.
I don’t think it’s HA that has the issue. I have exactly the same if I set Alexa routines, and even using the In.Touch2 app, too. I did the same as you with a repeat instruction in automations but, as you say, it’s still hit and miss. I have missed message like this 2-3 times a week.
.