Insteon acquired and servers coming back up

[lilyoyo1]

35 minutes ago, captainc said:

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

Not really. The nokia line was ready for release

[RPerrault]

20 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 agree - its a deal killer for me with z-wave - or any others that has unsynchronized devices in a scene

20 hours ago, upstatemike said:

I wonder how Thread/Matter will fix this and other problems we see in the current platforms they are meant to replace?

the point of this discussion

20 hours ago, upstatemike said:

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. 

that is where i am - waiting to see matter

lutron is awfully expensive (not the radio ra stuff - not interested)

living on prayer and fasting in the hope my insteon devices don't go craplinc before either insteon has replacements or matter is available and people have experience with it

 

[RPerrault]

11 hours ago, jec6613 said:

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 wifi mesh stuff - i don't have an understanding of how it works and what the advantages are

say i have 6 - do all 6 use the same channels?

how is the traffic sent back through the others?  through wifi or some kind of dedicated rf?

not sure how sophisticated these devices are - but every ap i have worked with decrease power when overlap in coverage is detected

[ryarber]

The old saying goes… “too many cooks in the kitchen spoil the broth.” 

That may happen with Matter. Who knows. Delays in the development cycle don’t inspire confidence. 

The main thing matter is promising to deliver is interoperability. That is not efficiency. The two can coexist, but often don’t. 

At this point, Matter is nothing more than an idea. We are talking like it already exists. Thread exists, but matter doesn’t. 

[RPerrault]

3 hours ago, WHaas said:

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.

um - every z-wave device can't necessarily reach every other z-wave device - if not in range, other devices repeat the signals - or hops

 

[ryarber]

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

May I ask, are your z wave devices all of a later generation? What generation are they?

And what type hub do you have?

Edited June 28, 2022 by ryarber

[larryllix]

1 minute ago, RPerrault said:

the wifi mesh stuff - i don't have an understanding of how it works and what the advantages are

say i have 6 - do all 6 use the same channels?

how is the traffic sent back through the others?  through wifi or some kind of dedicated rf?

not sure how sophisticated these devices are - but every ap i have worked with decrease power when overlap in coverage is detected

Yeah, I had one ASUS ax92u router and it seemed fine for power. I added another one and the power levels dropped dramatically.  have heard others complaining of the same thing. It seems that mesh is mostly to protect neighbours from being overpowered with your signal strengths. Another thing I found was that before the second mesh router was added I found my 5GHz had much better range when I turned both 2.4 and 5GHz signal strengths down. My guess was that the antennae or the output RF stage couldn't handle the total power being thrown at the air. MY wife's iPad had trouble with 5GHz across the same room and once I lowered the signals strengths it comm'd mush better anywhere in the house. Of course once she was forced to purchase a new iPad with WiFi6 on it, it worked flawlessly anywhere on our 1 acre property.

The mesh was supposed to allow devices to roam and force them to switch routers when needed. However, a lot of devices do not lie it when you switch and will drop the higher level of comm. My VR headset always had to be rebooted if I moved enough to switch routers. I had to disable that and basically use the routers as APs only.

Another gadget they attempt to force on users is the automatic band switching. That drops many devices as the attempt to force say...HA bulbs to 5GHz causes them to drop their connections, sometimes permanently until rebooting again.

Anybody else that states mesh is a PoS and a PITA, I agree with them totally. Devices already have automatic switching built into them for the last 20 years. They don't need routers attempting to force them off the air to make it happen.

[RPerrault]

1 hour ago, larryllix said:

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.

bingo - i thought that is how insteon worked with scenes but evidently not (watching event viewer it looks like individual device commands are sent)

that was my thought - its called 'multicasting' in routed networks - there are reserved addresses (standard ones but i think you can set your own) - generally used for streaming and video conferencing and such but not limited to that - ge uses it to stream telemetry data in its medical systems - not sure if the traffic can be tcp or only udp (generally its udp)

 

[RPerrault]

1 hour ago, larryllix said:

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.

i'm kinda thinking that too - never can get an example of real world constraints - just lots of theorizing (something i NEVER do - snicker)

[Dub]

10 minutes ago, RPerrault said:

um - every z-wave device can't necessarily reach every other z-wave device - if not in range, other devices repeat the signals - or hops

Hey RPerrault.  I’m not following your comment to my quote above.  I totally understand that with Z-Wave.  I tried adding my Polisy as a secondary controller to my Qolsys alarm panel and learned that the hard way. I like the ease of use of the Qolsys but the interoperability and not being able to shift to be a second controller opened my eyes.  I just wanted to add some “trigger” type Z-Wave devices like remotelinc in the Insteon world and Qolsys doesn’t recognize them and  can’t use them with the Polisy being the secondary controller. That’s when I figured out there wasn’t broadcast type traffic and the Polisy couldn’t see what the Zwave network was doing in real time since it wasn’t the primary.  I can query the Z-Wave device and send commands but not see changes in real time.  Doing a periodic query was where I settled on to bring my lock status and thermostat information into Polisy.  I may be misunderstanding something but have moved on from trying to tightly integrate with the Qolsys.

[larryllix]

bingo - i thought that is how insteon worked with scenes but evidently not (watching event viewer it looks like individual device commands are sent)
that was my thought - its called 'multicasting' in routed networks - there are reserved addresses (standard ones but i think you can set your own) - generally used for streaming and video conferencing and such but not limited to that - ge uses it to stream telemetry data in its medical systems - not sure if the traffic can be tcp or only udp (generally its udp)
 

I believe that us why multitasking and Insteon scenes cannot use a response. Do many devices trying to report back at the same time could really bog down comms for a few hiccoughs fighting over no arbitration technique except to keep blasting away at it.

Sent from my SM-G781W using Tapatalk

[RPerrault]

1 hour ago, larryllix said:

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.

i don't know how wifi handles this - but one thought is this

channel 6 time slot can send 5 meg for each burst

my ipad downloading debbie does dallas is on the same ap as my dimmer

my dimmer has a packet to be delivered that is 5kb

my ipad has a frame to be delivered on that same ap that is 4 meg

can both be sent in one burst on the same channel?

similar to stat muxing

in any event, both devices will be sending acknowledgments in tiny packets - so my guess is its muxed (not one packet per frame)

and - qos (quality of service - a traffic prioritizing method) is supported on wifi - delay the porn download - don't popcorn my scenes

 

[jec6613]

55 minutes ago, RPerrault said:

the wifi mesh stuff - i don't have an understanding of how it works and what the advantages are

say i have 6 - do all 6 use the same channels?

how is the traffic sent back through the others?  through wifi or some kind of dedicated rf?

not sure how sophisticated these devices are - but every ap i have worked with decrease power when overlap in coverage is detected

2 hours ago, larryllix said:

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.

Bandwidth in WiFi is a fickle thing.  Technically, you can move some obscene amount of bits around - but after the protocol overhead and weak signals, there be dragons.

@larryllixIn 802.11n, used on the 2.4 GHz channel by WiFi 5, each device beacons and exchanges L1 and L2 data on a set interval.  To solve the hidden station problem, these are the same length of time regardless of how much data is actually transmitted.  That means if you have 100 IoT devices on a normal 2.4 GHz WAP with 200 maximum devices, half of the WAP's time and therefore potential bandwidth is spent transmitting literally zero data, just with the devices confirming there is no data to be sent.

So if you take a typical 300 Mbps 802.11n 2.4 GHz deployment, add 100 IoT devices to it, you now have a theoretical maximum of 150 Mbps available to that 101st device that's streaming Netflix.  Add in the various protocol overheads to ensure reliable data transmission, and you're now at about 80 Mbps.  And now that 101st device is a Roku stuck behind a TV with terrible interference and can only reach 1/4 of its maximum rate, and now it's 20 Mbps.  Not actually enough for 4K streaming.

The long of the short of it is: the more associated STA, the less of your actual bandwidth your devices have available.

And, by the way, all of the above is shared with all WAPs that your WAP can see sharing its channel, as they arrange who gets which timeslice in a particular channel.

WiFi 6/802.11ax solves this by using a few methods - first, by making it work on 2.4 GHz as well for all those cheap IoT devices that use 2.4 GHz (the higher data rate means more room to start with), adding MU-MIMO support, and then it also uses sub channels and target wait times so that when a bandwidth hungry device demands the WAP's attention, it actually does receive close to the WAP's maximum available bandwidth despite so many other devices being connected.  But legacy WiFi 5 installs, or legacy WiFi 5 devices connecting to WiFi 6 networks, still suffer this problem.

@RPerraultMesh devices work generally by emulating what a traditional multi-access point setup would do - allowing devices to roam between them as required for coverage and bandwidth.  Like a traditional multi-AP setup, their software manages channels and client devices for optimum performance.  Most of the time, they're on independent channels for the client devices to connect to.  Their trick is that they use WiFi to transmit data back to the main router, rather than moving it over more traditional wired Ethernet (though many can and will happily use Ethernet if you have it available.

Why this is great with a lot of IoT devices is that 1) it solves the above mentioned timeslicing problem on the networking by simply brute forcing it with large numbers of WAPs, each able to use optimal channels, 2) the higher WAP population means the average power transmission so less interference with other WAPs sharing the channel and, 3) by using a closer WAP, the average data rate tends to be much higher for devices that do transmit a lot of data.

Even though the backhaul uses WiFi, it's only a handful of devices communicating, with the clearest possible channel, with highly optimized antennas and very fast radios (8x8 is normal).  And because no clients are on them, the "I have nothing for you" packets that are between the clients and WAPs simply never get transmitted across the backhaul connection except by the other WAPs in the mesh.

Edited June 28, 2022 by jec6613

[RPerrault]

38 minutes ago, larryllix said:

Yeah, I had one ASUS ax92u router and it seemed fine for power. I added another one and the power levels dropped dramatically.  have heard others complaining of the same thing. It seems that mesh is mostly to protect neighbours from being overpowered with your signal strengths. Another thing I found was that before the second mesh router was added I found my 5GHz had much better range when I turned both 2.4 and 5GHz signal strengths down. My guess was that the antennae or the output RF stage couldn't handle the total power being thrown at the air. MY wife's iPad had trouble with 5GHz across the same room and once I lowered the signals strengths it comm'd mush better anywhere in the house. Of course once she was forced to purchase a new iPad with WiFi6 on it, it worked flawlessly anywhere on our 1 acre property.

The mesh was supposed to allow devices to roam and force them to switch routers when needed. However, a lot of devices do not lie it when you switch and will drop the higher level of comm. My VR headset always had to be rebooted if I moved enough to switch routers. I had to disable that and basically use the routers as APs only.

Another gadget they attempt to force on users is the automatic band switching. That drops many devices as the attempt to force say...HA bulbs to 5GHz causes them to drop their connections, sometimes permanently until rebooting again.

Anybody else that states mesh is a PoS and a PITA, I agree with them totally. Devices already have automatic switching built into them for the last 20 years. They don't need routers attempting to force them off the air to make it happen.

unless there are some aps i don't know about - roaming requires a wifi controller of some sort - people don't realize that when buying something like those ubiqutit or unifi or whatever - but they do offer both a cloud controller (um - really?) or a hardware controller that can be installed locally

i don't know enough about mesh wifi (not the frequencies - the topology) but they seem to be fancy range extenders if they all use the same channels and have to route the traffic back via the same wifi frequencies

[RPerrault]

29 minutes ago, WHaas said:

Hey RPerrault.  I’m not following your comment to my quote above.  I totally understand that with Z-Wave.  I tried adding my Polisy as a secondary controller to my Qolsys alarm panel and learned that the hard way. I like the ease of use of the Qolsys but the interoperability and not being able to shift to be a second controller opened my eyes.  I just wanted to add some “trigger” type Z-Wave devices like remotelinc in the Insteon world and Qolsys doesn’t recognize them and  can’t use them with the Polisy being the secondary controller. That’s when I figured out there wasn’t broadcast type traffic and the Polisy couldn’t see what the Zwave network was doing in real time since it wasn’t the primary.  I can query the Z-Wave device and send commands but not see changes in real time.  Doing a periodic query was where I settled on to bring my lock status and thermostat information into Polisy.  I may be misunderstanding something but have moved on from trying to tightly integrate with the Qolsys.

oh - sorry - i saw another reply to you that was wrong - that the zwave associations were direct device-to-device - not if the associated devices are out of direct range of each other

 

[Dub]

8 minutes ago, RPerrault said:

oh - sorry - i saw another reply to you that was wrong - that the zwave associations were direct device-to-device - not if the associated devices are out of direct range of each other

 

Gotcha.  No problem.  Here to learn and appreciate the insights.

[jec6613]

19 minutes ago, RPerrault said:

unless there are some aps i don't know about - roaming requires a wifi controller of some sort - people don't realize that when buying something like those ubiqutit or unifi or whatever - but they do offer both a cloud controller (um - really?) or a hardware controller that can be installed locally

i don't know enough about mesh wifi (not the frequencies - the topology) but they seem to be fancy range extenders if they all use the same channels and have to route the traffic back via the same wifi frequencies

They do in fact do all of the above.  The controller functions are now so light relative to modern processors that they use one of the mesh nodes to act as a controller - exchanging keys and everything.  Cisco has had this for over a decade on their small business line of traditional WAPs (they called it "Single point setup")

Only fast roaming (802.11k/r) and assisted roaming requires a WiFi controller, devices can roam just fine by trying to figure out what's best by themselves, it's just that they necessarily are horrible at it.

[RPerrault]

12 hours ago, WHaas said:

Gotcha.  No problem.  Here to learn and appreciate the insights.

jump on in - we all are

i am victimizing the routed network guys to help me clarify concepts i am foggy about

i was talking to an anesthetist - she was from india - asking about why some nerve blocks last longer than others and why that is different from an epidural - she said 'you ask too many questions' - but she did answer

sigh

 

 

12 hours ago, jec6613 said:

They do in fact do all of the above.  The controller functions are now so light relative to modern processors that they use one of the mesh nodes to act as a controller - exchanging keys and everything.  Cisco has had this for over a decade on their small business line of traditional WAPs (they called it "Single point setup")

Only fast roaming (802.11k/r) and assisted roaming requires a WiFi controller, devices can roam just fine by trying to figure out what's best by themselves, it's just that they necessarily are horrible at it.

but one of the constraints of using wifi in ha was the limited channels - i pointed out that each ap uses 3 channels - not the SAME 3 channels - wondering is mesh uses the same 3 channels

too many aps too close cause problems - because they have to change channels because another ap in range is using that channel - too many can cause constant thrashing of all the aps constantly changing channels - one mitigation strategy is to power back the ap so its range is less 

 

11 hours ago, jec6613 said:

There's also IPv4 multicasting, which take advantage of the above to deliver messages to only subscribed clients.

can the traffic be tcp?  only applications that come to mind are udp applications

 

 

11 hours ago, jec6613 said:

a standard residential /64 subnet could contain up to 18 quintillion devices (future proof much?)

well when we are putting our nail clippers online...

 

12 hours ago, jec6613 said:

In 802.11n, used on the 2.4 GHz channel by WiFi 5, each device beacons and exchanges L1 and L2 data on a set interval. 

something like a keepalive?  or a time to live interval?  i did not think wifi had to solicit data from every device

 

12 hours ago, jec6613 said:

Their trick is that they use WiFi to transmit data back to the main router, rather than moving it over more traditional wired Ethernet

now THERE is overhead - bandwidth used for relaying is bandwidth not available to end devices

 

[jec6613]

3 hours ago, larryllix said:

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.

That's ... literally what the IP broadcast address is for.  If you have a network, 192.168.0.0/24, with 192.168.0.1 as your router, then by sending a packet to 192.168.0.255 it lights up every single device on that subnet.

For Layer 2 devices, if you send to MAC FF:FF:FF:FF:FF:FF, then it hits every port on your L2 broadcast domain.

There's also IPv4 multicasting, which take advantage of the above to deliver messages to only subscribed clients.

And, finally, IPv6 uses multicasting to address multiple devices at once, since IPv6 lacks a broadcast address since a standard residential /64 subnet could contain up to 18 quintillion devices (future proof much?)

[RPerrault]

in hospitals, they have an annual inspection of biomed equipment - and iv pumps are expensive and constantly disappear

while listening to the cfo whine about it - i told him i could put a $50 tag on each pump and find them for him IF they were in the building - he tried to kiss me

the proximity tags are battery operated wifi - when used with lots of other cisco components they already had, you can locate each tag

now granted, the batteries were changed annually - but they did last a year - and tons of them

granted, lots of aps too - but telemetry equipment, vital sign devices, guests on wifi streaming who knows what, 150 wifi phones, ekg carts - who knows what all is on wifi

had 2 wifi problems while at that hospital

one clinic was dropping and recovering aps - rogue detection is a regulation in that hospital and the clinic next door triggering it - they got 'free wifi' from those companies that give them free wifi in exchange for those huge tablets in the waiting and exam rooms selling you drugs you never knew you needed - and prompting you to beg the doctor for them

the second problem was when the director doubled the number of aps on one floor to expand coverage - which caused the hospital aps to thrash changing channels and decrease their power - giving less coverage

the proof was visible to the kissing cfo on the cisco prime heatmap - because the director refused to believe less can be more with aps 

the thing that amazed me was that even with all the thrashing, the wifi network handled it remarkably well - the diminished coverage was what brought attention to the problem

 

[upstatemike]

1 hour ago, ryarber said:

May I ask, are your z wave devices all of a later generation? What generation are they?

And what type hub do you have?

Several Homeseer dimmers and fan switches plus a Zooz wireless switch, 4 Zooz scene controllers, and some Zooz plug-in modules plus 1 Inovelli dimmer. All current generation 700 series. Currently testing with Homeseer/Z-Net but will also test using Polisy, Home Assistant, and Hubitat at some point. (I have all of the controllers, I just need to find the time)

[upstatemike]

54 minutes ago, RPerrault said:

but one of the constraints of using wifi in ha was the limited channels - i pointed out that each ap uses 3 channels - not the SAME 3 channels - wondering is mesh uses the same 3 channels

too many aps too close cause problems - because they have to change channels because another ap in range is using that channel - too many can cause constant thrashing of all the aps constantly changing channels - one mitigation strategy is to power back the ap so its range is less 

Another mitigation is to shut off auto channel select and lock each AP onto a non-overlapping channel. I definitely don't allow auto channel select in the 2.4GHz range.

[larryllix]

2 hours ago, jec6613 said:

Bandwidth in WiFi is a fickle thing.  Technically, you can move some obscene amount of bits around - but after the protocol overhead and weak signals, there be dragons.

@larryllixIn 802.11n, used on the 2.4 GHz channel by WiFi 5, each device beacons and exchanges L1 and L2 data on a set interval.  To solve the hidden station problem, these are the same length of time regardless of how much data is actually transmitted.  That means if you have 100 IoT devices on a normal 2.4 GHz WAP with 200 maximum devices, half of the WAP's time and therefore potential bandwidth is spent transmitting literally zero data, just with the devices confirming there is no data to be sent.

So if you take a typical 300 Mbps 802.11n 2.4 GHz deployment, add 100 IoT devices to it, you now have a theoretical maximum of 150 Mbps available to that 101st device that's streaming Netflix.  Add in the various protocol overheads to ensure reliable data transmission, and you're now at about 80 Mbps.  And now that 101st device is a Roku stuck behind a TV with terrible interference and can only reach 1/4 of its maximum rate, and now it's 20 Mbps.  Not actually enough for 4K streaming.

The long of the short of it is: the more associated STA, the less of your actual bandwidth your devices have available.

And, by the way, all of the above is shared with all WAPs that your WAP can see sharing its channel, as they arrange who gets which timeslice in a particular channel.

WiFi 6/802.11ax solves this by using a few methods - first, by making it work on 2.4 GHz as well for all those cheap IoT devices that use 2.4 GHz (the higher data rate means more room to start with), adding MU-MIMO support, and then it also uses sub channels and target wait times so that when a bandwidth hungry device demands the WAP's attention, it actually does receive close to the WAP's maximum available bandwidth despite so many other devices being connected.  But legacy WiFi 5 installs, or legacy WiFi 5 devices connecting to WiFi 6 networks, still suffer this problem.

@RPerraultMesh devices work generally by emulating what a traditional multi-access point setup would do - allowing devices to roam between them as required for coverage and bandwidth.  Like a traditional multi-AP setup, their software manages channels and client devices for optimum performance.  Most of the time, they're on independent channels for the client devices to connect to.  Their trick is that they use WiFi to transmit data back to the main router, rather than moving it over more traditional wired Ethernet (though many can and will happily use Ethernet if you have it available.

Why this is great with a lot of IoT devices is that 1) it solves the above mentioned timeslicing problem on the networking by simply brute forcing it with large numbers of WAPs, each able to use optimal channels, 2) the higher WAP population means the average power transmission so less interference with other WAPs sharing the channel and, 3) by using a closer WAP, the average data rate tends to be much higher for devices that do transmit a lot of data.

Even though the backhaul uses WiFi, it's only a handful of devices communicating, with the clearest possible channel, with highly optimized antennas and very fast radios (8x8 is normal).  And because no clients are on them, the "I have nothing for you" packets that are between the clients and WAPs simply never get transmitted across the backhaul connection except by the other WAPs in the mesh.

I have never heard of any beacons going back and forth on WiFi. I cannot detect any traffic on any of my devices unless higher level protocol layers do a keepalive packet on a periodic basis. If my devices are not used for a period of time the router forgets them and drops them from it's connected table. This happens to almost all my devices. My WiFi bulbs get sent a keepalive packet via a status request every 90 seconds that I set in my software.  If they are not talking or being talked to they do not consume any bandwidth from the time pool. No time slots are reserved AFAIK. 100 inactive devices on WiFi5 do not consume all the bandwidth for other devices. Perhaps that was some newer technique used in routers. I always thought WiFi was just another collisions detection system for arbitration as wired Ethernet is.

[jec6613]

2 hours ago, RPerrault said:

something like a keepalive?  or a time to live interval?  i did not think wifi had to solicit data from every device

 

now THERE is overhead - bandwidth used for relaying is bandwidth not available to end devices

 

WiFi (802.11n era) needs to give the clear to send signal at minimum intervals for all STAs.  Once you're on 802.11ac with MU-MIMO, or 802.11ax, the problem mostly disappears.  That's why in 802.11ac Wave 2 was such a boon for dense configuration.  But, most IoT are still 802.11n 2.4 GHz only.

As for the backhaul, on good mesh devices, it's a dedicated radio so there's nothing eating up bandwidth.  As an example, the Netgear RBRE960 sports:

1. 2.4 GHz 802.11ax for clients - 4x4 (1200 Mbps PHY)
2. 5 GHz 802.11ax for clients - 4x4 (2400 Mbps PHY)
3. 6 GHz 802.11ax for clients - 4x4 (2400 Mbps PHY)
4. 5 GHz 802.11ax backhaul only - 8x8 (4800 Mbps PHY)

Now, obviously, in a normal mesh configuration you'd be using a 600 Mbps 20 MHz channel for 2.4 GHz so you could get an aggregate 1800 Mbps across three WAPs, but, yeah.  Good wireless backhaul can outperform Gigabit Ethernet.

2 hours ago, RPerrault said:

can the traffic be tcp?  only applications that come to mind are udp applications

Yes it can, although in IPv4 nobody's done it, it's been used in IPv6 for some experimental uses and backhaul among networks.

2 hours ago, RPerrault said:

but one of the constraints of using wifi in ha was the limited channels - i pointed out that each ap uses 3 channels - not the SAME 3 channels - wondering is mesh uses the same 3 channels

too many aps too close cause problems - because they have to change channels because another ap in range is using that channel - too many can cause constant thrashing of all the aps constantly changing channels - one mitigation strategy is to power back the ap so its range is less 

This depends on the vendor, but the high quality ones use similar auto channel selection to a traditional Cisco controller - which means normally yes, different channels.  They also use the power back strategy on a per radio basis, and on newer WiFi 6 devices they dynamically adjust power based on which STA are currently connected and reduce power to radios on other WAPs.

Edited June 28, 2022 by jec6613

[smokegrub]

I am, at best, on the margin of this thread which has devolved into a discussion of what appears to be primarily installer-related concerns regarding the future of technology. That's great, but please permit me to share my interests and concerns as they relate to my use of Insteon technology. I have two homes with all Insteon and UDI (ISY) technology. With the help of UDI and many kind folks at this board I have installed and maintained these systems. They are dependable, fast and economical. Despite the fact that the homes are separated by hundreds of miles they have worked astoundingly well. for more that 10 years. I have have had one PLM and two other Insteon devices fail. One of the two devices was replaced by Smarthome under warranty. I suspect I may be in the minority, but I want the Insteon product line and technology to succeed and to be supported by UDI. In fact, I would like to see some new Insteon products such as dependable door locks. I have not used other technology for my doors because they are notorious for needing mesh technology. I have two situations where my Insteon devices dependably communicate up to distances of 30 yards! This includes leak detectors of which two have identified leaks and saved used us hundreds, if not thousands, of dollars. A blend of Wyze cameras, Insteon motion detectors, hidden door sensors and Alexa have added to our ability to monitor our homes and optimally use the Insteon devices. Simple programs and routines have improved our lives as we approach 80 years of age. I am "holding my breath" that the new owners of the Insteon product line will be successful and that they will work proactively with UDI to get even better. In the meantime, I encourage you to continue the march forward to new, improved technology.