Node-red-contrib-onvif-nodes : Beta test

Continuing the discussion from Onvif VS onvif-nodes issue:

I will resume the beta test topic from @BartButenaers here (because closed)

For me and my cheap ptz camera : I note that continuous movement and absolute movement are reversed PLUS : in the continuous movement (Absolute move) the UP and DOWN go left and right.

This is the complete https://github.com/bartbutenaers/node-red-contrib-onvif-nodes test
The 2 camera test :


Camera1

Camera2

imaging-node
image
media-node
image
video-media
image
stream-urls
image
snapshot-images
image
device-node
image
ptz-node


Runs randomly = some node run on camera1 and not on camera2 and vice versa.

@BartButenaers I think you can get out of the Beta (by putting compatibility warnings: some cameras will not respond).

2 Likes

Hi Chris,
Thanks a lot !!!!!!
Really kind of you to do all this test work. Now it is finally tested by someone else.
Now I need to find some time to have a look at your issues ...
But yes I also would like have it published on NPM.

1 Like

I think others have been doing some testing, though not formally organised I admit.
I have been using it on my system virtually since you first made it available.

1 Like

Yes because I am sure that many use it underground, it had to come out in broad daylight on the NR palette. Bart to find the time now :wink:

Absolutely. But due to the large number of functionality, I really needed someone to test all the features, so I have an overview of what needs to be done before I can go to NPM ...

Chris,
The version on Github should not crash anymore, when getting the hostname.

Well this demonstrates exactly why I have put - at the time being - on my readme page that it is not published on NPM yet and I mentioned that I needed to discuss it (which I will do now here):

image

To clarify: my Onvif nodes are NOT user-friendly! And the fact that you highlight these in yellow proves that... Will try to explain what is wrong with my nodes, and hopefully we can get some ideas here how to improve it :crossed_fingers

  • Suppose you want to setup two streams on your camera, one with a high resolution and one with a low resolution.

  • This means that you need to setup two media profiles, each with their own resolution. Here is a screenshot from e.g. GeniusVision that shows this very clearly:

    image

    But I need to find a Node-RED way to show and manipulate those profiles in a flow editor. And I have no idea at the moment what is the most user-friendly way to do that ... :woozy_face:

  • However when you look at the media profiles, their data structure is rather complicated. You can find the entire tree structure easily with following flow:

    image

    Which shows a large structure (containing two separate profiles in my case), with lots of sublevels for all kind of configuration (audio, video, ptz, ...):

    The amount of data and levels is quite large. So I don't think it is easy for users to read and manipulate this only via input messages???

  • You have to access the configuration always via the sourceToken. However that is generated automatically, so not easy to remember. To simplify it, my nodes also accept the profile name: I automatically search for the corresponding profile token, and use that one to access the configuration.
    And when you access the config via an input message (to update or read the config), you can also specify the profile_name or profile_token or none of both (in this case I will use the default token). This is why your flow didn't work: the example flow on Github seems to contain the tokens of my camera. But this is not clear to users .........................

  • I have added - at the time being - a search button on the config screen, that allows you to get automatically the media profile names from your camera (in my case two profile names 'mainStream' and 'subStream'):

    onvif_token_hell

    But of course that only shows part of the config, not the entire tree.

  • When you want to read/write a config you need to send input messages. Since that seemed the Node-RED way for me. But of course then you need to build the entire UI yourself, which triggers those input messages (e.g. some controls on the dashboard to specify the resolution). So the disadvantage is that users will need to build the UI on their own. On the other hand it is very flexible, since it allows you to implement it the way you want.

  • I have already been wondering if a sidebar panel would have been a better solution. I mean that you can select a camera in a dropdown, and that I show the config tree there somehow. Although then I'm building an entire Onvif manager, which would be hell of a job to build and maintain ... And then you can't control it via input messages, so you would loose the Node-RED way of doing things ...

Summarized: I DON'T KNOW HOW TO IMPLEMENT IT, SO IT BECOMES USER FRIENDLY.
And that is the reason why these nodes have never reached NPM ...