logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

OpenBeken BK7231N + BL0942 MQTT Sensor Availability in Home Assistant, Missing avty_t

avgapon 645 10
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 21821590
    avgapon
    Level 2  
    Posts: 9
    Hi. I am totally new here, so maybe I am asking something obvious or silly. My apologies if that's the case.

    I've just reflashed a pretty generic Tuya smart plug based on BK7231N (T34, actually) + BL0942 to the latest OpenBeken firmware that has been downloaded by the GUI flasher (1.18.249).
    Everything went very well, everything works.
    Home Asssistant has auto-discovered the device and it was also perfect.

    Then, I pulled the plug from the wall socket and that's when I got a bit puzzled.
    Home Assistant shows the switch entity of the device as unavailable, but for all power sensors it keeps showing the last reported value.

    I checked with MQTT explorer and I think that the issue may be related to availability topic ("avty_t") in the discovery messages.
    I see relevant topics under homeassistant/switch (there's just one, homeassistant/switch/XXX_relay_1/config) and under homeassistant/sensor (there are several of them).
    The topic under "switch/" has a message with JSON payload that has
    Code: text Expand Select all Copy to clipboard
    "avty_t": "~/connected"
    field in it.
    But messages in the topics under "sensor/" do not have that field in their payloads.

    I guess that's why Home Assistant does not know / care about availability of those sensors.

    I wonder if I configured something wrong or if I haven't configured something that I should have.

    AI: Could you please share whether you customized any MQTT or discovery settings in OpenBeken, or are you using the default configuration?

    Almost default configuration.

    In Flags I have only flag 2 set.

    I also have a startup command:
    Code: text Expand Select all Copy to clipboard
    backlog startDriver NTP; ntp_setServer 192.168.0.1; ntp_timeZoneOfs +3; SetupEnergyStats 1 60 5;


    AI: Which versions of Home Assistant and your MQTT broker are you currently using?
    mosquitto-2.0.22
    HASS 2026.1.2

    Added after 31 [minutes]:

    Another observation is that discovery messages for "internal sensors" (like chip temperature, RSSI, etc) do have avty_t in them.
    Only energy related sensors don't have it.
    Makes me wonder if maybe SetupEnergyStats could be responsible for that.
  • ADVERTISEMENT
  • #2 21822138
    avgapon
    Level 2  
    Posts: 9
    I think that the effect could be a regression from https://github.com/openshwprojects/OpenBK7231...mmit/d491a71a938135f92a7dc3f838e8f983e7101de7
    Code: text Expand Select all Copy to clipboard
    
commit d491a71a938135f92a7dc3f838e8f983e7101de7 (tag: 1.17.673)
Author: Tester23 <openshwprojects@gmail.com>
Date:   Thu Sep 5 18:19:26 2024 +0200

    made avty disable global


    If I read the intent correctly, it was to make flag 35 apply to all kinds of "entities", not only those considered as sensors (isSensor variable in hass_init_device_info).
    But after the change, "avty_t" is always disabled for sensors, regardless of the flag.
    I do not think that it was the intent?
  • ADVERTISEMENT
  • #3 21822144
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Interesting, if so, it's a bug. If you have a fix, please submit, if not, I'll check it with self test soon. I am not yet certain it's the case.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #4 21822147
    avgapon
    Level 2  
    Posts: 9
    >>21822144
    I don't have a formal fix, but I think that it should be to check only `!flagavty` instead of `!isSensor && !flagavty` as the code does now.
    I can open an issue or a PR if that would be better.
  • ADVERTISEMENT
  • #5 21834377
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    I see related PR is now online?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1985
    Helpful post? Buy me a coffee.
  • #6 21834493
    avgapon
    Level 2  
    Posts: 9
    >>21834377 >>21834377
    Yes, I did it to get a free firmware build :-) and to expose the proposed change properly.
    I've just tested the new firmware, and after doing "Start Home Assistant Discovery", I now see "avty_t": "~/connected" for all sensors where I expected it to be.
  • #7 21880556
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    this PR is good to merge?

    Added after 1 [hours] 40 [minutes]:

    additionally, is it true that these are not treated as 
    isSensor


    FREQUENCY_SENSOR
    ILLUMINANCE_SENSOR
    TIMESTAMP_SENSOR

    this
    Code: C / C++
    Log in, to see the code


    should be this?
    Code: C / C++
    Log in, to see the code
  • #8 21880685
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    This pr is awaiting external confirmation whether it's correct or not. I was not sure myself. Can you vouch we can merge it?
    Helpful post? Buy me a coffee.
  • #9 21880710
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    Not from experience but only through AI analysis, which said:

    Code: Text
    Log in, to see the code
  • #10 21880779
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    My concern is that we might have wanted to disable avty for sensors like device which report once and then go to deep sleep, but okay, in worst case, you can u this flag to disable it there...
    Helpful post? Buy me a coffee.
  • #11 21880780
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    ah OK sure. interesting. well, I dunno.

    Added after 2 [minutes]:

    there is this in code to suppress availability for those kinds of devices

    Code: C / C++
    Log in, to see the code


    Added after 1 [minutes]:

    The regression from d491a71 looks to have made all sensors lose avty_t regardless of the global flag
Reply | New topic
Report a violation of the law

Topic summary

✨ A user reflashed a generic Tuya smart plug based on the BK7231N (T34 variant) with BL0942 power monitoring using the latest OpenBeken firmware (version 1.18.249) via the GUI flasher. The device was successfully integrated and auto-discovered by Home Assistant, with all entities initially functioning correctly. However, after unplugging the device, Home Assistant marked the switch entity as unavailable while power sensor entities retained their last reported values. Investigation with MQTT Explorer revealed that the MQTT discovery message for the switch entity lacked the "availability topic" (avty_t), which is typically used by Home Assistant to track device availability status. The user observed that the switch configuration topic under homeassistant/switch/XXX_relay_1/config contained JSON data missing the avty_t field, whereas sensor topics under homeassistant/sensor/ included multiple entities. This suggests a firmware or configuration issue where the availability topic is not published for the switch entity, causing Home Assistant to not update its availability state properly.
Generated by the language model.
Today's popular
ADVERTISEMENT