[insteon] show Air Gapped and unplugged devices as "OFFLINE" on "Things" page with correct "lastHeardFrom" log entry.

[norem]

Currently, devices that are AIR Gapped (powered off by pulling set button on device) or physically unplugged show as "ONLINE" on "Things" Page and logs show a "lastHeardFrom" entry on every poll of the disconnected device..

Suggest that devices show as "OFFLINE" on "Things" page similar to the Android Insteon app, so one is able to quickly see if a device has been unplugged, gone bad, or has been air gapped and "lastHeardFrom" in logs show the last time entry when a device is "last" heard from and not just validation there is an entry for it in the Hub ALDB.

NOTES:

It appears that the Android Insteon App may be using the receipt of a cmd of 0x5C with 3 hops, and echoed 0x19 to decide if a thing/device is not available or disconnected, logs show the same response from the app as does the normal polling routine.

"lastHeardFrom" appears to only query the HUB if there is an entry in the ALDB to which it responds that there is.
"Things" page appears to only validate if the device has been initialized and an entry in the ALDB to show it is "ONLINE" and not if it can actually be communicated with ie. a status request.

Although there is code to look for timeout of device response, disconnected and non responsive devices status is returned by the Hub, not with the expected cmd: 0x50 (standard message) but reliably with cmd 0x5c noted in the code as an (unknown message) this is unfortunately not documented in any of the developer note.

All of my testing via openHab "insteon start_monitoring all" command , and allowing openHab to do its 5 minute polling.

All of my disconnected units so far have a response of cmd: of 0x5C (standard message) with 3 hops (max allowed hops for a device, and echoed 0x19 (status request).

Both of the following log entries are the same device, the first is plugged in and working, the next is unplugged.

`
2022-07-17 11:52:01.156 IN:Cmd:0x50|fromAddress:40.11.B6|toAddress:39.37.D5|messageFlags:0x20=ACK_OF_DIRECT:0:0|command1:0x00|command2:0xFF|

2022-07-17 11:52:07.275 IN:Cmd:0x5C|fromAddress:40.12.8B|toAddress:39.37.D5|messageFlags:0x23=ACK_OF_DIRECT:3:0|command1:0x19|command2:0x00|
`

To duplicate results, simply enter "insteon start_monitoring all" at the openHab prompt, allow to run a few polling cycles (about 15 minutes) then unplug or air gap a few switches and watch the log for another 15 minutes. noting the changes in the displayed information.

I'm currently using Windows 10 and 11 with version openhab-3.4.0 snapshot with openhab-3.4.0.kar with Insteon Hub II

I do not have anything other than the Hub II to test with so don't know what the results with a PLM are but suspect the same.

Devices in question, have all been properly added to the Hub II using the Android Insteon App and if unplugged show as disconnected in the Insteon Android app.

I have recently asked the community guidance to see if my configuration is incorrect, and have received no replies, so have to assume it's not a setting issue.

[lsiepel]

@norem i'm not sure if this issue is fixed by @jsetton in his rewrite if the binding here: #17146
But it would be great if you test that verison of the binding and if not already fixed, @jsetton might be able to comment on the request.

[jsetton]

@lsiepel This issue can be closed. My rewrite handles this case.
After 5 consecutive failed message reports received, the related device will show as OFFLINE with reason "Device not responding."

@norem has also confirmed that it worked as expected.