search

emsesp / EMS-ESP

ESP8266 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
303 stars 97 forks source link

Support for Junkers CerastarComfort ZWR and Junkers Bosch CR 100 #103

Closed philrich closed 5 years ago

philrich commented 5 years ago

Hello,

First of all: Thanks for the amazing work you have done on this project!

I own the following heating Components:

I have ordered bbqkees circuit and connected it to the EMS-Bus (connected cables in parallel to the thermostat connectors). I also built and installed the latest Firmware from the dev-Branch (1.7.0b9).

As others it seems I am not able to send data to the bus (Tx: no signal). The Tx queue is filling up slowly. I also tried to set tx_delay on but that didn't help. autodetect, send .., refresh ist not working, nothing gets sent back, queue fills up.

After manually setting Boiler (set boiler_type 08) and Thermostat (set thermostat_type 18) I see stats in the info screen. Unfortunately some values are missing or wrong.

This is how my info screen looks now:

EMS-ESP system stats:                                                                                                                                        [10/523]
  System logging set to None
  LED is off, Silent mode is off
  Thermostat is enabled, Boiler is enabled, Shower Timer is disabled, Shower Alert is disabled

EMS Bus stats:
  Bus is connected
  Rx: Poll=7 ms, # Rx telegrams read=0, # CRC errors=0
  Tx: no signal

Boiler stats:
  Boiler: DeviceID: 0x08 (ProductID:0 Version:?)
  Hot tap water: off
  Central heating: off
  Warm Water activated: ?
  Warm Water circulation pump available: ?
  Warm Water selected temperature: ? C
  Warm Water desired temperature: ? C
  Warm Water current temperature: 23.0 C
  Warm Water current tap water flow: 0.0 l/min
  Warm Water # starts: 6543 times
  Warm Water active time: 6 days 20 hours 4 minutes
  Warm Water 3-way valve: on
  Selected flow temperature: 0 C
  Current flow temperature: 24.0 C
  Return temperature: ? C
  Gas: off
  Boiler pump: off
  Fan: on
  Ignition: off
  Circulation pump: off
  Burner selected max power: 0 %
  Burner current power: 0 %
  Flame current: 0.1 uA
  System pressure: ? bar
  System service code:  (0)
  Heating temperature setting on the boiler: ? C
  Boiler circuit pump modulation max power: ? %
  Boiler circuit pump modulation min power: ? %
  Outside temperature: ? C
  Boiler temperature: ? C
  Pump modulation: 0 %
  Burner # starts: 17360 times
  Total burner operating time: 81 days 14 hours 10 minutes
  Total heat operating time: 74 days 18 hours 6 minutes

Thermostat stats:
  Thermostat: DeviceID: 0x18 (ProductID:0 Version:?)
  Setpoint room temperature: 16.5 C
  Current room temperature: 22.8 C
  Thermostat time is 01:07:24 26/4/2019
  Mode is set to ?

After disconnecting/reconnecting the Thermostat, this is what I get with log v.

(20:40:04.110) Boiler -> all, type 0x18 telegram: 88 00 18 00 00 01 05 00 00 00 22 44 C0 00 F5 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 (CRC=4A), #data=25
<--- UBAMonitorFast(0x18) received
(20:40:04.351) Boiler -> all, type 0x34 telegram: 88 00 34 00 37 00 F5 80 00 81 00 00 01 00 00 26 41 00 19 6A 00 (CRC=C9), #data=17
<--- UBAMonitorWWMessage(0x34) received
(20:40:05.223) Boiler -> all, type 0x07 telegram: 88 00 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=E6), #data=15
(20:40:13.464) Thermostat -> Boiler, type 0x07 telegram: 98 88 07 00 0E (CRC=67)
(20:40:13.498) Boiler -> Thermostat, type 0x07 telegram: 88 18 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=7C), #data=14
(20:40:13.523) Thermostat -> Boiler, type 0xEF telegram: 98 88 EF 00 01 (CRC=E3)
(20:40:13.545) Boiler -> Thermostat, type 0xEF telegram: 88 18 EF 00 (CRC=83)
(20:40:13.595) Thermostat -> Boiler, type 0x02 telegram: 98 88 02 00 0A (CRC=77)
<--- Version(0x02) received
(20:40:13.625) Boiler -> Thermostat, type 0x02 telegram: 88 18 02 00 5F 23 03 00 00 00 00 00 00 00 (CRC=D1), #data=10
<--- Version(0x02) received
Boiler found. Model Bosch Condens 2500/Junkers Cerapur Comfort (DeviceID:0x08 ProductID:95 Version:35.03)
* Setting Boiler to model Bosch Condens 2500/Junkers Cerapur Comfort (DeviceID:0x08 ProductID:95 Version:35.03)
Requesting type UBAMonitorFast(0x18) from dest 0x08
Requesting type UBAMonitorSlow(0x19) from dest 0x08
Requesting type UBAParameterWW(0x33) from dest 0x08
Requesting type UBAParametersMessage(0x16) from dest 0x08
Requesting type UBATotalUptimeMessage(0x14) from dest 0x08
(20:40:13.706) Boiler -> Thermostat, type 0x04 telegram: 88 18 04 0B 27 00 00 00 (CRC=35)
(20:40:13.812) Boiler -> all, type 0x07 telegram: 88 00 07 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=6F), #data=15
(20:40:14.101) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 00 01 A5 00 E0 21 2C (CRC=06)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:14.298) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 06 01 A5 2C 22 00 CA 03 03 (CRC=98)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:14.511) Boiler -> all, type 0x18 telegram: 88 00 18 00 00 01 05 00 00 00 22 44 C0 00 F5 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 (CRC=4A), #data=25
<--- UBAMonitorFast(0x18) received
(20:40:14.751) Boiler -> all, type 0x34 telegram: 88 00 34 00 37 00 F4 80 00 81 00 00 01 00 00 26 41 00 19 6A 00 (CRC=DF), #data=17
<--- UBAMonitorWWMessage(0x34) received
(20:40:15.030) Thermostat -> all, type 0x01B9 telegram: 98 00 FF 08 01 B9 FF (CRC=FA)
(20:40:15.221) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 0B 01 A5 03 01 00 CA (CRC=E7)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:15.470) Thermostat -> all, type 0x01F5 telegram: 98 00 FF 00 01 F5 00 (CRC=DD)
(20:40:15.661) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 0D 01 A5 00 CA 02 D8 (CRC=77)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:15.943) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 00 01 A5 00 E0 (CRC=1A)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:16.134) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 1A 01 A5 07 (CRC=AA)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:16.406) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 27 01 A5 00 (CRC=5C)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:16.585) Thermostat -> Boiler, type 0x33 telegram: 98 88 33 00 0D (CRC=B4)
<--- UBAParameterWW(0x33) received
Publishing boiler data via MQTT
Publishing thermostat data via MQTT
(20:40:16.777) Thermostat -> Boiler, type 0x25 telegram: 98 88 25 0A 0B (CRC=FE)
(20:40:16.793) Boiler -> Thermostat, type 0x25 telegram: 88 18 25 0A (CRC=04)
(20:40:16.818) Thermostat -> Boiler, type 0x15 telegram: 98 88 15 00 05 (CRC=24)
(20:40:16.830) Boiler -> Thermostat, type 0x15 telegram: 88 18 15 00 00 00 00 00 00 (CRC=75)
(20:40:16.852) Thermostat -> Boiler, type 0x18 telegram: 98 88 18 05 01 (CRC=1E)
<--- UBAMonitorFast(0x18) received
(20:40:16.863) Boiler -> Thermostat, type 0x18 telegram: 88 18 18 05 00 (CRC=E2)
<--- UBAMonitorFast(0x18) received
(20:40:16.884) Thermostat -> Boiler, type 0x34 telegram: 98 88 34 08 01 (CRC=B4)
<--- UBAMonitorWWMessage(0x34) received
(20:40:16.919) Boiler -> Thermostat, type 0x34 telegram: 88 18 34 08 01 (CRC=49)
<--- UBAMonitorWWMessage(0x34) received
(20:40:16.948) Thermostat -> Boiler, type 0x04 telegram: 98 88 04 05 01 (CRC=6E)
(20:40:16.982) Boiler -> Thermostat, type 0x04 telegram: 88 18 04 05 32 (CRC=A0)
(20:40:17.015) Thermostat -> all, type 0xFF01 telegram: 98 00 F7 00 FF 01 F5 27 0D (CRC=59)
(20:40:17.293) Thermostat -> all, type 0xFF01 telegram: 98 00 F7 00 FF 01 F5 07 0C (CRC=18)
(20:40:17.473) Thermostat -> Boiler, type 0x04 telegram: 98 88 04 0F 01 (CRC=7A)
(20:40:17.480) Boiler -> Thermostat, type 0x04 telegram: 88 18 04 0F (CRC=43)
(20:40:17.498) Thermostat -> Boiler, type 0x04 telegram: 98 88 04 14 01 (CRC=4C)
(20:40:17.511) Boiler -> Thermostat, type 0x04 telegram: 88 18 04 14 (CRC=58)
(20:40:17.530) Thermostat -> Boiler, type 0x25 telegram: 98 88 25 00 01 (CRC=E0)
(20:40:17.543) Boiler -> Thermostat, type 0x25 telegram: 88 18 25 00 (CRC=0E)
(20:40:17.681) Thermostat -> 0x09, type 0x29 telegram: 98 89 29 00 01 (CRC=D8)
(20:40:17.700) 0x09 -> Thermostat, type 0x29 telegram: 89 18 29 00 69 (CRC=55)
(20:40:17.733) Thermostat -> Boiler, type 0x26 telegram: 98 88 26 06 02 (CRC=E3)
(20:40:17.761) Boiler -> Thermostat, type 0x26 telegram: 88 18 26 06 (CRC=0E)
(20:40:17.786) Thermostat -> Boiler, type 0x16 telegram: 98 88 16 00 02 (CRC=2F)
<--- UBAParametersMessage(0x16) received
(20:40:17.795) Boiler -> Thermostat, type 0x16 telegram: 88 18 16 00 FF 42 (CRC=1C)
<--- UBAParametersMessage(0x16) received
(20:40:18.185) Thermostat -> Boiler, type 0x16 telegram: 98 88 16 00 02 (CRC=2F)
<--- UBAParametersMessage(0x16) received
(20:40:18.201) Boiler -> Thermostat, type 0x16 telegram: 88 18 16 00 FF 42 (CRC=1C)
<--- UBAParametersMessage(0x16) received
(20:40:18.229) Thermostat -> all, type 0xFF02 telegram: 98 00 F7 00 FF 02 1D 07 (CRC=CF)
(20:40:18.409) Thermostat -> Boiler, type 0x07 telegram: 98 88 07 00 0E (CRC=67)
(20:40:18.433) Boiler -> Thermostat, type 0x07 telegram: 88 18 07 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 (CRC=B4), #data=14
(20:40:18.497) Thermostat -> Boiler, type 0x08 telegram: 98 88 08 00 0A (CRC=5F)
(20:40:18.511) Boiler -> Thermostat, type 0x08 telegram: 88 18 08 00 (CRC=54)
(20:40:18.531) Thermostat -> Boiler, type 0x19 telegram: 98 88 19 19 02 (CRC=21)
<--- UBAMonitorSlow(0x19) received
(20:40:18.544) Boiler -> Thermostat, type 0x19 telegram: 88 18 19 19 80 00 (CRC=BC)
<--- UBAMonitorSlow(0x19) received
(20:40:18.572) Thermostat -> Boiler, type 0x34 telegram: 98 88 34 03 02 (CRC=A1)
<--- UBAMonitorWWMessage(0x34) received
(20:40:18.612) Boiler -> Thermostat, type 0x34 telegram: 88 18 34 03 80 00 (CRC=A5)
<--- UBAMonitorWWMessage(0x34) received
(20:40:18.635) Thermostat -> Boiler, type 0x14 telegram: 98 88 14 00 03 (CRC=26)
<--- UBATotalUptimeMessage(0x14) received
(20:40:18.873) Thermostat -> Boiler, type 0x17 telegram: 98 88 17 00 18 (CRC=31)
(20:40:18.886) Boiler -> Thermostat, type 0x17 telegram: 88 18 17 00 (CRC=6A)
(20:40:18.913) Thermostat -> all, type 0x01F5 telegram: 98 00 FF 00 01 F5 01 (CRC=DC)
(20:40:19.097) Thermostat -> Boiler, type 0x19 telegram: 98 88 19 00 1B (CRC=0A)
<--- UBAMonitorSlow(0x19) received
(20:40:19.141) Boiler -> Thermostat, type 0x19 telegram: 88 18 19 00 80 00 80 00 00 EC FF FF 00 00 00 43 AB 01 CA C0 00 00 00 01 A4 7E 00 2A 41 80 00 (CRC=BF), #data
=27
<--- UBAMonitorSlow(0x19) received
(20:40:19.273) Thermostat -> Boiler, type 0x1C telegram: 98 88 1C 06 13 (CRC=1A)
(20:40:19.297) Boiler -> Thermostat, type 0x1C telegram: 88 18 1C 06 00 00 01 CA C0 (CRC=8E)
(20:40:19.319) Thermostat -> Boiler, type 0x16 telegram: 98 88 16 01 01 (CRC=2E)
<--- UBAParametersMessage(0x16) received
(20:40:19.361) Boiler -> Thermostat, type 0x16 telegram: 88 18 16 01 42 (CRC=90)
<--- UBAParametersMessage(0x16) received
(20:40:19.379) Thermostat -> Boiler, type 0x25 telegram: 98 88 25 00 0B (CRC=EA)
(20:40:19.386) Boiler -> Thermostat, type 0x25 telegram: 88 18 25 00 (CRC=0E)
(20:40:19.713) Thermostat -> Boiler, type 0x25 telegram: 98 88 25 00 0B (CRC=EA)
(20:40:19.729) Boiler -> Thermostat, type 0x25 telegram: 88 18 25 00 (CRC=0E)
(20:40:19.747) Thermostat -> Boiler, type 0x26 telegram: 98 88 26 01 07 (CRC=E8)
(20:40:19.760) Boiler -> Thermostat, type 0x26 telegram: 88 18 26 01 (CRC=09)
(20:40:19.779) Thermostat -> Boiler, type 0x27 telegram: 98 88 27 02 0C (CRC=E1)
(20:40:19.791) Boiler -> Thermostat, type 0x27 telegram: 88 18 27 02 (CRC=08)
(20:40:19.811) Thermostat -> 0x09, type 0x29 telegram: 98 89 29 00 01 (CRC=D8)
(20:40:19.824) 0x09 -> Thermostat, type 0x29 telegram: 89 18 29 00 69 (CRC=55)
(20:40:20.274) Thermostat -> Boiler, type 0x2A telegram: 98 88 2A 14 01 (CRC=F4)
(20:40:20.291) Boiler -> Thermostat, type 0x2A telegram: 88 18 2A 14 (CRC=04)
(20:40:20.314) Thermostat -> Boiler, type 0x34 telegram: 98 88 34 00 09 (CRC=AC)
<--- UBAMonitorWWMessage(0x34) received
(20:40:20.333) Boiler -> Thermostat, type 0x34 telegram: 88 18 34 00 37 00 F5 80 00 81 00 00 01 (CRC=09), #data=9
<--- UBAMonitorWWMessage(0x34) received
(20:40:20.598) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 0D 01 A5 00 C9 02 D9 (CRC=7A)
<--- RCPLUSStatusMessage(0x1A5) received
(20:40:22.426) Thermostat -> Boiler, type 0x18 telegram: 98 88 18 23 01 (CRC=52)
<--- UBAMonitorFast(0x18) received
(20:40:22.446) Boiler -> Thermostat, type 0x18 telegram: 88 18 18 23 (CRC=57)
<--- UBAMonitorFast(0x18) received

Is there anything I can try to make Tx work? What else can I do to help to get my Boiler/Thermostat get fully supported?

cheers, Philipp

proddy commented 5 years ago

damn, I thought we'd fixed the Tx problem! I assume its all wired up correctly so it can only be a timing issue on the bus itself, which in itself is strange since another user also uses a similar Junkers boiler and it works for him. When the code starts it is supposed to autodetect both the boiler and thermostat models but since Tx is not working this is why you had to manually set them with set.

Could you try log v send 0B 98 02 00 20

this sends a read request to your 0x18 boiler for type 0x02 which is the version. So in the log you should see 'Sending....' and hopefully a response back. If not I'm afraid you may need to get a cheap 5 Euro logic analyzer and see what's blocking the transmits. Also worth searching for the guy with the other Junkers and comparing results.

philrich commented 5 years ago

hi, thanks for the quick response. i tried your suggestions and this is what i get

log v
System Logging set to Verbose
send 0B 98 02 00 20(00:01:05.895) Thermostat -> all, type 0x01A5 telegram: 98 00 FF 0D 01 A5 01 CD 01 D5 (CRC=68)
<--- RCPLUSStatusMessage(0x1A5) received

queue(00:01:10.434) Thermostat -> all, type 0x06 telegram: 98 00 06 00 13 04 10 1A 04 05 04 01 18 FF 00 (CRC=0F), #data=11
<--- RCTime(0x06) received

Tx queue (10/50)
 [1] action=read dest=0x08 type=0x02 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:00:03)
 [2] action=read dest=0x30 type=0x02 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:00:03)
 [3] action=read dest=0x18 type=0x02 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:00:03)
 [4] action=read dest=0x18 type=0x06 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:00)
 [5] action=read dest=0x08 type=0x18 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:00)
 [6] action=read dest=0x08 type=0x19 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:00)
 [7] action=read dest=0x08 type=0x33 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:00)
 [8] action=read dest=0x08 type=0x16 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:00)
 [9] action=read dest=0x08 type=0x14 offset=0 length=6 dataValue=32 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:00)
 [10] action=? dest=0x18 type=0x02 offset=0 length=6 dataValue=0 comparisonValue=0 type_validate=0x00 comparisonPostRead=0x00 @ (00:01:06)
(00:01:12.268) Boiler -> all, type 0x18 telegram: 88 00 18 00 00 00 E2 00 00 00 22 44 C0 00 E1 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 (CRC=7E), #data=25
<--- UBAMonitorFast(0x18) received
(00:01:12.509) Boiler -> all, type 0x34 telegram: 88 00 34 00 37 00 E0 80 00 81 00 00 01 00 00 26 83 00 19 92 00 (CRC=9B), #data=17
<--- UBAMonitorWWMessage(0x34) received
log n
System Logging set to None

This was directly after a reboot of the ems-esp, therefore the short tx queue.

You said, i should see a 'Sending....' in the log but aparently it is not there. and no response either. Maybe the delay is not right and sometimes works, sometimes not??

I am not really into hardware hacks but if it has to be done then I would try. But I have no idea about this logic analyzer thing .. :-/ I will also search the other Junkers guy ..

Any other Ideas?

proddy commented 5 years ago

i noticed the "Tx: no signal" in your log which gets displayed after an 'info' command. This means the EMS bus master (boiler) is not sending a poll request to our device (which has a type 0x0B) which in turn is the trigger to send any Tx messages. I recall seeing this issue before and need to look at older issues to see if this is the same conditions. In the meantime you can try the 'startup' command which is not documented and experimental but tries to send commands to the Boiler saying our device is alive

philrich commented 5 years ago

Unfortunately no response from the Busmaster after startup command. I think you refer to this issue: https://github.com/proddy/EMS-ESP/issues/39.

I have also tried all send ... commands which you recommended in this issue - to no avail.

Later, i will reboot the Thermostat and attach the log from the boot sequence. you can already see a thermostat boot in the log of the initial issue message. It starts at timestamp '(20:40:13.464)'

philrich commented 5 years ago

ok, so the boot sequence from the thermostat is this

(00:09:11.720) Thermostat -> Boiler, type 0x07 telegram: 98 88 07 00 0E (CRC=67)
(00:09:11.749) Boiler -> Thermostat, type 0x07 telegram: 88 18 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=7C), #data=14
(00:09:11.771) Thermostat -> Boiler, type 0xEF telegram: 98 88 EF 00 01 (CRC=E3)
(00:09:11.796) Boiler -> Thermostat, type 0xEF telegram: 88 18 EF 00 (CRC=83)
(00:09:11.843) Thermostat -> Boiler, type 0x02 telegram: 98 88 02 00 0A (CRC=77)
<--- Version(0x02) received
(00:09:11.870) Boiler -> Thermostat, type 0x02 telegram: 88 18 02 00 5F 23 03 00 00 00 00 00 00 00 (CRC=D1), #data=10
<--- Version(0x02) received

i tried to simulate this with

send 8B 88 07 00 0E
send 8B 88 EF 00 01
send 8B 88 02 00 0A

but it didnt work

philrich commented 5 years ago

so what i don't get: if we need to get polled by the busmaster before we can send something, the above send-commands never get sent because we are not getting polled. right?

i see above send requests in the txqueue which is growing. so if there has to be done some kind of handshake before we get polled there has to be some other way to send to the bus.

proddy commented 5 years ago

that's correct. Its waiting for the Poll which is single byte of 0x8B which for some reason you're not getting. You could modify the code around line 656 in ems.cpp to print out which polls you are getting?

philrich commented 5 years ago

i made this:

 653         _last_emsPollFrequency          = EMS_RxTelegram.timestamp;
 654         myDebug("Received 1 Byte: 0x%02X", value);
 655         // check first for a Poll for us

i attached the log which i am getting after this here: ems-log-received1b.txt (made with tmux capture so all control characters like ^M are in there. best view with less -R ..)

i also made a short count of values with this command (grep "Received 1 Byte" ems-log-received1b.txt | sort | uniq -c) here: received1b-count.txt

so, in many of these single byte telegrams the 7th bit is not set. also, there seems to be a clear pattern in the frequency of the single byte telegrams as seen in the second file i uploaded. it would be interesting to compare the log i made with maybe your own system to see the differences.

does this make any sense? any ideas? ( i just started reading the ems-wiki to get some knowledge of the ems protocol.)

proddy commented 5 years ago

those logs helped. What's interesting is a few of these telegrams like

Received 1 Byte: 0x18
(00:05:28.075) Thermostat -> all, type 0x06 telegram: 98 00 06 00 13 04 12 1C 1F 23 06 01 18 FF 00 (CRC=04), #data=11
<--- RCTime(0x06) received
Received 1 Byte: 0x98

shows the Poll for the thermostat (type 0x18) doesn't have the MSB set, and also replies with 0x98. This is the opposite to how it's implemented now. You could try and remove the mod from (EMS_ID_ME | 0x80) and see if that helps

philrich commented 5 years ago

i will try this as soon as i am back in vienna (attending a conference in munich at the moment). i want to be physically there just in case something odd happens .. i'll report back no later than wednesday.

sadrov commented 5 years ago

Hi @philrich, I'm also using this with a junkers cerapur boiler and in the info I see more than what you see, on the other hand i can't get my thermostat to be recognized. And I also have the same Tx issue, I can't send commands. I wish I had the knowledge to contribute to this investigation but for now I can just follow and hope you'll get it working. Anyhow many thanks for all the contributors spending a lot of time on this and especially Proddy for the always quick replies!

philrich commented 5 years ago

@proddy, i tried your suggestions. first, i rebooted the thermostat with the 1-byte debug code in:

Received 1 Byte: 0x13
Received 1 Byte: 0x14
Received 1 Byte: 0x15
Received 1 Byte: 0x16
Received 1 Byte: 0x17
Received 1 Byte: 0x18
(00:00:30.341) Thermostat -> Boiler, type 0x07 telegram: 98 88 07 00 0E (CRC=67)
(00:00:30.373) Boiler -> Thermostat, type 0x07 telegram: 88 18 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=7C), #data=14
(00:00:30.400) Thermostat -> Boiler, type 0xEF telegram: 98 88 EF 00 01 (CRC=E3)
(00:00:30.420) Boiler -> Thermostat, type 0xEF telegram: 88 18 EF 00 (CRC=83)
(00:00:30.464) Thermostat -> Boiler, type 0x02 telegram: 98 88 02 00 0A (CRC=77)
<--- Version(0x02) received
(00:00:30.500) Boiler -> Thermostat, type 0x02 telegram: 88 18 02 00 5F 23 03 00 00 00 00 00 00 00 (CRC=D1), #data=10
<--- Version(0x02) received
Boiler found. Model Bosch Condens 2500/Junkers Cerapur Comfort (DeviceID:0x08 ProductID:95 Version:35.03)
* Setting Boiler to model Bosch Condens 2500/Junkers Cerapur Comfort (DeviceID:0x08 ProductID:95 Version:35.03)
Requesting type UBAMonitorFast(0x18) from dest 0x08
Requesting type UBAMonitorSlow(0x19) from dest 0x08
Requesting type UBAParameterWW(0x33) from dest 0x08
Requesting type UBAParametersMessage(0x16) from dest 0x08
Requesting type UBATotalUptimeMessage(0x14) from dest 0x08
Received 1 Byte: 0x98
Received 1 Byte: 0x18
Received 1 Byte: 0x98
(00:00:30.655) Boiler -> all, type 0x07 telegram: 88 00 07 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=6F), #data=15
Received 1 Byte: 0x20
Received 1 Byte: 0x28
Received 1 Byte: 0x18

at 00:00:30.341 the thermostat starts sending after receiving a "poll" request without MSB set. so it seems junkers boilers don't always set MSB to poll!?

following is a list of 1-byte telegrams which get received over and over again: 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x20 0x21 0x28 0x29 0x30 0x31 0x36 0x38 0x39 0x3E 0x3F 0x40 0x41 0x46 0x47 0x48 0x49 0x4E 0x4F 0x50 0x51 0x56 0x57 0x58 0x59 0x5E 0x5F 0x60 0x61 0x66 0x67 0x68 0x69 0x6E 0x6F

so i changed the code in ems.cpp as follows:

        // check first for a Poll for us
        //if (value == (EMS_ID_ME | 0x80)) {
        if ((value & 0x7F) == EMS_ID_ME) {
            myDebug("Received poll request for us: 0x%02X", value);

unfortunately it is not working. i see log messages about "Sending raw telegrams", sometimes followed by CRC errors:

Received poll request for us: 0x0B
(00:02:38.165) Sending read of type 0x16 to 0x08: telegram: 0B 88 16 00 20 EC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D5 69 02
00 68 ED FF 3F 0
(00:02:38.192) Corrupt telegram: telegram: 0B 88 16 00 (CRC=EC)
(00:02:38.531) Thermostat -> Boiler, type 0x35 telegram: 98 08 35 00 11 01 (CRC=B0)
Received poll request for us: 0x0B
(00:02:39.727) Sending read of type 0x14 to 0x08: telegram: 0B 88 14 00 20 E4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EF 6F 02
00 68 ED FF 3F 0
(00:02:39.753) Corrupt telegram: telegram: 0B 88 14 00 (CRC=E4)
Received poll request for us: 0x0B

i think the telegrams are much too long.

when i try to send 8B 88 02 00 0A i get

(00:28:54.225) Sending raw telegram: 8B 88 02 00 0A 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 76 1A 00 6
8 ED FF 3F 06 00 00 00 00 C2 FF 3F
(00:28:54.251) Corrupt telegram: telegram: 8B 88 02 00 (CRC=5E)

or

(00:29:01.002) Sending raw telegram: 8B 88 02 00 0A 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CA 90 1A 00 6
8 ED FF 3F 06 00 00 00 00 C2 FF 3F
(00:29:01.029) Corrupt telegram: telegram: 8B 88 02 00 (CRC=5E)

i tried with set tx_delay on and set tx_delay off

proddy commented 5 years ago

there was a bug in how the telegrams were printed in raw mode which I just fixed. But it shouldn't have changed the behavior but anyway please try again

philrich commented 5 years ago

hmm. that did not do the trick. log messages look fine now but i get no response to any command i send. with set tx_delay on i see corrupt telegrams like this:

Received poll request for us: 0x0B
(10:00:31.370) Sending read of type 0x16 to 0x08: telegram: 0B 88 16 00 20 (CRC=EC)
(10:00:31.385) Corrupt telegram: telegram: 0B 88 16 00 (CRC=EC)
Received poll request for us: 0x0B
(10:00:40.646) Sending read of type 0x14 to 0x08: telegram: 0B 88 14 00 20 (CRC=E4)
(10:00:40.661) Corrupt telegram: telegram: 0B 88 14 00 (CRC=E4)
Received poll request for us: 0x0B

so it looks like the last byte got lost. but i get no answer of the boiler. i even modified the startup command to include the telegrams the thermostat sends on boot, like this:

Sending startup sequence...
Received poll request for us: 0x0B
(10:10:53.987) Sending raw telegram: 0B 08 1D 00 00 (CRC=84)
Received poll request for us: 0x0B
(10:10:55.461) Sending raw telegram: 0B 88 01 00 1B (CRC=8B)
Received poll request for us: 0x0B
(10:10:56.960) Sending raw telegram: 0B 88 07 00 0E (CRC=86)
Received poll request for us: 0x0B
(10:10:58.484) Sending raw telegram: 0B 88 EF 00 01 (CRC=02)

(also tried with 0x8B as src). again, no response.

any other ideas?

i looked at all other junkers issues and as far as i can tell no one has gotten tx to work. i would really like to get this working as my original intention was to implement some kind of smart thermostat (maybe even with zigbee? controlled radiator thermostats).

(there exists a german company named tado. they sell a smart thermostat which is able to speak ems with junkers boilers but controlling the boiler is done in "the cloud" and i don't like this. i even thought about getting this, sniffing with ems-esp, and then return the thing, but okay, maybe we can solve the puzzle..)

proddy commented 5 years ago

if after every manually send it's missing the last byte then it could be something to do with the uart timing and how the BRK signal is sent. However a strange thing I see in your examples, like:

(10:00:31.385) Corrupt telegram: telegram: 0B 88 16 00 (CRC=EC)

is that the CRC byte is correct so it's sending through 0B 88 16 00 EC instead of 0B 88 16 00 20 EC

If you had a 7 EUR logical analyzer you could hook up to the Rx and Tx lines on the board and you'll find out exactly what is happening.

philrich commented 5 years ago

hmm. okay, will order a logic analyzer. do you have any recommendations or should i buy the first hit on amazon?

i get the corrupt telegrams only if i turn on tx_delay. with tx_delay turned off, no errors reported - and no response from busmaster either.

proddy commented 5 years ago

something cheap like I mentioned in https://github.com/proddy/EMS-ESP/issues/23#issuecomment-456983631

philrich commented 5 years ago

i ordered a cheap logic analyzer from amazon, 'cause aliexpress shipping times are too long for me. in the meantime i tried to change EMS_ID_ME to 0x18 (my Thermostat), just to check if i get then a response. But nada. So i will wait for the analyzer.

I also saw the other issue #104 with the link to the Heatronic implementation. very interesting! maybe there are some hints regarding timing? have to look at it when i get the time. if i can help anyhow this would be cool. I am austrian so if you have any questions regarding translation of german words, i should be able to help. some coding should be possible too (have written only python recently but used to write some c-code)

proddy commented 5 years ago

I don't think that other Heatronic project does sending of telegrams?

philrich commented 5 years ago

Here (https://www.mikrocontroller.net/topic/317004#3925213) the author talks about the different hardware. At least ht_piduino and ht_pitiny are able to send telegrams. On the software side ht_transceiver is meant to implement the sending part. This message is from 2014, in the meantime i think ht_transceiver.py is the replacement. In the directory /HT3/docu/HT3_Adaption.pdf you can find documentation for this (page 44ff).

FYI: this project identifies as 0x0d on the bus (Modem).

The logic analyzer arrived today so i hope i can provide some findings soon.

proddy commented 5 years ago

yes you're right. The circuit does have a Tx part and the code in his ht_proxy_if.py gives examples of how the data is sent. It looks its using 0x23 as the device ID and not 0x0B. Also quickly scanning his code I think this Heatronics uses a completely different schema to EMS+. I'd like to be abale to handle both the Bosch EMS2.0 and Heatronics formats based on which version. The tricky part if finding the right command to query the bus to determine if its Bosch or Junkers.

philrich commented 5 years ago

ok, here are the first logic analyzer captures.

this is with set tx_delay off:

Bildschirmfoto 2019-05-06 um 23 27 27

so no response.

following a capture with set tx_delay on (sorry for swapping rx/tx rows):

Bildschirmfoto 2019-05-07 um 00 56 39

which is interpreted like this:

Bildschirmfoto 2019-05-07 um 00 57 49

what is interesting:

just to try something out i set the tx delay to 2500 but that didn't change anything (corrupt telegrams, no answer).

proddy commented 5 years ago

Interesting, I’ll need to think why that last byte is not picked up but the CRC is correct. What you’re seeing on Rx is an echo of the Tx which is normal.

On Tue, 7 May 2019 at 01:11, philrich notifications@github.com wrote:

ok, here are the first logic analyzer captures.

this is with set tx_delay off: [image: Bildschirmfoto 2019-05-06 um 23 27 27] https://user-images.githubusercontent.com/17569738/57260351-76e05f80-7063-11e9-8136-9b43c4de24cc.png so no response.

following a capture with set tx_delay on (sorry for swapping rx/tx rows): [image: Bildschirmfoto 2019-05-07 um 00 56 39] https://user-images.githubusercontent.com/17569738/57260387-a42d0d80-7063-11e9-8e93-ceac32100f86.png which is interpreted like this: [image: Bildschirmfoto 2019-05-07 um 00 57 49] https://user-images.githubusercontent.com/17569738/57260416-c030af00-7063-11e9-9145-49355962b03c.png

what is interesting:

  • i see the last telegram byte (0x20) in RX capture but in debug output its missing. maybe some kind of timing issue?
  • see markers A/B: first response from busmaster is a bit slower. RX not finished when TX starts. could this be a problem?
  • at marker C: it says "Frame Error" but i don't know exactly what that means.

just to try something out i set the tx delay to 2500 but that didn't change anything (corrupt telegrams, no answer).

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/proddy/EMS-ESP/issues/103#issuecomment-489819946, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJMO6GNSKIWGJERJQYWCC3PUC3INANCNFSM4HIRMMMQ .

proddy commented 5 years ago

it looks like the send is sending an extra 0x00 before the break. After the crc checksum value D4 it should show the break immediately. We actually want frame-errors as the is 11-bits and longer than the 8N1 package. I checked the code and can't see how this can happen. Do you have tx_delay on?

philrich commented 5 years ago

yes, the second capture is done with set tx_delay on. the second capture in this comment -> https://github.com/proddy/EMS-ESP/issues/23#issuecomment-476872291 looks similar to mine.

moustic999 commented 5 years ago

yes you're right. The circuit does have a Tx part and the code in his ht_proxy_if.py gives examples of how the data is sent. It looks its using 0x23 as the device ID and not 0x0B. Also quickly scanning his code I think this Heatronics uses a completely different schema to EMS+. I'd like to be abale to handle both the Bosch EMS2.0 and Heatronics formats based on which version. The tricky part if finding the right command to query the bus to determine if its Bosch or Junkers.

I don't think it is needed to determine if it is Junkers of Bosch. Even if the the bus is the same, message exchanged between devices is different depending on brand. This is most probably a strategy to avoid mixing brand. You could connect Junkers on Buderus, these are EMS, but it will not work because message are not same.

emitter and receiver must know each others how to talk. it is hardcoded in them.

implementation wise, each Brand/device type will need specific processing. for each one, we must find what are message type and how the message is formatted.

philrich commented 5 years ago

@proddy, i did some research and i am happy to report that i now get an answer back from the heater and the thermostat:

(00:03:04.808) Sending read of type 0x18 to 0x08: telegram: 8B 88 18 00 20 (CRC=1C)
(00:03:04.879) Boiler -> me, type 0x18 telegram: 88 0B 18 00 00 00 F4 00 00 00 22 44 C0 00 E5 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 (CRC=20) #data=25
<--- UBAMonitorFast(0x18)
(00:03:04.996) Sending read of type 0x19 to 0x08: telegram: 8B 88 19 00 20 (CRC=18)
(00:03:05.062) Boiler -> me, type 0x19 telegram: 88 0B 19 00 80 00 80 00 00 E4 FF FF 00 00 00 45 8B 01 D1 A0 00 00 00 01 AA 23 00 2B 1B 80 00(CRC=EA) #data=27
<--- UBAMonitorSlow(0x19)
(00:03:05.183) Sending read of type 0x33 to 0x08: telegram: 8B 88 33 00 20 (CRC=B0)
(00:03:05.233) Boiler -> me, type 0x33 telegram: 88 0B 33 00 08 FF 37 00 00 00 00 02 46 00 FF FF (CRC=AB) #data=12
<--- UBAParameterWW(0x33)
(00:03:05.371) Sending read of type 0x16 to 0x08: telegram: 8B 88 16 00 20 (CRC=24)
(00:03:05.386) Corrupt telegram: telegram: 8B 88 16 00 (CRC=24)
(00:03:05.420) Boiler -> me, type 0x16 telegram: 88 0B 16 00 FF 42 64 00 00 FB 03 01 03 64 0A 02 (CRC=0E) #data=12
<--- UBAParametersMessage(0x16)
(00:03:05.527) Sending read of type 0x14 to 0x08: telegram: 8B 88 14 00 20 (CRC=2C)
(00:03:05.566) Boiler -> me, type 0x14 telegram: 88 0B 14 00 0C 2C 07 (CRC=76) #data=3

there are still corrupted telegrams, so not everything is well with timing i guess. but i hope we will get that fixed.

i used the logic analyzer to capture the traffic between the boiler and the thermostat to better understand the timing. every time the thermostat gets polled by the boiler it immediately responds with its own address (MSB set). this is also explained here: https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme (but not the part with the MSB). so i enabled the already present code to respond to the polls.

i also measured the length of the BRK-signal sent by the thermostat (or heater) (which is ~1040ms, as documented in src/emsuart.h) and the length of the BRK which is sent by the EMS-ESP (which, when tx_delay is on is ~2080ms). I don't understand why EMS_TX_BRK_WAIT is 2080, when it should wait 1040ms?! So i divided the delay in the brk-function by 2.

Also, when responding to the busmaster the source address of the thermostat always has the MSB set so i replicated this behaviour.

I attached a patch for this first working draft here: ems-junkers-patch.txt

@proddy where can i find documentation for the UART code (and macros used) in emsuart.cpp?

philrich commented 5 years ago

some more findings: as you already suspected here (https://github.com/proddy/EMS-ESP/issues/103#issuecomment-487408779), what is really needed for the boiler/thermostat to answer requests is the reversed poll logic. so polls without MSB, src in requests/answers with MSB.

if i disable EMS_Sys_Status.emsPollEnabled tx still works, but i get polled at a much slower rate (~1sec vs ~100ms) so i think it is important to respond to every poll request.

i even could remove the timing changes i made and it still works but i get corrupted telegrams (as in the comments above) when sending (but it works and i get a response). i think the timing is not yet right but i would need more knowledge in uart programming. maybe this is the reason why it didn't work with your boiler when you tried to use tx_delay. i don't know how strict timing on the serial bus is (very strict, i suspect).

maybe, if the timing would be correct tx_delay is not needed (becaus always on - it's also mentioned here as a fact: https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme, see the logic analyzer images).

then, maybe ems-esp can detect which poll logic has to be used depending on the poll requests it receives.

btw: i think bosch is the company producing some of the parts, junkers is using in its products, so i think it is not either/or but as well/as ..

if you like we can continue discussion in a chat (i have discord but am not yet familar with..)

FrankRenp commented 5 years ago

Just an idea, if not already considered. Im using Version 1.6 with Junkers ZSB 14-3 with FW120. Just listening to the Bus. I get lots of CRC errors with different UBS-Power-Supplies - and none at all if using a battery. (Took some research...)

proddy commented 5 years ago

@FrankRenp that's actually really interesting. BBQKees and myself ran a few tests last year exploring this. I'll look into it again with a scope.

FrankRenp commented 5 years ago

If found this, after having the problem: https://arduino-hannover.de/2018/07/25/die-tuecken-der-esp32-stromversorgung/ - German only. As remedy an additional capacitor was proposed - besides good power supply and usb-cable with low resistance.
Although it was related to wireless and crash issues, it solved the CRC problems for me as well.

However, next i need to apply the patch from philrich to check, if Tx works - currently (1.7b15) it doesn't even with the tx_delay on - but this seems to be clear after philrich's analysis.

proddy commented 5 years ago

Thanks for sharing. We've been experimenting with powering the circuit directly from the EMS bus (both the two-wires and service jack) and smoothing out the Tx signals for bbqkees' next board which will eliminate the need to use an external USB power supply.

philrich commented 5 years ago

@FrankRenp interesting, i will later try with different power supplies/cables/battery. unfortunately i dont't have an oscilloscope only a cheap logic analyzer. i will also post some more pictures of my logic analyzer captures maybe they are helpful.

FrankRenp commented 5 years ago

@philrich It was quite obvious for my - with battery no CRC-errors at all - with power-supply lots of. Quite easy to reproduce.

If you check it - and do not get any errors, I would check your patch, which sound understandble for me - or does the 1.7.0 version have a working Tx with your Junkers configuration?

philrich commented 5 years ago

@FrankRenp i tried with different timings and finally found values where i don't get any crc errors at all (with std power supply and crappy cable). I will do additional research as soon as i have some time (i hope in two days).

You will need to patch even with version 1.7 because the poll logic which i have seen on my junkers (and this correlates with all other junkers users here) is exactly reverse to the documented behaviour (poll with 0x0b, src package in telegrams is 0x8b, set tx_delay on needed).

FrankRenp commented 5 years ago

@philrich Thanks, I'm going to check at the weekend.

proddy commented 5 years ago

and I'll test the Poll on Buderus/Nefit boilers with the Poll having the MSB stripped so works with both 0x0B and 0x8B. I think the problem with the Tx on Junkers is that its always sending an extra 0x00 before the break/BRK/frame-error. I will need to see if this happens also on non-Junkers EMS lines and optimize the code to work with both.

moustic999 commented 5 years ago

if I can help taking trace or whatever on my EMS+ buderus RC300, feel free to ask ....

proddy commented 5 years ago

@moustic999 could you replace line 569 in ems.cpp to:

if ( (value & 0x7F) == EMS_ID_ME ) {

and see if you're still able to Tx without any retries or failures in the log

FrankRenp commented 5 years ago

@proddy Related to Version 1.7. In platform.ink platform = espressif8266@2.0.4 seems to be required, since with 2.1.0 as per today I get an exception (3).

I (manually) applied the proposed changes from @philrich and get now Tx on and answers from the boiler, but also some corrupted Telegramms shown below. Not all but some -seems to follow a systematic.

(00:06:02.209) Sending read of type 0x18 to 0x08: telegram: 8B 88 18 00 20 (CRC=1C) (00:06:02.273) Boiler -> me, type 0x18 telegram: 88 0B 18 00 31 01 B3 64 2D 09 03 25 C0 80 00 80 00 80 00 FF FF FF 00 00 00 00 00 02 18 (CRC=FC) #data=25 <--- UBAMonitorFast(0x18) (00:06:02.427) Sending read of type 0x19 to 0x08: telegram: 8B 88 19 00 20 (CRC=18) (00:06:02.493) Boiler -> me, type 0x19 telegram: 88 0B 19 00 00 85 80 00 80 00 FF FF 00 0A 02 03 3F 0F 90 64 00 00 00 0F 90 64 02 03 3F 80 00 (CRC=17) #data=27 <--- UBAMonitorSlow(0x19) (00:06:02.614) Sending read of type 0x33 to 0x08: telegram: 8B 88 33 00 20 (CRC=B0) (00:06:02.630) Corrupt telegram: telegram: 8B 88 33 00 (CRC=B0) (00:06:02.663) Boiler -> me, type 0x33 telegram: 88 0B 33 00 08 FF 0F 00 00 00 00 02 4B 00 FF FF (CRC=57) #data=12 <--- UBAParameterWW(0x33) (00:06:02.776) Sending read of type 0x16 to 0x08: telegram: 8B 88 16 00 20 (CRC=24) (00:06:02.791) Corrupt telegram: telegram: 8B 88 16 00 (CRC=24) (00:06:02.819) Boiler -> me, type 0x16 telegram: 88 0B 16 00 FF 33 64 00 00 F6 03 01 03 64 0A 05 (CRC=64) #data=12 <--- UBAParametersMessage(0x16) (00:06:02.926) Sending read of type 0x14 to 0x08: telegram: 8B 88 14 00 20 (CRC=2C) (00:06:02.965) Boiler -> me, type 0x14 telegram: 88 0B 14 00 34 E3 FC (CRC=EA) #data=3

proddy commented 5 years ago

@FrankRenp what exception errors did you get with espressif2.1.0 (https://github.com/esp8266/Arduino/releases/tag/2.5.1). It seems to compile and build fine, but I haven't run any stress tests yet.

FrankRenp commented 5 years ago

@proddy - It seems to be an upload problem... Compiling is fine if using platform = espressif8266 After upload and pressing ? in Telnet this happens,

[TELNET] Telnet server started ?

Exception (3): epc1=0x40226660 epc2=0x00000000 epc3=0x00000000 excvaddr=0x4025af49 depc=0x00000000

stack>>>

ctx: cont sp: 3ffffd60 end: 3fffffc0 offset: 01a0 3fffff00: 00000000 00000000 ffff50e4 4020fd8f 3fffff10: 3fffdad0 3fff3378 3fff3124 4020c8ef 3fffff20: 4020fb3f 3fff3424 3fff3378 0000001e 3fffff30: 00000000 3fff3378 3fff3378 4020cdd4 3fffff40: 00000000 00000000 3fff3378 3fff33fc 3fffff50: 0000003f 3fff3378 3fff3124 4020c225 3fffff60: 0000003f 3fff3648 3ffe8560 3fff35ec 3fffff70: 3fff3124 3fff173c 3fff3114 3fff35ec 3fffff80: 3fffdad0 3fff173c 3fff3124 4020c2b4 3fffff90: 3fffdad0 00000000 3fff173c 40205be4 3fffffa0: 3fffdad0 00000000 3fff35bc 4020e168 3fffffb0: feefeffe feefeffe 3ffe8560 401006f1 <<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d vac02aff5 ~ld EMS Tx delay is disabled [WIFI] MODE AP --------------------------------------

philrich commented 5 years ago

@proddy, i think i finally understood the timings (please correct me if i am wrong).

It is important to know that when TX FIFO is empty (after something got written to it) it doesn't mean that it was already sent out on the wire. This link https://forum.arduino.cc/index.php?topic=119044.0 (at post #13) contains more info on the matter.

The problem i see with set tx_delay on is that the Break sent out is much too long (~2040us) which results in getting interpreted by the Busmaster as a 0x00 followed by a BRK.

The code in emsuart.cpp works like this (pseudo code):

emsuart_tx_buffer:
  send Byte
  delay(2080)
  ...
  send Byte
  delay(2080)
emsuart_tx_brk:
  wait for tx fifo empty (returns immediately, last byte already finished on wire 1040us ago)
  start brk (send brk immediately because everything was sent already)
  delay(2080) // much too long -> should be 1040
  stop brk

with set tx_delay off pseudo code looks like this:

emsuart_tx_buffer:
  send Byte
  ...
  send Byte (fifo fills up)
emsuart_tx_brk:
  wait for tx fifo empty (returns when last byte to send is processed but not yet finished on wire)
  start brk (brk is sent after last byte is finished on wire which takes ~1040us)
  delay(2080) // works because time to send last byte + brk ~2080
  stop brk

I made a new patch which does the following:

Here ist the Patch: ems-delay-rev-poll.patch.txt

For me this patch works and i get close to none Corrupted Telegrams when i set EMS_TX_WAIT_GAP to 7 Bits (728us). (3, 4, 5, 6 Bits also works, when setting this to 10 or more Bits i get many Corrupted Telegrams)

Please have a look at it and tell me what you think. I also would like to know if this patch works with your Boiler when you set tx_delay on and experiment with different EMS_TX_WAIT_GAP values.

Here are two logic analyzer captures with patch applied:

With set tx_delay on:

Bildschirmfoto 2019-05-17 um 00 07 48

[A]->[B] = EMS_TX_WAIT_BYTE (= 10 Bit = 1040us) [B]->[C] = EMS_TX_WAIT_GAP (= 7 Bit = 7*104us = 728us) [D]->[E] = EMS_TX_WAIT_BRK (= 11 Bit = 1144us)

With set tx_delay off:

Bildschirmfoto 2019-05-17 um 00 13 51

@sadrov @moustic999 @FrankRenp can you please also try this patch and report how it works?

proddy commented 5 years ago

that's some good investigation @philrich , I'll take a look and compare results on my boiler tonight. I was also thinking about why you always get an extra 0x00 and perhaps the proper way is not to send the tx wait after the last byte has been sent but instead immediately follow with a BRK. So:

void ICACHE_FLASH_ATTR emsuart_tx_buffer(uint8_t * buf, uint8_t len) {
    for (uint8_t i = 0; i < len; i++) {
        USF(EMSUART_UART) = buf[i];

        if (EMS_Sys_Status.emsTxDelay) {
          delayMicroseconds(EMS_TX_BRK_WAIT);
        }
    }
    emsuart_tx_brk(); // send <BRK>
}

becomes

void ICACHE_FLASH_ATTR emsuart_tx_buffer(uint8_t * buf, uint8_t len) {
    for (uint8_t i = 0; i < len - 1; i++) {
        USF(EMSUART_UART) = buf[i];

        if (EMS_Sys_Status.emsTxDelay) {
          delayMicroseconds(EMS_TX_BRK_WAIT);
        }
    }
   USF(EMSUART_UART) = buf[i]; // send CRC and quick follow with a brk
    emsuart_tx_brk(); // send <BRK>
}
susisstrolch commented 5 years ago

I thought about a different Solution. If you send the telegram in a burst, the busmaster will echo a burst. But if you ‚re sending the bytes with a delay between the master will echo each single byte. So the idea is to send and snoop the rx-buffer. As soon as the echo arrives you can send the next one. So you also can safely use the local loop back when sending the break signal. Additional advantage: you can early detect and abort on bus collisions.

Sent by mobile device

Am 17.05.2019 um 14:38 schrieb Proddy notifications@github.com:

that's some good investigation @philrich , I'll take a look and compare results on my boiler tonight. I was also thinking about why you always get an extra 0x00 and perhaps the proper way is not to send the tx wait after the last byte has been sent but instead immediately follow with a BRK. So:

void ICACHE_FLASH_ATTR emsuart_tx_buffer(uint8_t * buf, uint8_t len) { for (uint8_t i = 0; i < len; i++) { USF(EMSUART_UART) = buf[i];

    if (EMS_Sys_Status.emsTxDelay) {
      delayMicroseconds(EMS_TX_BRK_WAIT);
    }
}
emsuart_tx_brk(); // send <BRK>

} becomes

void ICACHE_FLASH_ATTR emsuart_tx_buffer(uint8_t * buf, uint8_t len) { for (uint8_t i = 0; i < len - 1; i++) { USF(EMSUART_UART) = buf[i];

    if (EMS_Sys_Status.emsTxDelay) {
      delayMicroseconds(EMS_TX_BRK_WAIT);
    }
}

USF(EMSUART_UART) = buf[i]; // send CRC and quick follow with a brk emsuart_tx_brk(); // send } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

proddy commented 5 years ago

@susisstrolch I think that's the right approach Juergen. You can see that same behavior in this image where the Rx and Tx are nicely aligned in in phase. It'll require a big change in my code since I process Rx as complete telegrams. Need to think about how best to approach this

KristofRobberechts commented 5 years ago

I have a Junkers Cerapur with Bosch CR 100 thermostat as well. I received my bbqkees board last Friday and had the same TX issues. Out of the box with the v1.60 firmware it wasn't working. After reading this thread, I decided to apply the @philrich patch and I can confirm it's working now. I did have to set tx_delay=on. In retrospect, I realized I didn't try the v1.60 firmware with tx_delay=on, so that might have worked too.

susisstrolch commented 5 years ago

@proddy Ok, Plan B - non intrusive method: New emsuart_tx_buffer() Disable RX interrupt, clear FIFO, set loopback mode while chars to send send char wait for loopback response Endwhile Set TX-break Wait until break detected Disable loopback, clear FIFO, enable RX int

Now we should receive the complete package from busmaster.

FrankRenp commented 5 years ago

@philrich Thanks for that - I applied your patch as it is to Version 1.7.1 and it works very well - no CRC errors at all and the log looks sound. I've got most of the boiler information.

These are my next steps:

BTW, I tried different power supplies and cables - finally i found one working. However, the power supply failure did not result in CRC failures - but in bad wireless signal

proddy commented 5 years ago

@philrich @FrankRenp , susisstrolch made the change to the Tx logic and I've merged into the latest 1.8 dev. I haven't had time to test it myself yet. Use tx_delay 2 to enable and see if it works with your Junkers.