The 8 byte limit and the 29 bit limit on message IDs are what made me want to move away from CAN.
I think the 8 byte limit is intentional, because large messages would clog the bus which is.bad when your anti-lock brake system needs to get through.
But for home automation, you might care about reliabilty and want your messages to always get through, but usually you don't care if it takes a little extra time.
The simplest scheme I have seen for sending long messages is to send them as a one byte sequence number and a 7 byte payload. Send the first seven bytes with sequence number 0, send the next 7 with sequence number 1, and then signal the end of the message. Signal the end with a message containing only the sequence number and no data. On the receiving side make sure all the sequence numbers incremented in the correct order.
You could have a message with a higher priority that meant "rewind to position X", which could also double as a request for the whole thing by rewinding to position 0. On the sending side, basically send messages while message counter is less than its final value and rewind when asked.
This kind of thing is hard in CAN because message acknowledgement is low level and doesn't really have a concept of a dropped message, and each message has a fair bit of overhead. CAN is extremely reliable, but you have to make sure whatever you stack on top of it is reliable.
Don't forget you have the option to define your own protocol on top of RS485 or even using CAN transceivers instead of using CAN.