emsesp / EMS-ESP

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

Hardware issue in EMS powered mode #155

Closed susisstrolch closed 5 years ago

susisstrolch commented 5 years ago

@bbqkees: I found an issue with my hardware (and probably all derived ones). Running in USB powered mode (using a D1 Mini Pro) Tx works like a charm. In contrast, when running in EMS powered mode the Tx doesn't work, the EMS busmaster doesn't echo.

Power supply is ok - 3.3V via EMS bus, 3.33V via USB.

I had to change the R4 and R5 (collector resistors of T2) from 470R to 390R. After that the bus master detected the Tx also in EMS bus powered mode.

bbqkees commented 5 years ago

Ok. Thanks for the heads up. I have reverse engineered several EMS thermostats and one Nefit Service Key in the past and they use a resulting resistor value of 225 to 250 Ohms for Tx. 2x390 would result in 195 Ohms.

My boards use 227 and indeed no Tx when bus powered. I'll try as well with values around 200.

My initial idea was to use a potmeter to determine the full range for Tx, but in the end never tried.

susisstrolch commented 5 years ago

Because of lazyness I currently have 3x470R -> ~160R which is pretty low, but works reliable. Maybe the base load of the bus powered device shifts the offset of the master receiver.

bbqkees commented 5 years ago

Yes I think so too. I don't recall all the details but I have done some power measurements on the RC35 and I thought it was about 20-50mA of continuous current and for the Wemos I measured about 70mA on the bus line itself. Perhaps the high(er) base load shifts the TX outside of the allowed 'current window'.

bbqkees commented 5 years ago

I tried today with 4x820 (=205 Ohm) and 4x750 (=188 Ohm) and with the latter value 'parasitic' mode works. 820 Ohm might work as well but on that board the Wemos seemd deprived of enough power.

bbqkees commented 5 years ago

Been running 4x750 now for a day or two in parasitic mode. About 20% of slave writes cause a corrupt telegram. So still looking into that.

susisstrolch commented 5 years ago

With the 3x470 I only have minimal Problems.

Sent by mobile device

Am 30.07.2019 um 09:36 schrieb Kees notifications@github.com:

Been running 4x750 now for a day or two in parasitic mode. About 20% of slave writes cause a corrupt telegram. So still looking into that.

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

bbqkees commented 5 years ago

I'm testing (slowly) for the edge cases. Dropping f.i. from 200 Ohm to 150 Ohm translates to about 25mA more power draw from the bus. Don't want to put an additional load on the bus that might not be necessary.

susisstrolch commented 5 years ago

My feeling: 4x680...

Sent by mobile device

Am 31.07.2019 um 09:46 schrieb Kees notifications@github.com:

I'm testing (slowly) for the edge cases. Dropping f.i. from 200 Ohm to 150 Ohm translates to about 25mA more power draw from the bus. Don't want to put an additional load on the bus that might not be necessary.

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

bbqkees commented 5 years ago

Yes that might be the 'sweetspot' for the Wemos/ESP8266.

susisstrolch commented 5 years ago

I think you should also use the latest "txmode2" branch, because it addresses a few issues with the communication protocol.

bbqkees commented 5 years ago

Testing with txmode2 branch since yesterday evening. In combination with 4x680 still the occasional corrupt telegram after a request but much less then before. But lots of reboots every couple of minutes or so. First I thought it was the web interface that was open but closing it didn't make a difference. Switched to jack power and now its running without reboots. Did not have time yet to see if the bunch of reboots are a power issue or a software issue.

susisstrolch commented 5 years ago

Hmm, thats pretty interesting! With my tests I see the reboot by software watchdog approx. after 6-9hrs. I think I'll add the reboot reason to the MQTT start to monitor w/o having Web or telnet connection.

bbqkees commented 5 years ago

It's now at 10,5h and counting. Last reset reason was 'external system', because I unplugged it myself of course. During the 2min reboots I saw the reason 'software WD' flashing by. Perhaps I should log it to a file as well.

proddy commented 5 years ago

In 1.9 which is still in dev (and buggy like all my stuff) has the new web interface and a log which I store in SPIFFS to record all crashes and reboots. We'll need to merge with @susisstrolch's txmode2 branch but then we should have an easier way to troubleshoot. I eventually want to only use Telnet for peeking into the bus, it was never intended to be used constantly. The web and mqtt stuff is all asynchronous, the telnet isn't.

susisstrolch commented 5 years ago

I always merge your changes into the txmode2 branch. We should also think about sending some informations via MQTT, like uptime, reset reason (can be sent with the start publish), bus mode (Buderus / Junkers).

bbqkees commented 5 years ago

I didn't see any difference in the web interface yesterday. So is it in yet?

I was thinking of running two boards with the latest builds simultaneously. One bus powered and and additional one but jack powered and in monitor mode.

bbqkees commented 5 years ago

BTW magnetic tape is quite convenient for small tests like these: ems magnetic

susisstrolch commented 5 years ago

I was thinking of running two boards with the latest builds simultaneously. One bus powered and and additional one but jack powered and in monitor mode.

That would require two changes (I'd like to see)

susisstrolch commented 5 years ago

... and a log which I store in SPIFFS to record all crashes and reboots. ...

Does it also work with the software watchdog? I never saw the stacktrace when it bite me. And whats about the flash wear-out? Shouldn't we be carefull with flash writes?

bbqkees commented 5 years ago

That would require two changes (I'd like to see)

* setting the ems-esp hostname (as a config value)

* setting the EMS busid (as a config value)

In a normal situation you never need two EMS-ESP's side by side. Not sure you want to add additional stuff just for just this case. You can still access each one via the IP address instead of the host name. If you run the second device in monitor mode there is no TX so it doesn't need another bus ID.

(I'm also wondering if there are any additional 'spare' bus ID's aside from the Service Key ID you could use without problems.)

I would be interested in running multiple side by side for a while to check whether crashes occur on all at about the same time or if we can f.i. catch issues that are hardware related this way.

susisstrolch commented 5 years ago

If you run the second device in monitor mode there is no TX so it doesn't need another bus ID.

No, that doesn't work out. There are a lot of codeparts which check for EMS_ID_ME and would therefore show a completly different behaviour. That's also true for the mDNS, which would announce the same host for different addresses. Suboptimal when trying to update...

(I'm also wondering if there are any additional 'spare' bus ID's aside from the Service Key ID you could use without problems.)

0X0A - Hand held terminal 0x0D - KM200 (Modem) 0x0F - Time modul 0x12 - external error module The last two would be pretty interesting, to see if the Bus master would automatically connect to it...

proddy commented 5 years ago

the hostname is customizable as well as a few other things. I'll see if I can get the web version uploaded to a separate GitHub branch for you guys to play around.

proddy commented 5 years ago

the hostname is customizable as well as a few other things. I'll see if I can get the web version uploaded to a separate GitHub branch for you guys to play around.

it's in the newweb branch

0X0A - Hand held terminal 0x0D - KM200 (Modem) 0x0F - Time modul 0x12 - external error module

I can make this BUS ID optional if you can confirm hardcoding to another values in ems.h: #define EMS_ID_ME 0x0B // our device, hardcoded as the "Service Key"

to 0A, 0D, 0F works for you.

proddy commented 5 years ago

bbqkees has an improved design supporting this. We can re-open if we see issues.

Sonusss commented 4 years ago

Hi,

I soldered a potmeter ;-) In my setup I had to lower the Tx resistor down to 130R to have the Logamatic TC100 being detected and even like this the readings are not stable. When powered from USB no issues at all.

How low can we go for this Tx resistor ?

My setup: BBkees interface V0.9 Wemos D1 mini EMS devices: Buderus GB172/Nefit Trendline/Junkers Cerapur (Version:06.08 ProductID:123 DeviceID:0x8) BC25 Base Controller (Version:03.03 ProductID:125 DeviceID:0x9) Logamatic TC100/Nefit Moduline Easy (Version:02.19 ProductID:202 DeviceID:0x18)

bbqkees commented 4 years ago

You could try 100 Ohm. Or just use the service jack, it has more than enough power.