Ems-esp: Support for Junkers CerastarComfort ZWR and Junkers Bosch CR 100

[philrich]

Hello,

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

I own the following heating Components:

• Boiler: Junkers CerastarComfort ZWR 18-7 KE 23
• Thermostat: Junkers Bosch CR 100 (According to the manual this is an EMS+ Device)

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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

[philrich]

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]

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

[philrich]

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]

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]

ok, here are the first logic analyzer captures.

this is with set tx_delay off:

so no response.

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

which is interpreted like this:

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).

[proddy]

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 [e-mail] 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]

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]

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]

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]

@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]

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]

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]

@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]

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]

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]

@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]

@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]

@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]

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

[proddy]

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]

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

[proddy]

@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]

@proddy Related to Version 1.7. In platform.ink platform = [email protected] 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]

@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]

@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
?

• Connected to: EMS-ESP version 1.7.0
• Device is in AP mode with SSID ems-esp
  *
• Commands:
• ?=help, CTRL-D/quit=exit telnet session
• set, system, reboot

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
<<

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]

@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:

• after each Byte written always ensure TX FIFO is empty (not sure about this) and also waits the time needed to send the Byte out (1040us)
• introduce some new #defines, one of them called EMS_TX_WAIT_GAP which is the additional time to wait after a byte was sent if tx_delay is on.
• also introduce a new flag to reverse the poll logic if we receive a poll request with 0x0b instead of 0x8b, assuming that the bus master does not send both.

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:

[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:

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

[proddy]

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
}
```

[susisstrolch]

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 [e-mail]:

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]

@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

[RadViking]

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]

@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]

@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:

• Integrate into ioBroker via MQTT for logging only - to check, if the read values are correct
• Understanding the thermosstat information (FW120) in particular how-to set the heating curve/paratmeters
• Check how to select the boiler flow temperatur based on the heating curve

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]

@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.

[FrankRenp]

@proddy Compile and Wifi ok, but I've got no device detection and no messages back - even not with "autodetect deep".
See attached log.
1.8.0b_Log.txt

[proddy]

yup, I'm testing it now and its not working either. I'm looking at it....

[proddy]

@susisstrolch this is the result of sending 0B 88 01 00 20 to the EMS bus (via a boiler read 1 msg).
It looks like the loopback isn't working. An alternative is after Tx'ing a byte wait for the echo on the Rx. If it doesn't match or times out, cancel.

[susisstrolch]

Ok - it looks like the busmaster answers in Intervalls, Even we are sending a whole telegram.
So - as you say - sending a single char and waiting for the real echo.
Nevertheless I‘d keep the loopback method to send the final Break.

Sent by mobile device

Am 22.05.2019 um 18:55 schrieb Proddy [e-mail]:

@susisstrolch this is the result of sending 0B 88 01 00 20 to the EMS bus (via a boiler read 1 msg).
It looks like the loopback isn't working. An alternative is after Tx'ing a byte wait for the echo on the Rx. If it doesn't match or times out, cancel.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[susisstrolch]

@proddy I‘ll work at ‚take two‘ - got. an additional idea about non-intrusive implementation...

[susisstrolch]

@proddy Please cherry-pick the latest commit from my repo (fork) - it contains a reconditioned version...
commit 4579da6ee049af2ffe4dd5a5101f813d2a8d17d4 (HEAD -> smart-tx-TakeTwo)

[proddy]

ok, I'll manually merge and will ignore the PR

[proddy]

@susisstrolch couldn't get it to work - Tx causes ESP resets. I was thinking of a different approach

• clear Rx, disabled interrupts
• for each byte in the Tx telegram:
  
  
  
  • send a byte
  
  
  • wait until same value its echo'd on the Rx
  
  
  • if its not break, and fail Tx
  
  
• finally send BRK
• enable Rx interrupts

[susisstrolch]

@proddy same here - reboot after 2-5min...
Hmm, watchdog timeout while waiting on large telegram?

[proddy]

I made a mistake in my uart_stop() function. Forgot it was also used when saving to SPIFFS. fixed now.

[proddy]

ok, so looking much better now with "Take Two". 100% success on all Tx. Nice work! See picture:

only two issues to address
1) the long delay before sending BRK
2) clear the Rx buffer to avoid the echo coming back as Corrupted telegrams, like:

(00:27:57.851) Sending read of type 0x01 to 0x08: telegram: 0B 88 01 00 20 (CRC=B0)
(00:27:57.883) Corrupt telegram: 0B 88 01 00 20 B0 00
(00:27:57.938) Boiler -> me, type 0x01 telegram: 08 0B 01 00 38 37 33 37 39 30 39 31 30 41 30 31 31 32 34 38 30 32 35 30 00 FF FF FF FF FF FF (CRC=10) #data=27

[susisstrolch]

the long delay before sending BRK

it's simply because we have to wait until we received the last char
I've changed this loop a litte bit:
uint8_t waitcount = 100; // we abort after 100 trials... do { // wait until we received sizeof(telegram) or RxBRK (== collision detect) delay(1); // 1ms delay (approx. 1char time) if ((--waitcount==0) || (U0IS & (1 << UIBD))) break; } while (((USS(EMSUART_UART) >> USRXC) & 0xFF) < len);

clear the Rx buffer to avoid the echo coming back as Corrupted telegrams

the corrupted telegram is because of BRK. Not sure if to short or to long...
Because we're surely after the last Rx char we can try to send a much longer break - f.e. 24 bit-times.

[susisstrolch]

@proddy notification: edit of last message...

[proddy]

I've added a line to clear the FIFO after the Tx and that tidies up the Corrupted messages. I understand the wait except now it seems its random. I'll take a few example screenshots so you can see the behaviour. Still the EMS master seems to be able to manage the inconsistencies with the timing. It'll be interesting to see if this works on EMS+ (RC300) and Junkers.

[susisstrolch]

@proddy here's something wrong (emsuart.cpp, line 228):
while ((((USS(EMSUART_UART) >> USRXC) & 0xFF) < len) || (U0IS & (1 << UIBD)))
I think it should be
`while ((((USS(EMSUART_UART) >> USRXC) & 0xFF) < len) || !(USIS(EMSUART_UART) & (1 << UIBD)))

We also should clear the Rx status register when entering emsuart_tx_buffer().

emsuart.cpp is also a bit inconsistent about usage of Uxxx(EMSUART_UART) and Uxxx...

[proddy]

I'll try that too. And yes, its a bit of a mess, like U0IS for reading the interrupt on UART0 is the same as USIS(EMSUART_UART). We should fix that and make the code more readable.

[proddy]

@susisstrolch the while didn't work. I made a few other changes and will collect sample data so we can see what's happening.

[susisstrolch]

See PR #116 - works fine here...
Maybe we should add a additional setting - number of bits for BRK - instead of fixed value...
delayMicroseconds(34 * EMSUART_BIT_TIME);
So the Junkers users could test the optimum BRK length...

[proddy]

I manually merged your emsuart.cpp and it's not working for me. Not a single Tx is getting through. while your previous version (in my github dev branch) seems to work fine flawlessly. I'll need to check with the logic analyzer. Are you sure it works on your end?

[susisstrolch]

Jep - it runs since 2hr with log v.
Simple use the whole tx-Funktions

[susisstrolch]

I mean the whole emsuart.cpp. It‘s based on your latest commit.

[proddy]

cool. ok @philrich you have the infinity stones. Does the latest build work with Junkers?

[philrich]

I will test your patches as soon as I find some spare time (tomorrow I think)

Am 24.05.2019 um 17:42 schrieb Proddy [e-mail]:

cool. ok @philrich you have the infinity stones. Does the latest build work with Junkers?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[susisstrolch]

I manually merged your emsuart.cpp and it's not working for me. Not a single Tx is getting through. while your previous version (in my github dev branch) seems to work fine flawlessly. I'll need to check with the logic analyzer. Are you sure it works on your end?

Just checken again- It seems Tx doesnt‘t work - neither with tx_delay 2 nor tx_delay 1

[proddy]

works fine on mine each time using the latest dev build, with your code (tx_delay 2) log v and refresh get a 100% success rate with no errors. tx_delay if 0 (my old code) works too but with the occasional corrupted messages due to collisions. tx_delay 1 never worked but was added for EMS+.

Since version 1.6 I started capturing the time between polls from the master hoping this can be used to set the timing somehow. It's not used, but its there are shown info

[susisstrolch]

I‘ll check latest dev later.
Tx_delay=1 worked in the past with normal EMS

Sent by mobile device

Am 25.05.2019 um 10:49 schrieb Proddy [e-mail]:

works fine on mine each time using the latest dev build, with your code (tx_delay 2) log v and refresh get a 100% success rate with no errors. tx_delay if 0 (my old code) works too but with the occasional corrupted messages due to collisions. tx_delay 1 never worked but was added for EMS+.

Since version 1.6 I started capturing the time between polls from the master hoping this can be used to set the timing somehow. It's not used, but its there are shown info

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[RadViking]

I tried version 1.8.0b3 on my Junkers boiler, it didn't work. I can't connect to wifi anymore when the EMS bus is connected. As soon as I disconnect EMS, I can telnet to it again. Tried tx_delay 1 and 2, same result.

[philrich]

ok, did a very quick test with recent source: tx_delay 1 gives crc errors, tx_delay 2 results in a reboot loop.
apart from that: i did a very quick look at the source: what is really important for junkers users to get a response: the poll arrives without MSB but the response needs to set MSB on src. please see my last patch and search for emsReverse.
for sending i think (as @susisstrolch wrote) way to go should be to wait for the echo after each byte and then send the next. i tried to simulate this in my tests with a higher setting for EMS_TX_WAIT_GAP (the gap between two bytes) but if i set this too high it didn't work again. so i am not sure.

[proddy]

@philrich I've merged your code into the dev branch and made some small changes. tx_delay 3 will enable your logic. This way we can keep experimenting until we find a solution that works with both ems, ems+ and heatronics.

[susisstrolch]

Seems it‘s time to rename tx_delay to tx_mode... 😬

Sent by mobile device

Am 26.05.2019 um 12:26 schrieb Proddy [e-mail]:

@philrich I've merged your code into the dev branch and made some small changes. tx_delay 3 will enable your logic. This way we can keep experimenting until we find a solution that works with both ems, ems+ and heatronics.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[philrich]

Thanks @proddy this sounds like a good idea.

Am 26.05.2019 um 12:26 schrieb Proddy [e-mail]:

@philrich I've merged your code into the dev branch and made some small changes. tx_delay 3 will enable your logic. This way we can keep experimenting until we find a solution that works with both ems, ems+ and heatronics.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[proddy]

Yup. Was very tempted to change it but was worried I might confuse people.

On Sun, 26 May 2019 at 13:07, susisstrolch [e-mail] wrote:

Seems it‘s time to rename tx_delay to tx_mode... 😬

Sent by mobile device

Am 26.05.2019 um 12:26 schrieb Proddy [e-mail]:

@philrich I've merged your code into the dev branch and made some small
changes. tx_delay 3 will enable your logic. This way we can keep
experimenting until we find a solution that works with both ems, ems+ and
heatronics.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
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?email_source=notifications&email_token=AAJMO6HJVMNWAKJSRVNT7XDPXJVPRA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWIDKWI#issuecomment-495990105,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6BC56RZVQ2YDHGV45DPXJVPRANCNFSM4HIRMMMQ
.

[susisstrolch]

Finally I fixed the tx_mode=2. Only caveat: we get a trailing phantom 0 in Rx-FIFO when receiving the telegram echo from busmaster. This is because we create the BRK in loopback mode.

[susisstrolch]

see #119

[susisstrolch]

Also fixed the phantom break problem - see #119

EMS Bus stats:
  Bus is connected
  Rx: # successful read requests=42, # CRC errors=0
  Tx: Last poll=1.263 seconds ago, Tx mode=0, # successful write requests=2

Seems info (tx_mode) needs a fix...

[proddy]

PR #119 works great. Also fixed the typo in Tx_mode

[RadViking]

I tried version 1.8.0b7, but tx_mode 2 or 3 don't work on Junkers, queue is filling up. At least it's not hanging the esp anymore.

When I applied the @philrich patch on 1.7.1 it works.

[proddy]

oh that sucks. btw tx_mode 3 should be the same as philrich's original code. I guess he needs to look into it.

[philrich]

will look into it as soon as i am at home.

[philrich]

see this small patch (as already sayed: MSB ist not set on poll by my junkers): ems-junkers-1.8.0b7.patch.txt
with this patch, latest 1.8.0b7 dev version works for me. 👍
my original idea was to set emsReverse automatically if we see a poll without MSB, but i don't know if maybe some boilers poll with both types .. research would be needed for this.
i will also look into tx_mode 2

[RadViking]

The patch works for me too, using tx_mode 3

[philrich]

just tested with tx_mode 2. i had to enable emsReverse for this mode with this change in ems.cpp at line 346:

-    if (mode == 3) {
+    if (mode > 1) {

after this it works fine! see logic analyzer capture

i'll let this run until tomorrow and see how many crc errors i get. good work!

[proddy]

see this small patch (as already sayed: MSB ist not set on poll by my junkers): ems-junkers-1.8.0b7.patch.txt
with this patch, latest 1.8.0b7 dev version works for me. 👍
my original idea was to set emsReverse automatically if we see a poll without MSB, but i don't know if maybe some boilers poll with both types .. research would be needed for this.
i will also look into tx_mode 2

@philrich thanks for checking. On my EMS the bus master sends out both 0x0B and 0x8B (with MSB set) so I couldn't use your trick to set the emsReverse. I think perhaps the best way is to set emsReverse if a Junkers heatronic is detected upon startup when it queries the versions - at the moment there is a single productID of 95 (ems_devices.h). But perhaps someone can think of a better idea? Ideally, I'd like to have one tx_mode that works for everyone and not have more set parameters for every different combination of bus protocols.

[kwertie01]

This morning I did a couple of tests with the DEV version 1.8.0b8
Products used:

• Boiler: Sieger BK15 Boiler/Nefit Smartline (ProductID:64 Version:03.02)
• Thermostat: RC30/Nefit Moduline 400 (ProductID:78 Version:02.20)

tx_mode 0:
This is not working in my environment. My boiler needs to echo back every transmitted byte and that takes time, This is why I started to add the delay in the first place See: #23
Anyway here the output:

tx_mode 1 (delay 2070):
Using this mode, transmitting worked but not always. I receive quite a few errors and some transmitted messages are not received (and answered back).

The delay of 2070 is just too short in my case. The next byte is already transmitted before the echo back from the boiler has been completely received see picture:

This is why the echo back bytes differ from the transmitted bytes. It looks like that everything is shifted one bit?

tx_mode 1 (delay 2320):
I did some testing with different delay values. This time I increased the delay quite a bit to 2320.
Although the echoed bytes are fine now, there is a problem with the break. Because the EMSUART_TX_BRK_WAIT value is used for the delay between the transmitted bytes, it is also used to define the length of the transmitted break. With this delay value the break is way too long. The transmitted break is longer than the echoed break. (if it is shorter than the echoed break it will work fine)
When this happens, an extra 0xFF is echoed back.

tx_mode 1 (delay 2120):
After some experimenting (I'm not sure how the value is related to the timing I see with my analyzer) I came to the value of 2120, which worked fine in my environment. This value is long enough to make sure that all bytes are transmitted after the echo back has completely been received and the break command is not too long. Still I think it is better to split the timing of those two values!

tx_mode 2:
Using this mode I receive almost no errors anymore! timing looks perfect! (the only errors I receive are real errors where there is some noise on the line)

tx_mode 3:
This mode is not working in my environment because I don't have a Junkers boiler. I tried it anyway but no transmits are working at all (also because the MSB in are revert and that is not working in my situation)

One problem (small bug) I noticed is that when you change the tx_mode to 3, the emsReverse flag is set. When you change back to an other tx_mode, for instance tx_mode 2 than the flag is not reset but is still true. I think it is solved with just an extra else….

void ems_setTxMode(uint8_t mode) {
    EMS_Sys_Status.emsTxMode = mode;

    // special case for Junkers. If tx_mode is 3 then set the reverse poll flag
    // https://github.com/proddy/EMS-ESP/issues/103#issuecomment-495945850
    if (mode == 3) {
        EMS_Sys_Status.emsReverse = true;
        myDebug_P(PSTR("Forcing emsReverse"));
    }
    else
    {
        EMS_Sys_Status.emsReverse = false;
    }
}

So far my tests. I'm very happy with tx_mode 2 :-)

[proddy]

@kwertie01 thanks for testing. I've modified the code with your suggestions.

[m1588]

I can confirm that my HT3 bosch condens 2500 TX works perfect with ems-junkers-1.8.0b7.patch.txt and tx_mode=3.
Great job, guys, thats really appreciated.

[proddy]

@m1588 could you also try with set tx_mode 2. This is the latest greatest code by susisstrolch and should work for ems, ems+ and heatronics.

[m1588]

tx_mode 2 does not work for me (I have upgraded to latest 1.8.0b9), no messages are sent and the queue is filling.

[proddy]

@m1588 that's a shame, I thought we nailed it. Do you happen to have a logic analyzer? Strange that the HT3 between philrich's Junkers CerastarComfort would differ from your Bosch 2500.

[m1588]

@proddy I have ordered analyzer from aliexpress, should come within a month.
My boiler has reversed logic and tx_mode 3 works only with patch

(if (value == ((EMS_Sys_Status.emsReverse) ? EMS_ID_ME : EMS_ID_ME | 0x80)))
I also think that mode 2 and mode 3 different in terms of reverse logic, I believe thats the reason that the only working mode is 3.

[philrich]

@m1588 i think you have to change the function ems_setTxMode as explained below (see https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496288145). if you have a junkers (or maybe other HT3 boilers) then the poll logic is reversed (in my testings)

just tested with tx_mode 2. i had to enable emsReverse for this mode with this change in ems.cpp at line 346:

-    if (mode == 3) {
+    if (mode > 1) {

after this it works fine! see logic analyzer capture

[m1588]

@philrich correct, with reverse logic enabled mode2 works now, thanks!

[philrich]

@philrich thanks for checking. On my EMS the bus master sends out both 0x0B and 0x8B (with MSB set) so I couldn't use your trick to set the emsReverse. I think perhaps the best way is to set emsReverse if a Junkers heatronic is detected upon startup when it queries the versions - at the moment there is a single productID of 95 (ems_devices.h). But perhaps someone can think of a better idea? Ideally, I'd like to have one tx_mode that works for everyone and not have more set parameters for every different combination of bus protocols.

i think we have a checken-egg-problem here. on my junkers a got no response from the busmaster until i changed the poll logic to be reversed. so querying the version does not work.

maybe it would be a good idea to make detection like this:

• on startup snoop all poll values for 1 or more cycles
• if 0x8B is found: emsReverse = False
• if 0x0Bis found but not 0x8B: set emsReverse = True

what do you think?

[susisstrolch]

@proddy can you have a look at emsuart.cpp, emsuart_tx_brk(), line 185?

    if (EMS_Sys_Status.emsTxMode <= 2) {
        delayMicroseconds(EMSUART_TX_BRK_WAIT); // classic mode
    } else if (EMS_Sys_Status.emsTxMode == 3) {
        delayMicroseconds(EMSUART_TX_WAIT_BRK - EMSUART_TX_LAG); // 1144 (11 Bits)
}

IMHO the delay in emsTxMode3 is a bit critical. According what I know about BRK, a short BRK should be > 11bit and < 2char times. Long BRK are longer than 2char and can go up to 50ms...
Also, if (EMS_Sys_Status.emsTxMode <= 2) should be if (EMS_Sys_Status.emsTxMode < 2)...

[proddy]

Yes its too long. I didn’t write that piece and it worked for others with
HT3 so I left it in. However good news is that txmode 2 seems to work for
everyone now so eventually I’ll remove txmode and use your new logic

On Wed, 29 May 2019 at 08:33, susisstrolch [e-mail] wrote:

@proddy https://github.com/proddy can you have a look at emsuart.cpp,
emsuart_tx_brk(), line 185?

if (EMS_Sys_Status.emsTxMode <= 2) {
    delayMicroseconds(EMSUART_TX_BRK_WAIT); // classic mode
} else if (EMS_Sys_Status.emsTxMode == 3) {
    delayMicroseconds(EMSUART_TX_WAIT_BRK - EMSUART_TX_LAG); // 1144 (11 Bits)

}

IMHO the delay in emsTxMode3 is a bit critical. According what I know
about BRK, a short BRK should be > 11bit and < 2char times. Long BRK are
longer than 2char and can go up to 50ms...

—
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?email_source=notifications&email_token=AAJMO6A4N66A4X6REDHNOGTPXYPUPA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWOKDXQ#issuecomment-496804318,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6BN23KAMX5UTLLHQTTPXYPUPANCNFSM4HIRMMMQ
.

[proddy]

The idea in the latest build was to automatically set the reverse flag when
it detects a Junkers. For some reason that didn’t work with your boiler
device. I’m away for a week so can’t check but look at code changes I
submitted yesterday.

On Wed, 29 May 2019 at 08:27, m1588 [e-mail] wrote:

@philrich https://github.com/philrich correct, with reverse logic
enabled mode2 works now, thanks!

—
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?email_source=notifications&email_token=AAJMO6H2BDJKLBI6B5LINBDPXYO3VA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWOJXAI#issuecomment-496802689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6DY2HHYFGA7YGQGZYDPXYO3VANCNFSM4HIRMMMQ
.

[moustic999]

Hi all, I finally got time to test on my system
reminder : buderus GB162 (with MC10/BC10, EMS ) and Thermostat RC300, EMS+
I tried all tx_mode 0->3
in mode 0, tx does not work
all others mode seems to work the same and tx works as well. I did only tried send Version request to the boiler and to the thermostat
So, works for me : 1,2,3

[FrankRenp]

1.8.0b9 does not work with my Junkers (with tx_mode=3), philrichs patch (https://github.com/proddy/EMS-ESP/issues/103#issuecomment-493368592) still works.

[philrich]

1.8.0b9 does not work with my Junkers (with tx_mode=3), philrichs patch (#103 (comment)) still works.

@FrankRenp can you try with tx_mode 2 and the modification from here: https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496801123. then it should work.

@proddy i checked your latest commit. i will try to get your detectJunkers function to work.

[FrankRenp]

@philrich: Did so - but tx: no signal. (for both tx_mode 2 and tx_mode 3)

:EMS Bus stats:
: Bus is connected
: Rx: # successful read requests=0, # CRC errors=1
: Tx: no signal

With Version 1.7.1 and your patch (https://github.com/proddy/EMS-ESP/issues/103#issuecomment-493368592) it looks like this:
:EMS Bus stats:
: Bus is connected
: Rx: Poll=32 ms, # Rx telegrams read=10, # CRC errors=0
: Tx: available, Tx delay is on, # Tx telegrams sent=0

[philrich]

@FrankRenp do you have this patch applied? -> https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496285679. look at src/ems.cpp around line 709. it should look like

        if (value == ((EMS_Sys_Status.emsReverse) ? EMS_ID_ME : EMS_ID_ME | 0x80)) {

this is needed, otherwise reverse poll logic does not work.
also you need to modify ems_setTxMode as in https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496288145 for tx_mode 2 to work.

for me this works very good:

EMS Bus stats:
  Bus is connected
  Rx: # successful read requests=29216, # CRC errors=3
  Tx: Last poll=1.218 seconds ago, Tx mode=2, # successful write requests=0

 [APP] EMS-ESP version: 1.8.0b7
 [APP] MyESP version: 1.1.12
 [APP] Build timestamp: 2019-05-27 19:16:27
 [APP] Boot time: start
 [APP] Uptime: 3 days, 21 hours, 9 minutes, 39 seconds

[RadViking]

@philrich Tried it with tx_mode 2 and reverse logic, it's working on my Junkers.

* Connected to: EMS-ESP version 1.8.0b9

EMS Bus stats:
Bus is connected
Rx: # successful read requests=44, # CRC errors=0
Tx: Last poll=1.466 seconds ago, Tx mode=2, # successful write requests=0

It seems like the reverse logic is the golden ticket. I'll leave it running for a while and see what happens.

[FrankRenp]

@philrich : Thanks, that was it. Running fine with the two patches in src/ems.cpp

[FrankRenp]

@philrich - too early too happy - connection to bus is getting lost after 2 - 4 hours.
With 1.7.1 there were no connection losts.

[philrich]

@FrankRenp what do you mean with "connection lost"? i think there where more changes to the code apart from the uart. which tx_mode did you use? if 2, can you try with 3 (or vice versa)?

[philrich]

The idea in the latest build was to automatically set the reverse flag when it detects a Junkers. For some reason that didn’t work with your boiler device. I’m away for a week so can’t check but look at code changes I submitted yesterday.

@proddy i fixed a bug in ems_detectJunkers, please see this patch: ems-junkers-detect.patch.txt. tx works for me with this patch (emsReverse gets set).
I'm not sure if this would work for everyone as you said your boiler polls with 0x0B and 0x8B. so the change in line 700 of ems.cpp maybe is problematic but needed for emsReverse detection.
What if other boilers also have this reverse logic? Wouldn't it be better to implement a generic logic as in https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496803357 ?

[proddy]

I’ll try this out next week when I’m back. The logic seems correct as Buderus boilers send out polls on both 0b and 8b. I was thinking of adding a flag in ems_devices.h next to a boiler or thermostat if it’s needs the reverse logic. Then during startup force a version check like we do now on both normal and switched logic

[FrankRenp]

@philrich
"Connection loss" -> Bus is not connected, no messages, LED flashing
I tried tx_mode 2 before - now I tried with tx_mode 3.

tx_mode 3 runs partly, but ends working after some time (between 15min and some hours). And in deviation to your patch to 1.7.1 it does not recognize the thermostat.

Number of Patches - as far as I understood:

• no change in emsuart.cpp is neccessary anymore, since proddy has implemented the change in Version 1.8.0.9b. (https://github.com/proddy/EMS-ESP/issues/103#issuecomment-495987093)
• this patch https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496285679
• this patch https://github.com/proddy/EMS-ESP/issues/103#issuecomment-496801123

Anymore?

[philrich]

@philrich
"Connection loss" -> Bus is not connected, no messages, LED flashing
I tried tx_mode 2 before - now I tried with tx_mode 3.

@proddy i had the same happening to me two times (latest version). hmm, it seems there was some bug introduced which causes the bus to disconnect after some time. how could i debug this?

[proddy]

I've just experienced this now myself, after 10 minutes it resets. Strange thing is that there is no crash data so its not a hard WDT reset. Useful commands are system and look for the Uptime to see how long the ESP has been running and another command is crash dump which will show the stack dump which can be copied into a file and analyzed to find at which function/line in the code it bombed.

I have a suspicion that it crashes when log v is left on which is more likely due to an out-of-mem error somewhere. There's a lot of conversions and printing going on and the code there is a little messy

[FrankRenp]

@philrich, @proddy I did not observe that problem with the patched Version 1.7.1 - yesterday I had an uptime some days. So for me it seems, that the bug has been introduced later.

[proddy]

@FrankRenp yes, I'm getting resets every 15mins with 1.8.x dev and 1.7.1 master is stable, both using the same esp core libraries so I expect its somewhere in the code. I'll do further investigation this week to find what is causing the resets

[FrankRenp]

@proddy - I noticed yesterday, that I also get the connections losses after 1-2 days with the 1.7.1 version...

[proddy]

@FrankRenp I've traced the software resets on 1.8.x dev to the 'phantonbrk' logic that's used when in 'tx_mode 2'. Working on a fix. I also added the restart info and root cause to the system command so if it does reset after 1-2 days we'll be able to find out. Note the ems bus will disconnect and reconnect if the ESP reboots but also if the wifi signal is interrupted, so it may be misleading.

[FrankRenp]

@proddy Thanks - very helpful. Since I have a weak wifi link I should rectify this first. Is there an automatic reconnect without a reboot in case of a wifi connection lost?

[proddy]

yes, it does an automatic request and picks up from where it last left off.

On Tue, Jun 11, 2019 at 11:18 AM FrankRenp [e-mail] wrote:

@proddy https://github.com/proddy Thanks - very helpful. Since I have a
weak wifi link I should rectify this first. Is there an automatic reconnect
without a reboot in case of a wifi connection lost?

—
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?email_source=notifications&email_token=AAJMO6AIRB3YFDYPXADC2TDPZ5UWFA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXMPYZY#issuecomment-500759655,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6BECYN377H6DR7ZFO3PZ5UWFANCNFSM4HIRMMMQ
.

[proddy]

@proddy Thanks - very helpful. Since I have a weak wifi link I should rectify this first. Is there an automatic reconnect without a reboot in case of a wifi connection lost?

Think I fixed the restarts - latest build 1.8.0b14

[FrankRenp]

@proddy tx_mode 2 seems to work. Get nearly immediate restarts with tx_mode 3.
With tx_mode 2 my thermostat is found and tx works.
EMS-ESP system stats:
System logging set to None
LED is on, Listen mode is off
Thermostat is enabled, Boiler is enabled, Shower Timer is disabled, Shower Alert is disabled

EMS Bus stats:
Bus is connected
Rx: # successful read requests=40, # CRC errors=0
Tx: Last poll=0.124 seconds ago, Tx mode=2, # successful write requests=6

Tx_mode 3:
[CRASH] Last crash was 0 days 0 hours 0 minutes 4 seconds since boot time
[CRASH] Reason of restart: 2 - Fatal exception
[CRASH] Exception cause: 28
[CRASH] epc1=0x40227694 epc2=0x00000000 epc3=0x00000000
[CRASH] excvaddr=0x00000000 depc=0x00000000
[CRASH] sp=0x3fffff30 end=0x3fffffc0

stack>>>
3fffff30: 00000020 3fff3c10 0000000d 40217fe2
3fffff40: 00000020 3fff3c10 3fff3bfc 3fff3c80
3fffff50: 0000000d 3fff3bfc 3fff39a8 4020ce61
3fffff60: 0000000d 3fff3eec 3ffe9720 3fff3e90
3fffff70: 3fff39a8 00000000 3fff399d 3fff3e90
3fffff80: 3fffdad0 3fff1fbc 3fff39a8 4020cf34
3fffff90: 3fffdad0 00000000 3fff1fbc 40205ce0
3fffffa0: 3fffdad0 00000000 3fff3e60 4020ef2c
3fffffb0: feefeffe feefeffe 3ffe9720 401006f1
<<

[proddy]

Oh poop.

On Wed, 12 Jun 2019 at 19:26, FrankRenp [e-mail] wrote:

@proddy https://github.com/proddy Get nearly immediate restarts with
tx_mode 2 and tx_mode 3

[CRASH] Last crash was 0 days 0 hours 0 minutes 4 seconds since boot time
[CRASH] Reason of restart: 2 - Fatal exception
[CRASH] Exception cause: 28
[CRASH] epc1=0x40227694 epc2=0x00000000 epc3=0x00000000
[CRASH] excvaddr=0x00000000 depc=0x00000000
[CRASH] sp=0x3fffff30 end=0x3fffffc0

stack>>>
3fffff30: 00000020 3fff3c10 0000000d 40217fe2
3fffff40: 00000020 3fff3c10 3fff3bfc 3fff3c80
3fffff50: 0000000d 3fff3bfc 3fff39a8 4020ce61
3fffff60: 0000000d 3fff3eec 3ffe9720 3fff3e90
3fffff70: 3fff39a8 00000000 3fff399d 3fff3e90
3fffff80: 3fffdad0 3fff1fbc 3fff39a8 4020cf34
3fffff90: 3fffdad0 00000000 3fff1fbc 40205ce0
3fffffa0: 3fffdad0 00000000 3fff3e60 4020ef2c
3fffffb0: feefeffe feefeffe 3ffe9720 401006f1
<<

—
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?email_source=notifications&email_token=AAJMO6GNQKGCY52JSDSK54DP2EWU7A5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXRGG5Q#issuecomment-501375862,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6HLOPED7KH77HMXTGDP2EWU7ANCNFSM4HIRMMMQ
.

[FrankRenp]

@proddy Please note, that tx_mode 2 seems to works well so far - Obviously I've updated the commend after you read it, sorry.

[susisstrolch]

@FrankRenp could you analyse the crash dump to see where it bailed out?
I see a similiar behaviour with Master, replacing the tx with a plain txmode 2.
will try a modified EMSlink hardware, cause I‘m Not shure if I have a power supply problem.

[FrankRenp]

@susisstrolch I could - if you tell me, what I need to do. I added the crash dump for tx_mode 3 in https://github.com/proddy/EMS-ESP/issues/103#issuecomment-501375862. For tx_mode 2 I don't have any crashdump.

[susisstrolch]

@proddy with latest I get

(00:06:34.785) Sending read of type 0x14 to 0x08: telegram: 0B 88 14 00 20 (CRC=E4)
(00:06:35.004) Corrupt telegram: 86 F3 1F F8 89

for each and any send telegram...

[proddy]

@susisstrolch that;'s unusual. I only moved the brkphanton logic to the emsRx function to detect double BRKs. The Tx should work as before.

[susisstrolch]

Pretty strange - I'll try to nail down the problem.
That's an excerpt of an autodetect:

Started scan on EMS bus for known devices
Requesting type Version(0x02) from dest 0x02
Requesting type Version(0x02) from dest 0x08
Requesting type Version(0x02) from dest 0x09
Requesting type Version(0x02) from dest 0x10
Requesting type Version(0x02) from dest 0x11
Requesting type Version(0x02) from dest 0x17
Requesting type Version(0x02) from dest 0x18
Requesting type Version(0x02) from dest 0x20
Requesting type Version(0x02) from dest 0x21
Requesting type Version(0x02) from dest 0x30
Requesting type Version(0x02) from dest 0x38
Requesting type Version(0x02) from dest 0x48
(00:24:33.170) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:34.056) Sending read of type 0x02 to 0x02: telegram: 0B 82 02 00 20 (CRC=EC)
(00:24:34.275) Corrupt telegram: 52 DB FF E0 90
(00:24:35.168) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:35.959) Sending read of type 0x02 to 0x08: telegram: 0B 88 02 00 20 (CRC=BC)
(00:24:36.178) Corrupt telegram: 42 FB DF F0 90
(00:24:37.067) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:37.828) Thermostat -> all, type 0x06 telegram: 10 00 06 00 13 06 16 0C 32 10 02 01 (CRC=B6) #data=8
<--- RCTime(0x06)
(00:24:38.093) Thermostat -> all, type 0xA3 telegram: 10 00 A3 00 11 00 00 01 04 01 0A 01 0A 83 00 83 00 (CRC=80) #data=13
<--- RCOutdoorTempMessage(0xA3)
(00:24:38.457) Sending read of type 0x02 to 0x09: telegram: 0B 89 02 00 20 (CRC=B4)
(00:24:38.676) Corrupt telegram: 96 D3 1B FA 90
(00:24:39.564) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:40.350) Sending read of type 0x02 to 0x10: telegram: 0B 90 02 00 20 (CRC=7C)
(00:24:41.375) Boiler -> all, type 0x18 telegram: 08 00 18 00 0B 00 C7 64 00 00 00 00 00 83 00 7D 00 80 00 00 00 FF 30 48 00 00 FF 00 00 83 00 (CRC=1C) #data=27
<--- UBAMonitorFast(0x18)
(00:24:41.655) Boiler -> all, type 0x18 telegram: 08 00 18 1B 00 00 00 00 00 00 00 0B 00 00 (CRC=FF) #data=10
<--- UBAMonitorFast(0x18)
(00:24:42.062) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:42.858) Sending read of type 0x02 to 0x11: telegram: 0B 91 02 00 20 (CRC=74)
(00:24:43.077) Corrupt telegram: E1 3D F5 2A 90
(00:24:43.960) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:44.746) Sending read of type 0x02 to 0x17: telegram: 0B 97 02 00 20 (CRC=44)
(00:24:44.965) Corrupt telegram: 0B FF F2 9B 1D F9 90
(00:24:45.858) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:46.683) Thermostat -> Boiler, type 0x34 telegram: 10 88 34 00 10 (CRC=FD) #data=1
(00:24:46.757) Boiler -> Thermostat, type 0x34 telegram: 08 10 34 00 00 83 00 7D 00 00 00 00 03 00 00 00 00 00 00 00 (CRC=AC) #data=16
(00:24:46.859) Sending read of type 0x02 to 0x18: telegram: 0B 98 02 00 20 (CRC=3C)
(00:24:47.956) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:48.747) Sending read of type 0x02 to 0x20: telegram: 0B A0 02 00 20 (CRC=E5)
(00:24:48.966) Corrupt telegram: 42 FB 1F F8 90
(00:24:49.854) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:50.645) Sending read of type 0x02 to 0x21: telegram: 0B A1 02 00 20 (CRC=ED)
(00:24:51.190) Thermostat -> Boiler, type 0x1A telegram: 10 08 1A 00 00 00 00 00 (CRC=91) #data=4
(00:24:51.314) Sending read of type 0x02 to 0x30: telegram: 0B B0 02 00 20 (CRC=65)
(00:24:51.658) Corrupt telegram: 82 FB 17 FC 64 00 00 00 00 00 83 00 7D 00 80 00 00 00 FF 30 48 00 00 FF 00 00 83 00 1C
(00:24:51.945) Boiler -> all, type 0x18 telegram: 08 00 18 1B 00 00 00 00 00 00 00 0B 00 00 (CRC=FF) #data=10
<--- UBAMonitorFast(0x18)
(00:24:52.248) Sending read of type 0x02 to 0x38: telegram: 0B B8 02 00 20 (CRC=25)
(00:24:52.467) Corrupt telegram: 96 D3 1B FA 89
(00:24:53.450) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:53.822) Sending read of type 0x02 to 0x48: telegram: 0B C8 02 00 20 (CRC=8E)
(00:24:54.041) Corrupt telegram: 96 D3 03 FF 90
(00:24:54.949) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=43) #data=15
(00:24:55.735) Sending raw: 8B 88 02 00 20 00
(00:25:01.356) Boiler -> all, type 0x18 telegram: 08 00 18 00 0B 00 C7 64 00 00 00 00 00 83 00 7D 00 80 00 00 00 FF 30 48 00 00 FF 00 00 83 00 (CRC=1C) #data=27
<--- UBAMonitorFast(0x18)
(00:25:01.636) Boiler -> all, type 0x18 telegram: 08 00 18 1B 00 00 00 00 00 00 00 0B 00 00 (CRC=FF) #data=10
<--- UBAMonitorFast(0x18)
(00:25:11.346) Boiler -> all, type 0x18 telegram: 08 00 18 00 0B 00 C7 64 00 00 00 00 00 83 00 7D 00 80 00 00 00 FF 30 48 00 00 FF 00 00 83 00 (CRC=1C) #data=27

As you can see the received data doesn't correlate in any way to the send telegram.
It looks like a completely disturbed Rx package...

[susisstrolch]

Argh... Silly me - I had txmode set to 0 from previous tests...

[proddy]

ah good. I'm planning to remove the tx_mode and use the '2' logic for everything, once it has been confirmed to work for Junkers and EMS+

[FrankRenp]

@proddy Version 1.8.014b seems to be running stable with tx_mode 2 with my Junkers.
(there seems to a misleading time indication - I assume, the correct interpretation of Uptime is
more than 2 days - exactly 56 hour, but only 56 hour

[APP] EMS-ESP version: 1.8.0b14
[APP] MyESP version: 1.1.14
[APP] Build timestamp: 2019-06-12 18:57:16
[APP] Boot time: start
[APP] Uptime: 2 days 56 hours 3 minutes 47 seconds
[APP] System Load: 1%
[...]
EMS Bus stats:
Bus is connected
Rx: # successful read requests=17805, # CRC errors=0
Tx: Last poll=0.150 seconds ago, Tx mode=2, # successful write requests=2

Boiler stats:
Boiler: Bosch Condens 2500/Junkers Heatronics3 (ProductID:95 Version:18.08)
[...]

Thermostat stats:
Thermostat: Junkers FW120 (ProductID:192 Version:53.02)
Setpoint room temperature: 90.0 C
Current room temperature: 22.5 C
Thermostat time is 10:03:29 15/6/2019
Mode is set to ?

[proddy]

thanks @FrankRenp . Uptime bug just fixed. I also noticed you like it hot (setpoint 90 degrees?) :-) Is that possibly another bug in the Junkers/FW120 code?

[FrankRenp]

@proddy Seems so - I don't have the thermostate installed in a sauna ;-). After having the communication stable, I'll check the messages and the results. I think, I need some reengineering. (The thermostat state is also unknown.)

Later on, I'd like to control the boiler - at least the flow-temperatur. Currenty, It can be set - boiler flowtemp works - , but a short time later, it is reset by the thermostat.

For that, there are some hints to use a modem adress (0d, hex) for the EMS, but I didn't research enought by now. (There is a similar project (in German) for a raspberry - https://www.mikrocontroller.net/topic/317004?goto=new#3935809)

[proddy]

I'm aware of the hometop_HT3 project. We all looked into it a while back and its close to EMS ESP design but tailored mainly for heatronics. I'm not sure what you mean by the modem address or how that can help block the thermostat for sending on flow-temp changes though?

[FrankRenp]

I need to understand the HT3 project - for me it seems, that they may have solved that problem. But currently I'm busy and will probably not get into that within the next 2-3 weeks.

[proddy]

@FrankRenp @philrich we have a new version 1.9 that's in dev and has some modified Tx code. Could you do us a favour and check if it works ok with Junkers? Note that all youir settings will be lost when going from 1.8.x to 1.9. Do check the ChangeLog for instructions on how build the firmware and its new web interface. Appreciate any help you can provide, thanks in advance..!

[sadrov]

sounds cool.
I will test it as soon as I come home but that won't be for another three
weeks so I can't be of any assitance for now
Thanks a lot though for all the work!!!

On Tue, Aug 20, 2019 at 11:29 PM Paul [e-mail] wrote:

@FrankRenp https://github.com/FrankRenp @philrich
https://github.com/philrich we have a new version 1.9 that's in dev and
has some modified Tx code. Could you do us a favour and check if it works
ok with Junkers? Note that all youir settings will be lost when going from
1.8.x to 1.9. Do check the ChangeLog for instructions on how build the
firmware and its new web interface. Appreciate any help you can provide,
thanks in advance..!

—
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?email_source=notifications&email_token=AKVERENHOROT5JPIYFF6NC3QFRO3RA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XW67Q#issuecomment-523202430,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKVEREPRKQARIR46MTPP45LQFRO3RANCNFSM4HIRMMMQ
.

[FrankRenp]

Will take some 2-3 weeks, but I will check.

[philrich]

Hi,

I'm on vacation too so it might take a while but i'm looking forward to test the new version ..

Am 20.08.2019 um 23:29 schrieb Paul [e-mail]:

@FrankRenp https://github.com/FrankRenp @philrich https://github.com/philrich we have a new version 1.9 that's in dev and has some modified Tx code. Could you do us a favour and check if it works ok with Junkers? Note that all youir settings will be lost when going from 1.8.x to 1.9. Do check the ChangeLog for instructions on how build the firmware and its new web interface. Appreciate any help you can provide, thanks in advance..!

[FrankRenp]

ESPAsyncUDP seems to be missing in platformio.ini

[proddy]

@FrankRenp the platformio.ini is up to the user to create, using the sample platformio-example.ini. It's not part of the repository.

[FrankRenp]

Sorry, should have read the update building instructions, forgot that from the previous version. Did it, got some other problems.

Gulp install:
-> npm WARN [email protected] No repository field.

gulp -> Syntaxfehler in Zeile 7

D:frank22_Projekte013_HeizungEMS-GitEMS-ESPtoolswebfilesbuilder>node .node_modulesgulpbingulp.js
internal/modules/cjs/loader.js:638
throw err;
^

Error: Cannot find module 'strip-ansi'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (D:frank22_Projekte013_HeizungEMS-GitEMS-ESPtoolswebfilesbuildernode_moduleschalkindex.js:4:17)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)

[proddy]

you need an older version of npm. See https://github.com/proddy/EMS-ESP/issues/178

[FrankRenp]

Thanks, got it compiled, but I was not able to save the settings via the web-interface (after entering, saving an reboot it was still in AP-Mode).

After configuring with -DFORCE_SERIAL I was able to configure via telnet/serial and connect to wifi. The related settings in the web-interface are still wrong.
(And set serial off is forgotten after restart).

[proddy]

set serial will always be overridden by -DFORCE_SERIAL. It's by design and only to be used in extreme panic situations. Re-compile with the -D setting and upload again.

When going to 1.9.0 all your previous settings will be lost (as explained in the wiki and changelog).

[FrankRenp]

Got that already. However, the problem is, that the wifi settings work (got a telnet connection via wifi) , but the settings are not show in the web front end (ap mode shown there).

[proddy]

This looks like the websockets is not working. do you see anything in the
Dashboard or System Status screens? I've seen this problem with iOS 12.4.x
too. Make sure there is only a single web connection open. Also let me know
what you're using to view the web. If I can reproduce here I can fix.
thanks for reporting back

On Fri, Sep 6, 2019 at 11:12 PM FrankRenp [e-mail] wrote:

Got that already. However, the problem is, that the wifi settings work
(got a telnet connection via wifi) , but the settings are not show in the
web front end (ap mode shown there).

—
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?email_source=notifications&email_token=AAJMO6GTMDNKBI6QE3QZIDDQILBT5A5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ECK4Q#issuecomment-529016178,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6HDLIMBHZ7LAI2ZBM3QILBT5ANCNFSM4HIRMMMQ
.

[FrankRenp]

If I change the settings in the web front end, they cannot be seen in telnet (what I understand that they are not saved).
-> Is set e.g. the mqtt configuration in the web front end, click the save button, than click the review and save button, see the "please review your system changes", press save&restart, then see the progress bar. After finishing changes are not visible in telnet.
Have open a single web connection (firefox, 64bit, 69.0, Windows 10) and a putty session (0.70) at the same time.
Dashboard/System Status is empty/No reaction on click

[proddy]

I'll try and reproduce. Is this on 1.9.0 or the dev 1.9.1 ?

[FrankRenp]

ESP8266 System stats:

[APP] EMS-ESP version: 1.9.0
[APP] MyESP version: 1.2.0
[APP] Build timestamp: 2019-09-06 23:04:36

[proddy]

from the web, after you've saved the settings using the web interface, do you see a log entry in the web that says 'config saved' ?

[FrankRenp]

No, log is empty. Same behavior with chrome (instead Firefox) - and also without a parallel telnet session. Seems that also the restart does not work. At least I cannot obverse any change at all after "Save&Restart". And the current settings are not shown by the web frontend, e.g. the ssid.

[FrankRenp]

To exclude a problem during compile on my side: I've got the warning below, may that be related?

Executing task: C:UsersFrank.platformiopenvScriptsplatformio.exe run <

DEPRECATED! A legacy library storage d:\frank\22_Projekte\013_Heizung\EMS-Git\EMS-ESP\.piolibdeps has been found in a project.
Please declare project dependencies in platformio.ini file using lib_deps option and remove d:\frank\22_Projekte\013_Heizung\EMS-Git\EMS-ESP\.p iolibdeps folder.
More details -> http://docs.platformio.org/page/projectconf/section_env_library.html#lib-deps
Processing debug (board: d1_mini; framework: arduino; platform: espressif8266)
...

[proddy]

not sure its related. I would remove the .piolibsdeps as its no longer supported in PlatformIO version 4. Everything is now installed in a .pio folder. Just to rule out any environment issues did you also try using the pre-built firmware from the GitHub releases page? Can't remember if you had...

[FrankRenp]

Tried the pre-built firmware 10min ago - same behavior.
Removal of .piolibdeps done - also no change.
Same behavoir with 1.91b

Remark: During my current tests, there is no ems-bus connection.

[proddy]

When you go to the web do you see the dashboard page or is it empty?

[FrankRenp]

Problem solved - I did not login. (need to RTFM more exactly - sorry for that) - A respective message ("without login no data"... or similar might be helpful to avoid that".
...
Dashbord is empty.
First, I get the menu on the right side and the login windows (Please log in). After closing the login windows (without any password entered since none is set), I can access to the menu.

[proddy]

ah, good spot. I'll modify the web code to prevent people closing the login window

[FrankRenp]

Checked with Version 1.9.1b1 with Junkers:
[APP] EMS-ESP version: 1.9.1b1
[APP] MyESP version: 1.2.0
[APP] Build timestamp: 2019-09-07 11:16:46

Tx not working - neither with tx_mode 1, 2 or 3. Rx ok, got some CRC errors with tx_mode 1, 2, but not with 3.

Info
EMS-ESP system stats:
System logging set to None
LED is on, Listen mode is off
Boiler is disabled, Thermostat is disabled, Solar Module is disabled, Shower Timer is disabled, Shower Alert is disabled

EMS Bus stats:
Bus is connected
Rx: # successful read requests=0, # CRC errors=0
Tx: no signal

Boiler stats:
Boiler:
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: ? C
Warm Water current tap water flow: ? l/min
Warm Water # starts: ? times
Warm Water 3-way valve: off
Selected flow temperature: 43 C
Current flow temperature: 43.0 C
...

[proddy]

damn. And it worked fine with 1.8.x and tx_mode 3 ?

[FrankRenp]

No, but it worked with tx_mode 2 with 1.8.014b - a later one I did not test.
(see https://github.com/proddy/EMS-ESP/issues/103#issuecomment-502345197)

Do you want me to try another version?

[rskallies]

Unfortunately I'm experiencing the same issue now. TX is not working since 1.9 for my Boiler Junkers Cerapur ZSB 14-5c worked fine since 1.8.014b with tx_mode=2

EMS Bus stats:
Bus is connected
Rx: # successful read requests=0, # CRC errors=15
Tx: no signal

Tested with both the prebuilt 1.9 firmware and with latest 1.9.1b4 from dev branch. Tried all tx_mode settings tx_mode=1 and =2 showing CRC read errors while tx_mode=3 shows no CRC errors but also Tx: no signal

[proddy]

damn. There's definitely a pattern here! Can you try with the 1.8.3 firmware (let me know if you take the pre-compiled .bin or build yourself). This will help me pinpoint the root cause.

[rskallies]

Using prebuilt 1.8.3 firmware everything is fine with tx_mode=2 (see attached log summary for other modes results)
1.8.3.txt

Using latest prebuilt 1.9.0 and also self build 1.9.1b4 TX is not working.

[proddy]

Great. Could you pull the txmode2 branch (https://github.com/proddy/EMS-ESP/tree/txmode2) and compile that? This has the revised code for tx_mode 2 which also ended up in 1.9.0 and 1.9.1.

Make sure the platformio.ini files are up to date too.

Sorry for all the extra work but it'll really help isolate what is causing the problem. There have been various reports of similar issues.

Copying in @susisstrolch

[rskallies]

Great. Could you pull the txmode2 branch (https://github.com/proddy/EMS-ESP/tree/txmode2)
and compile that? This has the revised code for tx_mode 2 which also ended up in 1.9.0 and 1.9.1.

TX is not working using this code.

Make sure the platformio.ini files are up to date too.

I had to add general_flags = -DPIO_FRAMEWORK_ARDUINO_LWIP2_LOW_MEMORY_LOW_FLASH
to platformio.ini because of very low free memory on the heap, I always set this flag when TX is not working because my ESP (from bbqkees kit) had always stability problems because of low memory when TX is not working and using this macro seems to help.

Sorry for all the extra work but it'll really help isolate what is causing the problem. There have been various reports of similar issues.

You are welcome, let me know if you need more help here.

[FrankRenp]

I also tested with the precompiled 1.8.3 and tx works with both tx_mode 2 and tx_mode 3. But with tx_mode 2 there are some more CRC-Errors than with tx_mode 3.

I will not be able to compile or apply any patches, since currently I'm at war with git...

[proddy]

@FrankRenp thanks for checking. When you say works with 1.8.3 but not in 1.9.x do you mean you see crashes with 1.9.x or just that no Tx is working?

[FrankRenp]

No crashes. Tx is not working and no boilder data is shown in the dashboard.

[proddy]

could you try if the latest 1.9.1 fixes the crashes?

[FrankRenp]

Yes, but it will be not within the next 2 weeks.

[Neonox31]

Hello,

Here is my configuration :

• Boiler: Bosch Condens 2500/Junkers Heatronics3 (ProductID:95 Version:10.11)
• Thermostat: Junkers FW120 (ProductID:192 Version:53.02)

All was fine with the 1.9.0 firmware built by myself from commit https://github.com/proddy/EMS-ESP/commit/2a2a50b but today I tried to use the pre-build EMS-ESP-1_9_1b8.bin firmware and I have the following state for tx in all modes (1, 2 and 3) :

EMS Bus stats:
  Bus is connected
  Rx: # successful read requests=0, # CRC errors=2
  Tx: no signal

My boiler is detected but only after I restart it while the gateway is up but my thermostat is never detected 😢 even if I use the autodetect deep command.

@proddy I am available for testing purpose if you want.

[proddy]

Thanks for checking. What is shown at the end of a ‘devices’ command? Is it
detecting any devices ?

On Sun, 29 Sep 2019 at 16:39, WEBER Logan [e-mail] wrote:

Hello,

Here is my configuration :

• Boiler: Bosch Condens 2500/Junkers Heatronics3 (ProductID:95
  Version:10.11)
• Thermostat: Junkers FW120 (ProductID:192 Version:53.02)

All was fine with the 1.9.0 firmware built by myself from commit 2a2a50b
https://github.com/proddy/EMS-ESP/commit/2a2a50b but today I tried to
use the pre-build EMS-ESP-1_9_1b8.bin firmware and I have the following
state for tx in all modes (1, 2 and 3) :

EMS Bus stats:

Bus is connected

Rx: # successful read requests=0, # CRC errors=2

Tx: no signal

My boiler is detected but only after I restart it while the gateway is up
but my thermostat is never detected 😢 even if I use the autodetect deep
command.

@proddy https://github.com/proddy I am available for testing purpose if
you want.

—
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?email_source=notifications&email_token=AAJMO6AXDGR3LYMEU2O7XULQMC43LA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73WR7A#issuecomment-536307964,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6F2KJ544EUYPU6SGK3QMC43LANCNFSM4HIRMMMQ
.

[Neonox31]

Here is the footer of devices command output :

These device IDs are on the EMS Bus:
No devices recognized. This could be because Tx is disabled or failing.

set command output :

Current settings:

  wifi_mode=client
  wifi_ssid=***
  wifi_password=***
  mqtt_enabled=off
  mqtt_ip=
  mqtt_username=
  mqtt_password=
  mqtt_base=home
  mqtt_port=1883
  mqtt_heartbeat=off
  serial=off
  ntp_enabled=off
  led=on
  led_gpio=2
  dallas_gpio=14
  dallas_parasite=off
  tx_mode=3
  listen_mode=off
  shower_timer=off
  shower_alert=off
  publish_time=120

[proddy]

ok, there are others with a similar issue. I must have broken something between 1.9.0 and 1.9.1 and I don't know what! Things to try

• what was the tx_mode you used in 1.9.0 when it worked?
• what does autodetect quick do using the latest 1.9.1 dev branch?
• does info tell you that Tx is not working at the top ?

[Neonox31]

• what was the tx_mode you used in 1.9.0 when it worked?
  tx_mode 3
• what does autodetect quick do using the latest 1.9.1 dev branch?
  autodetect quick command prints nothing
• does info tell you that Tx is not working at the top ?
  Unfortunately, the 1.9.1b10 has the same behavior :

EMS Bus stats:
  Bus is connected
  Rx: # successful read requests=0, # CRC errors=0
  Tx: no signal

[proddy]

Think I know what may be the problem. Can you turn on verbose logging and look for any telegrams with type 0x07 and post them here? In the meantime I'll do a quick change

[Neonox31]

Here are some telegrams with 0x07 type :

(07:54:43.353) 0x08 -> all, type 0x07, telegram: 88 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=ED) #data=15
(07:55:43.308) 0x08 -> all, type 0x07, telegram: 88 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=ED) #data=15

Hope this is enough for you, I have to left at work.

[proddy]

Great. Thanks. The fix I did last night should work.

On Thu, 3 Oct 2019 at 06:49, WEBER Logan [e-mail] wrote:

Here are some telegrams with 0x07 type :

(07:54:43.353) 0x08 -> all, type 0x07, telegram: 88 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=ED) #data=15
(07:55:43.308) 0x08 -> all, type 0x07, telegram: 88 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=ED) #data=15

Hope this is enough for you, I have to left at work.

—
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?email_source=notifications&email_token=AAJMO6GKK4LQDNL5UZPOKGDQMV2VVA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAG7FLA#issuecomment-537785004,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6DCMTC2OX7ZPMUMBYTQMV2VVANCNFSM4HIRMMMQ
.

[Neonox31]

Thanks for the fix :+1:
My boiler is detected again :

Boiler stats:
  Boiler: Bosch Condens 2500/Junkers Heatronic 3 (ProductID:95 Version:10.11)

But the tx signal is not back, is that a normal behavior ?

EMS Bus stats:
  Bus is connected, protocol: Junkers HT3
  Rx: # successful read requests=0, # CRC errors=0
  Tx: no signal

device command outputs the following :

These device IDs are on the EMS Bus: 0x08 0x09 0x10
No devices recognized. This could be because Tx is disabled or failing.

And the biggest problem is that my FW120 thermostat is not detected 😩
Is there a flag anywhere to enable thermostat ?

[proddy]

We need to find out why the Tx is failing. Could you

log v
autodetect quick

and capture the logs into a file and attach it.

[Neonox31]

Here is the autodetect quick log :
autodetect-quick-junkers-201910031915.log

[proddy]

from the logs, I see none of the telegram messages are being sent, which is strange because it worked in 1.9.0 also with the same tx_mode setting of 3. Is that correct?

The command send 8B 08 02 00 20 should work. It just asks the boiler to return the version information. In the latest 1.9.1 dev build can you try this with verbose logging and see if it returns any corrupted messages?

If not I need to take a close look at what's changed with 1.9.0 and double-check with other Junker users to see if they experience the same problem.

[m1588]

I have the same behaviour as Neonox31 with by HT3 bosch 2500 with the 1.9.1b11 build.
tx_mode=3

Tx: no signal
These device IDs are on the EMS Bus: 0x08 0x09 0x18
No devices recognized. This could be because Tx is disabled or failing.

Sending above command seems to not have an effect:

send 8B 08 02 00 20

(00:01:58.234) Sending raw: 8B 08 02 00 20 (CRC=10)
(00:02:02.855) 0x18 -> 0x08, type 0x23, telegram: 98 08 23 00 26 FF 00 (CRC=39) #data=3
(00:02:05.393) 0x08 -> all, type 0x18, telegram: 88 00 18 00 21 01 4A 46 23 09 23 25 C0 80 00 80 00 80 00 FF FF FF 00 00 00 00 00 02 18 (CRC=4D) #data=25
<--- UBAMonitorFast(0x18)
(00:02:05.633) 0x08 -> all, type 0x34, telegram: 88 00 34 00 2F 01 E4 01 E4 A1 00 00 03 00 00 53 F2 00 08 8C 00 (CRC=48) #data=17
<--- UBAMonitorWWMessage(0x34)

[proddy]

same issue as https://github.com/proddy/EMS-ESP/issues/98 - 1.9.1 is not detecting Junkers correctly.

[Neonox31]

I think I found the problem, the autodetect sends 8B 10 02 00 20 frame instead 8B 90 02 00 20 for the 0x10 device id. Pay attention to the second byte which is the telegram dest I think.

If I use the send 8B 90 02 00 20 command, the thermostat replies to the service key :

(00:04:16.136) Sending raw: 8B 90 02 00 20 (CRC=B4)
(00:04:16.192) 0x10 -> me, type 0x02, telegram: 90 0B 02 00 C0 35 02 00 00 00 00 00 00 00 (CRC=F8) #data=10
<--- Version(0x02)
EMS Device recognized as Thermostat: Junkers FW120 (DeviceID:0x10 ProductID:192 Version:53.02)

I have to check the code to understand why.

[proddy]

Exactly! That was what I was thinking too but hadn’t had time to look at the code. With the latest build does ‘autodetect’ show anything?

[Neonox31]

With 1.9.1b11 same behavior is observed :

(00:00:14.154) Sending read of type 0x02 to 0x10, telegram: 8B 10 02 00 20 (CRC=D0)

Here is the log of autodetect command : autodetect-201910041905.log

[proddy]

for Junkers, when sending a read request the Source has the MSB (8th bit set) and the destination has also the 8th bit set since its a read command. So to find out details of the boiler you would send 8B 88 02 00 20 . Does this work with you?

[proddy]

also @Neonox31 I forgot to ask. When you do info does it show the protocol as Junkers?

[Neonox31]

Yes it works :

(01:05:09.321) Sending raw: 8B 88 02 00 20 (CRC=74)
(01:05:09.368) 0x08 -> me, type 0x02, telegram: 88 0B 02 00 5F 0A 0B 00 00 00 00 00 00 00 (CRC=B5) #data=10
<--- Version(0x02)
EMS Device recognized as Boiler: Bosch Condens 2500/Junkers Heatronic 3 (DeviceID:0x08 ProductID:95 Version:10.11)

And the protocol is correct :

EMS Bus stats:
  Bus is connected, protocol: Junkers HT3
  Rx: # successful read requests=0, # CRC errors=0
  Tx: no signal

Here is the detailled log : autodetect_20191004_201157.log

[proddy]

ok then, so autodetect doesn't work. if so I think I know where the problem is

[Vuego123]

Same issue here: a Junkers installation that worked fine for 2-3 months on v1.8.X. Since my upgrade to 1.9.1b11, I'm having the same issue. My components: FW100 thermostat, ISM1 solar module and heatronic boiler.

EMS-ESP system stats:
System logging set to None
LED is on, Listen mode is off
Boiler is disabled, Thermostat is disabled, Solar Module is disabled, Shower Timer is disabled, Shower Alert is disabled

EMS Bus stats:
Bus is connected, protocol: Junkers HT3
Rx: # successful read requests=0, # CRC errors=0
Tx: no signal

Let me know if I can help debugging / testing.

[proddy]

what does send 8B 88 02 00 20 show with logging on?

[Vuego123]

Connected to: EMS-ESP version 1.9.1b11

send 8B 88 02 00 20

(01:31:51.477) Sending raw: 8B 88 02 00 20 (CRC=74) #data=1
(01:31:51.518) 0x08 -> me, type 0x02, telegram: 88 0B 02 00 5F 17 00 00 00 00 00 00 00 00 (CRC=74) #data=10
<--- Version(0x02)
EMS Device recognized as Boiler: Bosch Condens 2500/Junkers Heatronic 3 (DeviceID:0x08 ProductID:95 Version:23.00)
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
(01:31:52.717) SM -> all, type 0x0003, telegram: B0 00 FF 00 00 03 0B 0B 01 49 01 38 00 EB 01 00 00 F2 D8 (CRC=91) #data=13
<--- ISM1StatusMessage(0x03)
(01:31:53.372) Sending read of type 0x18 to 0x08, telegram: 8B 08 18 00 20 (CRC=78)
(01:31:53.434) Sending read of type 0x19 to 0x08, telegram: 8B 08 19 00 20 (CRC=7C)
(01:31:53.518) Boiler -> all, type 0x07, telegram: 88 00 07 00 0B 01 00 00 00 01 00 00 00 00 00 00 00 00 00 (CRC=6F) #data=15
<--- UBADevices(0x07)
(01:31:53.870) Sending read of type 0x33 to 0x08, telegram: 8B 08 33 00 20 (CRC=D4)
(01:31:53.938) Boiler -> all, type 0x33, telegram: 88 00 33 02 32 (CRC=B2) #data=1
<--- UBAParameterWW(0x33)
(01:31:54.306) Sending read of type 0x16 to 0x08, telegram: 8B 08 16 00 20 (CRC=40)
(01:31:54.418) Boiler -> all, type 0x16, telegram: 88 00 16 00 FF 2B 64 00 00 F6 03 01 03 64 0A 04 (CRC=F2) #data=12
<--- UBAParametersMessage(0x16)
(01:31:54.651) Boiler -> all, type 0x18, telegram: 88 00 18 00 23 01 7E 64 00 01 03 00 C0 80 00 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 (CRC=A8) #data=25
<--- UBAMonitorFast(0x18)
(01:31:54.873) Boiler -> all, type 0x34, telegram: 88 00 34 08 00 (CRC=88) #data=1
<--- UBAMonitorWWMessage(0x34)
(01:31:55.179) Sending read of type 0x14 to 0x08, telegram: 8B 08 14 00 20 (CRC=48)
(01:31:55.854) Boiler -> all, type 0x07, telegram: 88 00 07 00 03 01 00 00 00 01 00 00 00 00 00 00 00 00 00 (CRC=DF) #data=15
<--- UBADevices(0x07)

[Vuego123]

So it detected the Junkers heatronic boiler, but it still says TX: no signal. No other devices were detected (Thermostat and Solar Module).

[proddy]

Fixed now in b12

On Sat, 5 Oct 2019 at 12:21, Vuego123 [e-mail] wrote:

So it detected the Junkers heatronic boiler, but it still says TX: no
signal. No other devices were detected (Thermostat and Solar Module).

—
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?email_source=notifications&email_token=AAJMO6GAWOLUOJIK5U75323QNBTBFA5CNFSM4HIRMMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANPIHY#issuecomment-538637343,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJMO6HY7JXBWJHMNREHJ6LQNBTBFANCNFSM4HIRMMMQ
.

[proddy]

closing, if there are bugs please re-open or create a new issue.

[Vuego123]

I deployed 1.9.2b1 but the issue is not resolved. I don't see any difference.

[rskallies]

Running self compiled 1.9.2b1 and finally TX is working again with tx_mode 3 the first time after 1.8.3. All devices are detected fine.

EMS Bus stats:
Bus is connected, protocol: Junkers HT3
Rx: # successful read requests=18, # CRC errors=0
Tx: Last poll=2.600 seconds ago, # successful write requests=0

Boiler stats:
Boiler: Buderus GBx72/Nefit Trendline/Junkers Cerapur (ProductID:123 Version:06.03)

Thermostat: Bosch EasyControl CT200 (ProductID:203 Version:02.06)
Heating Circuit 1

@proddy Thank you for fixing this!

[proddy]

phew! that was a hard bug to find. thanks for being patient.

[Vuego123]

My bad, config issue. It is working here as well. Thank you for the bugfix!

[fwPunsher]

Sorry If I maybe missed ome obvious documentation. But I am confused whether the CW 100 is supported now. And if it is, are all operations possible? Especially setting the temperature?