by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Julian
    @JulianFeinauer
    But would be interesting to discuss the topic together with you
    Patrick Sernetz
    @patrickse
    :+1:
    Shan Desai
    @shantanoo-desai
    Hi all, quick question. Is it a possibility to host Vorto as a standalone instance and instead of sending data to a Cloud, the data is sent to a database on the server? I went through the videos of Vorto but couldn't wrap my head around a case where I can send the data to a database not on a cloud platform
    Kevin Olotu
    @kolotu

    Hi @shantanoo-desai , sure you can host your own Vorto Repository on your local machine or a server that's not in a cloud. You can either run the SpringBoot application directly, or use our Docker image to spin up your own instance. You can find a quickstart guide for using the Docker image here: https://github.com/eclipse/vorto/blob/master/docker/Readme.md

    If you have further questions feel free to reach out again.

    Shan Desai
    @shantanoo-desai
    Hi @kolotu I am now able to grasp the concept of Vorto. What I am unable to grasp is whether Vorto is compatible only with Bosch IoT Suite or similar platforms or can one use the examples such as MQTT python to send information to custom brokers.
    Are there some plans to provide some codes for Time Series Databases like InfluxDB? A lot of times it might be useful to observe the Things over a span of time and not just a generic overview
    Kevin Olotu
    @kolotu

    @shantanoo-desai Vorto is not restricted to any specific platform. I think for understanding how it works, it is important to distinguish the different components.

    The Vorto repository is a standalone application with a REST API that you can call from any application. There is a Java client that simplifies the integration for Java application.

    The Payload Mapping Engine (aka. Vorto Middleware) is a separate component that retrieves the mapping specifications from the repository and uses it to map telemetry data. To receive data the Middleware supports the AMQP protocol. The middleware can be easily extended to support multiple output types. AWS Kinesis is already implemented for time series data. (see here: https://github.com/eclipse/vorto-examples/tree/master/vorto-middleware/middleware-ext-kinesis)

    We currently are not planning to add InfluxDB or other similar DBs. If you would like to do the implementation, we are glad to accept your contribution.

    Julian
    @JulianFeinauer
    Hey Vorto Experts. I have a rather general question. Are there any no code approaches to vorto generated clients. If you assume that you have a specific transport on a device you could in theory just generate a complete client, e. G for ditto and just enter parameters like io addresses or something for the features.
    Do things like that exist?
    Kevin Olotu
    @kolotu
    Hey @JulianFeinauer, yes there are approaches for Vorto generated clients. We already have a generator for Eclipse Hono that supports Java, Python and Arduino. We don't have a Ditto client at the moment, since there's mostly Hono in between device and Ditto, but technically it would be possible to write one.
    In the code base, you can check generator-eclipsehono module. On the UI, you will find the generators on the right, when you view a model
    Julian
    @JulianFeinauer
    Thanks @kolotu, I will have a look. But it still generates code? My idea would be to interpret vorto spec in an executable which allows you to enter necessary client details and then does all the communication without the need to compile
    Kevin Olotu
    @kolotu
    @JulianFeinauer yes it generates code.
    interesting idea - and how will the device use the executable to send the data?
    Julian
    @JulianFeinauer
    My idea would be to base it for our use case on apache plc4x. So the executable has a configuration view or ui to enter transport information and for each feature in the vorto spec a plc address and then go
    This would allow to integrate every plc based thing (machine) with vorto without code gen
    If there is an interpreter api or something alike I could try to hack together something as poc
    Kevin Olotu
    @kolotu

    that sounds very interesting, it would be great if you could build a poc for that.

    what do you mean by interpreter api? the api to receive the telemetry data to map it? or an api to receive the model data from the repository?

    Julian
    @JulianFeinauer
    @kolotu the second
    To interact with the model
    Get all properties and stuff
    And also fetch from repo I guess
    Julian
    @JulianFeinauer
    this is what I looked for
    Kevin Olotu
    @kolotu
    ah good, you were faster than me
    Alexander Wellbrock
    @lionax_gitlab
    @kolotu sorry for the late replay. Right, at the moment I'm using a naive memory based caching. This works fine for small setups but causes huge amounts of traffic on a restart of the client, since the cache is not persistent. I thought of something like a redis cache integration or similar. Basically I'd like to reduce the bandwith usage from the client, since it seems to be quite heavy to query models for each request when it would save a huge amount of data caching the API.
    Kevin Olotu
    @kolotu
    @lionax_gitlab no worries. I like the idea, it sounds like a useful feature to me. Have you taken a look at our current (very simple) Java client? Is that kind of caching something that you would add to that client, or would you rather have it as a separate component?
    Julian
    @JulianFeinauer
    @lionax_gitlab probably a general solution like from resilience4j could help you?
    Alexander Wellbrock
    @lionax_gitlab
    @JulianFeinauer thanks for pointing me to resilience4j, which looks quite promising. However I'm currently integrating vorto into a nodejs application so I'm not able to use the java client and instead implemented basic API features in javascript @kolotu
    Julian
    @JulianFeinauer
    H I see
    Kevin Olotu
    @kolotu
    @lionax_gitlab ah okay I understand. So the caching needs to be implemented alongside your client.
    Would you like to contribute your nodejs implementation of the Vorto client to the project?
    Perhaps to the vorto-examples repository that is dedicated for such spin-off implementations around vorto (https://github.com/eclipse/vorto-examples/)
    Julian
    @JulianFeinauer
    Hey, a rather general question… is there a way in vortolang to decide whether a way is static „const“ (like a UNIT of a Value) or if its „dynamic“ i.e. will be changed frequently by device (like regular „values“)
    Menahem Julien Raccah Lisei
    @mena-bosch
    @JulianFeinauer not sure if this answers your question, but the vortolang spec allows java-like "enums" for units. On a completely different level, functionblocks have configuration blocks (read/write) vs status blocks (read-only).
    Julian
    @JulianFeinauer
    @mena-bosch thanks for the info. Indeed I discovered them. But for example the Temperature in this tutorial Block: https://vorto.eclipse.org/#/details/org.eclipse.vorto.tutorial:Temperature:1.0.0 has two statuses and I would expect unit to be „static“ but it canot be marked as such, right?
    Menahem Julien Raccah Lisei
    @mena-bosch
    @JulianFeinauer no problems. In the case you illustrate, the status represents read-only values given by the device, where the floating point value will be indeed variable of course, while the unit is also arbitrary (as opposed to being an enumerated type). In this case, I suspect the unit is not enumerated because it comes ultimately from the specific device and is therefore considered as arbitrary. However, I have to admit I am not privy to the original thought process there, so I'm only speculating.
    Julian
    @JulianFeinauer
    Thanks for the clarification. Indeed I see a certain „danger“ of „missusing“ properties, therefore I asked if there is a keyword like „const“ which means, when received once, will never change or something
    Menahem Julien Raccah Lisei
    @mena-bosch
    @JulianFeinauer there is no "const" notation, but you could enforce a measurement unit for a given status property, e.g. status { value as double with { measurementUnit: org.eclipse.vorto.Unit.second } }
    Note that the unit must be referenced with the fully qualified namespace in this case (there's an open ticket to have a simple "using" statement making usage of the fully qualified namespace unnecessary)
    Julian
    @JulianFeinauer
    okay thanks
    I would highly opt for some kind of simplification here : )
    Menahem Julien Raccah Lisei
    @mena-bosch
    @JulianFeinauer you're welcome, and point taken :D
    Julian
    @JulianFeinauer
    I will try to continue work on my demonstrator for plc4x-vorto client with @kolotu and when then see what i will learn about vorto : )
    Menahem Julien Raccah Lisei
    @mena-bosch
    @JulianFeinauer do let either of us know if you have any other questions.
    Julian
    @JulianFeinauer
    thank you, your help is appreciated : )
    Menahem Julien Raccah Lisei
    @mena-bosch
    @JulianFeinauer pleasure!
    Kai Hudalla
    @sophokles73
    Hi Vorto, I just came back from the Building IoT conference where I attended a talk given by Sebastian Käbisch from Siemens about the Web of Things. It immediately reminded me of the information models and function blocks used by Vorto achieve similar things. I wondered if it were possible to translate the Vorto information models to WoT Thing Descriptions on the fly in order to make them accessible to developers that alreay use WoT technology to implement clients for devices etc. WDYT?
    Kai Hudalla
    @sophokles73
    @kolotu ^^^ any thoughts on this?
    Kevin Olotu
    @kolotu
    Hi @sophokles73 , yes Web of Things is a similar approach to describe devices and their capabilities. It would be great to create interoperability between Vorto and WoT. atm it's not possible to generate WoT Thing Descriptions from Vorto models - that would be a good feature - it should be implemented as a new generator, I think.
    It would probably also be useful to allow WoT Thing Descriptions as input for the Vorto Repository, so developers with those models can use Vorto to manage them. Do you have opinions on those topics @sophokles73 ? I'm also happy to hear everyone elses opinions.
    Kai Hudalla
    @sophokles73
    Managing WoT Thing Descriptions in Vorto also seems like a nice idea. The W3C is about to start a new "round of standardization" which will be dealing in particular with Discovery of devices. Sebastian invited me/us to participate in this effort and I believe that it might be worthwhile to get in touch with him and discuss if the Vorto repository could be used for such purposes. However, the Vorto repository would only serve as a place where you can find abstract Thing Descriptions, i.e. descriptions that do not contain concrete endpoint addresses and protocol bindings for specific device instances. These would need to be served by Ditto, I guess, because Ditto knows about the specific Thing ID and endpoint addresses to use to interact with the device via Ditto.
    Kevin Olotu
    @kolotu
    That sounds interesting - that would be a good use case for the Vorto Repository to embed it in this greater architecture. It would definitely be abstract Thing Descriptions, as Vorto does not know specific device properties like Thing ID and endpoint addresses.
    How can we/you get in touch with Sebastian to participate in that effort?