No I did not solve that one.
I was thinking the same solution than you. Other one that I was thinking was creating channels for each of ācommand numbersā.
It would really nice to see the protocol spesification (at least was not able to find one), it could help identify the proper solution.
So not too much help from me for this topicā¦
No need to keep different pulse lengths. I have no problems when I test transmitting with rfxmgr on 350us for each of my sockets.
A good source would be RCSwitch, this is a library for embedded devices that also works with lighting4 switches.
Are you 100% sure, does it also work with more extreme values like 500, 50, 1000?
Because the manual suggest that 350 is default and with some fuzzy matching it could work with most devices then.
No, I was too focused on my own switches.
I think it would be a good initial approach to implement your fuzzy rounding method because I doubt we will see devices that require to receive on the exact same period as it was transmitted. These are usually cheap(er) devices which probably use cheaper timing parts which cause the inconsistent timing.
To me, it seems obvious that for discovery of these items, we just use the Device ID and ignore the pulse, and I think everyone agrees on that in this thread already.
For sending, there doesnāt seem to be much evidence for what to do. The purpose of sending is to mimic the device, so we need someone who can test that it mimics the device correctly under each of our suggested solutions. Iād like to hear from anyone who has a transmitter and receiver that reliably work together, and how reliable it is with different pulse settings. For example, can we just always set pulse to 0 in rfxmgr? Does 350 work? Does it only work if its within Ā±10 of the transmitter? @piejanssens seems to be the only data we have so far, and if 350 works consistently there, I think thatās where we start.
As a gut feeling, I donāt like the idea of rounding. If the transmitters arenāt sending a consistent value anyway, then surely the receivers canāt be using it either. If they really are accepting a rounded version, Iād like to see proof of that before writing rounding into our code, because weād just be guessing at what might work rather than understanding the problem. If we can get away with using a standard value (0, 350, whatever) rather than remembering what value is received, then we should do that, because again weād just be guessing. In the future, if we find more devices that donāt work with the simple approach, we can fix the code using the new data.
Do we use pulse anywhere else, for other lighting4 devices? Does anyone know what the purpose of the field is? What about the meaning of S1-S24?
@Jamstah thank for your response, hereby an overview of what I already found out with some references.
There is only one Lighting4 subtype at this moment and none of the other RFXCom message types support a similar concept.
I think the pulse timing is just really technical detail of this message type which was observed to vary by the creators of rfxcom, but I sent them an e-mail 
I think that is explained the best by kevin in the an issue he reported
The initial support for some of the s1/s24 commands is added in openHAB (1.x) by SpeederC:
There you can see that motion & contacts sensors send a different command with the s1-s24 bits.
These threads might also give some insight
What I saw it that my motion sensor sends a specific on command each time, but the full S1-S24 seems only to be in use by the 4-port relays. And it would only be really correct if an item discovered for the remote button is correctly retransmitted by the binding if requested.
I would really like to implement that sending of a specific command as well, but if we have a common opinion about the rest that should be easy 
And thanks to Bert@rfxcom I got the datasheet for the PT2262
http://www.princeton.com.tw/Portals/0/Product/PT2262_5.pdf
And he also stated that we can safely ignore the pulse width when receiving but we need to supply it when sending. Reading the datasheet I think it depends on the used oscillator resistor but I am just software developer
It sounds like it might be part of setting up timings, which would make sense. Hopefully that means we could get away with using a standard default value. I still think we need more some more testing to see if receiving devices are happy with us setting it to 350. Can you ask Bert if he can see any problems with always using 350? He might already have experience that could help.
Hello Pieter, if you do have time it would be great if you could do some testing just to get a hunch.
Bert thinks that sending a completely different pulse will not work, so letās wait for Pieterās tests and maybe there are some other people around who can also do some testing?
Did some tests to switch my devices on:
Thanks for the tests!
With a total range of 0 - 65.535 for the pulse this is not really certain but could be ok for now, it would be great if some other people with devices could also do some tests.
The values I found via google range between 200 & 486, so most likely it will work okay if we choose 350 as default for sending.
However the next problem is that we should send the same command as the one we received, so a similar structure as I created for storing the pulse on discovery is still useful.
Although the rfxcom manual also mentions devices with a pulse timing of 188 & 1040 
Then do
receiving < 250 = 188
250 < Receiving < 600 = 350
Receiving > 600 = 1040
My two cents in short.
When discovering an item I would try replicate that as closely as possible. So when sending an event it should fool all the listners to think that event was coming from original source.
If we have to remember and resend the pulse, then I donāt see the advantage of using ranges, it just lowers our accuracy when we can just parrot out the original. The reason for the tests is to see if we need to remember anything at all, or if we can just use one value that works with all receivers.
I also think it would be best to mimic the original pulse. Rounding is really okay, as we can see it may be way more than +/- 10 usec. But using ranges that are far off reality would only introduce problems.
I have some switchable sockets from the hardware store (typical ELRO-style sockets with red LED near corners and DIP switches) and they ignore my RFXCOM signals, if I am more than 50 usec off. Using the ranges would render them useless.
In any case, please fill the pulse length into a field so we can safely change it.
I did some commits in my own branch https://github.com/martinvw/openhab2-addons/tree/feature/rfxcom-light4-ignore-pulse-on-incomming but it still requires some more work, I might be able to work on it tonight.
A new version with support for storing pulses, onCommand and offCommands. And there is a special channel for receiving and firing specific command idās
org.openhab.binding.rfxcom-2.1.0-SNAPSHOT.jar.zip
I also created the pull-request: