logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Xindum Smoke Alarm CB3S MCU BA45F5250 OpenBeken Firmware WiFi Connection Issue

exo9er 1071 6
ADVERTISEMENT
Reply | New topic
  • #1 21046759
    exo9er
    Level 2  

    Looking for some help with this long life battery powered smoke detector. I have flashed the latest OpenBeken and have added an autoexec.bat. Two presses of the test button should power up the CB3S module and transmit the battery level (Low Mid, High), whether the test is successful and whether there is a fault or not. This works successfully once I keep power on the CB3S module but without doing this the MCU (BA45F5250) seems to only power the module for about 7 seconds which doesn't seem to be long enough for the CB3S to connect to the WIFI. This does work with the original Tuya firmware. Smoke detection works successfully with OpenBeken but would like get the testing part to work as well.

    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU
tuyaMcu_setBaudRate 9600
startDriver tmSensor
// smoke detect, 0 or 1, dpID 1 type enum (4)
setChannelLabel 1 Smoke
setChannelType 1 ReadOnly
linkTuyaMCUOutputToChannel 1 4 1
// Test Result, "checking","check_success","check_failure","others, dpID 9 type enum (4)
setChannelLabel 9 Test
setChannelType 9 ReadOnly
linkTuyaMCUOutputToChannel 9 4 9
// Fault, dpID 11, fault, serious_fault, sensor_fault, probe_fault, power_fault
setChannelLabel 11 Fault
setChannelType 11 ReadOnly
linkTuyaMCUOutputToChannel 11 5 11
// Battery state enumeration, dpID 14 type enum (4)
setChannelLabel 14 Battery
setChannelType 14 ReadOnlyLowMidHigh
linkTuyaMCUOutputToChannel 14 4 14
// Mute, dpID 101
setChannelLabel 15 Mute
setChannelType 15 Toggle
//link dpid 101  to channel 15
//linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 101 1 15


    The module only ever seems to be able to send the product query information before the power is turned off by the MCU

    Code: text Expand Select all Copy to clipboard
    
Sent by WiFi module
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK
Received by WiFi module:
55 AA	00	01		00 24	7B2270223A2266707276656A61616262326834636730222C2276223A22312E302E30227D	7A	
HEADER	VER=00	Product		LEN	{"p":"fprvejaabb2h4cg0","v":"1.0.0"}	CHK


    The MCU replies with the product information but nothing further seems to happen.
  • ADVERTISEMENT
  • #2 21047629
    p.kaczmarek2
    Moderator Smart Home  
    That kind of situation usually require having a communication capture from the original firmware. Is OBK supposed to send something else to MCU to make sure it keeps it alive?

    The strange thing is that, according to your post, it works in non-test mode, what is different? Is the MCU waiting longer for WiFi connection when a "not test" mode is used?

    Alternatively, maybe you're missing MQTT connection? OBK tmSensor requires MQTT to be present, otherwise it will not report 0x04 state to the MCU.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 21048015
    exo9er
    Level 2  

    Quote:
    That kind of situation usually requires having a communication capture from the original firmware. Is OBK supposed to send something else to MCU to make sure it keeps it alive?


    The original firmware sends the following data. I only have one USB device to capture so apologies for the 2 traces.

    Code: text Expand Select all Copy to clipboard
    Sent by WiFi module:
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	
Sent by WiFi module:
55 AA	00	02		00 01	03	05	
HEADER	VER=00	McuConf		LEN	03	CHK	
Sent by WiFi module:
55 AA	00	02		00 01	04	06	
HEADER	VER=00	McuConf		LEN	04	CHK	
Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN			CHK	
Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN			CHK


    Code: text Expand Select all Copy to clipboard
    Received by WiFi module:
55 AA	00	01		00 24	7B2270223A2266707276656A61616262326834636730222C2276223A22312E302E30227D	7A	
HEADER	VER=00	Product		LEN	{"p":"fprvejaabb2h4cg0","v":"1.0.0"}	CHK	
Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	
Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	
Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	
Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	
Received by WiFi module:
55 AA	00	05		00 0A	0E040001020104000101	2A	
HEADER	VER=00	Unk		LEN	dpId=14 Enum V=2,dpId=1 Enum V=1		CHK	
Received by WiFi module:
55 AA	00	05		00 0A	0E040001020104000101	2A	
HEADER	VER=00	Unk		LEN	dpId=14 Enum V=2,dpId=1 Enum V=1		CHK


    I've just noticed when the test is done the Smoke Alarm dpId is set to 1 which is normal and 0 is in alarm. I do remember the test results showing Smoke Alarm Release meaning the alarm is reset.

    Smartphone notifications showing test results, battery level, and smoke alarm status.


    Quote:
    The strange thing is that, according to your post, it works in non-test mode, what is different? Is the MCU waiting longer for WiFi connection when a "not test" mode is used?


    I can only guess that the Wifi module is kept active for slightly longer once smoke is detected. The alarm state is received in HA correctly

    Quote:
    Alternatively, maybe you're missing MQTT connection? OBK tmSensor requires MQTT to be present, otherwise it will not report 0x04 state to the MCU.


    The module starts off requesting the Product information and gets a reply but I never see anything after this. If I keep the module active for a few seconds longer by keeping power on pin 8 the information is received by HA using MQTT. Is there some way to fool the MCU into keeping the power for a little longer or sending the 0x04 state?
  • ADVERTISEMENT
  • #5 21052132
    exo9er
    Level 2  
    Not sure if I 'm going the right way but pressing the Test button now updates HA. I made some changes to the autoexec.bat to try prolong the time the Wifi module is powered. The test button doesn't seem to work continuously only after a certain time has elapsed since the last test does it power up the Wifi module long enough to update. I do remember the official app wouldn't update everytime only after it was left for a while.

    Code: text Expand Select all Copy to clipboard
    loglevel 6
startDriver TuyaMCU
tuyaMcu_setBaudRate 9600
startDriver tmSensor
mqtt_broadcastItemsPerSec 15

delay_ms 500

uartSendHex 55AA0001000000

uartSendHex 55AA000200010305
delay_ms 500
tuyaMcu_sendHeartbeat

uartSendHex 55AA000200010406

delay_ms 1000

uartSendHex 55AA000500010005

tuyaMcu_sendHeartbeat


// smoke detect, 0 or 1, dpID 1 type enum (4)
setChannelLabel 1 Smoke
setChannelType 1 ReadOnly
linkTuyaMCUOutputToChannel 1 4 1

// Test Result, "checking","check_success","check_failure","others, dpID 9 type enum (4)
setChannelLabel 9 Test
setChannelType 9 ReadOnly
linkTuyaMCUOutputToChannel 9 4 9

// Fault, dpID 11, fault,serious_fault,sensor_fault,probe_fault,power_fault
setChannelLabel 11 Fault
setChannelType 11 ReadOnly
linkTuyaMCUOutputToChannel 11 5 11

// Battery state enumeration, dpID 14 type enum (4)
setChannelLabel 14 Battery
setChannelType 14 ReadOnlyLowMidHigh
linkTuyaMCUOutputToChannel 14 4 14

// Mute, dpID 101
setChannelLabel 15 Mute
setChannelType 15 Toggle
//link dpid 101  to channel 15
//linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 101 1 15
  • ADVERTISEMENT
  • #6 21052477
    p.kaczmarek2
    Moderator Smart Home  
    Would you be able to compare what OBK sends to what original firmware sends? I saw your captures but I can't just tell out of the memory if something is missing. I can update the OBK driver once I know what should be done.
    Helpful post? Buy me a coffee.
  • #7 21065003
    exo9er
    Level 2  
    This is what is now sent to the MCU by Wifi module

    Code: text Expand Select all Copy to clipboard
    Sent by WiFi module:
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	

Sent by WiFi module:
55 AA	00	02		00 01	03	05	
HEADER	VER=00	McuConf		LEN	03	CHK	

Sent by WiFi module:
55 AA	00	00		00 00		FF	
HEADER	VER=00	Heartbeat		LEN		CHK	

Sent by WiFi module:
55 AA	00	02		00 01	04	06	
HEADER	VER=00	McuConf		LEN	04	CHK	

Sent by WiFi module:
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN			CHK	

Sent by WiFi module:
55 AA	00	00		00 00		FF	
HEADER	VER=00	Heartbeat		LEN		CHK	

Sent by WiFi module:
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	

Sent by WiFi module:
55 AA	00	02		00 01	03	05	
HEADER	VER=00	McuConf		LEN	03	CHK	

Sent by WiFi module:
55 AA	00	02		00 01	04	06	
HEADER	VER=00	McuConf		LEN	04	CHK


    And the MCU replies with

    Code: text Expand Select all Copy to clipboard
    Received by WiFi module:
55 AA	00	01		00 24	7B2270223A2266707276656A61616262326834636730222C2276223A22312E302E30227D	7A	
HEADER	VER=00	Product		LEN	{"p":"fprvejaabb2h4cg0","v":"1.0.0"}	CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Received by WiFi module:
55 AA	00	01		00 24	7B2270223A2266707276656A61616262326834636730222C2276223A22312E302E30227D	7A	
HEADER	VER=00	Product		LEN	{"p":"fprvejaabb2h4cg0","v":"1.0.0"}	CHK	

Received by WiFi module:
55 AA	00	05		00 0A	09040001010E04000102	32	
HEADER	VER=00	Unk		LEN	dpId=9 Enum V=1,dpId=14 Enum V=2		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	09040001010E04000102	32	
HEADER	VER=00	Unk		LEN	dpId=9 Enum V=1,dpId=14 Enum V=2		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	09040001010E04000102	32	
HEADER	VER=00	Unk		LEN	dpId=9 Enum V=1,dpId=14 Enum V=2		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	09040001010E04000102	32	
HEADER	VER=00	Unk		LEN	dpId=9 Enum V=1,dpId=14 Enum V=2		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	09040001010E04000102	32	
HEADER	VER=00	Unk		LEN	dpId=9 Enum V=1,dpId=14 Enum V=2		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	01040001010B05000100	26	
HEADER	VER=00	Unk		LEN	dpId=1 Enum V=1,dpId=11 Bitmap V=0		CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	01040001010B05000100	26	
HEADER	VER=00	Unk		LEN	dpId=1 Enum V=1,dpId=11 Bitmap V=0		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	01040001010B05000100	26	
HEADER	VER=00	Unk		LEN	dpId=1 Enum V=1,dpId=11 Bitmap V=0		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	01040001010B05000100	26	
HEADER	VER=00	Unk		LEN	dpId=1 Enum V=1,dpId=11 Bitmap V=0		CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	01040001010B05000100	26	
HEADER	VER=00	Unk		LEN	dpId=1 Enum V=1,dpId=11 Bitmap V=0		CHK


    This is much more than the original code. I would guess the autoexec.bat is sending a lot of messages to keep the MCU powering the WiFi module long enough for it to connect to the Wifi (> 10 seconds is enough). Also noticed the device checks in without any test button being pressed about every 96 hours.

    The traces from the original firmware are as follows


    Code: text Expand Select all Copy to clipboard
    Sent by WiFi module:
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	

Sent by WiFi module:
55 AA	00	02		00 01	03	05	
HEADER	VER=00	McuConf		LEN	03	CHK	

Sent by WiFi module:
55 AA	00	02		00 01	04	06	
HEADER	VER=00	McuConf		LEN	04	CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN			CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN			CHK


    and the response from the MCU

    Code: text Expand Select all Copy to clipboard
    Received by WiFi module:
55 AA	00	01		00 24	7B2270223A2266707276656A61616262326834636730222C2276223A22312E302E30227D	7A	
HEADER	VER=00	Product		LEN	{"p":"fprvejaabb2h4cg0","v":"1.0.0"}	CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	09040001010E04000102	32	
HEADER	VER=00	Unk		LEN	dpId=9 Enum V=1,dpId=14 Enum V=2		CHK	

Received by WiFi module:
55 AA	00	05		00 0A	01040001010B05000100	26	
HEADER	VER=00	Unk		LEN	dpId=1 Enum V=1,dpId=11 Bitmap V=0		CHK


    I think is similar to the information in this post

    Code: text Expand Select all Copy to clipboard
    https://www.elektroda.com/rtvforum/topic3975583.html
Reply | New topic
Report a violation of the law

Topic summary

The discussion revolves around a user experiencing WiFi connection issues with the Xindum CB3S smoke alarm after flashing the latest OpenBeken firmware. The user notes that while the smoke detection functionality works, the MCU (BA45F5250) only powers the CB3S module for about 7 seconds, insufficient for establishing a WiFi connection. Responses suggest capturing communication from the original firmware to identify differences in data transmission. The user shares data packets sent and received by the WiFi module, indicating ongoing troubleshooting efforts to extend the power duration for the WiFi module and ensure proper MQTT connection for reporting states. Adjustments to the autoexec.bat file are also discussed to improve functionality.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT