Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Burning rubber #5

Closed
atchoo78 opened this issue Jul 6, 2020 · 4 comments
Closed

Burning rubber #5

atchoo78 opened this issue Jul 6, 2020 · 4 comments

Comments

@atchoo78
Copy link

atchoo78 commented Jul 6, 2020

Could you please NOT secretly force change the GPIO settings for people when installing this extension? It just cost me 4 sensors, a neopixels shield and 2 rgb leds.

@Gadgetoid
Copy link
Member

Oof- sorry to hear that.

Installing this extension does not have any effect on GPIO pins. However, running Mopidy with it installed will certainly change the pins- as configured in the settings- to be inputs with a pull-up resistor, otherwise the purpose of this extension- to add GPIO button input to Mopidy- would be defeated.

I'm unsure what has actually happened here- but would appreciate more detail, since it might be possible to avoid this happening again. Could you elaborate upon:

  1. What sensors were involved
  2. How and where your sensors, NeoPixels shield and RGB LEDs were connected (GPIO pin connections)
  3. How and why you installed this library

@atchoo78
Copy link
Author

atchoo78 commented Jul 8, 2020

However, running Mopidy with it installed will certainly change the pins- as configured in the settings- to be inputs with a pull-up resistor, otherwise the purpose of this extension- to add GPIO button input to Mopidy- would be defeated.

This is what happened, I realize in akward retrospect. I see your point here.
I batch-installed a bunch of addons for Mopidy and forgot about it, and the next time I started it, it all went crazy.
I had 2 SPI buses + extra PWM activated via overlays, and as the outputs wasn't particulary fond of being inputs, they went "poof".

To be honest, I don't know much of the details. I just smelled something funky, and the piezo speaker/squealer I had connected started sounding like a wounded pig (my guess is that particular GPIO was pulled "HIGH")I pulled out the power cord, and saw that the temperature sensors had brown burn marks.

  1. What sensors were involved

DS18B20 temperature sensor
D-11 temperature/hydrometer
D-22 temperature/hydrometer
AM2320 temp/hydro sensor (i2C)

  1. How and where your sensors, NeoPixels shield and RGB LEDs were connected (GPIO pin connections)

I'll have to check that.

  1. How and why you installed this library

How:

sudo pip3 install Mopidy-Raspberry-GPIO

Why:

Because I'm a hobby developer (that's why I had 4 (!) temperature sensors connected...I developed a sensor plugin for Tellstick ZNet), professional music/audio nerd, and planned to set up a breadboard full of potmeters, rotary encoders and buttons and use it for music playback/volume/transport controls. By the time I started Mopidy again, I forgot that I had installed it, because what I really wanted to accomplish was to just download it and save it for when I had the controls wired up. Bummer. All is well that ends well though. I realized Mopidy just wasn't my thing. I ended up uninstalling it + all addons because it just wasn't my cup of...something.

Cheers

Andreas

@Gadgetoid
Copy link
Member

Thanks for the response.

From experience, I would not be surprised to find this was related to a short or wiring issue rather than the pins being set to inputs. Outside of intentional design or truly constrived situations there should be no way that a pin set to high-impedence input should cause everything to go poof. Bear in mind this is the default state for all pins because it's deemed to be the safest, and is the state that all pins are in at boot until software takes over and configures them otherwise.

Keen to hear back regarding your wiring since I expect we might find the issue there- I've had plenty of brushes with fried sensors myself (sometimes with fingers right on top of them) so I am... rather more familiar with this sort of problem than I'd like to be.

It might be prudent for me to include some method of blocking plugin launch until it has been intentionally configured, but we have shipped hundreds of software libraries that do potentially unexpected things with GPIO and this is one of the exceedingly rare occasions I've heard "Your code killed my device."

(P.S. your project sounds cool and is relevant to my interests as a fellow (not quite so hobby anymore) developer and hobby music nerd- we've got some rotary-encoders-on-a-breakout coming soon that might be useful for prototyping)

@atchoo78
Copy link
Author

It might be prudent for me to include some method of blocking plugin launch until it has been intentionally configured, but we have shipped hundreds of software libraries that do potentially unexpected things with GPIO and this is one of the exceedingly rare occasions I've heard "Your code killed my device."

I totally agree. The only critical short circuit going on that day was in my head...impulsive autopilot kicked in.

(P.S. your project sounds cool and is relevant to my interests as a fellow (not quite so hobby anymore) developer and hobby music nerd- we've got some rotary-encoders-on-a-breakout coming soon that might be useful for prototyping)

Cool. Send me a link when it's released, if it's not too much hassle 😀 I'll try to remember to look for it though!

Take care,
Andreas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants