Holmes Remote Control Fan

StealthAngel · Post by **StealthAngel** » Wed Jun 16, 2004 9:45 pm

Hey guys,

Upon Robmans suggestion, I picked up an URC-8811 to do learning with. I own a Holmes Remote Control Fan, so I'd like to create an upgrade to use with my 6131m remote. I've used the learning abilites to copy the 5 commands from the Holmes remote. Those commands are Osc, Speed, Mode, Time, and Off. I've then taken the information and downloaded it using IR. Then punched the OBC info, etc.. into KM to try and create an upgrade. But so far I've been unsuccessful.

Here is the IR info about the learned keys:

Code: Select all

LEARNED SIGNALS:
#	Bound Device	Bound Key	Protocol	     Device  OBC  Hex Cmd	       EFC                HOLMES KEY
1	TV	          Left        Old Panasonic	25		48	0F or 0D or 0E	058 or 042 or 066  Osc
2	TV	          Up          Old Panasonic	31		63	FF or FD or FE	181 or 165 or 189  Speed	
3	TV	          Right	    Old Panasonic	25		36	27 or 25 or 26	251 or 235 or 003  Timer	
4	TV	          Down        Old Panasonic	25		20	2B or 29 or 2A	091 or 075 or 099  Mode	
5	TV	          Select	   Old Panasonic	31		63	FF or FD or FE	181 or 165 or 189  Off

One of my problems, I believe, is that the keys use two different device codes. Should I create two different KM's (devices), one for each device number? Also the OBC is the same for the Select Key and Left key, which has me worried.

The upgrade information I get from KM is as follows (which is incorrect and doesnt seem to work

Code: Select all

Upgrade Code 0 = 17 DC (TV/2012) Holmes Remote Control Fan (KM v8.23)
 00 00 00 3E 85 80 80 80 FF FF 0F 0F 2B FC 24   
End

Incase anyone is wondering, I've tested each key that was learned and they work excellent, but if i create an upgrade with them and upload that into the remote, the keys flash the LED but nothing happens with the fan.

Any help, tips, pointers, corrections, or tidbits are welcomed with open arms.

Thanks everyone,
StealthAngel

johnsfine · Post by **johnsfine** » Thu Jun 17, 2004 4:11 am

The Panasonic_Old protocol allows three different device numbers per upgrade, so it should be possible in KM (and a little more obvious in RM) to create an upgrade for those decodes. The multi device feature of that protocol in KM isn't used much and I think at some point the instructions were wrong for specifying (on the functions sheet) which of the device numbers (from the setup sheet) to use for each function. If those are still wrong, that might explain the problem.

But those two 31:63 decodes aren't plausible. That makes me suspect that all the decodes might be wrong.

You should save the eeprom image file containing those learned signals and upload to the yahoo jp1 diagnosis folder and post the url back here. Then one of the experts here can check if the decodes were correct.

StealthAngel · Post by **StealthAngel** » Thu Jun 17, 2004 6:44 am

I'll relearn the keys tonight and upload the IR file, thanks for the help. Does it have any effect on KM or IR which keys you learn to?

johnsfine · Post by **johnsfine** » Thu Jun 17, 2004 7:44 am

I took a more careful look at the upgrade you posted. Even if the decodes are right, the upgrade is mostly wrong.

I tried entering data in KM to see what mistakes would be required to duplicate those results. I couldn't quite get there, but in testing that I'm fairly sure KM's support of the byte2 column in the functions sheet is still wrong (for Panasonic old protocol).

I tried RM and I think that handles it correctly.

Your main error (if the decodes are right) was that you entered just the 31 device number in KM's setup sheet. You should enter both device numbers (into two of the three device fields).

For a mini-combo protocol like this, it is usually best to switch the functions sheet to OBC mode and enter the decoded OBC in its column and use the byte2 column to select one of the three device numbers.

But since KM seems to mess up byte2 handling for Panasonic old, it is better to stay in EFC mode and select one of the three EFC values from the decode for each function. If you put the device number of that function in the device1 field you must select the first of the three EFCs. If you put it in the Device2 field you must select the second of the three EFCs, etc.

In RM it is cleaner to enter OBC values and select the actual device number from the pull down. You can also enter EFC numbers and it will show you the OBC and device selected by that EFC.

johnsfine · Post by **johnsfine** » Thu Jun 17, 2004 7:48 am

StealthAngel wrote:Does it have any effect on KM or IR which keys you learn to?

If I understand your question, the answer is NO.

The decode displayed by IR (protocol, device and OBC) depends just on the signal learned, not on which key you learned it to.

When you enter that decode info to KM you can assign it to whatever key you prefer. There is no connection to the key originally learned onto.

Post by **The Robman** » Thu Jun 17, 2004 10:38 am

I was able to re-create StealthAngel's upgrade, here is the KM file: Holmes_Remote_Control_Fan_BAD.txt. I also created a good KM file for this here: Holmes_Remote_Control_Fan_GOOD.txt

John is correct that there is a bug in KM's handling of the byte2 field, to select device #1 you enter 0 (which is correct) but to select device #2 you need to enter 2 and to select device #3 you enter 1. Ie...

0 = device 1
2 = device 2
1 = device 3

johnsfine · Post by **johnsfine** » Thu Jun 17, 2004 11:04 am

Rob, Did you test that upgrade (learn one remote to another)?

I didn't, so I might be misremembering the command encoding.

But I think the current behavior in KM is:

0 or blank = strange
1 = device 2
2 = device 3
3 = device 1

Since you have no device 3, the places where you put 2 will give you device 2 as intended. But the places you left blank shouldn't work.

Post by **The Robman** » Thu Jun 17, 2004 11:50 am

No I didn't (I'm at work). What I did was look at the source code for the executor itself and it uses the 2 rightmost bits to select the offset from R03 (ie, the first fixed byte) in much the same fashion as the RC-5 executor. So if those bits equate to 0, you should end up using R03, if they equate to 1 you should end up using R04, etc.

Obviously, these bits should be in MSB format, whereas the signal itself is LSB format, which is where KM gets mixed up, hence, entering 1 yields "10" rather than "01" and entering 2 yields "01" rather than "10". Entering 0 (and 3) yield the correct results (but of course, 3 isn't a valid value in this case).

StealthAngel · Post by **StealthAngel** » Fri Jun 18, 2004 1:59 pm

Well so far nothing has worked. I tired Robman's Good KM file and I relearned the keys from the fan's remote 2 times to make sure they were the same. Using this information I created a new KM using Johnsfine suggestions, which didnt work either

Here is the IR file with the learned keys. They are in the same position as before. The filename is Holmes Remote Control Fan.IR in the diagnosis Area.

Thanks for the efforts guys.

StealthAngel

johnsfine · Post by **johnsfine** » Mon Jun 21, 2004 2:16 pm

I finally looked at those learned signals. Sorry it took so long.

I should have asked earlier about "Old Panasonic", since the current decoder calls that "Panasonic_Old". These signals are not Panasonic_Old nor anything close enough to that to fool the decoder.

The decodes are comming from the old decoder built into IR. I'll check whether IR still lets DecodeIR disable parts of the old decoder, in which case it certainly should be disabling this part.

I'm a little surprised even the old decoder makes that big a mistake. But I don't intend to try to debug that, since it shouldn't be enabled any more.

The actual protocol looks simple enough. It should be easy to recreate in PB. I don't recognise it, but I'll try to minimally check to see if it's already available before I try to recreate it in PB.

johnsfine · Post by **johnsfine** » Mon Jun 21, 2004 2:46 pm

I wish the search in this forum worked on quoted strings of strange text, because I know we've discussed "1,-3|3,-1" bit patterns before and I wanted to check this one against earlier ones. But I can't find any way to search for things other than words.

I think this protocol is roughly:
{38K,634}<1,-3|3-1>(D:8,F:8,F:8,-21m)+

The fact that the F is repeated rather than having an inverse check byte is quite unusual, so maybe I've never seen this before and wouldn't have benefitted from the search working.

I think PB can handle that unusual check byte. I'll try that later.

johnsfine · Post by **johnsfine** » Tue Jun 22, 2004 6:13 am

I built that protocol in PB and then wrote a protocols.ini entry so an upgrade can be built in RM.

If you want to try it, edit the Protocols.ini file and add the following block (at the end of the file or anywhere between other blocks, but not within another block).

Code: Select all

[Holmes]
PID=01 7F
DevParms=Device=204
DeviceTranslator=Translator(lsb)
FixedData=00
CmdParms=OBC=0
CmdTranslator=Translator(lsb)
Code.S3C80=43 8C 11 8B 0E 8D 01 08 08 03 B7 01 29 01 3D 03 \
           A3 29 04 20 11 E4 04 05 8D 01 46

Then use RemoteMaster to create an upgrade. The default device is 204, because that is the value in those learned signals. The OBCs from your 6 learned signals were 163, 92, 70, 75, and 26.

If you test it and report back, or if I have time to test by learning from remote to remote, I'll post the PB file and other materials so future users of that fan will have it.

Post by **The Robman** » Tue Jun 22, 2004 8:02 am

Just FYI, $017F is the substitute PID that we use for one of the $007E Pioneer variants, so when you make this official you should pick another PID.

johnsfine · Post by **johnsfine** » Tue Jun 22, 2004 8:34 am

I assume we don't have any good list of which PIDs are taken. I just picked a number semi randomly and then checked protocols.ini for conflicts.

Clearly there aren't enough numbers available to be globally unique with all the protocols we've invented. I understand you're trying to keep the "official" ones (those supported by KM or RM) unique from each other. But even that would run out pretty soon.

I really think the job of keeping PIDs unique should be pushed into IR, where you only need to worry about the upgrades actually present in one remote at one time.

StealthAngel · Post by **StealthAngel** » Tue Jun 22, 2004 7:06 pm

Johnsfine,

Thanks! It worked like a charm, you are truly an expert in your on right! Well thats another remote off the table.

Last but not least on my list of remotes is a Pioneer Mini-Stereo. I tired to teach a few of the commands to my learning remote last weekend. Some of them worked just fine, others were totally ignored. (Never got the confirmation flashes on remote, nor did the key work) Do yo guys have any tips for handling situations like these?

Thanks again john, and everyone for the assistance. I'm hooked on JP1 from here on out!