Show HN: IR stove thermometer, firmware in Rust | Hacker News Reader

Show HN: IR stove thermometer, firmware in Rust

anyleaf.org

Actual link: https://www.anyleaf.org/stove-thermometer HN truncates my links to the top URL 30s after posting.

Just released this IR stove thermometer. Uses 2 nRF52 chips, with the ESB protocol. Programmed in Rust. Source code for the sensor module is here: https://github.com/David-OConnor/nrf-hal/tree/main/examples/...

Let me know if you have any questions on how it's done.

Of note, it seems like most people wouldn't have a use for something like this, since they care about internal food temp, or test surface temp by seeing how water or food reacts. I used a handheld thermometer, but wanted something hands-free and more accurate.

Oh boy I can see these guys are on a positive trajectory. These tools are useful across a broad spectrum of applications.

One of the things I would suggest is build APIs for them and people on HN will eat them up!

That's a great idea. Might be a way for tech-savvy people to custom-tune the behavior.

Maybe an edge case, but ever since I've had people forgetting to turn off my stove, I've wished there was something like this that could trigger an alarm on either temperature or timer (say, heat detected on stove for over 2 hours). A peizo beeper could make a great addition!

You should consider getting this product https://www.amazon.com/gp/product/B0863BFNWB/ref=pe_386300_4...

The canisters magnetically attach to your range hood, if there's a fire they pop open and spray a fire suppressing powder all over your stove. Very low tech, they only need to be replaced every 6 years.

I wonder what that powder is. My fire extinguisher uses a corrosive powder that is damaging to electronics especially. I think CO2 would be ideal from this point of view, but perhaps not efficient enough.

I wonder if I could make a poor man's version by filling a very thin plastic container like the kind used for bottle water and fill it with baking soda and attach it up there. If the heat melts the plastic, the powder will be dispersed and any flames will cause it to decompose, releasing CO2, hopefully snuffing them out.

This sounds outstanding, and probably quick to design / cheap to add to BOM. Will try to get it in an upcoming revision. A simple solution may be to trigger it if the temperature gets very hot - ie the sort of temp above what you'd use for normal cooking, but could happen if the skillet is left unattended. Might be able to come up with something more sophisticated too. Eg above a certain temp for an extended time.

Just install a 2-hour wall timer between the mains and the stove. Trigger the timer before cooking, it will cut the power to the stove after 2 hours (whether it is on or not). These timers are quite common in communal kitchens, e.g. in hostels. There are plug-in versions for devices like water boilers or clothes irons. No high-tech needed, always works. If you're broiling a mega-turkey you might want to restart the timer before it runs out, otherwise you won't notice it is there.

Won't work with gas burners, of course

It's not a million miles away from it though.

Typically gas stoves have a failsafe safety system that uses a thermocouple to keep the gas on only when there's enough heat.

If you used a timer to break that safety circuit (relay?), the solenoid will revert to it's safe state, and turn off the gas.

Doing that safely may be difficult. And doing anything with a gas installation may be illegal, depending on where you live.

In Australia this has only been legally required since 2017. My 2014 new house stove doesn't have it. Likely country dependent (I think more commonly it restarts the igniters instead of cutting the gas)

Sorry for the offtopicness but could you please email hn@ycombinator.com? I want to send you a repost invite.

A normally-closed gas solenoid valve is a readily available item for about $200.

https://www.mcmaster.com/gas-solenoid-valves/solenoid-on-off...

Combine with a countdown timer:

https://www.intermatic.com/Catalog/us/Products/In-Wall-Contr...

At ~$1200 DIY is a add-on fire suppression system for the range that would include a similar gas valve or contactor to shut down the range if fire suppression activated plus fire alarm klaxon and alarm system tie in possibilities.

https://guardianssi.com/

You can get those solenoid valves for around $20 online (e.g. [1]), that one is scandalously overpriced - a replacement coil costs $160...

[1] https://www.amazon.com/Beduan-Electric-Solenoid-Normally-Col...

McMaster tends to be that way, but it's got such a great catalog, that's why I end up there. I appreciate you forwarding the link for a more reasonable priced option.

At our company we have built a device which monitors your stove with an IR sensor and has an alarm for dangerous situations [0]. It does some processing on the sensor data - if it detects a dangerous situation it beeps loudly and sends you a text/call in case you are out. It can also guide you through recipes, currently there's only a small handful though [2].

We aren't entirely sure how to market it successfully though (there's an alternative landing page [1]), and the chip shortage is also affecting our ability to manufacture.

[0] https://mypippa.me/

[1] https://mypippa.me/pippa-saves/

[2] https://recipes.mypippa.me/

Nice idea for a product… one small piece of feedback from is is that whenever I see Kickstarter it is a big off switch for me.

I see it as a red flag for a product that may never actually launch.

Show me the product and let me order

Thanks for that feedback - the product is basically ready to go, the reason for Kickstarter was to get pre-orders to get enough capital to pay for a larger manufacturing run. Of course, it's quite possible to take pre-orders without using Kickstarter, so that may be a better route.

I wonder why stoves / ovens even have a “stay on forever” mode, let alone have it as the only mode. The microwave model of “be on this power for this duration and then beep and turn off” seems much nicer...

It's rewriting the URL because you have a `<link rel="canonical" href="https://www.anyleaf.org">` on the page.

Thank you! Fixed.

So weird I just had this idea after leaving the house with a burner on. Instead of (or in addition to) cooking accuracy I'd love a big warning light to know something in my kitchen is hot.

> Actual link: https://www.anyleaf.org/stove-thermometer HN truncates my links to the top URL 30s after posting.

This is probably because you have the following in your HTML:

  <link rel="canonical" href="https://www.anyleaf.org">

This is used to tell search engines and other sites that the page in question contains the same content as the page in the "canonical" link; so they should prefer to show the canonical version over the other one. I'm guessing HN also uses this for a single reason.

You shouldn't have canonical link relations to pages which are meaningfully different.

Edit: ah, I see that someone else pointed this out and you've fixed it already.

Why your own HAL crate? What’s different between yours and the original nRF HAL?

The `nrf-rs` HAL is quite good, but there are a few differences in my fork:

  - Replaced GPIO module with one with a cleaner API. Adjusted other modules to reflect this.
  - Replaced timer module; original was a thin wrap of the PAC
  - Tweaks to the RTC API to make it easier to set the timeout.
  - Overall, brought the API to parity with the STM32 HAL I wrote. This makes code more portable between projects for me.
  - Support for nRF-53

There were enough opinionated API changes that it would never get merged upstream in a PR.

That’s awesome! Your embedded rust is very good, that’s probably some of the cleanest embedded code I’ve ever seen. Awesome that you had time to tweak the HAL and ship your product. Makes me want to update a few embedded interfaces with better APIs.

Neat. I've been thinking that such a product should exist.

Are you sampling just a single point for temperature or do you get the maximum value of a bunch of IR-pixels?

Also, with your first dollars earned, I would hire a photographer for better product pictures :)

Single point. The sensor averages the temperature of everything in a 10° FOV, which should be suitable to get an average pan temperature.

I think you could do something more clever with an IR camera like you suggest, by identifying the edge the pan, and giving more info like the temp gradient, perhaps displayed as 2 temps. Ie, "edge temp", and "center temp".

I have a non-food related use for this, namely:

"Is my LED cooking already?"

I've found that most lamps and light fixtures are still designed with incandescent bulbs in mind, so there's often not a lot of space left inside, and thus too powerful of a LED is going to cook itself eventually.

It doesn't take long at all to figure out how fast it takes pans to get up to temperature when you start cooking on a new stove.

90% of stovetop cooking doesn't require this level of precision

Many cooking processes start with warming the pan up with something in it, and using the state of that material. Spices, onion, garlic are a few examples. Mirepoix is another example, cooked gently until you smell it, not based on temperature.

There are also a multitude of tricks to telling how ready a pan is - the water droplet test, putting your hand near the pan surface, etc.

It's a clever concept, but the sensor is going to get contaminated by smoke residue, grease, food splashes, etc pretty quickly. 3d printed cases are not appropriate for the kitchen because the rough, permeable surface is a breeding ground for bacteria and mold soon as it gets any food residue on it. The inset screen and buttons are also terrible for kitchen devices.

Also, it's not worth anything close to $100. OP's claim that it is somehow more accurate than handheld temperature guns is quite silly, given how widely they're used in industrial applications where accuracy can be quite important. OP used a lot of expensive components (nRF chips, OLED display etc) and a case manufactured using slow prototyping equipment. That doesn't translate into value for the purchaser.

Even if it does have a "more expensive sensor", which is certainly doesn't compared to any gun made by a reputable test equipment company - if you're not bothering with emissivity correction, the quality of the sensor is irrelevant.

All great points! I think you've hit the key question of "Is this useful", plus a lot of valid concerns about wear+tear, the environment it's in etc. I'd love to get the price down. Getting the enclosures injection molded would be great, but need to validate if it's worth the upfront cost first. The main BOM driver is the sensor, due to needing one with narrow-FOV optics.

I originally planned to use milled aluminum attached to the bottom of the sensor unit as a steam-shield, but the plastic has held up well after testing for a few months. There's an o-ring seal around the sensor, which should help. It's probably worth adding it to the base-unit buttons as well.

You're also right on the sensor quality claim. It's likely not as good as that used on industrial test equipment - the comparison is to the cheaper consumer grade ones many people use.

Could you make a 'shotgun sensor' like a shotgun mic? Those things are basically just a microphone in a long tube, which reduces the 'field of view'. The sensor reading would go down, but you could measure how it's affected and compensate for that.

Roughly, I think that's what the optics are doing. The higher-FOV sensors are short, while variants that have smaller FOVs like this use a long tube.

Also of note, you can get directionality from microphones by using arrays configured in various ways, that take advantage of interference. For example, 2 microphones, with the front summed with the inverted rear delayed by the dist sound takes to travel between the 2. There are caveats to this, like non-uniform freq response. Radars do this for transmitting RF energy; I'm curious if this could be employed in a camera.

More Rust relevant link: https://www.anyleaf.org/blog/writing-embedded-firmware-using...

thank you for the pointer. I was actually looking into this. Was wondering if rust gets transpiled to C, or just compiled into assembly. I was also curious what MCU architecture supports this and was very happy to see ESP32 is getting supported soon. I'm not sure (honestly I don't understand the space well enough) how IDF, the OS for esp32, gets incorporated with a Rust program.

I'd love to also hear more from OP the business side of this venture. OP if you can read me, I'd love to talk!

Rust is normally always compiled directly to Assembly using LLVM. The only exception is mrustc [0], which is only intended to be used for bootstrapping a Rust compiler with a C++ compiler. It produces "very ugly C".

[0] https://github.com/thepowersgang/mrustc

Impressive what you can get to the top of HN just by saying it's written in Rust.

"Assembled in Raleigh, NC, USA" if you're curious

Next level: Close the loop, integrate into the electric stove control, add up/down buttons on the display.

I think there’s a lot of opportunity around closed loop control in cooking that isn’t being done right now

I wonder if a stove measuring the temperature on the bottom of pan would be accurate enough. For gas I guess it wouldn't work, but for induction where the pan is heated internally, it should work as long as the temperature between the bottom and surface of the pan do not have too much of a delta.

All high-end Siemens induction stoves already have such closed-loop sensor, called fryingSensor Plus. It makes an audible alert when oil has reached the desired temperature, and then keeps that temperature.

Is there anything special about Rust that distinguishes it from, say, c++?

When you write Rust normally (without unsafe) you can mechanically verify it to be memory safe, whereas C++ is... well who knows really it's a 80s language, but if you follow <guidelines> maybe you're OK?

Add any number of safe Rust commits? Still memory safe.

Add any number of C++ commits? Who knows. Every change has to be checked.

This is true for the most part, as long as the safe Rust commits are not in the same module as unsafe code, and the unsafe code is built to prevent code in other modules from causing UB. See https://doc.rust-lang.org/nomicon/working-with-unsafe.html.

This is true if you have unsafe in your code, but I’m talking about Rust codebases with no unsafe blocks. (Which really any normal Rust app should adhere to, exactly for this sort of reason.)

Proper algebraic typing, a package manager (that's actually quite good), guaranteed memory safety, good LSP support, good performance, a not-nightmarish grammar... the list goes on and on. It's worth giving it a shot, honestly.

What are some resources you’d recommend for me to understand this level of firmware development better? I’d love to understand it a bit deeper than a quick code review

What plastic did you use to 3D print it? Any worries about steam or other heat softening it over time?

PLA. Initially used ABS due to the higher temperature tolerances, but remarkably, PLA worked better in practice. Perhaps due to a cleaner, more even print. (Using a Raise3D E2 filament printer) As mentioned earlier, had originally planned on an aluminum plate on the bottom to deal with warping from steam, but hasn't been a problem since switching to PLA.

Reply on news.ycombinator.com