stillwater

I am sure this won't be helpful to current participants in this thread but it might be to any onlookers... Maybe a month ago I set up a new Polisy using the wiki as a guide and there was zero ambiguity about which RJ-45 port to use for ethernet.

I am confused. The original program that wasn't working was looking for DOF command and now you are focused on DON not translating into proper state in IoP? Are you thinking these are the same problem (i.e. in the program the IoP thought the load was ON when it was OFF?)

I believe you mean Polyglot (which is a software facility for node servers commonly run on a Raspberry PI or on a Polisy (which is a piece of hardware sold by UDI that can run node servers in conjunction with an ISY or now can also run ISY software obviating the need for a hardware ISY). There is a Polyglot V2 but not a Polisy V2. I suspect you don't have a Polisy. PGC ran on virtual machines in the cloud until it was shut down for security reasons.

We are going to google for the answer. Seriously there are numerous threads already in the Smarthome subforum below. https://forum.universal-devices.com/forum/20-smarthome-channel/

As others have noted, the "Nokia" devices were not a Nokia effort -- just a licensing of the Nokia name by Smartlabs. So the informed view is that the Nokia devices are dead as well.

Thanks. This is the North American product index page -- listing of all certified Zwave products with North American frequency. https://products.z-wavealliance.org/regions/2/categories Lots of products.. Some of which are available!

Thanks! The Zen51 and Zen52 appear to be 1.5 x 1.4" and I don't know how thick so they look micro size. They are 700 /S2 series. Thanks for the direction to Fibaro and Aeotec. The Fibaro Dimmer 2 is slightly larger and is 500 series. Aeotec Nano Dimmer is 2.9" x 2.9" x 1.1" and also 500 series. I see on the site linked by Techman that Silicon Labs is already out with 800 series modules that are available to be incorporated into products. ... haven't looked at whether that means 700 series stuff will become somewhat obsolete or whether 800 series just allows longer battery life or something.

Thanks for this @lilyoyo1 With all the interest right now in moving from Insteon to Zwave (or adding Zwave devices to an Insteon system), It would be great to have a table that shows closest equivalents to the various Insteon devices -- I had the impression that Z-wave was mostly switches and outlets.. It looks there is more than I had assumed (for example. sensors). I have seen the Zen17 recommended as a replacement for the Insteon IO module. I was wondering are there Z-wave plus or (better) 700 series equivalents to the Insteon Micro On/Off, Micro Dimmer, and Micro Open/Close modules? Though they are not exact replacements I see the Zooz Z51 could work instead of the Micro On/Off and the Z52 instead of the Micro Open/Close. I looked at a few other brands but haven't yet found a Zwave 700 equivalent to the Insteon micro dim.

@Michel Kohanim Apparently yes a KPL button. First sentence of first post from @arshishk was "I have the following program that checks the status of a keypadlinc button, and if the status is On, waits 1.5 hours and then sets the switch to Off."

I don't think we on this forum should get too speculative about what UDI might or might not do if it succeeded in some way in licensing Insteon technology or buying some Smarlabs assets including IP. It does not help UDI if we talk up the value of the Smartlabs IP or assets! If resurrecting the existing product line were going to be a significant money maker the sale Smartlabs was negotiating would probably have gone through. If you look at modern equivalent products they have lots of features the existing insteon products lack -- like (for example in the Shelly pucks) Bluetooth Low Energy or wifi setup, software defined dimmer parameters (for example leading edge vs trailing edge, soft start, etc.). energy monitoring, etc. etc. Now the dexterity of the ISY or IoP makes up for some of that but not all of it. Making the insteon protocol a going proposition into the future would require very significant investment, in my opinion. It isn't impossible that it could work out, but it isn't a a sure thing either, even at a possibly very low purchase price.

By default a Mac will often unzip the firmware file you downloaded. You want to upload the stil-zipped file to the ISY994. Can't guarantee that this is your situation but that's often the problem.

3-4 Insteon devices failing each year out of 53 seems high, unless perhaps they are very old. Do you have a whole-house surge suppressor at the electric service entrance or main panel? If not this is a crucial investment to prolong the life of insteon and other electronic devices. It's been a long time since I made the jump to 5.x but my memory is that it isn't very difficulprocess if you only have insteon. You will need to check your scenes and the controller scene menus after the upgrade. A few programs may indeed need to be re-saved and possibly edited. The good news is there is no hurry to do the upgrade if everything is working for you now. You will definitely need to upgrade firmware and Z-wave interface before making use of Zwave --especially the new and better Zwave products (series 700) which you will want to use exclusively if you move to Zwave.. [I am not a Zwave user and others will have more info on that. I believe that there is an intro to Zwave somewhere either in this forum or in the UDI wiki that would be helpful to you --- maybe search for that.]

I don't use UD Mobile but if it's on an iPhone try disabling notifications for the UD Mobile App in Settings?

Thanks for this explanation. Very sad.

"ISY Serial Controller" I assumed @Michael805 meant a 2413s, or maybe a 2413s+ISY994i, not an ISY 994i

What is an Insteon server? I don't think I've ever used one. The insteon.com website is up.

Of course this means that for those of us that would never use the Shelly Cloud for access to devices have to pay a share of the cost for infrastructure we don't intend to use. Just saying... On the other hand since I am sure the Shelly Cloud is a big part of getting the multitudes to adopt initially, by amortizing the development cost over a bigger number it gets the hardware cost down for those of us who wouldn't use it so maybe it's not a bad bargain.

@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.

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...