![[BL602] BL602 PTBLU-W WiFi Module Pinout and Specs in EARU EAKCB-EWE-M Circuit Breaker](https://obrazki.elektroda.pl/5083588700_1751735837_thumb.jpg)
I've picked up a couple Tuya IRC03's which serve as both infrared receiver and transmitter.
My intent was to send signals for a Denon Stereo so that it can be woken up and switched to the correct input from another room.
Incoming data from the remote looks like:
SUSPEND button:
ON button:
When I attempt to publish, i.e. using cmnd/IRDevice/IRSend, payload:
The device logs:
OK, so it doesn't like Kaseikyo_Denon (is there a list of protocols somewhere?), but Denon does sorta work with cmnd/IRDevice/IRSend using payload:
The transmitter shows in the log:
But the actual data received (tested via the other IRC03) comes to the receiver as:
I tried then checking this against Denon codes from the IRDB (https://github.com/probonopd/irdb) and those also seem to strip the addresses front of any address (so 0x144 just becomes 0x4).
Using NEC protocol etc is received as expected but of course doesn't work on my device:
I believe I may have tracked this done. There's this bit under driver/drv_ir.cpp
Now if args_in is being split out of the command buffer, such as from httpserver/http_fns.c, that looks to be about 128 characters (inclusive of the command itself)
So if our command is "IRSend ", that's another 120 characters or so (plus the terminator) of potential input
Now if we look at where things get cut off
IRSend Kaseikyo_Sharp 1 1 0
That's the command (6 chars), a space, then "Kaseikyo_Sharp" (14 chars) - and that leaves only about 5 characters for the rest of the args_in. Anything more is going to get chopped
Further to that, one of the vendor ID's is "Kaseikyo_Mitsubishi", which is 19 characters just by itself.
This should be fixable by increasing this
to something like
That would allow for input of a larger vendor string plus a 5-char address arg, 4-char CMD arg, and a bit more for repeats/override (bits I think is actually set in the code under the "Arduino-IRremote-mod" folder, i.e.
That said, if OBK is potentially going to allow RAW output at some time the args character-array would definitely need to be even bigger.
My intent was to send signals for a Denon Stereo so that it can be woken up and switched to the correct input from another room.
Incoming data from the remote looks like:
SUSPEND button:
Quote:Info:IR:IR IR_Kaseikyo_Denon 0x314 0x0 0 (48 bits)
ON button:
Quote:Info:IR:IR IR_Kaseikyo_Denon 0x214 0x0 0 (48 bits)
When I attempt to publish, i.e. using cmnd/IRDevice/IRSend, payload:
Kaseikyo_Denon 0x314 0x0The device logs:
Quote:Error:IR:IRSend cmnd not valid [kaseikyo_denon 0x31] not like [NEC-0-1A] or [NEC 0 1A 1].
OK, so it doesn't like Kaseikyo_Denon (is there a list of protocols somewhere?), but Denon does sorta work with cmnd/IRDevice/IRSend using payload:
denon 0x314 0x0The transmitter shows in the log:
Quote:Info:IR:IR send denon 0x314 0x0 protocol 3 addr 0x314 cmd 0x0 repeats 0 bits override 0
But the actual data received (tested via the other IRC03) comes to the receiver as:
Quote:Info:IR:IR IR_Denon 0x14 0x0 0
I tried then checking this against Denon codes from the IRDB (https://github.com/probonopd/irdb) and those also seem to strip the addresses front of any address (so 0x144 just becomes 0x4).
Using NEC protocol etc is received as expected but of course doesn't work on my device:
Quote:cmnd/IRDevice/IRSend nec 0x314 0x0
Transmitter: Info:IR:IR send nec 0x314 0x0 protocol 7 addr 0x314 cmd 0x0 repeats 0 bits override 0
Receiver: Info:IR:IR IR_NEC 0x314 0x0 0
I believe I may have tracked this done. There's this bit under driver/drv_ir.cpp
extern "C" commandResult_t IR_Send_Cmd(const void *context, const char *cmd, const char *args_in, int cmdFlags) {
int numProtocols = sizeof(ProtocolNames)/sizeof(*ProtocolNames);
if (!args_in) return CMD_RES_NOT_ENOUGH_ARGUMENTS;
char args[20];
strncpy(args, args_in, 19);
args[19] = 0;
// split arg at hyphen;
char *p = args;
while (*p && (*p != '-') && (*p != ' ')){
p++;
}
etc etcNow if args_in is being split out of the command buffer, such as from httpserver/http_fns.c, that looks to be about 128 characters (inclusive of the command itself)
char tmpA[128];
...
commandLen = http_getArg(request->url, "cmd", tmpA, sizeof(tmpA));
So if our command is "IRSend ", that's another 120 characters or so (plus the terminator) of potential input
Now if we look at where things get cut off
IRSend Kaseikyo_Sharp 1 1 0
That's the command (6 chars), a space, then "Kaseikyo_Sharp" (14 chars) - and that leaves only about 5 characters for the rest of the args_in. Anything more is going to get chopped
Further to that, one of the vendor ID's is "Kaseikyo_Mitsubishi", which is 19 characters just by itself.
This should be fixable by increasing this
char args[20];to something like
char args[40];That would allow for input of a larger vendor string plus a 5-char address arg, 4-char CMD arg, and a bit more for repeats/override (bits I think is actually set in the code under the "Arduino-IRremote-mod" folder, i.e.
#define KASEIKYO_BITS (KASEIKYO_VENDOR_ID_BITS + KASEIKYO_VENDOR_ID_PARITY_BITS + KASEIKYO_ADDRESS_BITS + KASEIKYO_COMMAND_BITS + KASEIKYO_PARITY_BITS)That said, if OBK is potentially going to allow RAW output at some time the args character-array would definitely need to be even bigger.
