It was the best of times, it was the worst of times....


 
P

Phillip P

TVWBB Fan
Last weekend I had a great gathering of folks over.

Some butts and ribs were in the smoker and temps had been holding (moderately) well all day.

About an hour before things were to be pulled out, a friend who had imbibed a few too many microbrews stumbled through the pit area and managed to catch his foot on the blower lead to the fan. The subsequent crash signalled catastrophe. The leads had been pulled clean out of the blower. The Heatermeter had crashed to the ground and all the probes pulled out of their jacks.

The case had some scuff marks on it, but I plugged it back in and it came to life. I plugged back in the jacks so that I could at least monitor the pit temps, even without the blower running.

When I tried to get into the HM via the web, I got some very strange errors that I wish I had screenshots of. No dice on SSH either. I surmised something had gone wrong with the RPi, but that the heatermeter board itself was still functional.

So, I monitored the temps from the LCD and finished up the cook the "old fashioned way"

Today I finally had the time to take a look inside the case and came to find out that the SD card had been semi-ejected from the jack. Plugged it back in and, voila, everything came back to normal, except for this:

BBQ1.jpeg


The strange characters on the lower level of the LED display did not do this immediately after the accident, only after opening the case.

Once the RPi boots up and gets its IP address, the second row seems to be okay for a moment:

BBQ2.jpeg


However, once we get back to the monitoring screen, things are jacked up again.

My 4 way button has *never* worked, so I haven't been able to check any other screens. This situation has been workable since I have always used the web interface. I was hoping to fix that while I have it out of the case. It looks like the solder didn't make it through the PCB to fill the gold contacts on the other side.

Any thoughts would be truly appreciated.

Thank you,
Phillip
 
After just coming across this error when trying to get to the services tab in the web interface, I think I will give that a shot:

/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute firstchild dispatcher target for entry '/admin/services'.
The called action terminated with an exception:
/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute cbi dispatcher target for entry '/admin/services/msmtp'.
The called action terminated with an exception:
/usr/lib/lua/luci/cbi.lua:838: table index is nil
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:195: in function </usr/lib/lua/luci/dispatcher.lua:194>
 
Regarding the 4 way button, ensure you have it correctly oriented.

The middle pins are just slightly closer to one side than the other, as are the holes on the PCB, though it's easy enough to put the button the wrong way.
 
Tragedy! Alcohol is both the BBQ's best friend and worst enemy.

I've broken the wires on my blower a couple of times just because I'm always dragging it around either to work on HeaterMeter or to cook with. If you peel the label back slightly, the connection points aren't too difficult to solder. There are 3 terminals. I assume one is for a tachometer, but the two left-most (looking with the label oriented correctly) are the two you want:


As suggested, I'd re-image the SD card, flip over the button, and then use the HeaterMeter menus to "reset config". I suppose I should add that command to the serial interface for folks with non-working buttons.
 
DOH!

So, should your LED ever look funky and say stuff that it shouldn't, you *might* want to check your configuration and make sure that the Name corresponding to that sensor doesn't look funky and say stuff unexpectedly.

I re-imaged the card, everything was great! I restored my configuration and the problem returned! I then went to the home screen and noticed that the probe name was funky as well. I went to the configuration and, lo and behold, the name of the probe was "ambient -4." I dont know how that ever happened, but it did. I dont know where the weird underscore, comma, decimal and numeral "1" came into play, because that was NOT in the probe name. Anyway, changed the probe name back to just "Ambient" and everything seems to have righted.

Now, the button. That damned button. In my attempts to de-solder and remove it to turn it around, I managed to not only slightly melt the RPi socket (still works fine, just a bummer) but also destroy one of the leads on the button. So, new part is being ordered.


Leads re-soldered to the fan no problem.

Bryan, when you gaze into your beer-infused crystal ball, do you believe that HM 4.1 will be re-purposing much of the same parts? I was thinking to go ahead and just put in a fresh order for the whole shebang and await the new board as most of the parts appear to be in stock at this point. I am sure there will be some additions and deletions, but if it is close to 85% the same, I would rather have them on hand when the board comes out.

Thanks everyone!
 
Back to the services error. After setting some alarms and not getting my SMS's, still getting this:

/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute firstchild dispatcher target for entry '/admin/services'.
The called action terminated with an exception:
/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute cbi dispatcher target for entry '/admin/services/msmtp'.
The called action terminated with an exception:
/usr/lib/lua/luci/cbi.lua:838: table index is nil
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:195: in function </usr/lib/lua/luci/dispatcher.lua:194>

I guess I will re-image and rebuild the configuration from scratch.
 
EDIT: I subsequently re-imaged from the web interface with the "Restore Settings" box unchecked. That did the trick.


Well,


I re-imaged the card, followed the norestore steps in the wiki, but somehow the configuration persists. Any thoughts?


How do I prevent config restoration?

If you've messed up your configuration so badly that your device become inaccessible, you probably don't want that configuration restored when you reflash the SD card. To prevent the restore operation, add the flag norestore to the kernel command line (_Requires LinkMeter v8 or above_). This can be done after flashing the SD card, eject the card, then reinsert it and you should see a small FAT filesystem which contains a cmdline.txt file. Open this in any text editor and append norestore to the existing line:

dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait norestore

Configuration backup will still occur when the norestore option is specified on the command line.
Click to expand...
 
Last edited:
I've not been able to reproduce the configuration coming back problem. If the msmtp is the only thing wrong, maybe you can ssh in and post the contents of the file /etc/msmtprc? Seems like my careful error checking isn't enough.

The v4.1 will have almost all the same parts. There will be a few more parts added, and the MOSFET will more than likely be different and incompatible.
 
You must log in or register to reply here.

 

Back
Top