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.  

19 minutes ago, lilyoyo1 said:

If i didn't have access to the resources that i do, I'd probably swap to Ra2 keypads and hue bulbs for everything else. 

+1: I don't have access to the resources you do, and I'm switching to RA2.  Or more accurately, I'm setting up RA2 in my current temporary abode, and will be taking it back to my full-time residence to convert it from Insteon over time.

-Tom

@stillwater  Could just be the asking price.

Edited April 13, 20223 yr by apostolakisl

If the Nokia products have not ended up as also scrapped.

They seem to have used the Insteon protocol. At least having the same six digit ID number. Maybe they have licensed or want to purchase the Insteon Protocol

And what did I say more than ten years ago about the first idiot that ran the show (Joe Dadda) ???  And only last year about the new owner being a complete imbecile!

You literally had two stupid sh^t's that killed a great technology because they are too stupid to live . . .

Hope a meteor drops on them both and wipes them out . . . ? 

 

Edited April 13, 20223 yr by Teken

48 minutes ago, stillwater said:

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.  

With just a few years left on their patents, and their history, I can't see anyone really wanting to resurrect insteon. I love the product but even if i could afford to buy them out, it wouldn't be worth it's asking price unless it was low 6 figures. Even then, it would be difficult due to their history. Banks and investors probably won't be as lenient with terms.

Let's say hypothetically he'd sell at 1mil. The bank would require 30% (300k). With a dirt name, you'd still have to come up with at least a mil for startup costs (and that's working from your garage selling on eBay and Amazon). The only market you (not you personally) would have, is existing users. After they intially stock up, would you sell enough to pay back investors and your loan quickly enough to stay in business? 

Im using simplified numbers and scenario to explain myself as I think he's asking for much more than that. The patents are worth more but not the business which is the conundrum their in and why I can see them just letting it die off completely vs selling it for pennies on the dollar to someone else

 

Edited April 13, 20223 yr by lilyoyo1

And what did I say more than ten years ago about the first idiot that ran the show (Joe Dadda) ???  And only last year about the new owner being a complete imbecile!
You literally had two stupid sh^t's that killed a great technology because they are too stupid to live . . .
Hope a meteor drops on them both and wipes them out . . . [emoji2959] 
 

My guess is there was always a hidden agenda to run the business into bankruptcy or at least waste all the money. Nobody plays it as stupid as they did in business. Not even one attempt to make a comeback.

The handwriting was always on the wall but we were always given the excuses by phoney inside information. Glad it wasn't our dimes.

Sad.

Sent from my SM-G781W using Tapatalk

Nokia just licensed their name I doubt they would want to get involved in manufacturing the product.

It's going to be interesting to see where the remnants of Insteon end up.

Smarthome/Smartlabs basically has nothing left. There's no real estate, there's no goodwill and there's no inventory. The only item left is the patent which apparently expires in 2026. I doubt anyone would invest in something that's going to expire in a few years.

We need someone with access to the legal databases to keep an eye on Smarthome's asset(s). Maybe there's a creditor who will end up with the patent and who has no use for it.

 

 

 

7 minutes ago, larryllix said:

My guess is there was always a hidden agenda to run the business into bankruptcy or at least waste all the money. Nobody plays it as stupid as they did in business. Not even one attempt to make a comeback.

The handwriting was always on the wall but we were always given the excuses by phoney inside information. Glad it wasn't our dimes.

Sad.

Sent from my SM-G781W using Tapatalk
 

No hidden agenda just a stupid imbecile, with no common sense, and too stupid to live. This last guy is the epitome of ten kinds of stupid - period!

As soon as I read this half wit directed his teams to focus on software I knew the entire Insteon brand and company would fold. To this very day everyone who took part in this whole disaster needs to be punched in the throat.

Insteon could have been the Apple, Microsoft, name who ever . . .

But, no just a sh^t stain recorded in history run into the dirt by two of the most incompetents fools to ever grace this planet.  

 

Edited April 13, 20223 yr by Teken

Not sure how relevant the patents are.  Without the source code, the patents might not do much for you.  I don't know. 

A big part of the profitability question is how expensive is it to make these devices?  Seems like to make money you would need to have manufacturing costs at no more than $10 for a 2477d.  

Somewhere, I assume there is a pallet full of the proprietary Insteon chips.  I kind of doubt that running out of those chips was the end-of-Insteon production point.  Seeing as those chips are custom they would have run them in batches and no one else can use them.

25 minutes ago, larryllix said:

My guess is there was always a hidden agenda to run the business into bankruptcy or at least waste all the money. Nobody plays it as stupid as they did in business. Not even one attempt to make a comeback.

The handwriting was always on the wall but we were always given the excuses by phoney inside information. Glad it wasn't our dimes.

Sad.

Sent from my SM-G781W using Tapatalk
 

Gotta love how someone who rails against people being smart does the same thing at every opportunity they get. I guess I shouldn't expect much with someone who thinks routers existed 40 years ago and would still work with modern wifi devices 20-40 years later. 

12 hours ago, lilyoyo1 said:

This is a pipedream. Regardless of what Shelly can potentially do, how many people will want to take the necessary time to update and flash those devices? 

Take this forum  Those here are generally above avg hobbyists to much more advanced....yet, most are not willing to do what it takes to make those devices work on a large scale installation. Imagine having to flash 30+ devices just to install in an avg home. Worse in a larger home as you're now talking 70+ devices. That's a lot of work to do before even having to install the devices or to start programming. 

Even with zwave. How many actually update their devices (if they're working)? It's easy to do 1 or 2 but most aren't going to run around pushing updates to a bunch of devices one at a time. Shelly sounds good on paper but in reality, it's a smaller niche product for a really small niche market

Our B2B customer use automation to provision the devices.

For example, this script is being used by a grocery store chain to provision nearly 5,000 Shelly devices for their stores.

https://github.com/ALLTERCO/Utilities/tree/master/provisioning-tool

100 devices is trivial by comparison.

19 minutes ago, Doug Roberson said:

Our B2B customer use automation to provision the devices.

For example, this script is being used by a grocery store chain to provision nearly 5,000 Shelly devices for their stores.

https://github.com/ALLTERCO/Utilities/tree/master/provisioning-tool

100 devices is trivial by comparison.

I don't open links from strangers so i don't know what it says. You're comparing what a business has access to (and can afford to automate) to the avg home owner which probably do not have the ways or means to set something like that up

Edited April 13, 20223 yr by lilyoyo1

I understand, Github is a scary place to click links to.

The average home owner isn't installing 70+ devices. They're installing 3-4 and a consumer grade app on their smart phone is suitable.

You're describing power users and having an open source python script for mass provisioning is reasonably within the power user's means.

Regardless, I'm not here to convince you, was just explaining that the options aren't as limited as you believe. Take care.
 

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

1 hour ago, Doug Roberson said:

I understand, Github is a scary place to click links to.

The average home owner isn't installing 70+ devices. They're installing 3-4 and a consumer grade app on their smart phone is suitable.

You're describing power users and having an open source python script for mass provisioning is reasonably within the power user's means.

Regardless, I'm not here to convince you, was just explaining that the options aren't as limited as you believe. Take care.
 

GitHub isn't scary. Viruses are which can be embedded in many different links. If you don't know that by now not much i can say towards that. As a new user, I just don't know who you are to trust strange links.

Power user or not, most people aren't interested in those hurdles.  If that was the case, they'd already be jumping aboard vs avoiding it. 

I never said most would be installing 70+ devices. I specifically described someone desiring to do a whole home vs 3 or 4 devices. In my example, I used an avg size which is approximately 30 devices and a larger home which would require approximately 70. 

 With that said, why go through what you have to go through for 3 or 4 devices when you can purchase 3 or 4 standard kasa devices already ready to go and with a better looking app (though it's not needed since the context of the conversation was using it with Isy/polisy) 

wifi supports qos

be interesting to see what the constraint is on these 'routers'

also be interesting to know how many people with lots of ha devices that don't have at least one access point - especially when they are streaming 4k video

 

11 minutes ago, lilyoyo1 said:

GitHub isn't scary. Viruses are which can be embedded in many different links. If you don't know that by now not much i can say towards that. As a new user, I just don't know who you are to trust strange links.

Power user or not, most people aren't interested in those hurdles.  If that was the case, they'd already be jumping aboard vs avoiding it. 

I never said most would be installing 70+ devices. I specifically described someone desiring to do a whole home vs 3 or 4 devices. In my example, I used an avg size which is approximately 30 devices and a larger home which would require approximately 70. 

 With that said, why go through what you have to go through for 3 or 4 devices when you can purchase 3 or 4 standard kasa devices already ready to go and with a better looking app (though it's not needed since the context of the conversation was using it with Isy/polisy) 

Whoa there... hold up just a second.... Shelly devices do NOT need to be flashed to be integrated.  I have a node server in development (for a while) that works with Shelly devices out of the box with limited user input (basic config info) for each device.  I do think you are thinking of other common Wifi devices that people flash with Tasmota firmware.  This process is NOT needed for Shelly devices.

Just wanted to clear that up before this goes too far off the rails.

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. 

2 minutes ago, simplextech said:

Whoa there... hold up just a second.... Shelly devices do NOT need to be flashed to be integrated.  I have a node server in development (for a while) that works with Shelly devices out of the box with limited user input (basic config info) for each device.  I do think you are thinking of other common Wifi devices that people flash with Tasmota firmware.  This process is NOT needed for Shelly devices.

Just wanted to clear that up before this goes too far off the rails.

I was thinking about sonoff devices that needed tasmoto. Thanks for the correction and clarity. While I still wouldn't use it with my company, I'm still curious to see standard consumer/cable routers handle a large installation of them. 

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.  

1 minute ago, lilyoyo1 said:

I was thinking about sonoff devices that needed tasmoto. Thanks for the correction and clarity. While I still wouldn't use it with my company, I'm still curious to see standard consumer/cable routers handle a large installation of them. 

The issue with standard consumer combo wifi/router issues still exist with any wifi devices.  I think there are some innovations in this regard in the pipeline (can't discuss) so we'll have to wait and see.

An interesting thing however is that URC has now included Shelly devices as standard supported devices.  This was announced in CEPro a month or two back and was intriguing. 

I also have a RTI driver in the works along with the Polisy node server.  My current attention lately is with the Polyglot node.js interface and once that's done I'll begin the porting and updates to my other node servers.

9 minutes ago, stillwater said:

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. 

You are absolutely correct about that. I always question people who rip out devices to go with something different due to the issues they were having. 

I say that because all of them have their strengths and weaknesses. The key is to maximize their strength while minimizing your exposure to their weaknesses. 

I've gone in people houses to fix systems and have found insufficient network build outs, poor environments for device type chosen, and simply substandard design. Those same people trashed the product themselves vs their handy work.

3 minutes ago, stillwater said:

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

They are highly configurable indeed which can also be a problem for integration.  I like the CoAP and the MQTT integrations.  The problem with MQTT integration was the need to also have a MQTT broker also integrated with the node server and as such it would almost be like having 2 node servers to achieve one goal.  This route posed somewhat cumbersome and problematic.  Also NOTE that by using MQTT it disabled the "Cloud" access which disabled the Mobile App functionality which most people would prefer to also have available.  So with these issues I went the route of using the HTTP interface and the Shelly "Actions" to provide instant feedback to the ISY.  This has proven to work very well in practice.  In order to overcome the large amount of options and configuration that is what is taking the most amount of time.  Building those features in a way that works within the ISY Admin Console Interface and for each device.  So yes this one is taking a long time to get right and be ready for people.  Now with the porting to PG3 that has added some well... challenges and my attention is diverted to working with other developers to get PG3 ready before I put work into my own node servers.

19 minutes ago, stillwater said:

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. 

Hmm... I've seen this type of behavior from another "hub" that's very popular... usually it was caused by some "bad" read really cheap devices which were not actually Zigbee ZHA but still had a label they printed.....

In the world of Z-Wave/Zigbee a bad device can wreck a mesh network and a poorly implemented gateway stack (Z-Wave or Zigbee) on the "hub" can ruin the entire experience.