search

ccutrer / balboa_worldwide_app

Ruby library for communication with Balboa Water Group's WiFi module or RS-485
92 stars 27 forks source link

app crashes with connection reset error #75

Open squirtbrnr opened 1 year ago

squirtbrnr commented 1 year ago

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 commented 7 months ago

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.