Hi! Is anyone developing NMOS nodes for node-red?
Looks like it'll be the new broadcast standard when it comes to ST2110-20/30/40 AVoverIP streaming, routing & orchestration in mid-sized AV networks.
Thanks!
I don't know the system, but a quick search on the flows website suggests nothing is developed yet
1 Like
Nice find - will need installing via npm manually?, as it's not in the catalogue/flows website - at least I couldn't find it?
Hi.
Great topic ! I m in the media industry and knows the NMOS API quite well.
I m thinking for some time to build some flows to get easier and more powerful merhods to test devices, than just Postman requests.
NMOS is basically a Rest API, so easy to use in NR.
What do you want to achieve with it ? I dont have experience to build custom nodes, but could start soon to test some flows...
Jerome
Nice job - I work with Riedel MediornetIP ST2110 and was curious if anyone is working on a IS-04 & IS05 node which could discover and do video routing. Controlling devices via API is somewhat ok but I'm thinking of having it integrated in an NR UI and do matrix switching via NMOS IS-05 and dynamic buttonssimilar to the nmos/nvidia docker registry. Which NMOS registry are u using?
Yes, it's a good idea, and indeed the Nvidia NMOS tools is quite good, as far as I remember ( it also includes some parts of the IS-08 audio shuffling part if I'm right)
On our side we use Nevion videoIpath to handle 2110 devices , using NMOS or specific APIs, and don't really make use of a real NMOS registry. The NMOS API is being used but the devices and parameters are managed in Nevion ViP own DB.
Moreover we have what is commonly called a "purple network" which prevents us to use IGMP, but instead static multicast routing, also handled by Nevion system. So we can't really take benefit of IS-05, even if in some specific cases it can help, as soon as the multicast group is already present in the VLAN of the receiver....
Anyway, starting to work on this today gave me some ideas, I want to dig now it the IS-05 part, either for pulling or pushing manually created SDPs for example, and see how it goes. Happy to continue that discussion if interested 
Cheers
Jerome
Side note, I started today to play with Dante Domain Manager to get regular Dante audio devices in the 2110-30 world. I have one device set-up and nearly ready to be used.
The tricky part is about flows announcement, which is usually done with SAP but can't really be useful in our set-up. As DDM seems to also have an API, I think about using NR to get SDPs files from our 2110 system, and push them to DDM so they can be available for end devices to subscribe to the flows.
BR
Fetching and parsing the SDP file is key for IS-05 to work. This and IS-08 audio routing could be a great leap using NR in the media/broadcast business especially for using it as a gateway for OSC, Bacnet, Modbus, etc.
So is there anyone out there who has the skills to develop this and maybe more for node-red?
Luckily NMOS speaks JSON natively. Similar to a MQTT-broker the NMOS registry could run as a dedicated process/VM out of NR, so polling & parsing SDP files from clients and sending the calculated commands would be a first step. I guess this could be built with onboard nodes but a native nmos node would do a better job though… and of course DDM integration & AES67 as a future feature.
I'm afraid NMOS and 2110 is not really a concern for many of the NR users up there ( maybe in the future NMOS with IPMX will help), so I would not expect a lot in term of custom development. This is just my own feeling, I know how that could be useful but as right now I don't have the skills and time for custom nodes development I'll do that another way.
And the day I'm able to create my nodes, I'm not sure NMOS will be on top of the list...
Back to the NMOS registry which in your case would be the first piece of the puzzle, I guess it's all about having DNS-SD properly set in the network ad of course in your code. Once that works, it's mainly dealing with a database to handle device properties, and in the end GET/PUT/PATCH requests to handle connections.
On my side as mentioned earlier I have no plan to spend time on the NMOS registry topic until I see a real use case in my own work. I plan to use this stuff for debugging, having a easier way to manage device Ids changes, links with other DBs/systems and so on. But anyways, definitely open to new ideas and discussion 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
