Home Automation Adventures: Artika Austin Fan in OpenHAB
Costco was practically giving away these ceiling fan + light combos. The problem is that they’re a complete PITA to control programmatically. They use a 433MHz remote. Fortunately, there is a way, it’s just not easy.
There are a few devices that allow you to capture and transmit 433MHz signals of the appropriate type. The one I went with was the RFXCOM RFX433EMC. It’s not sold in the US due to not having FCC approval, but you can import one yourself.
Initial Attempt
Spoilers: The procedure here might not work for you – keep reading to see why.
In OpenHAB, first set up the dongle by attaching it via USB. It presents as a USB serial port. I added some udev rules to give it a consistent device name, since I also have the Nortek dongle which presents as two USB serial ports, but that’s not important if you’re only using this device.
First, add an “RFXCom USB Transceiver” thing. Enter the correct serial port, select 433.92MHz as the transceiver type, and enable “Lighting4 messages”. I also cranked the transmit power up to the max, as I figured I could lower it once I got it working.
Then, press a button on the remote. Go back to the Things menu, and open the “Inbox”. You should see an RF device show up. Add this as a new thing, then add an item linked to the “Command ID” channel.
Now, press the button again, and make note of the value that gets captured by the Command ID channel.
Open up a script scratchpad, and try sending commands to the channel. For groovy scripting, use this syntax. Replace the item ID with the ID you chose, and replace the value 5 with the command ID you picked up. Run the script, and it should emulate whatever button press you used.
println itemRegistry.getItem("Fan_Remote_Command_ID").send(new org.openhab.core.library.types.DecimalType(5))The problem is – this didn’t seem to work. I did a lot of troubleshooting, but it was all dead-ends. I really couldn’t understand why it wasn’t working. So I did what any reasonable person would do – got mad, and spammed the “Run Now” button. To my surprise – it eventually worked, leading me to believe that it was a signal strength issue. Sure enough, the included remote didn’t work reliably from the next room, where my OpenHAB box is. I guess the fan’s reception is just terrible. I tried a few different antennae, but no dice. I confirmed this by instead sending the commands with rfxmngr with the dongle instead attached to my PC, in the same room.
It’s not immediately evident how to translate what you captured in OpenHAB to inpouts in the rfxmngr software, but it’s fairly simple. Open the “Lighting4” tab, and you’ll see 24 checkboxes. Your “Device ID” (found as part of the Thing in OH) is the upper 20 bits, and the Command ID is the lower 4. For example, the light on/off button is device ID 108624 and command ID 5. 108624 is 0001 1010 1000 0101 0000, and 5 is 0101, so enter 0001 1010 1000 0101 0000 0101 by checking boxes corresponding to the ones. Click the “Transmit” button, and the fan light should turn on or off, accompanied with a beep.
Using the WiFi RFXCOM Firmware
To solve the signal problem, flash the WiFi firmware onto the RFXCOM module, and instead use the “RFXCOM USB Transceiver over TCP/IP” binding. You can find the necessary firmware download on the RFXCOM website, under the name “RFX-433 software zip file”. However, you also need ESP programming software. You can consult the manual (in the zip you downloaded) for options on how to do this, on page 8. I am using the “RFX433WiFi_RFXEMC” folder, and followed the instructions to enter the correct offsets on the esptool.spacehuhn.com website (requires a browser with serial port support).
After flashing, you need to connect to the WiFi network called “RFXCOM WiFi Manager”, password 12345678, open 192.168.4.1 in your browser, and then enter WiFi credentials for it to connect to. It does not appear to support DHCP, so you need to manually enter an IP and subnet mask for it to use. Also keep in mind that the device does not support any sort of authentication whatsoever, so consider making an isolated SSID for it to use.
Now, confirm it works by connecting rfxmngr to the device’s IP (if you put it on an isolated SSID, remember to open whatever necessary firewall rules so that it is reachable). After confirming, go back into OpenHAB, and add the RFXCOM USB Transceiver over TCP/IP binding. If you had already created any sub-Things, you do not need to delete and recreate them – you can change their parent bridge from within their settings.
Getting It All Working
As for the actual settings, you should use a pulse length of about 375 (I found that values between 350 and 395 seemed to work reliably, so I went in the middle). Do not use the auto-detected pulse length of 400+. You will need three Things in total, with different device IDs. Here’s the mapping that I found, though yours will likely have different device IDs in order to be able to differentiate between multiple remotes.
| Device ID | Command ID | Action |
| 108624 | 5 | Light On/Off |
| 108624 | 8 | Beeper On/Off |
| 108625 | 6 | 1H Timer |
| 108625 | 8 | CCT Cool |
| 108625 | 9 | Dimmer Up |
| 108625 | 10 | Fan Speed Medium |
| 108625 | 11 | Fan Reverse |
| 108627 | 0 | Fan On/Off |
| 108627 | 2 | Fan Speed High |
| 108627 | 3 | Fan Speed Low |
| 108627 | 5 | Dimmer Down |
| 108627 | 6 | 4H Timer |
| 108627 | 7 | CCT Warm |
In addition, I brute forced every command ID in rfxmngr, and didn’t find any hidden commands. I thought the beeper on/off was a secret, but the manual mentions that you can press both timer buttons simultaneously to achieve this. I certainly recommend leaving the beeper on while getting it set up, since it makes troubleshooting a lot easier.
Once you have your three Things set up, create an Item linked to the “Command ID” channel for each one. Then, you can make a rule that sends the necessary value to that Item:
Try running the rule. You should hear a beep. To automate this, just add a “When” to the rule, such as when you press a light switch.
Unfortunately, the biggest weakness of this fan is that the remote has several buttons that toggle something, rather than explicitly setting it on or off (lights on/off, fan on/off, forward/reverse). This means that it’s impossible to reliably track the state of the fan in OpenHAB, since even a single missed message will result in losing synchronization with the actual state of the fan. Same with CCT – you can’t pick an absolute value, only an incremental adjustment. The closest you can get is to just slam it all the way warm/cold by spamming the command, and then try to adjust from there.