A post to PATCH sensordefinition/178 with body:

{"device_hardware_id":"0123F2A286A98ACEEE","input_measurement_id":77,"inside":true,"name":"My first temp sensor"}

Returns:

{"id":178,"created_at":"2020-05-20 20:19:03","updated_at":"2020-06-04 23:39:02","name":"My first temp sensor","inside":null,"offset":null,"multiplier":null,"input_measurement_id":77,"output_measurement_id":null,"device_id":224,"input_abbr":"t_0","output_abbr":null}

So the true boolean is patched to null.

Click on Edit button of an inspection (https://app.beep.nl/webapp#!/hives/xxxx/inspections/xxxx)
Change Date of inspection and click Save Inspection

Expected: inspection is save with new date
Actual: a new inspection is created with the same data and the new date

new layers won't have an id property

Currently, when consuming the api as a JSON client, with content-type set to application/json, a 302 redirect is thrown when using none or an expired/invalid token. There is no way for the client to detect that its token has expired. Other than having a 302 imply an authentication failure and grep the body for login :(

Please throw 401 errors when the token is not present or invalid, and the content-type is anything other than html, e.g. application/json.

Also see #14 for further improvements. Currently there is no way to derive the ttl of the token and we need to wait for a call to fail, before we present the login screen.

1. verify new email after it has been changed
2. refresh API token after user patch request
3. in API docs: change 'password_confirm' to 'password_confirmation' and add 'name' as parameter
4. add current password as required parameter for patch request

This is the situation where I register a beep base with one account, then try to register it with another account. This throws a 500 instead of a 403 error code.

When calling POST /api/sensordefinition with the following (minimal) body:

{"device_hardware_id":"0e0123f2a286a98aceee","offset":11,"multiplier":1,"input_measurement_abbreviation":"w_v"}

It works. But when doing the same with the following payload:

{"device_hardware_id":"0e0123f2a286a98aceee","offset":11,"multiplier":1,"input_measurement_abbreviation":"w_v","output_measurement_abbreviation":"weight_kg"}

I get an internal server error:

LogicException: App\Measurement::pq_name must return a relationship instance. in file /opt/bitnami/apps/test.beep.nl/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.php on line 420

The issue seems to be with the output_measurement_abbreviation. When adding this, the 500 appears. We discussed before that weight_kg is the appropriate value, and it worked before. I also checked the taxonomy if this value was present, just to be sure. But no go.

It currently lacks a timezone. Preferably it should be serialized in UTC:

"updated":"2020-02-26T22:00:00Z",

On the inspection frontend, the maximum values of the top photo analysis brood layer & frames steppers are 2 and 11, instead of 5 and 20.

Maybe the max values are somehow overwritten by the lieberfelder template because of ng-show instead of ng-if in checklist_fieldset.html?

solution: omit ' 00:00:00' when queen already exists

In the hardware_id of the registered BEEP bases, there is the first byte of the response included (i.e. "0e") This should be removed from:

• Database
• LoRa message port 2 interpretation on API (KPN)
• LoRa message port 2 interpretation on TTN decoder (TTN)

For inspections including colony size calculations (via top photo analysis or liebefelder method):
When hive properties (frames, brood/honey layers) change, the input values for colony_size change, and therefore the colony_size is recalculated. This also happens when editing an inspection where colony_size has previously been calculated, even if you don't want to edit the colony_size. The recalculated colony_size value will be saved when saving the edited inspection, which is undesirable.

Suggestion for solution:
Set the frame and layer values for colony_size calculation to 'null' by default. If these values are null, retrieve the colony_size value from the database (if existent) as colony_size value. As soon as the values are (re-)entered, the calculated value will be displayed instead.

Please have collection endpoints, such as GET /api/devices return an empty array if the collection is empty, and make sure the http response code is also 200 OK.

Also have this behavior when applying query strings to collection endpoints e.g. GET /api/devices?hardware_id.

Currently endpoints, such as the one above, throw a 404 code and a string. This makes the client deserialization harder than necessary (invalid json, exception branching).

Current behavior for non collection endpoints such as GET /api/devices/{id} is fine as is (404).

DELETE /devices/{id} results in the following 500 error when the device to delete has sensors attached:

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`test_beep_nl`.`sensor_definitions`, CONSTRAINT `sensor_definitions_device_id_foreign` FOREIGN KEY (`device_id`) REFERENCES `sensors` (`id`) ON UPDATE CASCADE) (SQL: delete from `sensors` where `id` = 213)```

Dear Pim and Marten,

I just became aware of #67 and want to humbly make you aware about what @gutzbenj, @wetterfrosch and all other contributors are conceiving over at https://github.com/earthobservations/wetterdienst.

While this is currently just about ingesting weather information from @DeutscherWetterdienst, we want to tap into data from other domestic weather agencies soon.

So, maybe you can share some information about where we might want to look into when approaching open weather data from the Dutch weather agency?

With kind regards,
Andreas.

cc @ClemensGruber

Just looking at the code of ttn-payload-decoder.js the decoder, I think it has two errors for hardware_version and one for hardware_id.

The test payload of 0100010003000402935685E6FFFF94540E01237A26A67D24D8EE1D000001 on port 2 currently yields "37718.34278 ID:16749907" and "01237a26a67d24d8ee" but I think those should read "168790.34278 ID:4294939732" and "0e01237a26a67d24d8ee".

hardware_version is missing first byte?

decoded.firmware_version = ... + bytes[6]);
decoded.hardware_version = ((bytes[8] << 8) + bytes[9]) + ...

The code skips bytes[7]. Also, the code seems to document that's actually part of this hw version attribute:

// 0100010003000402935685E6FFFF94540E01237A26A67D24D8EE1D000001
// 01 00 01 00 03 00 04 02 93 56 85 E6 FF FF 94 54 0E 01 23 7A 26 A6 7D 24 D8 EE 1D 00 00 01 
// 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 
//    pl  fw version    hw version                 ATTEC ID (14)                 app config

Same goes for other parts of the decoder, skipping bytes[9]:

decoded.firmware_version = ... + bytes[8]);
decoded.hardware_version = ((bytes[10] << 8) + ... 

hardware_version is not handling the MSB in "ID" correctly?

Note that when using bitwise operators in a TTN decoder, JavaScript expects signed 32 bits numbers using two's complement encoding, hence allowing for numbers from -2,147,483,648 through 2,147,483,647.

Knowing that, the following smells:

... + " ID:" + ((bytes[12] << 32) + (bytes[13] << 16) + (bytes[14] << 8) + bytes[15]);

First, I'm quite sure the << 32 should read << 24? As JavaScript is working with 32 bits values, using << 32 effectively is the same as not shifting at all: 0xFF << 32 is actually 0x000000FF, and 0xFF << 40 is 0x0000FF00, and so on. Unlikely that's what you want?

Second, given that JavaScript expects two's complement encoding, using bytes[12] << 24 will yield a negative number if bytes[12] has its leftmost bit set. (So: if the value is 0x80 or above, or if bytes[12] & 0x80 is not zero.)

When using << 24 rather than << 32 then you can test with the payload you're already showing in the code, which holds FFFF9454 in 0100010003000402935685E6FFFF94540E01237A26A67D24D8EE1D000001 on port 2.

This can be circumvented by using the zero-fill right shift >>> (which, unlike the other bitwise operators, returns an unsigned 32 bits integer), along with actually shifting zero bits. Or by not using bitwise operators at all. Any of the following will work:

... + " ID:" + ((bytes[12] << 24 >>> 0) + (bytes[13] << 16) + (bytes[14] << 8) + bytes[15]);

... + " ID:" + (((bytes[12] << 24) + (bytes[13] << 16) + (bytes[14] << 8) + bytes[15]) >>> 0);

... + " ID:" + (bytes[12] * 0x1000000 + bytes[13] * 0x10000 + bytes[14] * 0x100 + bytes[15]);

Aside, when using bitwise OR rather than addition, one needs fewer parentheses, as addition has a higher precedence than the shift operator:

... + " ID:" + ((bytes[12] << 24 | bytes[13] << 16 | bytes[14] << 8 | bytes[15]) >>> 0);

Better yet, just define a helper that takes an array of bytes and returns an unsigned integer:

// Convert the array of bytes to an unsigned integer, MSB.
// This is only safe up to 0x1FFFFFFFFFFFFF, so: 6 bytes.
function toUInt(bytes) {
  return bytes.reduce(function(acc, b) {
    // Unsigned, so don't use any bitwise operators, which would always
    // yield a signed 32 bits integer instead.
    return acc * 0x100 + b;
  }, 0);
}

With another helper to accept a full array of bytes and a start index and length:

function getUInt(bytes, start, len) {
  return toUInt(bytes.slice(start, start + len));
}

...one could then rewrite:

decoded.hardware_version = ((bytes[8] << 8) + bytes[9]) + "." + ((bytes[10] << 8) + bytes[11])
    + " ID:" + ((bytes[12] << 32) + (bytes[13] << 16) + (bytes[14] << 8) + bytes[15]);

...to:

decoded.hardware_version = getUInt(bytes, 7, 3) + "." + getUInt(bytes, 10, 2)
    + " ID:" + getUInt(bytes, 12, 4);

(This also assumes bytes[7] indeed needs to be included.)

hardware_id is missing first byte?

The code skips byte[16]. The documentation in the code suggests it's part of hardware_id, named ATTEC ID in the example.

decoded.hardware_version = ... + bytes[15]);
decoded.hardware_id      = toHexString(bytes[17], 2) + toHexString(bytes[18], 2) + toHexString(bytes[19], 2)
                         + toHexString(bytes[20], 2) + toHexString(bytes[21], 2) + toHexString(bytes[22], 2)
                         + toHexString(bytes[23], 2) + toHexString(bytes[24], 2) + toHexString(bytes[25], 2);

Also, adding a helper that takes an array to print as hex keeps the code short:

// Get a hexadecimal representation with leading zeroes for each byte.
function toHex(bytes) {
  return bytes.reduce(function(acc, byte) {
    return acc + ('0' + byte.toString(16)).slice(-2);
  }, '');
}

...

decoded.hardware_id = toHex(bytes.slice(16, 26));

Bonus

It seems lines like the following are meant to convert fewer than 4 bytes into a signed integer?

decoded.t_i = hexToInt(toHexString(bytes[ds18b20_values_start_byte], 2) 
            + toHexString(bytes[ds18b20_values_start_byte+1], 2), 4); 

If true, then sign extension is your friend:

// Sign-extend a 16 bits number to 32 bits to make JavaScript understand negative values, by
// shifting the MSB 24 bits to the left, followed by a sign-propagating right shift of 16 bits
// to effectively shift 8 bits.
bits.decoded.t_i = bytes[ds18b20_values_start_byte] << 24 >> 16 | bytes[ds18b20_values_start_byte + 1];

Of course, a helper might be better:

// Get a signed integer from 2 bytes, MSB.
function toInt16(bytes) {
  // Sign-extend to 32 bits to support negative values: shift 16 bytes
  // too far to the left, followed by sign-propagating right shift
  return bytes[0] << 24 >> 16 | bytes[1];
}

function getInt16(bytes, start) {
  return toInt16(bytes.slice(start, start + 2));
}

...

bits.decoded.t_i = getInt16(bytes, ds18b20_values_start_byte);

Enjoy!

Currently only brood & honey layers (and frames) are logged in 'kasthandeling' inspection when a hive is changed.

Please also add 'feeding_box' and 'queen_excluder' layers to 'kasthandeling' inspection.

Now the 'editable' boolean is only present in groups -> hives endpoint, therefore not accessible when loading a single hive via the hives endpoint

F.e. when hive configuration is modified at 10am, it is being saved as 9am.

Hi,
I am pretty new to BEEP but I am super excited about the project as I had the idea of an open source hive management solution too but no time to dig into.

Currently I am working on a docker-compose deployment to simplify the deployment on a private server and local development (for this part some work is still needed).

During this process I faced one issue which is hard to automate.

Problem:
The force https section in the .htaccess file is preventing to run a none https deployment in a local setup. The result is, I have to adjust this file every time I am checking out the project.

Solution proposal:
If the force https part is part of the apache/beep-public.conf we can avoid having this inside the .htaccess.

The next version of the TTN LoRaWAN Stack, V3, is due on the community network somewhere this year. As per https://www.thethingsnetwork.org/forum/t/convert-custom-payload-to-lpp-payload-in-ttn-console/12171/9:

We’re dropping the converter and validator in V3 as they’re not being used; you can put conversion in the decoder, and it makes more sense to drop/filter out invalid values higher upstream.

And as per https://thethingsstack.io/v3.8.4/getting-started/migrating-from-v2/major-changes/

Payload Formats

The Things Network Stack V2 has support for payload decoders, converters, validators (for uplink) and encoders (for downlink). These can be either CayenneLPP or Javascript functions.

The Things Stack has support for an uplink payload formatter (similar to the payload decoder) and a downlink payload formatter (similar to the payload encoder). These can be set per application, and can even be overridden per end device. Similar to The Things Network Stack V2 , CayenneLPP and Javascript functions are supported.

Migrating the The Things Network Stack V2 payload encoder and decoder to an uplink and downlink payload formatter should be straightforward, since they have the same format.

So, it might be better to be prepared, and combine ttn-payload-decoder.js and ttn-payload-converter.js into a single Decoder.

Better yet, maybe decoding should be done in the BEEP backend?

When adding/editing an inspection, the number of bees calculated via the Liebefelder method is shown as 'total colony size', but the value is not saved in the inspection.

Also the input field with name 'colony_size' is not shown, which is ok from the user perspective, but may be part of the issue.

The documentation states that the "inside" property on sensordefinition is a bool. The api accepts both a number, a string, or a boolean. The response type from list sensordefinitions returns a number.

Please unify the typing to boolean in the response e.g. (see inside property)

  {
    "id": 78,
    "name": null,
    "inside": true,
    "offset": null,
    "multiplier": null,
    "input_measurement_id": 78,
    "output_measurement_id": null,
    "device_id": 125
  }

Please add two endpoints that can be used for proxying to the TTN application manager:

• A GET for TTN devices: http://eu.thethings.network:8084/applications/beep-digital-hive-monitoring/devices/<deviceId>
• A POST for TTN devices: http://eu.thethings.network:8084/applications/beep-digital-hive-monitoring/devices/<deviceId>

The post receives the following payload:

{
  "dev_id": "<deviceId>",
  "lorawan_device": {
    "app_id": "beep-digital-hive-monitoring",
    "dev_eui": "<devEui>", 
    "dev_id": "<deviceId>", 
    "app_key": "<appKey>",
    "app_eui": "70B3D57ED0028D38" 
  }
}

On https://github.com/beepnl/BEEP/blob/master/readme.md#documentation you can finde a link to https://beep.nl/manual

but this page throws an error

No route found for "GET /manual" (from "https://github.com/beepnl/BEEP/blob/master/readme.md")

The 'editable' property of a shared hive should be 'true' when marked as editable

Sensordata is submitted via the URL as:
https://bee.iconize.nl/api/sensors?key=secret&t=xxx&l=yyy&bv=zzz

Expected behaviour: Graph should show light, temperature and battery value.

Actual result:
Graph shows temperature, light, weight and corrected weight (that is fluctuating with temperature):

When calling PATCH /api/sensordefinition/{id} with body:

{"device_hardware_id":"<REDACTED>", "inside":true,"name":"My first temp sensor"}

The result nullifies the properties that are not present. In particular the input output measurement types.

This is not the expected result on a PATCH operation (but PUT, maybe). It should only patch the properties that are passed, and leave the omitted properties to their current values.

After creating a device, using POST https://test.beep.nl/api/devices/ I receive a JSON which contains the id of the new device.

The documentation mentions PUT/PATCH https://test.beep.nl/api/devices/<id>. When calling this endpoint with a json payload:

{"key":"<samekey>","name":"DifferentBaseName","hardware_id":"<samehardwareid>"}

, I get the error:

{
  "errors": {
    "key": [
      "The key has already been taken."
    ]
  }
}

When omitting the key, I get the error:

{
  "errors": {
    "key": [
      "The key field is required."
    ]
  }
}

Hey!

I'm impressed by the system which you developed and i would like to use it with my own server but i have problems with the installation of it.

Do you have instructions which works or even a Git container which works? For example the webapp directory is not existing in the public folder.
I used the master branch on a new Debian 9 machine.

Best Regards

Add a DELETE /api/devices/id call which allows for deletion of devices. It is fine if this is only restricted to admins.

root@localhost:/var/www/bee# ./run_actions.sh
Backup MySQL and Influx database (y/N)?
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Package jakub-onderka/php-console-color is abandoned, you should avoid using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should avoid using it. Use php-parallel-lint/php-console-highlighter instead.
Package jeremeamia/superclosure is abandoned, you should avoid using it. Use opis/closure instead.
Package phpoffice/phpexcel is abandoned, you should avoid using it. Use phpoffice/phpspreadsheet instead.
Generating optimized autoload files
Deprecation Notice: Class PHPExcel_Best_Fit located in ./vendor/phpoffice/phpexcel/Classes/PHPExcel/Shared/trend/bestFitClass.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class PHPExcel_Exponential_Best_Fit located in ./vendor/phpoffice/phpexcel/Classes/PHPExcel/Shared/trend/exponentialBestFitClass.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class PHPExcel_Power_Best_Fit located in ./vendor/phpoffice/phpexcel/Classes/PHPExcel/Shared/trend/powerBestFitClass.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class PHPExcel_Polynomial_Best_Fit located in ./vendor/phpoffice/phpexcel/Classes/PHPExcel/Shared/trend/polynomialBestFitClass.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class PHPExcel_Logarithmic_Best_Fit located in ./vendor/phpoffice/phpexcel/Classes/PHPExcel/Shared/trend/logarithmicBestFitClass.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class PHPExcel_Linear_Best_Fit located in ./vendor/phpoffice/phpexcel/Classes/PHPExcel/Shared/trend/linearBestFitClass.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Carbon 1 is deprecated, see how to migrate to Carbon 2.
https://carbon.nesbot.com/docs/#api-carbon-2
You can run './vendor/bin/upgrade-carbon' to get help in updating carbon and other frameworks and libraries that depend on it.

Illuminate\Foundation\ComposerScripts::postAutoloadDump
@php artisan package:discover --ansi
Discovered Package: appzcoder/crud-generator
Discovered Package: barryvdh/laravel-cors
Discovered Package: beyondcode/laravel-dump-server
Discovered Package: fideloper/proxy
Discovered Package: intervention/image
Discovered Package: kalnoy/nestedset
Discovered Package: laravel/tinker
Discovered Package: laravelcollective/html
Discovered Package: lawnstarter/laravel-darksky
Discovered Package: maatwebsite/excel
Discovered Package: mcamara/laravel-localization
Discovered Package: mpociot/laravel-apidoc-generator
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Discovered Package: pdffiller/laravel-influx-provider
Package manifest generated successfully.
34 packages you are using are looking for funding.
Use the composer fund command to find out more!
Nothing to migrate.

ErrorException : symlink(): No such file or directory

at /var/www/bee/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php:252
248| */
249| public function link($target, $link)
250| {
251| if (! windows_os()) {

252| return symlink($target, $link);
253| }
254|
255| $mode = $this->isDirectory($target) ? 'J' : 'H';
256|

Exception trace:

1 symlink("/var/www/bee/storage/app/public", "/var/www/bee/public/storage")
/var/www/bee/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php:252

2 Illuminate\Filesystem\Filesystem::link("/var/www/bee/storage/app/public", "/var/www/bee/public/storage")
/var/www/bee/vendor/laravel/framework/src/Illuminate/Foundation/Console/StorageLinkCommand.php:35

Please use the argument -v to see more details.

Originally posted by @majo91 in #48 (comment)

The current response to POST /api/login returns the following body:

{
  "id": 16,
  "name": "redacted",
  "email": "[email protected]",
  "avatar": "default.jpg",
  "api_token": "redacted",
  "created_at": "2020-01-16 18:18:57",
  "updated_at": "2020-02-06 23:52:45",
  "last_login": "2020-02-06 23:52:45",
  "policy_accepted": "beep_terms_2018_05_25_avg_v1",
  "email_verified_at": "2020-01-16 18:19:14"
}

Please add an expires_at property that indicated the expiration date of the api token.
I also notice that the dates do not have a timezone included. I suggest switching to ISO8601 format with the timezone included: YYYY-MM-DDTHH:MM:SS+/-hh:mm -> 2020-01-16T20:34:22+01:00. Preferably all dates are UTC by default, unless requirements specify otherwise.

289:3 error Duplicate key 'sensors' -> remove second key/value pair
376:3 error Duplicate key 'temperature' -> change second key to outsideTemperature
379:3 error Duplicate key 'humidity' -> remove second key/value pair
394:3 error Duplicate key 'year' -> change first key to years_old

Boolean checks should be as such for inspect.html:

-editing inspection only allowed when inspection.owner = true
-creating new inspection only allowed when hive.editable = true OR hive.owner = true

(in inspections.html these checks are already in place)

for hive-edit.html:

-editing hive only allowed when hive.editable = true OR hive.owner = true

Always receiving a 403 error: "sensor_not_yours" when no devices are present.

When calling GET https://test.beep.nl/api/sensordefinition I receive a 500 server error.

I think I have no definitions (can't check ;) so it might be a null pointer.

First part of error:

<!DOCTYPE html><!--


ErrorException: Trying to get property of non-object in file /opt/bitnami/apps/test.beep.nl/app/Http/Controllers/Api/SensorDefinitionController.php on line 74
Stack trace:

When executing `POST https://test.beep.nl/api/devices' with payload:

{"key":"fafafafafafafaf9","name":"MyBase","hardware_id":"0123456789abcdefffff"}

The hardware_id is not stored.
When writing the property as hardwareId it is also not stored.

Currently the invitation color value stays null when group has a hex_color. Fixing this would enable us to display the invitation in the correct group color.

Would expect a 4xx code e.g. 403 or 409. Also, please separate the error code and the detail message. See #30 for an example.

This is when I try to register a device TWICE, with the same account. So this is NOT the "device not yours" error.

Such that Vue can access the returned error messages. Most importantly for the User controller.

Such that user can choose a color for his/her apiary, which will be displayed in the apiary list.
Similar to how it currently works for groups.

(this can then be included in the apiary wizard by @JuliaBD)

Please change this to a 404 if no device was found.

For example device 257 (Kast 1 - BEEPBASE-TEST-0E93) (s_bin_480_532) and device 60 (Test 3 - BEEPBASE-EBE9) (s_bin_0_201 to 1807_2008).

SOUND:

    's_bin_480_532',
    's_bin_0_201',
    's_bin_201_402',
    's_bin_402_602',
    's_bin_602_803',
    's_bin_803_1004',
    's_bin_1004_1205',
    's_bin_1205_1406',
    's_bin_1406_1607',
    's_bin_1607_1807',
    's_bin_1807_2008',

SENSOR_NAMES:

  s_bin_480_532: '480-532Hz',
    s_bin_0_201: '0-201Hz', 
    s_bin_201_402: '201-402Hz',
    s_bin_402_602: '402-602Hz',
    s_bin_602_803: '602-803Hz',
    s_bin_803_1004: '803-1004Hz',
    s_bin_1004_1205: '1004-1205Hz',
    s_bin_1205_1406: '1205-1406Hz',
    s_bin_1406_1607: '1406-1607Hz',
    s_bin_1607_1807: '1607-1807Hz',
    s_bin_1807_2008: '1807-2008Hz',

SENSOR_UNITS:

    s_bin_480_532: '',
    s_bin_0_201: '',
    s_bin_201_402: '',
    s_bin_402_602: '',
    s_bin_602_803: '',
    s_bin_803_1004: '',
    s_bin_1004_1205: '',
    s_bin_1205_1406: '',
    s_bin_1406_1607: '',
    s_bin_1607_1807: '',
    s_bin_1807_2008: '',

Issue: Creating a new apiary gives the error that only 14 out of 15 arguments are provided for the createHive call on line 293 of HiveFactory.php, inside createMultipleHives function. The 'hive_layers' argument (see end of line 15) is missing. (The result is that new location is created in the db, but without any hives or hive_layers)

Solution: Please update 'createMultipleHives' function (in HiveFactory.php, called in LocationController.php) to include hive_layers as an argument.

-in LocationController, please call the property 'layers' instead of 'hive_layers' (better for my code consistency)
-ignore 'brood_layers' and 'honey_layers' properties whenever 'layers' is not null? Or whenever 'brood_layers' and 'honey_layers' are null / undefined?

Suggested format:

{
  "error": "some_immutable_error_enum_string_so_we_can_differentiate",
  "message": "This could contain some detail, and can be different for each invocation",
}

No need to add the http status code, since that's already in the response.

If you want to keep the possibility open for multiple errors, if applicable, you can decide to always return an array of errors such as:

[
  {
    "error": "some_error",
    "message": "some message",
  },
    "error": "some_other_error",
    "message": "some other message",
  },
]

But if you do, please always return errors an array for all calls, even if there is only one error.

Save export .csv file in data storage and return link such that the download link can easily be inserted in the download button

For hives that already existed with those layer types (feeding_box & queen_excluder), the type has been renamed (to 'beelogger' and 'deutsch_normalmass_1_5').

So something seems to be going wrong with the hive layers, when the type is not brood or honey.

Problem: When creating a new apiary, you can choose several options at the hive settings ("Hive amount at this location", "brood layers", etc.) These probably should be limited to numerical values, but the user can actually type in any value, like characters or special symbols.

Dear @pvgennip,

just a quick note. When registering for an account with an email address like [email protected], we found that the form-prefill back on the login page you are redirected to after confirming the activation email would not honor plus characters (+) properly.

This yielded

to us.

Just a convenience thing, not really a stopper bug.

Cheers,
Andreas.