Balboa Hot Tub/Spa Automation and Power Savings

Here’s how I was able to get my hot tub (Divine Sinclair) to show up in Home Assistant to allow all of the automation goodness. Clearwater Spas/Balboa equipment speaks a proprietary protocol over RS-485. Luckily for us, it’s been decoded and put into an open source project that uses MQTT as a communications broker.

UPDATE 2 You no longer need to manually create the entities. Balboa Worldwide App MQTT Homie Bridge now publishes them through Home Assistant MQTT Auto Discovery!

UPDATE 1 I’ve tested and confirmed the $24 RS-485 to WiFi works quite well and migrated the software to a docker container. Check out jshank/bwalink on GitHub for more details.


Original Post
This is version 1.0 and very, very DIY. For V2, I’m using an ESP8266 to just relay the RS-485 data over wifi to another host for processing to MQTT (still a bit janky). V3 looks to be a $24 premade RS-485 to WiFi adapter but I still need to test it. You could also spring for the $250 Balboa wifi module that does the exact same RS485 over WiFi, but what fun would that be.

Disclaimers and Legal Stuff First

As an Amazon Associate I earn from qualifying purchases. I get commissions for purchases made through links in this post. Most hot tubs are fed 240v and are capable of delivering 50-amps of current = 12,000 W so… electricity is dangerous and can cause personal injury or DEATH as well as other property loss or damage if not used or constructed properly. If you have any doubts whatsoever about performing do-it-yourself electrical work, PLEASE do the smart thing and hire a QUALIFIED SPECIALIST to perform the work for you.

NEVER WORK WITH LIVE VOLTAGE. Always disconnect the power source before working with electrical circuits.

How to Get Your Hot Tub into Home Assistant

Parts

Tools

1. Make the cable

My hot tub had a small Y-Cable hanging outside of the control box that you can plug into for power and to get to the RS-485 communications of the tub. If you don’t have this cable, you can likely plug into the main control board IF it has the same outlet type. This should be the same type of connector that goes to your control panel.

Note that the tab is on the left of the connector

The connection is an ATX Molex Micro Fit Connector 4Pin (no, not the same as your old ATX power supply, I know, I tried too). Cut the one you ordered in half since you’ll be making your own cable.

Next, we are going to adjust that 15.9 Volt output to 5 Volts so we can power our Raspberry Pi. I used a 12V power supply to calibrate but anything with more than 9V DC should work. Connect your multimeter and power supply to the DC-DC buck converter as shown below. Set your multimeter to DC voltage and then, using a small screwdriver, carefully turn the adjustment screw until the multimeter reads 5V.

These things are easy to break which is why then send you a bunch.

Disconnect everything from the DC-DC buck converter and be careful not to touch that adjustment screw. After final testing, put a small drop of hot glue on it to prevent accidental adjustments.

From the ATX Molex Micro Fit Connector, strip and solder the wire corresponding to +15.9 V DC to the DC-DC buck converter IN+ and the wire corresponding to ground to the DC-DC buck converter IN-. Then solder a length of the black silicone coated wire to the DC-DC buck converter OUT- and a length of the red silicone coated wire to the DC-DC buck converter OUT+. I suggest about 36" so you can stash the Raspberry Pi in the media-device pocket. Don’t forget to heat-shrink or electrical tape those connections.

Next we’re going to test our work and make sure that we did everything right. Strip the ends of the other ATX Molex Micro Fit Connector and take it, your multimeter, and your partially completed cable, out to the tub. Put some electrical tape around the exposed cables corresponding to the RS-485 A and B connections so you don’t short them. Connect your multimeter to the stripped connections (wire corresponding to +15.9 V DC and Ground) and make sure you are getting voltage where you expect it.

Now connect up your partially completed cable and measure the voltage coming from the DC-DC buck converter to confirm you are getting 5V, adjust the DC-DC buck converter screw if needed. If everything checks out, disconnect your partially completed cable and head back to your workbench/desk/table.

Heat that soldering iron back up and don’t forget to slide heat shrink tubing on the red and black silicone wires coming from the DC-DC buck converter. Solder those wires to the Micro-USB pigtail (red to red and black to black) and then seal everything up nicely with heat shrink or electrical tape. Insert the DC-DC adapter into your 3D printed enclosure or wrap it up with more electrical tape.

For the data wires, cut and solder a length of blue silicone coated wire to the ATX Molex Micro Fit Connector wire corresponding to the RS-485 B or -. Do the same for with a yellow length for the RS-485 A or +. I suggest crimping some 22AWG ferrules to the ends of those cables or you can just tin them and be careful.

That was the hardest part of the project, congratulate yourself.

Finished Cable

2. Setup the software

  • Setup an MQTT Broker
  • Following the directions here, install the Raspberry PI OS (formerly Raspbian) on your Raspberry PI SD card and get it connected to your wireless network

NOTE: You can just run jshank/bwalink in Docker if you don’t want to install Ruby and Balboa Worldwide App MQTT Homie Bridge. jshank/bwalink even supports a remote connection to a serial over IP device. More info in the GitHub readme.

  • SSH to your Raspberry Pi and sudo apt install ruby
  • Install the Balboa Worldwide App MQTT Homie Bridge by following the directions in the link. Note that your RS-485 adapter will most likely be /dev/ttyUSB0 if you bought the recommended hardware from the parts list.
  • Subscribe to the homie/# topic on your MQTT broker and then start the BWA service sudo systemctl start bwa_mqtt_bridge to confirm you are getting data
  • Shutdown the Raspberry Pi and head out to the tub with your Pi, RS485 USB adapter and custom cable.
  • Route the cable however you see fit and screw the blue wire into the B- terminal and yellow wire into the A+ terminal of the RS-485 to USB adapter. Plug the other end of your customer cable into the tubs Y-cable or J33 port on the main control board
  • Plug the micro-USB connector into your Pi and marvel at your work so far.

Within a few minutes and with some luck, you’ll see MQTT populated with data from your tub (example below).

homie/bwa/$homie 4.0.0
homie/bwa/$name BWA Spa
homie/bwa/$state ready
homie/bwa/$nodes spa
homie/bwa/spa/$name BWA Spa
homie/bwa/spa/$type CL501X1
homie/bwa/spa/$properties priming,heatingmode,temperaturescale,24htime,heating,temperaturerange,currenttemperature,settemperature,filter1,filter2,pump1,pump2,pump3,light1,circpump
homie/bwa/spa/priming true
homie/bwa/spa/priming/$name Is the pump priming
homie/bwa/spa/priming/$datatype boolean
homie/bwa/spa/heatingmode ready

3. Configure Home Assistant

NOTE: This is no longer necessary since Balboa Worldwide App MQTT Homie Bridge publishes the entities in the BWA Link device using MQTT Auto Discovery.

You can now setup Home Assistant using the following yaml configurations that represent the sensors and switches of your tubs functions.

Switches

  - platform: mqtt
    name: "Hot Tub 24hour Clock Mode"
    state_topic: "homie/bwa/spa/24htime"
    availability:
    - topic: "homie/bwa/$state"
      payload_available: "ready"
      payload_not_available: "lost"
    command_topic: "homie/bwa/spa/24htime/set"
    payload_on: "true"
    payload_off: "false"
    icon: mdi:wrench-clock
    
  - platform: mqtt
    name: "Hot Tub Pump 1 (Lounge)"
    state_topic: "homie/bwa/spa/pump1"
    availability:
    - topic: "homie/bwa/$state"
      payload_available: "ready"
      payload_not_available: "lost"
    command_topic: "homie/bwa/spa/pump1/set"
    payload_on: "toggle"
    payload_off: "toggle"
    state_on: 2
    state_off: 0
    icon: mdi:chart-bubble
  
  - platform: mqtt
    name: "Hot Tub Pump 2 (Seats)"
    state_topic: "homie/bwa/spa/pump2"
    availability:
    - topic: "homie/bwa/$state"
      payload_available: "ready"
      payload_not_available: "lost"
    command_topic: "homie/bwa/spa/pump2/set"
    payload_on: "toggle"
    payload_off: "toggle"
    state_on: 2
    state_off: 0
    icon: mdi:chart-bubble

  - platform: mqtt
    name: "Hot Tub Pump 3 (Feet)"
    state_topic: "homie/bwa/spa/pump3"
    availability:
    - topic: "homie/bwa/$state"
      payload_available: "ready"
      payload_not_available: "lost"
    command_topic: "homie/bwa/spa/pump3/set"
    payload_on: "toggle"
    payload_off: "toggle"
    state_on: 2
    state_off: 0
    icon: mdi:chart-bubble

  - platform: mqtt
    name: "Hot Tub Light"
    state_topic: "homie/bwa/spa/light1"
    availability:
    - topic: "homie/bwa/$state"
      payload_available: "ready"
      payload_not_available: "lost"
    command_topic: "homie/bwa/spa/light1/set"
    payload_on: "true"
    payload_off: "false"
    state_on: "true"
    state_off: "false"
    icon: mdi:car-parking-lights

Sensors

- platform: mqtt
  name: "Hot Tub Circulation Pump"
  state_topic: "homie/bwa/spa/circpump"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"
  icon: mdi:sync

- platform: mqtt
  name: "Hot Tub Priming"
  state_topic: "homie/bwa/spa/priming"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"

- platform: mqtt
  name: "Hot Tub Temperature Scale"
  state_topic: "homie/bwa/spa/temperaturescale"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"

- platform: mqtt
  name: "Hot Tub Heating"
  state_topic: "homie/bwa/spa/heating"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"
  icon: mdi:hot-tub

- platform: mqtt
  name: "Hot Tub Temperature Range"
  state_topic: "homie/bwa/spa/temperaturerange"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"
  icon: mdi:thermometer-lines

- platform: mqtt
  name: "Hot Tub Current Temperature"
  state_topic: "homie/bwa/spa/currenttemperature"
  unit_of_measurement: "°F"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"

- platform: mqtt
  name: "Hot Tub Filter 1 Cycle Running"
  state_topic: "homie/bwa/spa/filter1"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"
  icon: mdi:air-filter

- platform: mqtt
  name: "Hot Tub Filter 2 Cycle Running"
  state_topic: "homie/bwa/spa/filter2"
  availability:
   - topic: "homie/bwa/$state"
     payload_available: "ready"
     payload_not_available: "lost"
  icon: mdi:air-filter

Numbers

- platform: mqtt
  unique_id : hot_tub_set_temp
  name: "Hot Tub Set Temperature"
  state_topic: "homie/bwa/spa/settemperature"
  command_topic: "homie/bwa/spa/settemperature/set"
  min: 80
  max: 104
  availability:
  - topic: "homie/bwa/$state"
    payload_available: "ready"
    payload_not_available: "lost"
  icon: mdi:thermometer

Input Select

input_select:
  hottub_mode:
    name: Hot Tub Mode
    options:
      - ready
      - rest
      - ready_in_rest
  hottub_temperature_range:
    name: Hot Tub Temperature Range
    options:
      - high
      - low

Automations to support the selectors

- alias: "Update Spa Heating Mode Selector"
  trigger:
    platform: mqtt
    topic: "homie/bwa/spa/heatingmode"
   # entity_id: input_select.thermostat_mode
  action:
    service: input_select.select_option
    target:
      entity_id: input_select.hottub_mode
    data:
      option: "{{ trigger.payload }}"

- alias: "Set Hot Tub Heating Mode"
  trigger:
    platform: state
    entity_id: input_select.hottub_mode
  action:
    service: mqtt.publish
    data:
      topic: "homie/bwa/spa/heatingmode/set"
      payload: "{{ states('input_select.hottub_mode') }}"

- alias: "Update Hot Tub Temperature Range Selector"
  trigger:
    platform: mqtt
    topic: "homie/bwa/spa/temperaturerange"
   # entity_id: input_select.thermostat_mode
  action:
    service: input_select.select_option
    target:
      entity_id: input_select.hottub_temperature_range
    data:
      option: "{{ trigger.payload }}"

- alias: "Set Hot Tub Temperature Range"
  trigger:
    platform: state
    entity_id: input_select.hottub_temperature_range
  action:
    service: mqtt.publish
    data:
      topic: "homie/bwa/spa/temperaturerange/set"
      payload: "{{ states('input_select.hottub_temperature_range') }}"

Automations to heat the tub when I have excess solar and PG&E isn’t charging an arm and a leg per kWH

- alias: "Set Hot Tub Temperature Ready"
  trigger:
    platform: time
    at: "11:00:00"
  condition:
    condition: state
    entity_id: group.family
    state: "home"
  action:
    service: mqtt.publish
    data:
      topic: "homie/bwa/spa/settemperature/set"
      payload: "99"

- alias: "Set Hot Tub Temperature Standby"
  trigger:
    platform: time
    at: "17:00:00"
  action:
    service: mqtt.publish
    data:
      topic: "homie/bwa/spa/settemperature/set"
      payload: "80"
1 Like

How can i set the username and password for the MQTT Server in the MQTT Homie Bridge

It depends on which method you used to install, local installation on the OS or the Docker installation from jshank/bwalink.

For the local installation
Directions are as follows (from README.md)

sudo curl https://github.com/ccutrer/balboa_worldwide_app/raw/master/contrib/bwa_mqtt_bridge.service -L -o /etc/systemd/system/bwa_mqtt_bridge.service

Edit bwa_mqtt_bridge.service to pass the correct URI to your MQTT server, and path to RS-485 device or hostname/IP for WiFi

ExecStart=/usr/local/bin/bwa_mqtt_bridge mqtt://user:pass@host_ip:port /dev/ttyHotTub

For the Docker installation
Modify the MQTT_URI ENV variable as follows mqtt://user:pass@host_ip:port. See this page for even more MQTT URI options

My mqtt URI contains a special character in the password. How do I pass this through the docker environment variable? I’ve tried single quotes like MQTT_URI='username:pa##word@ip:port' and 'MQTT_URI=username:pa##word@ip:port' and escaping the # but every time I start the docker container I get an error and the container stops. If I keep everything the same but remove the # then the error changes to say it couldn’t authenticate with the MQTT broker and the container stops.

error from docker container log:

/usr/local/lib/ruby/2.6.0/uri/rfc3986_parser.rb:67:in `split': bad URI(is not URI?): "mqtt://username:pa##word@ip:port" (URI::InvalidURIError)
	from /usr/local/lib/ruby/2.6.0/uri/rfc3986_parser.rb:73:in `parse'
	from /usr/local/lib/ruby/2.6.0/uri/common.rb:234:in `parse'
	from /usr/local/bundle/gems/mqtt-0.5.0/lib/mqtt/client.rb:562:in `parse_uri'
	from /usr/local/bundle/gems/mqtt-0.5.0/lib/mqtt/client.rb:152:in `initialize'
	from /usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:13:in `new'
	from /usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:13:in `initialize'
	from /usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:283:in `new'
	from /usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:283:in `<top (required)>'
	from /usr/local/bundle/bin/bwa_mqtt_bridge:23:in `load'	
	from /usr/local/bundle/bin/bwa_mqtt_bridge:23:in `<main>'

What can I do to get the environment variable passed through properly? Other docker containers I have setup would specifically call out individual environment variables such as username, password, address, and port, which are passed through in escaped text and concatenated when the container or program inside starts up.

Also, I can’t get any of the sensors or the device created through MQTT Auto Discovery. I can subscribe to the homie/# topic and I see 60+ individual topics, but MQTT doesn’t find or create a device. Auto Discovery is enabled and as far as I can tell, everything is connected and talking. What I’m reading says Auto Discovery only works if the device publishes to the homeassistant MQTT topic.

Hey @squirtbrnr, thanks for trying out the solution. I reproduced the same error by changing my password to pa##word. The variable is properly passed to the Gem but bwa_mqtt_bridge barfs on the special characters in the URI.

# /usr/local/bundle/bin/bwa_mqtt_bridge mqtt://balboa:pa##[email protected] /dev/hottub
/usr/local/lib/ruby/2.6.0/uri/rfc3986_parser.rb:67:in `split': bad URI(is not URI?): "mqtt://balboa:pa##[email protected]" (URI::InvalidURIError)
        from /usr/local/lib/ruby/2.6.0/uri/rfc3986_parser.rb:73:in `parse'

Short answer; not a Docker problem but still a problem.

Can you open a new issue for balboa_worldwide_app? I’ll see if I can fix it and issue a PR to the author, ccutrer. The last few PRs are pending so it may be a bit to get a fix. I think you’ve got the best workaround by not using special characters in the broker password (I know, not great).

Subscribe to topic homeassistant/# and confirm you are getting messages there.

mosquitto_sub -v -t homeassistant/# -h localhost -p 1883 -u mqtt_user -P "mqtt_pass"

I ran into a similar problem and discovered I hadn’t granted the balboa mqtt user access to the homeassistant/# topic in mosquitto.acl

mosquitto.acl

user balboa
topic homie/#
topic homeassistant/#

I’ve been doing some more digging. I created another MQTT user account (that was a fiasco on my end because of how I initially setup my MQTT broker 4 years ago). I was able to authenticate this docker container and the app with my broker, albeit now with a password that does not contain special characters.

As for the auto discovery, it appears your docker container is pulling version 1.2.5 of the Balboa Worldwide App. HA MQTT Auto Discovery was added in tagged version 1.3.0 (released 20 days ago). I see your pull request to enhance HA MQTT Auto Discovery, however I am now getting this error when I run the container:

What I was able to do is create a volume and link it to the container and specify the path. First I launched the container without the volume mapping so it would download and install v1.2.5 of the app. Then I shut down the container, linked a volume with the v1.3.0 /bin and /lib folders to the location inside the container (-v /volume1/docker/bwalink/balboa_worldwide_app-1.3.0:/usr/local/bundle/gems/balboa_worldwide_app-1.2.5) and started the container. This gave me 1 device and 10 entities in MQTT Auto Discovery. However, all of the entities were now showing Unavailable. I then edited the “bwa_mqtt_bridge” file with your pull request and that’s where I’m stuck now. EDIT: I see now that your PR came before v1.3.0. in otherwords, ccutrer added their own changes to implement HA MQTT Auto Discovery instead of merging your PR.

I’ll admit I’m not sure where to find this file. Would this be in my mosquitto broker config? If it is, I don’t have this file and I’m wondering if that’s why my entities are now unavailable.

Well crud, ghcr.io/jshank/bwalink:lastest isn’t latest :roll_eyes: ghcr.io/jshank/bwalink:master is!

I’ve fixed the docker-compose in the repository but you may want to update to master while I work out the tagging.

If you’ve got autodiscovery working “This gave me 1 device and 10 entities in MQTT Auto Discovery” then you’re all set on your broker config and don’t need to worry about the ACL configuration.

Shutdown the docker container, go into Home Assistant and delete the BWA link device completely. Then start the docker container up again. I cleaned up the autodiscovery paths in hass-mqtt-discovery-2 to use the topic homeassistant\<component>\bwa\*. Home Assistant may be seeing the old paths.

For clarification, are you actually seeing connectivity to the spa in the homie\# topics?

Nice work on kludging together the PR and the existing container. I’d still do a docker pull ghcr.io/jshank/bwalink:master which should contain BWA 1.3.0 and does work. Here is the docker-compose.yaml that I’m using to run bwalink with my latest PR.

version: "3"
services:
  bwalink:
    image: ghcr.io/jshank/bwalink:master
    container_name: bwalink
    restart: unless-stopped
    environment:
      MQTT_URI: mqtt://balboa:[email protected] 
      BRIDGE_IP: 10.1.12.127
      BRIDGE_PORT: 8899
    volumes: 
      - "/etc/timezone:/etc/timezone:ro" 
      - "/etc/localtime:/etc/localtime:ro"
      - "/path/to/balboa_worldwide_app/bin/:/usr/local/bundle/gems/balboa_worldwide_app-1.3.0/bin/"
      - "/path/to/balboa_worldwide_app/lib/:/usr/local/bundle/gems/balboa_worldwide_app-1.3.0/lib/"

Just pull my latest version into /path/to/balboa_worldwide_app which will give you both jshank:hass-mqtt-discovery-2 and BowenMarmot:filtercycles

ccutrer did a cleaner implementation using my pattern. I then followed on and made it even better with Improve Home Assistant MQTT Discoverability by jshank · Pull Request #44 · ccutrer/balboa_worldwide_app · GitHub.

Ok I’ll need to work through this later today. I thought I had copied over the PR contents to replace the release and that’s where I got the error (see the edit history of my previous post) and the container exiting because of the error. Something to do with the topics. Maybe I copied the wrong PR.

I fixed the tag, latest is now actually latest.

I copied your PR into my docker volume and I get this error on startup and the container stops. It’s the same error I had before, a few posts ago. Yes I know it references 1.2.5 version, but really it’s all of the v1.3.0 code with your PR. I haven’t switched to master or pulled a new latest image yet.

/usr/local/bundle/bin/bwa_mqtt_bridge:23:in `load': /usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:111: invalid multibyte char (UTF-8) (SyntaxError)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:113: invalid multibyte char (UTF-8)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:232: invalid multibyte char (UTF-8)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:235: invalid multibyte char (UTF-8)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:251: invalid multibyte char (UTF-8)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:254: invalid multibyte char (UTF-8)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:257: invalid multibyte char (UTF-8)
/usr/local/bundle/gems/balboa_worldwide_app-1.2.5/bin/bwa_mqtt_bridge:260: invalid multibyte char (UTF-8)
	from /usr/local/bundle/bin/bwa_mqtt_bridge:23:in `<main>'

I have entities under the device showing up now, but under v1.3.0 code, not the PR as noted above. One thing I noticed is the current temperature sensor does not have a unit associated with it. Therefore HA displays it as a text value sensor (bar history rather than line history). the temperature unit sensor does have Fahrenheit so it knows what units the system is in. The current temperature sensor just needs to be modified to have the correct units, and that is probably somewhere in the MQTT topics/data.

It is fixed in the PR

If you wouldn’t mind trying a fresh install using the new latest docker image, then clone my fork and map the fork using the volume mapping suggested:

volumes: 
      - "/path/to/balboa_worldwide_app/bin/:/usr/local/bundle/gems/balboa_worldwide_app-1.3.0/bin/"
      - "/path/to/balboa_worldwide_app/lib/:/usr/local/bundle/gems/balboa_worldwide_app-1.3.0/lib/"

I’m baffled why you are seeing 1.2.5 paths at all, the Dockerfile installs the Gem in /usr/local/bundle/gems/balboa_worldwide_app-1.3.0/ so mapping lib and bin under 1.2.5 shouldn’t actually work at all.

Thanks for trying this out and the frequent back and forth. It helps immensely to be able to reproduce a working environment.

did a new pull of latest, cloned your fork and did the volume mapping. Container starts up with no errors. I used to get 13 entities, now I get 24. They get created on startup of the container but take about a minute to go from Unavailable to actually having data. Yes the current temperature sensor now has units. However… it’s now saying my hot tub is currently 0F :cold_face: I hope not, because it is set at an idle 90F and the heater isn’t on…

I was doing the volume mapping before but under an old version of both the docker container image and the app. I was mapping a cloned fork of the 1.3.0 app from ccutrer to the 1.2.5 folder in your old image. that’s what we’re doing now, just mapping 1.3.1 to the 1.3.0 folder to test new code.

MQTT Auto Discovery is working. Just now the current temperature is wrong.

EDIT: I was just thinking… sometimes the display on the hot tub shows “----” for temperature if the pumps have not run for a certain amount of time, and I wonder if that’s why it is displaying 0F in the temperature sensor. I’ll go turn a pump on and see if the current temperature sensor updates.

EDIT 2: I don’t seem to have control of the hot tub, just reading back status… Tried changing the setpoint and nothing changes, Tried turning on pump 1, and nothing happened.

What kind of tub control pack do you have? I’m developing against a Clearwater Spa CL501X1. It might be easiest to move this over to an issue report. As the author of BWALink, I can help with the docker implementation but can only make suggestions and PRs to Cody for changes to ccutrer/balboa_worldwide_app.

If you wouldn’t mind pasting the output from your docker logs once you set the environment variable
LOG_LEVEL: DEBUG

created an issue report. Sensors don't update and time wrong (continued discussion from HA Forums) · Issue #1 · jshank/bwalink · GitHub

Hi, how does this compare to the new BWA integration in HA? currently I have a BWA wifi module and I just added the new integration but I can only view a few pieces and control only the temp. I cant control the swim jets on my swim spa or the seat jets. Also cant control the lights like I can in the BWA app. It appears if I take out my BWA wifi module and replace with this home made BWA serial link I will get a lot more control… Curious everyone eleses thoughts?

The Balboa Spa Client (let me know if I googled the right one) is based on pybalboa whereas BWALink is based on the slightly more active balboa_worldwide_app. Both libraries do similar things in slightly different ways.

BWALink is a just a docker container that runs balboa_worldwide_app and socat for connecting to to the tub. balboa_worldwide_app uses MQTT discovery so you’ll need to have a broker setup and Home Assistant configured for MQTT Discovery. Balboa_worldwide_app supports the bwa™ Wi-Fi Module (50350) as well as custom RS-485 connections (local RPi or even RS-485 to Ethernet adapters), pretty much anything that can extract the RS-485 data and stream it works. BWALink also works independently of Home Assistant so you get another layer of abstraction and you can run this on a different server/Pi or even network as long as both BWALink and Home Assistant can communicate with your MQTT broker.

Balboa Spa Client is published on HACS (cool) so you don’t need to run anything extra but appears to require the official wifi module. I tried it out and it won’t connect with my RS-485 adapter. I do like that it presents the spa temperature as a thermostat and the blowers as fans instead of binary switches (better for multi-speed pumps). I’ll work on a PR to add those into balboa_worldwide_app.

Give them both a try and see which one works better for you.

3 Likes

Oh, awesome, I hadnt researched enough yet and didnt realize BWALink would work with my existing BWA Wifi module, that is great. To be honest I didnt think there was any support for the BWA outside of their app until I saw it was announced in 2021.12. It sounds like BWA Link is a lot more fleshed out at the moment based on the screenshot in the OP vs what I have with the BWA official HA integration (yes that is the correct one you googled) . The official HA one is still a work in progress and the dev is working on integrating it into HA so it should eventually get full support but I will definitely try this out as well.

Hi, @mikehaguy, my scenario is spa with BWA WiFi module controlled by HA to track green energy for water heating (most significant part of total power consumption, which can be time shifted, when there is excess energy from photovoltaics). So basically I need to just controll temperature setting or Low/High and Rest/ready modes for HA automation. Can you please share screenshot with all device/entities/sensors available through current BWA integration. Is there at least temperature setting, Low/High and Rest/ready modes available ? My spa is currently off - at the service and I´m waiting for upgrade so I can´t try it now.