logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Tasmota & OpenBeken Device Group: Relay 3 Sync for test_luce via DGR_SendPower

User question

openbecken setting relay 3 to tasmota device group test luce

Artificial Intelligence Response

Direct answer to the question

• Activate Device-Groups on the Tasmota side with
SetOption85 1
• Put all participants (Tasmota and OpenBeken) in the same group, e.g.
DevGroupName1 test_luce (avoid spaces in practice → test_luce)
• Tie Relay 3 of every Tasmota node that must react:
DevGroupTie1 3
• From the OpenBeken sender publish the power packet:
DGR_SendPower test_luce 3 <state>
where <state> = 0 (OFF), 1 (ON) or 2 (TOGGLE).

Detailed problem analysis

Device-Groups (DGR) are a Tasmota / OpenBeken UDP-multicast protocol (port 4447) that allows server-less, sub-millisecond synchronisation of relays, lights and sensors.
Key elements in your scenario:

  1. Group name – a plain ASCII string (no spaces recommended) that is written into DevGroupName1 … DevGroupName4. Every packet carries this string; only nodes with an identical string will accept it.
  2. Channel binding – DevGroupTie<x> <relay> links an individual relay (or PWM channel) to group <x> so that incoming packets operate the correct output.
  3. Packet transmitter – any device (Tasmota or OpenBeken) may send a packet with DGR_SendPower (OpenBeken) or an ordinary local relay change (Tasmota).
  4. Network – UDP broadcast; therefore all devices must sit on the same Wi-Fi subnet and the access point / router must allow broadcast traffic.

Sequence to realise “Relay 3 ↔ group test luce”:

A. Tasmota node(s) that should switch:

 SetOption85 1 // enable Device-Groups
DevGroupName1 test_luce // register in group 1
DevGroupTie1 3 // bind Relay3 to that group

B. OpenBeken command transmitter (e.g., a wall switch): • Web UI → Commands:
DGR_SendPower test_luce 3 1 (turn ON)
DGR_SendPower test_luce 3 0 (turn OFF)
DGR_SendPower test_luce 3 2 (toggle)

Internally OpenBeken builds the UDP frame
{ cmd:"POWER3", value:"ON" } and broadcasts it to 224.0.0.0:4447; all devices in group test_luce execute the change.

Current information and trends

• Device-Groups were introduced in Tasmota 8.2 and are now a quasi-standard for fast, broker-less room automations.
• OpenBeken (BK7231T/N) implements a fully compatible stack, plus extra helper commands (DGR_SendPower, DGR_SendColor, scripting events).
• Firmware builds from 2023-12 onward auto-retry lost packets and show DGR traffic in the web console, which simplifies debugging.

Supporting explanations and details

• Why avoid spaces? Some builds strip spaces, others don’t; using test_luce guarantees identical matching across firmware versions.
• DevGroupShare is not required for simple relay mirroring; DevGroupTie is the modern, explicit way.
• Unlike MQTT group topics, DGR messages stay inside the LAN, minimising latency (<10 ms typical) and broker load.

Example work-flow test

  1. Open two browser tabs, one to the OpenBeken console, one to the Tasmota console.
  2. Run DGR_SendPower test_luce 3 2.
  3. In Tasmota you should see
    DGR: Packet RX grp:test_luce cmd:POWER3 val:TOGGLE
    followed by the usual STAT … "POWER3":"ON" or "OFF" line.

Ethical and legal aspects

• Switching mains-powered loads must comply with local electrical codes; ensure devices are CE/UL-listed if used in residential/commercial environments.
• Broadcasting raw UDP inside a corporate Wi-Fi may violate IT policies; obtain permission before deployment.

Practical guidelines

Best practices • Keep firmware versions reasonably aligned (Tasmota ≥ 12.0, OpenBeken ≥ 1.17) to avoid subtle protocol changes.
• Document group names and relay bindings to prevent collisions in larger installations.
Potential pitfalls • Some enterprise APs block multicast/broadcast by default → enable “Wireless multicast forwarding”.
• If a unit must send only without reacting, leave its DevGroupTie unset or use DevGroupTie1 255.

Possible disclaimers or additional notes

• Device-Groups do not provide encryption; anyone on the same subnet can inject packets. For secure sites use MQTT with TLS instead.
• Firmware bugs: Early Tasmota 13.0 builds had a Relay >4 offset bug; update if you see mis-aligned channels.

Suggestions for further research

• Evaluate the new DGR_Sync frame type for synchronising dimmer levels alongside relay states.
• Experiment with OpenBeken scripts to create complex scenes (e.g., long-press button → DGR_SendPower test_luce 3 2).
• Watch the Tasmota GitHub issue tracker for the planned “encrypted DGR” option.

Brief summary

Tie every target Tasmota relay 3 to Device-Group 1 (SetOption85 1, DevGroupName1 test_luce, DevGroupTie1 3).
On the OpenBeken side issue DGR_SendPower test_luce 3 x where x is 0/1/2.
Ensure all devices share the same Wi-Fi subnet and broadcast is permitted.
This setup achieves instantaneous, broker-less synchronised switching of Relay 3 across all members of the test_luce group.

User question

i have openbecken 4 gang wall switch with 4 relay and tasmota 1 gang wall switch 1 relay. I want use device group luce_bombola with only relay number 3 of openbecken device and tasmota device

Artificial Intelligence Response

Direct answer to the question

• Use Tasmota / OpenBeken “Device Groups (DGR)” and bind only the required channels.
• Commands to enter from each device’s web-console:

OpenBeken (4-gang, only relay 3 in the group) 

DevGroupName1 luce_bombola // join group #1
DevGroupTie1 3 // bind relay-3 ⇄ group-1

Tasmota (1-gang, its single relay in the group) 

SetOption85 1 // enable Device Groups (reboots once)
DevGroupName1 luce_bombola // same group name, slot #1
DevGroupTie1 1 // bind relay-1 ⇄ group-1

After a reboot:
• Toggling Relay-3 on the OpenBeken switch or Relay-1 on the Tasmota switch immediately mirrors the state to the other device.
• Relays 1, 2 and 4 on the OpenBeken unit stay completely independent.

Detailed problem analysis

  1. Device Groups (DGR)
    • UDP-multicast protocol (default 224.0.0.0:4447) introduced in Tasmota v8.2; native in recent OpenBeken builds.
    • No MQTT/Broker required → sub-20 ms peer-to-peer reaction.

  2. Mapping relays to a group
    DevGroupTieN \<local-relay-index>
    • Index “1…8” → which relay of the device participates.
    • Index “255” → “ignore” (receive none / send none).
    Example (not required for you): DevGroupTie2 255 would explicitly exclude another relay from group 2.

  3. Flow of events (physical press or SW command)
    a. Press button connected to Relay-3 → OpenBeken changes local relay.
    b. Firmware sends { "grp":"luce_bombola","cmd":"POWER3","val":"ON" } via multicast.
    c. Tasmota receives packet, checks DevGroupName1, finds DevGroupTie1 1 and applies the command to its own Relay-1.
    d. Tasmota re-broadcasts the final state (unless SetOption89 1 = suppress) so both devices stay in sync even after packet loss.

  4. Optional direct software command
    From any console:
    DGR_SendPower luce_bombola 3 2 → toggle both relays (3 ⇄ 1) without touching the other channels.

Current information and trends

• OpenBeken nightlies ≥ 1.17.x and Tasmota ≥ 12.x maintain full inter-operability in mixed BK72xx / ESP8266 / ESP32 networks.
• Upcoming Tasmota 14. x stream adds TLS-capable Device Groups (encryptable multicast) – might remove the need for secured SSID isolation.
• Community is shifting from MQTT-centred topologies toward local broadcast (Matter, Thread, DGR) to reduce hub latency and single-point failures.

Supporting explanations and details

• Relay numbering is 1-based (POWER1 … POWER4).
• SetOption85 is only required on Tasmota; OpenBeken ships with DGR compiled-in and enabled.
• If you later need OpenBeken to send but not listen to the group, use DevGroupSend1 1 / DevGroupRecv1 0.
• Wi-Fi isolation, guest VLANs or “AP-isolation” will block the multicast – disable for these IoT clients or allow mDNS/UDP broadcast.

Ethical and legal aspects

• Local-only multicast keeps data inside your LAN – no cloud exposure, good for privacy-by-design.
• Still, UDP traffic can be sniffed by anyone on the same subnet; use WPA2/WPA3 and a dedicated IoT VLAN if tamper-resistance is critical.
• Always comply with local electrical codes when working inside mains-powered wall switches.

Practical guidelines

• Firmware versions
– Tasmota: status 0 => “Version 12.x.x” or newer.
– OpenBeken: web footer shows build ≥ 1.17.
• Reboot both devices after issuing the commands.
• In each console run DevGroupStatus to verify: 

 Group 1 : Name luce_bombola Tie 3 (or Tie 1)

• Packet sniff (optional): tcpdump -n udp port 4447 on a laptop to confirm multicast frames.

Possible disclaimers or additional notes

• Home-assistant auto-discovery does not track DGR state! If you need HA to reflect the new mirror, expose either device and treat it as the authoritative sensor, or enable MQTT in parallel.
• UDP multicast is connection-less – there is no ACK; if Wi-Fi is weak you may observe the occasional missed sync. Re-transmission code is being discussed for future firmware.

Suggestions for further research

• Test SetOption86 (device-to-group telemetry sharing) if you later want power-consumption or button-event replication.
• Evaluate Matter-over-WiFi or ESP-Now for battery-operated nodes where UDP multicast is too power-hungry.
• Track GitHub issue #18666 (Tasmota) for TLS-encrypted Device Groups roadmap.

Brief summary

Bind both devices to the same Device Group name (luce_bombola) and tie only the desired relays (3 on OpenBeken, 1 on Tasmota). With:

OpenBeken 

DevGroupName1 luce_bombola
DevGroupTie1 3

Tasmota 

SetOption85 1
DevGroupName1 luce_bombola
DevGroupTie1 1

the two relays operate in perfect unison, while all other channels remain unaffected—achieving the exact behaviour you requested with no MQTT broker and minimal latency.

User question

i have openbecken 4 gang wall switch with 4 relay and tasmota 1 gang wall switch 1 relay. I want use device group luce_bombola with only relay number 3 of openbecken device and tasmota device DevGroupName1 luce_bombola DevGroupTie1 3 they aren't command of openbecken

Artificial Intelligence Response

Direct answer to the question

  • DevGroupNameNN / DevGroupTieNN are Tasmota-only commands.
  • In OpenBeken you must configure Device-Groups with the DGR_… console commands or the Device-Group page in the Web UI.
  • For your case (relay 3 of the 4-gang OpenBeken ↔ relay 1 of the 1-gang Tasmota) the minimal working commands are:

OpenBeken (console or “Backlog” line) 

setChannelType 2 Relay_n # make sure all relays are declared
setChannelType 3 Relay_n
setChannelType 4 Relay_n
setChannelType 5 Relay_n # relay-3 is usually channel-5
DGR_SetName luce_bombola # group name
DGR_SetChannel 5 1 # tie channel-5 (relay-3) to group-slot-1

Tasmota (console) 

SetOption85 1 # enable Device-Groups
DevGroupName1 luce_bombola # same group name
DevGroupTie1 1 # tie relay-1 to slot-1

After saving/rebooting, toggling either relay updates the other, while the remaining three relays on the OpenBeken stay independent.

Detailed problem analysis

  1. Channel vs. relay numbering in OpenBeken
    • Logical channels start at 2 when a button matrix is present; for most 4-gang switches
    ‑ relay-1 → ch-2 - relay-2 → ch-3 - relay-3 → ch-4 or ch-5¹ - relay-4 → ch-5 or ch-6¹
    • Run channels or watch the main page to see which channel changes when you press relay-3 to be sure.
    • Substitute that channel number in DGR_SetChannel <channel> 1.

  2. Device-Group primitives in OpenBeken
    • DGR_SetName <name>   Assigns the group name (one per slot).
    • DGR_SetChannel <ch> <slot> Binds a local channel to that slot (1-4).
    • DGR_SendPower <name> <ch> <state> can be used for scripting or testing.
    • All parameters can also be set visually under Config → Device Groups.

  3. Tasmota side
    • Device-Groups were introduced in 8.2, improved since 12.x; keep firmware current.
    • SetOption85 1 must be ON for every Tasmota that participates.
    • DevGroupTieN X supports bit-fields, but “1” is enough for a single-relay module.

  4. Network requirements
    • UDP multicast/broadcast on port 4447 must be allowed between the two IP addresses.
    • Some mesh or enterprise Wi-Fi APs suppress multicast; if status packets are lost, enable “multicast-enhance” or IGMP-snooping-bypass in the router.

  5. Behaviour matrix

Action Expected result
Toggle relay-3 on OpenBeken Tasmota relay-1 follows within <100 ms
Toggle relay-1 on Tasmota OpenBeken relay-3 mirrors
Toggle any other OpenBeken relay No effect on Tasmota
Power-cycle either device State resynchronises automatically

Current information and trends

• OpenBeken v1.17.x added a full Device-Group GUI; console commands remain for scripting/REST.
• Tasmota 13.x introduced encrypted Device-Groups (key negotiation over UDP); OpenBeken support is on the roadmap but not merged yet – keep encryption disabled for now.
• Both projects are moving toward Matter/CHIP bridges; Device-Groups will likely coexist as a light-weight intra-LAN alternative.

Supporting explanations and details

Why not use MQTT?
Device-Groups operate locally without a broker, giving sub-100 ms latency and continuing to work when the Internet or your broker is down. They are ideal for basic “follow-me” lighting or three-way-switch logic.

Relay mapping pitfalls
Tuya often routes relays through a BK7231 “matrix” driver; therefore OBK channels start at 2. If you see unexpected channels, run:

loglevel 3
setPinRole ? # lists all pins and roles

and adjust the DGR_SetChannel line.

Ethical and legal aspects

• Always test on the bench first; inadvertent cross-linking of high-power loads could pose a fire hazard.
• In jurisdictions where mains rewiring requires certification, ensure that replacing firmware does not void compliance.

Practical guidelines

Implementation checklist
☑ Same SSID / subnet
☑ Firmware versions supporting Device-Groups
☑ Correct channel ↔ relay mapping verified
☑ Multicast allowed on AP
☑ Reboot both nodes after final save

Troubleshooting
‐ Run DGR_Debug 1 (OpenBeken) and DevGroupStatus 1 (Tasmota) to view live packets.
‐ If packets are seen but actions are ignored, re-check SetOption85 or DGR_SetChannel assignment.

Possible disclaimers or additional notes

• Some early OpenBeken builds (≤ 1.15) lack Device-Group code; upgrade if the menu is missing and DGR_* returns “unknown command”.
• Channel numbers above assume no RGB/PWM outputs are declared; mixed-type boards may shift numbering.

Suggestions for further research

• Test OpenBeken’s upcoming TLS-secured multicast (branch dgr-secure).
• Investigate bridging Device-Groups to Home-Assistant via an ESPHome node for scene feedback.
• Evaluate replacing UDP with CoAP multicast for reduced broadcast storms on large installations.

Brief summary

Use DGR_… on OpenBeken and DevGroup… on Tasmota.
Bind only the OpenBeken channel that represents physical relay-3 to group slot-1, and bind Tasmota’s single relay to the same slot. Confirm multicast connectivity, then both relays will stay synchronised while the remaining OpenBeken relays remain independent.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.
Report illegal content (Article 16 DSA)