Hello,
I am currently working with devices that use the Ember+ protocol and I’ve encountered some limitations.
As far as I could find, Skyline provides a protocol that allows reading parameters through Ember+, but I haven’t found any reference or support for writing/changing parameters. The library used is already precompiled inside QAction_1, with source code available, but I could not locate any documentation or implementation that enables parameter modification.
My question is:
Does Skyline offer any driver, automation script, or reference implementation that supports writing to Ember+ parameters, or is there a recommended approach to achieve this within DataMiner?
Thank you in advance for your guidance.
Hi Maximiliano,
Could you please specify which Ember+ device or DataMiner connector you’re referring to? This will help us determine whether write support is already available.
If the write implementation is not included in the current connector, it can usually be added depending on the device in question. In that case, we recommend reaching out directly to your Technical Account Manager (TAM) at Skyline to discuss the options.
There are some existing connectors (Eg. Lawo Power Core) that already support writing to Ember+ parameters, but this can vary depending on the device and its specific Ember Tree structure.
For more general information, you can also refer to our documentation on Ember+ and how it’s composed: Ember+ | DataMiner Docs.
There is an Ember+ Viewer available which allows you to verify if the parameters you are looking for are indeed writeable and how the tree structure looks like. This information will be handy when reaching out to your Skyline contact.
As an alternative, there is an official ember-plus-sharp library available to read out and update your Ember Tree.
Kind regards,
Robin
Hi, in this case, I’d recommend reaching out to your Skyline contact to request full support for the Dynamic Parameter functionality. If I understand correctly, the connector doesn't seem to propagate “set” messages for these parameters, so an update or extension on our side may be needed.
Hi Robin,
I’ve reviewed it, and it’s actually the exact same approach I had already tested — assigning the value directly to parameter.Value.
This works correctly for standard parameter types (integer, boolean, string), but it does not work for Dynamic Parameters, which is the scenario in our case.
The value assignment is accepted locally but no “set” message is sent to the device, so the change is never applied.
This seems to be a limitation or different behavior specific to Dynamic Parameters in the C# library.
Thanks in advance,