Boot problems after mounting a USB stick on a Raspberry Pi Zero

This will just be a short piece, more like a tip to take into consideration.
While playing around with a Raspberry Pi Zero W, I had inserted  a USB OTG ‘hub’  that could take a micro SD card and a USB stick and I had mounted the medium that was in there.
My goal was to use the USB stick to write picture files from a security camera to, in order to spare the SD card.
As also my ordered headers arrived, I shut down the Raspberry, soldered the headers and started up again.
To my horror, it wouldn’t start. Fearing that my soldering somehow had damaged the raspberry Pi, I exchanged cards with a Raspberry Pi B and restarted both. Thank god, the ‘start problem’  was related to the card, not the raspberry.
But how was that possible. It was a new card, and I always had properly shut down the raspberry it was in.
Then it dawned on me, could it be… no it couldn’t, could it??
I realised that after soldering, I had not reinserted the OTG hub with USB stick anymore. Could that be the problem??
After re-inserting the OTG hub with USB stick, my Zero started immediately again.
Obviously that is not the behaviour I want. I will see if I can do something about it, but for now I removed the mount.

 

Advertisements

Controlling a GPIO pin on a remote raspberry

In an earlier post I showed how one could address the raspberry GPIO pins from within OpenHab (or NodeRed for that matter). The only limitation here was that it was on a raspberry that also hosted OpenHAB.

What if you have a RaspberryPi whose pins you want to control from within OpenHab, while openHab is in fact operating from another machine?

In that case  MQTT seems the best option. I wrote a Python program that will do just that.
If you installed Jessie or Stretch, it comes already with Python 2.7 which is quite suitable for this goal.
You will need two libraries:

The lightweight MQTT client Eclipse Paho Mqtt: Here I describe how to install it, but you could also just do:
pip install paho-mqtt

The second one you need to install is the Rpi.GPIO library.
LadyAda gives a good explanation  how to do that, but it basically comes down to issuing the command:
sudo apt-get install python-dev python-rpi.gpio

The Python program itself is fairly simple, but there are a few things to point out
The Rpi.GPIO library has two modes to set up the pins. it has ‘BCM mode’ and ‘BOARD mode’
These two modes refer to the numbering of the pin.

The GPIO.BOARD option specifies that you are referring to the pins by the number of the pin in the plug – i.e the numbers printed on the board.

The GPIO.BCM option means that you are referring to the pins by the “Broadcom SOC channel” number, these are the numbers after “GPIO” that can be seen in the various pinout diagrams

If you are still a bit puzzled, you can try and issue “the gpio readall” command on your terminal and depending on the type of Raspberry you have, you may get outputs like this for the Rpi3:

or this one for the B+
You will also need to set the IP for your particular MQTT broker and need to change the topic according to your wishes.

The program currently switches one pin ON or OFF. it is not particularly hard to expand that for more than one pin. The working can be controlled by the gpio readall command (check in the column ‘V’ what the state of the pin is)

I saved the program in my home/pi directory. It can be started by
python mqttpublish2.py (or any other name you want to give it). It is best to have it start at boot-up
Output will look like this:
A slight word of warning: Python sees indents as part of the command structure. If after downloading my file you go change it, be careful not to mess up the indents.
Edit: In the mean time I expanded the program a bit, it now sends the state of the pin as a seperate topic. It also sends the IP nr, the program name and an ‘alive’ message on startup. It uses pin 18.

 

OpenHab GPIO Example

I know this might not directly be Arduino or ESP8266 related, but I thought I’d publish it anyway as it may come in handy with openhab

First of all, install the GPIO binding in the PaperUI. After one has done that, there isnt really much else to do on that binding. There is no services/gpio.cfg although some of the documentation mentions that file.

Before I go further it is good to note that I used the openhabian distro and I presume a lot of things are already OK in that, but if you did a manual install, it might be good to check if the user ‘openhab’ is member of ‘gpio’ and if not, set that with

sudo adduser openhab gpio

That’s basically all one needs to do.
Let’s setup an ‘input’ which in openhab is a ‘Contact’ and an ‘output’, which in openhab is a Switch. In fact, those are the only states the binding allows.

There is no pressing need to define anything in your sitemap file if e.g. you add the items to a group in your itemsfile, but if you prefer a sitemap then add this to your sitemap file:

Switch item=GPIO_LAMP
Text item=GPIO_BUTTON

Let’s pick some pins to use. It is easiest to use pins on the Raspberry header that are close to a ground pin.

Looking at the pin out of the raspi, we see that for instance GPIO pins 21,13,5, 7, 10, 27,22,24,25,12,16,26, 3, 4, 8 and 17 are next to a ground pin, but some of those have reserved functions so i stayed away from those.
I picked GPIO23 and GPIO24 as that one is also close to a 3V3 pin and when using that as input one can always decide later to make that have a HIGH or a LOW input.The configuration string for the binding is defined as follows:

gpio="pin:PIN_NUMBER [debounce:DEBOUNCE_INTERVAL] [activelow:yes|no] [force:yes|no] [initialValue:high|low]"

for those who consider this as double dutch, it will become clear in the items definition:

Add this to your items file:

Switch GPIO_LAMP "Lamp" (LivingRoom) { gpio="pin:23 force:yes" }
Contact GPIO_BUTTON "Button [%s]" (LivingRoom) { gpio="pin:24 activelow:yes" }

The group ‘LivingRoom’ is not mandatory if you have defined your sitemap and of course you may use another group that suits you more.

The Switch that I set up is quite simple. In fact it already would be enough if it would have been:

Switch GPIO_LAMP "Lamp" {gpio="pin:23"}.

But with ‘force:yes’ we force the use of the pin even if it would have been in use by another process. Obviously that might not be the most elegant way to do it, but as i am pretty sure I am not using it for another process, I just wanted to make sure Openhab would have the pin available.

The current of a GPIO pin is far to small to drive any significant load as it can deliver some 60mA I think.
But the output can drive a small LED to test it… but use a 330 ohm series resistor, no matter what other websites tell you: you dont want to fry your GPIO pin. Eventually it would be more useful to drive a small relay module as long as it has a separate transistor to drive the relay (I know, I am cautious)

The configuration allows for some other parameters.
i already mentioned ‘force:yes|no

activelow yes|no  this means that when the switch is off, there is no voltage on the pin
initialValue:high:low determines the state the pin will take during initialisation.
debounce:interval is used to set the debounce value for the switch in milisecs

If we look at the output, I have not added an activelow because I thought that was the default value (but correct me if I am wrong)
If we look at our input, I set that to activelow, because the way the button works is it applies voltage to trigger the pin and I added it because I was not sure about the default
I did not set a debounce for the contact, but you could state:

Contact GPIO_BUTTON "Button [%s]" (LivingRoom) { gpio="pin:24 debounce:10 activelow:yes" }