RM3 Mini D Code Sending Header Incorrect
See original GitHub issueHi there,
Looks like Device.code_sending_header is incorrect for RM3 Mini D 5f36. By default, the device is discovered but does not respond to learn or IR send commands. Previously, the modification here worked before today’s release, but I’m assuming that wasn’t supposed to happen since this isn’t an RM4 or RM4+ device, it’s RM3. So, the following change restores functionality for me in the new release:
this.code_sending_header = this.rm4Type ? new Buffer([0xda, 0x00]) : new Buffer([0xd0, 0x00]);
That’s probably incorrect for other tested devices, but in the case of RM3 Mini D it works starting the buffer with [0xd0, 0x00]. I have no other Broadlink devices to test with, but I’d be happy to make a PR for a conditional exception for this specific device (better than my band-aid above) if you think it’s a one-off for this model.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
Thanks for testing so quickly. I’ll push a new release now - it sounds like it could help a few people in https://github.com/lprhodes/homebridge-broadlink-rm/issues/551.
Yes, that works out of the box now. Ran
npm i kiwicam-broadlinkjs-rm@0.9.6-beta.0
, and I verified this overwrote my change with yours.Very odd exception, but maybe it’ll come up in newer firmware for RM3 devices? I ordered mine end of November from Amazon, found that other thread doing research as to why I couldn’t get it talking. Seems like an odd thing for them to just change.
If it helps to pin anything down here’s the device’s model info:
Thanks for looking into this so quick!