halo.connectmypool.com doesn’t appear to resolve in DNS. Maybe it is “coming soon” as suggested by @shanelord
@nagyOUT try 4B4A as your access code. That worked for me to allow it to be added. Most of my sensors are ‘Unknown’ but that might update in time…
I have no idea what I am doing, but I am in the process of trying to fork the existing integration, changing the UUID and adjusting to halo.
Didn’t think to try that… anyways all items are showing as unknown.
esphome proxy is connecting - I currently don’t know how to futher debug this at this instance to see what is happening.
Link to your fork? If youve already got a starting point with some halo stuff working, I’ll gladly assist there.
Nice debugging 
Yes, the initial pairing of a new user is done via BLE, then WiFi is available.
Once connected via WiFi, we should be able to MITM the connection.
I had another idea that I want to test, but unfortunately won’t get any time over the next few weeks - Set a laptop up as a WiFi AP for my phone, running packet-capture or Proxy inspection, then attempt to capture the authentication and connection that the phone uses to connect to the Halo Cloud.
I think there’s more value trying to intercept / reverse engineer the web service connection rather than the BLE connection.
2 Likes
I’m not really a fan of MITM type intergrations. I personally think either a local BLE approach as per the EQ, or if the halo makes it to connectmypool.com, then pull data via the API as theyve published the SDK.
Cheers - Btw. the astral Icon is no longer displayed.
Oh, and I found were i can see log data - using Log viewer.
Anyways. This still references the @pbutterworth 's pychlorinator api, so to continue making changes, that also need to be pulled locally to develop against.
icon - I have put in a pull request to the brands to solve this hopefully. I just duplicated and renamed the folder the pbutterworth set up. Not sure if that was the best or if there is a way to link it at all, will see if it is accepted and then that should work.
API - not sure how to do that, can I add you in somehow so you can develop also?
I’m not really a fan of MITM type intergrations.
Yes, me neither, but I just meant to MITM the web connections to do some reverse engineering so we can discover the connectivity methods used for the WiFi interface.
Then (potentially) HomeAssistant can hook straight into the Web Service for information and control.
I am not personally interested in setting up a BLE proxy for my Halo - My pool equipment is too far away from my house network.
It doesnt appear anything is exposed via the wifi/wired interface on the Halo. It would appear that it only uses it to send data to the cloud. So, it potentially only leaves you to pull data from the cloud server, just as the mobile app does. And as for reverse engineering that, it would be all in the .net files of the andriod apk file.
But, given the reference above to halo.connectmypool.com.au (Which comes up with Hal Chlorinator Communications Server), it would appear that Astral/Fluindra are possibly working on that intergration. So, if / when that happens. We could then pull data from connectmypool.com.au just as others are doing for their connect10 intergration.
Edit - a quick wireshark appears that the mobile app talks directly to that halo.connectmypool.com.au endpoint.
Hi,
I’ve been following this thread for months. I’ve got the Halo and the HaloChlor Go app. I just ordered an ESPHome for the bluetooth relay, but desperate to HA-enable this before I start on the temp and heat pump. Happy to ‘sponsor’ somebody’s time to get this going as I’m not smart enough. Any help would be appreciated. I’ve installed PButterworth’s original HACS integration, but no luck obviously, per your findings with the differences between this new Astral Halo stuff and the old ecosystem.
So, I’ve been watching with interest here.
If someone wants to have a crack at the direct BLE connection (rather than the cloud API), I think it should be reasonably doable. All the decomplied code I waded through referred to two different (but similar) protocols. It certainly looks like the halo is using the v2 protocol.
The process would look something like this:
-
Use a nRF BLE sniffer and wireshark to capture some conversation between the mobile app at the halo
-
Decrypt one packet by hand. This is to verify the decryption method.
-
Starting with pycholrinator, hack something together that connects, handshakes, reads a packet and decodes it. Achieve this by referring to the decompiled .net stuff. This is a long and painful process (well, it was for me). Best to just hack a python script that you run directly on your machine - keep HA out of it for this stage.
-
Now it’s just a matter of either publishing a new pychlorinator package, or extending pychlorinator to deal with both versions of the protocol. And, extending the integration accordingly.
Happy to do a brain-dump on anyone who is keen.
2 Likes
Happy to work with you on this. Got a nRF device i’ve previously used for zigbee sniffing 
1 Like
So I’ve looked into the cloud approach connection as per what the HaloGo mobile app does.
Here are my findings.
App connects via Websockets to wss://halo.connectmypool.com.au/
which needs a authorization header or it doesn’t connent.
You then need to send a connect message which contains your username and password. (I gained these credenitals from forcing everything on my mobile via mitmproxy).
Once connected it then streams websocket data from the halo via the cloud.
During this time, Bluetooth is not advertising on the Halo anymore, so you can’t connect to the Halo via bluetooth, and you also can’t connection to the cloud via the mobile app (says someone else is already connected).
So this would mean, any intergration done via the cloud / websocket method as per the app, would render any form of mobile app control as not possible.
The data is just base64 encoded.
So, unless every feature from the mobile app is implemented into a HA Plugin, you will loose functionality as you won’t be able to use the Mobile App.
Also, I’m not entirely sure Astral/Fluindra would be totally happy with constant websocket connections to their servers. You only need to look at other vendors, and how they responded to unauthorised devices connecting to their cloud servers (MyQ based garage door closers for example)
If a cloud approach is what you want, I’d lean towards hoping that Astral/Fluindra intergrate it into connectmypool.com.au patform as per the Connect10, that way we can poll the API at slower rates.
1 Like
Brilliant work, thank you!
You then need to send a connect message which contains your username and password. (I gained these credenitals from forcing everything on my mobile via mitmproxy).
Was there a pattern to the username and password that you could establish?
For example, are they a combination of the unit ID and serial number or something like that?
So, unless every feature from the mobile app is implemented into a HA Plugin, you will loose functionality as you won’t be able to use the Mobile App.
I presume the same constraint would apply via a Bluetooth connection as well?
But I feel that this constraint can be managed.
One option could be to rate-limit the HA Plugin by defaulting to a longer poll interval for the Web Service (or Bluetooth) query to reduce the frequency of connections.
For example, polling every hour should be more than sufficient to establish trends in pH and ORP measurements.
Likewise, setting a new value (e.g. a new ORP setpoint or timer value) would only need to be connected for that single instance.
Also, I’m not entirely sure Astral/Fluindra would be totally happy with constant websocket connections to their servers. You only need to look at other vendors, and how they responded to unauthorised devices connecting to their cloud servers (MyQ based garage door closers for example)
Agree, they probably wouldn’t be happy with high-frequency connections, however I feel this issue would be mitigated by a few points:
- The volume of people actually connecting via HA would be fairly low. The Venn diagram cross-over of people with Halo equipment + wanting Home Assistant integration is probably fairly low in the grand scheme of things.
- Implementing a rate-limited poll frequency would help reduce the load.
- This could also encourage Astral/Fluidra to accelerate development of their API once they see a demand.
1 Like
BTW @nagyOUT,
With my Viron EQ, the mobile app (BLE only) can still connect to the chlorinator while the HA integration is running.
Might be a case of first-in-first-served. The integration only connects every 60 seconds, and only briefly, so the chances of collision are low.
Was there a pattern to the username and password that you could establish?
For example, are they a combination of the unit ID and serial number or something like that?
The format of the connect json was as follows
{
"name": "HALO SERIAL NUMBER",
"payload": {
"password": "HashedPassword",
"userName": "Username as defined when you register a user"
},
"type": "connect"
}
I assume this would be part of when you “register” a user in the app. I’ve not look at how thats done in the source code at this point.
Well. I did install the HaloGo app on two mobile phones to test a few scenario’s. As soon as you connect to the Halo via bluetooth, it stops advertising, and the second mobile no longer sees it.
This may be because the Halo does bluetooth asynchronously via BLE notification subscription, rather than rely on the mobile app to poll characterisations like in the EQ.
Rate limiting would be easy to apply to API calls when Polling a cloud server. But given that this is a websocket connection, the data is streamed to you as the Halo is sending it. If you refer to my screenshot earlier, it is the same few messages as it is updating, ie, the only value changing is the CellCurrent. I’m not “asking” for specific data, im just getting given data as it changes by the halo.
To rate limit a websocket connection would be significantly more difficult to do programatically, as you may not get the data you want in a certain time frame of being connected.
In saying that, When initiating a websocket connection via postman, i’m only getting live updates. I don’t seem to get the initial “Vomit” of data which contains all the configuration details.
I need to dig further to see into my MITMPROXY captures to see what message is sent to request that.
So obviously data can be requested somehow based on that.
I have found this piece of code I could also dig into.
they might have ran out of descriptive words
As above, with 2 mobile phones as a test scenario, as soon as one mobile connects via Bluetooth, the BLE advertisements stop. It appears the Halo will then switch and focus on BLE Notifications to the connected device. Limited to 1 connection at a time.
- Agree. This isnt a Garage Door opener in comparison
- Given its websockets, its a little more difficult to implement, but not impossible.
- They already have connectmypool.com.au, which theyve got documented SDK for their API. So it’s not like they’d need to develop an entire new platform. https://www.connectmypool.com.au/downloads/Home_Automation_Integration_Guide.pdf
1 Like
It would be nice if we didn’t have to go via the ‘connectmypool’ to get access, and it could be kept local.
Regarding the username, I think this can be viewed when looking at the pair devices on Halo.
I would be happy to ditch the Halo app altogether if all the data was accessible in HA, timers can then be done with automation directly in HA.
That would only leave BLE as a solution. Which more work need to be done.
Gaining the Password is the problem. It appears to be generated as part of the Register User process in the app when it asks you for a username. But this is isn’t for local acces.
1 Like
Yeah, other than BLE, or hacking the Halo’s firmware, I don’t see any real way to use the Halo’s Local WiFi unfortunately.
That’s not really the nature of the whole Halo hardware setup.
IMHO, the most flexible option that doesn’t require any additional hardware is to establish a periodic connection to the ConnectMyPool Web Socket.
Beyond that, adding a BLE Proxy to HomeAssistant will (in the future) provide local control.
1 Like