ase

As we have discussed for literally days at a time. Both Polisy and Eisy are X86-64 PCs, just like you have sitting on your desk. They are simply smaller format. Polisy OEM was pcengines(https://pcengines.ch) all of the accessories like wifi and Bluetooth cards are available at that site, even wall mounts. Eisy OEM is MELE(https://www.mele.cn/). The OS for both is FreeBSD. In terms of why you were not able to use the backup directly is most likely because your windows based computer probably didn't have the needed options to mount an ext3/4 filesystems. For the best experience when working with systems like Polisy it is best to be working from a Linux or BSD system(windows sucks anyway). In terms of backup you can easily transfer any files with sftp and for full backups simply use dd to make an image. If in the future you want to use either as something other than a home automation controller, you can reflash the bios (I don't know if Eisy is a custom bios) and install OS and software you want.

You have 10 of them being powered separately? Are these attached to mini split systems, zone controllers or central?

I am just glad I have enough backup plms to last me for several decades. We shall see where everything goes. I find myself actually optimistic about matter. Insteon seems to be focusing on hub for now (which makes business sense). Insteon may enter the public domain in the future so hub makes sense for Insteon. Plenty of manufacturers are still committed to z-wave, and matter seems to finally be on track. UDI has eisy which appears to be built on the excellent work at Mele(they built excellent small form systems). I find myself feeling optimistic about the direction and diversity of the industry for the first time in a long time.

The big questions are. Does insteon intend to manufacture any plm? And do they intend to continue allow local api access on the hub? If they maintain local api do we begin to bulid a node to control insteon via the hub?

I would expect a lot of the queue was issues that occurred during the bankrupt period and probably have been solved via other means, but ended up in the system one way or another. These Troubleshooting and ticket systems can become overwhelmed very easily, with each ticket taking hours to close because you need to make contact and then figure out if any real issue exists. Often times it is simple user error and takes time to figure out that. If I were them I would post a blog post and e-mail all addresses with open tickets to resubmit any issues after a purge. Any users that truly need help will resubmit, the rest will just fall off and not be an issue. I think that is likely what they will do.

As for troubleshooting Insteon. I have always found it to be very easy. If you are using Insteon Hub, Insteon itself runs in a single process and the suite they built around it has several tools to help troubleshoot issues. Simply ssh session run some tools and bingo you know what the problem is. As for with a PLM or USB stick you can simply plug it into a computer and use your choice of several dozen insteon command line tools. Several have options to find bad links, issue commands and so on. Very early on Insteon was very open and willing to work with other. I think the closing down of that communication and openness is what put the final nail in the coffin. Had they been open with us(the Insteon community) about what was going on and how component shortages and free acess to hub had been draining the money, I am positive they could've raised capital. Hell I would have invested. Either way the earlier openness spawned a number of great tools to troubleshoot issues.

I agree wired is always better. TCP/IP has 4 layers. However, most network engineers use the OSI model for education which is 7 layers, so I will do the same. 1. Physical layer. 2. Data layer. 3. Network layer. 4. Transport layer. 5. Session layer. 6. Presentation layer. 7. Application layer. The only device that doesn't have "routing tables" is hubs. Hubs do not process any switching, they simply forward all packets to all ports. Hubs are known as a layer 1 device. Switchs in the strict sense are layer 2 devices and hold a table of MAC addresses. This is how a switch knows which ports need to talk to each other. Routers and "smart switches" are layer 3. They are both aware of IP addresses and MAC addresses. So you see unless you are using a hub(which would be a huge cluster f) each device is at the very least routing MAC addresses. Now even at the top of the mark consumer grade wireless routers are often quadcore arm processors or less with very small memory footprints. Think raspberry pi 3 or lower for processing. I have seen some "top" consumer grade routers that can only handle 120 entries. Nowadays doesn't take long to get there. The biggest issue with attempting to use UDP for anything really, is lack of data verification. UDP doesn't have any error check, so if data is corrupt, too bad. Now maybe wifi maybe the way of the future, but I am not going to hold my breath. More and more people are g upgrading to gigabit connections, in my neck of the woods gigabit is the second slowest connection one can buy, and maybe the slowest connection available within 2 years. The additional spectrum is more likely to be saturated quickly as more people move towards 10gigbit connections. Intel has proposed IOT in wifi 7, the question remains if consumer grade routers will upgrade CPUs and Memory enough to really see an advantage. It all can work smoothly enough right now with professional grade equipment. However,we have to accept that the reality is a home diyer buying a wifi swich off shelf and home depot and is at best running a linksys router they bought at Walmart. IMHO wifi is never going to be the best route for Home Automation. IP and network aware, yes. People will just keep saturating that bandwidth with video and games.

You're getting things mixed up. Rule one higher frequency always has lower propagation. The higher the frequency the more difficulty getting it through walls. Look at satellites, we can send very high frequencies from earth to space and back. Put the dish indoors and see what happens. The fcc hasn't signed off on 6e yet, it is still in comments. 6 ghz is not fully available on any consumer grade hardware. TP-link is the manufacturer that has deployed the most 6ghz and they max at 80 per channel. 6e should extend that to aggregated 1200 mhz. Either way it has to exist in co-exist mode(partial channels). We still have other things in that band. This creates the complex issue of maximum time a device can hold the channel. I think you are confused as to the difference between draft and full approval. The fcc often approves use during the draft period. You started seeing 5g in 2019 even though the draft wasn't closed until 2021. The next issue is packet size. Both wifi and tcp itself has standard packet sizes. This makes them very efficient for larger data but very inefficient for smaller data. Think of it like you needed a button battery and you ordered it from Amazon. Instead of an envelope, they send it in a 30x30x30 box and they pack it full of air packs so that the box doesn't collapse. This is kinda what is happening when you send small bits of data along tcp. There are several levels involved in sending that data that just isn't needed for control of a simple device. Meanwhile this effects the capacity of the device at a switching level. Example you can max out a 5 port gigabit consumer grade switch with just a couple of security cameras. 1Mbps continued will max out the switching capacity of that device. Now use a professional device and you couldn't replicate it. Most people just use whatever their ISP gives them. A low capacity consumer grade wifi ap gateway. Go talk to the claims department of your local Walmart, routers are amongst the top disposition items. They get sent back nearly as fast as they come in. For all kinds of reasons. Wifi and consumer grade networking just isn't the best method for IOT/home automation. Like I said, if installed properly, routed properly with proper professional equipment in an uncrowded environment, sure it will work great. Unfortunately you can't guarantee those conditions.

The fcc has not given the green light on 6e yet and 6ghz in the US has lots of strings attached. https://www.fcc.gov/document/fcc-opens-6-ghz-band-wi-fi-and-other-unlicensed-uses Most consumer grade equipment hasn't yet added 6ghz in the US. Even if they added it it will reach less distance than 5ghz and 2.4ghz. And none of that does any good without upgrades in memory and CPU to speed up switch capacity. None of it makes wifi for iot any more reliable. For that we need a sub-protocol and dedicated memory for iot routes. Which is why it is in draft for wifi7.

Well here are a few things to think about. The reason the number of aps showing on your list matters, is each one is an ap taking a chunk out of the available spectrum. The wifi alliance has basically said that the USA wifi spectrum is substantially congested. While there is momentum to open 6ghz up to wifi, that's going to be a bit yet. Next issue is most consumer grade hardware is maxed at 253 devices. Even if you change the IP class the router most likely has a routing table that can only handle the 253 devices. Next issue is most switches and routers have roughly 1/4 to 1/2 switching capacity as there max port throughput. This means that the device cannot maxout any interface. This also means small data being continuously exchanged weights down faster larger data streams. So having a light switch beaconing updates could cause performance issues. Both 4G and 5G had sub protocols and dedicated memory in devices for IOT for a reason. WIFI doesn't have such setups, although it is being discussed for WIFI 7, we aren't there yet. Next issue is that TCP/IP is a routed protocol. That being the case each piece of equipment must have some level routing table. That means the only method of broadcast is via the subnet broadcast address. This isn't exactly reliable across WIFI. The alternative is UDP, king of speed and failed packet delivery. As for WIFI "tools" there is only one worth talking about. Spectrum Analyzer and one thay will give you the whole picture costs about 1800 bucks. On the Insteon side any PLM can be paired with a computer and see where the potential issues are. As for cost, zip, the tools are free open source. Can a WIFI IOT/Home Automation network be built that works well? Yes of course. However, it almost requires a dedicated wifi network of its own. Furthermore way too many of the factors are out of the owners control, you can buy the best of everything and have it all fail because of something outside of your control. The creators of the many Home Automation protocols are not morons, they understood the issues with just trying to strap a wifi chip onto a device. Insteon was/is considered superior to most because it built on the bedrock of X10. Each device did a little bit of the heavy lifting, it was a true and complete mesh. Devices didn't require a controller or a central hub.

So as I stated back when the demise was but a rumor, the technology would continue even if the company failed. This is exactly what has happened. Insteon from a technical side is and has been head and shoulders above the others. There are still products that no one else makes better, like Fanlinc, the keypads, and the outdoor plugs. So here we are a new Insteon has risen from the ashes. I know I have questions and I am sure many of you do as well. Michel has said he has known Ken for years, this is a good sign. My questions are simple: Will the existing line of devices be brought back? Will Insteon be licenced to 3rd parties? Will Insteon be apt to work more closely with UDI? From posts in the Insteon SubReddit, it sounds like Hub will become a fee based system(as it always should have been). Now the issue is does that make them less or more likely to work with 3rd parties. Michel may already have these answers, and be unable to share them, or maybe nobody has those answers yet. I personally am just happy Insteon is back with better leadership. I think now, we may see just what Insteon really can do.

The hardware is from pcengines and is world renowned for reliability. After reading you past posts, I think there maybe some issues with your power source. The processor used in polisy is a passive cool model and is mounted on the bottom of the board. AMD white papers don't have any design for active cooling on the processor. Polisy shouldn't ever get hot enough to cause any issues. However, just like any electronic device it is sensitive to voltage drops and spikes. Also note that any computer processor is vulnerable to different type of electrical waves. You may want to do some line quality checks.

Try sudo -i to enter root and reissue commands without sudo

I think you may be stuck in a cycle of over thinking. Break down each think into a smaller program and then have a master program set to run each of the programs. It may take some trial and error. But, I find breaking it down into smaller bits helps to find what does and doesn't work and the adjustments are easier.

Their are several ways to use the hub as a PLM. Most methods are just to use the local "api" for access for other software to use it. Their are "ports" on the board for direct communication with both RF and PLM. It is my understanding (I have personally verified) that the hub does run linux and that insteon is running as a single process on the hub. If it is running Linux there are several options from that angle as well. I have several hubs kicking around and will be exploring all the possibilities. I have used openhab in the past. It does the job of controlling, not a whole lot of power there, but it does work with hub as a plm.