Struggling with some db cleanup using a 2245 hub

Eric Thomas

unread,

Jul 3, 2017, 11:14:35 AM7/3/17

to insteon-terminal

First, thanks for insteon-terminal ... really well done and exactly what I went looking for when my insteon network started acting up.

Equipment:

hub: 2245-222

relay: 2475SDB (InLineLinc relay)

After repeated creation and deletion of various scenes through the hub android app, I've managed to corrupt some of my device databases. yeah! So, now I have a few devices responding to scenes (group #3 actually), but the hub app does not identify the devices as members of the scene.

Easily got insteon-terminal communicating with the hub.

I configured my hub as a Modem2413U in init.py because I didn't see any 'hub' device. This was at least enough to get hub.startWatch() working.

I've confirmed that they rogue devices are in fact responding to the group 3 command and that each of the rogue devices includes a db RCVR entry for group 3, associated with the hub.

I configured my relay switches as Dimmer2477D units in insteon-terminal because there was not a specific 2475SDB class.

I've tried all of the direct commands to remove devices from the relay's db, but none of them seem to be causing any change; removeResponder(), removeDevice(), nukeDB()

So, I'm struggling with a few questions:

1. Is the hub capable of this level of control or do I need to get an actual 2413U modem?

2. Do I need to do anything to put the relays into a linking or unlinking mode before trying to remove entries from the db? (or, do I need to physically push a button?)

3. How do the linking and unlinking commands work with insteon-terminal? Should I be using these instead of direct db modification?

4. Are there other classes that I should try with the 2475SDB relays which may be more compatible?

Errors and db dump from one of the relay devices (fan) are below.

Thanks for any suggestions.

Eric

------

Common errors:

10:08:53.125 [Thread-5] WARN us.pfrommer.insteon.msg.MsgReader - incoming message does not start with 0x02

10:08:54.182 [Thread-5] WARN us.pfrommer.insteon.msg.MsgReader - got unknown command code 01

>>> fan.getdb()

getting db, be patient!

sent db query msg, incoming records: 1 2 3 4 5 6 7 7 8 9 10 11

----- database -------

0fdf patio 2A.A4.A7 (RESP) 00000010 group: 01 ON LVL: 3 RMPRT: 31 BUTTON: 1

0fd7 hub 39.36.9C RESP 10101010 group: 00 ON LVL: 0 RMPRT: 31 BUTTON: 1

0fcf hub 39.36.9C CTRL 11101010 group: 01 ON LVL: 3 RMPRT: 31 BUTTON: 1

0fc7 hub 39.36.9C RESP 10101010 group: 03 ON LVL: 255 RMPRT: 31 BUTTON: 1

0fbf hub 39.36.9C RESP 10101010 group: 0e ON LVL: 0 RMPRT: 31 BUTTON: 1

0fb7 keypad 19.25.7A RESP 10101010 group: 06 ON LVL: 0 RMPRT: 31 BUTTON: 1

0faf hub 39.36.9C RESP 10101010 group: 10 ON LVL: 255 RMPRT: 31 BUTTON: 1

0f87 patio 2A.A4.A7 (RESP) 00000010 group: 01 ON LVL: 255 RMPRT: 31 BUTTON: 1

0f7f kitchen 1B.29.6B (RESP) 00000010 group: 01 ON LVL: 3 RMPRT: 31 BUTTON: 1

0f77 patio 2A.A4.A7 (RESP) 00000010 group: 01 ON LVL: 3 RMPRT: 31 BUTTON: 1

0f6f 00.00.00 00.00.00 (RESP) 00000000 group: 00 ON LVL: 0 RMPRT: 0 BUTTON: 0

----- end ------------

Daniel Pfrommer

unread,

Jul 3, 2017, 11:27:46 AM7/3/17

to insteon-terminal

Hi Eric,

Could you run setLogLevel("TRACE") and give the output of running the removeDevice commands on the relay device? (if you could give the exact call you are making that might help too) What you are trying to do should be possible with a hub. Insteon devices do not let you change their link database unless the modem/hub is linked as a controller. That seems to be the case here however, so I'm not quite sure yet what's going on. More logging info might help shed light on the issue.

Daniel

Eric Thomas

unread,

Jul 3, 2017, 11:57:43 AM7/3/17

to insteon-terminal

Sure. Log is attached. Last two commands executed are shown below. fan is using Dimmer2477D. patio is using Switch2477S. Both are 2475SDB relays.

You can see that both commands still show the hub attached as a responder for group 3 after the removeResponder commands.

Also, I should have mentioned, that the getdb() command frequently returns incomplete results. Sometime insteon-terminal shows a message indicating that incomplete results were returned, and othertimes the results are presented as complete. However, subsequent calls to getdb() produce a different number of records.

Lastly, what does it mean with RESP is enclosed in parens (RESP) ? You can see that fan and patio include each other this way in group 1, multiple times with differing levels.

Thanks,

Eric

>>> fan.removeResponder("39.36.9C", 3)
getting db, be patient!
sent db query msg, incoming records:  1 2 3 4 5 6 7 8 9 10 11


----- database -------
0fdf patio                          2A.A4.A7 (RESP) 00000010 group: 01 ON LVL:   3 RMPRT:  31 BUTTON:   1
0fd7 hub                            39.36.9C  RESP  10101010 group: 00 ON LVL:   0 RMPRT:  31 BUTTON:   1
0fcf hub                            39.36.9C  CTRL  11101010 group: 01 ON LVL:   3 RMPRT:  31 BUTTON:   1
0fc7 hub                            39.36.9C  RESP  10101010 group: 03 ON LVL: 255 RMPRT:  31 BUTTON:   1

0f9f hub                            39.36.9C  RESP  10101010 group: 0b ON LVL: 255 RMPRT:  31 BUTTON:   1
0f97 hub                            39.36.9C  RESP  10101010 group: 0f ON LVL: 255 RMPRT:  31 BUTTON:   1
0f8f patio                          2A.A4.A7 (RESP) 00000010 group: 01 ON LVL:   0 RMPRT:  31 BUTTON:   1


0f87 patio                          2A.A4.A7 (RESP) 00000010 group: 01 ON LVL: 255 RMPRT:  31 BUTTON:   1
0f7f kitchen                        1B.29.6B (RESP) 00000010 group: 01 ON LVL:   3 RMPRT:  31 BUTTON:   1
0f77 patio                          2A.A4.A7 (RESP) 00000010 group: 01 ON LVL:   3 RMPRT:  31 BUTTON:   1
0f6f 00.00.00                       00.00.00 (RESP) 00000000 group: 00 ON LVL:   0 RMPRT:   0 BUTTON:   0
----- end ------------


database incomplete, reload() and retry!
>>> patio.removeResponder("39.36.9C", 3)
getting db, be patient!
sent db query msg, incoming records:  1 2 3 4 5 6 7 8 9 10 11 12
----- database -------
0fff hub                            39.36.9C  RESP  10101010 group: 0b ON LVL: 255 RMPRT:  28 BUTTON:   1
0ff7 hub                            39.36.9C  RESP  10101010 group: 0c ON LVL: 255 RMPRT:  28 BUTTON:   1
0fef hub                            39.36.9C  RESP  10101010 group: 00 ON LVL:   0 RMPRT:  28 BUTTON:   1
0fe7 hub                            39.36.9C  CTRL  11101010 group: 01 ON LVL:   3 RMPRT:  28 BUTTON:   1
0fdf hub                            39.36.9C  RESP  10101010 group: 03 ON LVL: 255 RMPRT:  28 BUTTON:   1
0fb7 hub                            39.36.9C  RESP  10101010 group: 0d ON LVL:   0 RMPRT:  28 BUTTON:   1
0faf fan                            25.7C.14 (RESP) 00000010 group: 01 ON LVL:   0 RMPRT:  28 BUTTON:   1
0fa7 fan                            25.7C.14 (RESP) 00000010 group: 01 ON LVL:   3 RMPRT:  28 BUTTON:   1
0f9f kitchen                        1B.29.6B (RESP) 00000010 group: 01 ON LVL:   3 RMPRT:  28 BUTTON:   1
0f97 fan                            25.7C.14 (RESP) 00000010 group: 01 ON LVL:   3 RMPRT:  28 BUTTON:   1
0f8f fan                            25.7C.14 (RESP) 00000010 group: 01 ON LVL: 255 RMPRT:  28 BUTTON:   1
0f87 00.00.00                       00.00.00 (RESP) 00000000 group: 00 ON LVL:   0 RMPRT:   0 BUTTON:   0
----- end ------------

debug1

Daniel Pfrommer

unread,

Jul 4, 2017, 6:43:32 PM7/4/17

to insteon-terminal

The parentheses mean that the record has been deleted or is not in use (i.e that it is not a valid entry). The remove command should print out when it has found a record to remove before sending out the delete message. Looking at your logs, no delete message is ever being written to the device, which is odd as it finds the device in the link database. Unfortunately I am currently away and so have no way of reproducing this issue. Can you try using a more generic command like removeDevice() and then give the results of getdb() after that has been run?

Thanks

jhoffs...@gmail.com

unread,

Aug 18, 2017, 6:32:32 PM8/18/17

to insteon-terminal

I'm having a very similar problem trying to remove device links. In my case I had an old Insteon hub (2242-222) that died. I replaced it with the new version but because the old one isn't usable I can't use it to unlink all my devices from it. With insteon-terminal I'm able to see the links and remove them but the links still show on the devices as (RESP). Not sure if there's something else I need to be doing. I tried both removeResponder() and removeDevice(). Can I get rid of the links altogether?

Here's a console log from when I tried to remove a linke from a LampLinc (2457D2) device.

>>> Dim1.getdb()

getting db, be patient!
sent db query msg, incoming records: >>>  1 2 3 4 5 6 7 8 9 10

----- database -------
0fff hub1                           2A.C9.0B  RESP  10100010 group: 00 ON LVL:   0 RMPRT:  28 BUTTON:   0
0ff7 hub1                           2A.C9.0B  CTRL  11100010 group: 01 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fef hub1                           2A.C9.0B  RESP  10100010 group: 01 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fe7 hub1                           2A.C9.0B  RESP  10100010 group: 05 ON LVL:   0 RMPRT:  25 BUTTON:   0
0fdf hub1                           2A.C9.0B  RESP  10100010 group: 06 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fd7 hub1                           2A.C9.0B  RESP  10100010 group: 0b ON LVL: 255 RMPRT:  25 BUTTON:   0
0fcf 38.FA.D9                       38.FA.D9  RESP  10100010 group: 03 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fc7 hub2                           39.FD.9D  RESP  10100010 group: 00 ON LVL:   0 RMPRT:  27 BUTTON:   0
0fbf hub2                           39.FD.9D  CTRL  11100010 group: 01 ON LVL:   0 RMPRT:  27 BUTTON:   0
0fb7 00.00.00                       00.00.00 (RESP) 00000000 group: 00 ON LVL:   0 RMPRT:   0 BUTTON:   0
----- end ------------

>>> Dim1.removeResponder("2A.C9.0B", 05)

getting db, be patient!
sent db query msg, incoming records: >>>  1 2 3 4 5 6 7 8 9 10

----- database -------
0fff hub1                           2A.C9.0B  RESP  10100010 group: 00 ON LVL:   0 RMPRT:  28 BUTTON:   0
0ff7 hub1                           2A.C9.0B  CTRL  11100010 group: 01 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fef hub1                           2A.C9.0B  RESP  10100010 group: 01 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fe7 hub1                           2A.C9.0B  RESP  10100010 group: 05 ON LVL:   0 RMPRT:  25 BUTTON:   0
0fdf hub1                           2A.C9.0B  RESP  10100010 group: 06 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fd7 hub1                           2A.C9.0B  RESP  10100010 group: 0b ON LVL: 255 RMPRT:  25 BUTTON:   0
0fcf 38.FA.D9                       38.FA.D9  RESP  10100010 group: 03 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fc7 hub2                           39.FD.9D  RESP  10100010 group: 00 ON LVL:   0 RMPRT:  27 BUTTON:   0
0fbf hub2                           39.FD.9D  CTRL  11100010 group: 01 ON LVL:   0 RMPRT:  27 BUTTON:   0
0fb7 00.00.00                       00.00.00 (RESP) 00000000 group: 00 ON LVL:   0 RMPRT:   0 BUTTON:   0
----- end ------------
database complete, analyzing...
erasing active record at offset: 0fe7
sent msg: OUT:Cmd:0x62|toAddress:26.F1.25|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x02|userData3:0x0F|userData4:0xE7|userData5:0x08|userData6:0x22|userData7:0x05|userData8:0x2A|userData9:0xC9|userData10:0x0B|userData11:0x00|userData12:0x19|userData13:0x00|userData14:0x93|
got set record: IN:Cmd:0x50|fromAddress:26.F1.25|toAddress:39.FD.9D|messageFlags:0x20=ACK_OF_DIRECT:0:0|command1:0x2F|command2:0x00|

>>> Dim1.getdb()

getting db, be patient!
sent db query msg, incoming records: >>>  1 2 3 4 5 6 7 8 9 10

----- database -------
0fff hub1                           2A.C9.0B  RESP  10100010 group: 00 ON LVL:   0 RMPRT:  28 BUTTON:   0
0ff7 hub1                           2A.C9.0B  CTRL  11100010 group: 01 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fef hub1                           2A.C9.0B  RESP  10100010 group: 01 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fe7 hub1                           2A.C9.0B (RESP) 00100010 group: 05 ON LVL:   0 RMPRT:  25 BUTTON:   0
0fdf hub1                           2A.C9.0B  RESP  10100010 group: 06 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fd7 hub1                           2A.C9.0B  RESP  10100010 group: 0b ON LVL: 255 RMPRT:  25 BUTTON:   0
0fcf 38.FA.D9                       38.FA.D9  RESP  10100010 group: 03 ON LVL: 255 RMPRT:  25 BUTTON:   0
0fc7 hub2                           39.FD.9D  RESP  10100010 group: 00 ON LVL:   0 RMPRT:  27 BUTTON:   0
0fbf hub2                           39.FD.9D  CTRL  11100010 group: 01 ON LVL:   0 RMPRT:  27 BUTTON:   0
0fb7 00.00.00                       00.00.00 (RESP) 00000000 group: 00 ON LVL:   0 RMPRT:   0 BUTTON:   0
----- end ------------

Thanks,

John

Daniel Pfrommer

unread,

Aug 18, 2017, 6:54:14 PM8/18/17

to insteon-terminal, jhoffs...@gmail.com

As I believe I mentioned above, the parenthesis effectively mean that the link record has been removed. Insteon devices never actually wipe the record database. Instead, when you delete a record, it simply marks the record as unused and will eventually override the record on the next link. The insteon terminal still displays these unused (i.e previously deleted) records and signifies that they are unused by putting parenthesis around CTRL or RESP.

Bernd Pfrommer

unread,

Sep 24, 2017, 4:17:29 PM9/24/17

to insteon-terminal

Confirm that Daniel is right. The record is marked as invalid and is being ignored, hence the parentheses.

Message has been deleted

veitc...@gmail.com

unread,

Oct 25, 2018, 2:52:49 PM10/25/18

to insteon-terminal

I was wonder if someone could help me out:

I'm trying to remove some entries and I'm getting a "no matching found record, no action taken!"

And you can see that I do a a record of 39.1A.B0 , 14 in the DB?

I tried the removeLastRecord () and that di remove the last record/

Thoughts?

>>> s_dim.removeResponder("39.1A.B0", 14)

getting db, be patient!

sent db query msg, incoming records: 1 1 1 2 2 2 3 3 3 4 4 5dbbuilder.done() is called

database complete, analyzing...

no matching found record, no action taken!

0fff test_modem 39.1A.B0 RESP 10101010 group: 00 ON LVL: 255 RMPRT: 28 BUTTON: 1

0ff7 test_modem 39.1A.B0 CTRL 11101010 group: 01 ON LVL: 3 RMPRT: 28 BUTTON: 1

0fef test_modem 39.1A.B0 RESP 10101010 group: 13 ON LVL: 255 RMPRT: 31 BUTTON: 1

0fe7 test_modem 39.1A.B0 RESP 10101010 group: 14 ON LVL: 255 RMPRT: 31 BUTTON: 1

0fdf 00.00.00 00.00.00 (STOP) 00000000 group: 00 ON LVL: 0 RMPRT: 0 BUTTON: 0

>>>

On Monday, July 3, 2017 at 10:14:35 AM UTC-5, Eric Thomas wrote:

Daniel Pfrommer

unread,

Oct 25, 2018, 3:06:38 PM10/25/18

to insteon-terminal

That is very odd. Could you call startWatching() on the modem and change the log level to trace using setLogLevel. Perhaps the resulting log could help figure out what is going on here.

veitc...@gmail.com

unread,

Oct 25, 2018, 5:16:52 PM10/25/18

to insteon-terminal

See Attached log

>>> setLogLevel("TRACE")

>>> s_dim.removeResponder("39.1A.B0", 13)

getting db, be patient!

16:15:48.643 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - read buffer: len 59 data: 02622BDCD11F2F0000000000000000000000000000D10602502BDCD1391AB0202F0002512BDCD1391AB0112F0000010FFF00AA00391AB0FF1C01F9

16:15:48.653 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 59 data: 02622BDCD11F2F0000000000000000000000000000D10602502BDCD1391AB0202F0002512BDCD1391AB0112F0000010FFF00AA00391AB0FF1C01F9

16:15:48.654 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 6 extended: true

16:15:48.655 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 23

16:15:48.660 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 36 data: 02502BDCD1391AB0202F0002512BDCD1391AB0112F0000010FFF00AA00391AB0FF1C01F9

16:15:48.683 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 36 data: 02502BDCD1391AB0202F0002512BDCD1391AB0112F0000010FFF00AA00391AB0FF1C01F9

16:15:48.684 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 9 extended: false

16:15:48.685 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 11

16:15:48.690 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 25 data: 02512BDCD1391AB0112F0000010FFF00AA00391AB0FF1C01F9

16:15:48.708 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 25 data: 02512BDCD1391AB0112F0000010FFF00AA00391AB0FF1C01F9

16:15:48.710 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 9 extended: true

16:15:48.711 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 25

16:15:48.711 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 0 data:

116:15:48.749 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 0 data:

16:15:48.750 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: -1

16:15:48.751 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 0 data:

16:15:49.655 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - read buffer: len 75 data: 02512BDCD1391AB0112F0000010FF700EA01391AB0031C01BC02512BDCD1391AB0112F0000010FEF00AA13391AB0FF1F01F302512BDCD1391AB0112F0000010FE7000000000000000000DA

16:15:49.667 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 75 data: 02512BDCD1391AB0112F0000010FF700EA01391AB0031C01BC02512BDCD1391AB0112F0000010FEF00AA13391AB0FF1F01F302512BDCD1391AB0112F0000010FE7000000000000000000DA

16:15:49.668 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 9 extended: true

16:15:49.669 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 25

16:15:49.677 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 50 data: 02512BDCD1391AB0112F0000010FEF00AA13391AB0FF1F01F302512BDCD1391AB0112F0000010FE7000000000000000000DA

216:15:49.705 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 50 data: 02512BDCD1391AB0112F0000010FEF00AA13391AB0FF1F01F302512BDCD1391AB0112F0000010FE7000000000000000000DA

16:15:49.706 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 9 extended: true

16:15:49.707 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 25

16:15:49.711 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 25 data: 02512BDCD1391AB0112F0000010FE7000000000000000000DA

316:15:49.737 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 25 data: 02512BDCD1391AB0112F0000010FE7000000000000000000DA

16:15:49.738 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 9 extended: true

16:15:49.739 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 25

16:15:49.740 [Thread-3] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 0 data:

4dbbuilder.done() is called

0fff test_modem 39.1A.B0 RESP 10101010 group: 00 ON LVL: 255 RMPRT: 28 BUTTON: 1

0ff7 test_modem 39.1A.B0 CTRL 11101010 group: 01 ON LVL: 3 RMPRT: 28 BUTTON: 1

0fef test_modem 39.1A.B0 RESP 10101010 group: 13 ON LVL: 255 RMPRT: 31 BUTTON: 1

database complete, analyzing...

0fe7 00.00.00 00.00.00 (STOP) 00000000 group: 00 ON LVL: 0 RMPRT: 0 BUTTON: 0

>>> no matching found record, no action taken!

On Monday, July 3, 2017 at 10:14:35 AM UTC-5, Eric Thomas wrote:

Daniel Pfrommer

unread,

Oct 26, 2018, 2:45:23 PM10/26/18

to insteon-terminal

Ah I see what's happening. The group number being printed there is actually the hex representation of the group number, so you probably want to use 0x13 not 13 in your method call.

That should probably be changed in the printout to include 0x before the group number to reduce confusion.

Bob Veitch

unread,

Oct 26, 2018, 3:58:39 PM10/26/18

to dan.pf...@gmail.com, insteon-...@googlegroups.com

Thanks

I did figure that out late last night...

--
You received this message because you are subscribed to a topic in the Google Groups "insteon-terminal" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/insteon-terminal/G-gI4QH50Bs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to insteon-termin...@googlegroups.com.
To post to this group, send email to insteon-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/insteon-terminal/1cd8f3f1-eb73-49a2-b552-8b6fd54ce37a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

veitc...@gmail.com

unread,

Oct 27, 2018, 1:56:53 PM10/27/18

to insteon-terminal

Another question related to the Keypad SW 8 pos.

I have one keypad sw with an issue with Button A, Which should be the load? but I can't get it to work? If I press the A button on the physical SW the load does come on and If I press the A button in the Insteon Android app that also turns on the load?

Buttons B and G work fine in OpenHab2 basic UI, but nothing from A???

Here are my Item settings and sitemap?

Any help would be greatly appreciated.

Switch keypadSwitch_k         "main load"                                          {insteonplm="42.15.52:F00.00.16#loadswitch"}
    Switch keypadSwitch_k_A   "keypad button A"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonA,group=0x01"}
    Switch keypadSwitch_k_B   "keypad button B"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonB,group=0x0F"}
    Switch keypadSwitch_k_C   "keypad button C"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonC,group="}
    Switch keypadSwitch_k_D   "keypad button D"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonD,group="}
    Switch keypadSwitch_k_E   "keypad button E"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonE,group="}
    Switch keypadSwitch_k_F   "keypad button F"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonF,group="}
    Switch keypadSwitch_k_G   "keypad button G"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonG,group=0x17"}
    Switch keypadSwitch_k_H   "keypad button H"                                    {insteonplm="42.15.52:F00.00.16#keypadbuttonH,group="}

 Frame label="Keypad_k"
                    {       Switch item=keypadSwitch_k label="main"
                            //Switch item=keypadSwitchFastOnOff label="fast on/off"
                            //Switch item=keypadSwitchManualChange label="manual change" mappings=[ 0="DOWN", 1="STOP",  2="UP"]
                            Switch item=keypadSwitch_k_A label="Button A"
                            Switch item=keypadSwitch_k_B label="Button B"
                            Switch item=keypadSwitch_k_C label="Button C"
                            Switch item=keypadSwitch_k_D label="Button D"
                            Switch item=keypadSwitch_k_E label="Button E"
                            Switch item=keypadSwitch_k_F label="Button F"
                            Switch item=keypadSwitch_k_G label="Button G"
                            Switch item=keypadSwitch_k_H label="Button H"
                    }

On Monday, July 3, 2017 at 10:14:35 AM UTC-5, Eric Thomas wrote:

veitc...@gmail.com

unread,

Oct 27, 2018, 2:06:13 PM10/27/18

to insteon-terminal

Strange, If I press C or D on OH the load comes on?

On Monday, July 3, 2017 at 10:14:35 AM UTC-5, Eric Thomas wrote:

Reply all

Reply to author

Forward