Can't trigger rules from Insteon Keypad Scene buttons

Setup, Configuration and Use Scripts & Rules
,
1

Hello,

I’ve been working with home automation for 7 or 8 years nor, but somewhat new to openHAB.

I have a 6 button keypad and want to use the A/B/C/D scene buttons to trigger rules.

I have followed all of the setup instructions on the PLM binding page and the linking instruction via the insteon-terminal from its page.

Here are those items:

Dimmer masterBed “Fan Light” (g2F_Master, Lights, g2F_Lights) {insteonplm=“28.A4.22:F00.00.15#loaddimmer”}
Switch masterA “Master A” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonA,group=0xf3”}
Switch masterB “Master B” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonB,group=0xf4”}
Switch masterC “Master C” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonC,group=0xf5”}
Switch masterD “Master D” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonD,group=0xf6”}

I have no problem turning on the main load from openHAB, can also turn on the lights on the scene buttons from openHAB, and also button presses on the physical keypad will change the corresponding switch states in openHAB.

My problem is using those keypresses to trigger rules:

I set up a simple rule like this:

rule “MasterA-on”
when
Item masterA received command ON
then
logInfo(“masterA”, “!!! MasterA Pressed ON”)
end

rule “MasterA-Off”
when
Item masterA received command OFF
then
logInfo(“masterA”, “!!! MasterA Pressed OFF”)
end

This will not trigger at all.

I tried changing from “received command” to “received update”
Now, I can trigger rules. The problem is that from time to time when openHAB updates statuses, it thinks something has changed and triggers the rule when I haven’t pushed any buttons!

Can someone tell me the proper way to use the A/B/C/D scene buttons to trigger rules?

Thanks!

Tom

2

Try received update instead. The following rule works for me:

rule "Master Bedroom Button A"
    when
        Item sMasterBedButtonA received update ON
    then

The item for my button is:

Switch sMasterBedButtonA "Master A" {insteonplm="22.F8.B8:F00.00.15#keypadbuttonA,group=3"}

You should also look in the log file and make sure the plm is set up as a controller and responder:

2016-03-06 20:10:11.260 [INFO ] [.o.b.i.InsteonPLMActiveBinding] - device 22.F8.B8 found in the modem database and the modem controls groups [0xFE,0x03,0x04,0x05,0x06] and responds to groups [0x01,0x03,0x04,0x05,0x06].
3

OK, so here is the problem that I have with using received update: sometimes when openhab polls for status changes, it things that the status has changed and it triggers the rule.

Example when I start up openhab, it goes and polls. I get this:

2016-03-10 19:00:35.699 [INFO ] [.o.b.i.i.device.MessageHandler] - SwitchRequestReplyHandler: dev 28.A4.22 button 3 switched to ON
2016-03-10 19:00:35.700 [INFO ] [.o.b.i.i.device.MessageHandler] - SwitchRequestReplyHandler: dev 28.A4.22 button 4 switched to OFF
2016-03-10 19:00:35.700 [INFO ] [.o.b.i.i.device.MessageHandler] - SwitchRequestReplyHandler: dev 28.A4.22 button 5 switched to OFF
2016-03-10 19:00:35.701 [INFO ] [.o.b.i.i.device.MessageHandler] - SwitchRequestReplyHandler: dev 28.A4.22 button 6 switched to OFF
2016-03-10 19:00:35.785 [INFO ] [g.openhab.model.script.masterA] - !!! MasterA Pressed ON
2016-03-10 19:00:35.830 [INFO ] [g.openhab.model.script.masterB] - !!! MasterB Pressed OFF
2016-03-10 19:00:35.855 [INFO ] [g.openhab.model.script.masterC] - !!! MasterC Pressed OFF
2016-03-10 19:00:35.890 [INFO ] [g.openhab.model.script.masterD] - !!! MasterD Pressed OFF

If I had a real rule in place it woudl turn on or off lights randomly w/o me pressing any triggers.

Here are m items:
Dimmer masterBed “Fan Light” (g2F_Master, Lights, g2F_Lights) {insteonplm=“28.A4.22:F00.00.15#loaddimmer”}
Switch masterA “Master A” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonA,group=0xf3”}
Switch masterB “Master B” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonB,group=0xf4”}
Switch masterC “Master C” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonC,group=0xf5”}
Switch masterD “Master D” {insteonplm=“28.A4.22:F00.00.15#keypadbuttonD,group=0xf6”}

Here is my rule to post a log message:

rule “MasterA-on”
when
Item masterA received update ON
then
logInfo(“masterA”, “!!! MasterA Pressed ON”)
//sendCommand(g2F_Lights,OFF)
end

and my startup message:

2016-03-10 18:59:59.761 [INFO ] [.o.b.i.InsteonPLMActiveBinding] - device 28.A4.22 found in the modem database and the modem controls groups [0xF3,0xF4,0xF5,0xF6,0x00,0x01,0x07] and responds to groups [0x01,0x03,0x04,0x05,0x06].

4

you could try a less detailed trigger,

rule "MasterA"
when
    Item masterA received command // or maybe update, but then you have to use masterA.state instead of receivedCommand
then
    logInfo("masterA", "!!!!!!!!!!!!!!!!!!!!!! MasterA pressed {}",receivedCommand.toString)
    if (receivedCommand==ON)
        {
        //do some stuff
        }
    else
        {
        //do some other stuff
        }
end
5

@ranielsen had exactly the same problem. Here is a snippet from our private email conversation:

I don’t think it has to do with cosmic rays mangling the messages on the insteon network, but rather has to do with the two different polling queries we perform: 0x19 0x00 to ask for the main load status, 0x19 0x01 for the buttons. There is some bug in the binding such that it is expecting a response to 0x19 0x01 when in fact it should be expecting a response to 0x19 0x00. So when the response to 0x19 0x00 comes in, it gets picked up by the handlers for the keypad button which totally misinterprets the message as all buttons pressed.

2015-11-01 17:26:17 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: KeyPadButtonGroup(0:0:0) OUT:Cmd:0x62|toAddress:22.F8.74|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x01|
2015-11-01 17:26:17 DEBUG o.o.b.i.i.d.DeviceFeatureListener[:163]- polling related device 22.F8.74 in 5000 ms
2015-11-01 17:26:19 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 22.F8.74 for another 3500 usec
2015-11-01 17:26:19 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:22.F8.74|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2015-11-01 17:26:20 DEBUG o.o.b.i.InsteonPLMActiveBinding[:522]- got msg: IN:Cmd:0x50|fromAddress:22.F8.74|toAddress:24.11.9D|messageFlags:0x2B=ACK_OF_DIRECT:3:2|command1:0x00|command2:0xFE|
2015-11-01 17:26:20 DEBUG o.o.b.i.i.d.MessageDispatcher[:194]- 22.F8.74:KeyPadButtonGroup qs:QUERY_PENDING cmd: 80
2015-11-01 17:26:20 DEBUG o.o.b.i.i.d.MessageDispatcher[:199]- changing key to 0x19 for msg IN:Cmd:0x50|fromAddress:22.F8.74|toAddress:24.11.9D|messageFlags:0x2B=ACK_OF_DIRECT:3:2|command1:0x00|command2:0xFE|
2015-11-01 17:26:20 INFO o.o.b.i.i.d.MessageHandler[:403]- SwitchRequestReplyHandler: dev 22.F8.74 button 3 switched to ON
2015-11-01 17:26:20 DEBUG o.o.b.i.i.device.DeviceFeature[:263]- 22.F8.74:KeyPadButton3 publishing: ON
2015-11-01 17:26:20 INFO o.o.b.i.i.d.MessageHandler[:403]- SwitchRequestReplyHandler: dev 22.F8.74 button 4 switched to ON
2015-11-01 17:26:20 DEBUG o.o.b.i.i.device.DeviceFeature[:263]- 22.F8.74:KeyPadButton4 publishing: ON
2015-11-01 17:26:20 INFO o.o.b.i.i.d.MessageHandler[:403]- SwitchRequestReplyHandler: dev 22.F8.74 button 5 switched to ON
2015-11-01 17:26:20 DEBUG o.o.b.i.i.device.DeviceFeature[:263]- 22.F8.74:KeyPadButton5 publishing: ON
2015-11-01 17:26:20 INFO o.o.b.i.i.d.MessageHandler[:403]- SwitchRequestReplyHandler: dev 22.F8.74 button 6 switched to ON
2015-11-01 17:26:20 DEBUG o.o.b.i.i.device.DeviceFeature[:263]- 22.F8.74:KeyPadButton6 publishing: ON
2015-11-01 17:26:20 DEBUG o.o.b.i.i.d.MessageDispatcher[:222]- 22.F8.74:KeyPadButtonGroup set status to: QUERY_ANSWERED
2015-11-01 17:26:20 DEBUG o.o.b.i.i.device.DeviceFeature[:263]- 22.F8.74:GenericLastTime publishing: 2015-11-01T17:26:20

Still don’t know how we get into this state, since I thought the binding should keep always just one message outstanding to avoid this very scenario.

This is really so screwed up about the insteon level protocol, that they don’t echo back the query command in the reply message. I had to put all this complicated logic in just to keep track of what message was sent out such that I could associate the reply to the query. And I still got it wrong!!

Again, will take a while to figure out what’s broken and how to fix it.

6

And this was my final conclusion to this problem:

“I have a better handle now on what’s going on. Messages enqueued by a higher level thread were not written to the modem until seconds later. Is it possible that there was quite some CPU load on the system? Ah, given that you are running openhab that is a stupid question, rephrase: is that box busy often?”

I took a stab at fixing it by restructuring the binding and eventually gave up realizing that I have virtually no way to guarantee and test if my implementation is robust to high CPU load. It would take me too much time to write a simulator. The problem is fundamentally that I have multiple threads running and Insteon messaging is unreliable so I have to work with timeouts. The binding does not deal well with the situation where a message does not get sent out due to high CPU load. It rather assumes that the Insteon network has dropped the message (a much more frequent situation).

What hardware are you running on, and is other stuff running on this machine?

7

Hello Bernd,

Thanks for the information. Pretty interesting look at the low level. I’m not sure if my issue is related to box load. I’m running on a full PC (not Rasp pi) with a 6 core AMD FX-6300 with 16GB RAM. Aside from this being my desktop PC, I do also run a zoneminder server on it, but I think typical loads are in the 0.2 range.

Over night I was thinking about why item statuses could be changing without the OH server knowing. I came up with two things:

  1. I realized that I still had X10 addresses assigned to scene buttons (and I guess all of my insteon switches). I’m moving to OH with a insteon hub from heyu with an old X10 CM-11A (similar to an Insteon PLM, but X10- only) with a mixed Insteon/X10 device environment. I also have a device that puts some noise on the X10 line and I think it was causing some of these scene buttons to randomly change state, but not send out the change to the OH server, so it wouldn’t figure it out until the next poll and then trigger a “received update” rule. While this is true for all of my switches, I never would notice this on anything but the scene switches since they typically trigger something big to happen. This morning I removed all of the X10 address assignments from these scene switches and will test later tonight to see if this helps.

  2. I have some of my keypad scene switches linked to other Insteon devices directly. Example: I have two keypads. On both of these keypads I use scene button C to control the same X10 command, so when I would press one C button, it would send out an X10 command and also trigger the other button to the same state via its Insteon linkage. I had linked these manually making both a receiver and controller for the same scene. So, with this linkage if I pressed keypad 1’s C button, OH would get the signal that it had changed, but not get the signal that keypad 2’s C had changed until the next poll. Then it would “magically” think keypad 2’s C button had “received update” and trigger that scene.

I also had a similar situation where I had keypad 2’s B and D buttons linked as controllers and receivers of two load dimmer switches. If I was operating those switches locally, they would tell OH that they had changed, but not that the scene switches had changed, then at the next poll, they would trigger their “received update” rules. I’ve also removed these linkages.

So, when I get my next opportunity I will retest and see if my issues were resolved with removing all of these X10 and Insteon linkages causing switches to change state without the OH server being told causing seemingly random “received update” rules to be triggered.

I do still have two questions:

  1. Is there a reason that scene switches don’t trigger “received command” rules and only “received update” or “changed” rules? Is there yet something wrong with my setup or is this how it is supposed to work? I notice when I change the switch via the OH gui it will trigger a “received command”, but not when operating the physical device.

  2. For my solution to #2 above with scene buttons being linked to other keypad’s scene buttons and or switches, I just removed the linkages and was planning on using OH rules to take care of it all. I do also see the “related” command that talks a lot about 3 way switches. This seems to be exactly what I would need to leave these bindings in place but still get OH to know that the status of both the actual load switch and the scene button have changed states without waiting until the next poll. Is there a way to use this “related” command with scene buttons?

Thanks for the help!

8

Your analysis on 2) is spot on. The “related” keyword may help you out there. It’s function is pretty simple: if item A is updated due to a message from the Insteon network, cause item B to poll it’s state as well. This should help you bring keypad 2 into sync with keypad 1 quicker, but it would still give the impression that the scene has been triggered twice.

One solution would be to actually make the modem a responder to the scene, and then implement a feature at the binding level that will cause a status update. Strange that I never thought of doing that. The downside obviously is that the state of the scene will be unknown until it is triggered by the controller(s). There is no polling. But then that’s the same for all insteon scenes. I see it occasionally that the switches in a 3-way configuration are out of sync (at the insteon level, w/o openhab in the picture). I guess the question is: how tolerant are you to missing one of the group broadcasts, i.e. missing a scene being switched from either one of the keypads?

More answers to your questions

1): I’m actually not that familiar with OH, I just did the binding. But I would imagine “received command” is only triggered when actually an OH command is issued. If you just flip a switch manually, and the binding tells OH about it, then no OH command was actually ever in the picture. But the state of the item did change nevertheless.

  1. Yes, the “related” feature does help speed up state discovery, and I believe it should work with the buttons as well. One thing I wanted to warn you of: don’t put OH in the critical path if you can do the same with Insteon device-to-device scenes. OH is not nearly as reliable, for various reasons, and much slower.
9

Hi @Bernd_Pfrommer

I’m new to OH and would like to first express my sincere gratitude for all the work and support you have put into both the PLM binding and Insteon Terminal.

So far I have found all my questions already answered here in the forum by you. However, I have a new question for which I cant find an answer. You mention above that

the “related” feature … should work with the buttons as well

I have some 3-way situations between keypad main loads and buttons on other keypads. I cant seem to figure out the proper syntax for linking a button to an item using the ‘related’ feature. I attempted to use its unique assigned group name, but the binding throws an error.

Can you please share the proper syntax, or help me understand what I am missing?

Any help is greatly appreciated.
Thank you!

Here is an excerpt from my items file. I left the error inducing group names to illustrate what I am attempting to do.
FYI all the devices here are linked in the insteon dbs. I am only trying to get OH to quickly see the updates to all the various devices when manual control is used at a keypad.

Dimmer ctrl_livRm_kpMain "living kp main" {insteonplm="49.F3.79:F00.00.15#loaddimmer,related=3A.76.6D+47.30.00+0xf3"}
Switch ctrl_livRm_kpBtn3 "living kp btn3" {insteonplm="49.F3.79:F00.00.15#keypadbuttonA,group=0xf8,related=43.9F.13"}
Switch ctrl_livRm_kpBtn4 "living kp btn4" {insteonplm="49.F3.79:F00.00.15#keypadbuttonB,group=0xf9,related=45.DF.52"}
Switch ctrl_livRm_kpBtn5 "living kp btn5" {insteonplm="49.F3.79:F00.00.15#keypadbuttonC,group=0xfA,related=3A.76.6D+47.30.00+0xf2"}
Switch ctrl_livRm_kpBtn6 "living kp btn6" {insteonplm="49.F3.79:F00.00.15#keypadbuttonD,group=0xfB"}

Dimmer ctrl_hallw_kpMain "Hall kp main" {insteonplm="43.9F.13:F00.00.16#loaddimmer,related=0xf8"}
Switch ctrl_hallw_kpBtn2 "Hall kp btn2" {insteonplm="43.9F.13:F00.00.16#keypadbuttonB,group=0xf1,related=45.DF.52"}
Switch ctrl_hallw_kpBtn3 "Hall kp btn3" {insteonplm="43.9F.13:F00.00.16#keypadbuttonC,group=0xf2,related=3A.76.6D+47.30.00+0xfA"}
Switch ctrl_hallw_kpBtn4 "Hall kp btn4" {insteonplm="43.9F.13:F00.00.16#keypadbuttonD,group=0xf3,related=49.F3.79+3A.76.6D+47.30.00"}
Switch ctrl_hallw_kpBtn5 "Hall kp btn5" {insteonplm="43.9F.13:F00.00.16#keypadbuttonE,group=0xf4"}
Switch ctrl_hallw_kpBtn6 "Hall kp btn6" {insteonplm="43.9F.13:F00.00.16#keypadbuttonF,group=0xf5"}
Switch ctrl_hallw_kpBtn7 "Hall kp btn7" {insteonplm="43.9F.13:F00.00.16#keypadbuttonG,group=0xf6"}
Switch ctrl_hallw_kpBtn8 "Hall kp btn8" {insteonplm="43.9F.13:F00.00.16#keypadbuttonH,group=0xf7"}

Error:

2018-03-31 15:36:42.570 [ERROR] [nding.AbstractGenericBindingProvider] - Binding org.openhab.binding.insteonplm.InsteonPLMActiveBinding threw an exception: 
java.lang.IllegalArgumentException: Address string must have 3 bytes, has: 1
	at org.openhab.binding.insteonplm.internal.device.InsteonAddress.<init>(InsteonAddress.java:61) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.binding.insteonplm.internal.device.InsteonAddress.s_parseAddress(InsteonAddress.java:217) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.binding.insteonplm.internal.device.DeviceFeatureListener.updateRelatedDevices(DeviceFeatureListener.java:166) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.binding.insteonplm.internal.device.DeviceFeatureListener.setParameters(DeviceFeatureListener.java:90) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.binding.insteonplm.InsteonPLMActiveBinding.addFeatureListener(InsteonPLMActiveBinding.java:532) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.binding.insteonplm.InsteonPLMActiveBinding.bindingChanged(InsteonPLMActiveBinding.java:226) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.model.item.binding.AbstractGenericBindingProvider.notifyListeners(AbstractGenericBindingProvider.java:112) [222:org.openhab.core.compat1x:2.2.0]
	at org.openhab.model.item.binding.AbstractGenericBindingProvider.addBindingConfig(AbstractGenericBindingProvider.java:106) [222:org.openhab.core.compat1x:2.2.0]
	at org.openhab.binding.insteonplm.InsteonPLMGenericBindingProvider.processBindingConfiguration(InsteonPLMGenericBindingProvider.java:80) [234:org.openhab.binding.insteonplm:1.11.0]
	at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:49) [222:org.openhab.core.compat1x:2.2.0]
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:341) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:310) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:195) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
	at org.eclipse.smarthome.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:377) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
	at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:314) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
	at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:143) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
	at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:247) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
	at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:311) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
	at org.eclipse.smarthome.core.service.WatchQueueReader.run(WatchQueueReader.java:209) [109:org.eclipse.smarthome.core:0.10.0.b1]
	at java.lang.Thread.run(Thread.java:748) [?:?]
10

From what I remember, you cannot specify the group name in the “related” keyword. In fact, I’m not sure why you would want to, because the “related” keyword will trigger a complete poll on the related device, thereby updating all its items.
I assume you tried specifying groups because things didn’t work without doing so. I recommend double checking that all groups are properly linked, and that when you press your keypad buttons, your modem does indeed get a message, and the binding produces a line in the debug log.

11

@elads,

Can you explain what you are trying to accomplish with the “related” keywords? I’ve read your post a few times and I’m not sure I know what you are looking to accomplish:

You say

“I cant seem to figure out the proper syntax for linking a button to an item using the ‘related’ feature”

Are you trying to actually trigger some action or change the button/switches physical state with “related”? I think that’s what I’m reading

If that’s the case, ‘related’ won’t work for you. “Related” just makes the binding go and re-poll all of the related units when the parent unit changes state.

.

12

@Bernd_Pfrommer
Thank you. Actually, I just wasn’t thinking it through clearly, and came to the same realization when I woke up this morning. I had in my mind divorced the state of the keypad button from the device main load. Thank you for starting with the obvious. I needed it. :slight_smile:
I’ll fix this when I get home from work and expect it should work as I need.

@tommycw10
Bernd hit it on the head. I just need to add the keypad’s ID in the related parameter and thereby get the updates for the whole device. I was too focused on needing to poll the specific button.

I am using rules to update the state of keypad buttons when a user turns on lights in the OpenHAB wed UI.
Just got started on this yesterday. So far so good, though manual input on a Insteon switch results in about a second delay before the rule updates the keypad button state. Haven’t gotten into this yet.

Thank you, both!

13

Unfortunately I don’t think there’s a way around the delay. I have my system set up with Insteon switches all over the house. I have each keypad button linked into openhab. I’ve noticed, if I trigger a scene that changes many lights and a few keypad buttons from OpenHAB itself everything seems to trigger fine. However if I push a button on a keypad which then triggers that same scene in OpenHAB there is a delay, and sometimes not all devices respond. I’m finding it to be a slow network.

If you find ways around these issue let me know. I’d love to know how you got around these issues. I’ve been working with Insteon for months now and can’t seem to find a way around adding delays to my rules to make things work out better.

14

Did you ever find a resolution to the slowness of this arrangement? I’m noticing the same thing…

Bruce

15

I never found a great way around it. I think it has to do with the fact that every time you push the button the whole network gets the scene notification, then there’s re response, then the keypad has to do the network cleanup. So there’s a whole lot of traffic on a network that really isn’t that fast.

The way I work around it is to start putting in delays using Thread::sleep(ms). That gives the network a chance to clean up the messages. You’ll have to play with the duration to get what works for your network.