Hallo zusammen, nachdem der Net-Io läuft habe ich mich dem Raspi beschäftigt und brauche etwas Starthilfe. Collectord kann ich manuell starten, die DB wird beschrieben. Der Start über init.d wird mit failed! abgebrochen. Die Konfiguration habe ich anhand dieses Threads angepasst. Das ist eine Baustelle. Das Webinterface läuft in Teilen, so sieht das Protokoll schon gut aus, aber im Livestatus bekomme ich keine Daten. Im log von lighttpd finde ich u.a. das hier: 2014-07-11 20:07:28: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice: Undefined index: servicecode in /var/www/lemscnt.ajax on line 36 PHP Notice: Undefined index: errorcode in /var/www/lemscnt.ajax on line 36 PHP Notice: Undefined index: in /var/www/lemscnt.ajax on line 36 PHP Notice: Undefined index: flameactive in /var/www/lemscnt.ajax on line 49 PHP Notice: Undefined index: 3wayonww in /var/www/lemscnt.ajax on line 50 PHP Notice: Undefined index: ww daymode in /var/www/lemscnt.ajax on line 52 PHP Notice: Undefined index: zirkpump daymode in /var/www/lemscnt.ajax on line 53 PHP Notice: Undefined index: hk1 partymode in /var/www/lemscnt.ajax on line 54 PHP Notice: Undefined index: hk1 pausemode in /var/www/lemscnt.ajax on line 54 PHP Notice: Undefined index: hk1 holidaymode in /var/www/lemscnt.ajax on line 5 6 Ich tippe auf Probs mit dem symlink emsincludes und bin mir nicht sicher wie und wo ich den richtig anlege, oder angelegt habe? Das Ganze ist zu komplex strukturiert (Anleitung im github und Hinweise hier) und viel Energie geht bei "try and error" drauf. Habt Ihr noch eine Starthilfe für mich? LG Lorenz
Lorenz G. schrieb: > Ich tippe auf Probs mit dem symlink emsincludes und bin mir nicht > sicher wie und wo ich den richtig anlege, oder angelegt habe? Moosy hat den symlink ins root gelegt. Sicher gibt es auch Menschen mit anderen Dateisystemphilosophien. ;) Ich habs jedenfalls auf meiner Kiste komplett umstrukturiert. Schau Dir vlt. noch mal in aller Ruhe die Links in den einzelnen Dateien an. Hat bei mir geholfen und es bringt den Vorteil, dass man einen Überblick über die Zusammenhänge erhält, der stets hilfreich ist. > Das Ganze ist zu komplex strukturiert (Anleitung im github und Hinweise > hier) und viel Energie geht bei "try and error" drauf. Ja, da ist was dran. Wir könnten jemanden gebrauchen, der eine "ems.deb" zusammenstellt. ;) hth Karl M.
Bei mir lagen diese fehler daran, das bei einigen dateien das ? gefehlt hat bei <?PHP dadurch kommt sowas zustande. guck einfach sämtliche daten(ems-tools und Ems website) durch on die PHP dekalration stimmt.
bitte mal testen Beim Löschen lässt es die Datenbank bestehen. Installiert bislang die init.d setzt sie aber nicht aktiv. Aufbau /etc/default /etc/init.d /esmincludes /usr/local/ems/ems-collector /usr/local/ems/ems-tools /var/www
ems-buderus.deb lässt sich auf dem Raspberry nicht installieren, da für amd64 gepackt und nicht für armhf. LG
Wenn du mir sagen kannst wie die abhängigen pakete genau heisen auf dem pi dann mach ich es offen für alle systeme. Oben ist noch ein fehler mit den libs drinne. Fixe ich heut abend
Wie bekommt man das raus? Bei mir bricht die Installation sofort ab wegen falschem System. LG
So, schau jetzt mal. Ich habe es komplett umgestell, damit es auf allen system selbst erstellt wird. Ich hoffe meine depencies stimmen. Wenn ein fehler beim erstellen kommt brauch ich die Namen der Pakete wie ihr sie braucht um den collectord zu erstellen,
Die Paketinstallation läuft nicht durch, Abbruch bei Erstellung des symlink mit dieser Meldung: Verlinke emsincludes ln: angegebenes Ziel „/emsincludes/“ ist kein Verzeichnis: Datei oder Verzeichnis nicht gefunden dpkg: Fehler beim Bearbeiten von ems-buderus (--install): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück Fehler traten auf beim Bearbeiten von: ems-buderus Ich habe verschieden Varianten versucht, mal mit angelegtem Verzeichnis /emsincludes im root mal ohne, immer das gleiche Bild. Die Probleme, welche ich manuell hatte, scheint auch die Paketverwaltung zu haben :-) LG
Also du brauchst definitv root rechte um den ordner im root zu erstellen. Er versucht erstmal den orden esmincludes in / anzulegen, Was passiert bei dir wenn du sudo mkdir /emsinclude eintippst? dann ls -ls / und dort sollt ein ordner /emsincludes sein EDIT nene quark du hast n Raspi.... das ding musst du erstmal neu mounten, damit du schreiben darfst im root (/) sudo mount / -o remount,rw das eingeben wenn das geht sag mal bescheid wenn fertig sudo mount / -o remount,ro
Ich war mit sudo su als root unterwegs. root@raspi:/emsinclude# ls -ls / insgesamt 92 4 drwxr-xr-x 2 root root 4096 Jan 7 2014 bin 16 drwxr-xr-x 3 root root 16384 Jan 1 1970 boot 0 drwxr-xr-x 12 root root 3140 Jul 13 12:31 dev 4 drwxr-xr-x 2 root root 4096 Jul 13 16:43 emsinclude 4 drwxr-xr-x 110 root root 4096 Jul 13 12:31 etc 4 drwxr-xr-x 4 root root 4096 Jul 4 16:23 home 4 drwxr-xr-x 12 root root 4096 Jul 5 16:49 lib 16 drwx------ 2 root root 16384 Jan 7 2014 lost+found 4 drwxr-xr-x 2 root root 4096 Jan 7 2014 media 4 drwxr-xr-x 2 root root 4096 Okt 17 2013 mnt 4 drwxr-xr-x 6 root root 4096 Jul 4 16:58 opt 0 dr-xr-xr-x 111 root root 0 Jan 1 1970 proc 4 drwx------ 5 root root 4096 Jul 11 08:42 root 0 drwxr-xr-x 18 root root 780 Jul 13 12:31 run 4 drwxr-xr-x 2 root root 4096 Jul 5 16:56 sbin 4 drwxr-xr-x 2 root root 4096 Jun 20 2012 selinux 4 drwxr-xr-x 3 root root 4096 Jul 6 12:10 srv 0 dr-xr-xr-x 12 root root 0 Jan 1 1970 sys 4 drwxrwxrwx 7 root root 4096 Jul 13 16:39 tmp 4 drwxr-xr-x 11 root root 4096 Jul 4 09:06 usr 4 drwxr-xr-x 12 root root 4096 Jul 5 17:18 var So sieht´s jetzt aus. Ich starte die Paketinstallation jetzt nochmal. Dauert dann aber wieder etwas ... LG
Uups, da habe ich gerade noch ein s im Verzeichnis vergessen. Werd´s korrigieren und starten.
Gleiches Problem: Verlinke emsincludes ln: angegebenes Ziel „/emsincludes/“ ist kein Verzeichnis: Datei oder Verzeichnis nicht gefunden dpkg: Fehler beim Bearbeiten von ems-buderus (--install): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück Fehler traten auf beim Bearbeiten von: ems-buderus Aber erstaunlicherweise ist das Verzeichnis nach der Paketinstallation weg: root@raspi:/# ls -ln insgesamt 88 drwxr-xr-x 2 0 0 4096 Jan 7 2014 bin drwxr-xr-x 3 0 0 16384 Jan 1 1970 boot drwxr-xr-x 12 0 0 3140 Jul 13 12:31 dev drwxr-xr-x 110 0 0 4096 Jul 13 12:31 etc drwxr-xr-x 4 0 0 4096 Jul 4 16:23 home drwxr-xr-x 12 0 0 4096 Jul 5 16:49 lib drwx------ 2 0 0 16384 Jan 7 2014 lost+found drwxr-xr-x 2 0 0 4096 Jan 7 2014 media drwxr-xr-x 2 0 0 4096 Okt 17 2013 mnt drwxr-xr-x 6 0 0 4096 Jul 4 16:58 opt dr-xr-xr-x 111 0 0 0 Jan 1 1970 proc drwx------ 5 0 0 4096 Jul 11 08:42 root drwxr-xr-x 18 0 0 780 Jul 13 12:31 run drwxr-xr-x 2 0 0 4096 Jul 5 16:56 sbin drwxr-xr-x 2 0 0 4096 Jun 20 2012 selinux drwxr-xr-x 3 0 0 4096 Jul 6 12:10 srv dr-xr-xr-x 12 0 0 0 Jan 1 1970 sys drwxrwxrwx 7 0 0 4096 Jul 13 18:39 tmp drwxr-xr-x 11 0 0 4096 Jul 4 09:06 usr drwxr-xr-x 12 0 0 4096 Jul 5 17:18 var LG
Ja danke, fehler erkannt, muss das fixen. mach mal fürn anfang sudo mkdir /emsincludes sudo dpkg --remove ems-buderus und dann installier dieses erneut: sudo dpkg --install ems-buderus
So ich denke so kann man es lassen, - Es lädt den Collector runter, compiled ihn Normal und mit RAW-support und kopiert es nach /usr/local/sbin - Es installiert die website von Moosy ( coding fehler behoben) nach /var/www/ems und richtet sie bei apache ein und startet diese. - Es richtet auf wunsch eine SQL-Datenbank mit User ein (ems passwort buderus) - Es fragt und editiert die config für die IP des NET-IO Die autostart funktion muss manuell eingerichtet werden. sudo update-rc.d ems-collector default starten mit /etc/init.d/ems-collector start /etc/init.d/ems-collector stop /etc/init.d/ems-collector raw installieren mit sudo dpkg --install ./ems-buderus_0-4.deb deinstall mit sudo dpkg --remove ems-buderus (löscht nicht die datenbank)
Also ich habe noch mal ausgiebig getestet: Das Gute: Die Installation läuft durch. Anschliessend ist aber /usr/local/sbin leer. Ich habe dann collectord dorthin kopiert. Beim start kommt failed vom collectord. Der Webserver hat keine Verbindung zum ems-Bus, Telnet auf 7777 geht natürlich auch nicht. Dann habe ich collectord manuell gestartet mit:./collectord -u ems -p buderus -d all tcp:192.168.178.190:7950 -> gleiches Bild. Nehme ich die die alte Version von maniac103/ems-collector ist die Datei wesentlich kleiner, aber läuft, allerdings auch nur mit o.g. manuellen Aufruf, wird aber natürlich bei Statistik im Web-Server als veraltet angemeckert. LG
Welche meldung bringt er denn beim installieren? Ich habe extra jede menge text in den install part gepackt. Intressant ist der teil direkt nach dem ersten compilen. Kopiere collectord. Hast du die libboost installiert? Es kann natürlich sein das ich die abhängigkeiten nicht richtig drinne hab und er es gar nicht erstellt bei dir? Geht es denn manuell zu erstellen?
Hallo, wie habt Ihr denn die Teile (Adapterplatine > AVRNetIO) bei euch im Schaltschrank verbaut? Weil ich suche jetzt schon länger noch einem Vernünftigem Gehäuse finde aber nichts. Gruß und Danke Marco
Angehängte Dateien:
-
Gehaeuse.jpg
100 KB
Zum Thema Gehäuse: Ich habe mir auch Gedanken um ein Gehäuse gemacht, damit der fliegende Aufbau wegkommt. Ich habe mich jetzt für eine separate Lösung neben der Heizung entschieden. Die Heizung ist in einem separaten Technikraum im Keller, da passt das auch vom Design. Ich muss aber noch schrauben. Zur Ansicht habe ich mal einen Raspi reingelegt. Der NetIO und die Adapterplatine kommen daneben rein... Das Gehäuse habe ich bei Amazon gefunden: JS7681 Installationsgehäuse mit transparentem Deckel Größe 240x190x110mm, Schutzart: IP 65 gem. DIN EN 60529/DIN 40050; Farbe: Gehäuse grau RAL 7035, Deckel transparent Material: Gehäuse: ABS (UV geschützt), Deckel: Polycarbonat, Schrauben: rostfreies Metall, Abmessungen: Breite: 240mm (B) Höhe: 190mm (A) Tiefe: 110mm, Installationstemperatur: -15°C bis +60°C gem. DIN EN 60670 Mit Montageplatte < 30€, ohne < 20€. Da ist Platz genug drin. Wenn ich das fertig bestückt habe, dann liefere ich noch ein Bild nach. LG Lorenz
Zur Paketinstallation von Lars: Auf dem Raspi hat es letztendlich fast funktioniert, bis auf das Problem mit dem nicht selbst startenden Collector auf dem Raspi. Das habe ich noch nicht im Griff. Z.Zt. erledige ich den Start noch manuell, läuft dann aber seit Wochen stabil. Bislang war die nicht funktionierende Grafik für mich noch Nebensache. Habe mir das aber jetzt angeschaut und gesehen, dass für den Raspi die Anpassung fehlte: Die mysql socket Angabe in der config.py: /var/run/mysqld/mysqld.sock für RaspberryPi/debian wheezy wurde hier auch schon geschrieben. Erledigt und funktioniert, nur der Vollständigkeit halber... Muss mir jetzt auch noch Gedanken über den Cron-Job machen. LG Lorenz P.S. Mittlerweile habe ich eine Verbindung zu fhem über das Modul ECMD erfolgreich eingerichtet, über telnet auf dem Port 7778 (nur Lesen), falls es Jemanden interessiert. Ich habe dazu auch was im Fhem-Forum geschrieben.
Angehängte Dateien:
-
Heizung.jpg
120 KB
Nochmal zum Gehäuse: Ich habe das Wochenende genutzt und den fliegenden Aufbau beseitigt. Zur DV-Verkabelung war es zum Glück nicht weit ;-) LG Lorenz
Angehängte Dateien:
-
emsClient_FHEM.png
47 KB
Die Lösung von Lorenz kann ich nur empfehlen, das war einfch und lüft super!! http://forum.fhem.de/index.php/topic,25688.msg190363.html#msg190363 Gruß, Bernd
Hi! Hat eigentlich schon jemand Fortschritte mit den EMS-Plus Telegrammen gemacht? Ich selbst komme da leider nicht weiter... Was mir momentan noch Fehlt sind die beiden Heizkreise HK1 und HK2 und die ganze Solar-Modul Geschichte... Was ich noch mal zur Verfügung stellen könnte wären Logfiles... Grüße
Hallo, ist es möglich die Daten des AVR Net IO nicht über eine Netzwerkverbindung sondern über eine Serielle Schnittstelle an den Raspi zu übertragen? Ich möchte mir die Schaltung rund um dem ATmega644 selbst zusammenbauen damit ich kein Net IO benutzen muss. Auf das Board soll die EMS-Pegelwandlung auch gleich mit drauf... Nur macht für die 20 cm wo die platinen auseinander sind LAN für mich keinen sinn. Dann lieber nen Pegelwandler zwischen das Net IO und den Raspi. Die Hardware bekomme ich hin, nur mit der Software hapert es... Kann da jemand helfen und mir erklären wie das geht bzw. was an der Soft auf dem ATmega644v dann geändert werden muss? Grüße Andy
Gibt es eigentlich zwischenzeitlich eine Platine für das Projekt? Ich denke, das bspw mit dem ESP8266 eine interessante und einfache Anbindung realisiert werden kann (kein AVR/PIC) und würde da gerne ein wenig "spielen". (Die serielle Schnittstelle erkennt Framing-Errors). Beitrag "Wlan2Serial Modul für 5 euro" http://www.esp8266.com/index.php
Hallo, nach vielen Stunden intensiver Lektüre habe ich meine "Transfer-Strecke" zum Laufen gebracht. Allerdings verhält sich der collector einfach zu ruhig. Die einzige Ausgabe ca. alle 10 (manchmal auch 20) Sekunden: IO: Got bytes 0xaa 0x55 0x1 0xff 0xff MESSAGE[03.10.2014 16:41:23]: source 0x00, dest 0x00, type 0x00, offset 0, data: 0xff Etwas verwundert habe ich danach mal den Status des NetIO nach etwa einer Stunde Laufzeit aufgerufen: Bytes total:149034 Bytes good:201 Bytes dropped:0 Packets good:197 Packets bad:2549 Packets 1byte:129833 229 Packets ack:0 nack:0 Overflow:0 Max fill:4 Warum werden so viele Telegramme verworfen? eine Konfig: GB162 (BC10) mit RC300 Ich weiß, die RC300 wird noch nicht direkt unterstützt, aber die Daten werden ja schon vom Framer gedropt... Woran könnte das liegen? Oder interpretiere ich die Daten falsch? Grüße Fabian
Update: obiges Problem gelöst! Nach einigen Messungen mit eine Oszi habe ich bemerkt, dass die Polarität an den Eingängen des Komparators/OPs falsch war. Grund: ich hatte die Anschlüsse beim Verschalten vertauscht. Argghhh... Umgelötet, läuft! Jetzt hänge ich beim Web-Frontend: Alles lt. Post von Michael (Beitrag "Re: EMS > Adapter > NetIO > Raspi") eingerichtet. EMSCLIENT lief nicht, php nicht gefunden. Klar kein CLI drauf, php5-cli nachinstalliert >> läuft. Webfrontend in den Ordner vom lighttpd kopiert. Erste Unklarheit: Im www-Ordner ist nur ein Link auf graphs enthalten. Muss das auf das aktuelle (in den conf Dateien angegebene) Verzeichnis angepasst werden? Fehler: Mein Webserver bringt statt der Seite nur die Fehlerseite 503. Im Serverlog des lighttpd wird ein fehlender socket (/tmp/php.socket) bemängelt. Lege ich diesen mit touch selbst an, wird vom Webserver "connection refused" gemeldet. Berechtigungen habe ich bis auf die graphs wie aus dem Post von Bernd angepasst. Zweite Unklarheit: Bernd schreibt, dass er die Berechtigungen der Files im Graphs-Ordner angepasst hat. Welche Dateien werden in den Graphs-Ordner kopiert? Irgendwie fehlt mir hier noch ein Stück vom Puzzle... Grüße Fabian
Fa Ke schrieb: > Fehler: > Mein Webserver bringt statt der Seite nur die Fehlerseite 503. Im > Serverlog des lighttpd wird ein fehlender socket (/tmp/php.socket) > bemängelt. Lege ich diesen mit touch selbst an, wird vom Webserver > "connection refused" gemeldet. Hallo Fabian, Du kennst: http://www.cyberciti.biz/tips/lighttpd-php-fastcgi-configuration.html Läuft Dannys Webapplikation? Ansonsten nochmal Pfade und Berechtigungen in Michaels Frontend checken. Du bekommst das hin, wir haben es schließlich auch geschafft. ;) Gruß Karl M.
Mal was anderes: kann ich per FHEM die mit Hm-Tc gemessene Raumtemperatur an den EMS Bus senden? Wenn ja - wie?
Guten Abend, ich stecke beim make für collectord fest, komme nicht mehr weiter und hoffe auf einen Tipp. Ein make für den collectord bringt mir tonnenweise Meldungen wie diese hier: main.cpp:(.text.startup+0x360): undefined reference to `boost::thread::~thread()' Ja, ich habe zuvor mit apt-get install die libboost1.50 Library installiert - exakt so, wie im Wiki angegeben. Ich habe auf meinem Raspi die aktuelle Wheezy drauf, mit allem auf neurstem Stand. Sachdienliche Hinweise sind hochwillkommen. Ich bedanke mich schon jetzt für die sicher zahlreichen Tipps. Danke ! Joshi
Hallo Joshi, ich hatte mich auch an das wiki gehalten und ein ähnliches Problem. Bei mir läuft es nur mit der 1.49er libboost Bibliothek. @all Update für das lighttpd Server-Problem: Es lag an dem eingefügten Teil in der lighttpd.conf
1 | fastcgi.server = ( ".php" => (( |
2 | "bin-path" => "/usr/bin/php-cgi", |
3 | "socket" => "/tmp/php.socket" |
4 | ))) |
der Abschnitt war optisch fehlerfrei und ich hatte ihn mit nano händisch eingetragen, nicht kopiert. Denn gerade bei kopierten Abschnitten hatte ich schlechte Erfahrungen gemacht, wegen manchmal inkorrekter Zeichen. Nach dem Kopieren ging es dann. Ich hoffe, es hilft anderen mit vergleichbaren Problemen. Gruß Fabian
Hi Fabian, danke für den Tipp, probiere ich nachher gleich mal aus. Die Ironie ist, dass er mir beim Installieren der 1.50 Libs gesagt hat, er würde die zuvor installierte 1.49 Lib entfernen -haha. Nochmals vielen Dank! Ich melde mich nachher mit einem Ergebnis - so oder so ;-) Joshi
Hi Fabian, das war's. libboost1.49-all hat's gebracht. Danke für den Tipp !!! Vielleicht kann der Maintainer des Wiki einen entsprechenden Hinweis anbringen, damit sich nicht immer wieder jeder durch den kompletten Thread durchwühlen muss. Danke und noch einen schönen Tag Joshi
Joshi schrieb: > kann der Maintainer des Wiki einen entsprechenden Hinweis > anbringen ... done ... Bei mir zeigt ein: root@home:~# ldconfig -v | grep libboost* libboost_chrono.so.1.50.0 -> libboost_chrono.so.1.50.0 libboost_math_c99.so.1.50.0 -> libboost_math_c99.so.1.50.0 libboost_math_tr1.so.1.50.0 -> libboost_math_tr1.so.1.50.0 libboost_thread.so.1.50.0 -> libboost_thread.so.1.50.0 libboost_python-py32.so.1.50.0 -> libboost_python-py32.so.1.50.0 libboost_mpi_python-py27.so.1.50.0 -> libboost_mpi_python.so libboost_python-py26.so.1.50.0 -> libboost_python-py26.so.1.50.0 libboost_python-py27.so.1.50.0 -> libboost_python.so libboost_math_tr1f.so.1.50.0 -> libboost_math_tr1f.so.1.50.0 libboost_regex.so.1.50.0 -> libboost_regex.so.1.50.0 libboost_wserialization.so.1.50.0 -> libboost_wserialization.so.1.50.0 libboost_unit_test_framework.so.1.50.0 -> libboost_unit_test_framework.so.1.50.0 libboost_random.so.1.50.0 -> libboost_random.so.1.50.0 libboost_program_options.so.1.50.0 -> libboost_program_options.so.1.50.0 libboost_serialization.so.1.50.0 -> libboost_serialization.so.1.50.0 libboost_prg_exec_monitor.so.1.50.0 -> libboost_prg_exec_monitor.so.1.50.0 libboost_mpi.so.1.50.0 -> libboost_mpi.so.1.50.0 libboost_date_time.so.1.50.0 -> libboost_date_time.so.1.50.0 libboost_timer.so.1.50.0 -> libboost_timer.so.1.50.0 libboost_system.so.1.50.0 -> libboost_system.so.1.50.0 libboost_mpi_python-py26.so.1.50.0 -> libboost_mpi_python-py26.so.1.50.0 libboost_wave.so.1.50.0 -> libboost_wave.so.1.50.0 libboost_math_c99f.so.1.50.0 -> libboost_math_c99f.so.1.50.0 libboost_filesystem.so.1.50.0 -> libboost_filesystem.so.1.50.0 libboost_mpi_python-py32.so.1.50.0 -> libboost_mpi_python-py32.so.1.50.0 libboost_graph.so.1.50.0 -> libboost_graph.so.1.50.0 libboost_signals.so.1.50.0 -> libboost_signals.so.1.50.0 libboost_iostreams.so.1.50.0 -> libboost_iostreams.so.1.50.0 libboost_locale.so.1.50.0 -> libboost_locale.so.1.50.0 libboost_graph_parallel.so.1.50.0 -> libboost_graph_parallel.so.1.50.0 ... und damit läuft der collectord ordnungsgemäß durch. Vielleicht kann das mal einer der "Problembehafteten" checken, damit klar wird, woran das liegt. Iirc hatte Bernd das Problem ja auch schon. Gruß aus der Wetterau Karl M.
Hi Charlie, danke für das rasche Einbauen ins Wiki. Ich bin nicht der große c++ Tüftler, deshalb fürchte ich, dass ich nicht viel zur Problemeinkreisung beitragen. Ich habe bei mir auch mal ein ldconfig gemacht (weiß nicht, ob das zur Wahrheitsfindung dienen kann), mit folgendem Ergebnis: libboost_python-py32.so.1.49.0 -> libboost_python-py32.so.1.49.0 libboost_math_tr1.so.1.49.0 -> libboost_math_tr1.so.1.49.0 libboost_mpi_python-py27.so.1.49.0 -> libboost_mpi_python.so libboost_graph_parallel.so.1.49.0 -> libboost_graph_parallel.so.1.49.0 libboost_math_c99.so.1.49.0 -> libboost_math_c99.so.1.49.0 libboost_locale.so.1.49.0 -> libboost_locale.so.1.49.0 libboost_thread.so.1.49.0 -> libboost_thread.so.1.49.0 libboost_wserialization.so.1.49.0 -> libboost_wserialization.so.1.49.0 libboost_python-py27.so.1.49.0 -> libboost_python.so libboost_python-py26.so.1.49.0 -> libboost_python-py26.so.1.49.0 libboost_mpi.so.1.49.0 -> libboost_mpi.so.1.49.0 libboost_serialization.so.1.49.0 -> libboost_serialization.so.1.49.0 libboost_iostreams.so.1.46.1 -> libboost_iostreams.so.1.46.1 libboost_wave.so.1.49.0 -> libboost_wave.so.1.49.0 libboost_timer.so.1.49.0 -> libboost_timer.so.1.49.0 libboost_date_time.so.1.49.0 -> libboost_date_time.so.1.49.0 libboost_prg_exec_monitor.so.1.49.0 -> libboost_prg_exec_monitor.so.1.49.0 libboost_math_tr1f.so.1.49.0 -> libboost_math_tr1f.so.1.49.0 libboost_filesystem.so.1.49.0 -> libboost_filesystem.so.1.49.0 libboost_unit_test_framework.so.1.49.0 -> libboost_unit_test_framework.so.1.49.0 libboost_math_c99f.so.1.49.0 -> libboost_math_c99f.so.1.49.0 libboost_iostreams.so.1.50.0 -> libboost_iostreams.so.1.50.0 libboost_graph.so.1.49.0 -> libboost_graph.so.1.49.0 libboost_chrono.so.1.49.0 -> libboost_chrono.so.1.49.0 libboost_signals.so.1.49.0 -> libboost_signals.so.1.49.0 libboost_iostreams.so.1.49.0 -> libboost_iostreams.so.1.49.0 libboost_random.so.1.49.0 -> libboost_random.so.1.49.0 libboost_system.so.1.49.0 -> libboost_system.so.1.49.0 libboost_iostreams.so.1.48.0 -> libboost_iostreams.so.1.48.0 libboost_mpi_python-py32.so.1.49.0 -> libboost_mpi_python-py32.so.1.49.0 libboost_regex.so.1.49.0 -> libboost_regex.so.1.49.0 libboost_mpi_python-py26.so.1.49.0 -> libboost_mpi_python-py26.so.1.49.0 libboost_program_options.so.1.49.0 -> libboost_program_options.so.1.49.0 Interpretieren kann ich es nicht, da muss leider jemand mit mehr als meinem Basiswissen ran, sorry. Ich bin gerne bereit, noch weiterenfos zu liefern, aber dann muss mir bitte jemand sagen, welche Befehle ich eintippen soll ... Ich habe noch 'ne Frage zum NetIO. Wie kann ich die Netzwerkadresse und die MAC-Adresse ändern ? Ich habe das Hexfile auf den ATMega644 gebrannt. So, wie es im Wiki steht, kann es doch aber nur gehen, wenn mein Netz 192.168.0.xxx wäre - ist es aber nicht, sondern 192.168.178.xxx, mit netmask 255.255.255.0 Über den seriellen Port des NetIO draufzugehen geht bei mir nicht, weil keine COM - Ports, nur USB :-( Nochmal danke an alle und viele Grüße Joshi
Joshi schrieb: > mein Netz 192.168.0.xxx wäre - ist es aber nicht, sondern > 192.168.178.xxx, mit netmask 255.255.255.0 Mal die IP auf Deinem PC in 192.168.0.1 ändern, dann mit: http://192.168.0.0/ecmd?mac „neue MAC“ (Aufkleber ATMega32) http://192.168.0.0/ecmd?ip „neue IP“ (z.B. 192.168.178.200) (vgl. WIKI) Dann PC-IP wieder ändern, wie gehabt. Dein gcc hatte ja mit: main.cpp:(.text.startup+0x360): undefined reference to `boost::thread::~thread()' eine fehlende libboost_thread.so.xxx angemeckert. Ich tippe mal auf unerfüllte Abhängigkeiten bei libboost1.50. Da ist jetzt, nachdem Du auf 1.49 umgestellt hast, natürlich nichts mehr zu sehen. 8) Egal, hauptsache es funzt jetzt! :) Gruß Karl M.
Danke für die schnelle Antwort. Auf die Idee, den NetIO direkt an den PC zu klemmen, bin ich nicht gekommen. Ich wollte ihn auf den Switch (der seinerseits am DSL-Router hängt und massig freie Ports hat) schalten ... Klar, so gehts ! Manchmal sieht man den Wald vor Switches ;-) nicht Danke und noch einen schönen Abend Joshi
Hallo! Darf ich nochmal meine Frage stellen? Mal was anderes: kann ich per FHEM die mit Hm-Tc gemessene Raumtemperatur an den EMS Bus senden? Wenn ja - wie? Wer kann helfen?
Also, wenn ich die Temperatur mittels Homematic hm-tc gemessen und in fhem geholt habe, dann möchte ich einen hk2 aufbauen, der über diese Temperatur gesteuert wird. Ich finde aber in all den Telegrammen den Punkt nicht, wo ich eine ist-Temperatur per telnet:7777 an den collectord senden kann, um das Vorhandensein eines RC35 Raumcontrollers zu simulieren... Bin ich gedanklich völlig daneben oder müsste das irgendwie gehen? Ziel soll es sein, die Fußbodenheizung im Erdgeschoss als Heizkreis 2 von der sonstigen Heizung abzukoppeln und die Umwälzpumpe über einen MM10 zu steuern. Dazu kann ich jetzt entweder die vorhandene Steuerung von Homematic verwenden oder muss eine Neuanschaffung tätigen, die nicht ins Schalterprogramm passt...
Angehängte Dateien:
-
brenner-month.png
7 KB
Guten Abend, ich habe mir eben mal die Graphen angesehen und habe das Problem, dass der Brenner mit dem Heizungsgraphen nicht stimmt. Der Brenner hat teilweise negative Werte. Hat jemand eine Idee woran das liegen könnte, oder wie man zumindest den Graph so begrenz bekommt, dass man nur 0-120% sieht? Gruss Norbert
Habe soetwas bei mir (EMS-Gateway) auch ab und zu mal festgestellt. Bei mir tritt das aber sporadisch auf und nicht in so regelmäßigen Abständen. Bei mir waren es fehlerhafte Telegramme. Sieht so aus als ob es immer Bei der Pumpenmodulation auftritt. Kannst Du bei diesen Telegrammen die Prüfsumme kontrollieren? Gruß Ingo
Kann er nicht, da der NetIO schon die Prüfsumme kontrolliert und das Telegramm verwirft, wenn sie nicht stimmt. Was genau heißt denn 'fehlerhafte Telegramme' bei dir?
Danny Baumann schrieb: > Kann er nicht, da der NetIO schon die Prüfsumme kontrolliert und > das Telegramm verwirft, wenn sie nicht stimmt. > > Was genau heißt denn 'fehlerhafte Telegramme' bei dir? Bei mir sind es ab und zu telegramme mit fehlerhafter Prüfsumme schon auf dem Ems–bus gewesen...
Norbert Schnitzler schrieb: > > ... Der Brenner hat teilweise negative Werte. Hat jemand eine Idee woran > das liegen könnte ... Nabend, sieht evtl. nach einem Wertebereich Problem aus. Möglicherweise wird die Brennerleistung als 8 Bit Signed Integer verarbeitet, da wird dann halt alles ab 127 negativ. //Niffko
Niffko _ schrieb: > sieht evtl. nach einem Wertebereich Problem aus. Möglicherweise wird die > Brennerleistung als 8 Bit Signed Integer verarbeitet, da wird dann halt > alles ab 127 negativ. Mein Code verarbeitet alles als signed int. Das sollte aber kein Problem sein, da 100% ja deutlich kleiner als 127 ist ;) Es wird übrigens erst ab 129 negativ, da 128 'nicht verfügbar' ist (..., 126, 127, NA, -127, -126, ...).
Danny Baumann schrieb: > Mein Code verarbeitet alles als signed int. Das sollte aber kein Problem > sein, da 100% ja deutlich kleiner als 127 ist ;) Hi Danny, es gibt Geräte, die mit einem sogenannten Warmwasserboost arbeiten, d.h. es wird im WW-Betrieb >100% angezeigt. Die WW-Mehrleistung liegt dann auch durchaus in dem kritischen Wertebereich, über den wir hier reden. Tja, der Teufel ist ein Eichhörnchen ... ;) //Niffko
Hmm, ok. Das heißt also, dass die Brenner modulation als unsigned aufzufassen ist - gilt das sowohl für Ist- als auch Soll-Modulation? Und ich gehe mal davon aus, dass es in diesem Fall keinen speziellen Wert für 'nicht verfügbar' gibt, oder?
Ja, Sollwert auch. Das Gerät mit dem größten Boost Anteil dürfte derzeit der GB162-25 T40S sein: Heizleistung 25kW, WW-Leistung 33kW. //Niffko
Hi, Niffko _ schrieb: > Das Gerät mit dem größten Boost Anteil dürfte derzeit der GB162-25 T40S > sein: Heizleistung 25kW, WW-Leistung 33kW. Kann ich bestätigen. Habe das obige Gerät. Bei WW-Bereitung geht "SensorMaxLeistung" auf -114%. Hat mich nie gestört, da ich die MaxLeistung nicht visualisiere. ;) Gruß Karl M.
Fixed: https://github.com/maniac103/ems-collector/commit/77482bfc7557a3c886ab63020da69b8b5400cab1 :) Hatte ich einfach nicht gemerkt, da mein GB132T so etwas nicht macht.
"Systemdruck" könnte über 12,7bar auch negativ werden ;) Dann hätte man allerdings auch andere Probleme ... //Niffko
niffko schrieb: > "Systemdruck" könnte über 12,7bar auch negativ werden ;) Also Laut der KM200 die ich parallel Abfrage habe ich einen Systemdruck von 25.5 Bar?!? (/heatSources/systemPressure) Der Collector zeigt mir -0,1 Bar an... Ich habe aber auch eine RC300 in meiner GB172-14 ... Ach und komischerweise kann ich mit dem gefixten collectord nicht mehr auf das WebInterface zugreifen: FATAL: Keine Verbindung zum EMS-Bus! Grund: Connection refused Habe den Dienst beendet und neu gestartet. Wenn ich ihn manuell per Shell starte habe ich keine Probleme und bekomme die Telegramme angezeigt... Grüße,
Der GB172 hat keinen Drucksensor, daher 8Bit Maximum -> 255. In dem Fall macht es dann doch Sinn, den Parser zu korrigieren. //Niffko
Niffko _ schrieb: > Der GB172 hat keinen Drucksensor, daher 8Bit Maximum -> 255. > > In dem Fall macht es dann doch Sinn, den Parser zu korrigieren. D.h. bei den unsigned-Werten ist 0xff die Repräsentation von 'nicht verfügbar'? Das kann ich natürlich auch noch einbauen...
So mein EMS-Platinchen läuft auch. Habe mir eine einseitige Platine mit dem ATmega644, Spannungsaufbereitung, dem ENC28J60 Netzwerkbrimborium und der Schaltung von Niffko gemacht. Die EMS-RX LED blitzt so 1-2 mal die Minute auf. Schaltung ist mehrfach kontrolliert, stimmt mit dem Layout überein. Falls jemand das Layout will kann ichs hier reinstellen. Platine ist einseitig und nicht zu filigran, kann man also in der heimischen Hexenküche herstellen (ging bei mir auch). Nur die Software bekomm ich nicht zum laufen: Zur Konfig: Der Raspi läuft unter Wheezy, alle pakete aktuell. Anbindung ans Heimnetz über Wlan-Stick, feste IP-Adresse (192.168.0.12) Anbindung der ethersex-Platine über Kabelnetzwerk direkt auf den Raspi, auch feste IP-Adresse (192.168.0.8) Netzwerkbrücke mit einem Wlan geht ja leider mit der aktuellen Distri nicht mehr, wurde aus dem Kerne entfernt. Trage ich in der ems-collector (die Config-Datei unter /etc/default/ als IP die 192.168.0.12 ein bekomme ich ein Connection Refused. Trage ich die 192.168.0.8 ein bekomme ich ein "Host not found (authoritative)" Eine Feste Kabelgebundene Anbindung kann ich dme Raspi leider nicht spendieren sind etliche Wände im Weg, Kabelverlegung nicht möglich. Ich bin also auf Wlan angewiesen. Was Kann ich tun um das ganze zum laufen zu bekommen? Grüße Markus
Nachtrag: Das Ethersex-Board hat die IP 192.168.0.10, auch wenn ich das eintrage in der config-Datei bekomme ich ein Connection refused...
Hallo Markus, > Das Ethersex-Board hat die IP 192.168.0.10 "connection refused" kann auf einen belegten Port oder eine falsche oder unbekannte IP hinweisen. Versuche doch mal von der Konsole ein: collectord -u "db_user" -p "password" tcp:192.168.0.10:7950 Hast Du mal probiert, was der httpd Deiner EMS-Platine zu sagen hat: 192.168.0.10 Falls es da auch ein "connection refused" gibt, tippe ich auf Probleme im Bereich des ENC28J60. hth Karl M.
Hallo, der httpd funktioniert. Stecke ich die ethersex platine an einen switch an kann ich über die ip darauf zugreifen und sehe die startseite "ethersex rulez". Der ENC schein also ok zu sein. ich habe den befehl welchen du oben geschrieben hast eingegeben. es passiert beim drücken auf enter nichts, kommt auch keine fehlermeldung. ist das gut oder schlecht?
Hi, > Der ENC schein also ok zu sein. das ist auch gut so. ;) > passiert beim drücken auf enter nichts, kommt auch keine fehlermeldung auf der console des raspi? irgendetwas muss er sagen. :) evtl. mysql checken: db_user angelegt, rechte eingetragen, passwort vergeben? hth
@charlie-w Datenbankuser und Pass habe ich in den Befehl eingetragen. Sollte auch soweit stimmen User ist ems, Pass ist buderus. Drücke ich dann enter springt die bash in die nächste zeile und erwartet eingaben. Mehr passiert nicht... Ich schau in der mysql Database noch mal nach ob da alles stimmt...
Hab grade noch mal Probiert, allerdings den collectord aufruf mit -f -d all erweitert da bekomme ich "Error: no route to host". Was bedeutet das? Mysql bin ich grade dran, da ich noch nicht viel mit mysql gearbeitet habe ist das aber recht schwer für mich. Ich fress mich grade durchs Manual durch... Kann also etwas dauern. Die Datenbank ems_data ist auf jeden fall da, der benutzer ems hat alle rechte daran. Nur ist in der Datenbank nix drin. Wenn ich mit dem Select-Befehl den inhalt haben will bekomme ich ein "no tables used" angezeigt. Sollte der collectord da nicht die ganzen Sachen anlegen nach dem ersten start?
Markus schrieb: > Die EMS-RX LED blitzt so 1-2 mal die Minute auf. Ich bin jetzt nicht mit ethersex unterwegs, aber nach kurzem Überfliegen von Dannys ethersex-framer code, würde ich sagen, dass die RX-LED bei jedem korrekt empfangenen EMS-Telegramm blinkt. Wenn das so ist, dann sind "1-2 mal die Minute" zu wenig. Das 0x18er z.B. kommt schon alle 10 Sekunden. //Niffko
Oh das klingt nicht gut... Dann werde ich die Schaltung der EMS-Pegelwandlung noch mal ganz genau Kontrollieren. Bei der Heizung handelt es sich übrigends um eine mit einem RC300 Modul drin, habe nachgesehen. In der EMS-Schaltung habe ich für den 10uF Kondensator einen Kerko eingesetzt. Oder muss das unbedingt ein Elko sein? Könnte das das Problem erklären?
Markus schrieb: > ... für den 10uF Kondensator einen Kerko eingesetzt. Und das ist gut so. Ist auf den original Buderusmodulen auch KEIN Elko. //Niffko
Hallo Ich bin dabei dieses Projekt nachzubauen. Habe jetzt das Problem den collectord auf meinem Raspberry zu laufen zubekommen.Es währe schön wenn jemand mir eine Schritt für Schritt anleitung geben könnte. Meine nächste Frage währe ob die grüne LED der Adapterplatine auch blinken sollte wenn nur der Net-io dran hängt also ohne Raspberry. Vielen Dank Stephan PS. Super Projekt genau das was ich gesucht habe. Echt tolle Arbeit.
Hi, > Schritt für Schritt Anleitung wer den Fred ganz gelesen hat, hat jenes gefunden: http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#raspberry_pi > grüne LED auch blinken wenn nur der Net-io dran hängt ja! Die LED Ansteuerung sitzt in Dannys Framer. hth'n greets Karl M.
Danke für die schnelle Antwort. Das habe ich schon probiert kann aber den collectord nicht starten. Ich probiere es grad nochmal aus und melde mich dann nochmal mit der Fehlermeldung. Danke Stephan
Ich habe jetzt versucht den collectord zu installieren. Bekomme aber eine Fehler meldung beim eingeben von : collectord -h Fehlermeldung : -bash: collectord: Kommando nicht gefunden. Stephan
Hallo Stephan, die meisten Anleitungen setzen einige Grundkenntnisse über Linux voraus. Da ich nicht sehr oft mit Linux arbeite, musste ich mich auch erst mal "durchkämpfen". Also erst solltest Du mal sicher stellen, dass Du im richtigen Verzeichnis bist. Nach login mittels terminal (z. B. putty) befindet man sich i. d. R. im home-Verseichnis des Benutzers. pwd gibt an, in welchem Verzeichnis Du gerade bist. Dann in das Verzeichnis des EMS-Collector wechseln Die nächste Hürde ist das Ausführen der Datei: collectord wird dabei nicht gefunden... probiere mal: ./collectord (Optionen und Parameter natürlich nicht vergessen;) Gruß Fabian
Hallo zusammen, ich verfolge den Thread schon einige Zeit. Den Adapter habe ich nachgebaut und nach einigen Schwierigkeiten mit dem Ethersex Hexfile aus dem Wiki zum Laufen gebracht. Ich habe UBA4, BC25, RC300 und SM100 und KM200 am EMS+ Bus. Leider hat der Adapter nach ca. 3 Wochen die Funktion eingestellt. Es kommen keine Daten, meistens antwortet das NETIO mit "connection blocked" und die gelbe LED blinkt nicht mehr. Hat jemand einen Tip, wo ich anfangen soll, den Fehler zu suchen? Ich hatte schon ein paar Daten auf dem EMS+ entschlüsselt und wollte weitersuchen indem ich über den KM200 gezielt Daten abfrage. Leider stehe ich jetzt wieder (fast) am Anfang. Grüße, Torsten
Hallo, vielleicht kann jemand von euch hier besser weiterhelfen... Dort hat jemand wohl Probleme mit der Adapterplatine vom NetIO. Beitrag "EMS-NetIO not running"
Hi Torsten, check noch mal deine Platine - kalte Lötstellen o.ä. Verbindungen alle sauber gesteckt/verschraubt? Alles stromlos gemacht? So die Klassiker halt. Ich habe auf den Punkt genau dein Setup was die Anlage betrifft ;-) Läuft seit einigen Monaten ohne Probleme... Gruß
Hallo, ich habe das Projekt verfolgt und auch nachgebaut: Heizung ist die GB172 mit RC300, d.h. ich erwarte, das nicht alle Daten erkannt werden, da ein EMS+ Anteil dabei sein wird. An der Heizung ist ein NetIO mit der Anpassungsschaltung auf Lochrasterplatine. Das scheint auch zu funktionieren. Den Collector möchte ich auf einem Cubietruck laufen lassen, habe es aber auch auf meinem Raspberry PI getestet. Aber ich habe jetzt auf beiden Rechnern folgendes Problem: Wenn ich den Collector mit der Option -f und -d all starte kommen vernünftige Ausgaben, bis zur ersten Prozentangabe, dann bricht das Programm ab:
1 | IO: Got bytes 0xaa 0x55 0xa 0x10 00 0xff 0xd 0x1 0xa5 0x1 0xb5 00 0x67 0x95 |
2 | MESSAGE[29.11.2014 00:42:58]: source 0x10, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x01 0xb5 0x00 0x67 |
3 | DATA: Unhandled message received(source 0x10, type 0xff). |
4 | IO: Got bytes 0xaa 0x55 0x19 0x8 00 0x2a 00 00 00 00 00 00 00 00 00 0xcc 00 0xcc 0x80 00 00 0x80 00 0x80 00 0x80 00 00 0x22 |
5 | MESSAGE[29.11.2014 00:43:03]: source 0x08, dest 0x00, type 0x2a, offset 0, data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xcc 0x00 0xcc 0x80 0x00 0x00 0x80 0x00 0x80 0x00 0x80 0x00 0x00 |
6 | DATA: Unhandled message received(source 0x08, type 0x2a). |
7 | IO: Got bytes 0xaa 0x55 0x17 0x8 00 0x34 00 0xb 0x2 0x34 0x2 0x34 0x20 00 00 0x4 00 00 0x50 0x90 00 0x4 0x88 00 0x80 00 0xdf |
8 | MESSAGE[29.11.2014 00:43:04]: source 0x08, dest 0x00, type 0x34, offset 0, data: 0x0b 0x02 0x34 0x02 0x34 0x20 0x00 0x00 0x04 0x00 0x00 0x50 0x90 0x00 0x04 0x88 0x00 0x80 0x00 |
9 | DATA: Warmwasser-Solltemperatur = 11 °C |
10 | DATA: Warmwasser-Isttemperatur = 56.4 °C |
11 | DATA: WW-Bereitungszeit = 20624 min |
12 | DATA: WW-Bereitungen = 1160 |
13 | DATA: Warmwasser-Tagbetrieb = AUS |
14 | DATA: Warmwasser-Einmalladung = AUS |
15 | DATA: Warmwasser-Therm. Desinfektion = AUS |
16 | DATA: WW-Bereitung = AUS |
17 | DATA: Warmwasser-Nachladung = AUS |
18 | DATA: WW-Temperatur OK = AN |
19 | DATA: Zirkulation-Tagbetrieb = AUS |
20 | DATA: Zirkulation = AUS |
21 | DATA: WW-System-Typ = Speicherladesystem |
22 | IO: Got bytes 0xaa 0x55 0x1d 0x8 00 0x18 00 0x29 0x1 0xc0 0x64 0x19 0x9 0x1 0x25 0x40 00 0xed 0x2 0x34 0x80 00 00 0xa7 0xff 0x2d 0x48 00 0xc8 00 0x2 00 0x44 |
23 | MESSAGE[29.11.2014 00:43:04]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x29 0x01 0xc0 0x64 0x19 0x09 0x01 0x25 0x40 0x00 0xed 0x02 0x34 0x80 0x00 0x00 0xa7 0xff 0x2d 0x48 0x00 0xc8 0x00 0x02 0x00 |
24 | DATA: Kessel-Solltemperatur = 41 °C |
25 | DATA: Kessel-Isttemperatur = 44.8 °C |
26 | DATA: Warmwasser-Isttemperatur = 56.4 °C |
27 | DATA: Rücklauf-Isttemperatur = nicht verfügbar |
28 | DATA: Brenner-Sollwert Modulation = 100 % |
29 | terminate called after throwing an instance of 'boost::bad_get' |
30 | what(): boost::bad_get: failed value get using boost::get |
31 | Aborted |
Da ich nicht so firm in C++ bin und auch das Collectorprogramm nicht wirklich durchschaue, hat jemend eine Ahnung was hier los ist? übrigens ist das Verhalten auf Cubietruck und PI exakt gleich. Gruß Heiner
Ich habe jetzt die Version vom März von Moosy Kompiliert. Jetzt funzts Heiner
Hallo zusammen, Erst einmal ein fettes Danke an alle Beteiligten für die bisherige Arbeit. Habe die Platine vorhin zusammen gebaut und soeben an meine GB172 mit RC200 angeschlossen. Was soll ich sagen? Es kamen sofort Daten auf die Status Seite :) Heiners Problem kann ich dennoch hier reproduzieren:
1 | IO: Got bytes 0xaa 0x55 0x1f 0x8 00 0x19 00 00 0x21 0x80 00 0x80 00 00 00 00 0xa 00 0x3 0x17 00 0x13 0xf1 00 00 00 00 0x13 0xf1 00 0x3 0x17 0x80 00 0xba |
2 | MESSAGE[03.12.2014 23:14:15]: source 0x08, dest 0x00, type 0x19, offset 0, data: 0x00 0x21 0x80 0x00 0x80 0x00 0x00 0x00 0x00 0x0a 0x00 0x03 0x17 0x00 0x13 0xf1 0x00 0x00 0x00 0x00 0x13 0xf1 0x00 0x03 0x17 0x80 0x00 |
3 | DATA: AuÃen-Isttemperatur = 3.3 °C |
4 | DATA: Wärmetauscher-Isttemperatur = nicht verfügbar |
5 | DATA: Abgas-Isttemperatur = nicht verfügbar |
6 | DATA: Kesselpumpe-Istwert Modulation = 10 % |
7 | terminate called after throwing an instance of 'boost::bad_get' |
8 | what(): boost::bad_get: failed value get using boost::get |
9 | Abgebrochen |
Danach beendet sich collectord. Die Version von Moosy läuft hingegen. Leider scheinen noch Daten wie z.b. Raumtemp ist/soll und Brennerstarts und Laufzeit zu fehlen. Weiss vielleicht jemand wie ich diese Daten noch anzeigen lassen kann?
Ich denke mal, der Fehler hängt mit den letzten beiden Commits zusammen, die Danny gemacht hat (Stichwort: unsigned Int). Habe schon mal über den Code geschaut, aber C++ ist nicht so meins. Danny?! //Niffko
Angehängte Dateien:
-
snip.JPG
100 KB
Ok, funktioniert jetzt, Danke. Allerdings fehlen mir leider noch Daten, siehe angehängtes Bild. Primär: Brennerstarts, -Laufzeit und Raumtemp. Hat vielleicht jemand eine Idee woran das liegen könnte?
Hallo, ich habe mir einen Atmega1284p für den AVR-Net-IO gekauft. Kann ich die gleichen Fuse Einstellungen wie für den 644p verwenden? Fuse Low Byte (FLB) = e7 Fuse High Byte (FHB) = dc Extended Fuse Byte (EFB) = ff Danke!
Frank S. schrieb: > Primär: Brennerstarts, -Laufzeit und Raumtemp. > Hat vielleicht jemand eine Idee woran das liegen könnte? Niemand eine Idee?
Ok, habe ein bissel gesucht. Es kommen keine Daten der Sensoren 19 und 20 in die Datenbank. Daten von 19 oder 20 kann ich aber über telnet 7778 sehen. Irgendwie schreibt collectord diese beiden Werte nicht in die Datenbank. Wenn ich "händig" Werte in die Datenbank schreibe, klappt auch die Anzeige mit diesen Werten. Raumtemp habe ich über Telnet auch nicht gefunden. Zu meiner Konfiguration: GW172 + RC200 (kein RC35). Dementsprechend sehe ich auch keine Telegramme von 0x10. Nur von 0x8 und 0x18. Ich glaube letzteres müsste RC200 sein?
Frank S. schrieb: > Ok, habe ein bissel gesucht. > Es kommen keine Daten der Sensoren 19 und 20 in die Datenbank. Daten von > 19 oder 20 kann ich aber über telnet 7778 sehen. Irgendwie schreibt > collectord diese beiden Werte nicht in die Datenbank. Wenn ich "händig" > Werte in die Datenbank schreibe, klappt auch die Anzeige mit diesen > Werten. Danke für das Debugging - der Moosy hat's kaputt gemacht ;-) Schau mal, ob es jetzt funktioniert. > Raumtemp habe ich über Telnet auch nicht gefunden. > Zu meiner Konfiguration: GW172 + RC200 (kein RC35). Das erklärt die fehlende Raumtemperatur, die wird vom RC3x gemessen. > Dementsprechend sehe ich auch keine Telegramme von 0x10. Nur von 0x8 und > 0x18. > Ich glaube letzteres müsste RC200 sein? Davon gehe ich mal aus, zumindest ist mir die Adresse bislang nicht anderweitig bekannt.
Prima, Danke. Die Anzeige der Brennerstarts und Zeit funktioniert jetzt. Nunja, da bei mir der RC200 die Raumtemp misst und ich mir deswegen nicht extra ein RC35 kaufen möchte, muss ich wohl hier ein bissel forschen... Leider sind die Ausgaben wohl eher EMS-Plus wie es bisher aussieht.
Moin zusammen, ich will mir demnächst auch den EMS Adapter inklusive NetIO aufbauen. Ein Raspi mit FHEM ist schon in Betrieb. Bezüglich der Spannungsversorgung habe ich noch eine Frage: Der NetIO soll laut Anleitung über ein 5V/1A Schaltnetzteil an Pin J6 angeschlossen werden. Was ist mit dem EMS Adapter? Wird dieser über die EXT Klemme des NetIO mit versorgt, oder benötigt er eine separate Versorgung über die 2-polige Anschlussklemme? Danke und Gruß, Ulf
Hallo Ulf, Ulf K. schrieb: > Wird dieser über die EXT Klemme des NetIO mit versorgt Ja, siehe Schaltplan: http://ems-gateway.myds.me/dokuwiki/lib/exe/detail.php?id=wiki%3Aems%3Anet_io&media=wiki:ems:ems-netio.png Pin 9 = GND, Pin 10 = VCC (+5V) > 2-polige Anschlussklemme = EMS (RC) hth'n greets Karl M.
Ah, jetzt hab ichs verstanden. Die 2-polige Klemme ist für den EMS und die 3-polige für den optionalen 1-Wire Anschluss. Danke Karl. Ich melde mich dann wieder wenns läuft (und andernfalls wahrscheinlich auch ;-) )
Hallo, hat jemand eine Eagel-Board-Vorlage von Niffkos Schaltplan für mich und kann mir die zur Verfügung stellen. Würde mir gerne am Wochenenden ein Board ätzen. Danke Mirko
Maciej Piliński schrieb: > Ich entwarf und erbaut Platinnen von Igor F. Diagramm > (http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io). Das Layout ist allerdings nicht von mir. Glaube es war von Niffko. Danke dass Du Dir die Mühe gemacht hast. Kann ich den auch in den Download vom Wiki packen? Edit: Ups... Der Beitrag ist ja schon etwas älter.... Habe ich erst durch die Änderung im Wiki mitbekommen...
So, das Gateway ist aufgebaut. Ich bekomme aber immer ein "FATAL: Keine Verbindung zum EMS-Bus! Grund: Connection refused" kann mir jemand ein HEX-File für den 1284P schicken? Gruß Mirko
Mirko Rüther schrieb: > So, das Gateway ist aufgebaut. Ich bekomme aber immer ein "FATAL: Keine > Verbindung zum EMS-Bus! Grund: Connection refused" kann mir jemand ein > HEX-File für den 1284P schicken? > Habe das ganze jetzt mit dem 644p am laufen. Jetzt verwirren mich die ems-stats: Bytes total:61653 Bytes good:219 Bytes dropped:0 Packets good:53 Packets bad:2512 Packets 1byte:234 0 Packets ack:0 nack:0 Overflow:1793 Max fill:4 Wo kann der Fehler liegen? So viele Packets bad können doch nicht normal sein. Gruß Mirko
Hallo, bin vor einigen Tagen auf dieses Projekt gestoßen und seitdem versuche ich es für mich umzusetzen. bisher habe ich: - NetIO zusammengebaut - NetIO gestestet -> OK - 644P eingebaut und geflasht - Die Fuse vom 644P sind -> OK - IP Mac GW! vergeben <- so geht's auch über Powerlan ;-) - Ethersex Webserver geht auf - EMS-NetIO-Adapter auf Lochraster aufgebaut (fehlende Brücke berücksichtigt) - 1-Wire Sensor am EMS-NetIO-Adapter -> OK - mySql gedönze auf Raspi installiert - EMS-NetIO-Adapter an der RC-Buchse meines Buderus G135 mit BC10 und RC30 angeschlossen. - collector mit Make kompiliert - collectord gestartet Ich bekomme leider keine Telegramme und auch die Led's auf dem EMS-NetIO-Adapter blitzen nicht auf. Den Aufbau des EMS-NetIO-Adapter habe ich schon x-mal überprüft, ohne einen Fehler gefunden zu haben, was aber nichts heisen mag. :-p Leuchten die Led's sofort auf wenn die Strecke EMS > Adapter > NetIO aufgebaut wurde oder erst wenn der collectord auf dem Raspi fehlerfrei läuft? Grüße Martin
Hallo Martin, Martin Berger schrieb: > Led's auf dem EMS-NetIO-Adapter blitzen nicht Das sollten die aber! Die Led-Blinzelei hat Danny im Ethersex versteckt. 10-pol Stecker korrekt? Spannung am Adapter? Wie hoch ist der Ruhestrom zwichen NetIO und Adapter? Adapter noch mal checken! Der NetIO scheint ja zu laufen. Danke für den Hinweis mit dem GW! Hatte ich doch glatt unterschlagen. ;-) Gutes Gelingen und Gruß Karl M.
Angehängte Dateien:
-
net-io.jpg
190 KB
Habe mir mal das Layout der Leiterplatte von Maciej Piliński angeschaut. Laut Schaltplan kommt der IC weder mit Masse, noch mit +5V direkt in Verbindung. Auf der Leiterplatte liegen aber sowohl Masse als auch 5+V am IC an. Da ist was schief gelaufen glaube ich.
Ah... 4 ist Masse und 8 ist +5V.... Sorry bin Anfänger. ;) aber das im markierten Kreis sieht doch aber aus, als wenn Masse und +5V zusammenkommen? Ich glaube, ich muss das mal messen.
Angehängte Dateien:
-
Unbenannt.png
340 KB
Das ist ein größeres Problem... Habe mir die Datei angesehen und musste feststellen dass alle Polygone im GND Layer sind habe mal bei mir das "+5V"-Netz und die Polygone hervorgehoben. Hoffentlich klappt es noch an den Stellen die Polygone frei zu schneiden...
Hi Karl, vielen Dank für deine Unterstützung. ;-) Karl M. schrieb: >Das sollten die aber! Die Led-Blinzelei hat Danny im Ethersex versteckt. >10-pol Stecker korrekt? >Spannung am Adapter? >Wie hoch ist der Ruhestrom zwichen NetIO und Adapter? >Adapter noch mal checken! - 10-pol Stecker -> OK, habe die Verbindung bis zum 644p durchgemessen. :-o - Spannung am Adapter -> 5V -> OK - Ruhestrom zwischen NetIO und Adapter -> 2,4mA - Aufbau 3 weitere male überprüft. :-( - Spannung am EMS-Bus 12,4V Bei dem Lochrasteraufbau hier aus dem Forum und im Wiki sind übrigens Comperator A mit B mit dem Schaltplan vertauscht, da sie "Pin" Kompatibel sind, ist es egal. Habe mir jetzt ein Oszi von der Firma ausgeliehen. An den - und + Eingänge des RX Comperators sehe ich die EMS Burst ankommen, der Pegel wird dabei allerdings nur um ca: 5 Volt gesenkt, ist das Normal? Der Ausgang des Comperators liegt permanent auf GND sobald ich das EMS Kabel anschließe, ohne EMS ist der Pegel bei +5V. Den LM393 habe ich schon gewechselt, das einzigste was ich nicht messen (mangels Messgerät) kann, sind die Kapazitäten. Der 1nF ist ein Kerko und 10uF ist ein BiPolar, das sind meine Favoriten das der Aufbau nicht funktioniert. :-( Grüße Martin
So Fehler gefunden, fehlende Verbindung zwischen der D6 und GND. Grrrrrrrr
Ich bastle momentan an einer Lösung, bei der das NETIO Modul vollständig durch ein ESP8266 (momentan -01, später -012er) ersetzt wird. Lesender Betrieb vom EMS-Bus läuft bereits - dank einer 128-Byte FIFO und einer sauberen BRK-Erkennung in der Hardware war dies trotz mangelnder Doku relativ einfach umzusetzen. Hier mal ein kleiner Auszug aus den empfangenen Daten ([timestamp, statusreg, fifolänge] <emsdaten> CRC)
1 | [ 3731.896138 080 2] 10 10 00 |
2 | [ 3731.921680 080 4] 09 00 9d 12 |
3 | [ 3731.952230 080 2] 09 09 00 |
4 | [ 3731.978570 080 2] a5 a5 00 |
5 | [ 3732.007318 080 4] 09 00 90 12 |
6 | [ 3732.036007 080 3] 00 ad 00 |
7 | [ 3732.065145 080 2] 09 09 00 |
8 | [ 3732.101361 080 2] 90 90 00 |
9 | [ 3732.166195 080 14] 10 00 06 00 0f 01 08 14 21 19 01 00 38 38 |
10 | [ 3732.435730 080 22] 10 00 3e 00 80 02 2c 7d 00 00 00 00 00 00 00 00 64 11 3c 00 06 06 |
11 | [ 3732.622531 080 2] 10 10 00 |
12 | [ 3732.634806 080 2] 09 09 00 |
13 | [ 3732.670815 080 2] 89 89 00 |
14 | [ 3732.685487 080 2] 90 90 00 |
15 | [ 3732.726075 080 2] 89 89 00 |
16 | [ 3732.740234 080 4] 90 00 10 39 |
17 | [ 3732.768651 080 2] cd cd 00 |
Momentan gibt es ab und an noch kleine Fehler, hauptsächlich bei den Poll-Requests. Die Ursache hierfür ist mit hoher Wahrscheinlichkeit eine zu hochohmige Verbindung zwischem dem LM339 und dem Rx-Eingang des ESP, bei dem das Signal nicht sauber bis auf GND gezogen wird. Interessanterweise tritt dieses Problem nur bei "Poll-Requests" auf dem EMS-Bus auf (Bsp: 90 00 10 39 - Break nicht sauber erkannt). Für das weiter Vorgehen fehlt mir noch die Information, wie NETIO und collectord zusammenspielen. Arbeitet das NETIO-Modul als TCP client Richtung collectord? Wenn ja, welcher Port wird dann für die Telegramme verwendet? Falls NETIO als Server/Listener arbeitet bräuchte ich noch ein wenig Info zum verwendeten Protokoll zwischen collectord und NETIO.
Juergen O. schrieb: > Für das weiter Vorgehen fehlt mir noch die Information, wie NETIO und > collectord zusammenspielen. > Arbeitet das NETIO-Modul als TCP client Richtung collectord? Wenn ja, > welcher Port wird dann für die Telegramme verwendet? > Falls NETIO als Server/Listener arbeitet bräuchte ich noch ein wenig > Info zum verwendeten Protokoll zwischen collectord und NETIO. Das NETIO ist der Server, collectord der Client. Die empfangenen Telegramme sendet der NETIO in diesem Format: <0xaa> <0x55> <length> <data0> ... <dataX> <csum> csum ist dabei ein running XOR über alle Datenbytes. Diese Checksummen-Prüfung wäre zwar bei TCP nicht nötig gewesen, ich wollte aber das Protokoll der seriellen Übertragung (frühere Variante mit Atmega8) und der TCP-Übertragung gleich halten. Die Datenbytes sind das komplette EMS-Telegramm, d.h. <source> <dest> <type> usw., allerdings ohne EMS-Prüfsumme, denn die wird vom NETIO überprüft. Gesendet werden die Telegramme im EMS-Format ohne Angabe der Quelladresse und EMS-Prüfsumme (beides fügt der NETIO hinzu).
Ok - stark abstrahiert also auf der NETIO-Seite
wait_for_connection()
while connected()
if (ems_rx_full) // EMS liefert Daten
tcp_send_pkg() // Daten an Collectord
if (tcp_rx_full) // collectord liefert Paket
ems_send_pkg() // Paket an EMS senden
end_while
Ich nehme an, das alle Daten (auch die Poll-Requests) gesendet werden
und der collectod selbst die Connection neu aufbaut, sofern diese mal
einschlafen sollte...
Nachtrag: wie wird das Polling der eigenen Adresse (0x8b) gehandhabt? Durchreichen und bearbeiten durch den collectord oder "shortcut", d.h. NETIO antworted mit "nichts zu senden" (0x0b)?
Juergen O. schrieb: > Ok - stark abstrahiert also auf der NETIO-Seite > > wait_for_connection() > while connected() > if (ems_rx_full) // EMS liefert Daten > tcp_send_pkg() // Daten an Collectord > if (tcp_rx_full) // collectord liefert Paket > ems_send_pkg() // Paket an EMS senden > end_while Jain. Im Prinzip ist es richtig, allerdings empfängt (und zählt) mein Ethersex-Code auch dann EMS-Traffic, wenn kein Client verbunden ist. > Ich nehme an, das alle Daten (auch die Poll-Requests) gesendet werden > und der collectod selbst die Connection neu aufbaut, sofern diese mal > einschlafen sollte... Ja, der collectord hat einen Watchdog, der die Verbindung bei Bedarf neu aufbaut. Poll-Requests sendet der NETIO allerdings nicht an den collectord, sondern nur Pakete mit Nutzdaten. Juergen O. schrieb: > Nachtrag: > wie wird das Polling der eigenen Adresse (0x8b) gehandhabt? > Durchreichen und bearbeiten durch den collectord oder "shortcut", d.h. > NETIO antworted mit "nichts zu senden" (0x0b)? Shortcut. Der NETIO antwortet normalerweise mit 0x0b. Wenn er Daten via TCP empfangen hat, sendet er diese und geht danach zu 0x0b über.
Prima! Das heisst, NETIO puffer im letzten Falle das Paket vom collectord bis zum nächsten 0x8b?
Juergen O. schrieb: > und einer sauberen BRK-Erkennung in der Hardware Was heisst BRK-Erkennung in der Hardware? Bedeutet dass das Du auch automatisch das Break über Hardware sendest? Frage nur weil ich auf dem EMS-Bus Probleme am Anfang hatte. Der PIC kann auch ein Break durch die Hardware senden. Allerdings gab es dabei Probleme auf dem EMS-Bus. Weiss nicht mehr genau welches Problem es war. Klingt aber so ähnlich wie Dein Problem. Der UART im PIC sendet ein sehr langes Break. Vermutlich um sicher zu gehen dass es auch bei geringerer Baudrate verstanden wird. Ich habe damals das Break dann über Software gemacht. Also UART ausschalten und den Port für die Dauer eines Breaks auf "0" gesetzt und dannach wieder zurückgesetzt und UART wieder eingeschaltet. Kann es sein dass das auch bei Dir der Fall sein könnte? Selbst wenn es das nicht sein sollte würde ich auf jeden Fall darauf achten dass das Break nur so lange gesendet wird wie es nötig ist (also 10 Bitlängen) Gruß Ingo
Juergen O. schrieb: > Ich bastle momentan an einer Lösung, bei der das NETIO Modul vollständig > durch ein ESP8266 (momentan -01, später -012er) ersetzt wird. ... äähhm! Will ja Euch Fachleuten nicht dazwischen reden, aber wäre es nicht angebracht, für dieses eigene Thema einen eigenen Thread zu eröffnen? Just my 0,02$.
Scheiße ;) Damit war die Leiterplatte glatt fürn Popo :) Habs auch erst gecheckt, als ich die 4x910 Widerstände löten wollte und stellte fest, dass die gar nicht an Masse kommen dürfen aber komplett auf Masse liegen. Ich glaube ich mach mir nun meine eigene Leiterplatte. Da ich die sowieso nicht als shuttle auf das netio schraube, kann ich etwas "freier" sein. Also nach dem Spiel ist vor dem Spiel ;)
Angehängte Dateien:
-
ww-hour.png
5,6 KB
Ich habe jetzt das Problem das die Raumtemperatur bei Konstant +3200°C liegt und beim WW-Speicher wechselt die Temperatur zwischen -3200°C und dem reellem Wert. Bei der Regelführungsgröße wird Raumtemperatur an stelle der Außentemperatur geführten interpretiert. Soweit ich das jetzt verstanden habe ist dafür der Collector verantwortlich und müsste angepasst werden? Ich habe eine RC30 V2.02 sowie BC10 2.0 mit UBA 2.01 sowie das Frontend von Mosi installiert.
Zwei Probleme beim Bau des collectord: 1.boost_thread-mt gibt es bei neuerem Boost nicht mehr 2.Linker commandline versagt bei neueren Linkern (Optimierung) Ich kann kein Issue in moosy/ems-collector öffnen - deshalb der Fix auf diesem Weg...
1 | diff --git a/collector/Makefile b/collector/Makefile
|
2 | index fec2d53..ae74844 100644
|
3 | --- a/collector/Makefile
|
4 | +++ b/collector/Makefile
|
5 | @@ -1,6 +1,6 @@
|
6 | CC = g++ |
7 | CFLAGS = -Wall -c -O2 -I/usr/include/mysql -std=c++0x |
8 | -LIBS = -lpthread -lboost_system -lboost_thread-mt -lboost_program_options -lmysqlpp
|
9 | +LIBS = -lpthread -lboost_system -lboost_thread -lboost_program_options -lmysqlclient -lmysqlpp
|
10 | SRCS = main.cpp IoHandler.cpp SerialHandler.cpp TcpHandler.cpp CommandHandler.cpp \ |
11 | EmsMessage.cpp Database.cpp Options.cpp PidFile.cpp |
12 | OBJS = $(SRCS:%.cpp=%.o) |
13 | @@ -19,7 +19,7 @@ $(DEPFILE): $(SRCS)
|
14 | -include $(DEPFILE) |
15 | |
16 | collectord: $(OBJS) $(DEPFILE) Makefile |
17 | - $(CC) $(LIBS) -o collectord $(OBJS)
|
18 | + $(CC) -o collectord $(OBJS) $(LIBS)
|
19 | |
20 | %.o: %.cpp |
21 | $(CC) $(CFLAGS) $< |
Juergen O. schrieb: > Zwei Probleme beim Bau des collectord: > 1.boost_thread-mt gibt es bei neuerem Boost nicht mehr > 2.Linker commandline versagt bei neueren Linkern (Optimierung) > > Ich kann kein Issue in moosy/ems-collector öffnen - deshalb der Fix auf > diesem Weg... Wie wär's, wenn du das einzige noch gepflegte Collector-Repo nehmen würdest? ;) https://github.com/maniac103/ems-collector (Da sind, neben anderen Dingen, genau diese beiden Dinge schon gefixt.)
Hallo, ich bin auch gerade dran mir eine komplette Busplatine zu bauen, also den EMS-Teil (über kleinen DC/DC-Wandler und zwei 6n137 Optokoppler von uC-Teil isoliert) und den uC Teil mit einem ATmega644P. Da ich nicht immer mit dem ICSP Flashen will, spricht was gegen den Einsatz von einen Bootloader? (Der von Chip45.com ist ganz gut, oder meinetwegen auch der Bascom-Bootloader) Der erste Hardware-UART ist ja noch frei und kann somit auf eine Stiftleiste geführt werden. Da kann man dann mit einem USB-TTL-Wandler (FT232 usw) schnell "Andocken" wenn man das Programm nach Änderungen neu hochladen will. LG Martin
Hallo, ich habe mir den Net-IO incl. EMS Adapter nachgebaut, mit den Bauteilen aus dem Warenkorb: https://secure.reichelt.de/index.html?&ACTION=20&AWKID=1000020&PROVID=2084 Grundsätzlich scheint alles zulaufen jedoch habe ich kaum gute Packete: http://192.168.178.11/ecmd?ems%20stats Bytes total:4603 Bytes good:3 Bytes dropped:0 Packets good:3 Packets bad:201 Packets 1byte:16 0 Packets ack:0 nack:0 Overflow:343 Max fill:4 Woran kann das liegen? Wie lang darf/soll die Verbindung Net-IO <-> EMS Platine sein? Danke
Stimmen die „Fuses“ des ATmega644P den? Sie sollten ja wie folgt eingestellt sein: Fuse Low Byte (FLB) = e7, Fuse High Byte (FHB) = dc, Extended Fuse Byte (EFB) = ff. Da das Verbindungskabel nicht geschirmt ist sollte es meiner Meinung so kurz wie möglich sein um nicht als Antenne zu fungieren.
Jochen schrieb: > Wie lang darf/soll die Verbindung Net-IO <-> EMS > Platine sein? Normalerweise dürfte die Verbindung mit RS232 bei 9600 Baud etwa 150m lang sein. Dort wird allerdings ein Pegel von +-12 verwendet. Bei der NetIO-Platine sind 0 bis 5V. Wie lang die Verbindung dabei sein kann ist mir unbekannt. Welche Länge hast Du denn bei Deiner Verbindung? Eventuell könnte es ja auch helfen verdillte Adern zu nehmen. Also ein Ader RX und GND und die andere Doppelader TX und GND. Ein paar cm sollten wohl kein Problem sein. Kann aber durchaus sein dass die Baudratenberechnung etwas "verbogen" sein. Das sind dann wohl die von Martin genannten Fuses sein.
Hallo, Ich benutze RC35 zum Kessel verbunden mit RC-Terminal. Wie kann ich die NETIO Adapter an Kessel? Ist das zu gleichen RC Terminal parallel RC35 angeschlossenen Adapter? vielen Dank für die Infos ...
Taner A. schrieb: > Hallo, > > Ich benutze RC35 zum Kessel verbunden mit RC-Terminal. Wie kann ich die > NETIO Adapter an Kessel? Ist das zu gleichen RC Terminal parallel RC35 > angeschlossenen Adapter? > > vielen Dank für die Infos ... Hallo, der Adapter kann parallel an der gleichen Klemme zum RC35 angeschlossen werden
Angehängte Dateien:
-
ems-gateway.jpg
54 KB
Liebe EMS-Gateway-Freunde, zuerst das Positive. Ich habe es als Newbie dank eurer Hilfe geschaft, den AVR-NETIO mit neuem Chip auszustatten und diesen mit dem HEX-File zu "brennen". :) ein "http://meinedomain/ecmd?ems stats" gibt aus: Bytes total:0 Bytes good:0 Bytes dropped:0 Packets good:0 Packets bad:0 Packets 1byte:0 0 Packets ack:0 nack:0 Overflow:0 Max fill:0 Nun habe ich mir vom angebotenen Schaltplan eine Platine erstellt. den 1wire habe ich ganz weggelassen und den 3-pol EMS-Anschluss zu einem 2-pol geändert. Die bestückte Platine findet Ihr im Anhang. Die o.g. Freude ist natürlich nur "bedingt", da ich auch die Platine angeschlossen habe und sie offensichtlich nicht funktioniert. Da ich den Eagle-Schaltplan genommen habe, schließe ich hier Fehler aus. Ich würde den Fehler wie folgt eingrenzen: 1. Überprüfung auf Bestückungsverwechlung 2. Überprüfun auf "falsche" Bauteile Da ich bei Widerständen kein großes "Falschteil-Potential" sehe, vermute ich Fehler bei Transitor und Kondensatoren. (Bezeichnung ist Reichelt-Artikelnummer) Ich habe als Transistor: T1: BC107B und als Kondensatoren: C1: Z5U 100n C2: KERKO 10n C3: KERKO 1,5n C4: X7R-5 1n C5: TANTAL 10/16 (10µ) C6: KERKO 68p Ich hatte noch alternativ einen TON 10/63 für den C6 in der Bauteileliste. Der erschien mir jedoch zu groß und daher habe ich "eigenmächtig" den TANTAL genommen. Kann jemand von Euch einschätzen, ob ich was bei den Bauteilen falsch gemacht habe? Vielen Dank für die Hilfe.
Hi, > ob ich was bei den Bauteilen falsch > gemacht habe? Platine --> nice! Nur, anhand des Bildes nicht prüfbar. *Wusste gar nicht, dass es noch Transis im TO-18 gibt. ;-)* Denke, dass es nicht die Bauteile sind. Verdrahtung, Anschlüsse checken! Spannungen nachmessen! Fuses? So das Übliche halt. Gutes Gelingen und Gruß! Karl M.
Hallo Karl, http://meineip/ecmd?fuse gibt aus: Fuses: low=62 high=99 ex=FF lock=FF Ist das so ok, oder müssen da andere Werte stehen? Wenn ja, wie kann ich das ändern? P.S. Ich tue mich schon schwer, das Datum zu ändern, ist immer noch auf: Thu 01.01.1970 01:00:15 +1:00 Bisherige Checks: 5V auf Bord von NETIO Lötstellen den 10 mü in einen TON Kondensator, aber hat nix gebracht LG Mirko
Bist du dir sicher, einen Atmega644p eingebaut zu haben? Das 'p' ist entscheidend.
Hallo Danny, auf dem Chip steht: ATMEGA644 20PU 1310 Ich fürchte das "P" bei 20PU ist nicht das, wonach es aussieht? Oder anders gesagt, ich habe den Falschen? LG Mirko
Genau das. Du brauchst einen 644P oder 644PA. Das '20PU' bezieht sich IIRC auf die maximale Taktfrequenz.
Hallo Danny, das freut mich! Da kann es ja sogar sein, dass dann alles funktioniert. Das macht Hoffnung ;) So, ATMEGA 644P bestellt... Ich halte Euch auf dem Laufenden.
Hi Mirko, > Fuses: low=62 high=99 ex=FF lock=FF Sollten so aussehen: Fuses: low=E7 high=DC ex=FF lock=FF > Wenn ja, wie kann ich das ändern? Hängt vom Progger ab, wie es mit Ponyprog funzt, findest Du unter [1]. Ansonsten natürlich ertst mal auf den 644P warten. ;-) hth'n greets Karl M. [1] http://www.mikrocontroller.net/articles/Pony-Prog_Tutorial
Angehängte Dateien:
-
pony.jpg
19 KB
Hurra, hurra... ich empfange Daten! Hier nun meine Erkenntnisse, damit auch andere etwas davon haben.... Ja, es lag am ATMEGA644, der ein ATMEGA644P sein muss! Ein "P" ist hier absolut entscheidend! Außerdem hatte ich keine Ahnung von FUSES. Als Hardware für den Brenner nutze ich das Atmel Evaluationsboard von Pollin. Hier sollte man noch ein serielles Verlängerungskabel bestellen (Amazon). Das Kabel wird NICHT an die serielle Schnittstelle des Eval.-Boards angeschlossen, sondern an den ISP-Port. Logisch oder? ;) Zum brennen des HEX-Files habe ich Ponyprog (Version 2.06g Beta) benutzt, Tipps kamen von Karl, der mir diesen Link gab: Beitrag "AVR 644p wird nicht erkannt" Die Fuses werden gesetzt, indem man zunächst mit "read" die aktuellen Werte ausliest und dann die geforderten Hexwerte "E7" und "DC" in Binärzahlen umrechnet: hight bit "DC" = 11011100 low bit "E7" = 11100111 und dann jeden Wert INVERTIERT in die angehängten (Bildausschnitt) 2 Zeilen von Ponyprogs/Configuration and Security Bits einträgt also: nix nix haken nix nix nix haken haken und in der unteren Zeile nix nix nix haken haken nix nix nix dann "write" und die Fuses sind richtig gesetzt. Mein TANTAL 10μ arbeitet einwandfrei, so dass ich denke dass der 10μ kein fetter TON-Elko sein muss. Ich könnte auf Wunsch also mal eine aktuelle vollständige Bauteilliste erstellen??? Außerdem habe ich festgestellt, dass man nach setzen einer individuellen IP, eines Gateways und der MAC-Adresse den Strom vom NET-IO trennen muss, damit diese Angaben gespeichert werden. Die Befehle: http://192.168.0.0/ecmd?ip 10.100.0.222 http://192.168.0.0/ecmd?gw 10.100.0.1 http://192.168.0.0/ecmd?mac 00:23:e8:02:df:a4 wurden zwar mit "ok" bestätigt, aber beim Test http://192.168.0.0/ecmd?ip erschien wieder die 192.168.0.0 Das kann temporär sein, aber wenn jemand Probleme hat, dann bitte meinen Tipp mit dem Strom versuchen. ;) Jetzt ist Zeit DANKE zu sagen. Ich bin totaler Idiot/Laie und habe es gepackt die ganze Sch... ;) zum Laufen zu bringen - Dank Eurer Hilfe, besonders danny und frank und im allgemeinen, jeden der hier was beiträgt! Coole Sache!
Angehängte Dateien:
-
buderus.jpg
95 KB
nächste Frage: Ich habe einen Logamax plus GB172 von Buderus mit einer RC35. Problem: -------- Bei Moosys-Webfrontend im Bereich von "Livestatus" erscheinen die Brennerdaten nur "halbrichtig". Unter anderem: a) Ich habe definitiv Tagbetrieb/Automatik, er zeigt Nachtbetrieb manuell. b) Wenn ich auf Schaltfläche "Automatik" klicke erhalte ich die Meldung "Befehl 'hkmode auto' ausgeführt.", aber es ändert sich nichts. Ähnlich auch bei Party- oder Pausenmodus. Vermutung --------- Ich muss irgendwo noch einstellen, dass ich ein "plus-Protokoll" habe Ich muss irgendwo noch einstellen, dass mein Heizungsbauer (seltsamer- oder vlt. auch richtiger Weise) den 2. Heizkreis als mein "ein und alles" eingerichtet hat. Hat jemand mit ähnlicher/selber Technik gleiche Erfahrungen gemacht und evtl. Lösungen bereit?
Mirko Konrad schrieb: > Vermutung > --------- > Ich muss irgendwo noch einstellen, dass ich ein "plus-Protokoll" habe Falsch :) Es gibt zwar 'EMS plus', aber RC35 ist definitiv das 'normale' EMS. > Ich muss irgendwo noch einstellen, dass mein Heizungsbauer (seltsamer- > oder vlt. auch richtiger Weise) den 2. Heizkreis als mein "ein und > alles" eingerichtet hat. Bingo. Moosy's Code unterstützt nur HK1. Konfigurierbar ist das allerdings nicht, nur insofern, dass du den Code durchgreppen und alle 'hk1' durch 'hk2' ersetzen kannst. Das betrifft sowohl ems-php-webinterface als auch ems-tools. Der ems-collector selbst kann mit allen möglichen Heizkreisen (1-4) umgehen.
Mirko Konrad schrieb: > (seltsamer- oder vlt. auch richtiger Weise)... 2. Heizkreis ... Um das herauszufinden, beschreib' mal bitte deine Heizkreisperipherie(z.B. Pumpe, Mischventil etc.). //Niffko
@Danny geändert.... in webfrontend und emsincludes BINGO :) Wenn ich "Party" 1h... dann geht der Brenner an ;) GEIL! @Niffko Antwort folgt....
Angehängte Dateien:
-
heizung.jpg
90 KB
Hallo Niffko, ich hoffe, ich hab alles drin, was Du nachgefragt hast...
wow ... Grafik = nice. Da dein Heizkreis gemischt ist, geht das mit HK2 in Ordnung. HK1 ist mit RC35 nur ungemischt konfigurierbar. Aber da du das Frontend erfolgreich anpassen konntest, ist ja alles im Lack :) //Niffko
Niffko _ schrieb: > wow ... Grafik = nice. ... ack! Mit welchem Programm hast Du das Schema denn "zu Papier gebracht", Mirko? tia'n greets Karl M.
@Karl, Grafik: CorelDraw von Hand ;) ------------------------- wieder ein Problem ;) nachdem ich mit "wget http://www.mikrocontroller.net/attachment/223645/ems-buderus_0-4.deb"; das Install-Scrippt gedownloadet habe, schlägt der Versuch der Installation fehl: dpkg --install ems-buderus_0-4.deb Vormals nicht ausgewähltes Paket ems-buderus wird gewählt. (Lese Datenbank ... 68022 Dateien und Verzeichnisse sind derzeit installiert.) Entpacken von ems-buderus (aus ems-buderus_0-4.deb) ... Download der Quellen Cloning into '/tmp/ems-collector'... error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://github.com/maniac103/ems-collector.git/info/refs fatal: HTTP request failed dpkg: Fehler beim Bearbeiten von ems-buderus_0-4.deb (--install): Unterprozess neues pre-installation-Skript gab den Fehlerwert 128 zurück Fehler traten auf beim Bearbeiten von: ems-buderus_0-4.deb --------- rufe ich https://github.com/maniac103/ems-collector.git/info/refs separat auf, erscheint: Please upgrade your git client. GitHub.com no longer supports git over dumb-http: https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days --------- habe ich irgendetwas vergessen? PS.: Vorher ausgeführt: apt-get install build-essential libboost1.49 -all mysql-server mysql-client libmysql++ php5-mysql und apt-get install git telnet php5 php5-cgi gnuplot Ohne Fehler....
Mirko Konrad schrieb > @Karl, Grafik: CorelDraw von Hand ;) ... chapeau! > wieder ein Problem ;) git clone git://github.com/maniac103/ems-collector hth
Ja kann sein das github da einiges geändert hat und es jetzt nicht mehr rennt. Da ich aber auch davon ausgehe das einiges behoben wurde an den sourcen was ich weg gepacht hab macht es kein Sinn daß Paket noch so zu verwenden.
gibts ne step-by-step-Anleitung für die Installation der Software, also collectord und moosy? ah, karl, danke?! git clone git://github.com/maniac103/ems-collector
Mein Installationsproblem (Beitrag "Re: EMS > Adapter > NetIO > Raspi") kam offensichtlich von einer falschen Systemzeit! LG Mirko
Moin und vielen Dank für diese tolle Arbeit hier, nutze eine GB142 mit RC30. Habe mit viel Mühe Dannys Code zum Laufen bekommen, mit der Hardware gab es keine Schwierigkeiten. Ein Problem ist noch übrig: Die RAUM-IST-Temperatur wird mit 3200°C angezeigt und zwar sowohl auf dem Web-Interface als auch im "ems-collector.log". Gesucht habe ich schon ordentlich, aber jetzt könnte ich einen Tipp richtig gut gebrauchen. Danke und Gruß KHS
khs schrieb: > Die RAUM-IST-Temperatur wird mit 3200°C angezeigt und zwar sowohl auf > dem Web-Interface als auch im "ems-collector.log". > > Gesucht habe ich schon ordentlich, aber jetzt könnte ich einen Tipp > richtig gut gebrauchen. Kann es sein, dass deine RC30 nicht an einen Heizkreis gebunden ist? Laut diesen Postings wird die Temperatur genau in diesem Fall als 3200.0°C (0x7d00) übermittelt: Beitrag "Re: Faktensammlung Buderus EMS" Beitrag "Re: Faktensammlung Buderus EMS" Das ist ein bekanntes Problem, das ich noch fixen muss. Verloren geht dir dadurch allerdings nix, die korrekte Anzeige in diesem Fall ist dann 'nicht verfügbar'.
Angehängte Dateien:
-
ems-gateway.jpg
54 KB
Habe noch eine bestückte und geprüfte Adapterplatine zum Anschluss an NET-IO und EMS übrig. Bei Kauf-Interesse bei mir per PN melden...
Hi Mirko, Mirko Konrad schrieb: > Adapterplatine Sag Mirko, möchtest Du Dein Platinen-Layout hier als Download zur Verfügung stellen? Würd's dann ins Wiki übernehmen. Mit dem Layout von Maciej Piliński scheint es ja Probleme zu geben, oder hat das schon jemand gefixt? Gruß Karl M.
Karl M. W. schrieb: > Mit dem Layout von Maciej Piliński scheint es ja Probleme zu geben, oder > hat das schon jemand gefixt? Denke mal an sich ist das Board auch OK. Zumindest wenn ich die Datei öffne. Meine irgendwo mal gelesen zu haben dass es Probleme mit Poligonen im GND-Poligon gab. Keine Ahnung ob Mirko ausversehen unbemerkt was am Board geändert hat oder Platinenhersteller da irgendwas "verbrochen" hat. Vielleicht war es ja auch nur eine "falsche" Eagleversion. Mirkos Platine im Wiki ist eine gute Idee, wenn Mirko das zur verfügung stellt. Oder ist das sogar irgendwo schon einem Thread angehangen? Gruß Ingo
Moin! Stimmt; die RC30 steckt direkt im Gehäuse. Die threads sind schon so lang und so viele, das hab ich überlesen. Vielleicht ein Punkt; sicher etwas OT: Ich habe entdeckt, dass das Feld "Zirkulations-Pumpe" manchmal grün erleuchtet war und habe dann einen Umbau gewagt und die Zirkulations-Pumpe direkt angeschlossen. Sie läuft nicht, auch auf "Dauer" geändert, es hat nicht geholfen. Offenbar zieht das Relais nicht an. Gibt es noch Bit was zu kippen ist oder einen Schalter, den ich noch betätigen könnte? Habe gesucht, Dr Goggle hat nichts ausgespuckt ;-) Danke KHS
Für die Zirkulationspumpe gibt es auch ein Zeitprogramm. Wenn das bei Dir eingestellt ist läüft die Zirkulationspumpe auch nur in bestimmten Zeiten. Wärend die Zirkulationspumpe "grün" wird sollt auch die echte Zirkulationspumpe laufen. Gruß Ingo
Moin! Genau so hab ich mir das mit der Zirkulationspumpe auch vorgestellt. Der Relaistest hat es auch nicht gebracht, das Relais zieht nicht. Werde morgen noch einmal das Releias für die externe WW-Pumpe ausprobieren. Wenn das auch nicht schaltet bin ich am Ende meiner Weisheit. sri for OT Gruß Knut
KHS schrieb: > Der Relaistest hat es auch nicht gebracht Wenn der Relaistest nicht funktioniert, ist entweder die elektr. Verbindung UBA -> Anschlussplatine gestört oder die Sicherung auf der Anschlussplatine durch. Beim Relaistest muss eins der beiden Relais auf der Anschlussplatine hörbar anziehen. Tut es das und die Pumpe läuft trotzdem nicht -> Sicherung durch. Zieht das Relais nicht an, ist entweder das Relais defekt -kommt eigentlich nicht vor- oder es wird nicht durch den UBA angesteuert. Letzteres könnte an einem Kontaktfehler am Kontaktfuß des UBA liegen. Prüfe, ob die untere Dichtlippe des UBA bündig auf dem Gerätechassis aufliegt und die Befestigungsschraube fest angedreht ist. Ansonsten UBA mal abbauen und den Kontaktfuß(am Gerät) auf aufgeweitete oder nach unten geschobene Kelche kontrollieren. Sollte dies alles nicht fruchten, wird es Zeit den Heizungsbauer deines Vertrauens einzubeziehen ... oder die Z-Pumpe wieder extern anzusteuern :) //Niffko
... oder die Z-Pumpe wieder extern anzusteuern :) Nee! Der Tipp mit dem Kontaktfehler hat es gebracht! Danke! Das Problem war ein verschwundener "Kelch", so eine Kabelhülse; sie war nicht da. UBA raus, Kabelbaum aufgetüddelt, den Kontakt gerichtet (die Federchen, die ein zurückschieben verhindern sollen waren komplett verbogen, das hat noch nie funktioniert). Nun läuft die Zirkulationspumpe wie gedacht. Vielen Dank! Knut
Bernd Gewehr schrieb: > Gibt es hierzu einen Tip? > > pi@raspberrypi /usr/local/bin $ ./calcemsgraphs.sh > > gnuplot> set grid lc rgb '#aaaaaa' lt 1 lw 0,5 > ^ > line 0: ';' expected > > pi@raspberrypi /usr/local/bin $ Hallo, habe ein ähnliches Problem mit den graphs von Moosys Frontend. Nachdem ich ./calcemsgraphs.sh manuell ausgeführt habe passiert nichts. Dann kommt nach etwa 2 bis 3 Minuten der selbe fehler. es wird nur ein hk.png Diagramm ohne Kurven gezeichnet. wenn ich mir aber calcemsgraphs.sh ansehen ist das die letzte Grafik die gezeichnet werden soll. Wenn ich im Frontend die Schaltzeiten aufrufe wird automatisch die Kurve der schaltzeiten durch das Frontend erzeugt. Hat jemand eine Idee was da schief läuft?
Haollo, inzwischen habe ich soweit alle fehlerhaften configurationen gefunden und behoben. Das größte Problem war ein vergessenes "d" was mir nie aufgefallen ist. Dummerweise ist mein SQL-Datenbank auf einem anderen Server. In der Install.txt steht geschrieben dass die Datenbank auf dem selben Server sein soll/muss. Dachte ich bin einfach so schlau und habe in die 'config.py' den Eintrag mysql_host = "192.168.1.123:3306" ein. die config.pyc hatte ich vorher auch mit vi bearbeiteit. Habe aber zum schluss die Datei mit 'phyton -m compileall .' compilieren lassn. Allerdings bekomme ich immer die Fehlermeldung dass der 'user'@'localhost' keine Berechtigung hat. Habe in keinen Dateine ein 'localhost', 'mysql_host' oder '127.0.0.1' finden können. Ist das nicht möglich auf einen anderen Server umzubiegen in PHP? Ist mein Gedankengang falsch oder mache ich irgendwas nicht richtig? HILFE!
Hallo Ingo, Ingo F. schrieb: > ... > habe in die 'config.py' den Eintrag > mysql_host = "192.168.1.123:3306" > ... In meiner config.py finde ich keine "mysql_host" Variable. Vielmehr wird doch der Socket definiert unter "mysql_socket_path". Da würde ich mal versuchen anzusetzen. Soweit mir bekannt, wird die *.pyc beim ersten run automatisch generiert, muss also nicht extra angelegt werden. Gruß und gutes Gelingen! Karl M.
Hallo Karl Karl M. W. schrieb: > In meiner config.py finde ich keine "mysql_host" Variable. Das stimmt, war bei mir auch nicht drin. Bei PHP kann diese Variable gesetzt werden um IP und Port vom Server anzugeben. Allerdings scheint die irgendwo überschrieben oder geändert zu werden. Oder die Variable wird in den scripten nicht benutzt. Habe jetzt mal testweise die MySQL-Datenbank auch umgezogen und es scheint soweit zu funktionieren. Auf die Dauer sollte aber die Datenbank wieder auf einen anderen Server. Habe noch ein paar Probleme dass die Konfiguration der RC30 falsch angezeigt wird und teilweise Kesseltemperaturen von etwa 2200°C. Denke das muss ein Fehler sein. Weiss auch nicht ob das zeichnen der Kurven wirklich 20 bis 30 Sekunden dauern muss. Außerdem werden beim Zeichnen der Kurven Fehler ausgegeben. Die scheinen aber für die Kurven unwichtig zu sein. Gruß Ingo
Hallo, gibt es schon einen collector der auch die Solar Daten verarbeitet? Im Wiki stehen ja schon einige Daten... Gruß JayKay
Ingo F. schrieb: > gnuplot> set grid lc rgb '#aaaaaa' lt 1 lw 0,5 > line 0: ';' expected So, der Fehler ist gefunden! Die 0,5 steht für die Lienienbreite. Das Dezimaltrennzeichen ist aber der Punkt. Den Fehler sieht man aber normalerweise nicht weil er mit "> /dev/null 2>&1" unterdrückt wird. Da ich aber noch Probleme mit dem pfad von "mysqld.sock" hatte war die Unterdrückung testweise herausgenommen. Gruß Ingo
Ingo F. schrieb: > Hallo Karl > > Karl M. W. schrieb: >> In meiner config.py finde ich keine "mysql_host" Variable. > > Das stimmt, war bei mir auch nicht drin. Bei PHP kann diese Variable > gesetzt werden um IP und Port vom Server anzugeben. > > Allerdings scheint die irgendwo überschrieben oder geändert zu werden. > Oder die Variable wird in den scripten nicht benutzt. Naja, das PHP-Skript benutzt die Python-Konfig-Datei nicht ;-) Wenn man die Variable in config.php schreibt, sollte es allerdings funktionieren. > Habe noch ein paar Probleme dass die Konfiguration der RC30 falsch > angezeigt wird und teilweise Kesseltemperaturen von etwa 2200°C. Denke > das muss ein Fehler sein. Wahrscheinlich schon. Logs wären an der Stelle hilfreich. > Weiss auch nicht ob das zeichnen der Kurven wirklich 20 bis 30 Sekunden > dauern muss. Siehe dazu meine Ausführungen hier: Beitrag "Re: Faktensammlung Buderus EMS" Kay F. schrieb: > gibt es schon einen collector der auch die Solar Daten verarbeitet? > Im Wiki stehen ja schon einige Daten... Nein. Pull Requests sind aber gerne gesehen ;-) Ich kann das auch einbauen, allerdings muss mir jemand erzählen, welche Werte davon relevant sind. Außentemperatur haben wir schon, Pumpenmodulation und Betriebszeit sind wahrscheinlich relevant, aber was ist 'Speicherunten'? Ingo F. schrieb: > Ingo F. schrieb: >> gnuplot> set grid lc rgb '#aaaaaa' lt 1 lw 0,5 >> line 0: ';' expected > > So, der Fehler ist gefunden! > Die 0,5 steht für die Lienienbreite. Das Dezimaltrennzeichen ist aber > der Punkt. Das erinnert mich daran, dass ich dafür schon seit Ewigkeiten einen Pull Request habe: https://github.com/maniac103/ems-collector/pull/2 Den habe ich bislang nur deshalb nicht gemergt, weil die Readme, die der PR auch noch mit reinbringt, mir noch nicht ganz gefällt. Ich glaube, ich werde das einfach mal mergen und fixen.
Danny Baumann schrieb: > Naja, das PHP-Skript benutzt die Python-Konfig-Datei nicht ;-) > Wenn man die Variable in config.php schreibt, sollte es allerdings > funktionieren. Beim Collector ist das ja auch kein Problem. Habe den Host dort irgendwo in der Config zusätzlich angegeben. Das Problem liegt an den Scripts von Moosys Frontend. Schaffe es nicht dass die sich über den mysqld.sock auf einen anderen MySQL-Server verbinden. Die Scripte benutzen ja eigentlich die config-Datei. Aber tritzdem verscuht er sich immer bei localhost anzumelden. Mit den 2200 °C muss ich mal bei Zeiten die Telegramme mitloggen die diese Fehler produzieren... Gruß Ingo
Ingo F. schrieb: > Das Problem liegt an den Scripts von Moosys Frontend. Schaffe es nicht > dass die sich über den mysqld.sock auf einen anderen MySQL-Server > verbinden. > > Die Scripte benutzen ja eigentlich die config-Datei. Aber tritzdem > verscuht er sich immer bei localhost anzumelden. Tun sie, ja. Allerdings verwenden die die config.php, nicht die config.py. Du hattest nur von letzterer gesprochen, war das ein Typo? Wenn nein, war das der Fehler...
Danny Baumann schrieb: > Kay F. schrieb: >> gibt es schon einen collector der auch die Solar Daten verarbeitet? >> Im Wiki stehen ja schon einige Daten... > > Nein. Pull Requests sind aber gerne gesehen ;-) > Ich kann das auch einbauen, allerdings muss mir jemand erzählen, welche > Werte davon relevant sind. Außentemperatur haben wir schon, > Pumpenmodulation und Betriebszeit sind wahrscheinlich relevant, aber was > ist 'Speicherunten'? Hi, "Speicherunten" ist die Temperatur unten im Warmwasserspeicher. Diese steigt bei mir wenn die Sonne kräftig scheint ;-) "Aussentemperatur" ist eventuell die Temperatur im Kollektor selbst, bin mir aber nicht sicher. Ich habe das alles momentan noch über die KM200 ins openhab gebracht, da die Werte ja noch nicht über den EMS-Collector kommen :-) Hier die Werte von der KM200 für Solar (fast selbst erklärend) "/solarCircuits/sc1/status" (Active) "/solarCircuits/sc1/solarYield" (Wh) "/solarCircuits/sc1/collectorTemperature" (Grad Celsius) "/solarCircuits/sc1/pumpModulation" (%) "/solarCircuits/sc1/dhwTankTemperature" (Grad Celsius) Gruß
Danny Baumann schrieb: > Tun sie, ja. Allerdings verwenden die die config.php, nicht die > config.py. Du hattest nur von letzterer gesprochen, war das ein Typo? Jain, ich hatte auch die Config.php gemeint:
1 | <?php
|
2 | $min_collector_version=2014031201; |
3 | $mysql_host = "192.168.1.123:3306"; |
4 | $mysql_user= "ems"; |
5 | $mysql_pass = "HierStehtMeinPasswort"; |
6 | $graphpath = "/var/www/html/graphs/"; |
7 | $emsscriptpath = "/home/ems-tools/scripts/"; |
8 | $tmpdir="/tmp/"; |
9 | $html_cols=3; |
Habe es aber auch in der Config.py eingetragen:
1 | mysql_socket_path = "/var/run/mysqld/mysqld.sock" |
2 | mysql_host = "192.168.1.123:3306" |
3 | mysql_user = "ems" |
4 | mysql_password = "HierStehtSchonWiederMeinPasswort" |
5 | mysql_db_name = "ems_data" |
6 | graphtargetpath = "/var/www/html/graphs/" |
Trotzdem kam aber die Meldung das 'ems'@'localhost' nicht existiert... Ohne ":3306" hat es aber auch nicht funktioniert..
Ingo F. schrieb: > Trotzdem kam aber die Meldung das 'ems'@'localhost' nicht existiert... > Ohne ":3306" hat es aber auch nicht funktioniert.. In welchem Kontext kommt denn die Meldung? Im Webserver-Log? Oder woanders?
Danny Baumann schrieb: > In welchem Kontext kommt denn die Meldung? Im Webserver-Log? Oder > woanders? Da die Grafiken nicht erstellt wurden habe ich in der *calcemsgraphs.sh* die Umleitung ins Nirva rausgeschmissen. Die Fehlermeldung kommt also im Linux Terminal. Dort wurde 30 mal die Meldung ausgeworfen wenn ich mich recht erinnere. Danny Baumann schrieb: >> Weiss auch nicht ob das zeichnen der Kurven wirklich 20 bis 30 Sekunden >> dauern muss. > > Siehe dazu meine Ausführungen hier: > Beitrag "Re: Faktensammlung Buderus EMS" Das ist ja nicht das Problem. Die ganzen Grafiken für die verschiedenen Zeitspannen werden alle innerhalb weniger Sekunden erstellt. Das Problem ist die letzte Kurve in der *calcemsgraphs.sh*. Dort wird die Heizkennlinie erstellt. Das sind 7 - 9 Datenwerte. Die Kurve benötigt 20-30 Sekunden. Allerdings ist dann auch nur Das Diagramm OHNE Kurven in der PNG-Datei. Kann diese Datei auch nicht im Fronend öffnen weil meine Heizung wohl Raumtemperaturgeführt ist.
Ingo F. schrieb: > Das Problem ist die letzte Kurve in der *calcemsgraphs.sh*. Werden denn die vier Daten-Files erzeugt und ist deren Inhalt sinnvoll? //Niffko
Naja, sieht jedenfalls nicht sinnlos aus: hka.dat: 8 5 8 45 kkn.dat: -11 -21 20 -1 hkt.dat: -11 -19 20 1 temp.dat <vier leerzeilen> -11
Wie es aussieht, bekommst du 4 Werte nicht rein ($AT,$RTO,$TT,$TN). In der Low-Level Funktion, die diese Werte holen soll, habe ich beim groben Überfliegen ein Timeout von 5 Sekunden gesichtet. Würde passen ... //Niffko
Hallo Niffko, Wieso 4 Werte? Wegen der vier Leerzeilen in der *temp.dat*? Vielleicht ist ja meine RC30 auch defekt. Ich komme nicht mehr in das Menü für in der auch der Urlaub- und Party-Modus aktiviert werden kann. Alle Tasten dafür funktionieren. Nur die Kombination der Tasten bringt mir nicht das Menü. Oder gibt es irgendwelche Einstellung die dieses Menü deaktivieren? Niffko _ schrieb: > $AT seltsamerweise kommt seit gestern keine Außentemperatur mehr rein... Muss aber nicht das selbe Problem sein. Vorher hat es ja auch so lange gedauert... Auch als die Außentemperatur noch kam...
Ingo F. schrieb: > Wieso 4 Werte? Wegen der vier Leerzeilen in der *temp.dat*? Erstens das und wenn man sich die Zwischenwerte $ATT, $BTT, $ATN, $BTN in den erzeugten Daten-Files anschaut ... //Niffko
Es sieht so aus, als ob die RC30 manche Werte einfach nicht liefert. $AT ist die Auslegungstemperatur, die in Telegramm 0x3d an Daten-Offset 36 erwartet wird. Mit meiner RC30 passiert aber nur das hier: # hole 42 Bytes aus 0x3d IO: Sending bytes 0x90 0x3d 00 0x2a # es kommen 27 Bytes zurück MESSAGE[12.03.2015 09:29:07]: source 0x10, dest 0x0b, type 0x3d, offset 0, data: 0x01 0x14 0x2a 0x22 0x00 0x28 0x00 0x02 0x00 0x05 0x05 0x2d 0x01 0x01 0x04 0x46 0x05 0x41 0x01 0x00 0x3c 0xff 0x11 0x05 0x05 0x00 0x02 # hole die restlichen 15 Bytes IO: Sending bytes 0x90 0x3d 0x1b 0xf # es kommen aber nur 5 Byte MESSAGE[12.03.2015 09:29:07]: source 0x10, dest 0x0b, type 0x3d, offset 27, data: 0x00 0x02 0x0f 0x32 0x0a # hole die restlichen 10 Bytes IO: Sending bytes 0x90 0x3d 0x20 0xa # es ist aber nix mehr vorhanden MESSAGE[12.03.2015 09:29:08]: source 0x10, dest 0x0b, type 0x3d, offset 32, data: Das heißt, dass die RC30 einige Werte wie Führungsgröße oder Auslegungstemperatur nicht liefern kann; zumindest nicht an der Stelle, an der sie bei der RC35 stehen. Ich meine die Auslegungstemperatur bei mir an Offset 17 zu sehen (HK1 65°C, HK2 43°C) und die max. Vorlauftemperatur an Offset 15 (70/47°C). Die Führungsgröße könnte evtl. an Offset 18 stehen (ich kann das gerade nicht testen, da nicht zu Hause). (NB: Offsets 9 bis 12 sehen nach Parametern für die Estrichtrocknung aus) Kann das mal bitte jemand, idealerweise auch mit einer RC35, verifizieren? Mir ist auch noch nicht ganz klar, wo der Unterschied zwischen 'Heizart' (Offset 0) und 'Heizsystem' (Offset 32) ist. Niffko, hast du da vielleicht eine Idee? $RTO (Raumoffset), $TT (Tagtemperatur) und $TN (Nachttemperatur) sollten allerdings auch so vorhanden sein (und sind es bei meiner RC30 auch).
Vorlauftemperatur und Auslegungstemperatur scheinen korrekt zu sein; ich habe Wiki und Collector mal entsprechend aktualisiert. Die Führungsgröße scheint bei der RC30 implizit bestimmt zu sein (Heizsystem Raumvorlauf ist raumtemperaturgeführt, ansonsten außentemperaturgeführt).
Hallo, ich habe noch das Problem das nicht alle Grafiken im Web Frontend angezeigt werden. Ist ein Std. Debian 7 System. /etc/sudoers:
1 | ... |
2 | www-data ALL=(ALL)NOPASSWD:/opt/EMSGateway/ems-tools/scripts/* |
3 | ... |
/data/apache/EMS/graphs# vdir
1 | |
2 | -rw-r--r-- 1 root root 10304 Mär 12 20:24 hk.png <-- Die wird als root:root vom Webserver angelegt, so das SUDO funktionieren sollte oder? |
3 | -rw-r--r-- 1 www-data www-data 8182 Mär 12 20:22 schedule.png |
/var/log/apache2/error.log
1 | .... |
2 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP Stack trace:, referer: http://homeserver/EMS/?seite=a_emslog.php |
3 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 1. {main}() /data/apache/EMS/index.php:0, referer: http://homeserver/EMS/?seite=a_emslog.php
|
4 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 2. require() /data/apache/EMS/index.php:31, referer: http://homeserver/EMS/?seite=a_emslog.php |
5 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 3. showline() /data/apache/EMS/a_emstime.php:82, referer: http://homeserver/EMS/?seite=a_emslog.php |
6 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 4. flush_buffers() /data/apache/EMS/a_emstime.php:18, referer: http://homeserver/EMS/?seite=a_emslog.php |
7 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 5. ob_flush() /opt/EMS Gateway/ems-tools/includes/emsqry.inc:20, referer: http://homeserver/EMS/?seite=a_emslog.php |
8 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP Notice: ob_flush(): failed to flush buffer. No buffer to flush in /opt/EMS Gateway/ems-tools/includes/emsqry.inc on line 20, referer: http://homeserver/EMS/?seite=a_emslog.php |
9 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP Stack trace:, referer: http://homeserver/EMS/?seite=a_emslog.php |
10 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 1. {main}() /data/apache/EMS/index.php:0, referer: http://homeserver/EMS/?seite=a_emslog.php
|
11 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 2. require() /data/apache/EMS/index.php:31, referer: http://homeserver/EMS/?seite=a_emslog.php |
12 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 3. showline() /data/apache/EMS/a_emstime.php:82, referer: http://homeserver/EMS/?seite=a_emslog.php |
13 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 4. flush_buffers() /data/apache/EMS/a_emstime.php:18, referer: http://homeserver/EMS/?seite=a_emslog.php |
14 | [Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP 5. ob_flush() /opt/EMS Gateway/ems-tools/includes/emsqry.inc:20, referer: http://homeserver/EMS/?seite=a_emslog.php |
15 | [Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/aussentemp-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php |
16 | [Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/raumtemp-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php |
17 | [Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/brenner-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php |
18 | [Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/kessel-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php |
19 | [Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/ww-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php |
20 | [Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/pumpen-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php |
Gruß JayKay
Danny Baumann schrieb: > $AT ist die Auslegungstemperatur, die in Telegramm 0x3d an > Daten-Offset 36 erwartet wird. Das ist die Auslegung spezifisch für Fußbodenheizung und existiert nur bei RC35. Beim RC30 ist nach Offset 31 Schluss. Bis dahin ist die Datenzuordnung allerdings identisch. Danny Baumann schrieb: > Ich meine die Auslegungstemperatur bei mir an Offset 17 zu sehen korrekt ... ist bei RC30 und RC35 gleich. Danny Baumann schrieb: > ... Unterschied zwischen 'Heizart' (Offset 0) und 'Heizsystem' (Offset 32) ist. Hmm ... kann ich mir auch nicht so richtig einen Reim drauf machen. //Niffko
Niffko _ schrieb: > Das ist die Auslegung spezifisch für Fußbodenheizung und existiert nur > bei RC35. Beim RC30 ist nach Offset 31 Schluss. Bis dahin ist die > Datenzuordnung allerdings identisch. Weißt du da mehr dazu? Mich würde interessieren, wo der Unterschied zwischen der 'normalen' Auslegungstemperatur und der für die Fußbodenheizung liegt. > Danny Baumann schrieb: >> ... Unterschied zwischen 'Heizart' (Offset 0) und 'Heizsystem' (Offset 32) ist. > > Hmm ... kann ich mir auch nicht so richtig einen Reim drauf machen. OK, dann werde ich 'Heizsystem' mal rauswerfen. Noch eine Frage, die damit semi-zusammenhängt und zu der du vielleicht etwas weißt ;-) : An Offset 33 scheint bei der RC35 die Führungsgröße (raum- vs. außentemperaturgeführt) zu liegen. Bei der RC30 ist diese Information - so ist zumindest meine Interpretation - im Heizkreis-Typ enthalten ('Raumvorlauf'/'Raumleistung' ist raumtemperaturgeführt, die anderen AT-geführt). Ist diese Interpretation richtig? Wenn ja: Ist das Verhalten der RC35 an der Stelle rückwärtskompatibel? In anderen Worten: Wenn ich da raumgeführt einstelle (Offset 33 = 1), taucht dann automatisch Raumvorlauf als HK-Typ auf (Offset 0 = 4)? Und funktioniert das dann auch andersherum? (Ziel der Frage ist, ob ich mir das Parsen der Führungsgröße sparen kann und sie implizit aus dem HK-Typ ableiten kann. Das wäre sehr hilfreich im Sinne der RC30-Kompatibilität.) Danke :-)
Angehängte Dateien:
-
kessel-halfweek.png
12 KB -
kessel-day.png
9,5 KB
Hallo, ich habe das Problem dass bei der Rücklauftemperatur bei meiner RC30 (EMS-Gateway --> collectord --> Moosys Frontend) in den Grafiken falsche Werte angezeigt werden. Hänge mal zwei Grafiken an.... Es scheint drei falsche Werte zu geben: 614,4°C, 2179°C und -2193,2°C Die Werte haben auch keinen bestimmten Abstand zueinander. Als ich vorhin einen fehlerhaften Wert (2179°C) hatte tauchten im Log über die USB-Serial-Verbindung keine aus der Reihe fallenden Werte auf. Die Temperatur ist gleichmäßig gestiegen. Es scheinen wohl nur alle 75 Sekunden vom Collector in die mySQL geschrieben zu werden. Der vorherige Wert war 0x01d4 = 46,8 und der Wert danach 0x01E4 = 48,4 °C Habe dann Zeitlich den Mittelwert genommen. Das war dann 0x01DD = 47,7 °C. Allerdings taucht der Wert 47,7°C aber in der MySQL-Datenbank auf. Also kann es nicht der Wert 0x01DD sein. Habe dann mal die Datenbank nach fehlenden Werten zu durchsuchen: In diesem Bereich fehlten z.B. folgende Werte (die Zweite Reihe ist die Differenz zum letzten fehlenden Wert). Da es kein gleicher Abstand ist wird das wohl Zufall sein.
1 | 41,3 |
2 | 42,5 1,2 |
3 | 43,5 1 |
4 | 44,5 1 |
5 | 45,5 1 |
6 | 46,7 1,2 |
7 | 48 1,3 |
8 | 49,3 1,3 |
9 | 50,7 1,4 |
10 | 52 1,3 |
11 | 54,4 2,4 |
12 | 55,2 0,8 |
13 | 56 0,8 |
14 | 56,8 0,8 |
15 | 57,6 0,8 |
16 | 58,4 0,8 |
17 | 59,2 0,8 |
18 | 60 0,8 |
19 | 60,3 0,3 |
20 | 60,8 0,5 |
21 | 61,4 0,6 |
22 | 61,5 0,1 |
vermutlich ist das gleichzeitige mitloggen über den Serial-Port vom EMS-Gateway den Fehler über den Port 7777 zum collectord keine Hilfe. Wie kann ich mit dem collector zusätzlich ein Logfile mit allen Telegrammen aufzeichnen kann. Also alle Telegramme die der collector bekommt? Ich habe sonst keine Ahnung woher die falschen Werte kommen... Denke fehlerhafte CRC werden vom EMS-Gateway und/oder collector ignoriert, oder? Jemand eine Idee wie so etwas kommt? Wer hat ähnliche Probleme? Gruß Ingo
Danny Baumann schrieb: > ... Unterschied zwischen der 'normalen' Auslegungstemperatur > und der für die Fußbodenheizung liegt. Wird bei Heizsystem 'Fußboden' gewählt, wird Auslegung 'Fußboden' verwendet. Alle anderen Heizsysteme verwenden die Auslegung bei Offset 17. Danny Baumann schrieb: > OK, dann werde ich 'Heizsystem' mal rauswerfen. Haaaalt :) Hab hierzu doch noch was: RC30 stellt Heizsystem nur über Offset 0 ein, ist klar. Mögliche Auswahl:
1 | Offset 0 |
2 | 0 - Keines |
3 | 1 - Heizkörper |
4 | 2 - Konvektor |
5 | 3 - Fußboden |
6 | 4 - Raumvorlauf |
7 | 5 - Raumleistung |
RC35 schreibt bei Änderung des Heizsystems auf Offset 0 UND Offset 32. Mögliche Auswahl:
1 | Offset 32 |
2 | 1 - Heizkörper |
3 | 2 - Konvektor |
4 | 3 - Fußboden |
'Raumvorlauf' und 'Raumleistung' fällt bei RC35 weg. Einstellung Führungsgröße über Offset 33. Mögliche Auswahl:
1 | Offset 33 |
2 | 0 - außentemp.geführt |
3 | 1 - raumgeführt |
Danny Baumann schrieb: > [RC35] Wenn ich da raumgeführt einstelle (Offset 33 = 1), > taucht dann automatisch Raumvorlauf als HK-Typ auf (Offset 0 = 4)? Und > funktioniert das dann auch andersherum? Nein. Bei RC35 wird auf Offset 0 nur 1,2 oder 3 erscheinen. Ansonsten ist jedes Heizsystem mit jeder Führungsart kombinierbar. Danny Baumann schrieb: > Danke :-) Büdde :-) //Niffko
Hallo Ich habe jetzt bis zum Raspberry alles am laufen. Beim aufrufen der Seiten wird immer nur der Ladebalken angezeigt. Die Seiten Statistik, Fehlerspeicher und Protokoll werden angezeigt.
Niffko _ schrieb: > Danny Baumann schrieb: >> ... Unterschied zwischen der 'normalen' Auslegungstemperatur >> und der für die Fußbodenheizung liegt. > > Wird bei Heizsystem 'Fußboden' gewählt, wird Auslegung 'Fußboden' > verwendet. Alle anderen Heizsysteme verwenden die Auslegung bei Offset > 17. Bah, warum machen die denn sowas? Da muss ich mir was einfallen lassen...spricht etwas dagegen, beim Setzen dieses Wertes einfach den gleichen Wert an beide Stellen zu schreiben? > Danny Baumann schrieb: >> OK, dann werde ich 'Heizsystem' mal rauswerfen. > RC35 schreibt bei Änderung des Heizsystems auf Offset 0 UND Offset 32. Ich hab Heizart trotzdem rausgeschmissen ;-) Ein neuer Kommandozeilenparameter selektiert zwischen RC30 und RC35; im RC30-Modus wird Offset 0 ausgewertet und geschrieben; im RC35-Modus ist es Offset 32+33. Danke aber für die Klarstellung :-) Ich glaube, ich muss mich doch mal um eine RC35 bemühen (und wenn es nur dafür ist, nicht mehr länger ein von den rauchenden Vorbesitzern vergilbtes Gerät im Wohnzimmer hängen zu haben...)
Ingo F. schrieb: > Es scheint drei falsche Werte zu geben: > 614,4°C, 2179°C und -2193,2°C > Die Werte haben auch keinen bestimmten Abstand zueinander. > > Als ich vorhin einen fehlerhaften Wert (2179°C) hatte tauchten im Log > über die USB-Serial-Verbindung keine aus der Reihe fallenden Werte auf. > Die Temperatur ist gleichmäßig gestiegen. Es scheinen wohl nur alle 75 > Sekunden vom Collector in die mySQL geschrieben zu werden. > > Der vorherige Wert war 0x01d4 = 46,8 und der Wert danach 0x01E4 = 48,4 > °C > Habe dann Zeitlich den Mittelwert genommen. Das war dann 0x01DD = 47,7 > °C. Ich kann dir hier nicht folgen. Was haben die Werte um die 40°C mit den falschen Werten zu tun? > Wie kann ich mit dem collector zusätzlich ein Logfile mit allen > Telegrammen aufzeichnen kann. Also alle Telegramme die der collector > bekommt? Mit dem Kommandozeilenparameter -d message=<Pfad>. > Denke fehlerhafte CRC werden vom EMS-Gateway und/oder collector > ignoriert, oder? Wenn du mit EMS-Gateway deine Platine samt Code meinst, solltest du das wissen ;-) Der Collector erwartet zumindest, dass CRC-Fehler vorher ausgefiltert wurden; er sieht ja auch keine CRC. Mein ethersex-Code filtert entsprechend.
Danny Baumann schrieb: > Ich kann dir hier nicht folgen. Was haben die Werte um die 40°C mit den > falschen Werten zu tun? Also ich habe ja über Serial-Port mitgeloggt und dort nur richtige Werte gesehen. zumindest nichts was Die Werte von etwa +-2000 erklären könnte. Wahrscheinlich konnte ich da nicht mehr klar denken ;-) Vermute mal jetzt dass irgendwie doch fehlerhafte Telegramme bei meinem EMS-Gateway zum collector durchgelassen werden, die allerdings aus dem Seriellen Port rausgefiltert werden. Denke Jürgen kennt sich da mit der Firmware besser aus als ich. Denke mal nicht das der collector ausversehen mal falsche Telegramme auswertet, oder? Allerdings habe ich jetzt schon mal einen Fehler gefunden. Da ich durch den Quellcode von Moosys Frontend und Deinem collector nicht durchblicke brauchte ich eure Hilfe. Inzwischen vermute ich den Fehler im collector. Also wenn ich im Frontend die Schaltzeiten öffne wird die letzte Schaltzeit vom Sonntag ignoriert. Diese Schaltzeit ist genau auf der Grenze von zwei Telegrammen! Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset 0x1C (=28) abgefragt. Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag ausgelassen und daher wohl vom Frontend ignoriert. Das zweite Telegramm müsste also mit Offset 0x1B abgefragt werden. Kann die Berechnung des zweiten Offset-Wertes allerdings nirgendwo finden. Macht diese Berechnung der collector? Bei meinen Schaltzeiten tauchen als erstes zwei Schaltpunkte auf die keinen Sinn machen:
1 | 10 0b 3f 00 |
Das würde ja eigentlich folgendes bedeuten: [code]10 0b Tag:Montag, Schaltpunkt:AUS Uhrzeit:1:50 3f 00 Tag:Dienstag, Schaltpunkt:undefiniert Uhrzeit:0:00[/] Kann es sein dass sich das EEPROM der RC30 verabschiedet und deswegen unsinnige Werte stehen? Dann würde das f bei 0x3f vermutlich bedeuten dass alle vorherigen Werte ignoriert werden sollen weil die Speicherstelle defekt ist. ODer die Bit4 bei 0x10 bedeutet dass diese Speicherzelle defekt ist und das Bit3 bei 0x3f bedeutet dass diese Speicherzelle ebenfalls defekt ist. Sonst werden diese Bits in keinen Schaltzeiten gesetzt. Das könnte eine Erklärung sein warum ich auf der RC30 nicht mehr in das Menü für den Party-/Urlaub-/Ferienmodus komme. Oder die Schaltpunkte werden bei Änderungen nicht neu geordnet und deswegen nur als gelöscht markiert.. Aber warum dann nicht bei beiden Schaltpunkten?
Was habt Ihr eigentlich für Softwarestände in der RC35? Müsste mir evtl einen gebrauchten kaufen. Kann bei mir keine RC300 einsetzten weil ich kein EMS+ habe. Kann das wirklich sein dass der Raumcontroller neu fast 700EUR kostet????
Danny Baumann schrieb: > Mit dem Kommandozeilenparameter -d message=<Pfad>. Danke, werd ich dann mal gleich testen... Denke mit Pfad ist auch der Dateiname gemeint.
Stephan Richardt schrieb: > Ich habe jetzt bis zum Raspberry alles am laufen. Beim aufrufen der > Seiten wird immer nur der Ladebalken angezeigt. Die Seiten Statistik, > Fehlerspeicher und Protokoll werden angezeigt. Mein PC ist ein Hypochonter... Habe seit dem ich das gelesen habe auch dieses Problem..
Stephan Richardt schrieb: > Ich habe jetzt bis zum Raspberry alles am laufen. Beim aufrufen der > Seiten wird immer nur der Ladebalken angezeigt. Dort wird die Verbindung zum EMS-Bus aufgebaut. Wenn die gestört ist bleibt der Ladebalken bei mir auch stehen. Wenn die Verbindung nicht beteht ist aber auch eine Anzeige unter dem Ladebalken Allerdings benötigt der "Live Status" bei mir auch 30 Sekunden bis die Seite angezeigt wird.
Ingo F. schrieb: > Bei meinen Schaltzeiten tauchen als erstes zwei Schaltpunkte auf die > keinen Sinn machen: 10 0b 3f 00 Also für mich sieht das ja wie ein Telegramm-Header aus. Kann doch kein Zufall sein ... zumal der Telegramm-Typ stimmt. //Niffko
Niffko _ schrieb: > Also für mich sieht das ja wie ein Telegramm-Header aus. Kann doch kein > Zufall sein ... zumal der Telegramm-Typ stimmt. > > //Niffko Schäm :-D Das war wohl ein copy&paste Error. Manchmal sollte man einfach mal eine Pause machen....
Ich habe ja inzwischen auch Moosys Fronend installiert. Wie lange dauert bei euch der Aufruf des LiveStatus? Bei mir sind es etwa 30 Sekunden. Wenn ich parrallel auf dem EMS-Bus sehe ich z.B. dass das unter anderem das Telegramm 0x3D fünf mal im Sekundentakt aufgerufen wird und dann passiert 5 Sekunden lang nichts. Dann werden mehrere Telegramme abgerufen und dann wieder das Telegramm 0x3d. fünf mal im Sekundentakt. Dauert dieser Aufruf bei euch nur 10 Sekunden und das Frontend erwartet irgend einen Wert im Telegramm 0x3d was es nicht findet und macht deswegen so lange Pausen? Bei den Schaltzeiten habe ich dann auch das Problem dass je nach Schaltprogramm nichts angezeigt wird oder die letze Schaltzeit nicht angezeigt wird. Bei anderen Programmen wird es aber dann doch angezeigt. Habe ja schon festgestellt dass bei den Zeitprogrammen ein Wert immer übersprungen wird. Habe mir zwar schon mal den Quellcode vom collector und Frontend angesehen. Aber bisher nichts gefunden wo dieser "fehlerhafte" Offset berechnet wird. Ein zurückschreiben der geänderten Schaltprogramme klappt auch nicht. Bei mir funktioniert auch das auf der LiveStatusseite nicht wirklich viel. Hatte vor kurzem noch die RC30 und habe auf eine RC35 aufgerüstet. Dort hat sich dann auch gestern kurz mal was auf der Livestatus-Seite getan. Jetzt aber wieder nicht. Nicht dass es Mißverständnisse gibt. Die Daten auf der Rechten Hälfte funktionieren nur die Linke nicht wirklich. Bei den Einstellungen funktioniert sind teilweise falsche Werte. Hatte schon vermutet dass es an der RC30 liegt. Moosy scheint ja auch eine RC35 zu haben. Gruß Ingo
Ingo F. schrieb: > Vermute mal jetzt dass irgendwie doch fehlerhafte Telegramme bei meinem > EMS-Gateway zum collector durchgelassen werden, die allerdings aus dem > Seriellen Port rausgefiltert werden. > > Denke Jürgen kennt sich da mit der Firmware besser aus als ich. > > Denke mal nicht das der collector ausversehen mal falsche Telegramme > auswertet, oder? Definiere 'falsche Telegramme'. Wenn 'falsch' == 'hatte eine fehlerhafte CRC' bedeutet, dann wertet der Collector die natürlich trotzdem aus - woher soll er wissen, dass die CRC falsch war? > Allerdings habe ich jetzt schon mal einen Fehler gefunden. Da ich durch > den Quellcode von Moosys Frontend und Deinem collector nicht durchblicke > brauchte ich eure Hilfe. > > Inzwischen vermute ich den Fehler im collector. Woher bist du dir so sicher, dass du einen Fehler gefunden hast, wenn du nicht weißt, wo? :-P > Also wenn ich im Frontend die Schaltzeiten öffne wird die letzte > Schaltzeit vom Sonntag ignoriert. Diese Schaltzeit ist genau auf der > Grenze von zwei Telegrammen! > > Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und > bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset > 0x1C (=28) abgefragt. > Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag > ausgelassen und daher wohl vom Frontend ignoriert. Einspruch. Das hier passiert bei 'hk1 getcustomschedule 1': IO: Sending bytes 0x90 0x3f 00 0x54 <---- Frage 84 Bytes von Telegramm 0x3f ab IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 00 0x1 0x1b 00 0x2d 0x1 0x54 00 0x8a 0x21 0x1b 0x20 0x2d 0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41 0x54 0x40 0x8a 0x61 0x1b 0x60 0xd6 MESSAGE[18.03.2015 15:19:12]: source 0x10, dest 0x0b, type 0x3f, offset 0, data: 0x01 0x1b 0x00 0x2d 0x01 0x54 0x00 0x8a 0x21 0x1b 0x20 0x2d 0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41 0x54 0x40 0x8a 0x61 0x1b 0x60 <---- 27 Bytes kommen rein IO: Sending bytes 0x90 0x3f 0x1b 0x39 <---- Frage 57 Bytes ab, Offset 27 IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 0x1b 0x2d 0x61 0x54 0x60 0x8a 0x81 0x1b 0x80 0x2d 0x81 0x54 0x80 0x8a 0xa1 0x1e 0xa0 0x8a 0xc1 0x1e 0xc0 0x8a 0xe7 0x90 0xe7 0x90 0xe7 0x90 0x52 MESSAGE[18.03.2015 15:19:12]: source 0x10, dest 0x0b, type 0x3f, offset 27, data: 0x2d 0x61 0x54 0x60 0x8a 0x81 0x1b 0x80 0x2d 0x81 0x54 0x80 0x8a 0xa1 0x1e 0xa0 0x8a 0xc1 0x1e 0xc0 0x8a 0xe7 0x90 0xe7 0x90 0xe7 0x9 <---- es kommen 27 Bytes rein An der Stelle wird abgebrochen, da die Ausleseschleife beim ersten Zeitwert von 0x90 ohnehin abgebrochen wurde. Zeig mal deine Logs. > Das zweite Telegramm müsste also mit Offset 0x1B abgefragt werden. Kann > die Berechnung des zweiten Offset-Wertes allerdings nirgendwo finden. > Macht diese Berechnung der collector? Ja. Für den aktuellen Code: CommandHandler.cpp, Zeile 1561. Zum allgemeinen Verständnis: Der Collector macht alles, was auf Telegrammebene passiert, also Telegramme parsen und senden - und zu letzterem gehört sowohl die Generierung der zu sendenden Telegramme als auch die Behandlung einer fragmentierten Antwort. Dem Frontend bietet er eine Schnittstelle zum Abrufen der geparsten Werte und eine Schnittstelle zum Senden von Kommandos an. Ingo F. schrieb: > Ich habe ja inzwischen auch Moosys Fronend installiert. > > Wie lange dauert bei euch der Aufruf des LiveStatus? > Bei mir sind es etwa 30 Sekunden. Bei mir etwa 10 Sekunden. > Wenn ich parrallel auf dem EMS-Bus sehe ich z.B. dass das unter anderem > das Telegramm 0x3D fünf mal im Sekundentakt aufgerufen wird und dann > passiert 5 Sekunden lang nichts. Dann werden mehrere Telegramme > abgerufen und dann wieder das Telegramm 0x3d. fünf mal im Sekundentakt. Logs bitte. > Dauert dieser Aufruf bei euch nur 10 Sekunden und das Frontend erwartet > irgend einen Wert im Telegramm 0x3d was es nicht findet und macht > deswegen so lange Pausen? Gut möglich. Eventuell die (bisher nur bei RC35 vorhandene) Auslegungstemperatur. Update den Collector mal auf den neuesten Stand (und füge rc-type=rc30 zur Config bzw. --rc-type=rc30 zur Kommandozeile hinzu). > Bei mir funktioniert auch das auf der LiveStatusseite nicht wirklich > viel. > > Hatte vor kurzem noch die RC30 und habe auf eine RC35 aufgerüstet. > Dort hat sich dann auch gestern kurz mal was auf der Livestatus-Seite > getan. Jetzt aber wieder nicht. > > Nicht dass es Mißverständnisse gibt. Die Daten auf der Rechten Hälfte > funktionieren nur die Linke nicht wirklich. > > Bei den Einstellungen funktioniert sind teilweise falsche Werte. > > Hatte schon vermutet dass es an der RC30 liegt. Moosy scheint ja auch > eine RC35 zu haben. Moosy's Code scheint an einigen Stellen sehr stark auf sein Setup (RC35, nur HK1 vorhanden, Fußbodenheizung) ausgerichtet zu sein. Was genau geht denn nicht?
Angehängte Dateien:
-
EMS_Livestatus.PNG
6,6 KB -
EMS-Schaltprogramme.PNG
4,4 KB
Danny Baumann schrieb: > Definiere 'falsche Telegramme'. Wenn 'falsch' == 'hatte eine fehlerhafte > CRC' bedeutet, dann wertet der Collector die natürlich trotzdem aus - > woher soll er wissen, dass die CRC falsch war. Das Problem hat sich erledigt und muss noch gefixt werden.... Der EMS-Gateway filtert die Fehlerhaften-Telegramme wohl nur bei Telnet und über den SerialPort heraus. Über die collector-Schnittsltelle wohl nicht. Danny Baumann schrieb: > Woher bist du dir so sicher, dass du einen Fehler gefunden hast, wenn du > nicht weißt, wo? :-P Na weil ich, wie alle anderen Menschen auch, eben fehlerfrei bin :-P Bei der RC-30 habe ich mal mittgeloggt und dann eben gesehen dass ein Wert fehlt. Wenn ich dann das Telegramm manuell abfrage 0b 90 3f 1b 1c dann bekomme ich das fehlende Byte. Habe das jetzt noch mal mit der RC35 getestet. Dort wird wohl nur der erste Teil des Telegramms geliefert. Hänge mal ein mein log als PNG an. Danny Baumann schrieb: > Gut möglich. Eventuell die (bisher nur bei RC35 vorhandene) > Auslegungstemperatur. Update den Collector mal auf den neuesten Stand > (und füge rc-type=rc30 zur Config bzw. --rc-type=rc30 zur Kommandozeile > hinzu). Jetzt habe ich eine RC35. Bei der RC30 kamm ich nicht mehr ins Menü wie in der ANleitung beschrieben. Danny Baumann schrieb: > Was genau geht denn nicht? Also in Einstellungen werde teilweise falsche Daten angezeit. z.B. Als Führungsgröße "Raum" obwohl bei mir Außengeführt ist. Daher auch keine Heizkurve. Schaltprogramme abfragen will nicht richtig. Senden geht auch nicht. Kommt eine Fehlermeldung. Möchte das jetzt nicht nochmal ausprobieren. Dann wird jedesmal mein Heizprogramm zerschossen und muss es wieder manuell an der RC35 eingeben. Kommt sobald ich das lesen erfolgreich hinbekomme... Im Livestatus werden die Tag und Nachtemperatur und die eingestellte Raumtemperatur nciht angezeigt. Gestern lief das mal ganz kurz. Die RaumSollTemperatur ließ sich aber nicht mi (-) und (+) verstellen. Party und Pause werden manchmal flasche Werte angezeigt. Das einizige was wohl richtig funktioniert ist der Status. Gruß Ingo
Ingo F. schrieb: > Bei der RC-30 habe ich mal mittgeloggt und dann eben gesehen dass ein > Wert fehlt. Wenn ich dann das Telegramm manuell abfrage 0b 90 3f 1b 1c > dann bekomme ich das fehlende Byte. > > Habe das jetzt noch mal mit der RC35 getestet. Dort wird wohl nur der > erste Teil des Telegramms geliefert. Hänge mal ein mein log als PNG an. An welcher Stelle wird dieses Log geloggt? Auf deinem Gateway? Spontan irritieren mich die mehrfachen Kommandowiederholungen. Die sollten da nicht sein, sondern der Offset sollte ordentlich hochgezählt werden. Starte den Collector mal bitte mit -d io=<Pfad>, lasse die Schaltzeitpunkte auslesen und lade die Datei mal bitte hoch. Vielleicht macht dein Gateway an der Stelle ja etwas falsch (z.B. Senden des vorhergehenden Sendepuffers, wenn neue Sendedaten eintreffen)? Das würde zumindest so ziemlich alle von dir beschriebenen Probleme erklären, und auch, warum z.B. ich diese Probleme scheinbar nicht habe. > Also in Einstellungen werde teilweise falsche Daten angezeit. z.B. Als > Führungsgröße "Raum" obwohl bei mir Außengeführt ist. Daher auch keine > Heizkurve. Das hier z.B. könnte auch so ein Problem sein, da die Führungsgröße hinter Byte 27 steht und Moosy alles, was nicht 'außengeführt' ist (also auch 'undefiniert') als 'raumgeführt' interpretiert (weshalb das bis vor kurzem auch nicht mit der RC30 funktioniert hat - die hat diesen Wert einfach nicht).
Sieht so aus als ob meine Softwarestand der Heizung es nicht mag wenn zuviele Daten abgefragt werden. wenn ich z.B. 0b 90 3f 00 54 absende erhalte ich immer nur ein Telegramm mit 27(=0x1b) Byte Daten. Mehr kommt dann nicht. Ist das bei Dir anders? Dachte der Collector oder das Frontend fragt nacheinander alle Telegramme in Stückchen der Reihe nach ab.
Ingo F. schrieb: > Sieht so aus als ob meine Softwarestand der Heizung es nicht mag wenn > zuviele Daten abgefragt werden. > > wenn ich z.B. 0b 90 3f 00 54 absende erhalte ich immer nur ein Telegramm > mit 27(=0x1b) Byte Daten. Mehr kommt dann nicht. > > Ist das bei Dir anders? Dachte der Collector oder das Frontend fragt > nacheinander alle Telegramme in Stückchen der Reihe nach ab. Das ist bei mir genauso, und wie du schon vermutest, sollte der Collector die weiteren Daten stückchenweise abfragen. Bei mir tut er das allerdings auch, weshalb es eigentlich nur 3 Möglichkeiten gibt: 1) dein Checkout des Collectors ist zu alt (unwahrscheinlich, ich habe die Fragmentbehandlung seit September 2013 drin) 2) dein Gateway macht etwas falsch (d.h. sendet andere Daten, als der Collector in den Socket gestopft hat) 3) der Collector hat einen Bug, der sich bei mir noch nicht manifestiert hat Jetzt gilt es rauszufinden, welche der 3 Möglichkeiten zutrifft - das ist der Grund, weshalb ich nach dem Collector-IO-Log gefragt habe ;-)
Danny Baumann schrieb: > Vielleicht > macht dein Gateway an der Stelle ja etwas falsch Will ich nicht ausschließen. Die Logs kommen vom USB-Port des EMS-Gateways. Aufgenommen mit HTerm. Denke das Problem ist in beiden Fällen dass nur der erste Brocken der Daten kommt. Würde jetzt sagen die Sofware meiner Heizung ist das Problem (von 2003). Durchaus kann es auch am Senden vom EMS-Gateway liegen... Dann müsste ich aber doch zumindest einen fehlerhaften Anwortversuch oder Buskollisonen bekommen?! Edit: Also den Collector habe ich ja erst vor einem Monat kompiliert. Ist also wohl die Fragmentierung drin.
Ingo F. schrieb: > Denke das Problem ist in beiden Fällen dass nur der erste Brocken der > Daten kommt. Würde jetzt sagen die Sofware meiner Heizung ist das > Problem (von 2003). Glaub ich nicht, meine ist zumindest ähnlich alt, die Anlage ist von 2004. > Durchaus kann es auch am Senden vom EMS-Gateway liegen... Dann müsste > ich aber doch zumindest einen fehlerhaften Anwortversuch oder > Buskollisonen bekommen?! Kommt drauf an, wie der Fehler aussieht. Wenn - wie ich oben schon spekuliert habe - unter bestimmten Umständen (z.B. gleiches Ziel + gleicher Typ) der Sendepuffer nicht mit den neuen zu sendenden Daten überschrieben würde, sondern die alten Daten drin stehen blieben, würde das genau das Fehlerbild erzeugen, das du siehst.
Danny Baumann schrieb: > Glaub ich nicht Kann man feststellen, ob meine Software zumindest älter ist:
1 | Softwareversion UBA 2.03 |
2 | Softwareversion BC10 2.00 |
3 | Softwareversion RC35 1.16 |
Werde noch mal ein Log vom collector machen lassen...
Ingo F. schrieb: > Danny Baumann schrieb: >> Glaub ich nicht > Kann man feststellen, ob meine Software zumindest älter ist: >
1 | > Softwareversion UBA 2.03 |
2 | > Softwareversion BC10 2.00 |
3 | > Softwareversion RC35 1.16 |
Bei mir UBA 2.05, BC10 2.00, RC30 2.05. Ich glaube aber wie gesagt nicht, dass das dein Problem ist, da meine RC30 auch nur max. 27 Bytes liefert.
Habe mal mein Log angehangen... Also vom UBA-Softwarestand wäre das ja möglich dass sie zu alt ist. Allerdings hat die ziemlich wenig mit dem Telegramm zu tun. Meine RC30 hat auch 2.05. Vermutlich gibt es niemanden der den EMS-Gateway und Moosys Frontend benutzt. Deshalb ist es vermutlich nicht aufgefallen wenn das Problem am EMS-Gateway liegt. Habe erst den Livestatus angeklickt und nach dem Laden die Schaltprogramme... Die Datei ist ja in den 50 Sekunden recht groß geworden.. hätte ich nie gedacht... Vielleicht nicht mit *-d all...* loggen sollen??? Edit: Ist das der aktuelle Stand vom collector? Habe "Main" vom ems-collector genommen... Version EMS-Collector 2014031201
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.