Access to things resource in Gateway add-on

WebThings
,
#1

I have designed my own webthings (framework, python) to control DIY LEDs from a Raspberry Pi 0. It works.

I have set-up a gateway 12.0 on a Raspberry Pi 4. It works.

I am now learning my way through creating an add-on, the purpose of which is to replace the Things view (eventually) (for my Gateway).

One piece of information that does not seem to bubble up in the gateway from my native webthings is their “id”. The solution I found is to either use API.getThings in the extension.js cient script or localhost/things in the API Handler, from this, find out a list of webthing servers, then request things from the webthing servers (from the API handler), collect the relevant information and pass it back on to the client - not withstanding changes to the list of things.

It seems convoluted, I have the impression that I am missing something obvious - maybe I overlooked an API function or two that allow to list all things, including their original id. I develop the backend in python, but I must have searched through both the add-on python API and the client javascript API dozens of times in vain.

Hoping someone has an easier, more efficient answer to my search.

#2

The gateway is, in itself, a web thing. It’s a web thing that can essentially proxy other web things (and non-web things). Because of this, all of its device have their own IDs.

#3

Thank you for your reply & I understand the design decision, but maybe there could be a field named “original-id”, passed on for reference?

However this does not explain why the client API or the back-end add-on API do not offer what is already available and central to the gateway and webthings servers: the catalog of things. I am sure there are good reasons, but as an experienced (non web) programmer, I find it wasteful to force upon the user to replicate data structures for the sake of isolation, especially at the cost of one or several network calls. The API seems overly lean, which forces what seems to me to be unnecessarily more elaborate code to compensate for the absent bridges. I’d be happy to be educated otherwise though.

Maybe the API is lean because it is only version 0.12 and is yet to be fleshed out. May I suggest that some form of all “things” be made available more readily and directly to add-ons both in the gateway client and back end APIs?

#4

Can you explain what it is you’re trying to do? More than likely, there’s already a way to do what you need.

#5

My goal is to present all my things in a different fashion so as to reduce to the minimum possible the number of clicks to switch lights on or off or to change their colour.

Context: my home-made devices are LED strips of different varieties (addressable or not), which I have made to appear as several devices each. For example in one place I have a white LED strip and an RGB LED strip, I show three devices (let’s call this the atomic device): one with a single White channel, one with RGB channels and one with RGBW channels. But really they are all part of one device (let’s call this the unified device).

A tab menu (main menu) gives me access to various screens, including one for each zone of my home, a group of rooms or areas (e.g. Bedrooms or Outside). A sub menu (also a tab menu and always displayed, one sub menu for each zone) shows a list of sections (rooms or areas) and within each section a list of unified devices (see context above). In the sub menu the sections, rooms or areas are not clickable, only for information, the unified devices when clicked will show a screen which that allows interaction (if I can get this together) with all atomic devices for this unified device and all relevant properties and actions for the selected atomic device.

To be able to achieve this I need to identify each device as atomic, as a unified device, as belonging to a room and a zone. To this effect I have used the id field. Maybe I need to use a property instead.

Either way, I need a full list of things and I find it inefficient to have to make a network call (API.getThings, or fetch /things) on the client or the back-end when the information is already present in the client browser app and the gateway server.

#6

If you can get around using the id field, and instead use a property or the description field, your life will be much easier. Then, you can have an Adapter class in your add-on which uses handleDeviceSaved. That callback will give you all thing descriptions.

#7

Indeed you are right, I could use the description field and it would make things easier, although it feels like perverting the rightful use of what a description should be. I need to think some more about my design. Using a property might be the way to go.

As to your comment about the Adapter class, this is what I call educational (from you to me). Thank you. I don’t quite fully understand yet, but I will experiment.

#8

Ok, getting there.

The Adapter “solution” allows me to move the code from the web client to the server, which is smart, but I still feel there is such a waste of 1/ effort to replicate what is already available somewhere in the client code and the server code; and 2/ a waste of resources (data duplication, unnecessary network calls) for exactly the same reason.

I think the add-on API should make available the whole dictionary of things and their current status in a more direct way to both the server and the client add-ons.

Also I found that the handleDeviceSaved is not thread safe - which can cause issues quickly.