Ember Viewer

[Ian Hollamby]

In order to help support devices that have only implemented the Ember protocol (like the Studer Vista console) rather than Ember+, I would like to know if there is an Ember Viewer tool available?

[Marius]

 Hello Ian,

I am sorry, but there is no "Legacy Ember Viewer" available. I guess there is no free software around that can be used instead.

[Bernd Niedergesaess]

Hi,

I am happy to announce the availability of a free Ember+ Viewer tool which you might find handy - feel free to use it, if you own any Ember+ equipment:

http://www.proppfrexx.radio42.com/download.html#EmberViewer

The tool is based on the Ember+ Sharp Project (https://github.com/Lawo/ember-plus-sharp).

Let me know, if you find any issues with it...

Many Greets,

Bernd

[Arndt Stedler]

I have testet the Ember Plus Viewer by proppfrexx but didn't long last...

It seems to have massive problems traversing a tree (tested it with Sapphire MK2 and Crystal

And even a JADE cannot be traversed.

Too bad, i hoped for a nice new tool...

[Hoffmann, Kimon (LAWO)]

Hi Bernd,

Awesome, thanks for taking the time to provide the community with a free tool for their benefit! It looks awesome, with a nice and clean interface.
If you'd like, we could place a link to the viewer somewhere on the Ember+ GitHub Wiki!?

Best regards,
Kimon

Lead Software Developer & Systems Architect

--
Lawo AG | Am Oberwald 8 | 76437 Rastatt | Germany
Phone +49 7222 1002 5810 | www.lawo.com
--
Lawo AG | Registered Office: Rastatt | Amtsgericht Mannheim HRB 707330
CEO: Philipp Lawo | Chairman of the Supervisory Board: Christian Otto, Attorney at Law

[Arndt Stedler]

Hi Bernd,

i have used Wireshark to have a look into your ember communication.

Small (weak) devices are not capable of answering multiple nodes at once.

In case of our devices it is NOT possible to request multiple Nodes in one go.
But your viewer makes such requests:

fe000e00018001020a02

  60 80 6b 80 <- Root Elementcollection

    a0 80 6a 80  <- 

      a0 04 0d 02 01 01  <- path = 1.1

      a2 80 64 80

        a0 80 62 80 

          a0 03 02 01 20 <- GetDir

        00 00 00 00

      00 00 00 00

    00 00 00 00

   a0 80 6a 80

     a0 04 0d 02 01 02 <- path 1.2

     a2 80 64 80

       a0 80 62 80

         a0 03 02 01 20 <- GetDir

       00 00 00 00

     00 00 00 00

   00 00 00 00

   a0 80 6a 80

   a0 04 0d 02 01 03 <- path 1.3

    a2806480a0806280a003020120000000000000000000000000a0806a80a0040d020104a2806480a0806280a003020120000000000000000000000000a0806a80a0040d020105a2806480a0806280a003020120000000000000000000000000a0806a80a0040d02011da2806480a0806280a003020120000000000000000000000000a0806a80a0040d02011ea2806480a0806280a003020120000000000000000000000000a0806a80a0040d02011fa2806480a0806280a00302012000000000000000000000000000000000e27afffe000e00016001020a021353ff

In this case we will only answer the first. All other requests are ignored.

As a hint: make one request per node only. Or make a switch to enable this 'feature' for Small Embedded devices 

Greetings from Troisdorf,

 Arndt Stedler - DSA-Volgmann

[Stefan Weber]

Hi Arndt

Am Donnerstag, 9. Februar 2017 17:38:44 UTC+1 schrieb Arndt Stedler:

In case of our devices it is NOT possible to request multiple Nodes in one go.

This basically means your providers are NOT fully Ember+ compliant.

The specification states:

It is also possible to query several nodes within one message. A consumer could construct a single tree with all known nodes and append a GetDirectory command to each of them. 

But since I didn't find a recommendation to reply in a single tree, you should still be free to reply in multiple packets, one for each "GetDirectory".

Cheers,

Stefan 

[Huber, Andreas (LAWO)]

Hi Arndt

 

I second Stefans point. We’ve been here before (e.g. numbers can change between session or not). Smooth interoperability is almost impossible if implementations pick and choose which aspects of the spec they support/implement. If you have special requirements due to constraints of your hardware then please bring them up in the Ember+ Meeting. I think that would really help to avoid such incompatibilities in the future.

 

Best Regards,

 

Andreas

 

--
You received this message because you are subscribed to the Google Groups "ember-plus-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ember-plus-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bernd Niedergesaess]

Hi Arndt,

thanks for testing the tool and reporting this issue!

Looks like this was indeed a bug, as I so far did not honor the fact, that a Parameter node could not even have Read access.

A fixed (new) version is available here:

http://www.proppfrexx.radio42.com/download.html#EmberViewer

or here:

http://www.proppfrexx.radio42.com/download/ProppFrexx_Ember.zip

So please (re)download and give it new try, if you want.

I added printing support in the new version as well ;-)

Many Greets,

Bernd

[Arndt Stedler]

Hi Bernd,

yes indeed that one works with the JADE now. The exception is gone.

Cool.

[Bernd Niedergesaess]

I am glad, that my little tool already revealed a few issues with an Ember+ implementation.

It shows, that it is worth having such tool.

Note, that there are already a few Options to set (see the Options Dialog and try the 'Dynamic Tree Loading' one).

This option will not load the entire provider tree at once, but on a node per node bases when you expand a node.

This option might especially be used with larger provider trees, as it queries the tree on-demand and thus is much quicker in terms of displaying the tree.

Meaning it first only displays the root node and then queries the provider when you expand a node...

.

I am however afraid, that this will not really solve your issue, as indeed it should be allowed (according to the Ember+ Spec) to send multiple 'GetDirectory' requests in one message.

The current Lawo 'Ember+ Sharp Project' library doesn't even offer an option to construct single messages per 'GetDirectory' request.

And I guess this is also not really needed, as think of it:

Combining multiple requests into one message basically reduces network traffic - which is especially good for smaller (embedded) devices.

Many Greets,

Bernd

Am Donnerstag, 9. Februar 2017 17:38:44 UTC+1 schrieb Arndt Stedler:

[benoit....@lawo.de]

Hi all,
Bernd, thank you for your efforts and special thanks for this 'Dynamic Tree Loading' option: it's indeed critical for big provider trees like Lawo mc² and nova series.
May I propose an enhancement to add the description string in the gui ? For the mentioned Lawo product, this helps a lot to be able to see them.
Regards,
Benoit

[Bernd Niedergesaess]

Hi Benoit,

good point.

I added a new 'Show Description' setting to the Options; as well as a related context menu item (right-click into the tree) to the tree.

If the 'Show Description' option is enabled, a secondary line is shown for the Node (underneath the current Identification text), but only, if a Node contains a Description and the Description is not identical to the Identification.

A new version (1.4.1.0) is available here:

http://www.proppfrexx.radio42.com/download.html#EmberViewer

or here:

http://www.proppfrexx.radio42.com/download/ProppFrexx_Ember.zip

So please (re)download and give it new try, if you want.

Many Greets,

Bernd

[benoit....@lawo.de]

Thanks !
I just gave it a try, that's perfect.
Regards, Benoit