HeaterMeter on the Raspberry Pi Model A+


 
Edimax is all I have and it connected on first boot without any issues. In fact, this was the first time I used AP mode wirelessly to set-up the initial Wireless settings.
 
Well here's your problem right here!


Also documented on the RPi Forums. Welp dangit. Can't we just get a working wifi adapter with decent drivers?!

EDIT: Reading that thread I see we are using the same firmware they are complaining about and there is a slightly newer version
Code: 
wget -O/lib/firmware/rt2870.bin http://capnbry.net/linkmeter/rt2870.bin

I'm going to try this when I get home tonight for sure.
 
Last edited:
John Bostwick said:
Edimax is all I have and it connected on first boot without any issues. In fact, this was the first time I used AP mode wirelessly to set-up the initial Wireless settings.
Click to expand...

So AP mode is working now with the Edimax? I tried a few times with no luck then changed to the RT5370 and it worked right out of the gate...
 
RalphTrimble said:
So AP mode is working now with the Edimax? I tried a few times with no luck then changed to the RT5370 and it worked right out of the gate...
Click to expand...

I guess, I only have Edimax adapters and it was my first time using wifi to set up the Heatermeter, I was always using a cable before trying AP on the A+
 
It seems like only on the A+. I have a model B HeaterMeter as well so I took the adapter out and put it into that device, 2 days, no problem. I put a different RT5370 adapter into the A+ and it died about a day later, then again in under 24 hours.

Tonight I will try putting some extra power draw on the 5V line. I would like to see if there's just a problem with the regulator not being able to supply a power spike when operating at such a low current.
 
I put 78 ohms on the 5V line (64mA) and it crashed in the night. To see if the idea has any merit at all I lowered that to 16 ohms (314mA) and we'll see if there are any crashes.

Oddly enough I put the RT5370 adapter in my Pi B-based HeaterMeter and it has been running fine for 3 days. I really hope it isn't a low power draw problem.
 
I've used a RT5370 adapter on my Model B and have had no problem keeping the HM online for weeks at a time, with the A+ the connection dies after about 12 hours every time. So I know the adapter works well with the B, not sure what the problem is with the A+.... but I am doubting it is a power issue, I'm thinking there is something different about the A+ that chokes on the driver eventually (hopefully, cause drivers can be fixed)...
 
Let's see I booted the Pi at 7:10am, and it was down today at 3pm, even with the additional 314mA current draw. I need to find my regular A and try it as well.

The B models (B and B+) the USB ports actually connect through a hub chip on the device that also has the ethernet on it. It is possible this is a problem with the Wifi adapter being connected to the USB host in the bcm2708 itself. "Vendor Request" is a USB term as well, and this would be their custom request 0x7 for index 0x101c is failing with -110 ETIMEOUT. It might be something fixed with later Pi kernels but golly we can't really fix that.
 
Well, at least we should try and get this issue nailed down and reported to the rPi development team if it isn't already, so there is a chance it will get fixed. On the bright side, as it is my A+ will stay online at least 12hrs with the RT5370 which is long enough for most cooks, and even if the WiFi connection drops the HM will still manage the pit properly, but you will miss out on alerts and remote monitoring at that point. At least it's not a "fatal" flaw....

John B said he booted up his A+ with the Edimax and was able to connect to it in AP mode, did you get AP mode fixed up on the Edimax? If AP mode works reliably on the Edimax than that would be the way to go with the A+ until the bug gets worked out at least...
 
And guess what! The regular A died with the same error after only 2.5 hours. Clearly there's an issue with the USB host interaction with the adapter. I don't think it is something we can push upstream because they'll ask "what kernel are you on?" and we'll say "3.2" an they will laugh. There have been a lot of changes to the USB layer in the past year so "all we have to do" is try the latest kernel to see if it fixes it. Easier said than done because we can't just drop it into place, all of OpenWrt is tied to a kernel version.
 
Does restarting network services fix it? If so, that's a pretty simple workaround that can be added with little effort.
 
So, this error has been here all along, with the A version. I wouldn't say that this is a big issue then, except you better use an cheap Edimax adapter with an A, and A+.
 
Steve_M said:
Does restarting network services fix it? If so, that's a pretty simple workaround that can be added with little effort.
Click to expand...
There's only one USB port on the Pi A, so there's no way to plug in a keyboard to fix it, and no network access.

Regarding the Edimax adapter in AP mode. I just booted a fresh A+ install with the Edimax installed and it worked in AP mode. I was able to connect and join my existing wifi network with no problem. I know I did some driver updates like a year ago but never reevaluated them. I thought the 4.0 driver had bigger fixes in it and we're building on 3.4.3 still.

In any case, it looks like the Edimax works well enough in AP mode to configure initially so, shrug, let's see if it stays running now.
 
I have this as a cron job running every 3 minutes

Code: 
# crontab -l
*/3 * * * *  /mnt/mmcblk0p4/net-watchdog.sh

# cat /mnt/mmcblk0p4/net-watchdog.sh
#!/bin/sh

test_host=$(netstat -nr | grep "UG" | awk '{ print $2}' | xargs ping -q -w 1 -c 1 | grep "received" | awk '{ print $4 }')
if [ "$test_host" == "0" ] || [ -z "$test_host" ] ;
then
/etc/init.d/network reload
sleep 60
test_host=$(netstat -nr | grep "UG" | awk '{ print $2}' | xargs ping -q -w 1 -c 1 | grep "received" | awk '{ print $4 }')
	if [ "$test_host" == "0" ] || [ -z "$test_host" ] ;
	then
	/sbin/reboot
	fi
fi
 
Oh nice! You could add a `logger` call in there after the network reload so you'd have something in the syslog about the network restart and you can check to see if it works from the webui (by looking for your log messages).
 
Bryan Mayland said:
In any case, it looks like the Edimax works well enough in AP mode to configure initially so, shrug, let's see if it stays running now.
Click to expand...
Both the A and A+ I have here have been running for over 2 days. I am going to call this a solution: only use 8192cu wifi adapters if you're using A/A+ Pi.
 
As I posted in this thread earlier, I had a problem using the 8Gig MicroSD card with the A+, it worked but would not save my password. I had no problem with the 4Gig MicroSD card however... Well, suddenly the 4Gig card stopped booting, I tried to re-image, no dice. I noticed the Disk Imager was really slow to write to the card after it started screwing up...

So I looked into the Disk Imager to see if perhaps there is a newer version, 'cause maybe it has an issue with the MicroSD cards. I found Disk Imager v0.9.5 is available, what I had been using was v0.7. So I image the 4G MicroSD with the new disk imager, which goes fast again so I am hopeful.... Still no dice, the rPi A+ will not boot from this card, I have no idea what happened to it... I decided to try the new imager with the 8G MicroSD, the rPI A+ boots from this card and now I can save my password! Not sure what the deal is/was, but the new disk imager fixed the problem with the 8G card but didn't help with the 4G....
I thought I would post this info here in case someone else runs into trouble with MicroSD cards on the A+, perhaps the newer disk imager will help you....
 
Now that I got my 8G MicroSD card working on the A+ I started to dig into what went wrong with the 4G card that had previously worked... Turns out this card somehow got into write protected mode and I can't manage to get it out. These MicroSD don't have a convenient slider tab to write protect, everything I've tried to remove the write protect has failed. Searching the web it seems I am not the only one having this problem, I guess lots of MicroSD cards have become locked down without explanation, at this point I guess I just need to chalk it up as a bad card. If anyone knows a trick I may not have tried to unlock this card I would appreciate the advice...
So, if you have an A+ (or B+) and suddenly your HM wont boot (HM functions but rPi doesn't fully boot so you cannot load the web interface), first thing I would do is connect the MicroSD to your computer and try to format the card. If you cannot format the card and it tells you the care is read only or write protected then "there's your problem"....
 
You must log in or register to reply here.

 

Back
Top