Support for Junkers CerastarComfort ZWR and Junkers Bosch CR 100 #103
Comments
|
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 Could you try 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. |
|
hi, thanks for the quick response. 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. 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? |
|
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 |
|
Unfortunately no response from the Busmaster after I have also tried all 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)' |
|
ok, so the boot sequence from the thermostat is this i tried to simulate this with but it didnt work |
|
so what i don't get: if we need to get polled by the busmaster before we can send something, the above 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. |
|
that's correct. Its waiting for the Poll which is single byte of |
|
i made this: 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 i also made a short count of values with this command ( 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. does this make any sense? any ideas? |
|
those logs helped. What's interesting is a few of these telegrams like 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 |
|
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. |
|
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. |
|
@proddy, i tried your suggestions. 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: so i changed the code in ems.cpp as follows: unfortunately it is not working. i see log messages about "Sending raw telegrams", sometimes followed by CRC errors: i think the telegrams are much too long. when i try to or i tried with |
|
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 |
|
hmm. that did not do the trick. so it looks like the last byte got lost. (also tried with 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..) |
|
if after every manually
is that the CRC byte is correct so it's sending through 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. |
|
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. |
|
something cheap like I mentioned in #23 (comment) |
|
i ordered a cheap logic analyzer from amazon, 'cause aliexpress shipping times are too long for me. 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. |
|
I don't think that other Heatronic project does sending of telegrams? |
|
Here (https://www.mikrocontroller.net/topic/317004#3925213) the author talks about the different hardware. At least FYI: this project identifies as The logic analyzer arrived today so i hope i can provide some findings soon. |
|
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. |
|
ok, here are the first logic analyzer captures. this is with following a capture with what is interesting:
just to try something out i set the tx delay to 2500 but that didn't change anything (corrupt telegrams, no answer). |
|
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 ***@***.***> 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
<#103 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAJMO6GNSKIWGJERJQYWCC3PUC3INANCNFSM4HIRMMMQ>
.
|
|
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? |
|
yes, the second capture is done with |
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. 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. |
|
We need to find out why the Tx is failing. Could you and capture the logs into a file and attach it. |
|
Here is the |
|
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 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. |
|
I have the same behaviour as Neonox31 with by HT3 bosch 2500 with the 1.9.1b11 build.
Sending above command seems to not have an effect: |
|
same issue as #98 - 1.9.1 is not detecting Junkers correctly. |
|
I think I found the problem, the If I use the I have to check the code to understand why. |
|
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? |
|
With Here is the log of |
|
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 |
|
also @Neonox31 I forgot to ask. When you do |
|
Yes it works : And the protocol is correct : Here is the detailled log : autodetect_20191004_201157.log |
|
ok then, so autodetect doesn't work. if so I think I know where the problem is |
|
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: EMS Bus stats: Let me know if I can help debugging / testing. |
|
what does |
|
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 |
|
So it detected the Junkers heatronic boiler, but it still says TX: no signal. No other devices were detected (Thermostat and Solar Module). |
|
Fixed now in b12
…On Sat, 5 Oct 2019 at 12:21, Vuego123 ***@***.***> 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
<#103>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJMO6HY7JXBWJHMNREHJ6LQNBTBFANCNFSM4HIRMMMQ>
.
|
|
closing, if there are bugs please re-open or create a new issue. |
|
I deployed 1.9.2b1 but the issue is not resolved. I don't see any difference. |
|
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: Boiler stats: Thermostat: Bosch EasyControl CT200 (ProductID:203 Version:02.06) @proddy Thank you for fixing this! |
|
phew! that was a hard bug to find. thanks for being patient. |
|
My bad, config issue. It is working here as well. Thank you for the bugfix! |
|
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? |
Hello,
First of all: Thanks for the amazing work you have done on this project!
I own the following heating Components:
I have ordered bbqkees circuit and connected it to the EMS-Bus (connected cables in parallel to the thermostat connectors). I also built and installed the latest Firmware from the dev-Branch (1.7.0b9).
As others it seems I am not able to send data to the bus (
Tx: no signal). The Tx queue is filling up slowly. I also tried toset tx_delay onbut that didn't help.autodetect,send ..,refreshist 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:
After disconnecting/reconnecting the Thermostat, this is what I get with
log v.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
The text was updated successfully, but these errors were encountered: