RFXCOM Cheap PIR Sensor Binding in Openhab2

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)

Hello,

I can try PR (would be my first one) on Sunday when I’m back at home.

Solution that I have is having some not so nice features tough. Like introducing new method to base message class.

–Ari

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 :slight_smile:

I at least don’t see any duplicates coming in a solution one. Device ID is the only one used to identify things. And id is not changing.

Why do you think there will be duplicates?

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 :slight_smile:

https://github.com/martinvw/openhab2-addons/commit/b0932be0925f3151f09ef8c4484ef4afb1a0419f

Sure, I’m back at home on Sunday.

With your speed you might already have working solution by then. :slight_smile:

@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:

  1. rounding the pulse-length for incoming messages and use the rounded and stored value when sending and receiving.

https://github.com/openhab/openhab2-addons/compare/master...martinvw:feature/rfxcom-lighting4-fixes

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

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

https://github.com/openhab/openhab2-addons/compare/master...martinvw:feature/rfxcom-light4-ignore-pulse-on-incomming

Thanks for your time.

PS: other people’s opinions are of course welcome to!

Hello,

your ignore pulse solution was in high level pretty much what i had also.

One question about the command:

If my device sends ON_3 should we also send ON_3 not ON_1?

Anyway, I’m happy with your solution because I’m not sending any command just receiving and this will enable me to use my sensors.

Thanks

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.

Did you already resolve this in your idea?

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 :slight_smile:

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 :wink:

1 Like

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?