My arduino were going on and offline a lot. Would that along the same lines of this trouble? Usually have to reset them couple times but sometimes they just go back online
yes, that is almost certainly the same issue. Our Raspberry Pi and Arduino devices talk to the same server, which is different from where MQTT/LoRa ones go. So assuming your Arduinos weren’t connected via MQTT I think that’s the answer.
ESP8266-1 not connecting to dashboard
It works again. Thanks for looking into it!
Great news, thanks for letting us know. I’m going to tentatively move this thread to the ‘Helped’ category, but by all means let me know if you (any of you) start seeing this again.
Without making any changes my Pi is connected.
I was having this issue up until this afternoon. The hotfix resolved the majority of my issues, but my digital output for an LED has not recovered. After a few seconds (or whenever I refresh the webpage) it goes into an ‘Unreachable’ status. I attempted to remove and re-add the button but the same result.
I did verify that I had the correct GPIO listed
My temperature sensor remains functional the entire time, even throughout this issue.
Upon this offline issue last night, I followed the troubleshooting steps outlined here: Troubleshooting Pi Showing Up as Offline in Dashboard and wound up changing a few things recommended.
-My Network.ini file was missing the “SARSServer=reg.mydevices.com” & “RemoteDesktopServerAddress=rds.vcom.com” lines so I added them
-My AppSettings.ini file did not have an ID listed, so I added mine as instructed.
I used the code here ( https://www.raspberrypi.org/forums/viewtopic.php?f=32&t=41639&p=377649&hilit=%2Btkinter#p377649 ) and was able to easily verify that the LED does in fact work without issue.
An update for the thread (and for you specifically @mechbuster2)
It looks like we haven’t quite squashed this issue server side, but we’ll be making another hotfix today that our engineers have good confidence in. A moment ago it was happening again to my Pis, and while things are OK at the moment that I type this, until the hotifx is out (hopefully a matter of minutes or hours now), it’s possible it could recur again. So if you’re still seeing the offline/zero value widgets issue, hang tight for my update before retesting.
For your issue of the ‘Unreachable’ button, I suspect it is probably related to this and should wait for the hotfix for a retest. But in the meantime, could you post the output from
uname -a on that Pi to ensure that you’re not running into another issue I know can cause an unreachable button?
Also, that post about troubleshooting Pi offline is a bit out of date. I don’t think there is any harm to the changes you made regarding SARSServer/remote desktop/AppSettings.ini but those things are not necessary in the current build of the Pi agent software. I’ll edit that FAQ post to bring it up to date in just a moment.
could you post the output from uname -a on that Pi to ensure that you’re not running into another issue I know can cause an unreachable button?
Sure thing! The output I get is;
Linux raspberrypi-tank 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
Also, that post about troubleshooting Pi offline is a bit out of date.
Ok good to know. Some of the output wasn’t right but I figured it couldn’t hurt to make those changes.
I’ll wait until tomorrow and see if there are any changes. Thanks for the rapid response @rsiegel
Ah, ok, so (and apologies for these issues) this one is because you’re running the 4.9 Linux kernel. There is a component of our software that only behaves with the 4.4 kernel that is part of stock Raspbian Jessie at the moment.
This can be resolved by switching to the 4.4 kernel with the following command:
sudo rpi-update 52241088c1da59a359110d39c1875cda56496764
and then rebooting the Pi when it’s done.
That should solve the Unreachable button issue for you. We have an agent update in QA at the moment that will work with both 4.4 and 4.9, putting an end to this issue, and should be released as an automatic update as soon as our QA signs off on it.
All, the latest hotfix is in place – when you have a chance again, check your devices, and the real test will be stability over the course of days and weeks, so let me know if you suspect this offline Pi issue again in the future.
Thanks for your patience while we work out these kinks in the server!
@rsiegel downgrading to 4.4 fixed the issue!
I will check it when I get back from travel in August. Where is a good place to see if the agent update has been signed off on?
My PLduino is mega based and it’s the only one now with the online/offline problem. It uses wifi thru esp-02. Any suggestions?
Cayenne is stucked again:
“Last known status: 7 hours ago (Jul 9, 2017, 2:40 am)”
but I’m using 4.4 kernel, so the problem looks to be worst:
“Linux raspberrypi 4.4.48-v7+ #964 SMP Mon Feb 13 16:57:51 GMT 2017 armv7l GNU/Linux”
After reboot Cayenne status is the same, stays down.
Guys, please remember J.F.K. words:
“We choose to fix Cayenne problems in this decade, not because it is easy, but because it is hard”"
Good luck and good work!
I also assume some downtime yesterday, but now is working fine. I see that it takes like a minute to the dashboard to show that the devices are active as well as the last data package sent and etc.
@rsiegel Was working great for a couple days but the issues seems to reoccurred this morning. The device shows offline sporadically.
Please let me know if there is anything i can do to help? Curious is it a server load problem with a growing Cayenne user base? Where are your servers hosted, what type of infrastructure does Cayenne use?
As mentioned in some other threads, our server cloud.mydevices.com was throwing 400 and 500 errors this morning and this is likely the explanation for the behavior seen by yourself and @aicraga this weekend as well. We’ve already make a fix today that we believe should put an end to this issue. Our servers are hosted on AWS – I don’t believe it is a load issue rather a configuration issue with the system in question. Again thank you for your reports and patience as we stabilize this system.
Yet on the same condition:
Last known status: 2 days ago (Jul 9, 2017, 2:40 am)
Rpi was rebooted more than once and I just logged Cayenne off and on again.
Could you share your output from:
service myDevices status?
● myDevices.service - myDevices service
Loaded: loaded (/etc/systemd/system/myDevices.service; enabled)
Active: failed (Result: start-limit) since Seg 2017-07-10 22:59:04 BRT; 39s ago
Process: 26118 ExecStart=/usr/bin/python3 -m myDevices -P /var/run/myDevices.pid (code=killed, signal=ABRT)
Main PID: 26118 (code=killed, signal=ABRT)
2017-07-10 19:33 GMT-03:00 Rsiegel <firstname.lastname@example.org:email@example.com>:
[https://discourse-cdn-sjc1.com/business2/user_avatar/community.mydevices.com/rsiegel/45/1305_1.png] rsiegelhttp://community.mydevices.com/u/rsiegel Technical Product Manager
Could you share your output from:
service myDevices status?
From this, I don’t think you ran into any issue on our server side as happened further up this thread, it looks instead like the myDevices service has failed to start.
You can try to restart it with
sudo service myDevices start. When it is running properly,
service myDevices status should show (running) similar to this:
I suspect it may fail again, potentially even immediately, if it’s failing even after reboots, however. If that’s the case, let me know the output from
systemctl status myDevices to see if it yields any more information about what is happening here.