why the aversion to wifi?

[RPerrault]

curious why the consensus seems to be against using wifi for packet delivery to home automation devices.

 

[lilyoyo1]

15 minutes ago, RPerrault said:

curious why the consensus seems to be against using wifi for packet delivery to home automation devices.

 

If you've read the posts to come to this conclusion, our answers are in those same posts. In short, think about all the issues people currently have with their current wireless devices and wifi networks! Now extrapolate that across potentially dozens of additional devices.

[stillwater]

Go look at the support forums for various wifi- based systems -- for example for Shelly https://www.facebook.com/groups/1686781668087857

You will find many happy campers and many with continuing problems with devices dropping their connections.  Of course the forums overrepresent those with problems.  

Factors that will affect performance include the total number of devices,  number of wifi clients on an access point, contention for 2.4 hz channels (how close are your neighbors and will they suddenly change wifi channels?), the quality of the access points (many supplied by cable or phone companies can only serve 20-30 clients), and whether the devices are in metal boxes or not.   Also some devices have better wifi than others (for example within the common Expressif universe the ESP32 devices have more power than the earlier ESP8266).    Other concerns include security (both capabilities and how they are implemented) and relatedly whether the devices need contact outside the house or not.  (Obviously a system that relies on a remote server to operate is going to be less reliable and more insecure than one that can be walled off by the router from connection outside the house.)

In sum people with small systems, high-capacity well-deployed wifi infrastructure (e.g. Unifi), no close neighbors to muck up the 2.4GHZ channels, and some luck will do better than people with lots of devices, haphazard wifi infrastructure, close neighbors, or devices in metal boxes.  

The discussions of wifi-based systems in this forum are mostly focussed on the general question of what would be best and most robust and reliable, with the fewest problems especially in a large or complex installation, and with the fewest failure modes due to separate systems (such as the wifi router and access points).   On these criteria a separate network and frequency seems preferable.   That is not to say wifi systems can not be made to work, especially based on the conditions mentioned above, or that a few wifi devices shouldn't be added to a large system that generally uses another communications net. 

 

Edited February 27, 2022 by stillwater
added conclusion

[larryllix]

I use WiFi for many HA devices in my home but they are mostly smart RGBCW light bulbs ad strips that are not resident inside a metal electrical box or in close proximity to house wiring and the importance of them being 100% is not critical. Havng said that mine works almost 100% of the time and I am quite happy with the results.

However I would not want to use any real-time, instant response required equipment on a WiFi protocol. I have a real hard time with a light switch that causes a light to go on 2 seconds later, let alone be delayed 5-10 or even 30 seconds later because my router is streaming  3 x 8K video channels.

WiFi can have it's uses but it's not for everywhere or everybody. My RGBCW bulbs all cost between $6 and $20 each and have 5 channels of LED colours. No cloud services involved.

[RPerrault]

i think i assumed every install would be the same as mine - single family dwelling distanced from neighbors - i can see where channel hopping could be a problem in apartments and condos - rogue detection can cause problems

i was given the job of keeping a hospital info tech afloat when a new owner bought it - they put in all new network equipment - including access points and controllers - when it was complete, the new director came in and decided to double the number of access points on one floor - which caused all the access points on the floor or power back resulting in less coverage - and the entire hospital thrashing by constantly changing channels - he could not understand why adding access points caused more problems and less coverage - the heat maps did not lie but he remained unconvinced

i installed a cisco be7k voip phone system and had cisco's new (at the time) wifi phones - about 200 of them - integrated them into a nurse call system - after the birthing pains, i had no problems - and there is a ton of stuff on wifi in a hospital - and guest access too

but - this was cisco end to end

i think i am misunderstanding the verbiage - for me - router is like a network router - i think here they use router to mean what i call a wifi controller - i also assumed that people had at least a rudimentary controller if they have more than one access point

not real knowledgeable about the number of devices that can be handled - but the packets for these devices are incredibly small - i'll have to check if my home stuff supports qos but that could prioritize the traffic

i read a thread where someone has a trace for rf traffic (sniffer, wireshark - whatever) - that took me off into looking into the insteon protocol - always been a black hole to me and i never crossed the event horizon to see what was inside - it seems to have at least a crc check and acks - more akin to tcp traffic than udp - always wondered about that when communication/reliability fights break out (started more than a few of those on my craplinc adventures) - still need to read about how the grouping works because i use a ton of scenes and love the inste part of insteon scenes 

 

[stillwater]

In Insteon the  PLM links table (<1000 entries) limits the number of devices/scenes that can be supported -- I only learned this after installing keypads and other devices that would have exceeded the links capacity of the PLM if I relied on scenes alone.  (ISY programs can substitute in many cases but then you are dependent on ISY).     Also the powerline component has its own issues -- see forum items on Insteon Communications Issues.     I had to install custom filters at my Insteon loads to prevent my GU10 Soraa bulbs from flashing full bright on Insteon traffic.  Other systems (Zwave, Lutron RA2 and RA3) all have their  own addressing limits.    In other words, nothing is perfect, especially when you factor in that things now widely available may not be tomorrow.     It's a wonder anything works! 

[RPerrault]

as best i recall, in the early days of insteon i hit that limit on my plm - someone sent me a custom built plm that i think i am still using today - his company makes a nice controller too *cough*

 

[RPerrault]

i wonder - if the secret to the inste part of insteon scenes - that i cannot go without - is implemented like multicast - the scene members have a different address they listen for in addition to their own address - an address all participants in that scene use

think i answered my own question using the event viewer - its no

that said - it IS amazing it works so well with all the scenes i have set up

just one room - den - 35 participants

 

[lilyoyo1]

11 hours ago, RPerrault said:

i think i assumed every install would be the same as mine - single family dwelling distanced from neighbors - i can see where channel hopping could be a problem in apartments and condos - rogue detection can cause problems

i was given the job of keeping a hospital info tech afloat when a new owner bought it - they put in all new network equipment - including access points and controllers - when it was complete, the new director came in and decided to double the number of access points on one floor - which caused all the access points on the floor or power back resulting in less coverage - and the entire hospital thrashing by constantly changing channels - he could not understand why adding access points caused more problems and less coverage - the heat maps did not lie but he remained unconvinced

i installed a cisco be7k voip phone system and had cisco's new (at the time) wifi phones - about 200 of them - integrated them into a nurse call system - after the birthing pains, i had no problems - and there is a ton of stuff on wifi in a hospital - and guest access too

but - this was cisco end to end

i think i am misunderstanding the verbiage - for me - router is like a network router - i think here they use router to mean what i call a wifi controller - i also assumed that people had at least a rudimentary controller if they have more than one access point

not real knowledgeable about the number of devices that can be handled - but the packets for these devices are incredibly small - i'll have to check if my home stuff supports qos but that could prioritize the traffic

i read a thread where someone has a trace for rf traffic (sniffer, wireshark - whatever) - that took me off into looking into the insteon protocol - always been a black hole to me and i never crossed the event horizon to see what was inside - it seems to have at least a crc check and acks - more akin to tcp traffic than udp - always wondered about that when communication/reliability fights break out (started more than a few of those on my craplinc adventures) - still need to read about how the grouping works because i use a ton of scenes and love the inste part of insteon scenes 

 

You're comparing having networking knowledge and enterprise equipment to the avg person who's using cable provided equipment or the cheapest router they can find. 

When I talk about things here, I tend to focus on what the avg person can do as they are the majority. There are people here who use a high number of wifi bulbs successfully but they understand networking and use multiple routers to manage them. For most, that would become a recipe for disaster. 

When I look at the knowledge I have about automation and integration, I feel like I'd be doing people a disservice if i came on here acting like less than optimal setups can be easily achieved and managed because I don't have issues (or leave out pertinent info pertaining to what it took to become successful). 

This is why I tell people to avoid wifi based devices (and limit them for myself). Who wants to make reservations for every device they want to use? I get paid to do so and still don't feel like sitting in front of the computer to do so. Then depending on home and network, having to add a second or third router to the mix..... You see where I'm going with this.

[lilyoyo1]

11 hours ago, stillwater said:

In Insteon the  PLM links table (<1000 entries) limits the number of devices/scenes that can be supported -- I only learned this after installing keypads and other devices that would have exceeded the links capacity of the PLM if I relied on scenes alone.  (ISY programs can substitute in many cases but then you are dependent on ISY).     Also the powerline component has its own issues -- see forum items on Insteon Communications Issues.     I had to install custom filters at my Insteon loads to prevent my GU10 Soraa bulbs from flashing full bright on Insteon traffic.  Other systems (Zwave, Lutron RA2 and RA3) all have their  own addressing limits.    In other words, nothing is perfect, especially when you factor in that things now widely available may not be tomorrow.     It's a wonder anything works! 

There are ways to avoid link limits but it takes a lot of planning prior to the installation. Offloading to the isy is one way though it does tie you to the Isy as you've stated. This isn't too big of an issue since you're tied to the Isy anyway. 

In larger installs that I've used insteon with, I've linked switches together outside of the isy such as 3ways in hallways and areas that arent managed. With the Isy supporting zwave, I've skip using insteon outlets and used zwave outlets instead (unless I needed the dual control). I use zwave sensors as well. Setting up scenes with all responders and using programs for the controller saves countless links while giving you the benefits of scene use.

In critical stuff, I always use Controller/responder scenes since it's paramount those work at all times. For the rest, I'm ok with the isy managing things

[stillwater]

@lilyoyo1  I'd be grateful for a little elaboration on   1) linking switches together (for 3-ways) outside of isy and 2) all-responder scenes saving links.  

On linking switches outside of ISY, do you do this just from the switches and then there is no way to restore a switch centrally?  Or is there a way to program the links into the switches centrally perhaps by using a separate PLM for the programming?  

Regarding responder-only scenes.   This never occurred to me.     I assume a responder-only scene can be activated by an ISY  program and can look like a controller-responder scene based on ISY acting to control the scene based on an action from what would otherwise be a controller.  I assume but don't really know that the addition of controllers makes the number of links in the plm the product of the number of controllers and responders.  So it would seem that a single controller isn't a big problem in terms of PLM links but multiple controllers would be, at least for scenes with large number of responders?   

Anyway I'd greatly appreciate any pointers you might have to explanations for how to do these things, or just a few words of elaboration to point me in the right directions.

 

[upstatemike]

4 hours ago, lilyoyo1 said:

You're comparing having networking knowledge and enterprise equipment to the avg person who's using cable provided equipment or the cheapest router they can find. 

When I talk about things here, I tend to focus on what the avg person can do as they are the majority. There are people here who use a high number of wifi bulbs successfully but they understand networking and use multiple routers to manage them. For most, that would become a recipe for disaster. 

When I look at the knowledge I have about automation and integration, I feel like I'd be doing people a disservice if i came on here acting like less than optimal setups can be easily achieved and managed because I don't have issues (or leave out pertinent info pertaining to what it took to become successful). 

This is why I tell people to avoid wifi based devices (and limit them for myself). Who wants to make reservations for every device they want to use? I get paid to do so and still don't feel like sitting in front of the computer to do so. Then depending on home and network, having to add a second or third router to the mix..... You see where I'm going with this.

I agree that any HA technology that requires special knowledge to use is a non-starter. I am not particularly network savvy and I would not begin to know how to use multiple routers to divide up WiFi bulb loads especially since any device on my network could at some point need to control or respond to pretty much any other device on the network. The only devices I can safely isloate are those on the guest Wi-Fi.

I'm not sure I agree that nobody wants to use reserved address for everything. I have approximately 180 reserved addresses and can't imagine what a pain it would be if every time I had to troubleshoot something I had to search through a list of MAC addresses to figure out what IP address I'm looking for. I always use reserved addresses and I won't use any router or WAP that doesn't display devices by the name I've assigned in the DHCP reservation table rather than by IP or MAC address. 

[upstatemike]

3 hours ago, lilyoyo1 said:

There are ways to avoid link limits but it takes a lot of planning prior to the installation. Offloading to the isy is one way though it does tie you to the Isy as you've stated. This isn't too big of an issue since you're tied to the Isy anyway. 

In larger installs that I've used insteon with, I've linked switches together outside of the isy such as 3ways in hallways and areas that arent managed. With the Isy supporting zwave, I've skip using insteon outlets and used zwave outlets instead (unless I needed the dual control). I use zwave sensors as well. Setting up scenes with all responders and using programs for the controller saves countless links while giving you the benefits of scene use.

In critical stuff, I always use Controller/responder scenes since it's paramount those work at all times. For the rest, I'm ok with the isy managing things

Half-Links. Sounds like something from "Lord of the Rings".

[lilyoyo1]

7 minutes ago, stillwater said:

@lilyoyo1  I'd be grateful for a little elaboration on   1) linking switches together (for 3-ways) outside of isy and 2) all-responder scenes saving links.  

On linking switches outside of ISY, do you do this just from the switches and then there is no way to restore a switch centrally?  Or is there a way to program the links into the switches centrally perhaps by using a separate PLM for the programming?  

Regarding responder-only scenes.   This never occurred to me.     I assume a responder-only scene can be activated by an ISY  program and can look like a controller-responder scene based on ISY acting to control the scene based on an action from what would otherwise be a controller.  I assume but don't really know that the addition of controllers makes the number of links in the plm the product of the number of controllers and responders.  So it would seem that a single controller isn't a big problem in terms of PLM links but multiple controllers would be, at least for scenes with large number of responders?   

Anyway I'd greatly appreciate any pointers you might have to explanations for how to do these things, or just a few words of elaboration to point me in the right directions.

 

I would add devices using another ISY/PLM and link those together using that setup. That way, I can configure the ramp rate and light level with the system and what they do, do not impact the isy. It also allows me to save the configuration should I ever need to restore it. Should a customer decide to add programming at a later date, I simply add them to the ISY thats on site. Should ramp rate and stuff not matter, this can be done manually (I have done it manually)

Ditto for situations such as storage closets. In those cases, I would use insteon sensors linked directly to the light so that the light turns on/off when the door opens or closes. No controller is necessary unless someone wants more functionality. Keep in mind, this is not the norm. My main goal is to keep things under 1 controller and everything part of the system. However, there are times when you have to think outside of the box to make stuff work. In general, you should not have to reload your system unless something goes wrong. With these situations being basic on/off control, im not as concerned about configuration as I would be with the system itself.

Responder scenes are just that. A scene created and configured with everything as a responder. I'll then write a program that will turn the scene on from it. You do lose flexibility this way in that you can't dim the lights on or off from the controller but thats not my concern when its done in this manner.

When you're trying to save links, every link you dont have is a link saved. A controller in a scene creates 2 links while a responder is 1. Take (2) 8 button kpls cross-linked with each other. Thats 32 links minimum vs 16. Now multiply that by any given number of other switches that you may have as part of that scene as controllers/responders.

 

 

 

[lilyoyo1]

5 minutes ago, upstatemike said:

Half-Links. Sounds like something from "Lord of the Rings".

Half links are bad and should be avoided as much as possible. However, if managed properly, one can avoid many pitfalls

[RPerrault]

i see what you are saying about using the wifi on a router supplied by an isp - wifi based devices would not repeat the signal so 'buying more' would not make communication more robust - anyone moving to wifi would be well served to know that wifi coverage is a prerequisite to using them - the upside is that most of these devices don't move so if they have multiple access points, the lack of roaming isn't a problem - i guess that is where the 'overwhelm the router' stuff comes in - with access points, the router is not involved 

dhcp works - no need for static addresses

but - for me - throughout my adventures in home automation - it has frustrated me dealing with the lack of diagnostic tools and not knowing the underlying protocol - while wifi and ip might seem overwhelming in the details, at least i CAN learn the details - if i wanted to - my adventures have been a guessing game of power bridges, repeaters, electrical filters - every guess involved more money - sigh

i don't think of hobbyists as 'masses' - i think some people want a parlor trick - anyone that asks me about home automation or the 'how do you do that' question - i tell them its a lot of time and money and planning and research - my guess is that half the people that begin with a parlor trick will get sucked into the black hole 

 

[lilyoyo1]

14 minutes ago, RPerrault said:

i see what you are saying about using the wifi on a router supplied by an isp - wifi based devices would not repeat the signal so 'buying more' would not make communication more robust - anyone moving to wifi would be well served to know that wifi coverage is a prerequisite to using them - the upside is that most of these devices don't move so if they have multiple access points, the lack of roaming isn't a problem - i guess that is where the 'overwhelm the router' stuff comes in - with access points, the router is not involved 

dhcp works - no need for static addresses

but - for me - throughout my adventures in home automation - it has frustrated me dealing with the lack of diagnostic tools and not knowing the underlying protocol - while wifi and ip might seem overwhelming in the details, at least i CAN learn the details - if i wanted to - my adventures have been a guessing game of power bridges, repeaters, electrical filters - every guess involved more money - sigh

i don't think of hobbyists as 'masses' - i think some people want a parlor trick - anyone that asks me about home automation or the 'how do you do that' question - i tell them its a lot of time and money and planning and research - my guess is that half the people that begin with a parlor trick will get sucked into the black hole 

 

Once again, you are seeing things via your lens- not the lens of others. Most do not understand networking enough to know the difference between routers and access points...unless they buy your typical google nest mesh system or something similar. Even then, its still a consumer based product which can have problems the larger the installation becomes. A few devices. No issue. Large number- yes it gets to be a problem. The internet is filled with bad reviews where you can read into the issue and tell its not the device but the network itself. Even in review  articles, ive seen the reviewer talk about problems they had getting things working and it would be due to the network and not the device itself.

Even with access points, the router is still involved as the signal passes through it. The router may not be whats talking directly to the device but its still in the pipeline. You are correct that dhcp works. But if one is trying to connect those devices to other systems (such as the isy) then yes a static address is needed. Imagine you have a house with 25 wifi switches and 30 wifi bulbs. What do you think happens after a power outtage when all of those devices are trying to connect at once? Someone's address will get changed at some point. The last thing anyone wants is to come home at 9pm turn on a light and it doesnt work due to an ip change. Now, if you're using the app and alexa alone, then yes, dhcp is enough since the assigned address is less of a concern.

Who do you think this stuff is made for? While you may not think of hobbyists as the masses, the manufacturers do. Of course some companies such as tuya, homeseer, etc. are hobbyist+ focused, but for most, the hobbyist is the so called masses. This is why every device taughts how a hub isnt needed and connects directly to alexa and google. Its why these companies are pushing Matter (if it matters long term remains to be seen). Everything about their actions says mass use, not hobbyist+. Parlor trick or not, they are where the money is and who things are designed for. We live in their world and try to adapt their products to our use. Not the other way around.

[larryllix]

WE have to remind ourselves that this breaks down into two main groups. The people wanting remote control of things, either via voice, or from a distance. Those people typically do not want the complexity of a "hobbiest system". Many will have routers that are ten years old and cannot handle more than 20-30 devices. These are typically the ones that use older 2.4GHz WiFi at the 56Mbps and slower speeds and are happy with it.

Then there are the people that want actual home automation (HA). These are the people that will sit on the bleeding edge, use the complexities of various technologies and can handle devices that may not work by just putting them n their credit cards. They crave more devices than the "remote control" armchair tech does, and are willing to do some hacking to get what they want. These people typically will have a decent router that can handle 50-90 devices on WiFi.

[RPerrault]

i do perceive the world through my lens - its the correct lens that everyone should use *snicker*

sorry i misunderstood the work router - i took the term as something that performs routing functions - the box provided by an isy will generally provide that function but also wifi and switch functions - should provide a firewall function too

delivering packets between devices on the same network does not need the router function

not much is reliant on a static ip address - there are address resolution lookup functions - open a command prompt and type in 'arp -a' - then 'nslookup ' and one of the ip addresses listed - protocols like ethernet use mac addresses - if a home automation device cannot another device on a network without hard coding addresses, you don't want that device 

devices on a network do not need to know the address of every other device - they only need to know who to ask where a device is - my pc does not need to know the address of the tivo dvr - gratuitous arp - blah - whatever

words need to have meaning - misunderstanding can happen and here is was not catastrophic - i learned what you mean when you say router

but i think before declaring existing technology incompatible for delivering home automation packets, you need an understanding of the technology - i am certainly no routed network geek - nor a z-wave geek - nor an insteon geek - insteon kept their details close to their vest 

i think its finally gelled in my mind where ud is going - i was again a victim of misunderstanding the meaning of words

poly - i think this refers to language - agnostic - c - java - whatever - seems like i read that somewhere - but its all running on that unix stuff - shudder - unix types and their greppin - turn your back on them and they might just grep your backside - one day i have to learn something about unix

the polywhatevers

ud gave us a practical way to manage insteon - the isy - and expanded to handle z-wave - it could be unending trying to support all of the devices and protocols out there - i think the node server phrase is what was throwing me off - now device handler - i'd have grasped that - and grepped it too - they  are giving us a unified interface to handle tons of stuff - gave us the framework for others to develop a device handler and present it to me to manage in something like a single pane of glass - the underlying hardware and protocols are for the developers - i just have to use the isy's interface to be master of it all - or maybe not

and it sounds like even the isy's interface will be migrated to be a polynode thingy - still trying to get a grep on the concept

i just know when i read his 'move over iot - old news - make room for silos' white paper - or something like that - i was way outta my league

 

[larryllix]

Sounds like a news station anchor.  Glad it is working out for you.

Edited February 28, 2022 by larryllix

[lilyoyo1]

36 minutes ago, RPerrault said:

i do perceive the world through my lens - its the correct lens that everyone should use *snicker*

sorry i misunderstood the work router - i took the term as something that performs routing functions - the box provided by an isy will generally provide that function but also wifi and switch functions - should provide a firewall function too

delivering packets between devices on the same network does not need the router function

not much is reliant on a static ip address - there are address resolution lookup functions - open a command prompt and type in 'arp -a' - then 'nslookup ' and one of the ip addresses listed - protocols like ethernet use mac addresses - if a home automation device cannot another device on a network without hard coding addresses, you don't want that device 

devices on a network do not need to know the address of every other device - they only need to know who to ask where a device is - my pc does not need to know the address of the tivo dvr - gratuitous arp - blah - whatever

words need to have meaning - misunderstanding can happen and here is was not catastrophic - i learned what you mean when you say router

but i think before declaring existing technology incompatible for delivering home automation packets, you need an understanding of the technology - i am certainly no routed network geek - nor a z-wave geek - nor an insteon geek - insteon kept their details close to their vest 

i think its finally gelled in my mind where ud is going - i was again a victim of misunderstanding the meaning of words

poly - i think this refers to language - agnostic - c - java - whatever - seems like i read that somewhere - but its all running on that unix stuff - shudder - unix types and their greppin - turn your back on them and they might just grep your backside - one day i have to learn something about unix

the polywhatevers

ud gave us a practical way to manage insteon - the isy - and expanded to handle z-wave - it could be unending trying to support all of the devices and protocols out there - i think the node server phrase is what was throwing me off - now device handler - i'd have grasped that - and grepped it too - they  are giving us a unified interface to handle tons of stuff - gave us the framework for others to develop a device handler and present it to me to manage in something like a single pane of glass - the underlying hardware and protocols are for the developers - i just have to use the isy's interface to be master of it all - or maybe not

and it sounds like even the isy's interface will be migrated to be a polynode thingy - still trying to get a grep on the concept

i just know when i read his 'move over iot - old news - make room for silos' white paper - or something like that - i was way outta my league

 

You've lost me and it sounds like you're just rambling. I'm going to bow out now as nothing about this makes any sense

[stillwater]

@RPerrault 

I too am not sure what your point is ... but let me offer one idea that may help your exploration of this space ... though I am far from an expert.

I think the crucial piece of the ISY evolution you didn't mention is the jump to version 5.x.  This opened up the representation of devices within the ISY (a device is a  structured set of nodes with each node having specified parameters, i think one could say.  For example an Insteon 8 button  KPL has 8 button nodes that each have  a status and can be the source of on/off/FastOn/FastOFF and brighten/dim commands,  or a thermostat has a contact and a setpoint and a temperature and maybe a humidity measurement, in set units).  The point is that 5.x opened up this device definition to the user.  

UDI used this new open node definition language to define Zwave devices but also it allows nodes to be defined by the user.   "Node server" may not be the most artful name but what a node server does is configure the representation of a set of devices and their nodes within ISY and then manage communications and synchronization between the ISY and the devices.  So installing the node server may give the user the capability to install specific devices and then the node server (a program running on an off-board computer in the case of PG2 or in the cloud in the case of PGC or on the POLISY hardware along with ISY in the case of PG3.   (I just realized I don't know for sure if POLISY will continue to allow homegrown Nodeservers on an external platform -- I certainly hope so since I just bought a POLISY)

In my case I have a sauna that is actually controlled as if it were a heating zone in my computer-controlled HVAC system.  I wanted to be able to have various insteon KPL buttons turn the Sauna ON and OFF and indicate when it is heating and when it is up to temperature.   So I have a Raspberry PI that receives info on the state of the Sauna (heating, ready, off) from the HVAC system and also is able to turn the sauna "zone" on in the HVAC system.   A node profile on the ISY creates a node for the Sauna that can be controlled by the KPL buttons and can be included in scenes.  When  the KPL controller button is pushed  on  or off  ISY tells the program running on the raspberry pi to change the sauna zone on or off accordingly, and similarly when the zone changes state (OFF, Heating, Ready) in the HVAC system  it tells the PI program and the PI program tells the ISY to change the node status. Then the ISY changes the KPL button lights  accordingly.   

All very simple and it turns out, completely reliable.  In my case the Raspberry PI is running a program written in Dyalog APL.  So yes node servers can be written in any language (though I am not using the PolyGlot facility). 

In practice  an operating node server may be viewed as  middleware between controllers or between an info source and ISY--  as with the various weather info nodeservers.   Or as your alternative name ("device manager") would suggest a node server could interact directly with a raft of IoT  devices by one or more special communication protocols and transport layers (HTTP or MQTT over wifi or ethernet,  but also Modbus or  Bacnet over RS485,  or Zigbee, LoRa, LTE, etc. etc.) 

[RPerrault]

thanks sw - i have to understand the concept of how something like this works - makes troubleshooting possible for me 

i kinda missed the poly revolution - i don't visit often - dropped in to see what was going on with insteon when i tried to order a device and saw the scarcity - and to see if there was a new software release - having some challenges with some iblinds - z-wave - it does not like me

i did have polycloud - played with ecobee, sonos, ring doorbells and a weather node - i saw the nodes show up in my isy, and one day saw that i could use those resources in programs - the doorbell can turn on the outdoor lights if it detects motion - perfect - i wanted a motion sensor in the front but was resigned to doing what i did in the back - elk wired motion sensor

after thinking a long time - it started to hit me what the node applications were - kinda gives me a single pane of glass to manage disparate hardware in an interface i am familiar with - someone ELSE did the hard part for me

this is great news - i tried insteon thermostats, motion sensors and water detection and never satisfied - with poly, i can set an ecobee thermostat, start playing tunes on sonos and turn on an insteon light when i cross a gps boundry - not that i do that kinda stuff - but i could

the isy interface with echo was the best thing ever though - no formulaic speech needed especially since the routines now give us the lights for each device - i begged for some kinda location awareness of each echo - now 'turn off the lights' means something different for each echo - (and the alternate names for resources in the portal is great - i heard alexa say 'i could not find damn lights' - realized it was my 95 year old mom trying to turn off the den lights - now damn lights or den lights - either will work with a southern drawl)

thanks for helping me get the concept gelled in my pointy head - ima get a polyhomedevice

one question though - from my reading - i can use the box with my existing isy?  sounds like eventually the isy functions will be moved to the home poly box - but i'd like others to deal with the birthing pains 

 

[stillwater]

Yes, my understanding is that for the last few years the primary use of the Polisy box was as an alternative to a Raspberry PI as a platform for running nodeservers, and that for now it can continue in that role as a co-processor for the ISY-994 series.  Soon of course many nodeservers may only be maintained on PG3 which will be only available on Polisy. 

The hardware in the Polisy will be more bullet-proof than the ISY (the SD card in the ISY is an occasional failure mode -- Polisy has a M2 SSD instead, I think), and the Polisy has more memory space and is faster.  I agree with you that for now the conservative path is to stick with ISY and use Polisy a a co-processor, but for folks who use node servers to control devices the faster speed of communication within the Polisy box compared to between Polisy and ISY using TLS may well be a motive for relatively early transition...   

[This is just my understanding --others know much better than I.]