I have three lights that haven’t disconnected at any time, all running on 2021.10.3 or dev.
The only difference with my dev lamp, is that you have actively disabled mDNS. Shouldn’t make a difference, but to rule out interoperability issues, maybe enable mDNS for a while.
I’ll setup one lamp with mDNS disabled for testing.
1 Like
Hello,
I have a bslamp2 and I want to integrate with HA.
Which hardware I need to flash the new firmware?
Kind regards.
The whole hardware side of the flashing procedure is described in the documentation on GitHub. It also lists the hardware / tools required. For your convenience:
- Allen key (2mm, 5/64") or torx (T8) screw driver
- Soldering Iron
- A serial to USB adapter (for example FTDI) that can provide 3.3V RX/TX signals
- Some wires
- Optional: sticky tape, hot glue gun, magnifying glass
Thanks mmakaay!
I have a USB To TTL device, this will work?
I installed ESPHome in a docker container I can access to the web interface, how could I compile the firmware for my device?
I create new configuration and put the name and wireless name/pass:
But which device must I select in the next page:
Sorry, but I am new with ESPHome.
I will appreciate your help.
Kind regards.
Simply go with ESP32. This is used to generate a basic configuration for you. What you can do after this, is take the example.yaml from my repository and use that as the new starting point. In other words: you can use random data for all fields when creating a new device, since you will overwrite the resulting YAML config file anyway.
And a USB to TTL device sounds fine to me.
Hello,
I create a firmware with this configuration:
Solder the pins and upload the firmware:
But now the lamp doesn’t work, if I put the logs viewer I get this message repeteating every time:
Did I make a mistake? I try to do it again but same problem.
I will really appreciate your help.
Best regards.
I got it!
I change the configuration to this:
packages:
bslamp2:
url: https://github.com/mmakaay/esphome-xiaomi_bslamp2
ref: dev
files:
- packages/core.yaml
- packages/behavior_default.yaml
- packages/ota_feedback.yaml
- packages/activate_preset_svc.yaml
refresh: 0s
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
password: "XXX"
wifi:
ssid: "XXX"
password: "XXX"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Bslamp2 Fallback Hotspot"
password: "XXXX"
And now it connect to the wifi and the lamp work.
I have a little problem with my SSID name, it has a “ñ” character, and the device can not connect, is it possible to fix it?
Now I will connect to the HA!
Kind regards.
Yes, including the new core configuration package makes sure that the correct build is done for the single core ESP32 CPU in this lamp. So that fixed the error for you.
One possible cause that I can think of, is that there is a difference in charset between ESPHome/config and the access point. If one does UTF-8 and the other ISO-8859-something, then the name of the access point would not match.
What you could check, is what happens when you connect the ESPHome logger to the lamp. It will dump all kinds of configuration information at the beginning, amongst which there are also the SSID’s of the detected WiFi access points. It would be nice to see how your access point gets reported there.
If there’s a problem with SSID’s that use special characters, then please consider creating an issue ticket in the ESPHome issue tracker. That is not something that would be solely related to the firmware for this lamp.
Thanks again for your help.
I try to change the ssid of the lamp remotely and it doesn’t connect, actually I have no serial adapter, I will try it in the weekend.
But I try to connect to the fallback hotspot, I can connect and can reach by ping to the lamp (192.168.4.1). But there is no web interface in http://192.168.4.1.
Is this normal? Need I configure something else to get web interface?
Kind regards.
To get a web interface, including web_server: in the configuration would be required.
However, because the ESP-IDF framework has only recently been included in ESPHome, not all components have been converted to work with ESP-IDF yet. Unfortunately, the web_server component is one of those.
Conclusion: for now, the web server is not an option. Not seeing the web interface is not an issue, and even normal for that reason. Home Assistant uses the ESPHome API, which follows a different route.
Thanks!
OK, but is it possible to connect to the failover network and change the ssid manually? I try ssh and telnet to 192.168.4.1 but it doesn’t respond.
I want to avoid to open the lamp again.
Regards.
Hello,
I find which is the problem, the new SSID has WPA2-PSK/WPA3-SAE mixed mode encryption, and the bedlamp can not connect.
I change to WPA2-PSK encryption and now it works.
This is related to the bedlamp firmware or is ESPHome issue?
Thanks for your help.
Best regards.
The firmware fully depends on ESPHome for WiFi support, so that would be an ESPHome issue.
Hi,
Yesterday I tried to update to new version of ESPHome but unfortunatly I could not because following error:
I haven’t changed anything from previous working configuration.
As per logs I am not sure if the root cause is new version but I am unable to compile using previous one so…
Any idea what’s happening?
Thank you,
That doesn’t look like any compile issue that I have seen before.
I just upgraded ESPHome and recompiled my previous build and that worked without issues.
Maybe a clean build helps?
Might have found the cause of my lamp losing WiFi.
At about the same time as this started, I set up the sunrise effect wake-up light blueprint. Thinking this could be related, I disabled the automation and it didn’t disconnect from WiFi for a few weeks. Enabled the automation and it disconnected within a week.
@mmakaay if you have a moment, can you look over the blueprint below and see if you can find anything that would cause this issue?
Thanks!
That thing is too massive to look over it and decide if somethings causing issues.
Also, I’m wondering how it could be related to WiFi.
A single disconnect within a week also doesn’t feel like an extensive data set. It could easily be that it is not related to the blueprint.
It’s disconnected several times, at least three, with the automation enabled and zero with it disabled. Bad thing is it takes several days before it disconnects, so it’s difficult to troubleshoot.
Yes, it’s a complicated blueprint. I’ll try to look it over and figure out how it works. My guess is it’s either issuing a command the lamp doesn’t like or it’s issuing commands too quickly.
Thanks for taking a look at it.
Well, the most logical reason would be that the automation takes too much time/resources, interfering with the operation of WiFi. That would mean the automation ought to be improved.
BTW, one factor that might apply here, is that this device has a single core ESP32, meaning that the networking stack will not be running on its own thread on the second core. Because of that, this device might be more sensitive for code that is blocking the main thread (only assuming that this is the case here as a hypothesis).