Using X10 commands to trigger rules (Insteonplm)

Setup, Configuration and Use Items & Sitemaps
1

I have several in-wall X10 controllers in my house, but due to LED lighting conversion, many of my dimmer switches no longer work. I’ve started implementing a Hue system, but would like to take advantage of my existing X10 controller infrastructure to trigger the Hue lights. I thought Openhab would do this easily based on the docs for the insteonplm binding.

X10 devices

It is worth noting that the Insteon PLM can command X10 devices over the powerline,
and also set switch stats based on X10 signals received over the powerline. This allows openHAB not
only control X10 devices without the need for other hardware, but it
can also have rules that react to incoming X10 powerline commands.

This sounds like exactly what I need to do. However after successfully setting up my insteonplm binding in OH2 and creating an items file to define all of my X10 addresses, I can use the Basic UI to control existing X10 lights, but if I use my wall controllers to trigger a light, only the A.2 and A.3 addresses are picked up by the binding. If I use a wall controller to let’s say turn on light A.5, the binding never sees it even though the light (X10 module) does turn on. I’ve used other software to verify that the plm is actually see the codes, and it is.

If I set up a rule to trigger a hue bulb based on receipt of an ON command for A.2, it works as expected, but I need for it to work with all X10 codes. Is there any reason that only A.2 and A.3 would be recognized by the binding? I have all of my X10 addresses (A.1 to A.15) coded the same way in the items file.

2

Hi, I’m having the same issue but on all X10 addresses. I’m using OH2 in Eclipse on 32 bit Java 8, Windows 8 with a 2012 HUB1 through the insteonplm binding.

From .items

Switch X10_A2		" A2"  {insteonplm="A.2:X00.00.01#switch"}

I’ve also added this rule to my .rules file (where non-X10 item triggered rules fire properly) but cannot seem to get any X10 derived rule to fire.

rule "X10 A2 Test"
when
	X10_A2 received command
then
		logInfo("report", "Rule X10 A2 Test executing")
		if (receivedCommand == ON) {
			logInfo("report", "X10 A2 ON")
		} else {
			logInfo("report", "X10 A2 OFF")
		}
end

Here is what shows up in the log when I press A2 OFF on an MC10A X10 power line mini-controller. The Insteon hub is indeed recognizing the command off of the powerline and passing it to openHAB.

2016-11-02 13:21:44.556 [DEBUG] [.o.b.i.InsteonPLMActiveBinding:591  ] - got msg: IN:Cmd:0x52|rawX10:0x6E|X10Flag:0x00|
2016-11-02 13:21:44.971 [DEBUG] [.o.b.i.InsteonPLMActiveBinding:591  ] - got msg: IN:Cmd:0x52|rawX10:0x63|X10Flag:0x80|
2016-11-02 13:21:44.972 [DEBUG] [b.i.i.device.MessageDispatcher:328  ] - A.2:X10Switch->X10OffHandler IN:Cmd:0x52|rawX10:0x63|X10Flag:0x80|
2016-11-02 13:21:44.972 [INFO ] [.o.b.i.i.device.MessageHandler:1141 ] - X10OffHandler: set X10 device A.2 to OFF
2016-11-02 13:21:44.972 [DEBUG] [o.o.b.i.i.device.DeviceFeature:321  ] - A.2:X10Switch publishing: OFF
2016-11-02 13:21:44.976 [DEBUG] [o.i.m.internal.MyOpenHABClient:491  ] - Sending update 'OFF' for item 'X10_A2'

As you can see, there is no evidence in the log of the rule firing.

If I switch X10_A2 OFF on an openHAB panel (HABDroid, in this case), the rule does indeed fire, as shown here:

2016-11-02 13:22:45.953 [DEBUG] [io.rest.core.item.ItemResource:284  ] - Received HTTP POST request at 'items/X10_A2' with value 'OFF'.
2016-11-02 13:22:45.958 [DEBUG] [.m.r.r.i.engine.RuleEngineImpl:295  ] - Executing rule 'X10 A2 Test'
2016-11-02 13:22:45.961 [DEBUG] [o.i.m.internal.MyOpenHABClient:491  ] - Sending update 'OFF' for item 'X10_A2'
2016-11-02 13:22:45.963 [INFO ] [.o.b.i.InsteonPLMActiveBinding:121  ] - Item: X10_A2 got command OFF
2016-11-02 13:22:45.963 [DEBUG] [o.o.b.i.i.device.InsteonDevice:241  ] - processing command OFF features: 1
2016-11-02 13:22:45.963 [DEBUG] [o.o.b.i.i.device.InsteonDevice:454  ] - gave up waiting for query reply from device A.2
2016-11-02 13:22:45.963 [DEBUG] [o.o.b.i.i.device.InsteonDevice:459  ] - qe taken off direct: X10Switch(1:3:2) OUT:Cmd:0x63|rawX10:0x6E|X10Flag:0x00|
2016-11-02 13:22:45.964 [DEBUG] [o.o.b.i.i.device.InsteonDevice:479  ] - next request queue processed in 2000 msec, quiettime = 2000
2016-11-02 13:22:45.964 [DEBUG] [o.o.b.i.i.device.InsteonDevice:454  ] - gave up waiting for query reply from device A.2
2016-11-02 13:22:45.964 [INFO ] [.o.b.i.i.device.CommandHandler:406  ] - X10OnOffCommandHandler: sent msg to switch A.2 OFF
2016-11-02 13:22:45.964 [DEBUG] [o.o.b.i.i.device.InsteonDevice:459  ] - qe taken off direct: X10Switch(1:3:2) OUT:Cmd:0x63|rawX10:0x63|X10Flag:0x80|
2016-11-02 13:22:45.964 [DEBUG] [o.o.b.i.i.device.InsteonDevice:479  ] - next request queue processed in 2000 msec, quiettime = 2000
2016-11-02 13:22:45.965 [DEBUG] [o.o.b.i.internal.driver.Port  :415  ] - writing (500): OUT:Cmd:0x63|rawX10:0x6E|X10Flag:0x00|
2016-11-02 13:22:45.995 [INFO ] [.smarthome.model.script.report:48   ] - Rule X10 A2 Test executing
2016-11-02 13:22:45.997 [INFO ] [.smarthome.model.script.report:48   ] - X10 A2 OFF

Rule fired!

I haven’t had the time to dig into the code myself to try and find the solution (will attempt to do so soon!) but maybe someone with more experience will know exactly where to look can make shorter work of this issue than I. I would be happy to apply and test any suggested fixes. I hope this helps.

3

My bad. Should have been using ‘received update’ and ‘state’ instead of ‘received command’

rule "X10 A2 Test"
when
	Item X10_A2 received update
then
		logInfo("report", "Rule X10 A2 Test executing")
		if (X10_A2.state == ON) {
			logInfo("report", "X10 A2 ON")
		} else {
			logInfo("report", "X10 A2 OFF")
		}
end
4

Henry: Did you create X10 device database entries in the PLM? I have about 50 X10 devices and my MisterHouse machine that I had been using for ~15 years (not backed up) died, so I moved to a PI with OpenHab and have started to move the X10 devices into OH. Got Hue working yesterday. Still having some PLM modem issues with Insteon, but I am thinking that is PLC bridge issue.

5

Hi David,

I think you’ve made a good choice! I’m extremely happy with openHAB and the direction the project is taking. Hats off to all involved! I’ve also got a sizeable X10 inventory that I’ve been accumulating since the '70s and also a lot of Insteon that I’m happy enough with and thus not really ready to replace. Great that new bindings are so plentiful and easy to add! I’m looking forward to adding some newer HA devices and some Arduino nodes! I am particularly happy with the SNMP binding for monitoring all my gear!

As per your question, from what I understand it is not necessary (or even possible?) to create X10 entries in the PLM device database. Basic one-way X10 protocol has no security or error detection information in the command protocol and thus pre-linking of controllers and devices (for example, like is necessary with Insteon) or device discovery is not required or possible with X10 on Insteon controllers. All one has to do on openHAB is to declare the X10 address in the item definition line in the .items file and it operates as described.

My own (related) current problem has to do with the multi-hub configuration I’m building.

Apart from Insteon itself not (yet) working in multi-PLM/hub topologies (as is warned about in the documentation), one shortcoming that seems to exist is the ability to declare which PLM/hub X10 commands should be sent to. My own application involves more than one site bridged by Ubiquiti networking radios with a hub and a mix of Insteon and X10 devices at each site.

Insteon protocol requires that Insteon devices be pre-linked to the individual hubs. Thus it is possible for openHAB to know which hub/site to send Insteon commands to by querying the device database of each hub at startup (which it does.) This is not done (or possible) for X10.

Thus, because there is no X10 pre-configuration at the PLM/hub level and no way to specify a port (PLM or hub) in the .items file, I’m not sure how openHAB as it exists could know which PLM/hub and thus site to send X10 commands to (like it should…via the hash table…something wrong in the code here?..with Insteon) during regular operation.

I can imagine that duplicating X10 commands to all configured PLMs/hubs (another (non-elegant?) way to X10 bridge 120v legs in North American house wiring?) and using different house codes at each site would work but I don’t know if it is set up that way (haven’t checked the code…trying to fix Insteon first). It seems that the openHAB Insteon binding as it sits today just sends all X10 commands to the first hub that it successfully configures at startup in multi-hub systems (what it currently incorrectly does with Insteon commands, because of a bug/bugs).

Maybe someone more familiar with the openHAB Insteon binding can tell me if my assumptions are correct and offer suggestions or even fixes! I’d certainly be happy to do any necessary testing and code changes (I’m running Eclipse) and I have multiple hubs (and some PLMs) to play with.

Haha sorry for the long-winded reply about multi-hub Insteon/X10. Not really sure what to say about your PLC bridge issue as I’m using hubs exclusively and have had no real problems using single hubs, both 2012 and 2014 versions. Have you made any progress?

6

Thanks for the reply

After moving the PLM from the RPi to a winxp machine to do some testing with the Insteon software as part of troubleshooting - since I think I have an issue with the PLM and Insteon dimmer being on different legs. Or a bum switch. I have two Insteon switches still in a box. Anyway moving the modem back to the RPi (hot) I found that it was assigned to another tty upon reconnect. Simple fix, reboot, but time consuming to troubleshoot. I have 2 Insteon radio bridges that I thought on the separate legs would at least allow me to have a consistent test. These won’t help with 10 messages though. Anyhow I’ve finally created a created an outlet/switch/light test jig for both troubleshooting the box of questionable devices and AC/leg issues. It does sound as if the PLM Database needs to be updated with the devices. A real PIA as I have to switch the PLM from RPi to WinXP machine to use the Windoz utility to update the Db. Or I have to go back and read how to setup the devices using the push buttons. I’ve confirmed in the logs that the Modem is found connecting and downloading the DB which is a good thing.

I’ve gone through a couple of the X10 bridges over the years, I get intermittent connections across the legs every once and a while. I still need to spend some time mapping the devices to the 2 legs. I have two TW-523 that I will do some testing with.

I’m a big Kodi (xbmc) user and have it on a RPi and have found a plug-in for OH to allow Kodi to display & use OH .site on the TV… very cool.

Other option is to move your devices to only one AC leg :slight_smile:

7

Hi David,

I hope you’re making progress! I’ve been very busy and haven’t had as much time to dedicate to my own issues as I’d like but things are moving along. Yes, frustrating to have to move the PLM around! I have some PLMs, too, but have chosen to mothball them because the hubs (cheap, used) allow me to continue to use my mix of Insteon and X10 devices with the Insteon app as I slowly learn and migrate everything to openHab2. The other advantage of the hubs is that they are TCP/IP addressable so no physical reconfiguration is required to swap between Windows and Linux tools/platforms, the problem that you’re facing. The app also allows for easy device linking and initial troubleshooting; button pressing only required occasionally, generally only on older devices.

The Insteon app also seems to coexist nicely with openHab (other than delays in device status showing up on openHab) and has been a great backup during the past while as myopenhab/openhabcloud evolves. It will also remain indispensable for my two-site, Ubiquiti-brdige-connected configuration until the ability for openHab to support multiple hubs (and PLMs) at a time gets addressed. I’ve also been using Insteon Terminal on Linux occasionally and, as yet, haven’t wiped my hub link database by also using Windows HouseLink but take the warning in the docs seriously!

Yes, the Insteon devices definitely need to be linked but not so for X10 devices. Sorry if my comments were misleading. Having dual hubs/PLMs, one for each leg, is def a solution to the bridging issue, IMO. As I move forward, my approach is to stop having my Insteon and X10 controllers control Insteon (through scenes etc.) and X10 devices directly. Each will be on a different house code and the openHab rule engine can be responsible for routing the control commands to the appropriate devices. This will, of course, make Insteon control via their app awkward (Android app still doesn’t support multiple hubs (homes) without signing off and on to a different account but the iPhone app does) but it’s only for backup anyway, so it’s not a long-term problem as along as the multiple hub issue gets resolved.

The problem, as I mentioned earlier in the thread, is that there doesn’t seem to be a way to pick which port to send X10 commands to, unlike with the Insteon addressing scheme that is possible because the linking database of each hub/PLM is loaded at startup which tells openHab which hub/PLM to send Insteon device commands to afterwards. Because X10 devices aren’t linked into each hub/PLM, openHab has no way to tell which hub/PLM and thus leg (or site in my configuration) to send X10 commands to. This would probably need to be set in the items file but there is currently no provision for picking which port in an X10 item definition. I hope to patch something in myself and then submit it to the project but it’s going to take me some time to be at that level, considering the learning curve I’m facing.

Maybe someone with more knowledge who happens to read this can offer some support or guidance. Unfortunately, there doesn’t seem to be a lot of love for our legacy X10 and Insteon products on the team, anymore, with all the exciting new tech getting the focus. Speaking of which, I picked up some Hue products over the last few days cheap and can fully understand! One Hue bridge is here at home and the other at the remote site later today!

All-in-all, I’m having a great time and have to say how happy I am to have found openHab! Open source home automation tech is, at worst, a great project with which to modernize one’s skills. Soon I’ll be writing my own bindings etc.! Kudos to the team!

Yes, I’ll be doing the Kodi thing, too, eventually! So cool LOL!

Once again, I hope you’re making progress!

8

Oh, also, the remote Insteon hub does indeed provide partial functionality to my openHab setup. I also have motion, leak, door/window sensors and a smoke bridge (hacked in the fix with Equinox, it works) at the remote site and, because they send TO the hub, openHab picks up those events and I can at least know when something happens over there. But it’s not possible to control any devices there because commands all get sent to the local hub, not the remote. At least with the Hue bridge over there, I’ll be able to turn on some pretty colored lights LOL for the time being. And I can run the devices over there with the hub and the Insteon app if need be. I can’t wait until multiple Insteon hubs are working properly!