Bug Filed on 03-30-2016: GPIO DO not toggling


#1

1. What OS? (Wheezy or Jessie)

Jessie

2. What class/size SD card? (ex. class 10 16gb)

Samsung Class 6 8bg SD Card

3. What Model Pi? (A+, A, B+, B, Pi2)

Pi Model B (2011 Made in the UK)

4. Please describe the bug / issue. Attaching any relevant screenshots would be very helpful! Thanks in advance.

Fresh install of Jessie. Ran sudo apt-get update and sudo apt-get upgrade. Reboot. Expand filesystem and reboot again. Manually installed Cayenne using wget and my personalized code. (I’ve also let the Android app install Cayenne automatically with the same results.) Pi is discovered on both remote and local network. I’ve created a device widget for a simple light (LED) connected to 17. For the life of me I’m not able to toggle widget. I’ve tried IE, Firefox and Chrome along with the latest version of the Android app. All exhibit the same behavior with the spinning icon. If I go to another page and come back, widget has stopped but not toggled. I’ve also accessed webiopi on port 8000 and cannot toggle the pins here either. I am able to change the state from in to out although it takes up to 15 seconds for the change to occur. I’ve used Webiopi standalone in the past with great success. What am i doing wrong??? I really want to like this and have it work…


#2

Hey Bucky,

We really want you to like it and make it work too :slight_smile:

Is the LED actually turning on?

Doesn’t look like you are using Jessie Lite (we’ll be supporting it soon). Did you install Cayenne over a previous version of WebIOPi? Cayenne uses a modified version of WebIOPi and we’ve had issues in the past that would resolve if Cayenne was installed on a Pi without previous version of WebIOPi.

Any weird network configurations that would cause Cayenne requests to be rejected? You are not on corporate network, right?

-B


#3

Holy. Fast. Response!

LED is not actually turning on. I was using a T-shaped breakout board with ribbon connector and suspected that could be an issue. Moved to dupont cables into a breadboard and still no look. Full version of Jessie that installed with win32imager. I’ve reinstalled Jessie multiple times just to make sure I’m starting with a clean slate; no previous version of WebIOPi on the SD card.

Nothing crazy on the networking end. I’m accessing it through the browser (Chrome ver 49) and the Android App with the same results. I just updated the Android app tonight when it notified me of a new version. I’m also experiencing high processor usage. I’m running top in an ssh window (putty) and as soon as i click pin 17 from input to output, load average jumps from 0.35 to somewhere in the range of 0.77 to 0.95. That’s without trying to toggle the pin; simply changing from input to output.


#4

Just reread the note about networking and realized it’s not very clear. I’ve connected on my home wifi with a PC browser and the Android app (also connected to the wifi) with the same results. Switching off wifi on my phone and connecting through the cellular connection yields the same results.

I’ve turned off blockers in the browser to make sure nothing is being blocked with flash/javascript/etc. Are the widgets using any of that programming or HTML5?


#5

Okay so doesn’t seem like networking issue or WebIOPi issue. It’s weird that not even stand alone WebIOPi is working.

Can you check and make sure you see a status for myDevices and webiopi: sudo service --status-all

If you do see those services, perhaps they need to be resarted: sudo serivce myDevices restart and sudo service webiopi restart

If you don’t even see those service from sudo service --status-all then we can go from there.

P.S. html5

-B


#6

And on the blue ribbon at top of page, under the Configure tab, you should see this version of the agent installed: 1.0.0.18542


#7

@buckyfan624

Bucky,

Welcome to the Cayenne community!

I’m going to throw out some thoughts, kind of back to basics-
I do not intend to insult anyone’s intelligence but sometimes the easy stuff is overlooked.

Do the LED and resistor combination work?
It is inferred that they do work here, but I’m double checking. [quote=“buckyfan624, post:1, topic:420”]
I am able to change the state from in to out although it takes up to 15 seconds for the change to occur.
[/quote]

Does the RPi behave properly without Cayenne?
For example run a simple python LED blink program like is outlined here-
http://www.raspberrypi-spy.co.uk/2012/06/control-led-using-gpio-output-pin/

Any chance you could include photos of the wiring or screenshots of the Cayenne setup only because a fresh set of eyes sometimes see something new.

Again welcome,

Ian

p.s.
Are you a fan of Ohio State?


#8

Output from sudo service --status-all yields:
[ + ] webiopi

myDevices is not listed as a service. Running the command sudo service myDevices restart and sudo service webiopi restart works and does not generate any errors (or any messages for that matter).

This is the output from sudo service myDevices status -l:

Doesn’t look too promising does it?

This is the output from `sudo service webiopi’


#9

LED combination works when applied to 3.3V and GND. I’ll upload pictures of the setup shortly. The problem is, even without the wires connected, I’m never able to toggle the pin from low to high. I’ll try the script when I get back tonight.

Here is a copy of the configuration screen:

I’m a Badger fan which makes Ohio State my mortal enemy! :joy:


#10

So why did the Badger get named after Ohio State?
Sorry, I’ll quit :slight_smile:.

Thanks for checking the easy stuff, now to look at the harder stuff…
Does the pin work outside of Cayenne?

Ian


#11

Hi Bucky,

We haven’t seen this before. Something weird happened on the install perhaps. myDevices should be appearing as one of the statuses, just like webiopi.

Can you paste the output of the following command?

tail /var/log/myDevices.log

-B


#12

Here is the output of the tail command:
pi@raspberrypi:~ $ tail /var/log/myDevices.log
2016-03-30 18:42:02 - myDevices - WARNING - Packet type not implemented: 37
2016-03-30 18:56:54 - myDevices - WARNING - DownloadSpeed TestUpload - Not implemented
2016-03-30 18:57:02 - myDevices - WARNING - Packet type not implemented: 37
2016-03-30 19:12:02 - myDevices - WARNING - Packet type not implemented: 37
2016-03-30 19:17:25 - myDevices - WARNING - DownloadSpeed TestUpload - Not implemented
2016-03-30 19:27:02 - myDevices - WARNING - Packet type not implemented: 37
2016-03-30 19:38:14 - myDevices - WARNING - DownloadSpeed TestUpload - Not implemented
2016-03-30 19:42:02 - myDevices - WARNING - Packet type not implemented: 37
2016-03-30 19:57:02 - myDevices - WARNING - Packet type not implemented: 37
2016-03-30 19:59:03 - myDevices - WARNING - DownloadSpeed TestUpload - Not implemented

I also have 13 .tar.bz2 files which I would assume are the appended log files? Would that be helpful to attach any of those?


#13

Bucky is way cooler than a Buckeye nut! :laughing:

I ran the script but the light still isn’t blinking. Confirmed the circuit works so with 3.3V and Gnd so that’s not the issue.

When I ran the script a second time, I got this message:

ledtest.py:8: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
   GPIO.setup(11, GPIO.OUT)

#14

Wouldn’t hurt attaching them if you have a few minutes.

I think this should be good. Let us investigate and get back to you. Sorry about this, we haven’t seen this occur before so this is a new issue that now user has experienced up until now, that I’m aware of.

-B


#15

A nut, or a weasel, don’t really have time for either one. Lets have some real fun and talk crap about Mustangs… on second thought better not, or the help from @bestes may stop.

The in use error on the second run is appropriate because GPIO.cleanup() wasn’t run after the first run, shouldn’t be a problem.

I went ahead and loaded it up on one of my RPi2b’s and it ran fine, I got the following response along with a blinking light-
pi@raspberrypi:~ $ sudo python ledtest.py Setup Pin 11 Start loop Set Output False Set Output True Set Output False Set Output True Set Output False Set Output True Set Output False Set Output True Set Output False Set Output True ^CTraceback (most recent call last): File "ledtest.py", line 18, in <module> time.sleep(1) KeyboardInterrupt pi@raspberrypi:~ $
I also got the already in use warning the second run, again not a problem.

I’m concerned there might be something up with your RPi, but @bestes is having concerns with what he is seeing, and he is way smarter than I am, even if he is a Mustang. I don’t suppose you have another RPi available?

Again, just thinking out loud,

Ian


#16

@Ian, about GPIO.Cleanup() this is something you shouldn’t use because, at least for me. When i run a script and end it with GPIO.Cleanup() it changes the pin to the default state, putting it to input state. After that i cannot use it anymore with widgets (output widget). If i press a widget it stays trying to execute and nothing happens (“gearwheel thinking”), i have to go to the gpio, change it to output and it starts working again. This is something that need a fixing, i think!?

Regards


#17

@helder-rodrigues

Good morning Helder!

I agree one needs to be careful with things like GPIO.Cleanup() especially when another program may utilizing a single GPIO. Perhaps I should have stated it differently, something like - " the error is expected because the first run of the program, a loop, was terminated with a ^C interrupt and left the IO in use".

Just for fun I set up a widget in Cayenne for the GPIO/LED and ran the external program. As long as I had 4-5 seconds between state changes Cayenne captured and posted the change in state to the dashboard. Any timing shorter than 4-5 seconds resulted in some changes being missed by Cayenne.

Thanks for the clarification!

Ian


#18

I have Pi’s all over the house running Kodi. I did install the service on a Raspberry Pi 2 and the toggling operates as it should (at least in software…I don’t have an LED attached and I’m remote).

I’m beginning to suspect it is a problem with the hardware and not necessarily software related.


#19

Hi Bucky,

I confirmed with Cayenne team that the warnings displayed in your log output should not affect any performance of the Pi / Cayenne. (and we’re cleaning up those warnings soon).

When you’re not remote, think you can see if you can get an LED working? Would be great if you could confirm if it’s hardware or software issue.

I’m eagerly awaiting :slight_smile:

Cheers,

-B


#20

Haha a wise decision!