Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    I sent you the link already
    I don’t have doc for the client. Onboard device using plgd mobile app to try.plgd.cloud and use the ui to interact with resources.
    atulkprajapati
    @atulkprajapati
    Can you suggest me a way, to connect with you in private and get a good understanding of the topic and implementation?
    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    I suggest you to firstly go through plgd.dev and iotivity.org and make hands dirty.
    There is enough context to get a good understanding.
    8 replies
    atulkprajapati
    @atulkprajapati

    Sure, thank you for the guidance

    I suggest you to firstly go through plgd.dev and iotivity.org and make hands dirty.

    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    🙂 because it’s not integrated with the gpio of the raspberry pi. The glue between the IoTivity code and raspi has to be done on your own.
    atulkprajapati
    @atulkprajapati
    Actually in the README, it's mentioned that it should work if connected to GPIO 7. Anyways, can you please guide me as to where can I find resources for that glue(ing) procedure :)
    Ondrej Tomcik
    @ondrejtomcik
    Could you please send me link to that readme?
    I honestly cannot guide you, I never did it. I would look for a bash script for raspi how to enable led, and execute it from the iotivity-lite light resource. That's the most simple way in my opinion.
    3 replies
    But pretty dirty. But I don't think you are now looking for a clean solution ;)
    Krzysztof Włodarczyk
    @kwlodarczyk
    @Danielius1922 In your description here https://deploy-preview-35--previewplgd.netlify.app/features/ocf-cloud-api/ you are using ngrok to to forward notifications from to the CTT. Why is forwarding needed in the first place? The local plgd instance and the CTT are running in the same local network, so there should not be a need to forward notification over the Internet, right? In my setup the notifications are not getting through, but only when they are forwarded via ngrok. Ideally we would like to remove ngrok from the setup. Could you please give me some hint on how to debug notifications on plgd side? Could it be some issue with the certificate of the event callback server? Are there logs in plgd cloud that I could check?
    Daniel Adam
    @Danielius1922
    @kwlodarczyk to be honest I was told to use ngrok, so I haven't investigated what would be necessary to make it run without it. However, I think the issue are certificates and that they must have specified protected domains - in our certificates that's localhost. We currently have no way of deploying custom certificates or generating certificates with different protected domain. (@jkralik please correct me if I got it wrong here). So I think it's not possible to avoid ngrok right now.
    Krzysztof Włodarczyk
    @kwlodarczyk
    @Danielius1922 @ondrejtomcik I have one more question. Today retrieving of auth code for a new device stopped working on pldg bundle. I'm getting error like below. Is this a known issue on your side? I tried deleting the docker container, image, persistent storage, etc but nothing seems to help. Any clues?
    obraz.png
    Ondrej Tomcik
    @ondrejtomcik
    @kwlodarczyk no, we don’t have this issue.
    Just for your information, we’ve just released new plgd hub version v2.2.0 . Mock OAuth Server which is built in in the bundle now works with the CTT tool, that means, you don’t need any external OAuth Server. You can execute all the tests just by running the bundle.
    Target Cloud conformance testing is documented here. https://plgd.dev/tutorials/ocf-conformance-testing/
    Origin Cloud conformance testing is in progress.
    Build of image is in progress. It should be pushed in 1-2 hours. Please let me know if everything works for you tomorrow morning.
    Wouter van der Beek
    @WAvdBeek
    Hi Josef, i have revert the pull request merge of yesterday.
    however this revert is still has an issue with plgd... not sure if that is related to plgd or iotivity.
    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]

    Hello Wouter. Jozef found the issue already. As soon as he is online, he will upstream the fix. I don’t know where the problem was. Let’s see.

    What do you mean issue with plgd? Where do you experience something failing, where plgd hub is included? Do you mean plgd hub tests?

    Wouter van der Beek
    @WAvdBeek
    however when the merge is done, everything is run again and then the same test passed, weird...
    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    We are on it.
    Wouter van der Beek
    @WAvdBeek
    well i would like to have now confirmation by comarch that it is working again, and make a new release.
    (e.g. tomorrow)
    then we can try to merge again...
    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    Ok. We have two more fixes + this one Jozef is working on. I will send you an email this evening / tomorrow.
    Fix for atomic, for create op and this one you just discovered.
    And Wouter, you didn’t sign up for plgd T-shirt. You really don’t want one? 🙂
    Wouter van der Beek
    @WAvdBeek
    oh, i forgot about the t-shirt...
    xxl please!
    Jozef Kralik
    @jkralik
    @WAvdBeek I'm ok with your suggestion. The PR iotivity/iotivity-lite#172 contains the fix .
    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    Check the commits, one is revert of revert, another one is one line fix.
    Krzysztof Włodarczyk
    @kwlodarczyk

    @kwlodarczyk no, we don’t have this issue.
    Just for your information, we’ve just released new plgd hub version v2.2.0 . Mock OAuth Server which is built in in the bundle now works with the CTT tool, that means, you don’t need any external OAuth Server. You can execute all the tests just by running the bundle.

    @ondrejtomcik
    Sorry for delayed answer. Yes, the updated plgd bundle works well. To account for the changes you mentioned Comarch needed to revise handling of account linking, retrieving token for device etc. which for previously used external auth server already took significant amount of time to figure out and automate. Automated tests of Target Cloud are soon to be finished. After additional adjustments they work well with the current plgd bundle, with the mocked oauth server as well as with the auth0.

    Origin Cloud conformance testing is in progress.

    Please let me know once you have this ready so Comarch can begin work on automating Origin Cloud tests.

    1 reply
    Wouter van der Beek
    @WAvdBeek
    the check fails, not sure why
    Daniel Adam
    @Danielius1922
    @WAvdBeek I'll look into it, need a few minutes to finish something and I'm on it.
    The re-run succeeded, it might be an unreliable test...? I'll check it out.
    Daniel Adam
    @Danielius1922

    Hi @SiMet , @kwlodarczyk , I'm working on Origin Cloud test cases and I'm currently stuck on 6.3.1. I keep getting an SSL connection error.

    13:28:29 DEBUG Starting verification with ID:"CT6.3.1_Check_3"...
    13:28:29 DEBUG Checking response(s) to notification(s) for event devices_registered for subscription 3ed8877f-1751-4e1b-a3f2-3337a0fe3015
    13:28:29 DEBUG Response to notification request ID=46461973: <request failed>
    13:28:29 ERROR CT6.3.1_Check_3: Notification request ID=46461973 for event devices_registered for subscription 3ed8877f-1751-4e1b-a3f2-3337a0fe3015 failed: The underlying connection was closed: Could not establish t...
    13:28:29 DEBUG continued: ...rust relationship for the SSL/TLS secure channel.
    13:28:29 DEBUG Verification with ID:"CT6.3.1_Check_3" ended with result: FAILED

    I think it's trying to send message to eventsUrl (in my case https://192.168.1.44/c2c/connector/api/v1/events
    ), but it cannot establish connection. This is the relevant part of my PICS configuration file:

    "cloudClientTrustAnchorCertificate": "...",
    "redirectUri": "https://192.168.1.44/c2c/connector/api/v1/oauthCallback",
    "bulkSubscribe": true,
    "asynchronousOperation": false,
    "supportedSubscriptionEventTypes": ["devices_online", "devices_offline", "devices_registered", "devices_unregistered", "resources_published", "resources_unpublished", "resource_contentchanged"],

    I've changed the cloudClientTrustAnchorCertificate to rootCA certificate of my running plgd-dev bundle, but it doesn't seem to work. Any idea what I might be doing wrong? Thanks.

    Krzysztof Włodarczyk
    @kwlodarczyk

    Hi @Danielius1922,

    After quickly looking at the code I suspect that the notification sender inside the CTT's Target Cloud simulator may be lacking a piece of code that makes use of the "cloudClientTrustAnchorCertificate" PICS value. However I'm not 100% sure yet. I'll try to look into this and let you know.

    If my suspicion turns true, then Comarch will need to fix that. As a temporary workaround you could try to install the plgd root cert as a trusted root CA in windows before running the CTT.

    Daniel Adam
    @Danielius1922
    @kwlodarczyk indeed, after importing the certificate from PICS into Windows as a trusted root certificate authority, the 6.3.1 test case works. I'm going to test 6.3.2-4 tomorrow using this workaround. If they work then all 6.x.x work with our plgd hub bundle and I'm gonna write down the guide how to make all tests pass.
    Krzysztof Włodarczyk
    @kwlodarczyk

    @Danielius1922, @ondrejtomcik

    Thanks for checking. I've confirmed today that the the CTT indeed does not configure trusted CA for requests containing notifications. This needs to be corrected on the CTT side. The fix is not very complex, however it would require to prepare an unofficial dedicated release to deliver it. Is it sufficient for you to finish your job using the mentioned workaround or is it necessary to release the fix to you?

    Ondrej Tomcik
    @ondrejtomcik:matrix.org
    [m]
    We can continue without the fix. But please let us know when the fix is available. When do you expect next release?
    2 replies
    Daniel Adam
    @Danielius1922
    With the workaround I was able to get all 6.3.x test cases working, which means that all 6.x.x test cases pass with the plgd hub bundle. I'll write down the How-To guide tomorrow.
    Krzysztof Włodarczyk
    @kwlodarczyk
    Excellent news! I've never used Origin Cloud part of plgd before. It will be great to see it in action. Please share the guide once it's ready.
    7 replies
    Ondrej Tomcik
    @ondrejtomcik
    By the way @kwlodarczyk as you see the setup to execute tests and switch between tests is super complicated. It would be perfect to simplify this process on the CTT side.
    Krzysztof Włodarczyk
    @kwlodarczyk

    @ondrejtomcik
    Do you mean that different configuration is needed to pass individual test cases? I think this could be simplified at least partially just by using one PICS for multiple tests. If you can su
    Please note that CTT test cases only implement what is written in the CTR. The fact that each test case requires a slightly different setup is a dictated by conditions specified in the CTR. If we are talking about changing PICS values for specific test cases then I agree that it should not be needed. The values that you set in the tutorial exclusively for specific tests should rather be defined once as they specify the behavior of the IUT. In my understanding an IUT that is under certification should stick to one behavior and apply only to those test cases which verify that behavior, other tests should be NA. If you say that asynchronousOperation is supported, then you should only run CT6.3.4 and CT6.3.1-3 are NA; and conversely, if it is not supported, you run CT6.3.1-3 and CT6.3.4 is NA. Which test is applicable to which behavior is dictated by the CTR. We cannot change the implementation unless OCF changes the CTR. I understand that plgd supports both and of course there is value in testing both, however the eventing test cases are not designed to be executed all in one run.

    I don't see any other PICS configuration that would need to be set exclusive:

    • cloudClientTrustAnchorCertificate can be set once for all test cases; it is used only to allow verification of server certificate when CTT Target Cloud simulator sends a notification to Origin Cloud; in other test the value is not used
    • bulkSubscribe can be set once; tests other than CT6.3.x just ignore that option
    • redirectUri - this value is simply displayed to the Test Operator in each prompt to do Account Linking

    To sum up, the tutorial can be simplified to provide all the PICS values once, with "asynchronousOperation": false and if you want to test also the asynchronous behavior, then you could provide second PICS with "asynchronousOperation": true. For each of the two you can run all the test cases:

    • those which are not applicable will be NA
    • for some tests the CTR defines separate test flow
    • other will run exactly the same flow as for the other behavior

    Please let me know if you have specific suggestions on what else can be done to make the setup less complex.