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.
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):
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:
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 ...
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:
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'):
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 ...