logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

OpenBeken logic configuration questions after flashing for beginners

proks777 921 9
Best answers LABEL_AI_GENERATED

How can I stop an `OnHold` button action from triggering the `addRepeatingEventID` DeepSleep timer in OpenBeken so the device stays awake?

Use the hold handler to cancel the repeating event first, then stop the scripts; a working example is `addEventHandler OnHold 8 backlog cancelRepeatingEvent 777; stopAllScripts`, which prevents the `addRepeatingEventID 777` DeepSleep action from firing when the button is held [#21890077] [#21893181]
AI summary based on the discussion. May contain errors.
ADVERTISEMENT
Report a violation of the law
Reply | New topic

  • OnHold conflicts with repeating DeepSleep event

    #1 21890073
    proks777
    Level 2  
    Posts: 10
    I've flashed OpenBeken >>21888469 and am now trying to configure its logic. Along the way, I've encountered many questions I can't find answers to. I hope this thread will help me and other newbies better understand OpenBeken.

    I'm currently trying to integrate two functions:
    addEventHandler OnHold and addRepeatingEventID.

    When adding addRepeatingEventID to the file, the addEventHandler OnHold function no longer works as expected; it triggers addRepeatingEventID!
    I want the device to remain active when I long-press the button, rather than going to sleep! How can this be accomplished?

    Here's an example of my file.
    Code: text Expand Select all Copy to clipboard
    startDriver battery
startDriver CHT83XX
Battery_Setup 2200 3000 1.92 2400 4096
addEventHandler OnHold 8 stopAllscripts
addRepeatingEventID 60 1 777 DeepSleep 300
waitFor WiFiState 4
waitFor MQTTState 1
cancelRepeatingEvent 777
delay_s 2
publishChannels
delay_s 4
PinDeepSleep 60
    W pełni konfigurowalna automatyzacja domu - prezentacja Fox Wi-Fi Quad Input [sponsorowany]
  • ADVERTISEMENT
  • Helpful post
    #2 21890077
    divadiow
    Level 38  
    Posts: 5236
    Help: 449
    Rate: 918
    not really sure but are you trying to stop scripts and cancel the repeating event, so the line should be

    Code: Text
    Log in, to see the code

    ?

  • Request for manual MQTT publishing on startup

    #3 21890088
    proks777
    Level 2  
    Posts: 10
    >>21890077
    Yes! Excellent! I've been struggling with this for two days.)) Thank you so much!

    Added after 11 [minutes]:

    Is there a way to switch MQTT publishing to manual mode?
    I'm currently sending data—temperature, humidity, battery in volts, and percentage! And I don't like that the data can be published multiple times during a single device startup!
    If I enable Flag 37 and Flag 51, the first data transmission happens too quickly, and I see 0% battery charge in Home Assistant.
    As I understand it, this is because the Driver battery initially displays a low voltage of ~700 mV and only after a couple of seconds displays a normal voltage of 2.7 V.
    When the device is booted, it constantly publishes data to MQTT. Is it possible to disable this and publish only once per session?
  • ADVERTISEMENT
  • #4 21892972
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14795
    Help: 659
    Rate: 12944
    Maybe use setChannelPrivate ?

    Or just do your own simple fork and comment out MQTT calls. We have online builds for that, should be very easy:
    https://www.elektroda.com/rtvforum/topic4033833.html

    For too quick publishes, there is also a work around - use -1 as start value for channel so device actually remembers it between reboots. But yet, that's not perfect...
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT

  • Battery pin mapping and temperature drift question

    #5 21893181
    proks777
    Level 2  
    Posts: 10
    p.kaczmarek2 wrote:
    Maybe use setChannelPrivate ?

    How to assign setChannelPrivate to a battery?

    I can't figure out how to find the correct battery pins. I'm currently using 5 - BAT_Relay, 10 - BAT_ADC. With this setup, I don't see 0% when starting. But I still think the pins are incorrect, as I get a large deviation in the readings when the temperature changes! After calibrating at 25C, I see 2.5V, but at 15C, I see 2.43V. Is this normal?

    OpenBeken logic configuration questions after flashing for beginners


    I think I got what I wanted. But I can't figure out why it works.

    Screenshot of MQTT Explorer showing topic list and a JSON message for “TH-4”


    Code: text Expand Select all Copy to clipboard
    {
  "vendor": "Tuya",
  "bDetailed": "0",
  "name": "Full Device Name Here",
  "model": "enter short model name here",
  "chip": "BK7238",
  "board": "TODO",
  "flags": "0",
  "keywords": [
    "TODO",
    "TODO",
    "TODO"
  ],
  "pins": {
    "0": "CHT83XX_SDA;2;3",
    "1": "CHT83XX_SCK;0",
    "5": "BAT_Relay;0",
    "6": "WifiLED_n;0",
    "8": "Btn;0",
    "9": "dInput;0",
    "10": "BAT_ADC;0"
  },
  "command": "",
  "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
  "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}


    Code: text Expand Select all Copy to clipboard
    startDriver battery
startDriver CHT83XX

//CHT_Calibrate -1 3

Battery_Setup 2100 2700 1.8 2400 4096
Battery_Cycle 2
CHT_Cycle 3
delay_s 2
Battery_Cycle 10
CHT_Cycle 10


addEventHandler OnHold 8 backlog cancelRepeatingEvent 777; stopAllScripts
addRepeatingEventID 30 1 777 DeepSleep 1800
waitFor WiFiState 4
waitFor MQTTState 1
cancelRepeatingEvent 777

delay_s 1
publish TH/TH-4 "{"t":$CH2,"h":$CH3,"bat_v":$batteryVoltage,"bat_p":$batteryLevel}" 1

CHT_Alert 0.3 5 60 2

PinDeepSleep 900

  • Request for BAT_ADC and BAT_Relay pin mapping

    #6 21895467
    proks777
    Level 2  
    Posts: 10
    Please help. I can't configure BAT_ADC and BAT_Relay. Everything I've tried gives incorrect readings. Temperature also significantly affects the readings. Can someone tell me the correct pins for BAT_ADC and BAT_Relay from a photo?
    OpenBeken logic configuration questions after flashing for beginners Close-up of a green PCB with SMD components, a mounting hole, and a plus sign marking Hand-drawn wiring diagram of a BME280 sensor connected to a microcontroller, with labeled I2C pins

    "pins": {
    "0": "CHT83XX_SDA;2;3",
    "1": "CHT83XX_SCK;0;0",
    "6": "WifiLED_n;0;0",
    "8": "Btn;0;0",
    "9": "dInput;0;0",
  • ADVERTISEMENT
  • #7 21895498
    divadiow
    Level 38  
    Posts: 5236
    Help: 449
    Rate: 918
    I think BAT_ADC on BK7238 is always P20

    Did you take backup of original firmware? Any config extracted from it using Easy Flasher Tuya Config Extractor tab?
  • #8 21895516
    proks777
    Level 2  
    Posts: 10
    >>21895498
    I couldn't extract the pins using Easy Flasher. Yes, I did make a backup. I sent it to you in a private message.
  • Helpful post

    KV dump shows no pin info

    #9 21895522
    divadiow
    Level 38  
    Posts: 5236
    Help: 449
    Rate: 918
    Oh yes! You did. Sorry

    Added after 1 [hours] 29 [minutes]:

    I remember now. no pin info was in the KV

    Code: JSON
    Log in, to see the code


    Code: Text
    Log in, to see the code


    the short boot log doesn't help either

    Code: Text
    Log in, to see the code


    Added after 13 [minutes]:

    OK, try

    P24 = BAT_ADC
    P26 = BAT_RELAY

  • BAT_ADC and BAT_RELAY pin mapping confirmed

    #10 21895607
    proks777
    Level 2  
    Posts: 10
    divadiow wrote:
    P24 = BAT_ADC
    P26 = BAT_RELAY


    Looks like these are the correct pins! I stuck it in the fridge, and there's practically no deviation in the readings! As I understand it, 2.85 (Battery_Setup 2100 2700 2.85) isn't quite standard? But the main thing is that it works! I tried this option before, but the readings were ~3.00 mV. To get adequate readings, you need to reboot!
    Thank you so much!

    OpenBeken logic configuration questions after flashing for beginners
Reply | New topic
Report a violation of the law

Topic summary

LABEL_AI_GENERATED
The discussion focuses on configuring OpenBeken logic after flashing, especially combining OnHold button handling with addRepeatingEventID so a long press cancels a repeating deep-sleep event and keeps the device awake. The working solution is to use a backlog command in the OnHold handler to cancel the repeating event before stopAllScripts. The topic then shifts to MQTT publishing behavior on boot, including how to reduce repeated startup publishes, avoid incorrect initial battery percentage readings, and use workarounds such as setChannelPrivate or initializing channels with -1. Later messages address battery measurement and pin mapping on a BK7238 Tuya device, including BAT_ADC and BAT_Relay assignment, temperature-related voltage drift, Battery_Setup calibration, and the discovery that the correct pins were not available in the extracted KV, with BAT_ADC believed to be P20.
AI summary based on the discussion. May contain errors.
Today's popular
ADVERTISEMENT