INSTEON 2443-222 Micro On/Off Module

Hey all,
Does anyone have any information on how to create the item for an INSTEON 2443-222 Micro On/Off Module? I’ve looked through the insteon plm binding setup but don’t see it. The module controls a bathroom vent and DOES work when using the on and off buttons on the module. I am using a plm u as the controller and see that it is added to the modem database but can’t seen to actually control it through openhab. Any help is appreciated. Thanks!

Pretend it is a 2477S switch, and follow the insteonplm binding’s wiki. If that gives you all the functionality you are looking for, pretty please let us know so we can add it to the list of supported devices.

Thank you, I will test it this evening and post back with the results. I will try using this product key:

2477S SwitchLinc Switch F00.00.02 Bernd Pfrommer

Hmm, No response from the device. :confused:

Here is the trace from insteonplm.log filtered for just that device ID:

2016-04-04 20:27:03 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item “UnderStairVent” read from .items file with cfg string 3B.12.08:F00.00.02#switch
2016-04-04 20:27:14 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item UnderStairVent binding changed: addr=3B.12.08|prodKey:F00.00.02|feature:switch
2016-04-04 20:27:14 TRACE o.o.b.i.i.device.InsteonDevice[:119]- setting poll interval for 3B.12.08 to 300000
2016-04-04 20:27:15 DEBUG o.o.b.i.InsteonPLMActiveBinding[:581]- got msg: IN:Cmd:0x57|RecordFlags:0xA2|ALLLinkGroup:0x01|LinkAddr:3B.12.08|LinkData1:0x00|LinkData2:0x00|LinkData3:0x00|
2016-04-04 20:27:15 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 3B.12.08: RESP group: 01 data1: 00 data2: 00 data3: 00
2016-04-04 20:27:15 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 3B.12.08
2016-04-04 20:27:15 INFO o.o.b.i.InsteonPLMActiveBinding[:611]- device 3B.12.08 found in the modem database and the modem responds to groups [0x01].
2016-04-04 20:27:15 DEBUG o.o.b.i.internal.driver.Poller[:64]- start polling device 3B.12.08|fastonoff->FastOnOff(0:1:2)|lastheardfrom->GenericLastTime(0:0:0)|switch->GenericSwitch(1:1:6)
2016-04-04 20:27:15 TRACE o.o.b.i.internal.driver.Poller[:126]- added entry 3B.12.08/Mon Apr 04 20:28:30 CDT 2016 originally aimed at time Mon Apr 04 20:28:30 CDT 2016
2016-04-04 20:27:15 TRACE o.o.b.i.internal.driver.Poller[:208]- waiting for 74999 msec until 3B.12.08/Mon Apr 04 20:28:30 CDT 2016 comes due
2016-04-04 20:27:15 TRACE o.o.b.i.internal.driver.Poller[:208]- waiting for 74999 msec until 3B.12.08/Mon Apr 04 20:28:30 CDT 2016 comes due
2016-04-04 20:28:30 TRACE o.o.b.i.internal.driver.Poller[:211]- entry 3B.12.08/Mon Apr 04 20:28:30 CDT 2016 expired at time 1459819710038
2016-04-04 20:28:30 TRACE o.o.b.i.i.device.DeviceFeature[:232]- GenericSwitch making poll msg for 3B.12.08 using handler FlexPollHandler
2016-04-04 20:28:30 TRACE o.o.b.i.i.d.RequestQueueManager[:51]- scheduling request for device 3B.12.08 in -1 msec
2016-04-04 20:28:30 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: GenericSwitch(1:1:6) OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:28:30 TRACE o.o.b.i.internal.driver.Poller[:126]- added entry 3B.12.08/Mon Apr 04 20:33:30 CDT 2016 originally aimed at time Mon Apr 04 20:33:30 CDT 2016
2016-04-04 20:28:30 TRACE o.o.b.i.internal.driver.Port[:201]- enqueued msg: OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:28:30 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:28:30 TRACE o.o.b.i.i.d.RequestQueueManager[:128]- device queue for 3B.12.08 rescheduled in 500 msec
2016-04-04 20:28:30 TRACE o.o.b.i.i.d.RequestQueueManager[:109]- request queue head: 3B.12.08 must wait for 499 msec
2016-04-04 20:28:30 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 3B.12.08 is empty!
2016-04-04 20:32:15 TRACE o.o.b.i.internal.driver.Poller[:208]- waiting for 75001 msec until 3B.12.08/Mon Apr 04 20:33:30 CDT 2016 comes due
2016-04-04 20:33:30 TRACE o.o.b.i.internal.driver.Poller[:211]- entry 3B.12.08/Mon Apr 04 20:33:30 CDT 2016 expired at time 1459820010039
2016-04-04 20:33:30 TRACE o.o.b.i.i.device.DeviceFeature[:232]- GenericSwitch making poll msg for 3B.12.08 using handler FlexPollHandler
2016-04-04 20:33:30 TRACE o.o.b.i.i.d.RequestQueueManager[:51]- scheduling request for device 3B.12.08 in 0 msec
2016-04-04 20:33:30 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 3B.12.08
2016-04-04 20:33:30 TRACE o.o.b.i.internal.driver.Poller[:126]- added entry 3B.12.08/Mon Apr 04 20:38:30 CDT 2016 originally aimed at time Mon Apr 04 20:38:30 CDT 2016
2016-04-04 20:33:30 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: GenericSwitch(1:1:6) OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:33:30 TRACE o.o.b.i.internal.driver.Port[:201]- enqueued msg: OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:33:30 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:33:30 TRACE o.o.b.i.i.d.RequestQueueManager[:128]- device queue for 3B.12.08 rescheduled in 500 msec
2016-04-04 20:33:30 TRACE o.o.b.i.i.d.RequestQueueManager[:109]- request queue head: 3B.12.08 must wait for 499 msec
2016-04-04 20:33:30 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 3B.12.08 is empty!
2016-04-04 20:34:44 TRACE o.o.b.i.i.device.DeviceFeature[:222]- GenericSwitch uses LightOnOffCommandHandler to handle command OnOffType for 3B.12.08
2016-04-04 20:34:44 INFO o.o.b.i.i.d.CommandHandler[:161]- LightOnOffCommandHandler: sent msg to switch 3B.12.08 to on
2016-04-04 20:34:44 INFO o.o.b.i.i.d.CommandHandler[:180]- Sending message to 3B.12.08
2016-04-04 20:34:44 TRACE o.o.b.i.i.d.RequestQueueManager[:51]- scheduling request for device 3B.12.08 in 0 msec
2016-04-04 20:34:44 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 3B.12.08
2016-04-04 20:34:44 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: GenericSwitch(1:1:6) OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x11|command2:0xFF|
2016-04-04 20:34:44 TRACE o.o.b.i.internal.driver.Port[:201]- enqueued msg: OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x11|command2:0xFF|
2016-04-04 20:34:44 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x11|command2:0xFF|
2016-04-04 20:34:44 TRACE o.o.b.i.i.d.RequestQueueManager[:128]- device queue for 3B.12.08 rescheduled in 2000 msec
2016-04-04 20:34:44 TRACE o.o.b.i.i.d.RequestQueueManager[:109]- request queue head: 3B.12.08 must wait for 1999 msec
2016-04-04 20:34:46 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 3B.12.08 is empty!
2016-04-04 20:37:15 TRACE o.o.b.i.internal.driver.Poller[:208]- waiting for 75001 msec until 3B.12.08/Mon Apr 04 20:38:30 CDT 2016 comes due
2016-04-04 20:38:10 TRACE o.o.b.i.i.device.DeviceFeature[:222]- GenericSwitch uses LightOnOffCommandHandler to handle command OnOffType for 3B.12.08
2016-04-04 20:38:10 INFO o.o.b.i.i.d.CommandHandler[:165]- LightOnOffCommandHandler: sent msg to switch 3B.12.08 off
2016-04-04 20:38:10 INFO o.o.b.i.i.d.CommandHandler[:180]- Sending message to 3B.12.08
2016-04-04 20:38:10 TRACE o.o.b.i.i.d.RequestQueueManager[:51]- scheduling request for device 3B.12.08 in 0 msec
2016-04-04 20:38:10 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 3B.12.08
2016-04-04 20:38:10 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: GenericSwitch(1:1:6) OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x13|command2:0x00|
2016-04-04 20:38:10 TRACE o.o.b.i.internal.driver.Port[:201]- enqueued msg: OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x13|command2:0x00|
2016-04-04 20:38:10 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x13|command2:0x00|
2016-04-04 20:38:10 TRACE o.o.b.i.i.d.RequestQueueManager[:128]- device queue for 3B.12.08 rescheduled in 2000 msec
2016-04-04 20:38:10 TRACE o.o.b.i.i.d.RequestQueueManager[:109]- request queue head: 3B.12.08 must wait for 2000 msec
2016-04-04 20:38:12 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 3B.12.08 is empty!
2016-04-04 20:38:30 TRACE o.o.b.i.internal.driver.Poller[:211]- entry 3B.12.08/Mon Apr 04 20:38:30 CDT 2016 expired at time 1459820310039
2016-04-04 20:38:30 TRACE o.o.b.i.i.device.DeviceFeature[:232]- GenericSwitch making poll msg for 3B.12.08 using handler FlexPollHandler
2016-04-04 20:38:30 TRACE o.o.b.i.i.d.RequestQueueManager[:51]- scheduling request for device 3B.12.08 in 0 msec
2016-04-04 20:38:30 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 3B.12.08
2016-04-04 20:38:30 TRACE o.o.b.i.internal.driver.Poller[:126]- added entry 3B.12.08/Mon Apr 04 20:43:30 CDT 2016 originally aimed at time Mon Apr 04 20:43:30 CDT 2016
2016-04-04 20:38:30 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: GenericSwitch(1:1:6) OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:38:30 TRACE o.o.b.i.internal.driver.Port[:201]- enqueued msg: OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:38:30 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-04-04 20:38:30 TRACE o.o.b.i.i.d.RequestQueueManager[:128]- device queue for 3B.12.08 rescheduled in 500 msec
2016-04-04 20:38:30 TRACE o.o.b.i.i.d.RequestQueueManager[:109]- request queue head: 3B.12.08 must wait for 499 msec
2016-04-04 20:38:30 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 3B.12.08 is empty!
2016-04-04 20:39:25 TRACE o.o.b.i.i.device.DeviceFeature[:222]- GenericSwitch uses LightOnOffCommandHandler to handle command OnOffType for 3B.12.08
2016-04-04 20:39:25 INFO o.o.b.i.i.d.CommandHandler[:161]- LightOnOffCommandHandler: sent msg to switch 3B.12.08 to on
2016-04-04 20:39:25 INFO o.o.b.i.i.d.CommandHandler[:180]- Sending message to 3B.12.08
2016-04-04 20:39:25 TRACE o.o.b.i.i.d.RequestQueueManager[:51]- scheduling request for device 3B.12.08 in 0 msec
2016-04-04 20:39:25 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 3B.12.08
2016-04-04 20:39:25 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: GenericSwitch(1:1:6) OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x11|command2:0xFF|
2016-04-04 20:39:25 TRACE o.o.b.i.internal.driver.Port[:201]- enqueued msg: OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x11|command2:0xFF|
2016-04-04 20:39:25 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:3B.12.08|messageFlags:0x0F=DIRECT:3:3|command1:0x11|command2:0xFF|
2016-04-04 20:39:25 TRACE o.o.b.i.i.d.RequestQueueManager[:128]- device queue for 3B.12.08 rescheduled in 2000 msec
2016-04-04 20:39:25 TRACE o.o.b.i.i.d.RequestQueueManager[:109]- request queue head: 3B.12.08 must wait for 2000 msec
2016-04-04 20:39:27 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 3B.12.08 is empty!


.item file:
Switch UnderStairVent “Under-Stair Vent” {insteonplm=“3B.12.08:F00.00.02#switch”}

.sitemap:
Switch item=UnderStairVent

.rules:
rule "Fan Logging"
when
Item UnderStairVent received update
then
logInfo(“VENT”,“VENT state:”+UnderStairVent)
end

openhab.log:
2016-04-04 20:38:10.802 [INFO ] [org.openhab.model.script.VENT ] - VENT state:UnderStairVent (Type=SwitchItem, State=OFF)
2016-04-04 20:39:25.043 [INFO ] [org.openhab.model.script.VENT ] - VENT state:UnderStairVent (Type=SwitchItem, State=ON)

Have you tried using F00.00.01 ?
I have Micro Up/Down modules installed for my roller shutters and got them working using F00.00.01#dimmer.

Looks like the modem is configured to listen for messages from the device (it as linked as a “responder”), but I don’t see a database entry that it is also configured as a “controller”. That could be the problem. Try linking it both ways, as a controller and a responder.

robinson:

Good to know, I’ll try using F00.00.01#dimmer. Were you able to get your Up/Down module linked as a responder?

After a lot of testing last night, that’s exactly what seems to be going on. I used F00.00.02 and was able to send the ON command from openhab to the switch but openhab would just sit there and wait. When it was waiting, I clicked the “on” button on the switch and Openhab recognized it and I got a Successful message in the openhab.log. It’s good to know its communicating, however, I have yet to be able to get the on/off switch linked as a responder. It will set up as a controller just fine.

I did a factory reset on the switch:
All settings, links and scenes will be erased.

  1. Press and hold Micro module Set button until it beeps
    LED will start blinking green
  2. Press and hold Micro module Set button until it beeps again
    LED will start blinking red
  3. Press and hold Micro module Set button until it beeps a third time
    LED will start blinking green
  4. Slowly tap Micro module Set button 3 times
    LED will start double-blinking green
  5. Press and hold Micro module Set button. Do not let go.
    Micro module will begin to emit a long beep
  6. After beep stops, release Micro module Set button
    After a few seconds, the LED will flash white
    Micro module will double-beep and the load will turn on

THEN

Remove Micro Module as a Controller
If you no longer want Micro module to control another device (or are removing Micro module from your network) it is
Important that you follow the instructions below for each responder.

  1. Press and hold Micro module Set button until it beeps
    LED will start blinking green
  2. Press and hold Micro module Set button until it beeps again
    LED will start blinking red
  3. Press and hold responder Set button until it double-beeps
    Micro module will double-beep and LED will stop blinking
  4. Test by tapping Micro module on and off
    Former responder will not respond

THEN

Make Micro Module a Responder (Switch)

  1. Press and hold controller Set button until it beeps
    Controller LED will start blinking
    You will have four minutes to complete the next steps before linking mode times out
  2. Adjust load connected to Micro module to desired level (on or off)
  3. Quickly tap switch connected to Micro module exactly five times in less than four seconds. (If using a latching or
    dual momentary switch, alternate switch directions: up-down-up-down-up or down-up-down-up-down.) After
    tapping switch, wait two seconds.
    Micro module will double-beep
    Controller will double-beep and its LED will stop blinking
  4. Test link by tapping controller button on and off
    Load connected to Micro module will turn on and off

I keep getting a message in openhab to the effect of “did you link the device?”

I’m thinking this may be more of a device issue than and openhab one…I feel like I’m using the proper instructions…Thoughts?

If the binding says “not in link database”, then it isn’t, and somehow the linking process didn’t /doesn’t work. Apparently this time the modem doesn’t even know it as a controller.

Do you have any other insteon devices to hook up to openhab? That way you’ll see how a healthy link database looks like: one entry for controller, one for responder.

There is another tool out there on github, called InsteonTerminal. It allows you to inspect the databases in more detail and do other funky stuff. It’s for developers mostly though, so not very polished. I use it as a tool to explore device functionality. You need to know python a bit.

I would say try again, linking it both ways: so long press the switch, then the modem. Afterwards, long press the modem, then the switch. You can hear the happy double-beep when the link succeeds.

Oh, I see. This device does not have a single button to press. You have to do a little rain dance. Now that’s interesting. Either way, listen for the double-beep from the modem. You don’t have to have it plugged into your computer, you can plug it into the nearest outlet while linking.

Thanks for the tips!

  1. InsteonTerminal sounds like a good tool and I know python, I’ll check it out.

2,.What a relief that I can plug the plm into ANY outlet for the linking process, lol… I probably went up and down the stairs 50 times last night.

I’ll give it another go when I get home this evening, Oh and Yes I have 2 insteon motion sensors working with the plm and openhab that function perfectly.

HAHA! SUCCESS! :smile:

This is the first device that has actually been hard-wired so the advice to plug the PLM into an outlet next to the switch was a BIG help, Thank You.

Here is my setup that is now working:

Product:
INSTEON 2443-222 Micro On/Off Module

.item
Switch UnderStairVent “Under-Stair Vent” {insteonplm=“3B.12.08:F00.00.02#switch”}

Instructions to link the Device properly as a responder:

Make Micro Module a Responder (Set button) - (If you CAN get to it inside the junction box)
Note: you must perform these steps before reinstalling the wall switch, outlet or fixture.

  1. Press and hold controller Set button until it beeps
    Controller LED will start blinking
    You will have four minutes to complete the next steps before linking mode times out
  2. Adjust load connected to Micro module to desired brightness level (even off)
  3. Press and hold Micro module Set button until it double-beeps Controller will double-beep and its LED will stop blinking
  4. Test link by tapping controller button on and off Load connected to Micro module will respond appropriately

Make Micro Module a Responder (Switch) - (If you CAN’T get to it inside the junction box)

  1. Press and hold controller Set button until it beeps Controller LED will start blinking You will have four minutes to complete the next steps before linking mode times out
  2. Adjust load connected to Micro module to desired level (on or off)
  3. Quickly tap switch connected to Micro module exactly five times in less than four seconds. (If using a latching or dual momentary switch, alternate switch directions: up-down-up-down-up or down-up-down-up-down.) After tapping switch, wait two seconds. Micro module will double-beep Controller will double-beep and its LED will stop blinking
  4. Test link by tapping controller button on and off Load connected to Micro module will turn on and off
1 Like

Glad to hear you got it working.

If you want the PLM modem to learn when the device has been switched manually (and you usually want that), you will need to link the PLM as a responder as well.
Could you please post the insteonplm binding’s logging lines regarding the modem database? Are there two entries now, one for responder, one for controller?

Good to know. Here are the entries, I have the PLM, the switch and 2 motion sensors.

I see that it is just set up as a responder. I’ll try to link it both ways. Thanks!

2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:104]- got all link records.
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:130]- MDB ------- start of modem link records ------------------
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 31.91.B0: CTRL group: 01 data1: 10 data2: 01 data3: 01
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 31.91.B0: RESP group: 01 data1: 10 data2: 01 data3: 01
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:142]- MDB -----
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 3B.12.08: RESP group: 01 data1: 00 data2: 00 data3: 00
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:142]- MDB -----
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 31.7F.86: CTRL group: 01 data1: 10 data2: 01 data3: 01
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 31.7F.86: RESP group: 01 data1: 10 data2: 01 data3: 01
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:142]- MDB -----
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:142]- MDB -----
2016-04-04 20:57:49 DEBUG o.o.b.i.i.d.ModemDBBuilder[:144]- MDB ---------------- end of modem link records -----------
2016-04-04 20:57:49 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 31.91.B0
2016-04-04 20:57:49 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 3B.12.08
2016-04-04 20:57:49 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 31.7F.86
2016-04-04 20:57:49 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 39.55.91
2016-04-04 20:59:49 TRACE o.o.b.i.i.d.ModemDBBuilder[:77]- exiting modem db builder thread