Message Format unknown

[netmindz]

Not yet sure which char is used as message delimiter or that bytesize and baudrate etc are defiantly correct.

Can't really start breakdown down the contents of the message until the basics are sorted

[davewatson91]

OK, so I've had a very quick play around.

If you split the file on 0xe1 20 20 20 80 0a 02 you can see 3x different message lengths (not sure if this is the right start sequence or not).

I'm curious - would the spa have been 38.5c temperature when you took the dump? - possibly seeing that in ascii in each message (maybe what it's sending for the display - might change when you press buttons and have the display change while recording (which may be in the other dump files I haven't played with yet)).

[davewatson91]

Further digging looks like that isn't a start sequence, the first byte in some packets appears to be possibly a tx/rx flag or user flag? - it changes when it looks like the temperature is changed. the ASCII does appear to be the temperature commanded, as it changes in the dumpfile dump-temp when split on 0xe9 as an end byte.

I need better packet/byte analysis tools - does anyone have any suggestions? Wireshark isn't playing ball for importing for some reason, and isn't the greatest for the completely unknown protocols.

[netmindz]

Yeah the spa was as 38.5 at the time with the temp dump was when i was trying to change the temp up to 40C

I should perhaps explain the dump files are not all the raw data, some of them were created from a script where i tried to guess the delimiter and write out each sequence on it's own line into the file to see if it looked plausible.

CTRL+B looked like it might be right and would seem to make sense as logical value to choose as that means "start of text"

What is interesting is that I am not seeing a one2one relation to what is in the stream and the display. e.g when the display alternates between "Ecn" and the temp, while mode is Economy, there is no reference to Ecn as a a straight ascii string. Similarly when in the menus, no entries there.

Given on this board we have both 8pin Main Panel connectors and 6 pin Aux Panel connectors, I wonder how the differ in what they carry.

Lost access to the tub at the moment as the 9v pin I tried to used with stepdown to v5 to power the pi isn't working, was on usb charge pack instead that's now flat. Will have a look after work

[netmindz]

dump-7 and dump-8 are raw

python tcp_serial_redirect.py --bytesize 8 /dev/ttyUSB0 115200
then
nc hottub 7777 > dump-8

Then the same, but bytesize = 7

[netmindz]

See dumps/dump.cap for tcpdump of the data @davewatson91 - This includes me pressing lights on/off, pump1 and pump2 on and off and then dropping the temp down

[bggardner]

I think the best way to detect the delimiter byte(s) is to add a timestamp as they come in. You will probably see a break between messages. On my BP series, the reported time between bytes is ~250us while the time between messages is usually greater (though not always). The TCP redirect may obfuscate this, so I'd stick with pure Python. Here's a snippet:

import serial
import time

s = serial.Serial("/dev/ttyUSB0", baudrate=115200)
while True:
    b = s.read(1)
    if len(b) == 0:
        continue
    print("{:02X}@{:f}".format(b[0], time.monotonic()))

[netmindz]

@bggardner

FA@12332.511769 14@12332.522348 33@12332.522613 34@12332.522830 30@12332.523043 43@12332.523247 00@12332.523447 00@12332.523650 E1@12332.523822 00@12332.523990 00@12332.524155 00@12332.524317 80@12332.524479 02@12332.524641 FF@12332.524803 FF@12332.524966 5D@12332.525132 00@12332.525295 00@12332.525457 00@12332.525619 00@12332.525781 00@12332.525943 3D@12332.526108 AE@12332.531697 0D@12332.531867 00@12332.532032 00@12332.532196 00@12332.532359 00@12332.532521 00@12332.532682 00@12332.532844 00@12332.533006 00@12332.533169 00@12332.533330 00@12332.533494 00@12332.533656 00@12332.533818 00@12332.533979 2D@12332.534141 AE@12332.551847 0D@12332.552137 00@12332.552360 00@12332.552567 00@12332.552769 00@12332.552971 00@12332.553176 00@12332.553384 00@12332.553588 00@12332.553760 00@12332.553925 00@12332.554088 00@12332.554250 00@12332.554415 00@12332.554577 2D@12332.554740 FB@12332.554903 06@12332.555066 03@12332.555228 45@12332.555391 0E@12332.555555 00@12332.555718 00@12332.555881 FF@12332.556044 74@12332.556209 AE@12332.570718 0D@12332.570993 00@12332.571218 00@12332.571425 00@12332.571629 00@12332.571830 00@12332.572032 00@12332.572240 00@12332.572443 00@12332.572616 00@12332.572781 00@12332.572945 00@12332.573111 00@12332.573278 00@12332.573441 2D@12332.573604 FA@12332.592088 14@12332.592359 33@12332.592581 34@12332.592788 30@12332.592991 43@12332.593197 00@12332.593400 00@12332.593601 E1@12332.593804 00@12332.593978 00@12332.594144 00@12332.594310 80@12332.594473 02@12332.594635 FF@12332.594797 FF@12332.594959 5D@12332.595122 00@12332.595287 00@12332.595450 00@12332.595611 00@12332.595773 00@12332.595937 3D@12332.596099 FA@12332.610959 14@12332.611231 33@12332.611451 34@12332.611655 30@12332.611855 43@12332.612061 00@12332.612264 00@12332.612465 E1@12332.612665 00@12332.612836 00@12332.613001 00@12332.613167 80@12332.613330 02@12332.613492 FF@12332.613654 FF@12332.613816 5D@12332.613979 00@12332.614143 00@12332.614305 00@12332.614466 00@12332.614627 00@12332.614789 3D@12332.614952 FB@12332.615114 06@12332.615277 03@12332.615439 45@12332.615602 0E@12332.615764 00@12332.615927 00@12332.616089 FF@12332.616253 74@12332.616416 FA@12332.632337 14@12332.632609 33@12332.632831 34@12332.633043 30@12332.633248 43@12332.633452 00@12332.633655 00@12332.633858 E1@12332.634065 00@12332.634267 00@12332.634440 00@12332.634606 80@12332.634771 02@12332.634935

[netmindz]

Tweaked to show time interval rather than time, see https://github.com/netmindz/balboa_GL_ML_spa_control/blob/main/tests/bggardner-timestamp-interval.log @bggardner

[bggardner]

Looks like FA and AE are prime candidates, so maybe both are delimiters. Dividing a dump up that way results in pseudo-triplicates like this:

AE0D010000000000000000000000005A
AE0D010000000000000000000000005AFB0603450E0000FF74
AE0D010000000000000000000000005A
FA14333835430000E1000000800A02FFFF65000000000050
FA14333835430000E1000000800A02FFFF65000000000050FB0603450E0000FF74
FA14333835430000E1000000800A02FFFF65000000000050
AE0D0A02000000000000000000000000C3
AE0D0A02000000000000000000000000C3FB0603450E0000FF74
AE0D0A02000000000000000000000000C3
FA14333835430000E1000000800A02FFFF65000000000050
FA14333835430000E1000000800A02FFFF65000000000050FB0603450E0000FF74
FA14333835430000E1000000800A02FFFF65000000000050

Notice that a byte sequence starting with FB is always after the 2nd "message" in the set. I think we're getting somewhere.

[netmindz]

yeah, that would appear to the the case,

See

• https://github.com/netmindz/balboa_GL_ML_spa_control/blob/main/tests/msg-count-light-on
• https://github.com/netmindz/balboa_GL_ML_spa_control/blob/main/tests/msg-count-light-off

[netmindz]

light of:

fa 14 33 33 35 43 00 00 6c 00 00 00 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 d1 fb 06 03 45 0e 00 00 ff 74 .........E....t
0a

light on:

fa 14 33 33 35 43 00 03 6c 00 00 08 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 e4 fb 06 03 45 0e 00 00 ff 74 .........E....t
0a

[netmindz]

pump1 on:

fa 14 33 33 35 43 02 00 6c 00 04 00 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 97 fb 06 03 45 0e 00 00 ff 74 .........E....t
0a

pump2 on:

fa 14 33 33 35 43 08 00 6c 00 08 00 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 51 fb 06 03 45 0e 00 00 ff 74 .....Q...E....t
0a

[netmindz]

pump1 on:

fa 14 33 33 35 43 02 00 6c 00 04 00 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 97 fb 06 03 45 0e 00 00 ff 74 .........E....t
0a

pump1 on - light on:

fa 14 33 33 35 43 02 03 6c 00 04 08 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 a2 fb 06 03 45 0e 00 00 ff 74 .........E....t
0a

[netmindz]

pump2 on:

fa 14 33 33 35 43 08 00 6c 00 08 00 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 51 fb 06 03 45 0e 00 00 ff 74 .....Q...E....t
0a

pump2 on - light on:

fa 14 33 33 35 43 08 03 6c 00 08 08 80 02 ff ff ..335C..l.......
5c 00 00 00 00 00 64 fb 06 03 45 0e 00 00 ff 74 .....d...E....t
0a

[bggardner]

Let me rearrange so it's easier to decipher the byte sequence:

fa 14 33 33 35 43 00 00 6c 00 00 00 80 02 ff ff 5c 00 00 00 00 00 d1 fb 06 03 45 0e 00 00 ff 74 0a // Light off
fa 14 33 33 35 43 00 03 6c 00 00 08 80 02 ff ff 5c 00 00 00 00 00 e4 fb 06 03 45 0e 00 00 ff 74 0a // Light on

fa 14 33 33 35 43 02 00 6c 00 04 00 80 02 ff ff 5c 00 00 00 00 00 97 fb 06 03 45 0e 00 00 ff 74 0a // Pump 1 on
fa 14 33 33 35 43 08 00 6c 00 08 00 80 02 ff ff 5c 00 00 00 00 00 51 fb 06 03 45 0e 00 00 ff 74 0a // Pump 2 on

fa 14 33 33 35 43 02 00 6c 00 04 00 80 02 ff ff 5c 00 00 00 00 00 97 fb 06 03 45 0e 00 00 ff 74 0a // Pump 1 on
fa 14 33 33 35 43 02 03 6c 00 04 08 80 02 ff ff 5c 00 00 00 00 00 a2 fb 06 03 45 0e 00 00 ff 74 0a // Pump 1 on & light on

fa 14 33 33 35 43 08 00 6c 00 08 00 80 02 ff ff 5c 00 00 00 00 00 51 fb 06 03 45 0e 00 00 ff 74 0a // Pump 2 on
fa 14 33 33 35 43 08 03 6c 00 08 08 80 02 ff ff 5c 00 00 00 00 00 64 fb 06 03 45 0e 00 00 ff 74 0a // Pump 2 on & light on

It's easy to tell what the light and pump bits are. The byte that always changes (byte 22) is most likely the checksum, so fb might actually be the start of another message (response?) since checksum is normally at the end.