Message Format unknown #1

netmindz · 2022-02-06T21:19:53Z

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 · 2022-02-07T04:29:43Z

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 · 2022-02-07T04:44:49Z

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 · 2022-02-07T14:46:30Z

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 · 2022-02-07T14:50:59Z

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 · 2022-02-07T15:17:34Z

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 · 2022-02-07T15:39:58Z

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 · 2022-02-07T18:39:20Z

@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 · 2022-02-07T19:29:44Z

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 · 2022-02-07T21:27:01Z

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 · 2022-02-07T21:35:39Z

yeah, that would appear to the the case,

See

netmindz · 2022-02-07T22:22:52Z

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 · 2022-02-07T22:34:40Z

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 · 2022-02-07T22:41:53Z

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 · 2022-02-07T23:00:05Z

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 · 2022-02-07T23:05:44Z

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.

netmindz · 2022-02-07T23:24:29Z

We actually see two messages if you see msg-count-light-on, they start the same but one has an extra bit on the end. For the hex dump i went for the longer form, just in case in some cases it contained useful stuff and didn't want to mix or suddenly change message length

I've just committed the very hacky debug2.php that is able to read the status for light, pump1 and pump2, What is interesting us both pumps on not only changes the pump byte, but also the light swaps to 80

netmindz · 2022-02-07T23:41:59Z

Runing php debug2.php dump-panel-test shows that the led byte is clearly dependent on other thing as seeing values of 04 and pump of c0

That was a dump taken of where i basically worked my way through all the buttons to see if i could grab all the different messages. running the script like that allows you to replay the events, though limited use i guess without a video of what i was doing at the time

netmindz · 2022-02-07T23:45:51Z

For reference the following

fa 14 33 33 35 43

is the header, (fa 14) then 335C in ascii when the tub us at 33.5C

netmindz · 2022-02-09T20:27:18Z

Have just pushed an updated debug2.php script

Making good process with showing status of the tub - got most stuff mapped now, bar knowing ecn/slp/std

netmindz · 2022-02-09T21:12:03Z

I've also tried to summarise on the wiki https://github.com/netmindz/balboa_GL_ML_spa_control/wiki/Message-Format

I'm getting the feeling that there is some bitmask style stuff is going on or something similar as things like while i thought was just the light, seems to change when you turn on multiple pumps

netmindz · 2022-02-09T22:03:37Z

Thanks for the great tip on using timing as clue to delimiter @bggardner and the help with the FA14 messages.

Any ideas on the AE0D messages or why you think we see the repeating format of messages i describe on the wiki page?

netmindz · 2022-02-09T22:09:35Z

@davewatson91 - Did you see I have a issue to track the pinout and the use of the remaining pins? #2

If you could take a look at the scope plots to see if you have any ideas about the rather odd values that would be much appreciated

bggardner · 2022-02-09T22:37:04Z

Try recording messages (with timestamps) during initial power-on of the spa. At this point, maybe only record timestamps per-message instead of per-byte. Do this with the top panel/display connected and disconnected and see if there is any different traffic. You can also try disconnecting the top panel/display while it's running, but be very careful as there is high voltage present.

netmindz · 2022-02-20T08:50:11Z

@bggardner without the top panel connected there is no traffic at all on the rs485 link. I wonder if the other pins form some part of discovery/negation system.

Have folk looked at the scope plots for the other pins. Any guesses at to what they are?

netmindz · 2022-03-04T00:25:47Z

As only 3 pins, that to me makes me think I2C maybe, but then what about the extra pin?

netmindz · 2022-03-05T10:47:12Z

I've committed the first very very rough PoC that is able to read the temperature data and show up automatically in Home Assistant

netmindz · 2022-03-05T13:16:08Z

So, bit more info. If you unplug the top panel then all data stops on the rs485 line, so either this is creating the data to be shared with other devices - say long distance link for aux panels inside the property based on the other pins or that the data we are seeing is only triggered by the panel with the control unit responding.

netmindz · 2022-03-12T08:53:24Z

Have an ESP8266 now running feeding the status data to Home Assistant. So thanks for everyone's help getting this far, next challenge is going to work out how to actually send commands, so any help would be much appreciated on that, see the other thread for discussion on the data lines

netmindz · 2022-03-12T10:48:30Z

@bggardner - I think you may be right about the FB 06 being some form of reply to the FA 14, what is odd about that though is why would you only get that after the first FA 14.

Turning my attention to the AE 0D messages, they actually cycle between AE 0D 00, AE 0D 01, AE 0D 02 and AE 0D 03

I'm also seeing some messages that are CA 82

Does anyone have a spare ESP8266 or ESP32 and RS484 adapter to try connecting up to their tub too? Have got to the stage that is actually useful for practical purposes, like checking up to temp from the comfort of the sofa and seeing the graphs and logs in Home Assistant for how the wind triggers the heater more often etc

bggardner · 2022-04-26T14:03:08Z

@netmindz I have a Balboa spa, just not this kind. I deciphered the bitstream for mine and figured it would be something similar for yours.

netmindz · 2022-05-24T13:24:30Z

@tmjo looks like the next two hex values after the time is the temp in Fahrenheit if you convert the hex to decimal. Interesting that it's sending the temp for the purpose of your display as Centigrade but also as Fahrenheit

tmjo · 2022-05-27T22:25:36Z

Hmm, that's interesting. Did a spotcheck right now, and seems that you're right. Could it be that this is the real temperature, and the location we're reading is basically the display? Could make sense since it actually includes the letter 'C' for centigrade, and it also changes to text when we're digging into the menus. Just a though, worth checking out.

Btw; I have some stuff regarding power and energy that I would like to propose, just need to find the time :)

My setup has been working flawlessly for more than a month now, really happy with what we have here! Did you get any further on sending commands?

tmjo · 2022-06-08T15:29:44Z

Proposed some PRs, take a look when u find the time. Included a sensor using the Fahrenheit value too. Applied some rounding with a tweak I found online to round to nearest 0.5 to match better the values we see in the display.

I had a good feeling that the F-value could be the 'master' as mentioned above, but on the other hand I see the following after trending it a few days:

That is before I added the rounding, but still you can see that the display value clearly shows some "dips" in temperature (and it matches when the heater is switched on). These are not shown in the post-time Fahrenheit value as far as I can record.

netmindz · 2022-06-14T21:06:55Z

So found out a key bit of info - while it's true that I don't see any serial traffic if you boot the controller without the top panel attached, if you boot up the controller with the top panel and then remove the top panel, the "long" messages just become short. e.g

fa14333230430000620000008002ffff5a0000000000d3
fa14333230430000620000008002ffff5a0000000000d3fb0603450e0000ff74
fa14333230430000620000008002ffff5a0000000000d3

becomes

fa14333230430000620000008002ffff5a0000000000d3
fa14333230430000620000008002ffff5a0000000000d3
fa14333230430000620000008002ffff5a0000000000d3

Therefore, the FB messages must be being sent by the top panel.

So still weird pattern, controller sends FA message, top panel ignores. Controller sends same FA message again, top panel responds, contoller sends FA message again, ignored by top panel

Controller then repeats pattern for the AE messages

The FB message for me pressing the temp down button is fb0603450e0002fd50

netmindz · 2022-06-14T21:26:56Z

Do you see the same FB strings @tmjo? I'm wondering if the top panel message has any form of deviceid as part of it, given you can have multiple top panels

tmjo · 2022-06-15T06:29:45Z

Interesting! I mostly see fb060343060000ffce, but I extracted values from my HA database over a couple of weeks and see that the last to characters change. The ce-value is there most of the time, but I've seen e7, c7, ce, cf and fe as last characters. The other ones come for very short time every now and then.

I've been thinking the same as you that there should be some kind of deviceid, address or something like that in there somewhere.

tmjo · 2022-06-15T07:31:34Z

Just a thought about the three messages - is it possible that the controller either has a max of three panels connected and therefor sends three "requests" where it expects a fb-reply from each panel? Or perhaps that one is the controller itself, while the two others are our top panel + esp if it senses that we're on the communication bus?

Anyway, what could be interesting to figure out is if we need to send some kind of fb-reply to be able to control the tub, right? I didn't figure out how you did when you tested sending commands. Care to elaborate a bit on your method, then I could try to test a bit too.

netmindz · 2022-06-15T12:04:56Z

Can you post what FB you get with pressing Temp+ and Temp-

press temp down
fb0603450e0002fd50

press temp up
fb0603450e0001fe66

vs my idle
fb0603450e0000ff74

I'm assuming at the moment final 2 values are some for of checksum

netmindz · 2022-06-15T12:23:42Z

Just a thought about the three messages - is it possible that the controller either has a max of three panels connected and therefor sends three "requests" where it expects a fb-reply from each panel? Or perhaps that one is the controller itself, while the two others are our top panel + esp if it senses that we're on the communication bus?

Anyway, what could be interesting to figure out is if we need to send some kind of fb-reply to be able to control the tub, right? I didn't figure out how you did when you tested sending commands. Care to elaborate a bit on your method, then I could try to test a bit too.

Mystery solved!!

So I had my panel connected to the middle of the 3 sockets and saw FB messages on the middle of the 3 FA messages, move my top panel to the top-most socket and i now see the FB on the 3rd message, so must be numbered bottom to top

fa14202020200000003200008002ffffff00000000008a
fa14202020200000003200008002ffffff00000000008a
fa14202020200000003200008002ffffff00000000008afb0603450e0000ff74

So - my thinking as that while probing established that while there is a single RS485 bus that all the panels connect to, the extra pins we haven't worked out what they are for yet seem to somehow let the panel know which port it's connected to

So, if during startup the panel knows it's panel number 1 say, then it replies to the 1st FA message it sees. If it's the second, then ignore the first FA and reply to the next etc

So to send our own message, we either need to discover this method or just have hard coded param in the code so we don't try and transmit at the wrong time. We count the FA messages then my code at the moment that just waits for a moment where there is no data, instead should only send the FB command when the FA for us has just been sent. It's odd that each FA message is the same rather than containing some ID, but this is my best guess at the moment

tmjo · 2022-06-15T12:51:26Z

Great finding!

I'll try to catch my fb while pushing temp up/dn once I'm online with the tub again.

netmindz · 2022-06-15T13:27:10Z

Team effort, based on your idea @tmjo

Have pushed a branch that has an attempt at sending data, won't work as our message processing is kinda one message behind.

i.e If the next byte is not the start of a message, add to the buffer, if it is then process what we hold in the buffer.

Makes for simple way to handle message that might be short/corrupt etc without checksums etc, but really i think we need to read X bytes, then based on that know the message length then read that many, then process as soon as we have all the message, not when the next message starts. Not sure how to handle short reads, how to get into sequence etc. Might have a look at the other Balboa project to see how they do it

#11

Note: for your MAX885 chip you would also need to toggle high/low for the tx/rx

netmindz · 2022-06-15T13:33:25Z

Also, thinking about it, our "fake" FB messages most likely need to use a different device id value as otherwise that could just be delayed response by the previous panel

Might need to try capturing all the serial data on bootup to see if i we see any of the panel discovery on the rs485 or if that's on the unknown (I2C?) pins

tmjo · 2022-07-18T11:44:48Z

Hi. Perhaps this is old news, but I can't remember that we discussed so it has slipped my attention for sure. I did some more thorough logging via Telnet (did some minor changes to code to send more of it to Telnet), and discovered two things that was new to me:

In addition to the ae0d01,02,03 there is a ae0d00 message. It seems to follow the same pattern as the other ae0d-messages (i.e. three in a sequence and there is a fb-tail on the first one), but the content is different. I started to dig into what it could mean. Example:
ae0d005353494420444953504c415994fb060343060000ffce
where the middle part reads in ascii: "SSID DISPLAY" followed by 94 hex or 148 decimal.
Studied the ca-message that comes every once in a while (approx once a minute?). It also comes with the same fb-tail as the other on some of the messages. Also, the latter part (after ca8200 in example) is followed by the same content as we see in the fa14-message (6900000084021500660000000000ea in example, possibly also two leading zeros). Moreover, the 8200-start seems to change when doing longer logs but I need to study it more in detail. Example:
ca82006900000080021611660000000000d6fb060343060000ffce

I'm not sure what this means for us, but for me this was news. Did you see it before?

I completely forgot to reply on the fb-message temperature up/down that we discussed above, but I did some tests back then, and I couldn't see the same as you. I will doublecheck just to be certain, but I actually believe we checked that before as well. If it is really different on your installation compared to mine, it could be since you have a panel with up/down buttons while I have only one button with kindof a state for up/down.

Anyway, just though I'd let you know. Leaving for a couple of days, but intent to do some more digging soon.

netmindz · 2022-07-20T08:01:49Z

Thanks for that @tmjo

I had in the past seen some non-idle AE0D messages, but I've actually removed that from my current display in HA. Can't remember if I thought was just duplicate or stuff we had already or if for some reason I was only seeing the idle message

netmindz · 2022-07-20T08:04:40Z

Don't think I've spotted and CA messages actually. Will have to see if I see them

netmindz · 2022-07-20T08:05:30Z

With the temp change. Can you try and do a message capture for changing temp? @tmjo

netmindz · 2022-07-20T08:28:51Z

One think to point out is that if the FB sequence is created by the top panel. As ours differ in both model and possibly manufacturer, it's to be expected these differ in their output.

The protocol format should be the same enough that cracking how we actually implement sending out own FB messages should be the same though. Simply replaying a FB message in response to one of the other "slots" of FA messages didn't seem to be enough. Which makes sense if we assume that the FB message has some form of unique id, then the control unit would only be looking for FB message with the right ID when listening for a reply in that "slot"

tmjo · 2022-07-22T19:14:44Z

Hi again,

Some temporary results from temp up/down test today:

2022-07-22 19:08:20.845473: s2: fa1433393043000069000000800212196600000000000afb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:9_STD menu:00 cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:21.207011: s2: fa1433393043000069000000800212196600000000000afb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:9_STD menu:00 cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:21.466378: s2: fa1433393043000069000000800212196600000000000afb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:9_STD menu:00 cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:21.586444: s2: fa1433393043000069000000800212196600000000000afb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:9_STD menu:00 cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:22.071089: s2: fa143339304300006946000080021219ff000000000045fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:22.807438: s2: fa143339304300006946000080021219ff000000000045fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:23.065137: s2: fa143339304300006946000080021219ff000000000045fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:23.306417: s2: fa143339304300006946000080021219ff000000000045fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:25
2022-07-22 19:08:24.545287: s2: fa14333835430000694600008002121aff000000000002fb060343060000ffce ->(65) LCD:385C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:24.786639: s2: fa14333835430000694600008002121aff000000000002fb060343060000ffce ->(65) LCD:385C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:25.145422: s2: fa14333830430000694600008002121aff000000000043fb060343060000ffce ->(65) LCD:380C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:25.654408: s2: fa14333830430000694600008002121aff000000000043fb060343060000ffce ->(65) LCD:380C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:26.626862: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:26.865512: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:27.022248: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:27.878094: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:27.987919: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:28.231694: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:29.085838: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:29.206302: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:29.348238: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:29.467530: s2: fa14333930430000610000008002121a6600000000004ffb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:1_STD menu:00 cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:29.606594: s2: fa14333930430000610000008002121a6600000000004ffb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:1_STD menu:00 cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:29.826579: s2: fa14333930430000610000008002121a6600000000004ffb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:1_STD menu:00 cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:30.211191: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:30.578100: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:30.686129: s2: fa14333730430000614600008002121aff000000000022fb060343060000ffce ->(65) LCD:370C, T:255F, 123.88988C pump:0 heat:0 light:0 status:1_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:31.092677: s2: fa14333735430000694600008002121aff00000000004bfb060343060000ffce ->(65) LCD:375C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:31.185113: s2: fa14333735430000694600008002121aff00000000004bfb060343060000ffce ->(65) LCD:375C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:31.304892: s2: fa14333735430000694600008002121aff00000000004bfb060343060000ffce ->(65) LCD:375C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:31.805225: s2: fa14333830430000694600008002121aff000000000043fb060343060000ffce ->(65) LCD:380C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:31.932452: s2: fa14333830430000694600008002121aff000000000043fb060343060000ffce ->(65) LCD:380C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:33.645202: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:33.765791: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:34.006195: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:34.152332: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:34.869809: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:35.005830: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:35.248917: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:35.365173: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:35.490215: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:35.613060: s2: fa14333930430000694600008002121aff000000000028fb060343060000ffce ->(65) LCD:390C, T:255F, 123.88988C pump:0 heat:0 light:0 status:9_STD menu:46_TSet cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:35.869446: s2: fa14333930430000690000008002121a66000000000067fb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:9_STD menu:00 cmd:0000000000 tubtime: 18:26
2022-07-22 19:08:36.105694: s2: fa14333930430000690000008002121a66000000000067fb060343060000ffce ->(65) LCD:390C, T:102F, 38.8892C pump:0 heat:0 light:0 status:9_STD menu:00 cmd:0000000000 tubtime: 18:26

Seems like the F-temp is showing value FF when we are in menu 46 (i.e. lcd blinking and temperature changing).
I don't see any change in fb-tail when doing temp up/down
I do however see changes in the 1-2 last bytes before the fb-tail. Unable to see the logic right now, but it seems clear that it is changing for every temp up/down. I think these bytes are missing from the cmd-string we have?
Standby mode also seem to report value FF as F-temp (menu=5a)
I do see some changes in last 4 bytes of fb-tail when doing mode changes.

Can't say I got any wiser, but at least some results :)

tmjo · 2022-07-22T21:54:12Z

Hmm, by doing some random logging without touching the tub I also see that the two bytes before fb-tail change when tubtime changes. I guess we assumed them to be some kind of checksum, right? That could be, but it was funny how they seem to change also everytime I press the temp up/down. Or then again, maybe not, since the LCD-value obviously changes as well.....

netmindz · 2022-07-23T08:12:17Z

Can you tweak your capture @tmjo to also log the FB sequence response to the AE0D messages, it might be your top panel send it's commands via those of you aren't seeing the value in what's being captured.

Just woke up, so brain not in gear enough to decode hex just yet, but yeah if you are seeing the final two values change in that suspected checksum, then there should be a value earlier that changes. If your top panel doesn't actually let you set the time, it might be an idea to flip the dip switch on the control board to reflect that and then we won't have the "noise" of the time changing

tmjo · 2022-07-23T23:35:26Z

Sure thing. I couldn't see anything when I looked, but for sure there must be something I'm not seeing. See here for logfiles (denoted _raw with all details).

I studied the newer protocol again, and it could make sense there are some Channel Assignment Requests or similar on our tubs as well. Also, it would be interesting to find if there is a clear-to-send (CTS) value of some sort. Although these tubs are newer, there seems to be quite some similarities too. I'm planning to make a clean sketch with pure telnet logging and then do some loggings during rebooting/powerup of the tub. Did you try that already?

tmjo · 2022-07-26T07:41:16Z

Hi again! Some interesting news from my side. Seems I could be missing some messages in the normal program, so I ran a cleaner version with pure telnet logging.

I do in fact see changes in fb-tail men pushing buttons. Did a lot of it, and seem to receive:

	Steady state	fb060343060000ffce
	Temp		fb060343060005
	Light		fb060343060009f64c
	Jets		fb060343060006f9a2
	Aux		fb060343060007f8b0

Reading a "c" when my Aux-function is on (after pushing Aux-button), so I believe the unknown byte just before pump byte is for this function. Physically this function is not working as it is disconnected due to earth failure on the aux pump.
Did some logging during power cycling the tub. Couldn't see anything very different from what we see normally (i.e. no new message types as far as I see), but there is certainly a sequence. It shows in the LCD-values a clear sequence of 100, 119, 28 and 1-3 while both time is FFFF and temperature is FF. I believe it could be some software version or possibly an address. Interestingly the ae0d00 message shows only zeros during this cycle (the one that normally showed some ascii SSID DISPLAY and a number). I don't think I waiting long enough to see it change, noticed the tub took quite a while before entering back into operation.

See here for results if you want to dig into the details. I made an Excel-sheet for easier reading, by using filtering it's easy to see when stuff is happening.

Will study it myself more in detail.

netmindz · 2022-07-26T08:40:29Z

Thanks for the extra info. My suspicion was that anything to do with startup initialisation is on the pins that we have yet to establish the format of, given I saw zero rs485 data unless the top panel is connected and how the physical port you are connected to affects what we see in terms of messaging.

With regards to the left of CTS, either this is on the other pins or simply done by counting the messages and then responding once the top panel has seen the FA message that's in its "slot"

I haven't put a scope onto the aux panel connectors to see if they are just the rs485, just the unknown stuff or entirely different

With regards to boot up, yeah that sounds like the display showing the firmware version of the control

With regards to the FB tails, that's good to hear you are seeing button press data there. What did you change to get to see those?

Is the temp really a short message or just a quirk of how you are parsing?

tmjo · 2022-07-26T19:41:29Z

I'm not quite sure what made a difference on the measurements. What I did was tweaking a cleaner and simpler code, removing all HA-stuff and webserver and leaving basically telnet only. To increase speed was the thought. But not sure if that made a difference, or if it just helped that I pushed the buttons like a maniac which made it easier to detect if loosing some messages.

To my knowledge I only see the short fb060343060005 for temp-button, it's strange that it is shorter, but I don't do anything in parsing that should shorten it.

I also see that I get som fa94 message in between (see the actions-sheet), quite a bit of them too. Most are just fa94, but there are some with some more data, but a few has more data too. Not sure if this can be garbled data, noise or something, or if they are real.....

tmjo · 2022-08-03T00:09:59Z

To my knowledge I only see the short fb060343060005 for temp-button, it's strange that it is shorter, but I don't do anything in parsing that should shorten it.

Thinking of it, it makes perfectly sence (in a way). The targetTemp never worked well for me, it never caught my temperature adjustments unless I did a "dummy" toggle on the temp-button (i.e. flashing temperature display, but making no changes). Since the code looks for result.length() == 64 && result.substring(0, 4) == "fa14" it wouldn't find my short message of fb060343060005 and that's probably why it doesn't work.

Why it is shorter is a still a mystery though.

netmindz · 2022-09-15T17:59:08Z

@tmjo - I did a bit more testing on the temp from F stuff you found, but certainly for me I'm still only seeing temp change in 0.5C increments. I hoped we might get greater granularity and so better time estimates for the time to temp, but looks like no luck there

tmjo · 2022-09-16T06:19:59Z

Agreed. I just get 0.5C resolution, and I've also noticed that the display shows a slightly different temperature sometimes (typically the 0.5C difference though). Typically is doesn't indicate the falling temperature that triggers the heater. Not very easy to see on the image below, but DisplayTemp (blue) clearly shows drops to 38.5 while F-temp (purple) doesn't indicate this.

I also see a FF-value in the F-temp when temperature is in set-mode (flashing). We need to "filter" that out, but unfortunately I didn't have much time lately to fool around with it. Should be easy enough.

netmindz · 2022-10-13T08:11:55Z

I'm so close and yet so far from being able to send data. Sending only once at the point in the stream I expect and with pin4 and pin5 in the state i believe to be right doesn't work but if I keep sending the tub with light toggle commands it takes effect intermittently

Might need to do more closer inspection of the output of genuine panel to see how many times a FB with button press is actually sent

Might also use the 3rd port and another rs485 adapter to read what's actually on the bus to confirm the esp is definitely putting the right data out all the time

netmindz changed the title ~~Message Format~~ Message Format unknown Feb 9, 2022

netmindz closed this as completed May 5, 2023

Message Format unknown #1

Message Format unknown #1

Comments

netmindz commented Feb 6, 2022

davewatson91 commented Feb 7, 2022

davewatson91 commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022

bggardner commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022

bggardner commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022 • edited

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022 • edited

bggardner commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 7, 2022

netmindz commented Feb 9, 2022

netmindz commented Feb 9, 2022

netmindz commented Feb 9, 2022

netmindz commented Feb 9, 2022

bggardner commented Feb 9, 2022

netmindz commented Feb 20, 2022

netmindz commented Mar 4, 2022

netmindz commented Mar 5, 2022

netmindz commented Mar 5, 2022

netmindz commented Mar 12, 2022

netmindz commented Mar 12, 2022

bggardner commented Apr 26, 2022

netmindz commented May 24, 2022

tmjo commented May 27, 2022

tmjo commented Jun 8, 2022

netmindz commented Jun 14, 2022 • edited

netmindz commented Jun 14, 2022

tmjo commented Jun 15, 2022

tmjo commented Jun 15, 2022

netmindz commented Jun 15, 2022

netmindz commented Jun 15, 2022

tmjo commented Jun 15, 2022

netmindz commented Jun 15, 2022

netmindz commented Jun 15, 2022

tmjo commented Jul 18, 2022

netmindz commented Jul 20, 2022

netmindz commented Jul 20, 2022

netmindz commented Jul 20, 2022

netmindz commented Jul 20, 2022

tmjo commented Jul 22, 2022

tmjo commented Jul 22, 2022 • edited

netmindz commented Jul 23, 2022

tmjo commented Jul 23, 2022

tmjo commented Jul 26, 2022

netmindz commented Jul 26, 2022

tmjo commented Jul 26, 2022

tmjo commented Aug 3, 2022

netmindz commented Sep 15, 2022

tmjo commented Sep 16, 2022

netmindz commented Oct 13, 2022

netmindz commented Feb 7, 2022 •

edited

netmindz commented Feb 7, 2022 •

edited

netmindz commented Jun 14, 2022 •

edited

tmjo commented Jul 22, 2022 •

edited