I have an XR3 / XR809 Mirabella Genio Door/Window Sensor with (I believe) a TuyaMCU onboard: the 8L151G - see attached image.
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.
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.
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.
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?
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?
Don't forget to enable it first:
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.
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.
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)
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.
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
----
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:
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)
-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.
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
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.
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.
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.
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
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.