Options
muse
ych
Posts: 30
1.Can the Muse controller be compatible with compiled files from Nelinx Studio?
2.Can it support calling jar packages? Package the jar through the amx plugin installed in eclipse and upload it to the new controller
3.Is the new controller API interface the same as before? Do you have any relevant Java or Python examples?
0
Comments
Many of the answers are in MUSE threads already in this message area.
@ych
1) no, Muse will not use compiled Netlinx program files. You can use IR, duet modules, and touch panel files from prior projects.
2) At it's core, Muse runs a java virtual machine. Many of the services, extensions, and drivers are .jar files. You can write a compatible duet module in eclipse (this is what we do) and use your duet module in Muse BUT you will need to insert a valid descriptor json file into the duet module. WE have a took to help with this, so write itg@harman.com if you have created duet modules and would like help constructing a desriptor file that muse will use to understand the capabilities of the module.
3) Assume the API is far different than netlinx. There is no longer a concept of device : port : system, there is no concept of channels and levels. YES there will be sample code published. My team is currently finishing up 1 room design completed in 4 different languages that should provide examples of achieving the same outcome via the 4 different developer paths.
So, thinking out loud for a bit..
Current Duet drivers are able to be used, we simply approach coding for them within your scripting language differently than in Netlinx. Yes, guidance is forthcoming and I apologize for the delay. There is no SNAPI router in Muse. As a result, I cannot simply turn on channel 27 for a discrete power on. Instead, we will reference that more explicitly by leveraging the duet component structure that has been published from the beginning but did not need to know because the SNAPI router mapped the commands to where they needed to go.
Yes, I anticipate sample project code releasing any day now -- my team is crafting it and each language is undergoing final test and eval.
Yes, we will publish a guide for creating compatible drivers. One important thing to note is that you have freedom in Muse that did not exist before. A developer has the option to write a driver any way they choose, but if you want it to be more plug and play with code written for a duet driver, you will ultimately conform to the duet component model to ensure compatibility.
The duet modules that work in Muse are the exact same file short of one insertion - a json file that describes the module capabilities to the control system. We did not reinvent them - the effort would have been too prohibitive to remake several thousand drivers. What was visible before is visible today.
If you open Netlinx Studio and visit HELP > Standard Netlinx API Help, you will learn more about how Duet drivers are architected.
Have your team considered using development tools directly to write programs, which is difficult to popularize because some technical personnel have become accustomed to the existing development framework and may not have time to relearn, especially in the Chinese region, where debugging personnel hardly understand software development and only use it simply? It is best for your team to add some new features of the Muse platform to the existing Nelinx Studio4, Keep its programming unchanged, just add new API interfaces. If you need to use more complex functions, such as handling HTTP related functions, you can consider using development tools. This can achieve rapid popularization of new products!
@ych - thanks for the suggestion. I can say that many things are considered when designing a new platform. For day 1 launch capabilities, the feature definition does contain elements of backwards compatibility, but more importantly, the significant number of new capabilities are what draw my attention. Moving from a compiled solution into a scripting solution will come with trade-offs and in some cases, hard limitations on what you can and can not do. I am excited about the trajectory of the new platform and am glad to know there is some degree of interoperability with the prior generation solution that served the market for 20 years. As a user community, if there are feature requests - we need to get those communicated and this is a terrific forum to do so.
Look at the recent wins -
We want an IR Edit software that works with computers from this century - DONE (IREdit 2)
We want an IR capture device that is smaller than a shoe box and can not be used as a weapon - DONE (IRIS 2)
We want software that is natively cross platform - DONE (IREdit 2, Muse Automator, VSCode)
We want another language option because my team does not know Netlinx or Java - DONE (Python, JS, Groovy)
We want a small POE automation control platform - DONE (MU-1000)
We want a faster boot time after code transfer - DONE (thanks scripting!)
I think you will find AMX is seeking to impose as few limitations as possible in Muse. I am confident we will find some hard edges based on how the scripting engines work when run on a JVM, but the design philosophy is intended to be as open as possible and not arbitrarily restrict use of existing libraries and resources.
We use Mavin today to build Muse native drivers, as for the Maven Store - I have not personally played with it to know an answer to this question today. If you look at the wide open philosophy that accompanies the Muse announcement, the trajectory is clear and we want you to be able to leverage the world of resources these tools provide. You can use VSCode plugins found in the wild and you can use NodeRed nodes from that community.
Will AMX be updating Netlinx Studio? This is unlikely. Barring a catastrophic change external to the AMX ecosystem, all development efforts for tools will be focused on the new platform. If you seek help processing json, take a look at David Vine's utility library: https://github.com/DavidVine/amx-util-library
Websocket Server? https://developer.amx.com/#!/searchresult?Manufacturer=AMX&Model=WebSocket Server
MQTT Client? https://developer.amx.com/#!/searchresult?Manufacturer=AMX&Model=MQTT Client
Will there be new design software aimed at leveraging all of the features of the new Varia line of user interface? Sure, at some point in the future but no announced release date has been communicated.