ase

As asbril said try again. make sure all letter are lower case. Is this ISY994i or Isy on Polisy?

I can't answer for UD, But, what I can say is that several of the products that are listed on thread's official website are already supported via polyglot. The other thing that hit me is the fact none of the products use Thread exclusively. They all have some other protocol available. This doesn't bode well for the protocol. Supporting a new protocol outside of the polyglot framework would be a massive undertaking. If the manufacturers who build on Thread are not fully committed to it why would UD want to spend the time to develop it within ISY? The other big issue is the fact it is IPv6 dependent. That isn't big deal if you live in say an asian market that has been quick on the pick up of IPv6, but, in North America where a huge chunk of the business is, that is nearly a deal breaker. While most devices in the market are capable of running IPv6. In most home deployments, it is off by default. Most North American consumers are not going to be able to enable IPv6 throughout their network. I am sure this is why none of the manufactures are 100 percent committed, they need a fallback. That being said I think it is a wonderful protocol. It is everything I want in a protocol. Network layer based, IP Aware, Encrypted, Mesh, and Open Source. The Fact it is Network level and IP aware means the medium becomes nearly irrelevant. It can communicate via RF, Powerline, Bluetooth, Wifi, Ethernet, or any other medium that can connect two IP nodes. That IPv6 requirement though, that complicates things. If manufactures continue to implement it, I could see it being supported broadly in the future. There just won't be a rush to support it right now, by any company building Home Automation hubs. The American consumer is used to being spoon fed products that require very little work from them. The market is already crowded and confusing to the average American consumer. And as unfair and insane as it seems most of the corporate world places their bets on the American market before all others.

I gotta call you out here. This isn't a unique model, not by a long shot. This is how nearly all software and technical products are built. Linux for instance powers 100 percent of super computers 80 percent of all servers, 87 percent of all cell phones. Linux has thousands of distos, millions of libraries and software packages. Apple for instance uses Darwin as the bases for all of its OSes. Darwin is simply a disto of FreeBSD, the very same software at the heart of Polisy. What you're thinking of is consumer level products. Products that are designed to be fool proof, that prove the quality of human fools. When it comes to professional products of any kind, in any industry, it is up to the professional to determine how well each item works for the scenario they are dealing with. That is why they are professionals. In software development no single company can produce vast products of quality. Take Microsoft for instance, they are more known for crashes, blue screen of death, and security holes than reliability. Meanwhile Linux which is open source and built on millions of "third-parties" is the most successful OS in history. This not so unique model allows for diversity of choices, diversity of support, openness of code allowing for flexibility. The fact is that this method breeds stability by allowing code to be viewed and modified as needed. That being said, it is possible that in the hands of a novice or a pseudo-professional that this can lead to instability and difficulty. However, that is why it is best to allow true professionals to deal with professional things.

SSH in and run sudo pkg update and then pkg upgrade

Meraki firewalls are layer 7 aware, you may need to add a rule specifically for Portal. I would use a network sniffer to see exactly what port ISY is attempting to use to get out then add a rule for it. Meraki is very paranoid.

If you are using Pi3 or Pi4 you can run 64 bit if that is possible you can download a 64 bit DEB at https://www.mongodb.com/try/download/community or if you need 32 bit you can compile it from source. The other option is to use Ubuntu Server for Pi and just install the version in their repo. On a side note, compiling isn't very hard in most cases you just navigate to the folder, issue the commands ./configure followed my make and then make install and you are done.

Seriously, you need to let it go. I explained what I was doing, I don't answer to you. If you are unable to "get it" then that is on you. You seem to have some type of complex that you "need" to be "right". I am here to help people if I need to break it down for people that is what I will do, if need to use their incorrect terminology to help them I will. Now growup and act like an adult. I will not respond to you any further and any further response from you will just show how petty you are. Go look for a fight elsewhere.

NP. I had to do that with both polisys I have.

This is a date issue with in BSD itself. This is an issue with BSD date time. You need to set the date and time in BSD. Certs are date time sensitive. You need to ssh into the unit. run the sudo date yyyymmddhh so if I were to set the time now I would run it as sudo date 202112100314

I wanted to call it what he "understood" it to be. Different objective. If a person only understands a mug to be a cup and you want to explain something about a mug to them you call it a cup so they understand. Again what we "say" is important. Sorry you can't catch me up in a logical conundrum buddy. One post is pointed at solving a person's problem and using their "terminology" so that they understand, the other post is to point out that if he understood the terminology that the group uses the miscommunication wouldn't happen. I was pointing out the fact that terminology in any method is user sensitive. Hence why communication seems simple and yet people take 7 year college courses on it. My point was that words are how we think. You would be hard pressed to find a non-tech understands the term "firmware" yet to the highly technical most of what is called firmware isn't even firmware. There is not only a gap between non-tech users and technical users but between their experience level and their background. Then to top it off we have ubiquitous language that is used incorrectly or technical terms that become ubiquitous. Look at the term Xerox, it comes from Xerographic. Xerox itself wasn't a word until the company comes about. I don't think to many people have ever asked their assistant to go make a xerographic. Kodak, another non-word. Yet if I tell you to take a picture with a kodak, and Xerox it, you know what I mean. UDI is actually quite good with technical terms, unfortunately the terms used within this industry are not singular in definition nor are they ubiquitous it the public "zeitgeist". Many of the terms come from different sources and are either technical in their own right or BS marketing jargon.

I like most of what you said, except what we call it matters. If you don't think terminology matters, just watch the show air disasters. Communication is the key, and is often a huge problem. I will take you statement from above as an example. "Once fully operational, users will not need the Isy to manage and control devices since polisy will be able to do the same thing." Stop and think about how that is phrased for just a second. Are you saying ISY the hardware won't be needed or ISY the Software won't be needed. Those are two totally different statements with the very same words, depending on what the person reading them understands. I mean if we want to get technical ISY has never been hardware, the ISY994i Hardware is actually a custom board with NXP's Coldfire Chip. Firmware Technically is a low level SOFTWARE that controls the chips themselves. So technically speaking ISY has never been a Firmware from the strictest sense of the word, it has alway been a program the runs on top of some OS. I have no Idea which OS was used with the Coldfire chips. So again depending on the knowledge of the reader a statement like we see here could mean something very different. Coming from 25+ years in computers, with and in depth understanding of Linux and BSD, having worked in many programing languages and having been on the hardware integration side as well. I am going to see things very different from someone who has little background in these things and is just trying to control some lights and a sprinkler system from their phone. What I am getting at here, is language is the single most important aspect. Miscommunication is at the heart of most of the worlds big disasters. Language is how we think and therefore how we act.

Didn't want to further confuse the poor guy, so I wanted him to differentiate polisy hardware from the software, he said he didn't understand Node and so on.

ISY is not a box, it is a program. 994i is the box. ISY is currently defaulted to install on the Polisy Hardware(which is just a PC from PCengines). Polisy hardware runs FreeBSD as an OS, Polisy the program runs on top of that OS the same as ISY does. At the OS level both programs are unaware of each other. Polisy(the software) is just a connection point for NON-Insteon and NON-Zwave hardware to communicate with ISY. ISY is still the "Brain" that orchestrates the automation. Since the two programs are unaware of each other on the OS they still operate as if separate(different hardware). For Polyisy and ISY to communicate with each other Polisy(program) Needs to find the ISY, if being run on Polisy(hardware) it will just be the IP address and port 8080 with the username and password for the ISY(program) Now PolyGlots are just small scripts that allow Polyisy to communicate with those other services or hardware(Tesla, Roomba, NOAA, and so on).

If you haven't cleared the cache, you can use pkg file in /var/cache/pkg to restore isy back to 5.1.1. You will need to uninstall isy 5.2.0 with sudo pkg delete isy (this will remove all configuration so you need to have a backup of isy if you don't have a backup, use sftp to copy /var/isy/FILES/CONF) then reinstall isy from cached pkg in /var/cache/pkg. sudo pkg install isy-5.1.1_7.pkg. I had both build 7 and 5, I reinstalled 7.

I used http on 8080 and https on 8443. That is the correct ports for the proper protocols. NMAP scan showed that isy was not listening on either port. Once the unit was downgraded back to isy-5.1.1_7 and backup files placed back into /var/isy/FILES/CONF/ and a restart, it listened and functioned perfectly. Upgrading once again caused unit to stop listening again, restored works again. So it is obvious that there is an issue with ISY-5.2.0_52.

Downgraded back to isy-5.1.1_7 restored backup and everything works. Reinstalled isy-5.2.0_52 and it doesn't listen on either 8080 or 8843 again.

I just run pkg upgrade and it upgraded ISY to 5.2.0 however now ISY is does not appear to be listening on any port. I can still access via portal and UD mobile.

Here is a walk thru on how to use SSH on a mac. https://www.servermania.com/kb/articles/ssh-mac/ Follow instructions