Juergen O. schrieb: > Ziel ist jedoch, direkt über den EMS-Bus zu versorgen. Die Stromversorgung dürfte nicht das Problem sein... habe ich auch so gemacht. Allerdings ist dann nur wichtig das der Stromverbruach nicht zu stark schwankt. Das könnte dann als Sendeversuch verstanden werden und den Bus wuschig machen Kenne den ESP8266-01 nicht. Könnte mir aber vorstellen dass der WLAN-Chip auch mal gerne schlagartig den Stromverbruach beim senden ändern könnte. Oder liege ich da komplett falsch?
:
Bearbeitet durch User
Nein, liegste vollkommen richtig. Das ESP zieht ca. 17mA, im Burst (beim Senden) jedoch bis zu 250mA. Deshalb wollte ich einen Buck-Konverter (mit Vorwiderstand zu Uems) einsetzen, um den Eingangsstrom zu reduzieren. Funktioniert jedoch nicht sauber. 0R: Der Eingangs-Elko des SDC filtert sauber alle Signale raus ;) 39R: Protokoll verstümmelt - der Komparator kommt aus dem Tritt 47R: kurze Telegramme kommen durch (wie bspw. 90 00 10 00 und 89 00 09 00), längere werden jedoch verstümmelt. 68R und größer: desaströs - der SDC schwingt nicht mehr an, R hängt voll als ohmsche Last an Uems... In allen Fällen geht die Heizung binnen kurzem auf Störung - zeigt nur noch ein blinkendes "-" an. Also fällt die Eigenversorgung mit dem ESP (zumindest via Uems) flach.
@Juergen O i'M also interested when you succeeded with a new PCB based on ESP8266-12. My ESP8266-12 is underway. If you are making new ones, count me in for one. Hope indeed to have it powered by the bus
The problem will be the powersupply. My EMS has approx. 15V w/o load. So a linear regulator for 3.3V isn't a choice at all, 'cause the ESP-12 requires approx 75mA w/o sending.
> w/o
w/o ist mir nicht geläufig, was darf ich darunter verstehen?
Im Datenblatt lese ich:
1 | Transmit 802.11b, CCK 1Mbps, POUT=+19.5dBm 215 mA |
2 | Transmit 802.11b, CCK 11Mbps, POUT=+18.5dBm 197 mA |
3 | Transmit 802.11g, OFDM 54Mbps, POUT=+16dBm 145 mA |
4 | Transmit 802.11n, MCS7, POUT=+14dBm 135 mA |
Das ist einiges! Wieviel "sporadische" Belastung verträgt denn der Bus, ohne das als Sendesequenz zu interpretieren? Könnte sowas funktionieren: EMS - Vorwiderstand - Längsregler - Goldcap - VCC? Oder gleich: EMS - Vorwiderstand - Längsregler - CR2032 - VCC?
Charlie W. schrieb: > Wieviel "sporadische" Belastung verträgt denn der Bus Also auf dem EMS-Bus wird in gesendet indem der Bus mit 227,5 Ohm belastet wird. Bei etwa 15Volt sind das etwa 66mA. Habe jetzt keine Ahnung wo die Ansprechscwelle liegt. sonst einfach mal ausprobieren wieviel Ohm den Bus durcheinander bringen wenn den Widerstand parallel zum Bus kurz anklemmt wird Vermute mal dass es bei etwa 20-30mA sein werden. Meine RC30 wird bestimmt nicht mit 30mA auskommen. Also muss dass irgendwie klappen können. Hat jemand mal den Stromverbrauch von der RC30,35,300 oder 350 gemessen? Ein einfacher Wiederstand in Reihe wird dann wohl nicht helfen. Aber vielleicht reicht es ja auch dem einen wenn die Schaltung an der Diagnosebuchse angeklemmt wird (3,5mm Klinke). Dort sind 12 Volt drauf. Wie stark die 12V-belastet werden dürfen ist mir unbekannt.
:
Bearbeitet durch User
Charlie W. schrieb: >> w/o load > w/o ist mir nicht geläufig, w/o wird without heissen. Also 15 Volt ohne Last Juergen O. schrieb: > Also fällt die Eigenversorgung mit dem ESP (zumindest via Uems) flach. Also der Raumcontroller von Buderus scheint das ja zu schaffen. Fragt sich nur wieviel Aufwand das ist dafür eine Spannungsregelung mit Buffer zu entwickeln. In meiner RC30 ist ein 5,5V 0,4F Goldcap eingebaut der einen 78L05 buffert. Vermutlch wird das beim WLAN-Chip nicht ganz so einfach sein.
:
Bearbeitet durch User
Hallo, ich finde die Verwendung des ESP8266 für die Heizungs-Kommunikation aufregend und bin gespannt was ihr noch realisiert. Ich selber habe keine Buderus sondern eine Junkersanlage, aber da ist der Heizungs-Bus mit seinen Eigenschaften sehr ähnlich. Ein paar Hinweise wollte ich zu dem Thema loswerden weil es mich auch sehr interessiert: Charlie W. schrieb: > Könnte sowas funktionieren: > EMS - Vorwiderstand - Längsregler - Goldcap - VCC? Der Vorwiderstand und Längsregler setzen die ohnehin knapp bemessene Leistung nur in Wärme um. Es muss ein Stepdown-Wandler verwendet werden, mit möglichst hohem Wirkungsgrad. Mit der Annahme, das die Strom-Schwelle bei ca.: 50mA liegt und bei einer Versorgungsspannung von minimal 10 Volt liefert der Bus für einen Client gerade mal 0,5Watt (schön gerechnet). Das ESP-Modul im Sendebetrieb und maximaler Leistung benötigt 3.3V * 0,215mA = 0,71 Watt. Das wird also sehr sehr knapp und tut dem Bus nicht gut, jedoch wird die maximale Sendeleistung ja nicht zu 100% der Zeit benötigt. Daher ist es schon gut zu wissen, wieviel Bytes/Zeiteinheit und wieviel Pause zwischen den Sendevorgängen bleibt um Luft (Strom) zu holen. Um den Stepdown-Wandler kommt man nicht herum, leider ist die Antenne fest verbaut. Da könnte ich mir noch eine effektivere vorstellen um die benötigte Sendeenergie und Stromaufnahme zu reduzieren. Gruß Norbert
Norbert S. schrieb: > Mit der Annahme, das die Strom-Schwelle bei ca.: 50mA liegt Wenn es möglich ist den Stromverbrauch langsam steigern, könnte es auch möglich sein Mehr Strom zu entnehmen. Hat jemand eine Idee wie das möglich sein könnte? Vielleicht die Ausgangsspannung des Step-Down-Wandler langsam ansteigen lassen bis zu 3,3V. Dann müsste das ESP-Modul bei erreichen der richtigen Spannung erst aktiviert werden.
:
Bearbeitet durch User
Hallo Ingo und Norbert, Norbert S. schrieb: > Ich selber habe keine Buderus sondern eine Junkersanlage. ... das wissen wir doch längst, oder glaubst Du im Ernst, wir würden Deinen coolen Thread nicht mitlesen? ;-) > Der Vorwiderstand und Längsregler setzen die ohnehin knapp bemessene > Leistung nur in Wärme um. ... na klar, sind doch existentielle Bestandteile einer Heizung. ;-) > ... knapp bemessene Leistung ... Kommt m.E. darauf an, was man betrachtet. Der EMS-Bus kann mit "vielen" Modulen betrieben werden. Meine RC35 glimmt nach Datenblatt mit Hintergrundbeleuchtung bei 0.6W. Unter 16V nach Adam Ries und Georg Ohm also 37,5mA. Andere Module werden in ähnlicher Größenordnung liegen. Daraus folgere ich mal, dass der Bus genügend Leistungsreserven hat. Kritisch ist doch die zeitlich punktuelle Belastung, die über die als "Sendebelastung" verstandene Schwelle hinausgeht. Der kann man m.E. mit einem entsprechend dimensionierten Vorwiderstand (nach Ingo: I < 20mA ==> bei 16V ca. 820R) begegnen. Dahinter eben der Regler und ein Puffer. Vielleicht wäre eine CR2032 o.ä., im Sinne der Pufferfähigkeit, besser geeignet als ein Goldcap? Oder sind meine Gedanken hier auf einer falschen Fährte? Gruß aus der derzeit frühlingshaften Wetterau Karl M. ps: je suis charlie vraiment!
:
Bearbeitet durch User
Karl M. W. schrieb: > I < 20mA > ==> bei 16V ca. 820R) begegnen. Das wäre dann für das ESP-Modul dann wohl zu wenig. 20mA von der Quelle gibt auch nur 20mA am Ausgang bei Linewarregelung. Das würde dann bedeuten dass etwa die 5fache Leistung im Linearregler verbraten wird. Das beste wäre ein Step-Down-Wandler und dann vielleicht durch Bufferung den Stromschwankungen unter z.B. 20mA halten z.B. 60-80mA. Der Strom war nur geschätzt und müsste getestet werden. Die Pufferung duch eine Knopfzelle wird nichts bringen. Habe keinhe Ahnung wie lange eine Knopfzelle bei dem Stromverbrauch für die Pufferung halten würe. Dann könnte man vermutlich besser AA-Akkus nehmen, oder? Aber hier geht es ja eher um die Schaltung komplett über den Bus versorgen lassen zu wollen.
Hallo, Karl M. W. schrieb: >Der kann man m.E. mit einem entsprechend dimensionierten Vorwiderstand ca. 820R) >begegnen. Versuch macht klug, ich kann nur theoretisch rumschwätze, weil ich das ESP-Modul noch nicht habe. Eventuell kann mann ja das ganze ein wenig entspannen (zeitlich) wenn man eben NICHT mit der laangsamen Baudrate von EMS (4800) Baud sendet sondern mal einwenig flotter auf der WiFi-Seite. Dafür ist dann allerdings auch die Software im ESP-Modul anzupassen. Das entspannt zwar nicht die Avarage-Stromaufnahme, aber kurzer Burst und lange Pause zum Strom-Tanken! Dann kannst du eventuell auch bei deinem Widerstand bleiben und statt eines Gold-Cap nur einen in Silber nehmen ! Gruß Norbert
Ich warte noch auf meinen Trenn-Trafo, damit ich vernünftige Messungen bei der Spannungsversorgung durchführen kann. Laut Hersteller Espressif liegt die Stromaufnahme des Modules zwischen 0.9mA im Sleep-Mode und max 170mA im Sendebetrieb (http://bbs.espressif.com/viewtopic.php?f=6&t=133). Problem ist anscheinend der Buck-Konverter selbst. Sobald dieser an Uems (Ausgang Gleichrichter) angeschlossen wird, zieht es den EMS-Bus nieder. Habe bereits eine Variante mit 2mA Ruhestrom probiert - ändert nichts. Die Idee ist nun, einen einfachen Längsregler (Transistor, Z-Diode, Widerstand) vor den Buck-Konverter zu schalten, um diesen mit Uems-3V zu versorgen und den EMS-Bus etwas besser vom Konverter zu entkoppeln. Die eigentliche Schnittstelle funktioniert bereits im Lesebetrieb. Wesentlich scheint hier zu sein, das der 4.7k Ausgangswiderstand am LM339 deutlich niederohmiger (ca 100R) ausgeführt wird. Mit einem 4k7 gibt es seltsame Latch-Effekte nachdem auf dem Bus der BRK gesendet wurde. Für eine gewisse Zeit (muß nochmal messen) geht das Rx-Signal nicht auf GND, sondern auf max 2V. Hierdurch kommen natürlich verstümmelte Zeichen auf dem Rx an.
Längsregler vorm Bulk-Converter funktioniert. Allerdings braucht es einen relativ fetten Kondensator am Ausgang, andernfalls wird die EMS-Kommunikation gestört. Im Anhang mal die Stromaufnahme im Uems Zweig, mit 1R Shunt gemessen.
:
Bearbeitet durch User
Juergen O. schrieb: > ... Längsregler vorm Bulk-Converter funktioniert. ... sehr schön! > ... fetten Kondensator ... oder Goldcap. ;-) Magst Du nicht einen separaten Fred eröffnen, nach Motto: EMS <> ESP8266-12 <> WLAN
Hallo, ich habe mir die Stecke EMS > Adapter > NetIO > Raspi aufgebaut. Vielen Dank an den ganzen fleißigen Entwicklern die hier ihr Projekt veröffentlicht haben und es mir so möglich war daran Teil zu haben. ;-) Ich habe bei den Frontend von Danny wie auch von Mosi einige Fehler bei der Auswertung der EMS Telegramme. Mein Heizanlage ist ein Buderus GB135-25 Ölbrenner mit RC30 V2.02, BC10 2.0 und UBA 2.01. Frontend Danny Warmwasser Soll: 10°C an Stelle -> 45°C Warmwasser Ist: -3200°C (hier wird Zeitweise der korrekte Wert Angezeigt!?) Außen gedämpft: keine Anzeige Raumtemp. IST: 3200°C Frontend Moosi zusätzlich Die Regelart der Anlage wird als Raumtemperatur geführt erkannt, das ist aber falsch, tatsächlich ist die Anlage Außentemperaturgefährt. Die Heizkurve im Frontend wird deshalb nicht angezeigt. Ich habe mal mit dem Collector ein Logfile erstellt, wäre für eine Lösung und Unterstützung sehr Dankbar. Grüße Martin
In meinem Log habe ich folgendes Entdeckt: Immer nach dem Telegramm source 0x08, dest 0x00, type 0x18, offset 0 ist die WWtemperatur bei -3200°C bei einem Telegramm source 0x08, dest 0x00, type 0x34, offset 0 wird die WWtemperatur hingegen richtig berechnet. Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, dest 0x00, type 0x3e, offset 0
:
Bearbeitet durch User
Martin Berger schrieb: > Immer nach dem Telegramm > source 0x08, dest 0x00, type 0x18, offset 0 > ist die WWtemperatur bei -3200°C > bei einem Telegramm > source 0x08, dest 0x00, type 0x34, offset 0 > wird die WWtemperatur hingegen richtig berechnet. Das Telegramm 0x18 kommt von der Brennersteuerung. Diese scheint keine Warmwassertemperatur zu haben (0x8000 wenn nicht vorhanden = -3276,8°C) Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das müsste vermutlich am besten in den EMS-Collector, oder? Martin Berger schrieb: > Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, > dest 0x00, type 0x3e, offset 0 Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller. Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder? Du hast Doch nur einen Raumtemperaturfühler, und der ist am Raumcontroller (RCxxx), oder? Gruß IngoF
:
Bearbeitet durch User
Ingo F. schrieb: > Martin Berger schrieb: >> Immer nach dem Telegramm >> source 0x08, dest 0x00, type 0x18, offset 0 >> ist die WWtemperatur bei -3200°C >> bei einem Telegramm >> source 0x08, dest 0x00, type 0x34, offset 0 >> wird die WWtemperatur hingegen richtig berechnet. > > Das Telegramm 0x18 kommt von der Brennersteuerung. Diese scheint keine > Warmwassertemperatur zu haben (0x8000 wenn nicht vorhanden = -3276,8°C) Komisch, der WWfühler ist bei mir direkt am UBA/MC10 angeschlossen. > Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das > müsste vermutlich am besten in den EMS-Collector, oder? Das sehe ich auch so. Vielleicht kann das jemand (Danny?) in den EMS-Collector basteln der mehr Ahnung von C hat als ich. ;-) > Martin Berger schrieb: >> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, >> dest 0x00, type 0x3e, offset 0 > > Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller. > > Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D > (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder? > > Du hast Doch nur einen Raumtemperaturfühler, und der ist am > Raumcontroller (RCxxx), oder? Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in der die richtige Raumtemperatur enthalten ist. Die am RC30 abgelesene Raumtemperatur habe ich schon in Hex umgerechnet und anschließend im Log gesucht. Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe ich einen Rechen/Denkfehler gemacht? Grüße Martin
Martin Berger schrieb: > Ingo F. schrieb: >> Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das >> müsste vermutlich am besten in den EMS-Collector, oder? > > Das sehe ich auch so. Vielleicht kann das jemand (Danny?) in den > EMS-Collector basteln der mehr Ahnung von C hat als ich. ;-) Das ist schon drin. Siehe EmsMessage.cpp Zeile 42 bis 48. Du benutzt aber schon mein Repo und nicht das von Moosy, oder? >> Martin Berger schrieb: >>> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, >>> dest 0x00, type 0x3e, offset 0 >> >> Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller. >> >> Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D >> (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder? >> >> Du hast Doch nur einen Raumtemperaturfühler, und der ist am >> Raumcontroller (RCxxx), oder? > > Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den > Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in > der die richtige Raumtemperatur enthalten ist. Die am RC30 abgelesene > Raumtemperatur habe ich schon in Hex umgerechnet und anschließend im Log > gesucht. Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe > ich einen Rechen/Denkfehler gemacht? 20.7°C = 207 auf dem EMS = 0x00 0xCF ... Wie kommst du auf 0x08 0x16?
:
Bearbeitet durch User
Martin Berger schrieb: > Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den > Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in > der die richtige Raumtemperatur enthalten ist. OK, dann war das ein Missverständnis. Hatte es so verstanden dass dort die richtige Raumtemperatur angezeigt wird. Aber immer nach einem bestimmten Telegramm eine falsche Raumtemperatur angezeigt wird. Martin Berger schrieb: > Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe > ich einen Rechen/Denkfehler gemacht? Das Beispiel sollte 0x00 0xcf sein, wie Danny schon geschrieben hat.
Danny Baumann schrieb: > 20.7°C = 207 auf dem EMS = 0x00 0xCF ... Wie kommst du auf 0x08 0x16? Ich habe nach 20,7°C = 2070 = 0x08 0x16 gesucht, das war Falsch. Das Repo was ich verwende haben hat Dateien mit dem Datum vom 18.12.2014, das ist das Repo von dir. ;-) Hier mal ein Aktuelles Telegramm mit der Falschen WWTemperatur: MESSAGE[28.01.2015 20:14:59]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x2d 0x01 0xfe 0x46 0x46 0x09 0x01 0x35 0x01 0x01 0x6b 0x83 0x00 0x80 0x00 0x02 0x0c 0xff 0x2d 0x48 0x00 0x00 0xff 0x00 0x10 0x01 0x44 DATA: Kessel-Solltemperatur = 45 °C DATA: Kessel-Isttemperatur = 51 °C DATA: Brenner-Sollwert Modulation = 70 % DATA: Brenner-Istwert Modulation = 70 % DATA: Flamme = AN DATA: Brenner = AN DATA: Zündung = AUS DATA: Kessel-Pumpe = AN DATA: 3-Wege-Ventil auf WW = AUS DATA: Zirkulation = AUS DATA: Warmwasser-Isttemperatur = -3200 °C DATA: Rücklauf-Isttemperatur = nicht verfügbar DATA: Flammenstrom = 52.4 µA DATA: Systemdruck = -0.1 bar DATA: Servicecode = -H DATA: Fehlercode = 0 Und hier das Telegramm mit einer richtigen WWTemperatur: MESSAGE[28.01.2015 20:13:14]: source 0x08, dest 0x00, type 0x34, offset 0, data: 0x0a 0x01 0x6b 0x83 0x00 0x00 0x00 0x00 0x03 0x00 0x00 0x62 0x8b 0x00 0x06 0x99 DATA: Warmwasser-Solltemperatur = 10 °C DATA: Warmwasser-Isttemperatur = 36.3 °C DATA: Warmwasser-Tagbetrieb = AUS DATA: Warmwasser-Einmalladung = AUS DATA: Warmwasser-Therm. Desinfektion = AUS DATA: WW-Bereitung = AUS DATA: Warmwasser-Nachladung = AUS DATA: WW-Temperatur OK = AUS DATA: Warmwasser-Fühler 1 defekt = AUS DATA: Warmwasser-Fühler 2 defekt = AUS DATA: Warmwasser-Störung = AUS DATA: Warmwasser-Störung Desinfektion = AUS DATA: Zirkulation-Tagbetrieb = AUS DATA: Zirkulation-Manueller Betrieb = AUS DATA: Zirkulation = AUS DATA: Warmwasser-Ladevorgang = AUS DATA: WW-System-Typ = groß DATA: Warmwasser-Durchflussmenge = 0 l/min DATA: WW-Bereitungszeit = 25227 min DATA: WW-Bereitungen = 1689 Und leider wird die DB mal mit der Richtigen und mal mit Falschen Temperatur beschrieben. Grüße Martin
Im Telegramm source 0x08, dest 0x00, type 0x34, offset 0 steckt die Wwtemperatur an Position 6 +7 -> 0x01 0x6d = 36,3 °C Im Telegramm source 0x08, dest 0x00, type 0x18, offset 0 steckt die Wwtemperatur an Position 14 + 15 -> 0x01 0x6d = 36,3 °C und im Wiki steht was von Position 16 + 17 Vielleicht ist da der Fehler, aber warum das nur bei mir auftritt, hmmm
Habe jetzt gerade mal bei mir nachgesehen und bei mir stimmt es zumindest. Im Wiki sind die Startadressen als Telegrammoffset angeben. Das wäre das Telegrammoffset+5. poste doch mal Deine Telegramme. Hier sind meine beiden Telgramme:
1 | Telegramm 0x18: 08 00 18 00 | 3f 02 22 64 3b 09 01 25 60 80 00 02 6f 01 e9 00 27 0c 2d 48 00 c8 ff 02 00 be |
2 | DatenOffset: -4 -3 -2 -1 | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
3 | TelegrammOffset: 1 2 3 4 | 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
4 | |
5 | 14-15: 0x8000 = Temperatur (DL-Erhitzer?) nicht vorhanden |
6 | 16-17: 0x026f =623 => 62,3°C Wassertemperatur |
7 | 18-19: 0x01e9 =489 -> 48,9°C Rücklauf Temperatur |
8 | |
9 | |
10 | Telegramm 0x34: 08 00 34 00 | 3c 02 6f 02 6f 21 00 00 03 ff 01 b9 e1 00 19 bf 2b |
11 | DatenOffset: -4 -3 -2 -1 | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
12 | TelegrammOffset: 1 2 3 4 | 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
13 | |
14 | 6 - 7: 0x026f =623 => 62,3°C Wassertemperatur |
Ingo F. schrieb: > Habe jetzt gerade mal bei mir nachgesehen und bei mir stimmt es > zumindest. > Im Wiki sind die Startadressen als Telegrammoffset angeben. Das wäre das > Telegrammoffset+5. > > poste doch mal Deine Telegramme. Hat er doch ;) In deiner Notation:
1 | Telegramm 0x18: 08 00 18 00 2d 01 fe 46 46 09 01 35 01 01 6b 83 00 80 00 02 0c ff 2d 48 00 00 ff 00 10 01 44 |
2 | DatenOffset: -4 -3 -2 -1 | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
3 | TelegrammOffset: 1 2 3 4 | 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
14-15: 0x016b = 363 => Temperatur (DL-Erhitzer?) 36,3°C 16-17: 0x8300 = -32000 => -3200°C Wassertemperatur 18-19: 0x8000 => Rücklauftemperatur nicht vorhanden Das Problem ist also, dass der Wassertemperaturwert gerade nicht 0x8000 ist. Ich bin mir allerdings nicht sicher, was die 'draufgeoderte' 0x300 zu bedeuten hat. In der Buderus-Doku, die ich habe, sind die Offsets 9 bis 12 leider nicht dokumentiert. Die einfachste Lösung wäre wahrscheinlich, diesen Wert einfach nicht mehr zu parsen, da ohnehin redundant.
Danny Baumann schrieb: > Hat er doch ;) Ups ...wie konnte ich das nur übersehen Danny Baumann schrieb: > Ich bin mir allerdings nicht sicher, was die 'draufgeoderte' > 0x300 zu bedeuten hat. Vielleicht noch eine Information warum der Wert nicht vorhanden ist? Also sozusagen eine Fehlermeldung?? Man könnte ja alles mit gesetztem höchstem Bit als nicht vorhanden bewerten. Oder zumindest unter -50°C(-500) z.B. Denke nicht dass die Außentemperatur soweit sinken wird.
:
Bearbeitet durch User
Ich habe keine Warmwasserbereitung (RC35, MC10). Bei mir taucht auch die 0x8300 auf. Hier der Debug-Output von meinem ESP-Interface...
1 | [ 694.808068 56.821 080 33] 08 00 18 00 3b 02 65 64 64 09 01 35 00 83 00 7d 00 80 00 02 09 ff 2d 48 00 00 ff 00 10 83 00 ? 3b:3b |
2 | [ 695.905880 96.991 080 33] 08 00 18 00 3b 02 66 64 64 09 01 35 00 83 00 7d 00 80 00 02 09 ff 2d 48 00 00 ff 00 10 83 00 ? c2:c2 |
Juergen O. schrieb: > Ich habe keine Warmwasserbereitung (RC35, MC10). Bei mir taucht auch die > 0x8300 auf. OK, ich schmeiß das Parsen dieses Wertes einfach raus. Wenn WW vorhanden ist, steht der Wert ja auch im WW-Monitor-Telegramm. Martin Berger schrieb: > Frontend Danny > Warmwasser Soll: 10°C an Stelle -> 45°C Ich hab ehrlich gesagt keine Ahnung, was dein UBA da macht. Byte 0 des WW-Monitor-Telegramms (0x34) ist (auch laut Buderus-Doku) die WW-Solltemperatur, und da steht bei dir 0xa = 10 drin. > Warmwasser Ist: -3200°C (hier wird Zeitweise der korrekte Wert > Angezeigt!?) Siehe oben :) > Außen gedämpft: keine Anzeige Die steht im Telegramm 0xa3 (gesendet vom RC30), welches bei dir - aus welchen Gründen auch immer - fehlt. > Raumtemp. IST: 3200°C Das muss ich nochmal verifizieren. Da steht 0x7d 0x00 drin, was laut Buderus-Doku ('Byte1 + (Byte2 * 256)') 12,5°C wäre (ganz schön kalt). Da der Algorithmus allerdings für alle Werte mit mehreren Bytes gleich ist, dürfte - wenn er falsch wäre - ja gar nix funktionieren. Ich werd mir das mal anschauen... EDIT: Passt schon. Die Doku definiert Offset 3 als Byte2 und Offset 4 als Byte1, d.h. 0x7d * 256 + 0 = 32000 -> 3200°C. Bei mir ist das z.B. 0x00 0xcb = 20.3°C. Ich habe wiederum keine Ahnung, was dein RC da macht...vielleicht ein Bug im RC30; bei mir haben sowohl RC30 als auch UBA V2.05. > Frontend Moosi zusätzlich > Die Regelart der Anlage wird als Raumtemperatur geführt erkannt, das ist > aber falsch, tatsächlich ist die Anlage Außentemperaturgefährt. Die > Heizkurve im Frontend wird deshalb nicht angezeigt. Der entsprechende Wert (Telegramm 0x3d, Offset 33) ist in deinen Telegrammen einfach nicht enthalten. Ich bin mir nicht sicher, was Moosy in diesem Fall macht. > Ich habe mal mit dem Collector ein Logfile erstellt, wäre für eine > Lösung und Unterstützung sehr Dankbar. Danke dafür. Ich habe darin noch gesehen, dass der Systemdruck nicht richtig ausgewertet wurde, das habe ich gleich mal mit gefixt.
:
Bearbeitet durch User
Danny Baumann schrieb: >> Warmwasser Soll: 10°C an Stelle -> 45°C 10°C stehen drin wenn kein Warmwasser bereitet werden soll. Die 10°C vermutlich nur wegen Frostschutz Danny Baumann schrieb: > Die steht im Telegramm 0xa3 (gesendet vom RC30), welches bei dir - aus > welchen Gründen auch immer - fehlt. Das hängt davon ab welches "Mauerwerk" man in der Heizung eingestellt hat. Das ist ja nur ein berechneter Wert. Es gibt auch irgendwo eine Einstellung dass Die Heizung automatisch vorher anspringt dass zur eingestellten Zeit auch die Temperatur vorhanden ist. Kann auch Sein dass es etwas mit der automatischen Sommerbetrieb zu tun hat. Mal nachsehen ob und auf welchen Wert das eingestellt ist. Danny Baumann schrieb: > Das muss ich nochmal verifizieren. Da steht 0x7d 0x00 drin Im Wiki hat irgendjemand eingetragen: Raumtemperatur Ist (0x7d00 für HK abgeschaltet)
:
Bearbeitet durch User
Ingo F. schrieb: > Im Wiki hat irgendjemand eingetragen: > Raumtemperatur Ist (0x7d00 für HK abgeschaltet) Hallo, wenn ich mich richtig erinnere habe ich diesen Eintrag geschrieben. Bei mir wird auch 0x7d00 angezeigt. Die RC30 ist bei mir am Brennwertgerät eingebaut, deswegen ist diese nicht mit dem Heizkreis verknüpft. @jschmied ich habe die Firmware geändert, nun werden die richtigen Werte über HTML empfangen. Kennt sich jemand mit Java-Script aus? Ich habe da keine Ahnung wie ich die Seite programmieren kann. Ich möchte die Parameter anklicken, welche ich ändern möchte.
:
Bearbeitet durch User
Hallo Franz, F. F. schrieb: > Kennt sich jemand mit Java-Script aus? Nö, nicht wirklich. ;) Aber ich glaube was Du suchst findet sich unter [1] oder [2]. Oder vielleicht [3]. Gruß aus der Wetterau Karl M. [1] http://de.wikipedia.org/wiki/XMLHttpRequest [2] http://wiki.selfhtml.org/wiki/JavaScript/API/XMLHttpRequest [3] http://api.jquery.com/jquery.get/
:
Bearbeitet durch User
F. F. schrieb: > @jschmied ich habe die Firmware geändert, nun werden die richtigen Werte > über HTML empfangen. > Kennt sich jemand mit Java-Script aus? Ich habe da keine Ahnung wie ich > die Seite programmieren kann. Ich möchte die Parameter anklicken, welche > ich ändern möchte. Das Schreiben über die JSON Schnittstelle ist bisher nicht richtig in der FW drin. Hab auch erstmal keine Zeit, weiterzumachen. vg Jürgen
jschmied schrieb: > Das Schreiben über die JSON Schnittstelle ist bisher nicht richtig in > der FW drin Die Firmware habe ich soweit geändert, sie funktioniert. Nur mit Html und Java-Script kenne ich mich nicht aus. Ich lade demnächst meine aktuelle Version hoch. Viele Grüße Franz
With great help of Danny and Ingo I now got the ems-ethersex-netio running, the basic issue was that I was using a 644 i.s.o. 644P w/o second UART, so all others where okay, but the system was dead. I also follwed the http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io" to setup a BananaPI environment for the collector, MySQL, Lighttpd, etc.... When I run the command "collectord -u ems -p geheim -f -d all tcp:192.168.xxx.xxx:7950" I see indeed the EMS messages tanzen auf das schirm. I tried to make the required init and default setting in order to run from booting. But I'm notsure the collectord is really running and putting data in a MySQL database. I tried to telnet from my Windows-7 PC "telnet 192.168.1.6 7777" but the system answers there is no connection to the host on this port. I tried root> collectord status, I get no error message nor a reaction. How to check that the Collectord is really capturing messages and storing them in MySQL ? Thanks Maarten
Hello Maarten, Maarten H schrieb: > ... the collectord is really running and putting data in a > MySQL database ... from your Bananas console, please try: root@banana: top you see all active processes. There schould be "collectord" and "mysqld". if "mysqld" exists, try next command: root@banana: mysqld -u "databasename" -p now enter your password, you'll get the mysql-console: at mysql> enter: use ems_data; show tables; you should see the tables structure of your db now enter: select * from numeric_data if there is data, you're fine. if not, check databases sanity. to quit mysql, insert "exit". > ... telnet 192.168.1.6 7777 ... afaik telnet only works on localhost. so, from your bananas console try: root@banana: telnet localhost 7777 if the collectord is running correctly, you should see some lines, now try: "help" and have fun. hth'n greets Karl M.
:
Bearbeitet durch User
Hallo Franz, F. F. schrieb: > Ich möchte die Parameter anklicken, welche ich ändern möchte. Du kennst Moosys Frontend?! https://github.com/moosy Gruß in die Berge! ;-) Karl M.
Maarten H schrieb: > But I'm notsure the collectord is really running and putting data in a > MySQL database. I tried to telnet from my Windows-7 PC "telnet > 192.168.1.6 7777" but the system answers there is no connection to the > host on this port. For that, you need to pass the parameter '-C 7777'. > How to check that the Collectord is really capturing messages and > storing them in MySQL ? There are a couple of options: - ps, as mentioned by Karl - let the daemon log into a file and check that file for new entries: '-d all=foo.log' - check the database contents ;)
Dear Karl, With "top" I see mysql, but not collectord top When I run the mysqld I get: bananapi@maarten ~ $ mysqld -u ems -p 150130 21:22:34 [Warning] Using unique option prefix key_buffer instead of key_b uffer_size is deprecated and will be removed in a future release. Please use the full name instead. 150130 21:22:34 [Warning] Ignoring user change to 'ems' because the user was set to 'mysql' earlier on the command line 150130 21:22:34 [Warning] Can't create test file /var/lib/mysql/maarten.lower-te st 150130 21:22:34 [Warning] Can't create test file /var/lib/mysql/maarten.lower-te st mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13) 150130 21:22:34 [ERROR] Aborting 150130 21:22:34 [Note] mysqld: Shutdown complete bananapi@maarten ~ $ collectord -h was still working So first I should get collectord running from booting I see: bananapi@maarten /etc/init.d $ ls -l ems-collector -rwxr-xr-x 1 root root 1883 Jan 29 22:07 ems-collector In this file: PROGNAME="collectord" PROG="/usr/local/sbin/$PROGNAME" DESCR="EMS collector daemon" Collectord is in this directory: bananapi@maarten /usr/local/sbin $ ls -l collectord -rwxr-xr-x 1 root staff 791487 Jan 30 21:38 collectord The default: bananapi@maarten /etc/default $ ls -l ems-collector -rw-r--r-- 1 root root 339 Jan 29 22:25 ems-collector So concluding: I get the impression collectord is not running from booting Many thanks Maarten
Hi again, > Ignoring user change to 'ems' because the user > was set to 'mysql' earlier on the command line You added user "ems" to the db? Please check: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#mysql_benutzer_anlegen > /etc/default/ems-collector what is the content of that file? You'll get it running! :-) Greets Karl M.
Hi Karl, Thanks for helping, I indeed really hope to get it working!!!! Yes as I made the change to the db, in fact I copied the log: bananapi@maarten ~ $ sudo mysql -u root -p Enter password:pa0mhe Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 45 Server version: 5.5.40-0+wheezy1 (Debian) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select password('my_PW'); +-------------------------------------------+ | password('my_PW') | +-------------------------------------------+ | *FAA663E23C9CA3A6918059359F95422DC1FA61DA | +-------------------------------------------+ 1 row in set (0.00 sec) mysql> create user ems identified by password '*FAA663E23C9CA3A6918059359F95422DC1FA61Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) mysql> GRANT ALL ON ems_data.* TO 'ems'@'%'; Query OK, 0 rows affected (0.00 sec) Content of "/etc/default/ems-collector" # Defaults file for EMS collector daemon # This is a POSIX shell fragment # config file location CONFIGFILE="/etc/ems-collector.conf" # Serial device file SERIALDEVICE="/dev/ttyUSB0" # Where to put the PID file PIDFILE="/var/run/ems-collector.pid" # Other options OPTIONS="-C 7777 -D 7778 -u ems -p my_PW -r 60 tcp:192.168.1.5:7950" Thanks again a lot Maarten
Hi Maarten; > # config file location > CONFIGFILE="/etc/ems-collector.conf" you may comment out this last line. All config is done within here. > # Serial device file > SERIALDEVICE="/dev/ttyUSB0" you have to comment out last line, cause you're talking tcp. > tcp:192.168.1.5:7950 912.168.1.5 is the ip of your netio with ethersex?! Restart the collectord and have a look at your db, whether or not all is working and showing tables and data. Yes, you'll succeed! Greets to Belgium Karl M.
:
Bearbeitet durch User
Karl M. W. schrieb: > Du kennst Moosys Frontend?! > https://github.com/moosy Danke, Karl diese Seite kannte ich noch nicht. Ich weiß aber nicht, in wieweit dies mit meiner Firmware (JSON) zusammenpaßt. viele Grüße an die Wetterau, bin morgen wieder da. :-) Franz
Hallo Franz, > Ich weiß aber nicht, in > wieweit dies mit meiner Firmware (JSON) zusammenpaßt. Falls ich Jürgen richtig verstanden habe, sollte das funken! Aus dem Wiki:
1 | N.b.: Selbst Ingos EMS-GW kann mit der Firmware 2.1.1 |
2 | und einem ENC28J60 Netzwerkmodul verwendet werden. |
3 | So kann man auch über das EMS-GW das neue Frontend |
4 | von Moosy benutzen. |
Gute Reise und genieße die gesunde Luft in Bad Nauheim! Gruß Karl M.
Dear Karl and Danny, Yes indeed my ethersex AVR is at 192.168.1.5:7950 collectord -u ems -p "My_PW" -f -d all tcp:192.168.1.5:7950 runs fine I can see the EMS messages in this case. etc/default/ems-collector: # config file location # CONFIGFILE="/etc/ems-collector.conf" # Serial device file # SERIALDEVICE="/dev/ttyUSB0" I gave a Reboot, I cheked with >top but nothing present from collectord, also not with telnet. I tried to start collectord: bananapi@maarten ~ $ collectord start Exception: Cannot open pidfile '/var/run/collectord.pid': Permission denied bananapi@maarten ~ $ sudo collectord start [sudo] password for bananapi: Exception: Access denied for user 'root'@'localhost' (using password: NO) The I tried to check the db: bananapi@maarten ~ $ mysqld -u ems -p 150131 12:50:32 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 150131 12:50:32 [Warning] Ignoring user change to 'ems' because the user was set to 'mysql' earlier on the command line 150131 12:50:32 [Warning] Can't create test file /var/lib/mysql/maarten.lower-test 150131 12:50:32 [Warning] Can't create test file /var/lib/mysql/maarten.lower-test mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13) 150131 12:50:32 [ERROR] Aborting 150131 12:50:32 [Note] mysqld: Shutdown complete "My concluding": collectord: is not starting, perhaps someting wrong with users and permissions ?, I'm surely not very experienced with Linux. mysqld: is started but still having problems. Thanks a lot both (Karl, Danny) for your support, Maarten
Hi again Maarten,
> Cannot open pidfile '/var/run/collectord.pid': Permission
Name and path of the Pidfile in the /etc/default/ems-collector must be
the same as the existing file. E.g.:
1 | root@home:~# ls -l /var/run/ems-collector.pid |
2 | -rw-r--r-- 1 root root 4 Jan 31 14:44 /var/run/ems-collector.pid |
> bananapi@maarten ~ $ mysqld -u ems -p
Sorry, sorry, sorry, my mistake!
It has to be:
bananapi@maarten ~ $ mysql -u ems -p
Give 'em a new chance! ;-)
Readya
Karl M.
Ich bekomme jetzt die immer die richtige WW Temperatur angezeigt. Vielen Dank Danny für die Änderung am Collector. ;-) Die Warmwassersolltemperatur +45°C wird nur während dem Normalbetrieb Angezeigt im Reduziertenbetrieb wird die +10°C Angezeigt, somit ist das in Ordnung. Im HK1 habe ich die Fernbedienung von „Keine“ auf „RC30“ umgestellt, seitdem bekomme ich eine Raumtemperatur (vom Heizraum) angezeigt. Jetzt ist auf dem EMS-Bus auch erheblich mehr Betrieb. Allerdings hat sich auch das Verhalten meiner Heizanlage geändert, den Raumeinfluss musste ich von +3K auf 0K ändern und meine Heizkurve durfte ich wiederherstellen. :-P Fehlt ein Fühler, wird bei meiner Anlage mit 0x8300 oder mit 0x8000 dargestellt. Abgastemperatur , Warmwasser Temperatur Ist 2. Fühler etc. bei meiner Anlage mit 0x8300. Telegramm 0x19 TelegrammOffset:18(Dataoffset13) = Betriebszeit komplett = Betriebszeit 1 (bzw. bei meinem 2-Stufenbrenner die Betriebszeit der 2 Stufe). Telegramm 0x19 TelegrammOffset:21(Dataoffset16) mit 3 Bytes ist die Betriebszeit 2 (bei meinem 2-Stufenbrenner die Betriebszeit der 1 Stufe). ← Das wäre doch was fürs Wiki und dem Collector ;-) Telegramm 0x3d geht bei meiner Anlage nur bis TelegrammOffset:32(Dataoffset27) und somit gibt es auch keine Führungsgröße, maximale Vorlauftemperatur etc. was im Mosys-Frontend „Erweiterte Einstellungen“ verwendet wird. Telegramm 0xa3 mit der gedämpften Außentemperatur habe ich noch nicht gesichtet, dafür ein paar andere Telegramme wie 0x20 etc. die im Wiki keine Erwählung finden und zum Teil leer oder mit 0x00 gefüllt sind
Dear Karl, ems-collector.pid file: Understood, but how to locate this file ? It is not in /var/run bananapi@maarten /var/run $ find ems-collector.pid find: `ems-collector.pid': No such file or directory mysql, I re-tried: bananapi@maarten ~ $ mysql -u ems -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 42 Server version: 5.5.41-0+wheezy1 (Debian) Copyright (c) 2000, 2014, Oracle . All rights reserved. Oracle is a registered trademark of Oracle Corporation Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> use ems_data Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables -> * -> \q Not sure, but I don't think this was the right feedback from the db ? Thanks again Maarten
Dear Karl, I did the experiments you suggested: bananapi@maarten ~ $sudo touch /var/run/collectord.pid bananapi@maarten ~ $ service ems-collector restart [warn] Stopping EMS collector daemon: collectord already stopped (warning). [....] Starting EMS collector daemon: collectordterminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info _injector<boost::program_options::invalid_command_line_syntax> >' what(): required parameter is missing in 'config-file' Aborted failed! bananapi@maarten ~ $ Something wrong with the config-file ? # Defaults file for EMS collector daemon # This is a POSIX shell fragment # config file location #CONFIGFILE="/etc/ems-collector.conf" # Serial device file # SERIALDEVICE="/dev/ttyUSB0" # Where to put the PID file PIDFILE="/var/run/ems-collector.pid" # Other options OPTIONS="-C 7777 -D 7778 -u ems -p xxxxx -r 60 tcp:192.168.1.5:7950" Thanks again Maarten-
Dear All, With help of Ingo, Danny and Karl I made big steps forward. Now the ems-collector service is running and the MySQL db filled. I can Telnet and see the db. Also the lighttpd webserver is running standalone and I can read the default php "Hello world" page. Next I hope to setup Danny's Webpage. I loaded the "webpage" files into /var/www, however I'm missing and index.php file ? Is there somewhere an Install procedure available ? Thanks in advance and Best regards Maarten
Maarten H schrieb: > Next I hope to setup Danny's Webpage. I loaded the "webpage" files into > /var/www, however I'm missing and index.php file ? > Is there somewhere an Install procedure available ? There is no index.php in my pages. I reference them directly and usually use status.php as entry point. Symlinking status.php to index.php probably also works.
Hi Danny, Thanks, I copied all your webpage files intor /var/www I renamed status.php into index.php. When I access the webpage with my Firefox browser I get a complete "light blue" page, and with IE an error HTTP 500 internal server error. Thanks Maarten
Hi Maarten, > "light blue" page, and with IE an error HTTP 500 internal server error. You know this page: http://www.penguintutor.com/linux/light-webserver hth'n greets Karl M.
Hi Karl, > You know this page: > http://www.penguintutor.com/linux/light-webserver Yes indeed I followed this very good tutorial, including the PHP setup, and testpage they gave. This worked fine. But with Danny's page it is going wrong, I think perhaps that I should not Copy the files to /var/www but somewhere else ? I also tried to make a symlink : ls -l /home/bananapi/ems-collector-master/webpage/status.php But also w/o success. The "light blue" pages is titled "Heizung" and when I look to source in my browser it is Danny's status.php Best regards Maarten
Maarten H schrieb: > But with Danny's page it is going wrong, I think perhaps that I should > not Copy the files to /var/www but somewhere else? No, the fact that you can access the page shows it's in the correct place. > The "light blue" pages is titled "Heizung" and when I look to source in > my browser it is Danny's status.php This sounds like there's some issue with the php interpreter. The web server should do an error log (e.g. for apache it's in /var/log/apache2/error.log) that should give an idea of what exactly is wrong.
ReHi Maarten,
> ... PHP setup and testpage ...
PHP is working?!
Tried the typical test.php?
---snip---
<html>
<head>
<title> PHP Test Script </title>
</head>
<body>
<?php
phpinfo( );
?>
</body>
</html>
---snap---
What's about the rights for the webserver files, are they set to
"www-data"?
Greets to Vlaanderen
Karl M.
Hi Karl, Yes I followed exactly the in the penguingtutor metioned file rights, ad this gave no errors, also "your" testpage is working see attachment. Maarten
Hi Maarten, ok, php is working! As Danny told, what is "/var/log/lighttpd/error.log" saying? Groetjes Karl M.
Hi Karl, I captured the following from the error.log 2015-02-02 21:16:15: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal error: Uncaug$ Stack trace: #0 /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc(6): PDO->__con$ #1 /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc(24): open_db() #2 /home/bananapi/ems-collector-master/webpage/index.php(27): get_current_sensor_v$ #3 {main} thrown in /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc on li$ Thanks again Maarten
Hi Maarten,
> /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc
seems, your www files are not in the www-directory??
But sorry for rest of this evening, got an old mate over here.
Some beers are waiting. ;~)
Readya
Karl M.
Hi Karl, Prosit. All Danny's webpage files are both in /var/www and in /home/bananapi/emc-collector-master/webpage And I have a symlink from /var/www/index.php to /var/www/status.php Bye, Maarten
Danny, Karl, What I see in the Errorlog is that "sensor_utils.php.inc" can't access the "ems_data" db in MySQL. When I do the manual: mysql> use ems_data; mysql> show tables; mysql> select * from numeric_data; It works, any idea what could be wrong ? Best regards Maarten
Hi Maarten, > "sensor_utils.php.inc" can't access > the "ems_data" db in MySQL. File rights?? Please show the first 10 rows of "sensor_utils.php.inc" Readya Karl M.
Hi Karl, Beginning my "sensor_utils.php.inc" file <?php include 'constants.php.inc'; function open_db() { return new PDO('mysql:dbname=ems_data;host=localhost', 'emsdata', 'emsdata'); } function format_value($row) { $value = (float) $row->value; if ($row->reading_type == ReadingTypeTime && $row->unit == "min") { $hours = (int) floor($value / 60); $mins = (int) ($value - 60 * $hours); if ($hours > 0) { return sprintf("%dh %dmin", $hours, $mins); } } I was thinking: Can it be something with file permissions ?, I see the "owner" of the db is "mysql" , this is logic, but can the php access this ? Best regards Maarten
The last 2 parameters of the 'new PDO...' line are the DB user name and password. Do those match what you've set up?
Hi Maarten, > return new PDO('mysql:dbname=ems_data;host=localhost', > 'emsdata','emsdata'); first 'emsdata' is 'your_dbuser', second 'emsdata' 'your_dbpass'. hth'n greets Karl M. * Danny ist deutlich schneller! ;-)
:
Bearbeitet durch User
Hi Karl, News from Vlaanderen, however Still not there Error.log lighttpd: 2015-02-04 22:19:35: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal error: Unc$ Stack trace: #0 /srv/www/sensor_utils.php.inc(6): PDO->__construct('mysql:dbname=em...', 'em$ #1 /srv/www/sensor_utils.php.inc(24): open_db() #2 /srv/www/status.php(27): get_current_sensor_values() #3 {main} thrown in /srv/www/sensor_utils.php.inc on line 6 2015-02-04 22:19:41: (server.c.1558) server stopped by UID = 0 PID = 3262 My line (6) ensor_utils.php.inc: return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 'my_pwd'); Best regards Maarten
... sorry, no idea at the moment. (Danny?) Will you show rows 4 to 8 again, please.
Hi Karl, Here sensor_utils.php.inc line 4..8 function open_db() { return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 'my_pwd'); } I was not aware this modification of adding user and pw, is there anywhere a install procedure of this webpage, as I perhaps miss also other settings. Best regards Maarten
Hi Maarten, > Here sensor_utils.php.inc line 4..8 seems perfect! > is there a install procedure of this webpage Know none. Perhaps you will (have to) go the hard way through all files and check all the stuff. Readya Karl M.
Hi Karl, I gave up on the old image and decided to start with a new, completely fresh setting_up everthing, and...... it is working, I can read Danny's webpage, still not with graphs, but that is for later. my Buderus setup is: MC10 / UBA Brenner (ol type) (We have here no gas close to my home) BC10 RC35 Warmwater boiler Now I noticed a few strange items: The "warmwasser IST" temperature is mostly indicated as 3200.0C, sometimes I get the right temperature, I see the system uses: source 0x08 type 0x18 offset 16, this is indeed 3200, but only in source 0x08 type 0x34 offset 6 is the right warmwater actual temperature. Is this easy to change ? My system also measures the "abgastemperature", I can see this on my RC35, but not on in the MySQL data, this is transmitted in source 0x08 type 0x19, this message is also used for other information presented in the webpage, is this possible to add ? I added a log file from my collectord Do you have an idea? Best regards Maarten
Maarten H schrieb: > The "warmwasser IST" temperature is mostly indicated as 3200.0C, > sometimes I get the right temperature, I see the system uses: source > 0x08 type 0x18 offset 16, this is indeed 3200, but only in source 0x08 > type 0x34 offset 6 is the right warmwater actual temperature. Is this > easy to change ? Yes. It's so easy that I actually already did it, see a few posts above. If you're using my repo, try a git pull, otherwise try using my repo. :) > > My system also measures the "abgastemperature", I can see this on my > RC35, but not on in the MySQL data, this is transmitted in source 0x08 > type 0x19, this message is also used for other information presented in > the webpage, is this possible to add ? Yes, sure. I'll add it.
Hi Danny, Very nice, I was very bussy with getting the basics running, so I didn't look carefully to other posts. I will upload your latest repo tomorrow. As you can understand I'm very happy that it is finally running, now I can enjoy the nice work you and your friends created. Short question: to get the graphs running, I see the phyton file "ems-gen-graphs.py", and I also see in "day.php" the graph's are called, but what to do with the phyton file ?, how to execute it ? where and when ? Thanks a lot Maarten
Hallo Danny, ich habe keinen Raspi und würde gerne den collectord auf meiner Synology Diskstation laufen lassen. Ich hatte mir gedacht meinen EMS-Gateway als Verbindung zwischen EMS-Bus und Diskstation zu nehmen. Also benötige ich wohl den Framer nicht, oder? der läuft ja dann auf dem NetIO?! Meine erste Frage richtet sich erst mal an die Boost-Bibliothek. WO kann man die Quellen dazu finden? Denke ja dass ich die dann auch noch erst kompilieren muss. Weitere Bibliotheken hast Du ja nicht verwendet, oder? Habe mal versucht eine einzelne Datei zu kompilieren. Die Datei mit den wenigsten importen scheint EmsMessage.cpp zu sein. Aber es hagelt nur Fehler.... Fängt scho mit "EmsMessage.cpp:25:28: error: boost/format.hpp: No such file or directory" an. Darf ich Dich eventuell mal per Mail "belästigen"? Gruß Ingo Edit: hänge einfach mal das ergebnis des ersten kompilier Versuch an....
:
Bearbeitet durch User
Hallo Ingo, du scheinst nicht alle Abhängigkeiten z.B. libboost-all-dev installiert zu haben. Gruss Norbert
Hallo Norbert, inzwischen bin ich schon etwas weiter. Boost konnte ich über ipkg nachinstallieren (boost-iostreams) Das Problem sind jetzt MySQL++-Imports. MySQL++ gibt es nicht in IPKG für die Diskstation. Habe mal versucht die Sourcen für den C++Connector herunterzuladen und zu kompilieren. Bekomme es aber irgendwie nicht hin. make hat keine Lust weil es wohl keine Makefiles gibt. Oder zumindest nur welche für CMake?! Gruß Ingo Edit: CMake ist wohl eher für CrossCompiling. Es muss wohl auch irgendwie mit Make gehen, habe aber keinen blassen schimmer. Google konnte mir aber noch nicht weiterhelfen
:
Bearbeitet durch User
Hi Danny, In the mean time I have the graphs --> GREAT Thanks a lot Maarten
Irgendwie komme ich nicht weiter beim kompilieren des mySQL Connector C++ Alle anderen Bibliotheken scheint es wohl zu geben nur nicht den "MySQL-Connector-C++" Den collectord würde ich bestimmt kompiliert bekommen. Das Bibliotheken-kompilieren scheint meinen Horizont zu übersteigen. Ergebnis zwei komplette Tage umsonst. Denke es wird wohl besser sein die Idee für ein paar Jahre zurückzustellen oder die Idee ganz zu begraben. Gruß Ingo
:
Bearbeitet durch User
Hallo Ingo, ich finde die Idee mit der Synology als collectod ganz smart und habe auch schon mit dem Gedanken gespielt, diesen für die Syno zu bauen. Welches Synology-Modell hast du denn?
Habe die DS212+ und DS415+. Das kompilieren klappt auf beiden erst mal ganz gut. Natürlich hagelt es Fehlermeldungen, Aber der größte Teil wird weg sein wenn die MySQLConnector-Bibliotheken erst mal da sein sollte. Gruß Ingo
Hab' noch ne paar Fragen zum EMS-Protokol... ACK (01 BRK) und NACK (04 BRK) - werden diese nur für die Datensätze des PC-Modules (0x0B) generiert? Ich konnte keine diesbezüglichen Msgs in meinen Logs finden - byteweises Versenden mit Echo vom Master Gilt dies auch ausschließlich für das PC-Modul? Meine Logs hier (0x08, 0x09, 0x10) zeigen kein derartiges Verhalten - Wie unterscheide ich (theoretisch) den Poll-Response eines RS232-Gateways (0x04) und einem NACK? Gateway (NETIO, PIC) Werden ACK und NACK an den collectord durchgereicht oder vom Gateway behandelt? (Bspw. Resend bei NACK) Wie werden Framing Errors bzw Collisions vom Gateway (PIC, NETIO) behandelt, wenn Daten zu senden sind? Datensatz nach Timeout nochmal versenden? Auf NACK vom Master warten? Oder einfach den Versuch "vergessen"? Uhrzeit/Datum Kann die Uhrzeit der RCxx jetzt gesetzt werden bzw. sind die Telegramme des Zeitmodules bekannt? Wiki... Anscheinend ist in der Erklärung der RCTempMessage etwas falsch - oder meine Heizung macht was anders...
1 | 10 00 a3 00 07 01 00 01 3a 01 40 01 40 83 00 83 00 ? ee:ee |
Die "gedämpfte Außentemperatur" ist im Wiki als 2-Byte Wert beschrieben. Das würde sich jedoch auf die Endianess der Temperaturen ab Pos. 8 auswirken...
Juergen O. schrieb: > Hab' noch ne paar Fragen zum EMS-Protokol... > ACK (01 BRK) und NACK (04 BRK) NACK un ACK werden nur auf Nachrichten gesendet die Werte verändern. Bei Abfragen (MSB von Zieladresse gesetzt) oder bei Telegrammen an Alle Ziel 0x00) werden diese auch nicht gesendet. Juergen O. schrieb: > Gilt dies auch ausschließlich für das PC-Modul? Das betrifft eigentlich alle Telegramme. Juergen O. schrieb: > Werden ACK und NACK an den collectord durchgereicht oder vom Gateway > behandelt? Beim EMS-Gateway werden diese einfach weitergeleitet. Weiss jetzt nicht mehr ob ein automatisches Resend kommt. Bin mir relativ sicher dass das nicht passiert. Juergen O. schrieb: > Uhrzeit/Datum > Kann die Uhrzeit der RCxx jetzt gesetzt werden bzw. sind die Telegramme > des Zeitmodules bekannt? Das Telegramm 0x06 von der RCxxx ist ja bekannt. Habe mal versucht einen Wert zu ändern (Wochentag) Kann aber auch daran liegen dass der Wochentag ja eigentlich schon durch das Datum vorgegeben wurde und deswegen nicht geändert wurde. Vielleicht liegt es ja auch daran dass das komplette Telegramm gesendet werden muss. Denke schon dass sich Zeit und Datum ändern lassen.
Juergen O. schrieb: > - byteweises Versenden mit Echo vom Master > Gilt dies auch ausschließlich für das PC-Modul? Meine Logs hier > (0x08, 0x09, 0x10) zeigen kein derartiges Verhalten 0x08 ist übrigens der Master ;) Ansonsten gilt, das was Du in Deinen Logs siehst, sind Echos des Masters. TX der Module siehst Du nicht, da sie über die Strom-Schnittstelle laufen. Juergen O. schrieb: > - Wie unterscheide ich (theoretisch) den Poll-Response eines > RS232-Gateways (0x04) und einem NACK? Einem Poll-Response geht ein Poll-Request vorraus, einem NACK ein Set-Telegramm ;) Juergen O. schrieb: > Die "gedämpfte Außentemperatur" ist im Wiki als 2-Byte Wert > beschrieben. Das müsste korrigiert werden. Gedämpfte AT ist signed 8Bit. Ein größerer Wertebereich macht keinen Sinn, da ganzzahliger Wert ohne Dezimalstelle. //Niffko
Niffko _ schrieb: > Das müsste korrigiert werden. Gedämpfte AT ist signed 8Bit. Ein größerer > Wertebereich macht keinen Sinn, da ganzzahliger Wert ohne Dezimalstelle. Habe das jetzt geändert. Das Offset müsste ja richtig sein... Wegen dem Diskstation collectord habe ich mal meine bisherigen Versuche als "Anleitung" im Wiki abgelegt. Tipps dazu am besten per mail oder PN. Dieses Thema hat ja nicht direkt was mit diesem Thread zu tun...
:
Bearbeitet durch User
Stimmt noch nicht ganz... da die gedämpfte Außentemp nur 1Byte hat, rutschen die folgenden Einträge alle um eine Position nach vorne:
1 | ... |
2 | 10 00 A3 6 0 1 1 2 °C Flag 1 |
3 | 10 00 A3 7 0 1 1 2 °C Flag 2 |
4 | 10 00 A3 8 0 2 10 2 °C Raum-Ist |
5 | 10 00 A3 10 0 2 10 2 °C Temperatur 1 |
6 | 10 00 A3 12 0 2 10 2 °C Temperatur 2 |
7 | 10 00 A3 14 0 2 ? 2 ? Sensor ? |
8 | 10 00 A3 16 0 2 ? 2 ? Sensor ? |
Die letzten beiden Sensoren sind bei mir nicht angeklemmt und demzufolge "83 00".
Juergen O. schrieb: > Gateway (NETIO, PIC) > Werden ACK und NACK an den collectord durchgereicht oder vom Gateway > behandelt? (Bspw. Resend bei NACK) Mein ethersex-Code reicht die durch, indem er daraus ein Telegramm zusammenbastelt. Aus 0x04 wird '<source> 0x0b 0xff 0x04', so dass die normale Paketauswertungslogik darauf anspringen kann und erkennt, dass es eine Antwort an den 'PC' ist. Der Collector sendet daraufhin eine entsprechende Antwort in den Socket (CommandHandler.cpp, Zeile 1126). > Wie werden Framing Errors bzw Collisions vom Gateway (PIC, NETIO) > behandelt, wenn Daten zu senden sind? Datensatz nach Timeout nochmal > versenden? Auf NACK vom Master warten? Oder einfach den Versuch > "vergessen"? Wie sollen die Collisions denn passieren? Es wird doch immer nur nach expliziter Aufforderung durch den Master gesendet.
Juergen O. schrieb: > Uhrzeit/Datum > Kann die Uhrzeit der RCxx jetzt gesetzt werden bzw. sind die Telegramme > des Zeitmodules bekannt? Die Uhrzeit habe ich schon einmal gestellt, das funktioniert. IngoF schrieb: > Das Telegramm 0x06 von der RCxxx ist ja bekannt
Juergen O. schrieb: > 10 00 A3 14 0 2 ? 2 ? Sensor ? > 10 00 A3 16 0 2 ? 2 ? Sensor ? > Die letzten beiden Sensoren sind bei mir nicht angeklemmt und demzufolge > "83 00". Die waren im Wiki noch nicht drin... Kann auch sein dass die je nach Softwareversion nicht vorhanden sind... Gruß Ingo
Hi, der EMS-Collector läuft nach erneutem Kompilieren wunderbar, (musste die erstellte executable noch in den sbin ordner kopieren damit die gefunden wird). Das PHP Interface macht mir aber kopfzerbrechen. Egal was ich aufrufe auf der Hauptseite der Heizungssteuerung ich bekomme keine Daten. Egal ob Protokoll, Statistik usw. Wenn ich den Livestatus anklicke erscheint nur der LAdebalken und bleibt bei 10% stehen. Ich vermute ein Rechteproblem der php dateien oder ein Problem mit der mysql database. Hat jemand einen Tip wie ich den Fehler rausfinden könnte? Grüße Roland
Hi Roland,
> ... Fehler rausfinden ...
1. Mal unter "/var/log/lighttpd(bzw. apache2)/error.log" nachschauen.
2. Im *.php script spionieren, was hinter der 10%-Marke des Ladebalkens
"gefährliches" kommt.
3. Ggf. Pfade anpassen, Rechte setzen (www-data).
hth'n greets
Karl M.
@charlie-w, danke das probier ich mal. Habe grade indie Logdatei geschaut, es sieht so aus wie wenn dem Apache ne datei fehlt die in den phpskripten aufgerufen wird. Da werd ich mal in die Skripte reinschauen....
Roland, Did you check sensor_utils.phh.inc line 6 ? return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 'yourpwd'); Maarten
Hallo Danny, Nach meinen ganzen vergeblichen compile und Crosscompile-Versuchen für die Diskstation brauchte ich dringend eine Erfolgserlebnis. Also habe ich den collectorD auf einem Laptop kompiliert und installiert. Die website-Dateien habe ich in den Apache-WWW-Ordner gepackt. Einen symbolischen link auf Status.php habe ich angelegt und die IP-Adresse inkl. Benutzernamen und Passwort in der *sensor_utils.php.inc* geändert. Jetzt bekomme ich die Status.php angezeigt mit allen aktuellen Daten. Allerding ist unten auf der Übersicht Tag/3Tage/Woche/Monat unten nur unter der Überschrift Graphen. die Wörter für die Entwicklung Temperaturen *Außen/Raum/Kessel/Warmwasser* Das ist kein Link. Ist das OK so, oder sollten dort die Temperaturkurven oder ein Link dorthin angezeigt werden? Muss noch irgendwo was eingestellt sein oder habe ich eventuell eine bibliothek oder ähnliches vergessen?
:
Bearbeitet durch User
Ingo F. schrieb: > Ist das OK so, oder sollten dort die Temperaturkurven oder ein Link > dorthin angezeigt werden? Die Kurven sollten angezeigt werden. Ich lasse dafür regelmäßig (via cron) gnuplot Bilder malen. Meine crontab ist hier: https://gist.github.com/maniac103/8486528 (Pfade musst du natürlich anpassen: /var/tmp/heizung entspricht bei mir <webpageroot>/graphs). Das Python-Skript liegt mit im Collector-Repo. Ich wollte das schon ewig mal auf clientseitiges Malen via flot o.Ä. umstellen, aber mir fehlt die Zeit :-/
Hi, Ihr Zwei, Danny Baumann schrieb: > clientseitiges Malen via flot o.Ä. schon mal bei Highcharts/Highstock vorbeigeschaut?! http://www.highcharts.com/stock/demo Tim Kang zeigt auf seiner Seite ein paar nette Beispiele, wie man Daten aus mysql holt und als skalierbare Grafik mit Highcharts/stock darstellt. http://blueflame-software.com/blog/column-chart-with-data-from-mysql-using-highcharts/ Gruß aus der frühlingshaften Wetterau Karl M.
Karl M. W. schrieb: > Hi, Ihr Zwei, > > Danny Baumann schrieb: >> clientseitiges Malen via flot o.Ä. > > schon mal bei Highcharts/Highstock vorbeigeschaut?! > http://www.highcharts.com/stock/demo > > Tim Kang zeigt auf seiner Seite ein paar nette Beispiele, wie man Daten > aus mysql holt und als skalierbare Grafik mit Highcharts/stock > darstellt. > http://blueflame-software.com/blog/column-chart-with-data-from-mysql-using-highcharts/ Naja, flot ist ja durchaus ähnlich: http://www.flotcharts.org/ Das Problem ist - v.a. bei Wochen- und Monatsansicht - die Menge der Daten: Bei einem Datensatz pro 2 Minuten kommen in einem Monat schon mal ~20k Datensätze pro Sensor zusammen. Das noch multipliziert mit 4 oder 5 Sensoren machen den JSON-Blob riesig. Man müsste sich an der Stelle mal Gedanken über ein sinnvolles Datenbankschema machen, das die Daten schon zusammengefasst vorhält (z.B. in Stundenintervallen), aber das ist Aufwand...
Danny Baumann schrieb: > Bei einem Datensatz pro 2 Minuten kommen in einem Monat schon mal > ~20k Datensätze pro Sensor zusammen Es gibt ja mehrere Möglichkeiten Daten zu reduzieren. Aber einen stündlicher Mittelwert wäre eigentlich einegute Idee. Dann noch mal ein paar errechnete Mittelwerte oder Summen für einen Tag speichern. Notfalls könnte man auch nur jeden x.ten Wert nehmen. Bei 20000 Datenwerten einfach jeden 10 Wert nehmen und den Rest ignorieren. Vielleicht könnte man ja auch pro Kurve einen Zähler einbauen der für jede Kurve einzeln hochzählt (8 oder 16 Bit). Dann könnte man z.B alle Werte rausfiltern die z.B. nur einen durch 10 teilbaren Wert im Zähler haben. Dann müsste die nicht aus der MySQL übertragen werden und können dort schon rausgefiltert werden. Gruß Ingo
Ingo F. schrieb: > Aber einen stündlicher Mittelwert wäre eigentlich eine gute Idee. Ja, Ingo, das dachte ich auch. Für Innen- und Außentemperatur lasse ich auf meinem Raspi-Server zwei separate log-files schreiben. Klar, könnte man auch noch in die ems_data einbauen, aber ich bin halt old-school. ;-) Die Auswertung macht ein shell-script, "upd_temp_file", s.o., das seinerseits jede Stunde von cron ins Rennen geschickt wird. Die Dateigrößen der generierten files halten sich in Grenzen, seit Mitte Oktober 2013 habe ich bis jetzt ca. je 300K gesammelt. Highstock setzt das Ganze dann mittels "temp_out.js" (Außentemperaturen) in eine nette Graphik um. Highstock ist deshalb mein Favorit, weil man damit jede Zeitstrecke individuell darstellen kann, und das im Browser quasi am lebenden Objekt. Im Gegenzug lasse ich die "ems_data" jeden Sonntag auf 30 Tage kürzen, damit sie nicht zu fett wird. Das erledigt "shorten_ems_data". Die übrigen "nicht ems Daten", die ich per 1-wire absammle, speichere ich mittels rrdtool in rrd_dbs, die haben eben den Vorteil, datenmäßig nicht aus dem Ruder zu laufen. Gruß Karl M.
Hello All, I have the complete "EMS system" running now, with both Web interfaces of Danny and Moosy, including Graphs, translated in Dutch and mofified to my "oil heating" properties. Thanks all who have supported!!! I found out that (in my case) the "Raumtemperatureinfluss" is halve the original value, so 3K on R35 is 1.5K in the collector. I think this value (at least in my case) should not have a division 2. In my case the "Auslegungstemperatur" is set to 65C @ (-17C), the presented value on Moosy is 45C. When I log the Raw data from collectord (not in deamon mode), I don't see complete mesaages type 0x3D, so I can't check what is in the RAW data. Also in the RAW data of Moosy's pop-up the value of "HK1 designtemperature" is not present. Is there one or other reason this data is not logged ? I'm specially interested in the "HeizKurve", without roomtemperature correction this is easy to calculated, but has anybody already found the algoritme (used by Buderus) for the roomtemperature correction ? Best regards Maarten
Karl M. W. schrieb: > Highstock setzt das Ganze dann mittels "temp_out.js" (Außentemperaturen) > in eine nette Graphik um. Very interesting for my extended domotica ambitions, I had a look on the Highstock site and these graphs look great. However I not very experienced with html or php: do you have also a small expample where you call or execute this Graph ? Thanks in advanced from Damme Belgium, Maarten
Dag allemaal, Maarten H schrieb: > do you have also a small expample where > you call or execute this Graph ? ... just have a look at my post under Beitrag "Re: Faktensammlung Buderus EMS" It's the "temp_out.js" file doing that job for the temperature outdoor. To let it fly, you need a tsv logfile as described in and made by "upd_temp_file". Last, you need a *.html/php file with a "<div id=temp_out></div>" where "temp_out" is the "renderTo" statement in the "temp_out.js" file. And for all other temperatures/parameters you just have to change the adequate variables. If you want to use mysql instead of tsv-logs, just alter the first lines of the *.js file accordingly. Gruß Karl M.
:
Bearbeitet durch User
Karl M. W. schrieb: > Last, you need a *.html/php file with a "<div id=temp_out></div>" where > "temp_out" is the "renderTo" statement in the "temp_out.js" file. Thanks, I was looking for this part, the rest was already done. Thanks again, Maarten
Wer kennt sich mit Moosys Frontend aus? Die Ems-tools werden ja benötigt bevor man sich an das Frontend machen kann, oder? Ich hänge an Punkt 5 der Installationsanleitung:
1 | 5. Start the emsclient in the CLI-Subdir. Type |
2 | help <enter>. |
Wie starte ich den? Das ist doch eine PHP-Datei, oder? sobald ich die über Terminal auf dem Linuxrechner starte wird mir nur der Quelltext ausgegeben. Habe auch mal versucht die Endung PHP zu geben. Die PHP-Seiten com collectors funktionieren alle problemlos. Auch eine Test.php die die Infos ausgibt funktioniert im Browser oder Console Egal wie ich den emsclient starte wird immer der Quelltext ausgegeben. Habe mal verschiedene Ordner probiert und Rechte probiert. Aufruft über Terminal:
1 | ./emsclient |
wenn ich im Ordner bin. Oder
1 | http://localhost/emsclient |
im Browser. Oder ist das keine PHP-Datei? Werden eventuell noch andere Bibliotheken oder Pakete als bei den collectord-dateien benötigt?
Fehler gefunden. Mein PHP erwartet
1 | <?php
|
,nur
1 | <? |
ist ihm zu wenig. Nach dem ergänzen von php im Quelltext funktioniert jetzt zumindest der emsclient aus den emstools.
:
Bearbeitet durch User
Ingo, I don't think you need emsclient for getting Moosy's Web frontend running. I also first made the emsclient running: I changed the properties into executable, I also installed php-cli, then I could simple execute it directly, without browser. BUT: now I have the whole Moosy's Wed frontend running, and even when I delete emsclient it still works. the collectord deamon however should be running. For the Moosy WEB-FE you have to go through all the files an take care all directories are well in place, surely in the config files. Also you have to take care www-data is owner-group of most of the directories. Success and best regards Maarten
Maarten H schrieb: > I don't think you need emsclient for getting Moosy's Web frontend > running. Thanks Maarten. i solved the problem. in the ems-client there was only <? without php. After inserting the missing php (<?php) it will work now.
Hallo zusammen, ich habe die Schaltung für den AVR NETIO nachgebaut und nach der Anleitung im Wiki in Betrieb genommen -> funktioniert einwandfrei, tolle Arbeit habt ihr da geleistet! Als Steuerung kommt eine RC30 zum Einsatz. Ich habe Moosys Webinterace laufen bzw. das CLI, ebenfalls von Moosy. Schaltzeiten kann ich ändern, aber wenn ich die Warmwassertemperatur ändere dauert es keine 30 Sekunden bis wieder der am RC30 eingestellte Wert erscheint. Sprich direkt nach dem Ändern bekomme ich über den Bus die veränderte Solltemperatur zurück, allerdings springt sie kurz darauf automatisch auf den vorherigen Wert. Hat jemand von euch eine Idee woran das liegen kann bzw. könnte an seiner Steuerung mal probieren, ob sich das genauso verhält? Grüße, MySam
Könnte mir vorstellen das die RC30 die eingestellte Wassertemperatur überprüft und wieder zurück stellt? Die RC30 ist ja als Wasserbereiter eingestellt, oder? Was willst Du denn damit erreichen. Du kannst ja auch einmalig die Wassertemperatur ändern. Notfalls kannst Du ja der RC 30 sagen dass sie kein Warmwasser bereitet und das dann selber machen?
IngoF schrieb: > Was willst Du denn damit erreichen. Du kannst ja auch einmalig die > Wassertemperatur ändern. ...einmalig die Warmwasserbereitung starten
Danke für deine schnelle Antwort. Ja, ich vermute dass genau das passiert. Ich wollte die Zirkulation manuell starten. Wenn ich an der RC30 auf den Knopf "Einmalladung" drücke und die Warmwasser-Temperatur weniger als 5 Grad von der Soll-Temperatur abweicht, dann wird die Zirkulation für 3 Minuten gestartet ohne das Wasser nachzuheizen. Daher wollte ich die Soll-Temperatur herabsetzen (um eine Ladung zu vermeiden) und über die Einmalladung die Zirkulation starten. Alternativ kann ich natürlich die Zirkulationspumpe auf Dauerbetrieb schalten, dann muss ich aber sicherstellen, dass ich sie nach 3 Minuten wieder abschalte. Kann ein Skript machen, muss ich nur sicherstellen, dass das zuverlässig funktioniert. Das ganze dient dazu herauszufinden, wie weit eine bedarfsgerechte Zirkulation den Energieverbrauch senkt. Bevor ich nun an den Zapfstellen Schalter anbringe, möchte ich gerne erstmal per Smartphone/Tablet testen wieviel das ausmacht. Meine Überlegung ist nur: ich kann Schaltzeiten im RC30 ändern; wenn ich eine neue Wassertemperatur setze, dann hätte ich erwartet dass sich der eingestellte Wert im RC30 ändert? Aus der Anleitungs des RC20 (ich habe keinen): "Wenn der Raumcontroller RC20 als Fernbedienung für einen Heizkreis installiert ist, wird die Warmwasserbereitung und der Betrieb der Zirkulationspumpe für die komplette Heizungsanlage mit der Bedieneinheit (z. B. RC30/RC35) eingestellt. Die eingestellte Warmwassertemperatur kann mit dem RC30/ RC35 oder dem RC20 geändert werden, es gilt jedoch der Einstellbereich des RC30/RC35 (maximal 80 °C)." Somit müsste das über den Bus doch zu machen sein?
wie wird denn die ww-solltemperatur mit dem webinterface eigentlich gesetzt (hab jetzt keine lust mir das aus dem code herauszupulen). bei mir mache ich das mit dem 33er telegramm. welche temperatur hast du denn versucht einzustellen? es gibt eine min-begrenzung. generell gilt: ww-bereitung ist eine funktion des UBA(0x08). sollwerte werden "in" den UBA geschrieben. der RC und du seid hier gleichberechtigt. der sollwert wird nur einmalig bei änderung gesetzt, der RC wird deine änderung also per se nicht korrigieren. anders sieht es aus, wenn man beispielsweise zirkulationspumpe oder einmalladung steuern will. hier setzt der RC minütlich ein eigenes telegramm ab (das 35er, wenn ich mich richtig erinnere). will man hier nicht "weggebügelt" werden, muss man ebenfalls minütlich senden. //niffko
Niffko _. schrieb: > wie wird denn die ww-solltemperatur mit dem webinterface eigentlich > gesetzt (hab jetzt keine lust mir das aus dem code herauszupulen). > > bei mir mache ich das mit dem 33er telegramm. Wenn ich moosy's Code richtig verstehe, macht dieser am Ende 'ww temperature <value>', was am Ende Offset 2 in Telegramm 0x33 anpasst. > welche temperatur hast du denn versucht einzustellen? es gibt eine > min-begrenzung. Das sollte der Collector schon entsprechend wegfangen (der hat ein Limit 30 <= value <= 80). > anders sieht es aus, wenn man beispielsweise zirkulationspumpe oder > einmalladung steuern will. hier setzt der RC minütlich ein eigenes > telegramm ab (das 35er, wenn ich mich richtig erinnere). will man hier > nicht "weggebügelt" werden, muss man ebenfalls minütlich senden. Interessant. Zirkulationspumpenkommandos sendet der Collector an die RC, da gibt's also kein Problem; Einmalladung wird aber im UBA aktiviert. Heißt das, dass die RC die vom Collector angestoßene Einmalladung nach einer Minute abbrechen wird? Muss ich glatt mal probieren...
:
Bearbeitet durch User
@danny über das 35er teilt der RC dem UBA mit ob ww aktiv/inaktiv, z-pumpe aktiv/inaktiv. der telegramminhalt ist logischerweise abhängig von den eingestellten zeitprogrammen. einmalladung ist nichts anderes, als dass das 35er für 3 min die z-pumpe aktiviert und ggf. auf ww-tagbetrieb umschaltet (das dann natürlich nicht nur 3 min.). //niffko
Vielen Dank für die Infos, leider stecke ich bei weitem noch nicht so im Detail wie ihr. Ich habe während der Änderung mal die Debug-Daten weggeschrieben (siehe Anhang, die interessanten Stellen siehe unten). Beim Setzen der WW-Temperatur passiert folgendes (der Versuch fand während der Nachtabsenkung statt, tagsüber ist das Verhalten aber gleich): IO: Sending bytes 0x8 0x33 0x2 0x2d IO: Got bytes 0xaa 0x55 0x4 0x8 0xb 0xff 0x1 0xfd MESSAGE[17.02.2016 22:27:47]: source 0x08, dest 0x0b, type 0xff, offset 1, data: DATA: Unhandled message received(source 0x08, type 0xff). IO: Sending bytes 0x88 0x33 00 0xa IO: Got bytes 0xaa 0x55 0xe 0x8 0xb 0x33 00 0x8 0xff 0x2d 0xfb 0xff 0x28 0xff 0x3 0x46 00 0x7c MESSAGE[17.02.2016 22:27:49]: source 0x08, dest 0x0b, type 0x33, offset 0, data: 0x08 0xff 0x2d 0xfb 0xff 0x28 0xff 0x03 0x46 0x00 DATA: Warmwasser-per Kesselschalter freigegeben = AN DATA: Warmwasser-Temperatureinstellung = 45 °C DATA: Zirkulation-Schaltpunkte = 3x 3min DATA: Warmwasser-Desinfektionstemperatur = 70 °C Daraufhin kommt von Quelle 0x08 noch 2x die gesetzte Temperatur, schon 30 Sekunden später werden wieder die 50 °C gesendet, die am RC30 gesetzt sind. IO: Got bytes 0xaa 0x55 0xf 0x8 00 0x33 00 0x8 0xff 0x2d 0xfb 0xff 0x28 0xff 0x3 0x46 00 00 0x77 MESSAGE[17.02.2016 22:27:57]: source 0x08, dest 0x00, type 0x33, offset 0, data: 0x08 0xff 0x2d 0xfb 0xff 0x28 0xff 0x03 0x46 0x00 0x00 DATA: Warmwasser-per Kesselschalter freigegeben = AN DATA: Warmwasser-Temperatureinstellung = 45 °C DATA: Zirkulation-Schaltpunkte = 3x 3min DATA: Warmwasser-Desinfektionstemperatur = 70 °C IO: Got bytes 0xaa 0x55 0x5 0x9 0x8 0x33 0x2 0x32 0x2 MESSAGE[17.02.2016 22:27:57]: source 0x09, dest 0x08, type 0x33, offset 2, data: 0x32 DATA: Unhandled message received(source 0x09, type 0x33). ... IO: Got bytes 0xaa 0x55 0x6 0x10 0x8 0x35 00 0x1 0x11 0x3d MESSAGE[17.02.2016 22:28:04]: source 0x10, dest 0x08, type 0x35, offset 0, data: 0x01 0x11 IO: Got bytes 0xaa 0x55 0xf 0x8 00 0x33 00 0x8 0xff 0x32 0xfb 0xff 0x28 0xff 0x3 0x46 00 00 0x68 MESSAGE[17.02.2016 22:28:08]: source 0x08, dest 0x00, type 0x33, offset 0, data: 0x08 0xff 0x32 0xfb 0xff 0x28 0xff 0x03 0x46 0x00 0x00 DATA: Warmwasser-per Kesselschalter freigegeben = AN DATA: Warmwasser-Temperatureinstellung = 50 °C DATA: Zirkulation-Schaltpunkte = 3x 3min DATA: Warmwasser-Desinfektionstemperatur = 70 °C Die letzten zwei Zeilen mögen interessant sein, denn dort werden von BC10 an MC10 die 50 Grad gesendet. Würde ja fast dafür sprechen, dass der Drehregler nicht auf "Auto" steht (wo soll der BC10 die Temperatur sonst her haben?), was ich mir aber absolut nicht vorstellen kann; da die Heizung nicht physisch hier im Haus steht werde ich das morgen trotzdem mal prüfen.
Hallo, hat noch jemand einen EMS - RxTx Konverter als PCB (gerne auch schon bestückt), dann würde ich die ihm gerne abkaufen. Boxi
Boxi B. schrieb: > Hallo, > > hat noch jemand einen EMS - RxTx Konverter als PCB (gerne auch schon > bestückt), dann würde ich die ihm gerne abkaufen. > > Boxi Wäre ganz gut zu wissen um welche es geht. Vermutlich um die WLAN-Version, oder?
Das kommt drauf an. Was ist denn noch verfügbar. Im einfachsten Fall genügt mir der Konverterteil von EMS auf RS232. Da kann ich mir dann den mC dranhängen. Was komplett fertiges nehme ich auch gerne. Oder sowas: https://www.mikrocontroller.net/attachment/245669/Selection_028.png
:
Bearbeitet durch User
Hallo, gibt es eine Möglichkeit die fest eingespeicherten Schaltzeiten (nicht die Eigenprogramme) abzufragen. Also Morgen, Mittag, Abendprogramm... In welchen Telegrammtype stehen diese? Ich benutze die RC30
:
Bearbeitet durch User
Hallo Ingo, die Daten auf: 1. http://ems-gateway.myds.me/dokuwiki/doku.php und 2. http://emswiki.thefischer.net/doku.php sind inhomogen. Das erzeugt unweigerlich Verwirrung. ?-) Vielleicht änderst Du den Inhalt der
1 | http://ems-gateway.myds.me/dokuwiki/doku.php |
einfach wie folgt:
1 | <? |
2 | header('Status: 301 Moved Permanently', false, 301); |
3 | header('Location: http://emswiki.thefischer.net/doku.php'); |
4 | exit(); |
5 | ?> |
Ist wesentlich einfacher, als zwei Wikis mit dem selben Inhalt konsistent zu halten. ;-) Gruß Karl M.
Danke für den Hinweis. Karl M. W. schrieb: > Vielleicht änderst Du den Inhalt der > http://ems-gateway.myds.me/dokuwiki/doku.php > einfach wie folgt: /dokuwiki/dokuphp und doku.php Ist die selbe Datei :-D Habe die alte Startseite mit einem Link zur neuen Seite versehen.
Ich mal mal wieder eine Frage für Niffko ;-) Ich habe vorhin gerade festgestellt, dass der vom Collector geschriebene Wert 'Innentemperatur-Soll' falsch definiert ist: diesen Wert sollte es nicht nur 1x geben, sondern 1x pro Heizkreis, da er mit dem HK-Monitor-Telegramm mitgeschickt wird. Bislang wird der Wert halt aus jedem Telegramm gleich behandelt, was so nicht funktioniert (deshalb war mir das auch aufgefallen - bei mir ist er zwischen 0 und der eingestellten Temperatur gependelt, weil er nur in HK2 ausgefüllt ist). Das kann man ja prinzipiell problemlos fixen (mit der Ausnahme, dass danach eine kleine Änderung an Moosy's Frontend nötig ist), allerdings stellt sich mir die Frage, wie man RC20-Statusmeldungen behandeln muss. Daher meine Frage: Wie erkenne ich, welchem Heizkreis die RC20 zugeordnet ist? Hat die je nach Zuordnung eine andere Busadresse, oder steht das mit im Statustelegramm, oder kann man das gar nicht erkennen?
Danny B. schrieb: > Wie erkenne ich, welchem Heizkreis die RC20 > zugeordnet ist? Bis Niffko antwortet erst mal meine Meinung: Ich meine irgendwann mal irgendwo irgendwie aufgeschnappt zu haben dass die Busadresse das ist... :-)
Wenn dem wirklich so ist, würde ich meine Frage mal noch erweitern: welche Busadresse der RC20 entspricht dann welchem HK? ;)
Danny B. schrieb: > Wenn dem wirklich so ist, würde ich meine Frage mal noch erweitern: > welche Busadresse der RC20 entspricht dann welchem HK? ;) Also ich habe mal alle möglichen Bedienungsanleitungen und Installationsanleitungen zur RC20, RC30, RC35 und RC300 durchgelesen. Dort gibt es nur das Beispiel mit zwei Heizkreisen. Und eine RC30/35 und eine Fernbedienung RC20. Demnach ist es wohl nur möglich an einem Heizkreis zu sagen ob sie Die RC20 benutzt oder die RC35. Die RC30/35 sollte es ja wissen an welchem Heizkreis die RC20 eingestellt ist. Steht es vielleicht in einem Telegramm zum Heizkreis drin welchen Controller sie benutzt? Eventuell ist es ja nur ein Bit. Bis dahin gibt es noch keine Busadressen Probleme. Nur dann wenn es drei Heizkreise oder mehr gibt. Hat denn jemand drei oder mehrere Heizkreise an seiner Heizung? Vielleicht bekommt man es ja so raus. Denke da kann vermutlich nur Niffko Klarheit schaffen.
Danny B. schrieb: > [...] welche Busadresse der RC20 entspricht dann welchem HK? gute frage. ich habe hierzu leider weder zahlen noch einen RC20 um es auszutesten ... es ist so, dass am jeweiligen RC20 die zugehörige heizkreisadresse(1-4) eingestellt werden muss. ich könnte mir vorstellen, dass hierüber dann auch die bus-adresse festgelegt wird. bei adresse "0" würde der RC20 als master arbeiten, es darf dann kein RC30/35 vorhanden sein. ich denke, wir können das nur klären, wenn ein RC20-besitzer mal testhalber die mögliche heizkreisadressen einstellt und dann schaut, wie die RC20-telegramme aussehen ... //niffko
Niffko _. schrieb: > ich denke, wir können das nur klären, Oder einfac h mal ins Wiki gehen ;-) http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme#busadressen_ems Jetzt weissich auch woher meine Vermutungen kamen. Hatte ja damals so ziemlich alle Adressen abgescannt... Also 0x17 als Standalone und 0x18 0x1f für Heizkreise 1-8.
IngoF schrieb: > für Heizkreise 1-8 Zu Heizkreis 1-8 muss ich allerdings sagen dass es eine Vermutung von mir ist. Da es für RC20, Mischer, Warmwasser und Solarmodule genau 8 Adressen gibt. Besser wäre es aber wenn das ein RC20 Benutzer bestätigen könnte.
Hi, ich versuche gerade, das "moosy"" Webinterface zum Laufen zu bekommen. Im cli-Verzeichnis wollte ich die emsclient-Datei starten, aber php gab mir immer den Dateiinhalt aus. Ursache ist, dass <? anstelle von <?php verwendet wurde, was wohl bei meiner PHP-Version nicht mehr zulässig ist. Nächstes Problem war: im include-Verzeichnis werden in den php-Dateien überall Dateien mit absolutem Pfad includiert. Z.b. in emsqry.inc: require("/emsincludes/config.php"); Der führende Slash sollte imho entfernt werden... oder soll man emsincludes unter / ablegen? (habe nicht viel Ahnung von PHP und lasse ich mich gern korrigieren). Gruß, Thomas
Thomas schrieb: > Nächstes Problem war: im include-Verzeichnis werden in den php-Dateien > überall Dateien mit absolutem Pfad includiert. Z.b. in emsqry.inc: > require("/emsincludes/config.php"); > Der führende Slash sollte imho entfernt werden... oder soll man > emsincludes unter / ablegen? Moosy hat glaub ich letzteres im Sinn gehabt bzw. gemacht. Da mir das auch nicht gefallen hat, habe ich bei mir dies Pfadangabe in sämtlichen Skripten geändert.
IngoF schrieb: > IngoF schrieb: >> für Heizkreise 1-8 > > Zu Heizkreis 1-8 muss ich allerdings sagen dass es eine Vermutung von > mir ist. > Da es für RC20, Mischer, Warmwasser und Solarmodule genau 8 Adressen > gibt. > > Besser wäre es aber wenn das ein RC20 Benutzer bestätigen könnte. Danke, das klingt für mich plausibel. 0x17 würde ich dann auch HK1 zuordnen.
So... weiter gehts.... In der mconfig.php habe ich noch <? durch <?php ersetzt. Im include-Verzeichnis habe musste ich aus allen Dateien die Pfade "emsincludes" entfernen. Nun scheint das Webinterface zu funktionieren. In mehreren Dateien fehlt das <?, das scheint aber nicht zu stören. In ems-heizkurve.py habe ich geändert: process.stdin.write("set grid lc rgb '#aaaaaa' lt 1 lw 0,5\n") process.stdin.write("set grid lc rgb '#aaaaaa' lt 1 lw 0.5\n") (Komma zu Punkt bei 0,5\n am Ende). Keine Ahnung ob das so stimmt, aber er Zeichnet jetzt die Kurve (calcheizkurve.sh manuell als root gestartet). In der config.py habe ich den mysql-Socket angepasst (mysqld anstelle von mysql) und in der ems-gen-graphs.py ebenfalls bei 0,5 das Komma durch einen Punkt ersetzt. -> Graphen da :) Die Scripte kann man auch z.B. alle 5 Minuten per Cron aufrufen, dann muss man den Webserver (bei mir apache) keine sudo-Erlaubnis geben.
Thomas schrieb: > So... weiter gehts.... Genau die selben Probleme hatte ich auch damals... Hatte das in irgendeinem Thread aufgelistet und nur auf meinem PC geändert Habe jetzt einfach mal diese Änderungen auch noch in Meinem Fork (ingof) übernommen
Hallo, bei "moosy" EMS-Rohdaten werden bei mir keine Temperaturwerte angezeigt, ist das nur bei mir so? Die Felder werden ganz normal gelb aber es kommen keine Werte, im Livestatus werden hingegen diverse Temperaturen angezeigt. Gruß Martin
Martin schrieb: > bei "moosy" EMS-Rohdaten werden bei mir keine Temperaturwerte angezeigt, > ist das nur bei mir so? Die Felder werden ganz normal gelb aber es > kommen keine Werte, im Livestatus werden hingegen diverse Temperaturen > angezeigt. RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und vorherige Diskussion. BTW, benutzt hier jemand OpenHAB? Wenn ja, besteht Interesse an einer Anleitung, wie man den Collector darin einbindet? :)
Danny B. schrieb: > BTW, benutzt hier jemand OpenHAB? Wenn ja, besteht Interesse an einer > Anleitung, wie man den Collector darin einbindet? :) Aber sicher doch. Lese mich auch schon seit ein paar Tage in openHab ein.
Ich bin noch ein kurzes Feedback schuldig beim Problem die Warmwassertemperatur zu ändern: ich war erst am Wochenende vor Ort, es war tatsächlich am MC10 der Regler auf "50" statt "AUTO" gestanden, dann ist es kein Wunder dass es nicht funktioniert. Seitdem er wieder auf Auto steht, lässt sich auch die Temperatur wie erwartet einstellen.
Danny B. schrieb: > BTW, benutzt hier jemand OpenHAB? Wenn ja, besteht Interesse an einer > Anleitung, wie man den Collector darin einbindet? :) Servus Danny, ... noch nutze ich kein OpenHAB. Neben FHEM wohl eines der Systeme, denen eine gewisse Zukunft gegeben scheint. Wobei ich gestehen muss, dass mir Perl als Sprache näher ist denn Java. Aber das spielt hier keine Rolle! Wäre es denn nicht grundsätzlich, und insbesondere auch für openHAB, von Vorteil, wenn Du EMS in das System "einbauen" würdest. Könnte mir vorstellen, dass es einige openHAB User gibt, die auch eine Buderus am laufen haben und noch niemals auf dieser Seite hier waren. Also, auf was wartest Du? ;-) Gruß aus der frühlingsnahen Wetterau Karl M.
Karl M. W. schrieb: > ... noch nutze ich kein OpenHAB. Neben FHEM wohl eines der Systeme, > denen eine gewisse Zukunft gegeben scheint. Wobei ich gestehen muss, > dass mir Perl als Sprache näher ist denn Java. Aber das spielt hier > keine Rolle! Siehst du, mir geht's genau anders herum: mit Perl bin ich noch nie warmgeworden, und Java spreche ich ohnehin fließend, weil ich viel für Android code. FHEM hatte ich anfangs verwendet, bin aber jetzt beim Wechsel auf stärkere Hardware (Wandboard -> NUC) auf OpenHAB umgestiegen. Mir scheint, als ob die beiden Projekte den Stereotypen der jeweiligen Programmiersprachen entsprechen: FHEM ist eher für Entwickler, stellenweise etwas kryptisch und fühlt sich 'basteliger' an, während OpenHAB ein typisches Java-Programm ist: braucht viel Speicher, ist tendenziell etwas overeingineered, aber sehr flexibel mit einem übersichtlichen Konzept untendrunter. > Wäre es denn nicht grundsätzlich, und insbesondere auch für openHAB, von > Vorteil, wenn Du EMS in das System "einbauen" würdest. Könnte mir > vorstellen, dass es einige openHAB User gibt, die auch eine Buderus am > laufen haben und noch niemals auf dieser Seite hier waren. > > Also, auf was wartest Du? ;-) Das habe ich ernsthaft erwogen, aber dann aus zwei Gründen wieder verworfen: - ich habe keine Lust, noch ein Projekt (hier: OpenHAB-EMS-Addon) zu maintainen - ich habe keine Ahnung, ob die OpenHAB-Leute ein solches Binding überhaupt wollen, weil dieses logischerweise den Collector nach sich ziehen würde Stattdessen habe ich den Ansatz gewählt, dem Collector MQTT-Support beizubringen. Dafür gibt's ein gutes OpenHAB-Binding, und der zusätzliche Daemon (MQTT-Broker, bei mir mosquitto) fällt gegenüber OpenHAB kaum ins Gewicht (im Moment bei mir: 272 (!) vs. 5 MB Speicherbedarf). Dafür muss man halt nur ein Stück Code pflegen und die schlussendlich erreichte Funktionalität ist praktisch identisch. Ich werde demnächst mal eine Zusammenfassung in's Wiki schreiben, wie man das Ganze aufsetzt und verwendet.
:
Bearbeitet durch User
Danny B. schrieb: > ... (Wandboard -> NUC) ... ... posh! > ... Ich werde demnächst mal eine Zusammenfassung in's Wiki > schreiben, wie man das Ganze aufsetzt und verwendet. ... awaiting!
Karl M. W. schrieb: > Danny B. schrieb: > >> ... (Wandboard -> NUC) ... > > ... posh! ;) Nachdem mir inzwischen 4 SD- und Micro SD-Karten im SheevaPlug und Wandboard gestorben sind - meistens mit Datenverlust - und wir uns auf das Funktionieren des Servers immer mehr verlassen, musste einfach etwas stabileres her, das nicht auf SD-Karten als Root-FS angewiesen ist, und damit sind so ziemlich alle ARM-Boards raus. Es gibt bestimmt auch welche mit eMMC, da ist der Preisunterschied zum NUC aber auch nicht mehr so riesig. >> ... Ich werde demnächst mal eine Zusammenfassung in's Wiki >> schreiben, wie man das Ganze aufsetzt und verwendet. > > ... awaiting! :) Mal sehen, wann ich dazu komme.
Danny B. schrieb: > RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und > vorherige Diskussion. Das ist eine RC35 Version 1.15
Martin schrieb: > Danny B. schrieb: >> RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und >> vorherige Diskussion. > > Das ist eine RC35 Version 1.15 Hast du Das such dem Collector gesagt? ;) Entweder mit dem Kommandozeilenoption --rc-type rc35 oder mit rc-type = rc35 in der Konfigurationsdatei. Edit: Auch wenn es nicht schadet, diese Option anzugeben, sollte es auf dein Problem keinen Einfluss haben. Ich muss nochmal schauen, wodurch dieses Problem eigentlich ausgelöst wurde...
:
Bearbeitet durch User
Danny B. schrieb: > Martin schrieb: >> Danny B. schrieb: >>> RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und >>> vorherige Diskussion. >> >> Das ist eine RC35 Version 1.15 > > Hast du Das such dem Collector gesagt? ;) Entweder mit dem > Kommandozeilenoption --rc-type rc35 oder mit rc-type = rc35 in der > Konfigurationsdatei. > > Edit: Auch wenn es nicht schadet, diese Option anzugeben, sollte es auf > dein Problem keinen Einfluss haben. Ich muss nochmal schauen, wodurch > dieses Problem eigentlich ausgelöst wurde... Der Fehler ist in der emsdetail.ajax von Mossy, nachdem ich die gegen die Version von Danny Beitrag "Re: EMS > Adapter > NetIO > Raspi" ausgewechselt habe funktionierts. Danke Danny !!
Danke für die Rückmeldung, spart mir das Gucken morgen :) (Ich wusste, dass da was war, konnte mich aber nicht genau erinnern)
Karl M. W. schrieb: > Danny B. schrieb: >> ... Ich werde demnächst mal eine Zusammenfassung in's Wiki >> schreiben, wie man das Ganze aufsetzt und verwendet. > > ... awaiting! Ein Anfang: http://emswiki.thefischer.net/doku.php?id=wiki:ems:openhab Die Zuordnung von Sensoren zu MQTT-Topics muss ich mal noch dokumentieren, die muss man sich im Moment aus der Ausgabe von Port 7778 erschließen. Die Steuerung der Heizung via OpenHAB werde ich später noch dokumentieren; ich möchte das vorher erst mal selbst testen ;-)
Danny B. schrieb:
> http://emswiki.thefischer.net/doku.php?id=wiki:ems:openhab
Danke Danny! Mal sehen, ob ich das kapiere?-)
Hi, ich habe das KM271 in meine Logamatik 2107 gesteckt und per USR-TCP232-2 an´s LAN genommen. Ich bekomme nun per C#-Programm folgendes gelesen (siehe unten) und habe große Mühe das zu interpretieren. Das, was ihr so bekommt, kommt bei mir nicht. Die Standards funktionieren (also eine 02 gesendet, kommt eine 10 zurück). Ich sende alle 20 sek. eine 10 um die Daten zu bekommen (ist das die richtige Vorgehensweise?) Das hier bekomme ich (kaum Änderungen und fast immer das Gleiche): 04 00 07 01 00 25 C0 01 10 03 F5 02 04 00 07 01 00 25 C0 01 10 03 F5 02 04 00 07 01 00 25 C0 01 10 03 F5 02 04 00 07 01 00 25 C0 01 10 03 F5 02 00 00 65 09 14 28 02 2A 10 03 6B 02 04 00 07 01 00 25 C0 01 10 03 F5 02 04 00 07 01 00 25 C0 01 10 03 F5 02 04 00 07 01 00 25 C0 01 10 03 F5 02 04 00 07 01 00 25 C0 01 10 03 F5 Was mache ich falsch? Danke, Daniel
Daniel K. schrieb: > Ich sende alle 20 sek. eine 10 um die Daten zu bekommen (ist das die > richtige Vorgehensweise?) Kenne jetzt speziell dieses Modul nicht. Aber Buderus verwendet zur Kommunikation oft 3964R-Protokoll. Dort steht genau beschrieben wie es funktioniert. Alle 20 Sekunden könnte bedeuten dass eventuell die Daten zwischen zwei Abfragen "verloren" gehen... denke die einzelne 02 gehört noch zum Handshake.. Kenne mich mit dem 2107 Bus überhaupt nicht aus und kann zur Telegrammbedeutung wenig sagen. Müsste aber alles am 2107-Thread stehen: Beitrag "Logamatic 2107 Schnittstelle" Daniel K. schrieb: > Das hier bekomme ich (kaum Änderungen und fast immer das Gleiche): Das könnte daher kommen dass viele Telegramme wegen des 20 Sekunden Polling ignoriert werden. Denke es dürfte dann nur alle 40 Sekunden ein Telegramm kommen...
Daniel K. schrieb: > Ich sende alle 20 sek. eine 10 Dann auch beachten dass deshalb die 10 Datenwerte doppelt gesendet werden.
Hallo, Mittlerweile habe ich mir ein Adapter besorgt (Beitrag "Re: EMS > Adapter > NetIO > Raspi"). Jetzt möchte ich gerne der Software von Danny B. auf eine Raspberry Pi zum laufen bekommen. Dazu habe ich noch einige Fragen und hoffentlich kann jemand die beantworten. 1. Hardware Anbindung Kan ich der Platine direkt an der RPI UART anbinden, oder ist es besser dies mit eine UART-USB Adapter zu machen? 2. Regler Typ Momentan habe ich ein Nefit Moduline 300, gleiches model als Buderus RC30. Ich möchte aber gerne auch der Außentemperatur mit aufzeichnen. Dazu muß ich mir dann ein Sensor und ein andere Regler besorgen, entweder der RC35 oder RC300. Funktionieren beide Regler mit der EMS-Collector? 3. Installations Anleitung Ich hab mir diese Thread, der Github (https://github.com/maniac103/ems-collector) und der Wiki nachgesehen. Habe ich etwas übersehen wenn ich nicht ein detaillierte Anleitung gefunden habe? Kann mir jemand Koordinaten geben? 4. Installation Wegen viele defekte SD-Karten in meine RPI's möchte ich gerne der Datenbank und Webseite auf meine Synology machen. Kann ich bei der Installation auf eine externe Datenbank verweisen? Kann der Webseite auf eine Datenbank der nicht auf 'localhost' legt zugreifen? So, viele Fragen, ich hoffe es gibt auch antworten ;-) Gruß, Ferdinand
Ferdinand S. schrieb: > 1. Hardware Anbindung Die Platine kann weder mit USB oder direkt am Raspi angeschlossen werden. Was mich aber wundert ist dass im Tread dort "Zu Raspberry Pi" im Schaltplan steht.?! Die Platine macht nur eine Umwandlung auf die Serielle Schnittstelle. Das Problem ist dass dann der Raspberry-Pi jedes Zeichen einzeln abholen muss damit das Framing (spezielles Break-Signal) erkannt werden kann. Es könnte auch in der Software anders verarbeitet werden um das Break durch die Datenanalyse nachträglich wieder zu erkennen. Glaub das aber nicht. Der Collector kann auch wohl Daten über die serielle Schnittstelle empfangen. Allerdings wird dabei ein spezielles Datenformat erwartet das mit dieser Platine wohl nicht funktionieren wird (Break). > 2. Regler Typ Der Reglertyp ist dabei egal. Die Außentemperatur wird auch so auf den Buss gegeben. Bei der Raumtemperatur wird die Temperatur durch den "Regler" gemessen. Das kann also nicht funktionieren. Der EMS-Collectore kommt mit der RC30 RC300 klar. Dafür wurde er ja urscprünglich geschrieben. > 3. Installations Anleitung Im Wiki gibt es auch eine Anleitung: https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io > 4. Installation Denke der collectord sollte kein Problem haben wenn die mysql nicht auf dem selben Server liegt. Allerdings müsstest Du dann eventuell auf die das PHP-Webinterface verzichten oder das auf dem selben (Web)Server wie die MySQL zu packen. Hatte damals keine Verbindung zu einer mySQL-Datenbank aufbauen können die nicht auf dem selben Server lag. Keine Ahnung ob das php-webinterface überhaupt interessant für Dich ist.
:
Bearbeitet durch User
Ingo F. schrieb: > Der Collector kann auch wohl Daten über die serielle Schnittstelle > empfangen. Allerdings wird dabei ein spezielles Datenformat erwartet das > mit dieser Platine wohl nicht funktionieren wird (Break). Richtig. Der Collector erwartet, dass im Bytestream auf der seriellen Schnittstelle schon ein Framing vorhanden ist: 0xaa 0x55 <len> <data0> <data1> ... <dataX> Diese Umwandlung (Break erkennen, Checksumme prüfen, Framing einfügen) hat bei mir bislang immer ein Atmega gemacht. Wenn die serielle Schnittstelle des Raspi (bzw. die Treiber der selbigen) Breaks erkennen kann, könnte man das auch in einen Prozess packen; da müsste mir nur mal jemand sagen, wie das geht...hab selber keinen Raspi. >> 2. Regler Typ > Der Reglertyp ist dabei egal. Die Außentemperatur wird auch so auf den > Buss gegeben. Bei der Raumtemperatur wird die Temperatur durch den > "Regler" gemessen. Das kann also nicht funktionieren. > > Der EMS-Collectore kommt mit der RC30 RC300 klar. Dafür wurde er ja > urscprünglich geschrieben. Nee, das stimmt so nicht. Er geht mit RC30 und RC35, allerdings nicht mit RC300 ... die ist EMS+, und dafür hat noch keiner die Telegramme decodiert.
Beitrag #5312980 wurde vom Autor gelöscht.
Danny B. schrieb: > Diese Umwandlung (Break erkennen, Checksumme prüfen, Framing einfügen) > hat bei mir bislang immer ein Atmega gemacht. Wenn die serielle > Schnittstelle des Raspi (bzw. die Treiber der selbigen) Breaks erkennen > kann, könnte man das auch in einen Prozess packen; da müsste mir nur mal > jemand sagen, wie das geht...hab selber keinen Raspi. Bleibt dann noch die Frage ob der RASPI schnell genug ist jedes Byte einzeln abzuholen. Auf einem PC hatte ich es damals nicht geschafft. Der Raspi ist ja eigentlich nichts anderes als ein "PC" Beim Polling muss die Antwort ja auch entsprechend schnell kommen. Sonst kann man nur lauschen und eben so lange auf das Telegramm warten bis es kommt. Senden ist dann nicht möglich. Dadurch kann dann auch kein Telegramm angefragt werden.
Ingo F. schrieb: > Bleibt dann noch die Frage ob der RASPI schnell genug ist jedes Byte > einzeln abzuholen. Auf einem PC hatte ich es damals nicht geschafft. Ja klar ist er das. Die reinkommenden Bytes werden ja mit einem Interrupt verarbeitet. Du wolltest das ja aus dem Userspace machen, und da habe ich auch Zweifel, ob das Out-of-the-Box funktioniert...daher auch der Hinweis auf den Kernel-Treiber. Die Hardware ist auf alle Fälle schnell genug, man wird aber wahrscheinlich einen speziellen Kernel-Treiber brauchen, der die Info 'Break Condition bei Byte X' an eben jenes Byte bindet.
Danny B. schrieb: > man wird aber wahrscheinlich einen speziellen Kernel-Treiber brauchen, der > die Info 'Break Condition bei Byte X' an eben jenes Byte bindet. Kerneltreiber schreibt man nicht mal so eben.... Break abfragen selber ist zumindest möglich BRKINT in c_iflag: http://man7.org/linux/man-pages/man3/termios.3.html Was meinst du mit > Du wolltest das ja aus dem Userspace machen,
:
Bearbeitet durch User
Hallo Danny Und Ingo, Vielen Dank für die schnelle Antworten und Diskussion! Hat mir wirklich geholfen. Also wenn ich es richtig verstanden habe ist dann folgende Situation vorhanden. 1. Hardware Ein direkte Verknüpfung geht ja Hardwaremäßig, aber nicht vom Software. Grund ist dafür das der Collector schon ein fertiges DatenFrame erwartet und um dass zu machen muß der SW die der Serielle Schnittstelle lest ein Break erkennen. 1a. Hardware Lösung Um es jetzt doch aus zu werten muß ich mit also ein AVR-NET-IO bei Pollin besorgen, inklusive einen ATmega644P-20PU und Netzteil. Mit der Vorhanden Hex-Datei wird dies dann Funktionieren. Anbindung ist wie folgt: TX vom Adapter an Pin 1 vom NetIO RX vom Adapter an Pin 2 vom NetIO 5V vom Adapter an Pin 10 vom NetIO Allerdings wird ich dann nicht der 3 LED's haben 1b. Software Lösung Wenn ich es richtig verstehe vom https://www.raspberrypi.org/documentation/configuration/uart.md mus der PL011 eigentlich schon ein Break Erkennung machen. Nur der Frage ist wie man es dann richtig umsetzt für Benutzung in Collector. Oder? Habe mir heute einiges angesehen wie WiringPi oder PySerial, und vielen Fragen im Internet. Habe aber noch keine schöne Lösung gefunden. In der wiki steht ein Option "# SERIALDEVICE="/dev/ttyUSB0", ich glaube deswegen habe ich mit gedacht das es mit eine 'einfache' UART/Serial-USB Adapter gehen wurde. Diese sollte auch Break Erkennung machen. Vielleicht wird ich mir dies einmal anschließen und einfach mal der Bus aufzeichnen, mal sehen was er dann bekommt. 2. Regler Typ Wenn ich also nur ein Sensor habe und ein RC30 wird der wert schon auf der Bus engezeigt. Also brauche ich der RC35 nur um es im Wohnzimmer an zu sehen. 3. Anleitung Danke, hat vile geholfen. 4. Installation Also der RPi mit der Collector ausrüsten und dann z.B. an ein Datenbank auf meine Synology verweisen. Nur der Webseite soll dan auch auf der Synology liegen. Danke
Ferdinand S. schrieb: > 1a. Hardware Lösung > Um es jetzt doch aus zu werten muß ich mit also ein AVR-NET-IO bei > Pollin besorgen, inklusive einen ATmega644P-20PU und Netzteil. Mit der > Vorhanden Hex-Datei wird dies dann Funktionieren. > Anbindung ist wie folgt: > TX vom Adapter an Pin 1 vom NetIO > RX vom Adapter an Pin 2 vom NetIO > 5V vom Adapter an Pin 10 vom NetIO > Allerdings wird ich dann nicht der 3 LED's haben Geht - zumindest wenn du nicht senden/steuern, sondern nur lesen willst - auch deutlich einfacher ;-) Siehe den Schaltplan hier: Beitrag "Re: EMS > Adapter > NetIO > Raspi" ... das ist ein EMS-zu-UART-Adapter, der ein Protokoll auswirft, das direkt mit dem Collector kompatibel ist. Teilekosten vielleicht 5€; du brauchst halt noch einen Atmega-Programmer (für das NetIO allerdings auch). > Wenn ich es richtig verstehe vom > https://www.raspberrypi.org/documentation/configuration/uart.md mus der > PL011 eigentlich schon ein Break Erkennung machen. Nur der Frage ist wie > man es dann richtig umsetzt für Benutzung in Collector. Oder? > > Habe mir heute einiges angesehen wie WiringPi oder PySerial, und vielen > Fragen im Internet. Habe aber noch keine schöne Lösung gefunden. Eine schöne Lösung wird's dafür nicht geben ... das Problem ist recht speziell :-/
Habe mal zum spielen einen PIC mit zwei Seriellen Ports im DIP-Gehäuse mit 14 Beinchen bestellt. Wegen internen Oszillator würden keine externen Bauteile benötigt (Außer EMS-Teil natürlich) Meine Idee wäre dass er einfach eine Umsetzung vom EMS-Bus auf die serielle Schnittstelle macht. Also ein kleiner ems-Gateway ohne Ballast(Ethernet,CAN,USB-Serial und den Rest). Ohne SMD und daher auch viel einfacher nachbaubar. Also als kleines Interface dass an den RASPI angeschlossen werden könnte und das Framing für den collectord besitzt. könnte bei auch mit einem USB-TTL-Serial am PC oder NAS angeschlossen werden. Hätte jemand an soetwas Interesse?
:
Bearbeitet durch User
Hallo Ingo, Na klar, das wird mich sicherlich interessieren! Ich möchte ja nur der EMS-Bus auswerten, also alles andere an der AVR-NET-IO wurde nicht benutzt. Wenn diese Adapter der EMS-Telegramme direkt auf der gute Framing für der Collector bereiten kann wäre das Super. Wenn ich darf einige Fragen dazu: * Können Sie sagen welches Modell Sie gekauft haben? (Reine Interesse) * Ist es angedacht nur zum Lesen oder auch Senden? * Wenn es mit ein USB-TTL-Serial kommuniziert könnte Mann ggf. auch auf ein RPi dies so anschließen und dann z.B. mit Python auslesen. Oder habe ich das falsch?
Ferdinand S. schrieb: > welches Modell PIC16F15325-I/P Über die serielle Schnittstelle kann dann über EMS-collector oder auch andere Programme gesteuert werden. Weil der PIC dann den EMS-Bus steuert und nur die Nachrichten über den Bus gehen. Aber dann alles über die Serielle Schnittstelle: https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-gw-netio Kommt erst in zwei Wochen. Wollte den Quelltext vom EMS-Gateway und den Bootloader verwenden und anpassen. Kann aber keine Termine nennen und nichts versprechen...
:
Bearbeitet durch User
Moin zusammen. Ich bin über den 2107 thread hier angekommen. Bei dem habe ich das erste Jahr gelesen - sehr interessant! - und den Rest sowie den hier überflogen. Ist ja echt ne Menge Stoff! Habe eine Buderus gb125 mit rc300 und würde gerne nur die Daten lesen und loggen. Nun habe ich zwar einen Rpi daheim, und könnte auch löten, habe aber leider von der theoretischen (Elektrik, Elektronik, Programmierung ) Seite eigentlich keine Ahnung. Interessierter Laie was das angeht, auch wenn ich im Prinzip verstehe was ihr macht. Gibt es mittlerweile eine Lösung, wo man vielleicht nur noch Hardware basteln und dann aber fertige Software Pakete / skripte etc installieren kann um die Daten zu loggen? Gruß Stephan
StephanW schrieb: > Gibt es mittlerweile eine Lösung, wo man vielleicht nur noch Hardware > basteln und dann aber fertige Software Pakete / skripte etc installieren > kann um die Daten zu loggen? Das ist Ansichtssache. Plug&Play gibt es nicht. Die *Hardware* besteht aus bis zu Drei Teilen. 1) EMS-Bus Interface für Ethernet 2) Hardware für CollectorD 3) Evtl. weitere Hardware für Webinterface/Datenbank/openHAB Für den EMS-Bus gibt es iegentlich zwei Hardwaretypen: *) NetIO-Board mit selbstgebauter/gekaufter Adapterplatine (und Prozessoraustausch für zweiter Serial-Port) *) EMS-Gateway (Fertig aufgebaut wenn wieder verfügbar, Sammelbestellung) Die *Software* Auf einem RaspberryPi könnte dann folgende Software laufen: 1) collectord um die Verbindung mit netIO oder EMS-Gateway herzustellen 2) mySQL-Server 3) php_Webinterface oder auch: 1) collectord um die Verbindung mit netIO oder EMS-Gateway herzustellen und MQTT 2) MQTT 3) openHab oder auch irgendwas anderes. Das erste Softwarepaket hatte ich mal auf dem Raspberry Pi laufen. Ein paar weiter Infos hast Du dazu bestimmt schon im Wiki gesehen.. https://emswiki.thefischer.net/ Der NetIO und die Adapterplatine kann mit etwas bastelerfahrung selber zusammenbauen. Beim EMS-Gateway ist das wegen viel SMD nicht möglich. Ich überlege eine kleine Platine nur für den Serial-Port zu bauen die auch an den Raspberry Pi angeschlossen werden könnte und einfacher nachbauen zu ist.
Ingof schrieb: >> .....dann aber fertige Software Pakete / skripte etc installieren > ...Plug&Play gibt es nicht. Das wichtigste vergessen: Dazu muss der collectord compiliert werden und die Andere Software installiert und alles konfiguriert werden. Aber mit etwas nachlesen probieren sollte das möglich sein. Bei Problemen einfach hier oder in einem der anderen Thread nachfragen...
Hallo, danke für die übersichtliche Darstellung. Wie gesagt, Hardware basteln ist nicht so das Problem, ich habe aktuell auch ziemlich viele Elektronik Entwickler als Kollegen mit entsprechender Hardware. :) Auch Software nach Anleitung installieren und ggf. mit Hilfe anpassen - ok, denke schon. Allerdings kann ich wie gesagt nicht programmieren und komme nicht aus der E-Ecke. Deswegen kann ich auch die Hard- und Software Varianten in ihren Vor- und Nachteilen bzw. ihrer Eignung nicht beurteilen und bin auf eure Empfehlung angewiesen. Letztendlich möchte ich einfach den zeitlichen Verlauf der Daten loggen, archivieren, und grafisch darstellen können (manuelle Wahl des Zeitfensters, ggf. mehrere zum Vergleichen). Gruß
Moin zusammen, ich weiß meine Logindaten gerade nicht (bin im Büro), mir gehen aber gerade ein paar Dinge durch den Kopf die ich lieber jetzt gleich frage, bevor ich die heute Abend vergessen habe ;-) a) Ich habe die alte Platine im Einsatz(daher ist die Abfrage direkt über Lan und/oder JSON nich möglich), die per USB an einem Pi2 hängt, den Collector incl. mysql DB und auch die php Weboberfläche ebenfalls. Aus aktuellem Anlass (Update anderer Pi auf Stretch) überlege ich den Umzug auf einen Pi3 und auf Stretch. Würde das eigentlich funktionieren und falls ja, wie wäre die beste Vorgehensweise ? b) Für meine Hausautomatisation hatte ich geplant regelmäßig die aktuellen Datensätze aus der DB abzufragen um nicht ständig die Daten aus der Schnittstelle umzusetzen. Das funktioniert auch relativ gut, bis auf die Daten aus der letzten Tabelle, da bricht die Abfrage nach 3min mit Timeout ab. Ich könnte natürlich die Scriptlaufzeit hoch setzen, denke aber das ich einfach nur eine ungünstige Abfrage genutzt habe. Das ganze läuft auf PHP, vielleicht hat ja jemand eine performantere Lösung ;-) Alternativ müsste man vielleicht nur die DB regelmäßig aufräumen um nicht den ganzen alten Ballast zu durchsuchen, da ich dafür zumindest nur die aktuellsten Daten benötige. Irgendwelche Vorschläge ?
1 | $sq3="SELECT b.sensor, c.name, b.value, c.unit, b.starttime, b.id from $mysql_Tbl_name2 b, $mysql_Tbl_name3 c where c.type=b.sensor and ((select max(id) from $mysql_tbl_name2 where sensor =c.type)=b.id)"; |
Gruß Jens
Der Link zum Wiki unter dem Punkt Doku zum Telegrammaufbau: - Wiki http://ems-gateway.myds.me/dokuwiki/ hat sich geändert zu: - Wiki https://emswiki.thefischer.net/
Hier noch eine interessante Faktensammlung zum Busprotokoll: https://domoticproject.com/ems-bus-buderus-nefit-boiler/ Stammt vom 10.04.2018
Ich habe einen GB125 Brennwertkessel und ein EMS-Board von BBQ_KEES welches ich an einen RasPi angeschlossen habe. Die Adapterschaltung ist direkt mit dem rückwärtigen EMS-Bus der Heizung verbunden (nicht über Diagnoseklinke) Ich empfange eine Menge Daten, die aber irgendwie nicht zu den EMS-Telegrammen passen. Hier gab es schonmal ein Posting mit dem GB125 aber dort sahen die Daten noch ganz anders aus. Die Ausgabe kommt aus dem ems-collector: Sind das gültige Daten oder empfange ich Müll? O: Got bytes 0x89 00 IO: Got bytes 0x9 00 IO: Got bytes 0x90 00 0x10 00 0x89 00 IO: Got bytes 0x9 00 IO: Got bytes 0x93 00 IO: Got bytes 0x89 00 0x9 00 0x94 00 IO: Got bytes 0x90 00 0x10 00 0x89 00 IO: Got bytes 0x9 00 0x95 00 IO: Got bytes 0x89 00 IO: Got bytes 0x9 00 0x90 00 0x10 00 0x96 00 IO: Got bytes 0x89 00 IO: Got bytes 0x9 00 0x90 00 0x10 00 IO: Got bytes 0x89 00 0x9 00 0x97 00 IO: Got bytes 0x89 00 IO: Got bytes 0x9 00 0x9a 00 IO: Got bytes 0x90 00 0x10 00 0x89 00 IO: Got bytes 0x9 00 IO: Got bytes 0x8 00 0x18 00 0x52 0x2 0x8c 0x64 IO: Got bytes 0x64 0xa 0x10 0x15 0x1 0x2 0x26 0x7d IO: Got bytes 00 0x80 00 0x2 0x13 0xff 0x3d 0x48 IO: Got bytes 00 00 0xff 0x1 0x10 0x83 00 0x66 IO: Got bytes 00 IO: Got bytes 0x8 IO: Got bytes 00 0x18 0x1b 00 00 00 00 00 IO: Got bytes 00 00 0x50 00 00 0x8a 00 IO: Got bytes 0xa2 00 IO: Got bytes 0x89 00 IO: Got bytes 0x9 00 0x90 00 0x10 00 IO: Got bytes 0xaa 00 IO: Got bytes 0x89 00 IO: Got bytes 0x9 00 IO: Got bytes 0x90 00 0x10 00 0x89 00 IO: Got bytes 0x9 00 0xb2 00 IO: Got bytes 0x89 00 0x9 00 0xba 00 IO: Got bytes 0x90 00 0x10 00 0x89 00 IO: Got bytes 0x9 00 0xc2 00 IO: Got bytes 0x89 00 IO: Got bytes 0x9 00 IO: Got bytes 0x90 00 0x10 00 IO: Got bytes 0xca 00
Habe mir das noch mal genauer angesehen. Deine Verwendete Platine wandelt vermutlich nur Den EMS-Bus auf die Serielle Schnittstelle um und machst sonst nichts. Kein Ausfiltern des Pollings oder Umwandeln des EMS-Framings (0x00 mit Stopbit 0) Der EMS-collector erwartet wohl ein Framing mit 0xAA 0x55 <Länge> Es müsste also so aussehen: Beitrag "Re: Faktensammlung Buderus EMS" Kann mir dann auch nicht vorstellen dass ein Schreiben auf den EMS-Bus möglich ist. Vermutlich nur lesen.
Dieses Projekt hat mir geholfen, meine Buderus GB162/RC35 über mqtt in Homeassistant anzubinden: https://github.com/proddy/EMS-ESP. Im Debug-Modus kann man sich die Daten auch über die ser. Schnittstelle/USB ausgeben lassen.
Vielen Dank für das Feedback. Ich hatte, bevor ich den RasPi an das Adapterboard angeschlossen hatte, einen Wemos D1 Mini mit der ems-esp Firmware angeschlossen. Leider kamen dort nie irgendwelche Daten von der Adapterplatine an; ich ging davon aus, daß der Wemos irgendwie kaputt war. Jetzt habe ich mir einen Wemos D1 besorgt und die ems-esp-Firmware geflasht. Hier habe ich jetzt den Effekt, daß ich wenn serial=on ist gar keine Meldungen empfange. Wenn ich serial=off setze, bekomme ich alle 20sek die folgende Meldung "Error! Unable to read from EMS bus. Retrying in 20 seconds..." Wenn ich serial=on setze sind die Fehlermeldungen weg ich bekomme aber keine Daten. Hat jemand eine Idee?
Gibt es mittlerweile Fortschritte bei der Dekodierung der EMSplus-Telegramme? Ich habe meine Erkenntnisse mal hier niedergeschrieben: https://github.com/Th3M3/buderus_ems-wiki
Hallo @TheM, benutzt Du einen RasPi um die Telegramme zu dekodieren? Ich habe mir die Telegramme auch angesehen, weiss aber nicht, wie ich diese "schneiden" soll. Zu sagen, daß nach jedem "00" ein neues Telegramm anfängt ist mE falsch. Falls Du eine Routine zur Telegrammerkennung hast würde ich mir diese mal sehr gerne ansehen. Gruß, Alex
Also generell werden Telegramme (Polling und die Antworten) mit einem Break beendet. Habe noch mal die Seite ganz wenig überarbeitet: https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme Es kann gerne jeder mithelfen die Telegramme zu ergänzen. Einfach mailen. Die Registrierungsfunktion hatte ich wegen SPAM abgeschaltet.
Ich kann bei der "Decodierung" der Telegramme leider nicht weiter helfen. Meine Heizung hat "nur" den EMS-Bus und kein EMS+.
Hallo zusammen, bin gerade am überlegen, wie ich Telegramme erkennen kann. Ich habe einen Raspi und einen ESP8266. 1) Der RasPi hat keine Break-Erkennung an seinem "mini" UART 2) Mit dem esp kenne ich mich noch zu wenig aus um da was basteln zu können 3) USB-UART mit Break Erkennung wäre eine Idee; ich weiss aber nicht, wie ich das in einem "Standard" C-Programm abfragen kann. Alternativ könnte ich einen Stream-Parser bauen, der nach jedem 0x00 versucht, ein gültiges Telegramm zu erkennen. Das sollte ja durch den bekannten Aufbau und die Prüfsumme kein Problem sein. Wie ist denn Euer Setup beim Telegramm-Parsen? Hat jemand einen Raspi im Einsatz und könnte ein bisschen Code zur Verfügung stellen?
Ich habe einen GB125 30kw Ölbrenner mit RC35 und MC10 und habe jetzt mal einen hexdump an meinem RasPI mit 9600 8n1 gezogen: hexdump -C /dev/ttyAMA0 00000000 90 10 89 09 e0 89 09 90 10 e8 89 09 90 10 89 09 |....�....�......| 00000010 8a 89 09 8b 90 10 89 09 8c 89 09 90 10 8d 89 09 |................| 00000020 90 10 89 09 8e 89 09 8f 90 10 89 09 91 89 09 90 |................| 00000030 10 92 89 09 90 10 89 09 93 89 09 94 90 10 89 09 |................| 00000040 95 89 09 90 10 96 89 09 90 10 89 09 97 89 09 9b |................| 00000050 90 10 89 09 a3 89 09 90 10 ab 89 09 90 10 89 09 |....�....�......| 00000060 b3 89 09 bb 90 10 89 09 c3 89 09 90 10 cb 89 09 |�..�....�....�..| 00000070 90 10 89 09 d3 89 09 db 90 10 89 09 e3 89 09 90 |....�..�....�...| 00000080 10 eb 89 09 90 10 89 09 8a 89 09 8b 90 10 89 09 |.�..............| 00000090 8c 89 09 90 10 8d 89 09 90 10 89 09 8e 89 09 8f |................| 000000a0 90 10 89 09 91 89 09 90 10 92 89 09 90 10 89 09 |................| 000000b0 93 89 09 94 90 10 89 09 95 89 09 90 10 96 89 09 |................| 000000c0 90 10 89 09 97 89 09 9a 90 10 89 09 a2 89 09 90 |............�...| 000000d0 10 aa 89 09 90 10 89 09 b2 89 09 ba 90 10 89 09 |.�......�..�....| 000000e0 c2 89 09 90 10 ca 89 09 90 10 89 09 d2 89 09 da |�....�......�..�| 000000f0 90 10 89 09 e2 89 09 90 10 ea 89 09 90 10 89 09 |....�....�......| 00000100 8a 89 09 8b 90 10 89 09 8c 89 09 90 10 8d 89 09 |................| 00000110 90 10 89 09 8e 89 09 8f 90 10 89 09 91 89 09 90 |................| 00000120 10 92 89 09 90 10 89 09 93 89 09 94 90 10 89 09 |................| 00000130 95 89 09 90 10 96 89 09 90 10 89 09 97 89 09 99 |................| 00000140 90 10 89 09 a1 89 09 90 10 a9 89 09 90 10 89 09 |....�....�......| 00000150 b1 89 09 b9 90 10 89 09 c1 89 09 90 10 c9 89 09 |�..�....�....�..| 00000160 90 10 89 09 d1 89 09 d9 90 10 89 09 e1 89 09 90 |....�..�....�...| 00000170 10 e9 89 09 90 10 89 09 8a 89 09 8b 90 10 89 09 |.�..............| 00000180 8c 89 09 90 10 8d 89 09 90 10 89 09 8e 89 09 8f |................| 00000190 90 10 89 09 91 89 09 90 10 92 89 09 90 10 89 09 |................| 000001a0 93 89 09 94 90 10 89 09 95 89 09 90 10 96 89 09 |................| 000001b0 90 10 89 09 97 89 09 9c 90 10 89 09 a4 89 09 90 |............�...| 000001c0 10 ac 89 09 90 10 89 09 b4 89 09 bc 90 10 89 09 |.�......�..�....| 000001d0 c4 89 09 90 10 cc 89 09 90 10 89 09 d4 89 09 dc |�....�......�..�| 000001e0 90 10 89 09 e4 89 09 90 10 ec 89 09 90 10 89 09 |....�....�......| 000001f0 8a 89 09 8b 90 10 89 09 8c 89 09 90 10 8d 89 09 |................| 00000200 90 10 89 09 8e 89 09 8f 90 10 89 09 91 89 09 90 |................| 00000210 10 08 1a 00 25 64 64 00 e1 01 10 92 89 09 90 10 |....%dd.�.......| 00000220 89 09 93 89 09 94 90 10 89 09 95 89 09 90 10 96 |................| 00000230 89 09 90 10 89 09 97 89 09 98 90 10 89 09 a0 89 |..............�.| 00000240 09 90 10 a8 89 09 90 10 89 09 b0 89 09 b8 90 10 |...�......�..�..| 00000250 89 09 c0 89 09 90 10 c8 89 09 90 10 89 09 d0 89 |..�....�......�.| 00000260 09 d8 90 10 89 09 e0 89 09 90 10 e8 89 09 90 10 |.�....�....�....| 00000270 89 09 8a 89 09 8b 90 10 89 09 8c 89 09 90 10 8d |................| 00000280 89 09 90 10 89 09 8e 89 09 8f 90 10 89 09 91 89 |................| Ich sehe viele wiederkehrende Muster aber nichts passt auf die angegebenen Telegramme.
ingof schrieb: > AlexS schrieb: >> 00000210 10 08 1a 00 25 64 64 00 e1 01 10 92 00210 ist auch keins. Das Problem fängt bei 1a an...
Hmmm. Müsste das dann nicht: 0x10 0x08 0xFF 0x1a heissen? Bzw. fehlt da nicht der Offset?
Auf dem EMS+ Bus werden die EMS und EMS+ Telegramme gesendet. Also doch folgende Werte möglich für das dritte Byte, oder? EMS ohne Offset 00x0 EMS mit Offset 0x1A EMS+ 0xFF
Stimmt, Du hast vollkommen recht; ich hab mich fälschlicherweise voll auf EMS+ konzentriert. Die Heizung schickt aber anscheinend nur EMS-Telegramme. (mittlerweile habe ich sogar verstanden, wie ich die EMS-Bus-Tabellen interpretieren muss). Ausserdem habe ich mehr über das Problem mit meinen Daten herausgefunden. Es gibt jemanden, der auf dem RasPi bereits einen Protokollparser geschrieben hat. Als ich diesen auf die Daten losgelassen habe, kam folgendes raus: (Auszug) UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Daten: 08 00 18 00 0b 02 ce 64 00 00 00 00 00 02 60 7d 00 80 00 00 00 ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler UBAMonitorWWMessage ( 08 00 34 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Daten: 08 00 34 00 3c 02 60 7d 00 21 00 00 03 00 06 a4 8d 00 b4 57 d3 00 97 00 89 - CRC-Fehler UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Daten: 08 00 18 00 0b 02 ce 64 00 00 00 00 00 02 60 7d 00 80 00 00 00 ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler UBAMonitorWWMessage ( 08 00 34 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Daten: 08 00 34 00 3c 02 60 7d 00 21 00 00 03 00 06 a4 8d 00 b4 57 d3 00 95 00 89 - CRC-Fehler UBASollwerte ( 10 08 1a 00) 01 02 03 04 05 06 07 08 09 Daten: 10 08 1a 00 00 00 00 00 91 - CRC-Fehler RCTimeMessage ( 10 00 06 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 Daten: 10 00 06 00 13 05 16 1e 19 10 03 01 0c 00 10 00 ed - CRC-Fehler UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Daten: 08 00 18 00 0b 02 ce 64 00 00 00 00 00 02 60 7d 00 80 00 00 00 ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler UBAMonitorWWMessage ( 08 00 34 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Daten: 08 00 34 00 3c 02 60 7d 00 21 00 00 03 00 06 a4 8d 00 b4 57 d3 00 91 00 89 - CRC-Fehler -> Irgendwie scheinen die CRC-Daten fehlerhaft zu sein. Allerdings sehe ich daß verschiedene Telegramme (z.B. UBA Monitor fast) identisch sind. Wenn es wirklich Störungen auf der Leitung wären, würde ich erwarten ,daß die Telegramme leicht unterschiedlich wären. Ich habe als Beispiel die Zeit-Telegramme rausgepickt: RCTimeMessage ( 10 00 06 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 Daten: 10 00 06 00 13 05 16 1e 19 10 03 01 0c 00 10 00 ed - CRC-Fehler Jahr=0x13 (2019) Monat=0x05 Mai Stunden=0x16 22 Tage=0x1e 30 Minuten=0x19 25 Sekunden=0x10 16 Wochentag=0x03 Donnerstag Flags 0x01 -> Sommerzeit CRC=0x0C Die Daten klingen alle plausibel (sind frisch gezogen). Leider weiss ich nicht, wie die CRC berechnet werden soll. Eine CRC-8 wäre 0x47
Ich habe mich selbst nochmal mit meinen falschen CRC's beschäftigt. -> Bei der Heizung wird immer derselbe CRC ausgegeben, obwohl sich der Inhalt geändert hat CRC ist immer 0x83 Wenn ich mir die Rohdaten ansehe empfange ich auch wirklich immer genau die falsche CRC. Kennt jemand das Phänomen? Kann das mit dem Break und dem RasPi-Uart zusammenhängen? Andererseits, hat derjenige, von dem ich das Skript 'geliehen' habe keine Probleme. Er verwendet auch den Raspi-Uart UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 crc_ist0x83 crc_soll0xaa Daten: 08 00 18 00 27 02 a4 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler data published UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 crc_ist0x83 crc_soll0x85 Daten: 08 00 18 00 27 02 a3 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler data published UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 crc_ist0x83 crc_soll0x85 Daten: 08 00 18 00 27 02 a3 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler data published
Was sind denn die "Rohdaten"? Kommen die auch vom Raspi? Habe die Erfahrung gemacht dass sich die serielle Schnittstelle unter Linux nicht so gut mit RAW-Daten verträgt. Die Schnittstelle muss erst durch die Konfiguration(Posix) dazu gezwungen werden die wirklich ankommenden Daten unverfälscht weiter zu geben. Einige Zeichen (XON, XOFF, Zeilenumbrüche, ....) werden gerne umgewandelt oder unterdrückt. Vielleicht enthält Dein Datensatz zufällig eines dieser Zeichen die bei der Heizung vom Programmierer nicht aufgetreten sind. Sind Deine Telegramme denn richtig aufgebaut und ergeben Sinn? Oder sind dort irgendwelche Werte "verrutscht"? Die CRC Berechnung hat mich damals fast in den Wahnsinn getrieben. Rudi hatte damals die 0x12 "gefunden". Hier der Links zum ersten Code zur CRC-Berechnung: Beitrag "Re: Logamatic 2107 Schnittstelle"
Habe die CRC-Berechnung noch mal schnell ins Wiki gepackt: https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme#crc
ingof schrieb: > Was sind denn die "Rohdaten"? Kommen die auch vom Raspi? > Die Rohdaten habe ich mit (stty raw; cat > /srv/received.log) < /dev/ttyAMA0 gesammelt Bytes fehlen bei den Telegrammen nicht; bis jetzt habe ich keine "Ausreisser" gefunden (ausser der CRC natürlich...) Hier ist die dekodierte Meldung mit der falschen CRC UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 crc_ist0x83 crc_soll0x0a Daten: 08 00 18 00 0b 02 af 64 00 00 00 00 00 02 48 7d 00 80 00 00 00 ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler data published Die Rohdaten sehen so aus (ist ein anderes Telegramm mit einer anderen WW-Temperatur): 000001d0 xx xx xx xx xx xx xx xx xx xx xx xx 08 00 18 00 |................| 000001e0 0b 02 b0 64 00 00 00 00 00 02 48 7d 00 80 00 00 |..�d......H}....| 000001f0 00 ff 30 48 00 00 ff 00 00 83 00 0c 00 08 00 18 |.�0H..�.........| > Habe die Erfahrung gemacht dass sich die serielle Schnittstelle unter > Linux nicht so gut mit RAW-Daten verträgt. > Die Schnittstelle muss erst durch die Konfiguration(Posix) dazu > gezwungen werden die wirklich ankommenden Daten unverfälscht weiter zu > geben. > Einige Zeichen (XON, XOFF, Zeilenumbrüche, ....) werden gerne > umgewandelt oder unterdrückt. > > Vielleicht enthält Dein Datensatz zufällig eines dieser Zeichen die bei > der Heizung vom Programmierer nicht aufgetreten sind. > > Sind Deine Telegramme denn richtig aufgebaut und ergeben Sinn? Oder sind > dort irgendwelche Werte "verrutscht"? Verrutscht oder fehlen tut nix. Es ist alles Da. Das einzige was ich merkwürdig finde ist daß die Vorlauf-Solltemperatur mit 11 Grad (statt 70 gesendet wird) Die Vorlauf-Ist-Temperatur ist ok. > Die CRC Berechnung hat mich damals fast in den Wahnsinn getrieben. Rudi > hatte damals die 0x12 "gefunden". > Hier der Links zum ersten Code zur CRC-Berechnung: > Beitrag "Re: Logamatic 2107 Schnittstelle" Ich schau mir mal die Berechnung an, Vielen Dank für Deine Hilfe!!
Hallo AlexS, derjenige, von dem du den Code "geliehen" hast, bin ich. Siehe http://www.kabza.de/MyHome/EMSbus.html Funktioniert das Auslesen von deinem EMS-Bus inzwischen ohne CRC-Fehler? LG, Alex
Alexander Kabza schrieb: > derjenige, von dem du den Code "geliehen" hast, bin ich. > Siehe http://www.kabza.de/MyHome/EMSbus.html Hallo Alex, Wie klappt das denn mit der Break-Erkennung auf dem Raspi? Ist es möglich die Zeichen schnell genug jedes einzelne Byte auszulesen um den Frameerror auszuwerten? Oder wie erkennst Du das Ende der Polling(Telegramme)? Gruß Ingo Edit: gerade auf Deiner Seite gefunden:
1 | Unregelmäßig dazwischen kommen Zeichenfolgen mit zwei Byte, wobei das zweite Byte immer 0x00 ist. Das erste Byte scheint ein Zähler zu sein, ... |
das ist das Polling mit dem die Busteilnehmer angesprochen werden. Es werden im größeren Abstand die Adressen hochgezählt... Das macht der Busmaster wohl zwischendurch wenn er Langeweile hat. Sobald ein Busteilnehmer darauf antwortet und sich dadurch am Bus "anmeldet" wird er haufiger abgefragt. Also Busadresse mit MSB gesetzt.
:
Bearbeitet durch User
Hallo Ingo, erst einmal danke für deinen Beitrag von 2011, nach dem ich meinen Pegelwandler in erster Version aufgebaut habe. Ich verstehe die beiden Fragen nicht ganz, versuch aber doch mal meine Antwort auf die erste Frage uu geben: Mein Python-Script liest so lange von der seriellen Schnittstelle, bis die ersten vier Bytes eines bekannten EMS-Header kommen. Ist das der Fall, dann wird die darauf folgende Botschaft eingelesen. Jede Botschaft hat ja eine festgelegte Länge. Ich muss also gar nicht auf ein Break oder Ende warten. Die Frage mit dem Frameerror verstehe ich aber nun wirklich nicht. Ich prüfe mit der Prüfsumme, ob die Botschaften fehlerfrei angekommen sind. Und nur dann wird das jeweilige XML-File erstellt. Funktioniert auf diese Weise seit August 2017 sehr zufriedenstellend. Danke auch für die Info mit dem Polling. Ich werde das wenn OK für dich auf meiner Homepage entsprechend anpassen. LG, Alex
OK, das habe ich vermutet. Das Ende der Telegramme wird durch ein Break gekennzeichnet. Also ein 0-Byte mit Stopbit 0. Das ist ein FrameError. Diesen FrameError können nicht alle seriellen Schnittstellen auswerten. Wenn die Schnittstelle das unterstützt muss allerdings jedes Zeichen einzeln ausgelesen werden. Wenn mann 5 Zeichen aus dem Buffer ausliest kann man nicht feststellen welches Byte dieses falsche Stop-Bit-0 hatte. Du liest einfach alle Daten ein bis z.b. 08 00 06 für die Uhrzeit auftaucht und wertest die folgenden Daten aus. Edit: Die Telegrammlänge andert sich ja an der selben Anlage nicht. Aber an einer anderen Anlage können die längen von Deiner abweichen. Gruß Ingo
:
Bearbeitet durch User
Hallo Alex K, habe gerade erst Deine Antwort gesehen. Ich verwende die Break-Erkennung auf dem Raspi nicht; hatte mich kurzzeitig damit beschäftigt, es dann aber aufgegeben. Laut Hardwarebeschreibung sollte der "echte" UART am RPi3 ja eine BRK-Erkennung haben, die ist aber nie angeschlagen. Ich habe immer noch dieselben "sonderbaren" CRC's. Mittlerweile vermute ich, daß das nichterkannte Break das CRC-Byte negativ beeinflusst. Interessanterweise habe ich bis jetzt kein einziges Telegramm mit unplausiblen Daten gesehen (also z.B. Bitkipper). Nur die CRC's sind alle nachweislich kaputt (aber immer die gleichen "falschen" Werte). Ich habe Dein Skript angepasst, daß es mir die Heizungsdaten an einen MQTT-Server postet, die ich dann in OpenHAB weiterverwerte. Wenn Du möchtest, kann ich es Dir zukommen lassen. Gruß, Alex S.
Hallo Alex dass nicht erkannte BRKs die CRC verändern halte ich für unwahrscheinlich. Sicher dass der Serialport richtig auf RAW konfiguriert ist? Könnte sein dass in den CRC Steuerzeichen sind durch den Serial Port verändert werden. Z.B. LF, CR, XON, XOFF, .... Aber das hatte ich bestimmt schon erwähnt....
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.