I feel like there has to be an issue in the controller’s firmware. Something makes it not happy and it hangs.
It looks like the important functionality of it keeps working, thankfully (regen did happen when the softener wasn’t reachable via BT proxy or app).
I believe there is as well. My theory is something is causing the connection portion of the Bluetooth code to get in an invalid state and the reboot simply resets the state back to normal. I have this on my list to take a look at and I’ll look at it when I get a chance to. We’re trying to finish up this new product and app that has a deadline at the end of the month, so hopefully I can take a look at this first thing next month. You’re also correct that the valve will still function normally as it only affects the Bluetooth connectivity.
I’ll let you know when I find something of interest.
Did you ever pick up a Bluetooth adapter Tony? Curious to hear whether your if your experience is similar to mine.
I last power cycled my valve on the 25th!
Ahh, I still haven’t gotten around to it! My automation totally took my mind off of it. I’m still averaging 2 power cycles a day. Almost a week strong for you is awesome, though—you’re convincing me to buy one just for the peace of mind 
I’m not so lucky with my proxy - the unit is power cycles ~7 times in 24h on average (maybe it would have even more, but I blocked off 3-5am to prevent regeneration cycle interruption)
I just noticed one peculiar detail. The frequency of power cycling increased tremendously when I got home and my iPhone with Legacy app installed came into range with the unit.
There were only two power cycles between 00:00 and 09:30, but when I got back around 14:55 - a string of power cycles began, followed by 6 more power cycles in 2 hours
That’s right, I had to reverse engineer the password logic, since as you said, I didn’t get much of any info without it.
But as far as functionality goes, even with my old C2.x firmware I can do everything in my own code that the Android app lets me do, which isn’t surprising since that’s what I reverse engineered.
With that said, I’m not sure which features a new board/firmware would grant some of us on older firmware. I can see my flow rate, avg daily consumption, next Regen time, etc. Seems like all the basic features what I’ve had for ~8 have been enough for me at least.
Unfortunately I got pulled away for a much bigger home project and won’t get back to this for at least a couple of months, but will keep you all updated when I get back to it.
If anyone is interested, I (mostly Claude) have reversed engineered my Chandler Meter and an ESP32 that can connect to the meter, poll it, and read most of the data on the device. The data is then placed in HA as a device. I have been able to write data to the device as well. Therefore, I can update salt/trigger regens if necessary. I have not at all, polished everything, but I am running C4.40. I know that has been a sticking point for most with my hardware and software which is the reason I set out on this project to begin with. I’ll provide a few screenshots of the data I am able to receive. The ESP is running a web server along with updating HA. I can certainly create a git if there is interest. I’m new to this and know just enough to prompt Claude for the coding, but wanted to share. I’m sure there are plenty of bugs, but nothing. that can’t be polished and reworked to make whatever you’d like. Feel free to reach out if needed.
Hello all,
I was able to finish the example project that I’ve mentioned previously. Here is a small overview of the requirements:
Few notes
GitHub Repo - GitHub - ChandlerSystems/csi-ble-ha-bridge: CSI Bluetooth Device → Bridge → Home Assistant · GitHub
Hi James,
Thanks for this. At this point, both your project and Tony’s causes the valve lockout issue very often when using the BLE on an ESP32. It can range from a couple minutes to a couple hours. Using Tony’s HACs addon but with a dedicated Bluetooth adapter is much more stable. Before disabling it to try yours, it had been up for almost 2 weeks.
I appreciate your time coding this ESP project up but I’ll keep running Tony’s till the valve lockout issue is resolved.
On a side not, it is very well documented that using BLE and Wifi on ESP32’s runs into performance issue and since they share the same radio its constantly switching between them. Does anyone have a Ethernet capable ESP32 that they can test with and see if these valve lockouts as often?
Well, now I do. I pulled all the WiFi/BLE proxies and even disabled the Bluetooth built into my HA server (Yellow). The only BT device recognized by HA now is Seeed XIAO W5500 Ethernet Adapter V1.2
Unfortunately, the board locks out just as frequently as with WiFi proxies.
Any update on the firmware? I still only see C6.18 which also locks out quickly for me (ethernet ESP32 proxy). Appreciate the effort to get this going!
We have an update pending, but there’s several things we need to complete internally before we release it. We’re releasing a new C4.xx series firmware, unrelated to this, as well as a new C6.xx series firmware. Both the new C4.xx and the C6.xx updates had a lot of major code changes, so we’re not rushing it.
For the new C6.xx series firmware I essentially rewrote a lot of the Bluetooth code as well as a lot of other low level drivers. There were also a lot of other changes, like support for the new C6.xx commercial boards, but that doesn’t really pertain here. The update tries to resolve a lot of edge cases, in the Bluetooth code, that could cause connection relates issues. I did test the HA connection and it ran for over a week with no issue (I tested using the HA bridge firmware - https://github.com/ChandlerSystems/csi-ble-ha-bridge).
I don’t think I’ve mentioned this before, but please note that these valves can only handle one interactive connection at a time. What I mean by that is it does use a secondary connection during firmware updates as it uses a different protocol, but that’s it. These valves were not designed with Home Assistant in mind as we were originally going to keep that functionality for our DROP product line only. We thought we would release this as we’ve had several people ask for it, but it’s officially not supported in any way. It was always designed with the homeowner in mind for ease of setup, checking their system, etc. It wasn’t designed for long-running connections. Anyway, if it’s connected to HA and then you try connecting to it with the app, it may have undefined behavior.
Regardless, I am not sure when the next firmware will be released exactly, but it is in the testing phase as I’ve mentioned.
Thanks James! really appreciate the detailed update. The cautions all make sense to me at least. I’ll keep an eye out for the new version.
