get_liveview() returns a immis protocol link

[IanTrudel]

get_liveview() returns a immis link on an XT2 camera instead of an rtsps link. The only information on the protocol that I could find is on lurume84/bling-desktop#26. Any (other) way to access the stream?

[fronzbot]

Not that I'm aware, sorry

[e-team-t]

get_liveview() return the following for me on a xt2 ,

.local/lib/python3.6/site-packages/blinkpy/camera.py", line 204, in get_liveview
    return response["server"]
KeyError: 'server'

Also tried this:
blinkpy.api.request_camera_liveview( blink, ...
Got the following in return:
{'message': 'An app update is required'}

any ideas?

[fronzbot]

Yeah looks like the API endpoint changed. This guy figured it out recently so looks like that link just needs to be updated: lurume84/bling-viewer@499f393#diff-a55f5692772dd8c93564ed9c3e86ba99

[e-team-t]

I changed line 248 of the api.py file to the following:

f"{blink.urls.base_url}/api/v5/accounts/{blink.account_id}/networks/{network}/cameras/{camera_id}/liveview"

and it is working fine, I am getting the immis link.

[fronzbot]

Awesome! Feel free to make a pull request if you'd like. Otherwise I'll get that in some time this week

[cee-dee]

Since the pull request was merged to dev I assumed that I could retrieve the liveview url via get_liveview. But I've trouble streaming it.

The server responds with
{ 'command_id': 91342095, 'join_available': True, 'join_state': 'available', 'server': 'immis://3.123.232.171:443/abcdef01234567890__IMDS_G8T11234513512B9?client_id=52265', 'duration': 300, 'continue_interval': 60, 'continue_warning': 10, 'submit_logs': True, 'new_command': True, 'media_id': None, 'options': { 'poor_connection': False } }

The method returns rstps//3.123.232.171443/abcdef01234567890__IMDS_G8T11234513512B9?client_id=52265, which is due to improper replacing of immis. But anyway, I cannot get players like vlc to stream the link rstp://3.123.232.171:443/abcdef01234567890__IMDS_G8T11234513512B9?client_id=52265.

Can anyone assist with this?

[fronzbot]

Full disclosure: I've never actually tested the method, just added it in because I saw the endpoint was there. Good catch on the game incorrect link formatting, I'll have to fix that!

Anyways, I'll try to test this today to see what my results are. It's possible the endpoint changed again and we're using a stale url.

[fronzbot]

Yeah I'm struggling to get this to work too. Not sure what the solution is

[cee-dee]

Do you have a working livestream with another camera?
Can you see the network traffic on that protocol? Maybe it differs from the working version by some kind of custom header?

[fronzbot]

No I don't. Your hunch is probably a good one, but I'm ill-equipped to do any network sniffing, unfortunately

[cee-dee]

Maybe there are ways to work work with an Android emulator to get insights in the traffic, see https://developer.android.com/studio/profile/network-profiler

But I haven't worked with that yet.

[foxm79]

Are you all able to view a live stream from your blink mini or outdoor cams?

Hello @fronzbot!
Firstly, Thanks you soo much for this library.
I am able to download my images now.

For get_liveview() I think I fixed a small issue in the camera.py:

blinkpy/blinkpy/camera.py

Line 269 in 014509b

server_split[0] = "rtsps:"

server_split[0] = "rtsps:"
link = "".join(server_split)
to
server_split[0] = "rtsps"
link = ":".join(server_split)

With this I get the link as:
rtsps://52.34.34.83:443/NBl17cWGk61xIJKy__IMDS_G8T1900001642F9F?client_id=57905

But I am not able to view it.
Any help will go a long way!

[esistgut]

Did anyone figure this out? I see the "liveview" rest api returns 'join_available': True, 'join_state': 'available', among other things, maybe the cam has to be "joined" in order for the stream to work?

[KiraPC]

Hello, any update on this?

[fronzbot]

Unfortunately, no. The protocol Blink uses appears to be proprietary and unless someone is able to crack it, anything with an immis link will be unviewable.

[simon2022]

any updates?

[MaUwJo]

any updates?

I downloaded the file "Blink Home Monitor_27.0_Apkpure.apk" and patched it with
apk-mitm --keep-tmp-dir Blink\ Home\ Monitor_27.0_Apkpure.apk
( https://github.com/shroudedcode/apk-mitm )strings libwalnut.so | grep immis
as I kept the tmp dir i'm able to navigate to it:
cd /tmp/apk-mitm-c08e4858c726d3cf7a351d94fe5ad834/decode/lib/x86_64
and do a strings libwalnut.so | grep immis
IMMIStreamSource can only operate on immis: URLs
immis
Receiving data after disconnect. immistreamsource._connectionState = %d
I think this is the library which is doing the imms stuff.
But unfortinuately my know how is not enought to analyze it deeper or to remove the ssl pining out of the library, so I could see unencrypted what's happening there.

All other calls to the API are now visible with PCAPDROID ( https://play.google.com/store/apps/details?id=com.emanuelef.remote_capture&hl=de&gl=US ) and the mitm binary which this tool can download.

Maybe there is someone out there who can analyze the details - I hope this helps.

[GiovanH]

I'm using an old-but-working version of the iOS app, which communicates like this:

curl -i -s -k -X $'POST' \
    --data-binary $'{\"intent\":\"liveview\",\"motion_event_start_time\":\"\"}' \
    $'https://rest-u034.immedia-semi.com/api/v1/accounts/{account_id}/networks/{network_id}/owls/{camera_id}/liveview'

which the server responds to with:

{"command_id":1055540110,"join_available":true,"join_state":"available","server":"immis://18.216.15.175:443/[hash]__IMDS_[hash]?client_id=606199","duration":300,"extended_duration":5400,"continue_interval":60,"continue_warning":10,"polling_interval":15,"submit_logs":true,"new_command":true,"media_id":null,"options":{"poor_connection":false}}

It then takes that command int in the response and loops over GETing a url like

https://rest-u034.immedia-semi.com/network/{network_id}/command/{command}

which returns this interesting session-y object

{"complete":true,"status":0,"status_msg":"Command succeeded","status_code":908,"commands":[{"id":1055540110,"created_at":"2024-06-23T00:17:52+00:00","updated_at":"2024-06-23T00:18:53+00:00","deleted_at":null,"execute_time":"2024-06-23T00:17:52+00:00","command":"lv","state_stage":"vs","stage_rest":"2024-06-23T00:17:51+00:00","stage_cs_db":"2024-06-23T00:17:52+00:00","stage_cs_sent":"2024-06-23T00:17:52+00:00","stage_sm":"2024-06-23T00:17:52+00:00","stage_dev":null,"stage_is":null,"stage_lv":null,"stage_vs":"2024-06-23T00:17:52+00:00","state_condition":"done","sm_ack":1,"lfr_ack":null,"sequence":172,"attempts":0,"transaction":"[hash]","player_transaction":"k-vUceCm9z7vMFqY","server":"immis://18.216.15.175:443/[hash]","duration":61,"by_whom":"[device name] - 6.26.0 (2305082009) #a328e77a4-mod - liveview","diagnostic":false,"debug":"","opts_1":0,"target":"owl","target_id":xx,"trace_parent":null,"sync_module_id":0,"parent_command_id":null,"camera_id":null,"siren_id":null,"firmware_id":null,"network_id":xx,"account_id":xx}],"media_id":null}

Note the transaction value is the hash from the imms url.