Open skilau opened 2 years ago
@skilau thats interesting. Does the floodlight have an additional USB port? Are you using an external USB hub? usb to ethernet?
@gtxaspec, yes, it has an extra USB port on the outside. You apparently can use it to add another V3 cam if you want. I don't use it though, or have anything plugged into it.
I saved this camera to install wz_mini_hacks on last, because it doesn't have any really good way to install a USB Ethernet adapter on it, while still looking reasonable. So I am using this one as Wifi only.
I am using your current master branch, nothing special configured yet. I tried enabling and disabling REMOTE_SPOTLIGHT, didn't seem to matter.
Below is the full dmesg dump: `
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.10.14isvp_swan_1.0 (t31@mips-development) (gcc version 4.7.2 (Ingenic r2.3.3 2016.12) ) #56 PREEMPT Fri Jul 8 18:22:25 PDT 2022
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 RESET ERROR PC:801D02C4
[ 0.000000] [<801d02c4>] delay+0x4/0x10
[ 0.000000] CPU0 revision is: 00d00100 (Ingenic Xburst)
[ 0.000000] FPU revision is: 00b70000
[ 0.000000] cgu_get_rate, parent = 1392000000, rate = 0, m = 0, n = 0, reg val = 0x081000ff
[ 0.000000] cgu_get_rate, parent = 1392000000, rate = 0, m = 0, n = 0, reg val = 0x081000ff
[ 0.000000] CCLK:1392MHz L2CLK:696Mhz H0CLK:200MHz H2CLK:200Mhz PCLK:100Mhz
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 004f8000 @ 00010000 (usable)
[ 0.000000] memory: 00078000 @ 00508000 (usable after init)
[ 0.000000] User-defined physical RAM map:
[ 0.000000] memory: 06300000 @ 00000000 (usable)
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x00000000-0x062fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00000000-0x062fffff]
[ 0.000000] On node 0 totalpages: 25344
[ 0.000000] free_area_init_node: node 0, pgdat 80505680, node_mem_map 81000000
[ 0.000000] Normal zone: 198 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 25344 pages, LIFO batch:7
[ 0.000000] Primary instruction cache 32kB, 8-way, VIPT, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 8-way, VIPT, no aliases, linesize 32 bytes
[ 0.000000] pls check processor_id[0x00d00100],sc_jz not support!
[ 0.000000] MIPS secondary cache 128kB, 8-way, linesize 32 bytes.
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 25146
[ 0.000000] Kernel command line: console=ttyS1,115200n8 mem=99M@0x0 rmem=29M@0x6300000 rdinit=/init mtdparts=jz_sfc:256K(boot),1984K(kernel),3904K(rootfs),3904K(app),1984K(kback),3904K(aback),384K(cfg),64K(para)
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 93148k/101376k available (4106k kernel code, 8228k reserved, 980k data, 480k init, 0k highmem)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:358
[ 0.000000] clockevents_config_and_register success.
[ 0.000014] Calibrating delay loop... 1391.00 BogoMIPS (lpj=6955008)
[ 0.087830] pid_max: default: 32768 minimum: 301
[ 0.092688] Mount-cache hash table entries: 512
[ 0.097609] Initializing cgroup subsys debug
[ 0.101865] Initializing cgroup subsys freezer
[ 0.107312] devtmpfs: initialized
[ 0.111484] regulator-dummy: no parameters
[ 0.115762] NET: Registered protocol family 16
[ 0.130498] bio: create slab
@skilau Looks like there is an internal USB hub, so SPOTLIGHT SERIAL IC -> USB-to-SERIAL IC -> USB HUB -> CAMERA
unfortunately for us, the DWC2 (usb2 driver) is really old and buggy, so it doesn't support the SPLIT
USB High Speed transfer mode, used sometimes when you have a hub. We may be able to have it work by forcing the usb2 interface to full-speed, dthe down side is you will be limited to 12mbps, usb1.1 speeds ... I can post a kernel for you if you want to try.
The actual solution would be to backport a newer dwc2 driver from a newer kernel to ours. This may or may not work, i'm fairly certain the implementation is jz (ingenic)
specific.
@gtxaspec Is the USB 1.1 speed just the connection to the Floodlight only? Or is it also the Cam -> Wifi also?
If it is just the Floodlight, 1.1 speed shouldn't really matter much, as there isn't much data going between them anyway. But if the 1.1 also would affect the Cam -> Wifi connection, yeah, that would not be good...
I can definitely give the new kernel a try, if it isn't too much of a hassle, at least we would know for sure if that fixes the problem or not.
Thanks!
@skilau It will be all USB devices to the camera, we have to force the camera's USB 2.0 host controller to 1.1 speed.
The wifi runs off the SDIO bus, so it's unaffected.
kernel attached, rename it to the factory name.
@gtxaspec Thanks!
I am now running with the new kernel, the dmesg logs look a whole lot cleaner, and indeed, the Floodlight is now seen properly. After running some quick tests turning it on and off, it looks good.
So that was definitely the issue and fix, thank you!
Of course, I am not sure of the way to ultimately resolve this, as most people would probably want High Speed USB.
thanks for the feedback. I will look into the newer dwc2 drivers, and test to see if they compile on our kernel.
@skilau can you share some logs? trying to figure out how the camera feeds audio to the floodlight speaker... lsusb if you can
@gtxaspec Sure! Sorry I missed this request earlier!
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
@skilau is this with no devices plugged into the camera?
can you also do logread | grep sound
@gtxaspec : Correct. I just have the Floodlight with the Cam only. No other devices plugged into the external USB port.
`
May 13 15:22:37 audiocardprocess: [soundcard_watchdog_init] ok TimerId:0 May 13 15:22:42 iCamera: soundcard_module_init Successfully May 13 15:22:45 audiocardprocess: [watchdog]dbg: soundcard_watchdog_snd_msg_feed [time:1652473365] May 13 15:22:46 iCamera: sound card feed watchdog success(feedWatchdogCount is 1) Jul 11 22:04:13 iCamera: automode:12 envDark:1 montionDark:2 soundDark:2 pir1 masterB:0 Jul 11 22:04:13 iCamera: {"mac":"77DD1D0E","softver":"1.0.0.55","realSwitch":"2","brightness":"255","mode":"3","PIR":"1","envDark":"1","montionDark":"2","soundDark":"2","durations":"15","PIRSensitivity":"255","PIRSilentTime":"1","PIRChoose":"224","ala Jul 11 22:04:23 audiocardprocess: [watchdog]dbg: soundcard_watchdog_snd_msg_feed [time:1657595063] Jul 11 22:04:23 iCamera: sound card feed watchdog success(feedWatchdogCount is 2) `
@skilau interesting. We had an issue with the kernel and the new version of libcallback, iCamera was breaking sound because we were using the same pcm device for one of the alsa_loopback devices which was assigned to a "soundcard".
The ingenic device's use a custom OSS sound implementation, so there should be no concept of a soundcard in these devices...
Originally we thought to disable the whole soundcard_module_init function, which was a temporary solution, since the function is pretty big. Now we know why, the camera's support an external usb sound card, which the floodlight uses internally.
thanks for the info!
@gtxaspec Ah, I hadn't considered that. Now I had to go look up that USB id: "Generalplus Technology USB Audio Device"
I suppose that might make sense. I think the Audio is better on this compared to the regular Camera. And the Alarm on it is VERY loud. It is meant to scare people off, and it sure would once they hear it! :)
you should try piping an mp3 radio station to it using cmd aplay...i wonder what speaker it will play from? lol
Ha, that is an interesting idea! PS: You should have heard it when I first set it up on Wyze! It screamed "READY TO CONNECT", and I swear the whole neighborhood could hear it!
@skilau need some more logs when you get a chance:
--nevermind, still testing stuff--
I see how this works on the stock kernel, all usb devices are limited to full-speed (12mbps) by default. This is how they have it working.
@skilau just to test, does the floodlight's speaker work when you talk through the app? or use the siren?
@gtxaspec : I had honestly never triggered the alarm before, so I just tried it now! It does work, it does like a pretty loud Beep-Beep-Beep noise, and flashes the LED floodlights off and on.
dmesg shows: [82886.015402] SPEAKER CTL MODE3 ! [82888.196972] SPEAKER CTL MODE0 ! When I trigger the alarm (and turn it off)
@skilau voice too?
edit - i think it shouldn't, because we don't include sound card drivers in the kernel at the moment. I can't get it working with my USB sound card with our kernel, even with the right drivers, only with the stock kernel. If you can confirm that using the speak
function in the app is working, with the audio coming out of the big speaker on the floodlight, that would just cause more confusion lol
I have ordered one but shipping is slow
@gtxaspec : Interestingly enough, it does! I hadn't tried it before, (I usually keep voice/speak off), but after turning it on, and speaking through my phone, I can hear it through the speakers on the Floodlight. Also went in into the recordings, and did a play back. My test speaking was recorded as well.
@skilau really interesting. Can't wait to get mine to take it apart. I really have no use for the floodlight, but in pieces I do lol
got my floodlight. It appears the serial adapter is a full-speed device, and the soundcard is a high-speed device, which is why audio works, but the floodlight control does not, unless we force the camera to full-speed.
the solution I think is to patch the dwc2 driver, if there a low speed device somewhere on the bus detected, we must force the host controller to full-speed. if the device is removed, switch it back to full speed.
Ah, thanks for the info! I hadn't dug in deep enough to figure that out! Hopefully that patch isn't too difficult.
no go so far. We are able to compile dwc2 as module, but it doesn't recognize the controller when you try to load it.
Thanks for the status update.
Just wondering if there is any update? Got Floodlight and under 4.36.9.139 and latest wz_mini it is not working ...
@skilau It will be all USB devices to the camera, we have to force the camera's USB 2.0 host controller to 1.1 speed.
The wifi runs off the SDIO bus, so it's unaffected.
kernel attached, rename it to the factory name.
Insanely stupid question, but what file in the directory am I replacing with this? Would love ot test out to see if this works. @skilau too, as it seems like you have it working?
@skilau Can you confirm how you got the kernel updated with the file @gtxaspec attached? I am having the same issue. The slower USB speed with the patched kernel isn't a big deal as I just need to be able to turn the light on and off.
You should be able to extract the bin from kernel-t31.bin.gz, then replace the 'factory_t31_ZMC6tiIDQN' on the root of the SD card with it.
we have to force the camera's USB 2.0 host controller to 1.1 speed
Is this something that can be added as config variable?
Weirdly I had access to flood light / PIR via WZ (not in wyze app) but it's no longer showing. Unsure what changed.
can confirm that with the attached kernel binary in this thread that the flood light works via the app now. I would like to investigate being able to command the light in the future.
@gtxaspec I also have the same issue with the floodlight. Is there any way you can include this fix in the official release? Thanks a lot.
@gtxaspec Just wanted to chime in and say I would also benefit from floodlight support. I put one up this weekend with plans for another soon.
Any updates on this using the newer firmware?
I have installed the kernel from the above post and the floodlight turns on in the app, but turns off as soon as I navigate away. This is on firmware 4.36.8.15 and floodlight fw 1.0.0.52.
Am I missing something about how to get this working? Or can I help troubleshoot the kernel?
See the gist logfile below with the turn on and navigate away events annotated: https://gist.github.com/loopy321/b115a510421e48eb63fa180c206b0fb5
Thanks.
I have installed the kernel from the above post on a and the floodlight turns on in the app, but turns off as soon as I navigate away. This is on firmware 4.36.8.15 and floodlight fw 1.0.0.52.
It is possible that it works fine, but the light sensor was keeping it off. I'll test more and update.
Looks like the kernel posted above is working here. I copied over to the root and still have access to flood light in the app.
I will report back if I have any issues. Thanks for the awesome project.
I have installed the kernel from the above post on a and the floodlight turns on in the app, but turns off as soon as I navigate away. This is on firmware 4.36.8.15 and floodlight fw 1.0.0.52.
It is possible that it works fine, but the light sensor was keeping it off. I'll test more and update.
Got it working perfect now! Thanks for the excellent work here!!
@skilau It will be all USB devices to the camera, we have to force the camera's USB 2.0 host controller to 1.1 speed.
The wifi runs off the SDIO bus, so it's unaffected.
kernel attached, rename it to the factory name.
I tried this kernel and though it worked, the camera was extremely slow. The go2rtc web interface took upwards of 15 seconds to load each page, and the official wyze app would show 1 or 2 frames before buffering for 30 seconds and repeating. This is the only issue preventing me from using the camera as I intended.
Can I help out by trying something else?
Anyone able to update the firmware on the PIR sensor? The PIR randomly turns the lights on without motion even when settings are all of minimum. I'm at 1.0.0.52 and have tried to update to 1.0.0.55 several times and it always fails.
@skilau It will be all USB devices to the camera, we have to force the camera's USB 2.0 host controller to 1.1 speed. The wifi runs off the SDIO bus, so it's unaffected. kernel attached, rename it to the factory name. kernel-t31.bin.gz
I tried this kernel and though it worked, the camera was extremely slow. The go2rtc web interface took upwards of 15 seconds to load each page, and the official wyze app would show 1 or 2 frames before buffering for 30 seconds and repeating. This is the only issue preventing me from using the camera as I intended.
Can I help out by trying something else?
My camera works very well with this firmware and is not slow at all. Do you maybe have a wifi issue?
You have to reduce the sensitivity of the PIR sensor by A LOT. Mine is set at 13%
On Wed, 8 Nov 2023 at 18:20, loopy321 @.***> wrote:
Anyone able to update the firmware on the PIR sensor? The PIR randomly turns the lights on without motion even when settings are all of minimum. I'm at 1.0.0.52 and have tried to update to 1.0.0.55 several times and it always fails.
— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/172#issuecomment-1802884051, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARZVGAPHB3YDIWTDDPJW23LYDQHSJAVCNFSM53FZ45Z2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQGI4DQNBQGUYQ . You are receiving this because you commented.Message ID: @.***>
You have to reduce the sensitivity of the PIR sensor by A LOT. Mine is set at 13%
I have mine at 1% and it still triggers on nothing. If yours is working well, can you please tell me the firmware version of the Floodlight and your Camera?
I wrote a little python app/docker container that exposes control of the floodlight over MQTT and utilizes https://github.com/SecKatie/ha-wyzeapi and fully disabled the PIR because it was so flaky. I now handle floodlight on/off with either frigate/camera detection or other door sensors/automations. I do keep an eye on this issue to see if I can easily move it to local control using hooks in the wz_mini_hacks firmware instead but haven't attempted to make that switch yet. Or if something related to the referenced kernel becomes more "official"
I am running the kernel above with no issues.
I did have issues with the camera stability and restarting (even on stock firmware) when it did not have a solid wifi signal, so I would look into improving the wifi signal if it is anything less than ideal and you are having issues.
here it is if anyone is interested, I am very happy with it vs stock, no support provided 😆 https://github.com/xconverge/wyze-python
thanks for the work here!
uploaded modified kernel to two floodlights. it works! but its definitely slower. any updates on potential improvements?
Hi @gtxaspec,
I'm working on adding USB to wyrecam and running into this same issue. What changes did you make to the kernel to force the camera's USB 2.0 host controller to 1.1 speed?
Thanks!
Answering my own question for posterity.
In my case br-ext-chip-ingenic/board/t31/kernel/t31.wyzec3.config needed this line added CONFIG_USB_DWC2_FULLSPEED_HOST=y
I also needed CONFIG_USB_ACM=m in the same file to compile cdc-acm.ko.
I finally got around to putting wz_mini_hacks on my Wyze FloodLight.
Once I did this, wz_mini_hacks loads just fine, but the Floodlight Controls in the Wyze app (Android) no longer is shown. It appears that Wyze doesn't believe the Floodlight is available anymore.
This is alluded to by a couple posts in this discussion: https://github.com/gtxaspec/wz_mini_hacks/discussions/91
Checking dmesg, I see a couple interesting things:
[ 0.986061] usb 1-1: device v05e3 p0610 is not supported [ 0.992020] hub 1-1:1.0: USB hub found [ 0.996220] hub 1-1:1.0: 4 ports detected [ 1.275015] usb 1-1.1: new full-speed USB device number 3 using dwc2 [ 1.281578] dwc2 dwc2: Sorry, SPLIT transfer is not supported! [ 1.287621] dwc2 dwc2: Sorry, SPLIT transfer is not supported! [ 1.293643] dwc2 dwc2: Sorry, SPLIT transfer is not supported! [ 1.375003] usb 1-1.1: device descriptor read/64, error -12
And:
[ 5.315028] usb 1-1.2: device not accepting address 10, error -12 [ 5.333537] hub 1-1:1.0: unable to enumerate USB device on port 2
Any thoughts?
PS: My floodlight is on my deck, so I have reasonable access to it if needed.