logo elektroda
logo elektroda
X
logo elektroda

[Solved] Corrupted partition? wifi_state_valid always 0 no matter the tuyaMcu_defWiFiState value

paoliniluis 1005 17
ADVERTISEMENT
  • #1 21071360
    paoliniluis
    Level 4  

    My device is a 3Phase Hiking Tomzn Power Meter DTS238-7, very similar to all tomzn devices posted here. No matter the value I insert on tuyaMcu_defWiFiState (0,1,2,3,4,5), the health check will always say:

    "ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0"

    I have run out of options by now and I really don't know what else to do.

    Some interesting facts that may or may not be relevant:
    1) when this device connects to the WiFi, a blue LED will blink or be fixed on the top right of the device, but this never happens
    2) the device IS connected to the WiFi network, even connects to MQTT if needed
    3) tried wiping all the config several times, even removing the WiFi config, but no luck
    4) tried going to ESPHome and then back, but no luck

    The reason for all this is that the device is sending bogus data on dpid 6,7 and 8 (the dpids that have the voltage, current and power readings), and I read that these tuya devices need to believe that they're connected to start sending real data (just FYI: the device readings on the device screen are fine, the problem is on the readings of the TuyaMCU chip)

    Is there any way of flashing these devices completely from zero via the web? like flashing all partitions and starting from a clean slate. I don't have any tools to flash via pins
  • ADVERTISEMENT
  • #2 21071399
    p.kaczmarek2
    Moderator Smart Home
    Would you be able to flash back original Tuya firmware and do the capture? https://www.elektroda.com/rtvforum/topic3970199.html

    What does the device return when you run tuyaMcu_sendQueryState?

    How do you know that there is bogus data on dpID 6, 7 and 8, maybe they changed dpIDs for your device and this data is something else?

    You can reset OBK with clearConfig command.

    Have you tried running tuyaMcu_defWiFiState at runtime? Maybe you are assigning this command before you start the TuyaMCU driver?

    Have you tried playing around with other commands, like tuyaMcu_sendRSSI?
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 21071409
    paoliniluis
    Level 4  
    Thanks for the super quick answer. Unfortunately I don't have the original firmware (is there anywhere I can get it?)

    Just sent tuyaMcu_sendRSSI, still got the wifi_state_valid in zero
    ```
    Debug:API:POST to api/cmnd
    Debug:CMD:cmd [tuyaMcu_sendRSSI]
    Info:CMD:[WebApp Cmd 'tuyaMcu_sendRSSI' Result] OK
    Info:MQTT:mqtt_host empty, not starting mqtt
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    Info:MAIN:Time 245, idle 241459/s, free 76608, MQTT 0(16), bWifi 1, secondsWithNoPing 181, socks 2/38 
    Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 01 02 00 04 00 00 00 08 20 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 1 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 8
    Info:GEN:No change in channel 4 (still set to 8) - ignoring

    ```

    This is what it returns when I send tuyaMcu_sendQueryState
    ```
    3 07 00 08 01 02 00 04 00 00 00 08 20 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 1 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 8
    Info:TuyaMCU:Received: 55 AA 03 07 00 13 06 00 00 0F 00 00 00 00 00 00 00 00 03 E8 00 00 00 09 1B 40 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 26
    Info:TuyaMCU:ParseState: id 6 type 0-raw len 15
    Info:TuyaMCU:Received: 55 AA 03 07 00 13 07 00 00 0F 00 00 00 00 00 00 00 00 03 E8 00 00 00 00 00 1D 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 26
    Info:TuyaMCU:ParseState: id 7 type 0-raw len 15
    Info:TuyaMCU:Received: 55 AA 03 07 00 13 08 00 00 0F 00 00 00 00 00 00 00 00 03 E8 00 00 00 00 00 1E 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 26
    Info:TuyaMCU:ParseState: id 8 type 0-raw len 15
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 0B 01 00 01 00 1B 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU:ParseState: id 11 type 1-bool len 1
    Info:TuyaMCU:ParseState: byte 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 0D 02 00 04 00 00 00 00 24 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 13 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 10 01 00 01 01 21 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU:ParseState: id 16 type 1-bool len 1
    Info:TuyaMCU:ParseState: byte 1
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 65 02 00 04 00 00 00 08 84 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 101 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 8
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 66 02 00 04 00 00 00 00 7D 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 102 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 67 02 00 04 00 00 00 00 7E 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 103 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 69 02 00 04 00 00 13 87 1A 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 105 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 4999
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 6A 02 00 04 00 00 00 01 82 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 106 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 1
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 6D 02 00 04 00 00 00 04 88 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 109 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 4
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 6E 02 00 04 00 00 00 00 85 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 110 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 6F 02 00 04 00 00 03 E8 71 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 111 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 1000
    Info:TuyaMCU:Received: 55 AA 03 07 00 22 11 00 00 1E 00 00 00 00 00 00 00 00 00 11 00 64 11 00 FA 11 00 C8 11 00 00 01 00 0A 10 00 0A 00 00 00 E9 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 41
    Info:TuyaMCU:ParseState: id 17 type 0-raw len 30
    Info:TuyaMCU:Received: 55 AA 03 07 00 15 12 00 00 11 00 05 00 1E 00 05 00 1E 00 3C 00 00 00 00 00 00 00 C3 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 28
    Info:TuyaMCU:ParseState: id 18 type 0-raw len 17
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 09 05 00 01 00 1D 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU:ParseState: id 9 type 5-bitmap len 1
    Info:TuyaMCU:ParseState: byte 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 10 6C 03 00 0C 30 30 30 30 30 30 30 30 30 30 30 30 D4 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 23
    Info:TuyaMCU:ParseState: id 108 type 3-str len 12
    Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8

    ```
    DPId 6,7 and 8 have the exact same length and those 3 come raw along 17 and 18 (which are alarms). Exactly the same as the TOMZN TOMPD-63-LW, but instead of monitoring 1 phase, it monitors 3 (dpid 6,7 and 8)

    I say that there's bogus data since the values in DP Id 6 (the one I have connected right now) doesn't show anything (see image). While I see values in the device display

    [url=https://obrazki.elektroda.pl/1938128000_1714948615.png]View of the MGF-T3-SMART electrical meter with a display showing a value of 232.7 V.
    OpenBK7231T user interface with buttons and energy statistics.[/url]

    I also tried to set up tuyaMcu_defWiFiState at runtime, here are the results (still wifi_state_valid = 0):
    ```
    Debug:CMD:cmd [tuyaMcu_defWiFiState 4]
    Info:CMD:[WebApp Cmd 'tuyaMcu_defWiFiState 4' Result] OK
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    ExtraDebug:TuyaMCU:Will send TUYA_CMD_WIFI_STATE.
    Info:MAIN:Time 1004, idle 246071/s, free 76344, MQTT 0(63), bWifi 1, secondsWithNoPing 940, socks 3/38 
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    Info:MAIN:Time 1005, idle 243041/s, free 76576, MQTT 0(63), bWifi 1, secondsWithNoPing 941, socks 2/38 
    Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    ExtraDebug:TuyaMCU:Will send TUYA_CMD_WIFI_STATE.
    Info:MAIN:Time 1006, idle 492100/s, free 76576, MQTT 0(63), bWifi 1, secondsWithNoPing 942, socks 2/38 
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    ExtraDebug:TuyaMCU:Will send TUYA_CMD_WIFI_STATE.
    Info:MAIN:Time 1007, idle 247245/s, free 76576, MQTT 0(63), bWifi 1, secondsWithNoPing 943, socks 2/38 
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    ExtraDebug:TuyaMCU:Will send TUYA_CMD_WIFI_STATE.
    Info:MAIN:Time 1008, idle 244760/s, free 76344, MQTT 0(63), bWifi 1, secondsWithNoPing 944, socks 3/38 
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    Info:MAIN:Time 1009, idle 241695/s, free 76576, MQTT 0(63), bWifi 1, secondsWithNoPing 945, socks 2/38 
    Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0
    ExtraDebug:TuyaMCU:Will send TUYA_CMD_WIFI_STATE.
    Info:MAIN:Time 1010, idle 248586/s, free 76576, MQTT 0(63), bWifi 1, secondsWithNoPing 946, socks 2/38 
    Info:GEN:dhcp=0 ip=192.168.2.211 gate=192.168.2.1 mask=255.255.255.0 mac=a0:92:08:ba:1d:b6

    ```

    This is my config:
    ```
    clearIO
    
    flags 0
    
    SetFlag 46 1
    
    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    
    tuyaMcu_defWiFiState 4
    
    linkTuyaMCUOutputToChannel 19 str 0
    setChannelType 0 ReadOnly
    setChannelLabel 0 "Breaker ID"
    
    linkTuyaMCUOutputToChannel 16 bool 1
    setChannelType 1 toggle
    setChannelLabel 1 "On/Off"
    
    linkTuyaMCUOutputToChannel 11 bool 2
    setChannelType 2 toggle
    setChannelLabel 2 "Prepayment"
    
    linkTuyaMCUOutputToChannel 12 bool 3
    setChannelType 3 toggle
    setChannelLabel 3 "Clear Energy Counter"
    
    // Total energy - Dpid 1 "total_forward_energy" -> channel 4
    linkTuyaMCUOutputToChannel 1 val 4
    setChannelType 4 EnergyTotal_kWh_div100
    setChannelLabel 4 "Total Energy"
    
    linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
    setChannelType  5 Voltage_div10
    setChannelLabel 5 "Phase_A_Voltage"
    setChannelType 6 Power
    setChannelLabel 6 "Phase_A_Power"
    setChannelType 7 Current_div1000
    setChannelLabel 7 "Phase_A_Current"
    
    linkTuyaMCUOutputToChannel 7 RAW_TAC2121C_VCP
    setChannelType 8 Voltage_div10
    setChannelLabel 8 "Phase_B_Voltage"
    setChannelType 9 Power
    setChannelLabel 9 "Phase_B_Power"
    setChannelType 10 Current_div1000
    setChannelLabel 10 "Phase_B_Current"
    
    linkTuyaMCUOutputToChannel 8 RAW_TAC2121C_VCP
    setChannelType 11 Voltage_div10
    setChannelLabel 11 "Phase_C_Voltage"
    setChannelType 12 Power
    setChannelLabel 12 "Phase_C_Power"
    setChannelType 13 Current_div1000
    setChannelLabel 13 "Phase_C_Current"

    ```

    thank you very much for your help
  • #4 21080167
    paoliniluis
    Level 4  

    Anyone that can lend me a hand here about what could be the next steps? I'm now wondering if flashing the bin file in https://www.elektroda.com/rtvforum/topic3928897.html might restore any functionality? BTW: I flashed ESPHome to the device and the wifi light is not working either, so I came back to OpenBeken.

    Pictures of disassembly below:
    Image of the interior of an electronic device with a circuit board and LCD screen. Main circuit board of an electronic device with connected cables. Image showing a disassembled electronic device with a visible circuit board and wires. Interior of an electronic device with a visible circuit board and components. The image shows an electronic circuit board with connected wires and a module labeled as VMS Model.
  • ADVERTISEMENT
  • #5 21080213
    divadiow
    Level 34  
    paoliniluis wrote:
    Anyone that can lend me a hand here about what could be the next steps? I'm now wondering if flashing the bin file in https://www.elektroda.com/rtvforum/topic3928897.html might restore any functionality?

    the dump on that thread doesn't appear to be viable. are you able to post the tuya config file?

    Screenshot of the Google homepage in a web browser with a dark theme.
  • #7 21081402
    divadiow
    Level 34  
    dunno if this is any help or what next.

    Code: Text
    Log in, to see the code


    Regarding the factory firmware flash, I haven't found an identical device dump anywhere I don't think.
  • #8 21081414
    paoliniluis
    Level 4  
    thanks a lot for the help :(
  • ADVERTISEMENT
  • #9 21081636
    p.kaczmarek2
    Moderator Smart Home
    Do you have manual for this device? How does one put it into pair mode with Tuya firmware?

    Maybe you need to press some buttons or hold them so it first starts the pair procedure and then fake the pairing in OBK?
    Helpful post? Buy me a coffee.
  • #10 21082222
    paoliniluis
    Level 4  
    I wrote to the Tomzn people to ask for original firmware and instead they sent me what it seems like an internal document about how everything works. I have never seen this anywhere and it seems like a very detailed document about the protocol and the inner workings of the device. As I can't upload PDF files I just dropped this in a Google Drive link https://drive.google.com/file/d/1pOQNOxHj9cfDyrLmk56bH8ntE5k6Ar_d/view?usp=drive_link

    BTW: the way to "pair" this device with the original tuya firmware was to press the "down" button next to the screen for a few seconds till the blue light started to blink and then from the tuya app you would connect to the device and pair it. Now if I do the same with OpenBeken it just shows an icon on the screen and it will never turn on the blue light
  • #11 21093949
    paoliniluis
    Level 4  

    Hi there! has anyone been able to check what I sent and give me any advice? thanks!
  • #12 21094089
    p.kaczmarek2
    Moderator Smart Home
    Are you really sure you didn't enable tmSensor by accident?

    That pdf is normal TuyaMCU, it says it should support 0x03:
    Fragment of a communication instruction table for TuyaMCU, including Wi-Fi status information.
    Maybe try manually calling tuyaMcu_sendCmd 0x03 04?
    Or do:
    
     uartSendHex 55AA000300010407 
    

    which is the same as the other command I shown.
    If you search for it, you can read that it helped people:
    https://www.elektroda.com/rtvforum/find.php?q=55AA000300010407
    Helpful post? Buy me a coffee.
  • #13 21095905
    paoliniluis
    Level 4  

    A few things I discovered while sending uartSendHex commands: the device believes it's in AP mode even if the device is already connected to the WiFi without any problem:

    Info:MAIN:Time 531, idle 249266/s, free 77696, MQTT 1(1), bWiFi 1, secondsWithNoPing 462, socks 3/38
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, WiFi_state_valid = 0, WiFi_state_timer=0
    ExtraDebug:TuyaMCU:Will send TUYA_CMD_WIFI_STATE.
    Info:MAIN:Time 532, idle 253079/s, free 77912, MQTT 1(1), bWiFi 1, secondsWithNoPing 463, socks 2/38
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, WiFi_state_valid = 0, WiFi_state_timer=0
    Info:MAIN:Time 533, idle 252139/s, free 77912, MQTT 1(1), bWiFi 1, secondsWithNoPing 464, socks 2/38
    Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Heartbeat) len 8

    I sent uartSendHex 55AA0005000004 (check if it's in smart network config or AP mode), and it replies with 55 AA 03 00 00 01 01 04 (AP mode)

    sending a uartSendHex 55AA000300010407 makes no difference, the device stays in WiFi_state_valid = 0, and won't provide any valid data in that state

    it's wild that the device is connected to the wireless network, with an IP and everything, but it still believes that it's in AP mode.

    any other idea? BTW: I tested basically everything on the document, but there's one that I can't make it work which is "resetting the WiFi"; I send fakeTuyaPacket 55AA0304000006 but it replies with

    Debug:CMD:cmd [fakeTuyaPacket 55AA0304000006]
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 4 (WiFiReset) len 7
    Info:TuyaMCU:ProcessIncoming: unhandled type 4
    Info:CMD:[WebApp Cmd 'fakeTuyaPacket 55AA0304000006' Result] OK

    I don't know what the "unhandled type 4 means"
  • #14 21100845
    p.kaczmarek2
    Moderator Smart Home
    Btw, are you doing full power off and power on cycle between autoexec.bat changes? It seems to be important, I've just had another user saying that was the cause of his problems...

    Your logs indicate that packet 0x04 is not handled by OBK, let's look it up...
    Screenshot of an MCU command table with command 0x04 highlighted.
    Let me try adding it....
    https://github.com/openshwprojects/OpenBK7231...mmit/041e316cf51d13b0e48409e720f474d228e606a1
    Wait for build, do OTA and try again.
    Helpful post? Buy me a coffee.
  • #15 21100928
    paoliniluis
    Level 4  

    Thanks! I tried the new version and sending fakeTuyaPacket 55AA0304000006

    Debug:CMD:cmd [fakeTuyaPacket 55AA0304000006]
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 4 (WiFiReset) len 7
    Info:TuyaMCU:ProcessIncoming: 0x04 replying
    Info:CMD:[WebApp Cmd 'fakeTuyaPacket 55AA0304000006' Result] OK
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 0, wifi_state_valid = 0, wifi_state_timer=0


    but I still get the wifi_state_valid = 0 after sending both the fakeTuyaPacket + tuyaMcu_defWiFiState 4
  • #16 21101029
    p.kaczmarek2
    Moderator Smart Home
    And requesting dpIDs (with query state) still yields no useful data?
    Helpful post? Buy me a coffee.
  • #17 21437858
    paoliniluis
    Level 4  
    The light needed to be on for the device to report the data
  • #18 21437864
    p.kaczmarek2
    Moderator Smart Home
    Helpful post? Buy me a coffee.

Topic summary

The discussion revolves around issues with a 3Phase Hiking Tomzn Power Meter DTS238-7, specifically regarding the persistent "wifi_state_valid = 0" despite various attempts to set the tuyaMcu_defWiFiState value. The device appears to connect to WiFi and MQTT but does not indicate a proper connection through the LED. Users suggest flashing the original Tuya firmware, checking the device's response to commands like tuyaMcu_sendQueryState and tuyaMcu_sendRSSI, and ensuring proper configuration resets. The conversation also touches on the possibility of the device being in AP mode and the need for a full power cycle after configuration changes. A detailed internal document about the device's protocol was shared, and users are exploring commands to troubleshoot the issue further.
Summary generated by the language model.
ADVERTISEMENT