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
    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?
    Kai Hudalla
    @sophokles73
    @kolotu I can introduce you to Sebastian by mail so you two can start discussing. WDYT?
    Kevin Olotu
    @kolotu
    @sophokles73 that would be perfect - thanks!
    Julian
    @JulianFeinauer
    @sophokles73 that's a very good idea... I'm so angry that I missed the Siemens talk
    Kevin Olotu
    @kolotu
    Hi everyone,
    Tomorrow Tuesday 17 March 2020 between 8AM-11AM CET we will perform maintenance works and a deployment on the main Vorto Repository https://vorto.eclipse.org. The repository will be inaccessible during that timeframe.
    Sorry for any inconvenience.
    Kevin Olotu
    @kolotu
    Maintenance will take longer than expected. ETA is now 2PM CET
    Kevin Olotu
    @kolotu

    We are facing some issues in the Vorto Repository. Some users might not be able to save models at the moment. We are working to fix the issue, we expect to solve the issue on Monday.

    We will send an update here, once it is resolved. Sorry for any inconvenience.

    Julian
    @JulianFeinauer
    Can I support you somehow @kolotu?
    Kevin Olotu
    @kolotu
    @JulianFeinauer thanks - we just rolled out a fix, so it should work already. We are verifying that at the moment.
    Kevin Olotu
    @kolotu
    The issue is fixed - saving models should work normally again.
    Kevin Olotu
    @kolotu
    Would there be interest in introducing a datatype for HEX properties in Vortolang? I have tentatively created an issue for it eclipse/vorto#2384
    Julian
    @JulianFeinauer
    Interesting Idea… I like how avro handles „komplex“ Types with their notion of „logical types“ vs „physical types“ (primitives how we would call it in java)
    as HEX in the ned is just… number?
    Kevin Olotu
    @kolotu
    yes HEX is a representation of a number, but since we already have integer, byte, float, etc in vortolang, maybe it would be useful to also add a primitive type for hex numbers. WDYT?
    Julian
    @JulianFeinauer
    If its not too much work it could make sense. Hex makes it way easier to express bit-masks (which are at least widely used in IIoT)
    Julian
    @JulianFeinauer

    Another Question that I have. Currently Vorto allows us only to define the „capabilities“ or „properties“ of a device but we do not have a chance to define how a „gateway“ could access them (e.g. "read from address xyz“). So I see the need for

    • Either an extension of the Specification or
    • A second complementary file format which allows to define this mapping.

    This would help us to get rid of client side code generation in some (standardized) environments. This would especially make sense in areas like IIoT (usually always PLCs to address) or think of the Bosch DYI products which I guess, have often times similar hardware with a standardized Layout and API.
    WDYT @kolotu?

    Kevin Olotu
    @kolotu

    @JulianFeinauer if I understand your question correctly you are asking, how platform-specific information (i.e. which address the gateway needs to use) can be added to a functionblock?
    That's something that could be done with Functionblock mappings, I think. They can be used to add additional platform-specific information to a functionblock.
    Here is an example how that currently looks in Vorto:
    A Functionblock: https://vorto-dev.eclipse.org/#/details/com.kevin.official.test:VehicleGearFb:1.0.0
    and the corresponding mapping that adds platform-specific information: https://vorto-dev.eclipse.org/#/details/com.kevin.official.test:VehicleGearCANMapping:1.0.0

    To see the result you can use this API: GET https://vorto-dev.eclipse.org/api/v1/models/com.kevin.official.test.VehicleGearFb:1.0.0/content/CAN

    Does this fulfil that requirement or did I misread your question?

    Julian
    @JulianFeinauer
    Thanks @kolotu this looks exactly what I was missing... Let me play around with it... Why didnt I find it somewhere.. This is a killer feature
    Kevin Olotu
    @kolotu
    @JulianFeinauer you didn’t find it, because it’s almost not documented yet - unfortunately! We have an open task for that...
    Julian
    @JulianFeinauer
    Okay, then its not only me
    good
    Julian
    @JulianFeinauer
    https://github.com/eclipse/vorto/blob/master/docs/vortolang-1.0.md
    hier ist das ja noch nicht ausreichend Dokumentiert, oder?
    Kevin Olotu
    @kolotu
    Yes exactly. On the development branch of that file is a short paragraph on Functionblock Mapping, but I think there should be a more thorough explanation and an example use case.
    Julian
    @JulianFeinauer
    yep
    In my PLC4X Use Case… this file should be totally sufficient, right?
    as it references the DB
    FB
    Kevin Olotu
    @kolotu
    I think it could be sufficient - we should just try and see whether it covers your use case entirely
    Julian
    @JulianFeinauer
    Basically the Worflow I see for IIoT / Automation is… One Party creates the „Vortofile“ (comes out of Construction usually). Then second party (PLC Programmers) does the mapping to sensors / PLC Adresses -> Mapping file. This file we then take to spin up the Monitoring
    Kevin Olotu
    @kolotu
    Yes that sounds like it fits the requirement.
    Julian
    @JulianFeinauer
    Do you have a Blog Post or something which describes the exact use case you have in mind with the VehicleGear Example files?
    Kevin Olotu
    @kolotu
    no that was just an example to show that feature. The idea behind the VehicleGear example was to add platform-specific hex values to each gear, without "hardcoding" them in the functionblock, to keep it platform-independent and reusable.
    Julian
    @JulianFeinauer
    I see
    in our case this could also be machine specific (as each machine can be programmed slightly different… for whatever reasons)
    Kevin Olotu
    @kolotu
    in that case you would need one mapping file per machine / implementation of the machine
    Julian
    @JulianFeinauer
    yep
    But one more question
    the mapping in theorie describes the value of the respectice property or just som „addidional“ information?