dbwarner5

@Javi sorry if this has been covered, I didnt see it quickly. In Mobilinc, one of the key features to making the dashboard (favorites in UDM) and other program results, so useful is the customizing of the true and false results of a program. Some examples: -Garage doors --> Shut of Open vs true or false -Alert setting --> On or Off vs true or false -Certain settings around the house, are they active or not? Enabled and Disabled vs true and false. Are there plans to allow this in the future? Thanks!

Michel troubleshooted this for me and got me up and running. Here was his comment, which is way above my understanding... as usual.. THANKS @Michel Kohanim "The issue was that there was a FreeBSD.conf in /etc/pkg preventing polisy from using pkg.isy.io packages."

@Blackbird Yes this will mess up the programs in that the old references to the Elk Module get deleted and need to be re-entered into the program using the nodes from the Node server. Key to doing this easily for me was to ensure I had a copy of the programs via in the Admin Console (Before conversion), click on programs, then right click on the top header My programs and go to the last menu item Copy folder to clipboard and then paste into a text editor like word etc. Then after conversion, open this up alongside the Admin console and scroll simultaneously and update each program. This was by far the most work for me in converting to IoP and PG3 but WELL WORTH IT. The Polisy is much much faster and the link between elk and IoP with motion sensors is noticeably faster. See this thread for more info

Update. After doing some searches, did these two steps below and now rings are reporting motion* to Alexa which is triggering my Alexa routines to set "lights" (isy variable) to certain percentages which is now triggering isy programs! Excellent work around, albeit dealing with Alexa routines. Two steps: -changed ring Email to match Alexa email (took 4-6 hours for Rings system to catch up) -Disabled the Ring Alexa Skill and reenabled (after above email was registered and I could sign in again) side note: Have often also found a delay in Alexa variables triggering isy upon initial set up. Sometimes takes 12-24 hours before they work for the first time, so if heading down this path, be patient. *While the motion is reported to Alexa from Ring to trigger routines as described above, if you go to the Alexa app / Devices / Cameras and click on a camera and then View Camera Events, it always comes up empty: "Nothing yet". So even though Alexa isn't collecting the actual video, which is available in the Ring app, this doesn't seem to be affecting the routine from triggering

@bpwwer When I do this, I get one quick beep.. a delay of 1-2 seconds, adn then FIVE beeps.. what does this all mean?

Same here @Michel Kohanim. I purchased now a total of 6 ring cameras and 2 doorbells because of the integration with ISY via the PGC NS. Have been trying to get Alexa to work as an integrator per this post: But havent gotten Alexa to recognize the motion yet for some reason.

@DPerovich Another option is to use disable and enable. Prog1 IF temp >40 degrees THEN: enable prog 2 disable prog 3 ELSE: Disable prog 2 Enable prog 3 Prog 2 IF from 7am to 8pm THEN Repeat every hour, run pump, wait 5 minute, stop pump (your original coop pump THEN) ELSE Stop coop pump Prog 3 IF Temp is <=40 RUN Coop Pump ELSE Stop Coop Pump

@asbril I had to go back to the dashboard, and then back to Details of the NS and then it shows the current newest version number.

ok.. one last piece of advice, since you are now going to 2 programs to accomplish one task: -the beginning name should be the same so that alphabetically in your list or folder, they are close to each other. For example... all my door lock programs all start with the word LOCK, so they are all together, especially in the summary tab. for some more flexibility, for your above situation, you can also think of a third program that monitors it after the 9pm warning, but with a delay more like 1 hour for the first warning. If program two runs, it enables the third program that watches for it to be on and then waits 1 hr then warns. this may require a fourth program to "reset " and disable the fourth program each morning like at 6am. much more complicated, but the ISY can do most anything. Good luck

Changed the log level one more time, and restarted ecobee.. WORKING.. All back again! yeah! Thanks

@bpwwer @JimboAutomates Good news. got them running: -installed 3.0.5.2 -Front end Version matches Version -ALL node servers were not working : Kasa, ecobee, elk, notifications, time date, Weatherflow -One at time, I am changing the log level, stopping the NS, going back to dashboard, waiting, starting it again.. -So far they all are restarting successfully. Log level chosen does seem to matter, just changing it. Only one that seems to still be struggling is Ecobee. It may just need more time? this line seems to be repeating: Thread-37 udi_interface DEBUG Controller:shortPoll: controller:shortPoll: Skipping since discover is still running Will keep an eye on it. Thanks!!

will load it now and let you know. @JimboAutomates @bpwwer

Will try that and let you know. Thanks Sent from my iPhone using Tapatalk

No change. Here is my Elk Node server log fyi. thanks. Also fyi, noticed the versions aren't matching, but understand if that is just a UI issue. Version 3.0.51Status: ConnectedFrontend Version: 3.0.50 ELK_3-24-2022_50156_PM.zip

Several of my node servers are also not working since 3.0.5... will upgrade to 3.0.51 and see if that corrects them.

Interesting discussion re: Alexa. I too have many "motion sensors" initiating voices and have found the following: -After initial setup, nothing will work for about 12-24 hours (maybe less idk), but so trying to "test" one immediately after set up (and for the next subsequent 1-2 hours of frustration), it wont work. But the next day (because I usually quit after 1-2 hours), it works! -Have not had a problem with ISY reboots as far as I know causing Alexa to stop working. Used to use IFTTT for this and some KASA plugs.. not worth the hassle. Direct Alexa integration and node servers are much easier.

Mike, I was in the same boat. The switch to the Elk Node server wasn't too bad. Key was to do a copy / paste of all your programs into a text editor, then its easy to see what you need to fix. I have not found any shortcomings, but have seen other users comment about the lack of elk keypad feedback to the NS, but I didnt use that feature before so its not a problem. My elk integrates garage doors, sprinklers, motion sensors, voice pages etc and it all works great and at times I think it has a faster response to turning on lights via motions sensors than 994i / ISY/ Elk module, probably due to the speed and power of the Polisy.

Just to echo what @MrBill said above, in slightly more words as it IS confusing if you are just catching up to Polisy: ISY is a software package For the last ~12 years, it has run on a piece of hardware called the 994i The Polisy is a new much much faster (with more memory) piece of hardware. The ISY software can run on the Polisy hardware and hence we now have the Isy on Polisy, or IoP. Additionally, the Polisy can also run other software packages called Polyglots. There are currently two different Polyglots that can run on the Polisy: PG2 and PG3 PG2 is being phased out as PG3 continues to reach stability. Currently PG3 is in Alpha stage, hopefully moving to Beta soon. These Polyglots run additional software packages called node servers. node servers allow other third party products, other than Insteon and zwave, to be incorporated into the ISY as "nodes", ie a new switch in your tree, which then allows for monitoring, control and programming of these third party devices via the ISY software. node servers are currently free on PG2. PG3 will allow developers the option to charge for their Node server work in the future. (Lastly, there is an additional Polyglot package called PG Cloud. This was an initial attempt for running Polyglot w/o a Polisy and the software resided on a UDI server and hence the "cloud". This has been discontinued recently due to unresolvable security issues.) In summary, the Polisy hardware is a far superior hardware device compared to the 994i and with the inclusion of Polyglots, expands the utility of the ISY software dramatically with over 100 different node servers currently on PG2 and >60 on PG3. However, please note, the 994i was and is a FANTASTIC piece of hardware that most users would agree, has been ROCK solid for so long and will continue to be for ISY only, but it does not have the ability to take advantage into the future of the third party home automation proliferation. Hope that helps!

Update.. I changed it to remote, and am still getting 0 and 0 for distanced and strikes, all other data is updating as expected. ill give it some more time to see if it changes.

So if I change it to remote, will all the data be from the server or is it a mix of data from local vs the server? But I guess it will match whatever is in the app so it really doesnt matter as that is what I see now whenever I look? thanks

@bpwwer Thanks Bob for moving the thread and the response. Am not sure what would be the best solution. The goal would be for the isy to alert me if lightning is a) within a certain range, b) it is moving closer (done through calculations and variables from the distance data, as it changes). I didnt realize that the lightning data on the app isn't coming directly from just my tempest, but from the server. Is the configuration for the NS to pull from the server vs the local tempest a user choice or a programming choice you would make / modify in the NS? If its the first, then I can play with it to see what makes sense, just let me know how. If its the latter, then that would probably be a large group discussion / consensus based on what others might be doing with the data. I just have never really seen any data on the NS yet, but its winter so we aren't really having any lightning! Thanks again for all you are doing to move Polisy forward!

Have noticed that the NS brings over two pieces of lightning data.... I think its distance and strikes. The tempest has three pieces of data: Last detected in time, distance and # of strikes in the last three hours. The data doesn't seem to match See screen shots below.

Actually, I was able to "Send Settings" from an iPad that was reasonably up to date with my phone and it loaded all my customizations, as well as the old access settings, which then I redid per the above and all is working and I have saved 90%+ of my customizations!! yeah! (after years of using this product, I have quite a few, not just the dashboard, but custom displays, true vs false --> open and closed etc). Thanks for all the help!

YES!! Succes!!. I had tried that the first day, as that is what is in the WIKI, but realize now, I still had the double https:// so it didnt work. Have lost all of my custom settings now, so will try a sync with an iPad that has them and see what happens.

@DennisC Dennis, this is a known issue by Michel. they are looking into it. @Michel Kohanim