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

I'm seeing this issue again - REST is slow, but some kind of caching means it's only slow "sometimes". For example, http://192.168.1.9/rest/programs/?subfolders=true took >10s to respond, and Chrome complained that the XML wasn't valid: "Extra content at the end of the document". When I reload it, the ISY responds quickly and all is well. Anything I can share here that'll help to debug this?

I made a backup earlier today, and when I restore it to the ISY it makes the device unreachable. I can successfully ping it from another machine, but it doesn't respond to web or telnet requests. I've tried doing a factory reset and then a restore - after the reset the device is reachable, but once I restore it becomes unreachable once more. Any suggestions?

1. The program I'm referring to is an ISY program which directly sets 15 variables once per minute - it doesn't use network resources at all, i.e. I don't have the ISY talking to itself via REST 2. I have other Python/PHP scripts running on a server which use the REST API. Good to know that loopback can be problematic - thanks!

That program is running on ISY (I should have stated that, sorry) - and all the variables are valid. Still some weirdness going on - I'm going to dig into it more, and I'll report back in case any of this is helpful to others. I've had super-fast responses from REST for years, but something is now filling up the IO queues...I'll get to the bottom of it!

I have one program which runs every minute, all it does is update sixteen variables on the ISY. If I disable it, the instances of the REST interface taking >20s to set a variable go away. Just rebooted my ISY, and left the program in question disabled... will see if that stops the issue. Since the slowness occurs when setting variables, I don't think PyISY will help, but I'll take a look - thanks for the tip, @Jimbo.

F/W 5.0.15A Devices: ~50, all Insteon (there are a few other things via Polyglot) The slowness is when I read all the variables to grab their IDs. Websocket may be the way to go, agreed. I'm using http - everything's on my subnet so I'm not concerned about http The only programs I have which loop do so no more than once per minute, and it's rare for more than six or seven of them to be looping at the same time. I've improved logging on the machine that's running the other services, so I should be able better to identify where the slowdowns are occurring. Thanks for the suggestions - updates to come

I rely quite a lot on the REST interface to pass state into and out of the ISY from variables - sometimes it can be very slow (e.g. a request for /rest/vars/definitions/1 can take >20s to return the results). Spending time debugging this today - I may consider caching the definitions results and refreshing it occasionally (I don't add/remove variables often) as it seems to be the slowest part of everything. Has anyone else seen this issue?

I followed the instructions from the wiki post referenced above by Brian H. Since I have a recent backup, I decided to factory reset the ISY and restore from the backup. That seemed to do the trick - it's working fine with the 'old' PLM now. Annoying, as it'd be nice to have had the logs to see if it's something that might happen to other people. Anyway, I'm back in business...living in a non-smart home for 24 hours wasn't much fun

I got a V2.4 from Amazon - dated 1017. Disturbingly, the ISY doesn't want to talk to it either. Any thoughts on what to try next?

Yes, it looks like a dead PLM. I've ordered another one. Thanks @lilyoyo for confirming my bad news! If only Insteon's hardware were as reliable as UDI's hardware. I don't post much, because I have few questions, but I am always amazed by Michel's low latency, high accuracy responses on this forum. UDI's customer support is amazing, and the products are just as good.