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

Hello,

How can I update my FW via OTA ? I saw the 1.2.0 release on GitHub, but the OTA says I need a RBL file. How can I get this one ?

Thanks

OTA and RBL is only for Beken platforms. There is no OTA for BL602 yet. If any user wants to help and contribute, feel free to do it, but in the current state of things other features like Tasmota Device Groups support are taking priority.

You should wait with updating bl602 if you dont need any new features. Tasmota device groups will be coming soon for bl602 as well so that might be handy.

PS: 25 days:

Hi there,
thanks for all the work. Great start.
I'm using it with LED RGB-Stripe on an BL602.
But I have difficulties with tasmota-compatible commands:
Setting color is fine. Setting Power: NOT;
In Tasmota POWER command is NOT per Channel, but per internal group. Meaning:
POWER 0 / 1 sets the LAST color-code OFF or ON without resetting the channels to 0.
I've looked into your code and found PowerStateOnly. But even this sets all channels to 0 and with a newly ON all channels are 255.
Is there a way to simple set ON/OFF the stripe and to preserve the channel colors?

Another question to MQTT: is it possible to use MQTT WITHOUT username/password? In home networks this should be ok. In tasmota you can enable/disable authentication.

And an OTA update would also be great, as newly soldering would be obsolete for an update.

Thanks in advance

droege wrote:

Is there a way to simple set ON/OFF the stripe and to preserve the channel colors?

https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/cmnds/cmd_newLEDDriver.c

droege wrote:

Another question to MQTT: is it possible to use MQTT WITHOUT username/password? In home networks this should be ok. In tasmota you can enable/disable authentication.

is leaving those fields blank working? It might work even in a current release

p.kaczmarek2 wrote:

That works great. Thank you.
Is there a way to get an MQTT feedback on dimming/color beyond only the three channels?

p.kaczmarek2 wrote:

Another question to MQTT: is it possible to use MQTT WITHOUT username/password? In home networks this should be ok. In tasmota you can enable/disable authentication.

is leaving those fields blank working? It might work even in a current release

Nope, that doesn't work. Have tried different variations, but if the MQTT server doesn't ask for authetication the connection is not established.

Hi there,

can you add 2 more commands to MQTT?
What I would like to see for Alexa-Compatibility is:
Setting Hue & Saturation.
Tasmoat does this via HSBColor1 & HSBColor2.
Hue is less important, as it is close to RGB. But Saturation is difficult, especially in combination with Alexa.
So if MQTT could support HUE & Saturation and set the basecolor accordingly, this would be great.

Then we could also integrate your firmware with SmartHome Systems like FHEM & Alexa.

Thanks,
best

droege wrote:

Is there a way to get an MQTT feedback on dimming/color beyond only the three channels?

What exactly do you need, I can add this for you. Do you mean that the device should do MQTT publish of received dimming/color values or what?

droege wrote:

What I would like to see for Alexa-Compatibility is:
Setting Hue & Saturation.
Tasmoat does this via HSBColor1 & HSBColor2.
Hue is less important, as it is close to RGB. But Saturation is difficult, especially in combination with Alexa.
So if MQTT could support HUE & Saturation and set the basecolor accordingly, this would be great.

So you want to HSV color space support for input color? I can add that, conversion between HSV to RGB is just several lines of C code, some simple math operations.

p.kaczmarek2 wrote:

droege wrote:

Is there a way to get an MQTT feedback on dimming/color beyond only the three channels?

What exactly do you need, I can add this for you. Do you mean that the device should do MQTT publish of received dimming/color values or what?

Well, I was thinking about the following things:
You're asking with basecolor_rgb for "#AABBCC" hex for color-coding, but returning 3 channel 0-100. Thats a little bit inconsistent and needs to be converted on the client side.
Could you publish the following:
cmnd(or stat)/device/Color [hex] without "#", so that we can use it for further calculations and icon-setting
cmnd(or stat)/device/Dimmer [dez 0-100], so that we can adjust icons according to the dimming state

This is the way Tasmota is doing it.

p.kaczmarek2 wrote:

droege wrote:

What I would like to see for Alexa-Compatibility is:
Setting Hue & Saturation.
Tasmoat does this via HSBColor1 & HSBColor2.
Hue is less important, as it is close to RGB. But Saturation is difficult, especially in combination with Alexa.
So if MQTT could support HUE & Saturation and set the basecolor accordingly, this would be great.

So you want to HSV color space support for input color? I can add that, conversion between HSV to RGB is just several lines of C code, some simple math operations.

Yes, that would be great.
Can you have two/three commands for Hue, Sat, Brightness(which could be mapped to dimmer) separately? Alexa delivers those things one after the other, not together. So taking dimmer into account Hue and Sat would be enough as separate commands.
This should go to "basecolor", so that the values stay there.

Thanks in advance for all the good work,
kind regards

I will try implementing this tomorrow, but I will need you to validate my changes. I'll post here when done.

Hey there,
any updates or progress? Can I help testing?

Thanks

For a start I added hue/saturation commands, do they work as you expected?

https://github.com/openshwprojects/OpenBK7231...mmit/edfd10b7fce07cbb99880b22f7bdb4d4f63c8503

Internally I still store color as RGB. The values set by those commands are later scaled by brightness you've set.

Thank you so much.
I will test tonight, how it works.
Thanks for all your work.

Added after 5 [hours] 42 [minutes]:

p.kaczmarek2 wrote:

For a start I added hue/saturation commands, do they work as you expected?

https://github.com/openshwprojects/OpenBK7231...mmit/edfd10b7fce07cbb99880b22f7bdb4d4f63c8503

Internally I still store color as RGB. The values set by those commands are later scaled by brightness you've set.

Hi there,
i've tested your built:
First of all: THANKS.

Second: Hue works like a charm. It accepts values between 0 - 359, which is perfectly fine.
Saturation is different: I expected values between 0-100 but you accept 0-1 (via floats). Which is also fine, if one knows, but it's inconsistent to hue, as it's not between 0-1; I prefer the big numbers.
Next: when setting HUE to a specific color (which one except red doesn't matter), then setting SAT to lower 100% this works fine.
BUT setting SAT then to 0 (it's getting white, ok) and then back to 100 (here 1), it turns to RED independent, which color has been preset before.

Is that somehow fixable?
The rest is perfectly fine. Also the scaling with dimmer works great.

Can you also add in a second step the reporting of data via mqtt as described?
THANKS in advance.

There was indeed a bug caused by the lossy conversion to RGB. Can you recheck now?
Values should be 0-360 and 0-100

It should remember hue as long as you don't send a RGB color in a meantime, even if you set sat to 0 and then to 1 again

p.kaczmarek2 wrote:

There was indeed a bug caused by the lossy conversion to RGB. Can you recheck now?
Values should be 0-360 and 0-100

It should remember hue as long as you don't send a RGB color in a meantime, even if you set sat to 0 and then to 1 again

Wow, that works great.
Everything fixed. Works as expected.
THANKS.
Now let's see, what we can do about feedback via publish?
Thanks,
best.

I have added the publish for raw RGB value, for dimmer value and for color temperature.

Please refer to my yaml for topic names:

Can you check if it's what you expected?

p.kaczmarek2 wrote:

I have added the publish for raw RGB value, for dimmer value and for color temperature.

Please refer to my yaml for topic names:

Code: YAML

Log in, to see the code

Can you check if it's what you expected?

Hi again,
in terms of content, I would say it's complete.
In terms of syntax:
I understand that you would like to use /device/parameter/get as MQTT topic, but it's not consistent to Tasmota and not to the command side:
/cmnd/device/paramter value
Because you could have done also here /device/parameter/set value

My proposal:
If you would like to stay compatible with Tasmota it's:
command: /cmnd/device/parameter value
state: /stat/device/parameter

if you would like to use set/get:
command: /device/parameter/set value
state: /device/parameter/get

Just my 2 cents. Hope that's reasonable.
Thanks,
best.

This is because we started with get/set and then added cmnd tasmota style syntax but gets are going through common API and it's not possible to change only part of them to one syntax and keep others in second syntax.

But do you think this is really important?

I will add autodiscovery soon so people will not have to worry about the yaml syntax.

Of course I could change all syntax to match Tasmota, but this would break stuff for my current OpenBeken users...

p.kaczmarek2 wrote:

This is because we started with get/set and then added cmnd tasmota style syntax but gets are going through common API and it's not possible to change only part of them to one syntax and keep others in second syntax.

But do you think this is really important?

I will add autodiscovery soon so people will not have to worry about the yaml syntax.

Of course I could change all syntax to match Tasmota, but this would break stuff for my current OpenBeken users...

Hey again,
that's absolutely understandable.
But what, if you could match /stat/device/parameter internally to /device/parameter/get

Meaning, accept both but implement the functionality just once.

With discovery, you are right, it's not important.
BUT: people are used to syntax of Tasmota. Maybe not for Home Assistant. But at least with FHEM they are.
So supporting maybe both syntaxes is a good idea? And matching on to the other can help?
So the "real" syntax could be set/get and a "proxy" with matching to the original could be /cmnd... /stat...?

Just an idea.
But anyway it's understandable. Just make sure, that documentation is clear and people can figure out, what is done and why.

Go on as you like. The project is good and needed. Just give the people a chance to understand how to use it, without the need to read code.

Another thing: can you produce another built with the changes? In GIT it's still before the changes.

Thanks,
best.

Hi,

Thanks for your work. I successfully flashed the firmware on a Magic Home led controller (White only) with BL602 chip. I can control the LED brightness, but each time I reboot or switch the controller ON/OFF, the default value for brightness is set back to 0. Adding "power 100" or "powerALL 100" in the startup command text, solves the problem in case of a restart, but after switching the power on/off, the brightness is back to 0.

Is there anything I'm overlooking to set the default brightness value too 100 when the controller is powered on ?

Hey, the automatic "save last power state" is not yet done, so the startup command is a way to go.

Please see:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/cmnds/cmd_newLEDDriver.c

you can use "led_dimmer 100" command or something like that. Along with led_basecolor_rgb and led_enableAll.

PS: Did you know that you can also send such commands by HTTP? Or use button event listener to send command to another device?
https://www.elektroda.com/rtvforum/topic3892160.html

Hi again,

Thanks for the clarification. One small thing to clarify: does the startup command only work on a warm boot (i.e. restart) or should it also work on a cold boot (power up) as well ? The latter works randomly now: sometimes it's executed and the LED is switched on, sometimes it stays off. I tried adding multiple commands, but each with the same behavior. Not sure if adding a delay would help.

And yes, I was aware of the http/mqtt functionality, but I wanted to avoid having a seperate 'smart' button for now.

You're a second person asking about it...

There is a "safe mode" feature which gradually disables commands and config if device does more than restart in 30 seconds.... it seems that you are running into it as well.

It was designed to allow users to "unbrick" device that crashes because of badly written config.

It seems that I have to change it to require more restarts or something...

indeed, that explains the 'random' behavior I referred to. When I leave the controller on for 30", it works as expected.

Thanks !

i have changed it and now you need at least 5 boot failures to run safe mode https://github.com/openshwprojects/OpenBK7231...mmit/65210cd44b44e8a7ffa112f5cd3990e7e9f848de

cool ! Just tested it on my device and it works as expected.

Thanks for the fix !

Hi again,
I've tested the MQTT publishes.
First of all : THANKS.
I have 2 remarks:
1) When changing dimmer, you are reporting correctly Dimmer, but not the changed RGB-Color. But this changes with a different dimmer value.
Same vice-versa. Can you fix that? I know, it's more problematic.

2) I have an RGBW stripe controller. So far we are talking about RGB. How can I address the White channel? There is no temperature, as it's only ONE white. Is it via Power 4 0/1 ? How does this correspond to led_enableALL? Can I get seperate reports if RGB is on vs. White-Channel is on?

Thanks,
best.

Hi again,

the last two builts were not for BL602. But you did great things in there ... save power state ... MQTT reporting ..
Can you explain a little bit more on these, and make a built for BL602?

Thanks,
best.

Saving pin state will not work yet for BL602 as flashvars save/load is missing, please wait a day or so.

Would you be able to check and verify the working of BL602 save and restore channel state (persisent channel state during power off/restart) when I finish it?

droege wrote:

1) When changing dimmer, you are reporting correctly Dimmer, but not the changed RGB-Color. But this changes with a different dimmer value.
Same vice-versa. Can you fix that? I know, it's more problematic.

this is very good insight. It seems there is a bug. At first I noticed that HA sends to my device both color and the dimmer value, so in code I scale the color by the dimmer value to get final color. I also broadcast the unscaled color and dimmer value by MQTT.
But it seems now that the color value is already scaled? So I should just ignore dimmer value or something?

droege wrote:

2) I have an RGBW stripe controller. So far we are talking about RGB. How can I address the White channel? There is no temperature, as it's only ONE white. Is it via Power 4 0/1 ? How does this correspond to led_enableALL? Can I get seperate reports if RGB is on vs. White-Channel is on?

I would have to look into it, as I never had just a RGBW controler. You can always access channels directly or maybe basecolor_rgbcw can be used with dummy value for w.

p.kaczmarek2 wrote:

Saving pin state will not work yet for BL602 as flashvars save/load is missing, please wait a day or so.

Would you be able to check and verify the working of BL602 save and restore channel state (persisent channel state during power off/restart) when I finish it?

Yes, I can test it.

p.kaczmarek2 wrote:

droege wrote:

1) When changing dimmer, you are reporting correctly Dimmer, but not the changed RGB-Color. But this changes with a different dimmer value.
Same vice-versa. Can you fix that? I know, it's more problematic.

this is very good insight. It seems there is a bug. At first I noticed that HA sends to my device both color and the dimmer value, so in code I scale the color by the dimmer value to get final color. I also broadcast the unscaled color and dimmer value by MQTT.
But it seems now that the color value is already scaled? So I should just ignore dimmer value or something?

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.

p.kaczmarek2 wrote:

droege wrote:

2) I have an RGBW stripe controller. So far we are talking about RGB. How can I address the White channel? There is no temperature, as it's only ONE white. Is it via Power 4 0/1 ? How does this correspond to led_enableALL? Can I get seperate reports if RGB is on vs. White-Channel is on?

I would have to look into it, as I never had just a RGBW controler. You can always access channels directly or maybe basecolor_rgbcw can be used with dummy value for w.

Ok, I will test this.
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?

Thanks,
best.

droege wrote:

Yes, I can test it.

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

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

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.