Credentials / IP-Adress / API-Keys input during (before) Setup a device

[carp3-noctem]

I'm highly missing the ability to ask the User for an IP-Adress Input or Login Credentials during an SDK Setup of the Device. If the User types in that Information it should also be visible in the Accounts section of the NEEO App.

[pfiaux]

The login and API keys are definitely something we want to add, we looked at some device APIs where a key is required before discovery. These might be special SDK capabilities or hooks that run before the discovery.

IP-Address on the other hand I feel would be best if we can avoid it because it's not the most user friendly. Do you have particular use cases where there is no type of discovery available and manual IP input is the only option? (I'm assuming we're talking about a local IP)

[carp3-noctem]

Fully agree with you on side of the API Key or any such things, also the need of Username / Mail and Passwort would be a great addition. IP-Adress is urgently needed in my case, as discover doesn't work for Enigma2 boxes like the Dreambox. Also it is a common way to adress something like a RaspberryPi running as "Translater" from TCP/IP to RS232 or just the GPIO Pins to control something.

[pfiaux]

We're working on making the SDK drivers easier to implement and also to install and use, with that vision manual IP isn't as user friendly as we want. Our main concern is the responsibility to discover the device. With manual IP that responsibility falls to the user, we believe it should fall to the driver. We see this as a different problem than the API keys or credentials which are usually used as an authentication and required by the device.

We will add more information here once we have ways to handle API keys or credentials.

Currently however we're not planning to add manual IP address support for the reasons mentioned above. A lot of cases can be handled implementing discovery on the driver level, even if it's a virtual discovery. My suggestions would be:

On RaspberryPi running the avahi deamon should make it it discoverable through mdns scans. Then the devices can be filtered using some extra mdns settings or validated with an about/info API call.

The non ideal case of non broadcasting devices can be handled running a scan of the local network (assuming the devices has an about call that can be used to validate it). Send a request to all IP addresses and see which one responds. Since it's slow it's better to run in it in the background cache the results and return these known devices when the Brain requests discovery (instead of running it on the fly).

Devices which would be non broadcasting and not have any get info calls (so only action calls) to identify them would currently not be covered, for these we need to find the best way to discover them if possible without manual IP. I'm not familiar with the Enigma2/Dreambox APIs but I believe the second option should be possible as long as there is an about or info API endpoint, let me know if that's not the case.

[nklerk]

I agree that discovery should always be the preferred option, in most networks IPaddresses are dynamically assigned. And therefore I believe that for most cases the NEEO devs could have an advising role in how to resolve the discovery. There are however use cases where without an IP option you’re not able to support a device. I.e. L3 separated devices.

[carp3-noctem]

So, actual example why an manual IP entry must be possible by the user: Using the coded KODI Driver from @nklerk but at all Android boxes there is no Zeroconf available since my box (shieldTV) and many others used for Kodi is based on Android this is required to be available, since the auto discovery it not working without the zeroconf enabled.

[neophob]

hey @carp3-noctem thanks for the update - but I'm not sure I did understand your point, can you elaborate your points?

@nklerk does Kodi not provide a upnp discovery option?

[nklerk]

I could check with SSDP if i can get the RPC interface. It's new to me that the android version of kodi lacks Zeroconf. apparently it has been removed at some point. hopefully v18 will include it again.

this would be a mayor setback :-(

[neophob]

@nklerk is just installed Kodi on OSX - Under "Settings / Services / General" you can enable zeroconf discovery. But I think the discovery option depends on the underlying OS and Kodi Version. What kind (Hardware and Version) of Kodi boxes do you (or other users) use?

[carp3-noctem]

@neophob We found that the actual stable release on android platforms have disabled Zeroconf, due to issues during the handling. Currently i installed the actual Leia Alpha to ShieldTV and this has the option available again, but this example shows, that sometimes there needs to be a backup for users (like entering an IP manually.

[neophob]

Some interesting links:

• https://sybu.co.za/wp/xbmc-zeroconf (Kodi 17+ Android: Kodi 17 on Android device does not have Zeroconf support)
• https://www.kodiinfopark.com/enable-zeroconf-kodi-krypton/
• http://homemediaportal.com/how-to-enable-zeroconf-kodi-17-connect-phones-and-remotes-to-kodi/

Zeroconf Summary:

• depending on the Kodi version and hardware, Zeroconf might be feasible to support discovery.
• Windows user need to install Apple Bonjour
• Kodi 17+ on Android does not support Bonjour. Android 18 should support zeroconf again, see https://kodi.wiki/view/Kodi_v18_(Leia)_changelog#Android_Specific

To Check:

• Is it feasible to use upnp (if enabled on Kodi)
• does ping rasbmc.local work (require zeroconf)

Idea:

• use Zeroconf and UPNP discovery in the plugin, so chances are high that discover succeed.

@carp3-noctem using the IP might work if you add the device, however most of the devices are DHCP clients - so if something in the network changes the driver won't be able to control Kodi again. at least a hostname should be used

[carp3-noctem]

You are right for DHCP, but when it first was discovered, maybe it is suitable to store the hostname, Mac Adress (and or other Infos) and if connection got lost, redo discovery with this Infos. And isn't it the same when you know change a discovered device? What would happen, if the previously discovered device changes the ip and the user doesn't readd it currently? This should fail as well, or?

[neophob]

What would happen, if the previously discovered device changes the ip and the user doesn't readd it currently

Well in reality this depends on the implementation, but what should be done is:

• driver starts
• brain informs driver that there are active subscriptions
• driver starts discovery to find requested drivers
• connect to device

this means even if the ip change, we don't care as this is handled by the discovery function (which is also the purpose of it ;) )

But anyway - we should cover 80% of the devices with discovery - after that we take care of the other 20%.

Just thinking about those other 20% - maybe that might be an interesting sideproject:

• a standalone tool to announce those zeroconf services so discovery works. but thats just a workaround until the root issue (in this concrete example kodi) readd zeroconf to the app.

It's late, I'll think about that after some sleep

[nklerk]

At a certain point I would like to have a username/password field for connecting kodi.

Offering an IP field isn’t a bad idea for some cased. Nerds like me have multiple subnets devided in vlans. As most discovery methods using a ttl of 1 they won’t work beyond their vlan

[pfiaux]

Small status update:

• pre-discovery security code (string input) will be part of the next minor release for the SDK (including example)
• pre-discovery Account (user & password inputs) is next after the API Key/Security code is complete

[pfiaux]

• security code is already in the next branch
• account (user/password) will be in the following minor release (so the "next" next branch)