Insteon acquired and servers coming back up

[upstatemike]

Maybe I missed it in the article but I still don't understand what Thread can do. Sure Thread devices can speak a common protocol like IPv6 but what baseline command set will they share? On/Off, Dim/Bright doesn't get you very far... how about color or color temperatur? Fan Speed? Energy usage? Will all Thread devices recognize scene commands? In what common syntax? Can a Thread Keypad button start a Thread enabled music player to start a  specific playlist without the need for controller intervention?

Just generalizations and verbal fluff at this point. I would like to see an example of a complex action as it will be set up and executed using Thread.

[RPerrault]

2 minutes ago, upstatemike said:

Maybe I missed it in the article but I still don't understand what Thread can do. Sure Thread devices can speak a common protocol like IPv6 but what baseline command set will they share? On/Off, Dim/Bright doesn't get you very far... how about color or color temperatur? Fan Speed? Energy usage? Will all Thread devices recognize scene commands? In what common syntax? Can a Thread Keypad button start a Thread enabled music player to start a  specific playlist without the need for controller intervention?

Just generalizations and verbal fluff at this point. I would like to see an example of a complex action as it will be set up and executed using Thread.

thread - like wifi - delivers packets - that is all

the content of that packet can be insteon or a phone conversation or porn -- it is not an application layer

matter is using existing packet delivery mechanisms WIFI, Threah, bt)to deliver packets - the contents will be what matter does (dim, off, whatever) 

that is different than insteon in that insteon invented both the application (insteon commands) and the method of delivery of those packets - thread nor wifi will dim a light - they are agnostic about the packet content - they just deliver to the device

if you have an existing wifi coverage at your home already - for ipads and whatever other devices - you have what you need to deliver to a dimmer already in place - this was not the path zwave or insteon or lutron or or or took - why they chose not to use what is already in place is what we are discussing - and why the matter standard adopted wifi and thread (and bt) into its new standard - wifi seems to be a bad fit to deliver tiny dimming commands and such - we were theorizing on how (and if) they are planning to make wifi a good fit for a new standard

i have tried to explain that inarticulately several times 

insteon's application (command set) is proprietary - i suppose its packet delivery is too - but it can only deliver what insteon allows - wifi and thread can stream porn!  to your dimmers i suppose - in any event - we all have wifi - with insteon, you have to 'build' yet another network that is used for only one thing

 

[lilyoyo1]

5 minutes ago, upstatemike said:

Maybe I missed it in the article but I still don't understand what Thread can do. Sure Thread devices can speak a common protocol like IPv6 but what baseline command set will they share? On/Off, Dim/Bright doesn't get you very far... how about color or color temperatur? Fan Speed? Energy usage? Will all Thread devices recognize scene commands? In what common syntax? Can a Thread Keypad button start a Thread enabled music player to start a  specific playlist without the need for controller intervention?

Just generalizations and verbal fluff at this point. I would like to see an example of a complex action as it will be set up and executed using Thread.

Unfortunately they've never made clear the stuff you've asked (as far as I've seen). I'm sure there will be some command specific things for consistency sake (such as on/off/dim/brighten). My guess, it'll be similar to what we have now in regards to using voice assistants to control devices. 

[RPerrault]

7 hours ago, ryarber said:

If I may pose a question… Admittedly, I am speaking with people who know much more about this than I. I understand what ase is saying even though I don’t have the depth of knowledge of routing, switches, layers, etc….

But it seems to me the way things will shake out is that, while Wi-Fi will be useful in IoT, it will not be the predominant mode of information delivery/control. I see Wi-Fi as a means to provide hubs and other bandwidth hungry IoT devices an interface with our smarter devices. And then thread as the primary interface with most IoT devices that don’t need the large packets and huge bandwidth. That’s been my understanding from the start. That while Wi-Fi is a necessary element, it will be a relatively minor player going forward. And that where possible, hardwired connections will still be preferable to wireless. 

I think I am understanding people here saying that each light switch, LED bulb, door lock, motion sensor, etc. would have independent wifi capability and I do not believe that is where we are headed. Ideally, I believe these “dumber” devices will have their own communication protocols while their controllers will act as a bridge to “smarter” devices and the internet. 

wifi signals have to reach their destination directly - meaning - devices must be within the range of the device that sends out the signal (access point) - the wifi signal does not require other devices or the destination device to repeat the wifi signal - what people here are calling 'mesh' - wifi reaches a reasonable distance and can penetrate walls and obstacles - within reason - some frequencies penetrate better and travel farther - 2.4 does that best - but higher frequencies are faster - 5 and 6 ghz - but to punch that signal out, power is needed 

thread is a little more of a mystery to me - i think devices participating in a thread network DO repeat signals - so a command can leap from device to device a long way - assuming there is no gap - but thread's advantage is its low power utilization - meaning battery operated devices - its said a coin battery can last for years in a thread device - but the cost of low power is distance and penetration - very low 

i assume there is nothing that says a wifi enabled 'matter' compliant couldn't repeat thread signals - even if it got the message from a wifi delivery - that is why i questioned if an insteon device that got a packet on the powerline would repeat that packet on both the powerline and rf - my guess is that matter compliant devices that are wifi enabled will also be thread enabled - but not the other way (battery devices won't talk wifi)

wifi and thread are only the method of delivering the packets - there are lots of considerations to determine if wifi is the best way to deliver tiny insteon packets o or lutron packets - or zwave packets 

wifi and thread both use an addressing standard - ipv6 - we are accustomed to ipv4 addresses (192.168.1.128) - ipv6 increases the number of addresses - a different format but functionally about the same

probably the way it will shake out is battery powered - thread - powered - wifi

 

[upstatemike]

1 hour ago, RPerrault said:

with insteon, you have to 'build' yet another network that is used for only one thing

 

But isn't that the point?

A purpose built network is optimized for the mission and does not have excess overhead to add manufacturing cost or kill batteries. 

A purpose built network can reduce interference by using different frequencies from Wi-Fi and can improve distance and penetration by using lower frequencies carrying smaller payloads.

A purpose built network does not consume limited IP address space, DHCP table space, or router CPU cycles and reduces the number of concurrent connections on each access point.

A purpose built network is resilient against netork storms and other problems that can be caused by IP devices that have nothing to do with the critical IoT mission. (Critical if you are depending on it for core IoT functions like turning on a light or alerting you to an emergency situation)

The idea that an existing Wi-Fi environement is "already there" to support a massive increase in client load is unrealistic. There might be a corner case where somebody buys a small number of IoT items and then never expands from there but that is not the trend. 

You can build up your network with semi-pro gear but that will not end up being cheaper or easier than just using a dedicated protocol and hub so... why would you want to go that route?

 

[ryarber]

My understanding is that thread will only be the wireless vehicle whereby most matter commands will be issued. At first, matter will only have commands for a few type devices. Lighting, motion sensors and a few others in the first wave. Later they will add support for cameras and other devices. So I believe they are still determining much of what you are asking (which commands are available), and the command set will grow over time. 

[RPerrault]

8 minutes ago, upstatemike said:

The idea that an existing Wi-Fi environement is "already there" to support a massive increase in client load is unrealistic.

a lot of smart people and money say otherwise

in my entire career i have seen wifi 'interference' once - and it had nothing to do with the signal - it was the rouge detection causing a problem

i have spent the money for wifi coverage - and with or without a smart dimmer, i still have the wifi that i had to pay for

building out insteon - single purpose - is an added expense - and not proprietary - and a zwave network - and a zig big 

wifi can and does have its challenges - and seems to be a bad fit for ha devices - that does not mean that someone cannot and has not overcome the challenges - that is what ase was helping me understand

adopting an open standard for packet delivery leaves the contents of the package to the application 

 

[RPerrault]

5 minutes ago, ryarber said:

My understanding is that thread will only be the wireless vehicle whereby most matter commands will be issued. At first, matter will only have commands for a few type devices. Lighting, motion sensors and a few others in the first wave. Later they will add support for cameras and other devices. So I believe they are still determining much of what you are asking (which commands are available), and the command set will grow over time. 

good point in that video is up in the ha realm now - much larger packets

 

[ryarber]

45 minutes ago, RPerrault said:

wifi signals have to reach their destination directly - meaning - devices must be within the range of the device that sends out the signal (access point) - the wifi signal does not require other devices or the destination device to repeat the wifi signal - what people here are calling 'mesh' - wifi reaches a reasonable distance and can penetrate walls and obstacles - within reason - some frequencies penetrate better and travel farther - 2.4 does that best - but higher frequencies are faster - 5 and 6 ghz - but to punch that signal out, power is needed 

thread is a little more of a mystery to me - i think devices participating in a thread network DO repeat signals - so a command can leap from device to device a long way - assuming there is no gap - but thread's advantage is its low power utilization - meaning battery operated devices - its said a coin battery can last for years in a thread device - but the cost of low power is distance and penetration - very low 

i assume there is nothing that says a wifi enabled 'matter' compliant couldn't repeat thread signals - even if it got the message from a wifi delivery - that is why i questioned if an insteon device that got a packet on the powerline would repeat that packet on both the powerline and rf - my guess is that matter compliant devices that are wifi enabled will also be thread enabled - but not the other way (battery devices won't talk wifi)

wifi and thread are only the method of delivering the packets - there are lots of considerations to determine if wifi is the best way to deliver tiny insteon packets o or lutron packets - or zwave packets 

wifi and thread both use an addressing standard - ipv6 - we are accustomed to ipv4 addresses (192.168.1.128) - ipv6 increases the number of addresses - a different format but functionally about the same

probably the way it will shake out is battery powered - thread - powered - wifi

 

My understanding is that thread has mesh capabilities. Battery powered devices will not participate in mesh. Only wired devices can participate in mesh. There are 3 type devices. End devices (battery powered eg door locks) border routers (command and control devices that bridge between internet and thread), and simple router (participate in the mesh). 

Thread device types

[RPerrault]

interesting conceptual overview

https://www.forbes.com/sites/moorinsights/2022/01/11/ces-2022-matter-and-thread-win-the-iot-connectivity-wars/?sh=1dba658d19b1

 

[upstatemike]

So I'm shutting off the lights in my one room (about 12 devices) where I have deployed Z-Wave (a protocol designed from the ground up for home automation) and I'm reflecting on the annoying popcorn effect as each switch responds to the off command individually. I wonder how Thread/Matter will fix this and other problems we see in the current platforms they are meant to replace? Z-Wave has detailed conceptual overviews and the promise of expanding device types (when will the device class for a regular keypad that can do something useful by direct association get released?) but that didn't result in a solid consumer friendly solution so why should I think Thread/Matter will do better? 

At the end of the day I will ignore all the industry hype and just install Thread/Matter into a room (maybe redo my Z-Wave room) and see if it solves any of the things that currently bother me. We'll see how it goes. 

Edited June 27, 2022 by upstatemike

[larryllix]

6 hours ago, upstatemike said:

So I'm shutting off the lights in my one room (about 12 devices) where I have deployed Z-Wave (a protocol designed from the ground up for home automation) and I'm reflecting on the annoying popcorn effect as each switch responds to the off command individually. I wonder how Thread/Matter will fix this and other problems we see in the current platforms they are meant to replace? Z-Wave has detailed conceptual overviews and the promise of expanding device types (when will the device class for a regular keypad that can do something useful by direct association get released?) but that didn't result in a solid consumer friendly solution so why should I think Thread/Matter will do better? 

At the end of the day I will ignore all the industry hype and just install Thread/Matter into a room (maybe redo my Z-Wave room) and see if it solves any of the things that currently bother me. We'll see how it goes. 

How badly does the popcorn effect look with Zwave? Can you guess at how long of a delay happens between the first bulb turning off and the twelfth bulb turning off?

Using MagicHome/LEDenet WiFi bulbs, I still get some slight popcorn effect but it is very minimal. There are some techniques to minimise the annoyance though. Turn off the most visible bulbs first, and then the ones that are typically behind you. With WiFi bulbs and strips, (and using my own NRbridge software) I divide big groups of bulbs into several smaller groupings so that say every third bulb turns on/off, then each interlaced next third of the bulbs, then the final interlaced third of the bulbs.   eg: with 12 bulbs the first group to turn on/off would be 1,4,7, & 10, then 2,5,8 &11,  and then 3,6,8 & 12. This makes the popcorn effect almost imperceptible.  This also gives me better festive lighting control and animation capablities where I can create a moving effect in long strings of bulbs. (annoy the neighbours )

The very fast ramping feature built in to the MagicHome bulbs also helps hide the remaining popcorn effect. With groups of about 12 bulbs, no popcorn effect is seldom seen with two different TV streaming 4K and a VR headset streaming 3D and video effects simultaneously.
BTW: NetFlix hardly uses a few percent of my WiFi data bandwidth. Prime uses about double that with 4K video. It comes in intermittent bursts of 3-5 Mbps on a 1200 Mbps WiFi channel. 2.4GHz or 5GHz WiFi 6 handles that while still sleeping.

However, I doubt Zwave would offer that control or perhaps with the right software, could it?

Edited June 27, 2022 by larryllix

[jec6613]

2 hours ago, larryllix said:

BTW: NetFlix hardly uses a few percent of my WiFi data bandwidth. Prime uses about double that with 4K video. It comes in intermittent bursts of 3-5 Mbps on a 1200 Mbps WiFi channel. 2.4GHz or 5GHz WiFi 6 handles that while still sleeping.

For me, Z-Wave popcorning (and latency in general) always depended on how big the network was and what devices were in it.  I just moved everything that was latency sensitive off of Z-Wave and used Insteon, worked much better.

As for WiFi, as you mention, Netflix doesn't use much actual bandwidth, but with WiFi 5 (802.11ac) and earlier every single device connected to the WAP uses a percentage of available airtime on that channel.  And with out of the box config, it usually is about a full percent just to have an associated device.  If you put 50 802.11ac home automation devices on a modern router capable of 600+ Mbps PHY rate in 2.4 GHz, and put all of your devices an average of a room away so almost nobody is running at the full PHY, add in beaconing and other WAP overhead, now you have a total of ~20-30 Mbps available for that Netflix device.  Add somebody working from home over Zoom and some remote desktop things, and now Netflix is buffering and stuttering.

Of course, the above scenario doesn't have to be the case and is a bit extreme - adding another access point relieves a lot of that - even if that's just a 5 GHz access point in the same physical router/WAP to make it dual band, but you can see how traffic of a bunch of IoT devices can bring WiFi to its knees rapidly.

This isn't without solutions though:

Surprisingly, this is how a wireless backhaul mesh helps a ton - because you're putting a 2.4 GHz WAP every couple of rooms throughout your home, the individual AP can run at much lower power and still maintain a faster base data rate and much more efficiently use the spectrum.  In terms of IoT device scaling, most homes installing mesh will scale their IoT capacity linearly through about 5-6 root and extender APs, and this doesn't depend on whether or not you're using wired or wireless backhaul.

The other technology that's slowly making its way in is 802.11ax (WiFi 6) on the IoT clients as well as the APs.  This allows each associated device to not have a full beacon time slice and frees up significantly amounts of bandwidth and air time on the WAP.  This is because WiFi 6 clients, when communicating to a WiFi 6 AP, can set a non-standard interval for communication, requesting that the AP only communicate with them once an hour or even once a day unless there are incoming messages.  Compared to the constant communication (and therefore air time) usage of WiFi 5, this is a huge improvement for IoT.

[upstatemike]

When I press the wireless Z-Wave switch at the entrance to the room there is enough delay that each switch clearly is operating in sequence. Takes about 5 seconds far all the lighst to respond to an on or off, not counting ramp rates.

My point is that companies claiming to solve the "problems" with current HA protocols seem to ignore the things that consumers actually care about and instead invent imaginary problems that match the strengths of their new technology to solve. How can Z-Wave claim to be designed from the ground up for HA and not understand why popcorn effect or a lack of good wall keypads or better implementation of direct association to reduce dependency on a controller for basic operations might  be important? How could broadlink just release a new Bluetooth protocol that has excellent smooth group control with no popcorn effect not realize that after a power failure their bulbs need to return to the previous state instead of snapping on in the middle of the night or while you are away at work? 

The folks coming up with this stuff are NOT as clever as everyone is assuming and I admit I am extremely cynical that Matter or any Wi-Fi based standard is somehow going to get it right this time.

Edited June 27, 2022 by upstatemike

[Dub]

4 hours ago, upstatemike said:

My point is that companies claiming to solve the "problems" with current HA protocols seem to ignore the things that consumers actually care about and instead invent imaginary problems that match the strengths of their new technology to solve.

100% Agree.  See a lot of technology that is that way...frustrating.  I did see a response in Reddit, that Home Seer can do Z-Wave without the popcorn effect, but its dependent on the controllers and the devices.  Thats my biggest issue with Z-Wave now is it should work, but interoperability is always questionable.  Lots of folks are optimistic about Matter because of the big names involved, but I will wait and see.  Sony was a big name when BetaMax was competing for that space.  My point is the bigger names probably fail at way more things than we remember or think about and having optimism because big names are involved doesn't get my attention like it did when Insteon was partnering with the Microsoft Stores ?

[lilyoyo1]

18 minutes ago, WHaas said:

100% Agree.  See a lot of technology that is that way...frustrating.  I did see a response in Reddit, that Home Seer can do Z-Wave without the popcorn effect, but its dependent on the controllers and the devices.  Thats my biggest issue with Z-Wave now is it should work, but interoperability is always questionable.  Lots of folks are optimistic about Matter because of the big names involved, but I will wait and see.  Sony was a big name when BetaMax was competing for that space.  My point is the bigger names probably fail at way more things than we remember or think about and having optimism because big names are involved doesn't get my attention like it did when Insteon was partnering with the Microsoft Stores ?

Homeseer allows you to set direct association between compatible devices which does away with the popcorn effect. However that's extremely limited compared to insteon in multiple ways. 

You're right about the big names failing. Most of what they release fails. We just remember the success stories because of their impact. 

[jec6613]

45 minutes ago, lilyoyo1 said:

Homeseer allows you to set direct association between compatible devices which does away with the popcorn effect. However that's extremely limited compared to insteon in multiple ways.

Z-Wave Association is better, as it's faster, but it's still sending multiple commands over a routed network with hops and full traffic control, so it reduces but doesn't eliminate it.

[lilyoyo1]

24 minutes ago, jec6613 said:

Z-Wave Association is better, as it's faster, but it's still sending multiple commands over a routed network with hops and full traffic control, so it reduces but doesn't eliminate it.

Direct association is direct communication between linked devices. There are no hops or communication over the network except for status being sent to the controller. You're referring to assigned association which is different

[Dub]

2 minutes ago, lilyoyo1 said:

Direct association is direct communication between linked devices. There are no hops or communication over the network except for status being sent to the controller. You're referring to assigned association which is different

I appreciate hearing the terminology so I can understand it bit better, but this reminds of how spoiled I was with my Insteon setup.  I didnt really know much about how it work, it just worked well for me.  Sure some lights may not have been 100% perfect 100% of the time, but it was not a problem or even something I would think about.  I didn't know what the pop corn effect was until Insteon went offline and started reading when I was looking at options.  Now I dont want it especially with multiple lamps in the same rooms.

[upstatemike]

It is interesting that Control4 uses a routed protocol (Zigbee) and yet have no popcorn issues. I wonder if it is because of their proprietary implementation of Zigbe or if Zigbee has some non-routed broadcaast capability that most manufacturers just don't take advantage of?

[larryllix]

There is no reason devices cannot use a second IP address so that group broadcasts can operate all bulbs in that group simultaneously. I doubt Insteon could patent that idea, as it is used in many places already for WiFi broadcast messing techniques.

This seems so easy but I don't think these developers have much experience with HA.

[larryllix]

8 hours ago, upstatemike said:

When I press the wireless Z-Wave switch at the entrance to the room there is enough delay that each switch clearly is operating in sequence. Takes about 5 seconds far all the lighst to respond to an on or off, not counting ramp rates.

<snipped>

Ouch@ 5 seconds?!

With WiFi bulbs, 12 bulbs would take about 1.5 seconds. To be fair I had only about 9 bulbs in a row on my longest deck and it appeared to be about 1 second but as I posted the techniques make it not so apparent.

I ran some animations where each bulbs profile was read and passed to the next bulb in a round Robin fashion and the biggest delay was ISY doesn't offer less than a Wait 1 second delay.
I almost forgot....originally I setup a circus tent ceiling with two pinwheels of ten RGBW strings on each post/hub. Using WiFi I could rotate those twenty RGBW (16.4 feet long) strings about one loop per second or less. I did find some jerkiness in the light sequence smoothness at times if my wife was streaming 4K videos on that router. That was before WiFi 6 ever was in my home using a 20 year old dual band Netgear router.

WiFi has plenty of bandwidth for HA if you don't use a 10 year old router with 55Mbps limits. Mind you, I don't think I would use it on lightswitches where delays are really annoying but I haven't tried. Think about gamers that whine about 20 msec lag times and 10 msec of jitter, when playing games against people in China through 100s of switches and routers. A few LAN devices are not going to be a problem.

Edited June 27, 2022 by larryllix

[larryllix]

10 hours ago, jec6613 said:

<snippage>

As for WiFi, as you mention, Netflix doesn't use much actual bandwidth, but with WiFi 5 (802.11ac) and earlier every single device connected to the WAP uses a percentage of available airtime on that channel.  And with out of the box config, it usually is about a full percent just to have an associated device.  If you put 50 802.11ac home automation devices on a modern router capable of 600+ Mbps PHY rate in 2.4 GHz, and put all of your devices an average of a room away so almost nobody is running at the full PHY, add in beaconing and other WAP overhead, now you have a total of ~20-30 Mbps available for that Netflix device.  Add somebody working from home over Zoom and some remote desktop things, and now Netflix is buffering and stuttering.

<Snippage>

What would use all that bandwidth for an HA application? Putting 100 bulbs on one WiFi channel and each bulb is turned on and off 10 times per day still doesn't add up to more than a few K of data. The crowding is only in the politics of the protocol and hardware, namely device counts in tables and arbitration hardware etc. HA is not high bandwidth data traffic.

Now we wait unit IPv6 comes to a LAN near you so we can have 1000s of HA devices on WiFi.

[captainc]

insteon technology and product development was so neglected for years it will take a long time to redesign the current line with available components let alone new product launches.

or take shortcuts and get product to market faster we will see

[lilyoyo1]

2 hours ago, upstatemike said:

It is interesting that Control4 uses a routed protocol (Zigbee) and yet have no popcorn issues. I wonder if it is because of their proprietary implementation of Zigbe or if Zigbee has some non-routed broadcaast capability that most manufacturers just don't take advantage of?

That's built into ZigBee. Hue bulbs do the same by assigning a separate address for groups/scenes