Hi ScrewLoose, sorry it took me so long to respond.
Yes my issue is that the light does not seem to get updated time from the esphome after a power failure correctly. I have 2 Plant 3.0 59W lights that behave like this.
I have been testing this by connecting to the light with esphome, and then unplugging the light and plugging it back in to simulate a power loss. I can see that the esphome reconnects to the light but the light still stays in its midnight programed state of all channels off.
Reconnecting with my phone and the fluval app correctly updates the time.
Thanks. I am seeing the same behavior with the Plant Nano.
Wish I understood more about the Bluetooth packet capturing. I would offer to help, but I’m afraid my learning curve would be too steep to offer much assistance. But, I’ll certainly test a new release when you have something ready.
Ok, I think I got the issue fixed (already merged into the regular fluval_ble_led branch, so no need to use the plant3 branch anymore).
So the issue had nothing to do with the Plant lights being different, but unfortunately I was careless when refactoring the code. At some point I’ve put the checksum generation into the send_packet method, so I do not have to calculate checksums individually all the time. I removed individual checksum generation for all methods but for the sync_time. So time sync had two checksums attached, which broke the packet and thus the function - not only for the plant lights but for all lights. I guess it was just by chance, that it showed up for the plant light first, and then only for those, as those were the only ones under test.
I fixed the issue with the latest commit to the fluval_ble_led branch, and I will have a close look at the source to see if I correctly removed all the checksums from individual packets asap.
So having read/grazed over all the progress, what would you say is the minimum parts needed to get this working is it simply a ESP32 & some form of BLE device?
This component is designed to work with “smart” Fluval fish tank lights which usually are controlled by smart phones. And yes, all you need is an ESP32 and such Fluval lights. The additional hardware shown in some pictures is actually a more complex project I started to monitor fish tank temperature to either switch on cooling - to keep fish safe in summer - as well as switch off heating with a Shelly plug - to keep fish safe from malfunctioning heaters. This Fluval component was an “addon” to this project, because why not control the light and fix the time sync issue on power loss while at it
We’ve already got 10 of the fluval lights haha mixture of plant/sky/marines so be interested to get them working with HA.
But makes a lot of sense to trying and build an all in one for each tank, I’ve currently in the process of setting up Sonoff TH devices for each tank for monitoring temps and sending out alarms if they encroach on thresholds I’ve set.
Well done on all the hard work getting it this far though is amazing and will roll it out to a ESP32 soon
Just moved to a different ESP32 board, and the new code is working perfectly. I’ve had 2 power flickers in the past week, and within 5 minutes, both of my lights restored correctly with HA time.
Thanks a lot - the component is running here with the lights as well, with no issues anymore - so thanks for you as well for testing and bringing the issues up! In my “day job” it’s called QA and a well paid job too
I will still keep on checking on this thread if anything else comes up. The “PR” to include this component into ESPHome was completely ignored though, so I will keep it in my own repository for now, and maybe try again later when the guys from ESPHome have a little bit more time
Meanwhile I might have a look at creating a component for HA itself as was suggested earlier, using the BLE proxy stuff. But no deadline on that yet…
Isn’t it possible to port this to work as a BLE integration in home assistant instead of making users buy a separate board for control? Many of us already have bluetooth hardware (I run HA on a Raspberry Pi 4 which has BLE chip inside) and there have been at least several months since Home Assistant has allowed BLE to work natively, for example with door locks and more. So it is actually a massive waste to have to buy a ESP board just to make this light work, when all the protocol has already been figured out and turning this into a BLE integration would allow communication with the light straight from Home Assistant not to mention save power because you don’t have to leave a board plugged in just to control light. Also saves money as you don’t have to buy a board, USB cable and power brick just for this task. If I knew how to create an integration I definitely would do it since the work is already mostly done. Does not have to be a native HA integration, it can be “unofficial” on the HACS store.
Yeah, it should be pretty much possible to use the BLE integration in home assistant for that. Most likely purely based on the information published in this thread, or from the source code in my git repo.
I decided to implement it on ESPHome first, because it best suited my needs. My Raspi 4 has BLE as well of course, but none of my fish tanks were in range, and I planned to put ESPHome next to my fish tanks anyway for temperature monitoring, climate control and “emergency stuff” (like cutting power to a misbehaving heater in a tank). So this component was an addon to my fish tank controller, not additional hardware.
Range was a factor as well, as with my tests, I could only reach devices within the same room as my Raspi, but well, my Raspi sits in a 19" server rack using external antennas for most stuff but onboard bluetooth, and my walls are thick brick and mortar walls.
With the introduction of BLE Proxying over ESPHome, at least my range problem was fixed - so it became possible to at least think about a native HA integration.
Last factor was time - I had to reverse engineer (“crack”) the protocol as well as what Fluval calls an encryption and then implement it in two coding languages (c++ and python) I did not use before. Having a 20+ years knowledge of coding helped to get into that though. I wanted to get the ESPHome integration stable and working for my own project as well as the good people supporting me in this topic by testing and finding bugs.
Next step will be a native HA integration though, most likely put into HACS as pushing it as an official component seems to be difficult at the moment due to time constraints on HA side. This requires far more knowledge in python though than ESPHome did, and I am currently working on obtaining that knowledge and doing research on how BLE works natively in HA as well as with the proxy. I can’t give a deadline though, as I do not want to put pressure on myself, due to my daytime job doing that already currently. So there will be an integration, either by me in due time or by someone else picking up on my research / code repo - it’s open source for a reason after all
best regards
mrzottel
PS: @anon78847916 Do you own such a Fluval light and would be willing to test it with a native integration?
Thanks for your awesome response, really sounds like you care
Because I do not have any coding skills, I am absolutely up for testing it! My raspberry pi sits in a cupboard in the center of the house, which just happens to be where my fish tank is. I only have one large one. So I only have one light, and can’t cover all use cases, but I guess we start from the basics right? Multiple lights should work just the same, probably.
Whenever you manage to put something together for testing, count me in, I’ll work with you to refine it.
Holidays will start tomorrow - free time to have a deep look into hacs, integrations and how to set everything up =)
Hope to get something to test until end of this year =)
Edit:
So I start a kind of “milestones” tracking again:
Prepare ESPHome Bluetooth Proxy to get in range of the fish tank. (easier than to move the tank or the server rack, should make no difference to the component if using proxy or bluetooth stick on the HA host) - Done: My HA instance is tracking the fluval ble light successfully.
Prepare dev environment (vscode, dev containers, etc.)
Prepare github repository → mrzottel/fluvalble: Home Assistant component for remote control of Fluval BLE fish tank lights (github.com)
Check how to get the custom component into HA without HACS first (faster dev cycle)
Create template “bluetooth-ish” component (check other ble components for hints)
Code (Encryption, BLE communication, Sensors/Buttons etc, Cherry on top: Configuration workflow with UI)
Integrate into HACS
Edit 22.12.2023:
Just a short update - I’m still at it, but I have gained a huge respect by the “development ecosystem” Home Assistant offers - and currently I fear I would break stuff by just “coding away” - so I am deeply into learning Pyhton right now. I don’t want to risk breaking peoples home automation in any case, so I need to understand more of what is going on. But - still at it
Adding my name to list of testers when we’ve got something to play with
For now I’m going to create the ESPHome integration based one you’ve already done, but I’ve starred and followed activity notifications on this new repo ready for giving it a shot the moment you need folk to.
I’ve an “Aquasky 530mm” and am rather looking forward to passing full control of it to HA seeing as I find I can’t trust it to keep itself on routine, especially if brief power outages have disturbed things!
@mrzottel , with regards to the handshake, do you know if you need to do this after a power reset on the light. Im writing some code on an ESP32 outside of ESPhome. I can turn the light on and off by sending the correct byte streams, but this only seems to work after i’ve connected the app at least once (im not programatically doing the handshake yet). Im assuming the phone app does the handshake and puts the light in a mode that allows it to be talked to by my code.
If this is the case, do you have examples of how to send the final bit of the data , the “syncDeviceTime”.
When you say “App writes 0x0F to service 1000”, is that only 0x0F, or the 0x54, 0x51 header and 0x0F
Thanks for any guidance you can give
EDIT: I see you have done a c++ implementation. Would be interested to see this if possible as that’s what im doing on the esp32.
The handshake implementation is a bit weired, so if you have questions about that, just PM me. I’m not really sure if this handshake is required - I captured it when the app contacted the LED, so I just replicated it. As far as I can remember, it was not encrypted, so no header - but it was sent to a different “service endpoint” than the later communication.
is amazing and will roll it out to a ESP32 soon 
