2 Replies Latest reply on Jul 1, 2009 1:32 PM by robbincarlson

    Holy Moly this is complicated

    robbincarlson

      I think my application is a natural for message queues, brokers and routers.

       

      I gather information from little thermometer and other weather IC's in various parts of 3 houses.  These are some of the things I do with the readings:

      1. Record when a thermometer changes by a degree in a mysql db.

      2. Record sunshine (maybe I get a solar collector someday?), wind, humidity, rainfall

      3. Check if it is too hot or cold.

      4. When I switch on the heat (detected by thermometers on the radiator pipes) does the air in the house get warmer.

      This last bit needs some relationships between various thermometers.  I might even like to track how long it takes the house to cool off or warm up.   I currently do some of this with sql queries, but in a monolithic set of java programs.  I think it would benefit from new plumbing.

       

      I think this can be accomplished by:

       

      • A data collection queue with a db writer listening and a thermometer reading supplying values.

      • A topic that some of the simple analytical programs can subscribe to.

      • Some router rules can move temperatures to different topics subscribed to by more complex or multivariate analytical programs.

      • A queue that can receive messages generated by all these listeners that can generate actions (first an email, second an SMS message, third a phone call, fourth phone a friend, depending on if the pipes are freezing or the furnace doesn't respond, or if it looks like someone broke in and a broken window is freezing a room)Why go to the trouble of FUSE?   Adding and subtracting thermometers, expanding monitoring types, new rules, modularity, small analytical programs, assessing the health of the programs;  I think it is the right thing to do, but gosh (my toned down word), FUSE is complicated.  There are so many things to do to make it work, starting with installs, learning the APIs and running it.

       

      My question is how do I go from requirements, to design, to coding, to installation without exploring every nuance of FUSE?  I'm not saying I don't want to learn, but I don't want to learn for a year (at night) to begin the process.  I'd like to validate my requirements, find a similar design so I pick a reasonable starting point, learn that - stealing what I need.  I'd like to build it incrementally.  But the breadth of FUSE is daunting.

       

      Where do I start?

       

      Edited by: robbin on Jun 30, 2009 10:15 PM

       

      Edited by: robbin on Jun 30, 2009 10:16 PM

       

      Edited by: robbin on Jun 30, 2009 10:17 PM

       

      Edited by: robbin on Jun 30, 2009 10:17 PM

        • 1. Re: Holy Moly this is complicated
          oisin

          The very first thing to do is establish your inputs, and the nature thereof. You have a set of analog inputs that need to be mapped to a numeric scale - so first step in the process is to establish the mensuration devices that are the endpoints and map them thru a digital range, depending on the hardware you are using. Separate the concepts of taking the temperatiure and a value between 0 and 255 has come in on pin 6

           

          Grab your Arduino board and attach/configure your sensors - you then need to give the value streams access to the route or queue. I'm thinking perhaps what you need to do is write a piece of ActiveMQ client that slurps the Arduino values and puts them on a Q (stomp is probably the easiest protocol) and then pull that into a Camel route which can process according to a header that has been attached by the client.

           

          If you are connected via a small pooter at all times, you do have the opportunity to use Camel to route decisions through endpoints which map to servos, etc.

           

          Basically -- forget about the hardware bitz - form them separately, then construct your integration network based on your measuring points. Good news is that you can put the Camel route into an OSGi bundle and whack it onto one of the Bug modules or something of that nature. But here is where you need to design first.

           

          Maybe not much value of advice there - but let's know how you get on

          • 2. Re: Holy Moly this is complicated
            robbincarlson

            The device reading part is as easy as pie.  I can read them with java directly or from owfs (it is 1-wire so they deliver the temperate and other things in degrees or percent or millibars).  Or I can use the owserver and just make a connection and use a different java jar to ask for and receive values. 

             

             

            I have a computer running cameras (which could be another interesting input if I get any good comes of this) 24x7 so the availablity is fine.  The bug looks interesting but no need to spend more than my time at this point.  I was also looking at an ATOM 330 solution which is about the same price and it uses on the order of 20 watts. 

             

            I wish there was a primer that said, start here (go read this) then go here (and read #2) and then here (read #3) and finally (I doubt 3 things are all I need) you have a solution.