The Development Log


 
I've been messing around with the v4.1 board, trying to figure out which direction to expand it. Ideally we'd take up more space over the Pi and use that to mount components on. What sucks about that is once the LCD is soldered in place, anything that is under it is pretty much off limits because it is an incredible pain to remove the LCD to be able to change out a component beneath it. If you assume that space is off limits, expanding the board over the Pi does next to nothing for creating more PCB space. The USB jacks on the left also start to get in the way. If there was some removable way of mounting the LCD so that it could be removed without making it sit any higher...

I've also finally settled on just copying the grillpid.* files over to the lmremote project. The IDE just isn't flexible enough to allow the right include path.

Finally, I did a little research on the IT+ transmitters, because the range seemed to be a lot lower than it should be. I pulled apart one of the LaCrosse transmitters and soldered wires all over it until I found data lines going to the transmitter and could record the data flow. Looks like the bitrate is right but the frequency and deviation were off slightly from what rfm_itplus had. I think it should be 915.030MHz (instead of 915.000) and 60kHz (instead of 90). I tried those numbers and the spectral patterns were closer when viewed with my SDR, but 912.025MHz looked to be a closer match. It is hard to see, because not every transmission appears on the waterfall. If anyone has any experience with SDRs and can tell me how to capture this more reliably that would be a great thing.


The long and the short of this is that the IT+ should now be better tuned to the LaCrosse frequency which should increase their effective range. I've also lowered the PLL bandwidth which reduces noise, but I'm not sure how much of an effect on the sensitivity.
 
Bryan,

I'm not sure if this is the right thread for this...

I've been coding an iPhone app to work with the HeaterMeter. I am going to start another thread asking for volunteer beta testers. I've done a couple of cooks with it and am ready for additional user feedback.

Since you have such a vested interest in this project, do you want to have input into the design, naming uses, colors, etc? Example: I've blatantly ripped off the color scheme to one of your posted graphs for the graphing feature in the app. I would not plan on charging for the app should I submit it to the apple store. Feel free to PM me if you'd rather take this out of the public forum.

I have a feature to change the set temp, fan min/max, probe names, and alarm low/high. This needs authentication. So far what I've done is to POST username/password to /luci/admin/lm/home, get assigned a sysauth cookie and screen scrape the ";stok=" value. I then call /luci/;stok=%@/admin/lm, screen scrape the configHash JSON for the purpose of getting the fan min/max for display. To update the HeaterMeter I then call /luci/;stok=%@/admin/lm/set?" with the parameters that have changed. Is there a better way to do this outside of the screen scraping? I didn't use the basic auth feature because most users aren't likely to have this setup.
 
Darren,

When you POST to the login page, you will also get a path cookie back that has the stok=x value. Might be easier to pull that value out of the cookie instead of screen scraping.

Also, if you issue a GET request to /luci/lm/hmstatus you will get pretty much what you are looking for (set temperature, fan values, alarm, etc) in JSON format.
 
Thanks Andy. I was mostly wondering if there is an easier way to update the settings that didn't require the separate login request, or if there is an undocumented login JSON request/response API. I'm using hmstatus for everything else, but it doesn't return the current fan min/max setting. For that I've only found /admin/lm. Wondering if there is a better way on that too.

Andy I saw in another thread where you mentioned having an iPhone. PM me if you'd like to take the app I've been working on for a test spin, and I can work with you to install it on your device.
 
If you need someone else to test on iPhone, I can. I'm still running on iOS6 since I don't want to lose my jailbreak! My iPad is running on iOS 7 though.
 
Hey that's awesome! Glad to hear there's going to be an iPhone app. My Dad has an iPhone and a HeaterMeter so that would be great for him. I do ask that you create a new thread for the topic instead of continuing it in here. I'll answer your questions though.

You're on your own for colors and designs and layouts. You're welcome to use the HeaterMeter colors, any of the color schemes. However if you come up with something better, I might want to steal it to use in a webui redesign.

The authentication system is pretty easy. Any page can be POSTed to with username and password to get access. From the returned page, you'll want to save the sysauth cookie and parse the ;stok=(hex)/ from the returned url. Both these should be included in subsequent requests. You can get by without that but each request creates a new session and each session is checked for validity on every request so your app makes the server run more slowly with each request unless you do the right thing. It's not like doing the right thing is at all difficult though.

Because any page take an authentication POST, just POST to the /lm/set page as well. /lm/set will take a POST and actually in the future will require a POST and not a GET, so code for the future now.

The configuration in JSON format is at /lm/conf
 
I've been working a lot on my 3D printer so I guess HeaterMeter is taking the back seat a lot. It sort of forms a stack. HeaterMeter -> Servo+Blower Damper -> 3D Z-axis autocalibration. I have made some minor changes though.

I've reduced the footprint of the Thermocouple code by about 20%. The code supports mV/C @ 3.3V ref (AD8495 would be a '5') as well supporting arbitrary references and slopes by supplying Vref / slope instead of mV/C.

I've been playing with another idea to more reliably start the blower from 0% to any low %. Most blowers will run with ~6V but won't be able to kick on unless they're getting ~7V. The experimental code determines if the blower is leaving 0% and kicks the blower up to 100% for a short period before setting it to the proper value. Right now it is 125ms. The challenge is supporting inverted output and max blower speed without adding a lot of overhead to the codebase. Without supporting those features, there's about 20 bytes of code, 1 byte RAM. That feels about right. With the features, it adds 70 bytes. That's too much!
 
These changes have been pushed:
-- Don't fully cut integral sum when reaching temperature for the first time. You may notice when HeaterMeter is heating up, as soon as it hits temperature the I term is completely zeroed out. With our new servo dampers, this cuts the fire so quickly that it doesn't have enough time to build up before the lid detect mode kicks in. The new code just reduces the integral sum when the setpoint is reached which should reduce the chance of lid detect going off on the first cycle. This reduction may need to be reduced further if it still happens, but not so much that pure blowers with not enough restricted airflow overshoot by too much.

-- Entering 0mV/C for thermocouples would just give you bad results (the calculation would use 1mV/C). Rather than do the wrong thing, now we don't care if you give us 0mV/C, you'll get completely bonker numbers. Either way you get wrong data, but this way saves code space!

-- GRILLPID_FAN_BOOST_ENABLED when the fan is turned on now, it boosts the fan to 100% for 125ms to get it spinning. This reliably activates my blower, which has gotten gunked up to the point it needed 15%+ to spin reliably, as low as 3% speed. 2% almost works. I might lower the default min fan speed to 7% or even 5% for better low-end control. It ended up taking 46 bytes, 2 RAM.

-- Optimized some time calculations to reduce code size by... 46 bytes. Coincidence!

Unpushed changes:
-- lmclient can now read messages from linkmeterd larger than 8k. I may reduce the buffer size to 4k to reduce lua memory pressure. This is just something that has been eating at me for a while. It seemed to discard any chunk you didn't read from the unix datagram socket, but actually it just discarded any extra data that was written atomically. If you write 8k but only read 4k, you can't go back for the other 4k, it's just gone. The trick is just to split the writes to the same chunk size because the kernel won't split a write into two reads but it will hold a pending read for you if the chunk is left intact.
 
Getting closer to making that alarms configuration from the previous page a reality, it is no longer a mockup. About 80% of that is now properly linked to the configuration through the cbi system. The bottom parts are backed by the uci configuration system, the /etc/config stuff.

The top parts, which are backed by data in HeaterMeter are more fun because they need custom code to let the cbi system access them. That's coming along to the point I can read it, and it shows up untemplated. I'll need to modify the template get it looking right, and the write() code needs to be done. CBI is pretty great, but I can't get it working with knockout.js without duplicating some code. I think I may be able to figure out a better way once I get the template done.
 
I think the Alarms configuration page is done. Everything here is fully functional, storing the config as needed to either /etc/config or to the HeaterMeter


I ended up dropping knockout.js because LuCI CBI handles everything except the enable/disable button so I didn't see any point in adding all that code just for that. I've saved it for later on when the webui is completely redone someday. The alarm alert manager also has all the code to make it work too, email, sms, and setpoint changes.

I still need to update the installer to provide some default config, and I want to move the linkmeter settings out of /etc/config/lucid and into /etc/config/linkmeter. While I'm at it I'll make the changes to install the default config items for upgrades as well. I have to look through my todo list but I think that's going to be everything for the next package version.
 
Last edited:
How about an "other" for the SMS field where I could fill in my own email address. I have my (tmobile) setup so you can't SMS via the normal @tmomail.net address. But I do have another email that will work.

That, or maybe make a way to customize the email so it's short and sweet.

Thanks, this looks awesome.

job
 
It is all customizable, you can write whatever you want in the email box. You can put it all in the subject if you want!

The "other", as I said, is complicated. I might take a crack at it for this version, but I'd rather focus on getting the rest taken care of.
 
I was fixing a bunch of corner cases in the alarm page on a "clean" install, and hacked out a way to get Other provider working I think. Don't need all the world's cell providers after all.

I've also added a "Test" button to force a trigger of the specified alarm directly from the webui. If you're like me you had a hard time testing your email configuration by cooling and heating a probe just to get it to trigger. Just press a button and see if you get the message now. Also the output of the alarm system is sent to the "System Log" so you can check for what error occurred rather than sitting around for 10 minutes waiting for an email that never comes.

I've also fixed the issue where autobackup wasn't working on upgrade installs I think.

Been a busy week so far for HeaterMeter. Over 20 hours of work. 681 additions, 138 deletions.
 
You must log in or register to reply here.

 

Back
Top