Page 5 of 6 FirstFirst 123456 LastLast
Results 53 to 65 of 66

Thread: LON Question

  1. #53
    Join Date
    Mar 2005
    Posts
    39
    My point is this:

    Its going to cost $20,000 to $30,000 to develop a product (done it several times). UL is requirement to sell any product in volume in the USA

    Saving $3000 on the price of a compiler (a crippled one at that) is not going to make much difference in the long run.

    The Neuron and FT-10 tranceiver are the most expensive parts on the board, and the combination is much more expensive than comparable alternatives - Echelon has to maintain its 60% gross margins somehow.

  2. #54
    Join Date
    May 2002
    Posts
    9,564
    You got to get your product developed elsewhere. My last one was 13,500.00

    ....ouch for you.

    And, UL is not the only standards organization for the US. Drives me insane that everybody assumes God-status with stinking UL. Use somebody else.

  3. #55
    Join Date
    Mar 2005
    Posts
    39
    I think you are really glossing over the realities of developing high volume products.

    If you can develop products that cheaply, why bother buying products from LonWorks manufacturers?

    For less than $100,000 you could have your set of controllers (and start your own line of controls) for the following applications:

    VAV
    Rooftop
    FanCoil
    UnitVent
    Heatpump
    Programmable
    Lighting

  4. #56
    Join Date
    Jun 2003
    Location
    Jacksonville, FL.
    Posts
    4,313

    Re: Re: Okay....

    Originally posted by sysint
    Originally posted by special ed
    Sysint:

    I'm still trying to wrap my feeble mind around all this LON stuff, & I still don't think I'm grasping it. Maybe because I work primarily on resi equipment & not commercial. Also, it sounds eerily a lot like we're talking about computer networks & not anything to do with HVAC. Tell me: Why would I install a LON network on a resi system?
    The cost is coming way down on LON systems. The neat thing about LON is that you don't necessarily need a computer, or you just need it one time to configure the devices. A computer is not necessary in the day to day operations of Lonworks.

    Samsung HomeVita is Lonworks.
    Merloni Appliances have Lonworks. (powerline -PLT)
    (I'm missing many)
    See Mini-EVK at http://www.echelon.com

    Special... You should read "about Lonworks" at http://www.grahamcontrols.com It is a nice explanation of Lonworks and what makes it a good communication choice for devices.

    Why install LON in residential? - At the moment unless it's a larger place, hold off. The new Mini-EVK development tool (I think it's $350) will have everyone making LON light switches, doors, thermostats, etc... (home type devices) cheap. You could have multiple manufacturers light switches and not worry whether or not you can group them together. Or easily turn on the lights when there is a break-in to the place. Or, like in Italy where power is expensive.... turn off the dishwasher during peak or get warning or notification of it's failure.

    Think about it.. the device could be anything, communicate on PLT, twisted wire, RF, whatever and talk to the other devices.

    I would also read up on Moore's law or other books on the benefits of networking.

    ..feeble mind? Right. You are smart enough to ask about it in the first place. All you need is a little research.



    Sysint & Osiyo,

    Thanks for the info, I'll have to look that stuff up.

    Oh, & Sysint, I think F.E. has been banned from this site for life.

  5. #57
    Join Date
    May 2002
    Posts
    9,564
    Originally posted by keyser_soze
    I think you are really glossing over the realities of developing high volume products.

    If you can develop products that cheaply, why bother buying products from LonWorks manufacturers?

    For less than $100,000 you could have your set of controllers (and start your own line of controls) for the following applications:

    VAV
    Rooftop
    FanCoil
    UnitVent
    Heatpump
    Programmable
    Lighting
    How much do you think Distech spent?

  6. #58
    Join Date
    Mar 2005
    Posts
    39
    Probably a lot more than $100,000.

    You would have to ask Etienne - but I doubt he will tell you.

  7. #59
    Join Date
    May 2002
    Posts
    9,564
    Keyser, I understand where you may have some bitterness.

    The facts remain that LON does what BACnet doesn't, hasn't, and probably will never.

    It also makes product development easier. Look at how many years companies like Trane have had comm problems..... then along comes Lonworks and things have gotten much easier.

    Critical mass and then the price starts to fall.

    Anyway, you can always develop your own "chip" like Loytec did. You could even sell it for less than the alleged 60% markup.

  8. #60
    Join Date
    Mar 2005
    Posts
    39
    Ok, 60% might have been an exaggeration, it is actually 56.4%.

    http://www.echelon.com/about/press/Q42004EarnRel.htm

    ......Gross margin for the quarter ended December 31, 2004 was 56.4% compared to 55.4% for the same period in 2003. Gross margin for the year ended December 31, 2004 was 56.2% compared to 55.9% for the year ended December 31, 2003.......


  9. #61
    Join Date
    Feb 2005
    Posts
    345
    With respect Keyser, 55% GM isn't huge in the technology game, but it depends largely on how you calculate GM. Take Microsoft for example. The cost of producing a copy of Windows is probably in the $3.00 region yet it sells for what? $150. That's a theoretical GM of 4000% but we know instinctively that's not true. Take an apple grower. His paper GM is probably in the several hundred % area, but how many rich apple farmers do you know? It's net margin that counts and even that can't be directly associated to profit. After GM comes the "cost of doing business"..and for a tech company who's selling worldwide, that can add up fast.

    I'd far prefer Echelon make a profit while enabling many other technology providers to also be profitable, than to have Echelon not make money... Them having money (Gross Margin) means they keep rolling it back into technology and you, and I, and many others stand to be better off because of it.

    I'd also far rather use and sell the technology of a company driven by profit than the technology driven by the consensus of a committee of self-serving grandfather companies. At least they have a reason to exist.

    I'm not defending Echelon, nor am I trying to accurately quantify their numbers, but I am saying that associating profit, and my all indications in your note you feel an unfair profit, to GM isn't black and white. But every company is in business to make money...they're not here to make you or I feel good about ourselves.

    Nikko

  10. #62
    Join Date
    May 2002
    Posts
    9,564
    Originally posted by keyser_soze
    Ok, 60% might have been an exaggeration, it is actually 56.4%. ......Gross margin for the quarter ended December 31, 2004 was 56.4% compared to 55.4% for the same period in 2003. Gross margin for the year ended December 31, 2004 was 56.2% compared to 55.9% for the year ended December 31, 2003.......
    Is that a problem for you? Instead of being bothered by the extra cost per controller why aren't you going after the BACnetter lying companies that promote being like Lonworks and not delivering? Apparently open involves profits that the BACnetter companies aren't willing to let go to the customer or the Integrator. They would rather lie about open, and bamboozle ASHRAE engineers who aren't taking the time to investigate. They are the ones trying to take the industry hostage. Thank you to the Army Corp of Engineers.

    Getting relative for the subject, Echelon also has developed this ilon100 which is the least expensive $/point web server on the market. The next closest server is 3x the cost. So, that 56% GM (thanks Nikko) works out in my favor and helps protect my GM. It also helps my customer who gets a nice protocol that is open.

    I guess the extra hardware cost for that box wasn't so bad. Why is that do you think?





  11. #63
    Join Date
    Apr 2005
    Posts
    5

    Wink

    There appears to be a misconception about LON and BACnet. Having sat on both committees for several years you can draw a conclusion that neither alone contains all of the features required for creating a seemless solution. There are many instances that either one or both are required to fulfill the customers requirements but more importantly, work. Regardless if you are choosing BACnet or LON devices for an installation, the initial configuration of the device is still proprietary to the manufacturer. Several attempts have been made to circumvent this in the marketplace by creating additional software nuisances such as LNS Plug-Ins. Some basic concepts need to be taken into account and understood when choosing the appropriate control hardware. I'll refer to these as the HVAC-BIG 3:

    ALARMING - BACnet has addressed the issue of reporting alarms with the system's client through object types and services. LON is in the process of defining some standarized mechanisms and once refined, manufacturers will probably move towards implementation.

    SCHEDULING - Once again BACnet has clearly defined the object types and services required to perform this function between a multi vendor platform. This goes beyond the fact that a particular device supports a schedule but defines how to create/modify/delete the schedule within the other manufacturers device without any special propritary software (i.e LNS Plug-Ins).

    TRENDING - There are several devices both within the LON and BACnet bandwagon that have the capability of trending and reporting information. In BACnet, the creation and harvesting of this data is defined whereas it is not within LON.

    So when does LON excel where BACnet does needs some work? Profiles. When a manufacturer implements a LonMark profile, there is reassuracne that a certain amount of information will be available within a device. Although the BACnet Committee Application Working group is defining an equivalent concept, it will take some time to be voted in. Currently it is up the the various manufacturers of BACnet devices to define what they want to share. There is another important consideration when choosing between LON and BACnet. Networking! From my observations within the industry, connecting devices from multi vendors onto a network of any sorts has been a dubious task. BACnet probably has the upper hand here because they choose to reuse pre-existing industry standards (EIA232, Ethernet, Arcnet, IP). This makes BACnet idea to move large amounts of data very fast 10/100 MB while making it very easy to network. MS/TP although created new for BACnet and has a mysterious element, still uses EIA485. The biggest concern that LON system integrators have voiced is the networking of LON devices upon a twisted pair network (subnet). Many difficulties are getting the devices talking at this level but once achieved, LON does tunnel into IP very well.
    Hope this commentary helps those who approach integration with skepticism. Work with what is available today while paying close attention to what is around the corner. (XML, SOAP, Zigbee, etc).



  12. #64
    Join Date
    Sep 2004
    Location
    SoCal
    Posts
    446
    Sys2 it's obvious that you're a BACnet spin doctor with little practical experience using LonWorks. I'd like to ask you a simple question. How many BACnet installations exist where field devices from multiple manufacturers communicate directly with each other without the need for gateways or network controllers AND the integrator utilized one network management platform to program, commission, and maintain the network? Get a clue Sys2.
    lb
    A hundred million nodes - it's a LON story.

  13. #65
    Join Date
    Feb 2005
    Posts
    345
    Sysint2:

    Thanks for your post. It’s most interesting. While there’s credibility to much of what you write, there are also portions which need further clarification.

    You state:
    There appears to be a misconception about LON and BACnet. Having sat on both committees for several years you can draw a conclusion that neither alone contains all of the features required for creating a seamless solution. There are many instances that either one or both are required to fulfill the customers requirements but more importantly, work.

    Here’s where we’ll disagree for the first time. LON was developed from the bottom up and has been masterfully adapted at accomplishing what needs to be done at the device level as well as being deployed across vast enterprise systems with ease and low cost.

    BACnet on the other hand has been designed from the top down and while BACnet does a reasonable job at the enterprise level, it’s like trying to stuff a pickled egg through a straw when it comes to functioning at the device level. It’s just not designed to go there efficiently. In other words, BACnet may need LON to put forth a well-rounded system, but LON does not need BACnet in any shape or form to fulfill actual performance requirements. It’s more than capable of standing on it’s own.

    I’m also curious if you “sat” on the committees or if you participated. By the sounds of things, you could be an asset if you chose to get involved.

    Regardless if you are choosing BACnet or LON devices for an installation, the initial configuration of the device is still proprietary to the manufacturer. Several attempts have been made to circumvent this in the marketplace by creating additional software nuisances such as LNS Plug-Ins.

    I have to say, this is a first. I have never once heard anyone speak of an LNS plug-in as a “software nuisance”. Come to think of it, I’ve never heard anyone claim that a LNS plug-in is proprietary either. Let’s deal with that one first. To quote from Dictionary.com:

    Proprietary:
    “In the language of hackers and users, inferior; implies a product not conforming open systems, standards, and thus one that puts the customer at the mercy of a vendor who can inflate service and upgrade charges after the initial sale has locked the customer in”.

    To deal with the issue of “open systems, standards”, I remind you that these plug-ins are based on ANSI/EIA 709.1; an open standard. To deal with the rest, may I direct your attention to:

    http://www.echelon.com/products/inte...in/default.asp

    Where you will find 278 LNS plug-ins listed. I’ve listed the one-stop-shop web site but lest you go down the path of “You have to go to Echelon to get these”, let me assure you that you can go to all the individual web sites of all the named companies and retrieve the software from them directly. I’ve simply listed the single point where all can be found for the purposes of convenience.

    I’m not sure of your definition of “several”, but I’m betting 278 exceeds it and I’m not sure of your definition of “attempts”, but these plug-ins are completed and tested and released products. I doubt much their creators would call them “attempts”.

    The majority of these plug-ins listed are available for free download; which contraries the opinion that there are upgrade charges etc. I could be wrong, but I’m not aware of a parallel to this concept in BACnet. If I am mistaken, please correct me.

    This is not to say that individual companies don’t write their own plug-ins, they do. And in order to continue product growth, I hope they continue to develop and further their product. Plug-ins are a valuable and mostly free tool that enable a set of manufacture agnostic network tools to configure a device with no need for an expensive toolset that’s historically been the norm in our industry. If you call that a nuisance, may I suggest you re-visit your terms of reference.

    Some basic concepts need to be taken into account and understood when choosing the appropriate control hardware. I'll refer to these as the HVAC-BIG 3:

    ALARMING - BACnet has addressed the issue of reporting alarms with the system's client through object types and services. LON is in the process of defining some standarized mechanisms and once refined, manufacturers will probably move towards implementation.


    Agreed and well stated.

    SCHEDULING - Once again BACnet has clearly defined the object types and services required to perform this function between a multi vendor platform. This goes beyond the fact that a particular device supports a schedule but defines how to create/modify/delete the schedule within the other manufacturers device without any special proprietary software (i.e LNS Plug-Ins).

    Partially agree. LonMark International released the Scheduler profile some time ago and it can be viewed at:

    http://www.lonmark.org/profiles/0007_10.PDF

    What’s interesting about the LonMark profile is that it can be implemented in each individual device (VAV box, heat pump, access controller etc) if desired, or it can reside in a scheduling node. This is critical to maintain the fully distributed architecture that prevents single point of failure. I believe that BACnet’s method of scheduling is “top device” dependant meaning it relies on active communication between the device that holds the schedule and the device that’s being told what to do. This was done to facilitate the top down approach of using a common scheduling tool to provide machine-to-machine instructions to a variety of proprietary manufacturers head-ends or “master controllers”. These instructions are then interpreted by those controllers and fed to their slave controllers. Interesting but extremely cumbersome method of doing things.

    TRENDING - There are several devices both within the LON and BACnet bandwagon that have the capability of trending and reporting information. In BACnet, the creation and harvesting of this data is defined whereas it is not within LON.

    Partially agree. There are a myriad of LON based product on the market today that accomplish this and in fact every company that’s competitive has trending. LonMark International has just placed a datalogger profile out for review and acceptance voting. It should be sanctioned within a couple of weeks. Upon acceptance there will be a LonMark standard (profile) to which any manufacturer can build product. If history is any indication, several manufacturers will release actual product based on this profile in a very short period of time. But that’s the way it works with truly Open Systems.

    These three areas (Alarming, scheduling and trending) have been traditional areas where the LON community has chosen to not jump the gun, to do research and to develop profiles that truly fit the multi-discipline platform that’s represented by LonMark approved product. In doing so, the LON community has taken a bashing from the BACnet community as this was the one area where BACnet could claim completion and LON was “catching up”. That’s either changed or changing and in the foreseeable future, the remainder of these points will be moot. You may want to start researching a new BACnet argument.

    So when does LON excel where BACnet does needs some work? Profiles. When a manufacturer implements a LonMark profile, there is reassuracne that a certain amount of information will be available within a device.

    Again, well stated. Except your term “a certain amount of”: should be replaced as “enough”.

    Although the BACnet Committee Application Working group is defining an equivalent concept,

    (borrowing heavily from LonMark…which is a good thing!)

    it will take some time to be voted in. Currently it is up the the various manufacturers of BACnet devices to define what they want to share.

    Well put and in fact to quote one of the BTL testers as published in a recent public email string:

    “The BTL (BACnet testing Lab) tested building controllers (soon to be released) are not required to conform to the building controller profile and interoperability should not be assumed for the full range of B-BC functionality. I would refer you to the fine print however there is none. The BTL only makes public an overview of information that was tested and is not permitted to publicly display the many caveats a device may have which may hurt interoperability. Devices that pass through the BTL are forced to be fairly decent quality (functionally speaking) but the documentation provided to end users is not enough to decide whether a device is interoperable or not. There are pushes to make the BTL testing and listing more balanced however as it is there are no end users sitting in the BTL working group probably because manufacturers currently rule and pay for the BTL quality assurance lab.

    In other words, interoperability with BACnet is a crapshoot and will be for some time to come. Further, the actual people (BTL) who are aware of products shortcomings are forbidden to speak of it. That doesn’t sound very open to me.

    There is another important consideration when choosing between LON and BACnet. Networking! From my observations within the industry, connecting devices from multi vendors onto a network of any sorts has been a dubious task.

    Bullhockey!! At the AHR tradeshow this year a well-known LON vendor displayed over 30 products from over 20 unique vendors on a single network coming back into multiple front-ends. Think about this for a minute!.. That’s a lot of interoperability! This display, which contained product from their competitors, was displayed front and center in their booth and any one was not only allowed, they were encouraged to take it for a test drive. It worked…and many vendors who had product on the display brought their own customers over to show it off.

    I personally have successfully integrated product from many manufacturers on a single network and have down so without so much as a sneeze. I’ve done this many times and each time has been in a paying network, not in a lab environment. Your credibility will wear thin if you continue down this path.

    BACnet probably has the upper hand here because they choose to reuse pre-existing industry standards (EIA232, Ethernet, Arcnet, IP).

    The reason BACnet supports these arcane and largely defunct standards (Ethernet and IP aside) is because that’s what the proprietary vendors who choose to claim “Open” through their association with BACnet choose to use. Arcnet? How old is that? EIA232 is an excuse, not a protocol. It’s a means of stuffing tiny amounts of data through an even tinier wire over a short distance. It can be useful in engineering backwards, but no decent engineer will design forwards with the stuff unless there are no other options available.

    This makes BACnet idea to move large amounts of data very fast 10/100 MB while making it very easy to network.

    Agreed. BACnet is very good at this and LonTalk is not designed to accomplish this. But let’s look at that for a minute. Exactly why would you be transporting large amounts of data over a BAS network in the first place? The only reason you would be is if you had a system that employed central controllers or controlling front-ends. If this is the case, each central controller has to ride over its associated slaves. This architecture is archaic. It’s old, and generally not accepted and once again, the companies that employ it are usually the same companies that are converting any BACnet messages into their own protocol meaning they’re not truly Open to begin with. The only time this ability to move large amounts of data across a network is if the network has been designed with single points of failure. This isn’t the way to do things correctly…. unless you’re charging vast amounts on $$ for those master controllers and no competing company can change them out or compete for the business.

    Distributed architecture makes much more economical sense for a DDC network and having each controller capable of performing it’s own sequence of operations, of handling it’s own scheduling, alarming and trending negates the need for these costly master controllers and makes for a far more robust network. It also does away with the requirement for a fast, high volume network (while it can still use it if it’s there and available). Your point become rhetorical when placed against solid, forward looking engineering. Why pay for a 14” water main when a simple 1” copper pipe is more than enough to do the job?

    MS/TP although created new for BACnet and has a mysterious element, still uses EIA485. The biggest concern that LON system integrators have voiced is the networking of LON devices upon a twisted pair network (subnet). Many difficulties are getting the devices talking at this level

    I’m really not sure what you mean here. Can you please explain it in greater detail? The networking of LON devices is simple and the architecture completely repeatable and scalable. This is a non-issue.

    but once achieved, LON does tunnel into IP very well.

    Agreed

    Hope this commentary helps those who approach integration with skepticism. Work with what is available today while paying close attention to what is around the corner. (XML, SOAP, Zigbee, etc).

    Once again, I agree. While I don’t think Zigbee is going to live up to it’s billing, I do think XML and SOAP are tools that we’ll be seeing more and more as they’re incorporated into the BAS world. oBIX is doing some really good work along these lines, towards the creation of higher-level open standards that will allow those who choose to, to accept and deliver information to a myriad of other DDC and control systems, and to higher level Enterprise level systems (ERP, MRP etc.). It’s a shame BACnet has withdrawn from this venture…. but I’m not surprised. oBIX is yet another truly Open Standard and when BACnet realized they’d have to peel back their own covers a bit if they wanted to play, they chose not to and instead, have elected to continue down the “we’re open because we say so, but we can’t prove it, and you’ll just have to believe us” path.

    Nikko

    [Edited by nikko on 04-12-2005 at 03:06 PM]

Page 5 of 6 FirstFirst 123456 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comfortech Show Promo Image

Related Forums

Plumbing Talks | Contractor Magazine
Forums | Electrical Construction & Maintenance (EC&M) Magazine
Comfortech365 Virtual Event