[P092] TA UVR interface - how to debug

[hollie]

Hello,

I discovered this project while searching for a solution to connect my solar heater over wifi. It looks promising!

My intention is to replace a custom interface I made for the solar boiler controller back in 2005 that connects over wired ethernet.
Times have changed and it is time to connect my boiler over MQTT

As I see that somebody already built a plugin for the specific controller I have on my solar boiler (a TA UVR-61, supported by plugin 092) I am attempting to set this up. I do experience an issue however: I cannot read valid sensor readings from the controller, although I am sure that the databus between the controller and the ESP has valid information (my old interface that is in parallel to the ESP can decode it fine).

I am using git build mega-20230306 collection C on a WROOM-32D module.

I have verified dat the signal that arrives at the device is as expected: it has the expected signal rate and expected logic level. See the attached scope screenshot. I have tried to read pulses with a pulsecounter input on the same pin, that also works fine. So the pin functionality is fine. I have also verified that the protocol version as described in the documentation for the UVR61-3 controller with firmware older than v8.2 is in line with the documentation I received from TA at the time I build my controller.

The logfile in the terminal that is connected to the ESP shows a status message telling me 'still receiving DL status bits`. See below for more a more details log.

My question: what is the best way to troubleshoot this further? Any pointers are welcome.

Thanks and best regards,
Lieven.

Code: Select all

914179 : Info   : PLUGIN_092_READ Task:0
914180 : Info   : P092_read: Still receiving DL-Bus bits!
914233 : Info   : PLUGIN_092_READ Task:1
914234 : Info   : P092_read: Still receiving DL-Bus bits!
916767 : Info   : WD   : Uptime 15 ConnectFailures 0 FreeMem 197008 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
946767 : Info   : WD   : Uptime 16 ConnectFailures 0 FreeMem 197008 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
974179 : Info   : PLUGIN_092_READ Task:0
974180 : Info   : P092_read: Still receiving DL-Bus bits!
974234 : Info   : PLUGIN_092_READ Task:1
974235 : Info   : P092_read: Still receiving DL-Bus bits!
976768 : Info   : WD   : Uptime 16 ConnectFailures 0 FreeMem 197004 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
1006769 : Info   : WD   : Uptime 17 ConnectFailures 0 FreeMem 197004 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
1034179 : Info   : PLUGIN_092_READ Task:0
1034180 : Info   : P092_read: Still receiving DL-Bus bits!
1034233 : Info   : PLUGIN_092_READ Task:1
1034234 : Info   : P092_read: Still receiving DL-Bus bits!
1036767 : Info   : WD   : Uptime 17 ConnectFailures 0 FreeMem 197004 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init

[hollie]

Adding the screenshot from the oscilloscope

[Ath]

There seem to be (at least) 2 series of the TA UVR-61, that have different software versions, resulting in different capabilities.
What actual UVR-61 model and software version do you use? And have you tried both UVR-61 settings?

Looking back at the development history, I can't determine the amount of testing that went into each model. The UVR-42 support that I added last year was fully based on the data-sheet, comparing that to the UVR-31 implementation and data-sheet... (don't own any of these devices, and I haven't worked on the other models either).

Also have no idea if this has been tested on ESP32, I've seen some other plugins initially having trouble when first being used on ESP32. Do you have an ESP8266 board available that can be used for comparative testing? You'll need a matching Collection_C build for ESP8266, of course.

[hollie]

Hey Ath,

thanks for your reply. I am aware of the two different versions of the TA UVR-61 and I have verified that the firmware version I have (2.1) is indeed using the protocol that is described in the 'versions below 8.2'. I also did try the '8.3 and later' version for a test but that also did not work.

I have tried running it on an ESP8226 board first, but that did not work either. I actually bought the ESP32 board in an attempt to get this working because I had the impression that the ESP8266 board was struggling to run the web interface of ESP Easy and I thought that had something todo with the fact that the readout was not working.

I think there is indeed some more validation to be done on this plugin for the UVR61-3. I am willing to do that, I am just not sure where to start exactly. I'll go through the appendix section of the documentation first and try to get some debugging working.

Best regards,
Lieven.

[hollie]

Hi,

a short status update, I have in the mean time setup the development toolflow and recompiled the build C with the debug option for plugin P092.

The output log looks like this:

Code: Select all

10669 : Info   : P092 ISR set
10670 : Info   : P092_receiving ... TaskIndex:0
11666 : Info   : Processing...
11667 : Info   : Invert bit stream...
11668 : Error  : Start bit too close to end of stream!
11669 : Info   : # Required bits: 386 StartBit: 171 / EndBit: 486
11670 : Info   : P092_receiving ... TaskIndex:0
36916 : Info   : PLUGIN_092_READ Task:0
36917 : Info   : P092_read: Still receiving DL-Bus bits!
39220 : Info   : WD   : Uptime 1 ConnectFailures 0 FreeMem 199308 WiFiStatus WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
66915 : Info   : PLUGIN_092_READ Task:0
66917 : Info   : P092_read: Still receiving DL-Bus bits!

From that point on there is never a new attempt to process, only repetivive

Code: Select all

126915 : Info   : PLUGIN_092_READ Task:0
126916 : Info   : P092_read: Still receiving DL-Bus bits!

So I'll need to figure out why the `processing` message is only displayed once.

Best regards,
Lieven.

[hollie]

After enabling some more debugging statements in the code I got the plugin to successfully decode the DL-bus payload once after a reboot of the ESP.

The output then looked like:

Code: Select all

53864 : Info   : P092 ISR set
53865 : Info   : P092_receiving ... TaskIndex:0
55862 : Info   : Wrong Timings: 
55863 : Info   : 1: PulseCount:1: BitCount:0 Value:0x81 ValueBefore:0x0 ValueAfter:0x2
55864 : Info   : Processing...
55864 : Info   : Invert bit stream...
55864 : Info   : StartBit: 21 / EndBit: 500
55865 : Info   : Check CRC...
55865 : Info   : Data: 906faa3311d41720227c2290229322ff2fff2f008000000d31814000
55865 : Info   : Received data OK TI:0
67114 : Info   : PLUGIN_092_READ Task:0
67115 : Info   : Get Sensor1: 54.4
67145 : Debug  : MQTT : zonneboiler_1/panelen/Value 54.4

However, after that the value was never updated again, although the value on the LCD of the controller were changing.

This only happened once, all other attempts always result in the 'still receiving bits' message.

I have the impression that the plugin does not attempt to re-sync with the DL-bus bitstream if it fails to find sync once. It is not clear to me how I can fix this.

Anybody who can point me in the right direction?

Kind regards,
Lieven.

[Max Meyer]

Hi Lieven,

did you manage to solve the problem? I have the same problem but with a UVR1611.
I tried 8266 and esp32 with different kinds of settings in the plugin
Oszilloscope shows pulses with 3V ,pulsecounter works,
My Build is : ESP_Easy_mega_20240229_collection_C_ESP32_4M316k Feb 29 2024
Maybe you can provide me your image so I can check with the UVR1611. I also have an ESR31 and an UVR61-3 if neccessary

Kind regards
Max