Issue creating scene on insteon on/off outlet

[randall-au]

I have run into an issue creating a scene that includes the top and bottom outlets controlled by a virtual scene in the modem. I did a join/pair on the outlet and then used the db_add_ctrl_of command to create the links like this:

`
foyer_lamps after join/pair
2020-01-22 11:12:09 UI Base: DeviceDb: (delta 46)
0fef: 53.bd.2e grp: 2 type: CTRL data: 0x03 0x00 0x02
0ff7: 53.bd.2e grp: 1 type: CTRL data: 0x03 0x00 0x01
0fff: 53.bd.2e grp: 1 type: RESP data: 0xff 0x00 0x02
Unused:
0fdf: 46.59.84 grp: 30 type: RESP data: 0xff 0x00 0x02 (UNUSED)
0fe7: 53.bd.2e grp: 2 type: CTRL data: 0x03 0x00 0x02 (UNUSED)
Last:
0fd7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
1 -> ['53.bd.2e']
2 -> ['53.bd.2e']

modem after foyer_lamps join/pair
ID: 46.59.84 grp: 1 type: CTRL data: 0x01 0x00 0x00
ID: 46.59.84 grp: 1 type: RESP data: 0x01 0x00 0x00
ID: 46.59.84 grp: 2 type: RESP data: 0x02 0x00 0x00

issue following to modem:
{ "cmd" : "db_add_ctrl_of", "local_group" : 30,
"remote_addr" : "foyer_lamps", "remote_group" : 1,
"two_way" : true, "refresh" : true }

foyer_lamps after command:
2020-01-22 11:18:50 UI Base: DeviceDb: (delta 50)
0fe7: 53.bd.2e grp: 30 type: RESP data: 0xff 0x00 0x01
0fef: 53.bd.2e grp: 2 type: CTRL data: 0x03 0x00 0x02
0ff7: 53.bd.2e grp: 1 type: CTRL data: 0x03 0x00 0x01
0fff: 53.bd.2e grp: 1 type: RESP data: 0xff 0x00 0x02
Unused:
0fdf: 46.59.84 grp: 30 type: RESP data: 0xff 0x00 0x02 (UNUSED)
Last:
0fd7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
1 -> ['53.bd.2e']
2 -> ['53.bd.2e']

modem after command:
ID: 46.59.84 grp: 1 type: CTRL data: 0x01 0x00 0x00
ID: 46.59.84 grp: 1 type: RESP data: 0x01 0x00 0x00
ID: 46.59.84 grp: 2 type: RESP data: 0x02 0x00 0x00
ID: 46.59.84 grp: 30 type: CTRL data: 0x1e 0x00 0x00

issue following to modem:
{ "cmd" : "db_add_ctrl_of", "local_group" : 30,
"remote_addr" : "foyer_lamps", "remote_group" : 2,
"two_way" : true, "refresh" : true }

foyer_lamps after command:
2020-01-22 11:22:47 UI Base: DeviceDb: (delta 51)
0fe7: 53.bd.2e grp: 30 type: RESP data: 0xff 0x00 0x02
0fef: 53.bd.2e grp: 2 type: CTRL data: 0x03 0x00 0x02
0ff7: 53.bd.2e grp: 1 type: CTRL data: 0x03 0x00 0x01
0fff: 53.bd.2e grp: 1 type: RESP data: 0xff 0x00 0x02
Unused:
0fdf: 46.59.84 grp: 30 type: RESP data: 0xff 0x00 0x02 (UNUSED)
Last:
0fd7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (UNUSED) (LAST)
GroupMap
1 -> ['53.bd.2e']
2 -> ['53.bd.2e']

modem after command:
ID: 46.59.84 grp: 1 type: CTRL data: 0x01 0x00 0x00
ID: 46.59.84 grp: 1 type: RESP data: 0x01 0x00 0x00
ID: 46.59.84 grp: 2 type: RESP data: 0x02 0x00 0x00
ID: 46.59.84 grp: 30 type: CTRL data: 0x1e 0x00 0x00
`
I would expect to see two group 30 responders in the outlet but maybe i'm wrong?

I then used the link commad to create the links manually. After that the db's look like this:

`
Modem:
ID: 46.59.84 grp: 1 type: CTRL data: 0x01 0x00 0x00
ID: 46.59.84 grp: 1 type: RESP data: 0x01 0x00 0x00
ID: 46.59.84 grp: 2 type: RESP data: 0x02 0x00 0x00
ID: 46.59.84 grp: 30 type: CTRL data: 0x02 0x39 0x44

foyer_lamps:
0fdf: 53.bd.2e grp: 30 type: RESP data: 0xff 0x1c 0x01
0fe7: 53.bd.2e grp: 30 type: RESP data: 0xff 0x1c 0x02
0fef: 53.bd.2e grp: 2 type: CTRL data: 0x03 0x00 0x02
0ff7: 53.bd.2e grp: 1 type: CTRL data: 0x03 0x00 0x01
0fff: 53.bd.2e grp: 1 type: RESP data: 0xff 0x00 0x02
`
This seems correct (to me at least) and it does actually work (i.e. turning modem scene 30 on/off does actually turn both the top and bottom outlets on/off) but only the group two device gets it's status updated.

The output of insteon MQTT looks like this:
`
2020-01-23 21:09:58 DEBUG Modem: Modem message insteon/modem/scene b'{ "cmd" : "on", "group" : 30 }'
2020-01-23 21:09:58 DEBUG MsgTemplate: Input template render: '{ "cmd" : "on", "group" : 30 }'
2020-01-23 21:09:58 INFO Modem: Modem input command: {'cmd': 'on', 'group': 30}
2020-01-23 21:09:58 INFO Modem: Modem scene 30 on=on
2020-01-23 21:09:58 INFO Protocol: Write message to modem: Modem Scene: grp: 30 cmd: 0x11 0x00
2020-01-23 21:09:58 DEBUG Protocol: Write bytes to modem: b'\x02a\x1e\x11\x00'
2020-01-23 21:09:58 DEBUG Serial: Wrote 5 bytes to serial /dev/ttyUSB0
2020-01-23 21:09:58 INFO Protocol: Read 0x61: Modem Scene: grp: 30 cmd: 0x11 0x00 ack: True
2020-01-23 21:09:58 DEBUG Protocol: Passing msg to write handler: ModemScene handler
2020-01-23 21:09:59 INFO Protocol: Read 0x58: All link status ack: 1
2020-01-23 21:09:59 DEBUG Protocol: Passing msg to write handler: ModemScene handler
2020-01-23 21:09:59 DEBUG ModemScene: Modem scene 30 command ACK
2020-01-23 21:09:59 DEBUG Modem: Found 1 responders in group 30
2020-01-23 21:09:59 DEBUG Modem: Group 30 -> ['46.59.84']
2020-01-23 21:09:59 INFO Modem: 53.bd.2e (modem) broadcast to 46.59.84 for group 30
2020-01-23 21:09:59 INFO Outlet: Setting device 46.59.84 (foyer_lamps) grp: 2 on True normal scene
2020-01-23 21:09:59 INFO Outlet: MQTT received on/off 46.59.84 (foyer_lamps) grp: 2 on: True normal 'scene'
2020-01-23 21:09:59 DEBUG Mqtt: MQTT publish insteon/46.59.84/state/2 ON qos=1 ret=1
2020-01-23 21:09:59 DEBUG Protocol: Write handler finished
2020-01-23 21:09:59 DEBUG Mqtt: MQTT writing
2020-01-23 21:09:59 INFO Protocol: Read 0x50: Std: 46.59.84 Type.CLEANUP_ACK grp: 1e cmd: 11 1e
2020-01-23 21:09:59 DEBUG Protocol: Setting next write time: 1579835399.494647
2020-01-23 21:09:59 DEBUG MsgHistory: Received 0 hops, total 0 for 11 entries
2020-01-23 21:09:59 WARNING Protocol: No read handler found for message type 0x50:

`

It looks like Insteon MQTT doesn't know group 1 is part of the scene even though the db's look correct and I have refreshed everything.

[TD22057]

Thanks. There is definitely a problem in the db creation step. I need to set up some test devices here and try out various combinations to debug it but once I get that done it should be easily fixable.

[TD22057]

FYI - I pushed a fix for this to the dev branch. I have a unit test that reproduces the behavior and shows that the fix works but I haven't had time to test it on an insteon device. Feel free to download the dev branch and try it out. I'll close the issue when I can test it on a device.

[krkeegan]

Ahh, a nifty problem I may not have run into yet.

The fix looks right. I will try and test on a keypadlinc tonight. I don't have too many multigroup devices where all groups should respond to the same controller.

[randall-au]

Has this issue ever been merged? I'm still seeing it in the latest release.