SOMFY IR transmitter bizarre decodes

johnsfine · Post by **johnsfine** » Tue May 10, 2005 7:28 am

I did the test of loading the upgrade (protocol and device) into an 8910 and learning the 8 signals to a 15-1994 and decoding/examining the results.

The signals all came out as I intended, so I didn't make any mistakes in constructing the protocol or upgrade.

That still leaves the question of whether I correctly interpreted the original, especially but not limited to the question of whether all those doubled pulses were really a learning error due to a phase glitch.

My 15-1994 got perfectly consistent clean learns from my 8910. Those learned signals look VERY different from the original learns from the Somfy remote. But if I understood the protocol right, these short clean learns are the correct ones.

Capn Trips · Post by **Capn Trips** » Tue May 10, 2005 12:10 pm

The upgrade works fine. Thanks a lot!

I'll post the upgrade tomorrow (It's on my work computer (yikes!))

johnsfine · Post by **johnsfine** » Tue May 10, 2005 12:36 pm

I will fix the pid in that protocols.ini entry (I didn't mean to pick a pid that's already defined elsewhere in the file) and I've already written a notes section, and I'll commit the protocols.ini changes at sourceforge so it will be official the next time Greg releases RM.

Your "upgrade" is an RM file?
I'm not sure whether that will load correctly in RM after I change the pid (though if not, it shouldn't need much tweaking).

johnsfine · Post by **johnsfine** » Tue May 10, 2005 12:51 pm

I posted an updated protocols.ini at
{link deleted - official version released}
that you can use until it is officially released with RM.

Capn Trips · Post by **Capn Trips** » Thu May 12, 2005 1:05 am

HERE (at last) is the "final" RM upgrade.

It works BETTER than the OEM remote (I suspect the JP1 remote sends "cleaner" signals than the OEM remote).

Now I am truly down to a single remote in each of my viewing areas!

Thanks for the expert analysis and work, John. This group is really something else!

Capn Trips · Post by **Capn Trips** » Wed Jun 28, 2006 4:11 am

Resurrecting this old thread, I have recently discovered that the OEM remote, in addition to "up" and "down" also can send "stop" signals to each of the four "channels" (by pressing both the UP and DOWN buttons simultaneously!)

So I have relearned ALL of the signals (there are now 12 vs. 8) and posted the learned IR file in the diagnosis area.

The "STOP"s all decode as OBC 0 for the respective Device codes John Fine created, (UP=OBC-1, and DOWN=OBC-2) so that's consistent, and decodeIR seems to decode them properly, since the upgrade works perfectly.

The decoder does NOT, however, decode the sub-device, which still has to be manually calculated using John's notes for the protocol.

I thought that perhaps having four additional learned signals to analyse might help crack the nut on this odd protocol, but in the spirit of "if it works, don't fix it", I'm not insisting on it. It's simply academic.

Post by **The Robman** » Wed Jun 28, 2006 10:44 am

The formula that John posted earlier for the checksum still works for the 4 new buttons.

I have taken the liberty of tweeking the protocol a little bit so that it uses one byte commands.

Here is a new upgrade that should (hopefully) replicate all 12 buttons. I have assigned the buttons as follows:

CH1 up/down/stop --> 1/4/7
CH2 up/down/stop --> 2/5/8
CH3 up/down/stop --> 3/6/9
ALL up/down/stop --> VOL+, VOL-, MUTE

Upgrade Code 0 = DD 4D (Home Auto/1357) COMFY KM (KM v8.43)
A1 00 C1 0C A1 99 B5 63 5B 77 22 1A 36 8E 4D 0C
End

Upgrade protocol 0 = 01 A1 (S3C8+) PB v3.11
3F 9D 01 8B 12 85 05 05 04 01 4E 00 F0 00 9A 01
A4 04 9C 04 0C 00 DE E4 03 04 F0 04 56 03 F0 20
11 8D 01 46
End

Here's the KM and PB files...
http://www.hifi-remote.com/forums/dload ... le_id=3381

Capn Trips · Post by **Capn Trips** » Mon Jul 10, 2006 4:24 pm

Well, Rob,

I finally got around to testing this. I didn't bother sooner, since I had a working upgrade, and this effectively saves 5 bytes (Protocol upgrade is 7 bytes bigger, device upgrade is 12 bytes smaller).

Bad news - it doesn't work. Of all of the signals, the only one that worked - and inconsistently, at that, was the channel 2 up command. None of the others worked at all. So I'm sticking with the older construct, with devices and OBC required to be selected and 2-byte functions as a result.

If there's any tweaks you want to test, I'll be happy to do so. But I'm happy with the working upgrade.