eclipse-thingweb / test-things Goto Github PK

Request's accept headers can be null in case they are not provided. This causes an error when .includes method called on the undefined variable.

Error happens here:

The generated Modbus forms contain "href": "?address=1&quantity=1", whereas the address should never be URI Variable. It should be part of the URI modbus+tcp://{address}:{port}/{unitID}/{address}?quantity={?quantity} e.g. modbus+tcp://127.0.0.1:60000/1/1

Currently, on port 8080 the traefik dashboard is available to anyone. We should add an authentication mechanism.

I tried on Windows to run docker-compose up as described here.

Anyhow, it fails with the following errors.

Running test thing reports JSON TDs like this..

Hence, it is not returned as JSON

see http://plugfest.thingweb.io:8083/counter for example, which indicates it is application/json

So far, we only test the TMs and TDs but not the communication. We should have end to end tests where a Consumer sends the requests. Ideally a node-wot consumer to really test TD consuming.

Even though observeproperty is in the forms, there is no observation mechanism implemented in HTTP Things

In places like https://github.com/eclipse-thingweb/test-things/blob/main/things/calculator/http/express/main.js#L66 , there is no content type being sent whereas the TD says JSON.

The HTTP and CoAP Things should be extended with affordances that exhibit media type based content negotiation as explained at https://w3c.github.io/wot-binding-templates/bindings/protocols/coap/index.html#content-negotiation

With all the Things running, we should start monitoring and managing them better.

• Prometheus with Grafana can help us identify some "low-level" issues already.
• Portainer is also a good option since it would allow us to manage containers as well. We wouldn't need to SSH, for example. It doesn't seem to be really open-source and can become paid in the future (not 100% sure of course), so @hasanheroglu will look for alternatives
• Traefik Dashboard is being tracked at #26

Still in discussion but the idea is to also add node-wot Things and manage them via a single docker compose

Once the devices are deployed, we should link to their TDs from the Readme. Also, add them to plugfest.thingweb.io

We should add BACnet Things given that the binding is online now at https://w3c.github.io/wot-binding-templates/bindings/protocols/bacnet/

Popular libraries:

• Python: https://github.com/JoelBender/bacpypes
• node: https://github.com/fh1ch/node-bacstack

For anyone interacting with Things over the specific protocol, it would be good to have knowledge about the Thing's current and past state:

• Property: value, observe subscriptions
• Action: invocation, received input, given output
• Events: emitted value, subscription amount, subscription request payloads and unsubscription request payloads (not sure how they work in general)
• Health Check of the Thing (feature of docker compose/stack)

All these should have historical values.

These can be integrated to Grafana but needs to be public. The dashboard should not be able to send values back to the Things.

Currently, the docker-compose file is meant for the deployment whereas the TDs in the repo are for local setup. Ideally, both should be supported. This means setting correct hostname and ports in the TDs are needed.

The current docker-compose file maps one port per Thing but since we want to add many Things here and do not want to ask for many ports from Eclipse, we should map one port to multiple devices internally. We need some routing of course. Some directions forward:

• https://doc.traefik.io/traefik/providers/docker/
• https://docs.docker.com/network/

Since we now have (and possibly in the future) errors that cause the crash of Things, it would be good to save and present the reasons visually so that we can work on solving them.

The following section explains how simple it is to run the things with docker-compose up. Good so far.

What I am missing is information on where certain things are visible and maybe an overall list.

E.g., http://localhost/ reports a 404 and one has to dig into the code to find for example http://localhost/http-express-calculator.
Maybe the README can contain this information or the log of docker or there could be some information in the root of HTTP etc.
Not sure w.r.t. other protocols.

We should Modbus Test Things since it is one of the bindings at https://w3c.github.io/wot-binding-templates/bindings/protocols/modbus. However, it cannot be based on the calculator since it is more property-driven. This is gonna be the case for BACnet so we can use the same TM.

Also see https://github.com/yaacov/node-modbus-serial#modbustcp-server

Currently, the dashboards are accessed through BasicAuth. It is fine but it means sharing a password so it would be better to use something like GitHub account based authorization solutions.

          Additionally, we can also save the dashboard config in GitHub. That way, anyone who tests locally can replicate the hosted dashboard

Originally posted by @egekorkan in #30 (comment)

Currently, we set the TD port and container port to the same value, but the container port must be set to PORT_IN and the TD port must be set to PORT_OUT.