Actions

Actions are events performed to devices, changing their state. Actions can have attributes defining where it happened, who performed them, when, etc. Actions are stored in a log for each device. An exemplifying action can be Repair, which dictates that a device has been repaired, after this action, the device is in the repaired state. Another example is performing a Sell to agent 1 (now this agent owns the device), and then performing another Sell to agent 2 (now agent 2 is the owner).

Devicehub actions inherit from schema actions, are written in Pascal case and using a verb in infinitive. Some verbs represent the willingness or assignment to perform an action; ToRepair states that the device is going to be / must be repaired, whereas Repair states that the reparation happened. The former actions have the preposition To prefixing the verb.

Actions and States affect devices in different ways or dimensions. For example, Repair affects the physical dimension of a device, and Sell the political dimension of a device. A device can be in several states at the same time, one per dimension; ie. a device can be repaired (physical) and reserved (political), but not repaired and disposed at the same time:

  • Physical actions: The following actions describe and react on the Physical condition of the devices.

    • ToPrepare and prepare.

    • ToRepair, Repair

    • ReadyToUse

    • Live

    • DisposeWaste, Recover

  • Association actions: Actions that change the associations users have with devices; ie. the owners, usufructuarees (from usufruct), reservees (from reserve), and physical possessors.

    • Trade

    • Transfer

    • Organize

  • Internal state actions: Actions providing metadata about devices that don’t usually change their state.

    • Snapshot

    • Add, remove

    • Erase

    • Install

    • Test

    • Benchmark

    • Rate

    • Price

The following index has all the actions (please note we are moving from calling them Event to call them Action):

Schema

Thing

Extends Schema

type

Text. The name of the type of Thing, like “Device” or “Receive”. This is the same as JSON-LD @type.

This field is required when submitting values so Devicehub knows the type of object. Devicehub always returns this value.

sameAs

List.

Submit

No.

updated

Date time (ISO 8601 with timezone). The last time Devicehub recorded a change for this thing.

Submit

No.

created

Date time (ISO 8601 with timezone). When Devicehub created this.

Submit

No.

Action

Extends Thing

Action performed on a device.

This class extends Schema’s Action.

id

UUID.

Submit

No.

name

Text. A name or title for the action. Used when searching for actions.

closed

Boolean. Whether the author has finished the action. After this is set to True, no modifications are allowed. By default actions are closed when performed.

severity

Severity. A flag evaluating the action execution. Ex. failed actions have the value Severity.Error. Devicehub uses 4 severity levels:

  • Info (Pass): default neutral severity. The action succeeded.

  • Notice: The action succeeded but it is raising awareness. Notices are not usually that important but something (good or bad) worth checking.

  • Warning: The action succeeded but there is something important to check negatively affecting the action.

  • Error (Fail): the action failed.

Devicehub specially raises user awareness when an action has a Severity of Warning or greater.

Info
Notice

1

Warning

2

Error

3

description

Text. A comment about the action.

startTime

Date time (ISO 8601 with timezone). When the action starts. For some actions like reservations the time when they are available, for others like renting when the renting starts.

endTime

Date time (ISO 8601 with timezone). When the action ends. For some actions like reservations the time when they expire, for others like renting the time the end rents. For punctual actions it is the time they are performed; it differs with created in which created is the where the system received the action.

snapshot

Snapshot.

Submit

No.

agent

Agent. The direct performer or driver of the action. e.g. John wrote a book.

It can differ with the user that registered the action in the system, which can be in their behalf.

author

User.

Submit

No.

components

List of Component.

Submit

No.

parent

Computer. For actions that are performed to components, the device parent at that time.

For example: for a EraseBasic performed on a data storage, this would point to the computer that contained this data storage, if any.

Submit

No.

url

URL. The URL where to GET this action.

Submit

No.

ActionWithOneDevice

Extends Action

device

Device.

ActionWithMultipleDevices

Extends Action

devices

List of Device.

Required

Yes.

Add

Extends ActionWithOneDevice

The act of adding components to a device.

It is usually used internally from a Snapshot, for example, when adding a secondary data storage to a computer.

Remove

Extends ActionWithOneDevice

The act of removing components from a device.

It is usually used internally from a Snapshot, for example, when removing a component from a broken computer.

Allocate

Extends ActionWithMultipleDevices

to

User. The user the devices are allocated to.

organization

Text. The organization where the user was when this happened.

Deallocate

Extends ActionWithMultipleDevices

from

Nested. The user where the devices are not allocated to anymore.

organization

Text. The organization where the user was when this happened.

EraseBasic

Extends ActionWithOneDevice

An erasure attempt to a DataStorage. The action contains information about success and nature of the erasure.

EraseBasic is a software-based fast non-100%-secured way of erasing data storage, performed by Workbench Computer when executing the open-source shred.

Users can generate erasure certificates from successful erasures.

Erasures are an accumulation of erasure steps, that are performed as separate actions, called StepRandom, for an erasure step that has overwritten data with random bits, and StepZero, for an erasure step that has overwritten data with zeros.

Erasure standards define steps and methodologies to use. Devicehub automatically shows the standards that each erasure follows.

steps

List of Step.

standards

List.

Submit

No.

certificate

URL.

Submit

No.

EraseSectors

Extends EraseBasic

A secured-way of erasing data storages, checking sector-by-sector the erasure, using badblocks.

ErasePhysical

Extends EraseBasic

The act of physically destroying a data storage unit.

method

PhysicalErasureMethod. Methods of physically erasing the data-storage, usually destroying the whole component.

Certified data-storage destruction mean, as of UNE-EN 15713, reducing the material to a size making it undecipherable, illegible, and non able to be re-built.

Shred

Reduction of the data-storage to the required certified standard sizes.

Disintegration

Reduction of the data-storage to smaller sizes than the certified standard ones.

Step

Extends Schema

type

Text. Only required when it is nested.

startTime

Date time (ISO 8601 with timezone).

Required

Yes.

endTime

Date time (ISO 8601 with timezone).

Required

Yes.

severity

Severity. A flag evaluating the action execution. Ex. failed actions have the value Severity.Error. Devicehub uses 4 severity levels:

  • Info (Pass): default neutral severity. The action succeeded.

  • Notice: The action succeeded but it is raising awareness. Notices are not usually that important but something (good or bad) worth checking.

  • Warning: The action succeeded but there is something important to check negatively affecting the action.

  • Error (Fail): the action failed.

Devicehub specially raises user awareness when an action has a Severity of Warning or greater.

Info
Notice

1

Warning

2

Error

3

StepZero

Extends Step

StepRandom

Extends Step

Benchmark

Extends ActionWithOneDevice

The act of gauging the performance of a device.

elapsed

TimeDelta.

Required

Yes.

BenchmarkDataStorage

Extends Benchmark

Benchmarks the data storage unit reading and writing speeds.

readSpeed

Float.

Required

Yes.

writeSpeed

Float.

Required

Yes.

BenchmarkWithRate

Extends Benchmark

The act of benchmarking a device with a single rate.

rate

Float.

Required

Yes.

BenchmarkProcessor

Extends BenchmarkWithRate

Benchmarks a processor by executing BogoMips. Note that this is not a reliable way of rating processors and we keep it for compatibility purposes.

BenchmarkProcessorSysbench

Extends BenchmarkProcessor

Benchmarks a processor by using the processor benchmarking utility of sysbench.

BenchmarkRamSysbench

Extends BenchmarkWithRate

Benchmarks a RAM by using the ram benchmarking utility of sysbench.

BenchmarkGraphicCard

Extends BenchmarkWithRate

Test

Extends ActionWithOneDevice

The act of documenting the functionality of a device, as for the R2 Standard (R2 Provision 6 pag.19).

severity in Action defines a passing or failing test, and ereuse_devicehub.resources.device.models.Device.working in Device gets all tests with warnings or errors for a device.

MeasureBattery

Extends Test

A sample of the status of the battery.

Ref in R2 Provision 6 pag.22 Example: Length of charge; Expected results: Minimum 40 minutes.

Operative Systems keep a record of several aspects of a battery. This is a sample of those.

Failing and warning conditions are as follows:

  • Severity.Error: whether the health are Dead, Overheat or OverVoltage.

  • Severity.Warning: whether the health are UnspecifiedValue or Cold.

size

Integer. Maximum battery capacity, in mAh.

Required

Yes.

voltage

Integer. The actual voltage of the battery, in mV.

Required

Yes.

cycleCount

Integer. The number of full charges – discharges cycles.

health

BatteryHealth. The health of the Battery. Only reported in Android.

Cold

Cold

Dead

Dead

Good

Good

Overheat

Overheat

OverVoltage

OverVoltage

UnspecifiedValue

UnspecifiedValue

TestDataStorage

Extends Test

The act of testing the data storage.

Testing is done using the S.M.A.R.T self test. Note that not all data storage units, specially some new PCIe ones, do not support SMART testing.

The test takes to other SMART values indicators of the overall health of the data storage.

Failing and warning conditions are as follows:

  • Severity.Error: whether the SMART test failed.

  • Severity.Warning: if there is a significant chance for the data storage to fail in the following year.

elapsed

TimeDelta.

Required

Yes.

length

TestDataStorageLength.

Short

Short

Extended

Extended

Required

Yes.

status

Text.

Required

Yes.

lifetime

TimeDelta.

assessment

Boolean.

reallocatedSectorCount

Integer.

powerCycleCount

Integer.

reportedUncorrectableErrors

Integer.

commandTimeout

Integer.

currentPendingSectorCount

Integer.

offlineUncorrectable

Integer.

remainingLifetimePercentage

Integer.

StressTest

Extends Test

The act of stressing (putting to the maximum capacity) a device for an amount of minutes.

Failing and warning conditions are as follows:

  • Severity.Error: whether failed StressTest.

  • Severity.Warning: if stress test are less than 5 minutes.

elapsed

TimeDelta.

Required

Yes.

TestAudio

Extends Test

The act of checking the audio aspects of the device.

Failing and warning conditions are as follows:

  • Severity.Error: whether speaker or microphone variables fail.

  • Severity.Warning: .

speaker

Boolean. Whether the speaker works as expected.

microphone

Boolean. Whether the microphone works as expected.

TestConnectivity

Extends Test

The act of testing the connectivity of the device.

A failing test means that at least one connection of the device is not working well. A comment should get into more detail.

TestCamera

Extends Test

Tests the working conditions of the camera of the device, specially when taking pictures or recording video.

Failing and warning conditions are as follows:

  • Severity.Error: whether the camera cannot turn on or has significant visual problems.

  • Severity.Warning: whether there are small visual problems with the camera (like dust) that it still allows it to be used.

TestKeyboard

Extends Test

Whether the keyboard works correctly.

Failing and warning conditions are as follows:

  • Severity.Error: if at least one key does not produce a character on screen. This follows R2 Provision 6 pag.22.

TestTrackpad

Extends Test

Whether the trackpad works correctly.

Failing and warning conditions are as follows:

  • Severity.Error: if the cursor does not move on screen. This follows R2 Provision 6 pag.22.

TestBios

Extends Test

Tests the working condition and grades the usability of the BIOS.

Failing and warning conditions are as follows:

  • Severity.Error: whether Bios beeps or access range is D or E.

  • Severity.Warning: whether access range is B or C.

bios_power_on

Boolean.

accessRange

BiosAccessRange.

A

  1. If by pressing a key you could access a boot menu with the network boot

B

  1. You had to get into the BIOS, and in less than 5 steps you could set the network boot

C

  1. Like B, but with more than 5 steps

D

  1. Like B or C, but you had to unlock the BIOS (i.e. by removing the battery)

E

  1. The device could not be booted through the network.

VisualTest

Extends Test

The act of visually inspecting the appearance and functionality of the device.

Reference R2 provision 6 Templates Ready for Resale Checklist (Desktop) https://sustainableelectronics.org/sites/default/files/6.c.2%20Desktop%20R2-Ready%20for%20Resale%20Checklist.docx Physical condition grade.

Failing and warning conditions are as follows:

  • Severity.Error: whether appearance range is less than B or

    functionality range is less than B.

  • Severity.Warning: whether appearance range is B or A and

    functionality range is B.

  • Severity.Info: whether appearance range is B or A and

    functionality range is A.

appearanceRange

AppearanceRange.

Z

  1. The device is new

A

  1. Is like new; without visual damage

B

  1. Is in really good condition; small visual damage in difficult places to spot

C

  1. Is in good condition; small visual damage in parts that are easy to spot, minor cosmetic blemishes on chassis

D

  1. Is acceptable; visual damage in visible parts, major cosmetic blemishes on chassis, missing cosmetic parts

E

  1. Is unacceptable; considerable visual damage, missing essential parts

Required

Yes.

functionalityRange

FunctionalityRange.

A

  1. All the buttons works perfectly, no screen/camera defects and chassis without usage issues

B

  1. There is a button difficult to press or unstable it, a screen/camera defect or chassis problem

C

  1. Chassis defects or multiple buttons don’t work; broken or unusable it, some screen/camera defect

D

  1. Chassis severity usage problems. All buttons, screen or camera don’t work; broken or unusable it

Required

Yes.

labelling

Boolean.

Rate

Extends ActionWithOneDevice

The act of computing a rate based on different categories:

  • Functionality (F). Tests, the act of testing usage condition of a device

  • Appearance (A). Visual evaluation, surface deterioration.

  • Performance (Q). Components characteristics and components benchmarks.

rating

Integer. The rating for the content.

Submit

No.

version

Version. The version of the software.

Submit

No.

appearance

Integer. Subjective value representing aesthetic aspects.

Submit

No.

functionality

Integer. Subjective value representing usage aspects.

Submit

No.

ratingRange

RatingRange.

VERY_LOW

1

LOW

2

MEDIUM

3

HIGH

4

Submit

No.

RateComputer

Extends Rate

The act of rating a computer type devices. It’s the starting point for calculating the rate. Algorithm explained in v1.0 file.

processor

Float.

Submit

No.

ram

Float.

Submit

No.

dataStorage

Float.

Submit

No.

graphicCard

Float.

Submit

No.

dataStorageRange

RatingRange.

VERY_LOW

1

LOW

2

MEDIUM

3

HIGH

4

Submit

No.

ramRange

RatingRange.

VERY_LOW

1

LOW

2

MEDIUM

3

HIGH

4

Submit

No.

processorRange

RatingRange.

VERY_LOW

1

LOW

2

MEDIUM

3

HIGH

4

Submit

No.

graphicCardRange

RatingRange.

VERY_LOW

1

LOW

2

MEDIUM

3

HIGH

4

Submit

No.

Price

Extends ActionWithOneDevice

The act of setting a trading price for the device.

This does not imply that the device is ultimately traded for that price. Use the Sell for that.

Devicehub automatically computes a price from AggregateRating actions. As in a Rate, price can have software and version, and there is an official price that is used to automatically compute the price from an AggregateRating. Only the official price is computed from an AggregateRating.

currency

Currency. The currency of this price as for ISO 4217.

Currencies as for ISO 4217.

Required

Yes.

price

Decimal. The value.

Required

Yes.

version

Version. The version of the software, or None.

Submit

No.

rating

Rate. The Rate used to auto-compute this price, if it has not been set manually.

Submit

No.

EreusePrice

Extends Price

The act of setting a price by guessing it using the eReuse.org algorithm.

This algorithm states that the price is the use value of the device (represented by its last Rate) multiplied by a constants value agreed by a circuit or platform.

warranty2

Float.

refurbisher

Nested.

retailer

Nested.

platform

Nested.

Install

Extends ActionWithOneDevice

The action of installing an Operative System to a data storage unit.

name

Text. The name of the OS installed.

Required

Yes.

elapsed

TimeDelta.

Required

Yes.

address

Integer.

Snapshot

Extends ActionWithOneDevice

The Snapshot sets the physical information of the device (S/N, model…) and updates it with erasures, benchmarks, ratings, and tests; updates the composition of its components (adding / removing them), and links tags to the device.

When receiving a Snapshot, the DeviceHub creates, adds and removes components to match the Snapshot. For example, if a Snapshot of a computer contains a new component, the system searches for the component in its database and, if not found, its creates it; finally linking it to the computer.

A Snapshot is used with Remove to represent changes in components for a device:

  1. Snapshot creates a device if it does not exist, and the same for its components. This is all done in one Snapshot.

  2. If the device exists, it updates its component composition by adding and removing them. If, for example, this new Snasphot doesn’t have a component, it means that this component is not present anymore in the device, thus removing it from it. Then we have that:

    • Components that are added to the device: snapshot2.components - snapshot1.components

    • Components that are removed to the device: snapshot1.components - snapshot2.components

    When adding a component, there may be the case this component existed before and it was inside another device. In such case, DeviceHub will perform Remove on the old parent.

Snapshots from Workbench

When processing a device from the Workbench, this one performs a Snapshot and then performs more actions (like testings, benchmarking…).

There are two ways of sending this information. In an async way, this is, submitting actions as soon as Workbench performs then, or submitting only one Snapshot action with all the other actions embedded.

Asynced

The use case, which is represented in the test_workbench_phases, is as follows:

  1. In T1, WorkbenchServer (as the middleware from Workbench and Devicehub) submits:

    • A Snapshot action with the required information to synchronize and rate the device. This is:

      • Identification information about the device and components (S/N, model, physical characteristics…)

      • Tags in a tags property in the device.

      • Rate in an actions property in the device.

      • Benchmarks in an actions property in each component or device.

      • TestDataStorage as in Benchmarks.

    • An ordered set of expected actions, defining which are the next actions that Workbench will perform to the device in ideal conditions (device doesn’t fail, no Internet drop…).

    Devicehub syncs the device with the database and perform the Benchmark, the TestDataStorage, and finally the Rate. This leaves the Snapshot open to wait for the next actions to come.

  2. Assuming that we expect all actions, in T2, WorkbenchServer submits a StressTest with a snapshot field containing the ID of the Snapshot in 1, and Devicehub links the action with such Snapshot.

  3. In T3, WorkbenchServer submits the Erase with the Snapshot and component IDs from 1, linking it to them. It repeats this for all the erased data storage devices; T3+Tn being n the erased data storage devices.

  4. WorkbenchServer does like in 3. but for the action Install, finishing in T3+Tn+Tx, being x the number of data storage devices with an OS installed into.

  5. In T3+Tn+Tx, when all expected actions have been performed, Devicehub closes the Snapshot from 1.

Synced

Optionally, Devicehub understands receiving a Snapshot with all the actions in an actions property inside each affected component or device.

uuid

UUID.

software

SnapshotSoftware. The software that generated this Snapshot.

Workbench

Workbench

WorkbenchAndroid

WorkbenchAndroid

AndroidApp

AndroidApp

Web

Web

DesktopApp

DesktopApp

Required

Yes.

version

Version. The version of the software.

Required

Yes.

actions

List of Action.

Submit

No.

elapsed

TimeDelta.

components

List of Component. A list of components that are inside of the deviceat the moment of this Snapshot.Order is preserved, so the component num 0 whensubmitting is the component num 0 when returning it back.

ToRepair

Extends ActionWithMultipleDevices

Select a device to be repaired.

Repair

Extends ActionWithMultipleDevices

Repair is the act of performing reparations.

If a repair without an error is performed, it represents that the reparation has been successful.

Ready

Extends ActionWithMultipleDevices

The device is ready to be used.

This involves greater preparation from the Prepare action, and users should only use a device after this action is performed.

Users usually require devices with this action before shipping them to costumers.

ToPrepare

Extends ActionWithMultipleDevices

The device has been selected for preparation.

See Prepare for more info.

Usually ToPrepare is the next action done after registering the device.

Prepare

Extends ActionWithMultipleDevices

Work has been performed to the device to a defined point of acceptance.

Users using this action have to agree what is this point of acceptance; for some is when the device just works, for others when some testing has been performed.

Live

Extends ActionWithOneDevice

A keep-alive from a device connected to the Internet with information about its state (in the form of a Snapshot action) and usage statistics.

ip

IP.

Submit

No.

subdivisionConfidence

Integer.

Submit

No.

subdivision

Subdivision.

Subvidision country codes from ISO 3166-2.

Taken from here.

Submit

No.

country

Country.

Countries as ISO 3166-1 alpha 2.

Taken from table from iso-3616-1 commit 8e31d749b9ce331cfa50c280a29b04ae2d805b7e.

Submit

No.

city

Text.

Submit

No.

cityConfidence

Integer.

Submit

No.

isp

Text.

Submit

No.

organization

Text.

Submit

No.

organizationType

Text.

Submit

No.

Organize

Extends ActionWithMultipleDevices

The act of manipulating/administering/supervising/controlling one or more devices.

Reserve

Extends Organize

The act of reserving devices.

After this action is performed, the user is the reservee of the devices. There can only be one non-cancelled reservation for a device, and a reservation can only have one reservee.

CancelReservation

Extends Organize

The act of cancelling a reservation.

Trade

Extends ActionWithMultipleDevices

Trade actions log the political exchange of devices between users. Every time a trade action is performed, the old user looses its political possession, for example ownership, in favor of another user.

Performing trade actions changes the Trading state of the device —ereuse_devicehub.resources.device.states.Trading.

This class and its inheritors extend Schema’s Trade.

shippingDate

Date time (ISO 8601 with timezone).

invoiceNumber

Text.

price

Price.

to

Agent.

Required

Yes.

confirms

Organize.

InitTransfer

Extends Trade

The act of transfer ownership of devices between two agents

Sell

Extends Trade

The act of taking money from a buyer in exchange of a device.

Donate

Extends Trade

The act of giving devices without compensation.

Rent

Extends Trade

The act of giving money in return for temporary use, but not ownership, of a device.

MakeAvailable

Extends ActionWithMultipleDevices

The act of setting willingness for trading.

CancelTrade

Extends Trade

The act of cancelling a `Sell`_, `Donate`_ or `Rent`_.

ToDisposeProduct

Extends Trade

The act of setting a device for being disposed.

See DisposeProduct.

DisposeProduct

Extends Trade

The act of getting rid of devices by giving (selling, donating) to another organization, like a waste manager.

See ToDispose and DisposeProduct for disposing without trading the device. See DisposeWaste and Recover for disposing in-house, this is, without trading the device.

TransferOwnershipBlockchain

Extends Trade

The act of change owenership of devices between two users (ethereum address)

Receive

Extends ActionWithMultipleDevices

The act of physically taking delivery of a device.

The receiver confirms that the devices have arrived, and thus, they are the ereuse_devicehub.resources.device.models.Device.physical_possessor.

This differs from Trade in that trading changes the political possession. As an example, a transporter can receive a device but it is not it’s owner. After the delivery, the transporter performs another receive to the final owner.

The receiver can optionally take a ereuse_devicehub.resources.enums.ReceiverRole.

role

ReceiverRole.

Intermediary

Generic user in the workflow of the device.

FinalUser

The user that will use the device.

CollectionPoint

A collection point.

RecyclingPoint

A recycling point.

Transporter

An user that ships the devices to another one.

Migrate

Extends ActionWithMultipleDevices

Moves the devices to a new database/inventory. Devices cannot be modified anymore at the previous database.

other

URL.

MigrateTo

Extends Migrate

MigrateFrom

Extends Migrate

Transferred

Extends ActionWithMultipleDevices

Transferred through blockchain.