I have a working RFXLAN from 2010, and it looks like the RFXCOM binding only supports the newer USB models. As I do not want to spend €110 ++ to replace a perfectly working device, I thought I would spend some time and see if I could get my device to work with OpenHAB.
Bart @ RFXCOM could not offer any documetation or help at all on how the RFXLAN works. , but luckily the DomotiGa project is both open source (GPL) and supports the RFXLAN device so its not impossible to figure out how it works.
After poking around with putty, a hex calulator and the DomotiGa source code (Gambas, a variation of basic), I appear to be able to see if a door opens or closes with my DS90’s.
So the plan is to clone the RFXCOM / binding template and create an RFXLAN binding for OH2 as OH1 is about to be superseeded by OH2. The only small challenge is that I’m not a developer, nor have I written a single line of Java in my life so it may take some time to complete…
If you too have an RFXLAN device and would like to test / help out, let me know.
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!
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?
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.
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"
when
Item bedroom_bedside_fred changed
then
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)
}
}
end
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.
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)
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.
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? https://github.com/HeyuX10Automation/heyu/
, but luckily the DomotiGa project is both open source (GPL) and supports the RFXLAN device so its not impossible to figure out how it works. 
