Problem changing mode and controlling from Hass

[TorbjOlss]

What an amazing project, really good work!
After having set this up I experience some strange behaviour, see below for more details.

Information from tub on status (heater on/off, tub temp, light on/off etc) seems to work as it should. The one exception of this is that Economy mode is never shown in the dropdown when selecting it on the display (it say Standard instead).

Furthermore controlling light and pumps does not work, my feeling is that the software is "doubble pressing" the functions. This is most clearly on the light on/off and pumps on/off, where the function is toggled on/off rapidly and goes back to the state before the activation of each function.

Below are some information on my setup and some observations (on display and via Mqtt Explorer). Please let me know if more information would be needed to track down what the problem may be.

General setup of my spa:
GL controller board and ML700 display
One smaller circulation pump and two larger pumps
ESP32 D1 Mini
Arceli TTL to RS485 (model 00160)
tub pin 5 on esp pin 18

I have installed both v0.2.4 and v0.2.3 and I get the same behaviour (below data captured with v0.2.4)

Testing functions from the controlls in Hass:

Light ON / Light OFF: (initial state set on display)
Does not work, the relay clicks twice and the light blink, then goes back to initial state

Pump 1 High / Pump 1 Off: (initial state set on display)
Same thing here, briefly off/High and then back to initial state

Pump 2 High / Pump 2 Off: (initial state set on display)
Same thing here briefly off/High and then back to initial state

Set temperature:
Does not work. When selecting a temp in Hass the display remains locked in "temp set" and the temperature steps all the way down or up.
On some occations I have had to pull power to spa/Esp to get out of this state. On another occations I got back to normal state on display after some time.

Mode change (via Hass dropdown):

When changing mode on the display Standard and Sleep are correctly shown in mode/stat_t but when selecting Economy it says Standard, i.e. it never changes to Economy in Hass when changed on the display.

Standard -> Sleep:
Blinks on the display between the states a few times and then goes to Economy

Standard -> Economy
Blinks on the display between the states a few times and then goes to Sleep

Economy -> Standard
Nothing happens, probably since the dropdown is already in Standard

Economy -> Sleep
Works, i.e. blinks on the display between the states a few times and then goes to Sleep

Sleep -> Standard
Blinks on the display between the states a few times and then goes to Economy

Sleep - Economy
Blinks on the display between the states a few times and then goes to Standard

Some data from Mqtt Explorer:
When in Standard mode:
raw/stat_t: 90000008002ffff640000000000

When in Economy mode:
raw/stat_t: a0000008002ffff640000000000

When in Sleep mode:
raw/stat_t: c0000008002ffff640000000000

Sequence captured via Mqtt Explorer when changing from Standard -> Economy on the display:
raw/stat_t:
a0000008002ffff630000000000 (2024-09-14 14:15:49 )
a0000008002ffff630000000000 (2024-09-14 14:15:49(-0 seconds) )
a4c00008102ffffff0000000000 (2024-09-14 14:15:48(-0.93 seconds) )
a4c00008102ffffff0000000000 (2024-09-14 14:15:48(-0.08 seconds) )
94c00008102ffffff0000000000 (2024-09-14 14:15:47(-1.05 seconds) )
94c00008102ffffff0000000000 (2024-09-14 14:15:47(-0.06 seconds) )
90000008002ffff630000000000 (2024-09-14 14:15:11(-36.53 seconds))

[netmindz]

Hi @TorbjOlss

Thanks for your nice feedback.

Can you confirm if it's the 2000 or 2001 you have? Also are you pumps single or dual speed?

In theory we should only be sending the button press commands once and some users this has worked for. For me personally it's not that reliable so there is a bit of a hack where I keep resending the command until I see a change of state. This was based on the behaviour of my 3rd party top panel that is closest to an ML500 rather than your 700.

So you can try disabling the retry, there are some comments in the code about where the dequeue should be.

Alternatively we might need to capture some full copies of the FA and FB commands your particular setup is using to work out what is wrong

[netmindz]

I'm not sure if you have read this thread yet, but it has quite a bit on information about our experiences so far

#25

[netmindz]

It also sounds like you are having similar experiences as this ML700 user #78

[TorbjOlss]

Hi @netmindz!

I have GL2001 as far as I can tell, it says "GL2001R1D" on the board.
The pumps are single speed i.e. on/off only.

I did read through the two reports you linked and my issues do indeed seem similar.

Thanks for the dequeing tip, I will start by trying to uncomment those rows (952 and 954) and see if it makes any difference.
I will report back when I have tested this. :-)

[TorbjOlss]

Hi @netmindz !

I installed v0.2.3 with the two rows 952 and 954 uncommented this afternoon. Some progress, but still not entirely there.

I tested to see if the Mode dropdown dialogue in hass follows what mode that is selected manually on the display:

• Standard - yes reflected correctly
• Economy - no, the dialogue says Standard when Economy is selected on the display
• Sleep - yes reflected correctly

Do you have any idea on what the problem could be for Economy not being displayed correctly?

I then also tested how the controls now works from Hass:

Light on/off: Now this works.

Pump 1 and pump 2 on/off: This also seems to work.

Turning on pump 1, turning on pump 2, turning off pump 1 and finally turning off pump 2 seem to work.
The same with turning on light, turning on pump 1, turning off light and finally turning off pump 1 also seem to work.

Switching from Standard -> Economy in hass (initial state Standard on display)
Does not work.
It changes on the display to Economy and then blinks a few times and then goes back to Standard. The behaviour is exactly as if trying to change from Standard to Economy on the display but without the final select press of the Mode button, i.e. "Mode"->"Arrow down" instead of "Mode"->"Arrow down"->"Mode"

Switching from Standard -> Sleep in hass (initial state Standard on display)
Does not work.
Here it also starts blinking on Economy and then goes back to Standard.
I.e. "Mode"->"Arrow down" instead of "Mode"->"Arrow down"->"Arrow down"->"Mode"

Switching from Sleep -> Standard in hass (initial state Sleep on display)
Does not work.
It seems only to display "Set temp" briefly as if "Arrow down" has been pressed and then nothing else.
On my display I go from Sleep -> Standard via "Mode"->"Arrow down"->"Mode"

I tried to check the rest of the status fields in hass (e.g. light, pumps, heating) and it seems as if the tub status is reflected correctly apart from the Economy mode.
One minor oddity I noticed is that it says "Circulating ?" for "Status", unclear why.

I briefly tested to change temperature on the hvac control in hass, and it does not work. It seems as if nothing happens and then the esp freezes (changes in hass e.g. light does not work). I had to unplug the esp to get the functionality back.

[netmindz]

Hi @TorbjOlss

Yeah most of what you describe there is consistent with missing commands, the drawback of no retry

You can try tweaking the time interval between simulated button presses, try both higher and lower. As you are still in the Set Mode, I'd start with increasing the delay between commands

I'll need to remind myself exactly where the state check is and how best to capture that. For your controller and a ML700 compatible config we might need to extend that variable to capture more of the FA value. The key thing is to not include the part that includes the time or temp as otherwise changes in these will be misinterpreted as state change due to correct commands sending

[TorbjOlss]

Hi @netmindz

Thanks for the quick reply!

Did some quick testing today and I think I made some progress at least.

Noted that when I change the mode on the display the field "Hottub status" in hass read the following:
Standard on display <=> "Circulation" in hass
Economy on display <=> "Cleaning" in hass
Sleep on display <=> "Circulation in sleep" in hass

I then simply swaped the s == "2" for Economy and s == "a" for Cleaning so that Economy is equal to 2 and Cleaning is equal to a (rows 761 and 764)
This seems to make the Mode dropdown in hass correctly reflect what is selected on the display on the tub (Standard, Economy and Sleep).

I will continue to test tweaking the time interval as you suggest and see what that will do. Stupid question from a non programmer; where do I do that in the best way?

[TorbjOlss]

Hi @netmindz

Done some more testing with getting changes between the modes from Hass to work.

Om my display I change between the modes on the tub display as follows:

Standard->Economy
Mode-Down-Mode

Standard->Sleep
Mode-Down-Down-Mode

Economy->Standard
Mode-Down-Down-Mode

Economy->Sleep
Mode-Down-Mode

Sleep->Standard
Mode-Down-Mode

Sleep->Economy
Mode-Down-Down-Mode

Perhaps this is the same on all displays, I do not know.

I created a simple automation in Hass to match the above keypress sequences with some added delays between each keypress.

I found out that a delay of 600ms seems to do the job, all varations of the keypresses then seem to work.

Next step I assume would be to change the delay in the code for sending commands, e.g. when changing the Mode dropdown in Hass. I am however not sure where and how to address this, any pointers would be very welcome. :-)

[netmindz]

Using the HASelect component should send all the commands needed rather than needing to make manual automations.

In terms of time between new commands

balboa_GL_ML_spa_control/sensor/src/sensor.cpp

Line 932 in 18e0866

if((millis() - lastCmdTime) >= 400) {

is the line you and try to play with to optimise for your setup

[TorbjOlss]

Hi @netmindz

Did some more testing today.

The first thing I noticed is that "Target Tub Temp" does not change after changing the temperature either on the display or in hass. In order for it to change to the correct value "Up" or "Down" need to be pressed either on the display or in hass.

I then tested changing the number in the line "if((millis() - lastCmdTime) >= 400"
I changed it from 400, 500, 600, 700, 800, 1000 and 1500. All in all I got the same behaviour for all tested delays. You could see the slowdown on the the display with the higher delays, but the results were the same.

When changing mode the following happens:
Standard->Economy: no change (Standard flashes, set temp turns on and then off)
Standard->Sleep: changes to Economy
Economy->Standard: changes to Sleep
Economy->Sleep: no change (Economy flashes, set temp turns on and then off)
Sleep->Standard: no change
Sleep->Economy: changes to Standard

My feeling is that some commands probably are different compared to yours. One difference that I found earlier is that you seem to have s=="a" for Economy whereas I seem to have s=="2" for Economy. As mentioned above I changed this earlier in rows 761, 764 to get the dropdown to show the correct mode as on the display when changing it there.

I can change manually from hass by e.g. pressing the Mode - Down - Mode buttons so those individual presse seem to work.

I then also tested changing the temperature from Hass with the hvac controller. The below resuls were the same for all the delay values I tested.
Changing temperature up does not fully work but changing temperature down seems to work.
Changing from 37 to 38 set the temp on 39 every time. On the display: (set temp->37->37.5->38->38.5->39)
Changing from 38 to 37 worked and set the temp to 37 every time. On the display: (set temp->38->37.5->38->37.5->37)
Also changing from 40 to 37 worked every time.

A question; does it matter in what mode the hvac controller is? I think I read that it does not. Mine was in "off" mode for the above tests.

[netmindz]

Hi @netmindz

Did some more testing today.

The first thing I noticed is that "Target Tub Temp" does not change after changing the temperature either on the display or in hass. In order for it to change to the correct value "Up" or "Down" need to be pressed either on the display or in hass.

This is expected - as far as I know the target temp is not sent in the FA messages as its own field, so I am just reading the value off the display when we are in Set Temp mode

I then tested changing the number in the line "if((millis() - lastCmdTime) >= 400" I changed it from 400, 500, 600, 700, 800, 1000 and 1500. All in all I got the same behaviour for all tested delays. You could see the slowdown on the the display with the higher delays, but the results were the same.

It was worth a try, I think the issue is that you are not getting 100% successful sending of messages

When changing mode the following happens: Standard->Economy: no change (Standard flashes, set temp turns on and then off) Standard->Sleep: changes to Economy Economy->Standard: changes to Sleep Economy->Sleep: no change (Economy flashes, set temp turns on and then off) Sleep->Standard: no change Sleep->Economy: changes to Standard

This is the classic symptom of missing commands

My feeling is that some commands probably are different compared to yours. One difference that I found earlier is that you seem to have s=="a" for Economy whereas I seem to have s=="2" for Economy. As mentioned above I changed this earlier in rows 761, 764 to get the dropdown to show the correct mode as on the display when changing it there.

Yeah there might need to be a bit of cleanup, at the start I was using the status for everything, so that tracks mode as well as state, e.g standard during eco, cleaning etc

I can change manually from hass by e.g. pressing the Mode - Down - Mode buttons so those individual presse seem to work.

Yeah, single commands being sent seems much more reliable, that's why toggle light has rarely given me an issue, it's when we try and fake a series of button presses, especially duplicates of the same one that we seem to struggle with.

Can you try pulling the latest code, without any of your changes - it's got some changes in there that might hopefully stop the issue you see with continual command retries, while still retaining the retry, which should help prevent missed commands

At some point, I need to try again sending the IDLE command between each button press, but I can't do that when I also have any retry sending code

I then also tested changing the temperature from Hass with the hvac controller. The below resuls were the same for all the delay values I tested. Changing temperature up does not fully work but changing temperature down seems to work. Changing from 37 to 38 set the temp on 39 every time. On the display: (set temp->37->37.5->38->38.5->39) Changing from 38 to 37 worked and set the temp to 37 every time. On the display: (set temp->38->37.5->38->37.5->37) Also changing from 40 to 37 worked every time.

Due to the way the dial works for the HVAC controller, sometimes we end up with double changes being queued. To check the maths is right, try see if the number of button presses being queued matches what you would expect

A question; does it matter in what mode the hvac controller is? I think I read that it does not. Mine was in "off" mode for the above tests.

The mode doesn't. I've had all sorts of issues with that comment and the 3rd party library. I send things like the current temp to both the standalone HASensor and the HVAC, but it updates inconsistently. I've also tried to set the current mode to change to say auto when in standard and heat when the heater is active without much luck. It doesn't really cause too many problems, just means you need the other sensors on the dashboard too

[TorbjOlss]

Hi @netmindz

Thanks for your time and effort, again very much appreciated.

...
This is expected - as far as I know the target temp is not sent in the FA messages as its own field, so I am just reading the value off the display when we are in Set Temp mode

Ok, good then there is nothing wrong in my end. It is easy enough to update the target tub temp as required with set temp mode from hass.

...
Yeah, single commands being sent seems much more reliable, that's why toggle light has rarely given me an issue, it's when we try and fake a series of button presses, especially duplicates of the same one that we seem to struggle with.

Agreed, also on my tub the single commands seem to work quite reliably.

...
Can you try pulling the latest code, without any of your changes - it's got some changes in there that might hopefully stop the issue you see with continual command retries, while still retaining the retry, which should help prevent missed commands

I will try the latest code and see what happens with regards to the missing commands. I will report back as soon as I have had time to upload and do some testing.

...
Due to the way the dial works for the HVAC controller, sometimes we end up with double changes being queued. To check the maths is right, try see if the number of button presses being queued matches what you would expect

Understood. I did all testing on my PC trying to get proper button clicks. I used the "+" and "-" buttons on the hvac controller when testing 37->38 and 38->37 and tried to only push twice. When testing 40->37 I however used the hvac controller dial.
The results were as far as I could see the same on all tests. I will test this again when testing the latest code.

...
The mode doesn't. I've had all sorts of issues with that comment and the 3rd party library. I send things like the current temp to both the standalone HASensor and the HVAC, but it updates inconsistently. I've also tried to set the current mode to change to say auto when in standard and heat when the heater is active without much luck. It doesn't really cause too many problems, just means you need the other sensors on the dashboard too

Good, then I know that this is the case. I agree that this is probably no big deal when you know about it.

[netmindz]

Had you seen that you can do remote updates using the webota?

[TorbjOlss]

Hi @netmindz

No that I had totally missed, really nice feature. Thanks for making me aware of it!

I will read up on webota and test it for sure. I am not so used to Platformio and all its possibilities, I have mostly used Tasmota and a bit Esp Home in the past.

I have used old fashioned USB upload so far which works pretty ok. I have installed everything in a project box that is connected with a RJ45 connector so it is pretty quickly done to disconnect it from the tub and flash it that way also.
However with Autumn and later on Winter coming that could be a really nice feature. Here in Sweden it is getting darker and colder every day now...

[netmindz]

You just run a build and then go to http://hottub-sensor:8080/update and upload the bin file

[TorbjOlss]

You just run a build and then go to http://hottub-sensor:8080/update and upload the bin file

Thanks!

[TorbjOlss]

Tested the new release and it does not seem to work. The web status page looks ok and says:

Mode: -1
State: Circulation
Temp: 38.0C
Heating: false
Last Update: Fri Oct 04 2024 15:57:02 GMT+0200 (Central European Summer Time)

However the tub status field in hass says: "panel select (pin 5) not detected"
and it is not possible to control anything.

Strange that the web status looks ok and the hass status says not detected. When running the Esp not connected to the tub it normally says:
Mode: -1
State: Panel select (pin5) not detected
Temp: -1.0C
Heating: false
Last Update: Fri Oct 04 2024 16:20:29 GMT+0200 (Central European Summer Time)

Just to rule out disconnected cables I reinstalled the previous code and everything works as it did before. After that reinstalled the updated code with the same error.

Checked my pins, I run an Esp32 D1 mini with pin_5 connected to "18" which seems to be what the config says by default.