Page 2 of 2 FirstFirst 12
Results 14 to 26 of 26
  1. #14
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by control$ View Post
    I guess this data would be for the ddc impaired individual? Suit's and bean counters maybe...
    I understand your point of view. There are more car parts breaking in a day then we have accidents as well as more cars running inefficiently due to lack of maintenance. So issues can be outside of the DDC and the physical problems as well. Or it could be regional too. For example Austin Texas is notorious about cedar pollen, I am sure it is effecting the air filters on cars more so than other cities.

    It checks the data for you. Your knowledge is passed into the axon function and while you are sleeping, computer is doing the check for you. When you wake up, if it reports an anamoly you would know to pick up an air filter on the service truck for that car. In our business, it would be valve, damper, actuator, fan belt, etc before leaving the office.

    We are essentially highly impared when it comes down to the sheer amount of volume of data. I would make another joke here about amount of data (listening to someone) but I should not on public forum.

  2. #15
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    1,602
    Post Likes
    Thread Starter
    Quote Originally Posted by control$ View Post
    I guess this data would be for the ddc impaired individual? Suit's and bean counters maybe...
    I heard the example that Analytics can compare the DAT at the AHU to the DAT at the VAV, of the reheat is closed, but you have a temp rise, it may alert you that the vav reheat valve is leaking by.
    Probably could also calculate a btu based on CFM at the box and slap a dollar amount on it... to justify the valve replacement expense.
    So good for the guy babysitting the facility, as it catches things I have no interest in checking, while also justifying the repairs in a language bean counters understand.
    But it is only what I heard. I have no first hand experience
    Hmmmm....smells like numbatwo to me.

  3. #16
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    I heard the example that Analytics can compare the DAT at the AHU to the DAT at the VAV, of the reheat is closed, but you have a temp rise, it may alert you that the vav reheat valve is leaking by.
    Whoever explained it explained it very well and you have listened well for sure. Think of having this on a distributed model within each controller.

  4. #17
    Join Date
    Jan 2003
    Location
    USA
    Posts
    4,876
    Post Likes
    Quote Originally Posted by numbawunfela View Post
    I heard the example that Analytics can compare the DAT at the AHU to the DAT at the VAV, of the reheat is closed, but you have a temp rise, it may alert you that the vav reheat valve is leaking by.
    And how hard would that be to do within the current control logic? Have single blocks to calc btus now. It would be trivial to set this up in a standard program that's just there from the start. Same can be said for most 'rules'.

    IMO the big advantage to analytics packages, you write the logic once and almost instantly apply it to as many devices you can toss at it. It can lay on top of whatever garbage is under it. Can you add logic to a thousand devices, which may already have unique logic without some crazy amount of labor?? Do those devices have enough spare capacity to add a few dozen rules like you describe? Can you even add logic to them?? "Analytics" today IMO is a bandaid to what the OEMs should have done a decade ago.

    Most analytic packages can work on histories. While there are certain cases this is a plus, there are equal cases that instant reaction is preferred. In that case, its hard to beat logic running right on the hardware with as few layers of BS as possible. Why look at the past, when your seeing the condition in real time? Executing reactions based on such alerts, hard to beat just running on the native platform which has been possible for some time now. Bodge it in on top, or bake it in? Certainly cases for both. Niagara has been able to work with time series data for some time now, so even that point is thin.

    What I hate about Skyspark is all the custom BS. Did they need to create their own programming language, time series DB, etc...nope. Its just putting up a wall and trapping you in their world. Can I hire a CS major and they run with it, nope. Funny enough they don't teach axiom & folio in collage and your still baby sitting with all the mechanical systems knowlage. That said they do have some pretty impressive options that simply are not available in any hardware I have seen.

    Guessing if the demand for 'analytic' functions become main stream, it will quickly get baked in from the start. Even then I assume there will be some demand for the high end features the typical OEMs will not chase.
    Last edited by orion242; 11-27-2019 at 11:17 PM.
    Propagating the formula. http://www.noagendashow.com/

  5. Likes alper liked this post
  6. #18
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by orion242 View Post
    And how hard would that be to do within the current control logic? Have single blocks to calc btus now. It would be trivial to set this up in a standard program that's just there from the start. Same can be said for most 'rules'.

    IMO the big advantage to analytics packages, you write the logic once and almost instantly apply it to as many devices you can toss at it. It can lay on top of whatever garbage is under it. Can you add logic to a thousand devices, which may already have unique logic without some crazy amount of labor?? Do those devices have enough spare capacity to add a few dozen rules like you describe? Can you even add logic to them?? "Analytics" today IMO is a bandaid to what the OEMs should have done a decade ago.

    Most analytic packages can work on histories. While there are certain cases this is a plus, there are equal cases that instant reaction is preferred. In that case, its hard to beat logic running right on the hardware with as few layers of BS as possible. Why look at the past, when your seeing the condition in real time? Executing reactions based on such alerts, hard to beat just running on the native platform which has been possible for some time now. Bodge it in on top, or bake it in? Certainly cases for both. Niagara has been able to work with time series data for some time now, so even that point is thin.

    What I hate about Skyspark is all the custom BS. Did they need to create their own programming language, time series DB, etc...nope. Its just putting up a wall and trapping you into their world. Can I hire a CS major and they run with it, nope. Funny enough they don't teach axiom & folio in collage and your still baby sitting with all the mechanical systems knowlage. That said they do have some pretty impressive options that simply are not available in any hardware I have seen.

    Guessing if the demand for 'analytic' functions become main stream, it will quickly get baked in from the start. Even then I assume there will be some demand for the high end features the typical OEMs will not chase.
    Genuine comments always deserve likes.

    Extract transform and load is not a small task that can be done without a good scripting language.

    Google recently purchased a company that does ETL for rest API services for billions.

    You don't need a CS major. We did work with young kid that knew scripting. They are not east to find now but within next generation, they will be much easier to find.

    Trapping. They open sourced project haystack in which many companies embraced the technology. Trap is very harsh. It can be installed anywhere. No trapment there either.😉 Be a little nicer with only that fact. If you say you are trapped in the sea of tags. I can feel the sentiment.

    We are very lucky to have Brian Frank within our industry, we should be very nice to him. ☺️

    Cheers happy Thanksgiving.

  7. #19
    Join Date
    Jan 2003
    Location
    USA
    Posts
    4,876
    Post Likes
    Quote Originally Posted by alper View Post
    Trapping. They open sourced project haystack in which many companies embraced the technology. Trap is very harsh.
    Fair enough. How many suppliers offer support for it and how available are experienced people with it?

    We hire a handful of collage interns at every opportunity. Its not uncommon we have 3-4 interns on payroll during that season and the keepers we offer jobs. Skyspark drove us to dive in hard with the CS group. Its custom crap that didn't need to be and regardless who you hire will be a significant investment to bring up to speed. There are more open languages and DB that would make adoption much easier. The only case I can see for their decision is to trap you into their world.

    Quote Originally Posted by alper View Post
    We are very lucky to have Brian Frank within our industry, we should be very nice to him.
    Will keep my comments to myself. Having access to their forum for some time now and seeing 'the brothers' responses, I will just say our opinions couldn't be further apart.
    Propagating the formula. http://www.noagendashow.com/

  8. #20
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by orion242 View Post
    Fair enough. How many suppliers offer support for it and how available are experienced people with it?

    We hire a handful of collage interns at every opportunity. Its not uncommon we have 3-4 interns on payroll during that season and the keepers we offer jobs. Skyspark drove us to dive in hard with the CS group. Its custom crap that didn't need to be and regardless who you hire will be a significant investment to bring up to speed. There are more open languages and DB that would make adoption much easier. The only case I can see for their decision is to trap you into their world.



    Will keep my comments to myself. Having access to their forum for some time now and seeing 'the brothers' responses, I will just say our opinions couldn't be further apart.
    With more open languages please write similar app, let me know how much it has cost you.

    We have written apps in java, fantom, dart, flutter, typescript, sedona lang, c and c++.

    Buildings are custom, where they are located, how they run, the way they run, the reason they run.

    Sorry your interns did not work out for you. The one we hired, we generated haystat, haystack based temperature humidity sensor that runs on esp32 chip. Excelled in axon as well.

    I can send you a free one to test it.

    Sent from my Pixel 3 XL using Tapatalk

  9. #21
    Join Date
    Jan 2003
    Location
    USA
    Posts
    4,876
    Post Likes
    Quote Originally Posted by alper View Post
    With more open languages please write similar app, let me know how much it has cost you.
    Software development is not our business, nor will it ever be. It would be far less hassle to take what we have learned with skyspark and just build it into control logic requesting additional features where we need them.

    Quote Originally Posted by alper View Post
    Buildings are custom, where they are located, how they run, the way they run, the reason they run.
    Sure, data is data though. The real value is the algos sorting it out, not the underlying framework IMO.
    Propagating the formula. http://www.noagendashow.com/

  10. #22
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by orion242 View Post
    data is data though.
    I would not generalize data.

    There is structured data SQL
    There is time series data for bool number enum
    There is untyped or unstructured string data.
    There are log datas that standardized but does not comform or comforms to standards (Somewhat "typed")

    It is like saying food is food. Dirty, clean, tasty, tastes like crap food. Then there is dirty street food that tastes great.

    Data is not data and food is not food.

  11. #23
    Join Date
    Jan 2003
    Location
    USA
    Posts
    4,876
    Post Likes
    Quote Originally Posted by alper View Post
    Data is not data and food is not food.
    Indeed. The creator/collector of the data is pretty well versed in digesting it however.

    Its a foodie, dining on its native food.
    Last edited by orion242; 11-28-2019 at 07:58 PM.
    Propagating the formula. http://www.noagendashow.com/

  12. #24
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by orion242 View Post
    Its an foodie, dining on its native food.
    Farm to table is not a bad thing. Sustainable if it is on short distances.

  13. #25
    Join Date
    Jan 2003
    Location
    USA
    Posts
    4,876
    Post Likes
    LOL! Keep up the good work. It would be nice to see things change. The realist in me thinks its going to be a while. Would love to be wrong in this case.
    Propagating the formula. http://www.noagendashow.com/

  14. Likes alper liked this post
  15. #26
    Join Date
    Mar 2006
    Location
    Austin Texas
    Posts
    89
    Post Likes
    Quote Originally Posted by orion242 View Post
    LOL! Keep up the good work. It would be nice to see things change. The realist in me thinks its going to be a while. Would love to be wrong in this case.
    Thank you, I need all the spiritual support.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •