I updated my wife's phone, also an S21, last night and her's reported correctly, too. The only thing I noticed was that charging/not charging does not seem to be an independent event which triggers a new report from the phone. What I noticed was that, this time, her phone was on the charger, motionless, and it didn't send any report for close to 7hrs. But at that time it reported correctly.
I have a fix ready - which will report the type of charging too - usb/ac/wireless/dock; it'll be in the next release
2 Likes
Let me know when the new version is ready and I'm happy to try it out.
Thanks
Hello @jpage4500
I was wondering if would be possible to link the tasker tiles back to a virtual button in hubitat?
The hope being that i could automate tasker tasks to run on my phone based off automations in hubitat.
Many thanks for this wonderful app and making it android auto capable. Its nice being able to see status of the devices i care about right on my car screen as im on the move.
That could be possible in combination with the new HD+ Device driver.. the reason is that allows the hub to push a message to the phone. Right now it can push a notification or TTS message. I'd have to add the ability to send some other type of command and handle it in HD+.
I'd also need to add some new capability to the driver as well.. like a button. Something that would tell the driver to notify the phone..
Please let me know some more use cases for this and I'll see if I can figure something out
1 Like
version 1.0.2215 (beta)
- send power source (wireless/ac/usb) via location tracking
- show previous version changes in update dialog
For the location tracking feature, I'm now sending a value for power source (wireless/ac/usb). It'll require the latest "My Location" driver (via Hubitat Package Manager)
I also made a change for future 'check for updates' - so it'll show more than just the most recent release notes (only available in the direct apk version)
5 Likes
Joe,
I saw you mention that the rtsp library you use supports Digest Authentication, but is that exposed in any way for the image/video tiles? Trying to add Amcrest IP Camera rtsp video and/or snapshots, seeing now that Amcrest changed to Digest only authentication a while ago (most examples show urls with basic auth, which is now disabled).
Hi Joe, thanks for the new release.
Tried to update APK update on two of my test devices without luck.
From 2212 to 2215 -> no update available
From 2203 -> update failed.
Main phone via Play Store still on 2212.
thanks for finding this - I made some changes to the release notes that I generate so it can show multiple versions. But, it looks like it got mangled somehow - I'll fix
EDIT: it should be fixed now
1 Like
This is the library: GitHub - alexeyvasilyev/rtsp-client-android: Lightweight RTSP client library for Android
It does mention this:
Basic/Digest authentification.
I'm not sure how to specify which type is used though.. maybe it auto-detects? I'll ask the author
Update works again. Charging flag gets updated now. Great work.
One question, can I see somewhere the type of charging or is this implemented in some variables stated in the details?
Thanks for the great work
Update: found the "power flag" which indicates the source of power.
1 seems to be charging by wire
4 seems to be charging wireless
Can you please confirm and fill the missing power sources?
Joe,
Thanks, would be great if there's a way to support it. Seems like digest auth is required for all Amcrest and Dahua cams now.
Took a quick look at that RTSP library and he has the support for Digest. The library has the calls and even shows the reference sequences in comments. The reference rtsp test app has the login credential fields in addition to the url.
But in addition to a url, you'd have to expose fields for username and password, and probably a 'use digest auth' option to start.
Digest does an initial connect request, I think the server passes back a '401' and a nonce, and then the noncee, username,pass etc go through hash operation which is sent to server for acceptance.
Image tiles would need the same digest auth support to get snapshots, but you
probably don't use the rtsp library for that.
You can set a username and password for RTSP video today and I'll pass that to the library. Since I only have a single URL input field, just put the username and password in the URL like this: rtsp://username:password@192.168.0.70:554/h264Preview_01_sub
I remove username:password from the URL and pass it into the login methods separately. So, if the library can automatically handle it from there it should be good to go.
Image tiles would need the same digest auth support to get snapshots, but you
probably don't use the rtsp library for that.
I get still images from my Reolink camera by passing the username/password in the URL
https://192.168.0.166/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=USERNAME&password=PASSWORD&width=640&height=480
I see an example that might work for Basic authentication.. is that what you're looking for? I could do something similar to RTSP if that might work
Joe,
I think the method of supplying username and pw in that fashion (as clear text in the url itself) is for basic auth. And basic auth is rejected now by Amcrest/Dahua due to its security issues (credentials in clear).
I may be wrong for his particular library and rtsp setup, as I didn't explicitly get that far with the video tile. But the form username:password@server:port is classic basic auth.
I was initially trying to make image snapshots work, and was using a similar method (basic auth) in the camera snapshot url. That was clearly being rejected by the camera, and thats where I saw that they switched to Digest.
I think today, you probably don't even need to know if its basic auth or just any other url at your app level . But for Digest I think you need the context.
And you probably have a bunch of users and legacy cameras still using basic auth (assuming there are other cameras still supporting that) with your current approach.
So you need a way to input the url (you have this), and also the username, and also the pw as separate entries and store them separately. It looks like you pass them into library as parameters for the rtsp connect init. The library hashes the username, pw, and the nonce (random seed) that is returned in the initial connection request and sends that up to the server for acceptance.
I'm not passing the URL as entered in HD+ into that RTSP library. I check for the presence of username:password and will remove them from the URL and pass them into the library separately (that init() method). The final RTSP URL that gets passed into the library won't have username:password in it. I'm just doing this to avoid having separate input fields.
So, maybe that messes up a legitimate basic auth style URL as that'll never make it to the library as-is. But, it seems like it'd work in your case today.
Oh, OK, sorry; fair enough for RTSP then. I will try that tonight, I'll have to figure out the correct rtsp url for my setup. When the image snapshot failed, I figured rtsp was in same boat and stopped.
For the image tiles, do you just use a standard android http/https library(?), so maybe doesn't work there (and the username/pw go up in the url). The http request in this case would also have to be digest auth encoded (mostly with fields in the http headers)
Joe,
Thanks and sorry for confusion, I made assumption that the issue was common to both the image and video tiles, especially since the format exactly matched basic auth. I just tried RTSP per your comment above, and that works fine, video tile works, thats awesome.
Image tile for snapshots (which is http or https GET) does not work. Just for kicks I tried the same format, but I suspect the image calls are going into standard android http driver (for sure they aren't going to rtsp). So the real issue would be seeing if that library supports digest for http and how to get credentials in. I assume you'd have to pass username and pw in similar to the rtsp library.
I use glide library for image loading/caching. That link above was specific to glide -- take a look and let me know if you think that would work.. link
If it works I can try to use a solution like I'm doing for RTSP.. user:pass@server/etc/etc. I don't know if any cameras already use that format though. My Reolink camera takes the user/pass as URL params so that wouldn't be affected
Hi @jb1, here is the list from Joe. This is listed on the myLocation driver github readme and also commented in the driver code itself.
power - Charging details (-1=unknown, 0=not charging, 1=AC, 2=USB, 4=wireless, 8=dock)
3 Likes
Joe,
No, thats still basic auth, but the method stuff the credentials into a header (I think its still clear but base-64 encoded.)
I can see someone asked for an example for digest auth on Glide, for exact same use case , but it went unanswered and marked as stale:
I think the solution is a little more complicated since you have to do the simple request first, collect the server's nonce response, and then use that with library to calc the digest hash and attach digest header,
There's a stack overflow on the topic with a few android solutions posted based on different libraries, but its not clear to me which library Glide is using for its http connections under hood.
need-help-creating-digest-authentication-for-android
Thats a pretty old thread, but the okhttp-digest library seems to be maintained and shows the examples...but assumes okhttp as the main lib.
