how to determine the delay time

[PeteEmbleton]

Thanks for the great project.
i am running an old Balboa 1500 and am hoping to do some load shifting with my solar excess.
Unig the main branch i am getting all the data but cannot send anything, it keeps trying to resend until i manully press the button i was emulating, at which point it says it got the command.
reading through the discussions i saw the tip about making sure the ttl to RS484 is at 5 v and not 3,3, which i had origannly done, i have changed that now but to no avail.
reading through some futher discussions i aslo saw a branch called control-send-command, which seemed to contain the testing for sending commads when i load this branch i get a much more verbose output in the serial terminal, which does reflect the status of the spa.
still no luck in sending commands however, i am getting the messages
onPumpSwitchStateChanged Pump1 2
Sending fb060343060006f9a2 - 2 times
message sent : 0
fa 14 33 35 30 43 00 03 62 00 00 08 80 02 ff ff fa 14 33 35 30 43 00
LCD: 350C T: 35.0 Tset: -1.0 State: Economy P1: 0 P2: 0 Heat: 0 Light: 1 Power: 0.0 Time: 255:2 T2T: 0.0 T_F: 121.0 CRC: 0
fa 14 33 35 30 43 00 03 62 00 00 08 80 02 ff ff 5f 00 00 00 00 00 a6
LCD: 350C T: 35.0 Tset: -1.0 State: Economy P1: 0 P2: 0 Heat: 0 Light: 1 Power: 0.0 Time: 255:2 T2T: 0.0 T_F: 35.0 CRC: A6
fa 14 33 35 30 43 00 03 62 00 00 08 80 02 ff ff 5f 00 00 00 00 00 a6
LCD: 350C T: 35.0 Tset: -1.0 State: Economy P1: 0 P2: 0 Heat: 0 Light: 1 Power: 0.0 Time: 255:2 T2T: 0.0 T_F: 35.0 CRC: A6
ERROR: Pin5 went high before command before flush : 0

i have been playing around with the delay time, I have tried from 40 up to 2500, is there any way that we can deduce approx this should be by interacting with the buttons on the spa and capturing the output in the code?

thanks for any advice

[netmindz]

Hi Pete

Timing is something I've really struggled with as there is only a very short time window between reading the message from the controller and when you can reply.
I did but a cheap oscilloscope, but I think a logic analyser might be more appropriate.

The code I'm running on my tub at the moment has the mqtt loop in a background task pinned to one of the CPU cores to help with the timing.

I've never had 100% successful sending personally, which is why the code has the retry until I see a change of state. Others have apparently been able to remove the retry; I'm not sure if they use the idle command like the real panels do.

What if really odd if that sometimes I see different behaviour even when I hadn't changed the code, so I can only assume it relates to the fact that the microcontroller is also running other tasks like the WiFi and network activity.

Debugging is tricky as any Serial.Print debugs slow down the code.

When I tried to port the code to esphome, I couldn't get command sending to work at all due to timings.

For testing I would recommend you use the toggle light command for testing. If you can't send any command, then double check you have the transmit side of the max485 wired up correctly and if possible, confirm the output using a logic analyser or osilscope

[PeteEmbleton]

Thanks for getting back to me.Next time there is a rainy weekend I will see what I can come up with.My initial thoughts are to capture the events into memory and then dump them every couple of seconds, along with the timing but will have to see if that works.Thanks for the great work in getting this far and sharing your learning.PeteOn 31 Mar 2025 8:43 pm, netmindz ***@***.***> wrote: Hi Pete Timing is something I've really struggled with as there is only a very short time window between reading the message from the controller and when you can reply. I did but a cheap oscilloscope, but I think a logic analyser might be more appropriate. The code I'm running on my tub at the moment has the mqtt loop in a background task pinned to one of the CPU cores to help with the timing. I've never had 100% successful sending personally, which is why the code has the retry until I see a change of state. Others have apparently been able to remove the retry; I'm not sure if they use the idle command like the real panels do. What if really odd if that sometimes I see different behaviour even when I hadn't changed the code, so I can only assume it relates to the fact that the microcontroller is also running other tasks like the WiFi and network activity. Debugging is tricky as any Serial.Print debugs slow down the code. When I tried to port the code to esphome, I couldn't get command sending to work at all due to timings. For testing I would recommend you use the toggle light command for testing. If you can't send any command, then double check you have the transmit side of the max485 wired up correctly and if possible, confirm the output using a logic analyser or osilscope —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>