eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
863 stars 782 forks source link

Make mDNS announcement Physical Web compliant (through a configuration option) #603

Open kaikreuzer opened 8 years ago

kaikreuzer commented 8 years ago

migrated from Bugzilla #468125 status ASSIGNED severity normal in component Core for --- Reported in version unspecified on platform PC Assigned to: Yasser Aziza

On 2015-05-24 06:51:30 -0400, Yasser Aziza wrote:

The openHAB runtime should announce itself through mDNS in the local network.

This feature is needed for the Google's Physical Web integration [1].

Any smartphone that is in the same network and has the Physical Web app installed should directly find the instance and open the web client (Eclipse SmartHome Classic UI) of it.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=468124

On 2015-05-24 06:57:22 -0400, Markus Rathgeb wrote:

Didn't this work out of the box? I this is not integrated in the current mDNS bundles, then I have implemented this already myself. Will have a look at on Tuesday.

On 2015-05-24 07:30:09 -0400, Kai Kreuzer wrote:

Yasser, please note that Eclipse SmartHome already has the ability to broadcast mDNS annoucements, see https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.transport.mdns/src/main/java/org/eclipse/smarthome/io/transport/mdns/internal/MDNSServiceImpl.java#L71. The REST API uses this infrastructure to announce itself already: https://github.com/eclipse/smarthome/blob/SHA: 1ffc8d439476f69552130066faf634c8ec72a9d0/bundles/io/org.eclipse.smarthome.io.rest/src/main/java/org/eclipse/smarthome/io/rest/internal/MDNSAnnouncer.java#L50

What is needed is to make this announcement compatible to the Physical Web format, i.e. it should announce the local url with it. Please note that for backward compatibility reasons, the current annoucement should not be changed, but adding the Physical Web compatible way could be enabled through configuration additionally.

Please also note that this is the Eclipse Bugzilla, this means that you should refrain from referring to openHAB here. If a functionality is related to openHAB directly, please add an issue at https://github.com/openhab/openhab2/issues instead.

@Markus: No need for you to get active in any way. Yasser is working on this topic in the context of a GSOC project, so he will take care of all implementations.

On 2015-05-24 09:03:06 -0400, Victor Belov wrote:

Kai, if it would not possible to make announcements both GPW compatible and backward compatible with mobile apps I can have a look into supporting both on the mobile app side.

On 2015-05-24 10:27:26 -0400, Kai Kreuzer wrote:

Thanks Victor. Nonetheless, for the migration path it probably would make sense to at least allow to configure whether it is old or new style of annoucements. It probably indeed does not make too much sense to have both annoucement styles active at the same time.

On 2015-06-01 05:59:08 -0400, Kai Kreuzer wrote:

Hi Yasser, I have adapted the title of this issue accordingly. Did you already make any progress on this?

On 2015-06-01 17:26:32 -0400, Yasser Aziza wrote:

(In reply to Kai Kreuzer from comment # 5)

Hi Yasser, I have adapted the title of this issue accordingly. Did you already make any progress on this?

Hi Kai, sorry for the late replay. I will send a patch in the next 2 days to github.

On 2015-06-08 06:53:19 -0400, Yasser Aziza wrote:

(In reply to Kai Kreuzer from comment # 2)

What is needed is to make this announcement compatible to the Physical Web format, i.e. it should announce the local url with it. Please note that for backward compatibility reasons, the current annoucement should not be changed, but adding the Physical Web compatible way could be enabled through configuration additionally.

Hi kai, just a last question: what is the best way to manage the annoucement configuration ?

On 2015-06-08 14:09:40 -0400, Kai Kreuzer wrote:

The annoucement is done for the REST API, hence the registered service can be found here: https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.rest/OSGI-INF/mdnsannouncer.xml As you can see in https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.rest/src/main/java/org/eclipse/smarthome/io/rest/internal/MDNSAnnouncer.java#L42, this service already supports ConfigurationAdmin settings. So the configuration whether or not it should be Physical Web compliant could be done in here.

But looking at this, I wonder whether we might simply have multiple announcements? Because the entry will actually point to a different url (not the REST endpoint, but to the Classic UI or the Paper UI). So maybe the MDNSService should simply offer an additional method "registerService(final PhysicalWebServiceDescription description)" and the UIs register an according service. What do you think?

On 2015-06-16 11:31:42 -0400, Yasser Aziza wrote:

Hi,

There is a problem with the android application announcement. After spending some time debugging this, i found that the problem is in the Physical Web implementation, i have opened an issue for this:

https://github.com/google/physical-web/issues/414

I have implemented the fix and i am just waiting for feedback from the Physical Web team.

Nontheless, i will submit my code to the Eclipse SmartHome tonight.

On 2015-06-29 10:15:42 -0400, Markus Rathgeb wrote:

Nontheless, i will submit my code to the Eclipse SmartHome tonight.

Have your code been ever submitted? Cannot find any PR.

On 2015-06-30 09:22:52 -0400, Kai Kreuzer wrote:

Have your code been ever submitted?

No, it hasn't :-( Yasser seems to be submerged...

scottjenson commented 8 years ago

A few comments from the Physical Web team. We're been working this issue for a while now and have been frankly hitting a bit of a wall. We're thrilled someone is pushing for mDNS access and would like your feedback. A couple of points:

So excited you guys are looking into this and looking forward to discussing this further.

Scott

maggu2810 commented 8 years ago

I think this one is related to the point (1) and (2): google/physical-web#492 Correct?

I already contacted the submitter of urlbookmark (on august as I posted to your github page).

There is some excerpt:

> Do you know anyone (a software component) that is using this service?
> You do you have created this one?

… to use it in the Bookmark Advertiser project https://github.com/ssp/bookmark-advertiser which can advertise the URLs in your open Safari Tabs via Bonjour.

These can be picked up by the Flame iOS app https://github.com/tominsam/flametouch which will then open the bookmarks.

> Are there further documentation about this type or are there no
> further limitations for the URL and that name?

It’s a few years since I worked on this, so my memory may be spotty. The point of this Rendezvous service is to advertise arbitrary bookmarks on the network, in particular URLs that are not on the machine doing the advertising (otherwise the usual _http._tcp would have done the trick).

A known limitation of the current implementation is that the URLs are lenght limited (due to the limits of the DNS-SD TXT record length.
scottjenson commented 8 years ago

excellent. Is this bookmark-advertiser part of any official mDNS spec or is it just a proposal at this time?

maggu2810 commented 8 years ago

excellent. Is this bookmark-advertiser part of any official mDNS spec or is it just a proposal at this time?

Hi Scott, sorry I don't understand what you mean.

Bookmark Advertiser reads the web pages currently opened in Safari and advertises the name and URL of each of them via Bonjour. Each bookmark is advertised as a Service of type _urlbookmark._tcp and the relevant information is contained in the Service’s TXT Record.

The "Bookmark Advertiser" is an app that is using the service type _urlbookmark._tcp

Why do you think such an app will ever be part of the mDNS spec?

scottjenson commented 8 years ago

Sorry Markus, I didn't say that well. I confused the app you linked to with the actual service. My goal was to confirm that the service type _urlbookmark._tcp was an official part of the mDNS spec. When my team tried to find it, they could only find a blog post about it so it seemed a bit experimental.

I just did a quick search and found it documented on dns-sd.org so it feels reasonably standardized. I'm curious if you know if many people are currently using it? It's not a problem if the answer is no. I'm just curious if it has any traction at this point.

maggu2810 commented 8 years ago

Ah, ok. I has expected that "cco3" found that service using my links posted here: https://github.com/google/physical-web/pull/492#issuecomment-130969266

So I assumed it is already known to be part of the spec.

I am not using this one and I am not familiar with this one. I have just used mDNS in some products and have also done a little debugging, reading specs etc.

Sorry, I don't think that I can help you.

htreu commented 7 years ago

@maggu2810 and @kaikreuzer: since Google PhysicalWeb is BLE only right now I guess this should be closed at the time being. Maybe with the new Bluetooth binding there is another chance to look into this. Sadly this issue does not point to any code or further implementation detail. wdyt?

kaikreuzer commented 7 years ago

Google PhysicalWeb is BLE only right now

Is it? Do you have a reference that they dropped mDNS support? I'm still dreaming of ESH instances popping up in Chrome if being discovered in the vicinity...

maggu2810 commented 7 years ago

I'm still dreaming of ESH instances popping up in Chrome if being discovered in the vicinity...

Hm, my Chrome (on a desktop machine) doesn't Popup anything if I follow this instructions: https://github.com/google/physical-web/blob/master/documentation/mDNS_Support.md

htreu commented 7 years ago

Yes, you got me here. I was referring to the point @scottjenson made earlier. Thanks @maggu2810 for pointing me to the dev docs. I tested the mDNS support as described in the docs with the latest iOS version and iOS Chrome w/o success. Side note: the iOS client in fact does show a link I copy to the clipboard on my desktop Chrome. So maybe the instructions in the dev docs just dont work.