Hi John,

Would it be possible to build the LAN support into the existing binding? Then you/we won’t have to maintain two sets of device definitions/classes.


Hi and short term no, long-term yes. Focus for me is to figure out how OH2 works, how bindings work, how to use eclipse (and not Visual Studio), java etc etc. Focus is not “clean” code for incorporating into RFXCOM.


I understand - although I would imagine 75% of the code is usable, so it might well save you time in the long run. I just don’t think having two separate bindings for effectively the same device/protocol is a great way to go. But then you are doing all the work so it is up to you! :wink:


OH1’s existing binding for X10 security appears use the high/low part of byte 8 for battery and signal:

batteryLevel = (byte) ((data[8] & 0xF0) >> 4);
signalLevel = (byte) (data[8] & 0x0F);

If the DomotiGa code is accurate, https://raw.githubusercontent.com/DomotiGa/DomotiGa/master/DomotiGaServer3/.src/CRFXComRX.class it looks like the RFXLAN protocol uses byte 3 in its “MODEB32” protocol to encode three pieces of information: State, Battery and Tamper:

Case &H1
sValue = "Open"
bLowBatt = True
Case &H40
sValue = "Open"
sValue2 = "Tamper"
Case &HC0
sValue = "Closed"
sValue2 = "Tamper"
Case &H84
sValue = “Closed”

Using my concept java code that connects to the RFXLAN device and processes X10 Security packets (ModeB32 on the RFXLAN is protocol ID 0x29 and is the first of the 7 bytes). From the rfxcom binding, if battery info is in byte position 8, its two bytes longer, and in a different position to the RFXLAN, which uses position 3.

Starting ProcessMessage thread
Waiting for data from RFXLAN…
Connection to rfxcom01:10001 created
Recieved data from RFXLAN. Added to message queue
Waiting for message from RFXLAN device
Recieved data. Process ‘packet’ of information from RFXLAN
Mode: MODEB32 Packet recieved: 8b 84 40 bf f2 80
X10Security: From [8b84f2]S / 8b84, State: Open, Batt: ‘’, Tamper: 'Tamper’
Recieved data. Process ‘packet’ of information from RFXLAN
Mode: MODEB32 Packet recieved: 8b 84 c0 3f f2 80
X10Security: From [8b84f2]S / 8b84, State: Closed, Batt: ‘’, Tamper: ‘Tamper’

What have I done wrong as you say the rfxcom and rfxlan is the same device/protocol?

If I am correct, and its a different protocol, how would this best be integrated into the existing rfxcom binding? A pre-processing function that converts the rfxlan protocol into the new rfxcom protocol?

As my concept code is correctly decoding the X10 messages, I’m at a crossroad; create new binding rfxlan, or find a “clean” way to add a very different protocol to the rfxcom binding.

Anyone else with info on the two devices/protocols, please do share!


I have a rfxlan myself. The one I have is loaded with the xPL firmware, due to my at the time HA solution. There is an xPL binding for openhab, which I’m now using with my RFXLAN.

Perhaps a solution for you would be to flash the RFXLAN with the xPL firmware, and do the same?

Hi and I would have done, but the original RFXLAN does not support the xPL firmware.

My rfxlan plugin has been running for about two weeks now, currently supports Oregon temp sensor and X10 sensors.


Been a little busy, but finally got around to adding support for sending commands as well as resuming if TCP connections die (WiFi can be a little unstable). That’s the good news. The bad news is that it looks like EPL and GPL licenses are not compatible. As all the RFXLAN specific code came from DomotiGa (GPL), as Bert @ RFXCom refused to provide any documentation, binding can’t be released. Best I can do is provide the individual files if requested and let ppl compile it.

Anyway, dont think there’s much demand for this binding as the RFXLAN I have is pretty old… If I’m wrong and EPL and GPL are compatible, drop me a line and I’ll make what I have available.


Hi Fredrik,

I use the xPL binding but can´t get any dimming device to work. Use “Nexa” dimmers.

Really hope that you maby have a tip.


In my experience, not all nexa-dimmers support dimming to a specific dim level, unfortunately. My older plugin modules does work. None of my newer plugin-modules, nor any of my build-in ones, can be set to a specific dimming level. If possible, first check that they actually can be dimmed using the rfxcom-usb binding or telldus.

Now, if they indeed are able to take a discrete dim level, it is still not straight forward to get them working with a dimmer item in openhab. The dimmer item gives a value between 0 and 100, whereas rfx-xpl expects a value between 0-15, or OFF. I have only one dimmer I need to control with xpl, so I’ve created a rule to do this. I use a dimmer-object that is visible in the gui, and is not bound to any physical item, and a “dimmer-support” string item that are bound to xpl. When changing the dimmer, the rule will trigger, and send the xpl command.

My items:

Dimmer bedroom_bedside_fred 	"Bedroom Bedside Lamp (Fred)" 	(Bedroom,Lights,bedroomLights) 
String bedroom_bedside_fred_support_switch "Bedroom Bedside Lamp (Fred) Support only not visible in GUI" {xpl="*,command,ac.basic,address=0x0003456,unit=1,command=#COMMAND"}

My rule:

rule "When changed fred bedside dimmer"

	Item bedroom_bedside_fred changed
	if(bedroom_bedside_fred.state == 0) {
		sendCommand(bedroom_bedside_fred_support_switch, OFF)
	} else {
		if(bedroom_bedside_fred.state instanceof DecimalType) {
			var switch_dimlevel = bedroom_bedside_fred.state as DecimalType 
			var xpl_dimlevel = (switch_dimlevel / 6.25)
			if( xpl_dimlevel.intValue == 16 ) {
				xpl_dimlevel = 15.0bd
			var command = "" + xpl_dimlevel.intValue
			sendCommand(bedroom_bedside_fred_support_dimlevel, command) 

Hi John, I’ve execty the same issue, currently in the fase to migrate frome homeseer to Openhab, and i would like to continue to keep using the LAN RFXcom device as it works very stable had never issues with it. Would you be able to share what you have ? regards

Hi and yes, that can be arranged. I’ll send you download link. You’ll need to change hardcoded values like the IP address, and username / password etc.



Have been busy with other tings… Thank you for the tip!!



I too have an RFXLAN and am a recent convert to OpenHab. Would like to get hold of your files if poss.

Hi John. I also have an old RFXCOM LAN (not compatible with xPL), can you send me your files / download link in order for me to try to connect it to OPENHAB2 ? (current binding does not seem to work)

Hi and maybe an attempt at doing this properly would be beneficial?

The X10 parts came from the DomotiGa project and https://eclipse.org/legal/eplfaq.php#USEINANOTHER, and other web sites, state the two licenses are incompatible, EPL and GPL, for re-distribution.

Maybe you could reach out to the DomotiGa project, https://domotiga.nl/projects/domotiga/wiki/Home, and ask if they can give concent to re-copyright/dual license or a one-off permission for us to use the X10 parts in an EPL project?

Alternativly, ask if the existing OH RFXCOM binding can be re-licenensed as GPL and make this plugin GPL licensed?

Or try RFXCom? While Bart? was not very helpfull when I approached him about a year ago, maybe if additional ppl reach out, he may be more willing to provide the relevant information?

Another option is to find the X10 information either in the public domain, or EPL licensed?


I’m a bit confused … : aren’t the x10 parts already handled by the actual OpenHAB RFXCOM binding (the one in openhab for the RFXCOMs connected through USB) ?

So bad this is a blocking thing for you, because i’m not even interested by x10 (only by some other protocols like oregon scientific).

Let me rephase / clarify; the information to decode the DS90 door/window sensors, the Oregon Scientific temp sensor and X10 wireless wall switches, when using the legacy RFXLAN device, all came from the DomotiGa project (GPL).

The old RFXLAN and the newer RFXCOM devices decode differently. All of that information came from the DomotiGa project (GPL). I reused the OH RFXCOM plugin as a shell (EPL)

The blocking thing for me is to respect the copyright holders and the licenses of their choice.


I’ve been looking for ways to replace my (still working) RFXLAN device, but lacking in protocol support, and stumbled across the RfLink project. I built mine for less than £10 and I’ve recently added support for outbound messages, switches/contacts, Oregon Temp sensor and RTS/Somfy support to the OH2 binding, RFLink binding.

I’ll probably end up with two of these, one for 433.92MHz and one for 433.42MHz (RTS/Somfy). I use usbip to “move” the ttyUSB devices to my OH2 box from the RPI the devices are connected to. Its been pretty stable so far.


Hello JJ,

Same as others, I am still using a RFXCOM LAN and I am planning to use OH.
Did you look at heyu project in order to see the code?

Hi and no, not looked at that project. I moved on to RfLink as it supported more protocols and was easier to replace parts etc.

The original devs went awol, and there is an open source firmware now which can be improved upon, new protocols etc.