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…
We really want you to like it and make it work too
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?
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.
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?
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]
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:
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.
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)
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.
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?
@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!?
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.
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.
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.
