RIKA firmware 2.28 – USB CDC handshake stops at 0x33 when emulating FireNet 2.0 with ESP32-S3
Hi everyone,
I am currently trying to replace the original RIKA FireNet 2.0 USB-WiFi stick with an ESP32-S3 using its native USB CDC interface.
The ESP32-S3 is programmed with Arduino and is configured to emulate the USB device as closely as possible:
- VID:
0x303A
- PID:
0x819A
- USB product name:
RIKA FireNet 2.0 USB-WiFi Stick
- Native USB CDC / TinyUSB
- WiFi, web server and mDNS are running on the ESP32 at the same time
I am using the Open-FireNet project and its documented protocol as the starting point:
openfirenet/open-firenet on GitHub
My RIKA stove is running firmware 2.28.
What works
The USB connection itself works.
The RIKA sends:
0x16
The ESP32 responds with the exact Open-FireNet version string:
GET_CDCDEVICE3_VERSION=0; BL=999; APP=201; REV=12201; DT=3;\n
The ESP32 confirms that all 60 bytes are successfully written to the USB CDC endpoint.
For example:
RX 0x16
*** 0x16 DETECTED ***
*** WAITING 50 ms ***
*** SENDING GET_CDCDEVICE3_VERSION ***
TX: GET_CDCDEVICE3_VERSION=0; BL=999; APP=201; REV=12201; DT=3;
USB TX RESULT=60/60 bytes
*** VERSION RESPONSE COMPLETE ***
So the basic USB CDC communication is definitely working.
The problem
Immediately after the version response, the RIKA sends:
0x33
ASCII '3'.
Then, about 16–17 ms later, it sends another:
0x16
The ESP32 again sends the version string, and the same sequence repeats indefinitely.
A typical sequence is:
RIKA ESP32-S3
| |
|-------- 0x16 ---------->|
| |
|<------- VERSION --------|
| |
|-------- 0x33 ---------->|
| |
| ~16 ms |
| |
|-------- 0x16 ---------->|
| |
|<------- VERSION --------|
| |
|-------- 0x33 ---------->|
| |
| ...
The timing is surprisingly consistent:
0x16 → version response: ~50 ms intentional delay
version → 0x33: ~76–77 ms
0x33 → next 0x16: ~16–17 ms
This repeats continuously.
The expected:
GET_CDCDEVICE_VERSION_FINISHED
is never received.
Things I have already tested
1. No response from the ESP32
I first tested what happens if the ESP32 does not respond to the RIKA at all.
The RIKA still sends:
0x16
0x33
So 0x33 is not caused by an ESP32 response.
2. Different response timing
I also tried changing the point at which the version response is sent, including waiting for the 0x16 / 0x33 sequence.
No change.
3. Echoing / responding to 0x33
I tried different responses to 0x33, including echoing it.
This did not advance the handshake.
4. Binary data capture
At one point I observed a sequence beginning with:
02 30 02 02 02 02 ...
and eventually ending with:
03
I therefore added a binary frame capture to the ESP32 firmware.
However, with the reproducible 0x16 → VERSION → 0x33 → 0x16 loop, this binary sequence does not appear consistently.
So I do not want to assume yet that 0x02 ... 0x03 is actually a protocol frame.
5. ACK 0x06
I am currently testing the hypothesis that 0x33 might require an ACK (0x06).
However, my first implementation of that test accidentally changed the working USB initialization, so that test is not considered valid yet. I will repeat it using the exact same USB code as the working implementation and only add:
0x33 → 0x06
An interesting firmware-version clue
There are reports from the Open-FireNet / Home Assistant community of very similar handshake problems with RIKA firmware versions around 2.25 / 2.27.
Interestingly, other users have reported successful communication with RIKA devices running firmware 2.29.
This makes me wonder whether there was a protocol or initialization change somewhere between these firmware versions.
My device is specifically running 2.28, so I am very interested in any information about changes introduced in this firmware generation.
Community discussion:
Open-FireNet USB CDC Gateway discussion on Home Assistant Community
What I am trying to understand
At this point I am mainly looking for information about what the RIKA firmware expects after:
GET_CDCDEVICE3_VERSION
Specifically:
- What exactly does
0x33 mean in the RIKA USB protocol?
- Is
0x33 an ACK/request/status byte, or something else?
- Is there an additional response expected from the FireNet stick?
- Does firmware 2.28 use a different initialization sequence than older Open-FireNet implementations?
- Are there known protocol differences between RIKA firmware 2.27, 2.28 and 2.29?
- Does the FireNet 2.0 protocol use
GET_FIRENET_STATUS instead of the older GET_CDCDEVICE_STATUS sequence on these firmware versions?
- Could the missing part be at the USB CDC control level rather than the CDC data endpoint?
In particular, I am wondering whether we are missing something such as:
- DTR / RTS state
SET_CONTROL_LINE_STATE- CDC line coding
- USB control requests
- endpoint state
- a firmware-specific initialization command
rather than simply missing another ASCII response.
Current ESP32 implementation
The ESP32 is using native USB CDC/TinyUSB, with the actual transmission performed using:
tud_cdc_n_write_available(0);
tud_cdc_n_write(0, ...);
tud_cdc_n_write_flush(0);
The version response is exactly 60 bytes and the USB write reports:
60/60 bytes
The ESP32 also runs a normal WiFi connection, web server and mDNS service, so the USB implementation needs to coexist with those functions.
Why I am posting here
I have reached the point where simply trying different responses to 0x33 does not seem like the best approach anymore.
The behavior is extremely deterministic, which makes me suspect that there is a specific protocol or USB-state transition missing.
If anyone has:
- a RIKA firmware 2.28 device,
- a working FireNet 2.0 implementation,
- USB captures from an original RIKA FireNet stick,
- information about firmware 2.28 protocol changes,
- or experience with the 2.27 → 2.28 → 2.29 transition,
I would really appreciate any pointers.
Even a raw USB capture of the original FireNet stick during the initial handshake would be extremely helpful.
Thanks!
