StokerX version 0.4


 
Hmm. So you mean an iOS (or Android) app that would communicate with StokerX (or StokerLog) and pull the data from that application as needed, rather than only being able to get the current snapshot that is available directly from the Stoker?

joe
Click to expand...

Not quite. Rebuild StokerX as a web service that can run on a web server. Mac users would install it into the web server built into OS X. When you load the webpage, it would build a graph from the time/temp data table it has been accumulating since the session started. Once you can monitor and control your stoker from an external web page (external to the stoker - can be on the web server on your mac, or on a linux server anywhere in the world) you can control your stoker with your smartphone. The web page would have to poll the stoker for data and refresh the web page at a user defined interval. It would run as a service on the web server.

Conversely, if you can build the time/temp data table, and store it somewhere on the internet, all the smartphone app needs to do is grab the data table, build the graph, and telnet the stoker for any changes.

This is better than the static web page the stoker serves because I really want to see the history of the temps. During a long cook, I might only check in once every other hour. I really need the temperature graph.
 
Originally posted by Jim (MadCityJim):
Not quite. Rebuild StokerX as a web service that can run on a web server. Mac users would install it into the web server built into OS X. When you load the webpage, it would build a graph from the time/temp data table it has been accumulating since the session started. Once you can monitor and control your stoker from an external web page (external to the stoker - can be on the web server on your mac, or on a linux server anywhere in the world) you can control your stoker with your smartphone. The web page would have to poll the stoker for data and refresh the web page at a user defined interval. It would run as a service on the web server.

Conversely, if you can build the time/temp data table, and store it somewhere on the internet, all the smartphone app needs to do is grab the data table, build the graph, and telnet the stoker for any changes.

This is better than the static web page the stoker serves because I really want to see the history of the temps. During a long cook, I might only check in once every other hour. I really need the temperature graph.
Click to expand...

Ah. I see. Really, it's a totally different application, because if you're going to do it that way at all, you really want to use a platform-independent language and graph generation toolkit. Written (for example) in PHP, it would then run on any system (Mac OS X, Linux, Windows) that supports Apache, MySQL (if needed), and PHP.

Not terribly hard, I think, but I've never tried writing a web application that needed to maintain a socket connection to a device. That might be a little tricky. Finding a decent package to generate JPG or PNG graph images should be straightforward.

joe
 
Originally posted by Joe Keenan:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Jim (MadCityJim):
Not quite. Rebuild StokerX as a web service that can run on a web server. Mac users would install it into the web server built into OS X. When you load the webpage, it would build a graph from the time/temp data table it has been accumulating since the session started. Once you can monitor and control your stoker from an external web page (external to the stoker - can be on the web server on your mac, or on a linux server anywhere in the world) you can control your stoker with your smartphone. The web page would have to poll the stoker for data and refresh the web page at a user defined interval. It would run as a service on the web server.

Conversely, if you can build the time/temp data table, and store it somewhere on the internet, all the smartphone app needs to do is grab the data table, build the graph, and telnet the stoker for any changes.

This is better than the static web page the stoker serves because I really want to see the history of the temps. During a long cook, I might only check in once every other hour. I really need the temperature graph.
Click to expand...

Ah. I see. Really, it's a totally different application, because if you're going to do it that way at all, you really want to use a platform-independent language and graph generation toolkit. Written (for example) in PHP, it would then run on any system (Mac OS X, Linux, Windows) that supports Apache, MySQL (if needed), and PHP.

Not terribly hard, I think, but I've never tried writing a web application that needed to maintain a socket connection to a device. That might be a little tricky. Finding a decent package to generate JPG or PNG graph images should be straightforward.

joe </div></BLOCKQUOTE>

I don't think a web app that maintains a socket connection is the way to go (or is possible). Looks like you are headed in the right direction but I would suggest separating the data acquisition (application) from the presentation (web server / browser).

The acquisition application could listen to the stoker and update a mySQL DB as needed. This could be written in a PHP script if that is what you are familiar with.

The presentation side would be a web service (PHP?) that accesses the mySQL DB and presents it to the browser as needed.

I have done this and if you click the 'about' button at the bottom of the link you will see an overview of how it works.

Providing Stoker update capabilities would require some additional design work.

Curt
 
Originally posted by Curt Timmerman:
I don't think a web app that maintains a socket connection is the way to go (or is possible). Looks like you are headed in the right direction but I would suggest separating the data acquisition (application) from the presentation (web server / browser).
Click to expand...

Not me headed in any direction.
icon_smile.gif
Other than StokerX for native Mac OS X. At this time anyway.

But you're right about the persistence issue with data collection. To do this right for an iOS or Android app (assuming you can't or don't want to keep the mobile app running full time), requires multiple components. You need the mobile display app, you need the always-running data collection component, and you need the transient connection component (web application, etc). Two of those could be very generic, with the mobile app being the only thing custom to the device. But that's a lot of work to build all three for a very limited market.
icon_frown.gif


joe
 
Originally posted by Joe Keenan:
You need the mobile display app, you need the always-running data collection component, and you need the transient connection component (web application, etc). Two of those could be very generic, with the mobile app being the only thing custom to the device. But that's a lot of work to build all three for a very limited market.
icon_frown.gif

joe
Click to expand...

For the reasons above, I recommended a browser application as opposed to a device specific application. One web page (publicly available) would allow viewing the current status, graphs, etc. Another page, wrapped in security, would allow updates to the stoker. Accesses is completely controlled by the web server.

Curt
 
Originally posted by Curt Timmerman:
For the reasons above, I recommended a browser application as opposed to a device specific application. One web page (publicly available) would allow viewing the current status, graphs, etc. Another page, wrapped in security, would allow updates to the stoker. Accesses is completely controlled by the web server.

Curt
Click to expand...

Oh, I agree. That's why I was always so pessimistic about a mobile device application. Now, doing a mobile optimized (small screen, touch input, etc) version of the website WOULD be useful.

joe
 
Originally posted by Joe Keenan:

Oh, I agree. That's why I was always so pessimistic about a mobile device application. Now, doing a mobile optimized (small screen, touch input, etc) version of the website WOULD be useful.

joe
Click to expand...

A browser application utilizing ajax would also allow a mobile device application to also interface to the server.

Curt
 
Joe, any chance you could integrate an alternative port option in the preference menu in case you want to run the Stoker on a different port other than port 80? Happy 4th to all.

Finished my first pulled pork yesterday. Will post seperately. Malte
 
Originally posted by J. Malte Stoeckhert:
Joe, any chance you could integrate an alternative port option in the preference menu in case you want to run the Stoker on a different port other than port 80?
Click to expand...

Didn't know you could set the Stoker up to do that. I'm assuming that would only apply to HTTP/JSON requests? I can do that. In fact, just try putting the port number in the IP address field, as in "192.168.1.101:8080". I think I just use the text field as it, so it might just work.

Not sure it's doable for the telnet mode. Anyone know if there's a way to change the port that it listens on for telnet protocol?

joe
 
Joe right now you cannot do a change in the Stoker software. Set to port 80.

I have an unofficial firmware release for testing purposes.

After I posted my quesion out of curiosity I tried to add the port suffix to the ip address in the preference menu of Stoker X. Seemed to work although there is a continuing message that the software tries to connect. It shows the ip
icon_razz.gif
ort while doing that.

Malte
 
OK, so assuming the info in the sensor table is correct, the HTTP/JSON query I do to the specified IP address (and port) is working. And the status message says that starting logging was successful.

Are you saying that after that, nothing happens? Or is it just that the status message stays on "attempting connection" when it shouldn't?

Are you using telnet or http mode for the logging?

joe
 
Hmm. There actually is logging going on. I see the lines overlaying the horizontal axis.

No vertical axis, though. What do you have the temperature range set to in preferences?

joe
 
Pit Sensor Low 200 / High 250

Temp Sensor Low 200 / High 250 (actually had that mixed up with food sensor 1)

Set in Stoker preferences.

In Stoker X it's 50 / 300.
 
Strange,

This happened to a friend of mine this last week. And he was trying to use the exact same temperature min and max. I had him change it to something more like 100 min and 240 max, and the y-axis came back. You might give it a try.......

Joe....are you trapping the y-axis range by any chance?
 
Originally posted by Marshall:

Joe....are you trapping the y-axis range by any chance?
Click to expand...

Hmm. Not sure I'm doing any error checking on that. If the preferences are messed up, it could cause something like that. I'll take a look.

I'm converting to Xcode4 right now, so everything in my development environment is a bit messed up. I'll try to look at it this week.

joe
 
You must log in or register to reply here.

 

Back
Top