Hi, Maybe the development team already fixed described issues in current release (I tested on DriveConnect app V1.16 and ctrlX Core V1.18) but let me post below problems I noticed: Issue 1) When someone wants to add to DriveConnect app drives from other subnets and the drive which you add is not pingable (or is not a drive or you just entered wrong IP address) the app probably hangs and the whole DL subtree devices/drives is gone for some minutes A. Image: Before adding the drive from other subnet. In my config there is one drive (IP: 192.168.99.99) and the ctrlX core is under 192.169.99.202 B. Image: now we add a drive (e.g. 172.16.5.1 routing established, IP from existing subnet in my config) using REST API call (according to https://docs.automation.boschrexroth.com/doc/3679523030/drive-connect-app/latest/en/) The drive is visible in the DL subtree devices/drives C. Image: now we add a fake drive (e.g. 192.168.168.1 no routing, IP from non existing subnet in my config) using REST API call (according to https://docs.automation.boschrexroth.com/doc/3679523030/drive-connect-app/latest/en/) D. After a couple of minutes the drives in a DL subtree are back but… see issue 2) Issue 2) It happens that drives from the same subnet as ctrlX are not visible under DL devices/drives subtree. Adding such drive with the REST API call is not fixing the issue (still not visible). Funny thing is that disabling and enabling the app (snap) is not solving the issue. Physical reboot of ctrlX core is necessary ☹ and the DL subtree devices/drives shows back the drives from the same subnet. The idea: What do you think about such solution: The drive connect app is not automatically searching and creating the DL subtree for drives from the same subnet (BTW: do we have any solution to limit drives to monitor if we have e.g. more than 20 devices in the same subnet as ctrlX core?). I also understand that just showing the drive in a subtree without a DL node subscription is not utilizing the CPU of the ctrlX or is actually ? In this case maybe a better solution would be to show the drives in a DL subtree devices/drives BUT after official registration via REST API or in future after selection via GUI even if they are from the same subnet as ctrlX core? Issue 3) This bug is rather connected to ctrlX CORE - Data Layer API V 2.1.0 in part of SSE subscriptions (I use V1.18 of ctrlX core) : I created an SSE subscription with the ID = sample_sse_id using REST API e.g. to collect only updates of some parameter from drives. Problem is that on a later stage when I want to makes changes to this subscription or just reference to it in my scripts this ID is not the right one. Example: A. Let’s use a REST API POST method to create an SSE subscription with "id" = sample_sse_id to collect some parameter from the drive - in this case the specific nodes in DL are created by DriveConnect App Payload JSON { "properties": { "keepaliveInterval":1000, "id":"sample_sse_id", "publishInterval":1000, "errorInterval":2000 }, "nodes": [ "devices/drives/7260415273125/axis-1/parameters/P-0-0190.0.0/data" ] } We got answer like this: So the subscription is created B. Now we need an SSE client (I made one config using node-red) to subscribe to the event using above given "location" string. As you see below the updates of the drive parameter P-0-0190 are delivered using the SSE client. So the config is OK we can use it in our applications BUT…. C. Now you would like to reference my subscription – the ID of it was: “sample_sse_id” – using e.g. REST API calls D. OK, so let’s try the first one GET method for getting info about our subscription We got an error: DL_INVALID_ADDRESS but it same time gives a hint where too look for: Response body: { "type": "about:blank", "title": "DL_INVALID_ADDRESS", "status": 404, "detail": "original error: DL_INVALID_ADDRESS", "instance": "datalayer/subscriptions/clients/client-00045cc4a5/subscriptions/sample_sse_id", "severity": "Error" } E. So let’s see the DL in this subtree: There is no subscription with the ID=”simple_sse_id” F. My specific subscription got some random ID: webSSE-1255 G. I have to use this specific random ID (which I do not know at all when using REST methods) to get the details of the subscription via REST API, please see: To summarize this specific 3 issue: There is a change requested for the REST API call for SSE subscriptions in handling of the id of the subscription: When calling the POST method for SSE events creation 1. Currently required json needs "id" of the subscription e.g. { "properties": { "keepaliveInterval":1000, "id":"sample_sse_id", "publishInterval":1000, "errorInterval":2000 }, "nodes":[ "devices/drives/7260415273125/axis-1/parameters/P-0-0190.0.0/data" ] } 2. But this required "id" from json is not used as a real id of the subscription but as part of the connection link to the event stream for the SSE client stroed under attribute "location". In our case attribute "location" (from REST call) which you get as a response of proper subscription creation: /automation/api/v2/events/sample_sse_id 3. In fact the SSE subscription is created for the client but under different "id" and can be used by the sse client but to reference your subscription in REST API calls you have to use internally created unknown id – if you use the id originally provided during subscription creation you will get an error. 4. I would ask you to reconsider a possible chnage change to current json structure for the rest call (POST SSE event creation): For POST invoking payload instead of the “id” – there should be attribute “path” required for the SSE subscription creation – works same as today id the “id” should be removed from the json Response JSON should provide under “id” attribute – the real “id” of the created subscription in our case this would be the unique name of the subscription as visible in DL the “location” attribute will remain as is (holds the link to the event stream for this particular subscription) - but the “location” attribute value is not stored in the DL - please see attributes of the subscription node via ctrlX GUI - so could be hard to know from which path on the server the SSE client should read the event stream Node-red specificity – I cannot see the clientID used for the SSE subscription in current implementation of https://flows.nodered.org/node/node-red-contrib-sse-client . So maybe adding the attribute “client_id” in response json holding client id as visible in the DL would be also nice and usefull for other such implementations. 5. If you will work on next releases in the SSE stream functionality I would see following ideas worth to consider: the “id “ attribute in the invoking payload of REST call (event POST) is not the id of the subscription but is id (name) of the event the events are always published by ctrlX as SSE stream under the path /automation/api/v2/events (maybe configurable but same for all events or maybe differentiating per clients) from client side: he makes a subscription under specific event id and can read from above stream location only his events he wants using event id e.g. today ctrlX is always publishing same event name “update” (but of course under specific location path) – I would prefer to create the event name as I want via the creation REST call and later use it for my reference as my event id or name. Pls see below the node-red node for SSE client has this ability to read different event (types = names =ids) from a specific URL. Many thanks and I hope it will not be many TLDR situations as to explain and show the examples requires some words. All the best 😁 Kookoolinoo
... View more
