I am using a Pi 2 Model B – dashboard behavior described below as different between WE and ANDROID.
Using a Samsung mobile OR Tablet the behavior is the same.
The RaspPi is found and appears highlighted.
On clicking it, goes to the next screen showing RAM/CPU/STORAGE/etc
and SERVER ERROR flashes up at the base of the screen in RED briefly.
The GPIO screen has no status for any of the pins
however REMOTE ACCESS is alive BUT only brings up a black screen that has no content.
The mouse pointer can be moved around the black screen
But I can exit successfully back to the App.
As above except that
NO GPIO data is displayed - just the column headings.
and no SERVER Error displayed
I am separated from my RaspPi installation by 200 miles but will be there next week.
So if there are any clues as to what I can do to resolve my issues wth “SERVER ERROR” it would be appreciated.
Hi @derek1 and welcome to the Cayenne Community.
The issue with ‘server error’ messages in the Android app requires a fix on our end (either app or server) and isn’t anything specific to your configuration or network. Apologies as it is sort of an annoying error message that pops up a lot, but in the meantime until it is resolved, we’ve found that for the most part you can just ignore it and the data still flows into the app OK.
As for the Remote Access feature – is it possible you’re running a ‘Lite’ Raspbian distribution like Jessie Lite or Stretch Lite? I suspect we’re trying to make a VNC connection into a machine with no GUI installed and that might account for the behavior you’re seeing. If that’s the case I expect it would be very similar from web too. On a full install of Stretch or Jessie I’d expect you were taken to a colorful GUI desktop, same as if you had a display connected to the Pi.
Finally, the issue you’re having with no GPIO data (on web or mobile) makes me think that
webiopi (a component of our Pi Agent) might not be running properly on that device. Could you run the command:
service webiopi status and share the output? If it is anything besides “active (running)”, I’d be interested if a reboot of the Pi has any impact on getting it to run. I’d also be interested in the status of
and thank you for your prompt reply.
I’m not running a ‘lite’ version of Raspbian, but my RaspPi does boot to the prompt. If it booted to the GUI would this make a difference?
My SD card ran out of space some months ago but I only found this out on my last visit 4 week’s ago. This was due to the log from webiopi at 2.4GB so I guess this may be a clue.
I will be where my RaspPi is housed from this Sunday when I will send the data requested.
These problems sounds me like there is no free space to the SD card for cache operation ? Also maybe the RAM is full? Try to killsome services ?
This is almost certainly what it is, I just configured my Pi to boot to the command line and it replicated the behavior you’re describing. Returning to a GUI boot brought back the expected experience.
Looks like our agent is expecting an active GUI session. If you don’t want to configure your Pi to boot to GUI, I’d try to set up a remote desktop outside the context of Cayenne with these instructions: Raspberry Pi Documentation - Remote access
After checking with our developers I found that the webiopi log at
/var/log is not zipped and purged every 7 days like our main myDevices.log is. On my 2 Pis with installs going back months, that only resulted in 125KB and 10KB log files, but I suppose if something went nuts with webiopi throwing a lot of errors into the log that could have bloated it, since it’s never purged.
We’re not going to fix it, only because we are soon releasing an updated agent that won’t require webiopi as a component anymore. So I’d suggest just deleting it on occasion if its becoming a recurring problem on your device. I can help you make a cronjob (automated task) to do that if necessary.
However, if you don’t mind sharing your bloated log (or perhaps since it’s so large, just a small portion from the end of it) we’d be interested just to see what kind of errors you were having in the first place to make it so large. They’d likely be a good hint of why your GPIO tab isn’t working as expected as well.
I have now booted the Pi in GUI mode and “Remote Access” now works OK. (Sadly I’m command line oriented!)
webiopi status webiopi_status.txt (324 Bytes)
A new log file is attached after about 5 minutes from deleting the old one. A set of ERROR/INFO data is created very Minute. var_log_webiopi.txt (15.4 KB)
The .ini settings requested are here: AppSettingsini.txt (191 Bytes)
I also now understand to ignore the “server error” messages – once I saw these assumed things that did not seem to work were a problem at my end.
Appreciate the logs – if you really are interested in command line based remote access, best bet would be to configure SSH outside the context of Cayenne. The Pi people have a good page on this one as well.
And apologies for the scary server error messages, we’ll get them resolved soon – you’re not the only one they’ve caught off guard.
Thank you for your reply and advice.
Was there a reason for the error messages in webiopi log? I have 2 identical pi’s (production and dev) and my dev version has a clean webiopi log with just some initial start up data.
Also on my production version I can not add a temp sensor (DS18B20) as an error creating/updating is returned. The temp sensor is working as I read it from a python program hourly and write it to a log file.
Can you stop for a while the python file and then try to add it to the Dashboard?
For the DS18B20, it’s a little different than the rest since it’s a 1-wire sensor. If you have pin GPIO4 open, try connecting it here per this tutorial. This will allow you to take advantage of our 1-Wire sensor autodetection, and you should not even need to manually create a widget. Once the Pi is powered back on and the Cayenne agent is running again, it should auto-detect the sensor and make a widget that you can then customize on your dashboard.
I’m not sure about the webiopi error messages just yet but I’ll check with our engineers. Ultimately as I said above we’re removing/replacing that component from the Cayenne Pi agent soon so it may be a moot point either way.