n_sievers

Just did this and resolved my issue as well, thank you for posting!

Just checked and mine just reconnected a few minutes ago too.

Unfortunately mine still remains disconnected.

Thank you, I appreciate the quick response and will continue to wait.

I have received the notice that the portal maintenance was completed but unfortunately my system's connectivity has not resumed. When logging into the portal, it is still showing as disconnected with no remote access to UD Mobile and Alexa connectivity. I am running a Polisy Pro on v5.8.4.

I just got home from a trip and found my routines that announce sensor change of state are no longer working. I can’t be sure when they stopped for sure but was sometime between last Wednesday and today. I have tried disabling and rebuilding with no success. I am running Polisy Pro on v 5.8.4

I am on a Polisy Pro running v5.8.4

Just got home from a trip and found my routines are no longer working to announce state of change on a contact sensor. I have tried disable/re-enable and rebuild the routine but nothing was successful.

I just completed the UD Mobile update and all of my lock/deadbolt devices using the default icon that was previously a lock keypad, have now changed to lightbulbs.

Michel got back to me very quickly and just had to complete the upgrade to PG3x and now all is back up and running.

I just tried upgrading from 5.8.3 to 5.8.4 and all seemed to go well with getting 4 finalization beeps. I cleared Java and downloaded new launcher. I went to connect to admin console and was indicating still on 5.8.3 so I initiated a reboot and have now lost connectivity. I never got the 4 beeps and when opening the launcher, my local address is no longer showing and only the "polisy.local" address shows up with a UUID of all "0" except for the final digit which is "1" but is showing it is on 5.8.4. I have tried power cycling the Polisy and the same issue occurs. When I try going to the portal address in the launcher and log in, all devices are showing no status or functionality. My whole system is now down and I have submitted a ticket so am just awaiting a response.

It is very different from any others I have seen and even has a small hole on the opposite side of the case from the "set" and LED that has a small pushbutton on the PCB. The PCB has "Insteon" printed on it but think you may be right in that is was something specially manufactured for Smartenit. With that being said, it may or may not be a capacitor issue plaguing it and with no info out there on it, I may just go ahead and replace all caps with the hope in resurrecting it.

The PLM that was originally on the EZFlora (about 10ish years old) is not dual band, is also not marked as to the model and is a different PCB layout than I have previously seen or recapped; pic attached. The EZIO4O that I was able to successfully use the PLM to replace the faulty one on the EZFlora was a USB 2412U but also want to clarify that the PLM from the EZIO2X4’s that I first attempted to use are the same USB 2412U and do not work with the EZFlora. There is also a small pen marking “9B” on the upper right hand corner of the label on the EZIO2X4’s so I am just making am assumption that is some indicator of the deference in the base PLM’s used?

I recently had what I finally determined to be a failure of the PLM on my EZFlora but it didn't exhibit the usual PLM power supply failure where the LED goes out, rather it was intermittently losing communication and then finally lost full communication. I had a few Smartenit modules EZIO2X4 and EZIO4O (5010J) so tried swapping out the PLM and found that the version used on the EZIO2X4 would not link to the EZFlora daughter board but the one from the EZIO4O successfully paired and communicated so this leads me to believe there are some differences between the PLM's used by Smartenit. I had to cannibalize my EZIO40 in order to get my irrigation back up and running with the heat so now am left with a non-functional EZIO40. Does anyone have any insight if something can be modified with the PLM base from the EZIO2X4 to allow it to properly pair with the EZIO4O daughter board or does anyone have a spare base PLM they would be willing to part with?

I am so sorry for the confusion, I had meant that Amazon went silent on me and all communicated frustration was directed only towards Amazon. They continue to be so incredibly frustrating and unhelpful in every sense of their customer service! I have absolutely no disparaging words for UD and greatly appreciate all the work you do and help that has been given over the years! I am currently running 5.8.3, have deleted and recreated the routine again but is still not working; I will submit a ticket.

Unfortunately they have gone silent on me again without any resolution. I am currently traveling so will have to follow up again next week. They have not been any help thus far so unfortunately I will likely give up if one more attempt goes unresolved.

Mine still are not working. The open/close sensor status updates correctly in UD mobile, AC and the Alexa app itself but will not trigger the corresponding voice announcement. I have tried taking this up with Amazon directly for investigation on their side but they keep telling me it is being escalated to their development team but never get a follow-up response and have to start over from scratch every time; this has occurred 3 times already. I have just deleted and recreated the routine again hoping it would by some chance resolved but no success. I have Polisy Pro running 5.8.3

Here for a friend with the exact same issue occurring with his 994i Pro IR. When click on sync everything appears to sync properly and get successful sync confirmation. Test of remote connection also comes up as successful. Isy is properly connected and access is available through portal and AC. He is not currently at the site so cannot test the local connection with UD mobile to confirm if that works or not.

Thank you for the insight on this. I have contacted Amazon and that was an absolute exercise in frustration where the rep didn't know anything other than reading from their script. Tried telling me that I am incorrectly using routines as they are not intended to do this..... Finally after almost an hour and several transfers, I was told the concern was being escalated to the development team and would get a response back in 48 - 72 hours so just waiting to hear back now. I saw the announcement about the audio player plugin but haven't explored that yet; guess will add that to my list.

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.