logo elektroda
logo elektroda
X
logo elektroda

Open source firmware for XR809 compatible with Tasmota HTTP/Home Assistant

p.kaczmarek2 35163 57
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • #31 20404770
    p.kaczmarek2
    Moderator Smart Home
    It's important to note that all XR809 features (and many more advanced ones) are now in my OpenBeken multiplatform firmware projects.
    https://github.com/openshwprojects/OpenBK7231T_App
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20881151
    elektroretro
    Level 6  
    I have an XR3 / XR809 Mirabella Genio Door/Window Sensor with (I believe) a TuyaMCU onboard: the 8L151G - see attached image.

    Close-up of the interior of the XR3 Mirabella Genio door/window sensor with markings on the circuit board.

    Has someone managed to source the outputs with this with a XR809 / tuyaMCU combination?

    I am trying to issue the "startDriver tuyaMCU" command in the startup / run commands - but keep receiving "Error:CMD:cmd startDriver NOT found (args tuyaMCU)".
    The same error shows up in the startup with the startScript command - so it appears I'm missing something.

    I am running XR809 build image OpenXR809_1.17.376.img from December 25, 2023.
    The rest of the configuration and webapp and logs are working but I am clearly missing something here with startDriver not being found as a command.

    I have searched all over and cannot seem to find what my issue would be.
    Any assistance gratefully received - very appreciative of the work of @p.kaczmarek2 and other members of this forum.
  • ADVERTISEMENT
  • #33 20881209
    p.kaczmarek2
    Moderator Smart Home
    TuyaMCU driver is not enabled on this platform. You are the first one ever to document a TuyaMCU device with XR809. I have never seen anything like that.

    To enable TuyaMCU, you would need to do two things:
    1. add a proper define here:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/obk_config.h
    2. add missing UART initialization here:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_uart.c

    Following operations may require some basic C and programming knowledge, but it does not require writing new code per se, you just need to fill the stubs with XR809 SDK examples.
    Helpful post? Buy me a coffee.
  • #34 20881463
    elektroretro
    Level 6  
    Thanks for this guidance - I will work on it.
    Is there another platform with TuyaMCU enabled that you would recommend to use as a reference in doing tbis work?
  • #35 20882312
    p.kaczmarek2
    Moderator Smart Home
    BK7231 is our main target and it's supported well.

    By the way, it seems that you also need to remove OBK_DISABLE_ALL_DRIVERS on XR809.
    Helpful post? Buy me a coffee.
  • #36 20882316
    elektroretro
    Level 6  
    Excellent - thanks for the advice.
  • #37 20882343
    p.kaczmarek2
    Moderator Smart Home
    Once you get it working, you can open a pull request.
    Helpful post? Buy me a coffee.
  • #38 20882358
    elektroretro
    Level 6  
    Will do thanks - just a quick question as I am reviewing code:

    I am thinking of starting with just enabling TuyaMCU with:
    #define ENABLE_DRIVER_TUYAMCU 1
    Then following through with the supporting code to get the comms working.

    I don't believe I would need anything else just looking at the other platforms.
    LittleFS would be nice but not needed to complete the initial concept.

    Am I on the right track with this?
    Would ENABLE_TEST_COMMANDS and ENABLE_TEST_DRIVERS be recommendable as well for initial development?
  • #39 20882645
    p.kaczmarek2
    Moderator Smart Home
    Don't forget to enable it first:
    Screenshot of a code snippet in a GitHub editor.
    The things you mentioned are development time test commands, you don't need them. You just need TuyaMCU driver to get TuyaMCU commands and fix the missing UART port open call with a baud rate setting. Ah, and also the missing UART port send call.
    Helpful post? Buy me a coffee.
  • #40 20882695
    elektroretro
    Level 6  
    Thanks - really appreciate your help with this, all of your guides and tutorials I have read over the past month are immensely helpful.

    So far have added the code (below) and working on getting the build to fully complete.
    Not sure whether the code will actually work but it seems to align with XR809 uart code examples.

    If any thoughts come to mind let me know, otherwise I'll keep hacking away and see what happens.

    ----CODE:
    In obk_config.h:
    
    #if PLATFORM_XR809
    // Enabling the TuyaMCU drivers on XR809
    #define ENABLE_DRIVER_TUYAMCU   1
    //#define OBK_DISABLE_ALL_DRIVERS       1
    
    In driver/drv_uart.c:
    
    #if PLATFORM_XR809
    #include "driver/chip/hal_uart.h"
    //#include <hal_uart.h>
    #endif
    ...
    #elif PLATFORM_XR809
    // Transferred across from OpenXR809-master\project\example\uart\main.c, uart_init()
    #define UARTID UART1_ID
    ...
    In uart_sendbyte(byte b):
    #elif PLATFORM_XR809
    	// Adapted from OpenXR809-master\project\example\uart\main.c, uart_init()
    	// UARTID defined as UART1_ID
    	HAL_UART_Transmit_IT(UARTID, &b, 1);
    ...
    In uart_inituart:
    #elif PLATFORM_XR809
    	// Adapted from OpenXR809-master\project\example\uart\main.c, uart_init()
    	// HAL_Status status = HAL_ERROR;
    	UART_InitParam param;
    	param.baudRate = 115200;  // XR809 sdk example: baud=115200
    	param.dataBits = UART_DATA_BITS_8;
    	param.stopBits = UART_STOP_BITS_1;
    	param.parity = UART_PARITY_NONE;
    	param.isAutoHwFlowCtrl = 0;
    
    	HAL_UART_Init(UARTID, &param);
    	//status = HAL_UART_Init(UARTID, &param);
    	//if (status != HAL_OK)
    	//	printf("uart init error %d\n", status);
    
    
    

    ----BUILD ERROR

    The build error is just a user issue on this end checking out the App repo correctly I'm sure.

    Getting a number of undefined references like:
    ../shared/src/cmnds/cmd_if.o: In function `getVoltage': C:\openxr809\project\oxr_sharedApp\gcc/../shared/src/cmnds/cmd_if.c:208: undefined reference to `DRV_GetReading')
    
    Resulting in: 
    collect2.exe: error: ld returned 1 exit status
    make: *** [../../../project/project.mk:204: oxr_sharedApp.axf] Error 1)
  • #41 20882715
    p.kaczmarek2
    Moderator Smart Home
    You need to learn basic tricks for navigation in Github projects. For example, use Github search to look for DRV_GetReading:
    https://github.com/search?q=repo%3Aopenshwpro...%2FOpenBK7231T_App%20DRV_GetReading&type=code
    It looks like DRV_GetReading is in bl_shared.c . Is bl_shared.c included in Makefile?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #42 20882727
    elektroretro
    Level 6  
    Thanks, you are completely right about that - I am still learning so this is helpful.

    I am going back to follow your build instructions for the XR809 - I did not check out the shared app repo but rather downloaded and copied tge code across to the shared directory, so that may be part of it.

    So I will go back and do it properly and do my own error checking before reporting back.
  • #43 20884388
    elektroretro
    Level 6  
    All compiles now - now the error is app.bin being reported as too large (selected build image error included further below).

    App.bin is 208KB after edits compared to 190KB in the current repo build and that seems to break the allocations in the image.
    I'm at 1,051,220 bytes for the 8 .bin files in total in the image directory, which is beyond 1024KB.

    Do you have any guidance for this one?

    I have tried to ensure the minimum additional adds to keep size down - re-did a couple of times from the beginning to build completely fresh, adding code and makefile inclusions piece by piece to ensure the minimum set was added to complete an error-free compile.

    --------------------
    MAKEFILE EDITS:
    ----
    Into new_common.h in XR809 definitions:
    typedef unsigned int u32;

    Into the makefile:
    SRCS += ../shared/src/driver/drv_bl_shared
    SRCS += ../shared/src/driver/drv_tasmotaDeviceGroups
    SRCS += ../shared/src/devicegroups/deviceGroups_write
    SRCS += ../shared/src/driver/drv_tuyaMCUSensor
    SRCS += ../shared/src/bitmessage/bitmessage_write
    ----


    BUILD OUTPUT - IMAGE ERROR:
    ----
    cp -u oxr_sharedApp.bin ../image/xr809/app.bin
    cp -u oxr_sharedApp_xip.bin ../image/xr809/app_xip.bin
    cp -u -t ../image/xr809 ../../../bin/xr809/boot.bin ../../../bin/xr809/net.bin ../../../bin/xr809/net_ap.bin ../../../bin/xr809/wlan_bl.bin ../../../bin/xr809/wlan_fw.bin ../../../bin/xr809/wlan_sdd.bin
    cd ../image/xr809 && \
    chmod a+r *.bin && \
    ../../../../tools/mkimage.exe -O -c image_auto_cal.cfg -o xr_system.img
    cfg string:
    {
        "magic"   :"AWIH",
        "version" :"0.3",
        "OTA"     :{"addr": "1024K", "size": "32K"},
        "count"   :8,
        "section" :[
                    {"id": "0xa5ff5a00", "bin" :"boot.bin", "cert": "null", "flash_offs": "0K",     "sram_offs": "0x00067000", "ep": "0x00067101", "attr":"0x1"},
                    {"id": "0xa5fe5a01", "bin" :"app.bin",  "cert": "null", "flash_offs": "32K",    "sram_offs": "0x00010000", "ep": "0x00010101", "attr":"0x1"},
                    {"id": "0xa5fd5a02", "bin" :"app_xip.bin",      "cert": "null", "flash_offs": "222K",   "sram_offs": "0xffffffff", "ep": "0xffffffff", "attr":"0x2"},
                    {"id": "0xa5fc5a03", "bin" :"net.bin",  "cert": "null", "flash_offs": "409K",   "sram_offs": "0x60000000", "ep": "0xffffffff", "attr":"0x1"},
                    {"id": "0xa5fb5a04", "bin" :"net_ap.bin",       "cert": "null", "flash_offs": "631K",   "sram_offs": "0x60000000", "ep": "0xffffffff", "attr":"0x1"},
                    {"id": "0xa5fa5a05", "bin" :"wlan_bl.bin",      "cert": "null", "flash_offs": "883K",   "sram_offs": "0xffffffff", "ep": "0xffffffff", "attr":"0x1"},
                    {"id": "0xa5f95a06", "bin" :"wlan_fw.bin",      "cert": "null", "flash_offs": "886K",   "sram_offs": "0xffffffff", "ep": "0xffffffff", "attr":"0x1"},
                    {"id": "0xa5f85a07", "bin" :"wlan_sdd.bin",     "cert": "null", "flash_offs": "1014K",  "sram_offs": "0xffffffff", "ep": "0xffffffff", "attr":"0x1"}
            ]
    }
    
    err: bin 1 and bin 2 were overlaped!
    Overlapped size: 17732 Byte(18kB)
    bin 1 name:app.bin    begin: 0x00008000    end: 0x0003BD44
    bin 2 name:app_xip.bin    begin: 0x00037800
    Bin files are too big, can't generat new cfg file!!
    Generate image file failed
    make: *** [../../../project/project.mk:260: image] Error 127
  • #44 20897769
    elektroretro
    Level 6  
    Hello - Do you have any advice on solving the mkimage build error from my last post?
    Many thanks
  • #45 20897808
    p.kaczmarek2
    Moderator Smart Home
    I haven't experienced this issue yet. As far as I remember, automatic partitions update always worked. Maybe you need to try to strip some features from the codebase to make the binary smaller. Alternatively, you can check for adjustable binary size limit somewhere in the build scripts. That MCU supposedly has 2MB flash:
    Open source firmware for XR809 compatible with Tasmota HTTP/Home Assistant
    Helpful post? Buy me a coffee.
  • #46 20897878
    elektroretro
    Level 6  
    Thanks - I too saw the 2MB flash on further research so it seems there is space.
    Likewise the auto adjust worked for me on earlier builds.

    Do you know if some of those binaries (wlan etc) need to be written to specific addresses?

    I was reading datasheets and running searches looking for clues.
    The mkimage config has sram offsets and other addresses included and I'm not sure where to find information about that.
    Maybe the sdk has something?

    Failing that my thinking is:
    -adjust the config so the binaries fit in the image and see what happens when flashed
    -strip out code to make it fit (might be lengthy trial and error)
  • #47 20927341
    elektroretro
    Level 6  
    Further results on this - not working yet:

    -mkimage binaries don't seem to need to be at specific addresses
    -running over 1024kb/1020kb has not worked even though 2MB should be available. Perhaps more needs to be done to enable access in the code.
    -tried using xz compressed bin following xz mkimage conf example in sdk, changed make configs to allow compressed bin, which added xz files to the compile and made a smaller image under the 1020kb limit but got no further than booting

    Has anyone had success with xz compressed bins in the image?
    It seems possible based on sdk examples but I am not sure what I'm missing.

    So last resort will be stripping out code - any suggestions on quick wins there?
    I need to save about 30kb.
  • #48 20929219
    p.kaczmarek2
    Moderator Smart Home
    Maybe you can remove json_interface.c which was made to be compatible with Tasmota JSON responses to commands.
    Helpful post? Buy me a coffee.
  • #49 20968200
    elektroretro
    Level 6  
    Ok - got it working, image just fits - your suggestion of excluding json_interface.c was enough.
    I can now issue startDriver tuyaMCU and startDriver tmSensor.

    Now I am looking for help in how to detect changes in the door sensor. Do you have some guidance?
    I had previously tried setting up mqtt to do this - is that the way to go? Or is there another way to test it without mqtt?
    Thanks again for your help.

    I issue this command in the webapp / Log on every startup - following from your work on another tuyaMCU door sensor:
    backlog startDriver tuyaMCU ; startDriver tmSensor ; linkTuyaMCUOutputToChannel 1 val 1 ; setChannelType 1 ReadOnly ; linkTuyaMCUOutputToChannel 3 val 3 ; setChannelType 3 ReadOnly ;

    My filesystem doesn't seem to work so I cannot create or copy an autoexec.bat.

    I will list in another post the changes I have made to the code and makefile to get this far in case anyone finds it useful.
    Eventually if it all works I will come back to see if a pull request is warranted.

    Added after 2 [minutes]:

    Changes made so far for the XR809 with a tuyaMCU:

    edited /obk_config.h:
    #define enable_tuyamcu

    edited driver/drv_uart.c:
    #include "driver/chip/hal_uart.h"
    #elif PLATFORM_XR809
    // Transferred across from OpenXR809-master\project\example\uart\main.c, uart_init()
    #define UARTID UART1_ID
    added to:
    uart_sendbyte
    uart_uart_inituart

    edited /new_common.h:
    In xr809:
    typedef unsigned int u32;

    makefile: in oxr_sharedapp/gcc
    added:
    SRCS += ../shared/src/driver/drv_bl_shared # for DRV_GetReading
    SRCS += ../shared/src/driver/drv_tasmotaDeviceGroups # for DRV_DGR_OnLedFinalColorsChange
    SRCS += ../shared/src/devicegroups/deviceGroups_write # for DGR_Quick_FormatPowerState (and requireds u32 defined in new_common.h
    SRCS += ../shared/src/driver/drv_tuyaMCUSensor # for TuyaMCU_Sensor_Init
    SRCS += ../shared/src/bitmessage/bitmessage_write # for MSG_WriteBytes

    removed:
    SRCS += ../shared/src/httpserver/json_interface
    # Excluded json_interface to save space in the image

    Then due to removal of json_interface:
    -removed in http_fns.c at line 2297 and 2303 reference to JSON_ProcessCommandReply
    project\oxr_sharedApp\gcc/../shared/src/httpserver/http_fns.c
    -removed in new_mqtt.c at line 712 reference to JSON_ProcessCommandReply
    project\oxr_sharedApp\gcc/../shared/src/mqtt/new_mqtt.c
    -removed in rest_interface.c:1722 reference to JSON_ProcessCommandReply
    project\oxr_sharedApp\gcc/../shared/src/httpserver/rest_interface.c
  • #50 21025243
    elektroretro
    Level 6  
    I have TuyaMCU and tmSensor working.

    I am looking for help in how to detect changes in the door sensor. Do you have some guidance?
    I had previously tried setting up mqtt to do this - is that the way to go? Or is there another way to test it without mqtt?

    I am a little lost on how to select channels, for example.
    I followed your initial work on door sensors where you selected Ch 1 but that did not seem to work and I am not sure how I would discover what channel to select.
    With so many pins to test with pullup/pulldown I was hoping to get some broad guidance to progress the research.

    Thanks again for your help.
  • ADVERTISEMENT
  • #51 21025435
    p.kaczmarek2
    Moderator Smart Home
    tmSensor driver will wait for MQTT connection to appear by design:
    Screenshot of programming code related to MQTT connection logic and Wi-Fi settings.
    ... unless you set default wifi state to 0x04 , then it will proceed without MQTT.

    In order to get broader understanding about the driver, you should refer to our other guides:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Also search for battery powered devices here:
    https://openbekeniot.github.io/webapp/devicesList.html
    Helpful post? Buy me a coffee.
  • #54 21170765
    elektroretro
    Level 6  
    Not having much luck here.

    I have read through several times and tried to replicate some of the commands on the thread on battery powered window sensors (and other threads), in particular this post:
    https://www.elektroda.com/rtvforum/topic3914412-30.html#20561478

    For some reason I am not receiving any TuyaMCU info messages in the debug log with "All" logging enabled. The drivers apparently start but that's it.
    I also cannot issue the uartSendHex command - command not found even though it should be in the build via the make file uart.c etc.

    I have got MQTT working, set flags 2, 10, 19, and tried to get contact sensor responses from channels 0 to 6, plus 58 to 63, no responses beyond 0.
    I'm only getting unexciting messages such as IP address through MQTT explorer and nothing is showing up in Home Assistant.
    (Command example for channel 1: Backlog startDriver tuyaMCU; startDriver tmSensor; linkTuyaMCUOutputToChannel 1 val 1; setChannelType 1 ReadOnly;)

    The firmware all seems to be working as far as configuration is concerned but I just cannot get inputs from the sensors and I'm not sure what more to try.
    It feels like I am getting something fundamentally wrong.

    Disappointing but this seems to have defeated me for now.
    Sorry, p.kaczmarek2 - you have such excellent explanations and analysis but I have been unable to replicate it in this situation.

    I will keep monitoring this thread in case anyone has any thoughts or progress that I can go back in and try.
  • #55 21170855
    p.kaczmarek2
    Moderator Smart Home
    If you cannot issue uartSendHex , then check here:
    A snippet of source code in C with defined platforms.
    in cmd_main.c
    Helpful post? Buy me a coffee.
  • #56 21177322
    elektroretro
    Level 6  
    Thanks - I added "|| defined(PLATFORM_XR809)" and re-compiled.
    Unfortunately I cannot seem to flash my unit.

    It does not seem to detect that the PRG/PRG2 pins are grounded and just boots straight into the existing image after ungrounding the RESET pin.
    I have re-soldered and tested connections several times and cannot get it to flash ("synchron error").
    I can see outputs through Realterm so other connections are working.

    I had a few problems on a re-build a month or so ago and it looks as though it's failed properly this time.
  • #57 21415015
    divadiow
    Level 34  
    if anyone's interested, the LoraTap wifi door and window sensor still appears to come with an XR3, mine just did anyway.

    https://www.aliexpress.com/item/1005007268034863.html

    Illustration showing LoraTap WiFi/ZigBee door and window sensors on the Aliexpress page.

    It's quite a nice package. Could do a separate topic on I suppose. Wouldn't be able to fully convert though to OBK I guess - deepsleep, ADC (?), ota, lfs
    LoraTap Wi-Fi door and window sensor in an open box with visible electronic components and a screwdriver.
  • #58 21523952
    p.kaczmarek2
    Moderator Smart Home
    I moved XR806-related discussion to: https://www.elektroda.com/rtvforum/topic4118139.html
    This topic will stay on XR809.
    Helpful post? Buy me a coffee.

Topic summary

The discussion revolves around developing open-source firmware for the XR809 WiFi module, aiming for compatibility with Tasmota HTTP and Home Assistant. Users share experiences and challenges related to programming the XR809 and XR3 modules, including issues with UART connections, flashing firmware, and integrating with TuyaMCU. Various users report on their progress, troubleshooting steps, and the need for specific UART configurations. The conversation highlights the potential for creating independent firmware that enhances device functionality without reliance on manufacturer servers, similar to existing solutions for ESP8266. Additionally, there are mentions of other modules like BK7231 and WB2S, with users exploring SDKs and firmware options for these devices.
Summary generated by the language model.
ADVERTISEMENT