Bug Filed on 05-24-2016: Relay board and gpio pin correspondence



What dashboard are you using? (Web, iOS, Android)
web, iOS

What OS? (Jessie, Wheezy)

What Model Pi?

Please describe the bug / issue. Attaching any relevant screenshots would be very helpful!
There is an imperfect correspondence between the gpio pin list in the web Nd iOS versions. On the GPIO page, there is no pin 27 which is listed in both web and iOS versions and, incidentally, necessary in runnin eight relays.
I include the pin ranges of iOS and web versions as well as a couple of segments from my notes :

“Cayenne pin numbering issues:
webpage selection range:
iPhone selection range:
working pin numbers entered from iPhone:
Mismatched pin numbers between webpage relay selector and phone selector make duplication impossible.
Not all data entered from phone goes to webpage, obviously.
The icons chosen from the phone have to be set again on the webpage.
Seems slow to process commands under certain conditions.
Two of the relays inherited from the phone had “Unreachable” icons. I think the pin selection mismatch between the webpage and phone selector lists may be at fault.
As for speed, the busy signal in the browser last between 1 and 12 seconds, typically 5 seconds.
The phone is much faster.
I just looked at the GPIO page, as opposed to the Overview page, on the website, and pin 27, is not listed.”


Hi @jimlynnjulian2,

Welcome to the Cayenne community! We’ll look into the discrepancies you brought up.

Regarding the phone being much faster, this is because when phone is connected to same wifi as the Pi, it uses WiFi to send commands to the Pi. Web dashboard will send commands through the cloud, so that is reason for web dashboard being a little slower.

Keep you updated on when look into and push fix for discrepancy issue. Thanks for letting us know!



Thanks, that makes a lot of sense. I did notice, just now, that the relay switch time is faster on the GPIO page than the Overview page in the PC’s web browser.


I just noticed pin 27 on the GPIO webpage, albeit in an unexpected place.
Was it there all along? (<—rhetorical question)


Yep, it is a sneaky pin. It can sometimes get hidden in the drop down I think.



BTW, iOS app fixed. This will be fixed when we release new version to app store.


I think part of the issue is my router setup. I have a 60mbs cable ISP, but when I logged on this morning, fifteen miles away, on someone else’s WiFi, the webpage was almost as fast as the iPhone. I was using my laptop.


Thanks for sharing! This very well could be a contributing factor. I used to have my Pi’s on WiFi, but switched to Ethernet since WiFi was much slower.



Thanks for responding.
I had been putting off the possibility of using a direct connection to the router, but just tried the setup.
Everything’s noticeably faster. The phone can off/on faster than I can tap. The dreaded busy signal on the webpage is much briefer than before. I suspected as much.
I suspect Windows’ IP system implementation. I recently stopped WiFi sharing on my laptop WiFi port and changed the Ethernet port to dynamic, from static, at I had done that to go ‘headless’ with my RPi.
Let me modify that. I just ran a manual on/off sequence. The webpage typically takes three seconds to turn on a relay, but when IO tried the same in an off sequence, number one went at about three seconds, but four went off into the ozone. I just tested the phone relay off/on test, in manual mode, and things have slowed down.
Let me mention at this point that I’ve tried the script mode and things go much faster all around. Eight relays off in less than a second the last time I tried.
And lest I forget, thank you.


Just to confirm, when you mention that the webpage takes 3 seconds, you are saying that it takes 3 seconds for the widget state to reflect properly? But the device connected to GPIO turns off/on almost immediately?




Most often, yes. The browser accomplishes the task but seems not to recover.
Those times are typical on a good day. If I did a series of tests and turned buttons on one at time then off one at a time, the time, the timing would change each run.
At least one in the sequence would trigger an extended or unending busy signal.
I noticed something else, the CPU and disk gauges dropped like a rock at one point coincident a device activity.
I’m assuming,for the time being, this is just that, a coincidence.
I’m using Chrome in this instance.


The GPIO discrepancy issue should be fixed now. Let us know otherwise.