[BK7231N] OpenBeken - How do I change the Tuya WiFi Smart PIR function from Control to Sensor?

Question

I have such a PiR Multifunction Alarm as in the attached pictures. I managed to flash it on OpenBeken, but I can't use it in the Alarmo plug-in in the home assistant because it is not detected as sensor but as control. Is it possible to change this somehow? I'm using the dinput function, because...

p.kaczmarek2 · Accepted Answer

This doesn't change anything. A completely clean OBK with just the Motion channel will be seen correctly by HA. Likewise, a pure OBK with dInput will be seen correctly by HA (but no longer as Motion). It is worth noting here that the channel types have priority. If they are not set then OBK guesses at the pins. Upload the latest version of OBK onto anything (but from these links what I'm giving, as the main build is broken temporarily), set the Motion channel, save (Save), do HA Discovery and you should be able to see this channel in HA. You don't need anything else, no pins. Maybe this is a phenomenon? Microcontroller works without power connection? Running on GND and UART alone, a conundrum. And no, MCU though. I don't like devices of this type, we have tmSensor for that but they are problematic: We have no control over the MCU. Maybe it is better to convert to DeepSleep Since further motion does not work then let's do it differently. You can artificially do a HASS discovery. 1. create a file myFile.txt in LittleFS 2. put a JSON HASS in it, for example: Code: JSONLog in, to see the code 3. use the command: Code: text Expand Select all Copy to clipboard publishFile homeassistant/binary_sensor/WinTest_3145CAFF_binary_sensor_1/config myFile.txt 1 This should artificially publish the Discovery with Motion channel and HA should detect it. Of course to use this in practice you need to correct the fields in the JSON to match yours.

p.kaczmarek2 · Answer

To start with you could try setting the role of the speaker pin to PWM and play around with the PWM settings, apart from the fill adjustment there is also the command PWMFrequency . There are no pre-programmed tunes at the moment, but that shouldn't be a big problem either, you could try to do it...

What about the sensor type, just out of curiosity, if you change the channel type from PIR value to OpenClosed does it change the type when you Ha Discovery again?

burba · Answer

Setting the pin to PWM helped - the speaker came to life, the 'Toggle Light' button and 'LED Dimmer/Brightness' slider appeared on the OpenBeken home page, and a light switch appeared in the HA 'controls' panel next to the switch showing the PIR status, which turns on the speaker. Thanks :-)

. I'll play with the settings later.

Changing the channel type (ch1 in this case) to OpenClosed/OpenClosed_Inv unfortunately didn't help. After removing the sensor from HA and re HA discovery all the time the PIR is a switch. Obviously the switch switches itself reacting to movement - because I didn't mention that at the beginning. It's just the wrong type that prevents me from plugging it into Alarmo.

PS. nods and admiration - amazing job, great design and responsiveness better than entire helpdesk teams in corporations!

p.kaczmarek2 · Answer

There is a flag to show raw PWM controls and this should disable treating this as an LED. Then this could be scripted in autoexec.bat and e.g. catch the channel state change event from the PIR... If you know the basics of C then you could add a simple driver for this to play a melody, but it depends if you want to play around... In that case I can add a new channel type for you (unless something else fits, but I'd have to check), just do you happen to know what specific settings the HA expects? Maybe you have some device with the correct Home Assistant Discovery and can capture it to peek at what is being sent? Otherwise.... what sensor class is this channel supposed to have? Can you provide the entire configuration of your device so I can enter it into the simulator and check it for myself with HA? This is an example from me: This is how HA sees it: Added after 8 [minutes]: Is this the binary_sensor from motion? Added after 5 [minutes]:2dd3e526464b This is what it would look like with motion: Added after 25 [minutes]:2dd3e526464b I uploaded the Motion channel type, can you do an OTA to the latest version and see if it works? C

burba · Answer

I guess I'm a bit short on time :-|

. The OTA shows me as the latest version "Build on May 3 2024 21:03:04 version 1.17.571". I uploaded what was the latest anyway, just in case, but the Motion channel type didn't show up. On GitHub I actually see that you have made changes to the "http_fns.c" file. Should I compile this myself somehow?

This is the extracted device configurations from HA mqtt-b020b...df2f5-.zip Download (6.99 kB) .
devices that can serve as alarm-triggering sensors are described in this way:
"entity_id": "binary_sensor.0xa4c13847c35b3626_occupancy"
"entity_id": "binary_sensor.0xa4c138c8c95d7439_smoke"

a PIR sensor with which there is a problem in this one:
"entity_id": "switch.multifunction_alarm_obke1552b06_1"

p.kaczmarek2 · Answer

I think I just messed up the compilation on the main page from Github:

I'll give the OTA file download or link here

Added after 26 [minutes]:

https://github.com/openshwprojects/OpenBK7231.../actions/runs/8984880294/artifacts/1480027898 select the correct OTA file for your platform from this zip

burba · Answer

Ok, thanks. Motion has appeared in the list of channel types, although it's pointing a bit the other way round: in the ON state it shows "no motion", but that's unlikely to be a problem - I've changed the PIN setting to "dInput_n".
Unfortunately, no change in HA - it's still in the "controls" panel, not "sensors".

p.kaczmarek2 · Answer

And did you do HASS Discovery? Do you have like in my screenshots?

burba · Answer

I removed the device from the HA (in the MQTT extension), restarted via the OpenBK main page and added again via OpenBK Config->Home Assistant Configuration->Start Home Assistant Discovery. And all the time it looks like in the screens below.

.

p.kaczmarek2 · Answer

Aha, you should have done that right away. I typed in your configuration and Found another problem, here is the new version to test:

burba · Answer

Now the PIR has disappeared altogether :-)

. Only the speaker pretending to be a light bulb remains in the "Controls" panel, but nothing new has appeared in "Sensors".

[Edit] In the "Diagnostic" panel, in addition to RSSI, the items "Build" and "uptime" appeared after a while, along with the values.

p.kaczmarek2 · Answer

So let's check again.
Before:

Configuration:

Result:

Hmm on me I think it is? After a while I have:

If I listen to the discovery topic (see screenshot):

This I have:

Log in, to see the code

Isn't this package at your place?

My colleague @DeDaMrAz will also check on HA and we'll see

Added after 1 [minutes]:

Edit: Fellow @DeDaMrAz checked, his screenshots:

He probably didn't set the Frequency channel no but there is motion in his....

What version of HA do you have? Can you check again if you have done everything ok?

DeDaMrAz · Answer

@burba After setting channels did you click save types on the bottom? .

burba · Answer

@DeDaMrAz yes, I've saved the type. Now for testing I've removed frequency, but the only effect is that frequency obviously disappeared from sensors.

@p.kaczmarek2 HA I have on proxmox (if that changes anything), version 2024.5.2

@p.kaczmarek2 where to look for this "listening theme"?
I think I did everything ok, the only thing I can think of is: "Paste this to configuration yaml
Make sure that you have "switch:" keyword only once! Home Assistant doesn't like dup keywords.
You can also use "switch MyDeviceName:" to avoid keyword duplication!" this is something I haven't done - do I actually have to paste this somewhere? Doesn't it import itself at HA discovery?

Added after 3 [minutes]:

still in autoexec.whip I have it switch the LED to show wifi status on boot, but that probably shouldn't affect:

.

p.kaczmarek2 · Answer

This field with OBK is obsolete. It is for the manual creation of YAML. We are discussing Discovery topics.

Discovery can be tapped in Home Assistant itself, in MQTT, in Configure there is an option to manually publish a packet (redundant now) and to listen for packets (this will come in handy). If you do a listen under a topic (see my screenshot from the previous post) like I did, you'll be able to catch what OBK is publishing as Home Assistant Discovery. If you approach those JSONs there, we'll know if the problem is on OBK's side (maybe the JSON from Motion isn't published after all?) or maybe on HA's side (the Json from Motion is published but HA doesn't read it)

My HA:

.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

burba · Answer

Looks like the sensor is not sending this binary_sensor/motion to MQTT at all:

"Message 26 received on homeassistant/sensor/multifunction_alarm_OpenBK7231N_E1552B06_build/config at 12:48 AM:

{
"dev": {
"ids": [
"multifunction_alarm_OpenBK7231N_E1552B06"
],
"name": "multifunction_alarm_obkE1552B06",
"sw": "1215_merge_dd32e251ff32",
"mf": "Beken Corporation",
"mdl": "BK7231N",
"cu": "http://192.168.11.110/index"
},
"name": "Build",
"~": "obkE1552B06",
"avty_t": "~/connected",
"uniq_id": "multifunction_alarm_OpenBK7231N_E1552B06_build",
"qos": 1,
"stat_t": "~/build",
"entity_category": "diagnostic"
}

QoS: 0 - Retain: false
Message 25 received on homeassistant/sensor/multifunction_alarm_OpenBK7231N_E1552B06_uptime/config at 12:48 AM:

{
"dev": {
"ids": [
"multifunction_alarm_OpenBK7231N_E1552B06"
],
"name": "multifunction_alarm_obkE1552B06",
"sw": "1215_merge_dd32e251ff32",
"mf": "Beken Corporation",
"mdl": "BK7231N",
"cu": "http://192.168.11.110/index"
},
"name": "Uptime",
"~": "obkE1552B06",
"avty_t": "~/connected",
"uniq_id": "multifunction_alarm_OpenBK7231N_E1552B06_uptime",
"qos": 1,
"dev_cla": "duration",
"stat_t": "~/uptime",
"unit_of_meas": "s",
"entity_category": "diagnostic",
"stat_cla": "total_increasing"
}

QoS: 0 - Retain: false
Message 24 received on homeassistant/sensor/multifunction_alarm_OpenBK7231N_E1552B06_rssi/config at 12:48 AM:

{
"dev": {
"ids": [
"multifunction_alarm_OpenBK7231N_E1552B06"
],
"name": "multifunction_alarm_obkE1552B06",
"sw": "1215_merge_dd32e251ff32",
"mf": "Beken Corporation",
"mdl": "BK7231N",
"cu": "http://192.168.11.110/index"
},
"name": "RSSI",
"~": "obkE1552B06",
"avty_t": "~/connected",
"uniq_id": "multifunction_alarm_OpenBK7231N_E1552B06_rssi",
"qos": 1,
"dev_cla": "signal_strength",
"stat_t": "~/rssi",
"unit_of_meas": "dBm",
"entity_category": "diagnostic",
"stat_cla": "measurement"
}

QoS: 0 - Retain: false
Message 23 received on homeassistant/sensor/multifunction_alarm_OpenBK7231N_E1552B06_sensor_2/config at 12:48 AM:

{
"dev": {
"ids": [
"multifunction_alarm_OpenBK7231N_E1552B06"
],
"name": "multifunction_alarm_obkE1552B06",
"sw": "1215_merge_dd32e251ff32",
"mf": "Beken Corporation",
"mdl": "BK7231N",
"cu": "http://192.168.11.110/index"
},
"name": "2",
"~": "obkE1552B06",
"avty_t": "~/connected",
"uniq_id": "multifunction_alarm_OpenBK7231N_E1552B06_sensor_2",
"qos": 1,
"dev_cla": "frequency",
"unit_of_meas": "Hz",
"stat_t": "~/2/get",
"stat_cla": "measurement",
"val_tpl": "{{ '%0.3f'|format(float(value)*0.1) }}"
}

QoS: 0 - Retain: false
Message 22 received on homeassistant/light/multifunction_alarm_OpenBK7231N_E1552B06_light_1/config at 12:48 AM:

{
"dev": {
"ids": [
"multifunction_alarm_OpenBK7231N_E1552B06"
],
"name": "multifunction_alarm_obkE1552B06",
"sw": "1215_merge_dd32e251ff32",
"mf": "Beken Corporation",
"mdl": "BK7231N",
"cu": "http://192.168.11.110/index"
},
"name": "1",
"~": "obkE1552B06",
"avty_t": "~/connected",
"pl_on": "1",
"pl_off": "0",
"uniq_id": "multifunction_alarm_OpenBK7231N_E1552B06_light_1",
"qos": 1,
"stat_t": "~/led_enableAll/get",
"cmd_t": "cmnd/obkE1552B06/led_enableAll",
"bri_stat_t": "~/led_dimmer/get",
"bri_cmd_t": "cmnd/obkE1552B06/led_dimmer",
"bri_scl": 100
}

"

Added after 8 [minutes]:

The OpenBK WebApp log shows something like this when the sensor detects motion:

.

p.kaczmarek2 · Answer

In that case, I suggest you save your configuration (you can even paste it here in a reply, just use the code tag) and then set up the device so that there is only a channel with the Motion type and then retry along with listening to MQTT.

In this way, I want to eliminate the option that something gets lost or cut off somewhere.... remove unnecessary variables from the equation

DeDaMrAz · Answer

@burba

I've tried adding multiple channels to test and this is the result from my side:

Here are some hints that you can try, delete your device from HA and reboot your HA (not reload), also try and restart your OBK module before activating HA discovery.

EDIT: also change the LED channel to anything other than 1 - dInput and LED on different channels.

p.kaczmarek2 · Answer

To be sure, download the latest version:

burba · Answer

I knocked out the whole pin configuration, rebooted. I just set dinput/motion on the PIR pin - nothing changed, it still wasn't sending to the HA that. The HA itself was rebooted by me several times during all these procedures. The sensor almost every time. I decided to clear the configuration completely, blew out the Wi-Fi settings - set to open access point and lost contact with the device. It doesn't show up as an access point. I tried five launches under 5s - nothing appears either. Only the LED is on continuously. So far brick. I'll try some more - as a last resort soldering and flashing again.

p.kaczmarek2 · Answer

Something we must be leaving out relevant since it works:
- at @DeDaMrAz on BK7231N - you also have BK7231N so strange...
- at me on simulator
- at me in code in unit test, see here:
https://github.com/openshwprojects/OpenBK7231...c/selftest/selftest_hass_discovery_ext.c#L305
Generally there are now 2 situations in the tests (motion channel, motion channel + LED + dinput), code in spoiler:

Log in, to see the code

All tests pass correctly.

So there must be some other, external factor.

Maybe special characters in the names? But I don't think so, because that would make the other publishe not work either...

@burba as to the brick problem then UART RX give it to TX2 (not TX1) and see the log output at 115200. You could also upload a 2MB backup of the original flash (flasher does it by default on the read backup and flash option)

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

burba · Answer

The debug from TX2 looks like this:

޹i-
V:BK7231N_1.0.1
REG:cpsr     spsr     r13      r14
SVC:000000D3          00401C1C 000033AC
IRQ:000000d2 00000010 00401e0c ceadc727
FIR:000000d1 00000010 00401ffc 09d56de6
SYS:000000df          0040192c 00000158
ST:00000000
J 0x10000
bk_misc_init_start_type 0 0
prvHeapInit-start addr:0x414400, size:113664
[Flash]id:0xeb6015
sctrl_sta_ps_init
cset:0 0 0 0
Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 196 #######
Info:MAIN:###### safe mode activated - boot failures 59
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 516 changes count.
Info:MAIN:Main_Init_Before_Delay done

Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay

Main_Init_Delay

delaying start
bandgap_calm_in_efuse=0x63
[load]bandgap_calm=0x63->0x23,vddig=4->5
[FUNC]rwnxl_init
[bk]tx_txdesc_flush
#Startup delayed 0ms#
[FUNC]intc_init
[FUNC]calibration_main
gpio_level=1,txpwr_state=15
                           user define rfcali mode:1
get rfcali_mode:1
#Startup delayed 10ms#
#Startup delayed 20ms#
#Startup delayed 30ms#
#Startup delayed 40ms#
#Startup delayed 50ms#
#Startup delayed 60ms#
#Startup delayed 70ms#
#Startup delayed 80ms#
#Startup delayed 90ms#
#Startup delayed 100ms#
#Startup delayed 110ms#
#Startup delayed 120ms#
#Startup delayed 130ms#
#Startup delayed 140ms#
#Startup delayed 150ms#
#Startup delayed 160ms#
#Startup delayed 170ms#
#Startup delayed 180ms#
#Startup delayed 190ms#
#Startup delayed 200ms#
#Startup delayed 210ms#
#Startup delayed 220ms#
#Startup delayed 230ms#
#Startup delayed 240ms#
#Startup delayed 250ms#
#Startup delayed 260ms#
#Startup delayed 270ms#
#Startup delayed 280ms#
#Startup delayed 290ms#
#Startup delayed 300ms#
#Startup delayed 310ms#
#Startup delayed 320ms#
#Startup delayed 330ms#
#Startup delayed 340ms#
#Startup delayed 350ms#
#Startup delayed 360ms#
#Startup delayed 370ms#
#Startup delayed 380ms#
#Startup delayed 390ms#
#Startup delayed 400ms#
#Startup delayed 410ms#
#Startup delayed 420ms#
#Startup delayed 430ms#
#Startup delayed 440ms#
calibration_main over
                     flash txpwr table:0xf
dif g and n20 ID in flash:4
dif g and n40 ID in flash:4
read txpwr tab from flash success
temp in flash is:342
xtal in flash is:80
xtal_cali:80
--init_xtal = 80
                [FUNC]ps_#Startup delayed 450ms#
ielayed 450ms#
[FUNC]func_init_extended OVER!!!

start_type:0
Version:
Initializing TCP/IP stack
#Startup delayed 460ms#
app_init finished
#Startup delayed 470ms#
#Startup delayed 480ms#
#Startup delayed 490ms#
#Startup delayed 500ms#
#Startup delayed 510ms#
#Startup delayed 520ms#
#Startup delayed 530ms#
#Startup delayed 540ms#
#Startup delayed 550ms#
#Startup delayed 560ms#
#Startup delayed 570ms#
#Startup delayed 580ms#
#Startup delayed 590ms#
#Startup delayed 600ms#
#Startup delayed 610ms#
#Startup delayed 620ms#
#Startup delayed 630ms#
#Startup delayed 640ms#
#Startup delayed 650ms#
#Startup delayed 660ms#
#Startup delayed 670ms#
#Startup delayed 680ms#
#Startup delayed 690ms#
#Startup delayed 700ms#
#Startup delayed 710ms#
#Startup delayed 720ms#
#Startup delayed 730ms#
#Startup delayed 740ms#

starting....
Info:MAIN:Main_Init_Delay done

Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:###### safe mode activated - boot failures 59
Info:MAIN:Using SSID []
Info:MAIN:Using Pass []
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:[SAFE] Time 1, idle 209699/s, free 84936, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:[SAFE] Time 2, idle 142481/s, free 84936, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:[SAFE] Time 3, idle 142670/s, free 84936, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:[SAFE] Time 4, idle 142652/s, free 84936, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:[SAFE] Time 5, idle 142633/s, free 84936, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:no flash configuration, use default
Info:MAIN:set ip info: 192.168.4.1,255.255.255.0,192.168.4.1
Info:MAIN:ssid:multifunction_alarm_OpenBK7231N_E  key: mode:0
hostapd_main_exiting
hostapd_exit_handler
hostapd_exit_done
Soft_AP_start
[saap]MM_RESET_REQ
[bk]tx_txdesc_flush
[saap]ME_CONFIG_REQ
[saap]ME_CHAN_CONFIG_REQ
[saap]MM_START_REQ
hapd_intf_add_vif,type:3, s:0, id:0
rw_ieee80211_get_centre_frequency:220

.

p.kaczmarek2 · Answer

Have you moved anything with the RF partition? I've seen virtually no such errors.

burba · Answer

Consciously certainly not. Unless in the flashing software some tickbox I could have ticked. And certainly not before the flashing itself. The hardware was successfully recovered. Uploading openBeken did not help - I had to upload the tuya firmware first and then openBeken. I then uploaded the build with motion via OTA. In the meantime, I removed all MQTT from the HA and Zigbee by the way. I reinstalled from scratch, set only pin 22 to dinput, changed a few channels to motion and tried adding and deleting the device with MQTT on different channels - unfortunately without success. HA and the device were rebooted several times each. Code: text Expand Select all Copy to clipboardMessage 21 received on homeassistant/sensor/multifunction_PIR_OpenBK7231N_E1552B06_build/config at 12:00 AM: {     dev: {         ids: [             multifunction_PIR_OpenBK7231N_E1552B06         ],         name: multifunction_PIR_obkE1552B06,         sw: 1215_merge_b99f04ae6cce,         mf: Beken Corporation,         mdl: BK7231N,         cu:      },     name: Build,     ~: multifunction_PIR_obkE1552B06,     avty_t: ~/connected,     uniq_id: multifunction_PIR_OpenBK7231N_E1552B06_build,     qos: 1,     stat_t: ~/build,     entity_category: diagnostic } QoS: 0 - Retain: true Message 20 received on homeassistant/sensor/multifunction_PIR_OpenBK7231N_E1552B06_uptime/config at 12:00 AM: {     dev: {         ids: [             multifunction_PIR_OpenBK7231N_E1552B06         ],         name: multifunction_PIR_obkE1552B06,         sw: 1215_merge_b99f04ae6cce,         mf: Beken Corporation,         mdl: BK7231N,         cu:      },     name: Uptime,     ~: multifunction_PIR_obkE1552B06,     avty_t: ~/connected,     uniq_id: multifunction_PIR_OpenBK7231N_E1552B06_uptime,     qos: 1,     dev_cla: duration,     stat_t: ~/uptime,     unit_of_meas: s,     entity_category: diagnostic,     stat_cla: total_increasing } QoS: 0 - Retain: true Message 19 received on homeassistant/sensor/multifunction_PIR_OpenBK7231N_E1552B06_rssi/config at 12:00 AM: {     dev: {         ids: [             multifunction_PIR_OpenBK7231N_E1552B06         ],         name: multifunction_PIR_obkE1552B06,         sw: 1215_merge_b99f04ae6cce,         mf: Beken Corporation,         mdl: BK7231N,         cu:      },     name: RSSI,     ~: multifunction_PIR_obkE1552B06,     avty_t: ~/connected,     uniq_id: multifunction_PIR_OpenBK7231N_E1552B06_rssi,     qos: 1,     dev_cla: signal_strength,     stat_t: ~/rssi,     unit_of_meas: dBm,     entity_category: diagnostic,     stat_cla: measurement } QoS: 0 - Retain: true I'm running out of ideas

p.kaczmarek2 · Answer

As it goes on, we'll just use the publishFile command added yesterday to artificially publish JSON with the motion class: Code: text Expand Select all Copy to clipboard 1. Create LittleFS file with any string 2. Use command: PublishFile [TopicName] [FileName]  Like: PublishFile myTopic myFile.txt 1 but it shouldn't be like that, something is wrong, so we test further: Last version build: OTA: Now Motion channel: Discovery: Result - is: Try again with dInput on the same channel (4): It is: Maybe try this version what I gave the compilation? maybe you have something in the flags? .

burba · Answer

I've got the flags clear - apart from the MQTT broadcast - but I guess that's supposed to be there? Autoexec.bat, nor anything else post-brick either, I haven't done anymore. Absolute minimum.

With the latest build no change.
If I understand correctly from the screenshots, with you the dinput pin appears in the HA "sensors" panel even with the channel set to default? And the channel next to it set as "motion" appears in "sensors" even if no active pin is paired with it? Interesting

I also have a relay previously converted to OpenBeken. Everything works - but it's unlikely to do anything for us, as there are no sensors there.

I have another PIR tuya, but only yesterday after a hard battle did I manage to flash it. Interestingly the flashing worked on the three wires (GND, RX, TX), right from the GND connection, without any contact shorting or power cycle, but each time it was interrupted before the end. I guessed it was probably the TuyaMCU cutting off (even though the chip on the board looks different to the ones in the photos), plugged GND and 3.3V directly into CB3S and it finally went. Unfortunately it's nightmarishly troublesome - it keeps disconnecting from wifi. In order to connect to its AP at all and set up the MQTT and SSID of its network, I had to power the CB3S board directly again. Now it switches on to wifi every 10-15s or so for 2s or so. The OBK web interface when connected like this with an annoying hiccup but it works. Is it possible to somehow force TuyaMCU not to save power as much? I'll let you know when I manage to get it under control enough for the sensor to check in HA.

.

burba · Answer

Well, success!But not in the way anyone would expect at this point. Manually uploading a file with the fake Discovery corrected to my settings did not help. There was no trace of it at all in the MQTT logs in HA. On the other hand, on this second PIR from tuyaMCU after uploading the custom build with motion sensor it appears. And then it occurred to me that maybe just the device name is too long and doesn't come through. And bingo! All I had to do was shorten the multifunction part of the name to mf. Then, just to be sure, I restored the long name for a test and again it didn't work. But without that motion channel type you added, it doesn't show the PIR as a sensor. So that means, however, that the thread was very productive and the motion channel is needed. Now I won't swear anymore, but in this relay, whose pictures I inserted I think also openBeken loaded on just GND, RX, TX. I will read about this conversion from tuyaMCU to DeepSleep. And for future battery-powered devices I'll just take ZigBee. Big thanks!

p.kaczmarek2 · Answer

That's valuable information, but in that case, didn't you get an error in the log that the name was too long? I can increase those buffers anyway... Added after 5 [minutes]: Fixed: And to set a test to verify that it already works:

burba · Answer

Well now actually when I checked it the error was showing. Just need to know what and where to look ;-)

was like this:

Info:MAIN:Time 7501, idle 181852/s, free 71072, MQTT 1(5), bWifi 1, secondsWithNoPing 7436, socks 2/38 
Info:HTTP:HASS counts: 1 rels, 1 pwms, 1 inps, 0 excluded
Info:MQTT:Queued topic=homeassistant/light/multifunction_PIR_OBK7231N_E1552B06_light_1/config, 1 items in queue
Error:MQTT:Unable to queue! Topic (13), channel (72) or value (406) exceeds size limit
Info:MQTT:Queued topic=homeassistant/sensor/multifunction_PIR_OBK7231N_E1552B06_rssi/config, 2 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/multifunction_PIR_OBK7231N_E1552B06_uptime/config, 3 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/multifunction_PIR_OBK7231N_E1552B06_build/config, 4 items in queue

and with the short name is like this:

Info:HTTP:HASS counts: 1 rels, 1 pwms, 1 inps, 0 excluded
Info:MQTT:Queued topic=homeassistant/light/mf_PIR_OBK7231N_E1552B06_light_1/config, 1 items in queue
Info:MQTT:Queued topic=homeassistant/binary_sensor/mf_PIR_OBK7231N_E1552B06_binary_sensor_1/config, 2 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/mf_PIR_OBK7231N_E1552B06_rssi/config, 3 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/mf_PIR_OBK7231N_E1552B06_uptime/config, 4 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/mf_PIR_OBK7231N_E1552B06_build/config, 5 items in queue

.

[BK7231N] OpenBeken - How do I change the Tuya WiFi Smart PIR function from Control to Sensor?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary