The was the alarms work is still being developed. However I like your idea and might build finctionality like that. Currently I an working on having a basic timer for general use. There will also be a alarm on any one of the probes that when reached will just beep or bring the cooker to a hold temp. If you have internet hooked up, I will try to integrate SMS as well.

Thanks for the questions!

Thanks! I see what you mean about having data on the same graph. I will look into that.

I actually do some webdesign part-time, so the pages are designed around speed. Everything is using HTTP, it is actually easier to keep everything in HTTP because I do not need processor resources to keep another type of server running. Either way works, it is just a tradeoff. After an initial release I will certainly work on an API for people to expand the data collection and functionality.

The best part about keeping everything browser based is that is always cross-platform. The development I am doing allows for much of the controlling and display code to be separate like you suggested.

Thanks again for your continued help and support.

How often are you going to poll the thermometers?

For your alarms, are you thinking they would go off when a set point temp is reached OR could you program the alarm to go off at a specific temp or time. It would be great to be able to set alarms to go off early at a specific temp or to go off every X number of minutes for mopping/spraying/etc.

You might already be planning this, but it would be great to be able to program your BBQ. Preheat to X deg., when thermometer 1 reaches X deg. reduce temp to 180, alarm at set point.

Eric

I personally like the idea of having both cooker and product temps in the same graph. Yes, there will be a pretty good relationship between the two, however we also know that carry over will be directly affected by the hold temps set on the controller. We can only track this effectivly if we can see both graphs together, rather than having to page back and forth to view two graphs.

As a point of reference, I would point you to the Stoker Log software applicaiton Amir has developed for John’s controller. (There is a good screen shot of the main page here: http://la.gg/upl/stokerlog.jpg ) If you research the life of this app, you may be able track some of the real world functionality requests that I suspect will be very similar to what is desired by the pellet cooker community.

If you look closely, you will notice that rather than using the built-in web server, Amir leverages the telnet function of the stoker interface. Given that most of the development platforms in the category I suspect you are using include both HTTP and Telnet built in, I would STRONGLY suggest you take advantage of this. Telnet data is very light weight and requires minimal processing horsepower on the part of the controller. Pushing the processing burden onto the client side allows you to take advantage of the massively stronger processing ability of a PC or Mac to do the real work. Best of all, if you author the app in JAVA or something similar, it will cross platforms and even function on mobile devices with minimal change. (this is something Amir has NOT done, and it is really costing him in cross platform development)

The added benefit of this separation of labor is two fold. It allows you to create a light weight but full function controller that does not require the use of a software interface. I know that part of your vision is to offer a product that scales well, and this architecture facilitates your achieving that vision. It also allows you to focus on controller code as a completely separate entity from the interface software. In fact, depending on your resource pool, you could even divide the two development projects between two people, or two teams. IMHO solid development of the controller code and function should be your primary focus. We’re all used to controlling our cookers from the on board interface as it is. Make the BEST pellet cooker controller available. The interface software can easily come as a close secondary function.

If there is anything I can do to assist, please feel free to contact me.

Jamie

Yes there is going to be 3 meat probes. I just had 4 placeholders in the graph. I am thinking about having a higher end model with 5 or 6, or maybe designing in the possibility of an expansion interface for more probes.

There is not a difference, just because the data is the same for testing.

Wireless would be standard 802.11 b/g, which is the same as your computer/router at home. Depending on your router is how far you can go. If you have your router in a window, you may be able to be easily 500ft away outside.

Glad you like it! Thanks for the support.

Looking good. Simple, clean looking and not confusing. Having said that, the first thing I noticed on the meat temperature data graph is that you have 4 meats. The setpoint adjustment allows for only 3.

I don’t see the difference between the two graphs relating to 120-minute temperature data and the 24 Hour Temperature Data.

The settings via computer are really going to make it very easy. For wireless I guess you will have to be within a reasonable distance of each other. I really like what you are doing so far and can’t wait for the finished product.

Don O, Pleasant Hill, CA