Viron Astral Pool ChlorinatorGo integration

I’m going to install an add-on that integrates my Bluetooth barbecue thermometer just to double check the Bluetooth side of things on my RPi.

@xarmoda @Mikkaat:

@Mikkaat helped me find a bug with the version that I had pushed to github.
I’ve fixed it and pushed changes to github.

Please grab the latest, overwrite the old and try again.

1 Like

installed. i’ll let you know how i go.

We have action. Looks awesome… Will test it out over the next few days and report my findings…

Great work

image

Update: For some reason All of the entities became unavailable after posting this morning, and then when I went to Reload the integration, a message popped up and stated “to finish reloading the integration, please reboot”. I rebooted and they did not come back, so I then deleted the integration and re-added and they all came back.

Thought I might test my BT while I was at it, so i disconnected my Bleutooth Proxy ESP32. The entities became unavailable again. I rebooted HA and they did not reattach. I deleted the integration, rebooted then waited for it to discover. I think my NUC is just a little too far as it did not rediscover automatically. I then added the following to one of my existing ESPHome devices (which is a few feet away from the pool controller), and HA discovered the pool controller instantly.

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

Don’t know why the entities became unavailable this morning, but will keep an eye on it and post back.

did a reinstall with the new GIT code last night, rebooted. my HA instance has not discovered anything yet.

Update:
The entities potentially became unavailable when I updated the Mode.

I was running the chlorinator on manual (which showed perfectly in HA). I then updated the Mode to Automatic, which sent the entities into Unavailable for about 20 seconds, after which, they represented their appropriate values again. I then updated the Mode to Off, which sent the entities into Unavailable. At this point, they would not return their proper values if I updated the mode, so I had to remove the integration and then re-add it to get the values back.

I found that my Bluetooth integration (connected to the hardware on my NUC) did not pickup the Chlorinator… might be a little too far away. I added the bluetooth proxy lines onto an existing ESPHome (ESP32) device and it picked it up straight away

@xarmoda, did you get a chance to experiment with putting you HA device closer to the chlorinator? Just for the sake of eliminating possibilities.

@Mikkaat, if you get a chance, try adding the chlorinator device to your history screen to see what it looks like over time.

Here’s what mine looks like. Note there are a few bits where it became unavailable:

yes. new code. no luck. its less than 10m from the chlorinator. I was going to test the bluetooth on the RPi with some other device as I have never used it.

@xarmoda Do you see a Bluetooth Integration (in your integrations)?

or a Bluetooth Proxy integration (or even both)


If you see the Bluetooth Integration (you said you were going to use the native rPi one so I will base my comments on this), click the device link

Then click the Download Diagnostics link

and in the txt file which downloads/opens, search for the word pool to see if you have any results

@pbutterworth


White spaces are all times where it was Unavailable. If its easy enough to fix, i’d say go for it. else it’s not too much of an issue though as it always comes back by itself…

If you are hungry to practice your coding, any chance of adding a Mode function which will:

  • is a single button to cycle through the Manual/Off/Auto modes, or
  • 3 buttons to enable one of the three possible modes Manual/Off/Auto

yes. i have a reference to the custom component.

{
  "home_assistant": {
    "installation_type": "Home Assistant OS",
    "version": "2023.3.5",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.10.10",
    "docker": true,
    "arch": "aarch64",
    "timezone": "Australia/Brisbane",
    "os_name": "Linux",
    "os_version": "5.15.84-v8",
    "supervisor": "2023.03.1",
    "host_os": "Home Assistant OS 9.5",
    "docker_version": "20.10.22",
    "chassis": "embedded",
    "run_as_root": true
  },
  "custom_components": {
    "shelly": {
      "version": "1.0.2",
      "requirements": [
        "pyShelly==1.0.2",
        "paho-mqtt==1.6.1",
        "websocket-client"
      ]
    },
    "hacs": {
      "version": "1.31.0",
      "requirements": [
        "aiogithubapi>=22.10.1"
      ]
    },
    "home_connect_alt": {
      "version": "0.6.0",
      "requirements": [
        "home-connect-async==0.7.7"
      ]
    },
    "sonoff": {
      "version": "3.4.0",
      "requirements": [
        "pycryptodome>=3.6.6"
      ]
    },
    "reolink_dev": {
      "version": "0.62",
      "requirements": [
        "reolink==0.0.64",
        "aiosmtpd>=1.4.2"
      ]
    },
    "astralpool_chlorinator": {
      "version": "0.1.2",
      "requirements": [
        "bluetooth-data-tools==0.3.1",
        "bleak==0.19.5",
        "pychlorinator==0.1.3"
      ]
    }
  },

That looks exactly the same as my BT integration (built into my NUC) which can see that the device is there, but is not connecting to it…

Can you see anything like these lines in the file (your Address should be different)?

  -85,
            [
              "/org/bluez/hci0/dev_D5_7D_B7_06_22_D0",
              {
                "Address": "D5:7D:B7:06:22:D0",
                "AddressType": "random",
                "Name": "POOL01",
                "Alias": "POOL01",
                "Paired": false,
                "Trusted": false,
                "Blocked": false,
                "LegacyPairing": false,
                "RSSI": -85,
                "Connected": false,
                "UUIDs": [
                  "45000001-98b7-4e29-a03f-160174643001"

If you can see this, I would say that the rPi Bluetooth simply isnt connecting to the chlorinator. You could try what I did, and add the following lines to an existing ESP32 device or create a new BluetoothProxy device

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

i’ve looked at the whole file, can’t see any devices with a name or alias that’s obvious. i’ll search specifically for the bluetooth address of the chlorinator later this morning. apologies, i’m also testing a water tank level device i built. it’s esp32 based, although further away so not sure its worth loading up as a proxy.

I know what the issue is, and it so stupid its laughable. what an idiot I am. its the model of Astral Pool Viron Chlorinator i have. its a v25 Salt. I’ve been wrapped up building my own ESP32 based devices for controlling my water tanks. On the positive side of had a breakthrough there!

So no Bluetooth on the v25?? if that’s the case, you can always opt for a solution I had running on my previous EQ which did not have Bluetooth.

Install two Shelly devices

  • Shelly 1PM
  • Shelly 1
    Shelly 1PM will be installed behind the power point which the controller is plugged into. This will act as the power monitor to tell you whether the controller is running.
    The Shelly 1 will be installed inside the controller as a Dry Contact relay to act as the button press to toggle between modes

@xarmoda, regarding the bluetooth diagnostics:
The “Custom_components” section doesn’t really tell the full story.
You need to scroll down to the section about “scanners” and have a wade through that.

yes, the unit has bluetooth, i use it via an iPhone app currently to makes changes to the schedule, chlorination levels and lights.

pb, looked through the whole thing. nothing obvious, which i why i was interested in obtaining the control unit’s unique BT address. i’d search for that.

i see lots of the following:

“AddressType”: “public” or “random”,
“Alias”: “XX-XX-XX-XX-XX-XX” ← assuming this is the BT address.