Interesting, here is what mine looks like, note that on the latest version it polls every 20sec, so his red highlighted bit occurs every 20sec to fetch the values from the chlorinator:
Even when I was debugging mine for loss of data I was seeing, I would still get the yellow lines, and usually a error 133. That blue line you have is the BT tracker scan, the lack of green lines I think means that home assistant isn’t even requesting the connection from the proxy. Maybe PB can say for sure, I’ve only scanned through the code.
Seems I have a wifi range issue so will try and work something out there.
I am using an extension chord to place the M5stack esp32 device in an area close enough to one of my wireless APs and close enough to the pool box where the chlorinator is.
I am getting this at the moment:
[16:20:36][D][esp32_ble_tracker:246]: Starting scan...
[16:20:41][I][bluetooth_proxy:254]: [0] [C1:F4:8B:xxxxxx] Connecting v3 without cache
[16:20:41][D][esp32_ble_tracker:214]: Pausing scan to make connection...
[16:20:41][I][esp32_ble_client:064]: [0] [C1:F4:8Bxxxxxx] 0x01 Attempting BLE connection
[16:20:51][I][esp32_ble_client:081]: [0] [C1:F4:8Bxxxxxxx] Disconnecting.
[16:21:11][D][esp-idf:000]: W (196902) BT_APPL: gattc_conn_cb: if=3 st=0 id=3 rsn=0x100
[16:21:11][D][esp-idf:000]: W (196907) BT_APPL: gattc_conn_cb: if=4 st=0 id=4 rsn=0x100
[16:21:11][D][esp-idf:000]: W (196910) BT_APPL: gattc_conn_cb: if=5 st=0 id=5 rsn=0x100
[16:21:11][W][esp32_ble_client:134]: [0] [] Connection failed, status=133
Just keeps looping doing the scan and failing to connect.
@MarioAus, no worries. I think you’re right, I had lots of trouble sniffing the connection in the first place - had to be very particular about where devices were placed. With my Doit esp32 devkit proxy, I have it 16.5m away and through one pane of glass and one sheet of ply, and I’m getting about -88 dBm (-90 is about the limit), but it seems to be pretty reliable.
My integration recently stopped working - couldn’t find the device with the address…
Solutions: make sure the ESPHome proxy is fully up to date, then delete the pool integration, restart and let it discover again. Seemed to work for me.
Previously I said that the access code is not case sensitive. THAT WAS ALL LIES. The access code must be entered in upper-case! I’ll put a fix in for this, but if you are finding that the device discovers, but just doesn’t work, this might be the problem. To have another go at entering the access code, you need to delete the integration at let it discover again (requires restart).
Thank you, my instance also stopped working however I think this is more due to an unstable HA environment which I have only just started rebuilding. The integration just dropped on the latest HA Update 2023.5, it was working perfectly until I updated.
I’ll update my proxy and follow the troubleshooting process as above.
EDIT: well I’ve tried all the steps, mine didn’t come back. I even tried to roll back but the restore didn’t take and I had to go reboot the VM to get it to come back up. I guess for now I’ll have to live without the integration unless it pops up again to reconfigure.
Well if anyone was interested, I found some time on the weekend to make a new board for my ESP32 chip to replace the ESP8266 chip that was on a breadboard (And yes I used single core cat6e cable to run the pool side).
Pool Acid - HX711 - Load cell (10kg)
Pool Level - JSN-SR20-Y1 - Waterproof dual-probe ultrasonic distance sensor
Pool Temp - DS18B20 - Dallas waterproof temperature sensor
Got this kind of working off the bat with my V25 salt chlorinator and P320XT variable pump. Huge thanks for getting us this far @pbutterworth most of my pain was reflashing a SLZB-06 as a btproxy.
For a bit of a kludge around not being able to set manual speeds instead I opted for the thing I could switch and setup the following:
Manual on: High speed schedule on HA 2.5hrs
Auto on: Low speed schedule on Viron 6 hrs
Sadly when I kicked it off today the HACS addon went unavailable entirely so we need to work a bit on stability or retry loops to make this something that is successful. There is enough promise here though that I won’t bother with an outdoor enclosure for a smart plug which was my backup plan of just dropping the pool if we didn’t have enough PV.
@cycloptivity just out of curiosity (to see if i am missing something i should be doing in my pool), why the high and low schedules? Why not just let the chlorinator determine the speed it needs?
Also, the only issue I had was when HA decided to upgrade recently and broke A CRAP LOAD of things, one of which was quickly fixed by the team (thanks again)…
Alos, as a side note, I have a Shelly2pm installed in an weatherproof power point enclosure (bunnings) which does the job of being able to kill the chlorinator for me…
No worries, you’re right from a sanitising point of view it is the same.
For me, the use case is load shifting to get the most out of my solar. 6 hrs on low is ~3kWh and 2.5hrs on high is again ~3kWh. But now I can setup the low run when its cloudy and harder to find enough capacity for everything else in the house. Running the pump on low is about 350W which is still easily covered during cloudy days.
I’ve pushed a beta version in which I’ve added another select for pump speed.
No idea if it works, since I have a single speed pump here.
It’s v0.1.11 - you’ll need to show beta versions and select it explicitly.
Let me know how it goes, if it works properly I’ll change it to a proper release.
@cycloptivity, others have found that connectivity is greatly influenced by bluetooth signal path. If you get your BT device within a couple of metres, it works much better.
There is no retry built in to the chlorinator API - one day maybe. So if it can’t connect there and then, it just gives up.
Here’s how I added a bit more reliability:
service: retry.call
data:
service: select.select_option
option: "Off"
retries: 10
target:
entity_id: select.pool_mode
alias: Keep trying to turn off the pool 10 times
This is an action from an automation that switches off the pool pump (don’t really want this to fail).
It uses a nice little HACS addon called Retry https://github.com/amitfin/retry
Thanks! Pulling it down now and i’ll flick it over and see what happens tomorrow. I’ll leave debug logs on and let you know. Since I had finished setting things up it’s been super stable. I suspect just shot myself in the foot with an ESP update or something. The SLZB-06 has a pretty serious amp and external antenna so RSSI should be rock solid (though I haven’t actually checked yet :shame:)