Stokerlog Version 6


 
FYI I have had my Wifi Unit running for a couple of hours. I have tried to break it but so far, only minor issues have popped up. The main one is that plugging new probes into the device causes a reboot and that confused stokerlog. So put all of your probes in there before you start stokerlog.

Other than that, I am running with 5 probes and a blower and she is running fine. I have changed target temp dozen+ times and association is not lost.

Anyone has a specific sequence that causes a problem?

I will keep this running a lot more to see if I can find any other issues.
 
Amir, can you try using the 5 minute blower off function FROM THE UNIT and see if wifi drops, or stokerlog loses connection after you do that?

And I am curious, have any of your "temp changes that caused no problems" come from the unit instead of Stokerlog?
 
Originally posted by Gerd Hilkemeyer:
Amir, can you try using the 5 minute blower off function FROM THE UNIT and see if wifi drops, or stokerlog loses connection after you do that?
I just tried that and it did not fail. I have two blowers and tried on each and it keeps working. Both the browser and Stokerlog continue to run as I type this.

And I am curious, have any of your "temp changes that caused no problems" come from the unit instead of Stokerlog?
Yes. I also tried it once or twice from the browser and that worked too. I have since played with alarms, food probes, etc. Nothing I have done has caused a failure. The machine has been up for two days now and keeps working.
 
Originally posted by D Arita:
Amir,
I got my Stoker a few months ago and have not updated the unit since. What version is in your Stoker?
The new one is running "2.7.0.270" according to the browser interface.
 
Well, I haven't used the Stoker for a week or so. Just pulled it out this morning to check my version and now I can't connect at all using Stokerlog or Stoker Status. Don't know what happened...?
 
Make sure the IP address has not changed. Look it up using the unit. I use a "static IP" address (manually entered) so it always remains the same. Since stokerlog remembers this value, you never have to worry again.
 
While I was running my fun little stoker test today I decided to try and break Stokerlog/Wifi like I had been seeing intermittently.

For the first 2 hours, I adjusted nothing, and all was fine except maybe a short loss of connectivity for a second about an hour in.

So, I changed the target temp from stokerlog. That worked.

I then went to the stoker black box itself, and disabled the blower for five minutes. I went to stokerlog to hit F5, and my pit sensor was unassociated. Status says "No(Fire) control probes found".

So, I shut it all down and brought it back up. I had to re-associate the probes. Done. Target temp 250, all is well. I changed the target temp on STokerlog to 240, clicked update, and all is well. I went to the Black box, changed the temperature on the black box to 235, and saved it. When I go back to stokerlog and F5 ..... unassociated. "No(Fire) control probes found".

EDIT to add: for what it is worth, if i hit F5 from stokerlog without making a change at the black box, there is no failure. If I make a change ON STOKERLOG and submit it, there is no failure. But if I THEN refresh from stoker log by hitting f5, the probe dissaciates every time. there is something about doing a refresh after a change has been applied ot the stoker, regardelss as to where that change was committed.
 
Ah. That may be the clue I need to figure out what is wrong! I am at our vacation house during the weekend but will try when I get home.

Thanks a bunch
icon_smile.gif
.
 
Running my first cook with my new stoker! I'm running 2 18" WSMs. What I've figured out is:
Change the target temperature on the stokerlog2 screen and the blower disassociates from the sensor. I go outside to the unit and there is no asterisk next to the blower on the sensor screen. A refresh of stokerlog merely reports the newly disassociated sensor as a food sensor on the main stokerlog screen. Late breaking news....while I was writing this post a change of the alarm temp did the same thing. It seems like any time I change anything on the stokerlog2 screen that needs to be communicated back to the stoker, the blower disassociates.
 
Originally posted by Joanne Macek:
Running my first cook with my new stoker! I'm running 2 18" WSMs. What I've figured out is:
Change the target temperature on the stokerlog2 screen and the blower disassociates from the sensor. I go outside to the unit and there is no asterisk next to the blower on the sensor screen. A refresh of stokerlog merely reports the newly disassociated sensor as a food sensor on the main stokerlog screen. Late breaking news....while I was writing this post a change of the alarm temp did the same thing. It seems like any time I change anything on the stokerlog2 screen that needs to be communicated back to the stoker, the blower disassociates.
Gosh, I have tried this scenario so many times and can't make it do this.

Can you tell me your configuration? How many probes, blowers, etc? I want to mimic it exactly to see if that is the difference.

Thanks. Same with others who are having this specific problems.
 
Originally posted by Joanne Macek:
Running my first cook with my new stoker! I'm running 2 18" WSMs. What I've figured out is:
Change the target temperature on the stokerlog2 screen and the blower disassociates from the sensor. I go outside to the unit and there is no asterisk next to the blower on the sensor screen. A refresh of stokerlog merely reports the newly disassociated sensor as a food sensor on the main stokerlog screen. Late breaking news....while I was writing this post a change of the alarm temp did the same thing. It seems like any time I change anything on the stokerlog2 screen that needs to be communicated back to the stoker, the blower disassociates.
Are you running as Administrator using 6.7? I can't run as administrator, so I have to use the prior version and have this happening.
 
I wasn't able to connect at all, so I called Kevin. The IP address in Stoker had changed. Kevin said that Stokerlog may be the cause of that and not to use it until Amir has fixed the issues. Is this possbile?
 
Sorry guys...long day involving a memorial service where the two briskets and 4 pork butts that I cooked last night were served as well as the opening day of little league!

I am running a black box with firmware Version 2.7.0.270.

I have two pit probes and 2 5cfm blowers that I'm attaching to the smoker with the WSM converter kit.

I turned off DHCP because I was getting network dropouts and the IP address kept changing on me (even before I installed StokerLog, I might add.) I'm running a Linksys WRT54G wireless router.

I'm running StokerLog 6.7 in a Dell Inspiron Mini Netbook running WindowsXP. I don't use logon accounts, so I would have full administrative privileges...I believe.

Interesting things I've noted:

(1) You need to have SOME type of sensor attached in order to connect to the unit at all. I wanted to turn it on to check the firmware version for this post and no dice until I plugged in a probe. This goes for both StokerLog and the built in web page.

(2) Since my previous post, even changes I made to Blower 1 that caused data to be pushed out to the Stoker unit caused Blower 2 to become disassociated.

(3) When you turn off DHCP for wifi (via the IPaddr/wifi.html page), there is no way to verify the IP address on the Stoker unit itself. If you go into the IP Addr menu, it shows all zeros. (which is always the case when you have wifi enabled...I think.) But the WiFi IP Addr (RO) screen usually shows the address. If you have DHCP disabled, it will also show all zeros. Make sure you remember the static IP you give the unit!

(4) I have had to shutdown StokerLog a couple times and restart it. But, that COULD have been because I was getting impatient when I got the little hourglass for too long. Unfortunately, I don't have specific examples of what I did to make that happen. I also had something on my network go wonky last night about 1:30 am. I awoke at 2:30 or so and saw the StokerLog graph hadn't been updated. I shut it down and restarted and it was unable to connect to the stoker. I also had other device network connectivity issues, so I rebooted the router and all was happy. Well, execpt me because I had to be up at 4am to foil the butts and brisket. This is the first time I've run on so little sleep since I was a college student or my kids were infants. Although truthfully, my kids let me sleep more than those smokers did last night!
 
Thanks Joanne. Can yo do me a favor and test with just one blower? Doesn't have to be when you are cooking. Just attached to it and see if you can repeat the problem.

I have tested with two blowers and didn't have issues there either.

Are you able to hook up using Ethernet (again, indoor for testing) and see if it still happens?
 
Test #1 - Wifi connection with single blower.

(1) Stoker with blower plugged into far right front, sensor plugged into far right back. DHCP disabled, connected with wifi
(2) Power on the stoker unit, blower starts blowing.
(3) Launch StokerLog, press Start.
(4) StokerLog interface comes up and shows Control: Pork (I had renamed the blowers yesterday). Target 280, Current 64.3
(5) Check the status of the sensor on the unit: Temp Control->Pork->Blower->Blower * Blower 2.
(6) Press Back, Back to get the display temp on the unit.
(7) Enter a new target temp of 100 on the StokerLog screen, Clickin the Conrol Probe box to get the Update Stoker button to become available.
(8) Press Update Stoker. See Saving Settings in the Stauts box, missed any other messages because I was writing this log
(9) The fan stops blowing.
(10) File->Refresh Data from Stoker on the StokerLog screen.
(11) Receive Status: No (Fire) control Probes found
(12) Check the status of the sensor on the unit: Temp Control->Pork->Blower shows no * on the Blower screen.
(13) Press Back, Back on the Unit. Select to check the target temp: Target Temp = 100. So we know the target temp update was received by the unit.
(14) Go back in, asssociate the blower and it starts blowing again.
(15) F5 on StokerLog and all is right with the world again.
(16) Launch FireFox. Open the go to the IP addr. Changed the target temp to 150. The interesting thing is, the blower stopped momentarily and then started back up again.
(17) f5 on StokerLog and everything is still associated, and the new 150 target temp is showing.

I really think you're onto something about the format of the configuration update. I'm about to install WireShark to see if I can see a difference between the info sent when doing a StokerLog update and a stoker web page update. Direct wired connection is before that, though. But I need to move my setup to my living room to plug into a switch instead of wifi.
 
Ran one more test. Configured the same setup as above, but with the other set of blower/probe. The behavior was the same as above.
 
Ok, guys...this is more serious than I thought. I couldn't wait and decided to install Wireshark before hooking up to wired ethernet. I was trying to capture the sequence of ethernet traffic that StokerLog did as well as StokerStatus (I'm going to use StokerStatus to refer to the Stoker webpage). In the process of trying to figure out which packets were which, I was doing a lot of temp changes on StokerStatus. And, the second or so time I did so, the blower disassociated!! StokerLog was no where in sight. It happened with the Stoker's own web page. Here are some of the captures:
(ETA: GAH! Proportional fonts! Copy and paste to a Word doc and use a Courier font...your eyes will thank you!)

StokerLog sending the new config set point = 150
0000 00 1d c9 d1 32 0c 0c ee e6 bc 22 df 08 00 45 00 ....2... .."...E.
0010 00 dd 8f de 40 00 80 06 e6 4f c0 a8 01 6b c0 a8 ....@... .O...k..
0020 01 31 05 45 00 50 10 72 b2 4c d6 ec d7 ce 50 18 .1.E.P.r .L....P.
0030 44 70 d1 cf 00 00 6e 32 31 45 30 30 30 30 30 30 Dp....n2 1E000000
0040 31 31 42 31 43 43 30 35 3d 42 6c 6f 77 65 72 20 11B1CC05 =Blower
0050 31 26 6e 31 41 39 30 30 30 30 31 32 39 39 38 44 1&n1A900 0012998D
0060 33 30 33 30 3d 42 72 69 73 6b 65 74 26 74 61 41 3030=Bri sket&taA
0070 39 30 30 30 30 31 32 39 39 38 44 33 30 33 30 3d 90000129 98D3030=
0080 31 35 30 26 74 6c 41 39 30 30 30 30 31 32 39 39 150&tlA9 00001299
0090 38 44 33 30 33 30 3d 31 37 30 26 74 68 41 39 30 8D3030=1 70&thA90
00a0 30 30 30 31 32 39 39 38 44 33 30 33 30 3d 33 30 00012998 D3030=30
00b0 30 26 61 6c 41 39 30 30 30 30 31 32 39 39 38 44 0&alA900 0012998D
00c0 33 30 33 30 3d 30 26 73 77 41 39 30 30 30 30 31 3030=0&s wA900001
00d0 32 39 39 38 44 33 30 33 30 3d 31 45 30 30 30 30 2998D303 0=1E0000
00e0 30 30 31 31 42 31 43 43 30 35 26 0011B1CC 05&

Stoker status sending the new config set point = 100 - but this disassociated the blower!!!
0000 00 1d c9 d1 32 0c 0c ee e6 bc 22 df 08 00 45 00 ....2... .."...E.
0010 00 e0 91 51 40 00 80 06 e4 d9 c0 a8 01 6b c0 a8 ...Q@... .....k..
0020 01 31 05 4b 00 50 89 93 9d 4b d0 9d fa 52 50 18 .1.K.P.. .K...RP.
0030 44 70 a0 93 00 00 6e 32 31 45 30 30 30 30 30 30 Dp....n2 1E000000
0040 31 31 42 31 43 43 30 35 3d 42 6c 6f 77 65 72 2b 11B1CC05 =Blower+
0050 31 26 6e 31 41 39 30 30 30 30 31 32 39 39 38 44 1&n1A900 0012998D
0060 33 30 33 30 3d 42 72 69 73 6b 65 74 26 74 61 41 3030=Bri sket&taA
0070 39 30 30 30 30 31 32 39 39 38 44 33 30 33 30 3d 90000129 98D3030=
0080 31 30 30 26 61 6c 41 39 30 30 30 30 31 32 39 39 100&alA9 00001299
0090 38 44 33 30 33 30 3d 30 26 74 6c 41 39 30 30 30 8D3030=0 &tlA9000
00a0 30 31 32 39 39 38 44 33 30 33 30 3d 6e 25 32 46 012998D3 030=n%2F
00b0 61 26 74 68 41 39 30 30 30 30 31 32 39 39 38 44 a&thA900 0012998D
00c0 33 30 33 30 3d 6e 25 32 46 61 26 73 77 41 39 30 3030=n%2 Fa&swA90
00d0 30 30 30 31 32 39 39 38 44 33 30 33 30 3d 31 45 00012998 D3030=1E
00e0 30 30 30 30 30 30 31 31 42 31 43 43 30 35 00000011 B1CC05

These are a hex dump of the data going across the wire. To the right is the ASCII translation of the data. There are two differences between the two that I noted: Note the + sign in the StokerStatus version. Versus the spacein the StokerLog version. Also note that the StokerLog has an & on the end. I think that's generally the separation character between fields because when I turn on serial numbers on the StokerStatus the data block ends with "&qq=on".

I also noted that the order of the fields is different. The "alarm on" ($al) field is last in the StokerLog version and first in the StokerStatus version.

I'm guessing the fields are:
StokerLog:
&ta
&tl - alarm low temp
&th - alarm high temp
&al - alarm on/off
&sw - sensor id to blower id association
StokerStatus:
&ta - target temp
&al - alarm on/off
&tl - alarm low temp
&th - alarm high temp
&sw - sensor id to blower id association


Amir, do you have a communication channel with the Stoker software people? I can't explain why it happens so regularly with StokerLog but not with StokerStatus. But it definitely happens with StokerStatus too!

Off to do the wired test...
 
Ok, my internet went down in the middle of this...curse you Time Warner! But, I can report that wiring the Stoker via a cable to a switch caused StokerLog AND Stoker Status to behave perfectly. No blower diassociation. Note that the netbook I was running StokerLog on was still using the network wirelessly.


Before I did that test, I tried one more thing.

Stoker = wireless
Tablet streaming Netflix wirelessly.
THAT caused the Stoker Status page to demonstrate the blower diassociation much more frequently. I was about to try Netflix streaming via my TV, which is hardwired into the same switch I had the Stoker on, but that's when I discovered that my internet went down.

So, I'm not thinking the problem is with StokerLog. Amir, if you have someone at Rock's that you can put me in touch with, I'd be happy to contact them to let them know the troubleshooting that I've done so far...

StokerLog is a VERY cool program that I sat transfixed in front of on Friday night. Can't wait for all of the kinks to be worked out of the black box...
 
Thanks Joanne. Seems like some kind of packet wifi corruption issue on the receiver end. I will contact the developer. Looking back, he had fixed a blower association problem before.
 

 

Back
Top