search

openhab / openhab-android

openHAB client for Android
https://play.google.com/store/apps/details?id=org.openhab.habdroid
Eclipse Public License 2.0
599 stars 317 forks source link

support multiple openhab server #10

Closed CWempe closed 4 years ago

CWempe commented 10 years ago

In case you got more than one openHAB server this app is not very usefull.

I am using a separate openhab server for developing. It is not nice to change the URL in the settings each time I want to use the other server.

Thomas38 commented 10 years ago

I also apply for this enhancement ! At the moment I have to go into the setup to change the address and sitemap. It would be greate if I could choose the site easily. I use OpenHAB in different buildings and different cities !

kidalabama commented 8 years ago

https://play.google.com/store/apps/details?id=treehou.se.habit

Alpoy commented 7 years ago

I have 2 different OH servers (one for my house and one for the cabin) would be very nice to see this feature implemented!

mueller-ma commented 7 years ago

When every oh server is in their own network you can assign them the same IP or dns name.

FlorianSW commented 6 years ago

I alredy thought about implementing such a functionality. However, it would probably a bit easier, once #562 is merged (I would start working on this after #562). The UI I had in mind so far was pretty similar how GMail does it with different e-mail accounts (providing a switch in the flyout menu).

However, some things we need to consider:

That are my thoughts so far :)

mueller-ma commented 6 years ago

I would say, that discovering the OH instance to connect to is pretty difficult with more than two servers

Currently if you have more one server, a random server is discorvery. Probably that one, which response faster.

FlorianSW commented 6 years ago

Uh, I haven't thought about that, my point with "discovering" was: When you start the app, it automatically selects if it connects to the local or remote server, which is based on the current network. If you've multiple servers in your configuration, the app probably selects a matching server randomly (if multiple remote and/or local servers are configured). So, I misused the term "discovery" here, sorry :)

didi1357 commented 6 years ago

I'll sooner or later also be facing that problem...

My suggestion: Autoconnect to the last used instance. Time stays the same that way. This is also the way, the KoRe App (Kodi Remote) for Android does it. Maybe we can get ideas from there?

mueller-ma commented 6 years ago

As a workaround you can use the stable version for one server and the beta for another one.

curlyel commented 4 years ago

Autoconnect to the last used instance.

Agree 👍 If this is not the right instance, the user should choose from the options menu to connect to another openHAB instance in case she needs to switch over to some other instance.

So we need to maintain a number of openHAB connection peers (local+remote-Url settings + the needed credentials).

I'd suggest to assign an instance id or a configuration slot id to each configuration "slot". This id clearly identifies the meant openHAB instance and can/should be used in the

So the NFC tag could be written with:

openhab://<configuration slot id>/<sitemap id>/<frame id> e.g. openhab://1/main/0003>

Once we get BLE beacon sitemap selection support as proposed in https://github.com/openhab/openhab-android/issues/213, we may consider using the Eddystone URL to broadcast configuration slot id/sitemap/frame id. Unfortunatly, Eddystone URL is limited to 18 characters AFAIK. So the sitemap id has to be quite short to fit (up to eight chars in below example).

And: The URL has to start with "http://" or "https://". So simply writing the above NFC string openhab://.... wont work. But e.g. this works:

20191020_155118

where:

oh = indicates openHAB use
1 = first configuration slot
main = sitemap id
0003 = frame id
MarcusWolschon commented 4 years ago

You'r overengineering this. A simple selection is all that is needed. THEN it can be improved in future features.

curlyel commented 4 years ago

You'r overengineering this.

Why? I guess you're referring to the configuration slot id - right? I think, this is important to have an indication, which openHAB instance is targeted by the widgets/NFC/etc. If not included, they may point to something (sitemap/item) which might not be valid in the current selected openHAB instance ...

A simple selection is all that is needed

Yes. That's the base function: Provide the option to configure a number of configuration sets and add a selection to chose from them.

MarcusWolschon commented 4 years ago

You'r overengineering this.

Why? I guess you're referring to the configuration slot id - right?

No about NFC tags and BLE beacons while support for multiple servers AT ALL doesn't exist yet.

curlyel commented 4 years ago

Mmhh...

  • shortcut/widgets
  • NFC tags

... are yet-existing features of our openHAB-android app. I assume you are aware of it.

When we think about implementing a "multiple server configuration" option, we should start thinking how this affects other features before start coding. Aggree?

That's what I was trying .... ;-)

Just lean back an think about it for a minute: What would you expect when you tap on a homescreen widget of your Android pointing to a specific sitemap/frame. Your expectation would be quite likely: "The openHAB-android app opens and shows exactly that sitemap/frame which you have made the widget for". It's mine too. AND: This is how it works today

_Once you have "multiple server configurations", you may have multiple homescreen widgets pointing to the different sitemaps out of these multiple servers. I guess you would expect that our app will select the right (correct) server connection and not just throw an error like "Sitemap not found"._

(NFC is exactly the same story, just replace "homescreen widget" by "NFC tag" in the above section)

That's why I came to my thought:

is important to have an indication, which openHAB instance is targeted by the widgets/NFC/etc. If not included, they may point to something (sitemap/item) which might not be valid in the current selected openHAB instance ...

My guess is, the developers/maintainer would prefer a solution which does not break existing features or make them prone to errors. From my point of view, the configuration slot id (or whatever this is named) solves the need.

Maybe you have a more elegant and less intrusive way to solve this without the need for an additional identifier?

Feel free to explain ...