RFXCOM Cheap PIR Sensor Binding in Openhab2

Or it might be a suggestion to do some rounding, because the pulse might identify the protocol used by the devices but there is some variance in it. In the above sample I see a variance of 2.

With a larger subset of my log I see a range of 389 to 394, we could round the value to 390.

I don’t think rounding would be appropiate. Because the Device ID already uniquely identifies the device.

But do you know for sure that we don’t need it for sending either.

At this moment the device-id and command are the only properties used for input. For output also the PacketType and SubType are given.

In the OH1 binding the pulse is only required for output. But that does conflict with auto discovery and I think that Things in OH2 are used for both input and output.

Hereby a wiki example for the OH1 binding.

Switch swWallController { rfxcom="<1285:Command" } // receive wireless wall switch
Switch pCoffeeMachine { rfxcom=">1285.315:LIGHTING4.PT2262:Command" } // control wireless outlet

I do think that the following could work:

  • rounding it (to group for auto-discovery)
  • Ignoring it when receiving a message
  • Using the rounded value when sending a message

Sweet, that’s the example I wrote for the wiki :slight_smile:

I now understand your idea about the auto-discovery and that it should for sure ‘save’ the pulse length to be able to send data as well.

In this case I agree with your thoughts:

with a little addition that the rounding value should be configurable in terms of defining the pulse width steps (e.g. 5 for pulses of …, 315, 320, 325, 330, …) and disabling it using a checkbox or setting pulse width steps to <= 1 .

Hello,

just wonder do we really have a situation that we have 2 different devices with same device id?

If not how about following solution:

  1. identify device (thing) with just devices id
  2. save the pulse as “default pulse” in thing configuration
  3. when receiving signal relay only the device id
  4. when sending use device id and the default pulse from configuration

But as far as I know the rfxcom things do not have something other type, subtype and device id or can we store anything there?

What is the status of this?

I am getting the following:

[DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Message received: Raw data = 091300E1D8AD59018F70, Packet type = LIGHTING4, Seq number = 225, Sub type = PT2262, Device Id = 14200069, Command = UNKNOWN, Pulse = 399 [DEBUG] [binding.rfxcom.handler.RFXComHandler] - Received message from bridge: rfxcom:bridge:rfxtrx433E message: Raw data = 091300E1D8AD59018F70, Packet type = LIGHTING4, Seq number = 225, Sub type = PT2262, Device Id = 14200069, Command = UNKNOWN, Pulse = 399 [ERROR] [binding.rfxcom.handler.RFXComHandler] - Error occurred during message receiving: Can't convert value UNKNOWN to COMMAND SwitchItem

Can I somehow create a device with that Raw Data ( it always stays the same).

thanks
Daniel

I had some time install the dev environment and play around with code.

In my code RFXComMessage are able to store a default pulse level to the configuration. And In discovery RFXComLighting4Message this value is stored to the thing. See bellow:

So the default pulse is used only when sending the message, but pulse level is not affecting when receiving a message.

That looks good to me, @pauli_anttila does this solution fit into your ideas about how the binding should work and develop?

If pulse length can be constant, yes, this is how it should be done . For me that has been always unclear, as I don’t own any Lightning4 devices and RFXCOM spec doesn’t say anything about it.

I have an extra Lightning4 fire alarm and motion sensor, I can give those for you as a gift for building (fixing :slight_smile: ) this binding.

Sorry for intruding, but I’m curious as to the progress in being able to send Lightning4 commands? :blush:

Sending works fine, as long as you have the original remote and use your rfxcom to fund the device id and pulse length by yourself.

Whaaat? :grin:
I do have original remote(s), and I have lots of items automatically created when I push the different buttons, but I can’t seem to figure out how to transmit using these items. Where do I find a ‘step-by-step’?

@Ari_Hagman Will you create a pull request based on these changes or was if for you just a proof of concept?

@pauli_anttila did you have any pending code changes for this, otherwise I should be able to make some time to work on this somewhere in the upcoming week.

@all please supply me with some debug data so I can properly create some unit tests the new changes, I have a motion sensor only so nothing to send data too.

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.