Yes all groups need to be unique. So just keep incrementing by 1.
OK - I tried it and no dice. When I try to do the addResponderForButton I get the following:
>>> KitchenTable.addResponderForButton("33.C8.A6",0xf3,3)
getting db, be patient!
sent db query msg, incoming records: 1 1 2 2 3 4 5 5 6 7 8 8 9 10 10 10 11 12 13 14 15 16 17 18 18 19 19 19 19 20 20 21 21 22dbbuilder.done() is called
0fff 3D.7F.4F 3D.7F.4F CTRL 11101010 group: 01 ON LVL: 3 RMPRT: 28 BUTTON: 1
0ff7 modem 33.C8.A6 RESP 10101010 group: 00 ON LVL: 0 RMPRT: 28 BUTTON: 1
0fef modem 33.C8.A6 CTRL 11110010 group: 01 ON LVL: 3 RMPRT: 28 BUTTON: 1
0fe7 Island 3B.40.DD CTRL 11101010 group: 08 ON LVL: 3 RMPRT: 28 BUTTON: 8
database complete, analyzing...
0fdf Kitchen Ceiling 42.D0.39 CTRL 11101010 group: 08 ON LVL: 3 RMPRT: 28 BUTTON: 8
0fd7 modem 33.C8.A6 RESP 10101010 group: 0d ON LVL: 255 RMPRT: 31 BUTTON: 1
0fcf modem 33.C8.A6 RESP 10101010 group: 0d ON LVL: 255 RMPRT: 28 BUTTON: 8
reusing inactive record:0f67 modem 33.C8.A6 (RESP) 00000010 group: 04 ON LVL: 3 RMPRT: 28 BUTTON: 4
0fc7 Island 3B.40.DD CTRL 11101010 group: 02 ON LVL: 3 RMPRT: 28 BUTTON: 2
0fbf modem 33.C8.A6 RESP 10101010 group: 0f ON LVL: 255 RMPRT: 28 BUTTON: 2
0fb7 Island 3B.40.DD RESP 10101010 group: 01 ON LVL: 255 RMPRT: 28 BUTTON: 2
0faf Kitchen Ceiling 42.D0.39 RESP 10101010 group: 01 ON LVL: 255 RMPRT: 28 BUTTON: 3
0fa7 Kitchen Ceiling 42.D0.39 CTRL 11101010 group: 03 ON LVL: 3 RMPRT: 28 BUTTON: 3
0f9f modem 33.C8.A6 RESP 10101010 group: 10 ON LVL: 255 RMPRT: 28 BUTTON: 3
0f97 modem 33.C8.A6 RESP 10101010 group: 0d ON LVL: 255 RMPRT: 28 BUTTON: 2
0f8f modem 33.C8.A6 RESP 10101010 group: 0d ON LVL: 255 RMPRT: 28 BUTTON: 3
0f87 Cabinet Lights 48.73.0E RESP 10101010 group: 01 ON LVL: 255 RMPRT: 28 BUTTON: 4
sent msg: OUT:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x02|userData3:0x0F|userData4:0x67|userData5:0x08|userData6:0xA2|userData7:0xF3|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x03|userData14:0xF9|
0f7f Cabinet Lights 48.73.0E CTRL 11101010 group: 04 ON LVL: 3 RMPRT: 28 BUTTON: 4
0f77 modem 33.C8.A6 RESP 10101010 group: 13 ON LVL: 255 RMPRT: 28 BUTTON: 4
0f6f modem 33.C8.A6 RESP 10101010 group: 01 ON LVL: 255 RMPRT: 28 BUTTON: 1
0f67 modem 33.C8.A6 (RESP) 00000010 group: 04 ON LVL: 3 RMPRT: 28 BUTTON: 4
0f5f modem 33.C8.A6 CTRL 11101010 group: 05 ON LVL: 3 RMPRT: 28 BUTTON: 5
0f57 00.00.00 00.00.00 (STOP) 00000000 group: 00 ON LVL: 0 RMPRT: 0 BUTTON: 0
got set record got no reply!
link record added!
As you can see, nothing listed is showing 0xf3 as the group. And I get a “sent msg” in the middle of the db output for some reason. I have debugging turned on, and here is what I see in the insteon-terminal log when I execute this command:
23:49:56.056 [Thread-6] DEBUG us.pfrommer.insteon.msg.IOPort - Msg written: OUT:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
23:49:56.382 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
23:49:57.387 [Thread-5] WARN us.pfrommer.insteon.msg.MsgReader - got unknown command code 1D
The
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 01 data: 00 00 00
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 03 data: 00 00 03
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 04 data: 00 00 04
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 05 data: 00 00 05
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 06 data: 00 00 06
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 07 data: 00 00 07
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 08 data: 00 00 08
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 09 data: 00 00 09
0000 KitchenTable 1D.F4.7F RESP 10100010 group: 0a data: 00 00 0a
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: 01 data: 01 1c 41
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f3 data: 00 00 f3
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f4 data: 00 00 f4
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f5 data: 00 00 f5
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f6 data: 00 00 f6
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f7 data: 00 00 f7
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f8 data: 00 00 f8
0000 KitchenTable 1D.F4.7F CTRL 11100010 group: f9 data: 00 00 f9
0000 KitchenTable 1D.F4.7F CTRL 11101010 group: 0d data: 01 1c 41
0000 KitchenTable 1D.F4.7F CTRL 11101010 group: 0f data: 01 1c 41
0000 KitchenTable 1D.F4.7F CTRL 11101010 group: 10 data: 01 1c 41
0000 KitchenTable 1D.F4.7F CTRL 11101010 group: 13 data: 01 1c 41
0000 KitchenTable 1D.F4.7F CTRL 11101011 group: 00 data: 01 1c 41
So the modem is acting as a controller for groups 0xf3 through 0xf9 (the groups the buttons are supposed to respond to if only the AddResponderForButton commands were working) and a responder for groups 1-9 (also for group 10 i.e. a0 - not sure if that’s an issue). Note the other groups in the keypads db are for other scenes programmed into the keypad in the past.
Also note that every once in a while I get something like this:
KitchenTable.addResponderForButton("33.C8.A6",0xf3,3)
getting db, be patient!
sent db query msg, incoming records: did not get full database, giving up!
database incomplete, reload() and retry!
If I do a KitchenTable.readdb() this seems to fix this problem for a while, but it will come back.
Oh and as far as OpenHAB’s log goes, here is what I get for the keypad in question when it starts up (or re-reads the insteonplm.items file):
device 1D.F4.7F found in the modem database and the modem controls groups [0x00,0x0D,0x0F,0x10] and responds to groups [0x01].
Any thoughts?
Thanks,
Bruce
Yikes!
I just tried to do KitchenTable.addResponderForButton("33.C8.A6",0xf7,7) thinking it might work better for a button that wasn’t already linked to a scene. I got the same result in the terminal window, but the debug log went nuts:
23:49:56.056 [Thread-6] DEBUG us.pfrommer.insteon.msg.IOPort - Msg written: OUT:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
23:49:56.382 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
23:49:57.387 [Thread-5] WARN us.pfrommer.insteon.msg.MsgReader - got unknown command code 1D
23:57:13.962 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x7F|Command2:0x02|ACK/NACK:0x06|
23:57:25.483 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x7F|Command2:0x00|ACK/NACK:0x06|
23:58:39.614 [Thread-6] DEBUG us.pfrommer.insteon.msg.IOPort - Msg written: OUT:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
23:58:39.740 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
23:58:40.745 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x50|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x2B=ACK_OF_DIRECT:3:2|command1:0x2F|command2:0x00|
23:58:40.746 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xFF|userData5:0x00|userData6:0xEA|userData7:0x01|userData8:0x3D|userData9:0x7F|userData10:0x4F|userData11:0x03|userData12:0x1C|userData13:0x01|userData14:0xAC|
23:58:41.768 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xF7|userData5:0x00|userData6:0xAA|userData7:0x00|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x00|userData12:0x1C|userData13:0x01|userData14:0x62|
23:58:41.778 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xEF|userData5:0x00|userData6:0xF2|userData7:0x01|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x01|userData14:0x1E|
23:58:41.789 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xE7|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x69|
23:58:42.752 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xE7|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x69|
23:58:43.956 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xE7|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x69|
23:58:44.962 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xE7|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x69|
23:58:45.967 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xE7|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x69|
23:58:46.970 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xDF|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x42|userData9:0xD0|userData10:0x39|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x7E|
23:58:47.973 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xDF|userData5:0x00|userData6:0xEA|userData7:0x08|userData8:0x42|userData9:0xD0|userData10:0x39|userData11:0x03|userData12:0x1C|userData13:0x08|userData14:0x7E|
23:58:47.977 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xD7|userData5:0x00|userData6:0xAA|userData7:0x0D|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1F|userData13:0x01|userData14:0x73|
23:58:49.980 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xCF|userData5:0x00|userData6:0xAA|userData7:0x0D|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x08|userData14:0x77|
23:58:50.983 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xCF|userData5:0x00|userData6:0xAA|userData7:0x0D|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x08|userData14:0x77|
23:58:50.988 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xC7|userData5:0x00|userData6:0xEA|userData7:0x02|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x02|userData14:0x95|
23:58:51.986 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xC7|userData5:0x00|userData6:0xEA|userData7:0x02|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x02|userData14:0x95|
23:58:53.193 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xC7|userData5:0x00|userData6:0xEA|userData7:0x02|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0x03|userData12:0x1C|userData13:0x02|userData14:0x95|
23:58:54.196 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xBF|userData5:0x00|userData6:0xAA|userData7:0x0F|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x02|userData14:0x8B|
23:58:55.199 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xBF|userData5:0x00|userData6:0xAA|userData7:0x0F|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x02|userData14:0x8B|
23:58:56.202 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xBF|userData5:0x00|userData6:0xAA|userData7:0x0F|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x02|userData14:0x8B|
23:58:56.205 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xB7|userData5:0x00|userData6:0xAA|userData7:0x01|userData8:0x3B|userData9:0x40|userData10:0xDD|userData11:0xFF|userData12:0x1C|userData13:0x02|userData14:0xEA|
23:58:57.205 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xAF|userData5:0x00|userData6:0xAA|userData7:0x01|userData8:0x42|userData9:0xD0|userData10:0x39|userData11:0xFF|userData12:0x1C|userData13:0x03|userData14:0xFE|
23:58:57.211 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xA7|userData5:0x00|userData6:0xEA|userData7:0x03|userData8:0x42|userData9:0xD0|userData10:0x39|userData11:0x03|userData12:0x1C|userData13:0x03|userData14:0xC0|
23:58:58.209 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0xA7|userData5:0x00|userData6:0xEA|userData7:0x03|userData8:0x42|userData9:0xD0|userData10:0x39|userData11:0x03|userData12:0x1C|userData13:0x03|userData14:0xC0|
23:58:59.213 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x9F|userData5:0x00|userData6:0xAA|userData7:0x10|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x03|userData14:0xA9|
23:59:00.216 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x9F|userData5:0x00|userData6:0xAA|userData7:0x10|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x03|userData14:0xA9|
23:59:01.219 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x9F|userData5:0x00|userData6:0xAA|userData7:0x10|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x03|userData14:0xA9|
23:59:02.223 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x97|userData5:0x00|userData6:0xAA|userData7:0x0D|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x02|userData14:0xB5|
23:59:02.231 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x8F|userData5:0x00|userData6:0xAA|userData7:0x0D|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x03|userData14:0xBC|
23:59:03.226 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x87|userData5:0x00|userData6:0xAA|userData7:0x01|userData8:0x48|userData9:0x73|userData10:0x0E|userData11:0xFF|userData12:0x1C|userData13:0x04|userData14:0xA7|
23:59:03.229 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x7F|userData5:0x00|userData6:0xEA|userData7:0x04|userData8:0x48|userData9:0x73|userData10:0x0E|userData11:0x03|userData12:0x1C|userData13:0x04|userData14:0x68|
23:59:04.232 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x7F|userData5:0x00|userData6:0xEA|userData7:0x04|userData8:0x48|userData9:0x73|userData10:0x0E|userData11:0x03|userData12:0x1C|userData13:0x04|userData14:0x68|
23:59:04.235 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x77|userData5:0x00|userData6:0xAA|userData7:0x13|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x04|userData14:0xCD|
23:59:05.235 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x77|userData5:0x00|userData6:0xAA|userData7:0x13|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x04|userData14:0xCD|
23:59:06.240 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x77|userData5:0x00|userData6:0xAA|userData7:0x13|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x04|userData14:0xCD|
23:59:07.244 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x77|userData5:0x00|userData6:0xAA|userData7:0x13|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x04|userData14:0xCD|
23:59:08.449 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x77|userData5:0x00|userData6:0xAA|userData7:0x13|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x04|userData14:0xCD|
23:59:09.452 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x6F|userData5:0x00|userData6:0xAA|userData7:0x01|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x01|userData14:0xEA|
23:59:10.657 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x6F|userData5:0x00|userData6:0xAA|userData7:0x01|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0xFF|userData12:0x1C|userData13:0x01|userData14:0xEA|
23:59:10.661 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x67|userData5:0x00|userData6:0x02|userData7:0x04|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x04|userData14:0x90|
23:59:11.660 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x67|userData5:0x00|userData6:0x02|userData7:0x04|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x04|userData14:0x90|
23:59:12.668 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x17=DIRECT:3:1|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x67|userData5:0x00|userData6:0x02|userData7:0x04|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x04|userData14:0x90|
23:59:13.672 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x11=DIRECT:1:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x5F|userData5:0x00|userData6:0xEA|userData7:0x05|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x05|userData14:0xAE|
23:59:14.676 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x51|fromAddress:1D.F4.7F|toAddress:33.C8.A6|messageFlags:0x12=DIRECT:2:0|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x01|userData3:0x0F|userData4:0x5F|userData5:0x00|userData6:0xEA|userData7:0x05|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x05|userData14:0xAE|
... (had to delete some becuase the message was too long)...
00:01:43.670 [Thread-5] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x62|toAddress:1D.F4.7F|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x02|userData3:0x0F|userData4:0x67|userData5:0x08|userData6:0xA2|userData7:0xF7|userData8:0x33|userData9:0xC8|userData10:0xA6|userData11:0x03|userData12:0x1C|userData13:0x07|userData14:0xF1|ACK/NACK:0x06|
00:01:43.687 [Thread-5] WARN us.pfrommer.insteon.msg.MsgReader - got unknown command code 1D
Yikes!
Bruce
Seeing this tells me it’s programmed incorrect, assuming the other groups are f3-f 9.
I believe now is the time to reset the keypad and start ove r. I would reset the modem also if it were me.
Once reset then follow the commands in the quick setup. I pasted them into a text editor and did a replace on the addresses to mine.
One last tip, shutdown openhab w hen using insteo n terminal. I read this somewhere as a best pra ctice.
I would also not use the insteo n app for programming and/or pairing of you are using terminal. I had some intermittent troubles with the app and openhab. These are lesson learned. After things are working with terminal you can work with ap p if you like.
OK - if I reset the keypad and modem, I’ll need to reset the other insteon devices that are used as responders and/or controllers in the system as well right? Should I reset with the insteon terminal (nukeDB()) or should I do a hard factory reset on everything using the buttons?
Once I do this, should I do all of my scenes through openHAB, or should I program them using insteon terminal? For example, button B on the keypad now turns on the lights over the kitchen Island. Can I accomplish that through insteon terminal, or should I have openHAB do it? In either case, how can I set different ramp rates for scenes?
Thanks for the help,
Bruce
Something just came to mind even for a problem I had. When you use scenes created in the app you have to use the broadcastonoff command.
Switch BlackLamp_broadcastOnOff "Living Room Group on/off" { insteonplm="3C.14.EF:0x000045#broadcastonoff,group=2"}
This was in the other thread I sent you. As far as how to create scenes in the terminal that is also in the thread. I believe as long as you use the broadcast on off command creating scenes in the app is ok. I have not figured out how to get the status of the keypad except to use insteon terminal and create the groups.
I am not sure if yo have to factory reset other items. I know if you factory reset the modem, the others will be gone anyway. So you will definitely have some type of re-pairing to do. I don’t think it matters if yo use nukedb or factory reset, I believe the result is still the same. It seemed to be for me.
So summarizing. If you create a scene in the insteon app and link it to a button. This should function, however if you want to control that scene with openhab you need to control with the boardcastonoff command. Doing this would not allow you to track the keypad button status as far as I know though. That is unless someone on the forum has a trick up their sleeve.
ok - I’ll try that as a short term fix, but it sounds like I still will need to melt and re-pour if I want the buttons to be tracked, etc.
I don’t see any thread that you sent me - just a link to the github page on insteon-terminal. Could you send me a link to the thread you’re thinking about?
Thanks,
Bruce
OK - maybe getting closer, but not all the way there. I switched to a different keypad that I was OK factory resetting. I went through all the instructions and have:
>>> TheaterKeypad.getdb()
getting db, be patient!
sent db query msg, incoming records: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17dbbuilder.done() is called
0fff modem 33.C8.A6 RESP 10101010 group: 01 ON LVL: 254 RMPRT: 28 BUTTON: 1
0ff7 modem 33.C8.A6 CTRL 11100010 group: 01 ON LVL: 3 RMPRT: 28 BUTTON: 1
0fef modem 33.C8.A6 CTRL 11100010 group: 03 ON LVL: 3 RMPRT: 28 BUTTON: 3
0fe7 modem 33.C8.A6 CTRL 11100010 group: 04 ON LVL: 3 RMPRT: 28 BUTTON: 4
0fdf modem 33.C8.A6 CTRL 11100010 group: 05 ON LVL: 3 RMPRT: 28 BUTTON: 5
0fd7 modem 33.C8.A6 CTRL 11100010 group: 06 ON LVL: 3 RMPRT: 28 BUTTON: 6
0fcf modem 33.C8.A6 CTRL 11100010 group: 07 ON LVL: 3 RMPRT: 28 BUTTON: 7
0fc7 modem 33.C8.A6 CTRL 11100010 group: 08 ON LVL: 3 RMPRT: 28 BUTTON: 8
0fbf modem 33.C8.A6 RESP 10100010 group: a2 ON LVL: 3 RMPRT: 28 BUTTON: 2
0fb7 modem 33.C8.A6 CTRL 11100010 group: 02 ON LVL: 3 RMPRT: 28 BUTTON: 2
0faf modem 33.C8.A6 RESP 10100010 group: a3 ON LVL: 3 RMPRT: 28 BUTTON: 3
0fa7 modem 33.C8.A6 RESP 10100010 group: a4 ON LVL: 3 RMPRT: 28 BUTTON: 4
0f9f modem 33.C8.A6 RESP 10100010 group: a5 ON LVL: 3 RMPRT: 28 BUTTON: 5
0f97 modem 33.C8.A6 RESP 10100010 group: a6 ON LVL: 3 RMPRT: 28 BUTTON: 6
0f8f modem 33.C8.A6 RESP 10100010 group: a7 ON LVL: 3 RMPRT: 28 BUTTON: 7
0f87 modem 33.C8.A6 RESP 10100010 group: a8 ON LVL: 3 RMPRT: 28 BUTTON: 8
0f7f 00.00.00 00.00.00 (STOP) 00000000 group: 00 ON LVL: 0 RMPRT: 0 BUTTON: 0
>>> modem.getdb()
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 01 data: 00 00 00
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 02 data: 00 00 02
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 03 data: 00 00 03
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 04 data: 00 00 04
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 05 data: 00 00 05
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 06 data: 00 00 06
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 07 data: 00 00 07
0000 TheaterKeypad 3D.7F.4F RESP 10100010 group: 08 data: 00 00 08
**0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: 00 data: 01 41 45**
**0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: 01 data: 01 41 45**
**0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: 03 data: 01 41 45**
**0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: 08 data: 01 41 45**
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a2 data: 00 00 a2
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a3 data: 00 00 a3
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a4 data: 00 00 a4
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a5 data: 00 00 a5
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a6 data: 00 00 a6
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a7 data: 00 00 a7
0000 TheaterKeypad 3D.7F.4F CTRL 11100010 group: a8 data: 00 00 a8
The lines with the ** at the start are related to scenes that were pre-defined in the hub before I factory reset the keypad - they are still there…
I have two sets of definitions in my items file (one for the button “state” and one for the button broadcast group).
// Theater
Dimmer TheaterKeypad "Theater Sconces" {insteonplm="3D.7F.4F:F00.00.16#loaddimmer"}
Switch TheaterKeypadB "Theater Keypad B[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonB,group=0x02"}
Switch TheaterKeypadC "Theater Keypad C[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonC,group=0x03"}
Switch TheaterKeypadD "Theater Keypad D[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonD,group=0x04"}
Switch TheaterKeypadE "Theater Keypad E[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonE,group=0x05"}
Switch TheaterKeypadF "Theater Keypad F[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonF,group=0x06"}
Switch TheaterKeypadG "Theater Keypad G[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonG,group=0x07"}
Switch TheaterKeypadH "Theater Keypad H[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonH,group=0x08"}
Switch TheaterKeypadBset "Theater Keypad B[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonB,group=0xa2"}
Switch TheaterKeypadCset "Theater Keypad C[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonC,group=0xa3"}
Switch TheaterKeypadDset "Theater Keypad D[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonD,group=0xa4"}
Switch TheaterKeypadEset "Theater Keypad E[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonE,group=0xa5"}
Switch TheaterKeypadFset "Theater Keypad F[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonF,group=0xa6"}
Switch TheaterKeypadGset "Theater Keypad G[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonG,group=0xa7"}
Switch TheaterKeypadHset "Theater Keypad H[%d %%]" {insteonplm="1D.F4.7F:F00.00.16#keypadbuttonH,group=0xa8"}
If I use the “set” versions, I can programatically turn the buttons on and off via OpenHAB. However, if I set up a rule to catch a change to one of the buttons (using either the standard or the “set” version of the item), it never executes. Interestingly enough, if I turn on the main load at the keypad, OpenHAB does see that and can spawn a rule. Here are the examples for my rules:
rule "Theater Keypad Button D set"
when Item TheaterKeypadDset received update
then
logWarn("myLog", "TheaterKeypadDset pressed")
Echo_BasementFR_TTS.sendCommand('You set Movie Keypad button D')
end
rule "Theater Keypad Button D"
when Item TheaterKeypadD received update
then
logWarn("myLog", "TheaterKeypadD pressed")
Echo_BasementFR_TTS.sendCommand('You pressed Movie Keypad button D')
end
rule "Theater Sconces"
when Item TheaterKeypad received update
then
logWarn("myLog", "Theater Sconces turned off or no")
Echo_BasementFR_TTS.sendCommand('You just turned the movie sconces on or off')
end
I can’t figure out why it isn’t seeing the press of the other buttons. Any thoughts?
Thanks for the help so far - we’ve made significant progress…
Bruce
Try seeing if the rules fire with “when button changed”. Vs received update. That works for me.
On your two sets of items one has groups 02-08 the other a2 - a8? Is one set the app and the other insteon terminal ?
Interestingly enough, the buttons on the other keypad that I started with began responding this morning: when my wife went down and turned on a light, my echo said “You have pressed button D”, which is in my rules for that keypad. But the new keypad still doesn’t respond. I’m confused, but I’ll try changing the rule to changed instead of update.
That’s straight from the insteon terminal documentation - one set of links so that the modem knows the button was pressed (2-8) , and one set so that the modem can turn the buttons on and off (a2-a8). Note it took me a while to realize that the reason the instructions started with 0x03 was that it was a 6-button remote and so the top (“on”) button is really the first 2 buttons, so on the 8-button keypad, B is 0x02 as expected.
I’ll let you know what happens.
Thanks for all the help!
Bruce
Thanks Bruce, I looked and I had those groups in mine also. The 02-06, I forgot because I don’t use them for anything. I only use the f3-f6 in items files.
I believe your address may be incorrect. Theater keypad is 3D.7F.4F correct? I get a little confused by the database dumps sometime, but I believe so.
It is interesting you had a rule fire, but the unexpected one. I had some of those issues when I first started. I realized, there is lots of info going in and out. I had to just slow down! On my first contact switch my items file didnt work, I factory reset the world. Only to come back to the same exact items file I originally had. So something was not setup properly in the app or ins terminal.
Lesson Learned for me: Put all the terminal commands in notepad, slow down, focus on only one device at a time. Do not use the insteon app until things work in openhab. This was my plan and it worked. Your path may be different as far as the app vs terminal. I do plan on spending a day and factory reset my devices and try using just the app to configure. I would like to see if its possible as the terminal is lots of typing and one typo can cause everything to be broken.
Lastly!! I clear my cache and restart with every change of my items file or rules file. I don’t care if it is necessary, I do it. I just don’t want to keep track of when yo u need to do this and when you don’t. To make it easy I put a file in my /bin folder with this line:
ostop && rm -rf $OPENHAB_USERDATA/tmp/* && rm -rf $OPENHAB_USERDATA/cache/* && ostart && tail -f /var/log/openhab2/openhab.log
This restarts openhab, clears cache, and tails the log file after. (ostop and ostart are also files with the systemctl command to start and stop)
Wow! That was it - I copied over the settings from the kitchen keypad and forgot to change the address!
It looks like it’s all working now.
Thanks for the help!
Bruce
1 Like
OK - it all “works”, but the latency isn’t what I was hoping. I’m using the following rules:
var FrontTableUpdate = now
var latency = 15
rule "Front Table Lamp Changed to ON"
when Item EntryKeypadD changed from OFF to ON
then
if(FrontTableUpdate.isBefore(now.minusSeconds(latency))) {
logInfo("KeypadRules", "Entry Keypad D Changed from OFF to ON")
FrontTableUpdate=now
FrontTableLamp_Brightness.sendCommand(100)
} else {
logInfo("KeypadRules", "Entry Keypad D Changed, but update was recent")
}
end
rule "Front Table Lamp Chagned to OFF"
when Item EntryKeypadD changed from ON to OFF
then
if(FrontTableUpdate.isBefore(now.minusSeconds(latency))) {
logInfo("KeypadRules", "Entry Keypad D Changed from ON to OFF")
FrontTableUpdate=now
FrontTableLamp_Brightness.sendCommand(0)
} else {
logInfo("KeypadRules", "Entry Keypad D Changed, but update was recent")
}
end
rule "Front Table Lamp Button (Change from 0)"
when Item FrontTableLamp_Brightness changed from 0
then
if(FrontTableUpdate.isBefore(now.minusSeconds(latency))) {
logInfo("KeypadRules", "Front Table Lamp just turned on - turning on button too")
FrontTableUpdate=now
EntryKeypadDset.sendCommand(ON)
} else {
logInfo("KeypadRules", "Front Table Lamp changed, but update was recent")
}
end
rule "Front Table Lamp Button (Change to 0)"
when Item FrontTableLamp_Brightness changed to 0
then
if(FrontTableUpdate.isBefore(now.minusSeconds(latency))) {
logInfo("KeypadRules", "Front Table Lamp just turned off - turning off button too")
FrontTableUpdate=now
EntryKeypadDset.sendCommand(OFF)
} else {
logInfo("KeypadRules", "Front Table Lamp changed, but update was recent")
}
end
I’ve had to add a 15 second “wait” so that the opposing rule wouldn’t fire. However, it can take quite a long time for things to change (i.e. I can press the button and the light might not come on for another 10 seconds, or I can turn on the light and the button might not light up for another 10 seconds). Is there any way to speed this up, or is this just a result of the polling interval for both the hue bridge and the insteon hub?
Thanks,
Bruce
Bruce a few questions.
- Have you cleared cache and restarted.
- It sounds as if you are controlling Phillips Hue with the keypad. I am also. Can you post the items file for those?
I am controlling Hue and Tradfri and don’t have issues like this. I do have an issue with my insteon loads being a little slower. I need to try a few fixes to the linking, but I have not done so yet. Keep in mind my max delays at anytime are less than 2 secs. 15 sounds like something else may be wrong.
Here is my original Hue rule:
rule "Button D Rule 1 ON_Off"
when
Item Ins_6Button1_D changed
then
logWarn("Insteon_RuleLog", "BTND Turned ON")
Hue.sendCommand(triggeringItem.state.toString)
end
My current rule has some other logic with it so I didnt post. It is related to whether brightness is 100% or not. But this rule worked fine with my hue. I just tested and it has less than 1second delay, almost no delay.
Had a thought.
- Shutdown openhab press a keypad button see if light turning on has a delay.
- Remove power from as many insteon devices as possible the keypad can power off by pulling the set button. Then try you insteon button for hue lights.
Trying to isolate where problem might be. Also lastly how many rule files do you have?
Sorry I didn’t respond sooner. I’ve been without internet for a few days due to an issue with my AT&T modem/router - since that’s the router that’s used for my internal wired network, I’ve been “out of business” for any openHAB work for a few days. They are sending a new modem today, so hopefully I’ll be back up and running this evening. Without the
I only have the one rules file with the two rules listed in my previous post. I have the extra logic in there about not running the rules again for a certain time because I need to be able to turn the light on with the button, but I also need the button’s light to turn on if the hue light is turned on with another method (e.g. hue app or Alexa voice control).
My insteon devices respond almost immediately to button presses.There is more lag going from the insteon keypad to a hue light, but it appeared to be better after I stopped openHAB, flushed the cache and tmp directories and restarted openHAB. I was able to reduce the latency variable to 2s, so that’s better. I’ll do some more testing either tonight or tomorrow depending on when I get the new modem/router up and running.
I’d love it if I didn’t have to have the extra logic in these rules (perhaps a different trigger or some other way of approaching it). Any thoughts?
Thanks,
Bruce
I am having a similar struggle. The extra logic piece. I need to look at my rules again and see what extra logic I had and why. Maybe we can work this rule thing together.
I asked a question about this on another board, and got a good suggestion.
I implemented that last night and it seems to work quite well. Let me know if it works for your situation.
Thanks for all the help!
Bruce
Thanks I am following that thread also. Have not tried it yet.
I had similar logic to what was in there, but still had another issue. I can’t remember what it was. I am going to try that code then move on if it works.
I do however have to co tact insteon to swap out my keypad. It has a flicker and also randomly buttons seem to get toggled. So something wrong with it.