I know Quartermaster exists, but I don’t think it’s been maintained in a long time. So I decided to make my own, and I think it’s coming along pretty nicely, and it’s already somewhat usable.
So what’s the difference?
Quartermaster AFAIK is fully native - my app just shows a native login, and after that jumps into a webview wrapper, just like the official Android and iOS companion apps. This way we get all the new features as they come without needing to keep up with the official Home-Assistant development, and the app is already after 1 day’s development nearly identical to the official companions.
Also, notifications are of course native. QT notifications themselves are super limited, so I figured I’ll use the app cover to show the stuff, and I think that turned out pretty neat. You post the notifications just like you would to an Android/iOS companion, and from the “data: “ payload it takes notification_icon and color, and does cool stuff with them.
Notifications run through websockets only at the moment, so the app needs to be open or backgrounded to receive them. But you’ll want it backgrounded anyway so you get to see the cover in action I don’t know how robust the websocket handling is yet when it switches between internal/external urls (those can be configured after login by pressing to cog icon on the cover), but if it’s unreliable, I’ll improve it later.
And generally, I’ll add features as I come across stuff I need myself, but I’m also open to suggestions on what to do next.
Oooo! Where is it? My precious! No, but seriously - been waiting for a native Home Assistant app. (Looking at you OpenHAB ). I think this is a great idea - an all native solution would ofcourse be awesome, but I understand that maintaining it and bringing alla the functionality in par with the Android/iOS version would need significant hours.
So, that said, can’t wait to see what this app of yours can do.
We’re getting spoilt for choice with Quartermaster, Lugar and now this!
@pauligrinder What would be incredible is if Helmsman could be used to add (new) Matter devices to your network. I haven’t found a way to get that working through AppSupport.
Are you adding them using Home-assistant or is it a separate thing? If it’s a service in hass, there’s a chance it could work
But we’ll see, I don’t have any matter devices myself (yet).
And yeah sorry for not being able to provide a release yet, I should’ve made sure the build succeeded before posting here. It’s not a big problem though, my local build was successful so it’s just a github configuration issue, so I will have it working tomorrow.
The default port was recently changed to 80 for all new setups (and changing it is pretty easy for anyone on port 8123), so Helmsman should probably check if entering a bare URL works first before adding :8123. In fact, I can’t get Helmsman to work on port 80. After entering the credentials it keeps spinning and reloading the page with the HA logo. I tried closing and reopening, but then it tries to go back to port 8123, and changing it to 80 again does nothing.
It’s part of the companion apps on Android and iOS, but for Android it only works on the Play Store version because it apparently has to download some extra stuff to be able to add new Matter devices.
Thank you Pauli! This is the way I like to use my HomeAssistant. Logging in with 2FA worked well, and the end is like using it in a browser. However I noticed that many times when starting the app, at first the page does not render completely, for example all widget content are empty, and top bar icons are not visible (only active). Swiping over buttons makes them flashing their content briefly. Going to some other sidebar item, for example maps, and coming back to overview everything is shown again. I thought it might be because of the connection if the data is lagging, but same happens on wlan and mobile connection. Not a problem of course if leaving the app minimized as a cover. Happy to see that you’re working with this app, thanks.
Hmm, it should go back to the initial connection screen if it can’t connect. I should probably add some kind of ping-test at least to the external url.
And yeah, the slight choppiness is due to the fact that the sfos browser itself isn’t very well optimized. I could check if it’s possible to use some other browser engine and if that would improve performance… But otherwise we’ll just have to wait for updates.
The “restore failed” already worked for me, but if the address was wrong there was just no way to change it. There was an address field in the resulting screen, but it wasn’t used. Now I replaced it with a button to navigate to the screen where both addresses can be configured and now also tested By the way, make sure http:// or https:// are correct in the urls - at least in my setup the local url is plain http whereas the external is https, so I made the addresses detect that from the URL.
I also tried to improve the initial loading, it now shows a spinner until the initial dashboard loading is complete so components don’t jump in and out. I don’t think I want to add that to each subscreen in the dashboards though, as that might slow it down considerably.
I guess my tip on using it would be to keep the app backgrounded most of the time. That’s needed for notifications anyway.
Oh and by the way:
What’s your opinion on the app name? Does it make sense? A helmsman is basically an assistant to a ship’s captain, and since SFOS has this nautical theme, home => ship. Quartermaster of course is an even more appropriate name, but as we know already, it’s taken I also thought about something pirate themed - Scallywag would’ve sounded fun, but I feel like it isn’t descriptive enough.
Nice app, on X10 IV it works just like in native SFOS web browser. I have a problem when logging out, the ring spins and the texts “Loading…” and “Preparing…” flash below it, I had to kill the application. Then I couldn’t start it again, at the beginning the texts flashed under the ring like when logging out.
Hey, @pauligrinder, quick question. Since this app is a webview for the Home Assistant, how does this work with automations? There’s a background connection to the HA instance, yes. I have an automation that when I’m on a specific WiFi, my status is for example “Home” or “Office”. Also, I’m getting an error on sending a notification to the app.
Ok, found the issue. “Failed to perform the action notify.mobile_app_helmsman_jollaphone2026. Device(s) with webhook id(s) not connected to local push notifications”
Edit 2: Closed and reopened the app and now the connection works and notifications come through. So, one issue “solved”.
Yeah the socket could be unreliable and will most likely need fine tuning. I just threw it together real quickly to see that it works to begin with.
And regarding the automations question, yeah, it doesn’t expose any sensors yet. It’s not something I commonly use myself, so that’s why it’s not there immediately - but I’ll put it on the todo-list and it’s likely a relatively easy thing to implement as well. It probably can’t support all the same sensors that the Android-app supports, but WiFi network is definitely one it will support (we already have that information in the internal/external detection).
Oh, favorites can definitely be done - just gotta check how many we can cram into the cover Another thing to investigate would be if we can have an Events view widget for it that could host the favorites.
This change made the initial loading a little bit more reliable to me. Before the change I had empty widgets problem at first load six times out of ten, and now only three times. But it came with cost of doubling the loading time from 6s to 12s… definetly not usable for all tabs… I wonder what is the difference, because when I launched HA ten times in a browser, it failed only once. Well, I’m using homeassistant all the time, so as you said, it’s better keep the app backgrounded. That way the loading time is 0.5s
My use is similar and I’d like to use the cover as you described.
Yeah, I guess the browser is just a bit flaky and the webview even more so. But yeah, backgrounding makes it work pretty nicely. I’ll also see if I can somehow cache and restore the webview state, which would make it faster.
This caused HA to be unavailable from the Internet (403 Forbiden), because HA is set to block IPs. HA worked for me in LAN.
Ah, so I guess it attempted to connect too many times and it got blocked? Shouldn’t it still work after your ip changes, or did your reverse proxy get blocked?
I encountered a similar situation just now, when restoring the session it blinked rapidly and when I got in I had a notification about a failed login. I don’t have any blocking setup though, so it didn’t lock me out. But I’ll try to improve those, I suspect it’s an http/https format issue.
It now has basic sensor functionality. It reports location (with a setting to show as “home” when on an internal connection), battery state, wifi network name, and some other stuff that was easy to pull. I’ll add more if/when deemed necessary (and if possible, of course)
I also changed the icon to be more sailfish-like and generally nicer.
I don’t know how robust the websocket handling is yet when it switches between internal/external urls (those can be configured after login by pressing to cog icon on the cover), but if it’s unreliable, I’ll improve it later.
). I think this is a great idea - an all native solution would ofcourse be awesome, but I understand that maintaining it and bringing alla the functionality in par with the Android/iOS version would need significant hours.
I also thought about something pirate themed - Scallywag would’ve sounded fun, but I feel like it isn’t descriptive enough.