Fault message A11-3071

[Nxtway]

More than 10 times a day I get the intermediate fault message A11-3071.
It indicates a communication problem to my (virtual) RC100H remote thermostat.

I capture an ems-esp logfile:
Err_Battery_Correction.txt

Maybe ems-esp want to read the remotecorrection and remotebattery information of the (virtual) RC100H.
But the simulation code in roomcontrol.cpp answer with an empty telegram for this requests.
Then the Buderus system interpret this empty answers as an error.
Please can you try to suppress the remotecorrection and remotebattery ems-esp requests for a virtual thermostat ?
Or another option might be to implement the remotecorrection and remotebattery requests also for a virtual thermostat ?

[MichaelDvP]

I don't think it's the empy reply to emsesp. Have you checked if there is a query from master thermostat? (thermostat(0x10) -R->thermostat(0x38)). Maybe it's the version info, we've seen this with RC200 giving errors if second subscriber is not replied.
I've made some changes in my test build https://github.com/MichaelDvP/EMS-ESP32/releases/tag/test
Please check, #1609 is also included.

[Nxtway]

I updated ems-esp yesterday evening to test build 3.6.5-test.12a but the issue happend again 2 times this night.

[MichaelDvP]

Then it's not the version info and not the correction and battery queries. You have to log the bus and check what happend at the time the error is logged in the thermostat.

[MichaelDvP]

Are you using the humidity? You can try if it is better to use RC200. I've also added a test for RF-sensor. Usage depends on Control-setting, Control: rc310 uses sensor, rc200 uses RC200, rc100 and rc100h uses RC100H emulation.
You have to stop emulation by sending remotetemp -1 (and wait for entities disapear) before changing the control and than set a new remotetemp.

[Nxtway]

Thanks, I will try the RC200 settings next week

[Nxtway]

I have followed your configuration steps for using an virtual RC200 but the same error messages pops up after a while.
In general the system works well but the diagnoses error memory spammed with this error and it would be nice to solve this somewhere.
Your suggestion was to capture the EMS communication in the time frame when to error happend, right ? Let's see if I could capture the issue.

[MichaelDvP]

Are you sure you aways send a valid value to the remote? Invalid stops remote, and this triggers a RC300 error. Maybe we should use only a single defined value (-1) to switch off and ignore other out of range values?

[Nxtway]

Yes only valid commands (see attachment). The error occurred 2 times during this session.
Log_20240216_0510.txt

I will try to make a capture when the error occurs

[Nxtway]

2 Logfiles with captured Error A11/3071 no communication to (virtual RC200) remote:
1st: Log_20240216_0900.txt
2nd: Log_20240216_1100.txt

[MichaelDvP]

Seems the polls are rare and sometimes the sending is > 1 minute, also the devices disappears from 0x07 telegram (but still sending poll-acks). Don't know why, i've changed to 30 sec sending intervall, maybe this helps. BTW: you only need to send remotetemp if it changes, the intervall is made inside ems-esp.

[Nxtway]

Sorry, same behavior with the new test version. Also an additional log file when the error occurs and gone.
At both events (error come and go) I pressed immediately the return button during the logging.
So you might see more precisely what happens (I pressed return maybe one or two seconds after the event).
Log_20240216_1530.txt
Might my huge number of custom entities the reason of such an instability ?

[MichaelDvP]

Yes, i can see in telegram 0x07: Device 0x38 missing:
000+00:16:12.230 T 3725: [emsesp] boiler(0x08) -B-> All(0x00), UBADevices(0x07), data: 09 01 00 00 00 00 00 00 01 08 00 00 00
Device 0x38 present:
000+00:19:17.223 T 4573: [emsesp] boiler(0x08) -B-> All(0x00), UBADevices(0x07), data: 09 01 00 00 00 00 01 00 01 08 00 00 00
But i don't know why it is deleted again. Normally it is present as long as the master polls are answered and we acknowledge every poll. @proddy Do you have an idea?

[airhead1234]

I have a RC200 RF connected to a RC310 via a RFM200 and have captured data which is hopefully helpful.

Take 1 - changing between automatic and manual mode on RC200 RF
Take 01 - man-auto.txt

• 00:00 - starting in manual mode
• 00:15 - changing to automatic mode
• 00:30 - changing to manual mode

Take 2 - changing the temperature setpoint on RC200 RF
Take 02 - change setpoint.txt

• 00:00 - starting at 19.0° C
• 00:20 - changing to 20.0° C
• 00:30 - changing to 21.0° C
• 00:40 - changing to 22.0° C
• 00:50 - changing to 23.0° C
• 01:00 - changing to 18.5° C

Take 3 - room temperature as measured by RC200 RF
Take 03 - change temperature.txt

• 00:00 - starting at 24.7° C
• 00:40 - changing to 24.5° C
• 01:40 - changing to 24.4° C
• 02:40 - changing to 24.6° C
• 03:40 - changing to 24.8° C
• 04:40 - changing to 25.1° C

Please let me know if you want me to try anything else.

[MichaelDvP]

Thank you, this RC200 is same product id 157, but lower version as we have from other log. The version is sended with length 10, as requested by master thermostat, and it is sometimes broadcasted. The device detection from boiler (telegram 0x07) is stable with devices 0x38 and 0x50 connected.

Can you also read the complete version from the RF-Base (0x50), read 50 2.
The mode change i can not see, it should send to the master with telegram 0x2B9, but there is only on 2B9 with mode manual in the log and no command from 0x38.
The setpoint is send to the master as manual temp, same as we do in thermostat/seltemp, this should work. It is not stored in the remote thermostat.
The room temperatures are send with 0x42B (as known) with roomtemp (*10), roomtemp (*100) and a final byte 0x1. Can you also log when the temperature decreases over time?

I'll change in my test-build to version with 10 byte and v32.02. Maybe this helps. Next we can try to broadcast the version periodical.

[airhead1234]

Here is the complete version from the RF-Base:

ems-esp:$ read 50 2
000+00:42:51.712 N 29: [emsesp] connect(0x50) -W-> Me(0x0B), Version(0x02), data: DA 22 05 00 FF 00 00 00 00

A log with decreasing temperature will follow separately.

[airhead1234]

And here is temperature increasing and decreasing:

Take 4 - room temperature as measured by RC200 RF
Take 04 - change temperature.txt

• 00:00 - starting at 20.7° C
• 00:39 - changing to 20.8° C
• 01:39 - changing to 23.4° C
• 02:39 - changing to 29.1° C
• 03:49 - changing to 29.6° C
• 04:49 - changing to 29.2° C
• 05:39 - changing to 28.5° C
• 06:39 - changing to 27.7° C
• 07:39 - changing to 27.1° C

Please let me know what you need next.

[proddy]

Yes, i can see in telegram 0x07: Device 0x38 missing: 000+00:16:12.230 T 3725: [emsesp] boiler(0x08) -B-> All(0x00), UBADevices(0x07), data: 09 01 00 00 00 00 00 00 01 08 00 00 00 Device 0x38 present: 000+00:19:17.223 T 4573: [emsesp] boiler(0x08) -B-> All(0x00), UBADevices(0x07), data: 09 01 00 00 00 00 01 00 01 08 00 00 00 But i don't know why it is deleted again. Normally it is present as long as the master polls are answered and we acknowledge every poll. @proddy Do you have an idea?

I'm not sure why it's doing this. If an EMS device is discovered by process_UBAdevices() it remains so the 0x38 thermostat shouldn't disappear.

[airhead1234]

I have now tested the test-build version with 10 byte and v32.02 (3.6.5-test.15) of @MichaelDvP. This works better than the previous virtual RC200 and I can now indeed control heating via changing the temperature of the virtual RC200. This was not possible with previous versions.

There are still all kinds of error messages in the logs. Maybe you can have a look:

Take 5 - modifying measured temperature of virtual RC200
Take 05 - Virtual RC200.txt

In addition, the entities reported by my RC310 differ between using a virtual RC200 to using a real RC200. When using the virtual RC200 the entity hc1/remotetemp is listed. This one does not show up when using the real RC200. There still seem to be difference between the virtual and the real RC200. Please see the CSV files of the entities for both setups:

Real RC200
r_Thermostat_RC300_RC310_Moduline 3000_1010H_CW400_Sense II_HPC410.csv

Virtual RC200
v_Thermostat_RC300_RC310_Moduline 3000_1010H_CW400_Sense II_HPC410.csv

Please let me know how I can help to optimize the virtual RC200.

[MichaelDvP]

Good, the UBADevices now shows constantly the 0x38 device UBADevices(0x07), data: 09 01 00 00 00 00 01 00 00 00 00 00 00 00 00

The hc1/remotetemp is not a ems entity, it is only ems-esp internal for setting the remote. In a real RC200 it should not be shown (or we get a conflict).

There are a few incomplete telegrams that looks like we sometimes miss a break while receiving after a poll-ack-echo. E.g. Incomplete Rx: 38 08 00 FF 10 06 74 00 7A 00 7A is showing the poll-ack 0x38 from before and then a complete telegram 08 00 FF 10 06 74 00 7A 00 7A. This is not a real issue on the bus, it is a timing inside ems-esp uart receive that shows a valid telegram as broken. Some others like Incomplete Rx: FE FC 08 00 E3 00 00 00 00 00 00 00 00 00 00 00 00 01 A8 00 00 50 00 are caused by garbage receive (EMC) and are normal.

[jurajbelobrad]

Hello, I have performed test with Test Build v3.6.5-test.16.

My sequence of commands:

Selected room temp 12 C for hc2, remotetemp send via Scheduler.
Time 20:58 - Initial setup of remotetemp to 15 -> RC100H device appears
Time 21:00 - hc2 control device set to RC100H
Time 21:02 - Remotetemp set to 11 ... heating activated, hc2 pump valve opening
Time 21:07 - Remotetemp set to 17 ... heating still activated
Time 21:10 - Remotetemp set to -1 ... heating still activated
Time 21:14 - hc2 control device set back to RC310 ... heating deactivated

A11(3092) error still present, heating does not react to change of remote temp
Log, printscreens from EMS ESP, and heating graph from Grafana attached (I can add any parameter to the graphs in future, if this helps to understand the ems communication).

Am I doing something wrong, or there is still something unknown with RC310 communication?

log(4).txt

[MichaelDvP]

Thanks for the log. @proddy has reduced the delay for weblog, now ~1/4 get lost on slower computers/browsers. I'll enlarge the delay in next testbuild. But i can see what happens in the log.

• the remote detection is working now, boiler 0x07 message is stable showing device 0x39 as long as it sends.
• on start there is a 0x41 device, this was a test to emulate a wireless sensor if control is set to internal. This does not work, i'll remove it. Maybe there is additional config for wireless base at 0x50 needed, but this is unknown.
• Error A11-3071 is generated after the remote is stopped and control is still on RC100H, that's right.

Your points:

Selected room temp 12 C for hc2, remotetemp send via Scheduler.

Why do you use the scheduler for that? seltemp does not need to be repeated and remotetemp is repeated by internal logic.

Time 20:58 - Initial setup of remotetemp to 15 -> RC100H device appears

I this case it generates a 0x41 device, not the RC100H,

Time 21:00 - hc2 control device set to RC100H

After the next sending of remotetemp the RC100H appears. The A11 error shows up after 1 minute if the remoettemps is nt send yet.

Time 21:02 - Remotetemp set to 11 ... heating activated, hc2 pump valve opening

Now we have RC100H and the RC310 reports the 11 degrees as roomtemp

Time 21:07 - Remotetemp set to 17 ... heating still activated

6 degrees up in a few seconds, unrealistic, i don't know what the PID-control do with this, some internal overflow i guess.

Time 21:10 - Remotetemp set to -1 ... heating still activated

One minute later the error A11 is shown because control is still on RC100H and values are missing.

Time 21:14 - hc2 control device set back to RC310 ... heating deactivated

When sending the remotetemp the virtual remote sends this as roomtemp to the thermostat R310. If it works RC310 shows the new roomtemp and starts to calculate the flowtemp that is needed. This flowtemp is send to the mixer. Mixer sets the mixingvalve to mix down to the flowtemp, the valve needs 2 minuten for closing (or opening). Then mixer tells the boiler what header temperature is needed. Boiler will complete the current heating cycle and in next cycle it heats to the new temperature.

If you want to test, set a remotetemp near the seltemp (a bit lower) and wait half an hour what happens, Check the flowtemp at mixer, should go slowly up. Then set remotetemp to a bit higher than seltemp and watch the flowtemp going slowly down. If you have a outdoor sensor the control is mainly weather controled and roomtemp has only little influence.

To avoid the error message make sure you always change control and set/unset remotetemp within one minute.
Start remote: first set control to RC100H, than send remotetemp direct after
Stop remote: first set control to RC310, than send -1 to remotetemp.

BTW: the error code entity is set on error and updated only every 4 minutes (on my RC35). To check if the error is still active better use the last error code showing time marks or duration.

Let's see what the RC310 do, starting with:
20:54:49.621 TRACE 104: [emsesp] thermostat(0x10) -W-> Me(0x0B), RC300Monitor(0x02A6), data: 00 A2 23 18 00 00 18 18 05 A0 00 03 01 00 7E 03 7E 00 00 11 01 02 06 56 00
internal roomtemp is 0x00A2 16.2°C, setpoint 0x18 : 12.0°C, calc. Flowtemp 0

Now the first remotetemp after set to RC100H
21:02:22.347 TRACE 1309: [emsesp] thermostat(0x39) -W-> thermostat(0x10), RemoteTemp(0x042C), data: 00 6E
roomtemp 0x006E: 11.0°C
21:02:31.945 TRACE 1337: [emsesp] thermostat(0x10) -B-> All(0x00), RC300Monitor(0x02A6), data: 00 6E 03 18 28 00 18 18 05 A0 00 03 01 00 76 03 86 00 00 11 01 02 FF FF 00
RC310 get the value and report roomtemp 11.0°C, setpoint 12.0°C, calculated flowtemp 0x28: 40°C High flotemp needed because the roomtemp drops very, very fast (16->11).
and sends the flowtemp to mixer
21:03:33.655 TRACE 1499: [emsesp] thermostat(0x10) -W-> mixer(0x21), ?(0x02E2), data: 01 28 64 00 01
The mixer requests from boiler a headertemp (boiler-flowtemp) of 45°C (0x2D)
21:04:32.791 TRACE 1640: [emsesp] mixer(0x21) -W-> boiler(0x08), UBASetPoints(0x1A), data: 2D 64 00
and mixer reports pump 100%, setflowtemp 40°C (0x28), mesured flowtemp 17.8°C (0x00B2)
21:04:33.019 TRACE 1642: [emsesp] mixer(0x21) -B-> All(0x00), MMPLUSStatusMessage_HC(0x02D8), data: 01 01 64 00 B2 28 00 00 08

Funny what happens at switching off the remotetemp:
21:10:21.000 INFO 2438: [command] Calling command 'thermostat/remotetemp' (room temperature from remote) with value -1 and id 2 on device 0x10
The RC310 suddenly gets no remotetemp and sets the flowtemp as roomtemperature 40.0°C (0x0190)
21:10:24.964 TRACE 2456: [emsesp] thermostat(0x10) -B-> All(0x00), RC300Monitor(0x02A6), data: 01 90
At this time there is no error reported
21:10:33.742 TRACE 2504: [emsesp] thermostat(0x10) -B-> All(0x00), RCError(0xA2), data: 00 00 00 00 00
But 2 minutes later we get first collected rror (0xBF) and then Thermosta error (0xA2):
21:12:51.008 TRACE 2846: [emsesp] thermostat(0x10) -B-> All(0x00), ?(0xBF), data: 10 9E 00 0E 11 41 31 31 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
21:12:53.290 TRACE 2851: [emsesp] thermostat(0x10) -B-> All(0x00), RCError(0xA2), data: 41 31 31 0C 00
After setting the control to interna
21:14:36.146 INFO 3114: [command] Calling command 'thermostat/control' (control device) with value RC310 and id 2 on device 0x10
21:14:36.661 TRACE 3117: [emsesp] Me(0x0B) -W-> thermostat(0x10), HPMode(0x0292), data: 00 (offset 3)
The thermostat gets the internal roomtemp again 0x00A3: 16.3°C
21:15:17.835 TRACE 3207: [emsesp] thermostat(0x10) -B-> All(0x00), RC300Monitor(0x02A6), data: 00 A3

[proddy]

Thanks for the log. @proddy has reduced the delay for weblog, now ~1/4 get lost on slower computers/browsers

the right thing to do is not use any delay and keep the log seen in the Web in sync with the server. I'll think about how

[MichaelDvP]

Agree, that's better. Maybe set a longer timeout (300-500ms) in esp and post back the message-id on event receive.
If the post is received in esp the next message-event can be send immediatly, otherwise repeat the message after timeout.
It could help to pack all queued messages to one event as json-array, that reduces the number of events.

[jurajbelobrad]

Thanks for the detailed analysis.

I have tried the excercise as proposed - time 18:00-19:30, the remotetemp was sent from Loxone manually.
It seems, that the heating is running even when the selected room temperature has been reached.
I have observed, that set flow temperature was jumping from 0 to 45 and back, not sure, if this is normal.

Yesterday at night I let the heating running with remotetemp values from real sensor - DS18B20.
Same behavior observed - hc2 heating was running until I reverted back around 6AM to RC310. Unfortunatelly, the logging was interrupted.

log(18_01-19_07).txt
log(19_00-19_28).txt
log-night.txt

[airhead1234]

Could it be that the virtual RC200 that worked wonderfully with version 3.6.5-test.12b from @MichaelDvP as discussed in #1611 (comment) does not work with the "official" version v3.6.5-dev.18?

When I set the remote device to RC200 and then execute call thermostat remotetemp 22 version test.12b does indeed create a virtual RC200 that behaves as expected. When I do the same in version dev.18 a RC100H is created despite me having selected RC200 as remote control device. Moreover, the temperature of the RC100H does not have any influence on the heating of my system.

[MichaelDvP]

Yes, actually it's only in the test build, but i keep the testbuild in sync with the official dev, See: https://github.com/MichaelDvP/EMS-ESP32/releases

[airhead1234]

Thank you, with your test build it works like a charm again. How can I see by myself once this functionality has been integrated into the versions at https://github.com/emsesp/EMS-ESP32?