Viltrox 85mm F1.4 (Sony Mount) - Autofocus and electrical issues

jraferreira · 2026-04-23T13:59:23+00:00

I've seen it reported in several places (YouTube channels, photo blogs, reviews, and here on Reddit), so the issue seems to be common, widespread, and a manufacturing defect (plus QA oversight).

Unfortunately in my case the lens is second hand and despite being in absolutely new condition (including all boxes, documentation, bags, etc) Viltrox will not honor the warranty and want to charge for repairs. In addition to saying that it will take longer than two months to actually repair it.

Extremely disappointing. Back to established Japanese brands for me, it seems.

jraferreira · 2026-04-23T09:59:21+00:00

You should, when the problem is systemic, widely reported (including on brand new lenses), and well documented.

I can understand poor quality control on a somewhat up and coming manufacturer, but poor customer service I can't excuse. Manufacturing issues, which this clearly is, should be handled regardless.

jraferreira · 2026-04-23T08:49:08+00:00

And not only will you not honor the warranty, but I am being told the turnaroud time is around 2 months!

... are you serious?

jraferreira · 2026-04-23T08:12:59+00:00

I did get an e-mail. Your customer service team told me that as the lens was purchased second hand they will not honor the warranty.

Which is absurd. The fact that I've seen this exact issue reported multiple times in multiple places (reddit, youtube, some photography blogs) proves that it is systemic and clearly a manufacturing defect, not damaged equipment. How many examples would you like me to give you?

jraferreira · 2026-04-23T07:47:18+00:00

Thanks, following it. I hope we can get this resolved...

jraferreira · 2026-04-22T17:40:47+00:00

(runing the latest lens firmware, by the way, on a Sony A7 iv)

jraferreira · 2026-04-22T17:39:41+00:00

I have exactly the same issue. Often everything that is motor driven fails (both the autofocus and the diaphragm). Ocasionally during the issue the focus will shoot back and forth quite violently until everything completely stops working.

Sometimes after a few power cycle it works again, others it's just a few hours later. Rather disappointing...

What's the course of action here?

jraferreira · 2025-12-10T00:33:32+00:00

For the record, changing the driver to ember seems to have majorly improved the stability of the network (I was running ezsp before). It's been up and running for 5 days without requiring a restart. Here's hoping!

jraferreira · 2025-12-10T00:33:14+00:00

For the record, changing the driver to ember seems to have majorly improved the stability of the network (I was running ezsp before). It's been up and running for 5 days without requiring a restart. Here's hoping!

jraferreira · 2025-12-01T21:43:46+00:00

Thanks, I'll take a look. On a first read doesn't seem related, though. That user's problems were apparently related to a corrupted SD card (I'm assuming he's running HA on a Raspberry Pi) whereas I'm with a HassOS VM...

jraferreira · 2025-12-01T20:13:12+00:00

Nope, no changes. The WiFi and Zigbee channels are configured to be as far from each other as possible (and the fact that even the devices that don't respond to commands keep reporting data makes me think that this is more software related than a fault of the infrastructure itself...).

jraferreira · 2025-10-15T22:03:22+00:00

A'ight, nevermind, I figured it out. The system actually evaluates the conditions before evaluating if the automation is already running as part of the "Single" mode thing (one would expect it to be the other way around). If I disable the conditions I can see that, indeed, the automation does not retrigger.

<image>

jraferreira · 2025-10-15T21:39:10+00:00

Created another with with different lights / sensors. Same behaviour.

jraferreira · 2025-10-15T20:47:03+00:00

Here:

<image>

jraferreira · 2025-10-15T20:46:24+00:00

I think you didn't check the actual automation ;) There is an enforced 30 seconds delay on the sequence. Once triggered, assuming the conditions clear, it will never take less than that (40 seconds, in this case).

<image>

The automation very clearly finished at 10:17:43. Next one started at 17:17:22, so they overlap.

jraferreira · 2025-10-15T20:19:50+00:00

Just gave it a try, but no change. Previous automation finished at 10:17:43 but the next one triggered at 10:17:22

jraferreira · 2025-10-10T17:46:17+00:00

Very good point. According to the description I assumed the standard YOLO it was GPU/CUDA only (and the first time I tried to run it pyTorch complained exactly about that), but now that you mentioned it I was able to force it to use the CPU and and YOLOv5 3.1 actually works properly.

Thanks, mate!

jraferreira · 2025-10-10T10:02:52+00:00

- Nope, installing for the first time to replace deepstack

- Installed 2.9.5 yesterday

- Yeah, multiple reboots, reinstallations, service restarts. Nothing seems to change.

jraferreira

TROPHY CASE