Stable Firmware Release v14


 
You should be able to use the most recent firmware, however, you would have to make sure not to set the blower in Voltage Mode, you need to use Pulse Mode because the HMv4.0 does not have the feedback circuit for the blower.

I just looked at the online repository and find it odd that the last release version was in Feb 2016, but that is what I am seeing. I would suggest you use the latest snapshot release, which is dated April 2019, I always run snapshots on my HM and find them to be very stable.

The HM update process has changed a bit since the 4.0 days, heatermeter.com/dl may be more up to date than what you are seeing in the online repository through your HM. If your HM software hasn't been updated in a long time you might want to go to heatermeter.com/dl and download the most recent release (I suggest latest snapshot) to update your system, make sure to select the proper rPi board before you download. (BTW latest release version on the above link is Oct 2017, I would still use the latest Snapshot release) You can either DOWNLOAD an image to write your sd card (via PC Win32DiskImager etc), select your rPi model and preferred wifi settings before you download... or you can click on the download.gz icon to download an image that you can flash via HM @ Config/System/"Backup / Flash Firmware".

BTW if you are interesting in tinkering with your HM here is a link to a thread I made which details how to update your HMv4.0 hardware to the current hardware build.

https://tvwbb.com/showthread.php?50543-HMv4-0-to-HMv4-1&highlight=HMv4.0+to+HMv4.1?

It involves installing the RC filters on the probes and upgrading the blower circuit to the current hardware version. The RC filters are cheap and easy to install, probe stability will be improved with this update, highly recommended... The blower update is more difficult, benefit is you can use Voltage Mode for the blower, which creates less noise on the probes. If you do the blower circuit update make sure you follow the thread far enough to get the HMv4.2 update, the thread details updating from v4.0 to 4.1, and later to v4.2....
 
Last edited:
Hi Bryan,

I was wondering if you noticed a bug in your heatmeter firmware. When configuring alarms, specially an SMS text alert for probe 1 low and high temp alert this is causing the pit setpoint to change.

When I set the value to 150F hit save and apply, then enter 165 for high value and hit save and apply. This caused the pit temp setpoint to change to 165F. I was doing a live cook with a setpoint of 225F for my brisket and then I noticed that the setpoint changed to 150 and then to 165. I was looking at output saying 0%, but I wasn't at target temp of 225F. But then I noticed that the setpoint had changed to 165F.

See image:
https://photos.app.goo.gl/UDjVDTcfFwF8HWEc9

I'm running the latest development build with a date of: May 20 2019 14:47:19 PDT
 
Last edited:
I can't reproduce this at all. The SetPoint change only can happen if the alarm fires, which includes pressing the TEST button on the far right. If the setpoint is changing, that means that the alarm is firing to make it change.

If you're sure that you didn't use the TEST button when saving, then maybe post a screenshot of your alarms settings (just the grid at the top) and I'll set mine up identical to yours and give it another try.
 
I just updated the HM firmware from https://heatermeter.com/dl/. I loaded the file using the web browser and pointed to the v14 release. The previous version was from the 2016 timeframe (v11 I think). After the update, the extra packages that I installed from the System>Software menu were no longer installed. (I had installed Python-mini and "bc"). I have tried to load the available packages list, but nothing shows up in the tabbed A-Z index like it previously did. There are bunch of urls in the configuration menu where it gets the feed and the status says it downloads the list, but nothing shows up. I do know the "linkmeter" url was throwing an error.

Not knowing exactly what I am doing I did play around to load it manually using "opkg update", the list was shown as downloaded. Then when executing "opkg find python" to test the list update, a response of "Segmentation Fault" was shown in the terminal window command. I'm not sure if this is related.

I tried again by reflashing the SD card with the "latest development release" using the win32 imaging tool, but now I think all of my network settings were overwritten and need to log back into it to determine what is going on.

Is there something missing or any suggestions on how to get the available packages to work again?
 
I don't think installed packages ever translate over from release to release, only the configuration is backed up and restored on upgrade. That goes doubly because the older HeaterMeter releases had no way to track filesystem changes and only backed up the /etc/config directory. The v14 and snapshot use the new overlay filesystem method so it has a better idea of what to copy over when upgrading, but I'm almost positive it still doesn't do installed packages. When you upgrade you'll have to reinstall them each time, someone can correct me if I am wrong.

I also think you have to comment out the linkmeter package definition in the list of package sources. I can't comment it out in the build because then the LEDE build process turns off all the HeaterMeter packages and doesn't include them, but at the same time if you have it defined, the opkg update fails because there's no linkmeter source in the official LEDE repository. Just put a # in front of the line and give it a try.

If you ever use the Win32DiskImager tool to flash the SD card, it wipes the filesystem completely. All network settings, configuration, installed packages, and any edited files are reset to default. If you download a pre-configured image, those are applied on top of the default config, so the same warning applies.
 
Bryan Mayland said:
I also think you have to comment out the linkmeter package definition in the list of package sources. I can't comment it out in the build because then the LEDE build process turns off all the HeaterMeter packages and doesn't include them, but at the same time if you have it defined, the opkg update fails because there's no linkmeter source in the official LEDE repository. Just put a # in front of the line and give it a try.
Click to expand...

I'll try again with the development version. I did comment out the linkmeter URL and rebooted several times, but no luck with loading a list of packages. Commenting it out does remove the error that I was initially seeing.
 
ScottZ said:
I'll try again with the development version. I did comment out the linkmeter URL and rebooted several times, but no luck with loading a list of packages. Commenting it out does remove the error that I was initially seeing.
Click to expand...

Still no luck. This is a fresh image v14 release that it quite working on. The previous release ~v11 worked ok. I did restore a backup from v11 to v14 and then the packages were populated, but the linkmeter tab was empty saying it couldn't communicate with the AVR. So I reflashed it and the linkmeter is back, but no packages are available. It shows success on downloading the lists after pressing the Update lists button, but the A-Z list is empty/none.

Code: 
General options: (nothing changed)
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
option check_signature 1

Distribution feeds (commented linkmeter, uncommented last two)
src/gz reboot_core [url]http://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages[/url]
src/gz reboot_base [url]http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base[/url]
# src/gz reboot_linkmeter [url]http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/linkmeter[/url]
src/gz reboot_luci [url]http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/luci[/url]
src/gz reboot_packages [url]http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/packages[/url]
 
I just took a fresh clean snapshot install (Win32DiskImager written, but shouldn't make a difference), went to System -> Software and hit the "Load lists" button. Waited and it all completed successfully, then searched for python-light and it was there ready to install, same thing with bc. When I looked at the A-Z list there was nothing there at first, but after a few seconds it loaded (3 seconds thereabouts). I didn't edit anything apart from setting up the wifi.

This was on a Pi Zero, which looks like what you've got (or an original Pi A or B), right?
 
Bryan Mayland said:
I just took a fresh clean snapshot install (Win32DiskImager written, but shouldn't make a difference), went to System -> Software and hit the "Load lists" button. Waited and it all completed successfully, then searched for python-light and it was there ready to install, same thing with bc. When I looked at the A-Z list there was nothing there at first, but after a few seconds it loaded (3 seconds thereabouts). I didn't edit anything apart from setting up the wifi.

This was on a Pi Zero, which looks like what you've got (or an original Pi A or B), right?
Click to expand...

I am using the Pi A+.

I tried the V14 image a few times again with no luck. I also swapped out for a fresh SD card with the same result. For some reason I cannot get the packages to show up like before. I am out of ideas after spending a couple hours trying different things and even trying to revert to an older image, but the HDMI doesn't want to work so i can configure the network settings. Frustrating in trying to recover a good configuration again.

Code: 
Downloading http://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_core
Downloading http://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages/Packages.sig
Signature check passed.
Downloading http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_base
Downloading http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base/Packages.sig
Signature check passed.
 
Last edited:
I finally got v12 successfully reinstalled and the available packages work fine. I think I'm going to stay at an older version.
 
I just tried v14 release and I have the same issue where opkg segfaults when trying to do any list function. I checked the config and package list settings versus the snapshot and tried configuring them the same but it still doesn't work. Is there a reason you've not tried the snapsnot firmware instead of rolling back versions? If there's a problem with the snapshot (which I don't see) then I can fix it going forward, but I can't fix anything in releases.
 
I am somewhat new to the software release process of heatermeter terminology.

I have tried both available Gzip'ed files using the preconfigured network download options at https://heatermeter.com/dl/. Both gave segmentation faults using opkg via command line and no packages listed in System>Software of the web interface. I will try the snapshot again though as I spent 99% of the effort on v14 and the details on the various combinations are a little fuzzy now.

- Latest stable release(v14)
- Latest development snapshot
 
I don't have an A+ that works any more, but I tested with a B+ which is somewhat closer to an A+ than a Zero is. With the "Latest development snapshot" it doesn't have any issues loading the software list and populating the webpage. No changes necessary to any of the package configuration. I know you've put a lot of time in on this already but if you could give it one more try with the snapshot and let me know how it goes. If it still doesn't work, I'm not sure where to go from there though, but hopefully it will? (optimistic uptick in voice)
 
I am happy to report that the development snapshot successfully loads the optional packages on the A+.


I seemed to have misreported my results above using the snapshot version. Version v14 definitely does not work for me. Staying up to 2am trying various things may have something to do with not being successful.


I have found that the rc.local now behaves differently in this version. I try to call a script to set the initial temperature setpoint, but the setpoint never changes the temperature. Doing a chmod 755 rc.local and executing the script at the command line ./rc.local, it works fine. It has a command to the lmclient to set the setpoint to 50F (off). I added an "echo script test" to the startup and see the text in the system startup log, so I know that rc.local is successfully called. I'm guessing the heater meter client is not up and running by the time I try to call it. Adding a sleep 20 in the script before the setpoint command didn't help either. It seems like the loading of processes in the newest version is different than the old v12 that I was using.
 
You're right about that, the load order has changed since v12. I took a look at it and looks like I've got the linkmeter service starting too late such that it happens after rc.local executes. I'll push out a new snapshot today that fixes the ordering so linkmeterd will be available, but you can fix this on your system without going through the upgrade by just doing this:
Code: 
rm /etc/rc.d/S99linkmeterd
ln -s ../init.d/linkmeterd /etc/rc.d/S70linkmeterd

You may need a small sleep of 1-2 seconds to make it work 100% reliably. I didn't need it testing on a Pi 1B across 3 reboots, but each time the command happened the exact second that linkmeterd was fully running so I could see it failing every once in a while. You could also get fancy and keep sending the command every second until you get an "OK" response, but that seems unnecessary.

Another way to turn the HeaterMeter off is to set the setpoint to the letter O `lmclient LMST,sp,O`which turns off the HeaterMeter instead of lowering the setpoint. To toggle "Off", long press the left button / left direction on the device or any setpoint change will re-enable control. Toggling "Off" saves the old setpoint so it can be resumed which could save you having to go into the menus to set it once you're ready. Note that the Off state does not persist across power cycles-- it will go back to the previous setpoint on the next power up.

EDIT: Snapshot firmware updated with this change.
 
Last edited:
I tried to push the latest snapshot firmware to my HM today and it reported the following error:

"Stopping LinkMeter OK

LinkMeter platform is BCM2708
Loading SPI modules...
AVR fuses ffd705 OK

e5e698684db6ea51f348e5e8a643ced5 /tmp/hm.hex
hmdude: compiled on Feb 14 2020 at 20:52:06
hmdude: invalid record at line 658 of "/tmp/hm.hex"
Using port: /dev/spidev0.0
Update successful
Starting LinkMeter OK"

I am running a rPi zero-w with HMv4.2.4.

It says the update was successful but after the update I am no longer seeing the temp for any of the probes on the graph and the time is showing in red. I've rebooted the system and get the same result. I tried to flash the last snapshot I have in my download folder and am seeing the same result as above from that now too.... Not sure if it is my system or if the last snapshot broke something that I can't walk back? I'll report back if I find a solution.

Happy Independence Day to everyone, hope you're smoking up something good!
 
Last edited:
Ralph,

I just downloaded http://heatermeter.com/devel/snapshots/bcm2708/openwrt-bcm2708.gz and updated my Pi Zero W and then performed a flash and it was ok.

Code: 
Downloading 'https://heatermeter.com/devel/snapshots/trunk/heatermeter.hex'
Connecting to 18.234.176.243:443
Writing to '/tmp/hm.hex'

/tmp/hm.hex          100% |*******************************| 70971   0:00:00 ETA
Download completed (70971 bytes)
Stopping LinkMeter OK

LinkMeter platform is BCM2708
Loading SPI modules...
AVR fuses ffd705 OK

                          0437da74bfe4b2112c42b74d514cfe18  /tmp/hm.hex
hmdude: compiled on Jun 28 2020 at 11:54:16
Using port: /dev/spidev0.0
Loading ihex file: "/tmp/hm.hex" (25222 bytes)

    0% |                                                  |     0 (0.0s)
    0% |                                                  |     0 (0.0s)
    5% |##                                                |  1262 (0.1s)
   10% |#####                                             |  2524 (0.2s)
   15% |#######                                           |  3784 (0.3s)
   20% |##########                                        |  5046 (0.4s)
   25% |############                                      |  6306 (0.5s)
   30% |###############                                   |  7568 (0.6s)
   35% |#################                                 |  8828 (0.7s)
   40% |####################                              | 10090 (0.8s)
   45% |######################                            | 11350 (0.9s)
   50% |#########################                         | 12612 (1.0s)
   55% |###########################                       | 13874 (1.1s)
   60% |##############################                    | 15134 (1.2s)
   65% |################################                  | 16396 (1.3s)
   70% |###################################               | 17656 (1.4s)
   75% |#####################################             | 18918 (1.5s)
   80% |########################################          | 20178 (1.6s)
   85% |##########################################        | 21440 (1.7s)
   90% |#############################################     | 22700 (1.8s)
   95% |###############################################   | 23962 (1.9s)
  100% |##################################################| 25222 (2.0s)
Update successful
Starting LinkMeter OK
 
Thanks for reporting the snapshot is valid.... Looks like I've got something going on with my HM software build, after the flash I get blocks on the LCD like I have a blank AVR. I swapped in a different ATMEGA which booted and was working, then I tried to flash the firmware I had been using to this AVR and got the same error and black LCD, hope I didn't kill two ATMega's!?!?
I tried to flash the reset-eeprom from the online repository but it is reporting invalid SSL certificate, Download failed. I can't download anything from the online repository, same error? Is there a fix for this? Do you happen to have a copy of the reset-eeprom file to share so I can try to revive these AVR's?
I'm going to try a fresh build in the SD card and hope that it is able to write the AVR's back to normal.
I'm open to suggestions to get over this issue....
 
The fix for the SSL error is you need to update the RasPi firmware with the latest development snapshot. Bryan pushed an update to fix the SSL issue on June 28th.
 
Last edited:
You must log in or register to reply here.

 

Back
Top