Pool-Controller
Pool-Controller copied to clipboard
pump control over rs485
Hello, This is not an issue but just a suggestion: why not controlling the pump via rs485? you can set the rpm as a percentage and the pump will reply with the watt usage. This is the way I control my Hayward pump with a PI. Cheers, Fred
Do you have more details on this? Obviously I'd prefer to use a comm bus vs. a one-way binary relay mechanism but at the time the protocol was not very well reverse engineered and beyond my capabilities.
Sure. Initially I decoded the chlorinator protocol and them when I changed the pump I looked to find if someone already decoded the pump protocol (has I had sold my Hayward OnCommand before I got the pump).
I took the original information from this website: http://www.desert-home.com/2014/07/controlling-hayward-ecostar-pump.html as he decoded some of the pump protocol. I had some issue with the pump watt reply so I did some decoding to find the proper watt information. So there might be some differences depeding of the pump. As soon as you get the pump running it's just a matter of capturing the reply, changing the speed, taking note of what is on the display and comparing to see how is the reply is formatted. The data sent to the pump is the same format and must be sent every second at 19200 bauds. I got first a USB to RS485 adaptor and then replaced it by uart to RS485 converter exactly this one : https://www.ebay.com/itm/Stable-UART-Serial-Port-to-RS485-Converter-Function-Module-RS485-to-TTL-Module/201370097521?hash=item2ee297d771:g:16MAAOSwdzVXiFS2
This is the code I wrote (starting with an example of the rexcontrols code as this is what I am using to control the rest of the pool). In the comments you will see some information that I copied from the deserthome webstite to build the code so more details on the website.
/*******************************************************
-
*
- REXLANG example - data exchange via serial line *
-
*
- Sender station *
-
*
- (c) REX Controls, www.rexcontrols.com *
-
*
*******************************************************/
// 2017-04-30
#define COM_DEVICE_FNAME 63 // serial device is defined by the fname parameter of the REXLANG block (e.g. /dev/ttyS0 in Linux or COM1: in Windows)
#define COM_BAUDRATE 19200 //baudrate, e.g. 9600, 19200, 57600, 115200
#define COM_PARITY_NONE 0 //no parity #define COM_PARITY_ODD 1 //odd parity #define COM_PARITY_EVEN 2 //even parity
#define BUFFER_SIZE 50 //maximum number of bytes to send
//assigning inputs to variables, these variables are READ-ONLY long input(0) signal0; //vitesse 1 long input(1) signal1; //vitesse 2 long input(2) signal2; //vitesse 3 long input(3) signal3; //vitesse 4 long output(0) signal4; //percentage long output(1) signal5; //Error flag long output(2) signal6; //watts long output(3) signal7; //watts
//assigning variables to outputs, these variables are WRITE-ONLY long output(15) handle; //handle of the serial device
//declaration of variables long hCom; //communication handle long buffer[BUFFER_SIZE]; //buffer for incoming data long dataCnt; //number of bytes sent long convData[2]; //array for data conversions
/* Off 0x10, 0x02, 0x0C, 0x01, 0x00, 0x00, 0x00, 0x1F, 0x10, 0x03
100% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x64, 0x00, 0x83, 0x10, 0x03
45% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x2D, 0x00, 0x4C, 0x10, 0x03
/ / Initialization of the REXLANG algorithm */ // the init procedure is executed once when the REXLANG function block initializes long init(void) { hCom = -1; return 0; }
/* The body of the REXLANG algorithm */ // the main procedure is executed once in each sampling period long main(void) { if (hCom<0) { hCom = Open(COM_DEVICE_FNAME,"/dev/ttyUSB1",COM_BAUDRATE,COM_PARITY_NONE); //opening serial device } else { buffer[0] = 0x10; buffer[1] = 0x02; buffer[2] = 0x0C; buffer[3] = 0x01; buffer[3] = 0x00;
if (signal1 == 1)
{
buffer[4] = 0x63; // 100%
}
else{
buffer[4] = 0x00;
}
buffer[6] = 0x00;
buffer[7] = buffer[0] + buffer[1] + buffer[2] + buffer[3] + buffer[4]; // 0x78; // Checksum sum of bytes %256
buffer[8] = 0x10;
buffer[9] = 0x03;
//now all the data can be sent
dataCnt = Send(hCom,buffer,8); //send data, number of bytes = 21
buffer[4]=0x00;
buffer[5]=0xff;
/*
It starts off with the begin packet bytes of 0x01, 0x02. Then 0x00 , 0x0c which would mean, from device 12 to device 0. Strange that it would reply to device zero when device 1 sent the command, but ?? Byte 6 of the packet is the speed, in the packet above it is byte 6 counting from the first byte being index [0]. Bytes 7 & 8 are the power and they threw me for a loop. They’re in nibble form of the actual speed if you read it out loud. For example:
0x10 0x02 0x00 0x0C 0x00 0x00 0x62 0x17 0x81 0x01 0x18 0x10 0x03
Byte 6 is 0x62, for 98 percent and bytes 7 & 8 are 0x17 0x81, this reads as one, seven, eight, one or a power reading of 1,781 watts. Is that weird or what? I tried big endian, little endian, hex, some obscure rotations I’ve seen in the past and other stuff until I just happened to read it out loud and then look at the motor. Shocked is probably the correct term for my reaction. */
dataCnt = Recv(hCom,buffer,BUFFER_SIZE); //receive data, max number of bytes = BUFFER_SIZE
signal4=buffer[7];
signal6=buffer[8];
signal7=buffer[9];
}
//publishing the serial communication handle through output signal (for debugging)
handle = hCom;
return 0;
}
/* Closing the REXLANG algorithm */ //the exit procedure is executed once when the task is correctly terminated // (system shutdown, downloading new control algorithm, etc.) long exit(void) { if(hCom>=0) Close(hCom); return 0; }
Would you be able to helpme with that ? I'm not able to receive any proper signal from the pump.. I only see a bunch of 0x00 every seconds from the pump when I set the baud rate at 19200... What I tried was to attach the setup as follow :
Pump RS485 port----Rs485to-TTL (thats a module called SH-U12)--------USB-to-TTL (module name CP2102)-----PC running Termite Com5/19200/8N1
I also get the exact same results if I skip the RS485-to-TTL as follow :
Pump RS485 port----USB-to-TTL (module name CP2102)-----PC running Termite Com5/19200/8N1
So I'm receiving something, I can see the RX led flashing every seconds on the usb-to-TTL but it's just not what is expected..
If I lower the baud rate, (to 1200) I see a repeating signal but nothing as described on Desert-Home web site :
01 01 00 00 6b 0d 0a 01 40 00 00 00 00 00 00 00 ....k...@.......
10 00 00 00 00 00 71 0d 0a ......q..
01 01 00 00 6b 0d 0a 01 40 00 00 00 00 00 00 00 ....k...@.......
10 00 00 00 00 00 71 0d 0a ......q..
01 01 00 00 6b 0d 0a 01 40 00 00 00 00 00 00 00 ....k...@.......
10 00 00 00 00 00 71 0d 0a ......q..
I've attached RS485 A,B and ground in parallel to the cables coming from the interface to the board next to AC current input on the pump. The pump being a SP2603VSP.
Only the dipswitch 1 is on. (I tried putting other ones also on without success :(
I am not clear how your hardware is hooked up. Is the pump RS485 connected ONLY to one of your devices (sh-u12 or cp2102)?
In that case, the pump will output nothing until you send it a command (set the rpm). I am not sure how to do that from a PC as I have no idea how to control the serial port outputs from the PC...it would have to be a hex command in the correct format (start bytes, rpm, xsum, end bytes). Only then would you get a response from the pump.
Do you have an arduino or photon to send a command to the pump through your SH-U12 (not quite positive but I think that device may not work for a photon because the voltage level on photon side needs to be 3.3v, I used https://www.amazon.com/DROK-Adapter-Module-Converter-Indicator/dp/B075V2NMV8/ref=pd_sim_147_1?_encoding=UTF8&pd_rd_i=B075V2NMV8&pd_rd_r=6355f339-dde0-11e8-8d12-c13cc35a75fb&pd_rd_w=820wy&pd_rd_wg=i8fXw&pf_rd_i=desktop-dp-sims&pf_rd_m=ATVPDKIKX0DER&pf_rd_p=18bb0b78-4200-49b9-ac91-f141d61a1780&pf_rd_r=54KYKE9S4MVEK2RC6DWM&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&psc=1&refRID=54KYKE9S4MVEK2RC6DWM )
On Wed, Oct 31, 2018 at 4:56 PM Mrdindon [email protected] wrote:
Would you be able to helpme with that ? I'm not able to receive any proper signal from the pump.. I only see a bunch of 0x00 every seconds from the pump when I set the baud rate at 19200... What I tried was to attach the setup as follow :
Pump RS485 port----Rs485to-TTL (thats a module called SH-U12)--------USB-to-TTL (module name CP2102)-----PC running Termite Com5/19200/8N1
I also get the exact same results if I skip the RS485-to-TTL as follow :
Pump RS485 port----USB-to-TTL (module name CP2102)-----PC running Termite Com5/19200/8N1
So I'm receiving something, I can see the RX led flashing every seconds on the usb-to-TTL but it's just not what is expected..
If I lower the baud rate, (to 1200) I see a repeating signal but nothing as described on Desert-Home web site : 01 01 00 00 6b 0d 0a 01 40 00 00 00 00 00 00 00 ....k...@....... 10 00 00 00 00 00 71 0d 0a ......q.. 01 01 00 00 6b 0d 0a 01 40 00 00 00 00 00 00 00 ....k...@....... 10 00 00 00 00 00 71 0d 0a ......q.. 01 01 00 00 6b 0d 0a 01 40 00 00 00 00 00 00 00 ....k...@....... 10 00 00 00 00 00 71 0d 0a ......q..
I've attached RS485 A,B and ground in parallel to the cables coming from the interface to the board next to AC current input on the pump. The pump being a SP2603VSP.
Only the dipswitch 1 is on. (I tried putting other ones also on without success :(
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Here-Be-Dragons/Pool-Controller/issues/4#issuecomment-434886797, or mute the thread https://github.com/notifications/unsubscribe-auth/AqFbihaFgV5PSCHwxmzw5X2WDzp8JZH8ks5uqjixgaJpZM4Tzpez .
Thanks for your reply. I was able to "talk" with the drive and make it run at a specific rpm but I had to disable the pump display by putting the SW1 to off. Other way, when I send the signal to the pump (I use Realterm https://realterm.sourceforge.io/), the display interface was overriding my signal. For some reason, Hayward used a different logic to talk with the drive then the one described here : http://www.desert-home.com/2014/07/controlling-hayward-ecostar-pump.html. I was able to sniff and reproduce a few signals already but I would like to understand how it works to avoid sniffing all the way to 3450rpm ! Also, understanding the drive reply would be nice !!
So far here is what I have :
Set pump at 0rpm: 0x01 0x01 0x00 0x00 0x6b 0x0d 0x0a 0x01 0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x13 0x00 0x00 0x00 0x00 0x00 0x0a 0x0d 0x0a
Set pump at 600rpm: 0x01 0x01 0x58 0x02 0xc1 0x0d 0x0a 0x01 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x15 0x00 0x01 0x00 0x00 0xed 0x0d 0x0a 0x
Set pump at 625rpm: 0x01 0x01 0x71 0x02 0xd2 0x0d 0x0a 0x01 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x15 0x00 0x00 0x00 0x75 0x02 0x85 0x0d 0x0a
Set pump at 650rpm: 0x01 0x01 0x8a 0x02 0x51 0x0d 0x0a 0x01 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x15 0x00 0x00 0x00 0x8a 0x02 0x52 0x0d 0x0a
Set pump at 675rpm: 0x01 0x01 0xa3 0x02 0x42 0x0d 0x0a 0x01 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x15 0x00 0x00 0x00 0xa2 0x02 0x54 0x0d 0x0a
Set pump at 700rpm: 0x01 0x01 0xbc 0x02 0xd6 0x0d 0x0a 0x01 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x15 0x00 0x00 0x00 0xbf 0x02 0xea 0x0d 0x0a
Set pump at 725rpm: 0x01 0x01 0xd5 0x02 0x9e 0x0d 0x0a 0x01 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Response from the drive : 0x15 0x00 0x00 0x00 0xd7 0x02 0xb7 0x0d 0x0a
In the meantime, I've done a working solution based on the relay support of the pump using a Sonoff 4chPro module that allows me to control it over wifi and with a rf433mhz remote (With espurna / mqtt). I'm still documenting and will share that info soon; It's super easy to implement. But I would definitely prefer the RS485 way of controlling it since I think my water heater also have that port available....
It sounds like you are doing the right thing in trying to find out what exactly is going on. I would suggest the following...I am no expert on any of this but here are my observations:
-
Are you sure your pump commands are that long...can they end after the 0x0d 0x0a markers?...that would make the commands and pump response consistent.
-
You would need to run a couple more test cases (high rpm) to make sure about this next one...I believe that in the commands you are sending the pump RPM in byte 3 & byte 4. RPM = (256 * byte 4) + byte 3.
-
Byte 5 of the pump command is unknown but I would suspect some kind of xsum...not obvious though. You would probably HAVE to figure this out in order to send valid pump commands at any random RPM.
-
I suspect Byte 5 of the pump response is simply the RPM that the pump was commanded to operate. In my case, it doesn't always match the RPM sent but usually settles down right around the number it is supposed to. Not sure what was going on in your 600rpm case though...doesn't seem to match my expectations.
-
finally, does your pump display watts? If so, you need to take the watts reading from the pump while doing this to see if the other bytes of the pump response include some kind of reference to that.
let me know if any of this turns out.
On Thu, Nov 1, 2018 at 8:51 AM Mrdindon [email protected] wrote:
In the meantime, I've done a working solution based on the relay support of the pump using a Sonoff 4chPro module that allows me to control it over wifi and with a rf433mhz remote (With espurna / mqtt). I'm still documenting and will share that info soon; It's super easy to implement. But I would definitely prefer the RS485 way of controlling it since I think my water heater also have that port available....
[image: sonoff4ch] https://user-images.githubusercontent.com/5002201/47861865-2e04d100-ddca-11e8-871f-a95340bf0b14.jpg
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Here-Be-Dragons/Pool-Controller/issues/4#issuecomment-435080636, or mute the thread https://github.com/notifications/unsubscribe-auth/AqFbimbsuWQ0-XrLxTIRkyEnwg0pe1qFks5uqxhvgaJpZM4Tzpez .
Sorry...
- I suspect Byte 5 & 6 of the pump response is simply the RPM.....
This means that....
- there is only one byte left in the response that seems to have a meaning....possible a checksum again....doesn't seem like enough info for watts
On Thu, Nov 1, 2018 at 9:51 AM Jonpcar C [email protected] wrote:
It sounds like you are doing the right thing in trying to find out what exactly is going on. I would suggest the following...I am no expert on any of this but here are my observations:
Are you sure your pump commands are that long...can they end after the 0x0d 0x0a markers?...that would make the commands and pump response consistent.
You would need to run a couple more test cases (high rpm) to make sure about this next one...I believe that in the commands you are sending the pump RPM in byte 3 & byte 4. RPM = (256 * byte 4) + byte 3.
Byte 5 of the pump command is unknown but I would suspect some kind of xsum...not obvious though. You would probably HAVE to figure this out in order to send valid pump commands at any random RPM.
I suspect Byte 5 of the pump response is simply the RPM that the pump was commanded to operate. In my case, it doesn't always match the RPM sent but usually settles down right around the number it is supposed to. Not sure what was going on in your 600rpm case though...doesn't seem to match my expectations.
finally, does your pump display watts? If so, you need to take the watts reading from the pump while doing this to see if the other bytes of the pump response include some kind of reference to that.
let me know if any of this turns out.
On Thu, Nov 1, 2018 at 8:51 AM Mrdindon [email protected] wrote:
In the meantime, I've done a working solution based on the relay support of the pump using a Sonoff 4chPro module that allows me to control it over wifi and with a rf433mhz remote (With espurna / mqtt). I'm still documenting and will share that info soon; It's super easy to implement. But I would definitely prefer the RS485 way of controlling it since I think my water heater also have that port available....
[image: sonoff4ch] https://user-images.githubusercontent.com/5002201/47861865-2e04d100-ddca-11e8-871f-a95340bf0b14.jpg
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Here-Be-Dragons/Pool-Controller/issues/4#issuecomment-435080636, or mute the thread https://github.com/notifications/unsubscribe-auth/AqFbimbsuWQ0-XrLxTIRkyEnwg0pe1qFks5uqxhvgaJpZM4Tzpez .
Yup, I'll have to look for this... Do you know how far you can run that kind of pump dry ? It's now inside my house so that I can play with it.... I'll try just to power the interface module with 12v without connecting the pump to the 230v circuit just to get the interface commands without the drive response...
Just completed the sniffing.. in case someone need it. I tested it and it work :
OFF | 01 01 00 00 6B 0D 0A 600 | 01 01 58 22 21 0D 0A 625 | 01 01 71 22 32 0D 0A 650 | 01 01 8A 22 B1 0D 0A 675 | 01 01 A3 22 A2 0D 0A 700 | 01 01 BC 22 36 0D 0A 725 | 01 01 D5 22 7E 0D 0A 750 | 01 01 EE 22 10 0D 0A 775 | 01 01 07 03 09 0D 0A 800 | 01 01 20 03 CC 0D 0A 825 | 01 01 39 03 26 0D 0A 850 | 01 01 52 23 A4 0D 0A 875 | 01 01 6B 23 E0 0D 0A 900 | 01 01 84 23 60 0D 0A 925 | 01 01 9D 03 6A 0D 0A 950 | 01 01 B6 03 53 0D 0A 975 | 01 01 CF 03 4C 0D 0A 1000 | 01 01 E8 03 89 0D 0A 1025 | 01 01 01 04 62 0D 0A 1050 | 01 01 1A 04 A2 0D 0A 1075 | 01 01 33 04 B1 0D 0A 1100 | 01 01 4C 04 D0 0D 0A 1125 | 01 01 65 04 C3 0D 0A 1150 | 01 01 7E 04 03 0D 0A 1175 | 01 01 97 04 FD 0D 0A 1200 | 01 01 B0 04 38 0D 0A 1225 | 01 01 C9 04 27 0D 0A 1250 | 01 01 E2 04 1E 0D 0A 1275 | 01 01 FB 04 F4 0D 0A 1300 | 01 01 14 05 73 0D 0A 1325 | 01 01 2D 05 37 0D 0A 1350 | 01 01 46 05 55 0D 0A 1375 | 01 01 5F 05 BF 0D 0A 1400 | 01 01 78 05 7A 0D 0A 1425 | 01 01 91 05 84 0D 0A 1450 | 01 01 AA 05 EA 0D 0A 1475 | 01 01 C3 05 A2 0D 0A 1500 | 01 01 DC 05 36 0D 0A 1525 | 01 01 F5 05 25 0D 0D 1550 | 01 01 0E 06 AF 0D 0A 1575 | 01 01 27 06 BC 0D 0A 1600 | 01 01 40 06 22 0D 0A 1625 | 01 01 59 06 C8 0D 0A 1650 | 01 01 72 06 F1 0D 0A 1675 | 01 01 8B 06 58 0D 0A 1700 | 01 01 A4 06 35 0D 0A 1725 | 01 01 BD 06 DF 0D 0A 1750 | 01 01 D6 06 BD 0D 0A 1775 | 01 01 EF 06 F9 0D 0A 1800 | 01 01 08 07 D6 0D 0A 1825 | 01 01 21 07 C5 0D 0A 1850 | 01 01 3A 07 05 0D 0A 1875 | 01 01 53 07 4D 0D 0A 1900 | 01 01 6C 07 77 0D 0A 1925 | 01 01 85 07 89 0D 0A 1950 | 01 01 9E 07 49 0D 0A 1975 | 01 01 B7 07 5A 0D 0A 2000 | 01 01 D0 07 C4 0D 0A 2025 | 01 01 E9 07 80 0D 0A 2050 | 01 01 02 08 79 0D 0A 2075 | 01 01 1B 08 93 0D 0A 2100 | 01 01 34 08 FE 0D 0A 2125 | 01 01 4D 08 E1 0D 0A 2150 | 01 01 66 08 D8 0D 0A 2175 | 01 01 7F 08 32 0D 0A 2200 | 01 01 98 08 1A 0D 0A 2225 | 01 01 B1 08 09 0D 0A 2250 | 01 01 CA 08 3C 0D 0A 2275 | 01 01 E3 08 2F 0D 0A 2300 | 01 01 FC 08 BB 0D 0A 2325 | 01 01 15 09 42 0D 0A 2350 | 01 01 2E 09 2C 0D 0A 2375 | 01 01 47 09 64 0D 0A 2400 | 01 01 60 09 A1 0D 0A 2425 | 01 01 79 09 4B 0D 0A 2450 | 01 01 92 09 9F 0D 0A 2475 | 01 01 AB 09 DB 0D 0A 2500 | 01 01 C4 09 ED 0D 0A 2525 | 01 01 DD 09 07 0D 0A 2550 | 01 01 F6 09 3E 0D 0A 2575 | 01 01 0F 0A 9E 0D 0A 2600 | 01 01 28 0A 5B 0D 0A 2625 | 01 01 41 0A 13 0D 0A 2650 | 01 01 5A 0A D3 0D 0A 2675 | 01 01 73 0A C0 0D 0A 2700 | 01 01 8C 0A 17 0D 0A 2725 | 01 01 A5 0A 04 0D 0A 2750 | 01 01 BE 0A C4 0D 0A 2775 | 01 01 D7 0A 8C 0D 0A 2800 | 01 01 F0 0A 49 0D 0A 2825 | 01 01 09 0B E7 0D 0A 2850 | 01 01 22 0B DE 0D 0A 2875 | 01 01 3B 0B 34 0D 0A 2900 | 01 01 54 0B 02 0D 0A 2925 | 01 01 6D 0B 46 0D 0A 2950 | 01 01 86 0B 92 0D 0A 2975 | 01 01 9F 0B 78 0D 0A 3000 | 01 01 B8 0B BD 0D 0A 3025 | 01 01 D1 0B F5 0D 0A 3050 | 01 01 EA 0B 9B 0D 0A 3075 | 01 01 03 0C 70 0D 0A 3100 | 01 01 1C 0C E4 0D 0A 3125 | 01 01 35 0C F7 0D 0A 3150 | 01 01 4E 0C C2 0D 0A 3175 | 01 01 67 0C D1 0D 0A 3200 | 01 01 80 0C F9 0D 0A 3225 | 01 01 99 0C 13 0D 0A 3250 | 01 01 B2 0C 2A 0D 0A 3275 | 01 01 CB 0C 35 0D 0A 3300 | 01 01 E4 0C 58 0D 0A 3325 | 01 01 FD 0C B2 0D 0A 3350 | 01 01 16 0D 0D 61 0D 0A 3375 | 01 01 2F 0D 0D 25 0D 0A 3400 | 01 01 48 0D 0D BB 0D 0A 3425 | 01 01 61 0D 0D A8 0D 0A 3450 | 01 01 7A 0D 0D 68 0D 0A
Looks like the rpm IS in bytes 3,2 ... RPM=Byte4*256+Byte3
But looks like some of the RPMs between 600-900 have a problem with bit 5 of byte 4. Seems like those should all be 02 & 03 rather than 22 & 23. Might want to double check those. Could be that it ignores the upper nibble of byte4 entirely but I wouldn’t think so.
Still can’t make any sense of byte5. It would be nice to be able to calculate that byte rather than have a table.
In 3350+ I’ve seen some protocols where they send a byte twice (0D in those cases) so that the hardware knows that is is NOT the beginning of the end sequence (0D 0A for all cases).
@farcouet and @Mrdindon
Could you post the model of your pump? I have a Hayward MaxFlow VS 500 (SP23520VSP) and am trying to control my pump over RS-485. Your post are very helpful but it sounds like Hayward has a few different protocols so I am trying to determine which one best matches my pump. Knowing the model of what you are using would be helpful.
It should be the same protocol as pretty much all there pumps uses the same rs-485 controller.. My pump is a SP2603VSP. Keep in mind that you have to send the signal every seconds or so... In my case it ended up being unmanageable and I fall back on the relay mode with the sonoff.. That way, I can control the pump both from the relay swiches, from rf433 and finally over wifi from my domotic setup...
What prompted me to ask this was the differences between the data you posted and the info at this site. The Hayward EcoStar (SP3400VSP) looks like it is different and tt also returns the wattage in the response packet. I have the logic coded for the EcoStar since I came across that first and should be able to test it out in the next few days once the rest of the equipment comes in.
Following. I have a VS500 also, and am intrigued by this. I have a great deal of RS-485 experience (I deal with Modbus/RTU) quite often. Was there a finalization on information regarding the control protocols? How can I assist?
It does seem to ignore the upper nibble of byte4...it certainly does in the response where it seems to be a binary status for some features (e.g. priming yes/no ; stopped yes/no). I have a VS700 which seems slightly different in response but accepts the speeds as sniffed above. I'm very frustrated at their checksum byte using some layer of obscurity so the lookup table is necessary...I compared it against many forms of crc but nothing matches. The return message from my unit sends the current speed which you can see transitioning to whatever you set it to. I don't know if it's just the 700 but sending a message every second to maintain the speed was not necessary. Return format for VS700 is:
<from=01> <to=40> <01 when running, 10 when stopped> <10 when running, 01 when stopped, 11 when starting> <speed lsb> <status? then speed msb> <checksum> <0d> <0a>
.
In the meantime, I've done a working solution based on the relay support of the pump using a Sonoff 4chPro module that allows me to control it over wifi and with a rf433mhz remote (With espurna / mqtt). I'm still documenting and will share that info soon; It's super easy to implement. But I would definitely prefer the RS485 way of controlling it since I think my water heater also have that port available....
Any chance you could share your work on this? I'd love to smart up my Hayward TriStar VS to a Sonoff!
Any chance you could share your work on this? I'd love to smart up my Hayward TriStar VS to a Sonoff!
check if that helps you: http://www.mrdindon.com
Hello All Good Morning
I prepare some automation controllers on Arduino Board. so with the help of RS485 port, I am able to controller single Hayward VSP below is the packet to control Hayward VSP @ 100% speed and it working perfectly ex. [ 0x10, 0x02, 0x0C, 0x01, 0x00, 0x64, 0x00, 0x83, 0x10, 0x03]
[START OF PACKET BYTES]: 2-bytes fix bytes which indicates Start of Packet [0x10 0x02] [DESTINATION ADD] : 1- Byte Destination Address [0x0C] [SOURCE ADD] : 1- Byte Source Address [0x01] [FIX BYTE] : 1- Byte fix byte [0x00] [DATA] : 1- byte Data - RPM Data in Parentage 0% - 100% [0x64] [CHECKSUM] : 2 Byte Checksum [0x00 0x83] [END OF PACKET BYTES]: 2-bytes fix bytes which indicates END of Packet [0x10 0x03]
Now Problem is I want to control 3 Hayward Pump with the same Arduino Board, but as per RS485 protocol, all Hayward VSL should have different Slave addresses.
and I seen in Hayward VSP terminal side, it has the same DIP switch - and as per my study this DIP switch is used for setting the different Slave addresses (please check doc in the attachment )
so when I keep all DIP switch ALL OFF or only 2nd DIP switch ON -- so I am able to control VSP with 0x0C (12) slave address
But I was not able to find other slave addresses with respect to the DIP switch, anyone could we help me on how to identify Hayward's VSP address and my understanding is correct or NOT ?
Hello All Good Morning
I prepare some automation controllers on Arduino Board. so with the help of RS485 port, I am able to controller single Hayward VSP below is the packet to control Hayward VSP @ 100% speed and it working perfectly ex. [ 0x10, 0x02, 0x0C, 0x01, 0x00, 0x64, 0x00, 0x83, 0x10, 0x03]
[START OF PACKET BYTES]: 2-bytes fix bytes which indicates Start of Packet [0x10 0x02] [DESTINATION ADD] : 1- Byte Destination Address [0x0C] [SOURCE ADD] : 1- Byte Source Address [0x01] [FIX BYTE] : 1- Byte fix byte [0x00] [DATA] : 1- byte Data - RPM Data in Parentage 0% - 100% [0x64] [CHECKSUM] : 2 Byte Checksum [0x00 0x83] [END OF PACKET BYTES]: 2-bytes fix bytes which indicates END of Packet [0x10 0x03]
Now Problem is I want to control 3 Hayward Pump with the same Arduino Board, but as per RS485 protocol, all Hayward VSL should have different Slave addresses.
and I seen in Hayward VSP terminal side, it has the same DIP switch - and as per my study this DIP switch is used for setting the different Slave addresses (please check doc in the attachment )
so when I keep all DIP switch ALL OFF or only 2nd DIP switch ON -- so I am able to control VSP with 0x0C (12) slave address
But I was not able to find other slave addresses with respect to the DIP switch, anyone could we help me on how to identify Hayward's VSP address and my understanding is correct or NOT ?
Just figured out how to address more than one pump. Piggybacking off desert home - The slave address is actually kind of two bytes, desert home never saw 0x00 change because he only had one pump. Example - if the second pump has the DIP Switch set to AUX 2, then the first 0x00 becomes 0x02. In other words [FIX BYTE] is [ADDRESS]. Hope this helps. filter pump - 0x10, 0x02, 0x0C, 0x01, 0x00, 0x2D, 0x00, 0x4C, 0x10, 0x03 AUX2 pump - 0x10, 0x02, 0x0C, 0x01, 0x02, 0x2D, 0x00, 0x4E, 0x10, 0x03
Using all information available online (nodejs-poolControler were a huge help). I have finally were able to document properly Tristar (Not sure about ecostar) VSP.
Here is a an addition to @zafarpatel7 doc. In fact 3rd byte is action and byte 5 is a pump address.
Pump Addresses that I have verified: 0x00: all dip switches off (Pool Filter) 0x02: 2nd dip switch on (Aux 1))
Protocol (example for the 0x00 pump address): on 45% [0x10, 0x02, 0x0C, 0x01, 0x00, 0x2D, 0x00, 0x4C, 0x10, 0x03] on 100% [0x10, 0x02, 0x0C, 0x01, 0x0C, 0x64, 0x00, 0x83, 0x10, 0x03] off [0x10, 0x02, 0x0C, 0x01, 0x00, 0x00, 0x00, 0x1F, 0x10, 0x03]
[START OF PACKET BYTES]: 2 byte. fix bytes which indicates Start of Packet [0x10 0x02] [ACTION]: 1 byte. action 12/0x0C -- set RPM, action 1/0x01 -- set remote control [SOURCE ADD]: 1 byte. Byte Source Address [0x01] [DESTINATION ADD]: 1 byte. Byte Destination Address [0x0C] [DATA] : 1- byte Data - RPM Data in Parentage 0% - 100% [0x64] [CHECKSUM] : 2 Byte Checksum [0x00 0x83] [END OF PACKET BYTES]: 2-bytes fix bytes which indicates END of Packet [0x10 0x03]
My only issue is that my pump is not replying on my commands for the first ~10minutes after its been power cycled. Is somebody aware of this issue?
Is this in addition to the prime cycle (3 min on my pump)?
I'm very glad I came across this, this will be awesome to play with and get set up.
One Suggestion: This might be helpful - https://www.reddit.com/r/pools/comments/ganhbv/pool_pump_timer_diy_plans_store_options_240v_pumps/
One question: I'm looking to do the valve actuator control (24 Vac) - I have two 3 way valves (jandy type), one that varies the skimmer/vacuum (permanent install), and one that varies the floor drains (for recirc). E.g., https://www.amazon.com/NSI-TPE24VA-Actuator-Compatible-Equipment/dp/B08ZV6GHZQ/ref=mp_s_a_1_3?keywords=pool+valve+actuator&qid=1672869034&sr=8-3
Would this, or another, program/equipment work for this? My struggle is finding control for 24 Vac... without re-inventing the wheel.
Would this, or another, program/equipment work for this? My struggle is finding control for 24 Vac... without re-inventing the wheel.
I believe doorbell transformers are 24vac!
Haha, yes, confirmed that. I guess I was overthinking it a bit. I can just use a smart switch to send the 120 Vac to the doorbell xfmr – for full open/close; I was considering/wanting to have full control of the valve.
Would this, or another, program/equipment work for this? My struggle is finding control for 24 Vac... without re-inventing the wheel.
I believe doorbell transformers are 24vac!
Looks like the rpm IS in bytes 3,2 ... RPM=Byte4*256+Byte3
But looks like some of the RPMs between 600-900 have a problem with bit 5 of byte 4. Seems like those should all be 02 & 03 rather than 22 & 23. Might want to double check those. Could be that it ignores the upper nibble of byte4 entirely but I wouldn’t think so.
Still can’t make any sense of byte5. It would be nice to be able to calculate that byte rather than have a table.
In 3350+ I’ve seen some protocols where they send a byte twice (0D in those cases) so that the hardware knows that is is NOT the beginning of the end sequence (0D 0A for all cases).
Well, I can confirm the pump ignores that bit. 58 22 is little endian INT 16. Little Endian, so flip the bits to have 22 58, ignore the 2 and you get hex 258 which is 600 in Decimal. I can confirm it ignores it, because I just bought a Super Pump VS 700 and sniffed the packets for the same value, which looks like the protocol is updated and actually uses the 0 values. However I can send the 58 22 from my PC over RS485 and the pump responds the same.
What does seem significant is the orignal sniffed packets compared to my updated sniffed packets. The only difference is the 2 changes to a 0...but the checksum only changes 1 digit. The 2nd digit remains the same across all the checksums.
Original Sniffed packets 01 01 58 22 21 0D 0A 01 01 71 22 32 0D 0A 01 01 8A 22 B1 0D 0A 01 01 A3 22 A2 0D 0A 01 01 BC 22 36 0D 0A 01 01 D5 22 7E 0D 0A 01 01 EE 22 10 0D 0A
My Sniffed packets 01 01 58 02 C1 0D 0A 01 01 71 02 D2 0D 0A 01 01 8A 02 51 0D 0A 01 01 A3 02 42 0D 0A 01 01 BC 02 D6 0D 0A 01 01 D5 02 9E 0D 0A 01 01 EE 02 F0 0D 0A
I'm in process of refining and adding features to my RPi pool controller. I already have it communicating with HA and opening and closing valves (24v valve actuators using a relay hat) and have been trying to decide whether or not to just wire the motor speeds to a couple of relays or to go the RS485 route. The relays would be easier, but what's the fun in that, right? I have looked at it several times over the past few years and never found much on it other than Dave's work at Desert Home. May have to revisit this again as soon as I get the current projects caught up...
Is this in addition to the prime cycle (3 min on my pump)?
Wow. I havent seen this reply. Yes sir, that was it. You have to start the pump at a full 3500RPM for the priming and then you can set any speed you want.
@MYeager1967 After 1 year of usage, it seems that my rs485 usage consists of just switching pump to 3500/1500 speeds . If you just want to have fun -- you can do rs485, if not - you wont lose much with relay controls (except that you need some more free relays. If you have hayward pump and this code in this repo wont work, you can try mine or reuse the code in https://github.com/avbdr/poold/ to see if it will make difference.