Paradigm Shift
ericmedley
Posts: 4,177
I do not intend this discussion to be a rant or hat-on one AMX solution vs. another. Its intent is to focus on one over-arching aspect of how the two solutions (SVSi control programming vs. Netlinx programming) fundamentally operate.
After doing a few SVSi and JavaScript deployments I'm finding a rather difficult thing happening. That being the SVSi environment is not really designed to be a central controller. The best analog I can think of using Netlinx-think is:
Imagine you have a Netlinx system where you have several touch panels in several rooms; each with similar functionality but not identical. You then have to follow these rules: 1) only one TP can connect to one master. If your room has more than one UI - you must have a separate master for each one. 2) There is no such thing as Master-to-Master communication. 3) Each of these masters must talk to each other so that certain global/system-wide operations can happen and that gloabal/system-wide thing has to be able to communicate with all the masters in the system.
So, imagine in this environment that your client has required you to write code for X number of stand alone rooms that do the usual things. Both solutions are capable and do a fine job.
But, when the client then asks for things that touch all of the rooms at once (say like give me the ability to set up all the rooms in combined mode, or set up a room based upon how my current room is set up or power all my rooms down at a time I determine on the fly, etc...) You then have to create a whole framework that lives in each separate master and in whatever dark overlord master you plan on using to maintain a bi-directinoal communication to facilitate this. In normal Netlinx land this is already done for you and programming it is very easy.
What I'm finding in my so far limited exposure is that my clients still think very much in the global controller mindset. They are often surprised that the overhead to get an SVSi system to behave globally across the entire system is a bit of a bear and adds significant programming costs and so forth. In each case - when we got to the point of discussing how it's done, they have all said, "Well, why didn't I just do a Netlinx system?" or worse, "Heck, Extron/Control4 does that for much less cost"
Now before you all pounce on me - I am NOT saying the SVSi/JavaScript way cannot do this. I know it can. But, I think it's fair to say it just wasn't thought about in these terms. I know this since I took two trainings from SVSi before they were a gleam in AMX's eye. They just didn't ever really plan on it being more of a global, single-master type system. In fact, they mocked the idea of having a single point of code base.
In my world, this has consequences. My clients tend to be more large-scale than just making a single conference room or whatnot work. They tend to create much larger integrated systems that touch a lot of things and are more difficult to micro-manage. They tend to like things designed for more global approaches to management.
My experience so far has been to work on systems where SVSi stayed strictly in the AV Switching realm and the control side was Netlinx. They were easy to program at a high degree of Global design and very easily scaled up to very large sizes without a lot of code management at the micro level.
It is my feeling that this seemingly small issue is not being addressed by the sales folks at AMX as they are not interested in this discussion. I would encourage them to perhaps think about it as I've seen over this year as AMX has obviously tried to move us all over to this new platform that it is having a very negative effect on the brand.
The issues are:
1) The SVSi doesn't deliver the same kind of project management paradigm that has evolved over the years with the more Netlinx/Central Controller environment.
2) and as a result, integration companies are figuring out that trying to ram the SVSi based system into a slot it was just not really built for is causing deployment problems that are damaging the brand and already fragile reputation of AMX
3) and te fact that there are many other solutions out there that operate on a much more local level which do roughly the same thing at a much less expensive price range..
all do not make me very confident about this direction.
Once again - I am NOT saying it can't do this stuff. It's just not what it was built for. Yes, it is possible to haul hay in a helicopter. It can be done. It's just not a very good way to do it.
After doing a few SVSi and JavaScript deployments I'm finding a rather difficult thing happening. That being the SVSi environment is not really designed to be a central controller. The best analog I can think of using Netlinx-think is:
Imagine you have a Netlinx system where you have several touch panels in several rooms; each with similar functionality but not identical. You then have to follow these rules: 1) only one TP can connect to one master. If your room has more than one UI - you must have a separate master for each one. 2) There is no such thing as Master-to-Master communication. 3) Each of these masters must talk to each other so that certain global/system-wide operations can happen and that gloabal/system-wide thing has to be able to communicate with all the masters in the system.
So, imagine in this environment that your client has required you to write code for X number of stand alone rooms that do the usual things. Both solutions are capable and do a fine job.
But, when the client then asks for things that touch all of the rooms at once (say like give me the ability to set up all the rooms in combined mode, or set up a room based upon how my current room is set up or power all my rooms down at a time I determine on the fly, etc...) You then have to create a whole framework that lives in each separate master and in whatever dark overlord master you plan on using to maintain a bi-directinoal communication to facilitate this. In normal Netlinx land this is already done for you and programming it is very easy.
What I'm finding in my so far limited exposure is that my clients still think very much in the global controller mindset. They are often surprised that the overhead to get an SVSi system to behave globally across the entire system is a bit of a bear and adds significant programming costs and so forth. In each case - when we got to the point of discussing how it's done, they have all said, "Well, why didn't I just do a Netlinx system?" or worse, "Heck, Extron/Control4 does that for much less cost"
Now before you all pounce on me - I am NOT saying the SVSi/JavaScript way cannot do this. I know it can. But, I think it's fair to say it just wasn't thought about in these terms. I know this since I took two trainings from SVSi before they were a gleam in AMX's eye. They just didn't ever really plan on it being more of a global, single-master type system. In fact, they mocked the idea of having a single point of code base.
In my world, this has consequences. My clients tend to be more large-scale than just making a single conference room or whatnot work. They tend to create much larger integrated systems that touch a lot of things and are more difficult to micro-manage. They tend to like things designed for more global approaches to management.
My experience so far has been to work on systems where SVSi stayed strictly in the AV Switching realm and the control side was Netlinx. They were easy to program at a high degree of Global design and very easily scaled up to very large sizes without a lot of code management at the micro level.
It is my feeling that this seemingly small issue is not being addressed by the sales folks at AMX as they are not interested in this discussion. I would encourage them to perhaps think about it as I've seen over this year as AMX has obviously tried to move us all over to this new platform that it is having a very negative effect on the brand.
The issues are:
1) The SVSi doesn't deliver the same kind of project management paradigm that has evolved over the years with the more Netlinx/Central Controller environment.
2) and as a result, integration companies are figuring out that trying to ram the SVSi based system into a slot it was just not really built for is causing deployment problems that are damaging the brand and already fragile reputation of AMX
3) and te fact that there are many other solutions out there that operate on a much more local level which do roughly the same thing at a much less expensive price range..
all do not make me very confident about this direction.
Once again - I am NOT saying it can't do this stuff. It's just not what it was built for. Yes, it is possible to haul hay in a helicopter. It can be done. It's just not a very good way to do it.
0
Comments
I wish for a better way to update firmware in the units, too.
Check out MQTT as a possible alternative to the traditional central controller model.
This code will run on the N-Touch controllers with out issue.
https://cdnjs.cloudflare.com/ajax/libs/paho-mqtt/1.0.1/mqttws31.js
Both cloud and on-premise ($30 Raspberry Pi anyone?) servers are possible.
May even be possible to run a broker on the N-Touch itself but its Sunday and I've got some other stuff to do ;-)
Thanks Ian! I will check this out.
E