I’ve bought the same PIR Sensors and they work very good and last long.
The solution to your problem is very simple. You need to set the Data Jumpers inside your PIR accordingly, so that they do not send a command which is UNKNOWN to rfxcom, but to ON. This will switch a Switch item to ON. (I believe, it would also CLOSE a contact, if used, but I only use switches).
Switch D1 to LOW: Remove all the jumpers from D0-D3 and place one Jumper to the left and middle row, in the D1 column. Just have a look at my picture and it will be clear.
This will cause to set the Switch to ON in OpenHAB. The good thing is: You can make yourself a rule to start a Timer to switch it off again after a few minutes. Presence-detection done.
If you need sophisticated examples using OpenHABs Timer Implementation, I’d be happy to provide them to you (all), if wanted.
I allready installed the development environment, but setting all up was bit to much for time I have available now. Maybe some future weekend I will do this.
I am indeed from Finland so went to Clas Ohlson to buy this. It works and and fullfills my needs. Thanks for the tip.
It looks like you have the ev1527 learning code type. (simple comparison)
I never used those, it’s way harder because you can’t just configure them, but you have way more different codes to “choose” ( or better “learn”) from.
Have a search for ev1527 and openhab or rfxcom. I’m sure that some people use them as well. Good luck!
I installed development environment and copied the behaviour from rfxcom RFXComLighting4Message 1.0 to 2.0. Now PIR and Smoke detector sensor works in my dev machine.
@pauli_anttila so basically I just coped the encodeMessage and decodeMessage from 1.0 to 2.0. Is this feasible solution?
If this was a feasible solution, just wondering what should should be my next steps.
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?
@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?
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?
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.
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.
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.
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.
