Ingo F. schrieb: > Habe mal mein Log angehangen... Irgendwas läuft da richtig schief. IO: Sending bytes 0x90 0x3f 00 0x54 IO: Got bytes 0xaa 0x55 0x20 IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3f 00 0x54 0xf0 Auf das gesendete Telegramm mit der Abfrage von 84 Bytes aus Telegramm kommt also - eine Antwort mit Länge 32, aber ohne Daten - eine Antwort, die nach einer Kopie des Sendepuffers aussieht Konsequenterweise versucht es der Collector daraufhin noch ein paar mal, aber bekommt weiterhin keine sinnvolle Antwort. Mal zum Vergleich, so sieht es bei mir aus: IO: Sending bytes 0x90 0x3f 00 0x54 IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 00 0x1 0x1b 00 0x2d 0x1 0x54 00 0x8a 0x21 0x1b 0x20 0x2d 0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41 0x54 0x40 0x8a 0x61 0x1b 0x60 0xd6 Da musst du wohl nochmal in die Gateway-Sourcen schauen ;-) IO: Sending bytes 0x90 0x3f 0x1b 0x39
Danny Baumann schrieb: > - eine Antwort mit Länge 32, aber ohne Daten > - eine Antwort, die nach einer Kopie des Sendepuffers aussieht Na dann kann es ja nicht wirklich funktionieren... Werde mich mal durch die Sourcen durchkämpfen...
Angehängte Dateien:
-
frame_3d.PNG
19 KB
Moin, dass RC30/35 bei Abfrage größerer Telegramme in die Knie gehen ist wohl normal ... das Thema hatten wir -glaube ich- auch schon mal. Der Service-Key fragt zumindest die entsprechenden Telegramme auch in kleineren Chunks ab. Ich hab mich kürzlich zum ersten mal mit der Abfrage solcher "Überlängen" beschäftigt. Dabei ist mir etwas aufgefallen, was evtl. etwas mit Ingos Problem zu tun haben könnte. Fragt man mehr Datenbytes an, als der RC30/35 liefern kann, wird keine CRC auf den Bus geechot (siehe Anhang). Kann das jemand verifizieren? Würde man jetzt das letzte Byte für einen CRC-Check hernehmen, geht das natürlich schief. Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge der abzufragenden Datenchunks von vorn herein auf einen Wert festzulegen, der auch sicher geliefert werden kann. //Niffko
Angehängte Dateien:
-
Ueberlaenge.PNG
14 KB
Niffko _ schrieb: > Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge > der abzufragenden Datenchunks von vorn herein auf einen Wert > festzulegen, der auch sicher geliefert werden kann. Die CRC werden im collector ja nicht mehr ausgewertet und deswegen vermutlich erst mal egal. Denke dass mit der 00-CRC bei "Überlängen" ist ein spezielles Problem vom NetIO. Auf dem EMS-Bus werden tzrotzdem CRC gesendet. Mit dem EMS-Gateway ist es zumindest nicht so. Denke aber es wäre keine schlechte Idee dass auf eine Datenlänge von 0x1b zu begrenzen. Mehr Daten werden sowieso nicht geliefert. Kann das mit der CRC mit dem EMS-Gateway nicht nachvollziehen... Vermute mal das Problem vom EMS-Gateway könnte sich dann nicht mehr so auswirken. Nur die Telegramme die ein größeres Offset als 0x1b haben könnten das Problem sein. Kleinere Telegramme gehen ja wohl, so wie es aussieht, Problemlos durch. Bin aber natürlich bei der Fehlersuche im EMS-Gateway dabei..
:
Bearbeitet durch User
Niffko _ schrieb: > Fragt man mehr Datenbytes an, als der RC30/35 liefern kann, wird keine > CRC auf den Bus geechot (siehe Anhang). Kann das jemand verifizieren? > Würde man jetzt das letzte Byte für einen CRC-Check hernehmen, geht das > natürlich schief. Ich kann das zwar nicht direkt verifizieren, da der Collector die CRC nicht sieht und ich am NetIO grade kein RS232 angeschlossen habe. Allerdings schließe ich daraus, dass - auf 0x90 0x3d 00 0x2a eine Antwort kommt und - gleichzeitig die Anzahl an Paketen mit CRC-Fehlern im NetIO gleich bleibt (d.h. kein neuer CRC-Fehler auftritt) und - mein ethersex-Code in der Tat das letzte Byte als CRC interpretiert dass ich das Problem nicht sehe. Das ist allerdings noch mit der RC30, mit der RC35 habe ich es noch nicht probiert. BTW, ein paar CRC-Fehler scheinen normal zu sein. Ich habe grad mal in die EMS-Statistik des NetIO geschaut, und der sagt 32326006 korrekte Pakete zu 114743 mit CRC-Fehlern, also eine Fehlerrate von ~0.4% kaputten Paketen. Ich bin mir allerdings nicht ganz sicher, wie das passieren kann... (Anderer Fun Fact am Rande: nur 15% der übertragenen Daten sind wirklich Pakete mit Nutzdaten, der Rest ist Polling ohne Datenübertragung.) Auch noch interessant: mehr als 6000x waren die aufgelaufenen Daten > 64 Byte, was, soweit ich meinen Code noch überblicke, heißt, dass manchmal doch längere Pakete auf dem Bus sind. Das muss ich nochmal mit einem größeren Puffer verifizieren) Ingo F. schrieb: > Niffko _ schrieb: >> Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge >> der abzufragenden Datenchunks von vorn herein auf einen Wert >> festzulegen, der auch sicher geliefert werden kann. > Die CRC werden im collector ja nicht mehr ausgewertet und deswegen > vermutlich erst mal egal. Es wäre vermutlich nicht egal, wenn der Collector keine Antwort bekäme, was bei falscher CRC passieren würde ;-) > Denke dass mit der 00-CRC bei "Überlängen" ist ein spezielles Problem > vom NetIO. Auf dem EMS-Bus werden tzrotzdem CRC gesendet. ??? Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau siehst du ein NetIO-Problem? > Vermute mal das Problem vom EMS-Gateway könnte sich dann nicht mehr so > auswirken. Nur die Telegramme die ein größeres Offset als 0x1b haben > könnten das Problem sein. Kleinere Telegramme gehen ja wohl, so wie es > aussieht, Problemlos durch. Es gibt schon noch andere Telegramme, die in deinem Log komisch aussehen. Z.B. dieses: IO: Sending bytes 0x90 0x37 00 0xc IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x37 00 0xc 0xa0 Bei der Wiederholung hat es funktioniert: IO: Sending bytes 0x90 0x37 00 0xc IO: Got bytes 0xaa 0x55 0xf 0x10 0xb 0x37 00 0xff 00 0x2 0x2 00 0x1 0x1 00 0x3c 0xff 0x58 0x48 oder hier (erste Antwort kaputt, zweite ok): IO: Sending bytes 0x90 0xa5 00 0x19 IO: Sending bytes 0x90 0x3f 0x54 0x1 IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3f 0x54 0x1 0xf1 IO: Got bytes 0xaa 0x55 0x6 0x10 0xb 0x3f 0x54 00 0x15 0x65 oder hier IO: Sending bytes 0x88 0x34 00 0xc IO: Got bytes 0xaa 0x55 0x5 0xb 0x88 0x34 00 0xc 0xbb oder hier (beide kaputt) IO: Sending bytes 0x90 0x37 00 0xc IO: Sending bytes 0x90 0xa5 00 0x19 IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x37 00 0xc 0xa0 IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0xa5 00 0x19 0x27 IMHO existiert da ein systematisches Problem ;-)
Danny Baumann schrieb: > Es wäre vermutlich nicht egal, wenn der Collector keine Antwort bekäme, > was bei falscher CRC passieren würde ;-) Hatte Niffkos Screenshot so verstanden dass der NetIO nur in diesem Fall Telegramme ohne CRC rausschickt. Der collector würde dann das Telegramm trotzdem mit fehlernder CRC bekommen. Aber der collector ignoriert diese CRC. Habe ich das falsch verstanden? Danny Baumann schrieb: > Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau > siehst du ein NetIO-Problem? in seinem Screenshots waren bei den Abfragen mit Längen über 0x1b am Ende immer eine 0x00. Ist das nicht die fehlende CRC? Ist das ein Datenbayte? Da bei mir max 0x1b Datenbytes übermittelt werden habe ich angenommen dass es kein Datenbyte sein kann. Danny Baumann schrieb: > IMHO existiert da ein systematisches Problem ;-) Das wollte ich damit nicht ausschließen. Das ist eine Tatsache dass der EMS-Gateway sich nicht korrekt verhält. Nur funktionieren bei mir die Telegramm mit weniger als 0x1b Daten. Auch wenn sie ab und zu ein zweites mal angefragt werden müssen. Wollte also nicht irgendjemandem die Schuld geben. Würde vernutlich dann bedeuten dass es bei mir dann vermutlich laufen würde wenn nur 0x1b Daten angefragt werden. Habe da so eine Vermutung gehabt was das Problem beim EMS-Gateway verursachen könnte. Aber das war vermutlich ein Irtum.
Ingo F. schrieb: > Hatte Niffkos Screenshot so verstanden dass der NetIO nur in diesem Fall > Telegramme ohne CRC rausschickt. Der collector würde dann das Telegramm > trotzdem mit fehlernder CRC bekommen. Aber der collector ignoriert diese > CRC. > > Habe ich das falsch verstanden? Niffko's Screenshot bezieht sich auf die Antwort, die (in seinem Fall) von der RC30 kommt, nicht darauf, was seine Sendehardware (IIRC verwendet er kein NetIO) rausschickt. Und nochmal ;-) Der Collector sieht nie irgendeine CRC. Entweder die empfangende Hardware (z.B. NetIO) sieht die CRC als OK an und schickt die Daten an den Collector weiter, oder sie schickt die Daten nicht weiter und der Collector sieht gar nix. > Danny Baumann schrieb: >> Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau >> siehst du ein NetIO-Problem? > > in seinem Screenshots waren bei den Abfragen mit Längen über 0x1b am > Ende immer eine 0x00. Ist das nicht die fehlende CRC? Ist das ein > Datenbayte? Ja, das ist ein Datenbyte. Niffko wollte darauf hinaus, dass bei Länge 25 (0x19) die CRC noch da ist, aber ab Länge 26 (0x1a) fehlt, erkennbar an der nicht mehr wachsenden Länge der Telegramme. > Nur funktionieren bei mir die Telegramm mit weniger als 0x1b Daten. Auch > wenn sie ab und zu ein zweites mal angefragt werden müssen. Das sehe ich eben anders - genau deshalb habe ich ja ein paar Telegramme mit Länge < 27 rausgepickt, die auch kaputt sind. Soweit ich das beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas grundsätzliches kaputt, was ein erfolgreiches Senden - völlig unabhängig von der angefragten Länge - zur Glückssache macht. Ich denke, dass die beste Idee wäre, zuerst dieses Problem zu fixen, und dann auf eventuelle Probleme mit bestimmten abgefragten Längen zu schauen. IMHO besteht eine nicht allzukleine Wahrscheinlichkeit, dass diese sich nach der Behebung des generellen Problems in Luft auflösen werden. Für das Debugging würde ich übrigens empfehlen, das Webfrontend erstmal komplett wegzulassen und nur die Telnet-Schnittstelle des Collectors zu verwenden, um die Komplexität runterzubekommen. Dann mit ein paar einfachen Befehlen anfangen (WW-Temperatur, Tag-/Nachtmodus, Ferienzeit usw.), um zu schauen, wie sich nicht fragmentierte Pakete verhalten, und gleichzeitig Gateway- und Collector-IO-Log beobachten. Dann beobachtete Inkonsistenzen fixen ;-) Wenn das geht, zu fragmentierten Paketen (Schaltzeitplan, 'hk1 requestdata' usw.) übergehen.
Danny Baumann schrieb: > Soweit ich das > beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas > grundsätzliches kaputt, Habe doch gesagt dass das eine Tatsache ist.... Danny Baumann schrieb: > und nur die Telnet-Schnittstelle des Collectors zu > verwenden, Wie bekomme ich dass denn hin? habe das cli von Moosys ems-tools genommen. Gibt es noch eine direkt Möglichkeit über telnet? Wenn ja, wie komme ich da hin? Beim Telnet auf 7777 und 7778 kommt sofort Die Verbindung wurde abgebrochen. Wäre der Telnet auf die Ports OK oder liege ich da falsch? Habe noch den Appache laufen. Aber die Webseite vom Fronend nicht geöffnet also dürfte der Port doch nicht belegt sein. Das Log vom EMS-Gateway für den collector-Port gibt es nicht wirklich soweit ich das sehe. Das Log über den USB-Port sieht ja anders aus. Müsste da wohl einen Spiegelport einrichten und wireshark nehmen.
Ingo F. schrieb: > Danny Baumann schrieb: >> Soweit ich das >> beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas >> grundsätzliches kaputt, > > Habe doch gesagt dass das eine Tatsache ist.... Ich will's dir ja auch nicht unter die Nase reiben :) Ich wollte einfach nur sagen, dass es sich IMHO nicht lohnt, sich auf das Längenproblem zu konzentrieren, wenn das wahrscheinlich nur ein Symptom eines anderen Problems ist. > > Danny Baumann schrieb: >> und nur die Telnet-Schnittstelle des Collectors zu >> verwenden, > > Wie bekomme ich dass denn hin? > habe das cli von Moosys ems-tools genommen. > > Gibt es noch eine direkt Möglichkeit über telnet? Wenn ja, wie komme ich > da hin? Beim Telnet auf 7777 und 7778 kommt sofort Die Verbindung wurde > abgebrochen. Genau das (Telnet auf 7777) sollte gehen {wenn entsprechend konfiguriert - wenn das nicht der Fall wäre, würde das Frontend aber auch nicht funktionieren). > Wäre der Telnet auf die Ports OK oder liege ich da falsch? Habe noch den > Appache laufen. Aber die Webseite vom Fronend nicht geöffnet also dürfte > der Port doch nicht belegt sein. Der Port akzeptiert auch mehrere gleichzeitige Verbindungen und lauscht auch auf Verbindungen von anderen Rechnern. Eventuell ein Firewall-Problem o.Ä.? > Das Log vom EMS-Gateway für den collector-Port gibt es nicht wirklich > soweit ich das sehe. Das Log über den USB-Port sieht ja anders aus. > Müsste da wohl einen Spiegelport einrichten und wireshark nehmen. Gut, das kann ich schlecht beurteilen. Das Log, was du oben gepostet hättest, sah nur ganz brauchbar aus.
Ja seht ihr denn die Zeichen nicht :-) Auszüge aus Ingos ems.log :
1 | MESSAGE[15.03.2015 19:03:38]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x34 0x02 0x0a ... |
2 | MESSAGE[15.03.2015 19:03:39]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a |
3 | MESSAGE[15.03.2015 19:03:40]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a |
4 | MESSAGE[15.03.2015 19:03:41]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a |
5 | MESSAGE[15.03.2015 19:03:43]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x34 0x02 0x09 ... |
Abfrage von 0x2A Bytes -> keine Antwort bei drei Versuchen
1 | MESSAGE[15.03.2015 19:02:18]: source 0x08, dest 0x0b, type 0x34, offset 0, data: 0x0a 0x01 0xa7 ... |
2 | MESSAGE[15.03.2015 19:02:18]: source 0x0b, dest 0x90, type 0x37, offset 0, data: 0x0c |
3 | MESSAGE[15.03.2015 19:02:18]: source 0x10, dest 0x0b, type 0x37, offset 0, data: 0xff 0x00 0x02 0x02 0x00 ... |
4 | MESSAGE[15.03.2015 19:02:48]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x34 0x02 0x13 ... |
Abfrage von 0x0C Bytes -> Antwort erfolgt //Niffko
Niffko _ schrieb: > Ja seht ihr denn die Zeichen nicht :-) Was meinst Du damit? Dass nach der (partiellen) Sonnenfinsternis die Welt untergeht :-D
:
Bearbeitet durch User
Niffko _ schrieb: > Ja seht ihr denn die Zeichen nicht :-) Ach menno, jetzt lenk den Ingo doch nicht wieder vom eigentlichen Problem ab ;-) > Auszüge aus Ingos ems.log : > [snip] Etwas später im Log:
1 | IO: Sending bytes 0x90 0x3d 00 0x2a |
2 | IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3d 00 0x2a 0x8c |
3 | IO: Got bytes 0xaa 0x55 0x20 |
4 | IO: Sending bytes 0x90 0x3d 00 0x2a |
5 | IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3d 00 0x2a 0x8c |
6 | IO: Got bytes 0xaa 0x55 0x20 |
7 | IO: Sending bytes 0x90 0x3d 00 0x2a |
8 | IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3d 00 0x2a 0x8c |
9 | MESSAGE[18.03.2015 16:44:28]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a |
Da wird dann auch ziemlich deutlich, warum keine weiteren Message-Zeilen kommen. Bei deinem Problem halte ich bei nochmaligem drüber nachdenken auch einen Bug im Empfänger-Code für möglich. Zumindest ist auffällig, dass du nur bis 25 Byte empfangen kannst, während die RC30 bei mir und die RC35 bei Ingo 27 Bytes schickt [ich teste morgen auch noch mal mit der RC35]. Eventuell ein Puffer zu klein o.Ä.?
Danny Baumann schrieb: > ... Bug im Empfänger-Code ... Eventuell ein Puffer zu klein o.Ä.? Tja Danny, was soll ich sagen ... Punktlandung! Die Diskrepanz von meinen 26 zu euren 27 Bytes ist mir nicht aufgefallen :( Jedenfalls ... kaum macht man den Empfangsbuffer etwas größer, klappts auch mit der CRC * facepalm * //Niffko
Hallo! Ich habe ein Heizung mit Solarmodul (SM10). Die Telegramme dazu sind ja schon im Wiki. Ist eine Aufnahme in den collector geplant? Wenn ja wann? Habe mir den Sourcecode mal angesehen. Wie müssen die Werte der Tabelle umgesetzt werden? Wäre das als Beispiel richtig? Gibt es Regeln für die Werte Namen (Pumpe & Aussentemp ist ja nicht eindeutig)?
1 | void |
2 | EmsMessage::parseSMMonitor() |
3 | {
|
4 | parseNumeric(0, 2, 10, EmsValue::SollTemp, EmsValue::None); |
5 | parseInteger(2, 1, EmsValue::Mischersteuerung, EmsValue::None); |
6 | parseNumeric(3, 2, 10, EmsValue::IstTemp, EmsValue::None); |
7 | /* ??? */ |
8 | parseBool(5, 1, EmsValue::PumpeAktiv, EmsValue::None); |
9 | parseInteger(7, 3, EmsValue::Mischersteuerung, EmsValue::None); |
10 | } |
Danke und Gruß JayKay
Hallo Dany, wie sollte denn die richtige Kommunikation zwischen EMS-Gateway/NetIO und collector aussehen? ALso z.B. zum zum NetIO: 90 06 00 06 (Empfänger, Typ, Offset, Anzahl) vom NetIO: 10 0b 06 00 11 22 33 44 55 66 Gruß Ingo
Kay F. schrieb: > Hallo! > > Ich habe ein Heizung mit Solarmodul (SM10). Die Telegramme dazu sind ja > schon im Wiki. Ist eine Aufnahme in den collector geplant? Wenn ja wann? Geplant ist da eigentlich nie etwas ;-) Entweder es gibt genügend (eindeutige) Informationen und jemand spricht mich drauf an, oder es schickt jemand einen Pull Request. Für SM10 Monitor hab ich das grad mal gemacht: https://github.com/maniac103/ems-collector/commit/7c9166f31401c3fab257cc0a3f074c5507ff865f - probier mal. Die Offsets im Wiki sehen allerdings komisch aus, so dass es nett wäre, wenn du mal ein Collector-Log mit Message-Debug, in dem die Nachrichten 0x96 und 0x97 enthalten sind, hochladen könntest. > Habe mir den Sourcecode mal angesehen. Wie müssen die Werte der Tabelle > umgesetzt werden? Wäre das als Beispiel richtig? Gibt es Regeln für die > Werte Namen (Pumpe & Aussentemp ist ja nicht eindeutig)? 'Type' ist die Art des Wertes, 'Subtype' eine Klassifizierung, wo der Wert herkommt. Es ist dabei nicht wirklich wichtig, unbedingt mit den existierenden Bezeichnungen auszukommen; wichtiger ist es, dass der Wert sinnvoll beschrieben ist. Essenziell ist allerdings, dass jede Kombination aus Type + Subtype eindeutig ist, da diese Kombination letztendlich den Sensor beschreibt. > parseNumeric(0, 2, 10, EmsValue::SollTemp, EmsValue::None); Ich denke, dass ist die Außentemperatur? (Interessant ist, dass du Offset 0 verwendest, was nicht zum Wiki passt - daher mein Kommentar oben) > parseInteger(2, 1, EmsValue::Mischersteuerung, EmsValue::None); Das ist doch eine Pumpenmodulation, also EmsValue::IstModulation. > parseNumeric(3, 2, 10, EmsValue::IstTemp, EmsValue::None); IstTemp ist richtig, ich habe dafür den Subtype 'SolarSpeicher' eingeführt. > parseBool(5, 1, EmsValue::PumpeAktiv, EmsValue::None); Das braucht noch einen Subtype, ist aber ansonsten korrekt. > parseInteger(7, 3, EmsValue::Mischersteuerung, EmsValue::None); EmsValue::Betriebszeit (zumindest laut Wiki)
Ingo F. schrieb: > Hallo Dany, > > wie sollte denn die richtige Kommunikation zwischen EMS-Gateway/NetIO > und collector aussehen? http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio :-) > zum zum NetIO: > 90 06 00 06 (Empfänger, Typ, Offset, Anzahl) Das würde die ersten 6 Bytes des Telegramms 6 vom RC abfragen, ja. > vom NetIO: > 10 0b 06 00 11 22 33 44 55 66 Da fehlt 0xaa 0x55 + Länge am Anfang und XOR über die Daten am Ende.
Hallo Danny, hier schon mal der Auszug für source 0x30 & type 0x97 (type 0x96 habe ich noch nicht im Logfile gefunden):
1 | IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 00 0x1f 00 0x1 0xb8 0x1 0x4 0x99 0x91 00 0xa 0x6 |
2 | MESSAGE[10.03.2015 21:11:54]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x00 0x1f 0x00 0x01 0xb8 0x01 0x04 0x99 0x91 0x00 0x0a |
3 | DATA: Unhandled message received(source 0x30, type 0x97). |
4 | IO: Got bytes 0xaa 0x55 0x7 0x30 0x8 0x35 00 00 00 0xf6 0xfb |
5 | MESSAGE[10.03.2015 21:11:54]: source 0x30, dest 0x08, type 0x35, offset 0, data: 0x00 0x00 0xf6 |
6 | DATA: Unhandled message received(source 0x30, type 0x35). |
7 | IO: Got bytes 0xaa 0x55 0x6 0x10 0x8 0x35 00 0x11 0x11 0x2d |
8 | |
9 | |
10 | IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 00 0x1f 00 0x1 0xb8 0x1 0x4 0x99 0x91 00 0xa 0x6 |
11 | MESSAGE[10.03.2015 21:12:54]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x00 0x1f 0x00 0x01 0xb8 0x01 0x04 0x99 0x91 0x00 0x0a |
12 | DATA: Unhandled message received(source 0x30, type 0x97). |
13 | IO: Got bytes 0xaa 0x55 0x7 0x30 0x8 0x35 00 00 00 0xf6 0xfb |
14 | MESSAGE[10.03.2015 21:12:55]: source 0x30, dest 0x08, type 0x35, offset 0, data: 0x00 0x00 0xf6 |
15 | DATA: Unhandled message received(source 0x30, type 0x35). |
16 | |
17 | |
18 | IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 0x2 0x34 0x5e 0x1 0xcf 0x3 0x4 0xa2 0xfb 00 0xa 0x55 |
19 | MESSAGE[22.03.2015 17:08:21]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x02 0x34 0x5e 0x01 0xcf 0x03 0x04 0xa2 0xfb 0x00 0x0a |
20 | DATA: Istwert Modulation = 94 % |
21 | DATA: Solarspeicher-Isttemperatur = 46.3 °C |
22 | DATA: Solar-Pumpe = AN |
23 | DATA: Solar-Betriebszeit = 303867 min |
Im Display der RC35 steht: Kollektor 48 Grad Speicher mitte 46 Grad Speicher unten 46 Grad Solar-Pumpe 0% Betriebsstunden 5064h 38 min
1 | IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 0x1 0xe1 00 0x1 0xce 0x1 0x4 0xa3 0x6 00 0xa 0x22 |
2 | MESSAGE[22.03.2015 17:24:27]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x01 0xe1 0x00 0x01 0xce 0x01 0x04 0xa3 0x06 0x00 0x0a |
3 | DATA: Istwert Modulation = 0 % |
4 | DATA: Solarspeicher-Isttemperatur = 46.2 °C |
5 | DATA: Solar-Pumpe = AUS |
6 | DATA: Solar-Betriebszeit = 303878 min |
Mir ist nur nicht ganz klar warum die Message teilweise Unhandled ist. Gruß JayKay
Kay F. schrieb: > Im Display der RC35 steht: > > Kollektor 48 Grad > Speicher mitte 46 Grad > Speicher unten 46 Grad > Solar-Pumpe 0% > Betriebsstunden 5064h 38 min > > >
1 | > IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 0x1 0xe1 00 0x1 0xce |
2 | > 0x1 0x4 0xa3 0x6 00 0xa 0x22 |
3 | > MESSAGE[22.03.2015 17:24:27]: source 0x30, dest 0x00, type 0x97, offset |
4 | > 0, data: 0x00 0x00 0x01 0xe1 0x00 0x01 0xce 0x01 0x04 0xa3 0x06 0x00 |
5 | > 0x0a |
6 | > DATA: Istwert Modulation = 0 % |
7 | > DATA: Solarspeicher-Isttemperatur = 46.2 °C |
8 | > DATA: Solar-Pumpe = AUS |
9 | > DATA: Solar-Betriebszeit = 303878 min |
10 | > |
Sieht doch schon mal gut aus. Die Kollektortemperatur steht an Offset 2,
die baue ich morgen noch ein. Wo die RC35 allerdings 2
Speichertemperaturen hernimmt ist mir nicht klar.
> Mir ist nur nicht ganz klar warum die Message teilweise Unhandled ist.
Naja, Nachrichten, die kamen, bevor ich die Behandlung dieser Nachricht
heute eingebaut habe, sind halt ... unbehandelt ;)
Ingo F. schrieb: > Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und > bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset > 0x1C (=28) abgefragt. > Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag > ausgelassen und daher wohl vom Frontend ignoriert. Hallo Danny, HURRA, ich habe den Fehler im EMS-Gateway endlich gefunden!!! Jetzt komme ich wieder zu meinem Problem. Das Offset der Daten wird falsch berechnet. Denke die XOR-Prüfsumme wird als Daten angesehen und mitgezählt. Hier mal das Beispiel der Kontaktdaten. Est kommen 21 Byte Kontaktinfo1 und dann 15 Byte Kontaktinfo2. Bei mir vorher gesetzt: abcdefghijklmnopqrstu ABCDEFGHIJKLMNOPQRSTU Zurück wird gegeben: abcdefghijklmnopqrstu ABCDE`GHIJKLMNOPQRSTU Das erste Telegramm das abgefragt wird ist dieses:
1 | 10 0b a4 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 41 42 43 44 45 46 91 |
die XOR-Prüfsumme 0x91 am Ende enstpricht der Position des "F" was als "`" (0x91) beim auslesen zurückgegeben wird. Ich habe noch weitere Proleme. Denke die sind vermutlich auch auf diesen Fehler zurückzuführen. (Schaltzeit die auf dieser Stelle zwischen zwei Telegramme befindet)
Danny Baumann schrieb: > Bitte einmal IO- und Message-Log :) kannste haben... Also ich habe im Frontend die "Einstellungen" Seite geladen und den collector restartet. Dann noch mal die beiden Werte gesetzte (Telegramm A4) abcdefghijklmnopqrstu ABCDEFGHIJKLMNOPQRSTU und dann noch mal die Werte abgerufen. das F wird dann durch die Prüfsumme 0x91 ersetzt. Gruß Ingo
Ingo F. schrieb: > und dann noch mal die Werte abgerufen. > das F wird dann durch die Prüfsumme 0x91 ersetzt. Die Prüfsumme ist nicht 0x91, sondern 0x48. Schau selbst:
1 | IO: Sending bytes 0x90 0xa4 00 0x2a |
Anforderung von 42 Bytes aus Telegramm 0xa4, Offset 0
1 | IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0xa4 00 0x2a 0x15 |
Echo des gesendeten Paketes? (das gehört da nicht hin)
1 | IO: Got bytes 0xaa 0x55 0x20 0x10 0xb 0xa4 00 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f 0x70 0x71 0x72 0x73 0x74 0x75 0x41 0x42 0x43 0x44 0x45 0x46 0x91 0x48 |
Antwort mit 32 Bytes (Quelle 0x10, Ziel 0x0b, Typ 0xa4, Offset 0): 0x61, 0x62, ..., 0x91; Prüfsumme 0x48 Du schickst also ein Byte zu viel - da wirst du doch noch mal in deinen Code schauen müssen ;-)
War so froh den Fehler gefunden zu haben dass ich erst das Log hochgeladen habe und erst danach angesehen habe. Aber das eine Byte abziehen das sollte ich wohl hinbekommen ... Habe das eine Byte zuviel auch dann genau zu der Zeit gefunden als Du geantwortet hast...
:
Bearbeitet durch User
Danny Baumann schrieb: > Echo des gesendeten Paketes? (das gehört da nicht hin) Stimmt schon... aber das werde ich mir dannach ansehen. Im Moment wird alles was auf dem EMS-Bus ankommt zum collector rübergeschaufelt. Das ist dann auch das Echo des selbst gesendeten Befehls. Werde dann die Echos der selbst gesendeten Befehle noch mal herausfiltern. Eigentlich dürfte dass kein zu großes Problem sein. Aber mal abwarten... Aber das scheint der collector erst mal zu ignorieren. Gruß Ingo
Das war der selbe Text nochmal... Habs mal gelöscht...
:
Bearbeitet durch User
Danny, hast Du mal ein 0x18 und 0x19 Telegramm aus Deinem Log? Wäre mal gut ein Telegramm so zu sehen wie es aussehen soll. Habe das eine Byte "entfernt" jetzt sieht eigentlich alles gut aus, aber jetzt läuft nichts mehr..
Ingo F. schrieb: > Danny, hast Du mal ein 0x18 und 0x19 Telegramm aus Deinem Log? > > Wäre mal gut ein Telegramm so zu sehen wie es aussehen soll. Bitteschön:
1 | IO: Got bytes 0xaa 0x55 0x1d 0x8 00 0x18 00 0x2a 0x1 0xfe 0x3a 0x29 0x9 0x1 0x25 0x60 0x80 00 0x1 0xc3 0x1 0xcf 00 0x76 0x10 0x2d 0x48 00 0xc8 0xff 0x2 00 0x21 |
2 | IO: Got bytes 0xaa 0x55 0x1d 0x8 00 0x19 00 00 0x3e 0x1 0xf7 0x80 00 00 00 00 0x37 0x1 0xc7 0x4a 0x7 0xe9 0xa6 00 00 00 0x6 0xf1 0x8d 0x1 0xb4 0xb7 0xd2 |
> Habe das eine Byte "entfernt" jetzt sieht eigentlich alles gut aus, aber > jetzt läuft nichts mehr.. Definiere 'nichts mehr' ;-) Auslesen wird doch schon noch gehen, oder?
Danny Baumann schrieb: > 'nichts mehr' Bedeutet das nichts mehr geht ;-) Das waren aber zwei andere Fehler. Mein provisorischer Server ist mit WLAN angebunden und hatte die WLAN-Verbindung verloren. Der Collector ließ sich wie immer mit Restart neustarten und zeigt OK an. Als ich dann aber mal "service ems-collector stop" abgesetzt habe hieß es dann "Kill: Kein laufender Service gefunden [Fail]" Nach einem Neustart funktioniert schon fast alles. Nur die Einstellungen werden ab 50% langsamer. Einige Telegramme haben jetzt wohl Probleme... Aber die Schaltzeiten, LiveStatus, Protokoll laufen Problemlos. Werde erst mal das Befehls-Echo rausnehmen und mir das noch mal genauer ansehen.
:
Bearbeitet durch User
So, jetzt funktioniert fast alles. Einfach ein Byte weglassen war nciht ganz so einfach. Musste doch mehr geändert werden. Das Befehlsecho und das überflüssige Byte sind jetzt auch weg. Wenn ich die Schaltzeiten auslese werden sie jetzt auch korrekt angezeigt. Nur das schrieben klappt nicht. Muss mir mal nächste Zeit das Log ansehen. Moosys Frontend möchte einen Wert setzten un bekommt nur als Antwort den Status 01 = OK. So wie es aussieht ist der Frontend damit nicht zufrieden und setzt dann noch vier weitere Male den Wert. Dann stürzt bei mir der collectord ab und ich muss den service stoppen und neu starten, sonst meckert das Frontend dass keine Verbindung zum EMS-Bus vorhanden ist. Und es läuft wieder nichts.
Ingo F. schrieb: > Moosys Frontend möchte einen Wert setzten un bekommt nur als Antwort den > Status 01 = OK. So wie es aussieht ist der Frontend damit nicht > zufrieden und setzt dann noch vier weitere Male den Wert. Komisch. Welcher Wert ist das? Status 01 sollte dazu führen, dass der Collector 'OK' meldet, vielleicht ist da irgendwas kaputt. Schick mal das Log von der Stelle, dann schau ich mir das mal an. > Dann stürzt bei mir der collectord ab und ich muss den service stoppen > und neu starten, sonst meckert das Frontend dass keine Verbindung zum > EMS-Bus vorhanden ist. Und es läuft wieder nichts. Wann genau ist 'dann'? Ist der Absturz reproduzierbar? Wenn ja, Log bitte ;) An der Stelle sind gleich 2 Dinge komisch: der Collector sollte nicht abstürzen ;) und wenn er es schon tut, sollte er doch vom Init-System neu gestartet werden?
Danny Baumann schrieb: > vielleicht ist da irgendwas kaputt. Schick mal > das Log von der Stelle Werde ich dann machen wird aber noch etwas dauern... Danny Baumann schrieb: > Wann genau ist 'dann'? Ist der Absturz reproduzierbar? Habe es zwei mal ausprobiert. Zweimal sah es so aus als ob der collector abgestürzt ist. Frontend sagte dannach immer "FATAL: keine Verbindung zum EMS-Bus" (oder ähnlich). Danny Baumann schrieb: > und wenn er es schon tut, sollte er doch vom > Init-System neu gestartet werden? kenne mich damit nicht so genau aus. Dauert das länger? Hatte eigentlich gedacht dass der collector nach dem Rechnerstart automatisch startet. Muss aber immer mit service ems-collector nach dem Booten starten. dachte durch das eintragen mit „update-rc.d ems-collector defaults“ würde der automatisch starten..
Ingo F. schrieb: >> Wann genau ist 'dann'? Ist der Absturz reproduzierbar? > > Habe es zwei mal ausprobiert. Zweimal sah es so aus als ob der collector > abgestürzt ist. Frontend sagte dannach immer "FATAL: keine Verbindung > zum EMS-Bus" (oder ähnlich). Was genau hast du an der Stelle gemacht? > Danny Baumann schrieb: >> und wenn er es schon tut, sollte er doch vom >> Init-System neu gestartet werden? > > kenne mich damit nicht so genau aus. Dauert das länger? Hatte eigentlich > gedacht dass der collector nach dem Rechnerstart automatisch startet. > Muss aber immer mit service ems-collector nach dem Booten starten. > > dachte durch das eintragen mit „update-rc.d ems-collector defaults“ > würde der automatisch starten.. Ich bin mir nicht sicher. Ein service ems-collector enable wird das aber sicherstellen.
Danny Baumann schrieb: > Ich bin mir nicht sicher. Ein service ems-collector enable wird das aber > sicherstellen. enable kennt er nicht bei mir... Habe es heute noch mal getestet und kann sagen der Fehler ist nicht reproduzierbar. Also muss dass gestern an meinem Rechner oder mit der WLAN-Anbindung zusammengehangen habe?! Vielleicht habe ich auch mit VI in der Logdatei herumgespielt als der collector in die Logdatei schreiben wollte. Also ich habe gestern und heute im Frontend unten eine Zeit von 23:30 auf 23:00 (ohne Enter zu drücken) geändert und oben rechts auf senden geklickt. Dann wurde mehrfach 10 3F 00 01 1E gesendet und als Antwort kam immer die 01 Nach insgesamt etwa 10 Sekunden kommt *Error while programming!* In Deinem Log sah es dann etwa so aus: MESSAGE[01.04.2015 11:33:41]: source 0x00, dest 0x00, type 0x00, offset 0, data: 0x01 IO: Sending bytes 0x10 0x3f 00 0x1 0x1e IO: Got bytes 0xaa 0x55 0x1 0x1 0x1 Hatt einmal aber auch die Antwort im Log vor dem absenden der Nachricht. Aber das wird vermutlich am Logging liegen, oder. Beim senden ist kein Zeitstempel dabei. Die Bestäütigung müsste so doch richtig sein, oder? Andere Daten kann ich schreiben. Beim Frontend gibt es noch das Problem dass beim ändern und lesen der max.Vorlauftemperatur immer das Offset von 0x23 verwendet wird. Und nicht das Offset 0x1E aus dem Wiki. Bei meiner RC35 liegt der auch wohl dort. Das scheint aber eine schreibgeschütze Stelle im Telegramm zu sein die immer auf 0x32=50 steht.
Ingo F. schrieb: > In Deinem Log sah es dann etwa so aus: > > MESSAGE[01.04.2015 11:33:41]: source 0x00, dest 0x00, type 0x00, offset > 0, data: 0x01 > IO: Sending bytes 0x10 0x3f 00 0x1 0x1e > IO: Got bytes 0xaa 0x55 0x1 0x1 0x1 Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors ;-) Ich mache aus den ACK und NACK ein Fake-Paket, damit der Parsing-Code das direkt ohne Spezialfälle verabeiten kann. Das heißt, dass das Gateway aus dem 0x1 folgendes machen muss: <source> 0x0b 0xff 0x01 <source> ist dabei das Ziel der letzten Schreiboperation, in deinem konkreten Fall also 0x10. Für 0x4 gilt das Ganze entsprechend. Meinen Code dafür kannst du hier finden: https://github.com/maniac103/ethersex/blob/master/protocols/ems/ems_proto.c#L62 Ich habe das gleich mal im Wiki entsprechend dokumentiert. > Beim Frontend gibt es noch das Problem dass beim ändern und lesen der > max.Vorlauftemperatur immer das Offset von 0x23 verwendet wird. Und > nicht das Offset 0x1E aus dem Wiki. Bei meiner RC35 liegt der auch wohl > dort. Soweit ich das sehe, sendet Moosy bei der max. Vorlauftemperatur das Kommando "hk1 heatflowtemperature <value>", was der Collector auf Telegramm 61, Datenoffset 15 mappt, was wiederum laut Wiki korrekt ist (im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen Offset 20). Wie kommst du auf die 0x23 und die 0x1e? 0x1e = 30 ist - je nach Zählung - entweder undefiniert oder die Betriebsart, aber auf keinen Fall die maximale Vorlauftemperatur.
:
Bearbeitet durch User
Danny Baumann schrieb: > Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors > ;-) Wie wird dass den beim NetIO gemacht? sendet der auch so ein "Pseudo-Frame"? Sonst müsste das ja auch noch dort geändert werden. Das heisst also dass die anderen "Schreibbefehle" funktionieren weil dort die Bestätigung nicht abgewartet wird? Danny Baumann schrieb: > 0x23 und die 0x1e? 0x1e = 30 weil dort fünf mal ein Schreibbefehl an das Offset 0x23 kommt. das 0x1E war nur geistige Verwirrung ;-) sollte 0x0F heissen was ja die 15 ist. Danny Baumann schrieb: > im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen > Offset 20 Hatte auch schon mal überlegt dass komplett zu ändern. Meistens benötigt man ja auch das Datenoffset und nicht das Telegrammoffset.
Ingo F. schrieb: > Danny Baumann schrieb: >> Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors >> ;-) > > Wie wird dass den beim NetIO gemacht? sendet der auch so ein > "Pseudo-Frame"? Ja klar, sonst hätte ich doch den Collector nicht so gebaut :) Die Stelle im Code, die dieses Fake-Telegramm erzeugt, hatte ich ja schon verlinkt. > Das heisst also dass die anderen "Schreibbefehle" funktionieren weil > dort die Bestätigung nicht abgewartet wird? Ich weiß aus dem Stegreif nicht, was Moosy da tut, aber ich vermute mal, dass das stimmt. 'Einteilige' Zugriffe funktionieren, mehrteilige nicht. > Danny Baumann schrieb: >> 0x23 und die 0x1e? 0x1e = 30 > > weil dort fünf mal ein Schreibbefehl an das Offset 0x23 kommt. Kann ich dafür bitte ein Log haben? Ich finde spontan keine Referenz auf Offset 0x23 bzw. 35 im Code. > Danny Baumann schrieb: >> im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen >> Offset 20 > > Hatte auch schon mal überlegt dass komplett zu ändern. Meistens benötigt > man ja auch das Datenoffset und nicht das Telegrammoffset. Jup. Ich werde das mal umstellen, wenn ich mal die Zeit finde.
> Kann ich dafür bitte ein Log haben? Ich finde spontan keine Referenz auf > Offset 0x23 bzw. 35 im Code. Sicher.. Aber vor Montag/Dienstag wird sich nichts mehr tun..
Danny Baumann schrieb: > Ich finde spontan keine Referenz auf > Offset 0x23 bzw. 35 im Code. Moin die Herren, 0x3D->0x23 ist die maximale Vorlauftremperatur speziell für Fußbodenheizung (RC35 only). Ist ein anderes Heizsystem eingestellt, muss der bekannte Offset benutzt werden. Schöne Ostern. //Niffko
Niffko _ schrieb: > 0x3D->0x23 ist die maximale Vorlauftremperatur speziell für > Fußbodenheizung (RC35 only). Ist ein anderes Heizsystem eingestellt, > muss der bekannte Offset benutzt werden. Danke für die Erinnerung. Dann ist klar dass ich das nicht sehe, weil ich das erst vor kurzem (noch nicht vollständig) umgestellt habe und Moosy vorher immer 0x23 verwendet hat. Das ist ein noch offenes TODO. > Schöne Ostern. Danke gleichfalls :)
Danny Baumann schrieb: >> Schöne Ostern. Wünsche ich auch allen.. Danny Baumann schrieb: > Ja klar, sonst hätte ich doch den Collector nicht so gebaut :) Die > Stelle im Code, die dieses Fake-Telegramm erzeugt, hatte ich ja schon > verlinkt. Hatte das mal wieder falsch verstanden. Dachte es wäre der Collcetor-Code und nicht vom NetIO. Also beim EMS-Gateway wird jetzt auch das ACK/NACK richtig zum Collcetor gesendet z.B.: AA 55 04 10 0B FF 01 E5 Schreiben klappt jetzt auch mit dem EMS-Gateway über Moosys Frontend. Noch mal eine Frage zum PseudoTelegramm vom NetIO. Werden andere NACK/ACK herausgefiltert? Oder was passiert dann? Es könnte ja passieren dass der collector und ein anderer direkter EMS-Busteilnehmer an den selben Teilnehmer einen Set-Befehl sendet. Wenn einer mit ACK und der andere mit NACK betsätigt wird kann es ja zu Problemen kommen. Welches ist jetzt für den collector? Gibt zwei Möglichkeiten: Andere Bestätigungen komplett rausfiltern oder alle ACK NACK die kommen mit 0x00 statt der Adresse im Pseudotelegramm zu setzen. Damit wäre ein unterscheiden wieder möglich. Danny Baumann schrieb: > Moosy vorher immer 0x23 Wo ist denn das aktuelle Frontend? dass von Moosy oder irgend ein Fork davon? Auf dem Master sind ja schon lange keine Aktivitäten mehr, oder habe ich die Übersicht bei GIT falsch interpretiert? @Danny, würde gerne meine anderen Telegramme auch über den Collector laufen lassen. Wie könnte ich am besten andere Telegramme über den Collector abarbeiten lassen? Also am einfachsten wäre eine Abarbeitung über eine extra Quellcode-Datei? Möchte ja nicht jedesmal wenn Du was am collector änderst auch den ganzen Code an meinem Fork ändern. Ein Telegramm sieht z.B. so aus: 81 11 23 45 00 08 0f 00 16 0d 42 09 15 0a (Extended-CAN. Normales Standart-CAN = 0x80) Sind ein paar 1Wire-Sensoren und andere Daten die ich auch in eine MySQL-Datenbank schieben würde.
Ingo F. schrieb: > Noch mal eine Frage zum PseudoTelegramm vom NetIO. > Werden andere NACK/ACK herausgefiltert? Oder was passiert dann? Die werden ignoriert. > Es könnte ja passieren dass der collector und ein anderer direkter > EMS-Busteilnehmer an den selben Teilnehmer einen Set-Befehl sendet. Wenn > einer mit ACK und der andere mit NACK betsätigt wird kann es ja zu > Problemen kommen. Welches ist jetzt für den collector? Wenn das NETIO gerade einen Befehl abgesetzt hat (nachdem es vom Master dazu aufgefordert wurde), weiß es, dass das nächste ACK oder NACK das kommt, die Antwort auf den Befehl ist. Jemand anderes kann in diesem Moment nix senden (zumindest nicht, wenn er sich korrekt verhält), da er ja nicht 'dran' ist. > Gibt zwei Möglichkeiten: Andere Bestätigungen komplett rausfiltern oder > alle ACK NACK die kommen mit 0x00 statt der Adresse im Pseudotelegramm > zu setzen. Damit wäre ein unterscheiden wieder möglich. Ja, oder die (N)ACKs denen zuordnen, die zuletzt kommuniziert haben. Ist aber IMHO sinnlos, da diese Antworten ohnehin uninteressant sind. > Danny Baumann schrieb: >> Moosy vorher immer 0x23 > > Wo ist denn das aktuelle Frontend? dass von Moosy oder irgend ein Fork > davon? Auf dem Master sind ja schon lange keine Aktivitäten mehr, oder > habe ich die Übersicht bei GIT falsch interpretiert? Ja, das von Moosy, und nein, das hast du schon richtig gesehen. Ich habe das Interface zwischen Collector und Frontend allerdings auch ewig nicht (inkompatibel) verändert, so dass diesbezüglich keine Änderungen nötig waren. Meine Ausführungen bzgl. 0x23 bezogen sich auf die Implementierung des Auslegungstemperaturkommandos im Collector. > @Danny, würde gerne meine anderen Telegramme auch über den Collector > laufen lassen. Wie könnte ich am besten andere Telegramme über den > Collector abarbeiten lassen? Mit einer neuen Message-Klasse, die im IOHandler entsprechend angelegt wird. Dafür braucht es natürlich ein Unterscheidungsmerkmal zu den EMS-Telegrammen. > Also am einfachsten wäre eine Abarbeitung über eine extra > Quellcode-Datei? > Möchte ja nicht jedesmal wenn Du was am collector änderst auch den > ganzen Code an meinem Fork ändern. Naja, das wäre im Zweifelsfall auch kein größeres Problem. 'git merge' ist recht mächtig :) > Ein Telegramm sieht z.B. so aus: > 81 11 23 45 00 08 0f 00 16 0d 42 09 15 0a Ich überblicke das Format zwar spontan nicht, aber ich muss es ja auch nicht implementieren ;)
Angehängte Dateien:
-
P0.png
16 KB -
P1.jpg
130 KB -
P2-99R.jpg
130 KB -
P3-2n5a.jpg
130 KB
Hallo zusammen, nachdem ich das Thema NETIO und EMS schon seit Jahresanfang beobachte, habe ich mir nun auch eine eigene Platine mit AVR und EMS-Anschaltung gebaut. Das Empfangen funktioniert nun auch schon mehrere Wochen prima, die Werte werden einwandfrei in fhem mithilfe des collectord mitprotokolliert. Nun wollte ich mal das Senden testen und - es klappt nicht. Ich habe in ethersex den EMS-Code mit Debugging etwas erweitert und gesehen, daß ca. alle 3 Sek. auf die Adresse 0x0B reagiert wird und das gleiche Byte auch wieder rausgeschickt wird. Auch längere Codesequenzen werden (zumindest vom Controller aus) verschickt. Aber z.B. ein einfaches "getversion" läuft auf Timeout. Nun habe ich mein Oszi rangeklemmt und etwas seltsame Kurven angezeigt bekommen. Meiner Meinung nach zieht der Transistor mit den Widerständen (4x910 Ohm) den Bus nicht weit genug runter. Ich bin bei den Widerständen bis auf (Gesamtwiderstand) 100 Ohm runtergegangen - kein Erfolg. Siehe Bilder anbei. Die gelbe Kurve ist am Kollektor des BC847B gemessen, die grüne Kurve hinter den Widerständen zu den Dioden hin (zwei Rote Kreise im Bild P0). Man sieht den Empfang eines Bytes und dann den Echoversuch. Bei der Messung P1 waren 3x470 Ohm parallel geschaltet, beim Bild P2 dann noch mehr (Gesamtwiderstand 100 Ohm), bei P3 wieder Original 2x470, aber mit höherem Kondensatorwert (1.5nF SMD + 2,7nf MKS parallelgeschaltet). Der Bus kann doch nicht so viel Strom liefern? Ich habe eine Logamax plus GB 172-14 mit RC300 dran. Weiss jemand Rat? Viele Grüße, Martin
Noch ein Nachtrag. Im Thread Beitrag "Re: Logamatic 2107 Schnittstelle" wird u.a. davon berichtet, daß die RC30 auf dem Bus nur mit 0,5 bis 1V sendet. Dann würde bei mir die Hardware ja funktionieren. Kann das jemand bestätigen, daß nur mit so geringem Spannungshub gesendet wird? Viele Grüße, Martin
Moin Martin, beim Senden ist der Spannungshub nicht entscheidend. Wir haben irgendwann mal den Konsens gefunden, dass das Senden über eine Stromschnittstelle läuft. Dies erklärt auch, warum der Master simultan empfangen und Echos auf den Bus absetzten kann. Er empfängt über Stromschnittstelle und echot über Spannungsschnittstelle. //Niffko
Martin Patzel schrieb: > Ich habe in ethersex den EMS-Code mit Debugging etwas erweitert und > gesehen, daß ca. alle 3 Sek. auf die Adresse 0x0B reagiert wird Da ist schon der Fehler. Am Anfang wird nach mehreren Sekunden jede Busadresse abgefragt. Auch die nicht mit dem EMS-Bus verbunden sind. Sobald ein Polling beantwortet wurde wird diese Busadresse regelmäßig abgefragt. Bei mir ist es gerade fünf mal in der Sekunde (~200ms). Was zeigt denn bei dir die RC30/35/300. Wenn das stimmt dürfte die Adresse 11 (0x0B) dort nicht im Busstatus auftauchen. Entweder stimmt wirklich was nicht mit der Sendefunktion, oder Deine Code-Erweiterung funktioniert nicht bei jedem Polling. Der Sendepegel beim senden ist wirklich so schwach. Das ist ganz normal. Wichtig ist nur dass das die gesendete PollingAntwort vom NetIO auch vom Bus widerholt wird. Jedes gesendete Byte von EMS-Bus-Teilnehmern wird vom Master sofort widerholt. Deine gesendeten Bytes sieht ohne das Echo nur der Busmaster (BC10/MC10?). Wenn Du den Bildausschnitt von deinem DOS etwas weiter nach rechts verschieben könntest solltest Du diese Echo auch sehen. Ein Beispiel für die Sendefunktion ist hier zu sehen: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-telegramme Einfach mal auf das erste Bild klicken und dann nochmals klicken um es in voller Größe zu sehen. Unten ist jeweils die Senderichtung (vor der "Sendestufe") und darüber ist das EMS-Bus-Echo. Auf Deinem DSO solltest Du dann noch deine "schwachen" Sendeversuche auf dem EMS-Bus sehen. Dieses Sendeversuche sind dort nicht zu sehen weil der Logiktester nur High und Low augenommen hat und keine Spannungswerte. Habe auch mal mein kleines collector-Test-Tool in den Softwaredownload vom Wiki gestellt. http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:software_download vielleicht hilft es ja ein wenig... Gruß Ingo
:
Bearbeitet durch User
Angehängte Dateien:
-
P1.jpg
110 KB
Hallo Ingo, anbei nochmal ein kompletteres Bild. Sieht ähnlich aus, wie auf dem von Dir beschriebenen, aber nicht ganz... Zum Coding im Ethersex nochmal: da habe ich nur Debugging dazugebaut. Am Ablauf mit Senden/Empfangen habe ich nichts geändert. Auf dem Bild sieht man, daß der Master das 0x0B sendet, dann (länger als im Beispielbild) den Bus auf High beläßt und anschließend vermutlich ein Break (langes Low) sendet (gleich wie im Beispiel). Dann sendet meine Schaltung das 0x0B. Das wird im Unterschied zum Beispiel nicht sofort vom Master wiederholt, sondern erst nach einer kurzen High-Phase des Busses. Zum Abschluß des Master-Echos sendet dann mein Ethersex nochmals einen kurzen Impuls - ist das überhaupt korrekt?? Dann ist Ruhe auf dem Bus. In meiner RC300 sehe ich als Busteilnehmer nur die RC300 selbst und den Basiscontroller BC25. Jetzt werde ich nochmal ans Debugging in Ethersex ran gehen. Viele Grüße, Martin
Martin Patzel schrieb: > Dann sendet meine Schaltung das 0x0B. Das wird im Unterschied zum > Beispiel nicht sofort vom Master wiederholt, sondern erst nach einer > kurzen High-Phase des Busses. Zum Abschluß des Master-Echos sendet dann > mein Ethersex nochmals einen kurzen Impuls - ist das überhaupt korrekt?? > Dann ist Ruhe auf dem Bus. An der Stelle, an der du den kurzen Impuls siehst, sollte ein Break gesendet werden. Überprüfe mal, ob du den Pin EMS_UART_TX richtig ins Pinning eingetragen hast. Siehe https://github.com/maniac103/ethersex/blob/master/pinning/hardware/netio.m4 Zeile 89 bis 91
Hallo Danny, ja, Pinning stimmt: dnl dnl port config for EMS, pin must match USART1 TX line dnl ifdef(`conf_EMS', ` pin(EMS_UART_TX, PD3) ') ifdef(`conf_STATUSLED_EMS_TX', ` pin(STATUSLED_EMS_TX, PD4, OUTPUT) ') ifdef(`conf_STATUSLED_EMS_RX_OK', ` pin(STATUSLED_EMS_RX_OK, PD5, OUTPUT) ') ifdef(`conf_STATUSLED_EMS_RX_FAIL', ` pin(STATUSLED_EMS_RX_FAIL, PD6, OUTPUT) ') ansonsten würde das Senden ja wohl generell nicht funktionieren? Viele Grüße, Martin
Martin Patzel schrieb: > Hallo Danny, > > ja, Pinning stimmt: > > dnl > dnl port config for EMS, pin must match USART1 TX line > dnl > ifdef(`conf_EMS', ` > pin(EMS_UART_TX, PD3) > ') > ansonsten würde das Senden ja wohl generell nicht funktionieren? Das stimmt so nicht, EMS_UART_TX wird nur und ausschließlich für die Break Condition verwendet. In diesem Umfeld würde ich auf alle Fälle debuggen. Zum Senden des Breaks wird der Transmitter ausgeschaltet, womit der Pin als normaler GPIO arbeitet, und der wurde bei der Initialisierung auf Output + Low gescchaltet Du kannst ja spaßeshalber das ganze mal testen: usart_init() aus kommentieren und sicherstellen, dass ein Pullup an der TX-Leitung anliegt -> Ausgang sollte Dauer-Low sein. Mach das aber nicht am EMS :)
Sendet der NetIO sooo schnell nach dem Break vom Polling? Wäre da nicht etwas mehr Pause schöner? Aber dass scheint den EMS-Bus ja nicht zu stören.. Auf jeden Fall liegt es am Break was da wohl kommen sollte..
Der Tipp mit dem Break war Gold wert!!! Daran lags. Problem ist: Bei mir läuft der AVR mit 20 MHz. Das hat in der Berechnung von BIT_TIME in ems_uart.c zu einem berechneten Wert von 260 geführt - ist natürlich zu viel für 8 Bit. Drum war bei mir der Break dann auch so kurz. Als Quick-und Dirty-Hack habe ich BIT_TIME halbiert und dafür den Break dann 22 Bit breit gemacht. Kommt zeitlich dann auf's Gleiche raus. Und siehe da - meine Heizung redet mit mir. Vielen Dank für die Hilfe! Echt toll, was ihr da auf die Beine gestellt habt! Jetzt kann ich weiter basteln... Viele Grüße, Martin
Hallo, ich habe jetzt Probleme mit Moosys Frontend. Also EMS-Collector habe ich kompiliert und erfolgreich installiert. Telnet auf 7777 klappt. Moosys EMS-Tools habe ich auch erfolgreich installiert. Das CLI-Interface klappt auch mit dem ems-collector. Dann habe ich Moosys webinterface/frontend installiert. PHP läuft (mit test.php getestet) und die Webseite wird auch so weit angezeigt. Habe mal die Bilder der Kurven in den graphs-ordner kopiert. Aber die werden auch nicht angezeigt. Alle Config-Dateien sind auch richtig angepasst. Dummerweise findet auf dem EMS-Bus keine Kommunikation statt. Bei der LiveANsich kommt nur der erste Balken mit 10% und bei den Schaltpunkten nur 90% Hat jemand eine Idee was das Problem sein könnte???
Was sagt denn dein Webserver-Protokoll, im Falle von Apache speziell error.log?
> Bei der LiveANsich kommt nur der erste Balken mit 10% und bei den > Schaltpunkten nur 90% Schau doch mal im Quelltext *.php der Seiten, was nach "progress(10);", bzw. "progress(90);" an Variablen aufgerufen wird.
Danny Baumann schrieb: > Was sagt denn dein Webserver-Protokoll, im Falle von Apache speziell > error.log? Nach meinem Log funktioniert der Zugriff nicht auf die emsincludes. Keine Ahnung warum... Die Dateien sind vorhanden und haben die selben Rechte und user wie auf dem anderen Testserver auf dem es funktioniert...
1 | [Mon May 25 17:52:11.265865 2015] [:error] [pid 5645] [client 192.168.11.22:61985] PHP Warning: require(/emsincludes/emssetvalue.inc): failed to open stream: Permission denied in /var/www/html/a_emslive.php on line 25, referer: http://192.168.11.33/?seite=main.php |
2 | [Mon May 25 17:52:11.265962 2015] [:error] [pid 5645] [client 192.168.11.22:61985] PHP Fatal error: require(): Failed opening required '/emsincludes/emssetvalue.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/a_emslive.php on line 25, referer: http://192.168.11.33/?seite=main.php |
3 | [Mon May 25 17:52:13.135235 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Warning: include(/emsincludes/emsqry.inc): failed to open stream: Permission denied in /var/www/html/a_emssched.php on line 31, referer: http://192.168.11.33/?seite=a_emslive.php |
4 | [Mon May 25 17:52:13.135325 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Warning: include(): Failed opening '/emsincludes/emsqry.inc' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/a_emssched.php on line 31, referer: http://192.168.11.33/?seite=a_emslive.php |
5 | [Mon May 25 17:52:13.135394 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Fatal error: Call to undefined function flush_buffers() in /var/www/html/a_emssched.php on line 64, referer: http://192.168.11.33/?seite=a_emslive.php |
1 | root@ems-server:/emsincludes# ls -la |
2 | insgesamt 80 |
3 | drwx------ 2 user user 4096 Mai 25 17:47 . |
4 | drwx------ 7 user user 4096 Mai 24 22:11 .. |
5 | -rw-r--r-- 1 root root 248 Mai 24 21:18 config.php |
6 | -rw-r--r-- 1 root root 202 Mär 8 14:32 config.py |
7 | -rw-r--r-- 1 root root 323 Mär 8 14:34 config.pyc |
8 | -rw-r--r-- 1 root root 76 Mai 24 21:19 config.sh |
9 | -rw-r--r-- 1 root root 4682 Mär 3 19:44 emschoosers.inc |
10 | -rw-r--r-- 1 root root 4920 Mär 3 19:44 emsgetinfo.inc |
11 | -rw-r--r-- 1 root root 12859 Mär 3 19:44 emsqry.inc |
12 | -rw-r--r-- 1 root root 13281 Mär 3 19:44 emsscdesc.inc |
13 | -rw-r--r-- 1 root root 4023 Mär 3 19:44 emssetvalue.inc |
14 | -rw-r--r-- 1 root root 2469 Mär 3 19:44 emsunits.inc |
15 | root@ThinkPad-T43:/emsincludes# |
Karl M. W. schrieb: > Schau doch mal im Quelltext *.php der Seiten, was nach "progress(10);", > bzw. "progress(90);" an Variablen aufgerufen wird. Scheint wohl an den emsincludes zu liegen. Das ist die erste Anzeige vom Fortschrittsbalken.
ingof schrieb: > -rw-r--r-- 1 root root 12859 Mär 3 19:44 emsqry.inc vorher waren sie auf user:user habe sie dann wie auf dem anderen Server auf root:root geändert. SIcherheitshalber Apache2 neugestartet. Hat sich aber nicht geändert...
Hallo Ingo, wenn ich mich nicht irre ist in Mossys Sourcen eine Datei die nur die PHP Short Tags verwendet <? statt <?php ... Danach hat es bei mir geklappt. Gruß JayKay
Kay F. schrieb: > PHP Short Tags verwendet <? statt <?php ... Das hatte hatte auch gedauert bis ich das herausgefunden hatte.. Habe ich aber schon geändert... Keine Ahnung warum er nicht auf die emsincludes zugreifen kann... Die Dateien werden angezeigt und lassen sich auch mit "vi /emsincludes/emsqry.inc" öffnen.
Danny Baumann schrieb: > SELinux aktiv? Nein, jabe ich auch bisher noch nie was von gehört... Habe Ubuntu 14.04.2 LTS Ist bei beiden auf einem Laptop installiert. Auf Laptop wo es im Moment läuft ist es ein 64-Bit und auf dem jetztigen ein 32-Bit. ABer das sollte ja nichts ändern... Ja, ist nicht ausführbar. Ist aber auf dem anderen Server auch nicht so. Un da funktioniert es..
ingof schrieb: > Ist aber auf dem anderen Server auch nicht so. sollte heissen dass es auf beiden nicht ausführbar ist (x). Aber ist ja nur eine include-Datei. Die ja nicht ausgeführt werden muss, oder?
Das Verzeichnis /emsincludes (nicht die Dateien darin) muss ausführbar sein, da es ansonsten nicht durchsuchbar ist.
Danny Baumann schrieb: > Das Verzeichnis /emsincludes (nicht die Dateien darin) muss ausführbar > sein, da es ansonsten nicht durchsuchbar ist. Stimmt, da war noch ein Unterschied. Beim neuen Server hatte das Verzeichnis "includes" die Rechte 700. Habe dann includes und das "ems-tools" Verzeichnis drüber gleich auch auf "755" gesetzt. Habe auch Besitzer auf "root:root" geändert. Nach Apache2 neustart hat sich aber auch nichts geändert... Also mal eine zusammenfassung:
1 | ls -la /: |
2 | lrwxrwxrwx 1 root root 33 Mai 25 17:51 emsincludes -> /home/user/ems/ems-tools/includes |
3 | |
4 | ls -la /home/user/ems/: |
5 | drwxr-xr-x 7 root root 4096 Mai 24 22:11 ems-tools |
6 | |
7 | ls -la /home/user/ems/ems-tools/: |
8 | drwxr-xr-x 2 root root 4096 Mai 25 17:47 includes |
9 | |
10 | ls -la /home/user/ems/ems-tools/includes/: |
11 | insgesamt 80 |
12 | drwxr-xr-x 2 root root 4096 Mai 25 17:47 . |
13 | drwx------ 7 user user 4096 Mai 24 22:11 .. |
14 | -rw-r--r-- 1 root root 248 Mai 24 21:18 config.php |
15 | -rw-r--r-- 1 root root 202 Mär 8 14:32 config.py |
16 | -rw-r--r-- 1 root root 323 Mär 8 14:34 config.pyc |
17 | -rw-r--r-- 1 root root 76 Mai 24 21:19 config.sh |
18 | -rw-r--r-- 1 root root 4682 Mär 3 19:44 emschoosers.inc |
19 | -rw-r--r-- 1 root root 4920 Mär 3 19:44 emsgetinfo.inc |
20 | -rw-r--r-- 1 root root 12859 Mär 3 19:44 emsqry.inc |
21 | -rw-r--r-- 1 root root 13281 Mär 3 19:44 emsscdesc.inc |
22 | -rw-r--r-- 1 root root 4023 Mär 3 19:44 emssetvalue.inc |
23 | -rw-r--r-- 1 root root 2469 Mär 3 19:44 emsunits.inc |
Das einzige was sich sonst noch geändert hat ist jetzt das Verzeichnis. Vorher in "/home" jetzt in "/home/user/ems/" auf dem neuen Server...
:
Bearbeitet durch User
OK... Habe den Fehler gefunden. /home/user/ems/ems-tools/ war noch auf "700" und "user:user". Hatte das beim letzten Beitrag als letztes geändert. Hatte aber vergessen den Apache2 neu zu starten. Nach einem Neustart von Apache kam "FATAL! keine Verbindung". Dann den ems-collector neugestartet und jetzt scheint es zu laufen. Aber warum der Ordner darüber auch diese Rechte haben muss ist mir nicht ganz klar. der Ordner "user" über den "ems-tools" besitzt immer noch die Rechte "700" und "user:user" bei den Graphs Ordner gab es das selbe Problem. Das x ist also bei Verzeichnissen nicht "ausführbar" sondern "durchsuchen erlaubt". Aber nur wenn das r auch gesetzt ist... DANKE an alle
:
Bearbeitet durch User
Dear Ingo, I had same type of problem after an update of my Avira antivirus SW. When I switch off the antivirus everthing runs fine. What I understand isthat it has to do with the ob_flush command, when I comment this out in emsqry.inc the a_emslive.php runs fine, even with Avira running, however this doesn't help for settings. Success Maarten
Hello Marten, I do not know Avira. try to find the logfile and check for errors with the IP, Port or the collector. I do not know whats the problem. If there is an integrated firewall. Then try to set your Port an IP-address on a white list. If not try to set the collector / webserver on a whitelist, if possible.
Hallo zusammen, hat jemand eventuell noch eine unbestückte Platine über und würde diese verkaufen? Gruß und Danke Marco
Hallo, habe auch Interesse an einer Platine, damit der Lötigel (hat überhaupt keinen WAF) endlich verschwindet. Gruß Knut
Hallo, kann ich den Collector auch auf meinem Synology laufen lassen? Ich habe darüber im Wiki gelesen, aber es soll noch nicht laufen? Ich würde ungern einen Raspberry installieren...
Meine ersten gehversuche haben noch nicht so ganz geklappt. Auf der Synology kompilieren geht wegen dem zu alten GCC. Es muss wohl auf einem Linux-PC kompiliert werden. Hatte dann auch die Versuche erst mal auf Eis gelegt. Aber vielleicht können wir ja mal einen Versuch zusammen wagen das dort zum laufen zu bekommen. Auf welcher Diskstation möchtest Du es denn zum laufen bekommen? Gruß IngoF
Hallo! Ich nutze die Lösung nun schon lange auf meinem Pi und in bin immer noch allen, die sowas möglich machen, sehr dankbar! Zur optimalen Einstellung habe ich Fragen: Welche Werte sollte man Eurer Meinung für die Parameter auf den Bildern verwenden, um einen guten Kompromiss zwischen Komfort und Energiesparen zu erreichen? Gruß Bernd
IngoF schrieb: > Auf welcher Diskstation möchtest Du es denn zum laufen bekommen? Hallo Ingo, ich würde es dann auf einer synology ds215j laufen lassen wollen. Ich muss mir aber zunächst einen Adapter bauen. Bevor ich das in Angriff nehme wollte ich wissen ob ich unbedingt einen Raspberry benötige, oder es auch anders geht. Alternativ hätte ich noch die Möglichkeit über einen 24/7 Windows PC die Daten abzufragen. Wie ich gelesen habe, geht dies über Telnet? Gruß Dennis
Sagen wir es mal so. Es sollte machbar sein den CollectorD für die Diskstation zu kompilieren... Im Moment habe ich ein altes Notebook und den CollectorD dafür kompiliert. Aber das ist nur eine Notlösung und soll hinterher auf meiner 415+ laufen. Notfalls ist ein RasbPi auch schnell gekauft. Die gibt es ja an jeder Ecke ;-)
Ich habe es auf einer GoFlex Net laufen. Benoetigt eine 2,5" SATA Platte und ein wenig Lust am Basteln (SW) und Einlesen (z.B. http://doncharisma.org/2013/09/22/build-your-own-pro-nas-seagate-goflex-net-with-debian-linux-raid1-and-openmediavault/ ). Dafuer bekommt man fuer aktuell unter 20 Euro (z.b. in der elektronischen Bucht) ein super NAS mit komplett freiem Linux (zum "Spielen" und Verwenden) - und eben eine super Plattform fuer den CollectorD ;-)!
Hallo, ich habe mir die Hardware auf Basis des AVR-Net-IO mit der Adapterelektronik für den EMS selbst zusammengebaut und die ethersex Software aufgespielt. Die Elektronik funktioniert auch mit dem Testtool für Collector wenn ich eine Crossover-Netwerk-Verbindung zum PC habe. Wenn ich die Elektronik aber mit einem Patchkabel an meinen Router stecke habe ich keine Verbindung. Nicht einmal einen Ping. Wo könnte denn da der Fehler liegen? Gruß Dennis
Hallo Dennis, hast du die Gateway IP in Net-IO vergeben? Das Net-IO mit dem ethersex antwortet nicht auf Ping-Anfragen. Grüße Martin
Hallo, ich habe es heute geschafft eine Verbindung herzustellen. Mit dem Testtool kommen Telegramme an... :-) Ich habe nun mal einen TCP-Client aufgemacht um zu sehen was ich direkt empfangen kann. Ich kann das ganze aber noch nicht interpretieren. Gibt es dazu irgendwo eine Beschreibung? Gruß Dennis
Chris schrieb: > Hallo, > ich habe es heute geschafft eine Verbindung herzustellen. > Mit dem Testtool kommen Telegramme an... :-) Von welchem Testtool sprichst due? > Ich habe nun mal einen TCP-Client aufgemacht um zu sehen was ich direkt > empfangen kann. > Ich kann das ganze aber noch nicht interpretieren. Gibt es dazu irgendwo > eine Beschreibung? Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?
Danny B. schrieb: > Von welchem Testtool sprichst due? Testtool Collector (Testtool für die Collector-Schnitstelle vom NetIO) Danny B. schrieb: > Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector? Zum AVR-Net-IO auf dem Port 7950. Es kommen Pakete an, diese sind aber deutlich länger als ich sie beim Testtool Collector sehe. Aufgefallen ist mir das die Datenbytes immer durch eine 0 getrennt gesendet werden. Aber wie kann ich die Pakete den Telegrammen zuordnen? (wie im Testtool auf der Rechten Seite) Werden da noch Befehle an den Net-IO gesendet damit er die Telegramme des EMS an den Verbundenen Telnet-Teilnehmer weitergibt? Gruß
Dennis schrieb: > Danny B. schrieb: >> Von welchem Testtool sprichst due? > > Testtool Collector (Testtool für die Collector-Schnitstelle vom NetIO) Davon habe ich ehrlich gesagt noch nie gehört. Wo findet man das? > Danny B. schrieb: >> Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector? > > Zum AVR-Net-IO auf dem Port 7950. > Es kommen Pakete an, diese sind aber deutlich länger als ich sie beim > Testtool Collector sehe. > Aufgefallen ist mir das die Datenbytes immer durch eine 0 getrennt > gesendet werden. > Aber wie kann ich die Pakete den Telegrammen zuordnen? (wie im Testtool > auf der Rechten Seite) > Werden da noch Befehle an den Net-IO gesendet damit er die Telegramme > des EMS an den Verbundenen Telnet-Teilnehmer weitergibt? Nein. Der Ethersex-Code blubbert auf Port 7950 immer genau das heraus, was hier beschrieben ist: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio ... 0xaa 0x55 ist dabei der Trenner zwischen den einzelnen Telegrammen.
Danny B. schrieb: > Davon habe ich ehrlich gesagt noch nie gehört. Wo findet man das? Den findet man auch im EMS-Wiki. http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:software_download Danny B. schrieb: > Nein. Der Ethersex-Code blubbert auf Port 7950 immer genau das heraus, > was hier beschrieben ist: > http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio > ... 0xaa 0x55 ist dabei der Trenner zwischen den einzelnen Telegrammen. Die Beschreibung hatte ich übersehen, sorry. Dann werde ich es damit mal probieren... :-)
Dennis schrieb: > Die Beschreibung hatte ich übersehen, sorry. > Dann werde ich es damit mal probieren... :-) Hallo, ich kann inzwischen die Telegramme auslesen und interpretieren. Was mir nun noch fehlt ist das geziehlte Abfragen bzw. Senden von Parametern. Es scheitert glaube ich an der CRC. Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich folgendes 0B 10 3F 91 01 01 <CRC> Wie bildet man denn die CRC? Bei einer Byteweisen XOR würde als CRC B5 herauskommen, dies scheint aber nicht zu funktionieren... :-( Gruß Dennis
Dennis schrieb: > ich kann inzwischen die Telegramme auslesen und interpretieren. > Was mir nun noch fehlt ist das geziehlte Abfragen bzw. Senden von > Parametern. > > Es scheitert glaube ich an der CRC. > Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich > folgendes > > 0B 10 3F 91 01 01 <CRC> > > Wie bildet man denn die CRC? > Bei einer Byteweisen XOR würde als CRC B5 herauskommen, dies scheint > aber nicht zu funktionieren... :-( Benutzt du nicht Ethersex? Wenn ja, brauchst du da doch keine CRC beim Senden? (Gibt es einen speziellen Grund, warum dunnicht den Collector verwenden willst? Der abstrahiert diese Dinge alle komplett weg...)
Danny B. schrieb: > Benutzt du nicht Ethersex? Wenn ja, brauchst du da doch keine CRC beim > Senden? Doch, ich habe die Ethersex Firmware aus dem ems-wiki. Aber ich bekomme keinen Response auf meine Anfragen... (Auch ohne CRC, wie oben beschrieben) Mache ich da noch was falsch?? :-( Danny B. schrieb: > (Gibt es einen speziellen Grund, warum dunnicht den Collector verwenden > willst? Der abstrahiert diese Dinge alle komplett weg...) Ich habe einen 24/7 PC zur Hausautomation und möchte mir nicht noch einen RaspberryPi installieren um den EMS abzufragen bzw. zu steuern...
ingof schrieb: > Den Collector habe ich zur Zeit nauch auf einem PC laufe Ich hatte das so verstanden das der nur auf einem Linux System läuft? Wie installieren ich den auf einem Windows PC?
Dennis schrieb: > Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich > folgendes > > 0B 10 3F 91 01 01 <CRC> ich gehe davon aus, dass du den offset (91) aus der wiki hast. 1. du must ihn in hex senden 2. der angegebene offset ist nicht nativ ems, es wird hier der header mitgezählt. ich weiß jetzt aber nicht, inwieweit ethersex das ausbügelt. um die partyfunktion für 6h zu aktivieren, muss der rc folgendes über den bus empfangen: 0B 10 3F 56 06 <CRC> (getestet) // niffko
Niffko _. schrieb: > 1. du must ihn in hex senden Du hast Recht, die 91 ist ja dezimal...! Das teste ich morgen früh gleich mal! Danke für den Anstoß... ;-)
Dennis schrieb: > Ich hatte das so verstanden das der nur auf einem Linux System läuft? Ist auch wohl so.. Habe wohl mal wieder zu schnell geschrieben und erst dann nachgedacht ;-)
Dennis schrieb: > Ich hatte das so verstanden das der nur auf einem Linux System läuft? > Wie installieren ich den auf einem Windows PC? Prinzipiell sollte der Collector auch auf Windows laufen: Er hat als Abhängigkeiten nur Boost (gibt's auch für Windows) und mysql++ (kann man gegebenenfalls rauscompilieren). Ich schau mal, was ich da machen kann, wenn ich mal Zeit finde. Niffko _. schrieb: > 2. der angegebene offset ist nicht nativ ems, es wird hier der header > mitgezählt. ich weiß jetzt aber nicht, inwieweit ethersex das ausbügelt. > um die partyfunktion für 6h zu aktivieren, muss der rc folgendes über > den bus empfangen: 0B 10 3F 56 06 <CRC> (getestet) Ausgebügelt wird da nix. Ethersex fügt die Absenderadresse und die CRC hinzu, der Rest landet 1:1 auf dem Bus.
Angehängte Dateien:
-
EMS-Gateway.png
48 KB
Hallo, ich habe nun die für mich wichtigsten Werte und Steuerungsfunktionen zusammengesammelt. Damit ihr auch seht warum ich soviel gefragt habe, hier ein Screenshot von meinem Testtool... Werde die Daten nun in die Visualisierung der Hausautomation implementieren. Vielen Dank noch einmal an alle! :-) Gruß Dennis
Ich habe den Collector mal auf Windows compilierfähig gemacht. Mysql kann er in diesem Fall nicht, und er läuft nur im Vordergrund; für das Ausführen als Service braucht man also noch ein Extra-Tool. Wenn es jemand probieren möchte: https://www.dropbox.com/s/xmdpncj8xmkmnyw/collectord.exe?dl=0 (etwa 6.3 MB groß, weil ich alles statisch linke, damit man nicht noch ein DLL-Package braucht)
:
Bearbeitet durch User
Hallo, ich habe mir die AVR-NET IO Platine mit dem Adapter zusammengebaut und an meiner GB142 getestet. Sie funktioniert! Ich kann empfangen und senden... :-) Nun habe ich diese Platine an eine GB132T an den RC-Anschluss angeschlossen und kann auch Telegramme empfangen. Das senden geht aber nicht! In den Monitorwerten (Busteilnehmer) wird mir auch nicht, wie bei der GB142, der Service-Key (Adresse 11) angezeigt. Muss man das noch irgendwie aktivieren??? Gruß Dennis
Dennis schrieb: > Hallo, > ich habe mir die AVR-NET IO Platine mit dem Adapter zusammengebaut und > an meiner GB142 getestet. Sie funktioniert! Ich kann empfangen und > senden... :-) > > Nun habe ich diese Platine an eine GB132T an den RC-Anschluss > angeschlossen und kann auch Telegramme empfangen. Das senden geht aber > nicht! > In den Monitorwerten (Busteilnehmer) wird mir auch nicht, wie bei der > GB142, der Service-Key (Adresse 11) angezeigt. > Muss man das noch irgendwie aktivieren??? > > Gruß > Dennis Das sollte genau wie an der GB142 gehen. Wenn die Platine angeschlossen wird sollte die MC10 das mitbekommen und die Adresse häufiger Pollen. Dann wird auch die Platine erkannt und im RC angezeigt. Wenn die Dort nicht im Raumcontroller steht kann man auch nicht senden. Beide haben ja den EMS-Bus. Oder ist an der GB132T eine RC300 oder RC350 angeschlossen? Dann wäre das der EMS+-Bus
IngoF schrieb: > Beide haben ja den EMS-Bus. Oder ist an der GB132T eine RC300 oder RC350 > angeschlossen? Dann wäre das der EMS+-Bus GB132T hat EMS (und funktioniert bei mir einwandfrei)
:
Bearbeitet durch User
Danny B. schrieb: > GB132T hat EMS (und funktioniert bei mir einwandfrei) Ich hatte eine ca. 10m 3x0,75 Leitung angeschlossen. (Vielleicht war es auch nur 0,5mm2) Könnte die Verbindung vielleicht nicht gut gewesen sein und ich deshalb nur Signale empfangen, aber nichts senden? Gruß
Dennis schrieb: > nur Signale empfangen, aber nichts senden? Wäre möglich... Unterscheidet sich denn die EMS-Verkabelung bei den beiden Heizungen stark? Wo ist denn die Platine angeschlossen? Direkt an der Heizung oder am Ende beim Raumcontroller? Ist dort ein längeres oder anderes Kabel zur RC30/35. Eventuell dann mal direkt an der Heizung anschließen. Eventuell mal an der Diagnosebuchse (Stereo Klinkenbuchse) versuchen. Die +12V dann nicht anschließen. Ich habe gerade die STeckerbelegung ins Wiki gepackt: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-bus Dann müsste die Verkabelung außen vor sein?!
Dennis schrieb: > Ich hatte eine ca. 10m 3x0,75 Leitung angeschlossen. da das senden - anders als das empfangen - über eine stromschnittstelle realisiert ist, könnte der leitungswiderstand mglw. relevant sein ... //niffko
Niffko _. schrieb: > könnte der leitungswiderstand mglw. relevant sein ... Meine RC ist über 20 Meter 0,5mm Kabel angeschlossen und funktioniert problemlos. Ist aber durchaus möglich dass es daran liegt. Verdrillt wird das Kabel ja wohl gewesesen sein..
Niffko _. schrieb: > leitungswiderstand Hallo Ihr EMS'ler, meine beiden Leitungen, y-förmig von der Heizung abgehend, das 1. NYFAZ, 2*0.75, ca. 12 m, zur RC35 2. NYLHY, 3*0.5, zwei belegt, ca. 15 m, zum NetIO also beide nicht verdrillt. Alles funktioniert problemlos, dank Eurer genialen Arbeit! Ich freue mich jeden Tag drüber! Gruß aus der Wetterau Karl M.
ingoF schrieb: > Verdrillt > wird das Kabel ja wohl gewesesen sein.. Hallo, verdrillt war das Kabel nicht. An der GB142 verwende ich ein LiYCY 2 × 2 × 0,75 wovon ein Aderpaar für den EMS-Bus genutzt wird. Ich werde es zunächst über ein kurzes Kabel über den Klinkenstecker testen und dann im 2. Step noch einmal ein anderes Kabel an der RC-Anschluß anschließen. Das wird aber erst morgen etwas. Ich werde berichten. Erst einmal danke für die Hilfe! Gruß
Dennis schrieb: > 2. Step noch einmal ein anderes Kabel an der Also Laut Handbuchern steht dort nichts von verdrillten Adern.
1 | • 100 m mit 0,50 mm2 Leiterquerschnitt |
2 | • 300 m mit 1,50 mm2 Leiterquerschnitt. |
Hatte nur mal bei einem 2-Meter Seriell-Kabel Probleme weil die Adern nicht oder falsch verdrillt waren. Allerdings war das auch eine höhere Bitrate und ein schwächerer Pegel.
Hallo, ich habe heute nun noch einmal versucht eine Verbindung zu der GB132T herzustellen. Leider hatte ich noch keinen Klinkenstecker, weshalb ich dann noch einmal ein anderes Kabel angeklemmt habe. Ohne Erfolg! Selbst mit nur 10cm Kabeln zwischen dem Net-IO und dem orangenen RC-Stecker kann ich zwar Telegramme empfangen, aber der Servicekey erscheint nicht bei den Busteilnehmern. Bei meiner GB142 habe ich die Platine noch einmal getestet, dort geht alles wie gewünscht. Woran kann das denn liegen? Kennt die GB132T vielleicht noch gar keinen Servicekey weil sie eine andere/ältere Firmware hat? Ich bin gerade ratlos wie ich dem EMS denn nun beibringen kann das nun ein "Servicekey" vorhanden ist. Hat von euch vielleicht noch jemand eine Idee??? :-( Gruß
Benutzt du being beiden Brennern die selbe RC3x? Was sind denn deine Firmwareversionen?
Danny B. schrieb: > Benutzt du being beiden Brennern die selbe RC3x? Was sind denn deine > Firmwareversionen? Nein, es ist jeweils eine RC35 vorhanden. Bei der GB132T wurde die RC30 mal gegen eine RC35 getauscht. Die Versionen sind wie folgt: GB132T: RC35 1.06 UBA3 3.02 BCM Version 12 BCM Nummer 1006 BC10 2.01 GB142: RC35 1.06 UBA3 3.05 BCM Version 14 BCM Nummer 1002 BC10 2.03 Die GB132 ist ein oder 2 Jahre älter als die GB142...
An den Versionen liegt es dann schon mal nicht. Ich habe UBA 2.05, BCM 9 und BC10 2.00. Meine RC35 ist neuer (1.16), aber da 1.06 bei dir an der GB142 geht, ist es das wohl auch eher nicht. Die EMS-Adapter-Platine ist in beiden Fällen die selbe, richtig? Ansonsten fällt mir auch nicht viel ein :(
Danny B. schrieb: > Die EMS-Adapter-Platine ist in beiden Fällen die selbe, richtig? Ja, das ist die selbe... Dann kann ich nur hoffen das es am Klinkenstecker geht. Da muss ich mir aber noch einen Stecker besorgen. Hast Du die EMS-Adapter-Platine auch an dem orangenen Stecker am Klemmbrett auf der linken Seite angeschlossen?
Kann ich grad nicht nach schauen; auf alle Fälle hängt die Platine bei mir an der Leitung, an der auch die RC35 hängt (letztere hängt im Wohnzimmer, nicht an der Heizung).
Danny B. schrieb: > (letztere hängt im > Wohnzimmer, nicht an der Heizung) Die RC35 hängt bei mir in beiden Fällen an der Heizung. Der RC Anschluss wird aber ja bestimmt einfach nur parallel zum Bus liegen...
Hallo, Die EMS-Wiki URL hat sich geändert: http://wiki.thefischer.net Die alte URL wird noch einge Zeit auch noch funktionieren Falls noch die alte URL in der Adressleiste erscheint liegt das am Cache vom Browser. Gruß IngoF
Ich habe jetzt nach einigen Problemen mein System mit dem Board von Jürgen und einem NetIO zum Laufen gebracht. Ich habe eine GB152 mit RC30. Es gibt 2 Heizkreise, HK1 ist ungemischt, HK2 gemischt. Der Raumtemperaturfühler am RC30 wird HK2 zugeordnet. Dieser wird an der RC30 auch richtig angezeigt aber nicht im Frontend. Hier kommt das berühmte 3200, wobei das auch nicht konstant ist. Bei mir fehlt der Telegramtyp 0xA3 (bzw. ist nur ganz kurz). Ich habe jetzt festgestellt, dass 2 Telegramme mit der Raumtemperatur gelesen werden, einmal für HK1 (mit 0x7d = 3200) und für HK2 ( der richtige Wert. IO: Got bytes 0xaa 0x55 0x13 0x10 00 0x3e 00 0x4 00 00 0x7d 00 00 00 0x5 0x5 0xd 00 00 00 00 0x5 0x5f MESSAGE[24.10.2015 23:47:06]: source 0x10, dest 0x00, type 0x3e, offset 0, data: 0x04 0x00 0x00 0x7d 0x00 0x00 0x00 0x05 0x05 0x0d 0x00 0x00 0x00 0x00 0x05 DATA: Raum-Solltemperatur = 0 °C DATA: Raum-Isttemperatur = 3200 °C DATA: HK1-Kennlinie = -10 °C: 5 °C / 0 °C: 5 °C / 10 °C: 13 °C DATA: HK1-Solltemperatur = 5 °C IO: Got bytes 0xaa 0x55 0x13 0x10 00 0x48 00 0x4 00 00 00 0xd7 00 00 0x5 0x5 0x9 00 00 00 00 0x5 0x87 MESSAGE[24.10.2015 23:46:06]: source 0x10, dest 0x00, type 0x48, offset 0, data: 0x04 0x00 0x00 0x00 0xd7 0x00 0x00 0x05 0x05 0x09 0x00 0x00 0x00 0x00 0x05 DATA: Raum-Solltemperatur = 0 °C DATA: Raum-Isttemperatur = 21.5 °C DATA: HK2-Kennlinie = -10 °C: 5 °C / 0 °C: 5 °C / 10 °C: 9 °C DATA: HK2-Solltemperatur = 5 °C Es müsste also der Wert 0x7d für die Raumtemperatur ignoriert werden. An einem RCxx kann nur ein Raumfühler hängen. Ist eigentlich geplant, das Web-Frontend mal auf 2 Heizkreise zu erweitern, oder wie könnte ich statt dem HK1 den HK2 verwenden ? Andreas Z Meine Versionen sind wie folgt : UBA 3.05 BC10 2.02 RC30 2.08
:
Bearbeitet durch User
In meinem Repo wird 0x7d00 schon länger ignoriert. Siehe hier: https://github.com/maniac103/ems-collector/blob/master/collector/EmsMessage.cpp#L586 - d.h. du musst nur mal deinen Collector updaten :) Aus Telegramm 0xa3 wird nur die gedämpfte Außentemperatur entnommen, es ist also OK, wenn dieses Telegramm nur kurz ist. An einer Unterstützung für HK2 im Frontend wäre ich auch interessiert, habe aber leider keine Zeit, das selber zu machen.
:
Bearbeitet durch User
@ Danny Vielen Dank für die Hilfe. Ich habe den Collector von Moosy verwendet, da ist das nicht drin. Ich habe heute Nacht noch eine andere Lösung gefunden. Beim Subtype HK1 parse ich die Raumtemperatur einfach nicht. Was ist denn der Unterschied / Vorteil der beiden verschiedenen "Collectoren" ? Für jemand der hier neu einsteigt ist es ein bisschen schwierig einigermaßen durchzublicken. Trotzdem ist eine tolle Leistung was ihr da auf die Beine gestellt habt. Ich konnte gestern bei mir schon die Brenneraufzeit verlängern indem ich die Hysterese erhöht habe. Jetzt will ich das Ganze noch für die WW-Bereitung machen, da hier kurz vor erreichen des Sollwertes ganz schönt getaktet wird. Andreas
:
Bearbeitet durch User
Andreas Z. schrieb: > Vielen Dank für die Hilfe. Ich habe den Collector von Moosy verwendet, Ah, da ist der Fehler ;) > Was ist denn der Unterschied / Vorteil der beiden verschiedenen > "Collectoren" ? Vorteil bei meinem Repo ist, dass es aktuell ist :) Im Ernst: Es gibt inzwischen überhaupt keine Grund mehr, Moosys Repo zu verwenden. Zwischenzeitlich (aber schon einige Zeit her) hatte er darin neue Features entwickelt, aber die habe ich inzwischen alle übernommen. Bugfixes wiederum landen nur in meinem Repo, da Moosy ja inzwischen 'verschwunden' ist. > Für jemand der hier neu einsteigt ist es ein bisschen schwierig > einigermaßen durchzublicken. Karl hat mal ein nettes How-To für das 'Standard-Setup' mit dem Net-IO gemacht: http://wiki.thefischer.net/doku.php?id=wiki:ems:net_io Wenn du anderweitige Ideen zu einer einsteigerfreundlichen Präsentation hast, nur raus damit ;)
Danny B. schrieb: > Karl hat mal ein nettes How-To für das 'Standard-Setup' mit dem Net-IO > gemacht: http://wiki.thefischer.net/doku.php?id=wiki:ems:net_io > Wenn du anderweitige Ideen zu einer einsteigerfreundlichen Präsentation > hast, nur raus damit ;) Hast ja schon den neuen Link genommen. Leider muss ich gestehen dass dieser Link sehr oft nicht funktioniert. Habe noch mehr Probleme damit beide Webserver auf eine Domain laufen zu lassen. Also bis auf weiteres erst mal der alte Link in diesem Fall also http://ems-gateway.myds.me/doku.php?id=wiki:ems:net_io Allerdings wird diese alte URL auch erst heute abend wieder richtig funktionieren... Fall die neue URL funktioniert kann es sein dass man noch auf einer etwas älteren Sicherheitskopie landet. Gruß Ingo
:
Bearbeitet durch User
So die EMS-Wiki ist jetzt über die neue Adresse erreichbar: http://emswiki.thefischer.net Das Problem war in meinem Firefox-Pofil. Es lief also von Anfang an Fehlerfrei...
:
Bearbeitet durch User
Hallo Danny, es läuft jetzt alles. Vielen Dank für deine Hilfe. Kompilieren auf dem Raspberry Pi ist wirklich ein Geduldsspiel. Ich habe einen ganz alten mit nur 256MB Ram. Der ist wirklich an der Grenze. Andreas
Andreas Zöller schrieb: > es läuft jetzt alles ... schön! Und der Hintergrund? Dannys Repo, oder was? > Der ist wirklich an der Grenze. Beim kompilieren "ja". Ansonsten kann ich das nicht bestätigen. Hab' auch so einen, der macht noch ein paar andere Dinge (lighty, owfs, mysql, etc.) nebenbei. :-) Gruß aus der Wetterau
Danny B. schrieb: > Kann ich grad nicht nach schauen; auf alle Fälle hängt die Platine bei > mir an der Leitung, an der auch die RC35 hängt (letztere hängt im > Wohnzimmer, nicht an der Heizung). Hallo, ich habe heute den von Danny beschriebenen Zustand hergestellt. RaumController über ein Kabel an Klemme RC verbunden. Dazu parallel die AVR NET-IO Platine. Ergebnis: RaumController funktioniert NET-IO kann nur empfangen, nicht senden! Monitorwerte "Busteilnehmer" wird kein ServiceKey angezeigt Wenn nun niemand mehr eine Idee hat werde ich an dieser Stelle wohl aufgeben müssen! :-( Gruß Dennis
Dennis schrieb: > Wenn nun niemand mehr eine Idee hat werde ich an dieser Stelle wohl > aufgeben müssen! :-( Was hast Du denn für Messmöglichkeiten? Digitales Seicher Oszilloskop (DSO) oder ähnliches ist vermutlich nicht vorhanden, oder? Schon mit dem Klinkenstecker probiert? Schon seltsam dass es an der einen Heizung funktioniert und an der anderen nicht. Was hast Du denn für Busteilnehmer am Bus an der Heizung die nicht funktioniert? Gibt es da vielleicht schon ähnliche Hardware? Sind auch alle vier parallel geschalteten Wiederstände im Sendeteil richtig angelötet. Könnte ja sein dass einer keinen richtigen Kontakt hat und die andere Anlage nur wegen anderen Toleranzen funktioniert. Hat die NetiO-Adapterplatine auch vier Widerstände? Danny, hattest Du nicht auch die Software für den NetIO programmiert? Gibt es da noch weitere Debugging-Optionen? Könnte man eventuell was "basteln"? Das erinnert mich an meine (Marken)-HiFi-Anlage. Bei mir war die extrem stark am Rauschen. Beim Händler, Nachbarn und Freunden lief die einwandfrei. Störende Verbraucher waren auch nirgend zu sehen. Habe nie herausbekommen woran es lag. Musste das nächst größere Modell kaufen. Schätze mal die Stromversorgung/Das Netzteil für den NetIO ist das selbe wie bei an der anderen Anlage, oder? Vielleicht zum Spass mal mit Batterien ausprobieren? Irgendwelche Seventuell störenden Geräte sind nicht in Nähe?
:
Bearbeitet durch User
Ingo F. schrieb: > Was hast Du denn für Messmöglichkeiten? > Digitales Seicher Oszilloskop (DSO) oder ähnliches ist vermutlich nicht > vorhanden, oder? Leider nur ein ganz einfaches analoges... Ingo F. schrieb: > Schon mit dem Klinkenstecker probiert? Nein, aber da habe ich dann ja auch fast keine Hoffnung mehr... Ingo F. schrieb: > Was hast Du denn für Busteilnehmer am Bus an der Heizung die nicht > funktioniert? Gibt es da vielleicht schon ähnliche Hardware? Es sind in beiden Fällen immer eine UBA ein BC10 und ein RC35 vorhanden. Ingo F. schrieb: > Sind auch alle vier parallel geschalteten Wiederstände im Sendeteil > richtig angelötet. Könnte ja sein dass einer keinen richtigen Kontakt > hat und die andere Anlage nur wegen anderen Toleranzen funktioniert. Hat > die NetiO-Adapterplatine auch vier Widerstände? Ich habe inzwischen auch 2 Adapterplatinen, bei beiden zeigt sich dieses Verhalten. Als Transistor wurde ein BC107 verbaut. Ingo F. schrieb: > Schätze mal die Stromversorgung/Das Netzteil für den NetIO ist das selbe > wie bei an der anderen Anlage, oder? > Vielleicht zum Spass mal mit Batterien ausprobieren? > Irgendwelche Seventuell störenden Geräte sind nicht in Nähe? Bei der funktionierenden Anlage habe ich es zunächst mit dem USB Anschluss vom Laptop getestet und nutze nun den USB Anschluss der Fritzbox als 5V Spannungsversorgung. Bei der nicht funktionierenden habe ich es nun nur mit dem Laptop getestet. Ohne EMS-Bus nimmt die Platine ca. 150mA auf... Danke das Du Dir die Mühe machst und mir Hilfestellung gibst. :-)
Dennis schrieb: > eider nur ein ganz einfaches analoges... Na das hilft doch schon mal. Am besten auf das Eingangssignal des Sendetransistors triggern und sehen was passiert. Evtl mit Trenntrafo messen?! In diesem Beitrag im zweiten Bild sieht man oben das Sendesignal. Der Busmaster wiederholt dann die Telegramme. Beitrag "Re: Logamatic 2107 Schnittstelle" zum generellen Telegrammaufbau: http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme Dennis schrieb: > Nein, aber da habe ich dann ja auch fast keine Hoffnung mehr... Da hilft nur ein Test um das herauszufinden. Dennis schrieb: > Bei der funktionierenden Anlage habe ich es zunächst mit dem USB > Anschluss vom Laptop getestet und nutze nun den USB Anschluss der > Fritzbox als 5V Spannungsversorgung. > Bei der nicht funktionierenden habe ich es nun nur mit dem Laptop > getestet. > Ohne EMS-Bus nimmt die Platine ca. 150mA auf... Na dann sollte das wohl nicht das Problem sein..
Ingo F. schrieb: > Danny, hattest Du nicht auch die Software für den NetIO programmiert? > Gibt es da noch weitere Debugging-Optionen? Könnte man eventuell was > "basteln"? Nicht wirklich :( Der NetIO-Code schiebt die auf dem Socket empfangenen Daten einfach in die serielle Schnittstelle rein, wenn er gepollt wird, da ist keine riesige Logik dahinter. Insofern ist dein Vorschlag, an der Basis des Sendetransistors zu messen, schon der richtige. Das einzige relevante, was man an Debugging anschalten könnte, wäre die EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem ECMD-Port absetzen; die zweite Zahl hinter 'Packets 1byte' ist dann die Anzahl, wie oft der Master Adresse 0xb gepollt hat. Wenn das auf 0 bleibt, stimmt etwas an der Heizungs-Konfiguration nicht (kann ich mir ehrlich gesagt aber nicht vorstellen).
Danny B. schrieb: > Das einzige relevante, was man an Debugging anschalten könnte, wäre die > EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem > ECMD-Port absetzen Die Option muss ich dann im Ethersex auf 1 setzen und mit kompilieren, oder? Aktuell nutze ich nämlich das Hexfile aus dem Wiki...
Dennis schrieb: > Hexfile aus dem Wiki ECMD_PARSER, ECMD_TCP, etc sind im hex enthalten. siehe auch: http://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io#software hth
@dennis du könntest spasshalber mal die bus-spannung bei beiden geräten mit und ohne angeschlossenem adapter messen und vergleichen. //niffko
Angehängte Dateien:
-
gb132t_bus.png
75 KB
du könntest, je nach lust und laune, auch noch den bus-stecker testen, der für den anschluss von funktionsmodulen vorgesehen ist und hinten im gerät rumfliegt (siehe anhang). //niffko
Niffko _. schrieb: > du könntest, je nach lust und laune, auch noch den bus-stecker testen, > der für den anschluss von funktionsmodulen vorgesehen ist und hinten im > gerät rumfliegt Hallo, ich habe gerade den Net-IO an die hintere Klemme angeschlossen. (Nachdem wir eine viertel Std. gesucht haben) Leider wird er immer noch nicht erkannt. Danny B. schrieb: > Das einzige relevante, was man an Debugging anschalten könnte, wäre die > EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem > ECMD-Port absetzen; die zweite Zahl hinter 'Packets 1byte' ist dann die > Anzahl, wie oft der Master Adresse 0xb gepollt hat. Wenn das auf 0 > bleibt, stimmt etwas an der Heizungs-Konfiguration nicht (kann ich mir > ehrlich gesagt aber nicht vorstellen). Statistik sieht wie folgt aus: Bytes total:12134 Bytes good:2008 Bytes dropped:0 Packets good:91 Packets bad:0 Packets 1byte:10046 61 Packets ack:0 nack:0 Overflow:0 Max fill:2 Das heißt doch die Adress 0x0b wurde 61x gepollt, oder? Gruß
So wie Danny das beschrieben hat ist das wohl die Anzahl wie oft die Busadress 0x0b (11) gepllt wurde. Wichtig ist allerdings dabei die Zeit. Es werden alle möglichen Adressen der Reihe nach angepollt. Weiß nicht mehr wie oft das ist. Meine es wären irgendwas über zwei Sekunden. Wenn ein Busteilnehmer auf diese Anfrage Antwortet wird kurz darauf das Polling erhöht und wird mehrmals pro Sekunde gepollt. Also scheint es wohl Probleme mit dem Sendeteil zu geben. Der NetIO bekommt das Polling und antwortet darauf. Wenn ich Danny richtig verstanden habe wird der Counter nur erhöht wenn der NetIO auf sein Polling sendet. Also wird wohl kein Weg am Oszilloskop vorbeigehen. Am besten auf das Sendesignal vom NetIO am NetIO-Ausgang triggern lassen und dann am EMS-Bus mitloggen. Der EMS-Bus sollte dann um einige Millivolt zusammenbrechen. Hatte ja den Link zum Oszillogramm genannt. Ein Test über Klinkenstecker kann auch nciht schaden, wird aber vermutlich auch kein anderes Ergebnis liefern. Gruß Ingo
Ingo F. schrieb: > Wenn ein Busteilnehmer auf diese Anfrage Antwortet wird kurz darauf das > Polling erhöht und wird mehrmals pro Sekunde gepollt. Dann erscheint der Busteilnehmer auch im RC
Ingo F. schrieb: > Also wird wohl kein Weg am Oszilloskop vorbeigehen Habe ich gerade schon angeschlossen... :-) Die Signale des Bus sehe ich. An der Basis des Transistors sehe ich aber gegen Masse keine Peaks! Deshalb kommt auch nix auf dem Bus an. Aber wieso wird der Transistor nicht angesteuert???
Angehängte Dateien:
-
EMS_TransistorBasis.jpg
240 KB
Dennis schrieb: > Die Signale des Bus sehe ich. > An der Basis des Transistors sehe ich aber gegen Masse keine Peaks! Hier mal ein Versuch ein Bild von dem Bus (Kanal B) und der TransistorBasis (Kanal A) zu machen. Man kann leider nicht ganz so gut die Signale sehen...
Dennis schrieb: > Dennis schrieb: >> Die Signale des Bus sehe ich. >> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks! > > Hier mal ein Versuch ein Bild von dem Bus (Kanal B) und der > TransistorBasis (Kanal A) zu machen. > Man kann leider nicht ganz so gut die Signale sehen... Bei der Y-Auflösung kannst Du dort nichts sehen. Das Signal was gesendet wird ist unter 1V. Die X-Auflösung ist auch viel zu klein. Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern. Aber scheinbar hat es zum triggern gereicht, Aber die Y-Auflösung ist auch zu gering um was erkennen zu können.
Hallo, ich implementiert Adapter mit AVR-NET-IO Board für meine Buderus GB112 Kessel mit RC35. Zunächst Ethersex, die aus dem Wiki heruntergeladen wird, wurde verbrannt und ATmega644P Sicherungen sind festgelegt, wie beschrieben. Ich überprüfte, dass AVR-NET mit Ethersex läuft erfolgreich. aber keine LED-Leuchten eingeschaltet am Adapter, wenn ich ihn zu RC in paralel mit RC35. Ich konnte keine Daten von Testkollektor nicht sehen, auch. Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt, Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ... Nochmals vielen Dank für das Projekt gerne ... PS: Sorry für mein Deutsch
Dennis schrieb: > An der Basis des Transistors sehe ich aber gegen Masse keine Peaks! > Deshalb kommt auch nix auf dem Bus an. > Aber wieso wird der Transistor nicht angesteuert??? Was sagt denn der entsprechende Pin auf dem Pfostenstecker? Taner A. schrieb: > Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft > es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt, > Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem > nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die > Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ... > Nochmals vielen Dank für das Projekt gerne ... Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung kommen mir zu wenig vor. IIRC sind das doch 12V?
Ingo F. schrieb: > Wichtig ist allerdings dabei die Zeit. > Es werden alle möglichen Adressen der Reihe nach angepollt. Weiß nicht > mehr wie oft das ist. Meine es wären irgendwas über zwei Sekunden. Mal schnell nachgeschaut: bei inaktiven Adressen liegt das Polling-Intervall bei ca 1,25sec.
1 | 15-11-06 6:47:05 45692.544 83 81 {4} 55 AA 83 81 D9 3E 3C 56 80 36 B9 02 04 00 |8B 00 E5 1A
|
2 | 15-11-06 6:47:06 46945.048 83 81 {4} 55 AA 83 81 DA 3E 3C 56 18 53 CC 02 04 00 |8B 00 E5 1A
|
3 | 15-11-06 6:47:08 48202.752 83 81 {4} 55 AA 83 81 DC 3E 3C 56 00 84 DF 02 04 00 |8B 00 E5 1A
|
4 | 15-11-06 6:47:09 49455.460 83 81 {4} 55 AA 83 81 DD 3E 3C 56 64 A1 F2 02 04 00 |8B 00 E5 1A
|
Aktive Busteilnehmer hingengen alle ~50ms (bsp. 0x90) abgefragt:
1 | 15-11-06 6:47:09 49712.100 83 81 {4} 55 AA 83 81 DD 3E 3C 56 E4 8B F6 02 04 00 |90 00 E5 1A
|
2 | 15-11-06 6:47:09 49763.511 83 81 {4} 55 AA 83 81 DD 3E 3C 56 B7 54 F7 02 04 00 |90 00 E5 1A
|
3 | 15-11-06 6:47:09 49827.203 83 81 {4} 55 AA 83 81 DD 3E 3C 56 83 4D F8 02 04 00 |90 00 E5 1A
|
4 | 15-11-06 6:47:09 49917.433 83 81 {4} 55 AA 83 81 DD 3E 3C 56 F9 AD F9 02 04 00 |90 00 E5 1A
|
5 | 15-11-06 6:47:09 49968.740 83 81 {4} 55 AA 83 81 DD 3E 3C 56 64 76 FA 02 04 00 |90 00 E5 1A
|
> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung > kommen mir zu wenig vor. IIRC sind das doch 12V? Hier sind's ca 15V mit einer ESP-Bridge, 13V wenn zwei Bridges angeschlossen sind. Der Signalhub (eingehend) liegt bei ca 4-5V. Die ESP-Bridge, die vom EMS-Bus versorgt wird, zieht ca. 50mA.
Ingo F. schrieb: > Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen > (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern. Ist es nicht so das die Basis vom OP mit 5V angesteuert wird? Deshalb hatte ich Kanal A mit 5V/d eingestellt... Als ich es dann wieder abgebaut hatte habe ich auch daran gedacht doch besser noch einmal den Eingang des OP bzw. den TX-Pin des µC zu messen. Werde ich heute noch einmal versuchen... Schade nur das ich den Verlauf nicht speichern kann. :-(
Dennis schrieb: > Ist es nicht so das die Basis vom OP mit 5V angesteuert wird? > Deshalb hatte ich Kanal A mit 5V/d eingestellt Habe mir gerade mal die Schaltung angesehen. http://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io#hardware Normalerweise sollte der OP-Ausgang hochohmig sein und wird über einen 4,7KOhm Widerstand auf +5Volt gezogen. Der OP zieht beim Senden die Basis vom Transistor auf 0V. Vermutlich hast Du mit Deiner Messchnur den Eingang auf Dauerhaft-0 gezogen. Wenn ich das Bild richtig Deute hast Du dort durchgehen 0,17V Also am besten vor dem OP messen. Für den EMS-Bus musst Du allerings die Empfindlichkeit erhöhen. Die Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann vom Master nochmals für alle wiederholt wird. Aber die Zeitachse sollte auch weiter auseinander gezogen werden.
:
Bearbeitet durch User
Ingo F. schrieb: > Normalerweise sollte der OP-Ausgang hochohmig sein und wird über einen > 4,7KOhm Widerstand auf +5Volt gezogen. Der OP zieht beim Senden die > Basis vom Transistor auf 0V. > Vermutlich hast Du mit Deiner Messchnur den Eingang auf Dauerhaft-0 > gezogen. Das würde ja bedeuten der Bus ist dauerhaft mit den 220 Ohm belastet und wird beim senden dann "entlastet"? Ingo F. schrieb: > Die > Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann > vom Master nochmals für alle wiederholt wird. Wie muss ich mir das vorstellen? Wie man auf dem Bild sieht wird der Bus von ca. 14,85V bei Telegrammen auf ca. 14,3V runtergezogen. Würde man beim senden dann die Telegramme oberhalb der 14,85V Linie sehen?
Dennis schrieb: > Das würde ja bedeuten der Bus ist dauerhaft mit den 220 Ohm belastet und > wird beim senden dann "entlastet"? Ups. habe mich vom GND täuschen lassen das oben liegt. Das ist ein NPN-Transistor. Also die Basis vom Tranistor wird vom OP dauerhaft auf 0 gezogen. Im Sendefall zieht der 4,7kOhm Widerstand die Basis hoch. Das bedeutet aber auch dass an der Basis etwa 0,7V abfallen Dennis schrieb: > Ingo F. schrieb: >> Die >> Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann >> vom Master nochmals für alle wiederholt wird. > > Wie muss ich mir das vorstellen? Wie in diesem Bild: https://www.mikrocontroller.net/attachment/191441/EMS_Burst2.jpg Die Grüne Kurve ist der EMS-Bus. Das große Signal ist der Master und das kleine Signal oben ist der NetIO
Ingof schrieb: > Die Grüne Kurve ist der EMS-Bus. Das große Signal ist der Master und das > kleine Signal oben ist der NetIO Man sieht dort zwei Byte Polling. Das wird dann vom NetIO beantwortet. Der Master widerholt sofort darauf jedes Byte. insgesamt also 6 Bytes.
Danny B. schrieb: > Taner A. schrieb: >> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft >> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt, >> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem >> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die >> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ... >> Nochmals vielen Dank für das Projekt gerne ... > > Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung > kommen mir zu wenig vor. IIRC sind das doch 12V? wenn ich ziehen Sie das RC35 ist die Spannung am RC 12 Volt. Aber wie gesagt, bevor die Spannung ist etwa 5-6 Volt, wenn RC35 verbunden
:
Bearbeitet durch User
Taner A. schrieb: > Danny B. schrieb: > >> Taner A. schrieb: >>> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft >>> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt, >>> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem >>> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die >>> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ... >>> Nochmals vielen Dank für das Projekt gerne ... >> >> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung >> kommen mir zu wenig vor. IIRC sind das doch 12V? > > wenn ich ziehen Sie das RC35 ist die Spannung am RC 12 Volt. Aber wie > gesagt, bevor die Spannung ist etwa 5-6 Volt, wenn RC35 verbunde Sorry nicht so ganz vertstanden. Am Bus sollte immer etwas über 12 Volt sein. Wann sind es 5-6 Volt? Wenn Du die Platine Anschließt? Wenn das so ist stimmt irgendwas mit der Platine nicht.
Ingo F. schrieb: > Bei der Y-Auflösung kannst Du dort nichts sehen. Das Signal was gesendet > wird ist unter 1V. > Die X-Auflösung ist auch viel zu klein. > > Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen > (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern. > > Aber scheinbar hat es zum triggern gereicht, Aber die Y-Auflösung ist > auch zu gering um was erkennen zu können. Hallo, ich habe gerade Vergleichsmessungen zwischen meiner funktionierenden GB142 und der GB132T gemacht. Leider kann ich das Scopemeter nicht kleiner als 20ns/d auf der Zeitachse einstellen. Ich sehe aber in beiden Fällen ähnliche Signale: - an der Transistorbasis liegen ca. 60mV an und man sieht dann Peaks von 700mV - am Pin5 des OP liegen in beiden Fällen ca. 630mV - an Pin6 des OP liegen ca. 5V und man sieht auch Peaks in Richtung 0V Einzig der Intervall in der diese Peaks an Basis bzw. TX Ausgang des µC kommen unterscheidet sich. Vermutlich weil bei der GB142 die Adresse 11 als vorhanden erkannt wurde. Ohne Speicher Oszilloscop werde ich hier aber wohl nicht mehr weiter kommen, richtig? Wieviel MHz sollte das Oszilloscope denn können? Gruß
Ingof schrieb: > Sorry not quite vertstanden. At the bus should always about 12 volts > be. > When there are 5-6 Volt? If you connect the board? If so > Is something wrong with the board. beim RC35 ist verbunden GB112, die RC voltzahl 5-6 Volt. (der adapter ist nicht angeschlossen) RC35 ist mit GB112 mit 20 Meter kabel verbunden ...
@Taner bad news ... im GB112 arbeitet ein UBA1.5 und der kommuniziert nicht über EMS. mir ist leider auch nicht bekannt, dass das dort verwendete protokoll schon "reversed" wurde. //niffko
Angehängte Dateien:
-
GB112-UBA.jpg
98 KB
Niffko _. schrieb: > @Taner > bad news ... im GB112 arbeitet ein UBA1.5 und der kommuniziert nicht > über EMS. mir ist leider auch nicht bekannt, dass das dort verwendete > protokoll schon "reversed" wurde. > > //niffko Oooopsss.... :( gibt es eine andere andere Protokoll vom RC35 verwendet? soweit ich weiß, RC35 nutzen nur EMS-Bus
:
Bearbeitet durch User
Taner A. schrieb: > Ingof schrieb: >> Sorry not quite vertstanden. do you use google-translator? I think it is better to write in english. Do you have 12V at the bus if nothing is connected? And if you connect the RC35 there are at first 12V and after a while there is only 5V? In the RC35 manual i can only find the EMS-Bus. Maybe the RC35 switches to an other Bussystem. But it seems that the RC35 changes the bussystem.
gb112 definitely cant't talk ems! there's a reason why rc35 can handle this. rc35 is the replacement unit for the obsolete erc-controller, so it can switch protocol and hw-interface. rc30 can neither be plugged on pre-ems systems. //niffko
Ingof schrieb: > Do you use Google translator? > I think it is better to write in English. > > Do you have 12V at the bus if nothing is connected? > And if you connect the RC35 there are at first 12V and after a while > there is only 5V? > > In the RC35 Manual I Can Only Find the EMS bus. > Maybe the RC35 switches to an other bus system. > > But It Seems That the RC35 changes the bus system Yes that's right. First 12V, after I connect GB112 RC to RC35, it reduces to 5-6 volts.
Niffko _. schrieb: > GB112 definitely cant't talk ems! There's a reason why RC35 can handle > this. RC35 is the replacement unit for the obsolete ERC controller, so > it can switch protocol and hardware interface. RC30 can neither be > plugged on pre-ems system. > > // niffko Thanks for the info, niffko. But km200 web system can talk with rc35 (I think via ems) so that, when rc35 is connected to gb112, can I talk with rc35 via ems ?
not sure i get you right, but both km200 and rc35 are in fact bus-clients. bus functionality is provided by the burner-automat acting as bus-master (UBA1.5 in your case, non-ems). so if there's no ems-bus-master, no client can talk ems to one another. //niffko
Hallo, ich benutze vom Ingo die EMS-Gateway Hardware, mit ENC28J60 Netzwerkmodul. Mich würde interessieren wie ich die Seite "ems-php-webinterface-master" benutzen kann. Ich habe kein Raspi. Ist es möglich direkt vom PC mit der Web-Seite über Gateway auf die Heizung zuzugreifen? Wie gebe ich den Port und die IP-Adresse ein? Kann man auch die Heizungseinstellungen vornehmen? Benötige ich evtl. noch den ems-collector?
Ja, genauso läuft es bei mir.... EMS–Gateway am Linux-PC mit Collector, Frontend und mySQL. Habe es aber nicht hinbekommen MySQL und Frontend auf verschiedenen Servern laufen zu lassen. Mit dem Windows-PC gibt es laut Danny eine Version ohne MySQL.
Angehängte Dateien:
-
schatlplan_Adapter.png
190 KB -
Bestueckungsplan.png
430 KB
Hallo zusammen, Ich habe versucht nach dem Wiki und den Forenbeiträgen ein System aus Adapterplatine, AVR NET IO und Raspberry aufzubauen. Leider nur mit dürftigem Erfolg, denn scheinbar haben alle Teilsysteme Fehler: 1. Adapterplatine Leider bin ich mit dem Schaltplan und den Layouts weniger gut zurechtgekommen als meine Vorredner. Meiner Meinung nach hat sich auch ein Fehler im Eagle Schaltplan oder im Platinenlayout eingeschlichen, da die Operatoren vertauscht sind. Zumindest passt das Layout nicht zum Schaltplan. Ich habe mich daher zunächst schwer getan, alle Bauteile auf dem Layout zu identifizieren. Anbei mein Bestückungsplan und Korrekturen im Eagle Schaltplan. Wäre schön wenn sich jemand diese ansehen könnte, da ich wenig Erfahrung habe und vielleicht schon hier ein Fehler liegt. 2. AVR NET IO 2.1. ATMEGA 644P getauscht mit Hex aus dem WIKI geflasht 2.2. Fusebits gebrannt und auch überprüft 2.3. IP und MAC Adresse entsprechenf geändert. Was ist mit dem Gateway? Trage ich hier meine Routeradresse ein? Sobald ich das mache, ist mein AVR NET IO selsbt nach einem restart nciht mehr ansprechbar un einzige Abhilfe ist ihn erneut zu flashen.. Ich habe das Gateway daher zunächst auf dem Standartwert gelassen. 2.4. ethersex page angesprochen : funktioniert 2.5 http://<meineIP>/ecmd?ems%20stats : mit angeschlossenem Adapter und EMS BUS: Bytes total:0 Bytes good:0 Bytes dropped:0 Packets good:0 Packets bad:0 Packets 1byte:0 0 Packets ack:0 nack:0 Overflow:0 Max fill:0 mit angeschlossener Platine ohne angeschlossenem EMS BUS: Bytes total:4470 Bytes good:19 Bytes dropped:0 Packets good:19 Packets bad:838 Packets 1byte:2670 0 Packets ack:0 nack:0 Overflow:0 Max fill:4 Die Platine habe ich überprüft, optisch scheint alles in Ordnung zu sein. Der EMS Anschluss scheint durch die Dioden verpolunempfindlich, richtig? Vielleicht habe ich die Platine doch falsch bestückt? 3. Raspberry später mehr dazu. Ich möchte euch nicht verwirren
Habe noch vergessen zu erwähnen welche Heizungskonfiguration ich verwende: Buderus Logamatic U124-11 mit UBA und RC(weder 30 noch 35!!). Hier die Beschreibung meiner RC: http://documents.buderus.com/download/pdf/file/5646994.pdf Ist aber wohl auch ein EMS BUS Gerät.
passuff schrieb: > die Operatoren vertauscht sind Das ist egal. Beide Comperatoren sind untereinander austauschbar.
Seppl F. schrieb: > Buderus Logamatic U124-11 ... die U124 ist kein ems-gerät. das wird nix, sorry ... @ingo ich denke, es wird langsam zeit für eine blacklist in der wiki. //niffko
Niffko _. schrieb: > Seppl F. schrieb: >> Buderus Logamatic U124-11 ... > > die U124 ist kein ems-gerät. das wird nix, sorry ... > > > @ingo > ich denke, es wird langsam zeit für eine blacklist in der wiki. > > > //niffko Oh jeh. Das wäre natürlich mehr als ungünstig. Kann es aber immer noch nicht ganz glauben. Laut Buderus Kundendienst kann ich meine U124 auf eine RC35 Bedieneinheit umrüsten. Das war mir allerdings zu teuer und auch nicht ausreichend funktionell, daher habe ich mich nach Alternativen umgeschaut. So kam ich zum EMS Gateway... Ich schreibe dem Buderus Kundendienst jetzt erst einmal....
Niffko _. schrieb: > ich denke, es wird langsam zeit für eine blacklist in der wiki. ist schon passiert. Wusste nicht was ich wohin schreiben sollte. Habe es erst mal so gelöst: http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-bus Hoffe ich habe nicht falsches geschrieben...
Seppl F. schrieb: > Laut Buderus Kundendienst kann ich meine U124 auf eine RC35 > Bedieneinheit umrüsten. das ist korrekt. heißt aber nicht, dass die kommunikation über ems erfolgt. siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" . Seppl F. schrieb: > Ich schreibe dem Buderus Kundendienst jetzt erst einmal.... tust du hier gerade ;) IngoF schrieb: > [Blacklist]Hoffe ich habe nicht falsches geschrieben... passt. ich mach mal die komplette liste fertig und stelle sie hier rein. //niffko
Hatte mir gerade die Serviceanleitung der RC35 durchgelesen und da fiel es mir wie Schuppen von den Augen. Nachrüstbar heißt, wie du schon geschrieben hast, nicht zwangsläufig, dass meine Anlage auch EMS spricht. ?UCK.. Gibt es Erkenntnisse ob man die RC35 als Gateway nutzen kann und sich mit dem hier beschriebenen System draufsetzen kann?
Geräte ohne EMS-Bus: U104 U112 U114 U122 U124 GB102 GB112 Linea Kombi 23 GB122 //niffko
Hallo Ingo F., hallo Zusammen, ich versuche mich auch an der Anschaltung. Adapterplatine muss ich noch zusammen bauen, dann ... Leider bin ich im Wiki (wiki:ems:net_io) auf so manche "Eigenheiten" gestoßen. Welche ich wohl nicht verstehe. Bzw. mit der Bitte um Korrektur. Bei der Ethersex-Software sind die Konfigurationsschritte gut erklärt. Aber was muss bei Protocols ---> [*] EMS Support ---> EMS USART auswählen/eintragen werden? Ich habe dort jetzt eine 1 stehen. Richtig? Software auf dem Linux-Rechner (Raspian/Debian). Hier fehlt IMHO einige „-dev“ Wenn man „libmysql++“ installieren will klappt das hier* nicht, weil apt-get meint alles zu nehmen was libmysql zu tun hat/anfängt. Das war hier unauflösbar. (Auch müsste bei libboost1.50-all / libboost1.49-all noch ein „-dev“ dran) Auf der Wiki-Seite ist zur Datei „/etc/default/ems-collector“ ein Eintrag falsch: SERIALDECIVE="tcp:192.168.XXX.XXX" Dieses sollte sicherlich SERIALDEVICE="tcp:192.168.XXX.XXX:7950" heißen. (V und C vertauscht und Port nicht vorhanden) Sonst bekomme ich den collectord nicht am laufen. Bzw. beendet sich sofort wieder. Viele Grüße Olaf hier* = Rasperry PI mit Raspian 7.8 oder x86er mit Debian 7.9
ingof schrieb: > Mit dem Windows-PC gibt es laut Danny eine Version ohne MySQL. Hallo Ingo, ich bekomme keine Verbindung zu ems-php-webinterface-master mit Windows PC. Gibt es eine Möglichkeit die IP einzustellen? Habe die IP mit collectord.exe eingegeben. Wie ich Mysql einrichte weiß ich auch nicht. Ich habe eine kostenlose Website mit bplaced eingerichtet. Außerdem würde ich auch gerne mit dem Android Handy auf die Werte zugreifen. Im Moment benutze ich die von mir erweitere HTML Seite von Jürgen S. Hier kann ich die IP einstellen und auch übers Internet die Werte abfragen. Viele Grüße Franz
Hallo Leute, habe vor einiger Zeit diesen Thread und das dazugehörige Wiki gefunden und bin begeistert. Also habe ich mir die Komponenten bei Pollin und Reichelt bestellt und habe mit der NetIO Platine dem Flashen des ATmega644P begonnen - und stoße bereits auf die ersten Probleme :-( Habe das fertige Hex-File mit PonyProg und einem AMTEL Evaluations-Board auf den 644P geflasht - auch die Fuses gemäß dem Thread angepasst. Der Zugriff per LAN funktioniert - ich kann per ECMD Kommando die Werte (MAC, IP, Gateway etc.) setzen und sie auch per ECMD?reset aktivieren, doch leider werden die eingestellten Werte nicht dauerhaft gespeichert. Sobald ich die Spannungsversorgung des NetIO Boards unterbreche 'vergisst' es alle zuvor gemachten Einstellungen und setzt sich wieder auf die Standardeinstellungen zurück. Habe schon verschiedene Vorgehensweisen durchprobiert - leider bisher ohne Erfolg :-( Hat jemand eine Idee, woran das liegen könnte und was ich machen kann, um die Netzwerkeinstellungen dauerhaft zu speichern? Danke für die Unterstützung :-) piet
Peter W. schrieb:
< ... kann per ECMD Kommando die Werte (MAC, IP, Gateway etc.) setzen
< und sie auch per ECMD?reset aktivieren. ...
Hi Piet,
"reset" weglassen. ;)
hth
Karl M.
Hallo Karl, vielen Dank für die schnelle Rückmeldung - aber an dem Reset Befehl liegt es wahrscheinlich nicht. Wenn ich die Stromversorgung vom NetIO Board mit dem geflashten 644P einschalte, dann sind die default Netzwerkeinstellungen aktiv. Ich kann dann mit den ECMD Kommandos über den WEB Browser die Einstellungen verändern. Die geänderten Einstellungen werden aber nicht aktiv (bis auf die MAC Adresse). Bei der Abfrage der geänderten Werte werden immer noch die Default Einstellungen zurückgegeben (IP, Gateway). In diesem Thread wird der Hinweis gegeben, dass ein Neustart erforderlich ist, um die geänderten Einstellungen zu aktivieren. Dies funktioniert bei mir aber leider nicht. Wenn ich nach der Anpassung die Stromversorgung unterbreche, sind nach dem Neustart wieder die Standardeinstellungen aktiv. Wenn ich nach der Anpassung der Netzwerkeinstellungen den Reset Befehl sende, dann sind die neuen Einstellungen aktiv - das Board ist dann auch über die geänderte IP erreichbar und die Abfrage der Parameter über ECMD liefert auch die geänderten Einstellungen zurück. Aber ein anschließender Neustart (durch unterbrechender Stromversorgung) setzt alle Einstellungen wieder zurück. Bin für jeden Tip dankbar :-) Viele Grüße Piet
Sers Piet, bei mir geht's so:
1 | http://192.168.100.151/ecmd?ip 192.168.100.152 |
-> ok reboot (vulgo: Stecker raus)
1 | http://192.168.100.152/ecmd?ip |
-> 192.168.100.152 Auf das Netzwerksegment (Subnetz) achten! Gruß aus der Wetterau und Frohes Fest an Dich und alle Mitleser! Karl M.
Hallo Karl, hallo Forum, frohe Weihnachten 2. Teil an alle ;-) Bei mir sieht es folgendermaßen aus: NetIO Adapterplatine direkt verbunden mit dem LAN Anschluss von einem PC. Netzwerkadresse am PC auf 192.168.0.1 eingestellt http://192.168.0.0/ecmd?ip -> 192.168.0.0 http://192.168.0.0/ecmd?ip 192.168.1.60 -> OK Reboot IP Adresse vom PC umstellen auf 192.168.1.61 http://192.168.1.60/ecmd?ip -> 192.168.1.60 http://192.168.1.60/ecmd?mac -> ff:ff:ff:ff:ff:ff http://192.168.1.60/ecmd?mac 00:22:f9:01:d1:e2 -> OK http://192.168.1.60/ecmd?mac -> 00:22:f9:01:d1:e2 Reboot http://192.168.1.60/ecmd?ip -> Keine Antwort von der Net-IO Platine IP Adresse vom PC umstellen auf 192.168.0.1 http://192.168.0.0/ecmd?ip -> 192.168.0.0 Die Platine hat die gemachten Einstellungen 'vergessen'. Gibt es bei den Einstellungen eine bestimmte Reihenfolge, die einzuhalten ist? Ich habe schon verschiedene Varianten ausprobiert, leider bisher ihne Erfolg. Ich schaffe es nicht, die Netzwerkeinstellungen der NetIO Platine dauerhaft zu speichern. Beim Durchtesten der verschiedenen Parameter habe ich festgestellt, dass ein 'ecmd?reset' die eingestelten Parameter aktiviert - ich kann also die MAC Adresse, die IP Adresse, die Netzwerkmaske und das Gateway einstellen und nach einem 'ecmd?reset' sind die eingestelltn Parameter aktiv und die Platine ist in meinem Netzwerk problemlos erreichbar - nach einem PowerCycle sind allerdings wieder die Default Einstellungen aktiv. Wo genau werden diese Daten eigentlich gespeichert? Oder kann jemand sagen, an welcher Stelle die Netzwerkparameter in dem Hex File hinterlegt sind? Dann könnte ich die direkt in das Hex-File integrieren... Oder hat jemand noch eine andere Idee, wie ich die Netzwerkparameter dauerhaft gespeichert bekomme? Vielen Dank! piet
Peter W. schrieb > Oder hat jemand noch eine andere Idee, wie ich die Netzwerkparameter > dauerhaft gespeichert bekomme? Den hex mit gewünschten Einstellungen selber backen, siehe: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#software Readya Karl M.
Hallo, ich wollte mich herzlich bei allen beteiligten Personen bedanken. Gestern habe ich endlich die Platine anschließen können. Provisorisch. Nach ein paar „Streitigkeiten“ mit meinem Linuxserver läuft heute alles wie gewünscht. Vielen Dank! Viele Grüße Olaf
Hallo, Ich habe die EMS-Adapterplatine zweimal vergeblich aufgebaut. Ich habe leider zwei linke Hände dafür. Ich bekomme via telnet auf collectord (tcp:7777) nur ein Timeout auf getversion. Via ecmd ems stats bleiben alle Werte auf Null. Der EMS-Bus gehört zu einer GB-172 und sollte prinzipiell funktionieren. Wenn jemand einmal eine Platine (bestückt oder unbestückt ist egal) an mich veräußern könnte und sich bei mir meldet, wäre ich sehr dankbar.
Hallo Matthias,
> Via ecmd ems stats bleiben alle Werte auf Null.
Ist in dem NET-IO (o.ä.) ein ATmega644P bzw. ATmeda1284P gesteckt?
(Der ATmega644-20PU ist falsch es muss mindestens der ATmega644P
-20PU sein)
Danke für die Antwort Olaf. Es ist das Experimentierboard von Ulrich Radig http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex Ist der zweite usart hier entscheidend?
Matthias F. schrieb: > Ist der zweite usart hier entscheidend? Da ich mal nicht davon ausgehe, dass du die RS232-Buchse samt MAX232 runtergerissen hast: ja, ist sie, da darüber die EMS-Kommunikation läuft. Wenn du den MAX232 abbaust, kannst du natürlich auch den EMS daran anschließen und Ethersex entsprechend umkonfigurieren, dann reicht auch ein 644 ohne P.
:
Bearbeitet durch User
Ein frohes neues Jahr wünsche ich. Danny B. schrieb: > Da ich mal nicht davon ausgehe, dass du die RS232-Buchse samt MAX232 > runtergerissen hast: ja, ist sie, da darüber die EMS-Kommunikation > läuft. Wenn du den MAX232 abbaust, kannst du natürlich auch den EMS > daran anschließen und Ethersex entsprechend umkonfigurieren, dann reicht > auch ein 644 ohne P. Ich habe den MAX232 nun runtergerissen und die Pins des Atmega644 so verdrahtet: m644 |LM393P ================== 14 (RXD)PD2 | Pin4 15 (TXD)PD1 | Pin6 Es werden Daten auf dem EMS-Bus empfangen wo auch die Regelung RC300/GB172 sitzt. Allerdings kann ich auf dem Bus nicht schreiben. Bspw. bringt ein 'getversion' in der Konsole des collectord:7777 dann ein timeout: ``` IO: Sending bytes 0x88 0x10 00 0x60 IO: Sending bytes 0x88 0x10 00 0x60 IO: Sending bytes 0x88 0x10 00 0x60 IO: Sending bytes 0x88 0x10 00 0x60 IO: Sending bytes 0x88 0x10 00 0x60 ERRTIMEOUT ``` So etwas kam auch mal rein ``` IO: Got bytes 0xaa 0x55 0x19 0x8 00 0x2a 00 00 00 00 00 00 00 00 0x1 0xd 0x1 0xd 0x80 00 00 0x80 00 0x80 00 0x80 00 00 0x22 MESSAGE[01.01.2016 17:56:33]: source 0x08, dest 0x00, type 0x2a, offset 0, data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x0d 0x01 0x0d 0x80 0x00 0x00 0x80 0x00 0x80 0x00 0x80 0x00 0x00 DATA: Unhandled message received(source 0x08, type 0x2a). IO: Got bytes 0xaa 0x55 0x17 0x8 00 0x34 00 0x3c 0x2 0x4a 0x2 0x4a 0x21 00 0x1 0x3 00 00 0x2 0x63 00 00 0x5c 00 0x80 00 0x9e MESSAGE[01.01.2016 17:56:34]: source 0x08, dest 0x00, type 0x34, offset 0, data: 0x3c 0x02 0x4a 0x02 0x4a 0x21 0x00 0x01 0x03 0x00 0x00 0x02 0x63 0x00 0x00 0x5c 0x00 0x80 0x00 ``` ``` Scheitert es nun an der Pin-Zuordnung? Hardcoded ist es in ethersex ja nicht. USART0 habe ich unter Protocols/EMS/UART 0 ausgewählt. Vielen Dank im Voraus für eure Hilfe.
Wie alt ist dein Ethersex-Checkout, und welches Repo verwendest du? Bis vor kurzem musste man im Pinning den TX-Pin für die Generierung der Break-Condition nochmal separat konfigurieren.
Es ist das Standard-Ethersex-Repo: git:master Den git-clone habe ich vor einer Woche gemacht.
Hallo liebe EMS Gemeinde, habe mir auch die Platine im freien Layout aufgebaut, und ebenfalls das Problem, das die EMS STATS auch leer sind, es ist aber ein 664p auf einem AVR NET IO verbaut. Die Platine habe ich schon zwei mal kontrolliert. Ich habe das fertige HEX file von der EMS Wiki Seite mit einem MKII und Atmel Studio 7 programmiert. Anschliessen habe ich auch die Fuses kontrolliert. Fuses: low=E7 high=DC ex=FF lock=FF. Was mich auch etwas stuzig macht unter HTTP://x.x.x.x/adc.ht haben die 8 Kanäle immer so um die 30 %. Auch wenn ich über das Testcollektor JAVA Tool mal eine Uhrzeit sende Blinkt keine sende leuchte. Hat noch jemand eine Idee, oder eine fertige Adapterplatine die getestet ist zum erweben. Als Heizkessel ist hier ein LOGAMAX GB132 mit RC30 die auch Funktionsfähig ist. Bytes total:3 Bytes good:0 Bytes dropped:0 Packets good:0 Packets bad:0 Packets 1byte:3 0 Packets ack:0 nack:0 Overflow:0 Max fill:1
:
Bearbeitet durch User
Hallo Zusammen, habe mir jetzt (nach Aufsetzen eines Ubuntu Rechners) das Hexfile mit den richtigen Netzwerkeinstellungen selbst erstellt. Nun funktioniert die NetIO Platine wir erwartet. Trotzdem komisch, dass die Netzwerkparameter nicht dauerhaft gespeichert werden :-( Nun habe ich leider noch ein Problem bei der Installation der EMSTools auf dem Raspi. Ich nutze einen Raspi2 Modell B mit Raspian Jessie. Die Installation von libmysql++ funktioniert schon nicht. Ich habe die Meldung mal als Text File angehängt. Ich habe hier im Forum einen Eintrag gefunden, dass ein '-dev' angehängt werden muss - also "sudo apt-get install libmysql++-dev" - das ist dann ohne Fehler durchgelaufen. Nach der Installation der anderen Pakete, habe ich die Installation der EMS Tools mit "sudo dpkg --install ./ems-buderus_0-4.deb" gestartet. Die Installation läuft bis zu einem bestimmten Punkt bei dem Compilieren des Collectors mit RAW support - da bricht er dann ab (siehe angehängte Datei). Ich würde mich über Tips, wie ich das Problem lösen kann, sehr freuen. Viele Grüße piet
Wer auch immer das deb-Package erstellt hat, muss sein Makefile aktualisieren. Da fehlt ein -DHAVE_MYSQL. Der erste Compilevorgang läuft wahrscheinlich mit meinem Makefile (und funktioniert deshalb), der zweite Compilevorgang benutzt wahrscheinlich ein eigenes Makefile.
Hallo Danny, vielen Dank für die Rückmeldung :-) Das deb-Paket wurde von Lars_r48 erstellt. Was mich nur wundert ist, dass bisher offensichtlich sonst niemand das Problem hatte - oder kann es sein, dass es nur bei mir nicht funktioniert? @Lars_r48 hättest Du Zeit und Lust, das deb-Package anzupassen? Ich würde mich über eine kurze Rückmeldung freuen, da ich ansonsten versuchen würde, die Komponenten "zu Fuß" zu installieren. piet
Ich glaube das ist so alt, da wird einiges nett mehr Funktionieren. Ich sehe es mir heute Abend mal an, aber da ich es selbst nicht mehr nutzen kann wegen meiner Rc300 hatte ich es auch aus den Augen verloren.
Für die Abhängigkeiten bitte selbst sorgen, bin da kein Profi drinne....
Hallo, mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der 644p-20pu der richtige Processor. low=E7 high=DC ex=FF lock=FF. Des weiteren wenn ich mit der JAVA Collektor Software sende, muss dann auf jeden fall die LED Blinken ???? Das tut sie auch nicht. Danke für eure hilfe
:
Bearbeitet durch User
Denis L. schrieb: > mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der > 644p-20pu der richtige Processor. Der controller passt. Erstelle das hexfile besser mal selbst aus ethersex'github Ich habe auch noch das Problem,dass ich keine Daten senden kann. Empfang klappt aber. Wahrscheinlich die selbst gebaute Platine... Wenn da wer mal eine für mich übrig hat, wäre ich sehr froh...
Hallo Forum, nach einigen Fehlschlägen und einigem Rumprobieren habe ich den "collectord" nun compiliert bekommen... Und was soll ich sagen - ES FUNKTIONIERT (weitestgehend) :-) Ein riesengroßes Dankeschön schonmal an Alle, die hier Fragen beantworten und Ihre Zeit und Ihr Wissen zur Verfügung stellen!!! Leider gibt es noch ein paar Dinge, die nicht ganz rund laufen und daher habe ich noch einige Fragen. Zunächst mal bekomme ich den "collectord" nicht als Service gestartet. Beim Versuch passiert folgendes:
1 | sudo service ems-collector start |
2 | Job for ems-collector.service failed. See 'systemctl status ems-collector.service' and 'journalctl -xn' for details. |
3 | |
4 | systemctl status ems-collector.service |
5 | ● ems-collector.service - LSB: EMS collector daemon |
6 | Loaded: loaded (/etc/init.d/ems-collector) |
7 | Active: failed (Result: exit-code) since Mon 2016-01-11 18:37:05 CET; 27s ago |
8 | Process: 5905 ExecStart=/etc/init.d/ems-collector start (code=exited, status=1/FAILURE) |
"Zu Fuß" kann ich den "Collectord" problemlos starten und er empfängt auch Daten über den NetIO vom EMS Bus. Die Dazugehörigen Konfigurationsdateien habe ich an diesen Post angehängt. /etc/ems-collector.conf /etc/init.d/ems-collector /etc/Default/ems-collector Das "collectord" Binary liegt im Verzeichnig /usr/local/sbin Vielleicht kann ja jemand helfen... Vielen Dank und viele Grüße piet
Was sagt denn journalctl -xn? Ansonsten fällt mir außer der Tatsache, dass die meisten Parameter (-u, -p, -r, -C, -D) sowohl in OPTIONS als auch in der Konfigurationsdatei enthalten sind (wozu?) erst mal nicht viel auf.
Hallo Danny, vielen Dank für die schnelle Antwort :-) journalctl -xn sagt:
1 | $ sudo journalctl -xn |
2 | -- Logs begin at Mon 2016-01-11 20:18:37 CET, end at Mon 2016-01-11 21:11:24 CET. -- |
3 | Jan 11 21:10:56 raspi2 ems-collector[2358]: -u [ --db-user ] arg Database user name |
4 | Jan 11 21:10:56 raspi2 ems-collector[2358]: -p [ --db-pass ] arg Database password |
5 | Jan 11 21:10:56 raspi2 ems-collector[2358]: TCP options: |
6 | Jan 11 21:10:56 raspi2 ems-collector[2358]: -C [ --command-port ] arg TCP port for remote command interface (0 to |
7 | Jan 11 21:10:56 raspi2 ems-collector[2358]: disable) |
8 | Jan 11 21:10:56 raspi2 ems-collector[2358]: -D [ --data-port ] arg TCP port for broadcasting live sensor data (0 to |
9 | Jan 11 21:10:56 raspi2 ems-collector[2358]: disable) |
10 | Jan 11 21:10:56 raspi2 ems-collector[2358]: failed! |
Stören die doppelt eingetragenen Parameter? Welche Parameterdatei sollte man nutzen? piet
Angehängte Dateien:
-
EMS_Rohdaten.PNG
86 KB -
Livestatus.PNG
59 KB -
Erweiterte_Einstellungen.PNG
61 KB -
Statistik.PNG
31 KB
Hallo Forum, so, habe nun noch Moosys WEB Interface installiert. Super Darstellung der verschiedenen Werte - echt klasse! Das Problem mit dem collectord als Service besteht immer noch, habe ich aber erstmal zurückgestellt... Meine Heizungsanlage ist eine GB132 mit RC30 Controller und 2 Heizkreisen (HK1 Heizkörper, HK2 Fußboden) und Warmwasserboiler. Ich habe gelesen, dass Moosys WEB Interface nur für einen Heizkreis gedacht ist (es werden ja auch nur die Werte von HK1 angezeigt). Hat schonmal jemand die Anpassungen für 2 Heizkreise vorgenommen oder kann mir jemand einen Tip geben, worauf dabei zu achten ist (kenne mich leider mit PHP und AJAX nicht aus)? Leider funktionieren nicht alle Anzeigen im WEB Interface fehlerfrei. - Keine Temperaturanzeige beim Livestatus (Heizkreis) - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B. fehlen die Temperaturwerte) - Heizkurve wird nicht angezeigt. Das WEB Interface sagt, die Anlage sei raumtemperaturgeführt - ich habe im Servicemenü vom RC30 nochmal kontrolliert, dort ist für beide Heizkreise "keine" Fernbedienung eingetragen. - Unter "erweiterte Einstellungen" werden nicht alle Änderungen in das System übernommen - z.B. "Nachtabsenkung abbrechen unter". Dagegen werden andere Parameter (z.B. Nachlaufzeit der Kesselpumpe) sehr wohl übernommen. Hier wird übrigens auch 'raumtemperaturgeführt' angezeigt, eine Änderung wird aber nicht übernommen. - Bei der Statistk fehlen immer die Werte in der Letzten Tabelle und die Graphen werden nicht generiert Im Anhang mal einige Screenshots von den Anzeigen im WEB Interface. Viele Grüße piet
Peter W. schrieb: > Hallo Danny, > vielen Dank für die schnelle Antwort :-) > journalctl -xn sagt: $ sudo journalctl -xn > -- Logs begin at Mon 2016-01-11 20:18:37 CET, end at Mon 2016-01-11 > 21:11:24 CET. -- > Jan 11 21:10:56 raspi2 ems-collector[2358]: -u [ --db-user ] arg > Database user name > Jan 11 21:10:56 raspi2 ems-collector[2358]: -p [ --db-pass ] arg > Database password > Jan 11 21:10:56 raspi2 ems-collector[2358]: TCP options: > Jan 11 21:10:56 raspi2 ems-collector[2358]: -C [ --command-port ] arg > TCP port for remote command interface (0 to > Jan 11 21:10:56 raspi2 ems-collector[2358]: disable) > Jan 11 21:10:56 raspi2 ems-collector[2358]: -D [ --data-port ] arg > TCP port for broadcasting live sensor data (0 to > Jan 11 21:10:56 raspi2 ems-collector[2358]: disable) > Jan 11 21:10:56 raspi2 ems-collector[2358]: failed! > Stören die doppelt eingetragenen Parameter? Die Ausgabe deutet schon daraufhin. > Welche Parameterdatei sollte man nutzen? Das ist prinzipiell egal, solange man jeden Parameter nur 1x angibt. Ich persönlich habe alles in ems-collector.conf, d.h. OPTIONS ist bei mir leer. > Ich habe gelesen, dass Moosys WEB Interface nur für einen Heizkreis > gedacht ist (es werden ja auch nur die Werte von HK1 angezeigt). > Hat schonmal jemand die Anpassungen für 2 Heizkreise vorgenommen oder Nicht dass ich wüsste. Ich würde aber auch Interesse daran anmelden. > kann mir jemand einen Tip geben, worauf dabei zu achten ist (kenne mich > leider mit PHP und AJAX nicht aus)? Das sind dann leider keine guten Startvoraussetzungen :( > Leider funktionieren nicht alle Anzeigen im WEB Interface fehlerfrei. > > - Keine Temperaturanzeige beim Livestatus (Heizkreis) Das hängt an den fehlenden Werten (wird aus 'hk1 daymode', 'hk1 daytemperature' und 'hk1 nighttemperature' bestimmt). Siehe unten. > - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B. > fehlen die Temperaturwerte) Das ist teilweise normal und teilweise komisch. Speziell die Temperaturwerte sollten auf alle Fälle da sein. Probier mal, dich mit Telnet auf Port 7777 zu verbinden und da das Kommando 'cache fetch hk1' aufzurufen. Sind dort daymode, daytemperature und nighttemperature vorhanden? Wenn ja, gucke ich nochmal in Moosy's Code nach, wie er das verarbeitet. Wenn nein, mache mal bitte folgendes: - führe den Collector mit den Parametern '-d message' und '-f' aus - verbinde dich zu Port 7777 (auf einem anderen Terminal) - 'hk1 requestdata' - wenn das fertig ist, poste bitte die Debug-Ausgaben des Collectors > - Heizkurve wird nicht angezeigt. Das WEB Interface sagt, die Anlage sei > raumtemperaturgeführt - ich habe im Servicemenü vom RC30 nochmal > kontrolliert, dort ist für beide Heizkreise "keine" Fernbedienung > eingetragen. Trag mal 'rc-type = rc30' in die Config ein, dann wird's wahrscheinlich gehen. Ich sollte mal eine Warnung hinzufügen, wenn dieser Wert nicht gesetzt ist. > - Unter "erweiterte Einstellungen" werden nicht alle Änderungen in das > System übernommen - z.B. "Nachtabsenkung abbrechen unter". Dagegen > werden andere Parameter (z.B. Nachlaufzeit der Kesselpumpe) sehr wohl > übernommen. Hier wird übrigens auch 'raumtemperaturgeführt' angezeigt, > eine Änderung wird aber nicht übernommen. Funktioniert denn z.B. ein 'hk1 reducedmodethreshold 5' auf Port 7777? > - Bei der Statistk fehlen immer die Werte in der Letzten Tabelle und die > Graphen werden nicht generiert Wenn die Raumtemperatur nicht gemessen werden kann, kann auch keine Statistik darüber geführt werden ;-) Die Graphen habe ich früher über einen Cronjob alle paar Minuten erzeugt; ich bin mir allerdings nicht sicher, ob das bei Moosy noch genauso ist.
Peter W. schrieb: > - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B. > fehlen die Temperaturwerte) Probier mal deine emsdetail.ajax mit der angehängten Version zu ersetzen.
Angehängte Dateien:
-
EMS_Rohdaten2.PNG
93 KB -
Heizkurve.PNG
5,4 KB
Hallo Danny, habe in der /etc/ems-collector.conf den Parameter "rc-type = rc30" ergänzt und in der /etc/default/ems-collector die Zeile OPTIONS="...." auskommentiert. Leider immer noch der gleiche Fehler beim Versuch, den collectord als Service zu starten... Habe mal Deine "emsdetail.ajax" genommen - und siehe da, die Werte sind nun vorhanden... Ich habe den collectord nun mal mit dem Parameter "-R rc30" gestartet und nun erkennt er auch, dass das System außentemperaturgeführt arbeitet. Allerdings wird die Heizkurve immer noch nicht gezeichnet :-( - ebenso wie die Graphen auf der Statistikseite. Wie lässt ma die denn per Cron Job zeichnen? Der Befehl "hk1 reducemodethreshold 5" wird im Telnet Fenster akzeptiert
1 | telnet localhost 7777 |
2 | Trying ::1... |
3 | Trying 127.0.0.1... |
4 | Connected to localhost. |
5 | Escape character is '^]'. |
6 | hk1 reducedmodethreshold 5 |
7 | OK |
...aber welchem Wert enspricht dies auf Moosys Webinterface - dem "Nachts reduzierter Betrieb unter"? Falls ja, dann wird der Wert nicht übernommen, denn in der Weseite (nach einem Refresh) steht dort wieder 0 Grad. Wenn ich z.B. den Wert "Nachtabsenkung abbrechen unter" auf der Webseite auf -5 setze, dann steht unten auf der Seite
1 | Wert 'absquit' gesetzt auf '-5'. |
Der Wert im Browser auf der Seite "Einstellungen" 'überlebt' auch einen Reload der Seite - allerdings nicht den Wechsel auf z.B. die Livestatus Seite und zurück. Die Heizkreistemperatur auf der Livestatus Seite wird auch trotz des RC30 Parameters nicht angezeigt - möglicherweise hängt das ja mit den 2 Heizkreisen zusammen... Habe dann noch den collectord mit den von Dir genannten Parametern gestartet:
1 | sudo ./collectord -R rc30 -C 7777 -D 7778 -u ems -p buderus -r 60 -d message -f tcp:192.168.1.60:7950 >/tmp/collectord.log |
... und in einem anderen Fenster ein Telnet gestartet und den Befehl 'hk1 requestdata' eingegeben - erstaunlicherweise bekomme ich in dem Telnet Fenster dazu keinen Output...
1 | telnet localhost 7777 |
2 | Trying ::1... |
3 | Trying 127.0.0.1... |
4 | Connected to localhost. |
5 | Escape character is '^]'. |
6 | hk1 requestdata |
7 | OK |
Das Logfile vom collectord enhält nicht viel Informationen - ich habe es trotzdem mal angehängt - vielleicht sind es ja die entscheidenden Infos ;-) Viele Grüße piet
Habe den Fehler mit den Graphen gefunden :-) In der Datei /emsinclude/config.py muss es heißen
1 | mysql_socket_path = "/var/run/mysqld/mysqld.sock" |
... dann klappt es auch mit den Grafiken :-)
Matthias F. schrieb: > Denis L. schrieb: >> mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der >> 644p-20pu der richtige Processor. > > Der controller passt. > Erstelle das hexfile besser mal selbst aus ethersex'github > > Ich habe auch noch das Problem,dass ich keine Daten senden kann. Empfang > klappt aber. > Wahrscheinlich die selbst gebaute Platine... > Wenn da wer mal eine für mich übrig hat, wäre ich sehr froh... Ja ich empfange mittlerweile auch endlich mal Daten mit der Lochrasterplatine, hab mir eine Platine nun Ätzen lassen. Kannst Du mir ein Hexfile erstellen, hier will die aktuelle Github mir keins rauswerfen, bekomme immer Fehlermeldungen. IP 192.168.2.41 SUB 255.255.255.0 GW 192.168.2.1 Das wäre super von euch. Liebe Grüsse Denis
Zeig mal die Logs her, was da beim Kompilieren schief geht. Ich habe im Anhang trotzdem mal ein hex-file für 644p@16MHz mit EMS auf USART1 gebaut. Hardware Pollin-AVR.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.