Device details screen redirects to login screen for non Admin user

[demon-xxi]

[10/1/2015 12:32:45 PM] Artem Sorokin: Steps to reproduce:

1. Create user
2. Create network
3. Register device in the user network
4. Go to device details
   [10/1/2015 12:32:55 PM] Artem Sorokin: Actual result:
   User is logged out
   [10/1/2015 12:33:05 PM] Artem Sorokin: Expected result:
   User can see device details

[demon-xxi]

Did initial investigation and the root cause is that device details screen is trying to access http://playground.devicehive.local/api/rest/device/class API which is not accessible to the non Admin user. So it gets 401 response and automatically switches to login view.

https://github.com/devicehive/devicehive-admin-console/blob/stable/scripts/models/DeviceEquipment.js#L48

We should either enable non Admin users to get device classes or refactor device equipment panel to use deviceClass and device/equipment info directly from /device result not requesting /class API at all.

[henrikbjorn]

Maybe i am mistaking, but you "fixed" this by commenting out some js and html so that equipment is not viewable on device classes?

[demon-xxi]

@henrikbjorn, we are going to deprecate equipment both for deviceclasses and devices. Right now even creation of equipment is broken on the api level and it was never properly adopted or used.
So I removed GUI related to that. The API will be trimmed accordingly.
We may add ability to set arbitrary data for device which should cover more cases than strictly typed equipment at is is now. But generally the more we can remove state and data from device management the better. It is recommended to store and update domain data outside of device hive device management. And that will scale better too.
If you have use cases related to equipment please share with us to take into account for api changes.

[henrikbjorn]

@demon-xxi Maybe i am missing something, but wont that change the flow of notification where an equipment notification will notify of a state change?

We use Equipment on DeviceClass level in order to have a structure of what a given device class has of equipment, this is used by application to determaine which graphs etc to show.

Equipment on a device level is used to save the latest state of an equipment, this allows us to poll for changes in some applications, what only need the last raw value.

Personally i feel like it will be a huge mistake removing equipment from device classes and devices. It will force us to build the equipment functionality, and thus remove some of the benefit DeviceHive gives us in terms of a functional api.

[demon-xxi]

@henrikbjorn thanks on following this up. Can you send us some examples to info@devicehive.com on how you describe schema and how it is used after that? As I pointed above we want to get rid of this functionality as it is, not fully working and barely used. You may be the first one to report that useful :) In this case we will look into rewriting it or providing an alternative as part of DH or an extension. So that you do not need to implement this yourself. But we still need to rewrite as of current state. Provide better API, documentation etc.. So knowing your case we may come up with better or at least not worse solution.

[henrikbjorn]

Disclaimer: I am only interested in the design changes. We dont use any of the "official" server implementations. But have our own implemented in Golang using NSQ as a message bus.

The device classes is used to identify the type of Device. Each device class is different and have supported equipment (in this case sensors). The equipment Code and Type is also then used when doing analytics and calculations (eg normalizing temperature or pressure).

The equipment raw value is not used much, but a couple of application does some low level calculations based on lets say temperature and then uses this to control the flow of hot water or similiar.

The equipment api was one of the big wins by chosing to implement the DeviceHive spec.

[demon-xxi]

Oh, golang sounds interesting. Did you have chance to look into devicehive/IoT-Framework already? It has golang client for DH.

Do you think it makes sense to refactor API to have ability to set multiple equipment sets to device? Right now Device has only one specific DeviceClass that has a predefined set of Equipment definitions.
We had some cases where a Gateway was running DH client and we could install multiple applications on it with different set of sensors. Basically reusing gw for multiple uses.
In this case though the schema comes not from device class but rather the device itself reporting uses it provides.

Also did you have any need for structured equipment values. For example gyroscope values with multiple axes?