Just do this

bash camera_watch.sh

And you should see this: Monitoring camera access…

That is all! From here if your setup is correct the moment you start your camera for a conference call or a meeting your hue light specified will turn on!

Github Repo

To get the actual files and run this locally go to THIS github repo and follow the README.

What the script does (purpose)

• Monitors macOS unified logs in real time to detect when the camera starts and stops streaming.
• Turns a Hue light ON when the camera becomes active.
• Turns the Hue light OFF when the camera becomes inactive.
• Optionally turns the light OFF on exit, so you don’t leave it on if you stop the script.

In practice, it’s a “webcam indicator light,” but better—because you can place it anywhere in the room, use any Hue bulb/fixture, and make it as noticeable (or subtle) as you want.

Why this is useful (benefits)

• Immediate, ambient awareness: You get a physical “camera is live” signal even if the app UI is minimized or on a different screen.
• Privacy + confidence: Helps you notice unexpected camera activation and reduces uncertainty (“Is my camera still on?”).
• Hands-free automation: No need to remember to toggle lights at the start/end of calls.
• Flexible setup: You can choose which Hue light to control and can override behavior via environment variables.

How it works

At a high level, the script is a loop:

1. Stream macOS logs continuously.
2. For each log line:

• If it indicates camera start: turn Hue on.
• If it indicates camera stop: turn Hue off.

Here are the key moving parts.

1) Safety and predictable shell behavior

The script starts with:

• set -euo pipefail: fail fast on errors, undefined variables, and pipeline failures.
• IFS=$'\n\t': safer word-splitting defaults.

This is defensive Bash: it reduces the chance of silent failures and weird parsing bugs.

2) Configuration with sensible defaults (and easy overrides)

It defines defaults, but allows overriding via environment variables:

• LOG_BIN (default /usr/bin/log): the macOS unified logging CLI.
• HUE_SCRIPT (default hue_camera_watch/hue_1.2.1.sh): the Hue control script it delegates to.
• HUE_LIGHT_TYPE (default light): passed through to the Hue script.
• HUE_LIGHT_ID (default 28): which Hue light to toggle.
• LOG_LEVEL (default info): log streaming verbosity.
• CLEANUP_TURN_OFF (default true): whether to force the light off when the script stops.

This design is practical: you can run the same script in different setups without editing it—just set env vars.

3) Simple logging helper

log_msg() prints timestamped messages to stderr, keeping stdout clean in case you want to pipe output:

• This is helpful if you run it under a supervisor, redirect logs, or want to keep the terminal tidy.

4) A tiny “adapter” function for Hue control

hue_state() is a wrapper that calls the Hue script like this:

/bin/bash "$HUE_SCRIPT" "$HUE_LIGHT_TYPE" "$HUE_LIGHT_ID" state on|off

This keeps camera_watch.sh focused on detection and state logic, while hue_1.2.1.sh handles the details of talking to the Hue bridge.

5) Cleanup and signal handling (don’t leave the light on)

Two traps are important:

• trap 'cleanup; exit 0' INT TERM : on Ctrl+C or termination, run cleanup and exit.
• trap cleanup EXIT : on any normal exit path, also run cleanup.

And cleanup itself is “best effort”: it tries to turn the light off, but won’t crash the shutdown sequence if that fails.This is the kind of detail that makes a script feel trustworthy day-to-day.

6) Early validation (fail fast)

Before streaming logs, it checks:

• The log binary exists and is executable.
• The Hue script file exists.
• HUE_LIGHT_ID is numeric.

That means you get clear errors immediately rather than a script that “runs” but doesn’t actually work.

7) The core event loop: streaming logs and detecting camera events

The heart of the script is:

log stream --style syslog --level "$LOG_LEVEL" --predicate '...'

It filters to:

• process == "UVCAssistant" and log messages containing:
• kUVCExtensionEventStartStream
• kUVCExtensionEventStopStream

Those messages correlate with the camera starting/stopping at the system level.Then, for each line:

• It skips header/noise lines (important to avoid false positives at startup).
• If it sees a StartStream event:
• If the script currently thinks the camera is inactive, it flips internal state and turns the Hue light on.
• If it sees a StopStream event:
• If the script currently thinks the camera is active, it flips internal state and turns the Hue light off.

That internal state (CAMERA_ACTIVE) is a simple but important detail: it prevents repeated “on” commands if multiple start log lines appear, and avoids spamming the Hue bridge.

Customizing it (common tweaks)

Because configuration is environment-driven, you can do things like:

• Pick a different light:

• Set HUE_LIGHT_ID to your bulb’s ID.

• Use a different Hue control script:

• Set HUE_SCRIPT=/path/to/your_hue_script.sh

• Keep the light as-is when you stop the script:

• Set CLEANUP_TURN_OFF=false

• Adjust verbosity:

• Set LOG_LEVEL=debug (or keep info)

Practical notes and limitations

• macOS-specific: it relies on the unified logging system and the UVCAssistant process behavior.
• Event accuracy depends on logs: if Apple changes log messages/process names in future macOS versions, the predicate may need updating.
• Requires Hue connectivity: if the bridge is unreachable, the script may fail when sending commands (it’s intentionally strict overall).

The post Turning a Philips Hue Light On When Your Mac’s Camera Turns On appeared first on Alexiev Arts.

In this article, we would explore a solution where we would make our index.html a handlebars template and hydrate it on the client site without SSR (Server-Side Rendering). This approach would use the npm scripts section of our package.json where we would replace the start and add prebuild stages with simple bash scripts. That way by doing npm start to start our app we would be hydrating and creating the index.html at run and build time. Also, this approach would allow for multiple environments and instances configuration. You would be able to dynamically hydrate your index for development vs. production build or siteA vs. siteB instance by simply providing create react app with a few environment variables.

TLDR: Working version of the CRA below can be found on Repl.it. Fork it to run the npm scripts etc.

Requirements:

• Nodejs version 8.10 or above
• npm version 5.6 or above

Setting up our React App

So lets start with creating our CRA first which we would name dynamic-meta with:

npx create-react-app dynamic-meta

npx on the first line is not a typo — it’s a package runner tool that comes with npm 5.2+

Next, let’s add the handlebars CLI package called hbs-cli and save it to our package.json file as a dependency:

npm i hbs-cli -s

We need the hbs-cli in order to run handlebars via the shell script which we would place in our package.json scripts section.

At this point, we have all the needed packages from npm to make this work. Next, let’s setup a few more files and folders for organization purposes. Let’s move the index.html from the public folder to a folder in the root called template and rename it to index.hbs. This would be our template which would be hydrated to produce the final index.html in the public folder. We would also add some handlebars variables and clean up some of the comments added by CRA. So the end result is something like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta property="og:title" content="{{{TITLE}}}"/>
    <meta property="og:description" content="{{{DESCRIPTION}}}"/>
    <link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
    <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
    <title>{{{TITLE}}}</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  </body>
</html>

You can already see what we would be replacing in the index template. All the handlebars variables shown above would be hydrated via json files at start/build time. To learn more about handlebars click here.

Now we would assume that we have few environments for our application and few instances as well. For example, we will have a development environment and a production one and in each of those, we might have different API and other keys that we might want to use. You might have a sandbox API key for a 3rd party integration in development and another production version for your production environment. Also, each one of the different instances might have a different favicon.ico and manifest.json as well. What about the app logo?

So in order to support all those we would simply create another folder in the root and call it sites. In that folder, we would have sub-folders with the name of our instances. For this example, we would use siteA and siteB. And since we are creating folders, let’s create another one called scripts in the root folder.

At this point, our app tree looks like this:

root
|
└-- public        // CRA default public folder
└-- scripts       // Our start and prebuild scripts reside here
└-- sites         // To keep our instance folders organized
|   |
|   └-- siteA     // Instance folder A
|   └-- siteB     // Instance folder B
└-- src           // CRA default source folder
└-- template      // Where our index.hbs resides
    |
    └-- index.hbs // Our handlebars template file

Since each instance of our site would be different in terms of look and feel we would copy favicon.ico, logo files, and manifest.json to each of the instance folders and remove them from the public folder. Our public folder should contain only the rebots.txt file generated by the CRA at this point. We would copy all the instance files from the instance folder to the public folder at start & build time. We will also add an entry to our .gitignore file to ignore all files in the public folder except the robots.txt one later.

The configuration JSON files

We would also want each site instance to have its own images/title/description/API Keys etc. So let’s start with what would be common between all the siteA environments. Title and Description sound like good candidates here. Let’s create a default.json file that would be always used by handlebars when we want to hydrate our index.hbs. For siteA we would have:

{
  "TITLE": "SITE A",
  "DESCRIPTION": "SITE A Description"
}

You would have the same name file in the siteB folder with different values for the TITLE and DESCRIPTION.

Ok we are almost there. The only thing missing is the actual scripts to “glue” together everything.

The Scripts

If you try to run our app at its current state nothing good would happen since we have no index.html at all in our public folder. We need to actually generate one. To do this let’s set up our scripts in our package.json first:

"scripts": {
    "start": "bash scripts/start.sh",
    "prebuild": "bash scripts/prebuild.sh",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },

Next, let’s create the prebuild.sh file in the scripts folder. We start with that one since the start.sh would be relying on the prebuild.sh. Here is what the prebuild.sh would look like:

#!/usr/bin/env bash

# Parameters
ENV=${REACT_APP_NODE_ENV:-development}
INSTANCE=${REACT_APP_NODE_APP_INSTANCE:-siteA}

# Folders
PUB="public"
SITES="sites"

# Files containing the handlebars variables
DEFAULT_FILE=${PUB}/default.json
ENV_FILE=${PUB}/${ENV}.json

# Template files as parameters to the CLI command
PARAMS="-D ${DEFAULT_FILE}"

echo "ENV: $ENV"
echo "INSTANCE: $INSTANCE"
echo

# Copy all instance files into the public web folder
[ -d ${SITES}/${INSTANCE} ] && command cp ${SITES}/${INSTANCE}/* ${PUB}

# Only continue if we have default template variables file
if [ -f ${DEFAULT_FILE} ]
then
  # Concatenate env variables file to the data parameters variable
  [ -f ${ENV_FILE} ] && PARAMS="${PARAMS} -D ${ENV_FILE}"

  # Run the CLI for handlebars to hydrate the template with the data files
  command npx hbs ${PARAMS} template/index.hbs -o ${PUB}

  # Remove the copied template json files except manifest.json
  command find ${PUB}/*.json ! -name manifest.json | xargs rm
fi

echo "┌-----------------┐"
echo "| Pre-Build Done! |"
echo "└-----------------┘"

Now we would not go into too many details of what the shell script above does (there are comments on every line) but here are few pointers. The first and most important thing to mention here is the parameters being read in ENV and INSTANCE variables. If any is provided then we would use those but if not we would default to development environment and siteA instance.

Note that we use the command prefix in order to make sure we avoid any aliases being used. For example, if the alias of cp -i is registered for the cp command the script would have different behavior. Another important thing to more here is the use of npx hbs in order to hydrate our index.hbs template and produce the index.html file. Handlebars by default outputs HTML so we only specify the output folder with the -o parameter.

Next lets setup our final script file – the start.sh:

#!/usr/bin/env bash

export REACT_APP_NODE_ENV="${REACT_APP_NODE_ENV:-development}"
export REACT_APP_NODE_APP_INSTANCE="${REACT_APP_NODE_APP_INSTANCE:-siteA}"

# Run the prebuild with the exported above ENV variables
bash scripts/prebuild.sh

# Start the app
npx react-scripts start

As you can see the only purpose of the start.sh is to export the REACT_APP variables so they are accessible to the prebuild.sh file. After that, it simply start the app via the react-scripts start command. Note also that it defaults the REACT_APP_NODE_ENV to development and REACT_APP_NODE_APP_INSTANCE to siteA. This is for convenience purposes since we do not want to always specify the CRA environment variables to start our app. This way npm start would start the development siteA.

Wrapping things up

So if you start our app right now with npm start … this is what we should see in the terminal:

ENV: development
INSTANCE: siteA

Wrote /<PATH TO YOUR APP>/dynamic-meta/public/index.html from template/index.hbs
┌-----------------┐
| Pre-Build Done! |
└-----------------┘

Opening the page source of the dynamically created index.html in the public folder gives us:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta property="og:title" content="SITE A"/>
    <meta property="og:description" content="SITE A Description"/>
    <link rel="apple-touch-icon" href="/logo192.png" />
    <link rel="manifest" href="/manifest.json" />
    <title>SITE A</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  <script src="/static/js/bundle.js"></script><script src="/static/js/0.chunk.js"></script><script src="/static/js/main.chunk.js"></script></body>
</html>

As you can see we have our handlebars variables hydrated. Now lets try passing a different instance with:

REACT_APP_NODE_APP_INSTANCE=siteB npm start

We would get as we would expect the siteB meta title and description:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta property="og:title" content="SITE B"/>
    <meta property="og:description" content="SITE B Description"/>
    <link rel="apple-touch-icon" href="/logo192.png" />
    <link rel="manifest" href="/manifest.json" />
    <title>SITE B</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  <script src="/static/js/bundle.js"></script><script src="/static/js/0.chunk.js"></script><script src="/static/js/main.chunk.js"></script></body>
</html>

More than just meta tags

Last but not least what about different values that we might have for environments like development or production? Let’s say we have a 3rd party app integration like google analytics or similar that has different keys for the different environments. How would we solve that with the approach above?

We simply add them in the index.hbs with handlebars if condition and we add the environment json files. Our prebuild script already accounts for that. So let’s add development.json and production.json in the siteA and siteB site folders. In each let’s add a prop with the name APP_ID. For example, this would be our sites/siteA/development.json:

{
  "APP_ID": "DEV SITE A"
}

and this sites/siteA/production.json:

{
  "APP_ID": "PROD SITE A"
}

Now lets add in the index.hbs template:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta property="og:title" content="{{{TITLE}}}"/>
    <meta property="og:description" content="{{{DESCRIPTION}}}"/>
    <meta name="description" content="{{{DESCRIPTION}}}"/>
    <link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
    <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
    <title>{{{TITLE}}}</title>
    <script type="text/javascript">
      {{# if APP_ID}}window.APP_ID='{{APP_ID}}';{{/if}}
      if (window.APP_ID) {
        alert(`APP_ID: ${window.APP_ID}`)
      }
    </script>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  </body>
</html>

We simply use handlebars if condition which says if we have as a variable APP_ID then write the text window.APP_ID='{{{APP_ID}}’ and replace the APP_ID with the value. Then we check if window.APP_ID exists and if so we alert it. So if we run this with the default npm start we would see the alert DEV SITE A since we have an entry for the APP_ID in our siteA development.json file.

Now lets run the production one with:

REACT_APP_NODE_ENV=production REACT_APP_NODE_APP_INSTANCE=siteA npm start

Now we would be using the the APP_ID from the production.json file and we would get PROD SITE A alert.

What about build time?

If you would like to crate a build for the default siteA instance and the default development environment when you simply run:

npm run build

To run a production build for siteB you would run:

REACT_APP_NODE_ENV=production REACT_APP_NODE_APP_INSTANCE=siteB npm run build

The cool thing is that we have hooked our dynamic index.html creation at the prebuild time so the actual build would already have the hydrated index.html from the index.hbs and would then go through the create react app react-scripts pipeline to create the final create react app build.

Repl.it

If you would like to play with the code for this and see the actual results from the create react app just go to this link. Then click on the Run button to start the default build. You can also then use the Repl.it console to execute the different npm start commands we mentioned above where you would pass the REACT_APP_NODE_ENV and the REACT_APP_NODE_APP_INSTANCE parameters.

Other Options

You can achieve a similar result without the use of the hbs-cli package and only with shell. For that, you can use the Mustache templates in bash or mo for short and call that instead of hbs-cli in your prebuild.sh script. You might have to change the parameters passed to mo slightly but other than that the rest would remain the same.

The post Dynamic meta tags with Create React App, Handlebars, and no Server-Side Rendering appeared first on Alexiev Arts.

How is this useful?

To give you one example: Tesla techs kept telling me that I had an upgrade that I did not have. Only when I gave them the raw data from the API they understood that they have missed one. In another example I found out from the options codes returned from the API that I had a feature I did not know I had and it was not listed anywhere in the orientation or the invoice which came with the vehicle!

Please note that this documentation is not official and in any shape or form supported or maintained by Tesla. It is actually reverse-engineered. The documentation web site Apiary is actually owned by Oracle and it is simply a product that helps with the documentation of application programming interfaces (or APIs). Also, none of your credentials are stored or kept anywhere. They are simply passed through to Tesla servers

How does this work?

We will start with the following steps needed to get the information we want from the Tesla Owners API:

• Authenticate via the Apiary Tesla Owner JSON API and get the authentication token we need in order to make any further requests to Tesla servers.
• Once we have the token we would use that and add it to the header so our request can properly. authenticate against the Tesla servers and obtain the other pieces of information we need.
• Get the list of vehicles under your account via the authentication token.
• Using a vehicle id get the information of interest.

Step 1: Go to the Tesla Owner JSON API on Apiary.io

Click on this link and have the browser window open and handy so you can see the current one you are reading from and the new one where you would add/change values. The link is to the actual documentation website we would use to make the requests.

Step 2: Get an authentication token from Tesla

You should see the screen above. The left side of it is the actual documentation and every request is explained in detail there. On the right side is the console where we would actually perform the requests and see the responses. Since the link already pointed to the Get an Access Token request it is already open and ready to be executed on the right side. The header information is already added as well as the majority of the body. What is only missing is your email and password. Enter those where it says “YOUR_EMAIL” and “YOUR_PASSWORD” and click on the “Call Resource”. Again no information is kept on your request. Your credentials are simply passed through to Tesla from the Apiary servers. You should see the following response in the console section:

You should get a 200 response from the server (see the red rectangle in the image above). This means we did everything correctly and we now have received an authentication token from the Tesla servers. This is the access_token in the Response Body above (masked in this example). Copy the value of that access_token (copy the text between the “” for the access_token key).

Step 3: Get the list of vehicles using the token

Now that we have the token we would go to the Vehicles part of the documentation and click on the List all Vehicles request:

In the console section, we would go to the Headers tab and for the Authorization key, we would set the value to be: Bearer and the token we copied from Step 1. That is all you need before clicking on the Call Resource again to this time to get the list of vehicles. Note that the Authorization value should not contain double quotes etc. Should be simply Bearer followed by space and the token value from Step 1. When you are done you should see something like this in the response:

All is well! We now have received the first few details about our car. We have the VIN, the actual Id in the Tesla system, the option codes, etc. Great result for a few minutes of actual “work” right? You also can now compare and check if your option codes match your invoice :). Now that we have the vehicle list we can copy the id_s value from it and dive into the actual specific data of that vehicle.

Step 4: Using the id_s to get vehicle data

What we will do now is to utilize the token and the id_s to get any of the State and Settings data we would like. We would only do the Vehicle State in this example since all others follow the same pattern. So two things we need to go forward with this. One is the authorization token we got from step 1 and second the id_s we got from step 3. Let’s click on the Vehicle State in the State and Settings section of the documentation.

Here in the console, we would go to the URL Parameters and for the value of vehicle_id, we would set the value we got from step 3 for the id_s. Then we would click on the Headers tab and do exactly what we did in step 3. Set the Authorization key to the Bearer and the token value from step 1. Clicking on Call Resource should return a response looking like this:

As you can see this returns a lot more data related to the actual state of the vehicle. You can now follow this example and do any of the other requests listed under the State and Settings section. For the sake of brevity, we would not cover the Vehicle Commands section. It follows the same patterns overall so you can experiment if you like it.

Hope this helps and if you have any questions do not hesitate to post a comment. I will do my best to reply promptly.

Use my referral code and save!

If you would like to receive 1,000 free Supercharger miles when you purchase your new Tesla use my referral code: http://ts.la/ilian3072

The post Tesla Owners API – How To appeared first on Alexiev Arts.

No router scenario

If you do not want/need a router then your setup steps are very straight forward and simply watching Spectrum’s video should get you set up. It goes step by step. You connect your modem to the cable. Connect your computer to the modem. Activate your modem and you should be good to go.

Router setup

The important step here is to make sure you activate your model only after you have connected your router to it and your computer to the router. If that is how you activated your model all should be fine and working. The way Spectrum makes the setup easy and secure is to remember your computer mac address

The mistake many people do is to connect the computer to the modem first. Activate the modem and make sure there is a working internet connection. Then adding the router to this setup should just work, right? Well not exactly. What happens is the modem records the computer mac address and from that point on it gets tricky to make it work with a router. Unless your router can do a mac clone.

Mac Clone

In our case, the router was added after the modem was activated with a computer connected to it. So the mac address of the computer was stored. The initial idea we had was we would set up the router with a static IP (which we got from our computer) and then have the modem as the gateway. That worked until Spectrum issued a new IP to us which was expected since we did not order static IP from them. They can change the IP anytime they want.

So how can you trick the modem to think that the computer that activated the service is the router? Here is where the mac clone functionality of the router comes into play. The router now “acts” as the computer with which you activated the service and you can still have your automatic IP setup as expected. Just click on the Mac Clone button and leave the WAN Connection type to “Automatic IP”.

Our router was Asus RT-AC68W but most if not all recent Asus routers have the mac clone capability. Other router manufacturers have that functionality as well. If you know how to get to your router user interface that should all you need to do.

To get to the router user interface you have to either connect a LAN cable to it and your computer. If it is a wifi router you can join the wifi network it creates. Then with your browser go to 192.168.0.1 or 192.168.1.1. Those are the usual default addresses manufacturers use. You should follow the manufacturer manual/documentation as to how to log in and get to the WAN settings.

The post Spectrum internet self-installation with a router appeared first on Alexiev Arts.

The thing about menu systems is that once you set it up you usually do not need to deal with it a lot. And even when you need to you always have a “Favorites” or “My Menu” where you store those hard to get to items. So we thought this is not a big deal.

Well, we got our A7III and we realized that some of the complaints in regards to the menu system are valid. Something as simple as switch between the EVF (Electronic View Finder) and the LCD is quite difficult to do. In fact, you can not unless you assign a custom button! Why would you need to do such a thing you would ask … good question let me explain:

The Problem

Out of the box, the camera switches automatically between the LCD and the EVF. When you get your eye on the EVF it defects it and shuts down the LCD. When your eye is away from the EVF it shuts it down and turns on the LCD. The issue is that the damn thing is so sensitive that every time you move your finger close to the EVF it shuts down the LCD which is THE thing you are a thing to change or do something with. Very annoying and frustrating after spending time with the camera. So we were on a mission to do this manually. If EVF is needed press a button to turn it on. Otherwise, keep LCD as the primary option. Or the other way around.

Since there are so many custom options you can have there are only a few that are not set and made sense to set this function on. We decided to set the Dial DOWN press to switch between the EVF and the LCD. Here is how we did it:

Step 1: Custom Operation1 > Page 8/9 > Custom Key

Please note that this selected item (Custom Keys) is a sub-menu for setting the camera custom keys (C1, C2, C3, C4, etc) ONLY when in “taking pictures mode”. The menu item underneath it is for setting the custom keys for when in video mode and the last one is for when in preview mode. It is not very self-explanatory. Icons are helping but not that much. Nikon menu system had a help function where you can press a button and see a screen full of explanation about the selected menu. It was VERY helpful. So back to the task at hand. Let’s get into the Photo Custom Key menu and try to find where the dial DOWN button is and set it to do what we want.

Step 2: Custom Key > Page 2 > Down Button

Once we are in the photo custom key section we go to page 2 and all the way down select/press on the “Down Button“. That refers to the main dial down button apparently. Next click on it and from that menu find the Finder/Monitor Sel. function located at page 14/19 in Display / Auto Review sub-menu:

Step 3: Display/Auto Review > Page 14/19 > Finder/Monitor Sel.

Once you select/press on the Finder/Monitor Sel. from the above Display / Auto Review sub-menu you are set. Now if you press the Down Button you will be able to manually switch between the LCD and the EVF!

Step 4: FINDER/MONITOR > Monitor (Manual)

Ok so we got the button covered but the camera still auto switches between the EVF and the LCD. In order to change that you need to go to the main menu (Just press the Menu button) and go to Display / Auto Review1 and then select FINDER/MONITOR (Yes it is in capital letters on the menu!). Once you select that you will get this on the screen:

We want to select here Monitor (Manual) from this menu. Once you do that on start the camera will turn on the LCD and not the EVF EVEN if you have your eye on it. You have to press the Down button to switch between the LCD and the EVF. Pressing again on the Down button would get you back on the LCD and turn the EVF off.

Note: Auto Preview

One thing to note is that if you have Auto preview on and you have set it to one of the time intervals (like 3-5 sec) it would ONLY show on the currently selected viewpoint. So if you are shooting with EVF and you have the auto preview it would show ONLY in the EVF :). For that reason, I have disabled the auto preview and it is only available by pressing the preview button. It actually works great that way since once you know the shot is good you hardly need to check and have the camera show every other picture of that sequence on the LCD or the EVF.

The post Sony A7III – Switch Between EVF and LCD via Custom Button appeared first on Alexiev Arts.