One other question, what do you all see as a better option:
ignore the pulses on receiving, included them on sending
an easy solution
duplicates are likely to pop up in you inbox
this is more or less similair to openHAB 1 implementation
round the pulses (on the nearest multiple of 10) and put them in the inbox with the rounded values
an more complex solutions where
we could optionally still ignore the pulses when receiving
items which items are discovered once (on almost all occasions)
with a (fairly) small chance that sometimes you cannot directly control a device as it was put into you inbox because the rounded values mismatches the receiver when sending via the rfxcom (but this does not seem likely to me)
Hm, I introduced the rounding for the pulse on the nearest ten-fold maybe we can create a downloadedable jar for both of them and let the community choose
Because to be able to properly create the item from the inbox it should be included somehow in the identifier string, so the pulse which will be variable creates different inbox items for the different pulses which are received.
I now see that I might be wrong on this one, besides the id also some additional fields are populated.
Iām interested in your change, you can also share your code with me via a diff or just a complete zip file.
I just came up with an idea which makes the complete discovery more flexible, I might be able to work on it tonight. I just let the message it self populate the discovery result, so if a message wants to store a pulse it should do so
@Jamstah & @pauli_anttila if you do have the time I would really appreciate it if you could given your opinions about the technical side of both implementation which I created:
rounding the pulse-length for incoming messages and use the rounded and stored value when sending and receiving.
~Actual rounding happens around line 166 in RFXComLighting4Message.java the rest is mainly to bring it in line with the code of OH 1.X~
ignore the pulse when receiving but store it as a separate field to use when sending, I added a generic way which also allows other messages to do there own āmagicā on the configuration and discovery result.
Fair point, should we add an on-command and off-command just like the pulse, the only other option I see is defining some kind of sub-sub-type but then we should know which on and off command belong together.
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.
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?
