Tasmota replacement for BL602, programming, pairing with Home Assistant, now with OTA working!

p.kaczmarek2 wrote:

This update should save bl602 raw channel states in flash
https://github.com/openshwprojects/OpenBK7231...mmit/69e2ac21c4c9ff69f2850d8f1713eaa94cba0787
this is not yet implemented for new led driver, if you want to save "led_basecolor" in flash then you will have to wait

OK, I will test it.

p.kaczmarek2 wrote:

droege wrote:

What I see is, that you are NOT reporting RGB as Color in any way, when changing only the dimmer value.
Same goes the other way around: if changing the RGB via color you report only RGB but not a change in dimmer, but this is maybe also changed due to differences in RGB settings.

This is what I assumed, I only broadcast changed values. Do you think that a change in dimmer should also broadcast RGB?
My assumption is:
1. home assistant sends rgb
2. home assistants sends dimmer
3. on my side, i do rgb * dimmer and set PWMs
but I am starting to think that it might not be a correct approach

Well, other systems also send dimmer/rgb seperately. BUT: in the FHEM system, for instance, the icon is calculated based on RGB/color-feedback, and also controls (color-scale) is updated, when color-feedback is received. And this doesn not happen at the moment, when changing only the dimmer. BTW: tasmota also updates color-feedback when only the dimmer is changed.
The internal processing (step 3) I think is perfectly fine. "Just" broadcast beside the changed value also the final RGB.

p.kaczmarek2 wrote:

droege wrote:

BTW, another question:
I've noticed, that you ar not reporting anymore via 'device/channel/get'. Is this by intention? Or is only the "old" led_driver doing this?

Clever one! yes, i disabled it because otherwise RGBCW bulb was doing about 8 publishes and was crashing MQTT with overflow. It is only disabled when channels are changed by LED driver.

Ok, understood. I will test it.
But this means, that at startup these things are reported in anyway instead of color/dimmer, etc., right?
Thanks,
best.

Added after 28 [minutes]:

droege wrote:

p.kaczmarek2 wrote:

This update should save bl602 raw channel states in flash
https://github.com/openshwprojects/OpenBK7231...mmit/69e2ac21c4c9ff69f2850d8f1713eaa94cba0787
this is not yet implemented for new led driver, if you want to save "led_basecolor" in flash then you will have to wait

OK, I will test it.

Tested it; I have set the startup-config to -1 (store the last value);
Tested it first with sliders on the web-interface; works.
NOW: it's better, than expected, because:
even using the new led_driver it stores the values in flash. This is either because you change the channels in anyway,
or because I use a backlog to set color: backlog led_basecolor_rgb #COLOR.0000 ; led_enableAll 1

Maybe the led_enableAll stores it in flash, or just the change of channels with the led_basecolor_rgb.
For me: IT WORKS, even with the new led_driver

Side-effect:
on restart/startup the device reports device/channel/get, which will report the flash-stored color. But only at startup.
That's fine for me, as my FHEM systems remebers the last color set/reported when the device was on.
It's just "funny" to see, that "normally" the channels are not reported (only Color for the new driver), but at startup they are.
But this does not cause any harm for me

Looks good.
Thanks,
best.

Hi,
At the moment i have 5 BL602 successfull connected and they run stable for more than 30 days now.

Is there already a way to fetch the IP address via MQTT?

Sorry, I forgot about that. Feel free to remind me earlier next time. I added IP publish, @_Roli_ :

NOTE: tested only on BK7231 so far

https://github.com/openshwprojects/OpenBK7231...mmit/a05fdfb69f694019dcf91bf6eb80fd108f9c512f
if the binary for bl602 won't compile, wait a while, I will fix it

btw, what kind of devices you have? 5 led strips?

@droege so you need both values to be broadcasted and also a third value, a final rgb? Ok, I will look into it

p.kaczmarek2 wrote:

btw, what kind of devices you have? 5 led strips?

I have 5 Led Strips but only single color dimmer

To get it working i guess i have to reflash my devices?

p.kaczmarek2 wrote:

Sorry, I forgot about that. Feel free to remind me earlier next time. I added IP publish, @_Roli_ :

NOTE: tested only on BK7231 so far

https://github.com/openshwprojects/OpenBK7231...mmit/a05fdfb69f694019dcf91bf6eb80fd108f9c512f
if the binary for bl602 won't compile, wait a while, I will fix it

btw, what kind of devices you have? 5 led strips?

@droege so you need both values to be broadcasted and also a third value, a final rgb? Ok, I will look into it

For startup I don't care, as I can handle all the things.
For changing dimmer / hue / sat value, I would like to see reporting of Color (as RGB) and dimmer in 0-100 for all changes and also vice-versa.
Whatever one changes, a new report on Color (rgb) and Dimmer would be great. If it is only Color (as RGB), but always, would also be ok

Thanks,
best.

Added after 11 [hours] 1 [minutes]:

But I have another request:
When the BL602 starts up (cold reboot), channel 1 blinks. I guess it's WIFI-reconnect indication?
Normally, that's fine, to see what's going on.
BUT: If there is a stored flash color, this blinking is disturbing, because it first blinks, and the changes to the deisred color.
Can you make this blinking configurable, in such a way, that it's switchable to off?
The idea: If one chooses to have stored flash values, on the same Web-Page one can select, to turn of this start-blinking?
Thanks,
best.

@Roli yes you have to reflash it, right now we have no OTA, as the BL602 is a small family of devices and I don't have time to port it or make it multiplatform

@droege it should publish current unscaled color and dimmer together
https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.4.20

droege wrote:

But I have another request:
When the BL602 starts up (cold reboot), channel 1 blinks. I guess it's WIFI-reconnect indication?
Normally, that's fine, to see what's going on.
BUT: If there is a stored flash color, this blinking is disturbing, because it first blinks, and the changes to the deisred color.
Can you make this blinking configurable, in such a way, that it's switchable to off?
The idea: If one chooses to have stored flash values, on the same Web-Page one can select, to turn of this start-blinking?
Thanks,
best.

I think that you have old version that had this bug (not a wifi indication). The current version should be ok, as I have a relay and PWM LED controller which do not blink on startup.

p.kaczmarek2 wrote:

@_Roli_ yes you have to reflash it, right now we have no OTA, as the BL602 is a small family of devices and I don't have time to port it or make it multiplatform

@droege it should publish current unscaled color and dimmer together
https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.4.20

I tested it. Yes, you are publishing Dimmer & RGB. But both are unscaled.
When setting RGB to a value, where dimmer shouldn't be 100, it's still on the last value.
Same vice-versa. Can you scale them against each other, depending on which has been set?
Scaling RGB when Dimmer is set, and scaling Dimmer, when RGB is set?

p.kaczmarek2 wrote:

I think that you have old version that had this bug (not a wifi indication). The current version should be ok, as I have a relay and PWM LED controller which do not blink on startup.

Sorry, but this behaviour is still in the latest built from above.
And it's independent, if I choose 1 or 0 as the first PWM channel. It's always the first channel, that blinks once at startup.

Any ideas?
Thanks,
best.

First of all many thanks @p.kaczmarek2 for your work.
I was able to flash my RGB LED controller for a first time yesterday. Today I was trying to use free GPIO20 pin with TTP223 touch sensor, but I see that the button handling logic is disabled for BL602 in the code. Am I right? Do you plan to support buttons/digital inputs with BL602?
Regards, MJ

droege wrote:

I tested it. Yes, you are publishing Dimmer & RGB. But both are unscaled.
When setting RGB to a value, where dimmer shouldn't be 100, it's still on the last value.
Same vice-versa. Can you scale them against each other, depending on which has been set?
Scaling RGB when Dimmer is set, and scaling Dimmer, when RGB is set?

If you could, at least, publish a scaled RGB (after Dimmer change). That's more important than a scaled Dimmer value after changing RGB.

Thanks,
best.

p.kaczmarek2 wrote:

NOTE: tested only on BK7231 so far

https://github.com/openshwprojects/OpenBK7231...mmit/a05fdfb69f694019dcf91bf6eb80fd108f9c512f
if the binary for bl602 won't compile, wait a while, I will fix it

Tested, and it's working on a BL602!

Thanks for your efforts:

Don't worry, help is near, my dev board just arrived so I will be able to test on BL602 easily!


@droege , I am not sure about all those MQTT broadcasting, as we have a limited MQTT requests space in LWIP library, but I added it to be configurable:

You must set those flags on your device as well, otherwise there will be no such MQTT broadcasts!
Commit: https://github.com/openshwprojects/OpenBK7231...mmit/b3d1b25f2ad07076163d02b41561fc5406b868ee bin is released
See MQTT names:

droege wrote:

That's more important than a scaled Dimmer value after changing RGB..

I honestly have no idea what is a "scaled dimmer value". Dimmer value is a float, so how do you want to scale that? But first check current release, led_finalcolor_rgb is a RGB that goes directly to channels (after scalling by dimmer) and led_basecolor_rgb is an echo of what you've sent (without dimming)

@mjarzebowski ok I am working on buttons now, let's see if it goes quick

p.kaczmarek2 wrote:

Don't worry, help is near, my dev board just arrived so I will be able to test on BL602 easily!


@droege , I am not sure about all those MQTT broadcasting, as we have a limited MQTT requests space in LWIP library, but I added it to be configurable:

You must set those flags on your device as well, otherwise there will be no such MQTT broadcasts!
Commit: https://github.com/openshwprojects/OpenBK7231...mmit/b3d1b25f2ad07076163d02b41561fc5406b868ee bin is released
See MQTT names:

OK, I tested it.
First of all: THANKS.
I used the flags. They work great. BUT: they don't survive reboot/cold reset of the device. Not written to flash, yet?

p.kaczmarek2 wrote:

droege wrote:

That's more important than a scaled Dimmer value after changing RGB..

I honestly have no idea what is a "scaled dimmer value". Dimmer value is a float, so how do you want to scale that? But first check current release, led_finalcolor_rgb is a RGB that goes directly to channels (after scalling by dimmer) and led_basecolor_rgb is an echo of what you've sent (without dimming)

OK. Just to explain. led_finalcolor_rgb gives back the dimmer-scaled RGB. This makes sense, when changing the dimmer value.
EG: RGB: FF0000; Dimmer 50% => finalcolor: 7F0000
so, first setting the color, then setting the dimmer. Fine.

BUT: if you directly set an RGB color, the idea was, not to scale this with a previous dimmer value, but adjust the reported dimmer value.
EG: Assume, last Dimmer value was 100%; now explicitly setting RGB-Color to 7F0000 => Report: FinalColor_RGB: 7F0000 (no suprise) and Dimmer 50% (as this is 50% of FF0000) [and maybe report the "unscaled_RGB" with FF0000 if you like].
This is, how Tasmota does this (without unscaled RGB).

But led_finalcolor_rgb as it is now is also good. I can use it. I would then like to switch off the unscaled RGB reporting, but keep dimmer reporting. Is that doable?

One addition: can you report led_finalcolor_rgb also when changing Hue/SAT?

Thanks,
best.

Huh, sorry, I just forgot to call CFG_Save_IfThereArePendingChanges . Now they are saved to flash well.

It's hard to maintain so many project, so you guys just have to test my work.

Send final color on HSV change? ok
https://github.com/openshwprojects/OpenBK7231...mmit/807aba96ba31768981b403c3fac683370c1ddc90

@mjarzebowski the buttons should work now, can you check;?

droege wrote:

OK. Just to explain. led_finalcolor_rgb gives back the dimmer-scaled RGB. This makes sense, when changing the dimmer value.
EG: RGB: FF0000; Dimmer 50% => finalcolor: 7F0000
so, first setting the color, then setting the dimmer. Fine.

BUT: if you directly set an RGB color, the idea was, not to scale this with a previous dimmer value, but adjust the reported dimmer value.
EG: Assume, last Dimmer value was 100%; now explicitly setting RGB-Color to 7F0000 => Report: FinalColor_RGB: 7F0000 (no suprise) and Dimmer 50% (as this is 50% of FF0000) [and maybe report the "unscaled_RGB" with FF0000 if you like].
This is, how Tasmota does this (without unscaled RGB).

This is less logical than I tought. Ok, so what is the formula to get dimmer value from RGB? I might look for that in Tasmota source code, but maybe you have it at hand?

EDIT:

Quote:

FinalColor_RGB: 7F0000 (no suprise) and Dimmer 50% (as this is 50% of FF0000)

And what if previous value was 7F0000 and we received 400000? Should it report dimmer 50% (as 400000 is a of 7F0000) or... or 25%?

I will test, thanks.
I don't have the calculations at hand, sorry. I'm not so deep into Tasmotas code .... sorry again.

But it's in that sense logical, as RGB colorscheme is fully self-contained, and dimmer is a "nice add-on". But originally RGB contains dimmer/saturation (and color of course) completly.

Whereas Hue/SAT/Bri needs all three parameter, to generate a final color, which means, that alls three needs to be stored and applied, changing just one.

And for your EDIT: it's than 25% beacuse, it's 25% of FF0000 (which is 100%)

Thanks in advance,
best.

P.S.: I think, when you convert RGB to HUE/SAT/BRI the Brightness=Dimmer is, what we are looking for. HUE/SAT/BRI needs all the three. Therefore it should work

p.kaczmarek2 wrote:

@mjarzebowski the buttons should work now, can you check;?

That was quick
Sure, I'll try to find some time today.

Hi again,
for conversion RGB=> HSV/HSB:
Let's assume we have an RGB value in variables R,G,B; then we can compute:

R' = R/255
G' = G/255
B' = B/255
Cmax = max(R', G', B')
Brightness/Dimmer = Cmax*100

Cheers

mjarzebowski wrote:

p.kaczmarek2 wrote:

@mjarzebowski the buttons should work now, can you check;?

That was quick
Sure, I'll try to find some time today.

Works like a charm! Cheers : )

Hello,
I own some MagicHome LED strip controllers equipped with the BL602. A couple of weeks ago I happily found this thread here and was able to flash your firmware on the device. Thank you very much!
Just one question: Are there plans to implement a Hue simulation just like in Tasmota? My intention was to control the MagicHome with Alexa but I don't have Home Assistant, FHEM or something like that. Just some devices flashed with Tasmota and an Amazon Echo.
Thanks

Hello, it's nice to see more people using OpenBL602.
What do you mean by hue simulation, would you like a hue slider/control on OpenBL602 web panel or are you referring to MQTT command? I haven't used Amazon Echo yet so I don't know how it works, but I can try adding whatever's needed

Or do you mean Hue Natural Daylight Simulation, change hue depending on local time?

Hi, thanks for the quick reply.
I have some ESP based devices, flashed with Tasmota. In the web interface of Tasmota in the menu "other parameters" is a setting "emulation". If "Belkin WeMo" or "Hue Bridge" is set here, the device will be detected by Alexa with the command "search new devices". After that, the devices can be controlled by voice over Alexa without the need of Home Assistant, FHEM etc. For instance I can say: "Alexa, set LED strip to green".
If emulation is set to "None", the device will not be detected. The same situation I have now with OpenBL602. Hopefully it is possible to implement this.

So it's the Philips Hue Driver?
https://github.com/arendst/Tasmota/blob/c0856...0/tasmota/tasmota_xdrv_driver/xdrv_20_hue.ino
I could do that, but I need to buy Alexa hub for testing that? I never used Alexa before.

p.kaczmarek2 wrote:

So it's the Philips Hue Driver?
https://github.com/arendst/Tasmota/blob/c0856...0/tasmota/tasmota_xdrv_driver/xdrv_20_hue.ino
I could do that, but I need to buy Alexa hub for testing that? I never used Alexa before.

Hey again,
you don't need an Echo Device. The Alexa-App on a SmartPhone is sufficient. Alexa uses the smart home skill to address the Hue bulb.

BTW: What's about Dimmer values to be published when changing RGB?

Thanks,
best.

p.kaczmarek2 wrote:

So it's the Philips Hue Driver?

Yes, I think so. The comments in the linked source code look promising.
I have very limited C programming and compiling skills, but I can test if you provide a new firmware image.
Thanks again for your efforts.
Kind regards,
Helge

Hey,
any news or progress on the project?
Thanks,
best.

I've had a few days off, due to the very high hot days here in Poland, but now I will look into ADC for Beken platform and then maybe fix that LED stuff,

Hi again,
in Version 1.5.6 the finalcolor_rgb is not working anymore in a consistent way.
Sometimes it is reported, sometimes not.
I have set it in the "General" Setup: Flag 1 & 2
When sending Dimmer Commands, this only works once.
After altering RGB this final color is not reported anymore ...

Any ideas?
Thanks,
best

That's strange, which version worked correctly before?

Here is the change log for led driver:
https://github.com/openshwprojects/OpenBK7231T_App/commits/main/src/cmnds/cmd_newLEDDriver.c
Last change 22 days ago.

Are you saying that something else changed during that 22 days?

Are you getting any publish failed warnings?

Hey again,

last thing that worked was 1.4.23 (haven't tested anything above since 1.5.6);
The device even did not reboot correctly with 1.5.6; again I used the flags 1 & 2; I guess, that the new flag with MQTT report made it fail.
I didn't got any update report via MQTT in 30 or so seconds;
Maybe that has changed the behaviour of MQTT and blocked reboot?
I had to flash back 1.4.23 in order to revive the device.
Cheers

droege wrote:

The device even did not reboot correctly with 1.5.6; again I used the flags 1 & 2; I guess, that the new flag with MQTT report made it fail.

The new MQTT flag (flag 3) made it fail even while it being disabled?
It should be set to 0 by default.

p.kaczmarek2 wrote:

droege wrote:

The device even did not reboot correctly with 1.5.6; again I used the flags 1 & 2; I guess, that the new flag with MQTT report made it fail.

The new MQTT flag (flag 3) made it fail even while it being disabled?
It should be set to 0 by default.

I've activated it, because I like the idea of continuous reporting.
Sorry for this.