Page 4 of 9 FirstFirst 123456789 LastLast
Results 40 to 52 of 114
  1. #40
    Join Date
    Aug 2016
    Location
    Sacramento, CA
    Posts
    168
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by yorkie820 View Post
    Does this mean your customers' infrastructure is not future proof? I thought that was the intent and purpose for every client.
    Future proofing doesn't exist.

    Software will become obsolete long before the hardware expires. We need to be educating customers on how building automation parallels any other technological market. For example, I still have my old iPhone 3GS (Which was one of the best six or seven years ago) and it still fires up. I would never connect it to the internet though as the iOS is completely outdated and 3/4 of the apps won't work anymore.

    Software has a 3-4 year lifespan regardless of when the hardware expires.

    Quote Originally Posted by BetterDuck View Post
    If I have VAV boxes handling 4 million data entries per box and have a site that is your 75k sq.ft lets say its 150 boxes.

    This means that the controllers individually deliver close to 11k entries each * 150 = 1,644k points per day or 1.46B points per year. And, you initiate queries on all the data in a distributed fashion and work locally in each box constantly perform diagnostics 24/7. Do things like have the box report issues and even automatically withdraw input to a controller on the AHU. The AHU automatically adjusts. No more binding or client mapping required.

    I didn't buy any platform or service. I didn't get caught up in a proprietary structure-frame, the associated dealer fees and licensing.

    The opportunity to put the exact same program in other manufacturer devices supporting the standard.

    Plus all the controllers host the entire site graphic. Not bad 150x graphical redundancy in HTML5 as a bonus.

    And, if somebody wants to put additional things on top.... go ahead. The boxes are simultaneously multi-lingual.
    This isn’t really the definition of fault-diagnostics or smart data.

    I agree that you can put simple alarms in a VAV – High SAT, low room temp, low flow, etc. These alarms are useful to the end user but don’t really identify what, if any, hardware is actually failed.
    VAVs and other unitary controllers, as far as I know, are completely incapable of advanced fault diagnostics that drive real value to a non-technical end user. They simply allow for alarms that must be correlated and then evaluated by an engineering staff to reach an actionable conclusion.

    I think what you’re describing is more Demand Controlled Ventilation (DCV) which, when programmed in a unitary controller, is still limited in efficiency. Rarely do you see high level sequences for DCV written at the unitary level.

    It’s much easier to troubleshoot and tune DCV sequences when written in a supervisory controller versus unitary - Not to mention how many unitary programming languages are proprietary and require clients to spend atrocious amounts just to tweak programming!

  2. Likes yorkie820 liked this post.
  3. #41
    Join Date
    Aug 2016
    Location
    Maryland
    Posts
    4
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by orion242 View Post
    Little more than marking wank IMO. Just try and find a definition of IoT.

    We have been putting systems on the net for more than a decade, whats new with IoT?

    Sure they have all these ideas that big data is going to change everything, yet find one detailed case study showing they did something new (that couldn't be done previously) and had real ROI. You have one camp running around calling for more security on these systems and the IoT guys trying to get everything opened up to 3rd parties via the internet.

    All that aside, none of their promises can happen without crap loads of labor to put meaningful metadata on all the information so they can actually analyze it. How many systems are using haystacks or similar today? 0.1*10^-25% of all installed systems? We are using haystacks and looking at a few of these packages today, none I find all that impressive for the labor required and the upfront & reoccurring costs. Haystacks itself seems half baked. Start using it and you quickly notice they are missing tons of what should be pretty common tags. N4 has its own tagging system which almost nobody but Tridium's own analytics package uses. Multiple tagging systems should help the adoption rate...

    Will it be a fad like 3d TV or something with real legs? Who knows, but it certainly looks to be a long bumpy road littered with bull$hit & promises at the moment.
    I'm not sure about all the tags that are missing, because I haven't actually used haystack for an actual job yet, but digging down into the docs, it's clear they have a long way to go. But like you said, Rome wasn't built in a day!
    Last edited by bdh2; 08-29-2016 at 12:55 PM. Reason: forgot quote

  4. #42
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,309
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Use it and you will quickly find it lacking. HW/CW valves for starters, the list gets a mile long when you use it on a large system with complex control. The out of the box tag groups are really limited, which leaves you to by hand defining them. At that point, you don't know if its going to be used by a 3rd party correctly.

    Seems like most 3rd parties today that support the haystack protocol, all have their own tag dict. This is just another smoke screen for open protocol. Tag it all you want with Haystacks dict, everyone else has their own requiring a wad of labor to convert it to match.
    Propagating the formula. http://www.noagendashow.com/

  5. #43
    Join Date
    Aug 2016
    Location
    Maryland
    Posts
    4
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by orion242 View Post
    Use it and you will quickly find it lacking. HW/CW valves for starters, the list gets a mile long when you use it on a large system with complex control. The out of the box tag groups are really limited, which leaves you to by hand defining them. At that point, you don't know if its going to be used by a 3rd party correctly.

    Seems like most 3rd parties today that support the haystack protocol, all have their own tag dict. This is just another smoke screen for open protocol. Tag it all you want with Haystacks dict, everyone else has their own requiring a wad of labor to convert it to match.
    What 3rd parties are requiring custom dicts?
    I think haystack was made to be extendable so only the "core" is interoperable with added functionality on top. Maybe I'm wrong I'm far from an expert on it.

  6. #44
    Join Date
    Nov 2015
    Posts
    393
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by EnerDapt, Inc. View Post
    ...VAVs and other unitary controllers, as far as I know, are completely incapable of advanced fault diagnostics that drive real value to a non-technical end user. They simply allow for alarms that must be correlated and then evaluated by an engineering staff to reach an actionable conclusion.

    I think what you’re describing is more Demand Controlled Ventilation (DCV) which, when programmed in a unitary controller, is still limited in efficiency. Rarely do you see high level sequences for DCV written at the unitary level....
    You apparently are not aware of all VAV controllers. Particularly one which is completely capable of advanced fault diagnostics and distributed query instantiations. I've already described a scenario whereby a VAV notifies an associated AHU that it is not "feeling well" and pulls itself from submitting erroneous data.

  7. #45
    Join Date
    Aug 2016
    Location
    Maryland
    Posts
    4
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BetterDuck View Post
    You apparently are not aware of all VAV controllers. Particularly one which is completely capable of advanced fault diagnostics and distributed query instantiations. I've already described a scenario whereby a VAV notifies an associated AHU that it is not "feeling well" and pulls itself from submitting erroneous data.
    Which VAV controller is this?

  8. #46
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,309
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bdh2 View Post
    What 3rd parties are requiring custom dicts?
    I think haystack was made to be extendable so only the "core" is interoperable with added functionality on top. Maybe I'm wrong I'm far from an expert on it.
    Finstack will only use the default tags tridium adds to the points when using haystacks, all the rest end up having to be remapped. So it will grab the device, history, etc tags, but has no clue about setpoints, temps, etc when using the default haystack dict. They make it fairly easy, but I thought the idea behind haystack was to eliminate this BS.

    Skypark is another that I forget the exact details but it will not import the tags with the haystack connector without alot a dicking around or writing your own script within SP to import them.

    We evaluated another package, name escapes me, that was along the same lines of these two, uses the haystack protocol fine doesn't use their dict so you end up tagging everything in their environment.

    Does anyone actually connect up and import all the default haystack tags?
    Propagating the formula. http://www.noagendashow.com/

  9. #47
    Join Date
    Aug 2016
    Location
    Sacramento, CA
    Posts
    168
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BetterDuck View Post
    You apparently are not aware of all VAV controllers. Particularly one which is completely capable of advanced fault diagnostics and distributed query instantiations. I've already described a scenario whereby a VAV notifies an associated AHU that it is not "feeling well" and pulls itself from submitting erroneous data.
    Writing code into a VAV that it's malfunctioning is fairly simplistic (If room temperature deviates by setpoint more than a few degrees, airflow deviates from setpoint by more than 25% of design CFM or, under the new dual-max setpoint algorithm, SAT deviates from its setpoint by more than a few degrees a VAV could be classified as rogue). Once it deems itself faulted or rogue, it sends a signal to the air handler which ignores its requests for more air or a cooler SAT.

    We were doing that with Spyder VAVs although most of the reset code was written in the JACE, not the AHU. It was easier to manipulate and tune the reset logic in the JACE, which kept us from having to program 60 network inputs into every single AHU controller to read feedback from its associated VAVs.

    Manufacturers throw around the term "fault diagnostics" like they do IoT, big data and analytics - It's a little played out. I remember when a few graphical developers were using the term because their software could do simple mathematics in the browser.

    The above rogue algorithms that we talked about in the VAV could be considered fault diagnostics. It's useful information, but only tell you a component has failed at that time. Meaning it's simply an alarm, not a prediction.

    When you comb through four months of previous trends and correlate the valve position to other components of the VAV, you can predict how that valve will function - That's true fault diagnostics. Based on that deviation from that prediction we can determine if the valve is leaking, stuck, etc. - Long before it causes the SAT to deviate and ultimately inhibits operation of the VAV or forces it to become rogue.

    I worked for a manufacturer and we did a 3-month research project on current IoT VAVs and found that there are no unitary controllers performing true fault diagnostics. They've certainly gotten better at alarming based on design conditions, but that's reactive not proactive detection; More classifying it as an alarm not fault diagnostics..

  10. #48
    Join Date
    Nov 2015
    Posts
    393
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do some more research.

  11. #49
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,309
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why don't you save us the time? Links, links anyone.....a penny for your links??

    I'm with dapt. 80% of the faults could be detected onboard with minimal effort, the remaining need long term performance data and the CPU HP to do it. Unless the controller can do this @ the same cost of what you can today with commodity hardware and hardware IT fully understands, why would you?
    Propagating the formula. http://www.noagendashow.com/

  12. Likes refrige-nate liked this post.
  13. #50
    Join Date
    Dec 2006
    Posts
    249
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm guessing BetterDuck is referring to the LIOB-AIR and that BetterDuck is someone familiar to this forum. Just guessing.

  14. Likes crab master, davem liked this post.
  15. #51
    Join Date
    Jan 2003
    Location
    USA
    Posts
    5,309
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "DCV algorithms safe energy" Come with arc flash protection?

    This controller has everything on it, including the kitchen sink.

    So supports up to 8 AHUs per project. What happens with you have more?

    Is it UL listed? Anyone here have it installed on a project?
    Propagating the formula. http://www.noagendashow.com/

  16. #52
    Join Date
    Aug 2016
    Location
    Sacramento, CA
    Posts
    168
    Post Likes
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That Lloytec controller seems as sophisticated as most of the other IP controllers out there. But they don't allude to whether it's real historical-based fault detection or simply alarms like everyone else. Again, a stuck damper or failed valve can be found simply by looking at offsets between controlled variable and setpoint - All of which are still just alarms.

    What I'm really worried about in the IoT movement for between IP based controllers (Thanks BetterDuck for bringing it up) and analytics is, who’s going to support it all?

    Manufacturers all want a piece of the IP automation bubble, but there are a lot of hurdles to overcome - The biggest being the training of their vendors. I really don't think 80-90% of all automation companies have any idea of the risks they are exposing customers to or how to maintain the systems they’re installing.

    When you look at the evolution of a tech you see:

    Level: 1 - HVAC tech -> Controls tech
    Level: 2 - Controls tech -> Programmer
    Level: 3 - Programmer -> IT professional
    Level: 4 - IT professional -> Security analyst
    Level: 5 - Security analyst -> Statistics expert (Supporting/maintaining analytics)

    Most companies have Level: I techs with a few Level: II techs for more advanced programming. When you begin to venture into IP hardware, the Level: I techs must become Level: III and the Level: II programmers must become Level: 4 Security/IT professionals – Anything shy of this results in haphazard installations, major security concerns (150+ IP enabled hacker gateways into your building) and lackluster performance.

    Not to beat up any controls companies, but how many people on staff do you have that could setup a VLAN and secure it with the right firewall with customized rule sets? Think about it….

    And don’t think for a split-second that in-house, customer IT teams are remotely close to Level: 4 Security/IT professionals. You’ll be lucky if they can setup a VLAN to take the BMS off their primary network – More or less have any idea how to secure it. And it will be your company, not them, that takes the fall when the tenant network gets hacked and your face ends up on the cover of USA Weekly.

    Throwing analytics into the mix, you would need a Level: 5 programmer capable of understanding statistical analysis in order to troubleshoot and manage the algorithms. Otherwise all those fancy valve leak detections and damper failures become overpriced ghost alarms.

Page 4 of 9 FirstFirst 123456789 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Contracting Business
HPAC Engineering
EC&M
CONTRACTOR