brandwidth

It's better than nothing, for sure. What typical latency do you see for controlling the bulbs?

Yes - the original PLM is dead now, if I try to restart with it the ISY goes into safe mode. Focusing on trying to get to a known good state with the new PLM and ISY.

That's very helpful - thank you. In the latest round of testing, my ISY has stopped responding on the web interface or via the admin console. I can telnet to it, so I know it's getting an IP address at least. Time for FR the ISY I think... that's not really scary since I have known good backups. Sometimes this makes me reflect on the fact that ISY, amazing as it is, spends a lot of its time persuading Insteon devices to do things they weren't really design to do. As a long-standing tech Product Manager, I'm well aware that building a product on top of a set of APIs designed for other purposes is fraught with challenges. ISY does an amazing job, almost all the time. Insteon, on the other hand, hasn't got much better in the last ten years ? The next house might need a different approach.

I've concluded that this is probably a PLM comms issue. It *looked* like a wireless issue, but it's not... wired devices are equally impacted. Since I've got good known backups, my plan is to try a reset of both the PLM and the ISY, and see if I can get a single wired device communicating with the ISY through the PLM when both devices are closely adjacent on the same circuit. If that works, I will restore the ISY from the backup, do a PLM restore, and then restore individual devices one by one checking for success at each stage. Given that this is brand new PLM, perhaps I'm just incredibly unlucky?! We'll see...

I think I'm running into a similar issue - way fewer links being restored to my new PLM. Did you make any progress with your installation? Would love to hear either way.

Yes, I did a restore devices - I'm trying another one now. One question I have that's related... since from reading around the topic I may need to delete devices and add them again... if I delete a device and add it back, do programs in the ISY still correctly map to it? I am guessing they will, because the device will have the same ID. I'd rather move house (!) than have to rebuild more than a hundred programs from scratch! ? Once my latest restore devices completes I'll report back - thanks for continued support here.

Yes, I unplugged everything, then brought up the new PLM, then connected the ISY, then restored the PLM. After some more sleuthing, I have found that when I look at the ISY links table for my wired devices, each of them contains the ID of the PLM. For my wireless devices, there's no PLM ID. I have tried factory resetting the motion sensors, restoring them (with battery-powered device updates disabled, so I can can write the updates one-by-one) but it doesn't help. Further info: even my devices with the PLM ID in their link tables aren't sending status updates (e.g. when I switch on a switch, I am sure I used to see a DON entry in the communications log... isn't that the case, that devices report their status on changes, and it's visible within the admin console?). Any thoughts on how to overcome this? I have good ISY backups, so if a restore might help I can certainly do that.

Yes - I used Restore Modem after switching to the new PLM and rebooting ISY. I have Pro, and I've been restoring the battery-powered modules separately. I looked at the link table for a wired device - it has a link to the PLM. None of my battery devices show the PLM in their link table (hence they don't send any comms to ISY when they change state). I'm going to try rebooting the ISY with the old modem (I have an ISY backup so not much can go wrong!), restoring the 'bad' PLM and then migrating to the new one again.

Thanks for the suggestions - yes, I've gone through and done a singular update to each of the devices such that there's no 1011 remaining. When I look at the links table, there's no PLM address in there Any ideas on how to get that working again? BTW, while I'm here I want to say thank you to this community for being so thoughtful and helpful. I had an amazingly automated home (almost never touch a light switch or ask Alexa to change things) that after switching to a new PLM has become very frustrating. I really appreciate folks chiming in to help me.

And now I think I've confused myself. The motion sensor is controlling a scene, and it's working. However, I want to trigger program events (as I've successfully done before) based on motion sensor activity. I need the sensor to send an update to the ISY when it triggers... but I'm not seeing that in the event viewer ?

My PLM was dying (frequent errors, etc.) so I bought a new one. I switched the ISY off, booted the new PLM, powered up ISY and did a restore PLM, then a restore devices (as I understand it, the devices wouldn't send updates to the new PLM, because all their links would be to the old PLM.) Now my motion sensors won't send comms events to ISY. I've tried factory resetting them and restoring them, and I see the ISY link being sent in the comms window. However, pressing the button on the sensors doesn't trigger any communication from the sensor to ISY. Any tips on how to get things working again? I can post logs of what's happening when I do a restore if that'll help.

I do have some battery devices which have updates 'permanently' pending - will try disabling automatic writes to battery devices and see if that has any impact - thanks for the tip @larryllix. Update: looks like that was the issue (I'd not considered that it'd have an impact on HTTP)... I'm now seeing response times reliably under 200ms

Michel - thanks for that super helpful background. It's likely my ISY is getting swamped by more than 3 concurrent HTTP connections - I'll try to optimise things based on what you've shared.

It's not being accessed using a browser - the python in question is: loadTime = requests.get("http://192.168.1.9/rest/vars/get/1",auth=('<username>', '<password>')).elapsed.total_seconds()

I added more logging to investigate this - a Python script makes a GET request and logs the round trip time whenever it's >1s. Any thoughts on why the variance is so high? I'm not adding any new variables here - the ISY is in "steady state". 2020-03-19 11:26:59,185 /rest/vars/get/2 took 26.229227 s 2020-03-19 11:27:25,683 /rest/vars/get/1 took 21.483313 s 2020-03-19 11:28:02,481 /rest/vars/get/2 took 36.762416 s 2020-03-19 11:28:28,739 /rest/vars/get/1 took 21.242982 s 2020-03-19 11:29:29,586 /rest/vars/get/2 took 60.818626 s 2020-03-19 11:29:56,218 /rest/vars/get/1 took 21.617317 s 2020-03-19 11:30:06,656 /rest/vars/get/2 took 4.381121 s 2020-03-19 11:36:39,764 /rest/vars/get/1 took 1.236568 s 2020-03-19 11:39:29,366 /rest/vars/get/1 took 48.736331 s 2020-03-19 11:39:32,130 /rest/vars/get/2 took 2.735085 s 2020-03-19 11:40:37,765 /rest/vars/get/1 took 27.713981 s 2020-03-19 11:41:04,113 /rest/vars/get/2 took 26.317265 s 2020-03-19 11:41:30,130 /rest/vars/get/1 took 21.006414 s 2020-03-19 11:41:56,175 /rest/vars/get/2 took 26.016872 s 2020-03-19 11:42:22,522 /rest/vars/get/1 took 21.332925 s 2020-03-19 11:42:48,723 /rest/vars/get/2 took 26.171875 s 2020-03-19 11:44:37,447 /rest/vars/get/1 took 27.657693 s 2020-03-19 11:45:03,417 /rest/vars/get/2 took 25.938609 s 2020-03-19 11:45:29,726 /rest/vars/get/1 took 21.294449 s 2020-03-19 11:46:05,035 /rest/vars/get/2 took 35.279932 s 2020-03-19 11:46:34,973 /rest/vars/get/1 took 24.923365 s 2020-03-19 11:47:31,158 /rest/vars/get/2 took 56.153243 s 2020-03-19 11:48:23,084 /rest/vars/get/1 took 46.909512 s 2020-03-19 11:48:33,025 /rest/vars/get/1 took 4.043669 s 2020-03-19 11:49:25,868 /rest/vars/get/2 took 3.541272 s 2020-03-19 11:50:59,241 /rest/vars/get/2 took 1.206724 s 2020-03-19 11:51:50,860 /rest/vars/get/1 took 30.128240 s 2020-03-19 11:52:18,113 /rest/vars/get/2 took 27.223486 s 2020-03-19 11:52:44,127 /rest/vars/get/1 took 20.999266 s 2020-03-19 11:53:10,118 /rest/vars/get/2 took 25.961969 s 2020-03-19 11:53:36,368 /rest/vars/get/1 took 21.236130 s 2020-03-19 11:54:02,571 /rest/vars/get/2 took 26.173769 s 2020-03-19 11:54:41,961 /rest/vars/get/1 took 23.311470 s 2020-03-19 11:55:10,910 /rest/vars/get/2 took 28.919070 s 2020-03-19 11:56:12,239 /rest/vars/get/2 took 1.743591 s 2020-03-19 12:03:07,859 /rest/vars/get/1 took 1.229289 s 2020-03-19 12:03:09,157 /rest/vars/get/2 took 1.268243 s 2020-03-19 12:03:55,366 /rest/vars/get/1 took 1.226776 s 2020-03-19 12:05:46,565 /rest/vars/get/1 took 1.242285 s 2020-03-19 12:05:47,809 /rest/vars/get/2 took 1.206969 s 2020-03-19 12:08:15,245 /rest/vars/get/2 took 1.206420 s