Some good news: The Raspberry Pi Zero does work. Today I for fun plugged in my Zero that I thought was blown up and low and behold it was still working. Meanwhile I also was able to get hold of an Edimax Wifi Dongle (as specified by Astroprint) and so I installed a fresh image on the SD card, went through the setup procedure and low and behold it now works just fine. So for all of you wanting to go a “cheap” route - once the Zero is available again that is - it does work.
1 Like
Holy shit. That’s great news. So you just bought a Pi Zero and this WiFi dongle and a Micro USB to USB cable for the printer and that’s it?
Here is how I set it up:
I have a small USB Hub from Staples. I 3D printed a small shell so the Hub is mounted in there with the Zero screwed in on top of it. The Ramps control board is connect to the Hub, and it powers the whole setup. Therefore one of the hub outlets is actually connected to the power port of the Zero. This way I prevent the possibility of powering the whole Ramps board through the Zero should I forget to power down the printer first.
The USB port on the Zero is connected to the input line of the hub. Additionally I have a webcam connected to the third port, and in the front port there is the Edimax Wifi dongle (I bought mine through Sparkfun, though).
As I mentioned in the other post, I did a clean install of the Astroprinter server, and everything works like a charm now.
If there is a way to upload a picture I’d be happy to post one of the setup.
Wolfgang
1 Like
Yup. Would be cool. You can certainly post pictures on this forum 
This is my first experience with AstroPrint. I have used OctoPrint in the past with good results.
I am having the same issue. Downloaded the 8.3 image and it worked fine. Wouldn’t upgrade to 8.4 unless I plugged into ethernet. Then, after upgrading and a hard reboot it fails to connect to my wifi network saying that the password is incorrect. Same behavior after re-flashing the sd and trying all over again.
Here is what I tried while connected to ethernet:
- sudo apt-get update
- sudo apt-get upgrade
- sudo apt-get install ntpdate
Reboot
Still will not accept my known good wifi password, whether connected to ethernet or not.
It seemed to be having network problems on 8.3, which is why I went to 8.4. Switching to OctoPrint.
I’m also experiencing some date-problems. It keeps resetting on reboot, even though I manually start ntp.
I could install it in one location earlier, but at my office I’m having some issues. I’m not really sure why though;
-
The time and date is set to
Wed Sep 9 20:30:10 2015 -
I logged in with SSH, and ran
sudo service ntp start -
Then the AstroBox webpage wouldn’t work, so I ran
sudo service astrobox restart
And now I could update to 0.8.5.
Now I can’t run “apt-get update” though, I get an error:
E: The method driver /usr/lib/apt/methods/https could not be found.
And when I reboot it’s back to either the 2015-date, or 3-4 days back.
It makes absolutely no sense 
But there is definitely something strange going on there…
1 Like
Yeah, that’d probably work, I just mentioned it because it happened after upgrading to 0.8.5…
Btw, is there any chance that you could create a new image, alternatively, is there a guide to install it from scratch?
I just keep having that NTP problem for some reason.
We’re going to create a new image for 0.9 which will include NTP. We don’t plan to create a new image for any of the 0.8 releases as these are not major releases
Cool!
It COULD be that there are some weird things on the office network. When trying to install at home, it works perfectly! UTC time was updated, but wrong timezone (which can easily be fixed with raspi-config).
I don’t know exactly why it shouldn’t work, because if I restart the NTP and then Astrobox services, it works… But after a reboot, the time is off again.
I can’t quite understand where it gets the wrong time from, as it works as intended on my home network.
I’ll check out the office network before I keep complaining to you guys 
BUT! The error does come after updating to 0.8.5, it works before updating:
E: The method driver /usr/lib/apt/methods/https could not be found.
I just thought you’d like to know
The fix is simply the command:
sudo apt-get install apt-transport-https
Thanks for this. We did add our own ppa to the apt sources on 0.8(5) it was done using https not realizing that the transport was not installed 
I’ll fix that.
Hmm, still problems with date at work. The NTP service is always stopped at boot, and time/date reset to the original image’s time when created.
If I start the service, then restart the astroprint service, it’s working as it should, but after a reboot, it’s reset again.
I also tried running
sudo sync
sudo halt
but it was the same result after starting up again. It is strange, as it doesn’t seem to be anything on our network, still it only happens here, not at home 
Are there any other services that could conflict with NTP, and change the time on my raspberry? Something happens when it is booting.
Tried different RPi and different cards. Currently RPi 2.
Edit:
Paid extra attention when starting Astrobox service:
sudo service astrobox start [....] Starting astrobox: astroboxPING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. --- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Wed Sep 9 20:29:55 CEST 2015
. ok
What just happened here? Did it just reset the time when starting the AstroBox service?
Here’s the full log:
pi@AstroBox ~ $ sudo service ntp stop
[ ok ] Stopping NTP server: ntpd.
pi@AstroBox ~ $ sudo service astrobox stop
[ ok ] Stopping astrobox: astrobox.
pi@AstroBox ~ $ sudo ntpd -gq
ntpd: time set +14937730.997032s
pi@AstroBox ~ $ sudo service ntp start
[ ok ] Starting NTP server: ntpd.
pi@AstroBox ~ $ date
Mon Feb 29 16:57:27 CET 2016
pi@AstroBox ~ $ sudo service astrobox start
[....] Starting astrobox: astroboxPING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Wed Sep 9 20:29:55 CEST 2015
. ok
pi@AstroBox ~ $Oh crap, I missed that the ping test failed 100%.
I’ll have to look into that. Definitely some DNS here.
It COULD be the reason for that apt-transport-https thing as well, but I’m not sure.
I installed it again home, and apt-get update/upgrade did work without problems after 0.8.5.
Btw is it possible to set a static IP without ruining something in AstroBox? I can’t do it from our router atm.
The closest thing I can find, is that our firewall might be set to block ICMP-traffic.
Does AstroBox’s service rely on using this to start up? It seems like the image used shuts down the NTP-service, and does something with the time when it starts up.
Everything works as it should regarding DHCP and DNS here, NTP works as it should as well. But on AstroBox, NTP stops, and the AstroBox service seems to override the date settings.
So… Is AstroBox waiting for an ICMP_ECHOREPLY to start the service properly?
This is probably the case, we check for internet connectivity in this manner to know if we need to start the WiFi hotspot, as this would be the only way to access the box.
Regarding dates, when no internet connectivity is found, the last known date (the date of the image creation) is set as current date. Otherwise a device with no access to an NTP server would start with a date prior to the image creation and some things won’t work.
It does appear that the ping test is failing on your end and starting a sequence of unfortunate events… I have not encounter this before, I’ll look into a different way to detect connectivity, perhaps with a GET request to our servers…
I have added this issue to track this: https://github.com/AstroPrint/AstroBox/issues/85
Aha! Excellent!
I’m not crazy after all! 
NTP does work when starting the service though, so I’m not quite sure what exactly happens there when the AstroBox service starts. It always stops when AstroBox is started.
Atm. the date is always set to 28. Feb 2016. Not sure why exactly that is.
It also seems to reset the timezone, which I’ve previously set in raspi-config.
You should be able to re-create the issue by putting the RPi on a (wired) connection behind a firewall blocking all ICMP traffic.
Will my AstroBox still work as it should, except that some timestamps might be wrong and that it can’t update without being forced with the correct time? I haven’t tested it with a printer.
Btw, this could work:
#!/bin/bash
wget -q --spider http://google.com
if [ $? -eq 0 ]; then
echo "Online"
else
echo "Offline"
fi