Logamatic 2107 Schnittstelle

Hi Niffko,
Ich denk auch, alles OK.
Noch ne Frage da ich gerade Telegramme decodiere ... ist der Code nur 
ein byte oder die 00 davor noch dazu? Die dokus hier in den Excel 
dateien sind "not obvious" ;-)
Ed

Gibt es ausser die Excel files oben im Thread no signifikante 
Forschritte bei dem Mapping von den Telegram Codes?
Bei mir huscht so vieles durch den Parser durch und am anderen Ende raus 
... ;-)

Ed

Den GB162 habe ich auch. Den habe ich einfach am 3.5mm Klinke abgehorcht 
(Service Buchse hinter scharzen Kappe am Front Pannel). Da sind wie oben 
irgenwo :-) erwaehnt 12 Volt, Gnd und Signal. Mit einem Transistor auf 
nen Optokoppler laeuft bei mir seit 6 Monate ohne Probleme. Eingriff ins 
Geraet fuer EMS + und - nicht noetig. Auch Max232 entfaellt und der 
ATmega Seriel Eingang kann direct an den Opto Ausgang. Aufpassen muss 
man nur bein reinstecken des Klinken steckers wegen der +12V? Einmal hat 
es mein Brenner resetet und seitdem mache ich Strom aus bevor ich den 
rein mache oder raus ziehe. Die info hier im Thread ist gut und viel, 
doch weit verstreut ...

Ed

Hallo Leute,

ich habe mir hier ein Setup aufgebaut, um meine Buderus Heizung per EMS 
auszulesen. Ziel der Sache ist es eigentlich die Tag/Nachtschaltung 
umzuschalten und somit das vorhandene RC25 zu "emulieren". Die 
Bedieneinheit soll natürlich weiterhin bleiben. Ich habe hier das 
Ethersex Modul von maniac103 am laufen. Damit habe ich nun mal ne halbe 
Stunde oder so mitgeloggt und eine Statistik erstellt. Weiterhin habe 
ich etwas in der Übertragung rumgestochert und folgendes 
"herausgefunden":

Sonne drücken: AA 55 06 17 08 35 00 11 11 2A
Mond drücken: AA 55 06 17 08 35 00 01 01 2A

Ansonsten war das Langzeitlog im Sonnemodus und der Referenzraum hatte 
21.4 - 21.9°C soweit ich das überblicken konnte.

Nun meine frage: Wie kann ich auf den Bus senden? Mit einem 
Logikanalyzer an der Interfaceplatine mit dem Komparator komme ich nicht 
wirklich weiter weil ich nur 32k Ram habe... Muss ich das ganze noch 
einmal bauen um auf dem Bus zu sniffen? Oder könnt ihr mir weiterhelfen?

LG Floppy

Hallo,

ich habe das PIC Gateway von Ingo und nutze ein Python Script um die raw 
Daten auszulesen.
Von Zeit zu Zeit habe ich falsche Werte in meiner DB so das ich gerne 
die CRC checken würde.
Habe hier auch die beiden Python Beispiele von Rudi gefunden, die bei 
mir so nicht laufen.
Das Format müsste ja so aussehen:
0xaa 0x55 <ems data> <ems checksum> <0x00=brk> <length between markers> 
0xaa 0x55
Wenn ich versuche die CRC berechnung über die <ems data> zumachen 
bekomme ich folgende Fehlermeldung:

1

für crc1(a):

2

 crc1 = crc1 ^ int(a[i],16)

3

ValueError: invalid literal for int() with base 16: '\x08'

4

5

bzw. für crc2(a):

6

    crc1 = crc1^int(a[i])

7

ValueError: invalid literal for int() with base 10: '!'

Was läuft da falsch?!?

1

def crc1(a):

2

        try:

3

                poly = 12

4

                crc1 = 0x00

5

                for i in range(0,len(a)-1):

6

                    crc1 = crc1 ^ int(a[i],16)

7

                    crc2 = crc1

8

                    if crc1 & 0x80: crc1 ^= poly

9

                    d = 0

10

                    if crc1 & 0x80: d = 1

11

                    crc1 = crc1 << 1

12

                    crc1 &= 0xfe

13

                    crc1 |= d

14

                return crc2

15

16

        except Exception, ex:

17

                logging.exception("crc: Something awful happened!" + str(ex))

18

                return ""

19

###################################################################################################

20

21

def crc2(a):

22

        try:

23

    crc1 = 0x00

24

    for i in range(0,len(a)-1):

25

      d = 0

26

      if crc1 & 0x80:

27

        crc1^=12

28

        d = 1

29

      crc1 = crc1 << 1

30

      crc1 &= 0xfe

31

      crc1 |= d

32

      crc1 = crc1^int(a[i])

33

    return crc1

34

###################################################################################################

Gruß
Kay

Noch ein paar Schnipsel mit neuen Feldern:

----------------
10 88 14 00 03 6E 00 07
[ 10 RC35   -> ?88 UBA   ] typ=14, off=00, length=03

08 10 14 00 2D 63 EA C1 00 09
[ 08 UBA    ->  10 RC35  ] typ=14
Betriebszeit gesamt h 49578.3  (off=1,len=3,div=60)
----------------
10 88 04 00 10 3D 00 07
[ 10 RC35   -> ?88 UBA   ] typ=04, off=00, length=10

08 10 04 00 04 1C 0B 40 0F 25 48 00 00 69 6B 0C 00 00 48 BC 00 15
[ 08 UBA    ->  10 RC35  ] typ=04
BCM-Nr.  1052  (off=1,len=2)
BCM      11    (off=3,len=1)
-----------------

hat sonst noch jemand etwas Neues?

vg

Jürgen

Hi Rudi,

mit welchem Hardwaremodul hast du die Anbindung an den Pi realisiert? 
Würdest du auch den Code dazu zur Verfügung stellen?

Gruss
Norbert

Hi Rudi,

danke für den Link,
hatte mich verlesen, der mit dem Pi war sysrun,
ich hätte auch Interesse an einer Anbindung an Openhab, wie jschmied.

Gruss
Norbert

Hallo!

Ich bringe dem EMS-GW im Moment TCP/IP und JSON bei. Damit dürfte sich 
auch die OpenHAB Anbindung einfach ohne ein spezielles Binding 
realisieren lassen.

Ob ich mir noch einen OpenHAB Server hinstelle, wenn das GW alles selbst 
macht (incl. WebGUI und Logs schreiben) weiß ich noch nicht. ;)

vg

Jürgen

Hi Jürgen,

ist das der normale oder schon gepimpte Gateway (größerer Pic mein ich 
irgendwo gelesen zu haben) von Ingo?

Gruss
Norbert

Hallo!

Mit ein paar Web-Seiten ohne JSON bin ich bei 31K ROM und 1366 RAM. Der 
PIC18F4580 hat 32 KB ROM. Ohne Webseiten würde das JSON Interface 
warscheinlich reinpassen. Es wäre (zumindest für mich) aber einfacher 
den PIC zu wechseln, als X Versionen der Firmware zu pflegen. In die 
96KB des PIC18F4685 passt alles rein.

Ich habe ein Board (wg. Blitzschaden) bereits umgebaut, den PIC zu 
wechseln geht schnell. Ich habe den alten mit einem Dremel weggefräßt, 
um das Board nicht zu beschädigen ;). Dann kann man die Reste der 
Beinchen einzeln auslöten.

vg

Jürgen

Hallo!

Ja, man kann alles auf einen externen Websserver packen und das GW nur 
JSON sprechen lassen. Da muss dann jeder für sich einen Webserver 
einrichten und die URL auf das GW konfigurieren.

Nachteil:
Es ist dann ein extra Gerät oder Webspace im Internet nötig

Vorteil:
Man kann leicht erweitern, andere Geräte einbinden, Design ändern, 
Grafik einbinden usw.

vg

Jürgen

Hallo,

an alle die einen EMS-Gateway oder eine andere Hardware für den EMS-Bus 
haben:
Es gibt jetzt eine Wiki zum EMS-Gateway (nicht Logamatic 2107):
http://ems-gateway.myds.me:8001/dokuwiki/

Es kann so gut wie alles gelesen werden.
Nur zum lesen einiger Bereiche (Telegramme des EMS-Bus) wird eine 
Registrierung benötigt.

Um Mithilfe bei der Entschlüsselung der EMS-Telegramme wird gebeten.

Da in diesem Thread auch der EMS-Gateway entstanden ist poste ich es 
auch hier...

Gruß
IngoF

Ingo F. schrieb:
> Es gibt jetzt eine Wiki zum EMS-Gateway (nicht Logamatic 2107):
> http://ems-gateway.myds.me:8001/dokuwiki/
>
> Es kann so gut wie alles gelesen werden.
> Nur zum lesen einiger Bereiche (Telegramme des EMS-Bus) wird eine
> Registrierung benötigt.
>
> Um Mithilfe bei der Entschlüsselung der EMS-Telegramme wird gebeten.

Vielleicht bin ich einfach zu blind, aber: Wie meldet man sich an? Eine 
Registrierungsseite habe ich nicht gefunden...
(Davon mal abgesehen: Warum der Registrierungszwang für die 
EMS-Telegramme?)

Danny Baumann schrieb:
> aber: Wie meldet man sich an?

Ganz einfach... oben rechts auf registrieren ;-)

Aber lag nicht daran dass Du blind warst.. Habe wohl zuviel an der 
Konfiguration herumgespielt. Und schwups war die Registrierung futsch...

Gruß
Ingo

So der Winter naht wieder... und ich habe dass Geraffel wieder hervor 
geholt. Nach längerem durchforsten der EMS Protocol Plugin Codes von 
Ethersex habe ich es nun auf einem ATMega 644P (wieder) laufen.

Dazu musste in der ems_uart.h folgendes hinzugefügt werden:
#define PORTEMS_UART_TX_PORT           PORTD
#define EMS_UART_TX_PIN       PIND
#define DDREMS_UART_TX_PORT     DDRD


Nun haut das Netio auch per TCP/IP die Daten raus. Mit Wireshark habe 
ich mal reingeschaut, wobei man ja nicht all zu viel sieht. Wie wertet 
ihr die Daten aus? (Ich hatte ja mal was laufen, kann mich aber zum 
Teufel nicht mehr erninnern wie/was).

Weiterhin gibt http://192.168.0.90/ecmd?ems%20stats folgendes aus:

Bytes total:37301
Bytes good:528
Bytes dropped:0
Packets good:83
Packets bad:1959
Packets 1byte:25524 501
Packets ack:0 nack:0
Overflow:0
Max fill:2

Könnt Ihr mir weiterhelfen?

LG Floppy

Tante Edit:
So, habe noch Realterm probiert und inerhalb von so ca. 5 Minuten 
folgendes mitgelogt:
AA 55 05 08 13 05 22 00 3C
AA 55 06 17 08 35 00 11 11 2A
AA 55 08 17 08 1A 00 00 00 00 00 05
AA 55 05 17 00 AD 03 01 B8
AA 55 02 17 FC EB
AA 55 05 08 13 05 22 00 3C
AA 55 05 08 13 05 22 00 3C
AA 55 06 17 08 35 00 11 11 2A
AA 55 08 17 08 1A 00 00 00 00 00 05
AA 55 05 08 13 05 22 00 3C
AA 55 05 08 13 05 22 00 3C
AA 55 15 08 00 34 00 28 00 D6 80 00 80 00 04 01 00 00 15 BC 00 30 B7 00 
E9
AA 55 02 17 FC EB
AA 55 05 08 13 05 22 00 3C
AA 55 15 08 00 34 00 28 00 D4 80 00 80 00 04 01 00 00 15 BC 00 30 B7 00 
EB

Such mal in meinen Postings in diesem Thread nach ems-collector ... das 
ist die Gegenseite dazu, die die von ethersex gelieferten Daten 
auswerten und in eine mysql-Datenbank schreiben kann.

Hallo,
ja daran habe ich mich auch schon versucht. Das ganze habe ich nach ein 
paar installierten Dev-Libs auf einer Debian Kiste kompiliert bekommen. 
Nun klemmts am Aufruf... Mysql Username und Datenbank sind erstellt, 
aber ich bekomme weiterhin fehlermeldungen dass das Device nicht gültig 
ist. gibt es hiezu Doku? Bis auf die kleine Help Ausgabe habe ich im 
Dunkeln gestochert und mich an Fehlermeldungen entlang gehangelt.

./collectord -u ems -p xxx -d5 -f 192.168.0.90
Exception: Target 192.168.0.90 is invalid.

LG

./collectord -u ems -p pass -d all -f tcp:192.168.0.90:7100 sollte 
funktionieren (evtl. must du den Port anpassen). Dass die Hilfe für das 
Target nicht angezeigt wird, ist eine Limitierung in 
boost::program_options (oder meiner Unfähigkeit geschuldet, das Zeug 
richtig zu benutzen).

Nun kommt was :) Danke schonmal

./collectord -u ems -p ems -d all -f tcp:192.168.0.90:7950
IO: Got bytes 0xaa 0x55 0x5 0x8 0x13 0x5 0x22 00 0x3c
MESSAGE[14.09.2013 09:58:39]: source 0x08, dest 0x13, type 0x05, data 
0x22 0x00
DATA: Unhandled message received(source 0x08, type 0x05).
IO: Got bytes 0xaa 0x55 0x2 0xb8 0xfe 0x46
MESSAGE[14.09.2013 09:58:41]: source 0x00, dest 0x00, type 0x00, data 
0xb8 0xfe
IO: Got bytes 0xaa 0x55 0x5 0x8 0x13 0x5 0x22 00 0x3c
MESSAGE[14.09.2013 09:58:59]: source 0x08, dest 0x13, type 0x05, data 
0x22 0x00
DATA: Unhandled message received(source 0x08, type 0x05).


Nun müsste man nur noch was damit anfangen können. Wie kann ich nun 
aktiv eingreifen? Ich will im endefekt von Tag auf Nacht umschalten 
können. Wie stelle ich das Webinterface ein dass es daten anzeigt?

LG

Tante Edit:
so die Website liefert ein Bild nachdem ich username/password angepasst 
habe (in sensor_utils.php.inc), wobei mit total wirren Informationen... 
da passt garnichts

Tag/Nacht umstellen sollte damit gehen:

telnet localhost 7777
hk1 mode night (oder hk2 mode auto, oder...)

Die Webseite ist mehr oder weniger ein Quick Hack, da musst du im 
Zweifelsfall mal etwas frickeln. Stimmen denn die Werte in der 
Log-Ausgabe und/oder der Datenbank?

Ich habe mal bis hk4 durchprobiert... kommt immer ERRTIMEOUT :(
Die datenbank füllt sich auch kaum... kann es sein dass ich irgendwo 
zuordnungstabellen anpassen muss? Es ist halt leider ein RC25 und kein 
RC35 Panel.

Bei ERRTIMEOUT hat sich die RC nicht angesprochen gefühlt ... bei den 
Unterschieden zwischen RC25, RC30 und RC35 bin ich allerdings überfragt. 
Selbst habe ich ein RC30, damit funktioniert es.

Zwei Dinge kommen mir aber komisch vor: der Bus-Slave 0x17 (ist das die 
RC25?) und die sehr hohe Anzahl an Bad packets, d.h. CRC-Fehlern. 
Letzteres deutet darauf hin, dass an der Schaltung noch etwas nicht in 
Ordnung ist. Bei mir ist das Verhältnis good-bad z.B. im Moment 
817000-24.

Hmmmm okay.... aber die Kesselsolltemperatur stimmt schonmal. 40°C sind 
an der Heizung eingestellt (durchlauferhitzer).
Wie komme ich dem ganzen am besten bei? So etwas zu Debuggen ist ja 
nicht gerade trivial.

So, ich war noch ein paar Daten sammeln ;)

Heizung: Buderus U154-20k
Bedieneinheit: RC25

Daten in dem RC25:
P1 -> 0     (Master ohne weitere Programmiergeräte)
P2 -> 1     (Roomflow Mode / Regelkreis auf die Durchflussrate)
P3 -> 0.0°C (Raumkalibrierung)
P4 -> 1     (DHW Heating True)
P5 -> 1     (Internal Boiler Pump)
P6 -> 5     (Nachlaufzeit Boiler Pump)
P8 -> 0     (Time Adjustment)
P9 -> 0     (No thermal disinfection)
P10-> 401   (Software Version)
P13-> 75°C  (Maximum Flow Temperature)

Vllt. hilfts ;) Mensch wär ich happy wenn ich irgendwie die f**k Heizung 
per TCP/IP ein/aus schalten kann. Geht sowas überhaupt? Es kann ja auch 
sein dass der RC25 als 2-Punkt Regler funktioniert und nur Brenner 
ein/aus Kommandos gibt. Somit wäre die komplette Steuerung in dem RC25 
und der Zustand Auto/Sonne/Mond kommt nie über den Bus und ist somit 
auch nicht beeinflussbar... (ANGST :p)
Da das Modul nicht mir ist (Mietshaus) würde ich Ungern direkt auf die 
Taster gehen (wobei ich immer mehr dazu tendiere).

LG :)

Das kennst Du?

http://www.buderusdaten.ch/webseite/joomla/index.php?option=com_remository&Itemid=38&func=fileinfo&id=1814

Auf alle Fälle muss die RC25 dem UBA (Brenner) regelmäßig bestimmte 
Pakete senden, ansonsten schaltet sich die Heizung nach einer Weile ab. 
Da die UBA bestimmt nur ein Protokoll spricht, sind es bestimmt die 
gleichen Pakete wie auch die RC35 senden würde.

Hat jemand mit einem EMS-GW einen RC25 als Master und kann einen 
Busmitschitt machen? Am besten incl. Boot-Sequenz dre Anlage.

vg

Jürgen

Ja das Dokument hab ich in Englisch per Google gefunden ;) Aber deutsch 
ist mir auch lieber.

Also muss ich nun als nächstes erst mal das bad/good Verhältniss 
aufpeppeln? Nur wie? Ich flashe gleich mal eine erweiterte Debug 
Software in das NetIO. Werde dann auch gleich mal den Schaltplan des 
Adapter-Moduls heraussuchen und hochladen.

Tante Edit:
So nun mit Schaltplan. das Adapterkabel schaut wie folgt aus:
EMS Board - EXT Netio
1 (VCC)   - 10 (5V)
2 (RX Out)- 1  (PD2)
3 (TX in) - 2  (PD3)
4 (U Ref) - NC
5 (GND)   - 9  (GND)

Hallo!

Prüfe mal die Taktfrequenz des Mikrocontrollers und die Baudrate der 
UART. Ein Fehler dort bring alles durcheinander.
Kritisch sind eigentlich nur C3/R4, da deren Zeitkonstanate nahe an der 
Baudrate ist, wirken sich Änderungen der Teile direkt auf die 
Tastverhältnisse an der UART aus.
Der + des OPV müsse ca. 0,6 V haben, der - ungefähr 0,05 V weniger.
Ansonsten ist an der Schaltung nicht viel falsch zu machen ...

vg

Jürgen

@Ra Sp

> [Schaltplan]

U_REF hast du falsch gedeutet. Hättest du nicht herausführen müssen, ist 
ne' rein interne Angelegenheit.


//Niffko

Ra Sp schrieb:
> Heizung: Buderus U154-20k

Der U154 ist, wenn man's genau nimmt, mehr Junkers als Buderus 
(Bosch-Synergieeffekt). Die Steuerplatine wird auch nicht als UBA 
bezeichnet. Kann was bedeuten, muss aber nicht. Auf jeden Fall könnte es 
Unterschiede geben.

//Niffko

Ja ist herausgeführt um evtl. mal zu erkennen ob der Bus angeschlossen 
ist. Man weis ja nie :) Wie prüfe ich bei RX die Baudrate? ;)

LG

niffko schrieb:
> [ironie]
> Achso ... dafür sind die ~0,6V natürlich geradezu ideal.
> [/ironie]

Tjoa... um ganze Bytefolgen zu übertragen reichts ja wohl.... dann werde 
ich wohl auch ein Bit heraus bekommen. Wo ein Wille da ein Gebüsch oder 
so :p

Wenns denn nötig wäre könnte man auf einen ADC Eingang gehen (für was 
anderes sind die AVR ADCs eh nicht zu gebrauchen)

LG

Es gibt Neues... Auch wenn es nur ein Bild ist :p
Messaufbau:
Grün: EMS - High side
Gelb: RX Out der Adapterplatine
Masse hole ich am Steckverbinder NetIO-Adapterplatine

Nur woher kommen die Drifts? Denke das sind meine 
Kommunikationsprobleme.

naja Sendeversuch ist meinerseits nie gelaufen. Das ist ein Mitschnitt 
zwischen Heizung und RC25. Und es sieht relativ häufig so aus.

Hmm... die Datenübertragung ohne NetIO schaut gut aus. Diese Ausläufer 
treten ohne Platine nicht mehr auf. Ob ich das Notebook beim Messen 
einstecke oder nicht ändert daran wohl nichts. Nun ist die Frage wo ich 
sonst die Masseschleife her bekomme (ich gehe nun einfach mal davon 
aus). Evtl übers Ethernet?! Probiere ich gleich noch einmal aus.

So, hole ich mir nun die Masse vom Bus, driftet das gelbe Logiksignal 
umher. Zwischen beiden Massen liegt ja eigentl. nur eine Diode. Klemme 
ich Ethernet ab, sind die Drifts weg.Nun kann ich leider die Sache nicht 
mehr debuggen.

Tante Edit:
Der RS232 Ausgabe entnehme ich dass es wohl geht.
Die CRC stimmt mit der berechneten über ein.. Ich bekomme im 
Sekundentakt Meldungen folgender Art:

D: ems: No client connected, dropping 5 bytes
D: ems: Packet CRC a2 calc a2

Nun muss ich zusehen wie ich die Masseschleife unterbinde.

Hallo!

Bei mir ist der EMS Bus an der Therme geerdet. Wenn der Oszi auch eine 
Masse mitbringt, gibts Probleme ...

vg

Jürgen

Ra Sp schrieb:
> Der RS232 Ausgabe entnehme ich dass es wohl geht.
> Die CRC stimmt mit der berechneten über ein.. Ich bekomme im
> Sekundentakt Meldungen folgender Art:
>
> D: ems: No client connected, dropping 5 bytes
> D: ems: Packet CRC a2 calc a2

Ja, ds sieht gut aus. Das 'dropping X bytes' passiert ja nur, weil er 
die Daten nirgendwo hin weiterleiten kann.

> Nun muss ich zusehen wie ich die Masseschleife unterbinde.

Hmm. Hast du an deinem NetIO schon irgendeine Modifikation durchgeführt? 
Ich musste eine ganze Menge Elkos um den ENC28J60 verteilen, damit der 
langzeitstabil wurde und sich nicht nach einer Woche oder so weggehängt 
hat (Anleitungen dazu findet man im Netz). Ich meine, mich dunkel 
erinnern zu können (ist ja schon 1,5 Jahre her), dass ich in diesem Zuge 
auch die Masse der Ethernet-Buchse des NetIO galvanisch getrennt habe: 
Lotflächen für die Schirmung von der entsprechenden GND-Plane getrennt 
(mit einem Cuttermesser weggeritzt) und mit einem C wieder verbunden. 
Das dürfte bei dir dann wahrscheinlich auch helfen. Warum Pollin da 
nicht selbst drauf gekommen ist, weiß aber kein Mensch...

So... nun geht es sogar mit Ethernet :p

Bytes total:93010
Bytes good:20370
Bytes dropped:0
Packets good:1058
Packets bad:3
Packets 1byte:71628 1377
Packets ack:0 nack:0
Overflow:0
Max fill:6

Das schaut ja soweit gut aus. Nun bleiben noch folgende Punkte offen:

1.) Tag/Nacht umschalten
2.) Tag/Nacht auslesen
3.) evtl. Raumtemperatur auslesen (eher unwichtig)

Ich versuche gleich erstmal den TX am µC aufzuzeichnen.
Kann ich direkt (per ecmd oder ähnlich) Hex-Bytes versenden?

LG

Tante Edit:
Also das hk1 mode night kommando erzeugt das zweite Bild (gelb RX, grün
bus), und dann kommen noch im x Sek Takt die Signale aus Bild 1.

Aufgrund falscher Bilder habe ich den letzten Beitrag gelöscht

Bitte beachte die Bildformate!
Und Bitmaps als JPG abzuspeichern macht kein Sinn.
Mit z.B. IrfanView hats soetwas schnell als png abgespeichert(geht sogar 
auch mit MS Paint)

Uh... sorry. Nun sehe ich es auch. Das macht die billige Hantech 
Software. Dort kann ich zwar zwischen JPG und BMP wählen, was aber wohl 
nicht implementiert ist. Dann verwende ich ab jetzt das Snippingtool von 
Windows.

Ra Sp schrieb:
> Ich versuche gleich erstmal den TX am µC aufzuzeichnen.

Wenn du mal ein git pull im ems-collector machst, siehst du danach die 
gesendeten Bytes direkt in dessen Debugausgabe ;)

> Kann ich direkt (per ecmd oder ähnlich) Hex-Bytes versenden?

Nein. Ich hab mir für solche Zwecke immer schnell den collector gehackt. 
Es wäre aber in der Tat wahrscheinlich mal eine sinnvolle Idee.

> Also das hk1 mode night kommando erzeugt das zweite Bild (gelb RX, grün
> bus), und dann kommen noch im x Sek Takt die Signale aus Bild 1.

Ich glaube, vom elektrischen Debugging kannst du jetzt weggehen. Was 
sagt den die Debugausgabe von ems-collector, wie sehen die empfangenen 
Pakete zu diesem Zeitpunkt (dekodiert) aus?

So,
heute erstmal den tftp-Kram vorbereitet. Morgen verfrachte ich das Teil 
mal an die Heizung. Kann mir jemand Service Unterlagen geben? Finde nix 
zur  U154-20k

LG

Die Firmware für das neue Board soll das können, sie besorgt sich per 
NTP die genaue Zeit.
Ich habs noch nicht probiert, aber ich denke:

0B 10 06.00 0D 09 14 13 00 00 <CRC>
............YY.mm.hh.dd.mi.ss

sollte die Zeit auf den 13.09.2013 20:00 setzen.

PS: Wir sollten mal einen neuen Thread auf machen. Mein UMTS 
Datenkontigent ist sonst mit 3 Mal hier rein gucken alle ;)

vg

Jürgen

Jürgen Schmied schrieb:
> Wir sollten mal einen neuen Thread auf machen.

^^finde ich gut.
Ich lese schon lange den Thread mit. Mit meiner langsamen DSL-Verbindung 
dauert es ewig das sich die Seite öffnet. Gibt es eine Möglichkeit nur 
die letzten Texte zu lesen?

Done :) Beitrag "Faktensammlung Buderus EMS"

#############################################################

*** Bitte hier nicht mehr posten ***

... wegen Überlänge ...

Bitte hier weiter machen:

Beitrag "Faktensammlung Buderus EMS"

#############################################################

Hallo zusammen,

habe bereits das NetIo-Board zusammengelötet.
Wollte statt dem 644p den 1284p einsetzen.

Wollte mir dann das Ethersex-File für den Atmega zusammenstellen.

Allerdings kann ich das EMS-Protokoll nicht auswählen.
Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" - 
egal, ob ich als CPU den 644p oder den 1284p auswähle.

Hat jemand einen Tipp, was ich falsch mache?

Vielen herzlichen Dank schon mal im Voraus!

Andreas S. schrieb:
> Allerdings kann ich das EMS-Protokoll nicht auswählen.
> Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" -
> egal, ob ich als CPU den 644p oder den 1284p auswähle.
>
> Hat jemand einen Tipp, was ich falsch mache?

Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat 
eine 2. UART.

Danny B. schrieb:
> Andreas S. schrieb:
>> Allerdings kann ich das EMS-Protokoll nicht auswählen.
>> Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" -
>> egal, ob ich als CPU den 644p oder den 1284p auswähle.
>>
>> Hat jemand einen Tipp, was ich falsch mache?
>
> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat
> eine 2. UART.

Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe 
ich den Atmega 644pa in die Liste rein?

Andreas S. schrieb:
> Danny B. schrieb:
>>
>> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat
>> eine 2. UART.
>
> Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe
> ich den Atmega 644pa in die Liste rein?

Mea culpa. Ich nehme alles zurück; der 644p sollte gehen. Die 2. UART 
ist der Unterschied zwischen 644 und 644p, nicht zwischen 644p und 
644pa.

Bei mir geht aber die Konfugiuration auch mit dem 644p: Load a default 
configuration -> NetIO, dann den 644p auswählen, dann unter Protocols -> 
EMS anschalten und '1' als 'EMS USART' auswählen.

Wie genau gehst du bei der Konfiguration vor?

Danny B. schrieb:
> Andreas S. schrieb:
>> Danny B. schrieb:
>>>
>>> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat
>>> eine 2. UART.
>>
>> Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe
>> ich den Atmega 644pa in die Liste rein?
>
> Mea culpa. Ich nehme alles zurück; der 644p sollte gehen. Die 2. UART
> ist der Unterschied zwischen 644 und 644p, nicht zwischen 644p und
> 644pa.
>
> Bei mir geht aber die Konfugiuration auch mit dem 644p: Load a default
> configuration -> NetIO, dann den 644p auswählen, dann unter Protocols ->
> EMS anschalten und '1' als 'EMS USART' auswählen.
>
> Wie genau gehst du bei der Konfiguration vor?

Hallo Danny,

ich habe mir unter CentOS 7 die benötigten Pakete heruntergeladen.
Anschließend habe ich das gitlab-Archiv auf meinen Rechner kopiert.
Anschließend mit make menuconfig gestartet

Dort dann Load a default configuration -> NetIO und als CPU den Atmega 
644p ausgewählt.
Wollte dann unter Protocols das EMS anschalten, jedoch erhalte ich die 
besagte Fehlermeldung, das kein UART frei ist.

Ich könnte mir höchstens vorstellen, das es am OS liegt (CentOS 7)

Hallo Danny,

Entwarnung, habs jetzt mal auf meinem Firmennotebook ausgeführt 
(ebenfalls CentOS 7)
Hier funktionierts jetzt.
Komisch, das es dann auf meinem Werkstatt-PC nicht funktioniert hat.

Vielen herzlichen Dank für deine Unterstützung!

Konnte jetzt alle bis auf eine Einstellung von 
https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io vornehmen.

Das Feld "[-] Onewire device detection support" kann ich leider nicht 
auswählen. Hängt dies evtl. von einer Einstellung ab, die Standardmäßig 
vielleicht ausgewählt ist?

Hast du hier für mich zufällig noch einen kleinen Tipp?

Andreas S. schrieb:
> Konnte jetzt alle bis auf eine Einstellung von
> https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io vornehmen.
>
> Das Feld "[-] Onewire device detection support" kann ich leider nicht
> auswählen. Hängt dies evtl. von einer Einstellung ab, die Standardmäßig
> vielleicht ausgewählt ist?
>
> Hast du hier für mich zufällig noch einen kleinen Tipp?

Nach langem Testen und probieren habe ich jetzt den Blockierer gefunden:

Wenn ich Debugging aktiviere "[*] Enable Debugging  --->" dann kann ich 
die Option auswählen.
Dieser Punkt hatte im Wiki leider gefehlt.

Hallo,

gibt es von der KM271 einen "erfolgreichen" Nachbau?

Chipshuffler hat einen Schaltplan veröffentlicht: 
Beitrag "Re: Logamatic 2107 Schnittstelle"

Die RS232 Schnittstelle ist dort ja nicht das Problem.

Ansonsten würde ich mich daran machen...

Malte war hier auch aktiv, hat seine Versuche zwar in seinem Wiki 
gepostet, ist leider aber nicht mehr online. Wer hier noch Daten hat 
kann  mir gerne zukommen lassen.

Hi zusammen,

Ich hätte ebenfalls Interesse an einem Adapter.
Gibt es noch irgendwelche Aktivitäten?

Viele Grüße und danke

Es wurden doch Fertigungsdaten gepostet, mit diesen wendet man sich an 
den Chinamann seines vertrauens und bekommt für wenige Euronen fertige 
Platinen.

Ja, ja. Platinen machen lassen... Ich habe da auch keine Erfahrung.

Hat jemand eine zu verkaufen? Nackt/bestückt/ wie auch immer?

Danke & Gruß

Hi,
ich hab mir die Platine erstellen lassen - war kein Hexenwerk. Ich bin 
aus Zeitgründen noch nicht dazu gekommen weiter zu machen :-(
Eine Frage in die Runde: Hat sich schon jemand an die Umsetzung mittels 
ESP8266 gemacht?

Ich habe mir damals zwei Platinen machen lassen und eine liegt hier noch 
rum (ohne Wiederstand).

Viele Grüße

Ich habe mir die Platine hier bestellt: 
https://bbqkees-electronics.nl/?lang=de

Preis finde ich ok - es gibt sogar ein komplettpaket mit ESP8266 und der 
EMS-ESP software

Nutze die jetzt seit monaten zusammen mit einem ESP8266 und MQTT

Hallo,

ich weiß, der Thread ist ein wenig älter, aber ich habe noch eine 
Logamatic, die ich noch eine Zeit lang betreiben muss und brauche 
dringend den Zugang über die serielle Schnittstelle, weil mein Brenner 
häufig auf Störung geht (Flammwächter spinnt manchmal) und ich nicht 
jede Woche kalt duschen möchte. Deswegen habe ich mir ein paar aus 
diesem Thread zusammengesucht und die KM217 mit WiFi/Bluetooth-Anbindung 
nachentwickelt und werde diese in den nächsten Wochen auch mit ESPhome 
und Home Assistant realisieren.

Genauere Infos gibt es hier: 
https://the78mole.de/reverse-engineering-the-buderus-km217/

Wer ebenfalls eine haben möchte, kann mich gerne kontaktieren. Ich werde 
ein paar PCBs mehr bestellen und zum Selbstkostenpreis (ich schätze ca. 
2-3 € pro PCB) abgeben.

Grüße,
Daniel

Fred G. schrieb:
> Ich habe mir die Platine hier bestellt:
> https://bbqkees-electronics.nl/?lang=de
>
> Preis finde ich ok - es gibt sogar ein komplettpaket mit ESP8266 und der
> EMS-ESP software
>
> Nutze die jetzt seit monaten zusammen mit einem ESP8266 und MQTT

Ich hab mich grad auf der Seite umgesehen, das ist echt interessant und 
ich würde mir das Modul mit WLAN gern zulegen. Wie krieg ich raus, ob 
meine Steuerung damit kompatibel ist, sprich diese Bus-Schnittstelle 
hat? Weiß jemand von euch das anhand des Fotos?

Gruß - Markus

So siehts im Inneren aus, leider nix von einem BUS Anschluss zu sehen 😒
Was meint ihr?

Am Typenschild steht HS2105M S0

Hallo Marcus,

eigentlich solltest Du im Beitrag auf meinem Blog sehr schön die
Schnittstelle erkennen, die es für das KM217 benötigt (siehe auch Bild
anbei). Der andere Anschluss sieht zwar identisch aus, aber da ist 1.
nicht genug Platz und 2. weiß ich nicht, ob die Belegung die Gleiche
ist.

Auf Deinem Bild ist die Schnittstelle auch zu erkennen, aber ob das die 
gleichen Abmessungen und die gleiche Belegung hat, weiß ich natürlich 
nicht.

Grüße,
Daniel

Daniel G. schrieb:
> Hallo Marcus,
>
> eigentlich solltest Du im Beitrag auf meinem Blog sehr schön die
> Schnittstelle erkennen, die es für das KM217 benötigt (siehe auch Bild
> anbei). Der andere Anschluss sieht zwar identisch aus, aber da ist 1.
> nicht genug Platz und 2. weiß ich nicht, ob die Belegung die Gleiche
> ist.
>
> Auf Deinem Bild ist die Schnittstelle auch zu erkennen, aber ob das die
> gleichen Abmessungen und die gleiche Belegung hat, weiß ich natürlich
> nicht.
>
> Grüße,
> Daniel

Hallo Daniel,

vielen Dank dir für die Erläuterung. Ich dachte, dass ich mit der 
fertigen Lösung von dem Online Shop eventuell auch arbeiten könnte. Aber 
da ich die Schnittstelle nicht habe, brauche ich deine Lösung um Zugriff 
auf die Daten zu bekommen, soweit ist mir das jetzt klar 👍
Ich hatte dir auch schon eine Email geschrieben, dass ich Interesse an 
der Platine von dir habe. Ich nehm auf jeden Fall eine!

Gruß - Markus

Hi Markus,

die Platinen werden gerade produziert und werden vermutlich in ca. 2 
Wochen (wenn der Zoll nicht verlängerte Mittagspause macht) bei mir 
aufschlagen. Hast Du denn die passenden Bauteile alle da, um die Platine 
zu bestücken?

Die BOM findest Du hier:
https://gitlab.com/the78mole/logamatic_2107_wifi_comm/-/blob/main/KM217-WiFi/bom/KM217-WiFi.csv

Grüße, Daniel

Hi Daniel,

perfekt! Meld dich einfach wenn du die Platinen hast dann können wir uns 
wegen Versand und Zahlung austauschen.

Hab nur den EPS32 lagernd 😉 hab bisher maximal SMD 0805 gelötet. Die 
Sachen muss ich also noch besorgen, irgendwie alles komplett bei einem 
Anbieter bestellen geht vermutlich nicht oder?

Gruß - Markus

Hallo Markus,

das Hühnerfutter für den Minimalausbau kann ich Dir noch dazu legen. Die 
MOSFETs (Level-Shifter) sind hoffentlich garnicht nicht nötig und das 
EEPROM ist ja auch nur da, falls man lokal was speichern möchte...

Falls Du Dir ein kleines Sortiment zulegen willst, ich hab vor vielen 
Jahren mit den Family-Packs von CSD 
(https://csd-electronics.de/Passive-Bauteile/Widerstaende/FamilyPacks:::10_57_181.html) 
angefangen, weil ich schon ein modulares, erweiterbares Sortiersystem 
hatte und diesen Röhrchenkram immer gehasst habe.

Grüße, Daniel

Hi Daniel,

das wär natürlich perfekt! Lokal speichern will ich in der Tat nicht, 
EEPROM brauch ich also nicht. Pack die Sachen dazu und ich bezahl die 
natürlich auch!

Bei CSD schau ich mich mal um, da find ich mir bestimmt was 😉

Danke schon mal vorab, hoffentlich kommen die Platinen dann bald...

Gruß - Markus

Hallo Daniel,

falls du noch eine Platine über hast, wäre ich auch an einer 
interessiert - ebenso an dem "Hühnerfutter" :-)

Viele Grüße
Jens

Hallo,

die Platinen sind da und ich hab auch schon eine auf- und eingebaut. 
Spannungsversorgung passt, LEDs kann ich mittels HomeMatic und ESPhome 
ein- und ausschalten. Firmware-Update über OTA funktioniert ebenfalls 
einwandfrei. Jetzt fehlt NUR NOCH die Software, um die serielle 
Schnittstelle in Betrieb zu nehmen, die Buderus-Steuerung zum Reden zu 
bringen und die Daten zu dekodieren :-P

Den Blog-Post habe ich auch nochmal für alle Interssierten aktualisiert:
https://the78mole.de/reverse-engineering-the-buderus-km217/

Die komplette Konfiguration für ESPhome werde ich bei Gelegenheit auch 
noch pushen. Wer mich bei der Software unterstützen will ist jederzeit 
willkommen.

Das Repo findet sich hier:
https://gitlab.com/the78mole/logamatic_2107_wifi_comm

Viel Spaß :-)

PS: Wer eine Platine will, bitte noch die postialische Adresse an mich 
schicken. Entweder per PM oder über Email (findet sich auch im Impressum 
meines Blogs).

Hallo Zusammen!

Vielen Dank an alle die hier mitgeholfen haben, die nötigen 
Protokollinformationen zu erarbeiten.

Falls Interesse besteht, ich habe auf GitHub ein Projekt hochgeladen, 
welches wunderbar zusammen mit der Platine von Daniel funktioniert.
Es liefert alle mir bisher bekannten Werte per MQTT und kann auch einige 
Werte per MQTT Befehle anpassen und steuern.

Ihr findet es hier: https://github.com/dewenni/ESP_Buderus_KM271

Grüße Sven

Hallo Jungs,

ich habe nun fast keine Module mehr und sammele gerade Ideen, die ich 
noch mit umsetzen könnte... Aktuell auf der Liste:

- OneWire Interface connector
- Add-On Connectors (some I/Os, I2C, SPI)

Wer noch gute Ideen hat, die mit den recht generischen beiden Sachen 
nicht abgedeckt sind, einfach hier rein :-)

Grüße,
Daniel

Daniel G. schrieb:
> Hallo Jungs,
>
> ich habe nun fast keine Module mehr und sammele gerade Ideen, die ich
> noch mit umsetzen könnte... Aktuell auf der Liste:
>
> - OneWire Interface connector
> - Add-On Connectors (some I/Os, I2C, SPI)
>
> Wer noch gute Ideen hat, die mit den recht generischen beiden Sachen
> nicht abgedeckt sind, einfach hier rein :-)
>
> Grüße,
> Daniel

Hallo Daniel,

an dieser Stelle einfach mal danke dir für deine Arbeit und Mühen die du 
in dieses Projekt steckst 👍👌
(Hatte fast schon befürchtet, du hast keine Zeit mehr gefunden um an dem 
Projekt weiter zu machen)

Gruß - Markus

Hi Markus,

tatsächlich hatte ich kaum Zeit, deswegen habe ich ja bestückte Platinen 
bestellt. Dass ich dann so viele Bestellung in so kurzer Zeit 
wegarbeiten muss, im Gegenzug aber drei tolle Personen (Sven, Jens, 
Bascht) aus der Community mir dann die Arbeit in der Firmware abnehmen, 
damit hatte ich nicht gerechnet.

Vermutlich werde ich noch vor Weihnachten noch ein paar neue Features in 
die Hardware einarbeiten und dann bestellen.

Ich bin auch echt begeistert, was da für eine Resonanz auf das Projekt 
kam... Ich hatte Bestellungen aus Deutschland, USA, Lettland, Polen, 
Ungarn, Litauen, Belgien, Spanien und Estland. Völlig crazy :-P

Grüße,
Daniel

Das Projekt ist auch für mich hochgradig interessant. Vor einigen 
Monaten war ich schon darauf gestoßen, als ich die Logamatic wegen eines 
defekten Brennerrelais reparieren musste und (mal wieder...) Ausschau 
nach einer Kommunikationskarte hielt.

Grundsätzlich würde ich aber lieber dem bewährten Motto "Wer Funk kennt, 
nimmt Kabel!" folgen, obwohl sich der relevante WLAN-AP direkt über dem 
Heizungskeller befindet. Daher hatte ich auch schon darüber nachgedacht, 
Deine Leiterplattenkontur zu "klauen" und als Grundlage für eine 
Ethernetversion zu verwenden. Ggf. wäre es durchaus interessant, den 
Ethernet-Teil mit IP101 an "Deinen" ESP32 dranzuknüppern, ähnlich wie 
hier:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-ethernet-kit.html

Offenbar scheint ja die Spannungsversorgung von Buderus nicht auf ein 
WLAN-Modul (oder auch Ethernet) ausgelegt zu sein, so ich erwäge, auch 
eine separate Stromversorgung vorzusehen oder zumindest eine höhere 
Spannung an anderer Stelle der Logamatic abzugreifen.

Nachdem mir Altium ein Ultimatum bezüglich einer möglichen 
Wiederaufnahme/Verlängerung von Wartung und Software-Updates gestellt 
hat, ist für mich auch endgültig klar, auf KiCad umzustellen. Somit wäre 
das o.a. ohnehin schon für KiCad vorliegende Projekt auch ein schöner 
Testballon (neben anderen beruflichen und privaten Projekten).

Hallo Daniel,

ein sehr interessantes Projekt :-)
Für mich wäre der OneWire Anschluss sehr interessant - dann würde ich 
mir meine aktuelle Platine für meinen Pufferspeicher + Temperaturen vor 
& nach der Systemtrennung mit 8 x DS18B20 sparen :-) - falls die 
Spannungsversorgung der Logamatic das mitmacht..

Viele Grüße

Hallo Jens,
hallo Andreas,

also mit dem WLAN des ESP32-WROOM-32D hab ich bisher nur gute 
Erfahrungen gemacht, was die Reichweite und Zuverlässigkeit angeht. Der 
Charme liegt ja gerade darin, dass ich keine Leitungen ziehen muss.

Grundsätzlich könnte man aber auch einen ENC28J60 an die 
SPI-Schnittstelle andödeln. Für ESP32 gibt es da durchaus Quellcode.
https://github.com/tobozo/ESP32-ENC28J60
Ethernet (über MII) direkt am WROOM verbrät halt unglaublich viele 
GPIOs.

Bezüglich Spannungsversorgung hatten meines Wissens bisher nur zwei 
Bastler Probleme. Bei den anderen (mehr als 50 Personen) lief alles wie 
am Schnürchen. Und auch bei mir bisher keinerlei Probleme. Ich vermute 
fast, dass bei den beiden Problem-Steuerungen entweder irgendwas 
angeschlossen ist, das viel Saft braucht oder das Netzteil ein 
Montagsmodell ist. Natürlich könnte man auch einen DC/DC verbauen. Der 
würde die Sache sicher deutlich entspannen, verbraucht aber auch wieder 
Platz und kostet deutlich mehr als der kleine LDO. Und die paar zehn 
Milliwatt Verluste sind auch nicht der Rede wert.

Die OneWire-Sensoren ziehen auch praktisch keinen Strom. Würden sie das 
tun, würden sie sich auch selbst zu stark aufheizen, um noch anständig 
zu messen.

KiCad kann ich tatsächlich nur empfehlen. Habe damit nun schon etliche 
Projekte gemacht und wenn man sich an ein paar Regeln hält, dann ist es 
eines der besten PCB-Tools, die ich je verwendet habe. z.B. die 
Original-Bibliotheken per GIT holen und in Ruhe zu lassen, die eigenen 
Symbole und Packages dann in ein eigenes GIT zu stecken. Außerdem sollte 
man für die Pfade entsprechend Variablen definieren.

Mal sehen, ob ich es noch vor Weihnachten schaffe oder dann "zwischen 
den Jahren" dazu komme.

Grüße,
Daniel

Daniel G. schrieb:
> Der
> Charme liegt ja gerade darin, dass ich keine Leitungen ziehen muss.

Der Charme von Ethernet liegt ja gerade darin, dass man bei einem 
Gerätetausch eines Switches nur die Patchkabel umstecken muss. Bei WLAN 
muss man wiederum alle Clients in den neuen Access Point einbuchen, was 
ja gerade bei Geräten ohne eigenes GUI o.ä. mit ziemlicher Bastelei 
verbunden sein kann. Und irgendwelche Smart-Home-Komponenten sind ja 
auch defür prädestiniert, bei solch einer Aktion vergessen zu werden.

Hi Andreas,

wenn man das WLAN gleich konfiguriert sollte alles wie vorher laufen, 
selbst mit Consumer-Geräten. Wenn ich bei mir einen AP tausche oder 
einen neuen dazu hänge, wird der automatisch provisioniert und alle 
Clients können den wie gehabt nutzen.

Wer Ethernet haben möchte, der kann meine "bare PCB-Variante" und einen 
Raspi oder irgend einen anderen Ethernet-UART-Konverter kaufen. Den 
wenigen noch verfügbaren Platz auf dem Board nutze ich lieber für andere 
Dinge als einen Ethernet-Anschluss (Stecker, Übertrager, Hühnerfutter), 
den gerade mal 1% der Interessenten nutzen will. Zumal der ESP ja gerade 
für WLAN (und vielleicht noch Bluetooth) prädestiniert ist.

Grüße,
Daniel

Daniel G. schrieb:
> Den
> wenigen noch verfügbaren Platz auf dem Board nutze ich lieber für andere
> Dinge als einen Ethernet-Anschluss (Stecker, Übertrager, Hühnerfutter),
> den gerade mal 1% der Interessenten nutzen will.

Genau, das verlange ich ja auch gar nicht. Oben hatte ich ja 
geschrieben, dass ich vermutlich Deine Leiterplattenkontur usw. für 
meine eigene Variante verwenden werde. Sofern ein Interesse besteht, 
wäre ich dann durchaus auch bereit, das ganze wieder zuveröffentlichen, 
ggf. auch in einem gemeinsamen Git-Repository.

> Zumal der ESP ja gerade
> für WLAN (und vielleicht noch Bluetooth) prädestiniert ist.

In der Tat wäre er - ohne "Projektaltlasten" nicht der Controller erster 
Wahl, wenn man WLAN gar nicht nutzen will.

Hi Andreas,

gerne kannst Du das Design nutzen und Dein eigenes veröffentlichen. Ich 
verlinke natürlich auch gerne Dein Repo auf meinen Seiten (GitLab, 
GitHub, mein Blog,...) und würde mich auch freuen, wenn Du mich 
umgekehrt verlinkst.

Grüße,
Daniel

Hallo zusammen,

meine Platine ist heute angekommen 👍👌😁

Ich gerade dabei, die Version von Sven auf das Modul zu laden. Das 
klappt soweit auch, allerdings bootet das Modul dann nicht mehr. Die 
LEDs leuchten auch nicht mehr. Im Serialmonitor seh ich nur, dass das 
Modul in einer Bootschleife hängt:

1

Brownout detector was triggered

2

3

ets Jun  8 2016 00:22:57

4

5

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)

6

configsip: 0, SPIWP:0xee

7

clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

8

mode:DIO, clock div:2

9

load:0x3fff0030,len:1184

10

load:0x40078000,len:13132

11

load:0x40080400,len:3036

12

entry 0x400805e4

13

14

Brownout detector was triggered

15

16

ets Jun  8 2016 00:22:57

17

18

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)

19

configsip: 0, SPIWP:0xee

20

clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

21

mode:DIO, clock div:2

22

load:0x3fff0030,len:1184

23

load:0x40078000,len:13132

24

load:0x40080400,len:3036

25

entry 0x400805e4

Das wiederholt sich ständig. Jemand eine Idee, wo das Problem liegt?

Gruß - Markus

Kommt der Brownout weil das Modul momentan nur an der seriellen 
Schnittstelle des Rechners hängt? Sprich: muss das Modul zur 
Inbetriebnahme im Sockel der Heizungssteuerung stecken?

Okay, in meiner Teststeuerung leuchten jetzt mal alle LEDs und kurz ist 
das Modul auch mit WLAN verbunden. Bricht aber nach einiger Zeit ab und 
connectet sich dann neu.
Was mach ich noch falsch? Muss an den Jumperleisten noch was umgesteckt 
werden? Hab ich so gelassen, wie sie im Lieferzustand waren.

Das könnte an einer nicht funktionierenden MQTT Verbindung liegen.
Es ist im Code so implementiert, dass bei WiFi und MQTT 5 
Verbindungsversuche mit jeweils 5s Abstand erfolgen. Nach 5 erfolglosen 
Versuchen sich mit dem WLAN oder MQTT Server zu verbinden, macht der ESP 
einen Restart.
WiFi und MQTT müssen also funktionieren.

Und du brauchst den Jumper auf P4 damit die Logamatic die Platine 
erkennt. Der Jumper fehlte bei mir im "Auslieferungszustand"

Die nötigen Jumper kannst du hier vergleichen: 
https://github.com/dewenni/ESP_Buderus_KM271/wiki/1.-Hardware-Setup

Sven T. schrieb:
> Und du brauchst den Jumper auf P4 damit die Logamatic die Platine
> erkennt. Der Jumper fehlte bei mir im "Auslieferungszustand"
>
> Die nötigen Jumper kannst du hier vergleichen:
> https://github.com/dewenni/ESP_Buderus_KM271/wiki/1.-Hardware-Setup

Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌

Hi Markus,

> Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌

Falls Du weiter Probleme mit Brown-Out hast, in seltenen Fällen (bisher 
2 von 70) scheint die Buderus aus unerfindlichen Gründen eine schwache 
Stromversorgung zu haben. Kann sein, dass da irgendwelche 
Zusatzkomponenten drin sind, die mehr Strom ziehen. Bei mir funktioniert 
das Modul nun seit Monaten in diversen Entwicklungsstufen einwandfrei. 
Nur anfangs hatte ich noch Probleme, als auf der 3,3V-Schiene zu wenig C 
(nur 100 nF) verbaut war. Auch die neueste Stufe mit den Level-Shiftern 
auf der seriellen Schnittstelle zum Buderus, wie ich sie auch verkaufe, 
läuft ohne einen einzigen Aussetzer.

Um dem Problem auf den Grund zu gehen, kannst Du einfach mal den 
5V-Jumper raus nehmen und das Modul mit 3,3V über die 
Programmierschnittstelle versorgen. Da eignet sich auch der 
USB-seriell-TTL-Adapter gut, wenn dieser 3,3V zur Verfügung stellt 
(Achtung: Keine 5V, die könnten den ESP beschädigen).

Wenn es dann funktioniert würde mich brennend interessieren, woran das 
liegt :-)

Ursache gefunden! Ich habe meinen mqtt Server auf einem anderen Port 
laufen und in deinem Code war der Port 1883 fest vorgegeben.
Ich habe die Credentials.h um die Angabe

1

#define MQTT_PORT 1884

erweitert sowie die mqtt.cpp geändert

1

mqtt_client.setServer(MQTT_SERVER, MQTT_PORT);

Damit funktioniert der Aufbau der Verbindung auf Anhieb. Danke nochmal 
für deinen Hinweis 👍🙋‍♂️

prima, dann nehme ich das mal noch mit auf.
Sowohl im Code als auch in der Beschreibung.

Daniel G. schrieb:
> Hi Markus,
>
>> Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌
>
> Falls Du weiter Probleme mit Brown-Out hast, in seltenen Fällen (bisher
> 2 von 70) scheint die Buderus aus unerfindlichen Gründen eine schwache
> Stromversorgung zu haben. Kann sein, dass da irgendwelche
> Zusatzkomponenten drin sind, die mehr Strom ziehen. Bei mir funktioniert
> das Modul nun seit Monaten in diversen Entwicklungsstufen einwandfrei.
> Nur anfangs hatte ich noch Probleme, als auf der 3,3V-Schiene zu wenig C
> (nur 100 nF) verbaut war. Auch die neueste Stufe mit den Level-Shiftern
> auf der seriellen Schnittstelle zum Buderus, wie ich sie auch verkaufe,
> läuft ohne einen einzigen Aussetzer.
>
> Um dem Problem auf den Grund zu gehen, kannst Du einfach mal den
> 5V-Jumper raus nehmen und das Modul mit 3,3V über die
> Programmierschnittstelle versorgen. Da eignet sich auch der
> USB-seriell-TTL-Adapter gut, wenn dieser 3,3V zur Verfügung stellt
> (Achtung: Keine 5V, die könnten den ESP beschädigen).
>
> Wenn es dann funktioniert würde mich brennend interessieren, woran das
> liegt :-)

Hi Daniel,

ich habe den Jumper gezogen, hat aber keinen Unterschied gemacht! In der 
seriellen Konsole kamen trotzdem die Brownout Meldungen. Steckt das 
Modul aber in der Steuerung, läuft das ganze ohne Aussetzer!
Die nächsten Tage werden dann zeigen, wie stabil es läuft. Sehe aber 
auch keine Einschränkungen hinsichtlich der Stabilität.

Gruß

Hi Markus,

> ich habe den Jumper gezogen, hat aber keinen Unterschied gemacht! In der
> seriellen Konsole kamen trotzdem die Brownout Meldungen. Steckt das
> Modul aber in der Steuerung, läuft das ganze ohne Aussetzer!
> Die nächsten Tage werden dann zeigen, wie stabil es läuft. Sehe aber
> auch keine Einschränkungen hinsichtlich der Stabilität.

Achso, der Programmieradapter liefert nicht genug Saft... Na dann bringt 
Jumper-Ziehen natürlich wenig. Der trennt den LDO ja nur auf der 
5V-Seite ab. Die Ausgangsseite ist immer verbunden, sollte aber nicht 
viel ausmachen, wenn man "von hinten" versorgt.

Wenn Du die Situation öfter hast, dass Du außerhalb der Buderus was 
testen willst, dann solltest Du evtl. über den Debug-Header die 5V z.B. 
von USB versorgen.

Grüße,
Daniel

Daniel G. schrieb:
> Wenn Du die Situation öfter hast, dass Du außerhalb der Buderus was
> testen willst, dann solltest Du evtl. über den Debug-Header die 5V z.B.
> von USB versorgen.
>
> Grüße,
> Daniel

Ich hab auch noch andere Adapter, mit verschiedener Bauart. Ich teste 
einfach mal mit einem anderen. Aber das ist für mich auch nicht wirklich 
entscheidend, die Programmierung läuft sauber und in der Steuerung 
funktioniert dann auch alles 👍

Was mir gestern auf die Schnelle aufgefallen ist: die ganzen Stati der 
Werte beziehen sich immer nur auf den Heizkreis 1. Bei mir an der 
Teststeuerung als auch an der "richtigen" Steuerung ist Heizkreis 2 
aktiv. Warum weiß ich ehrlich gesagt nicht. Kann ich dann damit 
überhaupt meine Steuerung ansprechen sprich auch den Heizkreis 2 
abfragen und steuern?

Gruß - Markus

Ich habe jetzt die Doku zu meiner HS 2105M gewälzt und rausgefunden, 
warum da HK2 aktiviert ist. Weil nur am HK2 der Mischerbetrieb möglich 
ist.
Auf meiner Teststeuerung habe ich nun HK1 aktiviert und kann auch per 
Befehl die Einstellungen steuern, funktioniert perfekt. Aber eben nur 
für den HK1.

Hab ich mit der Lösung eine Chance die Daten von HK2 irgendwie 
abzugreifen? Anscheinend müsste hier die Protokollauswertung erweitert 
werden oder?

Sven: funktioniert bei dir das Uhrzeit stellen? Macht bei mir gar nix 
wenn ich den Befehl per mqtt absetze.

Das Uhrzeit Stellen hat an meiner Logamatic 2107 funktioniert.
Es wird dann die Uhrzeit gesetzt, die per NTP Server ermittelt wurde.
Die Uhrzeit die im ESP aktuell verwendet wird, siehst du auch in der 
WiFi Struktur die per MQTT gesendet wird.
Möglicherweise hat die HS 2105M aber auch andere Adressen dafür. Das 
kann ich nicht sagen.

Bezüglich HK1 und HK2:
Ich habe mich bei der Software auf HK1 konzentriert, weil ich nur den 
HK1 habe und mich die Werte von dem nicht vorhandenen HK2 nicht 
interessiert haben.

Natürlich könnte man den HK2 auch noch mit dazu nehmen und es ggf. 
konfigurierbar machen.
Dokumentiert ist der HK2 hier auch:
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/00_KM271.pm

Der Aufwand dürfte sich in Grenzen halten. Ich kann dir aber nicht 
versprechen das ich das kurzfristig schaffe. Muss mal schauen. 
Vielleicht am kommenden Wochenende.

Grüße Sven

Sven T. schrieb:
> Das Uhrzeit Stellen hat an meiner Logamatic 2107 funktioniert.
> Es wird dann die Uhrzeit gesetzt, die per NTP Server ermittelt wurde.

Ich würde das ganze sogar fast umkehren und die Logamatic als Zeitserver 
verwenden. Ich fragte mich übrigens jahrelang, warum das Datum und die 
Uhrzeit immer korrekt waren. Erst bei der diesjährigen Renovierung 
unseres Wohnzimmers öffnete ich die Fernbedienung und entdeckte darin 
den DCF-77-Empfänger.

Hat eigentlich jede 2107-basierte Heizungsanlage einen DCF-77-Empfänger?

Hallo Andreas,

> Hat eigentlich jede 2107-basierte Heizungsanlage einen DCF-77-Empfänger?

Also meine sicherlich nicht :-P

Es gäbe aber auch noch eine andere Variante, wie man eine sehr genaue 
Zeitbasis haben kann: Die 50 Hz Netzfrequenz. Früher wurde die mal genau 
nach Atomuhr ausgeregelt. Heute ist das aber meines Wissens nicht mehr 
so scharf, aber vermutlich noch immer besser als jeder billige 
Uhrenquartz.

Übrigens, in "meiner" ESPhome-Variante ist auch HK2 bereits zum größten 
Teil integriert, allerdings sind wir in anderen Bereichen noch nicht so 
weit wie Sven.

Grüße,
Daniel

Sven T. schrieb:
> Natürlich könnte man den HK2 auch noch mit dazu nehmen und es ggf.
> konfigurierbar machen.
> Dokumentiert ist der HK2 hier auch:
> https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/00_KM271.pm

Danke für den Link! Ich schau da mal selber und versuche, die Werte 
selber einzubauen. Denke dass ich da viel spicken kann. Muss ja nicht 
immer nur einer die ganze Arbeit machen 🤣😉

Das mit der Uhrzeit ist auch ned so tragisch, nützlich wäre es halt. 
Aber erstmal ist der HK2 für mich wichtiger, sonst bringt mir das ganze 
Projekt nicht viel.

Grüße - Markus

Daniel G. schrieb:
> Es gäbe aber auch noch eine andere Variante, wie man eine sehr genaue
> Zeitbasis haben kann: Die 50 Hz Netzfrequenz.

Es wäre mir neu, dass auch die Uhrzeit über die Netzfrequenz übertragen 
wird. Das ganze taugt eben nur als Frequenznormal und nicht als 
Zeitnormal.

> Früher wurde die mal genau nach Atomuhr ausgeregelt.

Offenbar verwechselst Du die Netzfrequenz mit der Zeilenfrequenz der 
analogen öffentlich-rechtlichen Fernsehsender.

Bezüglich der Netzfrequenz werden jedoch nach wie vor die 
Einzelschwingungen aufsummiert und nach Möglichkeit im Laufe einiger 
Monate so weit ausgeglichen, dass sich der Fehler 
netzfrequenzsynchronisierter Uhren nicht immer weiter kumuliert, sondern 
auf insgesamt nur einigen Minuten begrenzt bleibt.

> Heute ist das aber meines Wissens nicht mehr
> so scharf, aber vermutlich noch immer besser als jeder billige
> Uhrenquartz.

Genau das trifft auf die Zeilenfrequenz zu. Wie die Synchronisation 
aller Fernsehsender, die bei DVB-x zu einem Bouquet gebündelt werden, 
ist mir aber nicht bekannt. Früher(tm) lief ja die gesamte 
Produktionskette streng synchron, d.h. vom primären Frequenz- und 
Timinggenerator bis hin zu den Studiokameras. Dadurch konnte man dann 
auch mit sehr wenig Aufwand zwischen verschiedenen Kameras auch weich 
überblenden.

Irgendwann gab es dann sog. digitale Time Base Correctors, d.h. 
Bildspeicher, mit denen sich Phasen- und Frequenzunterschiede 
asynchroner Videoquellen wieder ausbügeln ließen.

Lieber Daniel,
Deine Platine habe ich diese Woche erhalten, super! Am Wochenende kommt 
mit der Installation der Moment der Wahrheit...

Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu 
haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht 
mehr.

Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?

Achim

Achim W. schrieb:
> Lieber Daniel,
> Deine Platine habe ich diese Woche erhalten, super! Am Wochenende kommt
> mit der Installation der Moment der Wahrheit...
>
> Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu
> haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht
> mehr.
>
> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?
>
> Achim

Hi Achim, ich glaub das war mal in einer der ersten Versionen der 
Platine. Habe meine vor ein paar Tagen bekommen, die passte ohne 
Anpassung in den Slot!

Gruß

So, ich habe den Heizkreis 2 jetzt in meinem Code ergänzt.
Sowohl bei den Config Werten als auch bei den Status Werten und den 
Befehlen.

https://github.com/dewenni/ESP_Buderus_KM271

Markus: es wäre gut wenn du das mal testen könntest und mir Rückmeldung 
geben würdest ob es funktioniert.

Hallo Achim,

> Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu
> haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht
> mehr.
>
> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?

Das ist Vergangenheit (Version 0.0.1). Die 0.0.5 sollte perfekt passen. 
Zumindest hat sie das bei mir und gehört habe ich auch nichts mehr :-)

Grüße,
Daniel

Sven T. schrieb:
> So, ich habe den Heizkreis 2 jetzt in meinem Code ergänzt.
> Sowohl bei den Config Werten als auch bei den Status Werten und den
> Befehlen.
>
> https://github.com/dewenni/ESP_Buderus_KM271
>
> Markus: es wäre gut wenn du das mal testen könntest und mir Rückmeldung
> geben würdest ob es funktioniert.

Hallo Sven,

vielen Dank für deine Arbeit 👌 Ich war auch schon fast fertig bzw. war 
grad beim testen. Ich habe mir deine neue Version gezogen und getestet. 
Funktioniert soweit ich es getestet habe alles wie gewünscht! Lediglich 
Uhrzeit stellen mag er immer noch nicht?!? Was mir dabei auffällt, da 
kommt auch keine Bestätigungsnachricht zurück. Wenn ich z.B. die 
Betriebsart ändere, dann kommt eine received Bestätigung zurück. Bei der 
Uhrzeit aber nicht. Oder ist das doch eine Registersache?

Gruß - Markus

Okay - ich hab den Fehler gefunden wegen der Uhrzeit! 😂🤣
Ein Blick in die mqtt.cpp hat mir verraten, dass das Topic so aussehen 
muss:
/esp_heizung/cmd/setdatetime

Bei dir im Github stehts anders:
esp_heizung/setvalue/setdatetime

Kannst du ja mal bei Gelegenheit ändern. Andererseits schadet es nicht, 
dann geht man auch mal selber auf die Suche und ruht sich nicht auf der 
Arbeit anderer aus. 😁😉

Nochmals vielen Dank an dich für deine viele Arbeit!

Gruß - Markus

perfekt, genau das habe ich auch gerade festgestellt.

Dann ändere ich das im Code am besten auch mal auf "setvalue".

Am besten schicke ich auch in der Antwort dann Uhrzeit und Datum mit 
zurück:

message: datetime set to: 17.12.2022 - 16:07:35

Sven T. schrieb:
> perfekt, genau das habe ich auch gerade festgestellt.
>
> Dann ändere ich das im Code am besten auch mal auf "setvalue".
>
> Am besten schicke ich auch in der Antwort dann Uhrzeit und Datum mit
> zurück:
>
> message: datetime set to: 17.12.2022 - 16:07:35

Supi! Habe das Modul gerade in meine produktive Steuerung eingebaut. 
Funktioniert super und die gelieferten Werte passen auch alle. Jetzt 
muss ich das alles noch in mein NodeRed reinbasteln und die Märsche in 
den Keller runter sind Vergangenheit! 👌

Geniales Projekt - sowohl Hardware als auch Software.

so, ist geändert auf "/setvalue/setdatetime"

und als Antwort kommt: "message: date and time set to: 17.12.2022 - 
16:22:28 - DST:0"

DST zeigt an ob das Sommerzeit Flag in der Logamatic gesetzt wurde

Falls sonst noch was auffällt oder Wünsche bestehen, bitte melden.
Entweder hier oder als "Issue" im GitHub.

Sven T. schrieb:
> Falls sonst noch was auffällt oder Wünsche bestehen, bitte melden.
> Entweder hier oder als "Issue" im GitHub.

Ja mir ist jetzt tatsächlich noch was aufgefallen! In der km271.cpp hast 
du in den Abschnitten für den Hk2 die mqtt Topics von HK1 kopiert und 
dann den Text nicht geändert. So werden jetzt auch bei HK2 alle 
Statusmeldungen als HK1 ausgeliefert.

Oh man, danke!
Ich habe es geändert und im GitHub aktualisiert.

Daniel G. schrieb:
[...]
>> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?
>
> Das ist Vergangenheit (Version 0.0.1). Die 0.0.5 sollte perfekt passen.

Hallo Daniel, hallo Leute,
die Platine passt, super!

Nach Einbinden ins Haus-WLAN und ESPHome/Homeassistant kamen auch 
plausible Werte, aber nur kurzzeitig. Nach kurzer Zeit keine Werte mehr.
Ich habe noch versucht die YAML anzupassen (im Abschnitt ESPHome oder 
Configuration.yaml?). Jedenfalls war dann ein Ausrufezeichen beim 
km271-for-friends. Dann noch das Modul dort "gelöscht" und jetzt komme 
ich an nichts mehr ran. Auch nicht über den FallbackHotspot.
Bislang habe ich nur mit ESP32DevKits gearbeitet und musste vorhin 
erstmal einen Programmer ordern.

Dann gibts eine neue Firmware drauf für einen definierten Zustand --> 
damit alles auf Anfang.

Schönen 4. Advent

Achim

Kleine Ergänzung, bisserl OT:

Ich habe mit einem ESP32 Devkit, einem Ultraschall-Entfernungssensor und 
einem selbstgedruckten Gehäuse ein Projekt für einen Ölstandssensor im 
ESPHome/Homeassistant nachgebaut. Läuft seit 10 Monaten einwandfrei in 
einem Schütz-Öltank.

Link zum Projekt und herzlichen Dank an den Projektersteller: 
https://forum.iobroker.net/topic/30434/%C3%B6lstandsmesser-selfmade

Achim

Achim W. schrieb:
[...]>
> Dann gibts eine neue Firmware drauf für einen definierten Zustand -->
> damit alles auf Anfang.

Kleiner Erfahrungsbericht, eher ESPHome/HomeAssistant bezogen:
1. möglicherweise war das km271-for-friends-Modul von Daniel von mir 
nicht sauber im Steckplatz eingerastet, wäre ein Grund für die 
ausbleibenden Werte (hat aber grün geblinkt);
2. neu Flashen ging nur mit ESPTool.exe (Windows 11, HomeAssistant ohne 
SSL, bin-File aus den Repos);
3. das ESPHome-Addon in HA hat dann fortwährend Devices als "adoptable" 
gezeigt, ohne dass das funktioniert hätte. Händisches Einbindungen des 
neu geflashten und ins WLAN eingebundenen km271-for-friends führte zu 
einem Gerät ohne Entities. Mein ESP32-Ölstandsmesser (siehe Post drüber) 
funktionierte nach stundenlangem rumtüfteln auch nicht mehr;
4. testweise eine Homeassistant in einem Dockercontainer gestaret. Zwar 
keine Addons, aber sofortige Einbindung des ESP32-Ölstandsmessers UND 
des km271-for-friends und Anzeige der Werte im Dashboard.

Kleines Problem: die Abgastemperatur ist nicht plausibel und steht 
ohne Brennertätigkeit bei 255°C, bei Brennertätigkeit sind niedrige 
einstellige °C Temperaturen. So als wäre der Wert umgekehrt. Habt ihr 
das auch? Das Bild in der Anlage zeigt die UNterschiede. Bei den 
niedrigen Temperaturen war der Brenner in Betrieb, bei 255 °C nicht.

ToDo:
--> ursprüngliche Homeassistant-Installation auf einem Raspi muss wohl 
neu aufgesetzt werden, denn leider fehlen im HA-Container die 
Add-On-Möglichkeiten für DeConz - für mich essentiell.
--> heute nicht mehr

Achim

@Sven T.:

Hi Sven,

nachdem ich mit Verzückung deine Aktualisierungen heute gesehen habe, 
wollte ich diese gleich nutzen. Nachdem Upload der Version kam aber 
schnell die Ernüchterung! Nachdem ich gesehen habe, dass sowohl die 
WLAN-Verbindung als auch die mqtt-Verbindung ständig abbrechen, vermute 
ich dass der ESP mit der Version ständig einen Reboot macht. In der 
kurzen Zeit mit WLAN Verbindung kamen nur die wifi und die info Message 
rein, sonst nichts. Das aktivierte debug spuckte folgendes aus:

1

03_00_01_09_44_55_82_ba

Ich hab jetzt wieder die v1.0.0 drauf, mit der läuft alles stabil. Keine 
Aussetzer bei WLAN als auch am mqqt-Broker.

Bei dir läuft das stabil nehme ich mal an oder? Hat sonst jemand die 
aktuelle Version getestet?

Gruß - Markus

Hallo Markus,

evtl. wäre es geschickter, Probleme als Issue auf GitHub zu posten... 
Dieser Thread ist ohnehin schon viel, viel zu lang ;-)

Grüße,
Daniel

Hallo Markus,

danke für das Feedback, auch wenn es nicht erfreulich ist.
Ja bei  mir läuft die neuste Version natürlich.

Der Hinweis mit der der letzten empfangenen Debug Message hilft mir auch 
schon mal weiter.
Die 03 00 ist der erste von den 4 Fehlereinträgen aus der Logamatic die 
ich zuletzt noch ergänzt habe.

1

03 00 ...

2

03 07 ...

3

03 0e ...

4

03 15 ...

Ich habe das anhand dem FHEM Code umgesetzt.
Ein von mir provozierter Fehler liefert dann z.B. folgende Nachricht:

1

03_00_31_13_2a_00_13_2a_04_00_00

1

03_00 = erster Eintrag

2

31 = "Kesselvorlauffuehler defekt"

3

13 = 19 Uhr

4

2a = 42min

5

00 = Tage (muss später addiert werden)

6

13 = 19 Uhr

7

2a = 42min

8

04 = 4 Tage

Ergebnis:
Kesselvorlauffuehler defekt (>> 19:42 -4 Tage | << 19:42 -4 Tage)

Wenn ich mir aber deine Nachricht anschaue, dann passt das nicht:

1

03_00_01_09_44_55_82_ba

Das geht schon bei der Fehlerummer "01" los. Die ist gar nicht 
definiert.

1

0 => "Kein Fehler",

2

2 => "Aussenfuehler defekt",

3

3 => "HK1-Vorlauffuehler defekt",

4

4 => "HK2-Vorlauffuehler defekt",

5

....

Könnte also sein das die HS 2105M hier etwas anders funktioniert bzw. 
andere Werte liefert.

Wäre schön wenn du nochmal was testen könntest.
Nimm nochmal den letzten Stand und kommentiere die Stellen mit den 4 
Fehlermeldungen aus.

In der km271.cpp

vor der ersten case mit 0x0300 bis nach der case 0x0315

1

/*

2

case 0x0300: // 0x0300 : Error Buffer 1                               

3

...

4

case 0x0307: // 0x0307 : Error Buffer 2                               

5

...

6

case 0x030e: // 0x030e : Error Buffer 3                               

7

...

8

case 0x0315: // 0x0315 : Error Buffer 4  

9

10

*/

Lade aber bitte nochmal den aktuellsten Commit runter den ich gerade 
eben hochgeladen habe. Dort habe ich die Anzahl der Elemente in der 
Debug Nachricht wieder erhöht. Versionsnummer ist die v1.3.2

Schick mir dann bitte mal den Inhalt aller 4 Fehlermessages:

1

03 00 ...

2

03 07 ...

3

03 0e ...

4

03 15 ...

Dann schauen wir mal weiter. Einerseits sollte egal welcher Inhalt nicht 
zu einem Absturz führen. Da muss ich meinen Code dann nochmal prüfen. 
Andererseits hätte ich gedacht das die Nachrichten auch bei der HS 2105M 
so aufgebaut sind wie bei einer R2107.
Aber schauen wir dann mal.

Grüße Sven

Hallo zusammen,

wir (jensg, qschneider, the78mole) haben im Rahmen meines KM271-WiFi-Projektes mal die Parameter der Logamatic M2107 zusammengetragen und in ein Spreadsheet gepresst:

https://docs.google.com/spreadsheets/d/1W-oVek6CUZ5GJo_8_TkeF2YykQjmGvg-QrWh0w_4kFQ/edit?usp=sharing

Evtl. hilft das dem Ein- oder Anderen für seine Implementierung z.B. in FHEM oder Arduino/MQTT. Es ist zwar noch nicht 100%-ig komplett und sicher ist noch der ein oder andere fehler versteckt, aber daran lässt sich ja arbeiten :-)

Grüße, Daniel (the78mole)

Gernot schrieb:

Hallo, ich kann gerne detaillierte Fotos vom M404 Modul bereitstellen.

Das ist ein Foto vom gesamten Modul. Es wird immer nur in einen Platinen-Stecker auf der Ecomatic 4000 (HS4201) Haupt-Platine eingesteckt. Gernot

Hallo Gernot,

wozu soll denn die M404 überhaupt gut sein? Ist das einfach ein Kommunikationsmodul wie die Original-KM271 für eine andere Buderus-Steuerung?

EDIT: Found your comment on my blog :-)

Sorry to say, but since I don't have your logamatic unit, it is almost impossible to do all the engineering for another control unit. I think, the easiest way is to:

• attach a USB-RS485-cable to the comm-module to see if the Logamatic is talking a similar protocol than my one

If this is successful, attach an ESP32 with a RS485-Converter to the header of your communication module.

And if this also succeeds, I could give it a try to reverse engineer the remaining parts and build a PCB for the HS4201.

Cheers, Daniel (the78mole)

Hallo Daniel, ja, das KM404 ist für die Ecomatic 4000 das Kommunikationsmodul. So wie das KM271 für die Logamatic 2107. Die Buderus Ecomatic 4000 (meine Heizung ist Baujahr 1996) ist sozusagen die Vorgänger-Generation. Das Kommunikationsmodul "M404 / KM2.0" ist nur sehr selten verkauft worden.

EDIT: Yes, i will try to connect the M404 module via RS232 or RS485 and check the communication protocol.

I will keep you updated...

Fingers crossed :) Grüße, Gernot

Hi Gernot,

oh yes, I'm so, so, so looking forward to the results... If your control unit speaks the same "ugly language" like mine, then the chances are good, that we can attach many more Buderus control units and maybe even the newer ones.

Regards, Daniel

Heute ist das KM2.0 M404 Kommunikationsmodul eingetroffen. Als erstes habe ich die Kontakte des Platinen-Stecker ausgemessen und die Signale anhand der IC-Datenblätter ermittelt. Bisherige Erkenntnisse siehe Foto.

Gernot

Heute ist das KM2.0 M404 Kommunikationsmodul über RS232 (mit 2400 Baud) an eine ESP8266 angeschlossen und über den UART die Kommunikation im Debugger-Log angeschaut. Es wird von der Steuerung regelmäßig "\x02" ausgegeben. Wenn darauf "\x10" gesendet wird antwortet die Steuerung mit "\b\x03\x85\x10\x03\x9D" oder "\x11\x05:\x10\x03=" oder "a\x16\xFE\x10\x03\x9A" oder "B\x0F!\x10\x03"

Kann jemand erkennen, ob die Kommunikation die selbe ist wie beim KM271 Modul. Gruß Gernot

Hallo Gernot,

das sieht ganz stark nach dem 3964R-Protokoll aus, das auch die KM271 verwendet. Allerdings wird es sicher einige kleine Unterschiede in den Parametern geben. Aber das ist dann auch schon fast trivial und hauptsächlich Fleißarbeit: An der Steuerung umstellen und beobachten, was über die Schnittstelle kommt...

Ich denke, die schnellste Vorgehensweise wäre, unsere KM271-Komponente für ESPhome zu nehmen und erst mal alles aus der YAML rauszuwerfen und dann ins Log zu schauen. Ich vermute aber, der ESP8266 ist schnell an seinen Grenzen, aber für erste Versuche könnte es reichen.

Grüße, Daniel

Hallo Daniel, danke für die rasche Rückmeldung. Das hört sich gut an :) Für die weiteren Versuche habe ich mir schon einen ESP32 D1 Mini bestellt. So wie du angeraten hast, hatte ich eh vor mit eurer KM271-Komponente weiterzumachen. Die externe Beschaltung des ESP32 wird mit dem nötigsten ausgeführt - nach Vorlage der KM271-WiFi Karte. Gruß Gernot

Hallo Gernot,

genau. Und im YAML einfach erst mal nur die Sections angeben, ohne Verweis auf die Datenpunkte. Leider gibt es einen fehler, wenn man die Sections (button, number,...) weg lässt (zumindest war das noch vor ein paar Tagen so).

1

esphome:

2

  name: buderus-km217

3

  platform: ESP32

4

  board: esp32dev

5

6

# Enable logging

7

logger:

8

9

# Enable Home Assistant API

10

api:

11

12

ota:

13

  password: "<blahblah>"

14

15

wifi:

16

  ssid: !secret wifi_ssid

17

  password: !secret wifi_pass

18

19

uart:

20

  id: uart_bus

21

  tx_pin: GPIO2

22

  rx_pin: GPIO4

23

  baud_rate: 2400

24

25

external_components:

26

  - source: github://the78mole/esphome_components@main

27

    components: [ km271_wifi ]

28

29

km271_wifi:

30

  - id: budoil

31

    uart_id: uart_bus

32

33

text_sensor:

34

  - platform: km271_wifi

35

    firmware_version:

36

      name: "Firmwareversion Steuerung"

37

38

button:

39

number:

40

select:

41

binary_sensor:

42

sensor:

43

switch:

Und dann anfangen, die einfachen Datenpunkte einzubauen...

Grüße, Daniel

Hallo Daniel, inzwischen habe ich die Kommunikation über die RS232-Schnittstelle zum Laufen gebracht und die gesendeten Daten mit protokolliert. Aus der Analyse der Daten konnte ich ein paar erste Codes von Temperatur-Messwerten herausbekommen. Das ist echt eine Fleißarbeit... Gruß Gernot

Hi Gernot,

die ganzen Parameter und möglichen Settings kannst Du Dir ganz einfach aus dem Code des KM271-Moduls rausziehen. Wir werden das demnächst auch noch etwas ausführlicher dokumentieren...

Grüße, Daniel

Hallo, inzwischen habe ich ein paar weitere Codes für Ist- und Soll-Temperaturen, sowie die Bedeutung ein paar Bits aus einem regelmäßig gesendeten Staus-Codes aus dem Datenprotokoll der HS4201 Steuerung entschlüsseln können und diese in Home-AssistAnt eingebunden. Die Codes der Ecomatic 4000 HS4201 Steuerung sind leider komplett anders und weniger Strukturiert als die Codes der Logamatic Steuerung. Gruß Gernot

Hallo Jungs,

mir ist noch nicht ganz klar, was die Schnittstelle an Funktionen bietet. Mein Use Case wäre, die Heizkurve bequem auf der Couch mit dem Notebook auf dem Schoss einzustellen. Laut Bedienungsanleitung geht das ja nur mit der Kugelschreibermethode am Gerät.

Gruß Matthias

Hallo Matthias,

Du kannst über die Raumsolltemperatur (Parallelverschiebung) und die Auslegungstemperatur (Steigung) die Heizkurve bequem über das SmartHome verstellen, zumindest für alle Firware-Varianten, die ich kenne, die auf meinem Modul laufen. Leider bin ich aktuell leer-geräubert und werde frühestens im September wieder eine Charge der KM-271-ESP32-Module bestellen. (Verfügbar dann etwa einen Monat später).

Unbestückte Platinen hätte ich noch ein paar wenige in der Schublade.

Grüße, Daniel

Hallo Daniel,

unbestückte Platine würde reichen. Hast Du einen Link auf Dein Projekt zwecks Aufbau und Inbetriebnahme? Gibts eine "API"-Beschreibung zu den verfügbaren Funktionen?

Gruß Matthias

Hallo Matthias,

muss mich kurz fassen, Urlaub ist stressig 🤣... Hier solltest Du alles finden: https://the78mole.de/projects/km271-wifi-howto/, auch die Links zu GitLab und GitHub.

Grüße, Daniel

Hallo zusammen,

ich muss mal kurz diesen Thread kapern 😉 Ich hab auch Daniels Platine in der aktuellen 0.0.6 Variante im Betrieb. Hatte vorher eine andere Revision in Verwendung. Irgendwann kam mal durch Update bzw. Tausch der Platinen eine Fehlermeldung auf der Buderus Steuerung (sieh Bild). Und die bring ich nicht mehr weg, hab folgendes versucht:

• Stromversorgung des Moduls über die USB Buchse -> Fehler immer noch da
• Module ausgebaut, Steuerung in Betrieb genommen -> Fehler immer noch da
• aktuelle 3.2.4 von Sven's Software installiert (per USB bzw. seriell) -> Fehler immer noch da

Ansonsten funktioniert übrigens alles, sowohl mit der Heizung als auch mit dem Module. Es werden alle Parameter wie gewünscht per mqtt übertragen und die Steuerung via Webinterface funktioniert auch.

Etwas Suche im Web brachte den Hinweis, dass man wohl auf Ebene 2 der Steuerung Module ein- bzw. ausprogrammieren kann. Kennt sich wer damit aus wie das geht? Im "normalen" Setup Modus find ich jedenfalls nix dazu.

Grüße

Hallo Markus, der Fehler deutet auf ein defektes oder fehlendes FM242 hin. https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=63

Hat deine Steuerung ein "2-Stufen Brenner Modul" FM242 ? Falls nur ein "1-Stufen Brenner Modul" FM241 eingebaut ist, dann solltest Du versuchen die Einstellungen entsprechend zu ändern.

Siehe Service-Anleitung: https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=1

Gruß Gernot

Gernot A. schrieb:

Hallo Markus, der Fehler deutet auf ein defektes oder fehlendes FM242 hin. https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=63

Hat deine Steuerung ein "2-Stufen Brenner Modul" FM242 ? Falls nur ein "1-Stufen Brenner Modul" FM241 eingebaut ist, dann solltest Du versuchen die Einstellungen entsprechend zu ändern.

Siehe Service-Anleitung: https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=1

Gruß Gernot

Hi Gernot,

danke für den Hinweis, ich hab das mal auf 1-stufig umgestellt und nun ist die Anzeige bzw. der Fehler weg. Ich weiß allerdings nicht wirklich, welches Modul da verbaut ist. Weißt du, wo ich das sehe? Ist das in der Steuerung oder am Brenner zu sehen?

Gruß - Markus

Hallo Markus, da musst du in die Logamatic 2107 reinschauen. Das FM241 ist das Mischer-Modul für den Heizkreis 2 (siehe Bild). Das FM242 wäre zur Ansteuerung eines 2-stufigen oder modulierenden Brenners nötig... Gruß Gernot