by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Alexander Wellbrock
    @lionax_gitlab
    No, not yet. I'm still using vorto 0.10.1 because I couldn't get your docker image for 0.11.0 running and had not enough time to fix it yet :)
    Hmm. If inheritance is a bigger issue with api v1 then I'll probably first fix the docker image problem, then migrate to 0.11.3
    Alexander Wellbrock
    @lionax_gitlab
    Do you guys plan to restart releasing on docker hub on a regular basis any time soon?
    Alexander Edelmann
    @aedelmann
    But I see that the patch versions of 0.11 are missing. Ok. I need to check on that. 0.12 release is coming end of this month.
    Alexander Wellbrock
    @lionax_gitlab

    @aedelmann I'm currently migrating my ditto skeleton generator to 0.11.3, when I'm done with that I want to integrate it in the ditto generator and file a PR. While doing so I've come to the point where I'm stuck at the question how my generator build with the API v2 running in a docker container (just like the vorto-examples) register itself at my vorto instance.

    I've basically used the jsonschema and ditto generator to migrate the generator itself to 0.11.3 and I tried to use the generator-runner from the vorto-repo to upgrade my previously used runner from the vorto-examples repo, including the CodeGeneratorV1Adapter part. Now the generator is accessible over generators:8080/rest/generators and /api/2 but it won't register itself at vorto like it did before when using api v1. What am I missing here?

    (Since I'm asking a lot of questions and I'm trying hard to understand what is going on with the plugin api and everything I'll probably contribute my findings as PR to your docs :D)
    Alexander Edelmann
    @aedelmann
    In api version 2 registration is not done automagically anymore by generator but has to be done manually. U wanna check it the vorto repo test application yml. It contains a base 64 encoded string for plugin registrations
    Alexander Wellbrock
    @lionax_gitlab
    Ok, very cool indeed. It's working now. My instance is 0.11.3 nightly, the generator runs as docker service with latest API v2 from 0.11.3 and it's now registered and generating skeletons for ditto. Interestingly enough it now outputs configuration and status recursively, butonly on the last functionblock. I've 7 functionblocks, all empty but extending a generic functionblock with both configuration and status. The 7nth has all config and status, but all others don't. Why is that so? Is is likely to be a flaw in my template or do you thing it's worth opening an issue for that?
    Alexander Edelmann
    @aedelmann
    Hmmm. Could be a bug
    Not sure
    Need to look Into it.
    Alexander Wellbrock
    @lionax_gitlab
    Ok, I'll open an issue providing everything like configs and models
    Alexander Edelmann
    @aedelmann
    I am currently on holidays. Will look into it next week in office
    Thanks for noticing
    Alexander Wellbrock
    @lionax_gitlab
    Ok, sure! Nice holidays by the way and thanks a lot for your help yet
    Alexander Edelmann
    @aedelmann
    Np + thanks
    Alexander Wellbrock
    @lionax_gitlab
    Nothing critical but I noticed, that my generator plugin in the web ui has the key as name although I specified a name in getMeta and also the .properties file. Any idea why?
    Alexander Edelmann
    @aedelmann
    Yeah it’s a known bug and needs to be improved.
    glennergeerts-aloxy
    @glennergeerts-aloxy
    Hi, we are using Vorto now mainly as a normalized format and are starting to look into using the mapping engine for mapping different payload formats to Vorto model as well. I more or less understand how to map functionblock properties from JSON or binary payload using xpath and the conversion functions. However, I'm not clear how to support parsing of non-fixed format binary payload using this method.
    For instance we have an off the shelf LoRaWAN sensor which transmits in the following format:
    <length><frame type>[<sensor-id><sensor-value>] where length is the total frame length and sensor-id (for eg temperature, humidity, battery, ...) describes how to parse the sensor-value (ie length, datatype). In one frame multiple of these readings may be present in random order.
    Parsing this can be done easily in for instance loraserver.io using a small javascript function which iterates over all the bytes en returns the parsed properties. The same way will work in the Ditto payload mapping engine afaik.
    However, currently I don't see how to do something similar in Vorto mapping. This is just one specific sensor example ofcourse, but more examples exist on the market using similar dynamic payload format. I know there is already an open issue (#1535) to improve the documentation, but it would already be helpful to know if such flexible parsing would be possible using the mapping DSL. Am I overlooking something? Thanks for any pointers
    Alexander Edelmann
    @aedelmann
    Sorry for the delay. U can write a converter function that passes the frame to the function and extract the value by iterating through. This function can be specified and used in the mapping rule for the function block property.
    The converter function can only have one param tho. Which in your case is the entire frame.
    Bob Claerhout
    @BobClaerhout

    Hey there! I'm having a problem with getting Vorto 0.11.0 docker image running through the docker-compose.yaml. I have a folder with the docker-compose.yml, vorto-variables.yml and a data folder containing repo and db data. Maybe you can point me in the right direction if I'm just missing something here or if there is a bug here.

    I'm getting the error Caused by: java.io.FileNotFoundException: /code/src/main/resources/selfsigned.jks (No such file or directory) and then

    ***************************
    repository_1  | APPLICATION FAILED TO START
    repository_1  | ***************************
    repository_1  | 
    repository_1  | Description:
    repository_1  | 
    repository_1  | The Tomcat connector configured to listen on port 8080 failed to start. The port may already be in use or the connector may be misconfigured.
    repository_1  | 
    repository_1  | Action:
    repository_1  | 
    repository_1  | Verify the connector's configuration, identify and stop any process that's listening on port 8080, or configure this application to listen on another port.

    Hi @lionax_gitlab, I'm running into the same issue and I can't seem to find the issue on github. Do you remember how you fixed this?

    Bob Claerhout
    @BobClaerhout
    This issue seems to be fixed in the nightly build. I can't seem to find tag 0.12.x on docker hub?
    Alexander Edelmann
    @aedelmann
    Yeah we having a problem with the docker build. We will deploy a patch version this week.
    Alexander Edelmann
    @aedelmann
    We pushed the latest nightly to docker hub. Can u try if it works ?
    glennergeerts-aloxy
    @glennergeerts-aloxy

    @aedelmann thank you for the answer but I still don't succeed in passing the raw payload as bytearray to the javascript function. In order to test this I duplicated the org.eclipse.vorto.mapping.engine.converter.binary.BinaryMappingTest#testMappingBinaryContaining2DataPoints and adapted the model to use a custom javascript function like this

        evaluator.addScriptFunction(new ScriptClassFunction("extractTemperature",
    "function extractTemperature(value) { " +
            " print(\"parameter of type \" + typeof value + \", value = \" + value);" +
            " print(value[1]);" +
            "}"));

    The output of this function is

    parameter of type number, value = 1
    undefined

    Where the value 1 is the first element of the bytearray used.
    So the function does not seem to receive the parameter as bytearray.

    The model is configured with .withXPathStereotype("custom:extractTemperature(data)", "demo") so the payload is passed (as BinaryData) in the same way as in the testMappingBinaryContaining2DataPoints test (.withXPathStereotype("custom:convert(vorto_conversion1:byteArrayToInt(data,0,0,0,2))", "demo")). The only difference I see now is that in the testMappingBinaryContaining2DataPoints test is that the bytearray parameter is passed to a Java function instead of a javascript function. Or am I missing something?

    Also, I noticed that loop keywords like for and while are not allowed in the javascript code. So even if I can access the bytearray parameter in the javascript function I see no way for now how to iterate over this.

    Alexander Edelmann
    @aedelmann
    You are right. We restricted the Javascript function usage to very rudimentary set of language keywords excluding for loops as nasty stuff can be implemented there. What you could do Instead is to register a java function In your own namespace to the mapping engine. That function can hold a byte array. Later this function can be contributed to the mapping engine as a standard function to extract a certain value out for other developers to reuse.
    Can we move this chat to stackoverflow :) ?
    Bob Claerhout
    @BobClaerhout

    We pushed the latest nightly to docker hub. Can u try if it works ?

    The repo was already working yesterday using the nightly build.

    Bob Claerhout
    @BobClaerhout
    I have another question though: I'm trying to release an informationmodel. The release on itself seems to work but I can't approve the model. I'm getting following error: Referenced Model with ID 'org.aloxy.vorto:Temperature:1.0.0' is not in state(s) [[Released, Deprecated]]
    Is it possible the model is not in state "released" when you triggered the release on a parent model?
    Alexander Edelmann
    @aedelmann
    You would need to review and approve each dependent model explicitly before approving the parent model
    I also added your reply and my response to this there as well ;)
    if someone with enough SO points could create the eclipse-vorto tag this would be great I think
    Alexander Edelmann
    @aedelmann
    Cool :+1:
    Yeah. Sadly I don’t have enough credits. U know anybody :) ?
    glennergeerts-aloxy
    @glennergeerts-aloxy
    nope, not yet :)
    Bob Claerhout
    @BobClaerhout
    Hi, I'm currently using the java-client to get the models. However, I can't seem to find how to get the mapping specification. Do you have an example of this such as https://github.com/eclipse/vorto/tree/development/repository/repository-java-client ?
    Alexander Edelmann
    @aedelmann
    There is currently no API to download mapping spec. U need to use the editor Web UI to download it
    Bob Claerhout
    @BobClaerhout

    Too bad, I saw this function:

     @Override
      public ModelContent getContent(ModelId modelId, ModelId mappingModelId) {
        String url = String.format("%s/%s/%s/content/mappings/%s", getRequestContext().getBaseUrl(),
            String.format(REST_MODEL_BASE), modelId.getPrettyFormat(),
            mappingModelId.getPrettyFormat());
        return requestAndTransform(url, transformToClass(ModelContent.class));
      }

    and was hopefull. I noticed that the mappingReference is also null allthough a mapping is assigned to the model. Is this correct?

    Alexander Edelmann
    @aedelmann
    Yeah. That’s needs to be cleaned up at some point.
    Bob Claerhout
    @BobClaerhout
    FYI: we are currently using the rest API to get the mappingSpec dynamically. It would be nice to have the ability to do this using the client.
    Alexander Wellbrock
    @lionax_gitlab
    The docs on the generator-runner state, that the runner exposes/features Generators for APIv1 and APIv2. In the code it's clear, that the runner uses an adapter to integrate v2 generators by using the APIv1. This also means, that APIv2 features are limited this way. I'm trying to use the runner in a docker container for a APIv2 plugin which makes use of the configuration parameters, which are part of apiv2. How do I make that work? Do I have to implement my own spring-boot APIv2 capable generator-runner or am I just missing something here? I'm trying this, since I don't want to spin up a serverless on AWS.
    Menahem Julien Raccah Lisei
    @mena-bosch
    I have added the eclipse-vorto tag to SO last week. @glennergeerts-aloxy edited your question so it now features the tag. If anyone else has an open (or resolved) question, you can now edit and add the tag.
    glennergeerts-aloxy
    @glennergeerts-aloxy
    Thanks @mena-bosch !
    Menahem Julien Raccah Lisei
    @mena-bosch
    @glennergeerts-aloxy most welcome :)
    Bob Claerhout
    @BobClaerhout

    I have created a model which uses the multiple keyword to add an array of objects. In my case, it is an array of statuses mandatory multiple Statuses as Status. The status functionblock looks as follows:

    functionblock Status {
        status {
            mandatory Type as StatusType
            mandatory Level as StatusLevel
        }
    }

    I'm trying to get this functionblock filled (in Ditto) using the java client. Is this possible using the client and if so, do you have an example of that?

    Menahem Julien Raccah Lisei
    @mena-bosch

    Hi @aedelmann , I have a bit of a tough one for you. Unfortunately given it involves quite a lot of black box/proprietary stuff, I don't think it's suitable for SO.
    TL;DR

    • Provisioning a thing through the Vorto Postman script does not generate a "fully usable" policy (i.e. it lacks a subject entry of type "bosch-id"), so it will not pop up in your things when examined from the solution dashboard at things.eu-1.bosch-iot-suite.com.
    • Provisioning a thing through the swagger API (here: apidocs.bosch-iot-suite.com) does provide the "fully usable" policy, hence the thing will appear in your... err... things.

    Details

    • The two methodologies seem to differ quite a lot, as the former uses Vorto notation while the other does not.
    • Also, the Vorto Postman script points to deviceprovisioning.eu-1.bosch-iot-suite.com/api/1/, while the one in swagger points to things.eu-1.bosch-iot-suite.com/api/2/things.
    • I have tried to modify the Postman script to point to the latter, but it does not seem to "understand" Vorto notation.

    As I'm not quite sure what happens behind the scenes there, I'm not sure how to address this, and which team(s) would ultimately be responsible to provide a solution (assuming a solution is desirable, which I think it is).

    Workaround

    • Haven't tried yet, but I suspect a simple PUT request from the things/policies swagger to add the missing policy bit should help complete the Vorto provisioning process and allow the thing to be visible in the things dashboard.
    • The missing bit looks like (under "entries"):

    "solution-owner": { "subjects": { "bosch:[my technical user id]@ciamids_[some UUID]": { "type": "bosch-id" } }, "resources": { "thing:/": { "grant": [ "READ" ], "revoke": [] } } },