Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU

>>21869844

I meanwhile found out why it does not work - at least I think so:

we select the UART, but never route it to any physical pins.

Realistically, the best option for ESPs would probably be that you can do the TuyaMCU/Dreo UART assignment in the configure module dialog because these Chips have amazing pinmux flexibility and it is much less opaque to the user than 'use the alternate pins' (which are only vaguely documented defaults).

I will try a simple fix on my fork for this and come back.

Added after 32 [minutes]:

Progress my dudes!



Here you can see what I did so far. I think we're not fully there yet but progress is being made https://github.com/openshwprojects/OpenBK7231T_App/pull/2046

Great job! Keep it up!

ok @p.kaczmarek2


we seem to be getting something coherent now. the 66 in the table for example is the set temperature in fahrenheit, I know because it is on the device display.

There is still many garbage byte messages though so I guess this is where we need to start to debug the actual driver.




The keepalive ping-pong seems to be good as well as the status messages it seems. Where things generate these garbage messages is e.g. when I press the fron panel buttons, then it seems to not like something.

Added after 32 [minutes]:

To be a bit more precise now: serial logging suggests that the driver has issues with status change messages:



The status change messages lead to garbage byte messages in the log although they are well formed. The keepalive ping-pong works well.

It is intermittent, so this suggests there is some issue with the UART buffering or so.

This is a log with me turning the device on and off multiple times. Sometimes we consume the command message and the following state correctly, sometimes not.

So I could need some guidance from that point, how do we best debug this? insert more logging? more serial traces?

Maybe buffer is too small?
UART_InitReceiveRingBuffer(512);
But 512 seems big enough.
@insmod is ESP32 UART stable?

@markusdd do you have other module than ESP32 to check?

>>21871014
I do not have any other module but based on the serial traces I made observing the bus I have no reason to believe UART has a problem. The only fix required was to actually route the secondary UART pins in the espidf HAL and since then it was working fine.
The working handshake - and that we sometimes indeed get proper dpID decode with sensible values - also suggest that.

I think the issue arises because when you press a front panel button, the MCU responds with a cmd packet telling us whatg was pressed, immidiately followed by a huge status update packet.

I think we fail to seperate and parse back2back packets correctly.

EDIT: Some serial captures:

This is ESP towards MCU, just idle for the heartbeat. This looks perfect.




This is MCU towards ESP and a log snippet (also just idle):







This somehow suggest that we have issues to always retrieve stuff cleanly, or something else is polluting the buffer sometimes.

basic functionality is obviously there. Note that logging some of the garbage bytes comes from me, I was debugging with Grok a little yesterday evening.

EDIT: What is really telling is that sometimes we seem to 'desync' from the datastream. We do not process a heartbeat ACK, and suddenly with one following packet we suddenly resync and obviously get all kinds of stuff from the buffer which we do not parse and then have a pool of garbage bytes.

So it's maybe - if it is not the parser - the UART buffer handling that has a problem. The UART itself is fine when looking at the captures:




Added after 4 [hours] 49 [minutes]:

I handed the logs and serial captures as well as driver and hal files to Grok and this is what it had to say. Does this make sense? Is UART buffer handling treated differently for Beken chips?

https://grok.com/share/c2hhcmQtMi1jb3B5_178ada62-bbb5-4953-aebb-b9e7e017cf11

Do you have a serial capture that causes problem in OBK ? Maybe I can put it into windows simulator to check.

Maybe we could also try to tick ESP32 HAL UART from quicktick, so it's thread-safe. Or just really add this mutex, if that's it.

Ok. So I figured it out I think. Based on the Grok analysis we were operating and consuming the UART buffer while it kept being written, keading to garbage parsing results because length and position kept changing on us, especially for large messages or when they arrived shortly after one another.

The solution is to copy whatever is in the buffer to a local one and parse that 'offline', potentially keeping overhangs for the next round in case we fetched it while a message was arriving. Since I did this, I had zero garbage byte messages anymore:



@p.kaczmarek2 @divadiow how do we enable now MQTT and HASS discovery on these data points and make sure we can also send commands, not just consume status? Also, we still have unknown command packets with 0x03 coming from the MCU, I see those on mode changes like temp up/down and changing between eco and H3/2/1 modes.

Now that the physical layer seems fine, can we push for a completely working version this weekend? I need to actually hang this thing up at my mothers house over easter, so I need to conclude on this soon after 3 evenings and nights haha

EDIT: here is the changeset: https://github.com/openshwprojects/OpenBK7231T_App/pull/2046/changes

So the current state is that the parsing somewhat works but if I e.g. quickly press the temperature buttons at the fron it seems sometimes it is getting missed. Same with heartbeat responses.

This is getting way above my head tbh and I need help if we want this openbeken port to succeed.

And yes, I think the UART handling not being thread safe is the issue. I now tried to 'vibe code' that more safely by using a local buffer which we do the parsing on. That works far better than the original but we sometimes keep skipping a beat.

The question is if that is at all avoidable or if we just sometimes need to poll status again to re-sync with what the settings currently are.

If you know a good UART implementation for ESP maybem adopting it makes sense. The driver worked also in ESPHome so obviously their impl should also be good?

Hmm. I wish I knew how to help in a meaningful way. Id only throw it all at Codex to see what it makes of it all...

Added after 1 [hours] 53 [minutes]:

any different? https://github.com/divadiow/OpenBK7231T_App/actions/runs/23651245568

>>21871824



yes this one crashes xD

I think this is the issue: https://github.com/divadiow/OpenBK7231T_App/c...df0f6e8eecd6c8abe9a476f8ae2184b875b96cb676R94

This is allocating a 512 array on the stack.



Added after 19 [minutes]:

Ok I changed your diff so that array would be static (so not on stack but in .bss) and with this it runs now, but the behavior isn't really any different.



We are not having any garbage byte problems or so but some responses that I clearly see on my serial monitor do not show up internally.
If I press the front panel buttons mutiple times sometimes we also get a then correct dIP decode.

So whenever we fetch a packet right now we also handle it, but for my taste we are missing too many:

Thsi si the serial log I am capturing from the MCU->ESP line:

ha OK. oh well.

I've backed-out those changes and here's something else building: https://github.com/divadiow/OpenBK7231T_App/actions/runs/23656676577

lmk if this is just noise and to not pursue. Might not be any help at all.

>>21871949

We can look into both. This idea is similar to what I tried with Grok. ultimately I think it is a problem related to the HAL in combination with non-robust parsing code.

I'm currently playing with Grok to see if we can make the UART code actually thread safe.

Added after 1 [hours] 37 [minutes]:

ok both appraoches didn't lead me to success, your @divadiow does not work at all, it desyncs all the time because it has unsycned pointer issues into the UART buffer.

My trials to get it stable and reliable also failed.

so either someone speaks up now and we can get this running in task force mode this weekend or I have to cut my losses and run it via ESPHome. Already lost my original module.

EDIT: runninng one last ditch attempt now and this is trying to basically reuse most of TuyaMCU driver which exists and just implement the differences.

Didn't work

please give this a go. https://github.com/divadiow/OpenBK7231T_App/actions/runs/23667677706

if there are still misses please set loglevel to 6 and capture some button, app etc actions.