Closed susisstrolch closed 4 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.
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.
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'.
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.
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.
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.
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.
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.
Yes that might be the 'sweetspot' for the Wemos/ESP8266.
I think you should also use the latest "txmode2" branch, because it addresses a few issues with the communication protocol.
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.
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.
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.
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.
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).
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.
BTW magnetic tape is quite convenient for small tests like these:
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)
... 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?
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.
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...
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.
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.
bbqkees has an improved design supporting this. We can re-open if we see issues.
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)
You could try 100 Ohm. Or just use the service jack, it has more than enough power.
@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.