Hayward inverter heatpump 81504 njspc support? (same as 81514, 81524, 81534, 81544)

[wimvanspringel]

Hi everyone, I am very new to njspc and trying to find out if there is support for my Hayward heatpump 81504?
It is also sold under the brand Powerline by Hayward, and also different power versions (81514, 81524, 81534, 81544) sharing the same electronics. I managed to sniff the RS-485 and it doesnt use the goldline protocol, it is very simple back and forth between a master and 2 slaves with fixed size packets and no stx/etx.
Any tips or prior experience before I go in deep with Nixie (I dont have a pool controller).
Thanks.

[tagyoureit]

If you want to post up the comms packets we could take a look. I currently don't have a ton of bandwidth, but if you want to post up what you have I can take a look.

[wimvanspringel]

That would be great, thanks.
Yesterday I made some more progress analysing the protocol, I cant seem to use any of the standard tools (docklight/ioninja) as it seems packages are non-standard.
No modbus, no goldline/aqualogic, no ETX/STX and I cant find any size info in the packets either.
Thanks to IOninja and saleae I have found that the bus is 96008N1 and every packet ends with a 2-byte CRC, and with the saleae trace I can see the length of a packet transmission, but the size of each packet is a bit of a mystery, looks like they are fixed, with up to now 4 observed different lengths: 8, 31, 65 and 189.
The bus is very noisy, so unfortunately the saleae logic analyzer doesnt work (it is all over the place), but you can see subtle level differences when different senders are sending, looks there is 1 master and 2 slaves, one of them the display/button console on the outside.
For now, I test with the heatpump dry and only powering on, nothing more until I can decrypt the observed packets.

start.txt
This is the hex dump of first 10 seconds, first byte is startup gibberish.
start_small.zip
This is the saleae trace for the first 10 seconds

Assuming bus master always speaks first, it looks like it polls 2 slaves with 2 8-byte query packets:
Nr1: 0x01 0x03 0x0b 0xb9 0x00 0x1e 0x16 0x03
Nr2: 0x02 0x03 0x0b 0xb9 0x00 0x1e 0x16 0x30

Nr2 immediately answers with a 189-size packet (and keeps doing that) , I assume it to be the compressor.
Nr1 only answers after the 5th query, I think it is the display powering up. Right after the answer, 3 packets (sizes:189, 189, 31) get sent by the master, each time acq'ed by the slaves with an 8-byte return, returning the 6 first bytes with a 2-byte crc.
0x01 0x10 0x03 0xe9 0x00 0x5A
0x01 0x10 0x04 0x43 0x00 0x5A
0x01 0x10 0x0B 0xb9 0x00 0x0b
After that nothing else, just the master keeps querying and slaves returning same size packets.
I believe the 3 packets are display commands, as the displays powers up with 3 text strings: "U 1.5" then "u 1.3" then "off"
I am now into writing a python script to decrypt these messages and inspect the payloads a bit further.

Thanks for any tip!

[wimvanspringel]

Update after spending work on writing python code to make sense of this bus.
The good news: I think I got the protocol understood, I cant find size or address in the packet headers, but thanks to the 2-byte little endian crc at the end of each packet, I managed to nail it down to some 18 different packets.
I've got all the code and the resulting csv published on github here:
https://github.com/wimvanspringel/python-serial-485

Decoding payloads: The payloads in these packet are big, some 65 bytes, some 189 bytes and decoding them is the next step.
M1/M2 seem to give constant information on temperature and probably other parameters
M3/M4/M5 seem status defining
M7 and M10 seem to address a non-existing device (wifi controller?)
M8 and M11 are somehow linked but do get responded to

Any advice or tools to decode these payloads?
I already found a counter field in the SL1 payload but excel cant handle 362 character cells.
The csv viewer in Visual Studio Code is great but doesnt have data filter possibilities.

[tagyoureit]

Which RS-485 port are you connecting to? I'm asking because these packets look more like networking packets than RS-485 pool controller packets.

[wimvanspringel]

I'm connected at B, so right after the display controller. I havent investigated in depth at PCB level, but the schematics seem to imply that electrically these A & B connection points are the same.
These packets are indeed ridiculously long, I started analysing these payloads and at most 4-5 bytes change in a 189 packet, you wonder why. Not a bad idea to look at these with an 802.3 frame inspiration :-)
Will deep-dive into the pcb and cabling during the weekend

[tagyoureit]

I'd try to connect at A. The packets you have look more like networking packets, which might make sense if they are being sent to a WiFi controller. Hayward would have to re-write their entire stack to communicate like this with other/legacy equipment. My guess is that the other rs-485 should be more like the goldline protocol.

[wimvanspringel]

I removed the whole pcb and there is only one outside rs485 connection and that is the one I connect too.
As you suggested, these are probably frames ready for a wifi controller addition, not a poolcontroller interface.
I keep digging in analysing the traffic.
I think I know who the second device on the bus is, the EEV electronic expansion valve.
fyi the mcu on the pcb is a renesas 44-pin R5F100FFA

[wimvanspringel]

Update: I've uploaded all pictures of the teardown on github here.
Additionally, the EEV is not the 2nd rs485 device, the EEV is driven by a bunch of transistor switches.
I did a teardown of the display unit too.
Continuing my search for the mystery device on that bus.
I also found out the wifi add-on is most probably this one