R884B missing from Station View

Hello,

My rPIboom is working and Swam displays data normally.
I received an email warning me you receive no data from my Pi for 3 days.
I’ve downloaded the logs, had an overview over them, /opt/data/{archive,gifs} got datas up to this current date.
I can log into the pi.
SDcard use is at 48%, with 3.8Gb free.
Resolving your host from the Pi works as well.

I tried a reboot, nothing better.
I think the bork started when I tried to modify my pi geoposition + altitude on the settings map (http://myshakeip/config)

Data Producer : ON
Data Consumer : ON
Stand-Alone : OFF
Data Forwarding : ON
Server Connection : Connected

swarm continues to work after each reboot, but data is not transmitted.

What can I do ?

regards,

Alex

hi alex,

thanks for the report, we are looking into this and will get back to you.

cheers,
richard

Hello Alex, welcome to our community!

While we investigate, could you please send us the logs from your Shake? The instructions on how to download them are here: Please read before posting!

In this way, we will have a complete view on what could be happening, both from our side and from your side.

Thank you.

Thank you for your replies. The device started to publish again yesterday 21/09 around 20h38 UTC. I opened earlier this request as I received an email warning me there was no datas received by your server, which is a nice feature.
Tell me if you need still the logs.

2 Likes

Hello Alex,

Thank you for your confirmation. Your BOOM is now visible and transmitting live data on StationView here: RS StationView

There was no need for the logs, in the end, since we found that the issue was a server-side one, and our team was able to correct it.

Thank you for your patience, and enjoy your infrasound sensor!

1 Like

RSH.R892F.2021-12-31T09_10_26.logs.tar (565 KB)

Hello, I have a similar problem here. As far as I can see from the log files it seems that the connection to the server is working. however, the station is not visible and data is not accessible. Could you please help? Thanks

Hello manconi, welcome to our community!

Thank you for posting both logs and the screenshot. From them, it seems that the Shake can see and communicate with our servers, but is not connecting for some reason.

Could you please reboot the Shake and then try the following procedure to see if it solves the connectivity issue?

Please access your rs.local/ page, go to Settings (the gear icon high on the left), and then the Data tab. Make sure that the Forward Data box is checked, and then click Save and Restart.

The station should now be able to connect again.

If it does, then this error is caused by a known bug that we are examining and that will (hopefully) be solved in the next Shake OS v0.20 release.

Thank you for your cooperation.

Thanks for your reply. I have done the suggested procedure, but the situation has not changed.

Thanks for any advice.

Hello manconi,

Thank you for getting back to me. Sorry to hear that this fix has not worked. There must be something else that is preventing connection then.

Could you please shut down the Shake, wait for ~5 minutes, turn it on again, wait for around ~30 minutes, and send me the new logs?

I would like to check if there is something preventing connection with a fresh start, and compare this log set with the other one you sent me.

Thank you.

Hi

unfortunately I am in home office and the RS is not physically accessible…do you have any other suggestion I can apply from remote? Thanks

Hello,

if you have remote access, you can reboot your Shake instead of shutting it down. Then wait for the mentioned ~30 minutes, download the log again and then post them here.

It would be almost the same and it could help in pinpointing where the issue is.

Thank you.

RSH.R892F.2022-01-03T20_20_30.logs.tar (1013 KB)

Here they are. Thanks

Hello again,

Thank you for the updated logs. It doesn’t appear that there are connection problems, since the unit can is able to see our servers, at least from the results that I am able to see.

Could you please SSH (guide here: How to access your Raspberry Shake’s computer via ssh — Instructions on Setting Up Your Raspberry Shake ) into the Shake and try and ping the following addresses?

  • ping 8.8.8.8 -c 10
  • ping raspberryshakedata.com -c 10

The first one is the Google server, while the second is our data server. The two commands will execute the exchange ten times, and your expected result is a 0% packet loss for both instances.

I have also noticed, from the logs, that the disconnection happened around the first of January. In your knowledge, has something in the local network to which the Shake is connected to been reset on that day?

Hello

here the result of the ping

myshake@raspberryshake:/opt $ ping 8.8.8.8 -c 10

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=5.08 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=5.12 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=5.14 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=5.18 ms

64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=5.04 ms

64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=5.00 ms

64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=4.100 ms

64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=4.98 ms

64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=4.99 ms

64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=5.17 ms

— 8.8.8.8 ping statistics —

10 packets transmitted, 10 received, 0% packet loss, time 20ms

rtt min/avg/max/mdev = 4.978/5.070/5.181/0.097 ms

myshake@raspberryshake:/opt $

myshake@raspberryshake:/opt $ ping raspberryshakedata.com -c 10

PING raspberryshakedata.com (144.91.66.87) 56(84) bytes of data.

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=1 ttl=56 time=25.0 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=2 ttl=56 time=25.1 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=3 ttl=56 time=25.2 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=4 ttl=56 time=25.0 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=5 ttl=56 time=25.1 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=6 ttl=56 time=24.10 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=7 ttl=56 time=25.0 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=8 ttl=56 time=25.0 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=9 ttl=56 time=25.0 ms

64 bytes from ip-87-66-91-144.static.contabo.net (144.91.66.87): icmp_seq=10 ttl=56 time=25.0 ms

raspberryshakedata.com ping statistics —

10 packets transmitted, 10 received, 0% packet loss, time 19ms

rtt min/avg/max/mdev = 24.993/25.044/25.158/0.084 ms


The problem has appeared after I have tried to set a static IP address. I noticed that the RS was not online anymore and I set back to DHCP removing the parameters from /etc/dhcpcd.conf. Since then it doesn’t work. Here below the current configuration in /etc/dhcpcd.conf:

A sample configuration for dhcpcd.

See dhcpcd.conf(5) for details.

Allow users of this group to interact with dhcpcd via the control socket.

#controlgroup wheel

Inform the DHCP server of our hostname for DDNS.

Use the hardware address of the interface for the Client ID.

clientid

or

Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.

#duid

Persist interface configuration when dhcpcd exits.

persistent

Rapid commit support.

Safe to enable by default because it requires the equivalent option set

on the server to actually work.

option rapid_commit

A list of options to request from the DHCP server.

option domain_name_servers, domain_name, domain_search, host_name

option classless_static_routes

Most distributions have NTP support.

option ntp_servers

Respect the network MTU.

Some interface drivers reset when changing the MTU so disabled by default.

#option interface_mtu

A ServerID is required by RFC2131.

require dhcp_server_identifier

Generate Stable Private IPv6 Addresses instead of hardware based ones

Generate Stable Private IPv6 Addresses instead of hardware based ones

slaac private

A hook script is provided to lookup the hostname if not set by the DHCP

server, but it should not be run by default.

#nohook loo

denyinterfaces wlan0

Hello again,

I’m happy to see that the Shake can see and communicate with our servers from the ping results. And yes, the dhcpcd.conf is likely the cause of the issue you are experiencing. I will open a ticket so that this possible bug with the setup of a static IP address can be examined further.

In the meanwhile, you can try to do the following. Please open the dhcpcd.conf file with

sudo nano /etc/dhcpcd.conf

and add this line at the very beginning of the file: interface eth0. Do not modify anything else.

Save the edits, and then do:

sudo service dhcpcd restart

to make sure those changes took hold and then check the output file with

nano /etc/resolv.conf

Now restart your shake and let it retrieve its new network settings through DHCP. This should solve your connection issues.

If the connection status still remains, not connected, then please try this procedure:

Please access your rs.local/ page, go to Settings (the gear icon high on the left), and then the Data tab. Make sure that the Forward Data box is checked, and then click Save and Restart.

The station should now be able to connect again.

If the Shake still does not connect, then, unfortunately, the only other step I can recommend is to re-burn the microSD card, to start with a fresh system and erase any possible corrupted files that may have formed.

1 Like

Thanks for your reply! I have done all steps and now the RS shows up as “Connected” in the rs.local page. Still, the Station does not appears in the station.view page, but I guess this might need some time.

Cheers, Andrea

1 Like

Hello Andrea,

It’s great to hear that, glad that I could help!

Yes, it may take up to 24h for a new connected unit to show on our services, and your station is now visible on our services.

Have a good weekend!