upstatemike
Senior Member
How come all links to xPLHAL are failing? Other xPL related links seem to be OK but any efforts to get more info on xPLHAL end up on dead links.
Why is the Elk M1 so popular?
- Thread starter Stinger
- Start date
ronaldbeal
Member
>>"Ronald, why don't we develop a DMX-based home control system?
Unfortunately, as wide spread as DMX-512 is in the event lighting world, it is still an extremely limited protocol. The problem is DMX is based on a single output broadcasting model. The lighting console spits out 512 eight bit values, forty times a second. No return signals, (well technically DMX-512A with RDM does, but it's very new, and still limited. No multiple sources, etc...
The interesting note about DMX is it became the standard because a couple of propeller heads from 2 mfgs got together, created it, and put it on products. It was presented as an open standard and thus beat out AMX-192, D-192, C-192, VL S-200 (which was a FAR superior protocol,) NSI microplex, and the list goes on.
With the proliforation of computer networking technologies and ethernet, lighting mfgs started looking at ways to use ethernet as a backbone delivery system for DMX. This time a British company, Artistic License, released an open protocol with their hardware called "Art-Net" Art-Net is now almost the defacto standard, even though there are technically better protocols in existence, such as Pathport, and ETCnet2.
There are several lighting industry organanizations working on the next generation of lighting control protocols. ACN and SCP are the most prominent, however they seem to suffer feature bloat from too many chefs stirring the pot. ACN has been cooking for over seven years now, and they still want to add more features to it, before it is "released" Sheesh!
I just briefly looked at xPL... It seems like a step in the right direction, but has two major problems... I couldn't find any major vendor pushing it, and I'm not convinced that it's server/client relationship (almost requiring a PC 24/7 for the network to work) is a good thing.
Respectfully,
RB
Unfortunately, as wide spread as DMX-512 is in the event lighting world, it is still an extremely limited protocol. The problem is DMX is based on a single output broadcasting model. The lighting console spits out 512 eight bit values, forty times a second. No return signals, (well technically DMX-512A with RDM does, but it's very new, and still limited. No multiple sources, etc...
The interesting note about DMX is it became the standard because a couple of propeller heads from 2 mfgs got together, created it, and put it on products. It was presented as an open standard and thus beat out AMX-192, D-192, C-192, VL S-200 (which was a FAR superior protocol,) NSI microplex, and the list goes on.
With the proliforation of computer networking technologies and ethernet, lighting mfgs started looking at ways to use ethernet as a backbone delivery system for DMX. This time a British company, Artistic License, released an open protocol with their hardware called "Art-Net" Art-Net is now almost the defacto standard, even though there are technically better protocols in existence, such as Pathport, and ETCnet2.
There are several lighting industry organanizations working on the next generation of lighting control protocols. ACN and SCP are the most prominent, however they seem to suffer feature bloat from too many chefs stirring the pot. ACN has been cooking for over seven years now, and they still want to add more features to it, before it is "released" Sheesh!
I just briefly looked at xPL... It seems like a step in the right direction, but has two major problems... I couldn't find any major vendor pushing it, and I'm not convinced that it's server/client relationship (almost requiring a PC 24/7 for the network to work) is a good thing.
Respectfully,
RB
ronaldbeal
Member
>>"If I had to pick between everyone using the same protocol and keeping their current design, and everyone using a different protocol but have a design that actually works well with the automation system, then I'd pick the latter in a heartbeat."
I still think there is a third option... A new protocol that forces designers to implement their systems to work well with HA.
For the sake of discussion, lets assume CharmedQuark decides to develop a unified network protocol. We'll call it QuarkNet, (QN for short)
According to the Charmed Quark website, CQC does not currently have support for Insteon, UPB, and Zigbee. So CharmedQuark partners with Smarthome/Smartlabs to develop an Insteon to QuarkNet bridge.
Maybe a UBP mfg decides to get in on the act with a UPB to QN bridge so their stuff has a wider market. Suddenly, it is in the best interest of other developers to include QN support. We've reached critical mass.
So how does all this help make systems work well with HA? If I build an audio server that I want to interface with QN, my device must fall within the device model specifications. If the device model specs say my QN compatible device must respond to certain commands while in standby mode, and be responsive within 1 second of powerup, then it better meet those specs, or I'm not allowed to use the QN trademarks, etc...
Phillips did just that when record labels started to make out of spec "Red Book" audio CD's, in order to put copy protection schemes on the CD's Phillips established the Red Book spec, which defines how audio Compact Discs function. Phillips also owns the trademarks for the compact disc logo, and the CD and Compact Disk names. There is some other licensing involved, but for the most part the specs are fairly open. Once the record labels started hacking up the spec, Phillips won an injunction forbidding the labels from using the CD logo, names, and trademarks on any of those products. Copy protected audio disks can not be called CD's.
It would only take 2 or 3 key mfg's to get a protocol going enough to reach a critical mass. Once it is pervasive enough, any other mfgs that want to play ball, have to make their gear respond at least to a minimum standard.
This all supposes whether it should happen, not if it ever could happen in the current business climate ;-)
>>"Anyway, if you looked around out there now, and asked what technology probably is the closest to providing a standard backbone for automation systems, much as I hate to say it, it's probably Firewire. It's fast, it's a network, it was designed to be much more user friendly than ethernet,"
I like Firewire, and agree it is fast and user friendly. The downside is it is a peripheral sharing network. It is more of an appendage than a backbone. It requires a host/client relationship where the HA controller is the host and all other devices are the clients. The problem I see is a lot of HA systems could have multiple hosts and firewire fails miserably in multiple host networks. This is why I keep coming back to ethernet based systems... A peer to peer ability without a required central controller (but a central controller certianly is not excluded) seems more adapted to the very flexible requirements of HA.
Dean, ultimately, I think we actually agree on more issues than we disagree. (just those finnicky technical details ;-)
Respectfully
RB
I still think there is a third option... A new protocol that forces designers to implement their systems to work well with HA.
For the sake of discussion, lets assume CharmedQuark decides to develop a unified network protocol. We'll call it QuarkNet, (QN for short)
According to the Charmed Quark website, CQC does not currently have support for Insteon, UPB, and Zigbee. So CharmedQuark partners with Smarthome/Smartlabs to develop an Insteon to QuarkNet bridge.
Maybe a UBP mfg decides to get in on the act with a UPB to QN bridge so their stuff has a wider market. Suddenly, it is in the best interest of other developers to include QN support. We've reached critical mass.
So how does all this help make systems work well with HA? If I build an audio server that I want to interface with QN, my device must fall within the device model specifications. If the device model specs say my QN compatible device must respond to certain commands while in standby mode, and be responsive within 1 second of powerup, then it better meet those specs, or I'm not allowed to use the QN trademarks, etc...
Phillips did just that when record labels started to make out of spec "Red Book" audio CD's, in order to put copy protection schemes on the CD's Phillips established the Red Book spec, which defines how audio Compact Discs function. Phillips also owns the trademarks for the compact disc logo, and the CD and Compact Disk names. There is some other licensing involved, but for the most part the specs are fairly open. Once the record labels started hacking up the spec, Phillips won an injunction forbidding the labels from using the CD logo, names, and trademarks on any of those products. Copy protected audio disks can not be called CD's.
It would only take 2 or 3 key mfg's to get a protocol going enough to reach a critical mass. Once it is pervasive enough, any other mfgs that want to play ball, have to make their gear respond at least to a minimum standard.
This all supposes whether it should happen, not if it ever could happen in the current business climate ;-)
>>"Anyway, if you looked around out there now, and asked what technology probably is the closest to providing a standard backbone for automation systems, much as I hate to say it, it's probably Firewire. It's fast, it's a network, it was designed to be much more user friendly than ethernet,"
I like Firewire, and agree it is fast and user friendly. The downside is it is a peripheral sharing network. It is more of an appendage than a backbone. It requires a host/client relationship where the HA controller is the host and all other devices are the clients. The problem I see is a lot of HA systems could have multiple hosts and firewire fails miserably in multiple host networks. This is why I keep coming back to ethernet based systems... A peer to peer ability without a required central controller (but a central controller certianly is not excluded) seems more adapted to the very flexible requirements of HA.
Dean, ultimately, I think we actually agree on more issues than we disagree. (just those finnicky technical details ;-)
Respectfully
RB
Dean Roddey
Senior Member
That's the problem there... I agree with the idea, but no one has the oomph to push such a standard onto everyone. It'll take way more than a couple of companies using it. Plenty of companies will not use it just because they didn't invent it. Mostly, they'll just ignore it. There've been a number of such attempts to create these types of standards, and they just don't go anywhere because the market is way too broad ('automation' covers everything that could be automated, from lighting to sprinklers to A/V components to shades and so forth) to get any sort of consensus going.
And partly it's because, as we've both said, beyond just adopting the protocol, they must adapt to the protocol and meet certain standards that the protocol requires, such as consistently working in certain ways and exposing certain features. That's almost never going to happen. They'll build whatever they build and then they stick a serial port on it and provide a half working protocol, and that'll be that, because they often don't see automation as a key part of their market, just a small adjunct to it, not worth taking on any significant expense.
If you look at the breadth of companies you'd have to get to buy into such a thing, it would be Sony, Philips, Lutron, Aprilaire, Denon, Panasonic, Zen-Sys, Draper, and on and on. They are so disparate in their markets that they might as well be in different universes.
That's not to say it will never happen. I just don't expect it to happen in my lifetime, unfortunately. And that's not to say that people should push for it, since it won't happen any faster if people don't. But you should be prepared for a job that would make Sysiphus' look easy.
I'm not sure that ethernet is the best solution for the backbone in a broad acceptance of automation. It just wasn't designed to be self maintaining, and the danger of not failure of the network but failure of name resolution services, which will bring everything to a halt, is non-trivial in a system that can expect to receive little or no preventive maintenance by the customer, but which is constantly directly accessed and messed with the customer.
Maybe it requires a separate wired sub-net for the automaiton system or something like that, I don't know. But the single biggest problem we have is that the customer says X isn't working. We get the logs, and it's a name resolution problem, so client Y cannot find server Z. DNS and DHCP are moldy old technologies for the most part, designed for big machines managed by profesional people who know what they are doing and who do regular maintenance of the system.
I've had problems myself, where I removed a node from my Windows domain, but the DNS entry remained, and therefore machines referencing the old name didnt' get any errors (so that I see this and could fix them), but continued to reference this now out of date entry, which resolves to the same (fixed) address as the new machine that replaced it. Later on, I change the fixed address of this new machine, and now suddenly things stop working because the clients still trying to resolve that old name are getting a bogus address.
These types of things, to me, are why I think that a more dedicated network for the automation system would be optimal for a broad acceptance of automation into the homes of the great unwashed masses. And it's not just automaiton of course. Lots of devices are being networked, so everyone has a stake in getting this type of thing dealt with better. It's not as big a deal in the high end, where the customer always has a installer to call and get it fixed. But in the world where the only recourse of the customer is to call customer service in at Best Buy, they may die of old age before they get it fixed.
ronaldbeal
Member
>>"I agree with the idea, but no one has the oomph to push such a standard onto everyone. It'll take way more than a couple of companies using it. Plenty of companies will not use it just because they didn't invent it."
And there is the rub. I know it won't be something I see anytime soon. I do hope however that with the continued commoditization of networking gear, both wireless and wired, networks will be so pervasive that home electronics have no choice but to talk to all the other bits and peices. Maybe then it'll all work. (Hey, I can dream can't I!!!)
As for the viability of ethernet as a backbone, don't confuse the TCP/IP suite of protocols with ethernet. For the most part, ethernet just works when you plug it in. It's all the higher layer IP stuff such as DHCP, DNS, etc... , that many of the problems crop up. In professional event lighting, many of the propriatary backbone systems are ethernet, but NOT TCP/IP. Take a lighting control console, plug it into an ethernet network, plug some widgets in the other end that process data and output DMX protocol. Done. Nary an IP address touches the network. In even the largest touring concert lighting systems, the only time we have network problems is if someone creates a hardwired ethernet feedback loop. (We'll spend millions on curtains and scenery, but are too cheap to buy ethernet switches with STP to prevent loops!)
Respectfully,
RB
And there is the rub. I know it won't be something I see anytime soon. I do hope however that with the continued commoditization of networking gear, both wireless and wired, networks will be so pervasive that home electronics have no choice but to talk to all the other bits and peices. Maybe then it'll all work. (Hey, I can dream can't I!!!)
As for the viability of ethernet as a backbone, don't confuse the TCP/IP suite of protocols with ethernet. For the most part, ethernet just works when you plug it in. It's all the higher layer IP stuff such as DHCP, DNS, etc... , that many of the problems crop up. In professional event lighting, many of the propriatary backbone systems are ethernet, but NOT TCP/IP. Take a lighting control console, plug it into an ethernet network, plug some widgets in the other end that process data and output DMX protocol. Done. Nary an IP address touches the network. In even the largest touring concert lighting systems, the only time we have network problems is if someone creates a hardwired ethernet feedback loop. (We'll spend millions on curtains and scenery, but are too cheap to buy ethernet switches with STP to prevent loops!)
Respectfully,
RB
Dean Roddey
Senior Member
But wouldn't the coexistence of TCP/IP and non-TCP/IP protocols on the same wire effectively require that every computer on the network use a special card that encapsulates and passes through TCP/IP data so that all the PCs see it but the other devices don't? I.e. TCP/IP would have to be encapsulated within the lower level protocol packets, and that would mean either a special outboard box for each PC or a special PCI card.
AutomatedOutlet
Senior Member
Dean, I don't think you get out enough - lol
Dean Roddey
Senior Member
That's what's called stating the way beyond obvious 
Spanky
Senior Member
Wow what a thread!!
I agree with all the great ideas expressed. From a manufacturers point of view, the engineering effort to return on investment in the high end home automation controllers you are desiring is a losing proposition.
The M1 is an expensive security control and a low cost automation control. Where is the volume market that attracts manufacturers? In the security market where the installer can get recurring revenue for monitoring!!. The home automation market has not developed that recurring revenue path YET. When it does, everything will change.
All great ideas, especially SPANK.
I agree with all the great ideas expressed. From a manufacturers point of view, the engineering effort to return on investment in the high end home automation controllers you are desiring is a losing proposition.
The M1 is an expensive security control and a low cost automation control. Where is the volume market that attracts manufacturers? In the security market where the installer can get recurring revenue for monitoring!!. The home automation market has not developed that recurring revenue path YET. When it does, everything will change.
All great ideas, especially SPANK.
ronaldbeal
Member
>>"But wouldn't the coexistence of TCP/IP and non-TCP/IP protocols on the same wire effectively require that every computer on the network use a special card that encapsulates and passes through TCP/IP data so that all the PCs see it but the other devices don't?"
Not at all. In fact most networks have a fair ammount of low level non IP traffic, that is completely transparent to the user. STP, QOS, ARP, NetBios, etc. Even DHCP starts out as non-IP. IP is really just an abstraction layer that patches an arbitrairly assigned IP address to an actual physical MAC address/location.
Practically all ethernet hubs, switches and routers will pass non-IP traffic, (unless you intentionally firewall it or otherwise manage it.)
Think of it like this: ethernet MAC addresses are like latitude and longitude. Every address is unique, and absolute. IP addresses are more like street addresses. Arbitrairly assigned, different for every network etc... 123 Mainstreet in one city is a different location from 123 Mainstreet in another city.
If an ethernet device does not have an IP address, then no router or switch will send IP traffic to it, but other ethernet traffic will still flow. Likewise if a device (IP or not) sees data it dosn't understand, it just gets ignored.
In order for a PC to see non-IP traffic (such as my therotical QuarkNet or SPANK) it just needs a network socket, defining the traffic to look for.
A real world example:
For concert lighting there is a control console called the Virtuoso. http://www.prg.com/products/virtuoso
The Virtuoso has nodes and NIFs (network interfaces), both of which are devices that store and process data, and output other lighting control protocols.
The Virtuoso talks to these devices through its own special protocol over ethernet.
Nothing uses IP addresses.
You can use the network for other tasks as well, such as plugging in two laptops to play a head to head networked videogame using TCP/IP. (other than a bandwith performance hit from too much traffic, the 2 systems on 1 network will be invisible to each other.)
Then I can use one of those gaming laptops to launch the Virtuoso Visionary software application. This application looks for Virtuoso protocol on the network... and when it sees it, starts talking to the Virtuoso devices and consoles, again regardless of IP addresses
It's all just different traffic on the same streets, and sometimes using different styles of maps ;-)
Cheers
Respectfully,
RB
Not at all. In fact most networks have a fair ammount of low level non IP traffic, that is completely transparent to the user. STP, QOS, ARP, NetBios, etc. Even DHCP starts out as non-IP. IP is really just an abstraction layer that patches an arbitrairly assigned IP address to an actual physical MAC address/location.
Practically all ethernet hubs, switches and routers will pass non-IP traffic, (unless you intentionally firewall it or otherwise manage it.)
Think of it like this: ethernet MAC addresses are like latitude and longitude. Every address is unique, and absolute. IP addresses are more like street addresses. Arbitrairly assigned, different for every network etc... 123 Mainstreet in one city is a different location from 123 Mainstreet in another city.
If an ethernet device does not have an IP address, then no router or switch will send IP traffic to it, but other ethernet traffic will still flow. Likewise if a device (IP or not) sees data it dosn't understand, it just gets ignored.
In order for a PC to see non-IP traffic (such as my therotical QuarkNet or SPANK) it just needs a network socket, defining the traffic to look for.
A real world example:
For concert lighting there is a control console called the Virtuoso. http://www.prg.com/products/virtuoso
The Virtuoso has nodes and NIFs (network interfaces), both of which are devices that store and process data, and output other lighting control protocols.
The Virtuoso talks to these devices through its own special protocol over ethernet.
Nothing uses IP addresses.
You can use the network for other tasks as well, such as plugging in two laptops to play a head to head networked videogame using TCP/IP. (other than a bandwith performance hit from too much traffic, the 2 systems on 1 network will be invisible to each other.)
Then I can use one of those gaming laptops to launch the Virtuoso Visionary software application. This application looks for Virtuoso protocol on the network... and when it sees it, starts talking to the Virtuoso devices and consoles, again regardless of IP addresses
It's all just different traffic on the same streets, and sometimes using different styles of maps ;-)
Cheers
Respectfully,
RB
upstatemike
Senior Member
After reading through this thread I have to agree that the "golden age" of the dedicated hardware HA controller has passed and we will probably never again see manufacturers invest in Stargate or Homevision like products. Addicon will probably never develop an Ocelot Mk2.
In the super security panel arena, ELK and HAI will likely continue to prosper with the outstanding added value of basic automation functions but the twin realities of firmware space and market demand will forever keep them from replacing the HA "Programmable Logic Controllers" of old.
The PC based HA controller is perhaps the best bet for the future but only if you are interested in developing deep scripting and programming skills. Market forces again come into play making it profitable to build a general automation framework but not the sort of point and click GUI you will find on the super security panels. If you can't become proficient in the syntax of one or more scripting platforms you will be forever shut out of any but the most basic of Home Automation options. The age of the hardware tinkerer that is proficient in the ladder logic of home automation (but not the underlying programming language) is dead.
Even for the programmer, the future of HA may be restricted. Most PC controllers fail to come anywhere close to directly supporting the variety of inputs and devices that hardware controllers did. Instead they depend on those same hardware controllers to be subsystems that "pre-process" their connections to the outside world. Instead of overcoming the firmware limits attributed to hardware controllers they depend on those controllers for their inputs and agree to be bound by those same firmware restrictions. No PC based system can act on information it does not get nor provide features that a hardware subsytem manufacturer has decided not to support or provide access to.
Of course if you can't directly connect your low level input sensors and devices, it also means you will never again have a central point of configuration and management for your system. You will have to configure each subsystem individually using an ElkRP, or C-MAX, or whatever and you will have to be satisfied with the limits of what each individual company decides you should want to do.
In the super security panel arena, ELK and HAI will likely continue to prosper with the outstanding added value of basic automation functions but the twin realities of firmware space and market demand will forever keep them from replacing the HA "Programmable Logic Controllers" of old.
The PC based HA controller is perhaps the best bet for the future but only if you are interested in developing deep scripting and programming skills. Market forces again come into play making it profitable to build a general automation framework but not the sort of point and click GUI you will find on the super security panels. If you can't become proficient in the syntax of one or more scripting platforms you will be forever shut out of any but the most basic of Home Automation options. The age of the hardware tinkerer that is proficient in the ladder logic of home automation (but not the underlying programming language) is dead.
Even for the programmer, the future of HA may be restricted. Most PC controllers fail to come anywhere close to directly supporting the variety of inputs and devices that hardware controllers did. Instead they depend on those same hardware controllers to be subsystems that "pre-process" their connections to the outside world. Instead of overcoming the firmware limits attributed to hardware controllers they depend on those controllers for their inputs and agree to be bound by those same firmware restrictions. No PC based system can act on information it does not get nor provide features that a hardware subsytem manufacturer has decided not to support or provide access to.
Of course if you can't directly connect your low level input sensors and devices, it also means you will never again have a central point of configuration and management for your system. You will have to configure each subsystem individually using an ElkRP, or C-MAX, or whatever and you will have to be satisfied with the limits of what each individual company decides you should want to do.
upstatemike said:
That is a popular misconception. Just because the PC platform is more programmable and standard than a hardware platform does not mean that you have to have programming skills to use it. The fact is, it is quite the opposite - because it is more (standards based) programmable, the user interface is designed to provide a richer, more powerful set of automation capabilities without scripting or programming. I believe (but am not absolutely sure without checking) that everything HomeSeer offers except for working with Internet content is available via the point and click device and event interface pages. Events are created, triggers (what causes the event to run) are assigned, conditions (things to check before actually executing the event) are added, and then actions are added all with a point and click interface.
The programmability of the system is what DOES allow for the open APIs and other tools so that people who ARE capable of programming can write and offer (if they so desire) custom applications, hardware/software interfaces, or user interfaces for the system.
We have probably thousands of users integrating disparate systems together to create fully automated homes who have never written a single line of code or script. The programmability and scripting is a FEATURE, not a requirement.
upstatemike
Senior Member
I guess I am missing something then. I recall the very first thing I ever tried to do with Homeseer was to have it speak a TTS phrase that contained a variable value. I did not see any way to do that without writing a script. Maybe that changed in later versions?Tink said:
AutomatedOutlet
Senior Member
Tink,
I couldn't agree with you more - I'm one of them
Mike, I concur with Tink. PC based HA CAN make command building easier due to the additional GUI / Logic / hardware resources available. But, with the PC Capability also gets thrown into the mix and complicates the simple command builiding. As things get more configurable, up goes the difficulty in setup. With MainLobby Server 3's new Command Builder, things get much easier for MainLobby customers then the manual build your own method used previously. Much closer to the embedded controller type programming style.
Similar threads
