Does spotlight_ctl.sh work is self-hosted mode with wifi?

[bwrsandman]

My setup is the following: I have the wyze v3 floodlight with the camera plugged into the floodlight base for power. I have a second wyze cam v3 plugged into the spare usb slot. They're both running firmware 4.36.9.139 and using wz_mini_hacks from commit 87c9223.

I've been trying to have a way to control the floodlight/spotlight without any wyze cloud connectivity with no luck.
I am not able to use spotlight_ctl.sh to control the lights and the documentation isn't clear about how to get this working, seemlingly mixed with talking about usb to ethernet connection.

After digging around in the issues and discussions, I was able to at least control the flood lights with the cloud app with the custom kernel.

# lsusb
Bus 001 Device 002: ID 05e3:0610
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 1b3f:2008
Bus 001 Device 004: ID 1a86:7523

# ls /dev/
avpu                log_main            mtd1                mtdblock1           ptyp2               ram0                ram9                ttyp3               video1
bus                 loop-control        mtd1ro              mtdblock2           ptyp3               ram1                random              ttyp4               video2
console             loop0               mtd2                mtdblock3           ptyp4               ram10               rmem                ttyp5               watchdog
cpu_dma_latency     loop1               mtd2ro              mtdblock4           ptyp5               ram11               root                ttyp6               watchdog0
dsp                 loop2               mtd3                mtdblock5           ptyp6               ram12               shm                 ttyp7               zero
framechan0          loop3               mtd3ro              mtdblock6           ptyp7               ram13               sinfo               ttyp8               zram0
framechan1          loop4               mtd4                mtdblock7           ptyp8               ram14               snd                 ttyp9               zram1
framechan2          loop5               mtd4ro              net                 ptyp9               ram15               speakerctl          ttypa
full                loop6               mtd5                network_latency     ptypa               ram2                tisp                ttypb
input               loop7               mtd5ro              network_throughput  ptypb               ram3                tty                 ttypc
ipu                 mem                 mtd6                null                ptypc               ram4                ttyS1               ttypd
isp-m0              mmcblk0             mtd6ro              ptmx                ptypd               ram5                ttyUSB0             ttype
kmem                mmcblk0p1           mtd7                pts                 ptype               ram6                ttyp0               ttypf
kmsg                mtd0                mtd7ro              ptyp0               ptypf               ram7                ttyp1               tx-isp
log                 mtd0ro              mtdblock0           ptyp1               pwm                 ram8                ttyp2               urandom

[gponick]

DISCLAIMER: This works for me. I have no idea if it'll work for you. I make no statement about it's validity, but maybe gtxaspec or someone else who has done it can chime in and let us know if I'm crazy or not!

I actually started digging into this a bunch last night. I have 2 floodlights (v1) and want them to be self-hosted. I noticed in spotlight_ctl.sh and notes.md that the author (gtxaspec?) showed how to turn on the spotlight. This isn't the same as the floodlight, though.

It took me a bit but I finally worked out how to get these hex values to pass to echo - but I haven't worked out what they mean or why they're different per spotlight at the same values.

I first did lsof | grep '/dev/ttyUSB0' - and noted the 1st column (PID) and 3rd column (File Descriptor ID) for the iCamera process.

382     /system/bin/iCamera     31      /dev/ttyUSB0
937     /system/bin/kvs_stream  31      /dev/ttyUSB0

Then I did strace -xx -s 9999 -e write -ffp <ICAMERA PID HERE> 2>&1 | grep 'write(<FILE DESCRIPTOR ID HERE>,'.

This is gonna spit out a bunch of lines where the PID doesn't match iCamera (and that's ok - it's a forked process, that's what the -ff part of the strace command does) - that look something like [pid 427] write(31, "\xaa\x55\x43\x03\x4c\x01\x91", 7) = 7

These aren't what we want. Now that you see those, though, open the Wyze app on your phone/tablet/etc - and turn on the floodlight. That'll give you something that is like [pid 427] write(31, <HEX VALUE HERE>, 10) = 10 or [pid 427] write(31, <HEX VALUE HERE>, 10 <unfinished>. Copy those hex values, and then turn the floodlight off. You'll get another , 10) or , 10 <unfinished> line and that's your off value.

Those hex values are what you need to echo -ne <hex value, inc. the quotes> /dev/ttyUSB0 to turn on/off the floodlight. That seems to work fine for me, so I'm gonna spend some time wiring this up to make sure it works and maybe wrap it in a mosquitto client for control from HomeAssistant. I wanna be clear - my two floodlights have different values. I only got it working right before bed, so I haven't dug into it more to understand why they're not the same, nor if there's a way to generate the hex values without copying from a well-known-good request from the Wyze app. That said, I was able to repeatedly turn on/off both lights, so I'm making progress.

I'll try to pay attention to replies and share any info I find as well - and if I get something solid where I understand the values so they can be modified on the fly, I'll definitely share that too!

Edit: Well - I wired up a mosquitto client (thanks @g8keeperzuul) and added some state for the floodlight and 👍 it seems to be working pretty well. Next to figure out the format so we can change between AUTO|ON|OFF and set the values for brightness. :) I'll be sure to share with others once I get that working.

[randominternetuser]

I should have posted this a while ago - sorry all. I've been using this script to control the floodlight on my wz_mini Floodlight v1 for a bit and it seems to work great (with the Floodlight set to off in wz_mini):

(the DEVICE section is because on my floodlight periodically the USB interface comes up at /dev/ttyUSB0 or /dev/ttyUSB1 (but never both))

#!/bin/sh
# This script is used to control the floodlight on the camera

# This function takes a brightness percentage as an argument and returns the command string to set the brightness of the floodlight
get_floodlight_command_string() {
        initial_total=405
        brightness_pct=$1
        brightness_hex=$(printf "%02x" $((255*brightness_pct/100)))
        #echo "brightness_hex: ${brightness_hex}"
        brightness_dec=$((255*brightness_pct/100))
        sequence_start="\xaa\x55\x43\x06\x46"
        brightness_sequence="\x${brightness_hex}\x00\x07"
        combined_sequence="${sequence_start}${brightness_sequence}"
        # add brightness_dec and initial_total and print it as a 2 byte hex value in the format \x##\x##
        check_bytes_raw=$(printf "%.4x" $((${brightness_dec} + ${initial_total})))
        #echo "check_bytes_raw: ${check_bytes_raw}"
        # get the first 2 bytes of the check_bytes_raw using awk
        first_two_chars=$(echo $check_bytes_raw | awk '{print substr($0, 1, 2)}')
        # get the last 2 bytes of the check_bytes_raw using awk
        last_two_chars=$(echo $check_bytes_raw | awk '{print substr($0, 3, 2)}')
        # combine the first and last 2 bytes into a single string
        check_bytes="\x${first_two_chars}\x${last_two_chars}"
        echo -n "${combined_sequence}${check_bytes}"
}

# if there is no argument, print help
help() {
        echo "usage: floodlight_ctl ON <% value: 1-100>"
        echo "usage: floodlight_ctl OFF"
}

# if the script is run with no args, display help
if [ $# -eq 0 ]; then
        echo "Invalid number of arguments"
        help
        exit 1
fi

# if /dev/ttyUSB0 exists and is a character device, set DEVICE to /dev/ttyUSB0
if [ -c /dev/ttyUSB0 ]; then
    DEVICE="/dev/ttyUSB0"
fi

# if /dev/ttyUSB1 exists and is a character device, set DEVICE to /dev/ttyUSB1
if [ -c /dev/ttyUSB1 ]; then
    DEVICE="/dev/ttyUSB1"
fi

# if DEVICE is not set, print an error message and exit
if [ -z ${DEVICE} ]; then
    echo "Could not find a valid device"
    exit 1
fi

# if the argument is off or 0, set the brightness to 0 and exit
if [ "$1" == "off" ] || [ "$1" == "OFF" ]; then
        echo "OFF" > /var/run/floodlight.status
        brightness_pct=0
        echo "Setting brightness to 0"
        brightness_string=$(get_floodlight_command_string 0)
        echo -ne "${brightness_string}" > ${DEVICE}
fi

# if the argument is on, set the brightness to the value
if [ "$1" == "on" ] || [ "$1" == "ON" ]; then
        if [ $# -ne 2 ]; then
                echo "Invalid number of arguments"
                help
                exit 1
        fi
        if [ $2 -lt 1 ] || [ $2 -gt 100 ]; then
                echo "Invalid brightness value"
                help
                exit 1
        fi
        brightness_pct=$2
        echo "ON" > /var/run/floodlight.status
        echo ${brightness_pct} > /var/run/floodlight.brightness
        echo "Brightness PCT is ${brightness_pct}"
        brightness_string=$(get_floodlight_command_string ${brightness_pct})
        echo "Setting brightness to ${brightness_pct}: [${brightness_string}]"
        echo -ne "${brightness_string}" > ${DEVICE}
fi

I appreciate all this work I was able to get this working no problem with the custom kernel on mine however if I put the camera in self hosted mode it looses the app configuration settings where I disabled the motion sensor... very annoying.

Tried to use strace to narrow down what turns off the motion sensor but no success..

My goal is to make this thing entirely local with Frigate and HASS having control over the light.

[gponick]

Tried to use strace to narrow down what turns off the motion sensor but no success..

My goal is to make this thing entirely local with Frigate and HASS having control over the light.

I've been poking at both periodically as well. I actually have one floodlight on another of gtxaspec's projects, thingino, and I'm also struggling with it there as well.

tl;dr: I still can't sort out how to tell the motion/light sensor in the PIR module to buzz off - even strace hasn't helped as I've tried to replicate all the data sent to /dev/ttyUSB* and that hasn't helped.

[randominternetuser]

Tried to use strace to narrow down what turns off the motion sensor but no success..

My goal is to make this thing entirely local with Frigate and HASS having control over the light.

I've been poking at both periodically as well. I actually have one floodlight on another of gtxaspec's projects, thingino, and I'm also struggling with it there as well.

tl;dr: I still can't sort out how to tell the motion/light sensor in the PIR module to buzz off - even strace hasn't helped as I've tried to replicate all the data sent to /dev/ttyUSB* and that hasn't helped.

I suspect it might be something sent during bootup or when the iCamera service connects to the cloud and pulls down settings so it might be a bit too early?

But I've replicated every command as well while changing settings in the app I really don't know what's wrong.

[gponick]

I suspect it might be something sent during bootup or when the iCamera service connects to the cloud and pulls down settings so it might be a bit too early?

I think this is the case too - so I modified the startup script to run iCamera with strace on startup and still can't quite figure it out. :) Still poking though.

[MaxMyzer]

I've been poking at both periodically as well. I actually have one floodlight on another of gtxaspec's projects, thingino, and I'm also struggling with it there as well.

I have one running thingino too. Best I could figure out for now is using the above and a simple mqtt listener to integrate it into HA. Unfortunately, my unit (even before attaching the camera) has the issue where the light doesn't turn off. From what I gather online, it seems to be some kind of hardware issue (One person said they have 4, only 1 did this, they replaced it and it worked fine.).

With this, it isn't that it won't turn off - it just won't stay off. My guess is that the PIR is extremely sensitive, or something of that nature. Enough that the camera switching the IR filter is able to wake it up. Not sure if that is the whole story, as covering the sensor didn't help much.

I want sniff around and see if there are any other serial messages that can be utilized. I believe I saw someone trying to turn the PIR off (though the script didn't work for me). I also want to check if there is a command to fetch the current data from the light.

unfortunately, it isn't exactly easy to mess with once it is mounted. I might get another, but who knows.

[randominternetuser]

So the way I finally got this one working is with physical modification I ended up disassembling the PIR sensor head. There is a sticker covering rubber plugged screws and it comes apart pretty easily.

I unplugged the PIR sensor then used the custom kernel with floodlight support to control it via a script.

Then I used Home Assistant ssh command entities to create a switch to control the light. Brightness would probably also be pretty trivial this way but I didn't need this.