Elektroda.com
Elektroda.com
X
Elektroda.com

Tasmota Device Groups - connection of OpenBeken (BK7231T / BK7231N) with Tasmota

p.kaczmarek2 2898 40
This content has been translated flag-pl » flag-en View the original version here.
  • #31
    ferbulous
    Level 13  
    p.kaczmarek2 wrote:
    There is already a colour sender:

    Thanks, didn't see that in the command list on the main github page.

    p.kaczmarek2 wrote:
    but I heard some reports that C and W may be swapped, when a Tasmota RGBCW bulb does a DGR transmit to OBK, OBK gets values swapped... is this true, can you check?

    Works fine with my OBK when received DGR from Tasmota RGBCW, no swapped colors

    p.kaczmarek2 wrote:
    Regarding SetOption65... hmm, there is an option to change default "correct boot" timer from 30 seconds down to given value, wouldn't it be enough? Or do you want to disable the "back to AP" totally?

    Is there way for me to retain the same pin settings or maybe i need to compile openbk with default pin templates similar to tasmota?
    From my understanding, I would just need to reduce the timer to prevent the reset, correct?
  • #32
    p.kaczmarek2
    Level 28  
    What do you mean by "pin setting"? You can reduce the timer to lower the chances of unwanted safe mode. But even if it enters safe mode, you can reboot it again (after 30 seconds), and it will still remember pin settings. The safe mode does not mean that device clears it's config. It's just that safe mode ignores config for that single run, the config is still kept in memory intact.

    Here is the 30 second setting (this means that after 30 seconds after boot, the boot is marked as Ok. And if device gets more than 4 not-ok boots in the row, it goes to safe mode - to AP mode):
    Tasmota Device Groups - connection of OpenBeken (BK7231T / BK7231N) with Tasmota
  • #33
    ferbulous
    Level 13  
    p.kaczmarek2 wrote:
    But even if it enters safe mode, you can reboot it again (after 30 seconds), and it will still remember pin settings.


    So by default once it gets to safe mode, the pin configurations are reset.
    Then another reboot after 30 seconds will restore the pin settings?

    By the way, how do I enter color temperature values with DGR_SendRGBCW command?
  • #34
    ferbulous
    Level 13  
    Some updates
    Latest firmware 1.35 (i've only start testing with wall switch starting on this version)
    Device group enabled on all devices:
    3 Gang Wall switch (N device), if mqtt payload is sent, openbk stopped responding and I have to power cycle it.
    LED bulb (N device), no issues when mqtt payload is sent, online and functioning as usual.

    Code:

    Info:GEN:sta:rssi=-54,ssid=Suliana,bssid=a0:ab:1b:84:8c:d0 ,channel=10,cipher_type:
    Info:DGR:DGR_Parse: grp name cornerlamp len 10
    Info:DGR:DGR_Parse: [192.168.1.239] seq 0x003B, flags 0x00
    Info:GEN:CHANNEL_Set channel 0 has changed to 0 (flags 0)

    Info:DGR:DGR_Parse: grp name cornerlamp len 10
    Info:MAIN:Time 51, idle 474277/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 52, idle 471420/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 53, idle 476504/s, free 81704, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 5/38
    Info:MAIN:Time 54, idle 473156/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 55, idle 468226/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 56, idle 480692/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 57, idle 474013/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 58, idle 471789/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 59, idle 471671/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:MAIN:Time 60, idle 945873/s, free 81920, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
    Info:GEN:dhcp=0 ip=192.168.1.101 gate=192.168.1.1 mask=255.255.255.0 mac=38:1f:8d:8c:55:9e
    Info:GEN:sta: 1, softap: 0, b/g/n
    Info:GEN:sta:rssi=-54,ssid=Suliana,bssid=a0:ab:1b:84:8c:d0 ,channel=10,cipher_type:


    Last log entry before it stopped responding.

    Not related to mqtt crash but some comments on the device groups feature

    Since the device group works based on channel number
    LED bulb is on channel 0,
    For my 3 gang switch, I assigned the relay as 1,2,3 (channel 1,2,3) .
    Turning on/off the led bulb didn't change anything with the switch.
    so I tried changing the relay to 0,1,2. Toggling relay 0 now turns on/off the LED bulb
    Is it possible to add an option that assigns devicegroupname for specific channel?

    For now I'm using this script to send on/off command based on the channel # state of the switch (changed to initial relay numbers 1,2,3)
    Code:
    addChangeHandler Channel1 == 0 DGR_SendPower cornerlamp 0 0
    
    addChangeHandler Channel1 == 1 DGR_SendPower cornerlamp 1 0
  • #35
    ferbulous
    Level 13  
    For my lights (N device), i noticed openbk stops receiving/sending dgr commands after some time (>8 minutes)?
    Then after an hour device groups resume working and off again. Seems a bit random but mostly it stops working and there was no dgr related logs in the log output.

    If I restart openbk, device group works again but briefly as before.
  • #36
    p.kaczmarek2
    Level 28  
    ferbulous wrote:

    By the way, how do I enter color temperature values with DGR_SendRGBCW command?

    DGR_SendRGBCW 00FF00 for green, 000000FF00 for cool white, etc. 5 hex numbers (or 3, remaining are assumed to be 0)

    DGR has been updated today and we no longer send packets directly from MQTT/TCP callbacks, we are using a queue instead - they are sent from main tick. It seems that the potential crash on power state change is solved now. More changes soon..

    Devicegroup per channel is TODO, but you can still script DGR events.
  • #37
    ferbulous
    Level 13  
    p.kaczmarek2 wrote:
    DGR_SendRGBCW 00FF00 for green, 000000FF00 for cool white, etc. 5 hex numbers (or 3, remaining are assumed to be 0)


    Thanks for the example

    p.kaczmarek2 wrote:
    DGR has been updated today and we no longer send packets directly from MQTT/TCP callbacks, we are using a queue instead - they are sent from main tick. It seems that the potential crash on power state change is solved now. More changes soon..

    Nice, this is for the upcoming update?

    Using http request for now as I keep testing device group,
    Can I send a channel variable on HTTP GET request? I just modified it slightly from the DGR command
    Code:

    setButtonHoldRepeat 2
    addEventHandler OnHoldStart 22 SetChannel 6 0
    // when Hold repeats, add a 10 value as a step
    // AddChannelSyntax: channelindex delta minValue maxValue
    // the 0 255 is needed so we clamp the value to 255
    addEventHandler OnHold 22 backlog AddChannel 6 15 0 255; DGR_SendBrightness cornerlamp $CH6

    to
    Code:

    setButtonHoldRepeat 2
    addEventHandler OnHoldStart 22 SetChannel 6 10
    addEventHandler OnHold 22 backlog AddChannel 6 15 10 100; sendGet http://192.168.1.247/cm?cmnd=led_dimmer%20$CH6


    Added after 9 [hours] 19 [minutes]:

    p.kaczmarek2 wrote:
    Devicegroup per channel is TODO, but you can still script DGR events.


    Yes, adding a different device group name on the same device (switch) would be nice
    Just a mockup

    Tasmota Device Groups - connection of OpenBeken (BK7231T / BK7231N) with Tasmota
  • #38
    p.kaczmarek2
    Level 28  
    Those are great ideas, I will look into them. I will try to support this now:
    ferbulous wrote:

    Code:

    addEventHandler OnHold 22 backlog AddChannel 6 15 10 100; sendGet http://192.168.1.247/cm?cmnd=led_dimmer%20$CH6

    I will tell you when it was added to the build (if I don't forget).

    The DGR was updated with crash fix, but I am not sure yet about your "DGR off for some time" report.

    Futhermore, I am just making sure you've seen it:
    https://github.com/OpenBekenIOT/webapp/pull/27
    Your pull request has accidentally so many commits, can you recheck this pull and add only the devices.json changes?
  • #40
    p.kaczmarek2
    Level 28  
    Hmmm maybe the fastest way would be to just open a new pull request but only for that file?

    I am working on that within-string constant expansion for you, it's getting nicely. I am developing on Windows, because OpenBK now runs on Windows and it's a true gamechanger. I can add features really fast.
    Here is how my simple 'unit' testing looks in VC:
    Tasmota Device Groups - connection of OpenBeken (BK7231T / BK7231N) with Tasmota
  • #41
    ferbulous
    Level 13  
    p.kaczmarek2 wrote:
    The DGR was updated with crash fix, but I am not sure yet about your "DGR off for some time" report.

    It's still frequently happening, i just have nodered handle the automation for light groups & switches now. Just have to turn them off and re-test the device group with each new updates

    p.kaczmarek2 wrote:
    Hmmm maybe the fastest way would be to just open a new pull request but only for that file?

    Just did another pull request, hopefully i got it right