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 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.
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.