Communication between programs
izaganczyk
Posts: 5
Hi
Is there any possibility of inter process communications?
Some common objects or virtual device visible for all programs, Node-RED, JS etc.
Any way to trigger JS function from outside, from another JS program or Node-RED flow?
Thanks
0
Comments
The only ideas I have at the moment are to use shared files between the scripts and Node-Red, or to open network connections internally on different ports between scripted and Node-Red clients and servers.
For file solution, find attached a little document I did about the file path dependencies when doing file operations in scripting and Node-Red.
I have not tested yet if the relative path could be done and working in a way that Node-Red and the scripts can reach each other's default file folder, but I think it should work.
But that's not a suitable solution for "realtime" data exchange.
Regarding internal network connections, it should be possible to create e.g. a TCP server in Node-Red, and a TCP client in a script on on an unused IP port number, to send and receive data forth and back between the scripts and Node-Red. (don't know if "localhost" IP 127.0.0.1 will work)
Only food for thought....
I'm not using Node-Red, nor JavaScript, but in Python I have used Unix sockets.
This looks like it might be a solution for Node-Red? node-red-contrib-ipc
Until NodeJS is available, one would be limited to WebSockets only in JavaScript. Once again, I have not looked at Node-Red but I'm sure it has WebSocket support.
Can't tell much at all, but I've heard there may come updates to Muse, which may include a way to directly interact between scripts (and so maybe also to Automator).
Muse hasn't been updated for a long time, will it support Netlinx Studio in the future?
If you mean "will Muse support NetLinx programs"... imho I don't think that this will happen, at least not short term... NetLinx e.g. is based on device addresses (number:port:system), where Muse is based on IP addresses (panel gets connected only by IP address). Personally I see the ICSP protocol support in Muse more or less just "legacy"
If you do e.g. a Python code, you can set up the script similar to a NetLinx code, like defining device names for each panel port, and also simply said you have event handlers that react to a push and release from the panel, that then can call functions to be executed.
Beside of the language syntax itself, the visibly difference is that in NetLinx, most of the instructions a push should do, is written in the Push section of a button_event.
In Muse scripting, when the "button event" gets triggered, it calls a function where all the stuff to do is done, on Push and Release action.
And: "there finally is no more mainline"
If a NetLinx code is written well, even now everything is triggered by events, nothing done in the idle define_program
In Muse scripting, the is no other way to do it like event based
Personally, it would be nice to have a library (kind of "import netlinxLibs") for the scripting languages, to get predefined functions that operate like the NetLinx commands. so e.g. we would have kind of a simple
result = netlinxLibs.removeString(,,)
that works 1:1 like in NetLinx.
You can do e.g. a remove_string also in the scripting languages, but some things are more complicate.
hmmm..... might be an idea, to write a little NetLinx sample and e.g. a Python equivalent....
There is a library of IP communication functions at the AMX Git Hub:
https://github.com/amx-itg/muse-driver-amx-ipcomm
This jar can be imported like a Duet module into the Muse controller, and provides several different IP communication handlers for Groovy, Javascript and Python.
I haven't used them yet, but....
Sigh... I just posted a large comment, and the forum seems to have lost it!
Here is the gist of it again, from memory!
NetLinx will never be supported on MUSE, it's an entirely new platform designed to bring AV programming into modern software development.
Honestly, learn Python. It's just as easy to program as NetLinx. If you need to figure out how to do something, there is a 99.9% chance there is an answer on the internet. It's the world's most popular programming language.
I generally don't use any vendor supplied modules and the Duet IP comms module is just an unnecessary extra layer of abstraction and configuration. I have written a Python package that uses Python's asyncio and AsyncSSH to provide an event driven interface to TCP, UDP, SSH, and SSL/TLS sockets that works just like events in NetLinx. It uses Python decorators to be able to write code like this:
@data_event(<some event qualifier like socket client>, <some other event qualifier like 'online' or 'string'>) def some_event_handler(<event parameters>...): # do something hereI was fairly new to Python when I wrote it and cobbled it together using the asyncio documentation and hints from StackExchange.
With Python, it's totally possible (because I am doing it already) to write control code that runs on any platform that supports Python. MUSE (absolutely the best controller platform!
), Crestron (4-Series), Extron (when they upgrade their decrepit Python version from 3.5!), Windows, Linux, Mac.
I do all my development in WSL2 Ubuntu on Windows. Run the code directly on the laptop, test and debug. When it's ready to deploy, load it on to a controller. It takes literally seconds to restart a script and test changes. Compared to the compile/upload/test/modify cycle, it's so efficient. If you're concerned about no compiler to pick up errors, then use type hints and enable strict type checking in Pylance. Pylance and Pylint are very good at picking up errors as you develop, no compilation necessary. I recently wrote some code in Simpl#Pro (See this post), it was orders of magnitude slower than writing in Python, both in the compile/upload/test cycle and in the number of lines of code required.
NetLinx was, and still is, a great language. It's just not capable enough in today's IoT world. One simple example is parsing JSON. In Python it's literally one line of code. In NetLinx it's painful. Back in the day, I ported jsmn to NetLinx and wrote a function to convert the parsed JSON to XML for use with
XML_TO_VARIABLE, but it still required a one-to-one correlation between the JSON and thestructit was being decoded into.Why would you use Windows Forms for a UI?? Just use HTML5. React, Typescript, and WebSockets for a completely cross-platform solution. Host the HTML UI on the controller and run a Varia panel in web-kiosk mode.
I can't say definitively , but I highly doubt they are going add .NET
New firmware is available and we have a new programming guide to go with it. Check out pg. 36:
Exporting Script Functionality in the 1.2 version of the programming guide. Essentially, you can modify the program.json to expose your script as a muse device. I haven't tried it, but this appears to be the canonical method to achieve communication between processes, regardless of of weather its javascript, python, or groovy.