Hi Kevin, thanks for the reply.
I have run the command and a password box pops up for the network manager, enter the password and it closes so must be running.
Unfortunately I get the same error messages.
Is it my Wifi adaptor that is trying to create the cloudcutterflash AP or is it the floodlight?
I have another computer I could try with built in wifi on the MOBO but I’d have to run ubuntu from a USB stick as it is my main windows computer…
edit - Wifi on my main computers mobo is not recognised by ubuntu so that’s that option out of the window… Tried the same USB wifi dongle on the main computer though and get the same error… pulling my hair out now!
Yes it is the wifi adaptor that need to run the cloudcutterflash AP. I’d get a Raspberry Pi 3 B. You can get one for $35 dollars. You can get a nice case for it for another 10 bucks. You can run it headless. I find a use for it for things like this all the time.
I concur with @kyfalcon recommendation of a dedicated Raspberry Pi for running tuyaconvert and cloudcutter apps. Having this combined with a good AC power ON/OFF switch dedicated to the effort has made my conversions much less difficult. I also fire up a WiFi monitor program somewhere other than the RPi to give me visuals on the coming and goings of the AP’s during the conversion steps.
One thing to note. On all 12 flood lights I have converted when I get to this point below in the process. It halts, I then have to go into smartlife app and try to connect the device there. I then get the light in slow blink connect mode and in the smartlife app I set the AP to connect to to the cloudcutterflash. The on my phone I connect to the Lights AP usually A-somenumber. Go back to the smartlife app and the process will finish.
Using WLAN adapter: wlan0
Configuration file: /dev/stdin
Using interface wlan0 with hwaddr b8:27:eb:94:2a:de and ssid “cloudcutterflash”
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
I found a physical switch like these, link below, to offer the best control of power cycling. Some devices are very finicky, and require the ‘right touch’.
RPI arrived. Couldnt get the cloud-cutter.sh to run using pi os lite so went for the normal desktop option. I’m wondering if these steps may have helped with my ubuntu system?
sudo nano /etc/dhcpcd.conf then add line denyinterfaces wlan0
sudo nano /etc/NetworkManager/NetworkManager.conf and make it look exactly like
With the Pi I now have floodlights with the custom firmware on! but I have an issue with one…
When I set it to connect to my IOT network which should give it a DHCP of 192.168.2.10-192.168.2.254 it actually shows as being connected to my router using 192.168.1.234 - on the wrong subnet!
I forced it into safe mode via six on/offs, rechecked everything. IP is set to 0.0.0.0 which should make it use DHCP. Second attempt. Same again.
So I set the IP to be a manual 192.168.2.100, rebooted the device. And it is connected again as 192.168.1.234!
what on earth is going on…
I am using the latest UG 1.17.366 firmware.
So my main router is a Zyxel DX3301-T0
I tried connecting to my old Sky router, the floodlight was on 192.168.1.169 via DHCP. I altered the IP to 192.168.1.100 on the config, it reconnected to the sky router as 192.168.1.100. Static and DHCP working on Sky router but not sure why the Zyxel router is giving it 192.168.1.234 all the time
Second floodlight flashed with .299 (2months old). It receives a correct 192.168.2.80 DHCP address from my Zyxel router.The remaining pair also worked fine with .299 firmware.
Need to try find out how to change the firmware version on that first one that’s playing up…
I have it currently connected on my Sky router at the moment. Internet connectivity is tested ok, I can connect to the floodlight via it’s current DHCP IP of 192.168.1.197 and change configurations however I cannot launch the web application to try and select different firmware. It just shows a blank white page. Need to try find out if there is a way to use the Pi to flash over the system. Should have known not to use a latest version…
I had the same problem. I flashed 4 lights right before Halloween and when I got them back out for Christmas 2 of the 4 were unresponsive in ESPHome. They would cycle between being pingable for a minute or so to not responding. I downladed a new image when the lights created an AP (I turned off my router so they wouldn’t automatically connect to Wifi) but got the same behavior. I put the lights away after Christmas but plan on trying again soon.
After over 2.5 months of daily use I had this issue too. This happened with 2 of my Onforu floods first, then all 4 of my Novostellas. They showed up on the Network and I could ping them, but no logs or OTA worked. They died a few days before Christmas so I just pulled and left them unplugged in my garage.
Here is how I fixed them tonight:
Comment out DDP lines
external_components section
ddp:
effects: - ddp section
Plug in Flood light and start pinging it or look for it to join network
Push non DDP ESPHome through OTA update (I use ESPHome dashboard)
Wait for light to join network, test it out
Un-Comment DDP lines
Push DDP ESPHome to flood
Test flood and DDP
Not sure why OTA worked today, maybe there is some fallback in ESPHome for situations like this that only lasts for a certain time. I did block 1 flood light from the network and did a hotspot OTA update. Still had to remove DDP.
Plan to put them back out for Valentine’s lighting, lets see if they continue to work.
The color and warm/white seem to all work pretty well. But when I got to toggle the light off there seems to be a very faint light coming from some of the elements still. I went to move the light by hand and it started to flicker different elements. Are there some pins that need to be tied to high or low or some other setting I may have missed? I didn’t see anything above or in the tear-down. Thanks.
Odd- I have not noticed this issue with my lights. However, I have had some problems with color control becoming a little erratic at times.
If helpful, here’s my current config I’m running on all of the BK lights.
esphome:
name: ${device_name}
comment: ${device_description}
friendly_name: ${friendly_name}
bk72xx:
board: generic-bk7231n-qfn32-tuya
logger:
web_server:
captive_portal:
mdns:
api:
ota:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
button:
- platform: restart
name: Restart
debug:
update_interval: 30s
text_sensor:
- platform: debug
reset_reason:
name: Reset Reason
- platform: libretiny
version:
name: LibreTiny Version
binary_sensor:
# Reports if this device is Connected or not
- platform: status
name: Status
sensor:
# Reports the WiFi signal strength
- platform: wifi_signal
name: Signal
update_interval: 60s
# Reports how long the device has been powered (in minutes)
- platform: uptime
name: Uptime
filters:
- lambda: return x / 60.0;
unit_of_measurement: minutes
output:
- platform: libretiny_pwm
id: red
pin: P6
- platform: libretiny_pwm
id: green
pin: P7
- platform: libretiny_pwm
id: blue
pin: P8
- platform: libretiny_pwm
id: cold_white
pin: P26
- platform: libretiny_pwm
id: warm_white
pin: P24
light:
- platform: rgbww
name: Light
red: red
green: green
blue: blue
cold_white: cold_white
warm_white: warm_white
cold_white_color_temperature: 6500 K
warm_white_color_temperature: 2700 K
id: thelight
color_interlock: false #Prevent white leds being on at the same time as RGB leds
restore_mode: always_off
effects:
- random:
- strobe:
- flicker:
alpha: 50% #The percentage that the last color value should affect the light. More or less the “forget-factor” of an exponential moving average. Defaults to 95%.
intensity: 50% #The intensity of the flickering, basically the maximum amplitude of the random offsets. Defaults to 1.5%.
- lambda:
name: Throb
update_interval: 1s
lambda: |-
static int state = 0;
auto call = id(thelight).turn_on();
// Transtion of 1000ms = 1s
call.set_transition_length(1000);
if (state == 0) {
call.set_brightness(1.0);
} else {
call.set_brightness(0.01);
}
call.perform();
state += 1;
if (state == 2)
state = 0;