# Node capabilities and subject-id assignment **URL:** \ **Category:** CLI tools (Cynic/Yakut)\ **Created:** [July 8, 2022, 12:01am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704 "2022-07-08T00:01:56Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![generationmake](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/generationmake/32/611_2.png) [@generationmake](https://forum.opencyphal.org/u/generationmake)\ **Post date:** [July 8, 2022, 12:01am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/1 "2022-07-08T00:01:56Z")
Hi. Is there a way to identify nodes on the bus using yakut and read their capabilities? And how can I assign subject ids using yakut? I think I read the manual but didn’t find the answers to these questions. So could you please help? Thanks Bernhard ---
**Author:** ![aentinger](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/aentinger/32/1428_2.png) [@aentinger](https://forum.opencyphal.org/u/aentinger)\ **Post date:** [July 8, 2022, 5:43am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/2 "2022-07-08T05:43:37Z")
The best way to go about it is probably `yakut monitor` and go and see which node IDs are popping up (they are kind of hard to see but they appear at the very top of the UX, i.e. take a look [here](https://github.com/OpenCyphal/yakut/blob/main/docs/monitor.png), there are the node IDs 42, 1111, 1234, 2571, 3210, 3333). Note: You need to make sure that you are operating on the right bit-rate as the nodes. (Probably a no-brainer, but caught me.) ---
**Author:** ![generationmake](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/generationmake/32/611_2.png) [@generationmake](https://forum.opencyphal.org/u/generationmake)\ **Post date:** [July 8, 2022, 6:28am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/3 "2022-07-08T06:28:39Z")
I have already found `yakut monitor` but as you have already written it show the device info only in the first lines. Can I get a detailed report? Additionally it only shows the subject-IDs which send messages but not the data types connected to them. Is there a possibility to automatically connect data type to subject-IDs? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [July 8, 2022, 10:58am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/4 "2022-07-08T10:58:10Z")
> [@generationmake](#): > > And how can I assign subject ids using yakut? Subject-IDs are simply register values, so use “ **`yakut register`** ”, or simply “ **`y r`** ” if you (like me) have no spare second to type all these letters: ```auto y r 125 uavcan.pub.your_subject.id 8888 ``` > [@generationmake](#): > > it only shows the subject-IDs which send messages but not the data types connected to them. Is there a possibility to automatically connect data type to subject-IDs? This is a good point, and I also thought that the Yakut monitor should display the data type information. That information is available on the network, we just need to find a decent way of displaying it, considering the limitations of the CLI-based UI. Please do share suggestions here if you have any. While there is no ready-made user-friendly solution, you should remember that Yakut is designed to be flexible and repurposable. With that in mind, you can easily craft one simple, easy-to-remember command: ```bash y rl 125, | jq 'map_values([.[] | select(test("uavcan\\.(pub|sub|cln|srv).+\\.(id|type)"))])' | y rb ``` Mind the little comma, too; it matters. You can replace `125,` with a list or range of nodes like `15,125,8` or `10-50`. Use `--help` to get help. Here’s a demo: ![image](https://forum.opencyphal.org/uploads/default/original/2X/d/d736531a9d63377894b8aca860a6b49493aa177b.png) ---
**Author:** ![generationmake](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/generationmake/32/611_2.png) [@generationmake](https://forum.opencyphal.org/u/generationmake)\ **Post date:** [July 10, 2022, 11:49am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/5 "2022-07-10T11:49:11Z")
hi. How is this supposed to be? Should there be a register for every function (message) of a device to set its subject-id? do these have pre-defined names or ids? Thanks ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [July 10, 2022, 2:06pm UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/6 "2022-07-10T14:06:46Z")
> [@generationmake](#): > > Should there be a register for every function (message) of a device to set its subject-id? > do these have pre-defined names or ids? There shall be a register for every port (that is, subject or service) whose data type does not have a fixed port-ID. This means that there need not be a register for the heartbeat subject since its port-ID is constant. But there must be registers for your application’s subjects like servo setpoints and such. The register naming is well-documented in the Specification and also here: > ---
**Author:** ![generationmake](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/generationmake/32/611_2.png) [@generationmake](https://forum.opencyphal.org/u/generationmake)\ **Post date:** [July 10, 2022, 4:54pm UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/7 "2022-07-10T16:54:51Z")
thanks for clearification. I will try to implement this. ---
**Author:** ![pat1](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/43a26b/32.png) [@pat1](https://forum.opencyphal.org/u/pat1)\ **Post date:** [July 18, 2022, 7:12am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/8 "2022-07-18T07:12:11Z")
> Blockquote > There shall be a register for every port (that is, subject or service) whose data type does not have a fixed port-ID. Is not clear to me which user defined service need/can have constant port-ID. Is clear that segregation by source node-ID is, in general, incompatible with the publish-subscribe architecture but for services ? Calling a service need to specify a node-id so is correct in general to define a fixed port-ID for services in DSDL ? We have more than one node that offer the same service; the nodes can use the same fixed port-id ? So when is useful to have services without a fixed port-ID? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [July 18, 2022, 7:43am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/9 "2022-07-18T07:43:19Z")
> [@pat1](#): > > Is not clear to me which user defined service need/can have constant port-ID. _ **None.** _ None of the user-defined data types can have a fixed port-ID (with a marginal exception, which is not worth mentioning here probably). This is explained in the Specification (chapter 2 “Basic concepts”) and the Guide. This is not DroneCAN. Forget custom fixed port-ID, it was a terrible idea, and there is a good reason why they are no longer available in Cyphal. There are countless discussions on this forum about this already; here’s one: [Choosing Message and Service IDs](https://forum.opencyphal.org/t/choosing-message-and-service-ids/889). > [@pat1](#): > > Calling a service need to specify a node-id Correct. > [@pat1](#): > > so is correct in general to define a fixed port-ID for services in DSDL ? No, and for the same reason why it is not correct to use fixed port-IDs with custom message types. A node may provide multiple instances of the same service, and it is not appropriate for the data type designer to prohibit that (unless we are talking about the very basic low-level services provided by the protocol itself, but we are not talking about them right now). Generally, one should not expect to see many custom service types since they are somewhat limited in their ability to express complex abstractions. Let me quote the Guide: > [@The Cyphal Guide](https://forum.opencyphal.org/t/the-cyphal-guide/778/5): > > Observe that relying on node-IDs to differentiate the service instances or agents would be a mistake for two reasons. The first reason is that a node-ID, per the Cyphal network model, is a transport-layer property that exists primarily to facilitate the operation of the network itself rather than to enrich the application-level contracts. Relying on the node-ID to define application-level functions constitutes a leaky abstraction throughout the layers separating the application and the transport. The second reason is that such separation presumes that each service instance or agent should be implemented by a separate node, which is not an adequate assumption for a service designer to make. > > An attentive reader here might notice that Cyphal-services (not “architectural services” but “services as opposed to subjects”) are inherently bound to node-IDs and as such their ability to participate in well-architected network services is limited. This is a correct observation. This design is one manifestation of Cyphal’s commitment to providing powerful abstractions at zero cost – occasionally, certain trade-offs have to be made. Many practical services will be designed based on subjects alone without relying on Cyphal-services at all. ---
**Author:** ![generationmake](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/generationmake/32/611_2.png) [@generationmake](https://forum.opencyphal.org/u/generationmake)\ **Post date:** [September 23, 2022, 6:35am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/10 "2022-09-23T06:35:48Z")
with the latest updates of the 107-Arduino-Cyphal library the register API becomes more and more complete for Arduino devices. Because of that new questions arise: Is there a command or function of yakut which lists all registers of a node and their values? Is it possible to store all these values locally in a file and play them back to have a local backup of the settings? Thanks. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [September 23, 2022, 7:19am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/11 "2022-09-23T07:19:09Z")
Yes: [GitHub - OpenCyphal/yakut: Simple CLI tool for diagnostics and debugging of Cyphal networks](https://github.com/OpenCyphal/yakut#node-configuration-example)