logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Experience? / ONENUO 228WTH Smoke Detector with Temp/Humidity: OBK Flashing, Chip Info, Battery Life

io2345 984 44
ADVERTISEMENT
Reply | New topic
  • #31 21590440
    p.kaczmarek2
    Moderator Smart Home  
    Almost, but not exactly. I know it's inconvenient, because I went through this when doing previous TuyaMCu topics, including this presentation:
    [CB3S/BK7231N] Temperature/Humidity Sensor with TuyaMCU - Diagram, Reverse Engin
    but you need to manually order those packets. Our Analyzer tool is not quick enough to maintain order.
    You can use information from article linked above, especially this paragraph:
    Experience? / ONENUO 228WTH Smoke Detector with Temp/Humidity: OBK Flashing, Chip Info, Battery Life
    Honestly I don't even remember myself this protocol well at the moment, but it is also described on Tuya site, I'll attach the link if I find it.

    So, the basic workflow for solving your issue would be:
    1. create a clearly described, step by step log of communication with TuyaMCU on Tuya device - but not unsorted, like you posted
    2. create the same for OBK
    3. Figure out exactly at which point of time communication breaks, i.e. which exactly packet is sent by OBK incorrectly
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21590469
    io2345
    Level 8  
    I see. Let me try it a last time. I can use the existing logs for that, right? Just sort them.

    Still not convinced, that the communication breaks. The Wifi-module isn't powered longer with stock firmware, but they manage to transfer data. MQTT is probably not the best way to do it, it seems too slow. Is there no other way to transfer the data?

    Furthermore it is still unclear, why the TuyaMcu_setBatteryAckDelay doesn't work although supposed to do.
  • ADVERTISEMENT
  • #33 21591177
    io2345
    Level 8  
    Have a look, is that ok? (Better check in the Excel-File, as in PDF some lines are missing. But fields are identical)
    Of course, for the short wakeup a lot of the function is missing. But even for the long wakeup, there is one line of the connection status missing. And that's probably the reason, why in the webpage log this line appears (the last one):

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:Received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:ProcessIncoming[v=0]: cmd 2 (MCUconf) len 7
Info:TuyaMCU:ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
    Attachments:
  • #34 21592854
    io2345
    Level 8  
    It's quite obvious that this task is too hard - at least for summer time ;-).
    I think I should opt for this device: Link on elektroda forum
    It delivers these values, that I need: Temperature and VOC (in time, to prevent battery from burning), CO2 and CH2O (if it is already burning). Sadly the device has no alarm function itself, but I will build something in ioBroker.
  • ADVERTISEMENT
  • #35 21594427
    io2345
    Level 8  
    >>21590440 Is this log-message generated by OBK, or by the MCU - and what does it mean? Is there something missing?:

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:ProcessIncoming[v=0]: cmd 2 (MCUconf) len 7
Info:TuyaMCU:ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!


    What is "To do"?

    These two lines are the last on each short power-up cycle of the WiFi-module (if it's not by chance). So that should be where the communication breaks.
    Is there anything that can be done about it?
  • #36 21599554
    io2345
    Level 8  
    >>21594427 I going to send the device back by end of this week. So, if we want to check something more, we should do it now.

    To be honest, I'm a little disillusioned. I thought, that every Tuya-device can be converted to and run with OBK. Now I see, it is not necessarily true.
  • #37 21599574
    p.kaczmarek2
    Moderator Smart Home  
    Every device can be converted, it's just that battery-powered devices are much harder to convert and require more work, and not much work is done on them futher because WiFi hardware is not efficient enough for battery-powered devices anyway when there is also a Zigbee option.

    Those packets in PDFs are sorted?

    So you are saying that OBK is not sending
    Code: text Expand Select all Copy to clipboard
    
55 AA 00 02 00 01 02 04
HEADER VER=00 McuConf LEN 02 CHK
    ?

    Maybe we can also ping @DeDaMrAz , he was creating the previous battery powered guide with me
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #38 21599590
    io2345
    Level 8  
    >>21599574 As far as I can tell they are sorted from start to end. I monitored traffic with Real-Term. Wonder how one message could possibly overtake the following anyway.

    Exactly, I looks to me, like the mcuconf 02 message is missing, only 03 and 04 are present.

    I understand that investing time in inefficent devices is questionable. So, don't invest too much. I'll order a Zigbee gateway the next days and hope to cause less trouble then ;-)
  • #39 21599653
    p.kaczmarek2
    Moderator Smart Home  
    but if the MCUconf with 0x02 status is missing, it just means that OBK (?) reports a quicker connection:
    Experience? / ONENUO 228WTH Smoke Detector with Temp/Humidity: OBK Flashing, Chip Info, Battery Life
    I'm not sure if it can be the issue. Maybe there is a futher difference down in the exchange? For example, in dpCache?
    Helpful post? Buy me a coffee.
  • #40 21599661
    io2345
    Level 8  
    You're probably right. I did set Flag 37 + 51, so it should do a fast connect.

    What about the message "Info:TuyaMCU:ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!" in the logs?
  • #41 21599930
    p.kaczmarek2
    Moderator Smart Home  
    I've looked at the code and it seems implemented, probably message can be removed.

    Now, the question is - ignoring the extra WiFi state 0x02 packet, what else in OBK deviates from Tuya? Can you point to exact packet?
    Helpful post? Buy me a coffee.
  • #42 21600009
    DeDaMrAz
    Level 20  
    @io2345

    Can you share your LFS (autoexec) maybe??

    do you have

    Code: text Expand Select all Copy to clipboard
    waitFor WiFiState 4

    in there? I don't remember from the top of my head but this is needed for OBK to send status that you are missing (don't quote me on that!!)

    Also you can use this in combination.

    Code: text Expand Select all Copy to clipboard
    //configure flag 2 in general/flag settings
waitFor MQTTState 1
mqtt_broadcastInterval 1
mqtt_broadcastItemsPerSec 6
  • #43 21600115
    p.kaczmarek2
    Moderator Smart Home  
    Code: text Expand Select all Copy to clipboard
    waitFor WiFiState 4
    is not needed by TuyaMCU, only for deepsleep devices
    Helpful post? Buy me a coffee.
  • #44 21600447
    io2345
    Level 8  
    >>21600009 Thank you for replying. Autoexec.bat is in Post#27, and "waitFor WiFiState 4" is not in there. But p.kaczmarek2 is probably right when he says, that this line is missing when using fast WiFi connect (Flags 37 + 51).

    Currently the device is back on stock ROM and ready to be shipped, but if you are willing to try to solve some of the riddles, I can flash back to OBK without any problem.
    One riddle is the strange behaviour when entering and removing the "TuyaMcu_setBatteryAckDelay" command in autoexec.bat. When entered there was no effect (short 8 seconds wakeup), but after removing it always had long wakeups of more than 20 seconds, no matter which time value was in there before.
    If you want to try out one thing or the other, let me know. It will be back to OBK within some minutes.
  • #45 21600594
    DeDaMrAz
    Level 20  
    I am willing to buy that device from you, would you be willing to ship to Poland or Serbia? If so PM me to arrange something.

    I am not sure I can devote too much time at the moment and I would like to have it in hand to test it all.

    Let me know.
Reply | New topic
Report a violation of the law

Topic summary

The discussion centers on the ONENUO 228WTH smoke detector featuring temperature and humidity sensing, focusing on its compatibility with OBK firmware (OpenBK7231T_App) and the TuyaMCU protocol. The device uses a TuyaMCU + tmSensor architecture with a BK7321N chip, communicating via UART at 9600 baud. Key challenges include flashing the battery-powered device, managing power consumption, and ensuring reliable data transmission from the WiFi module to MQTT within the limited wake-up time (approximately 8 seconds). The device wakes periodically (about every minute) to report temperature, humidity, battery level, smoke, and overtemperature alarms. Attempts to extend WiFi module uptime using the tuyaMcu_setBatteryAckDelay command showed no effect, possibly due to firmware version or protocol adherence issues. Communication logs reveal incomplete MCU configuration handling (TUYA_CMD_MCU_CONF marked as TODO), which may cause premature WiFi module shutdown and data loss. Solutions discussed include capturing and comparing factory firmware traffic with OBK logs to identify protocol deviations, adjusting OBK autoexec.bat configurations for channel mapping and baud rate, and considering alternative devices or communication protocols (e.g., Zigbee) for better battery efficiency. The device’s hardware buttons ("WiFi" and "Test") and limited configurable features (e.g., smoke sensitivity) were noted. Overall, the device is functional but challenging to integrate fully with OBK due to battery constraints and protocol complexities, with ongoing efforts to optimize MQTT data transmission timing and power management.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT