Raspberry Shake(s) will not connect to server. (solved)
Background:
I installed 3 Shakes (RS3D, RS4D, RS&Boom) by simply plugging in and following the simple instructions. The devices were assigned IP addresses by the DHCP server.
Everything worked fine and data was sent immediately to Shakenet server.
Problem 1:
I followed the instructions and noted that plugging the devices in sequence resulted in network names of rs.local, rs-1.local and rs-2.local which I could access via my browser.
But….
When I tried to reconnect a few minutes later, rs.local was found but not rs-1.local or rs-2.local.
A network search tool found the devices, now renamed rs-24.local and rs-4.local.
What was happening?
The Shakes are assigned names starting with rs.local, but subsequent Shakes are then named in the order that they are found on the network. However, at least on a Windows operating system there is a problem – the default network uses both IPv4 and IPv6. When the network finds a new Shake using IPv4 it is assigned a network name, but then IPv6 finds the same device and renames it!
There were two solutions to this problem…
- Turn off the IPv6 network and only use IPv4, or
- Assign static IP addresses so that the devices can be found using their fixed IP address.
Problem 2:
I choose what I thought would be the simplest solution of assigning a fixed IP address to each of the Shakes. This was done using the “Settings” button on the devices web page.
When the static IP address had been entered the devices was rebooted using the button at the bottom of the page.
Data forwarding needed to be turned on again, but all the devices gave the message…
Server Connection: Not Connected.
I also noticed that the IP address had not been changed to the newly assigned static address and the box where the static address is to be entered had been cleared again.
Investigation:
After a lot of research, I discovered articles on the Raspberry Pi Forum confirming that the version of Raspbian used in the Shakes – Raspbian GNU/Linux 10 (buster), has a bug and does not support Static IP addresses.
There is an alternative way of getting a fixed IP address, but this is router dependent, so I cannot give details here as they will vary from router to router.
I have left my Shakes set to DHCP, but then in my router I have assigned addresses to a table called Static DHCP, whilst this is very similar to assigning a static IP address in the device, it works in a slightly different way… The table matches the MAC address of the Shake with a fixed IP address. Whenever a Shake is connected to my network the system it is given the same IP Address, but that address is not permanently assigned to the device. If the device is plugged into a different network a different IP address would be assigned allowing for flexibility.
The no connection problem remained.
Solution:
I then investigated the Shake at the programming level by connecting to the operating system. Since I was running on Windows, I used a program called PUTTY to connect to each Shake using SSH.
You will be prompted for a username and password. The Username is “myshake” and the password is whatevery you set it to during your installation, The default which you should have changed is “shakeme”.
You now need to edit a file called dhcpcd.conf.
Type the following…
Sudo nano /etc/dhcpcd.conf
The lines at the top after interface eth0, are wrong!
They are duplicated and seem to be added to every time you try to add a setting, and critically importantly the static router entry is blank.
In my case everything in the box must be deleted leaving only
Interface eth0
Static ip_address=192.168.1.1
Static routers=192.168.1.1
Static domain_name_server=1.1.1.1
The file is then closed and the Shake rebooted by typing Sudo Reboot.
After the reboot the Shake is still reporting no connection but this is because Data Forward needs to be turned on.
Turn on Data forwarding and then click on the button to restart the Shake system and after a few seconds the Server Connection will change to Connected!
The server connection problem has been solved.
I have seen a number of questions on this forum about similar connection problems and I believe that I have found the cause of the problems. There is a bug in the operating system that is triggered when an attempt is made to use a static address. This cannot be solved by reconfiguration using the GUI and the DHCPCD.CONF file must be edited.
Whilst this might be daunting for anyone who has not edited system files before it is actually very easy and I hope I have given sufficient instructions. It is much easier than burning a new copy of the operating system which will set everything back to only using DHCP but the problem will occur again if the Static address option is touched.
Happy seismology!