n_sievers

Thank you for that input. As soon as a replaced the spaces with %20, I got it to work. In all of this testing/diagnostics, I have found that the reason the sensor status was not updating in Alexa app (or at least visibly) is that this is connected to a contact sensor on a mailbox flap and the state was changing too quickly for it to show reflected in the app; however the state change was enough to trigger the notifications set up in my Polisy for email and push. If I slowly move the flap it does correctly show the updated state in the Alexa app but with that being said, the routine still will not execute based on the state change so that has opened the original question here again I believe. I have tried creating another test routine based on the state change of my deadbolt to see it that would be successful but unfortunately it does not seem to be working either so is not isolated to a single device.

I apologize for the confusion here but how do I structure the "yourdeviceaddress" portion? (Insteon address xx.xx.xx.1). I have tried with and without the periods, with and without spaces instead of periods, and without the .1 but all are returning "404". I fell I am just missing something on the structure here.

I have confirmed everything is correctly mapped and even deleted all Alexa associations and rebuilt, still with no success. I have noticed that after I trigger open/close numerous times repeatedly, it changes state once and then not again until I tried it again the next day where it changed state in Alexa app once. Even when it changes states in Alexa the single time, the routine still does not trigger.

Unfortunately I have tried and checked everything multiple times with no success. Previously it would intermittently work then completely stopped. The issue seems to be with Alexa app not updating/recognizing the open/close status from the sensor. All other device status states are and update correctly and the open/close sensor always updates correctly in AC and UD Mobile and those notifications are working properly so am still at a loss here.

Unfortunately mine is still not working. The open/close sensor state changes and is reflected properly in the AC and notifications come through properly through text and UD Mobile push but the state does not change when viewing the open/close sensor in the Alexa app, therefore the notification routine does not execute.

I have been facing the issue of my Alexa routine indicating that "mail is in" just stopped working. I have not made any changes to Alexa app or routines settings and only routine ISY firmware updates are being completed on my Polisy (currently running 5.8.0) so possibly it has to do with more recent versions of the ISY firmware? This started in November of last year where it just stopped announcing that mail is in and started to work on its own a couple weeks later, again without any changes/modifications occurring on my end. It again stopped working in December and has not worked since. I also have it set up to send UD push notifications and that has worked consistently without issue. I have the Insteon open/close sensor properly exposed in the portal as an open/close sensor and have tried numerous times by deleting the device and routine from Alexa and rediscovering (always finds the appropriate mailbox sensor and adds to Alexa) and creating a new routing without any success. It I look at the sensor's state in Alexa, it never changes from "Closed" but as previously mentioned, the state does properly change and the UD push notifications come through without any issue. I am at a loss and have just put it on the back burner for the time being.

I initially bought a Zooz Zen31 RGBW controller to experiment with and paired it with an inexpensive roll of of RGBWW led strip that I purchased off of Amazon to create a TV backlight. I was very happy with the integration of the ZWave control of the LED strips in ISY so following my successful experiment, I proceeded to purchase 3 more Zen31 controllers and and aluminum channel with diffuser for a clean LED strip installation in various other areas of my home. I have been running them for a few months now and am very happy with these controllers.

I second that!

This could be due to the setting under configuration for "catch up programs at startup". A program(s) containing those devices may initiate or possibly the "query at restart" is indicating a state change/update that initiates a program containing those devices.

I have 2 Venstar thermostats in my setup. One is a T1900 with the Insteon dongle. I have had this in my system for 15+ years and has been great (I did have to replace a failed Insteon dongle many years ago and have another spare if ever fails again) but unfortunately they stopped making the dongle and fully Insteon-integrated Venstar many years ago. The other one I have installed is a Venstar Voyager with Z-wave module. This too works very well and have been using for about 4 years. These particular Venstar thermostats are not “glamorous” but work very well and have the features that I need such as direct connection/integration to ISY (I am not interested in using a node server/wi-fi connectivity) for my particular integration, native humidifier control, wired outdoor temp sensor and terminals to connect a contact closure to as to place in vacation mode.

I am having some erratic issues occurring where the device status is not updating on my favorites page when connected remotely (outside my local network) but when I click on the individual device, it will enter its control page with status updating correctly and properly controlling the device. When I back out to favorites page, that particular device will then show correct status but all others are still blank. This is only happening when connected remotely and not when connected on local network.

Insteon used to actually have a specific 8-button keypad version of a countdown timer 2484D for uses such as a bath fan. The timer capabilities were built in to it but I haven’t seen one around for many years.

Sorry for the delay as I got tied up with work meetings. I checked a bit ago and noticed everything is back up and working as it should again! Thank you! I was moving a bit slow due to the weather in Denver today as well!

I have noticed this morning following leaving my local network and trying to access UD Mobile, initially the connection was painfully slow and all nodes did not populate. I closed out the app an reconnected but took several minutes for it to connect and was still exceptionally slow and only a couple other nodes populated. I had checked multiple times and the last time I tried going on about 15 minutes ago, it would not connect at all and the error that I get when this occurs is: "Connection Type: oAuthPortal. Error code 404". I am back on my local network and everything connects and works perfectly fine. I do have at the local address set up and my wifi network registered so that it can properly and quickly change over from local to remote as soon as my local network is not available. I tried logging into my portal to see if that was showing delay as well but all I good there. It was working properly over earlier this weekend and I updated UD Mobile this weekend so not sure if it related to that or not since I was on my local network all day yesterday and just discovered this upon connecting remotely.

I have confirmed that although the UI sunrise/sunset times are incorrect, my sunrise/sunset scheduled programs are running at the correct times.

I have the same issue occurring. I rebooted with no success.

Upon checking to make sure everything was good this morning, I found that the sunrise and sunset times displayed in the admin console are actually an hour earlier than they should be but the actual time is correct. I have no other obvious issues at this point and no disabled programs so I tried rebooting the Polisy but upon coming back up, the sunrise/sunset are still displaying an hour earlier than they should be. I am in Denver so on Mountain time.

For me it took several reboots, 2 of which I actually power cycled my Polisy, before the update was reflecting 5.7.0_5. Everything seems to be working well now and no further issue with all programs being disabled at this time.

I believe this is the device: http://resetplug.com A quick Amazon search came up with this option as well: https://www.amazon.com/Connect-Monitors-Connectivity-Required-Necessary/dp/B07MCRQPCS/ref=sr_1_5?keywords=wifi+reset+plug&qid=1697229665&sr=8-5

A number of years ago I had the same issue with recurring loss of connectivity with my Centruy Link DSL connection/modem due to CL's failing copper infrastructure. The only other option was Comcast but for the same reliability issues neighbors were having and also that they would not allow residential customers a static IP (CL did allow for this) and quite frankly for more reasons than I can explain, it was not an option and was holding out for fiber which was on the adjacent block but unfortunately not mine and no commitment to be bringing it to mine! I finally gave up and went with a local point-to-point wireless internet provider that came available to the area and have never looked back as have been extremely happy, not to mention a local person that I can speak to if/when there is an issue. I digress, but during my stint with CL and the ongoing issues, I found a unique device that would intermittently ping sites to confirm connectivity and then would power cycle the attached outlet at the outage time interval you set to do so following drop-out and then come back on after the time you programmed it to remain off. I traveled a lot for work so this worked great and got me through that time with an inferior internet provider. They even had a portal/service you could set up to notify you when internet was lost and then again restored. It has been quite a few years so I can see if I can find out the info for this device and let you know.

I did. I just did yet another reboot and is now showing as being on 5.7.0_5

I just tried doing the upgrade as I am on 5.7.0_4 and got the confirmation beeps. Upon checking to confirm current version, I found it was still on 5.7.0_4 instead of 5.7.0_5 so I did another reboot and the version still has not changed. I have run the upgrade process a 2nd time and rebooted still with no success of upgrading to 5.7.0_5.

I just ran the upgrade and all went well. Upon completing and logging in again, I was pleased to find that only the intended programs remained disabled. I confirmed it is now on 5.7.0_4 and did a power cycle of the Polisy to ensure the issue did not persist upon reboot and happy to report that all is good!

I have been out of town and during my absence a power blip disabled my programs, some of which are critical so wanted to see if there are any updates on the fix.

I have just upgraded my Polisy Pro from 5.6.4_8 to 5.7.0 and all seemed to go well but after logging in I found that all Z-Wave was not functioning and the error message under the Z-wave tab indicated that Zmatter Z-wave is not responding. I have tried both rebooting and power-cycling with no success. I have submitted a ticket and am just awaiting a response.