Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
TL;DR: In a 15-question troubleshooting thread, the fix was twofold: add the new
Motionchannel type and shorten the device name. As one maintainer put it, "I can increase those buffers." This FAQ helps OpenBeken and Home Assistant users turn a BK7231N Tuya PIR from a wrongly discovered switch into a working motion sensor for Alarmo. [#21076203]
Why it matters: If Home Assistant discovers a PIR as a light or switch, Alarmo cannot use it as a proper motion-triggering binary sensor.
| Option | Home Assistant result | Best use case | Main limitation |
|---|---|---|---|
dInput only |
Often discovered as switch/control | Simple digital input | Not enough for Alarmo motion use |
Motion channel type |
Discovered as binary_sensor with motion class |
PIR for Alarmo | Required newer test build |
DoorSnsrWSleep |
Can sleep the device | Battery-oriented sensors | Unwanted on USB-powered PIR |
Speaker pin as LED |
Chirps only | Quick pin test | Not a real chime mode |
Speaker pin as PWM |
Speaker works | Buzzer/chime experiments | No built-in tunes yet |
Key insight: The final blocker was not only channel mapping. A long OpenBeken device name overflowed the MQTT discovery queue, so Home Assistant never received the motion
binary_sensorpayload until the name was shortened.
Motion, save the type, rerun Home Assistant Discovery, and keep the device name short enough to avoid MQTT queue overflows. In this case, shortening multifunction to mf made Home Assistant finally receive the binary_sensor discovery payload. Without the new Motion type, the PIR stayed a control or switch and Alarmo could not use it correctly. [#21076009]dInput describes the pin role, not the Home Assistant device class. The maintainer stated that if channel types are not set, OpenBeken guesses from the pins, and a pure dInput input is seen correctly by HA but not as Motion. That is why a PIR wired as dInput alone can appear as a switch or control instead of a motion binary_sensor. [#21075733]Motion channel type. The maintainer added that channel specifically so Home Assistant Discovery could publish dev_cla: motion under binary_sensor, which is the format Alarmo expects. The thread confirmed that OpenClosed and OpenClosed_Inv did not solve the problem for this PIR. [#21072973]Config -> Home Assistant Configuration -> Start Home Assistant Discovery. That exact sequence was used during testing after switching channel types. [#21073250]homeassistant/binary_sensor/.../config with "dev_cla": "motion", "pl_on": "1", and "pl_off": "0". That is what makes HA treat the entity as motion instead of a switch. [#21073728]dInput when the PIR is USB-powered and should stay awake. "dInput" is a digital-input pin role that reads binary state changes from a GPIO, without adding sleep behavior designed for low-power door or wake-up sensors. The original user explicitly chose dInput because DoorSnsrWSleep was putting a USB-powered device to sleep unnecessarily. [#21072369]PWM and tune the PWM settings, especially PWMFrequency. That immediately brought the speaker to life in the thread, and OpenBeken exposed a toggle plus a brightness slider for testing. There were no pre-programmed tunes at that time, so recreating a real ding dong required manual tuning, scripting, or writing a simple driver. [#21072769]PWM and experimenting with both fill and PWMFrequency, because frequency control determines how the buzzer sounds. The thread also notes that raw PWM controls can be exposed and automated from autoexec.bat if needed. [#21072973]homeassistant discovery topic tree. 3. Trigger OpenBeken Discovery and inspect the JSON payloads. That method let the user confirm which sensor, light, and missing binary_sensor configs were actually published. [#21073815]binary_sensor. The final diagnosis showed a name-length issue, so the motion payload path or value exceeded the internal queue size while smaller diagnostic entities still published. [#21076385]Error:MQTT:Unable to queue! Topic (13), channel (72) or value (406) exceeds size limit. With the long name, the motion payload never queued; with the shortened name, the binary_sensor topic queued normally. [#21076385]multifunction_PIR... to mf_PIR... changed the result immediately: the short-name logs showed homeassistant/binary_sensor/.../config queued successfully, while the long-name logs did not. That difference directly determined whether Home Assistant created a motion sensor. [#21076385]publishFile homeassistant/binary_sensor/WinTest_3145CAFF_binary_sensor_1/config myFile.txt 1. The maintainer gave that exact pattern as a workaround for manually publishing a dev_cla: motion discovery packet. [#21075733]myFile.txt, which contained a custom Home Assistant discovery JSON later sent with the publishFile command. [#21075733]