app crashes with connection reset error

[squirtbrnr]

I'm using the docker image created by jshank. It works great, however the balboa worldwide app will crash which causes the container to crash. The container and app work just fine and update entities appropriately, however sometimes if I either send two commands successively in a short time span, or if I haven't sent any command in a while then attempt to send one, the app will crash and exit and the hot tub control never receives the command. Here is the crash that's logged. You will see it crashed after attempting to send a command, then 9 seconds later I restarted the container.

2023-07-10 14:37:06	stdout	I,   to spa: #<BWA::Messages::ToggleItem 4>
2023-07-10 14:37:06	stdout	D, wrote: 7e 07 0a bf 11 04 00 85 7e
2023-07-10 14:37:06	stderr	/usr/local/bundle/gems/balboa_worldwide_app-2.1.4/lib/bwa/client.rb:74:in `readpartial': Connection reset by peer (Errno::ECONNRESET)
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/lib/bwa/client.rb:74:in `block in poll'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/lib/bwa/client.rb:64:in `loop'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/lib/bwa/client.rb:64:in `poll'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/exe/bwa_mqtt_bridge:59:in `block in initialize'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/exe/bwa_mqtt_bridge:58:in `loop'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/exe/bwa_mqtt_bridge:58:in `initialize'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/exe/bwa_mqtt_bridge:421:in `new'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/gems/balboa_worldwide_app-2.1.4/exe/bwa_mqtt_bridge:421:in `<top (required)>'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/bin/bwa_mqtt_bridge:25:in `load'
2023-07-10 14:37:06	stderr	from /usr/local/bundle/bin/bwa_mqtt_bridge:25:in `<main>'
2023-07-10 14:37:15	stdout	I,   to spa: #<BWA::Messages::ConfigurationRequest>
2023-07-10 14:37:15	stdout	D, wrote: 7e 05 0a bf 04 77 7e
2023-07-10 14:37:15	stdout	D, discarding invalid data prior to message ff af 13 00 00 62 09 24 00 00 01 00 02 04 00 00 00 00 00 00 00 00 00 5c 00 00 00 78 00 00 c3 7e
2023-07-10 14:37:15	stdout	D, discarding invalid data prior to message 7e 05 10 bf ff
2023-07-10 14:37:15	stdout	D,  read: 7e 0d 0a bf 23 01 00 06 00 8d 00 04 00 25 7e
2023-07-10 14:37:15	stdout	I, from spa: #<BWA::Messages::FilterCycles cycle1 6:00@01:00 cycle2(enabled) 4:00@13:00>
2023-07-10 14:37:16	stdout	D,  read: 7e 1a 0a bf 24 64 dc 2b 00 4d 58 42 50 32 30 20 20 0c 10 47 d6 0a 01 0a 04 00 0c 7e
2023-07-10 14:37:16	stdout	I, from spa: #<BWA::Messages::ControlConfiguration MXBP20 V43.0>
2023-07-10 14:37:16	stdout	D, discarding invalid data prior to message 7e 05 10 bf 07 5b fe
2023-07-10 14:37:16	stdout	D,  read: 7e 0d 0a bf 23 01 00 06 00 8d 00 04 00 25 7e
2023-07-10 14:37:16	stdout	I, from spa: #<BWA::Messages::FilterCycles cycle1 6:00@01:00 cycle2(enabled) 4:00@13:00>
2023-07-10 14:37:16	stdout	D,  read: 7e 0b 0a bf 2e 0a 00 01 50 00 00 bf 7e
2023-07-10 14:37:16	stdout	I, from spa: #<BWA::Messages::ControlConfiguration2 pumps=[2, 2, 0, 0, 0, 0] lights=[true, false] circulation_pump aux=[false, false]>
2023-07-10 14:37:16	stdout	W, Balboa MQTT Bridge running (version 2.1.4)
2023-07-10 14:37:16	stdout	D,  read: 7e 0b 0a bf 2e 0a 00 01 50 00 00 bf 7e
2023-07-10 14:37:16	stdout	I, from spa: #<BWA::Messages::ControlConfiguration2 pumps=[2, 2, 0, 0, 0, 0] lights=[true, false] circulation_pump aux=[false, false]>

[axelthefatcat]

I am having this same issue and I am currently investigating it. I too have the same enviroment and I run an HA automation at 12:30 AM (SPA switches to READY and turns up the temperature, waits 4 hours then switches to rest and turns down the temperature). At this time the Add-on will crash. I have changed the time the Automation runs and the crash moves with the automation - I have also rewritten the automation incase there was a code issue.
I am still investigating as it seems to be the first command sent of a new day crashes it although still trying to prove this.