@p.kaczmarek2
Is there a way to mark MQTT "IP" field as retain true?
Is there a way to mark MQTT "IP" field as retain true?
ferbulous wrote:
ferbulous wrote:
How can I check for that?
marioalmeida wrote:@p.kaczmarek2
Is there a way to mark MQTT "IP" field as retain true?
p.kaczmarek2 wrote:Mark from MQTT on OpenBeken side? It should be very easy, there is already a bRetain flag, just set it in code and submit a pull request.
addChangeHandler Channel1 == 1 addRepeatingEvent 500 1 setChannel 1 0
addChangeHandler Channel1 == 1 addRepeatingEvent 300 1 setChannel 1 0
marioalmeida wrote:
I searched in the OpenBK7231T_App repo but was not able to find bRetain flag, may be I am searching the wrong location.
marioalmeida wrote:
What will happen if addChangeHandler is executed twice with different repeating values, eg:-addChangeHandler Channel1 == 1 addRepeatingEvent 500 1 setChannel 1 0 addChangeHandler Channel1 == 1 addRepeatingEvent 300 1 setChannel 1 0
Will the second execution override the first one?
marioalmeida wrote:
How can I cancel running addRepeatingEvent event?
marioalmeida wrote:
Is the any option to add child lock for a physical button?
Ari2 wrote:
1) When I disconnect (shut down) HA for a few hours, both switches disconnect (freeze?), and I can't access them from the browser. It happens all the time when HA is down for a longer time, and I have to turn off breakers at home to fix them. I think that maybe it is related to MQTT somehow, that packages are not reaching the broker.
Ari2 wrote:
2) I tried to set up the watchdog to ping my HA instead of the router. But this is another problem. When I set up the HA IP, the firmware doesn't see that the HA is down. It still shows that all pings are working fine.
p.kaczmarek2 wrote:
It executes them all, as far as I remember.
p.kaczmarek2 wrote:
I can add an option for that, maybe registering an event with a certain ID and then using this ID to cancel?
p.kaczmarek2 wrote:
How would you like it to work?
p.kaczmarek2 wrote:And what is the division of duties between the chief inspector and a single lead teacher?
The easiest way would be to add the required stuff to OpenBeken, as it would also work right away on BL602 and W800 and other supported platforms.
DDP has already been submitted for implementation by one of the US users and will be done as a very simple protocol.
Could you please mention which functionalities of this WLED you use?
@ darkman1 could use a UART log, so do older versions have this problem?
marioalmeida wrote:p.kaczmarek2 wrote:
It executes them all, as far as I remember.
Is it possible to cancel the previous execution?
marioalmeida wrote:p.kaczmarek2 wrote:
I can add an option for that, maybe registering an event with a certain ID and then using this ID to cancel?
Please if you can, in that case, how to get the registering event ID?
p.kaczmarek2 wrote:Without ID mechanism it won't be possible to determine which callback we are canceling. Unless... you'd want an option to cancel them all by event name?
p.kaczmarek2 wrote:I will add it when I get some time, please check again then. What kind of syntax would you expect?
p.kaczmarek2 wrote:Some progress update: HA autodiscovery and auto page refreshing is on the way!
p.kaczmarek2 wrote:Huh, you both guys have the same CB2S issue. This is very strange. It worked before on CB2S well, both for me and for Jennifer (she did the Qiachip Fan CB2S article).
@marioalmeida @blakadder I would ask you to try two things.
1. as said in post #909 , https://www.elektroda.com/rtvforum/viewtopic.php?p=20174686#20174686 , try flashing that full 2MB bin that clears the config partitions that are internal to BK7231N (they come from BK7231 SDK, not from Tuya, but Tuya updated the SDK version they use)
p.kaczmarek2 wrote:2. you can try using earlier OpenBeken version, just to make sure the issue is not caused by something else
p.kaczmarek2 wrote:If you are unable to flash the 2MB bin, because you don't have the wires attached, you can wait for me to add this "nuke config partition" button (which will clear the internal BK partitions and stuff, not the OpenBeken one)
p.kaczmarek2 wrote:I will try my best to help you, but remember, I am just one person and any testing/investigation help is welcome.
mqtt:
light:
- unique_id: "SmartBulb1 1"
name: "SmartBulb1 1"
state_topic: "SmartBulb1/1/get"
command_topic: "SmartBulb1/1/set"
brightness_command_topic: "SmartBulb1/1/set"
on_command_type: "brightness"
brightness_scale: 99
qos: 1
payload_on: 99
payload_off: 0
retain: true
optimistic: true
availability:
- topic: "SmartBulb1/connected"
- unique_id: "SmartBulb1 2"
name: "SmartBulb1 2"
state_topic: "SmartBulb1/2/get"
command_topic: "SmartBulb1/2/set"
brightness_command_topic: "SmartBulb1/2/set"
on_command_type: "brightness"
brightness_scale: 99
qos: 1
payload_on: 99
payload_off: 0
retain: true
optimistic: true
availability:
- topic: "SmartBulb1/connected"
- unique_id: "SmartBulb1 3"
name: "SmartBulb1 3"
state_topic: "SmartBulb1/3/get"
command_topic: "SmartBulb1/3/set"
brightness_command_topic: "SmartBulb1/3/set"
on_command_type: "brightness"
brightness_scale: 99
qos: 1
payload_on: 99
payload_off: 0
retain: true
optimistic: true
availability:
- topic: "SmartBulb1/connected"
- unique_id: "SmartBulb1 4"
name: "SmartBulb1 4"
state_topic: "SmartBulb1/4/get"
command_topic: "SmartBulb1/4/set"
brightness_command_topic: "SmartBulb1/4/set"
on_command_type: "brightness"
brightness_scale: 99
qos: 1
payload_on: 99
payload_off: 0
retain: true
optimistic: true
availability:
- topic: "SmartBulb1/connected"
- unique_id: "SmartBulb1 5"
name: "SmartBulb1 5"
state_topic: "SmartBulb1/5/get"
command_topic: "SmartBulb1/5/set"
brightness_command_topic: "SmartBulb1/5/set"
on_command_type: "brightness"
brightness_scale: 99
qos: 1
payload_on: 99
payload_off: 0
retain: true
optimistic: true
availability:
- topic: "SmartBulb1/connected"
p.kaczmarek2 wrote:IMPORTANT UPDATE
I have updated led driver to broadcast received values by MQTT. My current configuration yaml:Code: yamlLog in, to see the code
I have added support for rgb_state_topic with rgb_value_template, same for brightness_state_topic and color_temp_state_topic.
Quote:
To old version of the bulb used: {"NAME":"Treatlife RGBW","GPIO":[0,0,0,0,38,37,0,0,41,39,40,0,0],"FLAG":0,"BASE":18} Template.
p.kaczmarek2 wrote:1. as said in post #909 , https://www.elektroda.com/rtvforum/viewtopic.php?p=20174686#20174686 , try flashing that full 2MB bin that clears the config partitions that are internal to BK7231N (they come from BK7231 SDK, not from Tuya, but Tuya updated the SDK version they use)
p.kaczmarek2 wrote:What do you mean by "no luck"?
a) boot loop at start?
b) crash after obk startup?
c) crash after running obk for several minutes?
Anything else?
gamerayers wrote:If I go to change brightness, while on warm white, the bulb turns blue and the brightness goes to 10% in home assistant
// BLUE
setPinRole 26 PWM
setPinChannel 26 3
// GREEN
setPinRole 24 PWM
setPinChannel 24 2
// WARM WHITE
setPinRole 6 PWM
setPinChannel 6 5
// COLD WHITE
setPinRole 8 PWM
setPinChannel 8 4
// RED
setPinRole 9 PWM
setPinChannel 9 1
DGR_SendBrightness roomLEDstrips 128
DGR_SendPower testSocket 1 1
DGR_SendPower nightLamp 0 1
DGR_SendPower nightLamp 1 1
DGR_SendPower nightLamp 7 4
Info:DGR:Received 31 bytes from 192.168.1.42
Info:DGR:DGR_Parse: [192.168.1.42] seq 1024, flags 0
Info:DGR:Next section - 128
Info:GEN:No change in channel 0 (still set to 0) - ignoring
Info:GEN:No change in channel 1 (still set to 0) - ignoring
Info:GEN:No change in channel 2 (still set to 0) - ignoring
Info:GEN:No change in channel 3 (still set to 1) - ignoring
Info:GEN:No change in channel 4 (still set to 0) - ignoring
Info:DGR:Power event - values 8, numChannels 5, chans=
Info:DGR:[OFF]
Info:DGR:[OFF]
Info:DGR:[OFF]
Info:DGR:[ON]
Info:DGR:[OFF]
Info:DGR:
Info:DGR:Next section - 0
Info:DGR:Received 25 bytes from 192.168.1.158
Info:DGR:Received 25 bytes from 192.168.1.198
Info:DGR:Received 25 bytes from 192.168.1.199
Info:DGR:Received 25 bytes from 192.168.1.15
Info:DGR:Received 25 bytes from 192.168.1.53
Debug:HTTP:TCP will process packet of len 314
Debug:HTTP:TCP will process packet of len 306
Debug:API:POST to api/cmnd
Debug:CMD:cmd [DGT_SendPower nightLamp 1 1]
Error:CMD:cmd DGT_SendPower NOT found (args nightLamp 1 1)
Debug:API:POST to api/cmnd
Debug:CMD:cmd [DGT_SendPower nightLamp 0 1]
Error:CMD:cmd DGT_SendPower NOT found (args nightLamp 0 1)
Debug:API:POST to api/cmnd
Debug:CMD:cmd [DGT_SendPower nightLamp 7 4]
Error:CMD:cmd DGT_SendPower NOT found (args nightLamp 7 4)
ferbulous wrote:Debug:API:POST to api/cmnd Debug:CMD:cmd [DGT_SendPower nightLamp 1 1] Error:CMD:cmd DGT_SendPower NOT found (args nightLamp 1 1)
ferbulous wrote:
Info:DGR:Received 25 bytes from 192.168.1.158
Info:DGR:Received 25 bytes from 192.168.1.198
Info:DGR:Received 25 bytes from 192.168.1.199
Info:DGR:Received 25 bytes from 192.168.1.15
Info:DGR:Received 25 bytes from 192.168.1.53
ferbulous wrote:
3) Toggling on relay from openbk turns off the nightlamp group devices (invert?). Toggling off relay from openbk doesn't do anything.
Debug:API:POST to api/cmnd
Debug:CMD:cmd [DGR_SendPower nightLamp 7 4]
Debug:HTTP:TCP will process packet of len 306
Debug:API:POST to api/cmnd
Debug:CMD:cmd [DGR_SendPower nightLamp 1 1]
Info:DGR:Received 31 bytes from 192.168.1.42
Debug:API:POST to api/cmnd
Debug:CMD:cmd [DGR_SendPower nightLamp 0 1]
Info:DGR:Received 31 bytes from 192.168.1.42
p.kaczmarek2 wrote:Or to phrase it differently - are Tasmota packets seen by Beken?
20:26:55.520 CMD: devgroupstatus
20:26:55.528 MQT: stat/master_bedroom_3g/RESULT = {"DevGroupStatus":{"Index":0,"GroupName":"nightlamp","MessageSeq":112,"MemberCount":5,"Members":[{"IPAddress":"192.168.1.199","ResendCount":18,"LastRcvdSeq":138,"LastAckedSeq":112},{"IPAddress":"192.168.1.15","ResendCount":21,"LastRcvdSeq":117,"LastAckedSeq":112},{"IPAddress":"192.168.1.53","ResendCount":22,"LastRcvdSeq":122,"LastAckedSeq":112},{"IPAddress":"192.168.1.158","ResendCount":128,"LastRcvdSeq":2,"LastAckedSeq":112},{"IPAddress":"192.168.1.42","ResendCount":0,"LastRcvdSeq":12,"LastAckedSeq":112}]}}
p.kaczmarek2 wrote:Unless it's a byproduct by some other book, then you can use Relay_n pin types in OpenBeken to mitigate it.
p.kaczmarek2 wrote:Question: do you Beken relay indices start with 1 or with 0? Code expects them to start with 0.
p.kaczmarek2 wrote:What exactly are you trying to do? Do I understand correctly - you have 3 separate lamps and a single 4 button device and want to control 3 separate lamps by single device? I'd need to get in-depth explanation.
ferbulous wrote:
I have an ikea solhetta lamp that holds 4 gu10 bulbs in a row for my night lamp
The single 4 button device is added to the group merely for testing purposes. I wanted to try if I could only assign 1 button/relay to the group so it doesn't toggle all the relays like with tasmota's devgrouptie.
I will try with another 1 gang N device to test with this group