Hello @Pbonamy !
From what version did you update?
Hello @Pbonamy !
From what version did you update?
I update from the version just before.
When I use /usr/bin/vcgencmd get_throttled in ssh it returns me 0x50000 so I the problem is not the plugin but my pi I go to investigate.
I reboot and now it's OK
The value reaets on reboot. It will be back.
Just FYI, there was a bug fixed with the plugin, as found in the Release Notes:
- Fix the navbar icons not becoming visible in case of observed issues
i am using a RP3 (maybe it's 3B, not sure). It works fine when it's on its own. Now, since i wasn't satisifed with the original RP cam, i bought my an USB light and an USB webcam as well. The RP now shows undervoltage warning and the webcam stream only works for seconds before it turns black. Surely it's an undervoltage problem now. I am using a phone charger which should provide 5V, 3A. At least this is written in the phone charger which enable quick charge for my mobile phone.
I guess the original power supply for the RP would not fix this, would it? How to solve it? Get a RP4?
EDIT: Thanks in advance of course!!
In all, it is a charger. These work different than a proper power supply/power adapter and are not appropriate to provide a constant current and a constant voltage over a longer period.
Also, 5.2 Volts are better than 5.0 Volts
The best i can find is 5.1V and 2.5A. Will this be suitable?
All others work via USB-C but my RP is powered via Micro USB..
Yes, this fits for the RasPi 3B.
Together with the camera it should work too.
But the USB light can bring it to the edge. But you may power that one with the charger.
There should be adapters
If the USB light is drawing too much current, using a powered USB hub might be a solution.
I have two Pi-3B+ OctoPi's running right next to each other and they have been close to two years. Both use "official" power supplies. One of them has a tiny LED light plugged into it that is not on unless it is dark or I'm making a video (usually I use a separately powered 120V light to light up my printers) and each has a webcam converted WyzeCam-v2 plugged into it that I use for OctoLapse etc.
Both of these printers have worked great from an "undervoltage/throttling" standpoint until a few weeks ago. First one started giving me the undervoltage symbol on startup, then about a week later the other started. No other changes have taken effect. No new loads on my electrical system etc.
Is it possible that something has changed in the code on the Pi side that drives this indicator? Thresholds lowered etc?
FTR, I have had ZERO issues actually using them despite the warning. They work fine. It's just annoying to see that pop up every time I turn them on!
AFAIK, the threshold is unchanged (~4.63v iirc), and I think that this was not something that could be changed in software and is more a hardware-level trigger, either undervoltage or not undervoltage. And even if it was software I can't see any recent changes that would impact this.
What has changed recently, was a bug fix in the Pi Support plugin that meant that a lot of the time the notification was not shown - see 2020.6.14 - so maybe you are seeing the effects of this.
I recommend fixing the issue, because the Pi does throttle it's performance to avoid brownouts, so it will be running slower regardless of whether you feel the difference. Maybe it is only for a short while (on startup as you say) but it still exists.
This is one of the most discussed topics here and I'd like to share my experience fighting undervoltage hoping it may help someone.
Initially, for about a year or so, none of 2 printers was reporting undervoltage, but later both started to show it. Voltmeter would not indicate anything abnormal - the voltage was within acceptable range (measured on GPI pins). So I concluded that power supplies became old and I am getting occasional drops of power during peak CPU loads. It worth mentioning that I never had a single print failure due to this.
At some point I decided to do something with this and went big - I replaced RPI power supply with LSR-75-5, 5V 14A power supply.
I used AWG20 about feet long wires connected via GPI and while such connection bypasses RPI's power filter, it should still work (which as become clear later is not the case).
I was running out of ideas and have to admit was close to the point when you question everything even the validity of vcgencmd. My final option was to solder power wires directly to RPI board. That's actually not easy because there is not a single good spot to solder +5v wire. I ended up connecting to Test Point 2 and voila - that solved the issue !!
Interesting. So you just soldered 20AWG to the 2 bottom side terminals ?? Which power supply are you using now....the one shown in the above pic?
I also have 2 PI3B+'s, that run a PI camera, and fan. I don't know how to do a "soft shutdown", so I just leave them running whether printing or not.. I've tried multiple power supplies including a desktop model that has adjustable output settings. I've tried everything up to 5v, 4a and still get the "under voltage" warnings. BUT...I've been connecting the power via a cutoff micro usb (I think it's a micro) connection. If I can just bypass the terminal and solder 20AWG to the bottom terminals, that should solve the issue ??? I have multiple power supplies I can use, since I leave them running constantly anyway.
I am currently using LRS-75-5 power supply as shown on the 2nd image from my post. Also powering up BTT TFT70 screen from it.
I ended up soldering only +5V wire and used GPI ground pins for ground wire.
For soft shutdown I have a button that needs to be pressed for 5 seconds to initiate RPI shutdown. Python script pasted below is executed on RPI startup and scans button state.
#!/usr/bin/env python import RPi.GPIO as GPIO import time import sys Buzzer = 35 # pin-35 BCM-19/GPIO-24 Button = 11 # pin-11 BCM-17/GPIO-0 Freq = 900 def setup(buzzer_pin, button_pin): GPIO.setmode(GPIO.BOARD) # Numbers GPIOs by physical location GPIO.setup(buzzer_pin, GPIO.OUT) global Buzz # Assign a global variable to replace GPIO.PWM GPIO.setup(button_pin, GPIO.IN, pull_up_down=GPIO.PUD_UP) def beep(buzzer_pin): Buzz = GPIO.PWM(buzzer_pin, Freq) # set initial frequency Buzz.start(50) # Start buzzer_pin with 50% duty ratio time.sleep(0.25) Buzz.stop() def destroy(): GPIO.cleanup() def loop(button_pin, buzzer_pin): n = 0 beep(buzzer_pin) # This causes beep @ boot while True: # the script will stop GPIO.wait_for_edge waiting for button_pin to go from high to low GPIO.wait_for_edge(button_pin, GPIO.FALLING) # starting the loop to make sure button is continuously pressed for 5 sec while True: if GPIO.input(button_pin): # button was released in less than 5 sec; going back to waiting for GPIO.FALLING n = 0 break else: n += 1 if n >= 5: # 5 seconds passed; shutting RPI down beep(buzzer_pin) time.sleep(1) from subprocess import call call("sudo shutdown -h now", shell=True) # print("Shutting down") destroy() sys.exit() time.sleep(1) time.sleep(3) if __name__ == '__main__': # Program starts here setup(Buzzer, Button) try: loop(Button, Buzzer) except KeyboardInterrupt: # When 'Ctrl+C' is pressed, the child program destroy() will be executed destroy()
I also have RPI camera module connected to one of RPIs.
Nice.....but that might as well be written in Chinese for me. lol. I know almost nothing about code. I can BARELY mange Marlin. It's just as easy for me to leave the Pi's running. After all, they are "little computers", right....they should be able to stay running.
Can you please explain how you did this?
There are few ways to do that. I opted for adding the following line to the root cronjob
@reboot /home/pi/addon_scripts/script_name >/home/pi/.octoprint/logs/cronlog 2>&1
FWIW.....I've been using the below power supply for almost 4 weeks (at the advice of someone from another forum), and have not seen any undervoltage issues show themselves. Considering my tests, I've been very surprised...but all I run on my 3B+ is a Pi camera, and a 5v fan.
what is the easiest way to see what is actually reported using
Hello @alistair92fr !
OctoPrint settings -> System Info (on the bottom) -> If you are V1.7 or later (or was it 1.6.2?): click
More info on that is here: