Provide source for commands sent to openHAB

[ccutrer]

See openhab/openhab-core#5041 and docs at https://next.openhab.org/docs/developer/utils/events.html#the-core-events

Basically just add &source=org.openhab.ios to the query string (or regenerate the openapi wrapper, and provide it). If you can think of something useful for the "actor" (username or device name), append that after a $.

[digitaldan]

Excellent, would have to think about the actor name..... unless using the cloud service, it's likely we won't have a user, and IOS goes to great lengths to hide user identifiers. Maybe @timbms or @TAKeanice has an idea there. The sitemap code and notification actions are the primary users of the API, although it might be interesting @ccutrer to add the source tag to the Main UI code as well (i'm guessing this is on your list), we could then inject our identifier into the MainUI when loaded through the IOS client so its clear even then its a mobile request.

[ccutrer]

Oh that's a good point about iOS trying to hide identifiers.

And yes, BasicUI (in the browser) and MainUI (clearly in the browser!) are also on my list, but I haven't looked at them at all yet to see what that will entail. I hadn't even considered yet that MainUI inside the mobile app is just a web view, so will be extra work for the apps to attach a source to them. Is there anything I should do to ease that for you? Maybe accept it as a header instead of a query param?

[digitaldan]

Is there anything I should do to ease that for you? Maybe accept it as a header instead of a query param?

We already inject via javascript callback functions for menus and connection status, so if you open a PR up in the Main UI, i can add some commentary on creating a function that we could override to get the source/actor name ( or something like that, i would need to look, its been a minute since i last worked on this). I would recommend starting with just getting the Main UI working with the source id and then we can adapt as necessary.

[maniac103]

Maybe accept it as a header instead of a query param?

+1 for that approach. At least for Android the implementation would be simpler, I think, and using a header for this also feels like a more natural solution. Maybe allow both, preferring the query param if present?

[timbms]

will the openapi schema include the description for this extension of the command interface?

[ccutrer]

will the openapi schema include the description for this extension of the command interface?

Yes.

[ccutrer]

The source query parameter PR merged a few hours ago for both core and openhabcloud. So this should now be testable.

[ccutrer]

The header source PR is pending, as is BasicUI source PR. I have not yet written one for MainUI, but when I do I'll use the same header, and then when you intercept the web request you should add org.openhab.ios> to the front of the header value. For the latter, since the mobile app constructs the request completely, you should construct it like org.openhab.ios>org.openhab.ui.basic$<sitemap>:<page> so it looks the same as if it was in a browser.

EDIT: MainUI PR