OH3: not recording/catching Insteon Montion 2 (2844-222) extended data

Hey Folks,

I’ve been banging my head off the wall for the last few weeks trying to get the battery level, battery percent, tamper switch, temperature, LowBattery, LightLevelAboveBelowThreshold and light level extended data from several Insteon Motion 2 things to be registered by OH3 (I’m new to OpenHab but not home/industrial automation stuff), the contact closure works a treat. I’ve validated that when the device is triggered that several data bursts are sent and the Insteon terminal shows all the fields of interest. I’ve tried the fixes and notes mentioned in the docs and the forums to no avail (I’m not totally sure I’m entering them in the right place or not). Two things of interest are that sometimes the data does get captured but then won’t update again, and other times multiple persistence files are created but are null.

To aid in debugging I’ve switched persistence over to MySql so I can easily monitor the tables (the multiple item persistence files occur with the jrrd files as well).

I wasn’t sure where I should post this as I am a new OH users so this could totally PEBKAC, but I also suspect there is/are a couple of bugs at play. Figured this was the best place to start.

I’ve included the Insteon binding trace log as well capturing the motion start event and the timeout event. To me it appears that the extended data is there but I do not have a current protocol doc (only one I have is from 2007) so I’m not sure.

Any help that can be offered would be most appreciated, and as an aside The work that has been done is on OpenHab is impressive Kudos to all involved :slight_smile:

EDIT: I can’t seem to post the trace log inline as its exceeds the body lenght: 2844-222-trace.txt (98.4 KB)

  • Platform information:
    • Hardware: ARMv7 Processor rev 4 (v7l)
      Hardware : BCM2835
      Revision : a020d3
      Model : Raspberry Pi 3 Model B Plus Rev 1.3
    • OS: Centos 7 (32 bit)
    • Java Runtime Environment:
      OpenJDK Runtime Environment Zulu11.43+100-CA (build 11.0.9.1+1-LTS)
      OpenJDK Client VM Zulu11.43+100-CA (build 11.0.9.1+1-LTS, mixed mode)
    • openHAB version: 3.0.0-1 from openHAB-Stable yum repo

Things JSON object

 "insteon:device:a8664baef9:5587FF": {
    "class": "org.openhab.core.thing.internal.ThingImpl",
    "value": {
      "label": "testingMotion",
      "bridgeUID": {
        "segments": [
          "insteon",
          "network",
          "a8664baef9"
        ],
        "uid": "insteon:network:a8664baef9"
      },
      "channels": [
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "batteryLevel"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:batteryLevel"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "batteryLevel"
            ],
            "uid": "insteon:batteryLevel"
          },
          "label": "Battery Level",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Number:Dimensionless",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "batteryPercent"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:batteryPercent"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "batteryPercent"
            ],
            "uid": "insteon:batteryPercent"
          },
          "label": "Battery Percent",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Contact",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "contact"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:contact"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "contact"
            ],
            "uid": "insteon:contact"
          },
          "label": "Contact",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "DateTime",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "lastHeardFrom"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:lastHeardFrom"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "lastHeardFrom"
            ],
            "uid": "insteon:lastHeardFrom"
          },
          "label": "Last Heard From",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "lightLevel"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:lightLevel"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "lightLevel"
            ],
            "uid": "insteon:lightLevel"
          },
          "label": "Light Level",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Contact",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "lightLevelAboveThreshold"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:lightLevelAboveThreshold"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "lightLevelAboveThreshold"
            ],
            "uid": "insteon:lightLevelAboveThreshold"
          },
          "label": "Light Level Above/Below Threshold",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Contact",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "lowBattery"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:lowBattery"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "lowBattery"
            ],
            "uid": "insteon:lowBattery"
          },
          "label": "Low Battery",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Contact",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "tamperSwitch"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:tamperSwitch"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "tamperSwitch"
            ],
            "uid": "insteon:tamperSwitch"
          },
          "label": "Tamper Switch",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "insteon",
              "device",
              "a8664baef9",
              "5587FF",
              "temperatureLevel"
            ],
            "uid": "insteon:device:a8664baef9:5587FF:temperatureLevel"
          },
          "channelTypeUID": {
            "segments": [
              "insteon",
              "temperatureLevel"
            ],
            "uid": "insteon:temperatureLevel"
          },
          "label": "Temperature Level",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        }
      ],
      "configuration": {
        "properties": {
          "deviceConfig": "{\u0027heartbeatOnly\u0027: true}",
          "address": "55.87.FF",
          "productKey": "F00.00.24"
        }
      },
      "properties": {},
      "uid": {
        "segments": [
          "insteon",
          "device",
          "a8664baef9",
          "5587FF"
        ],
        "uid": "insteon:device:a8664baef9:5587FF"
      },
      "thingTypeUID": {
        "segments": [
          "insteon",
          "device"
        ],
        "uid": "insteon:device"
      }
    }
  },

Item JSON object

  "testingMotion_TemperatureLevel": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Number",
		  "tags": [
		  "Point"
		  ],
		  "label": "Temperature Level"
	  },
  "testingMotion_BatteryLevel": {
		  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
		  "value": {
			  "groupNames": [
			  "testingMotion"
			  ],
			  "itemType": "Number",
			  "tags": [
			  "Point"
			  ],
			  "label": "Battery Level"
		  }
	  },
  },
  "testingMotion_BatteryPercent": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Number:Dimensionless",
		  "tags": [
		  "Point"
		  ],
		  "label": "Battery Percent"
	  }
  },
  "testingMotion_LowBattery": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Contact",
		  "tags": [
		  "Point"
		  ],
		  "label": "Low Battery"
	  }
  },
  "testingMotion_LightLevelAboveBelowThreshold": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Contact",
		  "tags": [
		  "Point"
		  ],
		  "label": "Light Level Above/Below Threshold"
	  }
  },
  "testingMotion_Contact": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Contact",
		  "tags": [
		  "Point"
		  ],
		  "label": "Contact"
	  }
  },
  "testingMotion_TamperSwitch": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Contact",
		  "tags": [
		  "Point"
		  ],
		  "label": "Tamper Switch"
	  }
  },
  "testingMotion_LastHeardFrom": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "DateTime",
		  "tags": [
		  "Point"
		  ],
		  "label": "Last Heard From"
	  }
  },
  "testingMotion": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testing"
		  ],
		  "itemType": "Group",
		  "tags": [
		  "MotionDetector"
		  ],
		  "label": "testingMotion",
		  "category": "motion"
	  }
  },
  "testingMotion_LightLevel": {
	  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
	  "value": {
		  "groupNames": [
		  "testingMotion"
		  ],
		  "itemType": "Number",
		  "tags": [
		  "Point"
		  ],
		  "label": "Light Level"
	  }
  },
**MySQL Persistence Tables that show the double entries**

MariaDB [openHabPers]> select * from items;
+--------+-------------------------------------+
| ItemId | itemname                            |
+--------+-------------------------------------+
|      1 | testingMotion_Contact               |
|      2 | testingMotion_LastHeardFrom         |
|      3 | testingMotion_BatteryLevel          |
|      4 | testingMotion_BatteryLevel          |
+--------+-------------------------------------+
23 rows in set (0.00 sec)

MariaDB [openHabPers]> show tables;
+------------------------------------------+
| Tables_in_openHabPers                    |
+------------------------------------------+
| items                                    |
| testingmotion_batterylevel_0003          |
| testingmotion_batterylevel_0004          |
| testingmotion_contact_0001               |
| testingmotion_lastheardfrom_0002         |
+------------------------------------------+
24 rows in set (0.00 sec)

MariaDB [openHabPers]> select * from testingmotion_contact_0001;
+---------------------+--------+
| time                | value  |
+---------------------+--------+
| 2021-01-17 10:32:21 | CLOSED |
| 2021-01-17 10:32:34 | OPEN   |
| 2021-01-17 10:33:03 | CLOSED |
| 2021-01-17 11:07:43 | OPEN   |
| 2021-01-17 11:08:08 | CLOSED |
+---------------------+--------+
5 rows in set (0.00 sec)

MariaDB [openHabPers]> select * from testingmotion_batterylevel_0003;
Empty set (0.00 sec)

MariaDB [openHabPers]> select * from testingmotion_batterylevel_0004;
Empty set (0.00 sec)

MariaDB [openHabPers]>

Hey, not sure if this will help or not but as I’m in the process of moving over to OH3, I also found some idiosyncrasy with the Insteon Binding in that if I have 2 items linked to the same channel, one of the item will never be updated. I can’t tell from your YAML file if you have linked your item battery_level(3 and 4) to the same channel but I would look into that.

For me, I realized that when I was doing the Add Binding -> Configure Insteon Bridge -> Add Thing -> Configure Channels / Add Items and then when doing the Model -> Add Locations -> Add Equipment, a new set of items was created for each channel which is were I was running into trouble.

How do you have your motions sensors configured? The plm/hub must be configured as both a controller and responder to be able to both receive and send massages to the devices. You can check this with the insteon display_local_database console command. Unless you are using the alternate heartbeat method, battery level, battery percentage, light level and temperature level are queried from the device when it receives a message.

As for tamper switch, you need to configure an item for this channel and a message will get sent when you take off the cover and it starts to make a noise. LightLevelAboveBelowThreshold is off by default, and a value must be configured in order to receive the event.

Here’s a copy of the developer notes:
Motion Sensor II - Developer Notes FW v46[1].pdf. This came from an export from Confluence and not all features are implemented.

Looking at the log file, I see a couple of these:

2021-01-09 13:16:07.314 [DEBUG] [nsteon.internal.device.InsteonDevice] - gave up waiting for query reply from device 55.87.FF

Looks like the binding sent the request, but never received a reply.

Hi Rob,

I should have mentioned, but yes the PLM and sensor are paired bidirectionally…and when the insteon terminal is used the light level, and other extend data is updated. Which leads me to believe that there is something up either with the binding or OH3 not processing the data as it sometimes does. FYI…the motion sensor I’m testing with is plugged in with usb so its always awake and responsive.

I’m also using the alt heartbeat in the thing config:

( {'heartbeatOnly': true})`

Thanks for the dev docs…will take al look sometime this week to see if I can decode the packets that OH is receiveing.

Cheers,
Mike

Thanks for that Jacques,

Where are you seeing the double bind in the above (I just noticed I accidentally included a second battery level item from a different sensor)? The double persistence issue also happens with other devices as well.

Yeah, that gave me some grief at first too…now I just create the items when adding from the map ;p

Per the documentation, you have to enable the alternate heartbeat, and if you use this the device won’t be queried. BTW, it’s disabled by default. You need to send the command to enable the alternate heartbeat group (20 0A). You can do this with the console command:

smarthome:insteon send_extended_message AA.BB.CC 15 20 0A

Also, by default the heartbeat is sent every 23.8 hours, and minimum is every 23 minutes. You can lower this by with the low battery and heartbeat settings (2E 00 00 09). The following console command sets the heartbeat to every 23 minutes:

smarthome:insteon send_extended_message 54.69.D5 0F 2E 00 00 09 85 01

I’ve been using MS 2 for months now and I’m not having any problems. Also something isn’t set up correctly, I see two of these in the log file you shared:

2021-01-09 13:15:38.397 [DEBUG] [nsteon.internal.device.InsteonDevice] - gave up waiting for query reply from device 55.87.FF

Mike,

Just to be clear, I did not noticed a double bind in your code other then for the double entry of the battery level. I was simply stating that for me, in the Insteon binding, any channel where two items are defined, one will not work. I found another one this morning where I had frontLightsxx and InsteonFrontLightSwitchxxx defined on the same channel. No errors in any logs but the frontLights never received any update and sending a command to it never did anything. I deleted it and used the InsteonFrontLightSwitchxxx in my rules and everything is fine now.

Rob, can you clarify if the binding should support one channel to multiple items? I cannot find documentation to support this one way or the other.

It works the same as all other bindings. It only knows about channels, I’ve had multiple items linked to a single channel with no problems.

@mlindsay, did you figure out what was going on?

Hi Rob,

Sorry been absolutely slammed at work and haven’t had a chance to look yet, will revisit this weekend.

Cheers,
Mike

Thanks for clarifying jacques, was confused for a bit there ;p

Hi Rob,

So no luck with that…same results. So I have factory reset the modem and ms2, wiped and did a clean reinstall of OH3, re-paired the modem and ms2, and used the openhab-cli to issue the alt heartbeat as above. Still have the same result, the OH3 config only has the PLM and the MS2 configured (with {‘heartbeatOnly’: true} set or unset I get the same results).

Couple of things of note:

when I send:
openhab> openhab:insteon send_extended_message 55.87.FF 15 20 0A
openhab> openhab:insteon send_extended_message 55.87.FF 0F 2E 00 00 09 85 01

the 2844-222-trace_altHeartbeat_enable.txt (44.6 KB) shows the first command 15 20 0A seems to be accepted but with one line:
2021-01-24 11:48:50.089 [DEBUG] [steon.internal.device.MessageHandler] - DefaultMsgHandler ignoring unimpl message with cmd1:0x20

however when openhab> openhab:insteon send_extended_message 55.87.FF 0F 2E 00 00 09 85 01 is sent the logs show the 0F is being sent as 1F and additional padding (I have no idea it that is expected or not):
2021-01-24 11:48:59.425 [TRACE] [.insteon.internal.message.MsgFactory] - keeping buffer len 11 data: 02 62 55 87 FF 1F 2E 00 00 09 85 01 00 00 00 00 00 00 00 00 00 43 06

and further down

2021-01-24 11:48:59.967 [TRACE] [steon.internal.device.MessageHandler] - MotionSensorDataReplyHandler device 55.87.FF ignoring non-extended msg IN:Cmd:0x50|fromAddress:55.87.FF|toAddress:53.BF.99|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x2E|command2:0x00|

I’ve also validated that the MS2 is not sending an alt heartbeat by watching the insteon terminal (with openhab stop of course) for a couple of hours this morning with it both on battery and tethered via usb power which I think is related to the above.

I’m going to wipe the persistence db again and let the sensor sit (on battery, not tethered) for a few days to see if it heartbeats at all, if openhab doesn’t show any data for battery, light or temp after 24+ hours then I’ll stop openhab and repeat the test with the Insteon Terminal in watch mode to see if anything comes across the wire.

Insteon terminal

modem.getdb()
0000 testingMotion 55.87.FF RESP 10100010 group: 01 data: 00 00 00
0000 testingMotion 55.87.FF CTRL 11100010 group: 01 data: 10 16 47
Modem Link DB complete
testingMotion.getdb()
getting db, be patient!
sent db query msg, incoming records: 1 2 3dbbuilder.done() is called
00ff modem 53.BF.99 CTRL 11101010 group: 01 ON LVL: 3 RMPRT: 0 BUTTON: 0
00f7 modem 53.BF.99 RESP 10101010 group: 01 ON LVL: 3 RMPRT: 0 BUTTON: 0
00ef 00.00.00 00.00.00 (STOP) 00000000 group: 00 ON LVL: 0 RMPRT: 0 BUTTON: 0

As you can see the modem and the ms2 are cross-linked and are the only paired things on the insteon network, they are also the only things configured in OpenHab3 as well.

One thing has changed though…when I trigger the ms2 sensor the ‘gave up’ message no longer appears. But multiple persistence tables are still being created sometimes, but not always.:

iMariaDB [openHabPers]> select * from items;
+--------+------------------------------+
| ItemId | itemname                     |
+--------+------------------------------+
|      1 | testingMotion_LastHeardFrom  |
|      2 | testingMotion_BatteryPercent |
|      3 | testingMotion_LightLevel     |
|      4 | testingMotion_LightLevel     |
|      5 | testingMotion_BatteryLevel   |
|      6 | testingMotion_BatteryLevel   |
|      7 | testingMotion_Contact        |
+--------+------------------------------+
7 rows in set (0.01 sec)

MariaDB [openHabPers]> show tables;
+-----------------------------------+
| Tables_in_openHabPers             |
+-----------------------------------+
| items                             |
| testingmotion_batterylevel_0005   |
| testingmotion_batterylevel_0006   |
| testingmotion_batterypercent_0002 |
| testingmotion_contact_0007        |
| testingmotion_lastheardfrom_0001  |
| testingmotion_lightlevel_0003     |
| testingmotion_lightlevel_0004     |
+-----------------------------------+
8 rows in set (0.00 sec)

All the battery and light level tables are empty.

If the thing doesn’t heartbeat then I think I’ll move to the testing rpm branch and repeat (and then roll down to OH2 it if still doesn’t work, just for validation) unless there is something else you can recommend to try.

Cheers and thanks,
Mike

The motion sensor 2 code is basically the same code as the motion sensor, other than the extended query that is sent to the device (0x2e03 vs 0x0200). The motion sensor code hasn’t changed in years, and there is no difference between OH2 and OH3, in matter of fact, the code is essentially the same as the OH1 code. You can check it out for yourself at openhab-addons/MessageHandler.java at main · openhab/openhab-addons · GitHub and openhab-addons/MessageHandler.java at main · openhab/openhab-addons · GitHub

I don’t doubt you at all, I’m just absolutely stumped as to what is going on here and where the issue actually is…hence the thought of moving between versions.

I’m still confused as to why when openhab> openhab:insteon send_extended_message 55.87.FF 0F 2E 00 00 09 85 01 is sent the logs show the 0F is being sent as 1F

2021-01-24 11:48:59.425 [TRACE] [.insteon.internal.message.MsgFactory] - keeping buffer len 11 data: 02 62 55 87 FF 1F 2E 00 00 09 85 01 00 00 00 00 00 00 00 00 00 43 06

I’m not a java programmer (mainly rust, C, php, and assembly) and I find the language totally incomprehensible (not ment as a slight or to be offensive) to me, so I’m not sure what else to do here or what direction to go in, normally I would start debugging the code running an IDE with break points to see if I could see where the problem manifests but for me with java that’s not an option (agian not knocking java here ;p).

It’s obvious that OH3 and MS3 work just fine, but why not in my case. All I can figure is there is something either off with the CentOS 7 builds, or the firmware revisions on my PLM and MS2 are newer then what has been tested (I’m leaning towards this as there are some weird inconsistencies when trying to set the bit configs via the insteon terminal).

If you have a second would you mind comparing your revs with mine below:

MotionSensor 2 fw rev: R3.4 1719
PLM fw rev: R2.5 1719

I really doubt its anything to do with the firmware. My motion sensor’s firmware is the same as yours, I’ve had my PLM for years. Best guess is that you have your motion sensor in a weird state. Try again to factory reset the motion sensor, repair both ways with the device and see if you can get it to work. Instead of looking in the database, what shows up in the events.log file.

Also what do you see for the device with the console commands:

insteon display_local_database
insteon display_devices
insteon display_channels

Hi Rob,

I’ve factory reset both the modem and the MS2 (third time the charm maybe?) and applied the alt heartbeat config to the MS2 as above. Here is the output from the openhab cli (identical to what it was before):

openhab> insteon display_local_database                                                                                                                                         
local database contains 2 entries
53.BF.99: plm (/dev/insteonPLM)
55.87.FF: plm controls groups (1) and responds to groups (1)

openhab> insteon display_devices                                                                                                                                                
insteon:device:d76ce8fb2b:5587FF address = 55.87.FF productKey = F00.00.24 channels = batteryLevel, batteryPercent, contact, lastHeardFrom, lightLevel, lightLevelAboveThreshold, lowBattery, tamperSwitch, temperatureLevel

openhab> insteon display_channels                                                                                                                                               
insteon:device:d76ce8fb2b:5587FF:batteryLevel feature = data parameters = {field=battery_level}
insteon:device:d76ce8fb2b:5587FF:batteryPercent feature = data parameters = {field=battery_percentage}
insteon:device:d76ce8fb2b:5587FF:contact feature = contact parameters = {}
insteon:device:d76ce8fb2b:5587FF:lastHeardFrom feature = lastheardfrom parameters = {}
insteon:device:d76ce8fb2b:5587FF:lightLevel feature = data parameters = {field=light_level}
insteon:device:d76ce8fb2b:5587FF:lightLevelAboveThreshold feature = lightlevelabovethreshold parameters = {}
insteon:device:d76ce8fb2b:5587FF:lowBattery feature = lowbattery parameters = {}
insteon:device:d76ce8fb2b:5587FF:tamperSwitch feature = tamperswitch parameters = {}
insteon:device:d76ce8fb2b:5587FF:temperatureLevel feature = data parameters = {field=temperature_level}
openhab>  

so far the event.log is only showing data for the contact and last hear from events. I’ll let it sit over night to see if it heartbeats and populates the light, temp, and battery values.

Cheers,
Mike

I see you are using the same group for both controller and responder. I think this is what’s causing your problems. I wouldn’t be surprised if this is causing the PLM to consume the poll message that is intended to be sent to the motion sensor. FWIW, here’s what I have:

openhab> insteon display_local_database | grep 54.69.D5
54.69.D5: plm controls groups (254) and responds to groups (1)
openhab> insteon display_devices | grep 54.69.D5
insteon:device:home:5469D5 address = 54.69.D5 productKey = F00.00.24 channels = batteryLevel, batteryPercent, contact, lastHeardFrom, lightLevel, lightLevelAboveThreshold, lowBattery, tamperSwitch, temperatureLevel
openhab> insteon display_channels | grep 5469D5
insteon:device:home:5469D5:batteryLevel feature = data parameters = {field=battery_level}
insteon:device:home:5469D5:batteryPercent feature = data parameters = {field=battery_percentage}
insteon:device:home:5469D5:contact feature = contact parameters = {}
insteon:device:home:5469D5:lightLevel feature = data parameters = {field=light_level}
insteon:device:home:5469D5:temperatureLevel feature = data parameters = {field=temperature_level}

That makes complete sense, I’ve used the insteon terminal to change the CTRL group for the MS2 but still no go. I think your definitely on to something, duplicated messages could account for the multiple persistence tables being created (still empty though).

openhab> insteon display_local_database                                                                                                                                         
local database contains 2 entries
53.BF.99: plm (/dev/insteonPLM)
55.87.FF: plm controls groups (254) and responds to groups (1)

modem.getdb()
0000 testingMotion 55.87.FF RESP 10100010 group: 01 data: 00 00 01
0000 testingMotion 55.87.FF CTRL 11100010 group: fe data: 00 00 fe
Modem Link DB complete

I have another RPi 3+ coming tomorrow and I’ll throw openHABian on it and see if the problem still exist without changing the config on the MS2 or PLM.

FYI: I just saw this in the logs:

2021-01-26 17:03:41.283 [DEBUG] [ding.insteon.internal.InsteonBinding] - device 53.BF.99 found in the modem database, but is not configured as a thing and it is the plm (/dev/insteonPLM).

I have no idea if this is part of the issue or not, but it keeps re adding the plm to the inbox on every restart.

I’d suggest that you abandon anything with the alternate heartbeat, both enabling it on the MS2 and setting it in the config for the thing. Then you can focus on getting it working with polling for the extended message. After you get that working, you can then try and get the alternate heartbeat working, and disabled.

As for the other device, it shouldn’t cause any issues.