Janitor support needed to unclog another Toilet protocol 🪠

[jamsinclair]

Hey there!

I'm back with a new Japanese Toilet Washlet protocol. This is a different brand and differs significantly from what was last seen in #706.

I've used the auto_analyse_raw_data.py script to try generate a basic send/recv class, however it seems like this protocol will need some massaging beyond my expertise to get a working class functioning.

The remote seems to send two different states:

• 78 bit state (For more operational commands)
• 234 bit state (For more complex settings)

If you anyone is able to help point me in getting a functioning send/recv class I can try help debug and refine from there 🤓

Version/revision of the library used

v2.8.2

Output of raw data from IRrecvDumpV2.ino or V3 (if applicable)

Full Flush:

Timestamp : 000151.400
Library   : v2.8.2

Protocol  : UNKNOWN
Code      : 0x43BD67B3 (82 Bits)
uint16_t rawData[163] = {6266, 2734,  598, 540,  598, 1626,  598, 512,  622, 516,  598, 514,  598, 510,  598, 514,  628, 512,  596, 514,  600, 512,  598, 538,  600, 1622,  600, 512,  598, 540,  602, 510,  598, 512,  598, 512,  624, 514,  598, 512,  598, 512,  598, 514,  624, 512,  598, 514,  598, 1652,  596, 514,  598, 1626,  598, 1650,  598, 514,  598, 512,  598, 540,  598, 514,  596, 1626,  626, 512,  574, 1648,  598, 1650,  598, 514,  598, 512,  594, 544,  596, 514,  598, 37996,  6182, 2764,  598, 514,  600, 1648,  600, 512,  596, 514,  598, 540,  598, 512,  600, 512,  598, 512,  624, 514,  598, 514,  598, 512,  596, 1652,  598, 514,  598, 512,  596, 540,  598, 514,  598, 512,  598, 512,  598, 540,  596, 516,  596, 514,  598, 512,  574, 564,  598, 1626,  568, 542,  624, 1624,  626, 1622,  598, 514,  596, 514,  598, 514,  596, 540,  600, 1622,  598, 512,  600, 1650,  598, 1624,  596, 540,  600, 512,  598, 514,  596, 514,  622};  // UNKNOWN 43BD67B3

Light Flush:

Timestamp : 000175.684
Library   : v2.8.2

Protocol  : UNKNOWN
Code      : 0xE5B58773 (82 Bits)
    uint16_t rawData[163] = {6264, 2736,  598, 540,  602, 1622,  600, 510,  622, 516,  600, 512,  596, 514,  596, 514,  626, 512,  596, 514,  600, 510,  598, 538,  628, 1596,  598, 512,  600, 536,  598, 514,  598, 512,  598, 514,  624, 514,  598, 512,  602, 510,  598, 512,  624, 514,  596, 514,  598, 1652,  598, 514,  600, 510,  598, 514,  600, 1648,  600, 512,  596, 514,  598, 538,  600, 1624,  598, 514,  624, 512,  598, 514,  600, 1648,  598, 512,  600, 512,  596, 514,  598, 40244,  6186, 2760,  596, 514,  598, 1650,  600, 512,  598, 512,  598, 540,  598, 514,  596, 514,  598, 512,  624, 514,  600, 510,  600, 512,  598, 1650,  598, 514,  596, 514,  596, 514,  626, 512,  598, 512,  598, 512,  598, 540,  598, 514,  598, 512,  600, 512,  598, 540,  598, 1624,  598, 512,  626, 512,  598, 514,  598, 1624,  624, 512,  598, 514,  598, 512,  600, 1650,  624, 488,  598, 512,  598, 542,  594, 1624,  598, 516,  594, 540,  594, 518,  596};  // UNKNOWN E5B58773

Oscillate Bidet Function

Timestamp : 000200.759
Library   : v2.8.2

Protocol  : UNKNOWN
Code      : 0x4AC5E8B3 (246 Bits)
uint16_t rawData[491] = {6262, 2738,  600, 538,  596, 1624,  598, 512,  652, 486,  628, 484,  600, 510,  596, 516,  650, 488,  622, 488,  626, 484,  598, 540,  600, 1624,  602, 510,  596, 540,  602, 510,  598, 514,  598, 512,  626, 512,  598, 512,  598, 512,  598, 514,  626, 510,  598, 514,  598, 512,  598, 1650,  600, 1622,  600, 538,  596, 514,  600, 510,  596, 514,  596, 542,  598, 514,  598, 1624,  626, 1622,  598, 512,  600, 512,  620, 516,  598, 512,  598, 514,  598, 40244,  6184, 2764,  598, 514,  598, 1650,  598, 514,  596, 516,  596, 542,  598, 512,  596, 516,  600, 510,  624, 512,  598, 512,  596, 516,  598, 1652,  600, 512,  598, 512,  598, 540,  596, 518,  594, 514,  598, 512,  596, 542,  598, 512,  596, 514,  598, 512,  598, 540,  598, 514,  598, 1622,  624, 1626,  598, 514,  598, 512,  626, 512,  596, 514,  596, 514,  596, 540,  598, 1624,  600, 1650,  600, 512,  600, 510,  598, 512,  596, 540,  598, 512,  600, 40244,  6186, 2760,  600, 512,  596, 1626,  624, 514,  598, 512,  600, 512,  598, 512,  626, 512,  598, 512,  598, 512,  596, 540,  600, 510,  600, 1622,  600, 538,  596, 514,  596, 514,  598, 514,  624, 514,  596, 516,  596, 514,  600, 512,  622, 514,  600, 512,  600, 510,  600, 538,  602, 1622,  600, 1648,  626, 512,  572, 512,  598, 514,  650, 488,  598, 512,  594, 516,  598, 1652,  598, 1626,  598, 514,  624, 514,  596, 512,  600, 512,  598, 540,  596, 40246,  6184, 2736,  598, 538,  598, 1624,  598, 512,  598, 540,  598, 512,  600, 512,  596, 514,  600, 538,  626, 486,  598, 514,  596, 514,  652, 1596,  594, 516,  624, 514,  594, 516,  598, 514,  622, 490,  596, 540,  596, 514,  624, 488,  594, 514,  598, 538,  598, 512,  598, 514,  594, 516,  596, 540,  600, 1622,  572, 566,  600, 512,  570, 542,  598, 512,  598, 540,  600, 512,  594, 516,  598, 1652,  600, 512,  598, 514,  596, 514,  624, 514,  598, 42468,  6182, 2764,  624, 490,  594, 1652,  600, 512,  596, 514,  596, 540,  600, 512,  598, 516,  596, 514,  598, 538,  598, 516,  598, 512,  570, 1678,  596, 514,  596, 514,  598, 512,  624, 512,  594, 516,  596, 514,  600, 510,  626, 512,  596, 516,  594, 516,  598, 538,  598, 512,  596, 514,  596, 514,  596, 1652,  600, 514,  594, 516,  622, 514,  600, 512,  598, 514,  596, 514,  624, 514,  596, 1626,  598, 514,  622, 516,  594, 516,  598, 514,  596, 42496,  6184, 2764,  596, 516,  598, 1624,  626, 512,  598, 512,  596, 516,  600, 512,  624, 514,  598, 514,  594, 516,  596, 516,  620, 516,  600, 1624,  596, 540,  598, 514,  600, 512,  596, 516,  596, 542,  594, 516,  598, 514,  594, 516,  624, 512,  598, 512,  596, 514,  596, 514,  624, 514,  596, 516,  598, 1650,  594, 518,  596, 514,  596, 516,  596, 542,  596, 514,  596, 516,  596, 514,  596, 1652,  598, 514,  596, 514,  624, 514,  622, 488,  596};  // UNKNOWN 4AC5E8B3

...There are many more commands, I'll keep track of them once we can correctly decode the data being sent.

Product

Brand: Toto
Model: Washlet Toilet NJ
Manual File: https://www.d-resi.jp/dt/nishi-shinjuku/limited/imgs/pdf/book6.pdf

Circuit diagram and hardware used (if applicable)

Board: NodeMCU v1.0
Receiver: KY-022
Transmitter: KY-005

[crankyoldgit]

I'll drop everything & get right on it. Your Number Two problem is my Number One priority.

[crankyoldgit]

I warn you in advance, this protocol looks more complicated than the last toilet we supported.
Page 62 of the manual may happen as we test this. (i.e. Around page 32 of the PDF)

In all seriousness, it appears to be either a repeating 39 bit message, or for the longer ones, two different 39 bit codes.
This may take some contemplation time. I hope you have some reading material handy near the device. It might take a while.

[crankyoldgit]

@jamsinclair It's time for you to do some "Testing on the Toilet".
I've created branch "toto_toilet" https://github.com/crankyoldgit/IRremoteESP8266/tree/toto_toilet
It should have basic decoding (and sending) for the simple "short" messages. But NOT the longer ones.
i.e. It will probably decode those ones too, but half the data will be missing.

We need to do some analysis on the messages produced to see how we can cram the 39 + 39 bits of the longer codes into 64 bits.

Things I am looking for:

1. Do all of the codes you can produce have a constant/unchanging bits/bytes/section? i.e. If we can shrink 39 bits to 32 for each part of the short & long codes then we can fit it into a uint64_t safely.
2. Do all of the long codes (e.g. long: rawData[491] vs short: rawData[163] have the same 39 bit code at the start perhaps?
3. Any other ideas or patterns. e.g. each hex digit is bit-flipped with the blah-blah bits.

Let me know how the code goes etc.

The "long" codes appear quite funky. They appear to use different sized gaps and a different number of repeats of the sub-code.

You may be able to hack support for the longer codes using the smaller codes too. e.g.

// send a Full Flush.
irsend.sendToto(0x200800B0B0);  // send a Full Flush. The code is sent twice.
delay(30 * 1000);  // Wait 30 seconds
// Simulate sending a long message. e.g. Oscillate Bidet
irsend.sendToto(0x2008006060, kTotoBits, 2);  // Send the First half (39 bits) is sent 3 times.
irsend.sendToto(0x2008001010, kTotoBits, 2);  // Send the Second half (39 bits) is sent 3 times.
// Technically, there is no gap between the second & third send of the data in the second half of the protocol.
// The above doesn't emulate that part, but I'd guess it would work.

Looking at the pictures in the manual (sorry, my skill at understanding Japanese is 0.0001%) it looks like there is some controls that have a range of possible values. i.e. spray pressure & position. We might be able to glean a bit ordering for the data from those values if they increase linearly.

Anyway. Off ya go. Collect some data if it works.

[jamsinclair]

Thanks for the branch and insight @crankyoldgit! Rolling up my sleeves and getting into the dirty work 🔧

it appears to be either a repeating 39 bit message or for the longer ones, two different 39 bit codes

Hmm, something I seem to recall from previous toilet is there's two IR blasters in the remote (one on each end). Only one message was needed to reach the receiver on the bowl to activate it. I believe that may be a redundancy measure depending on where the remote and bowl end up located in the bathroom.

Looking at the pictures in the manual (sorry, my skill at understanding Japanese is 0.0001%) it looks like there is some controls that have a range of possible values. i.e. spray pressure & position.

Unfortunately my Japanese isn't much better, despite living here 😅 , but yes there's some range values that'll would be good to decode if possible. From some preliminary testing it seems that there a indeed particular bytes that change on increase/decrease. Much like an AC remote I'm inclined to believe the whole state is sent on key press. (Edit: I was completely wrong. Don't jump to conclusions without data!)

[NiKiZe]

Is there any message when you for example change pressure? Or how does any other message change after the pressure is changed?

Maybe you can isolate one transmitter and reduce noise?

[crankyoldgit]

Hmm, something I seem to recall from previous toilet is there's two IR blasters in the remote (one on each end). Only one message was needed to reach the receiver on the bowl to activate it. I believe that may be a redundancy measure depending on where the remote and bowl end up located in the bathroom.

That's possible. But we emulate what we see, for maximum compatibility.

Unfortunately my Japanese isn't much better, despite living here 😅 , but yes there's some range values that'll would be good to decode if possible. From some preliminary testing it seems that there a indeed particular bytes that change on increase/decrease. Much like an AC remote I'm inclined to believe the whole state is sent on key press.

Thanks for the insight. I look forward to the data and your analysis and replay attempts.

I hope to hear next that you're flush with success. Hope it doesn't drive you round the bend.

[jamsinclair]

Hmmm, it seems my trusty ESP8266 dev kit is in a bad state. Unable to re-flash it. Depending on if I can fix it, I might be at mercy of worldwide freight until my replacement arrives ✈️ .

Hope y'all didn't get pumped up on this porcelain wonder of a protocol.

[crankyoldgit]

Unable to re-flash it

Aww man, that's crap!
At least you're close to China.

[jamsinclair]

I've managed to battle with my board and got it to flash ⚡️🙌 (Seems like USB connector is a bit dodgy).

Looks like the protocol should be quite simple with some fun extra caveats.

1. Do all of the codes you can produce have a constant/unchanging bits/bytes/section? i.e. If we can shrink 39 bits to 32 for each part of the short & long codes then we can fit it into a uint64_t safely.

Yes, it seems like we can safely condense the codes down to 24 bits. The starting 0x2008 bits are the same across all commands.

2. Do all of the long codes (e.g. long: rawData[491] vs short: rawData[163] have the same 39 bit code at the start perhaps?

No. They do differ, but out of all the commands only two were the long ones:

	Part One	Part Two
Oscillate Bidet	0x2008006060	0x2008001010
Stop Bidet	0x2008AADA70	0x2008000000

3. Any other ideas or patterns. e.g. each hex digit is bit-flipped with the blah-blah bits.

I've got a Google Sheet with all the commands and their bits.

Two features, Water & Seat Temperatures do seem to pair their data together. Note the "Stateful Codes" section. It's clear that there's some pattern between the nibbles.

---

You may be able to hack support for the longer codes using the smaller codes too. e.g.

I can confirm the code you mentioned above, hacking the two repeating codes, does indeed work on the toilet

// Simulate sending a long message. e.g. Oscillate Bidet
irsend.sendToto(0x2008006060, kTotoBits, 2);  // Send the First half (39 bits) is sent 3 times.
irsend.sendToto(0x2008001010, kTotoBits, 2);  // Send the Second half (39 bits) is sent 3 times.
// Technically, there is no gap between the second & third send of the data in the second half of the protocol.
// The above doesn't emulate that part, but I'd guess it would work.

[crankyoldgit]

Thanks for that. It's very helpful.
I'm going to go with 24 bits per part and assume the 0x2008 (15 bits) at the start. That way we can shrink it down to 48 bits. i.e. Inside a uint64_t.

[crankyoldgit]

I've just updated the branch to reflect that and some improvements.
It's a work in progress, as it doesn't fully support decoding the long messages.

I also think the last byte of the data is an xor checksum of the two previous bytes. So we can probably shrink it further if need be.
e.g. Pressure 5 is 0x602040 & 0x60 ^ 0x20 equals 0x40.

I still need to work out the bit ordering. I think we may need to reverse it for the numbers to increase linearly.

Let me know how it goes.

[jamsinclair]

I still need to work out the bit ordering. I think we may need to reverse it for the numbers to increase linearly.

So I've updated the google sheet and added a panel with all the codes in LSB First order.

Correct me if I'm misunderstanding, but we're looking for some kind of linear pattern in a nibble? If so, I think your assumption is correct and it's likely LSB First ordering.

	Nibble (Index)	Decimal
Pressure 1	0010 (5)	2
Pressure 2	0011 (5)	3
Pressure 3	0100 (5)	4
Pressure 4	0101 (5)	5
Pressure 5	0110 (5)	6
Position 1	0101 (4)	5
Position 2	0100 (4)	4
Position 3	0011 (4)	3
Position 4	0010 (4)	2
Position 5	0001 (4)	1

*Looks like I have the nozel positions the wrong way around 😅

I also think the last byte of the data is an xor checksum of the two previous bytes. So we can probably shrink it further if need be.

Seems like that's the case for all the codes I see, looks like we could update it to a 16 bits code.

[crankyoldgit]

@jamsinclair I've updated the branch and created PR #1811
I think this does everything. i.e. LSBF and supports sending & decoding the long (48 bit) messages.
It also does the (xor) integrity check.

You'll have to recapture all of your codes again, but, I think this should be final. Touch wood (or Toilet Paper).

Let me know how it goes.

[jamsinclair]

Thanks for connecting all the pipes and unclogging the protocol into its current state. I've learnt a lot this second time around 👏 👏 👏

I can confirm that with your code in #1811:

• Can decode both 24 bit and 48 bit messages correctly ✅
• The devices responds accordingly to the sent commands for both 24 bit and 48 bit messages ✅

I believe we can close the lid on this fine issue now?

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.3 release of the library.