stillwater

I did not mean that the Shelly devices were ready for widespread US consumer adoption at this time -- in fact I raised several issues arguing in the opposite direction. Just that someone had done more or less what @lilyoyo1 mentioned. I specifically said I wasn't advocating them. Treat it as a proof of concept. They do it with the ESP32 platform which is widely available to developers. I doubt there are any intellectual property issues. In terms of predicting the wave of the future I suspect Wifi6 plus something like the ESP32 with more flash memory or RP2040 with wifi will win out over Zigbee or Zwave, though you have to worry about performance in urban areas with RF congestion. Or maybe LoRa or something else low power on 433 or 915 mhz will prevail eventually. The prevalence of wifi means that low-end of the market won't be available to fund the more exotic uses. Re Routers and Wifi Access Points -- I have had great success with Ubiquiti Unifi Edgerouter and Unifi access points. (I wish their branding was less confusing!) With several access points for 5G this leaves 2.4 GHZ open for IoT. The only glitch has been with a Roomba -- had to disable some advanced features on the APs that weren't doing me much good anyway. One of the new Wifi6 access points can handle 300 devices at a time. In fact the Shellies are a little more ready for adoption than my post suggests -- for people who don't need keypads and are retrofitting, their existing AC switches will work fine. From my reading of the various support forums it looks like there is abundant activity on Home Assistant to make using the devices more straightforward on that controller. (The changeover from Gen 1 to Gen 2 Shelly devices has put some bumps in the road). Re: No Shelly Switches Yes, I referred to the lack of keypads and meant switches too. As a Bulgarian company they have been more responsive to 230 v form factors and have just come out with their first switch (4 buttons per gang) but nothing yet for North American boxes. From what I have seen their plastics manufacturing is not the best anyway. If you like paddle switches there are high voltage switches that would work fine with no modification. For example the momentary SPDT Leviton 5657-2 (available in all the usual Leviton colors). This could control a single shelly input or 2 different Shelly inputs. And as mentioned the shelly inputs distinguish between singe and double taps and long pushes so you could in theory use it for 6 control inputs. (According to Shelly the i4 will later have additional input combinations with evolved firmware) [By input I mean either the switch input on a Shelly relay or dimmer or the input on a dedicated Shelly input device like the i4 or uni that communicates via wifi to other shelly devices or to a controller] My plan is to use dumb Kyle Touch Plate low voltage switches (either Mystique or Ultra). These are not cheap but they will never fail. I have not seen them close up yet but the pictures look nice (the Classic switches look clunky). You can get them engraved for $$$. And while it probably would be safe to use them with the non-isolated Shelly inputs, my plan is to connect them to the Shelly dimmers via opto-isolators so that there will be zero chance of shock. The Kyle switches are available in 1-8 momentary buttons per gang, with or without LED indicators (need to energize and control these separately). Update -- I received a sample Touch Plate Mystique 8 button switch in the Black color. My spouse said they are "beautiful." Not glossy like the Insteon or Lutron black (which always looks a little brown to me, btw). I haven't tried the engraving though on the Touch Plate site you can order either engraved button caps or engraved switch covers, or both. Touch Plate has been in business since 1946 so there is some likelihood that they will continue -- though this is only relevant for expansion or new houses -- there is no reason to think that these switches will ever break switching low voltage at minimal current (in my case 3 volts at maybe 20-35 ma.). https://www.touchplate.com/product/mystique-series-wall-switch/ (I actually ordered from Kyle Switch Plate in CA before I located the actual manufacturer).

@larryllix Re "Somebody just needs to develop grouping commands (Scenes) in WiFi based devices for less pop-corn effect." The following is just informational -- I am not advocating adoption of these but I am going to try some. I haven't tested this feature but the Shelly switches/dimmers/input devices have "webhooks" and scripting and some scheduling so you can set them up hubless. I vaguely remember the Gen 2 (ESP32-based ) devices have at least 5 webhooks -- so they can send http commands direct to 5 devices. I don't know how much of a lag between commands there might be but probably short if no authentication/encryption is used. There are drawbacks in that most of the devices are not (yet?) UL listed (though they are certified some other places), and there are no keypads (the input devices are designed to hide behind dumb switches) and most of the devices expose line voltage to the switches used to trigger them. A 50 cent photo coupler solves the last problem if you have a DC source -- (an AAA battery or a coin cell would have a very long life because it's only a momentary contact for something like 20 ma) and the input devices code separately for short, long, and double taps. And the Shelly Dimmer 2 can do a lot of tailoring in software (in addition to choosing between leading and trailing edge). But with no heatsinks it's limited to something like 200 watts -- and it's still a Gen 1 (ESP8266) device -- Gen 2 probably will be released by end 2022... The Shelly devices can also post/subscribe to an MQTT broker which would get around the small number of webhooks in the devices but still result in near simultaneous turn on of lights. There is a Shelly cloud but the devices can be set up to operate separately from it (and a router can enforce this gap if you don't trust the Shelly software to turn it off). There are also Shelly LED bulbs but I am finicky about light quality and don't plan on trying them. Also I'd stay away from the "PM" devices that have built-in "power measurement" as they seem to rely on resistors for measurement rather than Hall effect sensors and so generate more heat than they should. On the other hand the company seems to have rapid development cycles with frequent firmware releases and a hardware cycle that seems faster than most competitors so maybe they will manage to survive.

Right, but it could get you through selling the house.

@MarkJames My understanding is the 8 button and 6 button KPLs are the same under the plastic keys, so you just need 2 KPLs of either kind, of any color. May be able to find on (e.g.) Ebay.

@apostolakisl Future WiFi will have features to make it more friendly to numerous low power/low data rate IoT devices.... https://www.electronicdesign.com/technologies/iot/article/21182189/nordic-semiconductor-why-wifi-6-will-be-a-key-component-of-tomorrows-iot Whether this tips the balance to WiFi for HA I can't say. Unfortunately I notice that the new WiFi 6 Unifi Access Points only have WiFi6 on the 5 GHZ band. For my current project (new construction and retrofit with access to stud bays) I am going with maximum ethernet and wired low voltage stuff and some wifi devices (mostly dimmers in light fixtures). Sensors all wired. Switches/keypads will be dumb low voltage so completely agnostic to future technology. This is painful but the alternative was completely dumb with no comms.

One data point re Zigbee vs Zwave -- Nabu Casa, the business arm of Home Assistant, integrated Zigbee but not Zwave into their Home Assistant Yellow box. https://www.crowdsupply.com/nabu-casa/home-assistant-yellow Clarification -- the logic behind this choice is partly that Zigbee is the same worldwide whereas Z-wave operates on different frequencies and so makes more sense to add a USB stick as needed.

Interesting. I would have wanted the ability to separate the load from button A on a KPL. Theoretically if the LEDs became programmable and if one wanted to hack the FanLinc one could substitute a suitable opto-coupler for the LEDs and gain two more ISY controllable outputs from the Fanlinc. Also theoretically, could one write a Node server that would communicate appropriately with the PLM to provide functionality such as these elements that UDI has not included in the Insteon code in the ISY?

Maybe it doesn't come in the zw version. Others know better than I. I don't know much about zwave. Anyway it's very simple (see earlier in the thread). As I understand it (which may be wrong), it goes through the PLM to all the Insteon devices and updates the internal ISY representation of the status of all the devices. Presumably at 3:00 am the rest of the system is quiet and the rest of the house may be electrically quiet also (for better comms). The reason I disabled the program on mine was that during the query some insteon devices were being turned on that shouldn't have been. I figured this was because of screwed-up insteon traffic from the PLM, not the fault of the ISY. I also wrote programs to disable some key devices during the query all program (can't remember just now what I did). Anyway once I replaced the PLM the problems went away. I'd only worry about recreating it if you notice that the ISY seems to have innaccurate knowledge of device status - - but really I wouldn't be satisfied if the ISY were routinely ignorant of the status of one or more devices for hours at a time, as would seem to be needed to have a benefit from a nightly Query All.

No need to get huffy about this. The "Factory Query All" program came pre-installed on your ISY 994i if that is what you have. If it's disappeared it will take 90 seconds to recreate as detailed above in the thread by a very helpful person. Depends on how good your comms are whether you need it or not. I disabled it on mine because with a possibly failing PLM (since replaced) but otherwise perfect comms it was causing more problems than it solved.

That is not unusual in a system with insteon communications issues.

@larryllix I feel your pain. I am grateful to you and others on the "bleeding edge" -- will accelerate stable IoP for everyone else. I hesitated to comment because I am out of my depth but in case it affects others my Polisy log shows successful updating to Bios ver 1.1.3 from ver 1.0.0 despite a previous message saying "bios version 100 is old and needs to be updated." My polisy is very new and so there may indeed be some hardware difference but had I just read your post and had I not already updated I would have assumed based on my log that I had the "version 100 bios chip" you speak of and would have been fearful about upgrading. I am sure UDI will provide info once they understand the problem. PS My log looks like that of @JimboAutomates

What I understand from this forum is: 1) "Polisy" is a hardware box sold and supported by UDI that can serve as a co-processor host for node-servers for the ISY-994 controllers. A main focus of current development at UDI is porting the "ISY" controller itself to run on Polisy, obviating the need for the somewhat limited ISY-994 hardware. (Polisy is faster with more memory and a SSD rather than the SD card that has sometimes caused problem on the ISY-994.) 2) So your question is probably where is the guide to running "Polyglot" on the Raspberry PI. Polyglot is the collection of facilities that allows nodeservers to be easily installed and run between a coprocessor (Pi, other machine, or Polisy) and the ISY-994. 3) The current version of Polyglot that can run on a Raspberry PI (or on a Polisy) is called Polyglot 2, often abbreviated as PG2. I suspect you can find instructions for using this on the forum, though I haven't looked. But this may not be worth your while, because: 4) Most node server developer effort is now focussed on Polyglot 3 or PG3. This will only run on Polisy and provides a mechanism for node server developers to charge for the use of their products. As a result offerings in PG2 may atrophy and PG2 might atrophy as well. 5) There has also been a Polyglot Cloud that does not require additional hardware on-site with your ISY-994. For security reasons this is being rewrritten and is not available.

I am only offering a datapoint. Looking at my (smooth) ssh update/upgrade I find that my packages match the targets in @simplextech's log with the exception that my machine does not have pciids installed. So maybe that is the source of the problem people are experiencing? Again I am only offering data.

I upgraded via SSH without apparent problem (both PG2 and PG3 dashboards show up) but I wasn't running IoP or any nodeservers on Polisy before or after so perhaps not a very meaningful test...

Just got a Polisy and have some comments on the process just sort of fyi from someone new to polisy and polyglot. I mostly bought the polisy to future proof ISY/Insteon PLM combination from PLM or SD card failure. (Via usb plm or stick). So my intent was to just put it back in the box after I checked that it worked, and wait until IoP gets beyond ALPHA. I am NOT asking for troubleshooting or help -- just reporting my experience. I'm putting this on this thread because my positive suggestions relate to PG3. Caveats: (a) Because I wasn't making a permanent install I didn't initially set up a static IP address. Once I set one up in Polisy and in Router it didn't make much difference. Though Chrome did allow access (b) I didn't use with the ISY finder Experience: 1) Though I have a "modern router" (unifi edgerouter + unifi APs) i could not access the polisy using https://polisy on either chrome or opera browsers. (I could see on my router that it was indeed advertising the polisy name. ) Chrome also initially refused connection via the IP address owing to "scrambled" certificate.... I could access using Safari on MAC. Suggested work arounds (https://polisy.local and installing bonjour on a pc) made no difference. Also Putty on the pc wouldn't find the host polisy though it does find raspberry pis by hostname. Can ping raspberry pis by hostname (replies with suffix .local) but not polisy. Just weird but since I know its IP address it doesn't botehr me. 2) Polisy upgraded fine. I found it easier to SSH in rather than using the dashboard. Dashboard didn't always keep its promises on providing a second message if upgrade not required. So this didn't inspire confidence. 3) Despite looking at the wiki I could not find how to connect to PG3. Only by finding this thread did I discover I had to go to another port (3000). Since the wiki mentions PG3 how to access it should be included there too. 4) It was disconcerting that the default user/password combination still provides access via SSH and via PG3 dashboard even after password is reset to a different value via PG2 dashboard. I think the default behavior is that resetting the password in one place should reset the password in the other access modes as well. Since the stated plan is to get away from SSH the current behavior would leave the SSH access open forever via admin/admin. Not good! I hope this is useful to someone. Looking forward to moving from ISY994i to IoP when IoP and PG3 are more stable.

Use start.jnlp as detailed in the 5.34 upgrade instructions. Also upgrade to 5.3.4 which is the current release. See the first post on this page. https://forum.universal-devices.com/topic/33287-release-534-test-build-is-now-available/

Might as well upgrade to 5.3.4 (current release) at the same time. Follow instructions in the base post on this page: https://forum.universal-devices.com/topic/33287-release-534-test-build-is-now-available/

Hard to tell based on the very limited info you have provided but if it always happens at 3 am and you have the "Factory" Query all program set to run at 3 am (as many do) then I'd focus on the query all process -- first try disabling just that program and see what happens.

@Techman I just checked. You are correct, at least mostly. At least in one instance on 5.3.4. ISY did not delete the device from the program as listed. The name was still there. However the program did not run and the lines in the IF and Then sections needed to be updated and the program saved for it to work.

I am not positive but based on limited recent experience programs should still work as long as the added device has the same name in ISY as the old one. But yes if the ISY links table is the problem you'd have to manually add the re-added device to the scenes. Do you have a recent back-up from before the problem appeared? Restoring ISY from that backup that and then restoring the KPL device from the ISY inks table could test whether there could be some problem in the ISY links table. It would not be dispositive if the problem is caused by corrupting something in the KPL's internal program as as a byproduct of restoring a valid link table to the device If you want to try removing and re-adding the device you could do a backup first and then if it doesn't turn out to fix the problem (before adding back all the scenes) you could just restore the system from backup and restore the device and you'd be back to where you are now. OH -- before doing anything more with the KPL -- Did you try doing a factory reset of the PLM and restoring the PLM link table from the ISY? Perhaps a corrupt PLM link table is the source of your problem.

I don't have any specific ideas for you but here is a story that may give you hope: I noticed that a 2477s that controls a bathroom exhaust fan was acting strange -- a tap of the "on" part of the paddle when the switch was already on would turn it off. This was true irrespective of program or scene membership, The communications log showed only a DON message from the switch, as you would expect. On a factory reset of the switch it would behave normally. Restoring device from ISY would restore the weird behavior. Deleting the device from ISY, doing a factory reset of the device, and linking to the device all over again fixed the problem (at least for now). I don't know if there was something strange in the ISY links table or if the act of writing the links table to the switch was making it misbehave. (Or something else...)

This thread explains how to use a Raspberry PI (could be a zero or an A) to bridge between the ISY and the USB 2448A7 if Polisy is not available to you for whatever reason. I looked into using a RP2040 based board (Pico, $4) but none of the software packages (C, micropython, circuit python) currently support host mode USB beyond HID class devices. https://forum.universal-devices.com/topic/32546-insteon-2448a7-raspberrypi-isy994/

No, no need. If I were you given the current shortage of Insteon devices I would clip the wire to the beeper and hope that it works otherwise.

Interesting. Did you try a factory reset of the "problematic" one?

Clutching at straws here -- before replacing the ISY I'd try the following 1) I assume you've tried rebooting the ISY? If not that's an easy thing to try 2) Maybe a new SD card? ( @Michel Kohanim would have a better idea whether this is a conceivable fix for the problem)