LinkMeter v2 Homebrew BBQ Controller - Part 2


 
Originally posted by N Waring:


Or did I miss something?

Nick
Click to expand...

You missed something.
icon_wink.gif


We're saying that we use our Linkmeters as clients on our home WiFi networks. Sometimes I take my smoker over to my girlfriend's house, and bring my Linkmeter with me. When it's not a client on my home WiFi network, it's impossible to connect to via WiFi, since it's in client mode, and not AP mode.

The only way to "fix" it is to either switch configs prior to leaving the safety of my home network, or connecting to it via one of the switch ports when I get to where I'm going and reconfigure it to use her WiFi network.

What he was saying is, that it would be nice if it somehow could function as a client, but also as an AP, so if it travelled you could still connect to it to monitor progress of the smoke, even when it's not connected to the internet.
 
Originally posted by J. Winn:
I have an idea that I think may work that I'm going to try when I get home. Actually after I get my probes working right
icon_frown.gif
. I'll post if it works.
Click to expand...

The most straightforward way to check if the connections work correctly is to hook your thermistor up to the HM board directly. Just touch the two legs to the posts on the HM board. If this reads correctly, and when you do the "same" thing with the probe sockets connected and get a different reading, then yes you soldered them incorrectly.

dave
 
Yeah... I spotted the schoolboy error!

Surely the ideal option is to Build another Linkmeter - you could leave it there like your toothbrush and spare socks!

Apologies for not thinking of the scenario - the thought of taking my Smoker to a friends house is not that usual in the UK
 
Originally posted by N Waring:
Yeah... I spotted the schoolboy error!

Surely the ideal option is to Build another Linkmeter - you could leave it there like your toothbrush and spare socks!

Apologies for not thinking of the scenario - the thought of taking my Smoker to a friends house is not that usual in the UK
Click to expand...

It's not so usual here either.
icon_wink.gif
 
My probes seem to be working now; I didn't realize that once I changed coefficients I had to click the update URL. I'm noticing about a 5* difference between the Vishay mounted inside the case and a Maverick probe. Is this normal? Is it that much warmer inside the case? I didn't think it would generate much heat. Maybe it better to drill a hole for it? Also, I'm not seeing where I can manually control fan speed through the web gui. I have yet to install the button. Still trying to figure out how to do client/AP. My original idea didnt work. Thanks!
 
Originally posted by J. Winn:
My probes seem to be working now; I didn't realize that once I changed coefficients I had to click the update URL. I'm noticing about a 5* difference between the Vishay mounted inside the case and a Maverick probe. Is this normal? Is it that much warmer inside the case? I didn't think it would generate much heat. Maybe it better to drill a hole for it? Also, I'm not seeing where I can manually control fan speed through the web gui. I have yet to install the button. Still trying to figure out how to do client/AP. My original idea didnt work. Thanks!
Click to expand...

It is, actually, I would expect more than that. I drilled 2 holes through right above probe 4 and poked the leads through and soldered onto the jack tabs.
 
Originally posted by J. Winn:
I'm not seeing where I can manually control fan speed through the web gui.
Click to expand...
To set the fan speed directly just enter a negative number for the setpoint on either the config or home page.
 
Originally posted by Bryan Mayland:
To set the fan speed directly just enter a negative number for the setpoint on either the config or home page.
Click to expand...

So if I enter -10 will this correspond to 10%, -20=20% and so on and so forth or no? I was looking for something on the config page that said fan speed or something.
 
Yeah I thought it was somewhere in the documentation but I am apparently was wrong! Yeah a setpoint of -10 would be 10%, 0 = off, -100 = 100%.
 
Is it me or is it painfully slow to makw any sort of changes to the router config files with the web gui? The LinkMeter portion is fine its just anything I do with router seems to take forever or hangs up
icon_frown.gif
.
 
It is painfully slow. OpenWRT doesn't seem to be a very snappy firmware
icon_smile.gif


Originally posted by J. Winn:
Is it me or is it painfully slow to makw any sort of changes to the router config files with the web gui? The LinkMeter portion is fine its just anything I do with router seems to take forever or hangs up
icon_frown.gif
.
Click to expand...
 
Originally posted by J. Winn:
I have an idea that I think may work that I'm going to try when I get home. Actually after I get my probes working right
icon_frown.gif
. I'll post if it works.
Click to expand...

After trying my idea and it not working I found this:
https://forum.openwrt.org/viewtopic.php?id=23655

It seems that they have accomplished just what i'm trying to do but after reading through it several times and trying everything from scratch it is not working for me. Maybe someone else will have some luck.
 
Originally posted by J. Winn:
Is it me or is it painfully slow to makw any sort of changes to the router config files with the web gui? The LinkMeter portion is fine its just anything I do with router seems to take forever or hangs up
icon_frown.gif
.
Click to expand...
It is immensely slow. Actually it is a lot faster than it was initially, thanks to some performance enhancing patches I worked up and submitted back to the LuCI people. There's only enough memory to support 2 simultaneous connections (well, probably only 1 really) and there's only a 200MHz CPU inside these things. There's a lot of optimization that can be done in LuCI to make it faster but you'd really have to rewrite some major chunks to get it. I also don't know toooooo much about LUA profiling.

In any case, yeah it is ridiculously slow, and made worse by the fact that the pages are "live" and try to refresh themselves before they even finish loading. Someone should load up the official OpenWrt release and see if it is as bad.
 
Regarding the Alarm subsystem. I think I know how I want this to work but I'm trying to think of how this works on other devices too so I need some input:

Let's say you have a probe alarm set to go off at 180F. The temperature of the probe goes to 180.2F then back down to 179.9F. Does the alarm continue to go off? I assume it should "latch" in that once it starts going off it keeps going off until there is some interaction from the user to disable it. Once disabled, it will not go off again (even if it goes above 180F again) until re-enabled my the user.

Is that how things should work?
 
So is it LuCi that is slow or openWRT? I'm not really sure what the difference is.

I run Tomato on this same router and it is very snappy. Any chance of porting the web stuff to Tomato
icon_smile.gif


dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by J. Winn:
Is it me or is it painfully slow to makw any sort of changes to the router config files with the web gui? The LinkMeter portion is fine its just anything I do with router seems to take forever or hangs up
icon_frown.gif
.
Click to expand...
It is immensely slow. Actually it is a lot faster than it was initially, thanks to some performance enhancing patches I worked up and submitted back to the LuCI people. There's only enough memory to support 2 simultaneous connections (well, probably only 1 really) and there's only a 200MHz CPU inside these things. There's a lot of optimization that can be done in LuCI to make it faster but you'd really have to rewrite some major chunks to get it. I also don't know toooooo much about LUA profiling.

In any case, yeah it is ridiculously slow, and made worse by the fact that the pages are "live" and try to refresh themselves before they even finish loading. Someone should load up the official OpenWrt release and see if it is as bad. </div></BLOCKQUOTE>
 
ny ca
Click to expand...
Hi Bryan...

My thougths on your points:
1. When disabled, agree it should not go off again unless re-enabled by user
2. Yes, would agree that once it goes off, it should continue until switched off
3. Regarding the temperature settings, I may want different things to happen depending on whether it's the Pit or Food probe:
Pit Probe:
It would be good to apply some smoothing to the alarm... say 5 or 10 degrees for 10 minutes.
Food PRobe:
Ideally I'd like it to track the temperature and lower the Pit temperature in stages:
70% of food target - lower the pit by 20%
80% of food target - lower the pit by another 20%
90% of food target - lower the pit by another 20%
Food Target reached - set pit to match.

Does this make sense?

Nick
 
Originally posted by D Peart:
So is it LuCi that is slow or openWRT? I'm not really sure what the difference is.

I run Tomato on this same router and it is very snappy. Any chance of porting the web stuff to Tomato
icon_smile.gif


dave
Click to expand...

Yeah I ran dd-wrt on this same router before I converted it to a LinkMeter and it had no problems; everything ran quickly.
 
Originally posted by Bryan Mayland:
Regarding the Alarm subsystem. I think I know how I want this to work but I'm trying to think of how this works on other devices too so I need some input:

Let's say you have a probe alarm set to go off at 180F. The temperature of the probe goes to 180.2F then back down to 179.9F. Does the alarm continue to go off? I assume it should "latch" in that once it starts going off it keeps going off until there is some interaction from the user to disable it. Once disabled, it will not go off again (even if it goes above 180F again) until re-enabled my the user.

Is that how things should work?
Click to expand...

Sounds right, I believe thats how my Maverick works.
 
I ran some tests with the larger blower and different size capacitors. I connected to blower and multimeter to the blower leads and then ran the blower at 100,75,50,25,and 10%. I only went down to 10% because that is the lowest it will go while in automatic operation correct? Below are my results. I was thinking of going with the 10u or 22u or possibly get one in between because that seems to get the best range. The lowest the fan is rated to operate at is 4V and you can see the 10u is right above that. What do you think?
11j4x6r.jpg


Edit: I was just thinking, am I going to have to change the PID parameters or anything?
 
For the food probes yes, but the pit probe no, it should only alarm when it's out of specs (too high or too low temp), once it goes back in specs it should reset to where it will alarm if it goes of specs.

Originally posted by Bryan Mayland:
Regarding the Alarm subsystem. I think I know how I want this to work but I'm trying to think of how this works on other devices too so I need some input:

Let's say you have a probe alarm set to go off at 180F. The temperature of the probe goes to 180.2F then back down to 179.9F. Does the alarm continue to go off? I assume it should "latch" in that once it starts going off it keeps going off until there is some interaction from the user to disable it. Once disabled, it will not go off again (even if it goes above 180F again) until re-enabled my the user.

Is that how things should work?
Click to expand...
 
You must log in or register to reply here.

 

Back
Top