I have a triggerlinc in HA that seems to have been picked up but I don't see it in devices or entities. I do see it in the insteon_devices.json, as follows:

{
"address": "13e6e2",
"cat": 0,
"subcat": 0,
"firmware": 0,
"engine_version": 3,
"aldb_status": 1,
"aldb": {},
"operating_flags": {},
"properties": {}
}

The category, etc. are 0 so maybe that is why .. not defined in HA or something or maybe not defined in pyinsteon.

The only state specific types needed are:

• OnLevel (int)
• OnOff (bool)
• Enum (list type so could become an Enum type)
• Float (float)

The following states can be eliminated and mapped as follows:

• FanOnLevel -> Enum
• NormallyOpen -> OnOff
• NormallyClosed -> OnOff
• Temperature -> Float
• Humidity -> Float
• SetPoint -> Float
• SystemMode -> Enum
• FanMode -> Enum

This will have an impact on all call_subscriber methods that update these state values. this will require that we always use value as the parameter name in the set_value method.

The first PR could be to change the set_value method to have the value parameter only. Second PR would then allow the change to the states to the new state types.

Latest HA updates appear to have broken thermostats as outlined in this thread:
https://community.home-assistant.io/t/2023-4-broke-insteon-thermostat-integration/558223/2

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

This line appears to me incompatible with Python 3.9 and is causing the Home Assistant Insteon integration to fail with the error below.

2021-07-11 11:31:44 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/pyinsteon/protocol/protocol.py", line 187, in _write_messages
    await self._transport.async_write(msg)
  File "/usr/local/lib/python3.9/site-packages/pyinsteon/protocol/http_transport.py", line 110, in async_write
    await self._async_write_url(url=url, msg=bytes(data))
  File "/usr/local/lib/python3.9/site-packages/pyinsteon/protocol/http_transport.py", line 119, in _async_write_url
    await self._read_write_lock
TypeError: object Lock can't be used in 'await' expression

Currently, the definition of a 6 or 8 button KPL is only via their cat and subcat:
6 button dimmer
“cat”: 1, “subcat”: 66 => (0x042) 6 button dimmer
“cat”: 1, “subcat”: 65 => (0x041) 8 button dimmer

6 button On/Off
“cat”: 2, “subcat”: 44 => (0x2c) 6 button on/off

8 button dimmer
cat": 1, “subcat”: 66 = (0x42) 6 button dimmer

There must be a way to identify the actual configuration since the ISY is able to do this.

Currently, only one device can be linked at a time. Find a way to allow the modem to remain in linking mode until canceled.

I have a few fanlincs in HA and they seem to be pulled in as on/off devices. The fan side of the fanlinc has 4 states off, low, med, high. I can't see how to access these to properly control the fanlinc. Do I need to do something to manually configure? (FYI, I am new to HA)

From what I can tell, the 2475F is pulled in as the following which I think is a dimmable light?

Device info
2475F (0x01, 0x2e)
by Smart Home
Connected via Insteon Hub
Firmware: 45 Engine Version: i2cs

My goal here is to have a keypadlinc control the fanlinc. I have the light wired to the main on the keypadlinc rather than the fanlinc so when I activate the main switch on the keypadlinc in HA it works fine.

For the fan, given there isn't a low, med or high not sure what to do. Off seems to turn the fan off and on seems to either go to low setting. Sending multiple on's just kept it on low (didn't increment through speeds).

Looking at how the keypadlinc is defined, I am guessing that the light and each of the fan settings are different groups. Below are the keypadlinc and fanlinc, respectively, from my insteon_devices.json file:

  "7687": {
    "memory": 7687,
    "in_use": true,
    "controller": true,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 0,
    "target": "3c41e2",
    "data1": 1,
    "data2": 66,
    "data3": 69
  },
  "7679": {
    "memory": 7679,
    "in_use": true,
    "controller": true,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 3,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7671": {
    "memory": 7671,
    "in_use": true,
    "controller": false,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 1,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7663": {
    "memory": 7663,
    "in_use": true,
    "controller": false,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 3,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7655": {
    "memory": 7655,
    "in_use": true,
    "controller": true,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 5,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7647": {
    "memory": 7647,
    "in_use": true,
    "controller": true,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 6,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7639": {
    "memory": 7639,
    "in_use": true,
    "controller": false,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 5,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7631": {
    "memory": 7631,
    "in_use": true,
    "controller": false,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 6,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },
  "7623": {
    "memory": 7623,
    "in_use": true,
    "controller": true,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 254,
    "target": "3c41e2",
    "data1": 0,
    "data2": 0,
    "data3": 0
  },

  "7751": {
    "memory": 7751,
    "in_use": true,
    "controller": true,
    "high_water_mark": false,
    "bit5": true,
    "bit4": false,
    "group": 0,
    "target": "477ed7",
    "data1": 1,
    "data2": 46,
    "data3": 69

Add full support for Motion Sensor II (2844-xxx)

The Insteon hub v2 appears to use a non-standard TCP response, causing a retry to be triggered every 0.1 seconds as pictured above. The issue seems to be related to https://github.com/pyinsteon/pyinsteon/blob/master/pyinsteon/protocol/http_reader_writer.py, as it has a 0.1 second retry period.

Log is flooded with this message: "
2023-01-08 19:32:27.660 WARNING (MainThread) [pyinsteon.protocol.protocol] pyinsteon transport exception: 'bytes' object has no attribute 'extend' "

Hi,

Would you be open to adding support for the Smartenit EZIOXX input/output controller devices? I have 3 EZIO2X4 devices which I use for monitoring dry contact inputs, analog temperature sensors, and a couple output relays as well. The basic device support should be pretty straightforward/quick to add. The analog inputs are a little more complex, but pretty powerful in certain applications.

I'm not sure exactly how the analog inputs would be made useful in Home Assistant, but I suspect it would involve passing the raw value to a custom helper script that could then transform the value into something useful. For example, in my case I have an analog temperature sensor which requires some voltage math to convert into degrees F.

I have a functional PHP driver implemented from my defunct automation controller project which I would be happy to share with you if that is helpful. But the command set documentation is pretty straightforward and largely follows typical Insteon patterns.

Thank you for the consideration!

Since May 7th when Insteon came back online, my connection between HA and Insteon has been very unreliable. If I reboot the hub then it will work for some time but eventually loses connection and I start seeing the below errors in the logs. I did see in another post mention Hub connectivity issues occur when two connections try to access the local HTTP server built into the Hub at the same time or if an existing connection does not close. So HA is making a connection to the local HTTP on the hub and Insteon is as well and that's causing issues? That doesn't make sense as I know HA supported the hub before insteon went down.

I currently cannot connect to the hub from a browser connection to ip:25105 which would make sense why the logs show cannot connect to host. I have a dhcp reservation for the hub so the IP hasn't changed and the insteon app continues to work.

I first want to thank you for this module - it is really complex, but so is insteon and all of the bit matching that has to happen, but it is pretty readable.

I am working on moving my insteon devices from Indigo to Home Assistant and my 2441V thermostat has been showing the incorrect temperature and it has been completely baffling me since it isn't just a F <-> C issue (mine is in F).

I have found the issue with my thermostat, but I'm not quite sure the correct way to resolve it. Here is the output of a temperature change message:

2021-01-03 08:41:45,497 DEBUG pyinsteon.messages RX: msg_id: 0x50, address: 14f855, target: 34788c, flags: 0x0f, cmd1: 0x6e, cmd2: 0x43
2021-01-03 08:41:45,497 INFO Topic: 14f855.thermostat_temperature_status.direct data: {'cmd1': 110, 'cmd2': 67, 'target': 34788c, 'user_data': None, 'hops_left': 3}
2021-01-03 08:41:45,497 INFO Topic: handler.14f855.thermostat_temperature_status.direct data: {'degrees': 34}
2021-01-03 08:41:45,497 INFO Topic: state_14f855_temperature_10 data: {'name': 'temperature', 'address': '14f855', 'value': 34.0, 'group': 10}

The current temperature on the thermostat is 67 which is represented in cmd2, except this value is being divided by 2 before being returned: https://github.com/pyinsteon/pyinsteon/blob/master/pyinsteon/handlers/from_device/thermostat_temperature.py#L34

Page 5 of the docs say that the existing code is correct, but what the thermostat is doing doesn't match the docs (what?? never!).

I'm happy to make a PR for this, but not sure what the correct PR to make is.

I currently am running homebridge with the homebridge-platform-insteonlocal plugin on a HubPro 2243 using these instructions:

https://github.com/kuestess/homebridge-platform-insteonlocal#using-the-hubpro-model-2243-beta

I'd really prefer to run home-assistant, and am wondering if this type of hub could be supported similarly? Thank you!

I have several Insteon thermostats and would like to be able to set the schedule programmatically. According to the developer doc that I have, this should be possible using cmd1/cmd2 0x03 0x0[3-9]:

Cmd 2: 0x03 Set Sunday schedule 
  Data1: wake time 
  Data2: wake cool 
  Data3: wake heat
  Data4: leave time 
  Data5: leave cool 
  Data6: leave heat 
  ...
  Data13: CRCHigh 
  Data14: CRCLow
Cmd 2: 0x04  Set Monday schedule: Same as Set Sunday schedule
Cmd 2: 0x05 Set Tuesday schedule: Same as Set Sunday schedule
Cmd 2: 0x06 Set Wednesday schedule: Same as Set Sunday schedule
Cmd 2: 0x07 Set Thursday schedule: Same as Set Sunday schedule
Cmd 2: 0x08 Set Friday schedule: Same as Set Sunday schedule
Cmd 2: 0x09 Set Saturday schedule: Same as Set Sunday schedule

I think this can be easily implemented by creating a new method in ClimateControl_Thermostat class, perhaps with the following signature:

async def async_set_schedule(self, day, schedule):

Obviously that also requires a schedule class.

In any case, I'm willing to work on this feature provided some guidance.

Ultimately I'd like to be able to program my thermostat using HomeAssistant, so that may also require some work on the HomeAssistant integration, which I'm also willing to help with.

Fix issue with direct NAK response during writes.

Requires the following change:

Class ALDB line 322:

                async for test_rec in self._read_manager.async_read(
                    rec_to_write.mem_addr, 1
                ):

Removing the force parameter.

Should be released with #314

The IO sensor reports open when closed and closed when open.

Hi,

I have 5 Insteon Leak Sensors in my installation. When I (re)start Home Assistant, they all report Dry conditions. Over ~48 hours, all but one of them will randomly report Moist conditions and will remain in that state until the next restart. I have manually verified that there are no actual leaks/moisture conditions. And, it is always the same device (Water Heater) that remains in a correct Dry state, versus the other 4 devices which always end up in the incorrect Moist state.

All 5 of these devices were previously setup/ALDB linked to the PLM before I migrated my PLM and Insteon network to Home Assistant. They are all the exact same model and FW version, and had identical ALDB link records. They had been installed in these same locations for several years and had worked as expected in my previous PHP-based home automation controller until migrating them in to Home Assistant.

My suspicion is that the issue here is one of the following:

1. The Home Assistant (pyinsteon) driver for this device type is not working as expected; or
2. The Home Assistant (pyinsteon) driver for this device type doesn't work as expected with my ALDB links; or
3. The initial adoption of these devices into Home Assistant (pyinsteon) modified their ALDB links from a working state into a non-working state

Here is an example of the ALDB links for the working (Water Heater) device:

Here is an example of the ALDB links for one of the other erratic devices:

Here is the json definition of the working (Water Heater) device:

  {
    "address": "3fc195",
    "cat": 16,
    "subcat": 8,
    "firmware": 0,
    "engine_version": 2,
    "aldb_status": 1,
    "aldb": {
      "4095": {
        "memory": 4095,
        "in_use": true,
        "controller": false,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 0,
        "target": "191cd6",
        "data1": 0,
        "data2": 0,
        "data3": 0
      },
      "4087": {
        "memory": 4087,
        "in_use": true,
        "controller": true,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 1,
        "target": "191cd6",
        "data1": 254,
        "data2": 0,
        "data3": 1
      },
      "4079": {
        "memory": 4079,
        "in_use": true,
        "controller": true,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 2,
        "target": "191cd6",
        "data1": 254,
        "data2": 0,
        "data3": 2
      },
      "4071": {
        "memory": 4071,
        "in_use": true,
        "controller": true,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 4,
        "target": "191cd6",
        "data1": 254,
        "data2": 0,
        "data3": 4
      },
      "4063": {
        "memory": 4063,
        "in_use": false,
        "controller": false,
        "high_water_mark": true,
        "bit5": false,
        "bit4": false,
        "group": 0,
        "target": "000000",
        "data1": 0,
        "data2": 0,
        "data3": 0
      }
    },
    "operating_flags": {},
    "properties": {
      "led_brightness": 100,
      "cleanup_report_on": true,
      "ignore_jumper_on": true,
      "two_groups_on": true,
      "repeat_open_on": true,
      "repeat_closed_on": false,
      "led_on": false,
      "link_to_ff_group": true,
      "program_lock_on": false
    },
    "first_mem_addr": 4095
  },

And here is the json definition of the other erratic device:

  {
    "address": "3f59a0",
    "cat": 16,
    "subcat": 8,
    "firmware": 0,
    "engine_version": 2,
    "aldb_status": 1,
    "aldb": {
      "4095": {
        "memory": 4095,
        "in_use": true,
        "controller": false,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 0,
        "target": "191cd6",
        "data1": 0,
        "data2": 0,
        "data3": 0
      },
      "4087": {
        "memory": 4087,
        "in_use": true,
        "controller": true,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 1,
        "target": "191cd6",
        "data1": 254,
        "data2": 0,
        "data3": 1
      },
      "4079": {
        "memory": 4079,
        "in_use": true,
        "controller": true,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 2,
        "target": "191cd6",
        "data1": 254,
        "data2": 0,
        "data3": 2
      },
      "4071": {
        "memory": 4071,
        "in_use": true,
        "controller": true,
        "high_water_mark": false,
        "bit5": true,
        "bit4": false,
        "group": 4,
        "target": "191cd6",
        "data1": 254,
        "data2": 0,
        "data3": 4
      },
      "4063": {
        "memory": 4063,
        "in_use": false,
        "controller": false,
        "high_water_mark": true,
        "bit5": false,
        "bit4": false,
        "group": 0,
        "target": "000000",
        "data1": 0,
        "data2": 0,
        "data3": 0
      }
    },

Does anything jump out here?

Thanks in advance for your assistance!

I'm looking at switching over to the native Insteon component in Home Assistant, and at the same time I want to move from an Insteon Hub (unreliable) to an Insteon PLM (USB).

I have the insteon_tools loaded on a machine with the PLM and I'm testing with a couple of devices I don't use actively, but I'm not having success adding / linking a device to the PLM without physically pairing.

My main use case here is I have a few of these modules buried in the ceiling and I'm trying to avoid getting a ladder and taking stuff apart.

You can do this with the native Insteon App with the Hub, so I was hoping there was a formula to do it with the insteon_tools.

Currently states use a set_value method and DeviceFlags (operating flags and extended properties) use a load method. Modify all classes to use the set_value method. This requires changing all uses of load to set_value

Running insteon_tools:
aldb
add_device_to_scene

Enter in device address, scene number, on level....

Then it prompts "Ramp rate (Default 0.5):
If you put in any number or decimal, you get a response: "Must be a number. (Max: 400 Min: 0.1).

If I use the default by hitting enter, I get further errors:
"An error occured executing command.
unsupported operand type(s) for +=: 'int' and 'NoneType'

Impacts the following classes:

• DeviceFlagBase
• DerivedProperty
• ExtendedProperty
• ModemConfiguration
• OperatingFlag

Many devices are not responding to the LED dimming command correctly. Some devices use command:
cmd1: 0x2E cmd2: 0x00 userdata: 0x00 0x03 0xXX
Other devices require
cmd1: 0x2E cmd2: 0x00 userdata: 0x00 0x07 0xXX

I've noticed that in the new library, when running under Home Assistant, the "info" logging level seems to be the same as "warn". I'd like to discuss a proposal to change that behavior before I work out a pull request for the same. Here's my proposal:

• warn: Very quiet, mostly just success startup and any conditions that might need to be addressed. I think the existing code does that now quite well
• info: (new) Emit status for any state changes of a controller or actuator. So light on/off etc. All-Link groups would emit one change log for each endpoint in the All-Link group
• debug: Enough content that we can debug someone else's installation remotely if they have problems and enable debug level.

What do you think about my proposed changes to info?

device_base returns a tuple of ResponseStatus whereas battery_base, modem_base , and x10_base return a single ResponseStatus.

Change this to return a single response status.

This is a bit of a corner case but I have a 2842-222 motion that I must have factory reset at some point and yet it still allows me to poll it for status. I2CS should refuse to speak (NAK) unless the PLM is in the ALDB, yet this one responds to ALDB read requests. The device is in the PLM so pyinsteon finds it and tries to talk to it. However it repeatedly tries to pull the ALDB, never satisfied that the device responds with only one record at 0xFFF which is a high-water mark and not in use.

I'll submit a pull request that includes a fix for this issue.

Reported by @rlust

home-assistant/core#71802

My 2842-222 motion does not respond to the repeated attempts to put the device into extended listening and so none of the queued commands are ever attempted. Every time this device emits an All-Link Broadcast on/off for motion; pyinsteon tries in vain to talk to the device. This repeats indefinitely since the queued commands are never satisfied.

[pyinsteon.topics] Topic: send.extended_get_set.direct data: {'address': aabbcc, 'priority': 5, 'data1': 0, 'data2': 4, 'data3': 255, 'data4': 0, 'data5': 0, 'data6': 0, 'data7': 0, 'data8': 0, 'data9': 0, 'data10': 0, 'data11': 0, 'data12': 0, 'data13': 0, 'data14': 0}
[pyinsteon.device_types.battery_base] Keep awake result: failure

The root cause is that the current implementation does not consider the device state machine for an All-Link Broadcast. When a device sends an All-Link Broadcast message, it will then go though a cleanup process that involves sending direct All-Link Cleanup messages to every responder in it's ALDB (which respond with an ACK) then sending an All-Link Cleanup broadcast report. While all this is going on, the 2842-222 motion refuses to respond to direct commands. This may not be true of all Insteon devices because of this comment in the INSTEON Developers Guide:

An INSTEON Controller will send SC ALL-Link Cleanup Commands to all Responder devices in an ALL-Link Group, unless other INSTEON traffic interrupts the cleanup, in which case the ALL-Link Cleanups will stop.

But this goes to show that It is unwise to send any messages while a device's cleanup process is underway because at best it will abort the process. In the case of the 2842-222, the direct command is ignored.

I'll submit a pull request that includes a fix for this issue that waits for the All-Link Cleanup Broadcast message. This change has worked reliably for multiple restarts now.

Not sure exactly what is going on, but after an upgrade to 2022.9.5, I can no longer control my Insteon devices. I have rebooted the Insteon hub and restarted HA multiple times and the problem persisted. I rolled back to 2022.8.7 and the Insteon integration began working again.
Notes - using Hub V2, Upgrade to 2022.9.5 was my first update to 2022.9.x
This error shows in the log.

`Logger: pyinsteon.protocol.protocol
Source: runner.py:119
First occurred: September 18, 2022 at 11:17:45 PM (10599 occurrences)
Last logged: 2:58:38 PM

pyinsteon transport exception: 'bytes' object has no attribute 'extend'`

Hi, been a happy user of Insteon via my 2413U with Home Assistant for years. Started having problems where my devices wouldn't respond. Was able to get them back with a reboot. But now I can't control them at all. I turned on logging and also factory reset my PLM, but this is what I see in the logs:

2023-03-24 09:13:48.356 DEBUG (MainThread) [pyinsteon.protocol.protocol] Attempting to connect to modem
2023-03-24 09:13:48.360 DEBUG (MainThread) [pyinsteon.topics] Topic: connection.made data: {}
2023-03-24 09:13:48.699 DEBUG (MainThread) [pyinsteon.protocol.protocol] Scheduling the writer
2023-03-24 09:13:48.699 DEBUG (MainThread) [pyinsteon.protocol.protocol] Connected to modem in async_connect
2023-03-24 09:13:49.072 DEBUG (MainThread) [pyinsteon.protocol.protocol] Modem writer started.
2023-03-24 09:13:49.700 DEBUG (MainThread) [pyinsteon.topics] Topic: send.get_im_info data: {}
2023-03-24 09:13:49.701 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x60
2023-03-24 09:14:44.438 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: insteon
2023-03-24 09:15:44.519 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: insteon
2023-03-24 09:16:44.595 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: insteon
2023-03-24 09:16:50.704 DEBUG (MainThread) [pyinsteon.topics] Topic: send.get_im_info data: {}
2023-03-24 09:16:50.705 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x60

I'm guessing it's a hardware issue at this point? Anything in pyinsteon I could try? Thanks in advance.

Originally reported here:
home-assistant/core#72723

I'd jump right in and start debugging issue #72 for you but I'm intimidated by the completely revamped library. It took me about 2 months to trace and understand the startup, discovery, message sending, and message reception of python-insteonplm. I'm not looking forward to the same reverse engineering again. By any chance, did you happen to write up even an outline of these tasks in the new library?

I am running a PLM (usb) controlled by home assistant.
(from the insteon_devices.jason info:
"address": "20f4f9",
"cat": 3,
"subcat": 21,
"firmware": 155,
"engine_version": 3,
)

When invoking list_devices, I get an unknown format code error on the first entry. Based on hacking/debugging, it looks like the first device is the PLM and it has "network_bridges" (?) as the category.

bash-5.0# python3 run_tool.py
STDOUT: Set log level to 20
The command line module for pyinsteon is designed to test devices and perform certain common functions.
pyinsteon: connect /dev/ttyUSB0
pyinsteon: load_devices /config 0 1
Total devices: 40
pyinsteon: list_devices
Address Cat Subcat Description
'-------- ----- ------ ------------------------------------------------------------------------'
An error occured executing command.
Unknown format code 'x' for object of type 'str'
pyinsteon:

After changing the format string in list_devices (in tools/tools_base.py) to eliminate the ":s", I get
'-------- ----- ------ ------------------------------------------------------------------------'
20.F4.F9 network_bridges 0x15 PowerLinc USB Modem

When invoking find_broken_links, I get an "unsupported format string passed to Address.format" error on the first entry.

bash-5.0# python3 run_tool.py
STDOUT: Set log level to 20
The command line module for pyinsteon is designed to test devices and perform certain common functions.
pyinsteon: connect /dev/ttyUSB0
pyinsteon: load_devices /config 0 1
Total devices: 40
pyinsteon: manage_aldb
pyinsteon - aldb: advanced
pyinsteon - advanced: find_broken_links
Device Mem Addr Target Group Mode Status
'-------- -------- --------- ----- ---- ----------------------------------------'
An error occured executing command.
unsupported format string passed to Address.format

After hacking/debugging, it seems the addresses can't be formatted as strings(?).

After changing the format string in tools/advanced.py to eliminate the :s format on the source and target addresses, I get:

'-------- -------- --------- ----- ---- ----------------------------------------'
20.F4.F9 1fff 14.8E.0F 1 C Missing responder

Not sure if there is some deeper issue...

Insteon scene message flow should also provide feedback. Currently, the pyinsteon module sends a status request to each device before updating the device state. Can we use the All-Link Cleanup process to confirm message receipt and response?

Per the discussion here:
home-assistant/core#71375

Version 1 devices require peak/poke commands for read/write functions to manage the All-Link Database. This request will add the read/write capabilities via peak/poke commands.

I'm trying to write Insteon-based automations in Home Assistant. The problem is not writing imaginary device numbers and hoping that eventually I will accidentally hit a combination of entries that works, the problem is that I cannot see what signals the Insteon devices are transmitting (if any). Within Home Assistant or pyinsteon, there is no current way to read an event log of raw Insteon device signals.

Please solve this problem. I have a shortwave radio tuned to 130 KHz that tells me the devices are trying to send signals, but to no effect within Home Assistant. I have this entry in config/configuration.yaml:

logger:
  default: info
  logs:
    insteonplm: debug
    homeassistant.components.insteon: debug

Then I run this code in a terminal:

$ tail -f config/home-assistant.log 

All very exctiting -- lots of log entries, but none of them relevant to what the Insteon devices are emitting -- the copious radio signals notwithstanding.

Also, the Developer Tools / Events / Listen to Events utility emits ... nothing, regardless of what filter it is offered.

Please make it possible to read Insteon events, as was true in the earlier, crappy Insteon Java control program that I am trying desperately to replace.

To see what I'm missing in pyinsteon, here's an example image from the now-moribund Insteon Java app's event viewer:

https://i.imgur.com/JAkw8WN.png

Thanks for addressing this critical deficit.

Should work exactly as an on / off device.

Actual device category 0x0F and sub 0x06
Similar device category 0x02 and subcat 0x37

Hi,

I'm a seasoned PHP developer/Insteon pro who recently migrated to Home Assistant, and thus pyinsteon, from my own home automation controller application I had designed and developed in PHP since ~2005. In my existing Insteon environment, and in my PHP application, I had implemented support for a few additional device types which are not currently implemented in pyinsteon -- such as the EZIO devices from Smartenit. I do not do python normally, but can get around. I am wondering if anyone here might be willing to offer me a high level primer of steps I could follow to implement support for a new device type?

They fit the following cat/subcat defintion:

cat   subcat
0x09 | 0x0A
0x09 | 0x0B

Developer guide missing.

Update the following classes:

• OpenCloseResponderBase
• OpenCloseControllerBase

Allow for multiple groups and events to be created rather than the current single group and single on/off event. This will also simplify the following classes:

• AccessControl_Morningstar
• EnergyManagement_LoadController
• SecurityHealthSafety
• SecurityHealthSafety_MotionSensor
• SwitchedLightingControl
• SwitchedLightingControl_ApplianceLinc

I've been using python-insteonplm with HA v1.105 for a very long time and it has worked well. Today I finally found the courage to try the new pyinsteon library. On the very initial startup I encountered the traceback below. It was repeated multiple times. The full log output can be found in this gist https://gist.github.com/mstovenour/fafd9b72870e7234aa76d2983a37f9c3. I have logs set globally to info. I've left the system in this state with out restarting or performing any other actions in HA. What do you suggest for the next steps to debug this issue?

bash-5.0# more /usr/src/homeassistant/homeassistant/components/insteon/manifest.json
{
  "domain": "insteon",
  "name": "Insteon",
  "documentation": "https://www.home-assistant.io/integrations/insteon",
  "requirements": ["pyinsteon==1.0.8"],
  "codeowners": ["@teharris1"],
  "config_flow": true
}

...
2021-02-25T13:35:47.681321616Z 2021-02-25 07:35:47 INFO (MainThread) [pyinsteon.managers.device_manager] Adding device to INSTEON devices list: 37f42e
2021-02-25T13:38:15.693845479Z 2021-02-25 07:38:15 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.insteon entity: switch.on_off_outdoor_module_37_f4_2e
2021-02-25T13:40:32.748218989Z 2021-02-25 07:40:32 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.insteon entity: switch.keypadlinc_on_off_20_42_d3_main
2021-02-25T13:40:32.748245328Z 2021-02-25 07:40:32 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.insteon entity: switch.keypadlinc_on_off_20_42_d3_button_a
2021-02-25T13:40:32.749351557Z 2021-02-25 07:40:32 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.insteon entity: switch.keypadlinc_on_off_20_42_d3_button_b
2021-02-25T13:40:32.749382996Z 2021-02-25 07:40:32 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.insteon entity: switch.keypadlinc_on_off_20_42_d3_button_c
2021-02-25T13:40:32.749493404Z 2021-02-25 07:40:32 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.insteon entity: switch.keypadlinc_on_off_20_42_d3_button_d
2021-02-25T13:41:58.204982754Z 2021-02-25 07:41:58 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
2021-02-25T13:41:58.205063502Z Traceback (most recent call last):
2021-02-25T13:41:58.205080286Z   File "/usr/local/lib/python3.8/site-packages/pyinsteon/managers/device_manager.py", line 222, in async_setup_device
2021-02-25T13:41:58.205093101Z     await device.async_add_default_links()
2021-02-25T13:41:58.205106151Z   File "/usr/local/lib/python3.8/site-packages/pyinsteon/device_types/device_base.py", line 224, in async_add_default_links
2021-02-25T13:41:58.205119347Z     return await async_add_default_links(self)
2021-02-25T13:41:58.205130939Z   File "/usr/local/lib/python3.8/site-packages/pyinsteon/managers/link_manager/default_links.py", line 39, in async_add_default_links
2021-02-25T13:41:58.205143037Z     result = await async_link_devices(
2021-02-25T13:41:58.205154018Z   File "/usr/local/lib/python3.8/site-packages/pyinsteon/managers/link_manager/__init__.py", line 53, in async_link_devices
2021-02-25T13:41:58.205166527Z     _, failed_2 = await responder.aldb.async_write()
2021-02-25T13:41:58.205178044Z   File "/usr/local/lib/python3.8/site-packages/pyinsteon/aldb/aldb_base.py", line 272, in async_write
2021-02-25T13:41:58.205189736Z     for mem_addr in self._dirty_records:
2021-02-25T13:41:58.205205973Z RuntimeError: dictionary changed size during iteration
...

Add the following to ALDB class async_load method line 48:

        if self._mem_addr not in self._records:
            # Query the first record
            try:
                async for rec in self._read_manager.async_read(
                    mem_addr=0, num_recs=1, read_write_mode=mode
                ):
                    self._mem_addr = rec.mem_addr
                    self._add_record(rec)
            finally:
                await self._read_manager.async_stop()

Requires a fix to the AldbReadManager class method _async_read_one line 114:

                    if (
                        record is not None
                        and record.mem_addr == mem_addr
                        or mem_addr == 0x0000
                    ):

I'm not sure if this is the right place to post this or not, please let me know if there is a better place.

I have must moved my PLM over from an indigo box to a raspberry PI running HA and was attempting to load all devices from the PLM.

When running `` with

entity_id: all
reload: true

I get this in HA:

/usr/local/lib/python3.8/site-packages/pyinsteon/aldb/__init__.py:63: RuntimeWarning: coroutine 'async_register_services.<locals>.async_srv_save_devices' was never awaited
  callback()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
2020-12-27 08:18:38 ERROR (MainThread) [frontend.js.latest.202012120] https://myname.duckdns.org:8123/frontend_latest/chunk.6b18c64ed740014d3f00.js:1:8122 YAMLException: unacceptable kind of an object to dump [object Undefined]

I grabbed the JSON from /config/insteon_devices.json and ran it through a parser just to make sure there weren't any exceptions there. I'm not sure which YAML this error is referring to though to go check that out.

Previously I was getting these errors when I had run the import first (which did import a bunch of devices, but not all)

2020-12-27 07:47:03 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pyinsteon/managers/device_manager.py", line 222, in async_setup_device
    await device.async_add_default_links()
  File "/usr/local/lib/python3.8/site-packages/pyinsteon/device_types/device_base.py", line 224, in async_add_default_links
    return await async_add_default_links(self)
  File "/usr/local/lib/python3.8/site-packages/pyinsteon/managers/link_manager/default_links.py", line 39, in async_add_default_links
    result = await async_link_devices(
  File "/usr/local/lib/python3.8/site-packages/pyinsteon/managers/link_manager/__init__.py", line 53, in async_link_devices
    _, failed_2 = await responder.aldb.async_write()
  File "/usr/local/lib/python3.8/site-packages/pyinsteon/aldb/aldb_base.py", line 272, in async_write
    for mem_addr in self._dirty_records:
RuntimeError: dictionary changed size during iteration

I removed and re-added the insteon integration and it still has the 24 devices previously found and attempting to run insteon.load_all_link_database doesn't give any different results after that.

I have a keypadlinc and am using the latest pyinsteon build. The 8 entities are created properly for the keypadlinc. In addition the main button (ie one with the load) works fine as expected. The other buttons however do not update in HA when they are physically pressed on the keypadlinc.

Keypadlinc is paired to an INSTEON Hub v2. Everything works fine through the Insteon app. Also as soon as I open the device details on the Insteon app, the status in HA for all the button syncs.

From this I believe the issue is that HA is not polling the status of the keypadlinc. Is there a way to update the polling interval for this or force a refresh somehow?

Thanks

Harley