stillwater

@simplextech Good thing you chose HTTP rather than COAP because the 2nd Gen Shellies (ESP32 based Plus and Pro) that are (I assume) mostly or completely replacing the ESP8266 1st Gen do not use COAP. On the other hand they allow MQTT and the Shelly Cloud to coexist on the same device (optionally). There are some subtle differences in the HTTP responses of Gen2 vs Gen1 that may require attention also, though it seems in recent firmware these differences have been narrowed somewhat. Obviously you have a connection to a better source of info than me.

I originally looked at the Shelly devices when the Insteon Micro modules became unavailable (Dimmer, On/Off, Open/Close). Shelly had almost the same form factor (maybe a little smaller?) and functionality though of course via wifi rather than Insteon powerline/RF. They also could be separated from the Shelly Web application, which was a plus in my book compared to some alternatives. Ultimately I had enough Insteon modules for my needs at that time. Frankly coming from the ISY/Insteon world the Shelly world was something of an adjustment. @simplextechas far as a node server is concerned, the Shellies are so flexible I am not sure how you would go about configuring them as nodes except to some extent as substitutes for the earlier insteon modules... Looking forward to see what you do with them. I'd tend to use the MQTT mode of communication with them.

Nothing "just works." On the Shelly English Facebook support group right now there is someone who is trashing all his or her zigbee devices because they keep dropping off the network --and replacing them with wifi shellies.

FYI for Forum readers.... Google says Doug Roberson is the CTO of Allterco Robotics US, which I take to be the US arm of the manufacturer of the Shelly automation products.

@Doug Roberson Thanks for the explanation of the Shelly Plug US backlog and redesign. The inclusion of a heat sensor and automatic disconnection on high-temperature in many of the Shelly devices is an impressive safety feature.

@lilyoyo1 Here is the "Features" description from the Python Script in the Github link posted by @Doug Roberson This utility can be used to provision, maintain, update, and keep an inventory of IoT devices. There are many different operations available, described briefly here, and in more detail in the built-in help for the program. It can automatically locate new devices that are in the factory reset state, ready to configure. Each located device can be added to the local WiFi network, using the "provision" operation, or added to specific other WiFi networks, on a per-device basis, using the "provision-list" operation. The provision-list operation can also assign different static IP addresses to each device if required. With provision-list, one or two spare DD-WRT routers can be used as the client connection and WiFi access point, automatically configured at each step to match network SSID of the factory reset IoT device and the target SSID and credentials specified in a list of instructions given to the program. Note that with two DD-WRT devices, the process is much faster, able to provision 1 to 2 target devices per minute. When using the simple provision operation, your computer or laptop will change from one WiFi network to another (to connect to the target device's WiFi hotspot to configure it). Using the more sophisticated provision-list can mean no loss of WiFi connectivity on your computer, since instructions can be sent to a DD-WRT device to set the WiFi SSID instead. The provision-list operation in this mode is generally twice as fast as provision. There are commands to work with the set of instructions used by provision-list to import, view and clear the list: "import," "list," and "clear-list". The concept behind importing and managing the list of instructions is so that the program can easily resume where it left off. The set of "todo" items gets checked off as the program successfully provisions each device and this information persists even if you quit and then restart the program. The provision operation supports only DHCP, while provision-list can setup devices with either DHCP or static IP addresses. Either operation can additionally command each newly provisioned device to take an OTA firmware update to the LATEST or a specific version of software. With provision-list there are many additional features, including setting the name of the device as it shows up in the phone app and in the settings web UI, plus latitude/longitude and timezone on an individual device basis. The imported list of instructions can include a "Group" column, which then allows provision-list to work on a specific set of instructions instead of the entire queue. A mechanism for automatically printing labels, given a small program provided by the user, is available with both provision and provision-list, but additional attributes like "Label" (a free-form text string) can be added to the imported instructions for provision-list. There is a "factory-reset" operation which makes it easy to return a device to factory settings, given it is on the local WiFi network. The "flash" operation instructs local devices to take an OTA firmware update. A database is maintained with all of the newly provisioned devices. For an end-user provisioning devices for use on a local network, the database is tremendously useful for tracking the devices, managing settings and performing OTA updates. For existing devices on the local WiFi network that weren't provisioned using the tool, there is a "probe-list" command to discover their settings and status. For battery-powered devices that are only periodically available on the network, the option --access=Periodic lets probe-list run for an extended period of time looking frequently for the devices. A powerful "query" operation can report on any information recorded during provisioning or found using the probe operation. An "apply" operation allows programming the discovered devices with OTA firmware updates, as well as making arbitrary settings changes using the --settings and --url options. An "identify" operation is available to continually toggle on/off a light or relay, given an IP address, in order to aid in identifying a device. Useful, for instance, with multiple light bulbs in a lighting fixture. The settings from one device can be copied to a new replacement device using the "replace" operation. Having transfered the settings, it is then possible to use "apply" with --restore to reprovision the replacement device. Use the "list-versions" operation to check the available archived versions of prior firmware for a device. The "acceptance-test" operation checks that devices can be contacted in AP mode (factory reset) and toggles their relay, without provisioning them. For a more complete test, choose "config-test" which provisions each device, toggles their relay, and then returns them factory settings.

Website is working for me (Chrome browser on a Mac)

Conceivably a niche player could economically resurrect the previous product line by paying next to nothing for the rights and having better management. Seems like if a major player were interested they would have bought it by now.

@Idan I ordered a Shelly plug (US) in December and it hasn't arrived yet --though I did receive a Pro 1 -- so it's plausible the problem with your delayed replacement is lack of stock rather than poor organization. It's true that communication is not their strong suit -- I received a partial order and had to inquire by email to be sure that other items were still to come ---but they did respond by email after a couple of days. Their management actively participates in the Facebook Shelly English Support group -- Not as organized as UDI forums but a good place to get the pulse. The eu official support forum seems to have has less corporate response but seems to be more organized. Google translate is useful if you don't understand German...

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?

@CPrince There is nothing special about that triac, though they do seem to be out of stock. Digikey has 174 of the 800 volt version of that triac in stock for $1.97 each Quantity 1 https://www.digikey.com/en/products/detail/littelfuse-inc/BTA16-800CW3G/1961059 Just gives you an extra safety margin compared to the 600 volt version

I have multiple clerestory ("awning" ) windows that have motorized openers actuated by insteon micro open/close modules. Automated by HVAC control system -- primarily to cool down the house in the evening in Summer. Auto close on rain and smoke. I am also aware of motorized skylights. For example https://www.fenestration.net/pdf_documents/Quasar-L-InstallGuide.pdf Hard to see how you would motorize a double hung window though could have sort of a worm drive with a gear track, - but binding would be a big problem unless you drove both sides, and security could be an issue also. I think there are motors for use on casements in inaccessible places but haven't put my finger on these. Probably manufacturer specific but could replace the crank. Since the Insteon Micro Open/Close may be unavailable, it may be of interest that there are small Shelly devices that have two relays in them that can serve the same function, activated over wifi.

Not sure what wiring configuration you have or intend. Are you thinking of an intentional delay to have two inrush pulses through the 2477s? If all there is in the ceiling is 2 wires + ground coming from the switch, then the 2475 would have to boot up before it could receive commands. This wouldn't be the best arrangement and it would also be more intelligence than you need. A DC relay fed from a wall wart through a series resistor and capacitor to ground could be set up to have a delay of maybe a fifth of a second (could easily be more) which would be enough to delay the inrush from the second group -- would be cheaper and more reliable than an insteon switch. If you have power and neutral in addition to the switched line in the ceiling then you could use the 2475 as you suggest but you could instead use a relay with a 120v coil just to switch the other 4 or 5 bulbs when the 2447s provides power. Also cheaper and more reliable than insteon. But without knowing the actual in-rush current for your bulbs and the ratings of the relays there is no guarantee that you'll get long life out of splitting the load in half. How long did the original 2477s last? There is also the alternative of putting an NTC (negative temperature coefficient) thermistor in series with each LED socket. For example a GE or Amphenol CL-140 NTC thermistor ($1.34 each in quantity 10 from Mouser) is rated 1.1 amp full load. It is 50 ohms at room temperature which would limit your start current to less than .4 amps per LED or 3.6 Amp total (would be less because there's some series resistance in the LED power circuit). At 75% of rated load -- the on (hot) resistance is 1.3 ohms so it would dissipate a watt for each bulb -- less than 2% loss. Actually you are closer to 100% of full load where the resistance is 0.9 ohms. There are also fancier soft-start circuits that might combine an NTC thermistor with a relay that would close after the inrush to eliminate the heat dissipation after the lights are on. Obviously test this on a bench with one lamp, wearing safety goggles, before installing.

Wow over 11 amps at 120 volts with inrush current probably several times that. I am a big fan of the Omron G9H hybrid relays though they cost $90+ sometimes you can find them new on Ebay for 1/2 or less. You'd have to match the "coil" voltage to what's in the dimmer and run coil wires outside the dimmer to the G9H because I doubt even one would fit inside the dimmer case. But they top out at 10 Amp continuous (80 Amp surge if I remember correctly). You could put two in parallel but that would be expensive and take extra some space. (It's not like putting regular electromechanical relays in parallel which doesn't work because one will make or break before the other. [Correction: Omron says only put SSRs in parallel as protection against open-state failure off one and not to increase current capacity because often only one would conduct due to differences in on-state voltage drop. ]

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.

I can't remember the sources but my memory is that I concluded back in 2014 or 2015 that the 2477D, rated 600 watts incandescent, was only good for 220 watts of LED load. I can't remember whether this was specific to my (SORAA VIVID GU-10) LEDs or generic. Also there used to be instructions for thermal de-rating of dimmers when in multi-gang boxes adjacent to other dimmers. Relay switches shouldn't be subject to thermal derating and the derating for LED for a relay versus a dimmer would depend a lot on the internal circuits in both the dimmer and the LED.

Correct about in-rush current. Conceivable to have an NTC thermistor in series with load(s) which would reduce the problem unless the the load is turned off and on again before the thermistor has a chance to cool down. Best to use a hybrid relay with an SSR or Triac to switch the ac on and off and then a relay contact that closes after the SSR to eliminate the voltage drop (and heat) across the SSR and then the relay contact opens a few cycles before the SSR is turned off when the load is switched off.

@RPerrault If you like ip distribution take a look at Shelly devices and also the ESPhome library for Home Assistant. The new Shelly pro units have wired ethernet for areas where wifi could be problematic. The ESP32 provides adequate security and built in wifi and bluetooth and will allow doing anything you want. Of course there is a dearth of devices that have been UL approved and decently productized but all the building blocks exist. I do think that the problems of the cheap ISP-provided Wifi access points and the home wifi environment especially in town houses and apartments is a significant issue keeping serious players from using 2.4 GHZ wifi as the main rf net for home automation. I suspect that before too long you will also see RP2040 based systems but ESP32 is plenty of power for most applications. THe shellly Gen 2 devices provide significant peer-to-peer scripting and scenes without the need for a hub (but also MQTT for a hub based system) so their is lots of capability even without the Shelly cloud based app. (Not having any heatsinks in the hardware does cause issues though) EspHome -- https://esphome.io/