FrankRenp
commented
5 years ago @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
Closed philrich closed 5 years ago
FrankRenp
commented
5 years ago @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
commented
5 years ago yup, I'm testing it now and its not working either. I'm looking at it....
proddy
commented
5 years ago @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
commented
5 years ago 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 notifications@github.com:
@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
commented
5 years ago @proddy I‘ll work at ‚take two‘ - got. an additional idea about non-intrusive implementation...
susisstrolch
commented
5 years ago @proddy Please cherry-pick the latest commit from my repo (fork) - it contains a reconditioned version... commit 4579da6ee049af2ffe4dd5a5101f813d2a8d17d4 (HEAD -> smart-tx-TakeTwo)
proddy
commented
5 years ago ok, I'll manually merge and will ignore the PR
proddy
commented
5 years ago @susisstrolch couldn't get it to work - Tx causes ESP resets. I was thinking of a different approach
susisstrolch
commented
5 years ago @proddy same here - reboot after 2-5min... Hmm, watchdog timeout while waiting on large telegram?
proddy
commented
5 years ago I made a mistake in my uart_stop() function. Forgot it was also used when saving to SPIFFS. fixed now.
proddy
commented
5 years ago 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=27the 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:
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
commented
5 years ago @proddy notification: edit of last message...
proddy
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Jep - it runs since 2hr with log v. Simple use the whole tx-Funktions
susisstrolch
commented
5 years ago I mean the whole emsuart.cpp. It‘s based on your latest commit.
proddy
commented
5 years ago cool. ok @philrich you have the infinity stones. Does the latest build work with Junkers?
philrich
commented
5 years ago 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 notifications@github.com:
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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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 notifications@github.com:
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.
KristofRobberechts
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago Seems it‘s time to rename tx_delay to tx_mode... 😬
Sent by mobile device
Am 26.05.2019 um 12:26 schrieb Proddy notifications@github.com:
@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
commented
5 years ago Thanks @proddy this sounds like a good idea.
Am 26.05.2019 um 12:26 schrieb Proddy notifications@github.com:
@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
commented
5 years ago Yup. Was very tempted to change it but was worried I might confuse people.
On Sun, 26 May 2019 at 13:07, susisstrolch notifications@github.com 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 notifications@github.com:
@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
commented
5 years ago 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
commented
5 years ago see #119
susisstrolch
commented
5 years ago 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=2Seems info (tx_mode) needs a fix...
proddy
commented
5 years ago PR #119 works great. Also fixed the typo in Tx_mode
KristofRobberechts
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago will look into it as soon as i am at home.
philrich
commented
5 years ago 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
KristofRobberechts
commented
5 years ago The patch works for me too, using tx_mode 3
philrich
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago This morning I did a couple of tests with the DEV version 1.8.0b8 Products used:
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
commented
5 years ago @kwertie01 thanks for testing. I've modified the code with your suggestions.
m1588
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago @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.
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