XML file describes configuration variables to openhab. I just fixed one description field in xml, which does not have any functional changes.
Hello @pauli_anttila,
sorry been busy with other stuff, but today I managed to do the testing.
I had those 2 devices and both of them worked so, that they created 2 items over time. I sent the signal with different distances. Maybe that was having the impact?
LIGHTING4-119125.489
LIGHTING4-119125.491
Packettype = Lighting4
subtype = PT2262
Sequence nbr = 1
Code = 1D155C decimal:1906012
S1- S24 = 0001 1101 0001 0101 0101 1100
Pulse = 491 usec
Signal level = 7 -64dBm
and
LIGHTING4-694940.417
LIGHTING4-694940.419
Packettype = Lighting4
subtype = PT2262
Sequence nbr = 0
Code = A9A9C9 decimal:11119049
S1- S24 = 1010 1001 1010 1001 1100 1001
Pulse = 419 usec
Signal level = 7 -64dBm
@Ari_Hagman, thanks for the testing. I just copied idea from the OH1 binding, where pulse is part of the unit id. If pulse can be changed, then this broach doesn’t work on OH2 as it generate a new thing for every individual device id (it doesn’t work on OH1 either). I don’t have any clue, what is the purpose of this pulse is lighting4 messages and how it should be used.
So this have impact to the pulse, but what do you mean by distance?
Thanks @pauli_anttila,
I try to do more detailed testing on next weekend to check that if the signal level actually had an impact to pulse / unit id.
Do you know any documentation that would have info about the lightning4 details? Only docs that I was able to find was rfxcom docs. There were some details about identifying id for different lightning4 devices. I will also read those more thought on next weekend.
These devices vary heavily with their pulse frequency. Mostly when they partly overlap with another device (they usually repeat their messages up to 7 times to “ensure” the message gets heard. Also it depends a lot on the ambient temperature and humidity of the room.
IMHO the pulse width should not be included into the thing ID. The device ID is the only interesting part anyways.
Yes, that would probably help with my cheap sensors, but maybe there was a reason to use the pulse in the first place? That is the question that some else needs to answer.
I have now spent few hours googling and I have not found any documentation that could help sort this out. @pauli_anttila do you have opinion about this?
Unfortunately no. That’s why I asked your help 
If pulse is somehow mandatory and varies, switch item can’t be used. One possibility is to remove pulse from device ID and use static pulse value for normal ON/OFF commands and then introduce another number channel, which could be used to send commands with different pulse values. So e.g. integer value (hex) yxxxx, where y is command (on/off) and rest are pulse value.
Hello @pauli_anttila ,
I just received a cheap PIR sensor which works via the lighting4 protocol and I can confirm that it should not include the pulse-id in the device-id.
The strange thing is that the openHAB 1 binding includes the pulse id for output but not for input. And it will not work for input because it varies in a small range. However maybe some actors who run the Lighting4 protocol might require a proper value to be able to control them.
Could we also make it asymmetric in OH2?
A detected sensor is stored without pulse and if you want to add an output you can (optionally) add the pulse.
Note in OH1 my config looks like this:
Contact cheap_motion_sensor (gMyOpenHAB, gSyncToOH2) { rfxcom="<286169:Contact", expire="4s,CLOSED" }
Switch cheap_motion_sensor_2 (gMyOpenHAB, gSyncToOH2) { rfxcom="<286169:Command", expire="4s,OFF" }
Number cheap_motion_sensor_signal_level (gMyOpenHAB, gSyncToOH2) { rfxcom="<286169:SignalLevel" }
String cheap_motion_sensor_rawData (gMyOpenHAB, gSyncToOH2) { rfxcom="<286169:RawData" }
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 
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:
- identify device (thing) with just devices id
- save the pulse as “default pulse” in thing configuration
- when receiving signal relay only the device id
- 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 
) this binding.
Sorry for intruding, but I’m curious as to the progress in being able to send Lightning4 commands? 