I have done some RS485 sniffing (Aseko has internal RS485 port as well) and you can find the RS485 datagram description ( i have found somewhere) below:
It looks that this is producer´s working document, the translation reflects the state of the document in 2020.
New external display: the automate sends cca 1 x per 10 seconds data at speed 57600 bauds. The data consist in following bytes: 1th byte: 0ah 2th byte: type of automate lower 4 byte 0 - 3 bit
0 bit ,1’ - Cl probe *
1 bit ,1’ - Rx probe*
2 bit ,1’ - without probe dose*
3 bit ,1’ - without probe sanosil *
upper 4 byte 4 - 7 bit*
4 bit ,1’ aqua NET*
5 bit ,1’ salt*
6 bit ,1’ home*
7 bit ,1’ profi *
3rd byte: ph upper byte 4th byte: ph lower byte
*5th byte: Rx or Cl upper byte *
*6th byte: Rx or Cl lower byte * 7th byte: Rx or Cl upper byte
*8th byte: Rx or Cl lower byte * 9th byte: teplota upper byte 10th byte: teplota lower byte 11th byte: error_1 - 00h no error, >00h error 12-15. byte - serial number 16th byte 0xff hexa 17th byte required pH - 1 dec, place 18th byte required Cl or Rx - for Cl 1 dec. place, for Rx needs to be multiplied by 10 19th byte 0xff hexa 20th byte how many hours without filtration 21th byte hourly dosage ml/m3 per hour 22th byte states of pumps0 0.bit - pump pH, 1.bit - pump Cl 23th byte not for general use 24th byte display 25th byte not for general use 26th byte not for general use 27th byte: crc - aah xor 1th byte xor…xor 26th byte
every value sent as hexadecimal number pH, Cl,temperature - sent with 2 digits for measured values 0xff hexa - error value the communication should look like this: 0A 41 03 CF 00 00 00 00 00 C0 00 00 00 00 01 00 46 00 19 05 03 08 FF 00 02 00 40
Unfortunatelly I haven’t found a way how to overwrite any parameters.
Maybe we could sniff datagrams when changing configuration at unit itself.
I am pretty sure it sends some datagrams, so we could reverse engineering the protocol itself.
I would preffer local communication as well.
Feel free to ask for any testing if needed.
I have done sniffing for one of RS485 ports, dedicated only for External Aseko Display (External Touch Display en - Aseko Pool Technology ) connection. There is no need for consumption data for the scenarion. we could try sniffing another RS485 port, as stated in the user manual (red marked one):
Using cheap RS485->TCP converter like elfin ew 11 we could create local TCP connection quite easily and it would not affect cloud connection using inbuilt Aseko K5 TCP converter.
This is just a question of navigating to the local IP address of your Aseko unit via a web browser, then it is quite easy to see where you would change ‘pool.aseko.com’ to a different daddress.
The information above seems to be correct. I quickly threw together a Node-Red to check the information. With the position of the serial number I quickly came up with the following:
The unit always sends two packets. One of 27 bytes, which corresponds with the datagram above, and one of 120 bytes.
With the serial number I was able to find out some information in the 120 bytes packet as well. Most is double information but I also found temperature in the 120 bytes packets. This is my buffer parsers for the 27 bytes packet
@jmnemonicj Sorry have to edit my reply. Went through your posts and noticed that the image over the ports might be the controller and not the dosing unit?
However the dosing unit might also have an RS485 port. Or I’ll try your suggestion on picking up the data via the IP port into Node-Red.
It is very little info or blogs on this product online. I am very grateful that you are sharing your knowledge with us. BIG Thank you. I am getting to work ASAP.
The image I posted is internal diagram from user guide (Aseko - Files ), just for purpose we can make local serial RS485 connection for sniffing the comm protocol.
Weird that I never thought that this Aseko device would have a web UI. never crossed my mind. Pretty stupid. @tipofthesowrd Thanks for knocking on my head and bringing this option to my attention. Now it’s a completely new ballgame.
(Device is Aseko, Asin Net) First step, get the data flow into Home Assistant via Node-Red (creating MQTT sensors) to monitor the current data from the Aseko Asin sensors.
This is what I’ve done:
In the Aseko Web UI: Changed the Aseko Local IP settings from DHCP to a static IP (to keep all comms steady)
In the Aseko Web UI: Changed the Aseko setting for Serial Port “Remote Server Adds” to my HA server (with Node-Red) IP address.
In NODE-RED:
In Node-red the “TCP-IN” Node is Listening to the default port 47524 (stream of Buffer). I am getting data almost every second.
Tried to identify where the correct data is in the Buffer. First used what was posted but got the wrong data. Spent some time going through the Buffer to parse. So I am starting with the main sensors for my first version. This is what I found. (Only receiving the 120 bytes packet, haven’t seen 27… yet).
Next I’ll try to see what else I can find. Anyone that manage to identify the data in the Buffer… please share so we can create an overview table for everyone who wants to go down this route.
Prio now is to find and parse the state of water flow to the probes.
From the Aseko Asin NET model. (If streams are different.)
Finding the data for Status of “Water Flow” to the probes.
My re-search and dig for the correct part to parse.
So how is it presented. As boolean or text. In the HA integration it turns up as “OK”. And the ASCII values are O=0x4F, K = 0x4B
If Boolean Flags? Looking at the offsets 6-9, 18-19, 22-23, etc. (Multiple occurrences of 0xFF) Could 255 be true as in Active?
or… Potential Text for Status (“OK”): Offsets 23-24 (0x50 0x58)**
The hex values 0x50 and 0x58 are not directly “OK” in ASCII (0x4F 0x4B for “OK”)
Anyone else having a thought?
> EDIT 15 SEP 2024
Haven’t figured out the “Water Flow”… need more time for that…
Listening to the streams coming out from the TCP port I got errors in Node-Red so I setup a switch to filter the different packages that seem to be sent out. Confirming what has been identified in previous posts in this thread there are different sizes on these packages.
First and most common 120. (Using, is where I get my data for the common sensors inc Redox. Works ok from what I can see without a deep dive into it.)
Second there is a 14
Third a 128 sized package
Then 106 sized starts to pop up
Later a 112 sized
So would be interesting what the different ones are containing and what function.
In the link you will find a dump with several transfers via TCP. Unfortunately, I can neither recognize the serial number (110157093) nor pool values. Does anyone know how this is coded exactly? is the data processed in binary form? Thank you
Hi, adding my 2 cents, I found the following:
offset 20 might be Salinity * 10
offset 73 pool volume?
offset 74-75 startup delay in seconds? - in my case app shows 8 minutes, that’s 480 seconds, that’s 1 and 224 on 74-75
EDIT:
20 is definitely Salinity * 10
46-51 is date and time (YY MO DD HH MM SS)
the same data again on 86-91
68 Backwash every N days
69 Backwash starts at HH
70 Backwash starts at MM
71 Backwash takes N * 10 secs
I found this image of the board in the “Home” model user guide 2024 ver (owners manuals) under the page “Accessories Connection”. Not sure that all models have the same functions?
We have the smaller unit called “NET”. The cheaper slimmed down model. An option to connect other functions to the board is not shown in the manual (Except You can connect an external screen though.) Doesn’t mean that some of the connectors doesn’t exist. It doesn’t have built in WiFi, however not an issue as I prefer stable connections with Ethernet cables. Connecting via TCP stream now to capture the data streams.
When I asked technician at Aseko (I got the cell phone no. from my pool wholeseller) about possibility (or the whole protocol description) to control my pool pump through my dosing unit through the cloud app few months ago, he answered there is no such functionality implemented in the cloud api (maybe it was just the way how to avoid to send me the protocol, i don’t know).
That’s why I focused on RS485 connection after then. The cloud api has been changed completely now, we will see later when populated.
The external display can read all the necessary parameters (External Touch Display en - Aseko Pool Technology ), but can control the pool pump (on/off) and other functionalities of dosing unit as well.
Focusing on cloud api protocol by sniffing the TCP packets is easy way, but it could happen the protocol itself will be limited (as stated by the technician) for our units. Maybe that’s the reason there are two mobile apps, Pool Live and Pool remote. Pool remote app can definitely control pool pump.
Cloud api endpoint for my unit is ipool.aseko.com, but for Pool remote units it should be iremote.aseko.com (check: iPool REMOTE change address - Aseko Pool Technology ). Different endpoints = different protocols?, I don’t know.
BTW Aseko has small app to setup the Kx cloud communication module, you can download it here: Aseko - Files.
My config is as follows:
It seems K1 device is the dosing unit itself and USK-K6 is cloud api communication module. The device and module are connected locally through LAN? It seems so, but I thought it is RS485 interconnection (as checked at the screenshot checkbox) .
But of course you can use web interface to setup USR-K6 as well.
I like the idea of a locally connected solution. Do you think it would be possible to keep the cloud connectivity by having nodeRED copying the TCP stream back to Aseko.com?
This is good although at the moment I am only seeing water flow and free chlorine entries, and not the other ones I expect (particularly water temperature and pH). My model is an Asin Aqua Net with CLF probe.
never crossed my mind. Pretty stupid.
