hamma-dev / mjolnir-hamma Goto Github PK

We have a new server, so let's use it! (There are changes to make in other packages as well....)

See also: project-mjolnir/sindri#5 (comment)

Bug in relay script that prevents it from working.

@CAM-Gerlach Should the file https://github.com/hamma-dev/mjolnir-hamma/blob/master/files/mount-udisks.pkla have an hyphen (as it does now) or an underscore (as it is in some of the commands)?

sunsaver.py in the scripts directory has Python interpreter coded as part of brokkrenv, which use on the development system. We don't use this nominally in deployment. Need to think about the best way to handle it....

Right now, we look for a ping failure to determine if the sensor can be reached, as a proxy for the sensor powered and operating as expected. When it fails, we send out a notification.

However, there can be a ping failure even when the sensor is on. (I think it is due to trying to ping while the sensor is sending out a data packet, as it primarily seems to happen during storms.)

Add a hook to wait for consecutive bad pings before sending out a notification.

Brokkr watches the stream of data from the sensor and writes to a Pi-attached drive. The sensor also writes data. So, we have two places where data can be found. Typically:

1. The sensor drive is smaller than the Pi drive
2. The sensor drive does not buffer, so under high flash rates might drop triggers.

We want to:

• Make sure that every trigger on the Pi drive is on the sensor drive.

This will catch any case where brokkr fails to write data. Note that we don't need to worry about the converse.

• Periodically clean sensor drive.

If it fills, the sensor goes into a reboot cycle. This can happen near daily, depending on the size of the USB drive.

First line of sunsaver script has a tilde in the shebang line:

#!~/dev/brokkrenv/bin/python

This won't call the Python you want it to...

After about a day or so, some mjolnir systems lose cellular connectivity.

After some checking, it looks like these systems have a lot of udhcpc processes spawned. This process gets run when the "degraded" state is detected for wwan0.

A suggested fix - that has been nominally tested - is to quit udhcpc after obtaining a lease.

Trying whatever I can to make sure @CAM-Gerlach is ok

Right now, we are writing a binary HAMMA file for every trigger. This quickly leads to a situation in which we can no longer write more files because the underlying filesystem cannot handle "a lot" of files in the directory. The error appears as misleading "not enough space" error. (Took a while to track this down.) "A lot" seems to be ~16k files.

So, we need to either figure out a way to not write so many files (I don't think this is possible), or find a way to add some sub-directories to write to. Currently I'm thinking of subclassing brokkr.outputs.binaryfile.BinaryFileOutput to dynamically add some directories on the fly, but more ideas are welcome!