My shake (RAB20) was connected and displayed in DataView for a long time, but recently was disconnected from the shakenet and hasn’t been able to reconnect since. The device was slow and I had trouble accessing the locally stored data, so I reformatted and reimaged the sd card with the OS. Local data is stored now, but it is sporadically cutting in and out: the data is not continuous. I have data forwarding checked, and I have all the pertinent info placed into the registration space - but I am still “not server connected” and not on the station view map. There is another school district that is nearby who also has a raspberry shake and theirs has also seen their device be removed from the stationview map and network.
I have been in contact with IT and none of the routes to the internet are blocked - we can access the device through IP (not rs.local) and view the helicorder and download the log files.
I am unsure as to which log file we should be looking at to determine the causes of the problems.
RSH.RAB20.2023-05-01T18_42_43.logs.tar (1.3 MB)
1 Like
Hello SouthLewisHighSchool, and welcome to our community!
Thank you for posting the logs from the Shake, and for explaining all the troubleshooting/steps you’ve already taken.
From the logs themselves, it appears that the Shake cannot find a valid IP address in your local network, as these lines suggest:
2023 121 18:05:33: Ethernet is OFF and WiFi is OFF
2023 121 18:05:33: Unable to determine a valid IP address, continuing without one...
and, even if the Data Sharing is correctly turned ON, the Shake cannot communicate with our servers.
It is an unusual situation, so I would like to see what is detected with a newly clean system by resetting the Shake OS to default after a microSD re-burn following these steps. I will leave the burning instructions here for your convenience:
If this second new re-burn doesn’t solve the issue, please then reboot the Shake, wait for around ~30 minutes, download the new logs and post them here.
Thank you again for your collaboration!
So the reburning process was something I already accomplished and the logs I posted were after that occurred.
In the monitor, I see two things as the shake boots:
- in the running text, the IP address is shown and it is the IP that I access the device through. My IT department can also access this IP and it was monitored today at 100%.
- In the line that identifies the device, IP ADDR reads NONE.
I don’t believe I have ever seen an IP address in this line - even when it was publishing data to the shakenet dataview site.
1 Like
Hello SouthLewisHighSchool,
Your observations are correct and match what I also noticed from the data you have provided.
The fact that the IP address was empty, together with the lack of communication with our servers, joined together with what I have highlighted from the logs in my previous message (both Ethernet and WiFi marked as OFF, which should not appear unless the Shake is set for Offline operations), prompted me to suggest a new re-burn.
If, after a new one, those messages remain the same, we can be sure that the issue you are experiencing is not related to the Shake OS on the microSD card, but to some other element that we have to determine. If, instead, the new re-burn solves the issue, then we will have saved some time as it would have been just a case of bad re-burn, which can happen every now and then.
Also, could you please post a screenshot (or the actual image) of the breaks in the data you described? Those could also offer a clue on what is happening.
Thank you.
I will attempt another reburn.
Here is a typical helicorder image in the meantime.
I will add that before my reburn I was getting messages that said, “Undervoltage detected” and so I obtained a different charging block and an uninterrupted power supply. I have not seen the message since.
2 Likes
Thank you for the screenshot.
Usually, the cause of such gaps is related to undervoltage and lack of constant power supply, but you did great in anticipating my suggestion of checking this and trying a new power supply/adapter/charging block.
Thank you also for taking the time to do a new re-burn. After done, simply wait for around ~30 minutes, download the new logs and post them here. I will look at them first thing tomorrow morning.
I have completed the re-burn. IP address still reads as normal in the loading text on the PI, but not in the login section (picture attached).
I can access it directly through my browser on another PC on the network.
Which power adapter would you recommend for this device?
RSH.RAB20.2023-05-02T00_02_41.logs.tar (67 KB)
Logs will not reflect my selected and save options of data forwarding.
1 Like
Let’s see, regarding the power supply, we recommend using the official Raspberry Pi one. However, any other power supply that guarantees continuous delivery of stable voltage between 5.0 and 5.2V and a current of at least 2.5A, as a decrease in power could lead to data services interruption. If you have another Pi power supply that you know is in working condition, you can try that one too in place of what you are using now.
From the new logs, those lines that indicate a missing local IP address assignment are still present, but I can see an IP address confirmed both from other log files, and from the fact you can SSH into it.
Could you please turn on the Data Sharing feature (if you haven’t already after sending me the new logs) and see what happens?
Please access your rs.local/ page, go to Settings (the gear icon high on the left), and then the Data tab. If already checked, try unchecking the Forward Data box and, after ~30 seconds, recheck it. If unchecked, simply check it. Then, click save and restart.
If the Shake still doesn’t connect to the server, can you please SSH into it again and execute the following commands and report their ouput here?
- Testing server ping connection
ping 144.91.66.87 -c 5
- Testing ports availability:
nc -zv raspberryshakedata.com 55555;nc -zv raspberryshakedata.com 55556
Both of these should report a successful output for the Shake to be able to connect and send data to our servers. If any doesn’t, it will give us a clue on what the problem is.
Thank you for your collaboration.
RSH.RAB20.2023-05-03T14_02_08.logs.tar (282 KB)
Local files still report outages of locally stored data.
Ping response:
ping 144.91.66.87 -c 5
PING 144.91.66.87 (144.91.66.87) 56(84) bytes of data.
— 144.91.66.87 ping statistics —
5 packets transmitted, 0 received, 100% packet loss, time 203ms
the nc -zv raspberryshakedata.com 55555;nc -zv raspberryshakedata.com 55556 response:
nc: connect to raspberryshakedata.com port 55555 (tcp) failed: Connection timed out
nc: connect to raspberryshakedata.com port 55556 (tcp) failed: Connection timed out
2 Likes
We are going to be checking firewall settings.
2 Likes
We can now successfully ping 144.91.66.87
2 Likes
I switched PI boards with another that we had lying around and things improved. The board is now snappy on the network and is now connected to the stationview map.
2 Likes
Hello,
Thank you for the further tests and for showing the step-by-step process you have done! I’m sure it will be of help to other users in similar situations.
The fact that both commands failed would have led me to the same suggestion of checking your firewalls and/or modem/router port forwarding options. In the end, good idea to test a Pi board change, that solved all the issues you were experiencing with the data breaks, as far as I can see.
If you require anything else, I remain available.
