Da die alten Threads ja inzwischen ziemlich unübersichtlich geworden sind, möchte ich mal einen neuen Thread zum EMS aufmachen. Dieses Posting dient dabei gleich als Linksammlung die wichtigsten Informationen. Wenn jemand Linkvorschläge hat, nur zu :) Hardware-Schaltpläne: - Original-Schaltung, getestet, reverse engineered von Niffko Beitrag "Re: Logamatic 2107 Schnittstelle" Software: - EMS-Collector (C++-Daemon, der EMS-Daten auswertet und in MySQL schreibt; erlaubt auch Steuerung) http://github.com/maniac103/ems-collector - Ethersex (AVR-Firmware, kann EMS auf TCP umsetzen) http://github.com/ethersex/ethersex Doku zum Telegrammaufbau: - Wiki http://ems-gateway.myds.me/dokuwiki/ - EMS-Collector-Quellcode (siehe oben) - Java-Quellcode von Jürgen Schmied Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung" Bestehende Threads mit Informationen: - alter Thread Beitrag "Logamatic 2107 Schnittstelle" - EMS-Gateway-Thread von Ingo F. Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung"
So... Dann entjungfere ich mal den Thread :p Anbei das Logfile, ca. 20h lang. Am Bus war nur die Heizung, NetIO mit Sniffer und ein RC25. Das Logfile hat vorne ein Timestamp, dann durch ein Strich getrennt die Länge, gefolgt von den Daten welche auch mit einem Bindestrich abgetrennt wurden. Mal sehen was man so auswerten kann. LG
So... Da ich nichtmehr bearbeiten kann wieder einen neuen Beitrag :p Hier mal meine ersten Statistikversuche in den Datensätzen. Schaut ja schonmal gut aus. Ich versuch nun mal die Temperaturreports usw zu finden.
Hallo! Da sind ein paar Nachrichten drin, die in Kombination mit RC35 nicht auftreten (0x2a,0xad,0xae). Die bekannten Nachrichten mit Temperaturdaten sind aber auch da (0x18/0x19. Die Busadresse 0x13 ist auch bisher nicht aufgetreten. Ich sehe mit das Log mal nächste Woche genauer an. vg Jürgen
Hallo, ich Analysiere es gerade ;) Wenn mich mein Excel bei 40k Zeilen nur nicht laufend verlassen würde. (3MB Daten -> 1GB Ram) Soweit bin ich bis jetzt: Aus (Mond drücken): Länge Sender Empfänger Typ Daten gefolgt von CRC 0x05 0x17 0x00 0xad 0x03 0x00 0xb9 Ein (Sonne drücken): Länge Sender Empfänger Typ Daten gefolgt von CRC 0x05 0x17 0x00 0xad 0x03 0x01 0xb8 Raum-Temperatur (0xe3 Byte): Länge Sender Empfänger Typ Daten gefolgt von CRC 0x0c 0x17 0x00 0xae 0x00 0x80 0x02 0x2c 0x00 0xe3 0x00 0x00 0x00 0xf4 Muss ich einfach die Bytefolgen senden um umzuschalden oder kollidieren dann die Sender IDs?
Hallo! Nein, das funktioniert anders. Interpretieren wir mal Deine Bytefolge: > Aus (Mond drücken): > Länge Sender Empfänger Typ Daten gefolgt von CRC > 0x05 0x17 0x00 0xad 0x03 0x00 0xb9 0x17 Ich bin RC20 ... 0x00 ... und gebe allen bekannt ... 0xad ... in Telegramm 0xad ... 0x03 ... an Offset 0x03 ... 0x00 ... ist die Einstellung jetzt 0x00 ... wenn Du senden willst: 0x0b Ich bin das EMS-GW ... 0x17 ... und sende an RC20 ... 0xad ... in Telegramm 0xad ... 0x03 ... an Offset 0x03 ... 0x01 ... es werde Tag ;-) (0 - Nacht, 1 - Tag, 2 - Auto) CRC Die RC20 müsste dann mit 0x00 (OK) antworten. Das EMS-GW darf grundsätzlich nur mit 0x0B als Absender senden !! Die anderen Einstellungen analog. PS: Bie der Raumtemperatur musst Du das passende Byte finden. Am besten die angezeigte Temperatur mal im Telegramm suchen. z.B. 25,6°C = 0x100 = .. 01 00 .. vg Jürgen
:
Bearbeitet durch User
PS: Denkfehler: Nur Raum- und Waser-Ist-Temperatur hat 10 als Multiplikator. Raum-Soll ist x2 und Wasser-Soll x1. vg Jürgen
Gut wäre vielleicht, wenn jemand mit WEB KM200 mal die Änderung von Betriebsart und Raumsoll mitschneiden könnte. Dann wüssten wir sicher, wie so was von "extern" auszusehen hat. //Niffko
Jürgen Schmied schrieb: > Die RC20 müsste dann mit 0x00 (OK) antworten. Ich glaube, das sollte 0x01 heißen, oder? ;) > Das EMS-GW darf grundsätzlich nur mit 0x0B als Absender senden !! Da er ein NetIO + Ethersex mit meinem EMS-Code verwendet, ist das schon abgesichert: Die Senderadresse und die EMS-CRC wird von Ethersex ausgefüllt. Niffko _ schrieb: > Gut wäre vielleicht, wenn jemand mit WEB KM200 mal die Änderung von > Betriebsart und Raumsoll mitschneiden könnte. Dann wüssten wir sicher, > wie so was von "extern" auszusehen hat. Betriebsart funktioniert bei mir (RC30) definitiv hiermit: 0x0b 0x10 0x3b 0x07 0x0X <crc> (für HK1; X = 0 Nacht, 1 Tag, 2 Auto; 0x45 statt 0x3b für HK2). Die RC30 sendet, wenn ich direkt daran drücke, auch entsprechende Meldungen für jeden HK: 0x10 0x00 0x3d 0x07 0x00 0x10 0x00 0x47 0x07 0x00 Wie der Zusammenhang zwischen den Typen (also z.B. 0x3b vs. 0x3d) ist, ist mir noch nicht ganz klar. Ich bin mir allerdings ziemlich sicher, dass das Kommando stimmt, da ich es aus der Buderus-Doku habe (EMS-310809: "Technische Information Logamatic EMS Parameter und Monitordaten") Raumtemperatur geht hiermit: 0x0b 0x10 0x3b 0x0X 0xYZ <crc> (X = 1 Nacht, 2 Tag, 3 Urlaubsmodus, YZ = Temperatur * 2, also z.B. 20.5°C -> 41 -> 0x29) Steht aber alles auch in meinen EMS-Collector-Sourcen ;)
Jürgen Schmied schrieb: > 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. Leider funktioniert das nicht :( 0x06 scheint ein Read-Only-Telegramm zu sein. Man bekommt zwar ein OK zurück, an der Zeit ändert sich aber nix.
Schade. Versuchs mal Byteweise: 0B 10 06.00 0D 0B 10 06.01 09 0B 10 06.02 14 0B 10 06.03 13 0B 10 06.04 00 0B 10 06.05 00 Vieleicht hat er nur das erste Byte geschrieben !?
:
Bearbeitet durch User
Nope :( Ich hab Jahr und Monat (Offset 0 und 1) probiert, selbes Ergebnis: OK, aber keine Änderung.
So, Soll und Ist Temp habe ich schonmal :) Bei dem Tag/Nacht State bin ich noch nicht ganz sicher, weis ja aber was beim Umschalten passiert ;) void EmsMessage::parseRC20StateMessage() { RETURN_ON_SIZE_MISMATCH(9, "RC20 State"); // 9 Nettobytes printBoolAndAddToDb(1, 7, "Tagbetrieb", Database::SensorWWTagbetrieb); printNumberAndAddToDb(3, 1, 2, "Soll Raum-Temp.", "°C", Database::SensorRaumSollTemp); printNumberAndAddToDb(4, 2, 10, "Ist Raum-Temp.", "°C", Database::SensorRaumIstTemp); } und die Switch erweitert mit: case addressRC20: switch (m_type) { case 0xae: parseRC20StateMessage(); handled = true; break; } break; Das habe ich nun in der EmsMessage.cpp eingefügt ;) Wie sende ich nun die passende Meldung? Atm. stochere ich noch im Blinden rum. Wird das selbst gesendete geloggt? Also die Wiederholung der Heizung. Oder wie teste ich sonst was raus geht? :) LG
So, habe nun den Logic Analyzer dran hängen (oben TX, unten RX). Ich habe den Collector umgebaut dass er 0x0B 0x17 0xAD 0x03 0x00 0x88 sendet. Die Heizung wiederholt Byteweise, danach ist auf dem Bus für 260ms Ruhe... bis es mit 0x8C weiter geht. Also von einer Antwort des RC20 ist da nichts zu sehen. der Collector sagt mir auch Timeout :( Hoffe Ihr könnt mir nu wieder weiterhelfen :p
Hallo! Tja, der Empfänger unter 0x17 fühlt sich von einem Schreibbefehl nicht angesprochen. Sende doch mal: 0x0B 0x97 0xAD 0x03 0x01 <CRC> Dann müsste die BC20 das 4. Byte von Telegramm 0xad zurück senden. vg Jürgen
Wo ist das Break als Abschluss des Telegramms??? Nach dem CRC muss TX für mindestens 10 Bits auf LOW sein.
:
Bearbeitet durch User
Okay... dass müsst ich dann in dem NetIO einflicken. Bin grade dabei die State Machine darin zu verstehen.
Ra Sp schrieb: > Okay... dass müsst ich dann in dem NetIO einflicken. Bin grade dabei die > State Machine darin zu verstehen. Das ist doch da schon drin?!
Und wieso wirds nicht getan? :) Hier der Aufruf: sendCommand(151, type, data, sizeof(data));
:
Bearbeitet durch User
151 als Zieladresse? Davon mal abgesehen bin ich mir bei dem Ethersex-Code 99.9% sicher, dass der richtig ist, da ich hier ja einwandfrei senden kann. Getriggert wird das Break von ems_uart. c:188 nachdem das letzte TX-Byte raus ist. Du kannst ja spaßeshalber mal ethersex aus meinem Fork bei github bauen, einen Unterschied sollte das aber nicht machen.
:
Bearbeitet durch User
Hmmm vllt. hast du ja auch eine Konstellation wo es passt. Hast du mal nachgemessen was effektiv rauskommt?
Ja. So hatte ich auch diesen Bug entdeckt: https://github.com/maniac103/ethersex/commit/6a2be5b5a80152da7e14dcee11ad719b9487306a Der führte dazu, dass das Break verschluckt wurde, wodurch nix ging. Du kannst den Code gerne nochmal nach Bugs abklappern, grundsätzlich ist aber alles da.
So, hab den Ethersex Code mehrfach durchwühlt. Nun habe ich mir RS232 Debug-Marken (EMSPROTODEBUG) gesetzt und nun kommen die 11 low-bits... Kommentiere ich diese wieder aus, bekomme ich keinen 11-Bit lowpegel. Im Moment weis ich grade nicht ob DDRD und PORTD was bringt (habe ich eingefügt). Eine Antwort kommt immer noch nicht vom Bus. Mag vllt. am Timing liegen dass die 11 Bits zu spät kommen. static void start_break(void) { EMSPROTODEBUG("S\n"); usart(UCSR,B) &= ~(_BV(usart(UDRIE)) | _BV(usart(TXEN)) | _BV(usart(TXCIE))); DDRD |= (_BV(PD3)); PORTD &= ~(_BV(PD3)); bit_counter = 13; //war 11 TC2_COUNTER_COMPARE = BIT_TIME; TC2_COUNTER_CURRENT = 0; TC2_INT_COMPARE_ON; state = STATE_TX_BREAK; } ISR(TC2_VECTOR_COMPARE) { bit_counter--; if (bit_counter == 0) { TC2_INT_COMPARE_OFF; usart(UCSR,B) |= _BV(usart(TXEN)); tx_timeout = 0; //DDRD &= ~(_BV(PD3)); go_to_rx(); EMSPROTODEBUG("E\n"); } } Tante Edit: So, nun sende ich an 0x17 meine 0xAD Kommandos und es geht :) die Heizung schaltet um :) HAPPY
:
Bearbeitet durch User
Ra Sp schrieb: > Im Moment weis ich grade nicht ob DDRD und PORTD was bringt (habe ich > eingefügt). Wahrscheinlich nicht, da das Gleiche schon in ems_uart_init() gemacht wird und der GPIO danach nicht mehr angefasst wird. > Tante Edit: > So, nun sende ich an 0x17 meine 0xAD Kommandos und es geht :) die > Heizung schaltet um :) *HAPPY* Und was hast du dafür nun getan?
Tjoa nicht viel auser die 2 Debugmeldungen hinzugefügt. Den rest wie oben beschrieben. Ich habe mir nun noch das WebIF erweitert um eine Cronfile zu erstellen ;) Naja erstmal reicht mir das so. Wenn die anderen Projekte fertig sind gehts hier weiter ;) Tante Edit: Tjoa wie immer... Rechtschreibfehler wurden nach dem posten gesichtet und schon korrigiert ;)
:
Bearbeitet durch User
Ra Sp schrieb: > Tante Edit: > So, nun sende ich an 0x17 meine 0xAD Kommandos und es geht :) die > Heizung schaltet um :) *HAPPY* Kannst du mal schauen ob du eines von den DEBUG-Befehlen rausnehmen kannst? Da ist definitiv noch etwas am Timing nicht richtig.
Hallo! Ich habe mal einen kompletten Schreibzyklus incl. Quittierung und Busfreigabe aufgezeichnet. So soll es idealerweise aussehen. vg Jürgen
Hallo zusammen, könnt Ihr bitte in die Firmware die Initialisierung des LCD Displays mit einbauen und einen Begrüsungstext (Versionsnummer der Software) ausgeben. Wenn ich demnächst schon mal am Löten der Stiftleisten bin, wollte ich gleich mal das Display mit testen. LG Stefan
'Die Firmware'? Ich glaube, das wolltest du in den EMS-Gateway-Thread posten, oder?
Das hier ist doch der nachfolge Thredd nach Jürgens Wunsch. lg Stefan
IMHO nein, siehe meine Antwort im Gateway-Thread. Das hier ist der Nachfolgethread für alles, was den EMS selbst betrifft. Wenn wir wieder anfangen, alles durcheinanderzumischen, wird der Thread in absehbarer Zeit wieder genauso lang...
Guten Tag, Ich wollte eine unsere Logamatic 2107M über eine RC35 ansteuern, wozu eine Art Konverter zwischengeschaltet werden muss. Nachdem ich diesen Thread quasi ganz durchgelsen habe, blicke ich nicht mehr ganz durch. :( Die wichtigste Frage - Beinhaltet dieses EMS-Gateway den Konverter den ich benötige? "Beifang" - Wenn ja, kannt das Gateway gleichzeitig eine Ansteuerung über LAN bereitstellen? Ich bedanke mich in Vorfeld für die Informationen.
Hallo! Die Logamatic 2107M gehört zum 2000er System. Da gibt es kein EMS Bus. Auch das Buderus "RS232 Gateway" ist nur für EMS und 4000er. Ein KM271 würde wohl laufen und bietet eine RS232 Schnittstelle. Da brauchst Du aber Logamatic Easycom oder ECO-SOFT (€!). Das LAN Gateway von Buderus geht auch nur für 4000er. vg Jürgen
Hallo zusammen, Ich verfolge schon seit einigen wochen sämtliche Einträge bezüglich des EMS bus von Buderus. Wollte eigentlich mit einem nand gatter auf die Anlage zugreifen. Habe da ich meinen Freundlichen Heizungsbauer sehr gut kenne ein Web-Gateway KM-200 zum testen bekommen und gleich mal das Ding zerlegt da ist ein Bosch Low Ethernet to CAN drin. Habe dann auch gleich mal die apk der zugehörigen App zerlegt und jetzt kommt das interesante in der App selber sind all Funktionen bereits integriert nur nicht auf aktiv. Kennt sich denn einer gut mit Java und App Programmierungaus und könnte sich den Sorce mal anschauen ob man nicht auf diese Art und weise an eine Machtigere Schnittstelle zur Anlage kommt. Ich wollte eigentlich mit der Platine mit dem Nand gatter und der Original Software Eco-Soft die Anlage lesen und Schreiben. Nur über eine App wäre das natürlich viel eleganter. Ich kann auch gerne mal Bilder von dem KM-200 Innenleben machen. Gruß Alex
:
Bearbeitet durch User
Es ist leider nicht viel zu erkennen, außer das dass CAN Interface nicht bestückt ist. Kennt jemand einen Mikrocontroller im QFP-128 Gehäuse? Wenn Du am Laufen hast, kannst du ja mal mit Wireshark testen, wie die Kommunikation zwischen KM200 und App läuft. vg Jürgen
Hier mal der mitschnitt zwischen der App und dem KM-200 Der KM-200 wird als V850.local angesprochen/aufgelistet mit der IP 192.168.178.157 nur leider kann ich damit so gut wie nix anfangen alles Spanisch Chinesisch oder sonst was für mich. gruß Alex
:
Bearbeitet durch User
Hier noch der sorce der Buderus APK komplett Orignal APK Orignal classes.dex Entpakte APk Sorce Umgewandelte classes.dex in classesdex2jar.jar für jd-gui.exe Anm. Administrator: Anhang entfernt (Urheberrecht beachten!).
:
Bearbeitet durch Admin
Weiß jemand wie ich auf die verschiedene Programme wie Abendprogramm, Eigenprogramm usw. umschalte und wo ich genau diese Schaltzeiten finde. Kann ich evtl. auch die anderen Schaltzeiten wie beim Eigenprogr. verändern? Ich habe die RC30.
Du meinst per RC30 oder per Interface (wie dem EMS-GW) direkt auf dem Bus? Die Telegramme vom Bus findest Du unter http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme Dort sind auch die einzelnen Schaltprogramme aufgeführt. Die Umsschaltung der Betriebsart für Warmwasser bzw. die Heizkreise sind dort auch dokumentiert. vg Jürgen
Hallo Franz, also die vorprogrammierten Wochenprogramme sind in der RC30/RC35 fest programmiert. Es kann eigentlich nur das "Eigenes Programm" geändert werden. Es gibt aber für jeden Heizkreis ein eigenes Telegramm mit den Zeiten. Also Urlaubs-/Ferienfunktion und Schaltzeiten stehen im Wiki bei den Telegrammen... http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme#hk1schaltzeiten Der Aufbau der Schaltzeiten ist sind dank Jürgen hier: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme#schaltzeiten_allgemein Dummerweise habe ich keine Zeiten für die Warmwasserbereitung/Zirkulation gefunden. Denke das macht die RC30 selber und deswegen gibt es wohl keine Telegramme dafür ?!? Gruß Ingo
Da war Jürgen wohl schneller... Jürgen Schmied schrieb: > Warmwasser Das ist ja interessant... Scheint das Telegramm 0x38 zu sein.
Zumindest bei der RC35 ist Telegram 0x39 das Schaltprogramm für die Zirkulation. Was die RC30 alles steuert, weiß ich leider nicht. Dazu müsste man mal einen längeren Busmitschnitt so einer Anlage haben ... Hat jemand die Möglichkeit? vg Jürgen
Hallo Ingo, hallo Jürgen, Ingo F. schrieb: > stehen im Wiki bei den Telegrammen... > http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme#hk1schaltzeiten die Wiki habe ich gelesen, hier geht aber nicht hervor wie ich auf die verschiedene Programme wie Abendprogramm, Singleprogramm, Eigenprogr. umschalte. Ingo F. schrieb: > also die vorprogrammierten Wochenprogramme sind in der RC30/RC35 fest > programmiert. Es kann eigentlich nur das "Eigenes Programm" geändert > werden. das habe ich mir gedacht, ich müßte aber die Zeiten trotzdem auslesen können, bzw die Zeiten vom Eigenprogr. ändern können. Im Wiki habe ich nur die Urlaubszeiten (Typ 0x3f) gefunden. Gibt es eine Aufschlüsselung der Schaltzeiten der RC35 Typ 0x49 und Typ 0x4c Ingo F. schrieb: > Dummerweise habe ich keine Zeiten für die > Warmwasserbereitung/Zirkulation gefunden. Denke das macht die RC30 Im Wiki steht 0x38 und 0x39 aber ich weiß nicht, ob es die Urlaubsfunktion ist.
Jürgen Schmied schrieb: > Zumindest bei der RC35 ist Telegram 0x39 das Schaltprogramm für die > Zirkulation. Was die RC30 alles steuert, weiß ich leider nicht. Dazu > müsste man mal einen längeren Busmitschnitt so einer Anlage haben ... > > Hat jemand die Möglichkeit? Ich lass meinen Daemon mal einen Tag mitloggen. Ich glaube allerdings, dass das Durchsehen mühselig wird, oder hast du Skripte, um das zu analysieren?
Hallo Danny, leider habe ich keine Skripte, mal eine Frage: Wenn ich das Schaltprogramm an der RC30 ändere, werden diese Daten dann auf den EMS-Bus sofort gesendet? Viele Grüße Franz
Das Schaltprogramm ist im Speicher der RC30. Diese sendet auch die Steuerbefehle zu den programmierten Zeitpunkten zu dem Brenner, Pumpe usw. Zusätzlich wird das Schaltprogramm als Kopie auf den Bus gesendet - aber anscheinend nur zur Information für andere Teilnehmer. Ohne die RC30/35 passiert nichts. vg Jürgen
PS: Umschaltung in den Urlaubsmodus: Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung" PSS: Ja, ich habe ein Java-Programm, um den binären Byte-Stream vom EMS-GW auszuwerten. Es übersetzt ihn in in Text und den kann normal durchsuchen. vg Jürgen
F. F. schrieb: > Im Wiki habe ich nur die Urlaubszeiten (Typ 0x3f) Das sind auch die Schaltzeiten. Die Urlaubsfunktion ist ab Offset 0x57 Die Urlaubsfunktion kann man mit 0b 10 3f 57 06 <Prüfsumme> von Heizkreis 1 abfragen. Die Schaltzeiten sind im ganzen Bereich vor der Urlaubsfunktion. Jürgen Schmied schrieb: > Zusätzlich wird das Schaltprogramm als Kopie auf den Bus gesendet - aber > anscheinend nur zur Information für andere Teilnehmer. Ohne die RC30/35 > passiert nichts. Hast Du denn schon mal probiert die Zeiten zu ändern? Denke schon dass die RC30/RC35 das akzeptiert. Die Uralubsfunktion konnte ich schon erfolgreich über mein Java-Programm ändern. Allerdings hatte ich die Urlaubsfunktion nicht für Warmwasser und Zirkulation gefunden. Beim Einschalten der Urlaubsfunktion wurden wohl nur die Schaltzeiten-Telegramme für die Heizkreise gesendet. Für Warmwasser und Zirkulation habe cih damals keine Telegramme auf dem Bus gesehen. F. F. schrieb: > Wenn ich das > Schaltprogramm an der RC30 ändere, werden diese Daten dann auf den > EMS-Bus sofort gesendet? Bin zwar nicht Danny, Aber wenn man die Schaltzeiten an der RC30 ändert werden diese dann in mehreren Teilen übertragen. Gruß Ingo
Alex Amend schrieb: > Der KM-200 wird als V850.local angesprochen/aufgelistet mit der IP > 192.168.178.157 > nur leider kann ich damit so gut wie nix anfangen alles Spanisch > Chinesisch oder sonst was für mich. ich habe mir mal dein Log angeschaut, und so wie es scheint geht die Kommunikation über HTTP/80 per Binary JSON. ----- HTTP/1.0 200 The request has succeeded Content-Type: application/json veSJNc+lFfrdObDjj04tWC+pGbZELyzUiQaSZli48U+ax2nFuLmVP6m9X7M/PtRmDZc/PngS 6VF+9Pj8OG1XIj+7oCNQV9vAp0fGL9gboUhh8XdfqOcQbkH6eu1RzHJ1H/6mdPjM2ielVRed TgYvvfhOeldH64YiUN8bfnu3cjPxSn1zR5y82nSQszQ2kK7/oRaBNHJaJ1xkVXpl1y8KQrT8 IfzTrW356VeTa+inpSehjHXp6aiiD21SDCQPBHexaNq+MMb3ZjCppyNTUhKxspybIEuNRNYP NEF7R/SF6rAewrwo1cLzsSB22pKqrXjxPSIbEWDCGTJDKY8suxLT5u+Dv74hIHsg0xc3fo1q PhEf4x5XbfveedsRqPMi+ePSQr1pEkkKyYkEkksXKEHoYk4TFKaWQSdi7yilgfc/0LJKW5cp jlnqppMN5ZIvKFZyL4Cc+Tl8CBVHbj2oBxPw/V2GnLFpvBoKAC9DZiNiBCLnSp+bI99TozqR oalkC9H/SakHzT3hN3vMpLhj/qCOiQs6+CA968AYE0qwO80pLRPi+JTsCM0oB+ecPePkiUQq v4m5wtVuPAUXM6Px109+VPhOeldH64YiUN8bfnu3cjOS665LPoIv0JnQrdQcebJMoRaBNHJa J1xkVXpl1y8KQrT8IfzTrW356VeTa+inpScIiqy5T3fgAcy3RxT42S0r ---- Das ganze ist dann noch Base64 kodiert. Das Endergebnis ist dann allerdings wiederum ernüchternd. Nichts was man so lesen könnte. Ich dachte es wäre evtl. am Ende dann doch wieder JSON, aber da komme ich nicht weiter. Gruß Kevin
Auch nach einem base64 Decoder ist es immer noch kein JSON oder Binary-JSON. Also komplett unlesbar. js
Jürgen Schmied schrieb: > Zumindest bei der RC35 ist Telegram 0x39 das Schaltprogramm für die > Zirkulation. Was die RC30 alles steuert, weiß ich leider nicht. Dazu > müsste man mal einen längeren Busmitschnitt so einer Anlage haben ... So in etwa? ;) Sind die Nachrichten von ~16h Laufzeit meiner Anlage - von gestern abend bis gerade eben.
Ja, so in etwa. Stimmt es, dass Du ein MM10 und WM10 Modul sowie 2 Heizkreise in der Anlage hast? Der Kessel ist auf 58% max Leistung gedrosselt? Die Anlage ist 7326h in Betrieb? Komisch ist: HK2 Raum-Solltemperatur 0.0 °C Warmwasser-Soll-Temperatur 10.0 °C Brennerstarts 100149 Es gibt wieder neue Telegramme zum entschlüsseln ;) vg Jürgen
Jürgen Schmied schrieb: > Ja, so in etwa. Stimmt es, dass Du ein MM10 und WM10 Modul sowie 2 > Heizkreise in der Anlage hast? Der Kessel ist auf 58% max Leistung > gedrosselt? Ja. Die Drosselung hast du gesehen, weil bei Warmwasserbereitung auch nur 58% anliegen, oder? Edit: Ach nee, max. Leistung ist ja Teil der MonitorFast-Message. > Die Anlage ist 7326h in Betrieb? Das ist doch Brennerlaufzeit, nicht Anlagenbetriebsdauer, oder? Dürfte dann hinkommen; die Anlage ist seit 2004 in Betrieb. > Komisch ist: > HK2 Raum-Solltemperatur 0.0 °C > Warmwasser-Soll-Temperatur 10.0 °C Wann war das, evtl. nachts? > Brennerstarts 100149 Hmm, das wären etwas mehr als 10000 im Jahr oder 30 am Tag ... erscheint mir in Anbetracht der Tatsache, dass es heute bislang 15 waren, nicht komplett unmöglich, wenngleich etwas hoch. Wir sind allerdings erst 2009 eingezogen; ich habe keine Ahnung, mit welchen Parametern die Anlage vorher betrieben wurde.
:
Bearbeitet durch User
Hallo! So, hier das Log in lesbarer Form. Habe die neuen Telegramme im Wiki eingefügt. vg Jürgen
Hallo Jürgen, gute Arbeit, mit was für einem Programm schreibt Ihr die Protokolle mit? Ist es möglich die Daten auf SD-Karte zu sichern um sie dann mit einem Hex-Editor auszulesen? viele Grüße Franz
Danny Baumann schrieb: > Jürgen Schmied schrieb: >> Ja, so in etwa. Stimmt es, dass Du ein MM10 und WM10 Modul sowie 2 >> Heizkreise in der Anlage hast? Der Kessel ist auf 58% max Leistung >> gedrosselt? > > Ja. Die Drosselung hast du gesehen, weil bei Warmwasserbereitung auch > nur 58% anliegen, oder? > Edit: Ach nee, max. Leistung ist ja Teil der MonitorFast-Message. Bei WW ist die Leistung max. 125%. >> Brennerstarts 100149 > > Hmm, das wären etwas mehr als 10000 im Jahr oder 30 am Tag ... erscheint > mir in Anbetracht der Tatsache, dass es heute bislang 15 waren, nicht > komplett unmöglich, wenngleich etwas hoch. Wir sind allerdings erst 2009 > eingezogen; ich habe keine Ahnung, mit welchen Parametern die Anlage > vorher betrieben wurde. Bei der Umschaltung der Heizkreise kann der Brenner schon ausgehen und in der Übergangszeit ist es eh am schlimmsten mit den Brennerstarts. Das gibt sich dann wieder im Winter wenn es gut kalt ist oder im Sommer wenn nur WW bereitet wird. ---
Hallo,
Danny Baumann schrieb:
>> Brennerstarts 100149
Habe hier seit 06.2010 ca. 38.600 Brennerstarts. Das sind rund 30 pro
Tag. Deckt sich mit Deinen Angaben.
Gruß aus der derzeit kalten Wetterau
Karl M.
ps. Habe mich jetzt auch mal registriert. Charlies gibt's ja wie Sand am
Meer. :-o
Hi, also ich liege mit einer GB172-24 bei 5-6 Starts pro Stunde im SCHNITT, da kommst du ja noch gut weg. Gruss Norbert
Hi, die andauernden Brennerstarts gingen mir damals 2006/2007 als unsere GB-132 16 neu war, gerade in der Übergangszeit auch auf den Nerv, da halt nicht wirklich Bedarf da ist und so hatte die ohne Ende getaktet. Ich habe damals (zusätzlich zu weiteren Optimierungen, Heizkurve, ...) eine Sperrzeit eingestellt, sodass der Brenner erst nach frühestens 45min erneut starten darf. Dadurch konnte ich die Starts erheblich senken und habe bisher keinen Komfort einbüsen müssen ;-) Grüße giovanne
> die andauernden Brennerstarts gingen mir damals 2006/2007 als unsere > GB-132 16 neu war, gerade in der Übergangszeit auch auf den Nerv, da > halt nicht wirklich Bedarf da ist und so hatte die ohne Ende getaktet. > Ich habe damals (zusätzlich zu weiteren Optimierungen, Heizkurve, ...) > eine Sperrzeit eingestellt, sodass der Brenner erst nach frühestens > 45min erneut starten darf. Das ist interessant. Wie hast du das gemacht?
giovanne schrieb: > eine Sperrzeit eingestellt, sodass der Brenner erst nach frühestens > 45min erneut starten darf. Ja, würde mich auch interessieren. Hab hier 'ne Buderus GB162-25 T40S.
Hi, auf dem RC35 die beiden rechten und den linken Knopf gleichzeitig drücken, dann ist man im 'richtigen' Menü, dann müsste das bei den Heizkreiseinstellungen sein. Gruss Norbert
Taktsperre ist auch in der 2.Bedienebene nicht einstellbar. Über Ecosoft geht's. Oder man kennt das "richtige" Telegramm ... //Niffko
Hi, wegen Taktsperre müßte ich mal schauen. Ich meine aber es in der Eco-Soft gemacht zu haben, im Bereich der Sonderparameter ;-)
für 30.000 Starts hat unsere alte GB112 10 Jahre und 30.000h gebraucht und das unoptimiert für ein gut dimensioniertes modulierendes Gerät dürfen es nicht mehr als 3.000 Starts pro Jahr werden, eher sogar nur 2.000 mit mehreren Stunden Laufzeit pro Start alles andere läuft grottig schlecht (Hydraulik, Temperaturen)
Giovanne Giovanne schrieb:
> Wie vermutet, in den Sonderparametern -> Antipendelzeit
Hi,
danke für's rauskramen! Leider komme ich da nicht ran, habe keine
Ecosoft.
Kennt jemand die Telegrammparameter?
Gruß aus der Wetterau
Karl M.
Wie ist denn die default Einstellung? Die sollte doch schon auf dem Bus zu sehen sein ...
Hallo! Ich rate mal: 08 00 16|00 FF 5A 64 00 06 FA>0A<01 0B 64 37 02|2E Die 0x0a könnte der gesuchte Wert sein. Die 0x0b ist der Kesselpumpennachlauf (hier 11 Min). vg Jürgen
Sollte passen, ein Mitschnitt per 3964R Terminal während des Ecosoft Betriebes zeigt die Werte zum Zeitpunkt wenn für das Online Monitoring neu eingelesen/initialisiert wird: Folgende Werte sollten zu meinen Einstellungen passen: (Mitschnit sieht so aus, da ich derzeit nur lese per 3964R Terminal, da ja Ecosoft die sende-Befehle Hoheit hat ;-) 1384909781306 - COM12 - (z00) receive: <<04>>. Rejecting. 1384909781306 - COM12 - (z00) receive: <<08>>. Rejecting. 1384909781306 - COM12 - (z00) receive: <<16>>. Rejecting. => Telegramm 1384909781306 - COM12 - (z00) receive: <<00>>. Rejecting. 1384909781322 - COM12 - (z00) receive: <<FF>>. Rejecting. => 255 ? 1384909781322 - COM12 - (z00) receive: <<5A>>. Rejecting. => Kesseltemp.: 90° 1384909781322 - COM12 - (z00) receive: <<32>>. Rejecting. => 50 ? 1384909781322 - COM12 - (z00) receive: <<00>>. Rejecting. 1384909781322 - COM12 - (z00) receive: <<06>>. Rejecting. => 6 ? 1384909781338 - COM12 - (z00) receive: <<FA>>. Rejecting. => 250 ? 1384909781338 - COM12 - (z00) receive: <<2D>>. Rejecting. => Antipendelzeit: 45min 1384909781338 - COM12 - (z00) receive: <<01>>. Rejecting. => 1 ? 1384909781338 - COM12 - (z00) receive: <<1E>>. Rejecting. => Kesselpumpennachlauf: 30min 1384909781338 - COM12 - (z00) receive: <<50>>. Rejecting. => Kesselkreispumpenmodulation max. Leistung: 80 1384909781338 - COM12 - (z00) receive: <<37>>. Rejecting. => Kesselkreispumpenmodulation min. Leistung: 55 Ach ja, schön wäre wenn man das 3964R Terminal nur zum Lauschen nutzen könnte und die Daten bereits korrekt aufbereitet würden (inkl. Erkenntnisse aus http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:sk_schnittstelle bzgl. Änderungen) und von dort in eine DB geschrieben werden könnten. Tue mich da derzeit noch ein wenig schwer :-(
:
Bearbeitet durch User
Ok, ist im Wiki eingepflegt. Verdächtig ist noch Byte 7: bei mir 0x64 (warscheinlich 100%) bei Dir 0x32 (warscheinlich 50%). Ideen? Zum Rest fällt mir erstmal nichts ein. vg Jürgen
:
Bearbeitet durch User
bzgl. 0x32 (warscheinlich 50%) sehe ich noch keine direkt Zuordnung in den Parametern. Wenn eine 1 davor wäre, hätte es theoretisch Mischerlaufzeit = 150sek. bei mir sein können. Bei den Sonderparameter (s. Screengrab oben), wären noch Temperaturanhebungen für HK1 (bei mir 5), HK2 (bei mir 5) und WW (bei mir 15) in Kelvin, welche ich aber auch noch nicht im Protokoll wiedergefunden habe. Ich könnte es alles einfacher lesen, wenn das 3964R Terminal im rein lesenden Betrieb die Daten/Protokolle sauber rausfischen könnte ;-)
Giovanne Giovanne schrieb: > Ich könnte es alles einfacher lesen, wenn das 3964R Terminal im rein > lesenden Betrieb die Daten/Protokolle sauber rausfischen könnte ;-) Hallo Giovanne, ist halt nicht einfach dem 3964R-Terminal das Handshake abzugewöhnen. Ist halt nicht dafür gedacht das Drei Busteilnehmer an einem Serial-Port hängen. Da das 3964R-Terminal eine fertige Bibliothek verwendet müsste man die Bibliothek entsprechen umbauen oder selber schreiben. Also am besten Service-Key oder eine andere Software. Vermutlich wäre für so kurze Mitschnitte "hTerm" besser geeignet. Am besten das Handshake vom 3964R-Protokoll für einen Zeilenwechsel beim hTerm einstellen. Wird dann vermutlich viel übersichtlicher. Dann muss man aber noch die doppelten 0x10 herausfiltern. Wenn man dem 3964R-Terminal das schreiben in die Datenbank "beibringt" müsste man also auf den Service-Key verzichten. ...Oder ein komplett neues Programm schreiben dass das Handshake ignoriert und nur die Daten herausfischt... Gruß Ingo
IngoF schrieb: alles schon klar, deshalb ja auch provokant geschrieben. Evtl. hätte sich ja jemand gefunden der auch die Originalsoftware nutzt und dann einfach die Daten hithorchen möchte und diese in eine DB schreiben will und beim Programmieren/Herausfischen der Daten schneller ist ;-), da dies bei der Original Ecosoft nur über riesige Umwege / bis garnicht möglich ist. Ich habe bestimmt eher ne neue Heizung als das ich fertig bin ... ;-) > ist halt nicht einfach dem 3964R-Terminal das Handshake abzugewöhnen. > Ist halt nicht dafür gedacht das Drei Busteilnehmer an einem Serial-Port > hängen. ist schon klar, deshalb verwende ich ja auch com0com um zumindest aus einem zwei separate virtuelle COMs zu machen. Funktioniert auch soweit. In com0com bzw. hub4com kann sogar direkt die Datenweiterleitung/Flusssteuerung bestimmt werden. > > Da das 3964R-Terminal eine fertige Bibliothek verwendet müsste man die > Bibliothek entsprechen umbauen oder selber schreiben. > > Also am besten Service-Key oder eine andere Software. > > Vermutlich wäre für so kurze Mitschnitte "hTerm" besser geeignet. Am > besten das Handshake vom 3964R-Protokoll für einen Zeilenwechsel beim > hTerm einstellen. Wird dann vermutlich viel übersichtlicher. > Dann muss man aber noch die doppelten 0x10 herausfiltern. kann ich für kurze Mitschnitte / Protokollanalysen ja mal probieren, mein End-Ziel sind aber ja keine kurzen Mitschnitte ;-) > > Wenn man dem 3964R-Terminal das schreiben in die Datenbank "beibringt" > müsste man also auf den Service-Key verzichten. > > ...Oder ein komplett neues Programm schreiben dass das Handshake > ignoriert und nur die Daten herausfischt... genau, vom 3964R Terminal spreche ich ja nur weil da als Grundlage schon etwas da ist und die benötigten Daten im Trace bereits auftauchen, aber halt nicht als solche zusammenhängend erkannt werden. Ich könnte nun etwas nachschalten, was aus den erzeugten Logfiles die Daten/Protokolle heraussucht und in die DB schreibt, oder aber wie Du schon schreibst von Null anfangen... Mal schauen, zumindest scheint es nicht viele zu geben die die Original HW/SW haben und dort mithorchen wollen. Ihr habt ja alle Eure eigene HW. Thema braucht Ihr aber in dem Thread nicht weiter fortführen... wenn jemand gleiche Interessen hat kann man sich ja ggf. erstmal per PN austauschen.
:
Bearbeitet durch Admin
Giovanne Giovanne schrieb: > Mal schauen, zumindest scheint es nicht viele zu geben die die Original > HW/SW haben und dort mithorchen wollen. Ich glaub wir reden aneinander vorbei... Es macht ja in meinen Augen kein Sinn zwei Programme mitloggen zu lassen. Also entweder Original-Software ODER Eigene Software. Sicher für eine Übergangslösung bis die eigene Software läuft ist das OK. Sobald auch nur noch eine Software am Service-Key hängt haben sich die Handshake-Probleme gelöst. Deswegen macht es wenig Sinn eine Spezielle Software zu schreiben die ohne einen Dritten neben dem Service-Key funktioniert . Also zum Mittloggen um die Funktion zu erkennen ist bestimmt H-Term besser... Da ich ja keinen Service-key habe kann ich schlecht die Software dafür schreiben. Habe Dir ja meinen Quelltext im SVN zur Verfügung gestellt. Aber kann nicht beim Programmieren helfen wenn die Weiterentwicklung nicht im SVN stattfindet. Aber ich habe ja sowieso keine Langeweile, eher im Gegenteil... Gruß Ingo
IngoF schrieb: > Ich glaub wir reden aneinander vorbei... > > Es macht ja in meinen Augen kein Sinn zwei Programme mitloggen zu > lassen. > Also entweder Original-Software ODER Eigene Software. klar, wenn die Eigenentwicklung irgendwann ALLES kann was die Original Soft kann. Da werde ich aber nie hinkommen (wollen). Somit möchte ich nur mithorchen und "täglich" wichtige Daten in die DB für schnelles nachschauen schreiben. Für detaillierte Informationen ist sicherlich die Originalsoft besser, nur leider läßt sich in den Aufzeichnungen dort nicht einfach suchen geschweige denn einfach in eine DB zu schreiben. Zudem ist die Soft blockiert wenn sie 24/7 loggt/aufzeichnet. > > Sicher für eine Übergangslösung bis die eigene Software läuft ist das > OK. > > Sobald auch nur noch eine Software am Service-Key hängt haben sich die > Handshake-Probleme gelöst. > > Deswegen macht es wenig Sinn eine Spezielle Software zu schreiben die > ohne einen Dritten neben dem Service-Key funktioniert . wie oben geschrieben schon, da die Eigenentwicklung ja bzgl. Handshake garnichts machen soll. Macht ja die Originalsoft. Eigenentwicklung: Horchen, Erkennen, Wegschreiben. > > Also zum Mittloggen um die Funktion zu erkennen ist bestimmt H-Term > besser... schau ich mir an... > > Da ich ja keinen Service-key habe kann ich schlecht die Software dafür > schreiben. > > Habe Dir ja meinen Quelltext im SVN zur Verfügung gestellt. Aber kann > nicht beim Programmieren helfen wenn die Weiterentwicklung nicht im SVN > stattfindet. Ist ja noch keine Weiterentwicklung. Eher Quick & Dirty um Erfahrungen zu sammeln. Als Weiterentwicklung ist es ja nicht geeignet, da ja z.B. kein Handshake behandelt würde und somit "3964R" nicht mehr passt. Wenn ich was hätte würde ich es sofort hochladen, derzeit würde aber jeder über das Quick&Dirty lachen ;-) > > Aber ich habe ja sowieso keine Langeweile, eher im Gegenteil... > hab ich auch nicht, deshlab geht es ja nicht so schnell. Und kann nur abends/nachts weiter gehen. Zudem werde ich dann sicherlich eher eine neue Heizung haben ehe die Soft alles kann was die Originale kann. Aber Thema braucht hier nicht weiter diskutiert werden. Also Schluß damit ;-) Also kommt zurück zum Thema, würde Euch bei weiteren Bestandteilen der fehlenden Protokolle helfen. Vieles ist wohl in der Initialisierungsphase des Online-Monitoring der Eco-Soft mit ganzen Telegrammen enthalten...kann es derzeit halt nur nicht "komfortabel" lesen... ;-)
:
Bearbeitet durch User
Hi all! @Giovanne und Jürgen Herzlichen Dank für Euer Bemühen und Eure Arbeit. @Danny Hast Du vor, die MC10 Parameter (0x16) in Deine Software einzupflegen? Für meine RC35 habe ich in der EMSMessage.cpp folgendes geändert: * RETURN_ON_SIZE_MISMATCH (28, "MonitorSlow"); * RETURN_ON_SIZE_MISMATCH (18, "MonitorWW"); * RETURN_ON_SIZE_MISMATCH (17, text); Würde es Deiner Meinung nach Sinn machen, die RC20 / RC35 über eine Abfrage automatisch vorzubelegen? Falls es jemanden interessieren sollte: Meine Buderus GB162-25 T40S spuckt auch den aktuellen Warmwasserdurchfluss aus. Folgendes habe ich dazu in den folgenden Files (von Danny) ergänzt: --- Database.cpp query.execute(SensorWarmwasserDurchfluss, sensorTypeNumeric, "Warmwasserdurchfluss", readingTypeVolume, "l/min", 1); Database.h SensorWarmwasserDurchfluss = 26, static const unsigned int readingTypeVolume = 7; EMSMessage.cpp printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min", Database::SensorWarmwasserDurchfluss); www/ems/constants.php.inc define('SensorWarmwasserDurchfluss', 26); define('ReadingTypeVolume', 7); www/ems.php print_cell("WW-Durchfluß", $sensors[SensorWarmwasserDurchfluss]); --- Danke noch mal an Alle, die hier eine hervorragende Arbeit geleistet haben. Gruß aus der Wetterau Karl M.
Hallo, ich habe mir mal die Wiki Telegramme genauer angeschaut, dabei sind mir einige Fehler oder Unregelmäßigkeiten aufgefallen. Könnt Ihr den Anhang mal nachschauen? Ich frage mich, wie bei den Bits die Zählweise hier ist. Bit 1..8 gleich von links nach rechts? Ich zähle immer Bit 7..0 also Bit 0 ist bei mir rechts. Viele Grüße Franz
Hallo Franz, ich hatte damals die Bits nummeriert. Bit 1 entspricht dem Bit0 (2^0). Die 0 hiess mal dass die kein bestimmtes Bit gemeint ist. Gruß Ingo
Danke Ingo, sollte man evtl. noch ändern. Bei der Byteanzahl komme ich auch nicht weiter. Hier könnte man auch Hi und Lo dazu schreiben. Viele Grüße Franz
F. F. schrieb: > Hier könnte man auch Hi und Lo dazu schreiben. Wie meinst Du das? Wenn z.B. Ein Wert aus zwei Bytes besteht also zwei Zeilen für den Wert? Keine Ahnung ob das übersichtlicher ist. Habe jetzt einfach mal oben eine kleine Erklärung der Tabellen eingefügt und Die Bitzählweise auf 0-basiert umgestellt. Das erste Bit ist jetzt als Bit0. Gruß Ingo
Hallo, IngoF schrieb: > Die Bitzählweise auf 0-basiert umgestellt Danke, das ist für mich jetzt übersichtlicher zu lesen. Macht es einen Sinn, anstatt des Startwertes den Offset (=Startw.-5) zu nehmen? Jetzt habe ich nur noch einen Fehler bei den Bits gefunden: 08 00 34 Startw. 10 Ich habe mal einen Frage zur Antipentelzeit: 08 00 16 Startwert 11 was bedeutet der Wert in Minuten genau? Ist es die Mindeststandzeit? Da mein Brennwertgerät bei kleiner Last ständig ein- und ausschaltet habe ich mal etwas getestet. Dabei habe ich zwei Werte herausgefunden: 08 00 16 Startwert 9: Abschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist Startwert 10: Einschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist (Wert ist hier negativ). Was mir noch nicht ganz klar ist, ob der Frostschutz hier noch garantiert ist, wenn ich den Wert vom Einschaltpunkt zu tief setze. Viele Grüße Franz
> Ich habe mal einen Frage zur Antipentelzeit: > was bedeutet der Wert in Minuten genau? Ist es die Mindeststandzeit? Das ist die Zeit nach Stopp des Brenners, welche mindestens vergehen muss, bevor der Brenner wieder gestartet werden kann. Die anderen Änderungen sind im Wiki. vg Jürgen
Hallo Jürgen, Jürgen Schmied schrieb: > Das ist die Zeit nach Stopp des Brenners das muß ich nochmal überprüfen, mir ist die Zeit kürzer vorgekommen. Jürgen Schmied schrieb: > Die anderen Änderungen sind im Wiki danke, die Einheit müßte aber °C bzw. Kelvin sein. Ich habe noch etwas herausgefunden, 08 00 16 Startw. 7 Kesselleistung_max 08 00 16 Startw. 8 Kesselleistung_min? Dieser Wert geht aber immer wieder auf Null was mich interessiert, mein Kessel fährt mit einer Mindestleistung von 20%, obwohl ich weniger Leistung benötige. Kann ich diese Leistung irgendwo einstellen? Oder ist diese fest? Viele Grüße Franz
> was mich interessiert, mein Kessel fährt mit einer Mindestleistung von > 20%, obwohl ich weniger Leistung benötige. Kann ich diese Leistung > irgendwo einstellen? Der Brenner hat eine Minimalleistung, mit der er moduliert werden kann. Die kannst Du nicht unterschreiten. vg Jürgen
Jürgen Schmied schrieb: > Der Brenner hat eine Minimalleistung ... > Die kannst Du nicht unterschreiten. Stimmt. Einige, meist sicherheitsrelevante, Parameter sind "hard-coded". Die Brennerautomaten (UBA) sind universell. Für jede Geräteart und Leistungsgröße gibt es ein sogenanntes Kessel-Identifikations-Modul (aka KIM). In diesem KIM steckt ein EEPROM, auf dem diese Parameter gespeichert sind. //Niffko
Hallo, danke für die Antwort. Jürgen Schmied schrieb: > Der Brenner hat eine Minimalleistung, mit der er moduliert werden kann. > Die kannst Du nicht unterschreiten. dann muß ich die Leistung bei 20% lassen. F. F. schrieb: > Startwert 9: Abschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist > Startwert 10: Einschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist damit habe ich das ständige Ein- und Ausschalten stark reduziert. Jürgen Schmied schrieb: > Das ist die Zeit nach Stopp des Brenners Das trifft bei mir nicht ganz zu (RC30). Als Antipentelzeit habe ich 20 Minuten (0x14), den Ein- und Ausschaltpunkt um jeweils 10°C Differenz eingestellt. Nach einer Brennerlaufzeit von über einer Stunde hatte ich +10°C erreicht. Der Brenner ging aus, als Service-Code kam 0Y. Nach 6 Minuten Standzeit hatte ich eine Differenz von -10°C vom Sollwert und der Brenner sprang sofort an. Kann es sein, daß die 20 Minuten die gesamte Periode aus Brennerlaufzeit und -standzeit ist? Bei kürzere Laufzeiten hatte ich nach dem Einschaltdelta den Code 0A und der Brenner stand noch eine Weile, aber weniger als 20 Minuten. Ich habe noch eine Frage zum "Optimierung Schaltprogramm" (10 3d Startw 24) Was macht das genau? Bedeutet das bei Raumtemperaturgeführt, das die Heizung rechtzeitig einschaltet? Ich habe diesen Punkt für HK2 testweise gesetzt. Viele Grüße Franz
ich habe noch eine Unklarheit: bei UBAMonitorFast 08 00 18 Startw. 12 (Offset 07) habe ich wenn der Brenner läuft 0x25 (0010 0101) danach müßte die Gasarmatur (Bit 0) ein sein. Kesselkreispumpe (Bit 5) ist ein. Auf der Web-Seite bekomme ich hier aber Gasventil ein, Zündung ein, Kesselpumpe und Zirkulationspumpe aus. Ist Kesselpumpe und Kesselkreispumpe das gleiche? Dann stimmt etwas mit der Seite nicht.
:
Bearbeitet durch User
in Ecosofts graf. Darstellung wird Bit 5 als "Kessel 1:Heizkreis-/Zubringer Pumpe" bezeichnet und Bit 0 (Gasarmatur) als "Flammensignal". 08 00 18 12 Bit0 1 digital Gasarmatur EIN => Kessel 1:Flammensignal 08 00 18 12 Bit2 1 digital Gebläse EIN => Kessel 1:Gebläsemodulation 08 00 18 12 Bit3 1 digital Zündung EIN => Kessel 1:Zündung 08 00 18 12 Bit5 1 digital Kesselkreispumpe EIN => Kessel 1:Heizkreis-/Zubringer Pumpe 08 00 18 12 Bit6 1 digital 3-Wege-Ventil auf WW => Warmwasser:WW-Laden 08 00 18 12 Bit7 1 digital Zirkulation EIN => Warmwasser: Zirkulationspumpe in Anhang Beispiel 0x25 mit bisherigen Bezeichnungen.
:
Bearbeitet durch User
so steht es im Wiki auch, auf der Web-Seite bekomme ich aber immer "Kesselpumpe aus" obwohl das Bit 5 gesetzt ist. (0x25)
ok sorry, da kann ich nicht mitreden. Ich kenne die Webseite nicht :-(
auf Deinem Bild oben ist auch Zündung weiß und Zubr. Pumpe grün? 0x25?
auf der Web-Seite habe ich für 0x25: Gasventil ON Gebläse OFF Zündung ON Kesselpumpe OFF Zirkulationspumpe OFF 3-Wege-Ventil-WW OFF
Ich habe mal den Ablauf beim Starten und Stoppen des Brenners zusammengestellt. Da ist der Ablauf gut zu sehen. Ecosoft wird schon Recht haben ;) vg Jürgen
:
Bearbeitet durch User
die rechte Ziffer ist das der Fehlercode? Hier bekomme ich immer 0 angezeigt. Kann aber sein, weil ich kein Fehler habe und die RC30 besitze. (Evtl. wird es auch durch die Endemarkierung vom Servicecode auf Null gesetzt?).
ok, ich glaube da ist ein Fehler in emsProtokoll.h. Habe mal meine Version unter emsProtokoll_geaendert.h hochgeladen.
> die rechte Ziffer ist das der Fehlercode? Hier bekomme ich immer 0 > angezeigt. Hallo der Fehlercode ist in der FW 8bit statt 16bit. Daher meistens 0. Ich ändere das. Den Rest muss ich mir in Ruhe ansehen. vg Jürgen
A propos Dokumentationsprobleme: Kann jemand mit Durchlauferhitzer (GB152, richtig?) mal bitte posten, wie die 'Monitor WW'-Nachricht (0x34) bei ihm aussieht? Ich habe den Verdacht, dass die Doku für den Typ des WW-Systems (Byte 13) falsch ist. Ich bekomme bei mir 0x3, was laut Doku 'keins + Durchlauferhitzer' heißt - das ergibt einfach keinen Sinn. Ich denke, dass man das Ganze als Werte (d.h. 0, 1, 2, 3, 4 anstatt 1 << 0, 1 << 1, 1 << 2, 1 << 3, 1 << 4) interpretieren muss (dann käme bei mir korrekterweise 'großer Speicher' raus), ich würde das aber mal gerne noch verifizieren ;)
Hallo! Diese Bits sollten so stimmen. Die waren mal in einem Dokument (8718575620 – 09/2009 DE) drin, welches aber inzwischen nicht mehr in den Downloads zu finden ist. Das Logamatic EMS RS232 Gateway hatte anfangs mal den EMS Bus direkt unterstützt, da sind einige der Felder offiziell dokumentiert gewesen. vg Jürgen
Hallo! Ok, so wie sie dokumentiert sind, gibt es keinen Sinn. Bei mir wäre das {UBAMonitorWWMessage:WW-System: kein} AN {UBAMonitorWWMessage:WW-System: Durchlauferhitzer} AN {UBAMonitorWWMessage:WW-System: kleiner Speicher} AUS {UBAMonitorWWMessage:WW-System: großer Speicher} AUS {UBAMonitorWWMessage:WW-System: Speicherladesystem} AUS wenn man das als 0x03 "kleiner Speicher" deutet, wäre es Ok. (Sind 240L klein?). Hat jemand etwas anderes als 3 drin? vg Jürgen
Jürgen Schmied schrieb: > Logamatic EMS RS232 Gateway hatte anfangs mal den EMS Bus direkt > unterstützt, Geht das nicht mehr? Als ich damals ein EMS-Gateway kaufen wollte hieß es dass der EMS-Gateway demnächst auch den EMS-Bus unterstützen würde... Das ist aber bestimmt schon fast 10 Jahre her.. Gruß Ingo
Auf der Web-Seite steht beim RS232 Gateway: "Offenlegung Kommunikationsprotokoll zu Logamatic auf Anfrage" von EMS ist nur im Zusammenhang mit ECO-SOFT die Rede. Das Dokument, welches das EMS Protokoll dokumentiert ist nirgends mehr auf der offiziellen Seite zu finden. Ich denke auch, das "Logamatic web KM200" ist inzwischen der Nachfolger von RS232 Gateway. vg Jürgen
müßte wie im der doku/wiki passen: Monitor WW - Typ 52 Offset 8 Art des Warmwassersystems 1. Bit = kein Warmwassersystem vorhanden 2. Bit = Durchlauferhitzer 3. Bit = kleiner Speicher 4. Bit = großer Speicher 5. Bit = Speicherladesystem -> ab Ver: 3.0 6. Bit bis Bit 8 = frei
Passt ja eben nicht: bei mir steht hier 0x03 drin. Ich habe aber ein GB152 mit Speicher und nicht gleichzeitig "kein Warmwassersystem vorhanden" und "Durchlauferhitzer" ...
:
Bearbeitet durch User
ok bei GB152 kann ich auch nicht helfen. ...werde mal sehen ob ich den Datentyp 52 beim Ecosoft mal mitlauschen kann, dann kann ich zumindest sehen wie es zum GB132/EMS/160 l-Speicher passt... Edit: ist bei mir auch derzeit mit 0x03 belegt, kann ich also bestätigen, passt irgendwie nicht zur Doku. Edit2: Ecosoft weiss jedoch das ein Speicher vorhande ist ;-) Mal sehen woher ...
:
Bearbeitet durch User
Hallo, kennt ihr "Technische Information Monitordaten System 4000"? Da habe ich auf Seite 34 die Monitorwerte für Störmeldemodul Typ 0x9c gefunden. Ich denke, daß dies die Werte vom Wiki WMStatus2 bzw WMParameter sind. https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CD0QFjAB&url=http%3A%2F%2Fwww.ip-symcon.de%2Fforum%2Fattachment.php%3Fattachmentid%3D13808%26d%3D1320956568&ei=AqGsUrmrHoiAtAbP0ICQCg&usg=AFQjCNGM-sq-a6zyIivMQwbdxqWX-GnXhQ&sig2=XhjWX0LTiHP7nwxO-w5LrQ Viele Grüße Franz
Hallo! Ja, das würde sehr gut passen. Möglicherweise sind auch noch andere Bytes damit erklärbar. Muss ich mal testen, wenn ich Zeit finde ... vg Jürgen
ich habe in Wiki dieses Bit geändert: 10 00 3E 6 7 1 digital Party- Pausebetrieb es steht für Party oder Pause-Betrieb
I don't speak German, sorry ! This is easy Kevin Heidrich schrieb: > Alex Amend schrieb: >> Der KM-200 wird als V850.local angesprochen/aufgelistet mit der IP >> 192.168.178.157 >> nur leider kann ich damit so gut wie nix anfangen alles Spanisch >> Chinesisch oder sonst was für mich. > > ich habe mir mal dein Log angeschaut, und so wie es scheint geht die > Kommunikation über HTTP/80 per Binary JSON. > > ----- > > HTTP/1.0 200 The request has succeeded > Content-Type: application/json > > veSJNc+lFfrdObDjj04tWC+pGbZELyzUiQaSZli48U+ax2nFuLmVP6m9X7M/PtRmDZc/PngS > 6VF+9Pj8OG1XIj+7oCNQV9vAp0fGL9gboUhh8XdfqOcQbkH6eu1RzHJ1H/6mdPjM2ielVRed > TgYvvfhOeldH64YiUN8bfnu3cjPxSn1zR5y82nSQszQ2kK7/oRaBNHJaJ1xkVXpl1y8KQrT8 > IfzTrW356VeTa+inpSehjHXp6aiiD21SDCQPBHexaNq+MMb3ZjCppyNTUhKxspybIEuNRNYP > NEF7R/SF6rAewrwo1cLzsSB22pKqrXjxPSIbEWDCGTJDKY8suxLT5u+Dv74hIHsg0xc3fo1q > PhEf4x5XbfveedsRqPMi+ePSQr1pEkkKyYkEkksXKEHoYk4TFKaWQSdi7yilgfc/0LJKW5cp > jlnqppMN5ZIvKFZyL4Cc+Tl8CBVHbj2oBxPw/V2GnLFpvBoKAC9DZiNiBCLnSp+bI99TozqR > oalkC9H/SakHzT3hN3vMpLhj/qCOiQs6+CA968AYE0qwO80pLRPi+JTsCM0oB+ecPePkiUQq > v4m5wtVuPAUXM6Px109+VPhOeldH64YiUN8bfnu3cjOS665LPoIv0JnQrdQcebJMoRaBNHJa > J1xkVXpl1y8KQrT8IfzTrW356VeTa+inpScIiqy5T3fgAcy3RxT42S0r > > ---- > > Das ganze ist dann noch Base64 kodiert. Das Endergebnis ist dann > allerdings wiederum ernüchternd. Nichts was man so lesen könnte. Ich > dachte es wäre evtl. am Ende dann doch wieder JSON, aber da komme ich > nicht weiter. > > Gruß > Kevin To decrypt this : 1. Base64 decode 2. generate MD5 for gateway password 3. generate MD5 for user password 4. concat MD5 from gtw and MD5 of userpasw 5. use this as Key for AES decryption (AES/ECB/NoPadding) then it should become JSON human readable.
Hallo, ich baue gerade ein kleines Interface für einen RPi und beschäftige mich erstmalig mit der gezielten Abfrage von EMS-Daten. Bis jetzt hatte ich mir immer nur die benötigten Daten vom Bus gepickt. Was ich festgestellt habe ist, dass Anfragen an den Master(0x08) sehr oft beim ersten mal nicht beantwortet werden. Das nächste mal, beim darauf folgenden Polling, klappts dann aber immer. Kennt dieses Verhalten jemand, oder habe ich noch irgendeinen Knoten in der Software? //Niffko
Hallo Niffko Bei mir ist es schon länger her dass ich testweise mal ein paar Werte abgefragt habe. Die Antwort kam immer nach der ersten Abfrage. (Datum/ Uhrzeit und Partymodus/Urlaub. Nur Abfragen an die 0x09 dauerten länger.. Gruß Ingo
Hallo Jürgen, mir ist mit Telnet aufgefallen, das das Brennwertgerät die gesendeten Daten annimmt ich aber nicht immer auf eine Anfrage eine Antwort bekomme, manchmal fehlen auch ein paar Bytes. Auch bei der JSON-Abfrage bekomme ich nicht immer eine Antwort. Vielleicht hilft das weiter.
IngoF schrieb: > Bei mir ist es schon länger her dass ich testweise mal ein paar Werte > abgefragt habe. Die Antwort kam immer nach der ersten Abfrage. (Datum/ > Uhrzeit und Partymodus/Urlaub. Diese beiden Dinge kommen ja auch von der RC ;) Mir ist beim Abfragen der Fehlercodes auch schon aufgefallen, dass meistens keine Antworten vom UBA kommen. Ich habe dann einen Retry-Mechanismus eingebaut: https://github.com/maniac103/ems-collector/commit/649eab5cf6726b76e9270baf39f71399ec99dd5c Nach meiner Beobachtung macht die RC30 genau das gleiche, scheint also normal zu sein.
:
Bearbeitet durch User
>[...unbeantwortete Abfragen...] ok, dann scheint das offensichtlich normal zu sein. Danny Baumann schrieb: > Ich habe dann einen Retry-Mechanismus eingebaut ... joa, habe ich auch getan. @Danny Mal interessenhalber: Sendest Du bei nicht erfolgter Antwort noch eine Busfreigabe(0x0B) oder lässt Du einfach "weiterlaufen"? //Niffko
Niffko _ schrieb: > @Danny > Mal interessenhalber: Sendest Du bei nicht erfolgter Antwort noch eine > Busfreigabe(0x0B) oder lässt Du einfach "weiterlaufen"? Wenn ich mich recht entsinne (der Lowlevel-Kram ist schon so lange her ;) ), lässt mein Ethersex-Code an der Stelle einfach weiterlaufen. Das 0xb wird nur gesendet, wenn entweder eine Polling-Anfrage reinkam (d.h. 0x8b) oder eine Antwort reinkam. Probleme habe ich dadurch noch keine festgestellt.
Danny Baumann schrieb: > ... einfach weiterlaufen. mach ich genau so ... auch keine Probleme. //Niffko
Danny Baumann schrieb: > Nach meiner Beobachtung macht die RC30 genau das gleiche, scheint also > normal zu sein. Was macht denn die RC30? Fragt sie die Telegramme dann aktiv selber noch mal ab. Beim Party-Telegramm das ja aus vier oder fünf Teilen besteht gibt es etwas ähnliches. Ab und zu fehlt dann das letzte Telegramm (aus Zeitgründen?). Dort wird dann aber das Telegramm kurz später nochmal automatisch komplett nachgeschickt. Aber das wird dann wohl nur die RC30/35 machen. Gruß Ingo
Hi > To decrypt this : > 1. Base64 decode > 2. generate MD5 for gateway password > 3. generate MD5 for user password > 4. concat MD5 from gtw and MD5 of userpasw > 5. use this as Key for AES decryption (AES/ECB/NoPadding) > then it should become JSON human readable. does not work for me. Gateway pass ist printed on the Label User Pass ist Pass fpr the ios App ?? AES 256? can you please give an example tried it with openssl and mcrypt (php) - NO Success
Hallo, mich hat die unbekannte Verschlüsselung der KM200 so genervt, dass ich mich ein paar Abende ans Beschnüffeln der iOS-App gemacht habe. Mit Erfolg :) Der Schlüssel basiert wie von Moustic beschrieben auf dem Gateway-Passwort und dem Benutzerpasswort, ist allerdings mit einem geheimen Salt versehen. Hat man diesen wird es gleich hell. Verschlüsselung ist AES 256 mit ECB, Padding macht die App mit PCKS#7 und das Gateway mit Null-Bytes. Damit alle etwas davon haben hier eine Referenzimplementierung in PHP. Viel Spaß :)
1 | // IP Adresse oder DNS-Hostname des KM200 |
2 | define( "km200_gateway_host", '192.168.1.7', true ); |
3 | // Gerätepasswort. Achtung: Ohne Bindestriche und in ASCII! |
4 | define( "km200_gateway_password", 'abcdABCDabcdABCD', true ); |
5 | // Eigenes Passwort wie in der App vergeben |
6 | define( "km200_private_password", 'geheim', true ); |
7 | // Dreh- und Angelpunkt: Der geheime Salt der MD5-Hashes zur AES-Schlüsselerzeugung |
8 | $MD5Salt = pack( |
9 | "c*", |
10 | 0x86, 0x78, 0x45, 0xe9, 0x7c, 0x4e, 0x29, 0xdc, |
11 | 0xe5, 0x22, 0xb9, 0xa7, 0xd3, 0xa3, 0xe0, 0x7b, |
12 | 0x15, 0x2b, 0xff, 0xad, 0xdd, 0xbe, 0xd7, 0xf5, |
13 | 0xff, 0xd8, 0x42, 0xe9, 0x89, 0x5a, 0xd1, 0xe4 |
14 | ); |
15 | define( "km200_crypt_md5_salt", $MD5Salt, true ); |
16 | // Erste Hälfte des Schlüssels: MD5 von ( Gerätepasswort + Salt ) |
17 | $key_1 = md5( km200_gateway_password . km200_crypt_md5_salt, true ); |
18 | // Zweite Hälfte des Schlüssels: MD5 von ( Salt + privates Passwort ) |
19 | $key_2 = md5( km200_crypt_md5_salt . km200_private_password, true ); |
20 | define( "km200_crypt_key", $key_1 . $key_2, true ); |
21 | |
22 | function km200_Decrypt( $decryptData ) |
23 | { |
24 | $decrypt = mcrypt_decrypt( |
25 | MCRYPT_RIJNDAEL_128, |
26 | km200_crypt_key, |
27 | base64_decode( $decryptData ), |
28 | MCRYPT_MODE_ECB, |
29 | '' |
30 | ); |
31 | // Entferne zero padding |
32 | $decrypt = rtrim( $decrypt, "\x00" ); |
33 | // Entferne PKCS#7 padding |
34 | $decrypt_len = strlen( $decrypt ); |
35 | $decrypt_padchar = ord( $decrypt[ $decrypt_len - 1 ] ); |
36 | for ( $i = 0; $i < $decrypt_padchar; $i++ ) |
37 | { |
38 | if ( $decrypt_padchar != ord( $decrypt[$decrypt_len - $i - 1] ) ) |
39 | break; |
40 | } |
41 | if ( $i != $decrypt_padchar ) |
42 | return $decrypt; |
43 | else |
44 | return substr( $decrypt, 0, $decrypt_len - $decrypt_padchar ); |
45 | } |
46 | |
47 | function km200_GetData( $REST_URL ) |
48 | { |
49 | $options = array( |
50 | 'http' => array( |
51 | 'method' => "GET", |
52 | 'header' => "Accept: application/json\r\n" . |
53 | "User-Agent: TeleHeater/2.2.3\r\n" |
54 | ) |
55 | ); |
56 | $context = stream_context_create( $options ); |
57 | return json_decode( |
58 | km200_Decrypt( |
59 | file_get_contents( |
60 | 'http://' . km200_gateway_host . $REST_URL, |
61 | false, |
62 | $context |
63 | ) |
64 | ) |
65 | ); |
66 | } |
67 | |
68 | // Beispielaufruf |
69 | $REST_Service = '/system'; |
70 | $json = km200_GetData( $REST_Service ); |
71 | echo "Service: " . $REST_Service . "\n"; |
72 | var_dump( $json ); |
Hallo Andreas Danke für die Mühe, bei mir kommt das Ergebnis. Service: /system object(stdClass)#1 (3) { ["id"]=> string(7) "/system" ["type"]=> string(7) "refEnum" ["references"]=> array(6) { [0]=> object(stdClass)#2 (2) { ["id"]=> string(13) "/system/brand" ["uri"]=> string(32) "http://192.168.0.48/system/brand" } [1]=> object(stdClass)#3 (2) { ["id"]=> string(11) "/system/bus" ["uri"]=> string(30) "http://192.168.0.48/system/bus" } [2]=> object(stdClass)#4 (2) { ["id"]=> string(18) "/system/systemType" ["uri"]=> string(37) "http://192.168.0.48/system/systemType" } [3]=> object(stdClass)#5 (2) { ["id"]=> string(15) "/system/sensors" ["uri"]=> string(34) "http://192.168.0.48/system/sensors" } [4]=> object(stdClass)#6 (2) { ["id"]=> string(20) "/system/healthStatus" ["uri"]=> string(39) "http://192.168.0.48/system/healthStatus" } [5]=> object(stdClass)#7 (2) { ["id"]=> string(17) "/system/appliance" ["uri"]=> string(36) "http://192.168.0.48/system/appliance" } } } Das sagt mir leider gar nichts. lg Stefan
Hallo Stefan, > Danke für die Mühe, bei mir kommt das Ergebnis. [...] > Das sagt mir leider gar nichts. Das ist der Variablen-Dump des PHP-Objekts, welches vom Gateway geholt wurde. Es wird prinzipiell über eine REST-API mit JSON angesprochen. Im Beispielcoding wird der Aufruf durch die Funktion json_decode() geleitet und damit zum PHP-Objekt. Im IP-Symcon-Forum gibt es auch weitere REST-URLs: http://www.ip-symcon.de/forum/threads/25103-Buderus-Logamatic-Web-KM200 Ciao, Andreas
Hallo, na endlich hat sich einerf die Mühe gemacht und eine Lösung zur Dekodierung des json strings gefunden. Ich hatte vor ca. einem Jahr auch versucht hier etwas zu finden, war aber an der dekodierung gescheitert. Voller Vorfreude habe ich Dein script dann auch direkt an meinem gateway probiert. Komischerweise erhalte ich nichts zurück. Ich dachte zuerst, dass irgendein pw nicht passt, ader das war es nicht. Mein gateway antwortet nur noch mit: Sorry, the requested file does not exist on this server. Egal welche URL (hier z.B. auf /system) Das war aus meiner Erinnerung mal anders. Ich bekam immer diese endlose kryptische json Zeichenkette. Ich habe dann mal den Traffic der app und dem gateway gesnifft. Die URLs sind gleich. Die App ruft die gleichen auf. Hast Du eine Idee was das sein kann?
Hallo, > Voller Vorfreude habe ich Dein script dann auch direkt an meinem gateway > probiert. Komischerweise erhalte ich nichts zurück. Ich dachte zuerst, > dass irgendein pw nicht passt, ader das war es nicht. Mein gateway > antwortet nur noch mit: Sorry, the requested file does not exist on this > server. Egal welche URL (hier z.B. auf /system) > Das war aus meiner Erinnerung mal anders. Ich bekam immer diese endlose > kryptische json Zeichenkette. > Ich habe dann mal den Traffic der app und dem gateway gesnifft. Die URLs > sind gleich. Die App ruft die gleichen auf. > Hast Du eine Idee was das sein kann? Das sieht mir nach einem falsch gesetzten "User-Agent"-Header aus. Beim meiner Verbindung hatte ich "TeleHeater/2.2.3" gesnifft, das kann bei Dir je nach Softwarestand auch etwas anders sein. Ist die neuste App installiert und auf dem Gateway die neuste Firmware (Gateway ins Internet lassen, installiert automatisch die neuste Version)? Meine Firmware-Version ist 01.05.04. Ciao, Andreas
Hallo, ja ich dachte auch schon an den falschen Header. Früher hatte meine App den Useragent "Buderus%20iCom/2.01". Jetzt meldet sich die App auch mit TeleHeater/2.2.3 Die Firmware meins Gateway ist 01.09.04 Hardware Version iCom_Low_v1 App Version 2.2.3 Sieht so aus als hätte ich eine neuere Firmware aus Du. Gateway ist dauerhaft mit dem Internet verbunden. Somit sollte die auch sehr aktuell sein. Ich bekomme immer die Meldung: Sorry, the requested file does not exist on this server. Auch wenn ich mir einenen get request baue der die richtigen Header hat. Irgendwie will das Gateway nicht mehr die den jason request senden. Eventuell eine Änderung in der Firmware?
Hallo, > ja ich dachte auch schon an den falschen Header. Früher hatte meine App > den Useragent "Buderus%20iCom/2.01". Jetzt meldet sich die App auch mit > TeleHeater/2.2.3 > Die Firmware meins Gateway ist 01.09.04 > Hardware Version iCom_Low_v1 > App Version 2.2.3 Ich habe die Hardware Version iCom_Low_NSC_v1, vielleicht daher auch der andere Firmware-Stand. > Sieht so aus als hätte ich eine neuere Firmware aus Du. Gateway ist > dauerhaft mit dem Internet verbunden. Somit sollte die auch sehr aktuell > sein. > Ich bekomme immer die Meldung: Sorry, the requested file does not exist > on this server. Auch wenn ich mir einenen get request baue der die > richtigen Header hat. Irgendwie will das Gateway nicht mehr die den > jason request senden. Gib dem Request mal alle Header mit die die App auch sendet, ich habe nur einen Teil davon eingebaut. Wichtig: Bei jedem Header die Groß- und Kleinschreibung beachten! Im IP-Symcon-Forum gibt es eine Antwort die darauf schließen lässt, dass es mit deinem Soft- und Hardware-Stand wohl funktioniert: http://www.ip-symcon.de/forum/threads/25103-Buderus-Logamatic-Web-KM200?p=230020#post230020 Vielleicht ist irgendwo ein Übertragungsfehler, versuch auch mal ein Copy&Paste von dem Coding aus dem o.g. Forum. Ciao, Andreas
Hallo, es liegt nicht an dem Script. Das andere will auch nicht. Irgendwie antwortet mein Gateway auf Abfragen die nicht von "Buderus" kommen immer mit dieser Fehlernachricht. Da muss noch etwas sein. Ja die zusätzlichen header hatte ich auch schon definiert. Das war es aber nicht. Übrigens, das script von der anderen Seite kann jetzt auch Werte setzen und nicht nur lesen. Irgendwie muss es gehen, denn meine Firmware und Hardware scheint bei anderen zu gehen.
Gelöst: Ich nehme alles zurück und behaupte nun das Gegenteil. Es läuft. Bei mir ist der Header irgendwie anders. Habe noch mal gesnifft und 1zu1 den Headerv der App eingetragen Danke
Vielleicht kannst du mal erklären, wie das script zu nutzen ist? wenn ich es direkt aufrufe mit php dein script läuft es durch zeigt aber nichts an. ich dachte evtl muss ich dem script ein parameter übergeben wie z.b php deinscript /system/sensors/temperatures aber auch da läuft es durch gibt aber keine meldung. habe es mal mit dem html code versucht von http://www.ip-symcon.de/forum/threads/25103-Buderus-Logamatic-Web-KM200/page4 aber dort zeigt die page nur service value selsbt wenn ich die Service ergänzt habe. ich habe eine GB162 mit RC300
Egal was ich versuche, ich bekomme immer bool(false) als meldung Was musstest du ändern damit es bei dir lief?
Mann benötigt schon die module dazu... sudo php5enmod mcrypt sudo service apache2 restart
Hallo, gibt es eine möglichkeit den Netio über Levelshifter direkt mit dem Raspi zu verbinden um das LAN interface einzusparen? Hier: Beitrag "Re: EMS > Adapter > NetIO > Raspi" wird das auch gefragt aber bis jetzt keine Antwort. Ich will mir eine kleine Schaltung mit dem Mega644 bauen damit ich nicht den ganzen Netio dafür verwenden muss (ich hab nur einen und der ist für was anderes) Die Sache soll dann an meiner Heizung permanent dran bleiben damit ich etwas loggen kann... Marius.
Hi Marius, ich versuche was ähnliches mit einem ESP8266 Modul. Da meine Platine - im Prinzip der reine EMS - RxTx Konverter von Ingo/Niffko - noch nicht fertig ist, dauert das allerdings noch ein wenig. Die Platine hat einen Bestückungsplatz für ein ESP01-Modul sowie eine Arduino-kompatible FTDI Steckerleiste (J1). Bei Interesse gibste einfach Bescheid.
:
Bearbeitet durch User
Hallo Jungs, toller Thread zum Thema, der mir endlich ermöglichen wird, meine Heizung (GB162/15 mit RC35) vernünftig fernzusteuern und die Einbindung des solaren Überschusses in die Heizung optimal gestalten zu können! 1.) Hat schon mal jemand herausgefunden mit welchen Funtionen das Störmeldemodul EM10 den Brenner fernsteuert ? Mich interessiert insbesondere die Leistungs- bzw. Temperatur- anforderung. 2.) Wie funktioniert dabei das Zusammenspiel mit einer evt. parallel vorhanden Steuerung z.B. einer RC35 ? Damit meine ich das Problem, das es bei gleichzeitigem Vorhandensein eines EM10 und einer RC35 prinzipiell 2 unterschiedliche Wärmeanforderungen an den Kessel im System gibt. Wie funktioniert das dann? Wer hat Vorrang? Grüße Stefan aus Berlin
:
Bearbeitet durch User
Hi all, am 13.07. hat Baumeister folgendes geschrieben: > Gelöst: >Ich nehme alles zurück und behaupte nun das Gegenteil. Es läuft. Bei mir > ist der Header irgendwie anders. Habe noch mal gesnifft und 1zu1 den > Headerv der App eingetragen Ich stehe nun vor dem gleichen Problem (habe ein KM50) und bekomme exakt die gleiche Antwort. Ist hier bekannt, wie Baumeister das gelöst hat, und was im Header nun stehen muß? Vielen Dank
Hallo, arbeitet noch jemand am Reverse der aktuellen EMS-Protokollbestandteile z. B. der RC300? Ich meine alle bisher unbekannten Messages. Ich habe mal einige Dinge geloggt und bin dabei mich mit einigen Lines vom Typ 0xff zu beschäftigen. Z. B. habe ich ein paar Werte gefunden, welche die RC300 beim Ändern von Auto in Manuell ändert. (Kessel-Soll und eingestellte Raumtemp.) Um nichts doppelt zu machen: hat schon jemand Fortschritte mit diesen Telegrammen gedacht? Ich hoffe, der Thread wird zu diesem Zweck noch benutzt... Gruß Fabian
Fa Ke schrieb: > Um nichts doppelt zu machen: hat schon jemand Fortschritte mit diesen > Telegrammen gedacht? Hallo FaKe hast Du Lust und Zeit das in das EMS-Wiki einzupflegen? Oder kannst Du Deine Erkenntnisse zur weitergeben damit ich sie ins Wiki einbauen kann? Wenn man zusammen an einer Baustelle arbeitet wird es meistens einfacher. Habe leider "nur" EMS ohne "+" kann da selber nichts herausfinden. Wer hat denn alles dieses "+"? Gruß IngoF
Habe schon mal Platz für die Infos geschaffen. Ein Teil der EMS Seiten habe ich schon mal hein kopiert. Falls es Gemeinsamkeiten von EMS und EMS+ gibt kommen die dann etwas höher in den gemeinsamen Teil. Wer Infos hat gerne hier posten... Falls jemand selber einpflegen will ist auch ganz schnell ein Benutzer im Wiki eingerichtet. Die Automatisierte Anmeldung musste ich wegen SPAM leider "abschalten". Gruß IngoF
Hallo Ingo, danke für die "Vorarbeit". Da ich die Daten in Access einlese um sie schneller auszuwerten zu können, habe ich erst mal ein paar Änderungen an den Modulen EmsMessage.cpp und IoHandler.cpp gemacht. Ziel war die einheitliche Anzeige von raw IO-Bytes und Messages. Außerdem habe ich die hex-Anzeige der IO-Bytes ergänzt (z. B. aus 00 wird 0x00 und aus 0x2 wird 0x02, dann lassen sich Zeilen direkt untereinander legen) und einen TimeStamp wie bei Messages hinzugefügt. Vorher sah die Anzeige so aus:
1 | IO: Got bytes 0xaa 0x55 0x11 0x8 00 0x7 00 0xb 0x1 00 00 00 00 00 00 0x1 00 00 00 00 0x4 |
2 | MESSAGE[14.10.2014 15:48:13]: source 0x08, dest 0x00, type 0x07, offset 0, data: 0x0b 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 |
Damit man die raw Bytes besser vergleichen und zeitlich korrekt zuordnen kann, jetzt diese Formatierung:
1 | IOBytes[22.10.2014 15:52:54]: 0xaa 0x55 0x08 0x10 0x00 0xff 0x00 0x01 0x67 0x00 0x00 0x89 |
2 | MESSAGE[22.10.2014 15:52:55]: source 0x10, dest 0x00, type 0xff, size 0x08, offset 0, data: 0x01 0x67 0x00 0x00 |
Ach so, die Länge (size) habe ich mit eingefügt. Bei den Messages mit Typ 0xff gibt es verschiedene Längen, welche jeweils zusammengehören. Daher nimmt die eindeutige Länge vorerst eine Art virtuellen Typ des Telegramms ein. Wenn jemand eine bessere Idee hat, ich bin für alles offen... ;) Grüße Fabian
Juergen O. schrieb: > Hi Marius, > ich versuche was ähnliches mit einem ESP8266 Modul. Ich bin zwar nicht Marius, bin aber trotzdemsehr interessiert an deinem Projekt. Ist es mittels Ethersex überhaupt möglich die Daten ohne Netzwerk an den Raspi zu übertragen? Die Software auf dem Raspi muss ja dann auch angepasst werden (der Collectord wenn ich mich richtig erinnere). Die Hardware ist nicht so das Problem nur mit der Software steige ich da nicht so ganz durch... Ich würde mir halt gerne die Netzwerkgeschichte Sparen da der Raspi direkt neben dem EMS-Platinchen montiert wird (in einer großen Aufputzkiste)... Grüße Andy
Nachtrag: Ich habe mich etwas eingelesen und meine nun das es behandlungstechnisch auf der Raspi-Seite egal ist ob die Daten über Kablegebundenes Netzwerk oder über Wlan kommen. Ist das Korrekt?
Hallo, könnte jemand mal einen Mitschnitt eines EmsPlus Systems posten. Im Speziellen interessieren mich Anfragen an den RC300. Ich habe an meinem EMS System einen RC300 montiert und bin auf der Suche nach der Raumtemperatur. Wie es aussieht, werde ich die aktiv abfragen müssen. Besten Dank im Voraus! //Niffko
Hallo, warum sind bei der EMS Schaltung die Widerstände R5/R6 am Ausgang des oberen Komparators? Da der ATmega ja mit 5V Pegel Arbeitet könnte R5 ja wegfallen oder? Der Pull-Up ist ja notwendig da der LM393 einen Open Collector Ausgang hat. Aber der Widerstand R5 in der Leitung zum NetIO macht für mich irgendwie keinen Sinn. Hab ich da was übersehen? Grüße Andy
@Andy: An sich hast Du recht, bei gleichen Pegeln wäre der Widerstand nicht notwendig. Aber oft koppelt man solche Systeme mit Widerständen, sog. Line-Widerständen. In dieser Hinsicht war ich auch über den Eingang an Pin6 ohne diesen Linewiderstand verwundert. Aber sicher entstammt das dem ursprünglichen Schaltplan... @Niffko Ich zeichne seit gut zwei Wochen alle Daten wie oben beschrieben auf. Alle paar Tage beginne ich ein neues File. Wie viel willst Du haben und wie soll ich es Dir zu senden? Ich bin leider wegen anderer Baumaßnahmen noch nicht zum Auswerten gekommen. Ich steuere den Ofen derzeit behelfsmäßig über das eingebaute KM50. Da sollte folglich einiges in Richtung RC300 dabei sein. Leider antwortet das Modul oft nicht und hängt sich ca. einmal die Woche komplett auf. Da hilft nur Stecker ziehen. Werde ich bei Gelegenheit mal bei Buderus reklamieren. Gruß Fabian
Hallo! R5 soll warscheinlich die IC's schüzten, falls der Ausgang vom uC auch auf Output geschaltet ist und beide Ausgänge dann gegeneinander arbeiten. Jürgen
Jürgen Schmied schrieb: > falls der Ausgang vom uC auch > auf Output geschaltet ist und beide Ausgänge dann gegeneinander > arbeiten Das sollte exakt die Erklärung sein. Ich hatte vergessen, auf den Schutz-Charakter der Rs hinzuweisen. Jürgen hat es auf den Punkt gebracht. Danke! Gruß Fabian
Hab' was Neues zum Thema EmsPlus (zumindest habe ich es noch nirgends gelesen). Danke an Fabian für die Log-Daten! Es betrifft die Telegramme vom Typ "FF", die mit EmsPlus aufgetaucht sind. "FF" ist hier weniger der Telegrammtyp als vielmehr eine Art Marker für ein Telegramm mit erweitertem Typenumfang (16Bit). Und da ein Beispiel mehr als 1000 Worte sagt ... Anfrage: 0B 90 FF 00 0A 01 B9 CRC 0B Sender 90 Empfänger FF Marker EmsPlus 00 Offset 0A Anzahl Bytes 01B9 Telegramm Typ Antwort: 10 0B FF 00 01 B9 Data CRC 10 Sender 0B Empfänger FF Marker EmsPlus 00 Offset 01B9 Telegramm Typ In Fabians Log gibt es noch Telegramme vom "Typ" F6, F7 und F9, bei denen es sich anscheinend auch um den neuartigen Telegrammtyp handelt. //Niffko
Hallo Niffko, ich hatte diese Entdeckung auch bereits gemacht, war mir jedoch nicht sicher, daher die Einstufung vorerst nach der Länge. Hier mal eine kurze Gruppierung in Access: S1 Source Dest Typ Offs T1 T2 B7 B8 B9 0x08 0x10 0x00 0xff 0x08 0x01 0xa5 0x00 0x10 0x53 0x08 0x10 0x00 0xff 0x06 0x01 0xa5 0x2c 0x1e 0x7f 0x08 0x10 0x00 0xff 0x08 0x01 0xa5 0x00 0x0b 0x48 0x08 0x10 0x00 0xff 0x08 0x01 0xa5 0x05 0xa0 0xe6 0x08 0x10 0x00 0xff 0x06 0x01 0xa5 0x2f 0x2f 0x4d 0x08 0x10 0x00 0xff 0x08 0x01 0xa5 0x00 0x0b 0x48 0x08 0x10 0x00 0xff 0x06 0x01 0xa5 0x2c 0x1e 0x7f 0x08 0x10 0x00 0xff 0x06 0x01 0xa5 0x2f 0x2f 0x4d 0x08 0x10 0x00 0xff 0x08 0x01 0xa5 0x05 0xa0 0xe6 0x08 0x10 0x00 0xff 0x00 0x01 0x67 0x00 0x00 0x89 das sind Werte die innerhalb weniger Minuten geloggt wurden. Der letzte fällt bei gleicher Länge in diesem Beispiel aus der Reihe. Aus obiger Reihe (demnach vom Typ 0xFF 0x01 0xa5) habe ich bereits zwei Werte vom RC300 identifizieren können (hier ohne Trailer 0xaa 0x55): 0x1f 0x10 0x00 0xff 0x00 0x01 0xa5 0x80 0x00 0x01 0x2c 0x21 0x00 0x2c 0x1e 0x00 0x8e 0x03 0x03 0x01 0x00 0x8e 0x00 0x53 0x00 0x00 0x11 0x01 0x03 0xff 0xff 0x00 0xb4 und 0x1f 0x10 0x00 0xff 0x00 0x01 0xa5 0x80 0x00 0x01 0x2f 0x21 0x00 0x2f 0x2f 0x05 0xa0 0x02 0x03 0x01 0x00 0x8d 0x00 0x54 0x00 0x00 0x11 0x01 0x02 0xff 0xff 0x00 0xaa Ich habe die Raum-Soll-Temp. von 22,0° (0x2c) auf 23,5° (0x2f) geändert und dabei hat sich die Vorlauf Solltemperatur von 33° (0x21) auf 37° (0x25) geändert. Das ist eindeutig, habe es mehrfach auch mit anderen Werten getestet. Die Raumtemp. scheint in zwei Spalten zu stehen. Keine Ahnung warum. Nicht viel, aber ein Anfang... Gruß Fabian
Hallo, mir ist gerade mal aufgefallen dass 0xff z.B. immer bei Quelle 0x10 Ziel 0x00 aufgetaucht ist. Sobald aber 0x48 in Quelle oder Ziel auftaucht kommt immer 0xf7 oder 0xf6 Dabei unterscheidet sich ja nur das Bit0. Wer ist den 0x48? Vielleicht bringt es was wenn man nur die Telegramme mit >=0xf0 herausfiltert und nach Absender oder Ziel sortiert. Vielleicht gibt es ja einen Zusammenhang mit den neuen Telgrammtypen (0x01a5) Gruß IngoF
Hallo Ingo, IngoF schrieb: > > Wer ist den 0x48? > ich hatte weiter oben beschrieben, dass ich über das eingebaute KM50 auf die Regelung des Ofens mittels REST-Api zugreife. Folglich sollten dort Informationen ausgetauscht werden. Übrigens: ich sende zum Aktivieren des Ofens 22° und zum deaktivieren 15° als temporäre Temperatur (wie beim manuellen Ändern der eingestellten Temperatur im auto-Modus). Auch das sollte sich finden lassen. Gruß Fabian
Hallo zusammen, ich habe auf dem EMS+ ein paar Daten identifiziert: Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureRoomSetpoint Antwort: 10 f9 00 ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2: 0a: min: 5°C 2a: ???: 21°C? 3c: max: 30°C 2a: value: 21°C Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/eco Antwort: 10 f9 00 ff 01 b9 04 1f 00 00 00 0a 00 00 00 1e 00 00 00 2d 00 00 00 22 Wieder Faktor 2: 0a: min: 5,0°C 1e: ???: 15,0°C? 2d: max: 22,5°C 22: value: 17,0°C Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/comfort2 Antwort: 10 f9 00 ff 01 b9 02 0f 00 00 00 23 00 00 00 2a 00 00 00 3c 00 00 00 2e Wieder Faktor 2: 23: min: 17,5°C 2a: ???: 21,0°C? 3c: max: 30,0°C 2e: value: 23,0°C Abfrage auf dem KM200: /heatingCircuits/hc1/fastHeatupFactor Antwort: 10 f9 00 ff 01 af 0a 17 00 00 00 01 00 00 00 00 00 00 00 64 00 00 00 00 Diesmal Faktor 1: 01: min: 1% 00: ???: 0%? 64: max: 100% 00: value: 0% Ich vermute mal, dass die 3x 00 vor den Daten für hk4...hk2 reserviert sind. Grüße, Torsten
Hello all, Sorry but my German writing is not good enough, but ready no problem. I'm already for a year or so ready all your interesting studies and hope to "control" my Buderus also. My setup here is: RC35 BC 10 controller GB125 with BE2.3 (Heater on oil) LT135 (Boiler) I build the EMS-NetIO-adaptor and use the Pollin NET-IO with the Ethersex code. I have also compiled the ems collector on a Linux system. I can communicate via the browser with the EMCD On the UART RX port of the AVR is data comming in. But with the emcd?ems stats I get nothing. Can some please help in getting this running ??? See also the ems_stats and ems_UART_dump Many thanks Maarten von Belgiem
Looks like your ems-board is out of order or the serialSpeed is wrong. You are receiving wrong data. 9600 8N1 should be OK for the EMS-Bus. I suppose the Counters are still at zero because the are no "framing-bytes" (aa 55). Is this the circuit, you have built: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#hardware
Torsten Georg schrieb: > 10 f9 00 ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a Hallo Thorsten, Sind das die ganzen Telegramme oder nur die Nutzlast? Wenn ich es richtig verstanden habe sollte nach dem 0xff als Datentyp erst die Länge und dann ein 16-Bit Telegrammtyp kommen? Gruß IngoF
IngoF schrieb: > I suppose the Counters are still at zero because the are no > "framing-bytes" (aa 55). You're confusing EMS UART data with preprocessed data. There's no 0xaa 0x55 to be expected on the EMS, and the NET IO outputs its data via LAN, not UART ;) Still, this looks like invalid data, so something is probably wrong in the hardware.
Danny Baumann schrieb: > You're confusing EMS UART data with preprocessed data. Das stimmt.. Warum zählt denn "Bytes total:0" nicht hoch? sind das nur die Bytes der Fehlerfreien Telgramme? Hätte jetzt vermutet die kompletten Empfangenen Bytes.
IngoF schrieb: > Danny Baumann schrieb: >> You're confusing EMS UART data with preprocessed data. > > Das stimmt.. > > Warum zählt denn "Bytes total:0" nicht hoch? sind das nur die Bytes der > Fehlerfreien Telgramme? Hätte jetzt vermutet die kompletten Empfangenen > Bytes. Ups manchmal könnte denken helfen ;-) Der NetIO schickt ja nur Fehlerfreie Telegramme weiter. Also kann Dein Collector ja nichts hochzählen was er nciht bekommt..
IngoF schrieb: > IngoF schrieb: >> Danny Baumann schrieb: >>> You're confusing EMS UART data with preprocessed data. >> >> Das stimmt.. >> >> Warum zählt denn "Bytes total:0" nicht hoch? sind das nur die Bytes der >> Fehlerfreien Telgramme? Hätte jetzt vermutet die kompletten Empfangenen >> Bytes. > > Ups manchmal könnte denken helfen ;-) > > Der NetIO schickt ja nur Fehlerfreie Telegramme weiter. Also kann Dein > Collector ja nichts hochzählen was er nciht bekommt.. Richtig. Die Anzeige kommt allerdings vom NET IO, was fehlerhafte Daten durchaus zählt ;) Ich nehme mal an, dass das NET IO schon gar kein Framing (d.h. Breaks) sieht und deshalb gar nicht erst anfängt, die Daten zu interpretieren.
IngoF schrieb: > Looks like your ems-board is out of order or the serialSpeed is wrong. > You are receiving wrong data. > 9600 8N1 should be OK for the EMS-Bus. > > I suppose the Counters are still at zero because the are no > "framing-bytes" (aa 55). > > Is this the circuit, you have built: > http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#hardware Dear Ingo, Thanks a lot for your reaction, and the great work you guys make here. Yes indeed I used this circuit, connected to the "EMS" from my BC10 and when I measure with my scope I see the expected signals and levels, all looks clean. I see no framing start (aa 55) however I see a lot of "3F" connecting Putty via an MAX. I indeed can also to the conclusion it is NOT the Net-IO with the Ehtersex, but now already for months (with pause) I'm stuck here. Any other idea how to debug ? Best regards Maarten
Are you using the 3.5mm service connector for connection? If yes: don't, but use the normal EMS bus connectors (where other modules and/or RC35 are connected)
Hi, Maarten H schrieb: > I see no framing start (aa 55) however I see a lot of "3F" perhaps a timing issue. are the fuses in the right order? (e7) Fuse Low Byte (FLB) (dc) Fuse High Byte (FHB) (ff) Extended Fuse Byte (EFB) Greets Karl M.
Maarten H schrieb: > connecting Putty via an MAX. maybe thats the problem. an USB-Serial-Cable wit a max232 has RS232-level. The board ist designed for the serial-port with TTL-level. You must use an USB-TTL-Serial-Cable to check if the ems-board works fine. if you do not have a TTL-Cable you can swap the both inputpins 2&3 of IC1A. But do not forget to swap back if you want to use it with your AVR. Or you can put an CMOS Inverter between the output of the ems-board and the RX of the serial-cable. Or is the serial-port connector at the AVR-port a RS232-version, too?
IngoF schrieb: > Maarten H schrieb: >> connecting Putty via an MAX. > > maybe thats the problem. > > an USB-Serial-Cable wit a max232 has RS232-level. The board ist designed > for the serial-port with TTL-level. You must use an > USB-TTL-Serial-Cable to check if the ems-board works fine. > > if you do not have a TTL-Cable you can swap the both inputpins 2&3 of > IC1A. > But do not forget to swap back if you want to use it with your AVR. > > Or you can put an CMOS Inverter between the output of the ems-board and > the RX of the serial-cable. > > Or is the serial-port connector at the AVR-port a RS232-version, too? Hi Ingo, I have an invertor added behind the EMS-NetIO-adaptor, than I have a MAX to convert to RS232 levels and than a RS232-USB dongle to convert to USB, with which I enter my PC. I use this invertor as the MAX also inverts the signals. It is a pitty that I have only an old analog oscilloscope here at home, else I could provide some signals. Best regards Maarten
Maarten H schrieb: > I have an invertor added behind the EMS-NetIO-adaptor, than I have a MAX to convert to RS232 I suppose thats the problem. if the board has a ttl-Output you only need a max232 and a usb-Rs232 cable. the max232 has a inverter inside. or you can use an inverter instead the max232 for tests. Then you should see the right data at the terminal program. But that is not the reason for the AVR-Problem...
IngoF schrieb: > Torsten Georg schrieb: >> 10 f9 00 ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a > > Hallo Thorsten, > Sind das die ganzen Telegramme oder nur die Nutzlast? > Wenn ich es richtig verstanden habe sollte nach dem 0xff als Datentyp > erst die Länge und dann ein 16-Bit Telegrammtyp kommen? > > Gruß > IngoF Hallo Ingo, ich war ein paar Tage unterwegs. Daher erst jetzt meine Antwort. Du hast natürlich recht. Ich habe da etwas unterschlagen. Ich habe im Log nur die "MESSAGE"" aktiviert, da ich dabei die Uhrzeiten mit der KM200 Abfrage einfacher vergleichen konnte. Hier die korrigierte Version: Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureRoomSetpoint Antwort: MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2: 0a: min: 5°C 2a: ???: 21°C? 3c: max: 30°C 2a: value: 21°C Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/eco Antwort: MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, data: ff 01 b9 04 1f 00 00 00 0a 00 00 00 1e 00 00 00 2d 00 00 00 22 Wieder Faktor 2: 0a: min: 5,0°C 1e: ???: 15,0°C? 2d: max: 22,5°C 22: value: 17,0°C Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/comfort2 Antwort: MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, data: ff 01 b9 02 0f 00 00 00 23 00 00 00 2a 00 00 00 3c 00 00 00 2e Wieder Faktor 2: 23: min: 17,5°C 2a: ???: 21,0°C? 3c: max: 30,0°C 2e: value: 23,0°C Abfrage auf dem KM200: /heatingCircuits/hc1/fastHeatupFactor Antwort: MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, data: ff 01 af 0a 17 00 00 00 01 00 00 00 00 00 00 00 64 00 00 00 00 Diesmal Faktor 1: 01: min: 1% 00: ???: 0%? 64: max: 100% 00: value: 0% Ich vermute mal, dass die 3x 00 vor den Daten für hk4...hk2 reserviert sind. Grüße, Torsten
Hallo Torsten, Torsten Georg schrieb: > Du hast natürlich recht. Ich habe da etwas unterschlagen. Ich habe im > Log nur die "MESSAGE"" aktiviert, da ich dabei die Uhrzeiten mit der > KM200 Abfrage einfacher vergleichen konnte. genau deswegen habe ich den EMS-Collector modifiziert. Damit findet sich in beiden Infos (Message und IO-Bytes) die Zeit, außerdem hatte ich die Größe noch extra aufbereitet, da man die EMS+ Messages damit erst mal grundsätzlich ordnen kann. Siehe mein Log-File im Post weiter oben. Wenn Interesse besteht und von offizieller Seite (Andi und Danny) nichts dagegen spricht, kann ich die beiden geänderten Quelldateien hier veröffentlichen. Gruß Fabian
:
Bearbeitet durch User
IngoF schrieb: > Maarten H schrieb: >> I have an invertor added behind the EMS-NetIO-adaptor, than I have a MAX > to convert to RS232 > > I suppose thats the problem. > if the board has a ttl-Output you only need a max232 and a usb-Rs232 > cable. > the max232 has a inverter inside. > > or you can use an inverter instead the max232 for tests. > > Then you should see the right data at the terminal program. > > But that is not the reason for the AVR-Problem... Hello Ingo, I did some more work and have some answers. You are right with the "inverter discussion" , UART-TTL and RS232 have inverted polarity. The bad news however is that I tried both already. What I found was that the data slicer was not always working correctly, I found that adapting some values (C4 1nF --> 330pF, R7 100K --> 82K) gave more stable data. I compared the dat with the data slicer of the KM200, and the result was very simulair Thr bad news however is that the AVR with EMS_Ethersex still is not reacting at all. When I monitor the UARt signal with Hyperserialport 8n1, I see all messages starting with 3F 00, not with the AA 55 you mention ? I attach a txt file with a short capture. I monitor the bus called "EMS" on the BC10, the same bus where you normally connect the KM200. Can it be the case that this bus has as adress 3F ? Thanks a lot for your time, Maarten
Moin zusammen, da mir noch die Anzeige der Raumtemp. fehlt und ich nur ein RC200 zu meiner GW172-24 besitze, ist hier vermutlich auch noch ein wenig reverse nötig. Da ich nur 0x08 und 0x18 als source finde, gehe ich mal davon aus, dass 0x18 mein RC200 ist. Hier mal ein kleiner Auszug:
1 | MESSAGE[14.12.2014 18:57:35]: source 0x18, dest 0x00, type 0xff, offset 0, data: 0x01 0xa5 0x00 0xdf 0x21 0x2b 0x2a 0x00 0x2b 0x20 0x00 0xf4 0x03 0x03 0x01 0x00 0xf4 0x02 0x90 0x00 0x00 0x11 0x01 0x03 0x08 0xb9 0x00 |
2 | MESSAGE[14.12.2014 18:57:36]: source 0x18, dest 0x00, type 0xff, offset 25, data: 0x01 0xa5 0x00 0x04 0xff 0xe2 0x00 0x00 0x00 0x64 0x4b 0x00 0x3c 0x01 0xff |
3 | MESSAGE[14.12.2014 18:57:36]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64 |
4 | MESSAGE[14.12.2014 18:57:51]: source 0x18, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x00 0xf3 0x02 0x91 |
5 | MESSAGE[14.12.2014 18:58:20]: source 0x18, dest 0x00, type 0x06, offset 0, data: 0x0e 0x0c 0x12 0x0e 0x39 0x1e 0x06 0x00 0x18 0x00 0x00 |
6 | MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x00, type 0xff, offset 0, data: 0x01 0xa5 0x00 0xdf 0x21 0x2b 0x2a 0x00 0x2b 0x20 0x00 0xf3 0x03 0x03 0x01 0x00 0xf3 0x02 0x91 0x00 0x00 0x11 0x01 0x03 0x08 0xb9 0x00 |
7 | MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x00, type 0xff, offset 25, data: 0x01 0xa5 0x00 0x04 0xff 0xe2 0x00 0x00 0x00 0x64 0x4b 0x00 0x3c 0x01 0xff |
8 | MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64 |
9 | MESSAGE[14.12.2014 18:58:50]: source 0x18, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x00 0xf2 0x02 0x92 |
10 | MESSAGE[14.12.2014 18:59:20]: source 0x18, dest 0x00, type 0x06, offset 0, data: 0x0e 0x0c 0x12 0x0e 0x3a 0x1e 0x06 0x00 0x18 0x00 0x00 |
11 | MESSAGE[14.12.2014 18:59:34]: source 0x18, dest 0x00, type 0xff, offset 0, data: 0x01 0xa5 0x00 0xdf 0x21 0x2b 0x2a 0x00 0x2b 0x20 0x00 0xf2 0x03 0x03 0x01 0x00 0xf2 0x02 0x92 0x00 0x00 0x11 0x01 0x03 0x08 0xb9 0x00 |
12 | MESSAGE[14.12.2014 18:59:34]: source 0x18, dest 0x00, type 0xff, offset 25, data: 0x01 0xa5 0x00 0x04 0xff 0xe2 0x00 0x00 0x00 0x64 0x4b 0x00 0x3c 0x01 0xff |
13 | MESSAGE[14.12.2014 18:59:34]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64 |
Auch hier sind die "ff" Telegramme ähnlich wie bei Fabian. Raum Soll 0x2b passt. Leider finde ich aber die aktuelle Raumtemp. von 22,0 Grad nicht darin (vielleicht bin ich auch zu blind). Hat jemand eine Idee?
@Frank S. Ich habe hier eine Mischinstallation GB142(EMS) + RC300(EMS+). Somit ist das Folgende etwas mit Vorsicht zu genießen. Unter EMS+ wird die Raumtemperatur offensichtlich nicht mehr ungefragt auf dem Bus bereitgestellt. Sie muss aktiv abgefragt werden. Versuche mal, ob du eine Antwort bekommst, wenn du vom RC200 Telegramm 0xFF Subtype 0x0139 abfragst. //Niffko
Hallo Danny, vlt. willst Du folgendes in Deinen Collectord einbauen: // add Warmwasserdurchfluß // Buderus GB162-25 T40S // --- Database.cpp query.execute(SensorWarmwasserDurchfluss, sensorTypeNumeric, "Warmwasserdurchfluss", readingTypeVolume, "l/min", 1); Database.h SensorWarmwasserDurchfluss = 26, static const unsigned int readingTypeVolume = 7; EMSMessage.cpp printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min", Database::SensorWarmwasserDurchfluss); www/ems/constants.php.inc define('SensorWarmwasserDurchfluss', 26); define('ReadingTypeVolume', 7); // --- ... dann können die Jungs und Mädels, die einen GB162-25 T40S ihr Eigen nennen, den Warmwasserdurchfluß ihres Boilers ablesen, zB. mit: www/ems.php print_cell("WW-Durchfluß", $sensors[SensorWarmwasserDurchfluss]); tia'n greets Karl M.
Charlie W. schrieb: > EMSMessage.cpp > printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min", > Database::SensorWarmwasserDurchfluss); ... uuups, da habe ich wohl ein paar Änderungen vom 17.02.2014 verschlafen. :-*) So sorry! Karl M.
Charlie W. schrieb: > Charlie W. schrieb: >> EMSMessage.cpp >> printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min", >> Database::SensorWarmwasserDurchfluss); > > ... uuups, da habe ich wohl ein paar Änderungen vom 17.02.2014 > verschlafen. :-*) So sorry! Da komme ich jetzt nicht mit. Warmwasserdurchfluss habe ich nicht implementiert, und Moosy AFAIK auch nicht. Wo siehst du das in meinem Code? (Und wenn es nicht drin ist: In welchem Telegramm steht das?)
Sers Danny, Danny Baumann schrieb: > Und wenn es nicht drin ist: Ist "noch" nicht drin. ;-) > In welchem Telegramm steht das? UBAMonitorWWMessage Quelle Ziel Typ Start Bit Bytes Divisor Linie Einheit 08 00 34 14 1 10 analog l/min Hatte das für mich mal eingepflegt - vor der Änderung am 17.02.2014 - und dann wieder vergessen. Jetzt wollte ich es wieder einpflegen und merke, Du hast den Code deutlich umstrukturiert. Sorry, ich hatte vorher nicht drauf geschaut. Wäre natürlich super, wenn Du es einbauen könntest. Gruß Karl M.
Charlie W. schrieb: > UBAMonitorWWMessage > Quelle Ziel Typ Start Bit Bytes Divisor Linie Einheit > 08 00 34 14 1 10 analog l/min Danke. > Wäre natürlich super, wenn Du es einbauen könntest. Kann und werde ich tun. Muss es auch in die Datenbank mit rein? Wenn ich mich recht entsinne, verwendet doch Moosy's Frontend jetzt den Live-Feed (auf Port 7778) und/oder die Abfragemöglichkeit per Kommando (cache fetch...), oder? EDIT: Probier mal das, was ich gerade eingecheckt habe :)
:
Bearbeitet durch User
Danny Baumann schrieb: > Muss es auch in die Datenbank mit rein? Jepp! Habe ich damals, 12.2013, bei mir händisch hinzugefügt. > Wenn ich > mich recht entsinne, verwendet doch Moosy's Frontend jetzt den Live-Feed > (auf Port 7778) und/oder die Abfragemöglichkeit per Kommando (cache > fetch...), oder? So sehe ich das auch. > Probier mal das, was ich gerade eingecheckt habe :) Herzlichen Dank! Werde ich tun, ich melde mich dann.
Niffko _ schrieb: > Versuche mal, ob du eine Antwort bekommst, wenn du vom RC200 Telegramm > 0xFF Subtype 0x0139 abfragst. Ich bin mir nicht sicher, ob die Abfrage korrekt ist: raw read 0x18 0xff 0x01 0x39 0 25 Dabei kommt nur ein "OK" edit: Output ist der folgende: source 0x18, dest 0x0b, type 0xff, offset 1, data: 0xf8 0xbc aktuelle Temp ist 22,5 Grad und ein "raw read 0x18 0xff 0 25" ergibt : source 0x18, dest 0x0b, type 0xff, offset 0, data: 0xda 0x64
:
Bearbeitet durch User
Hi Danny, Danny Baumann schrieb: > Probier mal das, was ich gerade eingecheckt habe :) Perfekt, hat auf Anhieb geklappt! Dann noch folgendes nachtragen in: www/ems/constants.php.inc define('SensorWarmwasserDurchfluss', 26); define('ReadingTypeFlowRate', 7); und in: www/ems/lemscnt.ajax ... print ... $d["ww flowrate"]." l/min" ... ... und schon klappts auch mit Moosys Frontend. Bedankt und Gruß Karl M.
@Frank Orientiere dich an meinem Beitrag "Re: Faktensammlung Buderus EMS" Davon ausgehend, dass 0x18 dein RC200 ist, müsste die Anfrage auf dem Bus so aussehen: 0B 98 FF 00 FF 01 39 CRC Ob das Dannys Code so auf den Bus bzw. geparst kriegt, weiß ich nicht. //Niffko
Niffko _ schrieb: > "FF" ist hier weniger der Telegrammtyp als vielmehr eine Art Marker für > ein Telegramm mit erweitertem Typenumfang (16Bit). > > Und da ein Beispiel mehr als 1000 Worte sagt ... > > Anfrage: 0B 90 FF 00 0A 01 B9 CRC > > 0B Sender > 90 Empfänger > FF Marker EmsPlus > 00 Offset > 0A Anzahl Bytes > 01B9 Telegramm Typ Torsten Georg schrieb: > Hier die korrigierte Version: > > Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureRoomSetpoint > Antwort: > MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, > data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a > > Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2: > 0a: min: 5°C > 2a: ???: 21°C? > 3c: max: 30°C > 2a: value: 21°C Hallo, ich habe das mal so "verstanden": MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a KM200: /heatingCircuits/hc1/temperatureRoomSetpoint Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2: Sender 0x10 Empfänger 0x48 EMS-Plus 0xf9 Offset 0x00 Typ 0x01b9 ?? 0x0a ?? 0x13 12 0a: min: 5°C 16 2a: ???: 21°C? 20 3c: max: 30°C 24 2a: value: 21°C /heatingCircuits/hc1/temperatureLevel/eco Wieder Faktor 2: Sender 0x10 Empfänger 0x48 EMS-Plus 0xf9 Offset 0x00 Typ 0x01b9 ?? 0x04 ?? 0x1f 12 0a: min: 5,0°C 16 1e: ???: 15,0°C? 20 2d: max: 22,5°C 24 22: value: 17,0°C KM200: /heatingCircuits/hc1/temperatureLevel/comfort2 Wieder Faktor 2: Sender 0x10 Empfänger 0x48 EMS-Plus 0xf9 Offset 0x00 Typ 0x01b9 ?? 0x02 ?? 0x0f 12 23: min: 17,5°C 16 2a: ???: 21,0°C? 20 3c: max: 30,0°C 24 2e: value: 23,0°C KM200: /heatingCircuits/hc1/fastHeatupFactor Diesmal Faktor 1: Sender 0x10 Empfänger 0x48 EMS-Plus 0xf9 Offset 0x00 Typ 0x01af ?? 0x0a ?? 0x17 12 01: min: 1% 16 00: ???: 0%? 20 64: max: 100% 24 00: value: 0% Was mich dann wundert ist dass die ersten 3 Beispiele das selbe Telegramme mit dem selben Offset ist. Ist das erste Byte der Daten ein weiteres Offset?? Oder gilt das alte Offste nicht mehr? Hat jemand eine Idee? habe erst mal einiges im Wiki zu EMS-Plus versucht umzustricken...
Ingo F. schrieb: > ich habe das mal so "verstanden": > MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0, > data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a Was mich bei den Telegrammen irgendwie stört, ist das "FF" zwischen Offset und Subtype. Wenn mein RC300 antwortet, würde das so aussehen: 10 48 F9 00 01 B9 XX XX ... Dass bei den ersten 3 Beispielen Typ und Offset gleich sind, liegt denke ich daran, dass die vom KM200 abgefragten 3 Parameter im gleichen Telegramm enthalten sind. Dieses erscheint dann natürlich bei jeder einzelnen Abfrage auf dem Bus. Ich vermute, dass die Sollwerte zwischen den Abfragen geändert wurden. //Niffko
So, offensichtlich funkt der RC200 doch die Werte ungefragt auf den Bus. War wohl bisher zu blind :) Folgende Werte habe ich identifiziert: IO: Got bytes 0xaa 0x55 0x1f 0x18 00 0xff 00 0x1 0xa5 00 0xe0 0x21 0x2b 0x29 00 0x2b 0x20 00 0x2a 0x3 0x3 0x1 00 0x2a 0x3 0xd2 00 00 0x11 0x1 0x3 0x8 0xbe 00 0xfe 0x18 (Wert 4) = RC200 0xe0 (Wert 11) = aktuelle Raumtemp 22,4Grad 0x21 (Wert 12) = Raum Nacht Soll 16,5 Grad 0x2b (Wert 13) = Raum Soll aktuell (21,5 Grad) 0x29 (Wert 14) = Kessel Soll 0x00 (Wert 18) = Tag (0x01 für Nacht) Die Werte "0x2a" (Wert 19 und 24) ist wohl ein Zähler, der pro Nachricht um 1 dekrementiert Der Wert "0xd2" (Wert 26) inkrementiert um 1 pro Nachricht Bei jeder Raumtemp Änderung schickt RC200 zusätzlich ein "Update": IO: Got bytes 0xaa 0x55 0x8 0x18 00 0xff 00 0x1 0xa5 00 0xde 0x9d 0xde = aktuelle Raumtemp 22,2Grad Jetzt die Preisfrage: Wie bekomme ich diese Erkenntnisse in collectord ? Das Spannende ist wohl, dass es mehrere Typ "ff" Nachrichten gibt (siehe mein voheriger Post).
Niffko _ schrieb: > Davon ausgehend, dass 0x18 dein RC200 ist, müsste die Anfrage auf dem > Bus so aussehen: 0B 98 FF 00 FF 01 39 CRC > > Ob das Dannys Code so auf den Bus bzw. geparst kriegt, weiß ich nicht. Ich hab mal einen 'emsplus'-Branch gepusht, der dieses Format unterstützt, d.h. bei dem 'raw read 0x18 0x139 0 255' genau diesen Output liefert. Ordentlich testen kann ich das mangels EMS plus leider nicht. Frank S. schrieb: > Jetzt die Preisfrage: Wie bekomme ich diese Erkenntnisse in collectord ? > Das Spannende ist wohl, dass es mehrere Typ "ff" Nachrichten gibt (siehe > mein voheriger Post). Das ist eine sehr spannende Frage. Ich bin mir nicht sicher, ob ich das blind coden will (da ich - siehe oben - keinen EMS plus habe) (genauer gesagt bin ich mir ziemlich sicher, dass ich das nicht blind hincoden möchte); also wäre es mir sehr lieb, wenn es so wie bei Moosy's Änderungen liefe: jemand macht einen Pull Request (oder schickt mir meinentwegen den geänderten Code per Mail), und ich ziehe dann höchstens noch ein paar Architekturelle Dinge glatt. Die Parser-Infrastruktur sollte im oben erwähnten emsplus-Branch soweit sein, dass man die neuen Nachrichten verhältnismäßig einfach in das zentrale switch-Statement einbauen kann; der Ausbau des CommandHandlers ist dann natürlich etwas mehr Aufwand. Also, Freiwillige vor :)
Frank S. schrieb: > IO: Got bytes 0xaa 0x55 0x1f 0x18 00 0xff 00 0x1 0xa5 00 0xe0 0x21 0x2b > 0x29 00 0x2b 0x20 00 0x2a 0x3 0x3 0x1 00 0x2a 0x3 0xd2 00 00 0x11 0x1 > 0x3 0x8 0xbe 00 0xfe > > 0x18 (Wert 4) = RC200 > 0xe0 (Wert 11) = aktuelle Raumtemp 22,4Grad > 0x21 (Wert 12) = Raum Nacht Soll 16,5 Grad > 0x2b (Wert 13) = Raum Soll aktuell (21,5 Grad) > 0x29 (Wert 14) = Kessel Soll > 0x00 (Wert 18) = Tag (0x01 für Nacht) OK. Da ich meinen Brenner selbst steuere, habe ich im RC300 keinen Heizkreis aktiviert. Dashalb kommt das 1A5 Telegramm bei mir ohne Inhalt auf den Bus. Ich habe testweise einen Heizkreis aktiviert und konnte deine Feststellung nachvollziehen. Du müsstest die "00"(Wert10) noch mit dazu parsen. Raumtemperatur ist 16Bit, sonst wär bei 25,5°C Sense. //Niffko
Niffko _ schrieb: > Was mich bei den Telegrammen irgendwie stört, ist das "FF" zwischen > Offset und Subtype. Kann es sein dass der alte Offset-Wert keine Funktion mehr hat und nur von Modulen gesendet wird die EMS und EMS-Plus verstehen? Oder hat der Offset 0xff noch eine andere Bedeutung? Dann könnte der neue Offset-Wert hinter dem 16-Bit-Typ kommen. nur das Erste und zweite Byte funktioniert nicht als Offset Beide Bytes könnte schon eher in Frage kommen. Vielleicht wurde ja auch die Telegramm/Speicherlänge verändert und es ist ein 16-Bit-Offset Oder ist das jetzt ein 16-Bit Offset oder noch ein weiterer neuer Datentyp? Kann auch sein dass es nur ein Messwert ist oder eine Art Zeitstempel? Gruß Ingo
Bin nun auch stolzer Anwender einer Heizung mit BC10 und RC300. Bevor ich mir nun eine Platine ätze, frage ich mal in die Runde, ob jemand Platinen über hat. Wenn ja, bitte ich um Info. Zusätzlich will ich mir zu Testzwecken eine EMS Anbindung mit einem Atmel Mega 8 bauen. Nur so als serielle Anbindung für PC/Terminal.
Wolfgang schrieb: > Bin nun auch stolzer Anwender einer Heizung mit BC10 und RC300. Bevor > ich mir nun eine Platine ätze, frage ich mal in die Runde, ob jemand > Platinen über hat. Habe hier noch vier Platinchen abzugeben. Design Niffko / NetIO mit zusätzlichen Jumperfeldern, Aduino-kompatibler Steckerleiste sowie Sockel für ein ESP8266-ESP01 Modul. Selbstkostenpreis: 3€ incl. Porto.
:
Bearbeitet durch User
Juergen O. schrieb: > Wolfgang schrieb: >> Bin nun auch stolzer Anwender einer Heizung mit BC10 und RC300. Bevor >> ich mir nun eine Platine ätze, frage ich mal in die Runde, ob jemand >> Platinen über hat. > > Habe hier noch vier Platinchen abzugeben. Design Niffko / NetIO mit > zusätzlichen Jumperfeldern, Aduino-kompatibler Steckerleiste sowie > Sockel für ein ESP8266-ESP01 Modul. > > Selbstkostenpreis: 3€ incl. Porto. Dear Jurgen, I'm very interested to buy such a platinchen. When you contact me by mail: maarten.heuvelman@gmail.com and give me your bank account I will transfer the Selbstkostenpreis: 3€ incl. Porto. Many thanks Maarten
Sorry Maarten, just delivered the last one. If there's sufficient interest, I'll develop a new one, this time for ESP8266-12, also a bit more multi purpose.
Sers Jürgen, Juergen O. schrieb: > If there's sufficient interest ... dann kannst'e mich mal auf die Liste setzen. Klingt interessant, dieser ESP8266-x. Noch ein paar Fragen, wenns beliebt: Im Moment betreibst Du die Platine als EMS-Adapter für den NetIO, richtig? Hast Du für den ESP8266 schon eine Firmware gebaut, oder ist der Sockel nur fakultativ? Wie hast Du die Stromversorgung (3.3V) realisiert? Gruß und Dank Karl M.
Ich habe keinen NetIO dran, sondern das ESP8266-01 Modul. Bastle grade an der Firmware herum - letztendlich wird die stark an EtherSex angenähert sein. Die 3.3V erzeuge ich momentan noch mit einem eigenen Netzteil mit einem StepDown Wandler. Ziel ist jedoch, direkt über den EMS-Bus zu versorgen.
Juergen O. schrieb: > Ziel ist jedoch, direkt über den EMS-Bus zu versorgen. Die Stromversorgung dürfte nicht das Problem sein... habe ich auch so gemacht. Allerdings ist dann nur wichtig das der Stromverbruach nicht zu stark schwankt. Das könnte dann als Sendeversuch verstanden werden und den Bus wuschig machen Kenne den ESP8266-01 nicht. Könnte mir aber vorstellen dass der WLAN-Chip auch mal gerne schlagartig den Stromverbruach beim senden ändern könnte. Oder liege ich da komplett falsch?
:
Bearbeitet durch User
Nein, liegste vollkommen richtig. Das ESP zieht ca. 17mA, im Burst (beim Senden) jedoch bis zu 250mA. Deshalb wollte ich einen Buck-Konverter (mit Vorwiderstand zu Uems) einsetzen, um den Eingangsstrom zu reduzieren. Funktioniert jedoch nicht sauber. 0R: Der Eingangs-Elko des SDC filtert sauber alle Signale raus ;) 39R: Protokoll verstümmelt - der Komparator kommt aus dem Tritt 47R: kurze Telegramme kommen durch (wie bspw. 90 00 10 00 und 89 00 09 00), längere werden jedoch verstümmelt. 68R und größer: desaströs - der SDC schwingt nicht mehr an, R hängt voll als ohmsche Last an Uems... In allen Fällen geht die Heizung binnen kurzem auf Störung - zeigt nur noch ein blinkendes "-" an. Also fällt die Eigenversorgung mit dem ESP (zumindest via Uems) flach.
@Juergen O i'M also interested when you succeeded with a new PCB based on ESP8266-12. My ESP8266-12 is underway. If you are making new ones, count me in for one. Hope indeed to have it powered by the bus
The problem will be the powersupply. My EMS has approx. 15V w/o load. So a linear regulator for 3.3V isn't a choice at all, 'cause the ESP-12 requires approx 75mA w/o sending.
> w/o
w/o ist mir nicht geläufig, was darf ich darunter verstehen?
Im Datenblatt lese ich:
1 | Transmit 802.11b, CCK 1Mbps, POUT=+19.5dBm 215 mA |
2 | Transmit 802.11b, CCK 11Mbps, POUT=+18.5dBm 197 mA |
3 | Transmit 802.11g, OFDM 54Mbps, POUT=+16dBm 145 mA |
4 | Transmit 802.11n, MCS7, POUT=+14dBm 135 mA |
Das ist einiges! Wieviel "sporadische" Belastung verträgt denn der Bus, ohne das als Sendesequenz zu interpretieren? Könnte sowas funktionieren: EMS - Vorwiderstand - Längsregler - Goldcap - VCC? Oder gleich: EMS - Vorwiderstand - Längsregler - CR2032 - VCC?
Charlie W. schrieb: > Wieviel "sporadische" Belastung verträgt denn der Bus Also auf dem EMS-Bus wird in gesendet indem der Bus mit 227,5 Ohm belastet wird. Bei etwa 15Volt sind das etwa 66mA. Habe jetzt keine Ahnung wo die Ansprechscwelle liegt. sonst einfach mal ausprobieren wieviel Ohm den Bus durcheinander bringen wenn den Widerstand parallel zum Bus kurz anklemmt wird Vermute mal dass es bei etwa 20-30mA sein werden. Meine RC30 wird bestimmt nicht mit 30mA auskommen. Also muss dass irgendwie klappen können. Hat jemand mal den Stromverbrauch von der RC30,35,300 oder 350 gemessen? Ein einfacher Wiederstand in Reihe wird dann wohl nicht helfen. Aber vielleicht reicht es ja auch dem einen wenn die Schaltung an der Diagnosebuchse angeklemmt wird (3,5mm Klinke). Dort sind 12 Volt drauf. Wie stark die 12V-belastet werden dürfen ist mir unbekannt.
:
Bearbeitet durch User
Charlie W. schrieb: >> w/o load > w/o ist mir nicht geläufig, w/o wird without heissen. Also 15 Volt ohne Last Juergen O. schrieb: > Also fällt die Eigenversorgung mit dem ESP (zumindest via Uems) flach. Also der Raumcontroller von Buderus scheint das ja zu schaffen. Fragt sich nur wieviel Aufwand das ist dafür eine Spannungsregelung mit Buffer zu entwickeln. In meiner RC30 ist ein 5,5V 0,4F Goldcap eingebaut der einen 78L05 buffert. Vermutlch wird das beim WLAN-Chip nicht ganz so einfach sein.
:
Bearbeitet durch User
Hallo, ich finde die Verwendung des ESP8266 für die Heizungs-Kommunikation aufregend und bin gespannt was ihr noch realisiert. Ich selber habe keine Buderus sondern eine Junkersanlage, aber da ist der Heizungs-Bus mit seinen Eigenschaften sehr ähnlich. Ein paar Hinweise wollte ich zu dem Thema loswerden weil es mich auch sehr interessiert: Charlie W. schrieb: > Könnte sowas funktionieren: > EMS - Vorwiderstand - Längsregler - Goldcap - VCC? Der Vorwiderstand und Längsregler setzen die ohnehin knapp bemessene Leistung nur in Wärme um. Es muss ein Stepdown-Wandler verwendet werden, mit möglichst hohem Wirkungsgrad. Mit der Annahme, das die Strom-Schwelle bei ca.: 50mA liegt und bei einer Versorgungsspannung von minimal 10 Volt liefert der Bus für einen Client gerade mal 0,5Watt (schön gerechnet). Das ESP-Modul im Sendebetrieb und maximaler Leistung benötigt 3.3V * 0,215mA = 0,71 Watt. Das wird also sehr sehr knapp und tut dem Bus nicht gut, jedoch wird die maximale Sendeleistung ja nicht zu 100% der Zeit benötigt. Daher ist es schon gut zu wissen, wieviel Bytes/Zeiteinheit und wieviel Pause zwischen den Sendevorgängen bleibt um Luft (Strom) zu holen. Um den Stepdown-Wandler kommt man nicht herum, leider ist die Antenne fest verbaut. Da könnte ich mir noch eine effektivere vorstellen um die benötigte Sendeenergie und Stromaufnahme zu reduzieren. Gruß Norbert
Norbert S. schrieb: > Mit der Annahme, das die Strom-Schwelle bei ca.: 50mA liegt Wenn es möglich ist den Stromverbrauch langsam steigern, könnte es auch möglich sein Mehr Strom zu entnehmen. Hat jemand eine Idee wie das möglich sein könnte? Vielleicht die Ausgangsspannung des Step-Down-Wandler langsam ansteigen lassen bis zu 3,3V. Dann müsste das ESP-Modul bei erreichen der richtigen Spannung erst aktiviert werden.
:
Bearbeitet durch User
Hallo Ingo und Norbert, Norbert S. schrieb: > Ich selber habe keine Buderus sondern eine Junkersanlage. ... das wissen wir doch längst, oder glaubst Du im Ernst, wir würden Deinen coolen Thread nicht mitlesen? ;-) > Der Vorwiderstand und Längsregler setzen die ohnehin knapp bemessene > Leistung nur in Wärme um. ... na klar, sind doch existentielle Bestandteile einer Heizung. ;-) > ... knapp bemessene Leistung ... Kommt m.E. darauf an, was man betrachtet. Der EMS-Bus kann mit "vielen" Modulen betrieben werden. Meine RC35 glimmt nach Datenblatt mit Hintergrundbeleuchtung bei 0.6W. Unter 16V nach Adam Ries und Georg Ohm also 37,5mA. Andere Module werden in ähnlicher Größenordnung liegen. Daraus folgere ich mal, dass der Bus genügend Leistungsreserven hat. Kritisch ist doch die zeitlich punktuelle Belastung, die über die als "Sendebelastung" verstandene Schwelle hinausgeht. Der kann man m.E. mit einem entsprechend dimensionierten Vorwiderstand (nach Ingo: I < 20mA ==> bei 16V ca. 820R) begegnen. Dahinter eben der Regler und ein Puffer. Vielleicht wäre eine CR2032 o.ä., im Sinne der Pufferfähigkeit, besser geeignet als ein Goldcap? Oder sind meine Gedanken hier auf einer falschen Fährte? Gruß aus der derzeit frühlingshaften Wetterau Karl M. ps: je suis charlie vraiment!
:
Bearbeitet durch User
Karl M. W. schrieb: > I < 20mA > ==> bei 16V ca. 820R) begegnen. Das wäre dann für das ESP-Modul dann wohl zu wenig. 20mA von der Quelle gibt auch nur 20mA am Ausgang bei Linewarregelung. Das würde dann bedeuten dass etwa die 5fache Leistung im Linearregler verbraten wird. Das beste wäre ein Step-Down-Wandler und dann vielleicht durch Bufferung den Stromschwankungen unter z.B. 20mA halten z.B. 60-80mA. Der Strom war nur geschätzt und müsste getestet werden. Die Pufferung duch eine Knopfzelle wird nichts bringen. Habe keinhe Ahnung wie lange eine Knopfzelle bei dem Stromverbrauch für die Pufferung halten würe. Dann könnte man vermutlich besser AA-Akkus nehmen, oder? Aber hier geht es ja eher um die Schaltung komplett über den Bus versorgen lassen zu wollen.
Hallo, Karl M. W. schrieb: >Der kann man m.E. mit einem entsprechend dimensionierten Vorwiderstand ca. 820R) >begegnen. Versuch macht klug, ich kann nur theoretisch rumschwätze, weil ich das ESP-Modul noch nicht habe. Eventuell kann mann ja das ganze ein wenig entspannen (zeitlich) wenn man eben NICHT mit der laangsamen Baudrate von EMS (4800) Baud sendet sondern mal einwenig flotter auf der WiFi-Seite. Dafür ist dann allerdings auch die Software im ESP-Modul anzupassen. Das entspannt zwar nicht die Avarage-Stromaufnahme, aber kurzer Burst und lange Pause zum Strom-Tanken! Dann kannst du eventuell auch bei deinem Widerstand bleiben und statt eines Gold-Cap nur einen in Silber nehmen ! Gruß Norbert
Ich warte noch auf meinen Trenn-Trafo, damit ich vernünftige Messungen bei der Spannungsversorgung durchführen kann. Laut Hersteller Espressif liegt die Stromaufnahme des Modules zwischen 0.9mA im Sleep-Mode und max 170mA im Sendebetrieb (http://bbs.espressif.com/viewtopic.php?f=6&t=133). Problem ist anscheinend der Buck-Konverter selbst. Sobald dieser an Uems (Ausgang Gleichrichter) angeschlossen wird, zieht es den EMS-Bus nieder. Habe bereits eine Variante mit 2mA Ruhestrom probiert - ändert nichts. Die Idee ist nun, einen einfachen Längsregler (Transistor, Z-Diode, Widerstand) vor den Buck-Konverter zu schalten, um diesen mit Uems-3V zu versorgen und den EMS-Bus etwas besser vom Konverter zu entkoppeln. Die eigentliche Schnittstelle funktioniert bereits im Lesebetrieb. Wesentlich scheint hier zu sein, das der 4.7k Ausgangswiderstand am LM339 deutlich niederohmiger (ca 100R) ausgeführt wird. Mit einem 4k7 gibt es seltsame Latch-Effekte nachdem auf dem Bus der BRK gesendet wurde. Für eine gewisse Zeit (muß nochmal messen) geht das Rx-Signal nicht auf GND, sondern auf max 2V. Hierdurch kommen natürlich verstümmelte Zeichen auf dem Rx an.
Längsregler vorm Bulk-Converter funktioniert. Allerdings braucht es einen relativ fetten Kondensator am Ausgang, andernfalls wird die EMS-Kommunikation gestört. Im Anhang mal die Stromaufnahme im Uems Zweig, mit 1R Shunt gemessen.
:
Bearbeitet durch User
Juergen O. schrieb: > ... Längsregler vorm Bulk-Converter funktioniert. ... sehr schön! > ... fetten Kondensator ... oder Goldcap. ;-) Magst Du nicht einen separaten Fred eröffnen, nach Motto: EMS <> ESP8266-12 <> WLAN
Hallo, ich habe mir die Stecke EMS > Adapter > NetIO > Raspi aufgebaut. Vielen Dank an den ganzen fleißigen Entwicklern die hier ihr Projekt veröffentlicht haben und es mir so möglich war daran Teil zu haben. ;-) Ich habe bei den Frontend von Danny wie auch von Mosi einige Fehler bei der Auswertung der EMS Telegramme. Mein Heizanlage ist ein Buderus GB135-25 Ölbrenner mit RC30 V2.02, BC10 2.0 und UBA 2.01. Frontend Danny Warmwasser Soll: 10°C an Stelle -> 45°C Warmwasser Ist: -3200°C (hier wird Zeitweise der korrekte Wert Angezeigt!?) Außen gedämpft: keine Anzeige Raumtemp. IST: 3200°C Frontend Moosi zusätzlich Die Regelart der Anlage wird als Raumtemperatur geführt erkannt, das ist aber falsch, tatsächlich ist die Anlage Außentemperaturgefährt. Die Heizkurve im Frontend wird deshalb nicht angezeigt. Ich habe mal mit dem Collector ein Logfile erstellt, wäre für eine Lösung und Unterstützung sehr Dankbar. Grüße Martin
In meinem Log habe ich folgendes Entdeckt: Immer nach dem Telegramm source 0x08, dest 0x00, type 0x18, offset 0 ist die WWtemperatur bei -3200°C bei einem Telegramm source 0x08, dest 0x00, type 0x34, offset 0 wird die WWtemperatur hingegen richtig berechnet. Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, dest 0x00, type 0x3e, offset 0
:
Bearbeitet durch User
Martin Berger schrieb: > Immer nach dem Telegramm > source 0x08, dest 0x00, type 0x18, offset 0 > ist die WWtemperatur bei -3200°C > bei einem Telegramm > source 0x08, dest 0x00, type 0x34, offset 0 > wird die WWtemperatur hingegen richtig berechnet. Das Telegramm 0x18 kommt von der Brennersteuerung. Diese scheint keine Warmwassertemperatur zu haben (0x8000 wenn nicht vorhanden = -3276,8°C) Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das müsste vermutlich am besten in den EMS-Collector, oder? Martin Berger schrieb: > Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, > dest 0x00, type 0x3e, offset 0 Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller. Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder? Du hast Doch nur einen Raumtemperaturfühler, und der ist am Raumcontroller (RCxxx), oder? Gruß IngoF
:
Bearbeitet durch User
Ingo F. schrieb: > Martin Berger schrieb: >> Immer nach dem Telegramm >> source 0x08, dest 0x00, type 0x18, offset 0 >> ist die WWtemperatur bei -3200°C >> bei einem Telegramm >> source 0x08, dest 0x00, type 0x34, offset 0 >> wird die WWtemperatur hingegen richtig berechnet. > > Das Telegramm 0x18 kommt von der Brennersteuerung. Diese scheint keine > Warmwassertemperatur zu haben (0x8000 wenn nicht vorhanden = -3276,8°C) Komisch, der WWfühler ist bei mir direkt am UBA/MC10 angeschlossen. > Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das > müsste vermutlich am besten in den EMS-Collector, oder? Das sehe ich auch so. Vielleicht kann das jemand (Danny?) in den EMS-Collector basteln der mehr Ahnung von C hat als ich. ;-) > Martin Berger schrieb: >> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, >> dest 0x00, type 0x3e, offset 0 > > Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller. > > Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D > (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder? > > Du hast Doch nur einen Raumtemperaturfühler, und der ist am > Raumcontroller (RCxxx), oder? Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in der die richtige Raumtemperatur enthalten ist. Die am RC30 abgelesene Raumtemperatur habe ich schon in Hex umgerechnet und anschließend im Log gesucht. Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe ich einen Rechen/Denkfehler gemacht? Grüße Martin
Martin Berger schrieb: > Ingo F. schrieb: >> Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das >> müsste vermutlich am besten in den EMS-Collector, oder? > > Das sehe ich auch so. Vielleicht kann das jemand (Danny?) in den > EMS-Collector basteln der mehr Ahnung von C hat als ich. ;-) Das ist schon drin. Siehe EmsMessage.cpp Zeile 42 bis 48. Du benutzt aber schon mein Repo und nicht das von Moosy, oder? >> Martin Berger schrieb: >>> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, >>> dest 0x00, type 0x3e, offset 0 >> >> Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller. >> >> Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D >> (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder? >> >> Du hast Doch nur einen Raumtemperaturfühler, und der ist am >> Raumcontroller (RCxxx), oder? > > Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den > Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in > der die richtige Raumtemperatur enthalten ist. Die am RC30 abgelesene > Raumtemperatur habe ich schon in Hex umgerechnet und anschließend im Log > gesucht. Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe > ich einen Rechen/Denkfehler gemacht? 20.7°C = 207 auf dem EMS = 0x00 0xCF ... Wie kommst du auf 0x08 0x16?
:
Bearbeitet durch User
Martin Berger schrieb: > Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den > Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in > der die richtige Raumtemperatur enthalten ist. OK, dann war das ein Missverständnis. Hatte es so verstanden dass dort die richtige Raumtemperatur angezeigt wird. Aber immer nach einem bestimmten Telegramm eine falsche Raumtemperatur angezeigt wird. Martin Berger schrieb: > Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe > ich einen Rechen/Denkfehler gemacht? Das Beispiel sollte 0x00 0xcf sein, wie Danny schon geschrieben hat.
Danny Baumann schrieb: > 20.7°C = 207 auf dem EMS = 0x00 0xCF ... Wie kommst du auf 0x08 0x16? Ich habe nach 20,7°C = 2070 = 0x08 0x16 gesucht, das war Falsch. Das Repo was ich verwende haben hat Dateien mit dem Datum vom 18.12.2014, das ist das Repo von dir. ;-) Hier mal ein Aktuelles Telegramm mit der Falschen WWTemperatur: MESSAGE[28.01.2015 20:14:59]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x2d 0x01 0xfe 0x46 0x46 0x09 0x01 0x35 0x01 0x01 0x6b 0x83 0x00 0x80 0x00 0x02 0x0c 0xff 0x2d 0x48 0x00 0x00 0xff 0x00 0x10 0x01 0x44 DATA: Kessel-Solltemperatur = 45 °C DATA: Kessel-Isttemperatur = 51 °C DATA: Brenner-Sollwert Modulation = 70 % DATA: Brenner-Istwert Modulation = 70 % DATA: Flamme = AN DATA: Brenner = AN DATA: Zündung = AUS DATA: Kessel-Pumpe = AN DATA: 3-Wege-Ventil auf WW = AUS DATA: Zirkulation = AUS DATA: Warmwasser-Isttemperatur = -3200 °C DATA: Rücklauf-Isttemperatur = nicht verfügbar DATA: Flammenstrom = 52.4 µA DATA: Systemdruck = -0.1 bar DATA: Servicecode = -H DATA: Fehlercode = 0 Und hier das Telegramm mit einer richtigen WWTemperatur: MESSAGE[28.01.2015 20:13:14]: source 0x08, dest 0x00, type 0x34, offset 0, data: 0x0a 0x01 0x6b 0x83 0x00 0x00 0x00 0x00 0x03 0x00 0x00 0x62 0x8b 0x00 0x06 0x99 DATA: Warmwasser-Solltemperatur = 10 °C DATA: Warmwasser-Isttemperatur = 36.3 °C DATA: Warmwasser-Tagbetrieb = AUS DATA: Warmwasser-Einmalladung = AUS DATA: Warmwasser-Therm. Desinfektion = AUS DATA: WW-Bereitung = AUS DATA: Warmwasser-Nachladung = AUS DATA: WW-Temperatur OK = AUS DATA: Warmwasser-Fühler 1 defekt = AUS DATA: Warmwasser-Fühler 2 defekt = AUS DATA: Warmwasser-Störung = AUS DATA: Warmwasser-Störung Desinfektion = AUS DATA: Zirkulation-Tagbetrieb = AUS DATA: Zirkulation-Manueller Betrieb = AUS DATA: Zirkulation = AUS DATA: Warmwasser-Ladevorgang = AUS DATA: WW-System-Typ = groß DATA: Warmwasser-Durchflussmenge = 0 l/min DATA: WW-Bereitungszeit = 25227 min DATA: WW-Bereitungen = 1689 Und leider wird die DB mal mit der Richtigen und mal mit Falschen Temperatur beschrieben. Grüße Martin
Im Telegramm source 0x08, dest 0x00, type 0x34, offset 0 steckt die Wwtemperatur an Position 6 +7 -> 0x01 0x6d = 36,3 °C Im Telegramm source 0x08, dest 0x00, type 0x18, offset 0 steckt die Wwtemperatur an Position 14 + 15 -> 0x01 0x6d = 36,3 °C und im Wiki steht was von Position 16 + 17 Vielleicht ist da der Fehler, aber warum das nur bei mir auftritt, hmmm
Habe jetzt gerade mal bei mir nachgesehen und bei mir stimmt es zumindest. Im Wiki sind die Startadressen als Telegrammoffset angeben. Das wäre das Telegrammoffset+5. poste doch mal Deine Telegramme. Hier sind meine beiden Telgramme:
1 | Telegramm 0x18: 08 00 18 00 | 3f 02 22 64 3b 09 01 25 60 80 00 02 6f 01 e9 00 27 0c 2d 48 00 c8 ff 02 00 be |
2 | DatenOffset: -4 -3 -2 -1 | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
3 | TelegrammOffset: 1 2 3 4 | 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
4 | |
5 | 14-15: 0x8000 = Temperatur (DL-Erhitzer?) nicht vorhanden |
6 | 16-17: 0x026f =623 => 62,3°C Wassertemperatur |
7 | 18-19: 0x01e9 =489 -> 48,9°C Rücklauf Temperatur |
8 | |
9 | |
10 | Telegramm 0x34: 08 00 34 00 | 3c 02 6f 02 6f 21 00 00 03 ff 01 b9 e1 00 19 bf 2b |
11 | DatenOffset: -4 -3 -2 -1 | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
12 | TelegrammOffset: 1 2 3 4 | 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
13 | |
14 | 6 - 7: 0x026f =623 => 62,3°C Wassertemperatur |
Ingo F. schrieb: > Habe jetzt gerade mal bei mir nachgesehen und bei mir stimmt es > zumindest. > Im Wiki sind die Startadressen als Telegrammoffset angeben. Das wäre das > Telegrammoffset+5. > > poste doch mal Deine Telegramme. Hat er doch ;) In deiner Notation:
1 | Telegramm 0x18: 08 00 18 00 2d 01 fe 46 46 09 01 35 01 01 6b 83 00 80 00 02 0c ff 2d 48 00 00 ff 00 10 01 44 |
2 | DatenOffset: -4 -3 -2 -1 | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
3 | TelegrammOffset: 1 2 3 4 | 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
14-15: 0x016b = 363 => Temperatur (DL-Erhitzer?) 36,3°C 16-17: 0x8300 = -32000 => -3200°C Wassertemperatur 18-19: 0x8000 => Rücklauftemperatur nicht vorhanden Das Problem ist also, dass der Wassertemperaturwert gerade nicht 0x8000 ist. Ich bin mir allerdings nicht sicher, was die 'draufgeoderte' 0x300 zu bedeuten hat. In der Buderus-Doku, die ich habe, sind die Offsets 9 bis 12 leider nicht dokumentiert. Die einfachste Lösung wäre wahrscheinlich, diesen Wert einfach nicht mehr zu parsen, da ohnehin redundant.
Danny Baumann schrieb: > Hat er doch ;) Ups ...wie konnte ich das nur übersehen Danny Baumann schrieb: > Ich bin mir allerdings nicht sicher, was die 'draufgeoderte' > 0x300 zu bedeuten hat. Vielleicht noch eine Information warum der Wert nicht vorhanden ist? Also sozusagen eine Fehlermeldung?? Man könnte ja alles mit gesetztem höchstem Bit als nicht vorhanden bewerten. Oder zumindest unter -50°C(-500) z.B. Denke nicht dass die Außentemperatur soweit sinken wird.
:
Bearbeitet durch User
Ich habe keine Warmwasserbereitung (RC35, MC10). Bei mir taucht auch die 0x8300 auf. Hier der Debug-Output von meinem ESP-Interface...
1 | [ 694.808068 56.821 080 33] 08 00 18 00 3b 02 65 64 64 09 01 35 00 83 00 7d 00 80 00 02 09 ff 2d 48 00 00 ff 00 10 83 00 ? 3b:3b |
2 | [ 695.905880 96.991 080 33] 08 00 18 00 3b 02 66 64 64 09 01 35 00 83 00 7d 00 80 00 02 09 ff 2d 48 00 00 ff 00 10 83 00 ? c2:c2 |
Juergen O. schrieb: > Ich habe keine Warmwasserbereitung (RC35, MC10). Bei mir taucht auch die > 0x8300 auf. OK, ich schmeiß das Parsen dieses Wertes einfach raus. Wenn WW vorhanden ist, steht der Wert ja auch im WW-Monitor-Telegramm. Martin Berger schrieb: > Frontend Danny > Warmwasser Soll: 10°C an Stelle -> 45°C Ich hab ehrlich gesagt keine Ahnung, was dein UBA da macht. Byte 0 des WW-Monitor-Telegramms (0x34) ist (auch laut Buderus-Doku) die WW-Solltemperatur, und da steht bei dir 0xa = 10 drin. > Warmwasser Ist: -3200°C (hier wird Zeitweise der korrekte Wert > Angezeigt!?) Siehe oben :) > Außen gedämpft: keine Anzeige Die steht im Telegramm 0xa3 (gesendet vom RC30), welches bei dir - aus welchen Gründen auch immer - fehlt. > Raumtemp. IST: 3200°C Das muss ich nochmal verifizieren. Da steht 0x7d 0x00 drin, was laut Buderus-Doku ('Byte1 + (Byte2 * 256)') 12,5°C wäre (ganz schön kalt). Da der Algorithmus allerdings für alle Werte mit mehreren Bytes gleich ist, dürfte - wenn er falsch wäre - ja gar nix funktionieren. Ich werd mir das mal anschauen... EDIT: Passt schon. Die Doku definiert Offset 3 als Byte2 und Offset 4 als Byte1, d.h. 0x7d * 256 + 0 = 32000 -> 3200°C. Bei mir ist das z.B. 0x00 0xcb = 20.3°C. Ich habe wiederum keine Ahnung, was dein RC da macht...vielleicht ein Bug im RC30; bei mir haben sowohl RC30 als auch UBA V2.05. > Frontend Moosi zusätzlich > Die Regelart der Anlage wird als Raumtemperatur geführt erkannt, das ist > aber falsch, tatsächlich ist die Anlage Außentemperaturgefährt. Die > Heizkurve im Frontend wird deshalb nicht angezeigt. Der entsprechende Wert (Telegramm 0x3d, Offset 33) ist in deinen Telegrammen einfach nicht enthalten. Ich bin mir nicht sicher, was Moosy in diesem Fall macht. > Ich habe mal mit dem Collector ein Logfile erstellt, wäre für eine > Lösung und Unterstützung sehr Dankbar. Danke dafür. Ich habe darin noch gesehen, dass der Systemdruck nicht richtig ausgewertet wurde, das habe ich gleich mal mit gefixt.
:
Bearbeitet durch User
Danny Baumann schrieb: >> Warmwasser Soll: 10°C an Stelle -> 45°C 10°C stehen drin wenn kein Warmwasser bereitet werden soll. Die 10°C vermutlich nur wegen Frostschutz Danny Baumann schrieb: > Die steht im Telegramm 0xa3 (gesendet vom RC30), welches bei dir - aus > welchen Gründen auch immer - fehlt. Das hängt davon ab welches "Mauerwerk" man in der Heizung eingestellt hat. Das ist ja nur ein berechneter Wert. Es gibt auch irgendwo eine Einstellung dass Die Heizung automatisch vorher anspringt dass zur eingestellten Zeit auch die Temperatur vorhanden ist. Kann auch Sein dass es etwas mit der automatischen Sommerbetrieb zu tun hat. Mal nachsehen ob und auf welchen Wert das eingestellt ist. Danny Baumann schrieb: > Das muss ich nochmal verifizieren. Da steht 0x7d 0x00 drin Im Wiki hat irgendjemand eingetragen: Raumtemperatur Ist (0x7d00 für HK abgeschaltet)
:
Bearbeitet durch User
Ingo F. schrieb: > Im Wiki hat irgendjemand eingetragen: > Raumtemperatur Ist (0x7d00 für HK abgeschaltet) Hallo, wenn ich mich richtig erinnere habe ich diesen Eintrag geschrieben. Bei mir wird auch 0x7d00 angezeigt. Die RC30 ist bei mir am Brennwertgerät eingebaut, deswegen ist diese nicht mit dem Heizkreis verknüpft. @jschmied ich habe die Firmware geändert, nun werden die richtigen Werte über HTML empfangen. Kennt sich jemand mit Java-Script aus? Ich habe da keine Ahnung wie ich die Seite programmieren kann. Ich möchte die Parameter anklicken, welche ich ändern möchte.
:
Bearbeitet durch User
Hallo Franz, F. F. schrieb: > Kennt sich jemand mit Java-Script aus? Nö, nicht wirklich. ;) Aber ich glaube was Du suchst findet sich unter [1] oder [2]. Oder vielleicht [3]. Gruß aus der Wetterau Karl M. [1] http://de.wikipedia.org/wiki/XMLHttpRequest [2] http://wiki.selfhtml.org/wiki/JavaScript/API/XMLHttpRequest [3] http://api.jquery.com/jquery.get/
:
Bearbeitet durch User
F. F. schrieb: > @jschmied ich habe die Firmware geändert, nun werden die richtigen Werte > über HTML empfangen. > Kennt sich jemand mit Java-Script aus? Ich habe da keine Ahnung wie ich > die Seite programmieren kann. Ich möchte die Parameter anklicken, welche > ich ändern möchte. Das Schreiben über die JSON Schnittstelle ist bisher nicht richtig in der FW drin. Hab auch erstmal keine Zeit, weiterzumachen. vg Jürgen
jschmied schrieb: > Das Schreiben über die JSON Schnittstelle ist bisher nicht richtig in > der FW drin Die Firmware habe ich soweit geändert, sie funktioniert. Nur mit Html und Java-Script kenne ich mich nicht aus. Ich lade demnächst meine aktuelle Version hoch. Viele Grüße Franz
With great help of Danny and Ingo I now got the ems-ethersex-netio running, the basic issue was that I was using a 644 i.s.o. 644P w/o second UART, so all others where okay, but the system was dead. I also follwed the http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io" to setup a BananaPI environment for the collector, MySQL, Lighttpd, etc.... When I run the command "collectord -u ems -p geheim -f -d all tcp:192.168.xxx.xxx:7950" I see indeed the EMS messages tanzen auf das schirm. I tried to make the required init and default setting in order to run from booting. But I'm notsure the collectord is really running and putting data in a MySQL database. I tried to telnet from my Windows-7 PC "telnet 192.168.1.6 7777" but the system answers there is no connection to the host on this port. I tried root> collectord status, I get no error message nor a reaction. How to check that the Collectord is really capturing messages and storing them in MySQL ? Thanks Maarten
Hello Maarten, Maarten H schrieb: > ... the collectord is really running and putting data in a > MySQL database ... from your Bananas console, please try: root@banana: top you see all active processes. There schould be "collectord" and "mysqld". if "mysqld" exists, try next command: root@banana: mysqld -u "databasename" -p now enter your password, you'll get the mysql-console: at mysql> enter: use ems_data; show tables; you should see the tables structure of your db now enter: select * from numeric_data if there is data, you're fine. if not, check databases sanity. to quit mysql, insert "exit". > ... telnet 192.168.1.6 7777 ... afaik telnet only works on localhost. so, from your bananas console try: root@banana: telnet localhost 7777 if the collectord is running correctly, you should see some lines, now try: "help" and have fun. hth'n greets Karl M.
:
Bearbeitet durch User
Hallo Franz, F. F. schrieb: > Ich möchte die Parameter anklicken, welche ich ändern möchte. Du kennst Moosys Frontend?! https://github.com/moosy Gruß in die Berge! ;-) Karl M.
Maarten H schrieb: > But I'm notsure the collectord is really running and putting data in a > MySQL database. I tried to telnet from my Windows-7 PC "telnet > 192.168.1.6 7777" but the system answers there is no connection to the > host on this port. For that, you need to pass the parameter '-C 7777'. > How to check that the Collectord is really capturing messages and > storing them in MySQL ? There are a couple of options: - ps, as mentioned by Karl - let the daemon log into a file and check that file for new entries: '-d all=foo.log' - check the database contents ;)
Dear Karl, With "top" I see mysql, but not collectord top When I run the mysqld I get: bananapi@maarten ~ $ mysqld -u ems -p 150130 21:22:34 [Warning] Using unique option prefix key_buffer instead of key_b uffer_size is deprecated and will be removed in a future release. Please use the full name instead. 150130 21:22:34 [Warning] Ignoring user change to 'ems' because the user was set to 'mysql' earlier on the command line 150130 21:22:34 [Warning] Can't create test file /var/lib/mysql/maarten.lower-te st 150130 21:22:34 [Warning] Can't create test file /var/lib/mysql/maarten.lower-te st mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13) 150130 21:22:34 [ERROR] Aborting 150130 21:22:34 [Note] mysqld: Shutdown complete bananapi@maarten ~ $ collectord -h was still working So first I should get collectord running from booting I see: bananapi@maarten /etc/init.d $ ls -l ems-collector -rwxr-xr-x 1 root root 1883 Jan 29 22:07 ems-collector In this file: PROGNAME="collectord" PROG="/usr/local/sbin/$PROGNAME" DESCR="EMS collector daemon" Collectord is in this directory: bananapi@maarten /usr/local/sbin $ ls -l collectord -rwxr-xr-x 1 root staff 791487 Jan 30 21:38 collectord The default: bananapi@maarten /etc/default $ ls -l ems-collector -rw-r--r-- 1 root root 339 Jan 29 22:25 ems-collector So concluding: I get the impression collectord is not running from booting Many thanks Maarten
Hi again, > Ignoring user change to 'ems' because the user > was set to 'mysql' earlier on the command line You added user "ems" to the db? Please check: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#mysql_benutzer_anlegen > /etc/default/ems-collector what is the content of that file? You'll get it running! :-) Greets Karl M.
Hi Karl, Thanks for helping, I indeed really hope to get it working!!!! Yes as I made the change to the db, in fact I copied the log: bananapi@maarten ~ $ sudo mysql -u root -p Enter password:pa0mhe Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 45 Server version: 5.5.40-0+wheezy1 (Debian) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select password('my_PW'); +-------------------------------------------+ | password('my_PW') | +-------------------------------------------+ | *FAA663E23C9CA3A6918059359F95422DC1FA61DA | +-------------------------------------------+ 1 row in set (0.00 sec) mysql> create user ems identified by password '*FAA663E23C9CA3A6918059359F95422DC1FA61Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) mysql> GRANT ALL ON ems_data.* TO 'ems'@'%'; Query OK, 0 rows affected (0.00 sec) Content of "/etc/default/ems-collector" # Defaults file for EMS collector daemon # This is a POSIX shell fragment # config file location CONFIGFILE="/etc/ems-collector.conf" # Serial device file SERIALDEVICE="/dev/ttyUSB0" # Where to put the PID file PIDFILE="/var/run/ems-collector.pid" # Other options OPTIONS="-C 7777 -D 7778 -u ems -p my_PW -r 60 tcp:192.168.1.5:7950" Thanks again a lot Maarten
Hi Maarten; > # config file location > CONFIGFILE="/etc/ems-collector.conf" you may comment out this last line. All config is done within here. > # Serial device file > SERIALDEVICE="/dev/ttyUSB0" you have to comment out last line, cause you're talking tcp. > tcp:192.168.1.5:7950 912.168.1.5 is the ip of your netio with ethersex?! Restart the collectord and have a look at your db, whether or not all is working and showing tables and data. Yes, you'll succeed! Greets to Belgium Karl M.
:
Bearbeitet durch User
Karl M. W. schrieb: > Du kennst Moosys Frontend?! > https://github.com/moosy Danke, Karl diese Seite kannte ich noch nicht. Ich weiß aber nicht, in wieweit dies mit meiner Firmware (JSON) zusammenpaßt. viele Grüße an die Wetterau, bin morgen wieder da. :-) Franz
Hallo Franz, > Ich weiß aber nicht, in > wieweit dies mit meiner Firmware (JSON) zusammenpaßt. Falls ich Jürgen richtig verstanden habe, sollte das funken! Aus dem Wiki:
1 | N.b.: Selbst Ingos EMS-GW kann mit der Firmware 2.1.1 |
2 | und einem ENC28J60 Netzwerkmodul verwendet werden. |
3 | So kann man auch über das EMS-GW das neue Frontend |
4 | von Moosy benutzen. |
Gute Reise und genieße die gesunde Luft in Bad Nauheim! Gruß Karl M.
Dear Karl and Danny, Yes indeed my ethersex AVR is at 192.168.1.5:7950 collectord -u ems -p "My_PW" -f -d all tcp:192.168.1.5:7950 runs fine I can see the EMS messages in this case. etc/default/ems-collector: # config file location # CONFIGFILE="/etc/ems-collector.conf" # Serial device file # SERIALDEVICE="/dev/ttyUSB0" I gave a Reboot, I cheked with >top but nothing present from collectord, also not with telnet. I tried to start collectord: bananapi@maarten ~ $ collectord start Exception: Cannot open pidfile '/var/run/collectord.pid': Permission denied bananapi@maarten ~ $ sudo collectord start [sudo] password for bananapi: Exception: Access denied for user 'root'@'localhost' (using password: NO) The I tried to check the db: bananapi@maarten ~ $ mysqld -u ems -p 150131 12:50:32 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 150131 12:50:32 [Warning] Ignoring user change to 'ems' because the user was set to 'mysql' earlier on the command line 150131 12:50:32 [Warning] Can't create test file /var/lib/mysql/maarten.lower-test 150131 12:50:32 [Warning] Can't create test file /var/lib/mysql/maarten.lower-test mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13) 150131 12:50:32 [ERROR] Aborting 150131 12:50:32 [Note] mysqld: Shutdown complete "My concluding": collectord: is not starting, perhaps someting wrong with users and permissions ?, I'm surely not very experienced with Linux. mysqld: is started but still having problems. Thanks a lot both (Karl, Danny) for your support, Maarten
Hi again Maarten,
> Cannot open pidfile '/var/run/collectord.pid': Permission
Name and path of the Pidfile in the /etc/default/ems-collector must be
the same as the existing file. E.g.:
1 | root@home:~# ls -l /var/run/ems-collector.pid |
2 | -rw-r--r-- 1 root root 4 Jan 31 14:44 /var/run/ems-collector.pid |
> bananapi@maarten ~ $ mysqld -u ems -p
Sorry, sorry, sorry, my mistake!
It has to be:
bananapi@maarten ~ $ mysql -u ems -p
Give 'em a new chance! ;-)
Readya
Karl M.
Ich bekomme jetzt die immer die richtige WW Temperatur angezeigt. Vielen Dank Danny für die Änderung am Collector. ;-) Die Warmwassersolltemperatur +45°C wird nur während dem Normalbetrieb Angezeigt im Reduziertenbetrieb wird die +10°C Angezeigt, somit ist das in Ordnung. Im HK1 habe ich die Fernbedienung von „Keine“ auf „RC30“ umgestellt, seitdem bekomme ich eine Raumtemperatur (vom Heizraum) angezeigt. Jetzt ist auf dem EMS-Bus auch erheblich mehr Betrieb. Allerdings hat sich auch das Verhalten meiner Heizanlage geändert, den Raumeinfluss musste ich von +3K auf 0K ändern und meine Heizkurve durfte ich wiederherstellen. :-P Fehlt ein Fühler, wird bei meiner Anlage mit 0x8300 oder mit 0x8000 dargestellt. Abgastemperatur , Warmwasser Temperatur Ist 2. Fühler etc. bei meiner Anlage mit 0x8300. Telegramm 0x19 TelegrammOffset:18(Dataoffset13) = Betriebszeit komplett = Betriebszeit 1 (bzw. bei meinem 2-Stufenbrenner die Betriebszeit der 2 Stufe). Telegramm 0x19 TelegrammOffset:21(Dataoffset16) mit 3 Bytes ist die Betriebszeit 2 (bei meinem 2-Stufenbrenner die Betriebszeit der 1 Stufe). ← Das wäre doch was fürs Wiki und dem Collector ;-) Telegramm 0x3d geht bei meiner Anlage nur bis TelegrammOffset:32(Dataoffset27) und somit gibt es auch keine Führungsgröße, maximale Vorlauftemperatur etc. was im Mosys-Frontend „Erweiterte Einstellungen“ verwendet wird. Telegramm 0xa3 mit der gedämpften Außentemperatur habe ich noch nicht gesichtet, dafür ein paar andere Telegramme wie 0x20 etc. die im Wiki keine Erwählung finden und zum Teil leer oder mit 0x00 gefüllt sind
Dear Karl, ems-collector.pid file: Understood, but how to locate this file ? It is not in /var/run bananapi@maarten /var/run $ find ems-collector.pid find: `ems-collector.pid': No such file or directory mysql, I re-tried: bananapi@maarten ~ $ mysql -u ems -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 42 Server version: 5.5.41-0+wheezy1 (Debian) Copyright (c) 2000, 2014, Oracle . All rights reserved. Oracle is a registered trademark of Oracle Corporation Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> use ems_data Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables -> * -> \q Not sure, but I don't think this was the right feedback from the db ? Thanks again Maarten
Dear Karl, I did the experiments you suggested: bananapi@maarten ~ $sudo touch /var/run/collectord.pid bananapi@maarten ~ $ service ems-collector restart [warn] Stopping EMS collector daemon: collectord already stopped (warning). [....] Starting EMS collector daemon: collectordterminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info _injector<boost::program_options::invalid_command_line_syntax> >' what(): required parameter is missing in 'config-file' Aborted failed! bananapi@maarten ~ $ Something wrong with the config-file ? # Defaults file for EMS collector daemon # This is a POSIX shell fragment # config file location #CONFIGFILE="/etc/ems-collector.conf" # Serial device file # SERIALDEVICE="/dev/ttyUSB0" # Where to put the PID file PIDFILE="/var/run/ems-collector.pid" # Other options OPTIONS="-C 7777 -D 7778 -u ems -p xxxxx -r 60 tcp:192.168.1.5:7950" Thanks again Maarten-
Dear All, With help of Ingo, Danny and Karl I made big steps forward. Now the ems-collector service is running and the MySQL db filled. I can Telnet and see the db. Also the lighttpd webserver is running standalone and I can read the default php "Hello world" page. Next I hope to setup Danny's Webpage. I loaded the "webpage" files into /var/www, however I'm missing and index.php file ? Is there somewhere an Install procedure available ? Thanks in advance and Best regards Maarten
Maarten H schrieb: > Next I hope to setup Danny's Webpage. I loaded the "webpage" files into > /var/www, however I'm missing and index.php file ? > Is there somewhere an Install procedure available ? There is no index.php in my pages. I reference them directly and usually use status.php as entry point. Symlinking status.php to index.php probably also works.
Hi Danny, Thanks, I copied all your webpage files intor /var/www I renamed status.php into index.php. When I access the webpage with my Firefox browser I get a complete "light blue" page, and with IE an error HTTP 500 internal server error. Thanks Maarten
Hi Maarten, > "light blue" page, and with IE an error HTTP 500 internal server error. You know this page: http://www.penguintutor.com/linux/light-webserver hth'n greets Karl M.
Hi Karl, > You know this page: > http://www.penguintutor.com/linux/light-webserver Yes indeed I followed this very good tutorial, including the PHP setup, and testpage they gave. This worked fine. But with Danny's page it is going wrong, I think perhaps that I should not Copy the files to /var/www but somewhere else ? I also tried to make a symlink : ls -l /home/bananapi/ems-collector-master/webpage/status.php But also w/o success. The "light blue" pages is titled "Heizung" and when I look to source in my browser it is Danny's status.php Best regards Maarten
Maarten H schrieb: > But with Danny's page it is going wrong, I think perhaps that I should > not Copy the files to /var/www but somewhere else? No, the fact that you can access the page shows it's in the correct place. > The "light blue" pages is titled "Heizung" and when I look to source in > my browser it is Danny's status.php This sounds like there's some issue with the php interpreter. The web server should do an error log (e.g. for apache it's in /var/log/apache2/error.log) that should give an idea of what exactly is wrong.
ReHi Maarten,
> ... PHP setup and testpage ...
PHP is working?!
Tried the typical test.php?
---snip---
<html>
<head>
<title> PHP Test Script </title>
</head>
<body>
<?php
phpinfo( );
?>
</body>
</html>
---snap---
What's about the rights for the webserver files, are they set to
"www-data"?
Greets to Vlaanderen
Karl M.
Hi Karl, Yes I followed exactly the in the penguingtutor metioned file rights, ad this gave no errors, also "your" testpage is working see attachment. Maarten
Hi Maarten, ok, php is working! As Danny told, what is "/var/log/lighttpd/error.log" saying? Groetjes Karl M.
Hi Karl, I captured the following from the error.log 2015-02-02 21:16:15: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal error: Uncaug$ Stack trace: #0 /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc(6): PDO->__con$ #1 /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc(24): open_db() #2 /home/bananapi/ems-collector-master/webpage/index.php(27): get_current_sensor_v$ #3 {main} thrown in /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc on li$ Thanks again Maarten
Hi Maarten,
> /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc
seems, your www files are not in the www-directory??
But sorry for rest of this evening, got an old mate over here.
Some beers are waiting. ;~)
Readya
Karl M.
Hi Karl, Prosit. All Danny's webpage files are both in /var/www and in /home/bananapi/emc-collector-master/webpage And I have a symlink from /var/www/index.php to /var/www/status.php Bye, Maarten
Danny, Karl, What I see in the Errorlog is that "sensor_utils.php.inc" can't access the "ems_data" db in MySQL. When I do the manual: mysql> use ems_data; mysql> show tables; mysql> select * from numeric_data; It works, any idea what could be wrong ? Best regards Maarten
Hi Maarten, > "sensor_utils.php.inc" can't access > the "ems_data" db in MySQL. File rights?? Please show the first 10 rows of "sensor_utils.php.inc" Readya Karl M.
Hi Karl, Beginning my "sensor_utils.php.inc" file <?php include 'constants.php.inc'; function open_db() { return new PDO('mysql:dbname=ems_data;host=localhost', 'emsdata', 'emsdata'); } function format_value($row) { $value = (float) $row->value; if ($row->reading_type == ReadingTypeTime && $row->unit == "min") { $hours = (int) floor($value / 60); $mins = (int) ($value - 60 * $hours); if ($hours > 0) { return sprintf("%dh %dmin", $hours, $mins); } } I was thinking: Can it be something with file permissions ?, I see the "owner" of the db is "mysql" , this is logic, but can the php access this ? Best regards Maarten
The last 2 parameters of the 'new PDO...' line are the DB user name and password. Do those match what you've set up?
Hi Maarten, > return new PDO('mysql:dbname=ems_data;host=localhost', > 'emsdata','emsdata'); first 'emsdata' is 'your_dbuser', second 'emsdata' 'your_dbpass'. hth'n greets Karl M. * Danny ist deutlich schneller! ;-)
:
Bearbeitet durch User
Hi Karl, News from Vlaanderen, however Still not there Error.log lighttpd: 2015-02-04 22:19:35: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal error: Unc$ Stack trace: #0 /srv/www/sensor_utils.php.inc(6): PDO->__construct('mysql:dbname=em...', 'em$ #1 /srv/www/sensor_utils.php.inc(24): open_db() #2 /srv/www/status.php(27): get_current_sensor_values() #3 {main} thrown in /srv/www/sensor_utils.php.inc on line 6 2015-02-04 22:19:41: (server.c.1558) server stopped by UID = 0 PID = 3262 My line (6) ensor_utils.php.inc: return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 'my_pwd'); Best regards Maarten
... sorry, no idea at the moment. (Danny?) Will you show rows 4 to 8 again, please.
Hi Karl, Here sensor_utils.php.inc line 4..8 function open_db() { return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 'my_pwd'); } I was not aware this modification of adding user and pw, is there anywhere a install procedure of this webpage, as I perhaps miss also other settings. Best regards Maarten
Hi Maarten, > Here sensor_utils.php.inc line 4..8 seems perfect! > is there a install procedure of this webpage Know none. Perhaps you will (have to) go the hard way through all files and check all the stuff. Readya Karl M.
Hi Karl, I gave up on the old image and decided to start with a new, completely fresh setting_up everthing, and...... it is working, I can read Danny's webpage, still not with graphs, but that is for later. my Buderus setup is: MC10 / UBA Brenner (ol type) (We have here no gas close to my home) BC10 RC35 Warmwater boiler Now I noticed a few strange items: The "warmwasser IST" temperature is mostly indicated as 3200.0C, sometimes I get the right temperature, I see the system uses: source 0x08 type 0x18 offset 16, this is indeed 3200, but only in source 0x08 type 0x34 offset 6 is the right warmwater actual temperature. Is this easy to change ? My system also measures the "abgastemperature", I can see this on my RC35, but not on in the MySQL data, this is transmitted in source 0x08 type 0x19, this message is also used for other information presented in the webpage, is this possible to add ? I added a log file from my collectord Do you have an idea? Best regards Maarten
Maarten H schrieb: > The "warmwasser IST" temperature is mostly indicated as 3200.0C, > sometimes I get the right temperature, I see the system uses: source > 0x08 type 0x18 offset 16, this is indeed 3200, but only in source 0x08 > type 0x34 offset 6 is the right warmwater actual temperature. Is this > easy to change ? Yes. It's so easy that I actually already did it, see a few posts above. If you're using my repo, try a git pull, otherwise try using my repo. :) > > My system also measures the "abgastemperature", I can see this on my > RC35, but not on in the MySQL data, this is transmitted in source 0x08 > type 0x19, this message is also used for other information presented in > the webpage, is this possible to add ? Yes, sure. I'll add it.