Insteon acquired and servers coming back up

[Geddy]

15 hours ago, upstatemike said:

3 Popcorn effect really really really sucks and we need better channels to communicate to manufacturers that fixing this is important. I suggest any device sold on Amazon deserves a question about smooth group actions to deliberately emabarrass any product manufacturer who did not make an effort to provide this in their offering.

WHAT? It sucks? I thought it was a feature? HA! Just kidding.

Agree...it would be nice to have a way to mark a product as "not subject to popcorn effect". Heck...Amazon can mark products "human friendly" or whatever they claim when a product can work with Alexa. That's great, but Alexa can't work with this human sometimes. (stupid "smart" speaker!)

 

[lilyoyo1]

2 hours ago, Dub said:

That’s an interesting thing to think about.  

 

 

Was there any new features in the “Nokia” (new line of products) that you can disclose without violating any confidentiality or NDA that might still be enforced(not sure how all that works or holds up  with all the business side changes).

They already had articles on it that details most stuff so an NDA really doesn't apply at this point. 

It goes without saying- everything that insteon currently does the Nokia line does as well. There are no changes. The new capabilities include the ability to update the firmware (via the hub), set the low level trim on the dimming function, and use each device as a dimmer or a relay. 

The main things that attract me to it is the huge step forward in build quality. Not only do they look much better, they also feel better to the touch. They're much quieter in operation and dim LEDs exceptionally well. Not as good as lutron sunnata dimmers but for the price, there's a day and night difference.

[larryllix]

I see matter as just another of the 10,000 protocol failures coming to complicate the market even further.

I watched this happen with DNP 3.0 and several other 'universal protocol developments.

Here is one of the problems....since none of the manufacturers can totally agree they will put manufacturer specific codes inside the protocol. This way manufacture X can support video while manufacture Y doesn't want video but needs control of bitcoin exchanges.
Now we have a universal protocol that no brand will communicate with any other brand and the whole concept flops.

The real answer is to get all the manufacturers to drop their own ideas and products and work together.


Not going to happen

... but we will now have another protocol to divide the hobby up even further.

Sent from my SM-G781W using Tapatalk

[apostolakisl]

1 hour ago, larryllix said:

I see matter as just another of the 10,000 protocol failures coming to complicate the market even further.

I watched this happen with DNP 3.0 and several other 'universal protocol developments.

Here is one of the problems....since none of the manufacturers can totally agree they will put manufacturer specific codes inside the protocol. This way manufacture X can support video while manufacture Y doesn't want video but needs control of bitcoin exchanges.
Now we have a universal protocol that no brand will communicate with any other brand and the whole concept flops.

The real answer is to get all the manufacturers to drop their own ideas and products and work together.


Not going to happen

... but we will now have another protocol to divide the hobby up even further.

Sent from my SM-G781W using Tapatalk
 

I fear you may be correct.  My main hopes for this protocol would be 

1) encrypted.  I think for sure this is handled.

2) A local and open API.  If you are going to join the Matter framework, then it seems like publishing a detailed api and supporting it would be part of the deal.  Node server creators often are struggling to reverse engineer it or are dealing with talking to web based server that might simply not be accessible. 

3) Everyone joins it.  If everyone doesn't join it, then it just complicates things as one more protocol to support. With seemingly all the big guns pledging support, this might just catch on. 

I really don't see any issues for current protocols to join it.  Insteon and Zwave can easily join it by just adding a Matter enabled device into the mix.  It could be a hub, or just any device that "hops" the message to the Matter IP framework. Could just be adding a new light switch that has Matter on it. You have to be of the mindset that your entire Insteon or Zwave network is a single Matter end point, not each device.  Since the message content in Matter appears to be unrestricted, I see no reason this could not be the case.

[Bumbershoot]

4 hours ago, Geddy said:

Agree...it would be nice to have a way to mark a product as "not subject to popcorn effect".

It appears that Thread supports Multicast, which makes me believe that a command can be sent to multiple devices at once.  Isn't that at least a step along the path to eliminating the popcorn effect?

[larryllix]

19 hours ago, apostolakisl said:

I fear you may be correct.  My main hopes for this protocol would be 

1) encrypted.  I think for sure this is handled.

2) A local and open API.  If you are going to join the Matter framework, then it seems like publishing a detailed api and supporting it would be part of the deal.  Node server creators often are struggling to reverse engineer it or are dealing with talking to web based server that might simply not be accessible. 

3) Everyone joins it.  If everyone doesn't join it, then it just complicates things as one more protocol to support. With seemingly all the big guns pledging support, this might just catch on. 

I really don't see any issues for current protocols to join it.  Insteon and Zwave can easily join it by just adding a Matter enabled device into the mix.  It could be a hub, or just any device that "hops" the message to the Matter IP framework. Could just be adding a new light switch that has Matter on it. You have to be of the mindset that your entire Insteon or Zwave network is a single Matter end point, not each device.  Since the message content in Matter appears to be unrestricted, I see no reason this could not be the case.

I don't see Insteon joining Matter. From what I can decipher the protocol's lower OSI level (hardware) is only going to support 2.4GHz, 900MHz and 850Mhz.

IMHO if you allow three different frequencies you may as well not spec any RF or hardware comm technique. You have already divided the industry support in three possible sections. **sigh**

Edited August 9, 2022 by larryllix

[upstatemike]

9 hours ago, Bumbershoot said:

It appears that Thread supports Multicast, which makes me believe that a command can be sent to multiple devices at once.  Isn't that at least a step along the path to eliminating the popcorn effect?

Eve just released a new thread enabled motion sensor that is supposed to operate lights in a scene instantly. Waiting for somebody here to get one and confirm that.

[apostolakisl]

10 hours ago, larryllix said:

I don't see Insteon joining Matter. From what I can decipher the protocol's lower OSI level (hardware) is only going to support 2.4GHz, 900MHz and 850Mhz.

IMHO if you allow three different frequencies you may as well not spec any RF or hardware comm technique. You have already divided the industry support in three possible sections. **sigh**

They only need to make a single device Matter, likely the hub, then the whole thing is Matter.  Every single Insteon device would be a target within the single Matter IP address.  The packet content is undefined as I understand, so you could have essentially an infinite number of nodes within the single Matter endpoint.  So, it would just be the Matter formatted IP address, and the content would probably be the exact current Insteon language.  This should work the same for z-wave.

 

[lilyoyo1]

12 hours ago, larryllix said:

I don't see Insteon joining Matter. From what I can decipher the protocol's lower OSI level (hardware) is only going to support 2.4GHz, 900MHz and 850Mhz.

IMHO if you allow three different frequencies you may as well not spec any RF or hardware comm technique. You have already divided the industry support in three possible sections. **sigh**

Insteon's new CEO has already stated that their next hub will be able to integrate with Matter. No different than UDI making Polisy and eisy compatible with Matter 

Edited August 9, 2022 by lilyoyo1

[apostolakisl]

6 minutes ago, lilyoyo1 said:

Insteon's new CEO has already stated that their next hub will be able to integrate with Matter. No different than UDI making Polisy and eisy compatible with Matter 

Not sure how that would work if some of your Insteon stuff integrates to Matter and some doesn't.  Seems like the best way to handle this would be what I said about making the entire Insteon network a single Matter IP address via a Matter enabled hub/plm/whatever you want to call it.

[lilyoyo1]

37 minutes ago, apostolakisl said:

Not sure how that would work if some of your Insteon stuff integrates to Matter and some doesn't.  Seems like the best way to handle this would be what I said about making the entire Insteon network a single Matter IP address via a Matter enabled hub/plm/whatever you want to call it.

No different than how polisy connects to HA,habitat, and hue. It's able to do so and pick up those devices without issue. 

Ditto for Alexa, Google and homekit. All of them do so now in some capacity 

Edited August 9, 2022 by lilyoyo1

[apostolakisl]

17 minutes ago, lilyoyo1 said:

No different than how polisy connects to HA,habitat, and hue. It's able to do so and pick up those devices without issue. 

Ditto for Alexa, Google and homekit. All of them do so now in some capacity 

It would be rather discombobulated to control some Insteon devices using one protocol and others using a different one.  For this to work, you would have to have something like an ISY as your gateway.  If you were an Insteon user, having Matter on some devices and not others without an ISY or similar would mean controlling some of the devices using a Matter controller and some using an Insteon controller.  Unless the Insteon Matter devices themselves acted as gateways for all the non-Matter Insteon devices.

[lilyoyo1]

4 minutes ago, apostolakisl said:

It would be rather discombobulated to control some Insteon devices using one protocol and others using a different one.  For this to work, you would have to have something like an ISY as your gateway.  If you were an Insteon user, having Matter on some devices and not others without an ISY or similar would mean controlling some of the devices using a Matter controller and some using an Insteon controller.  Unless the Insteon Matter devices themselves acted as gateways for all the non-Matter Insteon devices.

What are you talking about? I said that they stated that they are adding matter to their next hub. Any device that's able to connect to it would be able to work with it.

You literally stated that's what they needed in your previous post (in response to my statement) and now you're saying that you don't see how that would work. 

How would the insteon hub be any different than Polisy or eisy being the gateway?

[Bumbershoot]

6 hours ago, lilyoyo1 said:

No different than how polisy connects to HA,habitat, and hue. It's able to do so and pick up those devices without issue. 

Ditto for Alexa, Google and homekit. All of them do so now in some capacity 

 

6 hours ago, apostolakisl said:

Unless the Insteon Matter devices themselves acted as gateways for all the non-Matter Insteon devices.

Presumably, once the Polisy/eisy have Matter on board (also presuming border router functionality), then one can easily imagine the Polisy/eisy providing the glue  between native Matter devices and any devices in the UD universe (legacy Insteon/Z-Wave/Node server  devices).  Performance might be a question mark, but there's no reason to think it would be much slower than any other node servers.

Edited August 9, 2022 by Bumbershoot

[apostolakisl]

5 minutes ago, lilyoyo1 said:

What are you talking about? I said that they stated that they are adding matter to their next hub. Any device that's able to connect to it would be able to work with it.

You literally stated that's what they needed in your previous post (in response to my statement) and now you're saying that you don't see how that would work. 

How would the insteon hub be any different than Polisy or eisy being the gateway?

Sorry, I mis-read.  Thought you said "bulb".

[apostolakisl]

5 hours ago, Bumbershoot said:

 

Presumably, once the Polisy/eisy have Matter on board (also presuming boarder router functionality), then one can easily imagine the Polisy/eisy providing the glue  between native Matter devices and any devices in the UD universe (legacy Insteon/Z-Wave/Node server  devices).  Performance might be a question mark, but there's no reason to think it would be much slower than any other node servers.

I suppose it would be identical to current node servers.  The difference would not be in the node server, but rather the route to the device.

[upstatemike]

I wonder what happens if an end point device supports Matter plus a legacy protocol? Will the Matter path always take priority? Will the device be clever enough to determine which path is more efficient (least latency)? Will this be yet another thing that is left up to the manufacturer so there is no way to predict what will happen?

[lilyoyo1]

1 hour ago, upstatemike said:

I wonder what happens if an end point device supports Matter plus a legacy protocol? Will the Matter path always take priority? Will the device be clever enough to determine which path is more efficient (least latency)? Will this be yet another thing that is left up to the manufacturer so there is no way to predict what will happen?

I see things being like they are now with zwave except happening with other devices. 

Ie: turn switch A on matter hub relays signal to switch B to turn on. 

[Michel Kohanim]

Hi guys,

Unfortunately no go. We were discussing converting Nokia Hubs to PLMs. Unfortunately it costs us $40 per unit to convert and insteon wants another $35.00 per unit. Considering the huge initial investment (about $75K), defect rate, support, and development to support ASCII communications, we'll probably have to charge at least $125 a unit to just break even on 1000 units. 

Unfortunately, insteon does not want to convert and sell on their own. So, this chapter has also reached a dead end.

The only remaining hope is Hub Pro which, as per Ken, they are working on.

With kind regards,

Michel

 

[upstatemike]

2 hours ago, Michel Kohanim said:

The only remaining hope is Hub Pro which, as per Ken, they are working on.

With kind regards,

Michel

 

 

Is Hub Pro the same as PLM Pro? We don't really need a hub, just an updated PLM.

[Michel Kohanim]

Yes, apologies, PLM Pro.

With kind regards,

Michel

[ase]

7 hours ago, Michel Kohanim said:

Hi guys,

Unfortunately no go. We were discussing converting Nokia Hubs to PLMs. Unfortunately it costs us $40 per unit to convert and insteon wants another $35.00 per unit. Considering the huge initial investment (about $75K), defect rate, support, and development to support ASCII communications, we'll probably have to charge at least $125 a unit to just break even on 1000 units. 

Unfortunately, insteon does not want to convert and sell on their own. So, this chapter has also reached a dead end.

The only remaining hope is Hub Pro which, as per Ken, they are working on.

With kind regards,

Michel

 

 

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?

[lilyoyo1]

1 hour ago, ase said:

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?

They do. Michel corrected himself and said PLM pro. Its the one that showed up on the FCC database a few years back

Edited August 22, 2022 by lilyoyo1

[mango]

Any more data/links on the PLM Pro pls?

[apostolakisl]

8 hours ago, Michel Kohanim said:

Yes, apologies, PLM Pro.

With kind regards,

Michel

How was your device going to compare to the proposed PLM Pro?