The capabilities are undefined, which resulted in the TypeError.
Now all your capabilities are loaded together with the other service data.
In the service list you can see which services your camera supports.
So I need to use this list instead...
EDIT:
Seems my older Panasonic camera's don't return services, but only capabilities. While your ReoLink camera only supports services, but no capabilities. So I had to support both types at the end...
I had to do quite some changes, but I can now connect both to my Panasonic and your ReoLink cameras. I will push it to Github tomorrow evening, because it is getting too late now...
Unfortunately I don't know anyh way to test the discovery and event streams remotely from here ...
I have pushed a large number of changes to my Github repository:
Support for both services and (older) capabilities. This should solve the TypeError, and allow the node to connect to your device (as described in the previous posts above).
Extra node status "no services" when no services/capabilities can be loaded from the device.
Extra logging to make it easier to understand why an input message is rejected. For example:
When the node is not connected to a device.
When the specified service is not supported by the device.
When the specified action is not supported.
...
The logs are now available in the Debug sidebar. For example the node status indicates that your camera has no PTZ service, and the same information will be displayed in the sidebar (when an input msg is injected):
At the start I searched the IP address of your domain name. But your WAN address changes from time to time, which caused me wondering why it didn't connect. But at the end I entered your domain name in the config screen, which continued working fine. I have now added the label "or hostname" to the config screen to make this more obvious:
It would be nice if you could do some testing:
Are you able now to connect to your camera.
Is the TypeError solved when you start listening for events.
Do you receive events? I don't receive events, but I don't know if I should receive events at this moment? Perhaps there is still something wrong with the event streams?
About the broadcasting issue. As mentioned before I found some some irregularities in the onvif library code (see here for my technical details). And I see now that there is somebody else who has reported an issue today! And it seems that my own discovery also gives a "Discovery error Wrong SOAP message from ..." since I installed the latest version . To be continued...
Don't forget to install my latest version from Github!
There was still one open issue in my code that prevented the original input message fields to be kept during discovery. That is now also fixed on Github.
@madmax,
Got again another issue from an event stream not functioning anymore in the latest version.
When I look at his code, the XAdr naming is entirely different as for your camera
And in his case each service has now an array of capabilities (like it should be):
I can't remember that your cam had such capabilities per service.
But perhaps I have overlooked that ...
I would appreciate if you could make your cam public again. Thanks!!
Thanks!! You can close it again. Then I will ask you to open it again in 5 minutes or so
Like I thought, your ReoLink camera doesn't have those arrays of capabilities per service. Since this is new functionality of the onvif lib, I have no either whether that is a problem or not. So I have raised an issue about this.
Btw I did some further investigation about the "unsupported" issues, and that should be solved now. I have pushed a fix to Github a couple of minutes ago.
There is another know issue: when you start listening to a stream, the node status will be "listening" very shortly and then it becomes "connected". I will try to fix that tonight.
When I start listening to your event stream, I get this error in my Node-RED log (and Node-RED stops):
I have managed to get round to testing the latest version with my camera at last. It seems to be performing perfectly for me. It now connects ok when the camera becomes available (if it was not available on startup). Thanks for all your work.
Hi @Colin,
thanks for testing!
I have to change that test. When the cam was unavailable at startup, then it automatically connects. But I don't think it will automatically connect afterwards, when you temporarily disconnect your cam and connect it again.
That is also something I need to fix.
I assume people will start understanding now why I have not yet published these nodes on npm...
Hi guys,
Although this is an experimental node (with only beta versions on npm), it seems to be used by lots of people. I don't have time at the moment to finalize it, but it became clear that at least I should have at least version management (to allow people to revert to the previous version)...
So I have done some changes:
A new beta (version 0.0.1-beta.15) has been published on NPM.
The commits are now tagged and a corresponding releases page has been created, where people can track changes in new future beta releases.
The installation section on the readme page has been updated, to install from NPM instead of Github.
Hopefully that is a bit clearer for users, until I have time to create a major 1.0.0 release version...
@Colin ,
Since I had already added recently an auto refresh mechanism, I would like to have it working correctly now. Especially since that will make the flow less complex.
I have pushed a fix to the fix-refresh-status branch on Github. Would be nice if you could install and test this fix:
I have executed some tests myself, with an automatic refresh interval of 5 seconds:
Which means that every 5 seconds a request is being sent to the camera, to see whether it is alive or not. And if it was previously disconnected and now connected, then it should automatically get all the config from the device.
I have been testing two scenario's:
The camera is disconnected when Node-RED is started. Afterwards the camera becomes connected.
2 The camera is temporarily down when Node-RED is running, but shortly afterwards the camera becomes connected again.
In both cases it seemed to be working fine: the node status is updated almost immediately. But due to the Onvif issues from last weekend, I would appreciate if you could also test this. Or anybody else ...
Colin,
In the previous version when your cam was "connected" and you decoupled the cam from your network, the node status stayed "connected". In the new version it will automatically go to "disconnected". And when you turn the camera back on, the new version will show automatically "connected" again (and all the configs will be reloaded from the device automatically).
In the previous version this only worked at startup: when your cam was offline at Node-RED startup, then the status was "disconnected". When you turned on the cam, then the status became automatically "connected".
Hopefully that is a bit more clear now?
When I disconnect the camera the status changes to disconnected in red. When I connect the camera again it returns to the connected state, after about 10 seconds
That is with version 0.0.1-beta.15
Ok - after a few seconds of unbelieve - I have done the same tests with beta15.
It seems that on sunday I had forgotten that I had already fixed this on friday, so I have implemented it then again in a different way.
Summary: or I am getting old or I should find a hobby with less challenges
I will remove the fix-refresh-status branch again...
Thanks for testing !!
. To be continued...
