Can someone help work out what needs to be done to get the ipcamera binding to show up in the suggested addons list? Is it simply a matter of editing the file binding\src\main\resources\OH-INF\addon\addon.xml as per this information:
Is there anything else needed?
How to test this as the org.openhab.misc.addonsuggestionfinder gets built last after all addons are built, so moving an updated jar is probably not enough.
I found this in the PR comments:
manually putting an 'addons.xml' file in the '/userdata/addons' folder
Is there an easy place to grab this file from so I can edit and play around with it without having to compile all the addons locally?
Anyone done this and can provide some info to help speed up someone else that is looking into it?
Does the IP-Camera Binding support autodiscovery ?
If not, it is not supported by the addon finder.
If yes, there needs to be information about discoverable device in addon.xml (discovery service, identifyer)
@AndrewFG Do we support multiple decices/vendors within one Binding ?
Yes it has an implemented and merged DiscoveryService.
To discover ONVIF cameras it uses port 3702 and IP multicast address 239.255.255.250 using what is called WS-Discovery. It is just a SOAP/XML packet sent.
I have another couple questions if you do not mind.
Does this discovery process only happen during setup phase?
Does it slow down the loading of the addon page?
Is there a way that it can be triggered later on or on a recurring basis if a user so desired?
I think it is a very cool enhancement and feature that will help new users for sure as well as folks that did not know they had some items that may be able to be controlled via Openhab.
One last question will it only be limited to official bindings or will marketplace bindings also be chosen?
I did read all I could find on this but did not find any answers to the questions I pose now.
The most common discovery method is mDNS and UPnP. There are 2 others already in the code: running processes on the server of openHAB (e.g. to discover a running mosquito broker or influxdb process) and an IP scan.
The IP scan currently is only tested and working for KNX. The intention is to generalize this, but for some add-ons it may require further work in core. In the case of ONVIF, it may already work.
See here for the KNX discovery parameters: https://github.com/openhab/openhab-addons/blob/6763100511974badda06eb970c5bd68254722462/bundles/org.openhab.binding.knx/src/main/resources/OH-INF/addon/addon.xml#L29
You need to replicate this in the addon.xml file for ONVIF and put in the right parameters. Note that the current core code does not check the return package after the multi-cast, it just checks there is a return value. That is a needed enhancement for 4.2. If you do not need to check the return package, it should work.
To test this, the easiest way is to go add the discovery xml code to the openhab-addons.xml file in the userdata/addons folder for the add-on. Search for the add-on in the file. That is the file that will get generated by the build. You could actually also create an extra xml file in that same folder, with the same structure. At start, OH will read all xml files in the folder.
Most finders will run continuously (unless completely disabled, which can be done in the add-on settings in the UI, or in a config file). The current IP scan finder only runs once at startup. This is also an enhancement for 4.2 to look into.
However, all finders cache the add-on suggestions. So you will get the suggestions in the initial setup wizard, and when opening the add-on store at any point in time. If it has been added to the suggestions cache before, it will be visible.
It shouldn’t slow down the loading of the add-on page, as it is working from an internal cache (there is one extra REST call to get the suggestions).
Marketplace bindings are on the radar, but not supported for the moment. The challenge is with providing all necessary metadata from the marketplace posting (all of the discovery criteria). The marketplace add-on list is generated from the marketplace title, which is limiting at the moment.
Thanks for reply full of info and the link. It does not need the return packet checked, as the requesting packet tells the devices to only reply if they are a NetworkVideoTransmitter so assuming is fine to do. It appears you can already use a regex on the replies to filter them from what I can see.
I see two issues that may stop it working, it is in XML format and the addon.xml is also in XML, can you encode the packet like this value seems to be in hex?
The second and bigger issue is that the following packet also needs the randomUUID() replaced with a random number that can only be used once from memory. Maybe we can cheat and rely on the cache to store the replies.
At the moment, it only works for the catch all regex. Other finders user the regex for filtering. This one does not (yet).
The second point is indeed a bigger challenge. First, the request parameter is assumed to be a udp package defined in hex format. We may have to change that and allow other formats. Secondly, the finder may need a random number function to replace (like done for srcIp and srcPort).
For all of this, I suggest to open an issue, so we can collect these requirements. That will allow us to improve this finder for 4.2. Rather than focussing on the requirements for 1 add-on, the issue should try to capture more of the possible uses, so we can come up with a more general implementation.
FWIW we are also working on a scanner to enable suggestion of addons related to specific USB plug in devices. The Zigbee, ZWave, and EnOcean sticks come to mind. But there may be others like A/V devices where such a scanner would be useful…
