Can't extend new functionality for Custom Configuration Parameters/Editor?

[ferventgeek]

I need your advice, community. As developers, but also Poly/Polisy users.

I'm building a new Node Server for a controller that itself needs to be extended to become a fully-armed battle station of ISY Unicorn Magic. As with many things early in IoT and automation, the controller I'm connecting to is highly opinioned, so now limited. It's tightly coupled to the proprietary devices in its once revolutionary ecosystem of "the next big thing". But as with everything closed, they didn't become ubiquitous and were replaced, and then replaced again, by succeeding vendors themselves trying to corner the market.

However, it can do a lot more that wasn't even on the horizon back then, but not without extending it's interface. And so I appeal to you- the Ploy/Polisy community, for your recommendations/requirements for how to do this.

Option "A": The Microsoft Win32 "_ex" function example.

For this I use the Polyglot Node Server as the extension layer, with new methods not part of the base controller interface. This has the advantage of being simple to use in Polyglot. It will "do what it says and say what it does." and nothing more. Download from the store, install, stick it in a Node bin, done.

The downside is that there are potentially dozens of possible extensions which are evolving as vendors come and go. (INSTEON, triggered!). So what happens is a) the Node Server has along list of custom methods that users only use a small subset of, that complicates discovery for every user of the Node Server. Worse, b) you'll have to have me or someone else extend the Node Server every time you want to add a new "dialect" of managed device that the controller can manage. As a result, the uptake of the Server is low, and I have little motivation to maintain it beyond keeping it working for myself.

Option "B": Open extendibility configuration.

With this approach you'd install the Node Server and get the expected full OEM functionality for it's connected controller out of the box. 80% of users would take no other action. They'd run discovery, do mighty things in ISY, done and done.

But others who want to take advantage of "scriptable" extensions to the controller, could set a block of JSON as a custom property. That would then expose custom manipulation of the controller's base interface as new methods. Basically it would be acting as a puppet master behind the scenes, and hiding controller API shenanigans so you don't have to worry about them. They'd just show up as new options in the discovery results in ISY.

So when you'd be inspired to build, "oh, I have {new geek thing X} plugged into the controller!", you'd be able to hack your own config JSON without the need to ask for the Node Server to be extended for your unique setup. It could make supporting the long tail of multitudinous specific user environments self-service. I think you can see which I prefer.

Challenge, extending the /nsdetails UI

While I can do this using the existing STRING parameter in the Node Dashboard view, that's going to be yucky. JSON is multiline and twitchy about syntax. In a normal project, I'd extend the UI to add a JSON type to extend STRING. On the server side there are no changes, but in the UI it would add a multi-line edit mode, and pull in syntax highlighting and validation as any well behaving JSON editor should.

And if adding a JSON type is too much, adding a little ellipsis button at the end of the existing value input field that pops an "edit as" option would work to. That could eventually support XML, YAML, TOML or whatever as custom properties. And by support I mean dramatically reduce configuration errors and bring Polyglot happiness by pushing clean config and validation to the browser, not down in the bowless of logfiles, obscure parsing errors and trial and error editing.

The big But

I may be missing it, but I don't see the code for the UI anywhere in this repo or anything in UDI in general. Am I missing it, or maybe this is proprietary UDI code in the compiled .js files?

So the questions are:

1. Is a simple extension of the Node custom property editor possible in this project, or is that UDI secret sauce we can't touch?
2. Do you like the idea of dynamic configuration extensible Node Servers, or is the convention to keep them very simple and opinionated about the specific support they offer for their southbound integrations?

Thanks so much for your advice!

[bpaauwe]

The UI for PG2 is in a different repository. https://github.com/UniversalDevicesInc/polyglot-v2-frontend

However, PG2 is not being maintained by UDI nor by anyone else as far as I know.

[ferventgeek]

Thx Bob. So.. Um, what's running in Polisy? I see v3 node interfaces but not a repo for v3. The status doesn't show the Polyglot version.

Version 2.2.13
Frontend Version: 2.2.9-5
ISY Version: 5.3.0

[bpaauwe]

PG2 is still running on Policy but it's being deprecated and replaced by PG3. PG3 is not open source, it's UDI proprietary software.