die Protokolle des EMS-Bus auswerten und visualisieren kann:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io
Die Kosten des Projektes belaufen sich, Stand 12.2013, auf ca.:
Adapterplatine 6,00 € selbst gefertigt
AVR-NetIO 20,00 € Pollin Bausatz
ATmega644P 5,00 € Ersatz für ATmega32
RaspberryPi 39,00 € Modell B
SD-Card 16 GB 10,00 € für Raspi
Netzteil 5,00 € 5V, 1.5A
Sonstiges 5,00 € Kleinteile, etc.
--------------------------------
Summe 90,00 €
Die beigefügten Bilder zeigen auszugsweise, wie sich die Auswertung im
Browser darstellen kann.
Dieser neue Thread dient zur Entzerrung der EMS-Bus Hardware Thematik
und beschäftigt sich ausschließlich mit dem im Wiki vorgestellten
Projekt: Adapterplatine > AVRNetIO > RaspberryPi.
Bitte alle allgemeinen Hinweise und Anfragen zum EMS-Bus weiterhin
posten in: Beitrag "Faktensammlung Buderus EMS".
Gibt es die Möglichkeit den Adapter direkt an den Raspberry
anzuschließen. Der Raspberry hat doch auch eine UART Schnittstelle.
Könnte man den AVR Net-io so einsparen ? Bzw. ist vielleicht auch ein
Arduino denkbar ?
Thomas Ihmann schrieb:> Könnte man den AVR Net-io so einsparen
Wenn man den Framer für den Raspi umschreibt sollte das imho möglich
sein.
> Bauteilliste
Der Blackboard-Plan hat iirc eine Liste. Aber bei den "3" Bauteilen?!
charlie W. schrieb:> Wenn man den Framer für den Raspi umschreibt sollte das imho möglich> sein.
Na ich weiß nicht. Die Datentelegramme werden ja durch Framing errors
getrennt.
Sollte die Himbeere einen Framing error überhaupt detektieren können, so
wird dies wahrscheinlich nicht schnell genug vonstattengehen.
Es muss ja nicht gleich ein AVRNetIO sein, aber um einen kleinen µC mit
entsprechender Firmware kommt man hier m.E. nicht herum.
//Niffko
Oder gleich ein Beaglebone Black:
Adapterplatine 6,00 € selbst gefertigt
BeagleBone Black 45,00 €
Netzteil 5,00 € 5V, 1.5A
Sonstiges 5,00 € Kleinteile, etc.
--------------------------------
Summe 61,00 €
und packt den EMS-Code in das PRUSS (Programmable Realtime Unit
Subsystem http://elinux.org/Ti_AM33XX_PRUSSv2). Das sind zwei 200MHz
Kerne, die genau für solche Fälle geschaffen sind.
Nebenbei ist der Beaglebone deutlich flotter als das RPi und verbraucht
auch noch weniger Strom ...
Hallo zusammen,
ich habe mir jetzt
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io diverse
Male durchgelesen und muss sagen:
Den Großteil im Abschnitt "Adapter" und "NetIO" verstehe ich nicht.
Den Großteil im Abschntt "Raspberry Pi" aber sehr wohl. Wenn jemand in
der Lage ist mich mit einer entsprechenden Hardware auszustattem
(Raspberry Pi habe ich selbst), würde ich sehr gern ein natives
openhab-Binding dafür entwickeln. Also nicht auf Dannys Code aufsetzen,
sondern direkt aus dem Java-Code die Anbindung vorzunehmen.
Ich bin aber leider nicht in der Lage, mir so eine Platine
zusammenzuschustern. Ihr sollt das natürlich auch nicht kostenlos
machen. ;-)
Wenn mich da jemand unterstützen kann, wäre ich sehr dankbar.
Hallo!
Ich habe die Anleitung für den RaspberryPi verfolgt und hänge an der
Ausführbarkeit meines Daemons:
pi@raspberrypi ~ $ sudo service ems-collector restart
[warn] Stopping EMS collector daemon: collectord already stopped
(warning).
[....] Starting EMS collector daemon: collectordterminate called after
throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info
_injector<boost::program_options::too_many_positional_options_error> >'
what(): too many positional options
Aborted
failed!
Wer kann mir dazu etwas helfen?
Vielen Dank!
Hallo,
ich habe im Projekt gelesen, dass man den atmel32 gegen den atmel64
austauschen muss, weil man für das Projekt eben zwei solche
Schnittstellen braucht.
Mal nachgefragt: warum eigentlich?
Gruß, Bernd
Hallo,
habe nun fast alles beisammen. Wenn ich den Original Atmel im Net-IO
habe, dann klappt die serielle Kommunikation mit getip und so sofort.
Setze ich den 644P ein, kommt gar nichts.
Welchen Schritt habe ich übersehen?
Danke und Gruß
Bernd
Keine Firmware bisher - habe den 644 so wie er kam in den Sockel
gesteckt.
Ich fürchte ich muss noch einen ISP Programmer kaufen, um eine Firmware
zu flashen, oder?
Hallo miteinander,
ich lese schon seit geraumer Zeit mit und habe bislang vorwiegend von
der Community profitiert. Ich habe erfolgreich das Pollin-NETIO zum
Laufen gebracht und mittels Adapterplatine aus dem Wiki an den EMS-Bus
meiner GB132 Therme mit RC35 (1 ungemischter Heizkreis Fußbodenheizung,
1 Warmwasserspeicher mit Zirkulation) angebunden. Dannys ems-collector
läuft auf meinem Hausserver (Selbstbau, openSuSE Linux).
Jetzt ist es also langsam Zeit auch ein wenig was beizutragen.
Als erstes habe ich mal im EMS-Wiki bei den Telegrammen die Dinge
ergänzt, die ich beim Spielen mit meiner Therme herausgefunden habe
(u.a. Wartungsdaten, Funktionstest, ein paar Detailinfos). Ab sofort auf
Ingos Wiki :).
Als nächstes habe ich Dannys ems-collector-Software ein wenig ergänzt,
so dass sie nun fast alle im RC35 verfügbaren Funktionen abdeckt. Danny
prüft den Code gerade :).
Und schließlich habe ich ein PHP-Webinterface als Frontend gebastelt,
das so ziemlich alles abdeckt, was meine Therme kann. Sobald der
aktualisierte ems-collectord freigegeben ist, werde ich die Seiten zur
Verfügung stellen (vorher machts keinen Sinn, da die Seiten zum
ems-collector passen müssen).
Aber wie gesagt, zunächst mal das aktualisierte Wiki :).
Herzliche Grüße und nochmals einen RIESENDANK an alle, die durch ihre
Beiträge all das erst möglich gemacht haben,
Moosy
Also,
- NetIO zusammengebaut
- 644 P eingebaut
- 9V angeschlossen
- ATMEL ISP MKII besorgt
- Flachbandkabel - Adapter gebastelt
- Mit AVR Studio den 644 P mit dem Hex aus dem Wiki geflasht
- IP / Mac vergeben
- Ethersex HP geht auf
Wunderbar .. hat Spaß gemacht xD
... jetzt kommt der Raspberry :) ist der eigentlich unbedingt notwendig
?
Jetzt noch mal ne ganz dumme Frage, ich komm grade nicht drauf :)
EMS Bus <=> Selbstgebastelte Platine <=> 10pol. Stecker <=> 10.pol
Stecker <=> AVR Net IO <=> RS232 <=> USB <=> Raspberry Pi
Stimmt das in etwa ?
> - 9V angeschlossen
Stecker-Schaltnetzteil mit 5V/1A an der Buchse „J6“ ist energiesparender
und Deine Bude überheizt nicht ;)
> - Mit AVR Studio den 644 P mit dem Hex aus dem Wiki geflasht> - IP / Mac vergeben> - Ethersex HP geht auf
Dann scheint der HEX ok. Danke für die Rückmeldung! :)
> Raspberry :) ist der eigentlich unbedingt notwendig
Auf dem läuft der collector, der die Daten vom EMS absammelt und der
lighty o.ä., der Dir die Daten via http serviert. Aber es sollte auch
mit jedem anderen (Linux)Server klappen.
> Stecker <=> AVR Net IO <=> RS232 <=> USB <=> Raspberry Pi
... <=> AVR Net IO <=> ethernet <=> Raspberry Pi (orwhateveryouwant)
@Bernd
Nein, da bist Du völlig richtig. Ich habe Danny als Maintainer meine
Erweiterungen zukommen lassen, damit der die Aufnahme in das offizielle
Release prüfen kann. Da das erst vor ein paar Tagen war, ist er wohl
noch nicht dazugekommen.
Ich habe den sourcecode meiner aktuellen "Arbeitsversion" mal angehängt.
Es handelt sich hierbei nur um das collector-Verzeichnis, da ich an den
anderen nichts geändert habe.
Ich bitte um konstruktive Kritik :).
Achja: Wenn jemand meinen Programmierstil etwas seltsam findet, dann
liegt das daran, dass ich kein C++ kann ;)
Viele Grüße
Moosy
P.S: Diese Version ist work-in-progress und von daher mit Vorsicht zu
genießen, auch wenn sie bei mir soweit ich das beurteilen kann klaglos
funktioniert (GB132 mit RC35).
Zur Orientierung mal die Hilfe (das Prompt und die Begrüßung gibts mit
der neuen Startoption -i bzw. --enable-cli):
diego:/home/programming/Heizung/ems-collector # telnet localhost 7777
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Buderus EMS interface extended edition
(c) 2014 by Danny Baumann, Michael Moosbauer
For help type 'help'.
ems> help
Buderus EMS interface extended edition
(c) 2014 by Danny Baumann, Michael Moosbauer
Available commands (help with '<command> help'):
ww <subcommand>
-- hot water subsystem
hk[1|2|3|4] <subcommand>
-- heating subsystem
uba <subcommand>
-- the heater itself
getversion <deviceid>
totalhours
getcontactinfo [1|2]
setcontactinfo [1|2] <text>
geterrors geterrors2 geterrors3
emsqry [0xtarget 0xtype offset len]
-- do custom EMS query
emscmd [0xtarget 0xtype offset data]
-- write custom value to EMS device (CAUTION!!)
ems> uba help
Available subcommands:
antipendel <minutes>
hyst [on|off] <kelvin>
getstatus
getmaintenance
setmaintenance [ off | byhour <hours/100> | bydate DD-MM-YYYY ]
isinmaintenance
pumpdelay <minutes>
pumpmodulation <minpercent> <maxpercent>
testmode <brennerpercent> <pumpepercent> <3w-vent:0=heat,1=ww>
<zirkpump:0=off,1=on>
(use at own risk! repeat command periodically.)
ems> hk1 help
Available subcommands:
mode [day|night|auto]
daytemperature <temp>
nighttemperature <temp>
holidaytemperature <temp>
getholiday
holidaymode <start:DD-MM-YYYY> <end:DD-MM-YYYY>
getvacation
vacationmode <start:DD-MM-YYYY> <end:DD-MM-YYYY>
partymode <hours>
pausemode <hours>
minouttemp <temp>
building [leicht|mittel|schwer]
enabledamping [on|off]
minheatflowtemp <temp>
maxheatflowtemp <temp>
redmode [Abschalt|Reduziert|Raumhalt|Aussenhalt]
refinput [Raum|Aussen]
refinputvac [Raum|Aussen]
maxroomeffect <temp>
designtemp <temp>
schedoptimizer [on|off]
frostmode [off|Raum|Aussen]
tempoffset <temp>
frosttemp <temp>
summertimetemp <temp>
stopnighttemp <temp>
nightdoredtemp <temp>
getstatus
getstatus2
getstatus3
getstatus4
getpartypause
actschedule
chooseschedule
[Familie|Morgen|Frueh|Abend|Vorm|Nachm|Mittag|Single|Senioren|Eigen1|Eig
en2]
getschedule [1|2]
schedule [1|2] <index> unset
schedule [1|2] <index> [MO|TU|WE|TH|FR|SA|SU] HH:MM [ON|OFF]
ems> ww help
Available subcommands:
mode [on|off|auto]
temperature <temp>
limittemp <temp>
thermdesinfect mode [on|off]
thermdesinfect day
[monday|tuesday|wednesday|thursday|friday|saturday|sunday]
thermdesinfect temperature <temp>
thermdesinfect hour <hour>
getschedule [w|z]
getstatus
getstatus2
getstatus3
chooseschedule [Eigen1|Heizkreis]
schedule <index> unset
schedule <index> [MO|TU|WE|TH|FR|SA|SU] HH:MM [ON|OFF]
zirkpump mode [on|off|auto]
zirkpump count [1-6, 7=alwayson]
zirkpump chooseschedule [Eigen1|Heizkreis]
zirkpump schedule <index> unset
zirkpump schedule <index> [MO|TU|WE|TH|FR|SA|SU] HH:MM [ON|OFF]
loadled [on|off]
loadonce
canloadonce
ems>
Michael Moosbauer schrieb:
> Ich bitte um konstruktive Kritik :).
Grüß Gott Michel,
- Moosbauer klingt nach Südbayern, ich hoffe, die Anrede passt. ;)
Gute Arbeit, soweit ich das beurteilen kann!
Dann wollen wir mal auf Danny warten ... oder Du baust Deinen eigenen
Fork!?
Was ich noch interessant fände, wäre die Status-/Fehlermeldungen zu
vertexten. Etwa nach Muster:
-H 200 = Gerät im Heizbetrieb
3P 216 = Das Gebläse dreht nicht schnell genug
etc ...
Da könnte man in einer Tabelle alle relevanten Meldungen anlegen und
sähe anschließend Klartext. Hat jemand eine Idee zur Umsetzung, oder
findet Ihr das langweilig?
Wünsche weiterhin frohes Schaffen!
Gruß aus der Wetterau
Karl M.
Hi Karl,
ja, komme aus Puchheim :).
Ich habe alle (fast) Statusmeldungen aus der Buderus-Serviceanleitung
extrahiert und in mein Webinterface eingebaut (siehe im Anhang 2
Ausschnitte aus meiner Web-Bedienoberfläche).
Aber veröffentlichen kann man das ja wohl nicht, da doch Buderus die
Urheberrechte an seinen Textschnipseln hat, oder?
Viele Grüße
Moosy
P.S: Wer findet den "Fehler" in der Anzeige, der davon kommt, dass ich
extra für Euch die Anlage in den Tagbetrieb geschaltet habe und dann zu
früh den Screenshot gemacht habe?
Danke Charlie W. :) .. sorry ich versuch mich gerade da etwas
reinzudenken.
Gut wir haben eine Ethernet Verbindung zb. über einen Switch zwischen
AVR - NetIO und Raspberry.
Jetzt mal meine Frage .. was wird an Daten zwischen Rasp und NETIO
ausgetauscht ? Welches Protokoll ?
Nächste Frage :
# Other options -- db-user, db-pw, rate-limit (s) to write to db, target
OPTIONS="-u ems -p password -r 60 tcp:192.168.xxx.xxx:7950"
Muss hier die Lokale IP Adresse des Rasp rein oder die des NET IO ?
Danke !
Hallo, Flobo,
ich bin an derselben Stelle des Fortschritts ;-)
Die IP ist die des Net-IO, der Port 7950 ist im Ethersex fest
vorgegeben, die u und p sind die MySQL Userdaten des Raspi für den
ems-collector daemon, der auf dem Raspi laufen muss. Soweit mein
Verständnis.
Ich bekomme derzeit noch keine zuverlässigen Daten und frage mich, ob
das an den ca. 10m Telefonkabel zwischen dem Pegelwandler und der
Heizung liegen kann...
Ich habe den Pegelwandler an PIN 1 (TX) und PIN 9 (GND) des EXT Ports am
Net-IO angeschlossen, aber es passiert nix sinnvolles. (Probehalber an
PIN 2 auch nicht)
Mein Pegelwandler an einem TTLUSBUART liefert einen kontinuierlichen
Datenstrom von Unsinn, aber immerhin.
Kann mir an dieser Stelle jemand weiterhelfen?
Danke und Gruß
Bernd
Naja :) nun habe ich ein weiteres Problem xD
Wenn ich nun versuche den Daemon zu starten werde ich mit folgender
Meldung begrüßt :
service ems-collector start
[....] Starting EMS collector daemon: collectordterminate called after
throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info
_injector<boost::program_options::invalid_command_line_syntax> >'
what(): required parameter is missing in 'config-file'
Aborted
failed!
Hab mich Streng an die Anleitung gehalten :( was könnte das sein ?
Ich hab mit Erfolg den 4-Teile Programmer nachgebaut.
Noch nie habe ich nur 40,- Ct an der Conrad-Kasse bezahlt, tolles Gefühl
;-))
Danke, das hat schon mal funktioniert!
Hier taucht nochmal ne Frage zum Ethersex auf:
> Die Portbelegung des ATmega644p stellt sich jetzt wie folgt dar:> PD2 = RX
ja, PD2 ist ja auch der Empfänger.
Allerdings taucht der nicht im Pinning des netio.4 auf?
Da würde ich mal auf Ethersex nachfragen.
Irgendwie fehlt mir da ein:
ifdef(`conf_EMS', `
pin(EMS_UART_RX, PD2)
')
Charlie, sagt Dir das was?
Gruß, Bernd
Zitat aus dem Wiki:
Vor dem Kompilieren sind noch folgende Änderungen in
“./pinning/hardware/netio.4“ vorzunehmen:
ifdef(`conf_ONEWIRE', `dnl
/* onewire port range */
ONEWIRE_PORT_RANGE(PD5, PD5)
')dnl
ifdef(`conf_EMS', `
pin(EMS_UART_TX, PD3)
')
ifdef(`conf_STATUSLED_EMS_TX', `
pin(STATUSLED_EMS_TX, PD4, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_OK', `
pin(STATUSLED_EMS_RX_OK, PD6, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_FAIL', `
pin(STATUSLED_EMS_RX_FAIL, PB0, OUTPUT)
')
Nun meine Situation:
“./pinning/hardware/netio.4“ gibt es nicht, aber
“./pinning/hardware/netio.m4“, also nehme ich diese
ifdef(`conf_ONEWIRE', `dnl
/* onewire port range */
ONEWIRE_PORT_RANGE(PD5, PD5)
')dnl
ifdef(`conf_EMS', `
pin(EMS_UART_RX, PD2)
')
ifdef(`conf_EMS', `
pin(EMS_UART_TX, PD3)
')
ifdef(`conf_STATUSLED_EMS_TX', `
pin(STATUSLED_EMS_TX, PD4, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_OK', `
pin(STATUSLED_EMS_RX_OK, PD6, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_FAIL', `
pin(STATUSLED_EMS_RX_FAIL, PB0, OUTPUT)
')
Kann mir das jemand bestätigen?
(Gelöst wurde mein Problem dadurch jedenfalls nicht... ich erhalte nach
wie vor keine Daten.)
Bernd Gewehr schrieb:
> “./pinning/hardware/netio.4“ gibt es nicht, aber> “./pinning/hardware/netio.m4“, also nehme ich diese
Schreibfehler von mir, sorry, ist korrigiert.
@Bernd:
Du hast Post.
@Flobo:
Zeig mal Deine
1. /etc/default/ems-collector
2. /etc/init.d/ems-collector
oder klappt's mittlerweile?
@Moosy:
Tolle Wurst! Du hast ja schon alles erledigt, was ich mir noch
vorgenommen hatte. Wieso hast Du Bedenken, das öffentlich zu machen. Ist
doch Dein Werk!
Abend :)
@Bernd: Hast Du eigentlich die Fuses beim Atmega richtig gesetzt? Ich
musste das trotz Einstellung im make menuconfig noch von Hand machen.
Vorher hatte ich das gleiche Symptom wie Du: Ethersex Webseite geht,
Pins lassen sich schalten, aber keine Daten. Vermutlich weil wegen
falscher Taktrate das Timing hinten und vorne net stimmte.
Brenn mal Deine Fuses auf
(e7) Fuse Low Byte (FLB)
(dc) Fuse High Byte (FHB)
(ff) Extended Fuse Byte (EFB)
Danach ging's bei mir ab wie ein Zäpfchen g
@Charlie W: Ja, die PHP-Seiten werd ich demnächst zur Verfügung stellen
(wenn ich den Code soweit separiert habe, dass er auch wo anders als bei
mir laufen sollte). Ich hab nur ein wenig Bedenken wegen meiner
Zuordnungsdatei Fehlercode -> Text... Die besteht zu 90% aus Text aus
dem Servicemanual :)
Hallo, Moosy,
danke, super Tip, meine Fuses waren tatsächlich ganz anders gesetzt,
obwohl ich die schon in make menuconfig sauber angegeben hatte. Hab ich
korrigiert.
Dennoch, mein EMS2TTL-Pegelwandler schafft es nicht, dem uC Signale zu
servieren, die er als seriellen Datenstrom verarbeiten kann.
Hat den der 644P an seinem zweiten UART keine TTL-Pegel?
Oder ist bei einer Leitungslänge von ca. 8-10 m Telefonkabel sowieso
kein zuverlässiges Signal mehr zu erwarten?
(Obwohl: der Raspi mit USBTTLUART schön brav kontinuierlichen Unsinn
empfängt...)
Ich traue mir den Aufbau der Schaltung von NEFFKO nicht wirklich zu,
kann auch kein Blackboard File öffnen (warum eigentlich kein einfaches
Bild?), gibt es evtl. lötwillige Helfer hier im Forum?
Danke und Gruß, Bernd
Servus,
ich kann dir so eine zusammenlöten, ich probiere momentan auch mit dem
EMS Bus Anschluss selber rum. Komme allerdings erst nächste Woche zum
Testen des ganzen Konstrukts da die Heizung nicht bei mir Voort ist.
Kann mir jemand mal ein Bild posten in dem ersichtlich ist, wo genau man
an dem EMS Bus bei der Heizung anschließen muss ?
Solange es dir nichts ausmacht das das ding auf ner Lochrasterplatine
bestückt ist :) .. ich arbeite allerdings bei erfolgreichen Tests mit
einem Freund zusammen an einem geätzten Platinenlayout.
Ich denke ich werde diese dann auch zum Kauf anbieten :) ich muss mich
momentan nur mit dem rechtlichen diesbezüglich auseinandersetzen.
Aber soweit ich weiß unterlegen Protokolle nicht dem Patentrecht, somit
sollte es machbar sein einen EMS Pegelwandler feilzubieten.
Grüße
Flobo
@Bernd:
> Hat den der 644P an seinem zweiten UART keine TTL-Pegel?
5V != RS-232
> ca. 8-10 m Telefonkabel
Dürften überhaupt kein Problem darstellen. Bei mir ist es mehr.
@Flobo:
> wo genau man an dem EMS Bus bei der Heizung anschließen muss ?
Entweder:
1. Am Gerät. Orange Buchse, Aufdruck "RC" (bei meinem GB162).
2. Am RCxx.
> Pegelwandler im geätzten Platinenlayout
Sehr fein!
Gruß aus der Wetterau
Karl M.
Mal was anderes: Welche NetMask soll am PC verwendet werden, um das
frisch geflashte Net-IO unter 192.168.0.0 anzusprechen, damit man mit
ECMD die IP setzen kann?
Servus,
ich habe die 255.255.255.0 verwendet, einfach in den Browser eingeben,
kein Gateway oder DNS.
Es sollte dann als Bestätigung ein herzliches OK kommen.
Die MAC Adresse nimmst du von dem nicht mehr verwendeten ATmega32.
Ich hab mal einen pull request losgetreten...
Ich bin mir nicht ganz sicher, ob die Zielsetzung meines Codes die
gleiche ist wie Dannys, aber dazu wird er sich sicher demnächst äußern.
Ich strebe ein Tool an, das sowohl als Backend für z.B. Webinterfaces
taugt als auch als CLI zur kommandozeilenbasierten Bedienung.
Danny sieht das Ganze wohl eher als reines Machine2Machine-Interface.
Na mal sehen, was er so sagt :)
Hi,
Sorry for posting in English, I can read German if I try hard enough but
not write it well enough to be understandable. Hope this is OK?
I spend at least 10 hours over the last weeks to read and try to
understand all information on this forum regarding interfacing the EMS
bus with a PC. I have a Nefit (Dutch brand) heater that I want to
control through a home automation system (based on IP Symcon). From what
I understand, Nefit and Buderus are under the same umbrella and they
both use EMS. That is why I ended up finding this forum through Google.
I think I roughly understand the current state of affairs but I'd
appreciate if somebody could confirm the following:
There are two ways to communicate with an EMS bus:
- Through a dedicated and hard to build (for non-experts) circuit board,
which has a USB or serial interface, directly into a PC;
- Or through a simple to build circuit board (which can be build on a
bread board) as described on the EMS>Adapter>NetIO>Raspi page of the
wiki. The circuit board need a ATmega644P instead of the ATMega32 that
is on it standard. This circuit board interfaces with a NetIO module,
through a regular 5x2 wire flat cable. The firmware to be flashed to
this module is standard, that is to say, the EMS code is part of the
standard distribution of AVR. It needs to be compiled on a PC, then
flashed to the module using something like e.g. the mySmartUSB
programmer. This module can communicate with a PC through Ethernet.
There exists a daemon, called ems-collector, which periodically polls
the NetIO module and stores measurements of temperatures. It also
provides an interface to enter commands and read certain configuration
parameters.
Is this correct so far?
If so, for my purposes, I could leave out the ems-collector and hence
the RaspberryPi, and just query the NetIO module directly from my home
automation software. The protocol is a relatively simple binary
request/response design, which is 'documented' in the ems-collector
source code; I can also check my implementation by using a sniffer to
check the byte streams ems-collector sends vs what my own software
sends. Correct?
Alternatively, I can extend ems-collector to be non-interactive so that
I can use command-line calls from my home automation software, or I
could turn ems-collector into a PHP module so that it can be used
directly from IP-Symcon (which is largely based around PHP).
This second route I described is doable for somebody like me who is a
software engineer but can only solder simple kits together and has no
further knowledge of electronics. I'd just go to an electronics shop,
buy the parts that are on the schematic, solder it literally following
the lines on the schematic, and that should be it. Right?
Considering all this, is there still a reason to go the dedicated, hard
to build circuit board route? Or am I missing a disadvantage of the
NetIO-based approach?
Thanks to anyone reading this far!
regards,
Roel
Hoi Roel,
Roel schrieb:
> ...> the NetIO module and stores measurements of temperatures. It also> provides an interface to enter commands and read certain configuration> parameters.>> Is this correct so far?
... absolutely!
And as a software engineer you are able to modify or alter or just use
the idea of the existing collector-code.
> Considering all this, is there still a reason to go the dedicated, hard> to build circuit board route? Or am I missing a disadvantage of the> NetIO-based approach?
IngoFs board, that's what you're talking about, I suppose, has an
additional CAN interface. But both ways lead to the point, that yo can
read and write EMS ;)
Groetjes
Karl M.
Hallo,
ich komme zwar mit der Elektronik nicht weiter und warte auf FLOBOs
Platinen, aber das hier kann ich vielleicht bis dahin schon mal beheben:
pi@raspberrypi $ telnet 127.0.0.1 7777
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Kann mir dazu jemand was sagen?
Danke und Gruß
Bernd
Hallo Michael,
sieht ja super aus. Ist in Danny's Code / Deinem Fork schon etwas zur
Solarthermie drin ? Muß noch meine Hardware basteln, dann gehts los.
Habe eine Buderus Anlage mit Solarthermie, mit Steuerung / Anzeige über
RC35.
Oder auch:
pi@raspberrypi $ telnet localhost 7777
Trying 127.0.0.1...
Trying ::1...
telnet: Unable to connect to remote host: Address family not supported
by protocol
Sagt mir leider auch nichts...
Hallo Michael,
Michael Moosbauer schrieb:
> Rückmeldung gerne willkommen ;)
Habe gerade mal etwas genauer drüber geschaut. Sieht ja super aus! Du
musst ein sehr fleißiger Mensch sein, Michael. ;)
Wie ich eben auf GitHub gelesen habe, will Danny Deine Änderungen, wenn
er mal Zeit findet, übernehmen. Na, dann übe ich mich in Geduld und
harre der Dinge. |-0
Vielen Dank auf alle Fälle schon mal für die tolle Arbeit!
Gruß in's schöne Oberbayern
Karl M.
@Thomas I:
Nein, leider nicht. Weil ich keine Solaranlage habe. Das müsste jemand
rausfummeln, der eine hat zwinker :)
Der Einbau eines neuen Features ist eigentlich immer gleich:
1. Identifizierung der Parameter/Werte, die man ändern/einstellen kann
2. Herausfinden, in welchen Telegrammen sie stecken. Das geht mit meiner
Version des collectord recht leicht:
a) emsqry DE TY 0 25 , wobei DE das DEVICE is (also 10=RC35, 08=UBA),
und TY der Telegrammtyp, den man im Verdacht hat, dass er
zuständig
ist.
Ausgabe merken.
b) Wert am RC35 verstellen
c) a) wiederholen. Wenn sich was geändert hat, ist es ein heißer
Kandidat.
d) a) - c) wiederholen um sicherzugehen
e) emsqry DE TY OFF 1 , wobei OFF der ausgezählte Offset ist,
so lange probieren, bis genau dieser eine Wert da steht
f) emscmd DE TY OFF <andererWert> und gucken, ob sich der Wert am
RC35 geändert hat.
WENN NICHT: mit emscmd DE TY OFF <Wert aus e)> alten Wert
wiederherstellen.
3. Für die Messwerte parallel die Werte am RC35 ablesen und per emsqry
gucken, ob man sie irgendwo findet (dabei beachten: emsqry liefert
hex,
Temperaturen sind oft verdoppelt 30° = 60 oder verzehnfacht 30° =
300).
4. Ins EMS-Wiki eintragen (lassen)
5. In den ems-collectord einbauen (lassen)
6. Ins Webinterface einbauen (lassen)
:D
Viele Grüße
Moosy
@Thomas I:
Wenn Du das EMS-Interface zum Laufen bekommen hast, dann spiel doch mal
ein wenig mit den Typen
0x96 ParameterSolar
0x97 MonitorSolar
Ich vermute, mit 0x96 kann man die Einstellungen ändern und mit 0x97
kommen die Messwerte an (analog WW 0x33 Parameter und 0x34 Monitor) ...
So, ganz nebenbei bin ich dabei, meine Codebasis so aufzudröseln, dass
Danny sie einfach(er) häppchenweise integrieren kann.
Ich habe daher meinen master-Branch in git neu auf Basis von Dannys
aktueller Version aufgesetzt. Der kann natürlich noch lange nicht alles.
Meine Version, die man auch für das Webinterface braucht, habe ich im
Branch develop ausgelagert.
Wer also mein Webinterface ausprobieren will, der muss den collectord
aus
git clone -b develop https://github.com/moosy/ems-collector
verwenden. :)
Viele Grüße
Moosy
Charlie W. schrieb:> Bernd Gewehr schrieb:>> telnet: Unable to connect to remote host:> starte mal den collectord
Nachdem ich unter Verwendung der richtigen dev-Pakete neu compiliert
habe, funktioniert nun auch mein telnet-Zugriff.
Die Erkenntnis ist: mein debian Linux hat die Version 3.10.25+ und
benötigt libboost1.49-all-dev UND libboost1.49-dev und natürlich die
restlichen Pakete wie im Wiki beschrieben. Damit ging's dann...
Gruß, Bernd
So, Michael's Änderungen sind jetzt alle komplett gemergt, d.h. das
Kommando-Interface von ems-collector hat jetzt eine Unmenge Optionen
zusätzlich. Danke Michael :) Lediglich die direkten Lese-Schreibbefehle
('raw write <dest> <type> <offset> <data>' und 'raw read <dest> <type>
<offset> <len>', vorher emscmd und emsqry) müssen im Makefile aktiviert
werden.
Neu ist auch, dass das Kommando-Interface mit der Kommandozeilenoption
-C (oder --command-port) explizit aktiviert werden muss; und dass es
einen weiteren Port gibt, der den Livedatenstrom ausgibt (Option -D bzw.
--data-port).
Roel schrieb:> There are two ways to communicate with an EMS bus:>> - Through a dedicated and hard to build (for non-experts) circuit board,> which has a USB or serial interface, directly into a PC;
If you only want to read from the EMS, an adapter which takes the EMS as
input and has an RS232 output can be built reasonably simply. Something
like http://www.mikrocontroller.net/attachment/70536/EMSlog.gif (minus
Q1, R5 and R6) will do; the firmware for the Atmega8 can be found in the
framer/ directory of ems-collector). For sending it's not as
straightforward as the Atmega8 only has one UART.
Directly interfacing the EMS to a PC isn't really a viable solution due
to timing constraints, as pointed out by Niffko.
> - Or through a simple to build circuit board (which can be build on a> bread board) as described on the EMS>Adapter>NetIO>Raspi page of the> wiki. The circuit board need a ATmega644P instead of the ATMega32 that> is on it standard. This circuit board interfaces with a NetIO module,> through a regular 5x2 wire flat cable. The firmware to be flashed to> this module is standard, that is to say, the EMS code is part of the> standard distribution of AVR. It needs to be compiled on a PC, then> flashed to the module using something like e.g. the mySmartUSB> programmer. This module can communicate with a PC through Ethernet.> There exists a daemon, called ems-collector, which periodically polls> the NetIO module and stores measurements of temperatures. It also> provides an interface to enter commands and read certain configuration> parameters.
Correct, with two minor corrections: 'standard distribution of AVR'
actually is 'standard distribution of a commonly used custom AVR
firmware called ethersex', and ems-collector doesn't periodically poll
the NET-IO for data, but opens a TCP connection and just waits for the
data pushed into the connection by the NET-IO.
> If so, for my purposes, I could leave out the ems-collector and hence> the RaspberryPi, and just query the NetIO module directly from my home> automation software. The protocol is a relatively simple binary> request/response design, which is 'documented' in the ems-collector> source code; I can also check my implementation by using a sniffer to> check the byte streams ems-collector sends vs what my own software> sends. Correct?
You can do that, but why would just want to redo the framing decoding
etc. done by ems-collector a second time instead of using
ems-collector's interface?
> Alternatively, I can extend ems-collector to be non-interactive so that> I can use command-line calls from my home automation software, or I> could turn ems-collector into a PHP module so that it can be used> directly from IP-Symcon (which is largely based around PHP).
ems-collector already is (designed to be) non-interactive. (At least) me
and Michael are already using its TCP interface from PHP code. The TCP
interface may look like a CLI as it's text based and usable via telnet,
but it's not the intended use case and neither is the telnet protocol
actually implemented (which is why Ctrl+C doesn't close the connection).
The intended use case is using it as a machine interface from client
software (PHP, Java, whatever).
> This second route I described is doable for somebody like me who is a> software engineer but can only solder simple kits together and has no> further knowledge of electronics. I'd just go to an electronics shop,> buy the parts that are on the schematic, solder it literally following> the lines on the schematic, and that should be it. Right?
Hopefully yes :)
> Considering all this, is there still a reason to go the dedicated, hard> to build circuit board route? Or am I missing a disadvantage of the> NetIO-based approach?
The main advantage of the NET-IO approach is that one doesn't need close
proximity between the EMS and the machine evaluating the data. In my
particular case, both are in exactly opposide sides of the house.
Danny Baumann schrieb:> So, Michael's Änderungen sind jetzt alle komplett gemergt> ...
Michael arbeitet an seinem Fork weiter, Du an Deiner Software ?)
Meine Fragen: "Wo sind die Unterschiede derzeit, wohin soll die Reise
gehen? Bleibt es bei dem Fork? Wenn ja, mit welcher Absicht?"
Ihr seht, ich bin total verwirrt, wie weiland Nena. Vielleicht könnt Ihr
mir ein wenig aus meiner Konfusion helfen. Fänd' ich total super.
Gruß
Karl M.
Charlie W. schrieb:> Danny Baumann schrieb:>> So, Michael's Änderungen sind jetzt alle komplett gemergt>> ...>> Michael arbeitet an seinem Fork weiter, Du an Deiner Software ?)>> Meine Fragen: "Wo sind die Unterschiede derzeit, wohin soll die Reise> gehen? Bleibt es bei dem Fork? Wenn ja, mit welcher Absicht?"
Ich kann natürlich nicht für Michael sprechen, ich denke aber, dass der
Plan ist, das PHP-Frontend auf die nun gemergten Änderungen umzustellen,
d.h. das Frontend mit dem Collector aus meinem Repo gängig zu machen -
ansonsten hätte man sich die Mühe des Einreichens ja sparen können?
Hi Danny,
Danny Baumann schrieb:> Ich kann natürlich nicht für Michael sprechen
.. ist schon klar, trotzdem Danke für die rasche Antwort!
Dann warten wir noch auf Bayern. ;)
Gruß aus der Wetterau
Karl M.
Sodala, da bin ich wieder :)
Klar ist der Plan, das ganze Teil auf den "neuen" collectord
umzustellen.
Ich habe die letzten Nächte gecodet wie verrückt ;)
Nochmals danke an Danny für das mergen (was ist mit den letzten paar
kleinen Bugfixes... ;) ).
Ich habe die Gelegenheit genutzt und das PHP-Frontend komplett umgebaut.
Es werden nun keine Daten mehr aus Logfiles entnommen.
Stattdessen sieht der Aufbau mittlerweile so aus:
Ethersex <--> collectord <--> emscache <--> frontend
Der emscache ist ein kleiner Daemon, der den Livestream des collectord
auswertet und die Daten inkl. Zeitstempel cached. Somit sind bei einer
Anfrage stets alle Daten sofort verfügbar, incl. Angabe, wie aktuell
diese sind.
Das Frontend verbindet sich also doppelt: Zum Daten holen mit dem
emscache und zum Kommandos absetzen mit dem collectord.
Zusätzlich zur Funktion doEmsCommand() gibts nun die Funktion
doEmsDataCommand, die auf dem Kommandoport nach Daten fragt und diese
dann aus dem emscache zieht.
Es gibt nun auch zwei Frontends: Erstmal das PHP-Webinterface, das ich
bei dieser Gelegenheit weitgehend auf AJAX (naja, sowas ähnliches ;) )
umgebaut habe, um die ewigen Ladezeiten und Servercycles zu umgehen. Es
gibt also (fast) keine "Setzen" Buttons mehr, Wert ändern genügt. Und
wenn man an der RC35 oder anderswo nen Wert ändert springt der Wert im
Webinterface auch mit um (nach kurzer Verzögerung).
Und außerdem gibts noch ein CLI mit Commandhistory und "Verzeichnissen"
und ein paar builtin commands:
diego:/home/programming/Heizung/emsclient # emsclient
EMS-Client V0.1 (c) 2014 by Michael Moosbauer
Connecting to EMS-Bus... OK!
ems:/> cd ww
ems:/ww> req
warmwaterminutes = 190783
warmwaterpreparationactive = off
warmwatersystemtype = large
warmwatertempok = on
ww boostcharge = off
ww currenttemperature = 50
ww customschedule = off
ww daymode = off
ww desinfection = on
ww desinfectionactive = off
ww desinfectionday = tuesday
ww desinfectionhour = 1
ww desinfectiontemperature = 70
ww masterswitch = on
ww maxtemperature = 80
ww onetimeload = off
ww onetimeloadindicator = off
ww opmode = auto
ww settemperature = 53
ww targettemperature = 10
zirkpump customschedule = off
zirkpump daymode = off
zirkpump opmode = auto
zirkpump switchpoints = 3x
zirkpumpactive = off
ems:/ww> cd zirkpump
ems:/ww/zirkpump> mode auto
OK
ems:/ww/zirkpump> cd /hk1
ems:/hk1> help
Available subcommands:
mode [day|night|auto]
daytemperature <temp>
nighttemperature <temp>
temperatureoverride <temp>
getholiday
holidaymode <start:YYYY-MM-DD> <end:YYYY-MM-DD>
vacationtemperature <temp>
getvacation
vacationmode <start:YYYY-MM-DD> <end:YYYY-MM-DD>
partymode <hours>
pausemode <hours>
getactiveschedule
selectschedule
[family|morning|early|evening|forenoon|noon|afternoon|single|senior|cust
om1|custom2]
getcustomschedule [1|2]
customschedule [1|2] <index> unset
customschedule [1|2] <index> [monday|tuesday|...|sunday] HH:MM [on|off]
scheduleoptimizer [on|off]
minheatflowtemperature <temp>
maxheatflowtemperature <temp>
reductionmode [offmode|reduced|raumhalt|aussenhalt]
relevantparameter [outdoor|indoor]
vacationreductionmode [outdoor|indoor]
maxroomeffect <temp>
designtemperature <temp>
temperatureoffset <temp>
frostprotectmode [off|byoutdoortemp|byindoortemp]
frostprotecttemperature <temp>
summerwinterthreshold <temp>
reducedmodethreshold <temp>
vacationreducedmodethreshold <temp>
cancelreducedmodethreshold <temp>
requestdata
OK
ems:/hk1>
Das CLI ist noch sehr Alpha, es fehlt noch mindestens Tab-Completion und
eine ausführlichere Hilfe.
Der emscache ist auch noch nicht ganz fertig, denn da soll die
Funktionalität der Mail-Benachrichtigung mit rein, so dass man sich
einen weiteren Cronjob spart.
Außerdem soll diese Funktionalität leicht erweiterbar sein, so dass
jeder je nach Gusto auf verschiedene Dinge reagieren kann (Wenn das
Warmwasser am Morgen heiß genug ist, schicke eine Nachricht aufs Handy
"Kannst jetz baden!") oder so ;)
Ich werd noch ein bissl brauchen, bis alles von anderen verwendbar ist.
Außerdem fehlen in Dannys repo noch ein paar kleine Commits (ist der im
Urlaub?)
Vermutlich wirds auf ein weiteres Repo "emstools" hinauslaufen mit dem
cached und dem CLI (emsclient), wo auch die grundlegenden PHP-includes
mit drin sind, und darauf aufbauend dann das Webinterface.
Mal gucken ;)
Viele Grüße
Moosy
Okokok, ich seh schon, ich werd ein Pre-Release machen :)
Also:
Der derzeit aktuelle EMS-Collector ist der hier:
https://github.com/moosy/ems-collector
weil Danny die letzten kleinen Commits von mir noch nicht gemerged hat
(ich denke, er kam noch nicht dazu, weil es eigentlich alles reine
Mini-Bugfixes sind, die offensichtliche Tipp- bzw. Copy/Pastefehler
betreffen).
Sobald diese fixes mit drin sind, wird die einzige relevante offizielle
Version des collectors (wieder) diese hier sein:
https://github.com/maniac103/ems-collector
Diese Versionen sind vom Befehlssatz und von den Schnittstellen
weitgehend INKOMPATIBEL zum alten Webinterface!!
Um den neuen collectord mit Webinterface zu verwenden, braucht es:
1. Das repo ems-tools von mir (das noch nicht online ist, aber bald)
2. Das neue ems-php-webinterface (das auch noch nicht online ist, aber
bald).
Ich mach jetzt mal folgendes:
Ich bring meine aktuelle Bastelversion soweit auf den Stand, dass sie
standalone lauffähig ist, trenne sie auf in die ems-tools und das
ems-php-webinterface und lade die Dinger mal hoch, auch wenn noch ein
paar Dinge fehlen.
Die kommen dann später per commits dazu.
Aber ich sehe schon, es besteht Bedarf für die neue Version ;)
Viele Grüße
Moosy
Michael Moosbauer schrieb:> Nochmals danke an Danny für das mergen (was ist mit den letzten paar> kleinen Bugfixes... ;) ).
Ich dachte, es kommt noch ein Pull Request ;) Ich schau sie mir morgen
mal an.
> Stattdessen sieht der Aufbau mittlerweile so aus:>>> Ethersex <--> collectord <--> emscache <--> frontend>> Der emscache ist ein kleiner Daemon, der den Livestream des collectord> auswertet und die Daten inkl. Zeitstempel cached. Somit sind bei einer> Anfrage stets alle Daten sofort verfügbar, incl. Angabe, wie aktuell> diese sind.
Interessant. Das heißt, du benutzt den Livestream gar nicht aus dem
Frontend? In dem Fall könnte man den Cache ja auch in den ems-collector
packen und sich das Erzeugen und Parsen des Streams sparen...
Wie sieht denn dein Abfrage-Interface für den Cache aus?
> Außerdem fehlen in Dannys repo noch ein paar kleine Commits (ist der im> Urlaub?)
Nein, einfach nur mit anderen Dingen beschäftigt; ansonsten siehe oben.
;)
Ich kann's kaum erwarten mit all dem Neuen zu experimentieren! DANKE!
Kompiliert Ihr den collectord mit libboost1.49 oder mit libboost1.50?
Bei mir wird bei der Installation von libmysqlcppconn-dev immer
gemeckert, dass libboost1.50-all eben nicht libboost-dev ist und daher
libboost1.49-all benötigt wird. Wenn ich libboost1.50-all installiere,
wird libmysqlcppconn deinstalliert.
Also compiliere ich mit libboost1.49-all
Ergebnis:
Ich bekomme den telnet-Service des collectord nicht angesprochen (immer
noch nicht), ich erhalte immer connection refused...
Weiss jemand Rat?
Bernd Gewehr schrieb:> Ich kann's kaum erwarten mit all dem Neuen zu experimentieren! DANKE!>> Kompiliert Ihr den collectord mit libboost1.49 oder mit libboost1.50?
1.49 sollte völlig ok sein.
> Ergebnis:> Ich bekomme den telnet-Service des collectord nicht angesprochen (immer> noch nicht), ich erhalte immer connection refused...
Hast du den Parameter -C bzw. --command-port angegeben?
Nein, bitte genauere Angaben:
Usage: /usr/local/sbin/collectord [options] <target>
General options:
-h [ --help ] Show this help message
-r [ --ratelimit ] arg (=60) Rate limit (in s) for writing numeric
sensor values into DB
-d [ --debug ] arg (=none) Comma separated list of debug flags (all,
io,message, data, stats, none) and their files, e.g.
message=/tmp/messages.txt
-i [ --enable-cli ] Open the API interface (port 7777) as CLI
(interactive)
Daemon options:
-P [ --pid-file ] arg (=/var/run//usr/local/sbin/collectord.pid)
Pid file path
-f [ --foreground ] Run in foreground
-c [ --config-file ] arg File name to read configuration
from
Database options:
--db-path arg Path or server:port specification of database
server (none to not connect to DB)
-u [ --db-user ] arg Database user name
-p [ --db-pass ] arg Database password
Kann es sein, dass das telnet-Interface des collectord erst nach
erfolgreichem Verbindungsaufbau zum EMS-Bus aktiviert wird? Das würde
einiges erklären, ich warte nämlich immer noch brennend auf meine
Niffko-Platine von Flobo
... teste also "auf dem Trockenen".
Hallo zusammen,
ich hab meinen Krempel mal hochgeladen ;)
https://github.com/moosy/ems-toolshttps://github.com/moosy/ems-php-webinterface
Bitte zuerst die ems-tools ans Laufen bringen, und mittels des
emsclient testen. Wenn das geht, das ems-php-webinterface nachziehen.
Obwohls bei mir prima läuft, kanns bei Euch noch hakeln.
Bitte um Rückmeldung ;)
@Danny: Klar könnte man das cachen auch im collector machen. Das geht
ohne Änderung des aktuellen Frontends, wenn er auf Port 7779 lauscht,
und auf "getdata<cr>" hin sowas ausgibt:
diego:/home/programming # telnet localhost 7779
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
getdata
3wayonww = off | 1394319165
antipendelminutes = 15 | 1394317836
[...]
zirkpump opmode = auto | 1394315137
zirkpump switchpoints = 3x | 1394315136
zirkpumpactive = off | 1394319165
OK
Momentan versteht der cached genau 3 Befehle: getdata, flush und quit
:).
Wobei in der Praxis eigentlich nur getdata zum Einsatz kommt.
Als nächstes soll der cached noch Trigger bekommen, so dass z.B. bei
Störung eine Mail geschickt wird und so.
Wobei es natürlich nicht schlimm wäre, wenn der cached dann nur noch
diese Funktionen hat und das cachen im collector passiert ^^.
Und der liefert halt eine alphabetisch sortierte Liste aller
data-Port-Ausgaben ergänzt um einen (Unix-)Zeitstempel bei jedem
einzelnen Wert, wann das letzte Update war.
Achja: Pull Request #13 ist immer noch offen ;)
LG
Moosy
Bernd Gewehr schrieb:> Kann es sein, dass das telnet-Interface des collectord erst nach> erfolgreichem Verbindungsaufbau zum EMS-Bus aktiviert wird? Das würde> einiges erklären, ich warte nämlich immer noch brennend auf meine> Niffko-Platine von Flobo
Ja, das ist in der Tat so. Da man ohne bestehende EMS-Verbindung ja eh
nix tun kann, lauscht der Collector erst dann auf Kommandos, wenn er
sich selbst mit der Gegenstelle verbunden hat.
Michael Moosbauer schrieb:> @Danny: Klar könnte man das cachen auch im collector machen. Das geht> ohne Änderung des aktuellen Frontends, wenn er auf Port 7779 lauscht,> und auf "getdata<cr>" hin sowas ausgibt:
Done, wenngleich etwas anders: Port 7777 hat jetzt ein 'cache
fetch'-Kommando. 'cache fetch' ruft alles ab, 'cache fetch hk1' alle
Werte von Heizkreis 1, 'cache fetch targettemperature' halt alle
Solltemperaturen (usw. usf.) Die Formatierung habe ich so wie bei dir
gelassen. Ich hab's auch mit dem Webinterface getestet (ems_data_socket
rausgerissen und den Kommandonamen aktualisiert) - funktioniert :)
Ich denke noch drüber nach, die Cache- und Livestream-Ausgabe
JSON-formatiert zu machen, bin mir aber noch nicht sicher, ob das
Overkill ist. Hast du eine Meinung dazu?
> Als nächstes soll der cached noch Trigger bekommen, so dass z.B. bei> Störung eine Mail geschickt wird und so.> Wobei es natürlich nicht schlimm wäre, wenn der cached dann nur noch> diese Funktionen hat und das cachen im collector passiert ^^.
Ja, Eventbehandlung ist Frontend-Geschichte, das gehört nicht in den
Collector, insofern kannst du dich da austoben :)
> Und der liefert halt eine alphabetisch sortierte Liste aller> data-Port-Ausgaben ergänzt um einen (Unix-)Zeitstempel bei jedem> einzelnen Wert, wann das letzte Update war.
Warum alphabetisch sortiert? Die momentane Sortierung ist 'Position in
der Type-Enum, wenn gleich, dann Position in der SubType-Enum'. Das kann
man natürlich ändern (wenngleich alphabetisch ziemlich hässlich wäre,
Subtype vor Type wäre aber IMHO ok), aber spielt das eine große Rolle?
Ach ja, und das Servicecode-Protokoll bräuchte wahrscheinlich eine
Längen-Limitierung - sowohl mein Wandboard als Server als auch der
Browser haben ordentlich zu tun, das Protokoll jedes Brennerstarts der
(bei mir) letzten 3 Jahre anzuzeigen ;)
Ich habe den collectord zum Testen gerade auf ubuntu 12.4 compiliert.
Dort ist der g++ etwas komisch und braucht die Angabe der lib Dateien
nach den *.o Dateien:
Geht nicht (orginal Makefile):
collectord: $(OBJS) $(DEPFILE) Makefile
$(CC) $(LIBS) -o collectord $(OBJS)
Da gibts massenhaft "Nicht definierter Verweis auf"
Folgendes geht:
collectord: $(OBJS) $(DEPFILE) Makefile
$(CC) -o collectord $(OBJS) $(LIBS)
War etwas schwer zu finden ...
Viele Grüße
Jürgen
jschmied schrieb:> Geht nicht (orginal Makefile):
Bei mir läuft Raspbian GNU/Linux 7.2 (wheezy). Mit dem Original makefile
gibt es hier kein Problem, läuft einwandfrei durch.
Danny Baumann schrieb:> Port 7777 hat jetzt ein 'cache fetch'-Kommando
In emsqry.inc wie folgt geändert:
Z. 49: $service_port_data=7777;
Z. 150: $tmp = "cache fetch\n";
und schon klappts auch mit der Heizung.
Woran es bei mir noch hapert ist das Feld "Beschreibung" des Statuscode.
Mal zeigt es an, mal zeigt es nicht an. Muss ein Blinker eingebaut sein.
;)
Und die Graphiken schreiben noch nicht, muss ich noch mal vertieft
schauen.
Wirklich tolle Arbeit Jungs! Herzlichen Dank dafür!
Gruß aus der Wetterau
Karl M.
@Danny:
Habs schon umgebaut. Nur im cache is mMn noch ein kleiner Bug, so dass
nur der erste Wert eines targets gecached wird. Fixvorschlag im PR.
Funzt ansonsten prächtig. Sortierung is egal, hatt ich halt so damals.
Ist Frontendsache.
Längenlimit kommt mit dem nächtsten Commit.
3 Jahre sind ein wenig viel in einem Schirm :smile:
Michael Moosbauer schrieb:> Habs schon umgebaut. Nur im cache is mMn noch ein kleiner Bug, so dass> nur der erste Wert eines targets gecached wird. Fixvorschlag im PR.
Jup, bescheuerter Bug meinerseits. Wenn ich den []-Operator gehabt hätte
(m_cache[key] = ...) hätte es funktioniert - der braucht aber einen
Default-Konstruktor für den Value.
Danke für den Fix, das ist der richtige :)
Bernd Gewehr schrieb:> Kürze Frage:> Muss der neue Cache mit einem Parameter wie -K 7779 aktiviert werden> oder wie geht das?
Der muss nicht aktiviert werden, sondern ist immer da.
Hallo!
Eine Frage noch:
apt-get install php5-mysql
installiert auch apache2. Ist das wirklich nötig wenn man mit lighttpd
arbeiten möchte?
Viele Grüße
Jürgen
Habe nun soweit alles laufen!! Geil!! :-)
Ich bekomme die Graphen nicht hin, welche Hilfe könnt Ihr mir noch
geben?
Eine Step-by-step-Anleitung würde sehr helfen!
Ich danke Euch für diese starke Leistung!
jschmied schrieb:> apt-get install php5-mysql> installiert auch apache2. Ist das wirklich nötig wenn man mit lighttpd
Zwei Webserver parallel? Kein wirklicher Gewinn. ;)
Du arbeitest mit Ubuntu 12.4?
Die Anleitung unter:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#software1
ist für "Raspbian" = Debian 7.x (wheezy) geschrieben.
Da hat er den Apachen nicht nachgeladen.
Sag mal Jürgen, Du kennst Dich doch gut mit Jquery-mobile aus, wenn ich
mich recht erinnere. Was sagst Du denn zum Thema: Michaels Website auf
Jq-mobile portieren? ;)
Gruß aus der noch immer sonnigen Wetterau
Karl M.
>> apt-get install php5-mysql>> installiert auch apache2. Ist das wirklich nötig wenn man mit lighttpd>> Zwei Webserver parallel? Kein wirklicher Gewinn. ;)> Du arbeitest mit Ubuntu 12.4?
Hab jetzt einen Pi. Gestern hab ich nach der Anleitung im Wiki mit
2014-01-07-wheezy-raspbian getestet und php5-mysql hat den apache2
mitgezogen ...
> Sag mal Jürgen, Du kennst Dich doch gut mit Jquery-mobile aus, wenn ich> mich recht erinnere. Was sagst Du denn zum Thema: Michaels Website auf> Jq-mobile portieren? ;)
Das sind unterschiedliche Architekturen. JQuery rechnet im Browser d.h.
die Daten würden z.B. über JSON geladen werden und im Browser gerendert.
Michaels Webseite rendert alles auf dem Server. Ansonsten geht es
natürlich mit jeder Sprache ...
PS: Bin gerade dabei den collectord mit dem PIC EMS-GW zum Laufen zu
bringen, um Michaels Webseiten zu nutzen. Das EMS-GW ersetzt dann den
netio und sendet einfach das gleiche Protokoll.
vg
Jürgen
Charlie W. schrieb:> Woran es bei mir noch hapert ist das Feld "Beschreibung" des Statuscode.> Mal zeigt es an, mal zeigt es nicht an. Muss ein Blinker eingebaut sein.> ;)
Habe den "Blinker" gefunden. Es sind die Umlaute und Ligaturen im Array
der EMS-Sevicecode-Descriptions (/ems-tools/includes/emsscdesc.inc).
Merke: Ohne ä, ö, ü und ß gehts besser!
Gruß aus der Wetterau
Karl M.
> Merke: Ohne ä, ö, ü und ß gehts besser!
Noch besser währe ein richtiger Zeichensatz ;)
Habs jetzt mit dem EMS-GW teilweise am Laufen. Probleme gibts noch mit
fehlenden Sensor-Namen, ich bekomme überhaupt keine Grafiken und hab
noch ein paar andere Fehler/Warnungen im lighttp-Log.
Wenn ich ems-gen-graphs.py per Hand starte, wird nur das PNG für die
Heizkurve erzeugt.
Die Buttons der ersten Seite z.B. zum Starten der Einmalladung sind noch
ohne Funktion - zumindest bei mir ;)
Wenn ichs in den nächsten Tagen nicht alleine hinbekomme, melde ich mich
noch mal.
vg
Jürgen
Jürgen Schmied schrieb:>> Merke: Ohne ä, ö, ü und ß gehts besser!> Noch besser währe ein richtiger Zeichensatz ;)
Logo! Hab' ich mit 'rumexperimentiert. Allerdings ohne Erfolg.
Dann habe ich kurzerhand die Texte gekürzt und die "nicht utf-8" Zeichen
ersetzt. Wenn's bei Dir läuft, bin ich für einen Hinweis dankbar. ;}
> bekomme überhaupt keine Grafiken
Hatte ich auch, sind meist unrichtige Pfadangaben. Moosy hat seine
eigene Struktur. ;) Bis auf die Schaltpunkte (schedule.png) geht's jetzt
aber.
Mit freundlichen Grüßen aus der Wetterau
Karl M.
Hi Michael,
ich gehöre zu den glücklichen die ein Gateway bekommen haben, gibt es
eine Möglichkeit dein Frontend mit allen Features auch damit zu nutzen
(Ohne den NetIO), Raspi ist natürlich auch vorhanden?!
Gruss
Norbert
Hallo!
Die Probleme mit den Graphen lagen bei mir neben den Pfaden vor allem an
- der mysql socket Angabe in der config.py:
1
/var/run/mysqld/mysqld.sock
für RaspberryPi/debian wheezy
- den Berechtigungen an den Verzeichnissen
1
chmod 777 /tmp/
2
chmod 777 .../graphs/
- den Berechtigungen für die Graphen
1
chown pi *
2
chmod 777 *
auf die graph-Dateien in .../graphs/ (ich hatte sie mit dem user root
kopiert)
- den Berechtigungen für den www-data User
1
chown www-data schedule.png
in .../graphs/ damit der webserver die Datei ändern darf (lighttpd mit
user www-data)
Bei mir geht jetzt alles, bis auf das Zeichensatzproblem!
Gruß Bernd
Hallo zusammen :)
@Norbert:
Mit dem Low-Level-Kram hab ich mich eigentlich gar nicht beschäftigt.
Soweit ich das EMS-GW kenne, bietet das ja seine Daten auch seriell an,
was Dannys collectord ja prinzipiell auch anbietet.
Es sind also "nur" noch unterschiedliche Protokolle. Ich kann schwer
abschätzen, wie groß der Aufwand ist, das EMS-GW an den collectord
anzubinden. Aber wenn das gelingt, sollte es eigentlich keinen
Unterschied machen zum NETIO, da ja das NETIO nur die Daten von/auf den
EMS-Bus gibt und die Checksummen und das BREAK erzeugt. Die ganze
Intelligenz ist ja im collector. Hat nicht Jürgen da schon was zum
Laufen gekriegt?
@Jürgen:
Heißt das, dass die Kommunikation collectord <-> EMS-GW klappt?
Funktionieren die Befehle, die man mit meinem emsclient bzw. per telnet
auf den Commandport des collectord absetzen kann? Wenn ja, dann müsste
eigentlich alles gehen.
@Bernd:
Lust, die Installationsanleitung entsprechend zu erweitern?
Wegen dem Zeichensatzproblem:
Versucht mal in der lemscnt.ajax in Zeile 110:
$desc=htmlentities ($desc, ENT_COMPAT | ENT_HTML401 , 'ISO-8859-1');
Bin ich echt der einzige UTF-8 Verweigerer hier?
@Karl:
Was geht bei den Zeitprogramm-Bildern nicht?
LG Moosy
P.S: Zitat php.net:
> encoding> Like htmlspecialchars(), htmlentities() takes an optional third argument> encoding which defines encoding used in conversion.
[...]
> Although this argument is technically optional, you are highly> encouraged to specify the correct value for your code.
Okay, okay. Encoding sollte also immer rein ;)
> Es sind also "nur" noch unterschiedliche Protokolle. Ich kann schwer> abschätzen, wie groß der Aufwand ist, das EMS-GW an den collectord> anzubinden. Aber wenn das gelingt, sollte es eigentlich keinen> Unterschied machen zum NETIO, da ja das NETIO nur die Daten von/auf den> EMS-Bus gibt und die Checksummen und das BREAK erzeugt. Die ganze> Intelligenz ist ja im collector. Hat nicht Jürgen da schon was zum> Laufen gekriegt?
Ja, es geht bei mir. Allerdings nicht seriell, sondern über Ethernet.
Ein ENC28J60 Modul ist also nötig. Ein paar Probleme habe ich aber noch
mit der Weboberfläche.
>> @Jürgen:> Heißt das, dass die Kommunikation collectord <-> EMS-GW klappt?> Funktionieren die Befehle, die man mit meinem emsclient bzw. per telnet> auf den Commandport des collectord absetzen kann? Wenn ja, dann müsste> eigentlich alles gehen.
Ja, ich sehe im Log des collectord eine zweiseitige Kommunikation. Die
Weboberfläche holt sich ja auch aktiv Daten vom Bus. Das geht schon.
Ich stelle die FW heute Abend auf die Wiki Seite.
vg
Jürgen
Michael Moosbauer schrieb:> Hallo zusammen :)> @Norbert:> Mit dem Low-Level-Kram hab ich mich eigentlich gar nicht beschäftigt.> Soweit ich das EMS-GW kenne, bietet das ja seine Daten auch seriell an,> was Dannys collectord ja prinzipiell auch anbietet.> Es sind also "nur" noch unterschiedliche Protokolle. Ich kann schwer> abschätzen, wie groß der Aufwand ist, das EMS-GW an den collectord> anzubinden. Aber wenn das gelingt, sollte es eigentlich keinen> Unterschied machen zum NETIO, da ja das NETIO nur die Daten von/auf den> EMS-Bus gibt und die Checksummen und das BREAK erzeugt. Die ganze> Intelligenz ist ja im collector. Hat nicht Jürgen da schon was zum> Laufen gekriegt?
Ich würde Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung" mal als
'ja' deuten. AFAIK ist das EMS-GW aus collectord-Sicht mit dieser
Firmware identisch zu einem NET-IO.
> @Bernd:> Lust, die Installationsanleitung entsprechend zu erweitern?> Wegen dem Zeichensatzproblem:> Versucht mal in der lemscnt.ajax in Zeile 110:> $desc=htmlentities ($desc, ENT_COMPAT | ENT_HTML401 , 'ISO-8859-1');> Bin ich echt der einzige UTF-8 Verweigerer hier?
Ja. :-P
IMHO ist, wenn das Zielsystem Linux ist, die Verwendung von UTF-8 immer
eine gute Idee, schon weil es am wenigsten Verwirrung verursacht ;)
Pffff :)
Bei mir hier hat bislang UTF-8 mehr Ärger gemacht als es bringt. Ich
werde beim nächsten Server-OS-Upgrade mal über nen Umstieg nachdenken.
Ich habe übrigens gerade gesehen, dass ich in der ajax.php eine Zeile
vergessen habe (ganz am Anfang):
<?php
header('Content-Type: text/html; charset=iso-8859-1');
[...]
Oder halt UTF-8, wenns jemand umgebaut hat ;).
Hilft das bei Euch?
LG
Moosy
Hallo,
gibt es inzwischen schon eine fertige Platine? Weiter oben habe ich mal
gelesen dass flobo eine anbieten will. Falls nicht wäre ich sehr froh
wenn mir irgendwer (natürlich gegen Bezahlung) eine zusammenlöten würde,
da ich ein Lötdau bin.
Viele Grüße
Gerd
Das Meiste wird jetzt angezeigt, ich habe aber noch ein paar Fehler:
Livestatus:
2014-03-19 14:19:26: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice:
Undefined index: menu in /var/www/index.php on line 21
2014-03-19 14:19:26: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice:
ob_flush(): failed to flush buffer. No buffer to flush in
/emsincludes/emsqry.inc on line 20
2014-03-19 14:20:15: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice:
Undefined index: heaterpump currentmodulation in /var/www/lemscnt.ajax
on line 73
PHP Notice: Undefined index: heatexchanger currenttemperature in
/var/www/lemscnt.ajax on line 92
PHP Notice: Undefined index: outdoor currenttemperature in
/var/www/lemscnt.ajax on line 100
Erweiterte Einstellungen:
2014-03-19 14:23:09: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice:
Undefined offset: 1 in /emsincludes/emsgetinfo.inc on line 146
Fehlerspeicher:
PHP Notice: Undefined offset: 51816 in /var/www/a_emserr.php on line 53
PHP Notice: Undefined offset: 51858 in /var/www/a_emserr.php on line 53
PHP Notice: Undefined offset: 51816 in /var/www/a_emserr.php on line 53
PHP Notice: Undefined offset: 12816 in /var/www/a_emserr.php on line 53
PHP Notice: Undefined offset: 12816 in /var/www/a_emserr.php on line 53
PHP Notice: Undefined offset: 12794 in /var/www/a_emserr.php on line 53
PHP Notice: Undefined offset: 12816 in /var/www/a_emserr.php on line 53
Statistik:
2014-03-19 14:23:51: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice:
Undefined index: menu in /var/www/index.php on line 21
PHP Notice: Undefined index: heater operatingminutes in
/var/www/a_emstime.php on line 22
PHP Notice: Undefined index: heater heatingminutes in
/var/www/a_emstime.php on line 22
PHP Notice: Undefined index: heater heaterstarts in
/var/www/a_emstime.php on line 28
PHP Warning: Division by zero in /var/www/a_emstime.php on line 58
Letzte Stunde:
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 85
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 11
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 12
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 20
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 21
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 87
PHP Notice: Trying to get property of non-object in
/var/www/sensor_utils.php.inc on line 11
...
PHP Warning: strftime() expects parameter 2 to be long, string given in
/var/www/utils.php.inc on line 11
vg
Jürgen
Noch eine Frage: muss ich calcemsgraphs.sh in den cron hängen? Ich kann
bisher die graphs nur manuell erzeugen.
Ansonsten:
Ich vermisse noch ein Diagramm für den HK1. Ist das geplant oder soll
ich mir das selbst bauen ? ;)
Im Diagramm für die Pumpen ist die Kesselpumpe immer an. Ist das bei
Euch auch so?
Viele Grüße
Jürgen
Jürgen Schmied schrieb:> Undefined index: menu in /var/www/index.php on line 21
$menu = (@$_GET["menu"]!="no");
> ob_flush(): failed to flush buffer. No buffer to flush in> /emsincludes/emsqry.inc on line 20
// ob_flush(); ;)
Ja, ich weiß, ist nicht die Feine, aber funzt.
Zu den übrigen Fehlern kann ich leider nichts sagen, sind bei mir nicht
aufgetreten. Aber Moosy wird's schon richten. ;)
So, nachdem ich alle ;) Eure Tips beherzigt habe, läuft's bei mir
jetzt rund. Super Arbeit, super Sache, alles perfekt!
Nochmals vielen Dank für Eure Mühen und Eure Arbeit. Ganz besonderen
Dank aber an die zwei Macher, an Danny und Michael!
Gruß aus der Wetterau
Karl M.
Jürgen Schmied schrieb:> Noch eine Frage: muss ich calcemsgraphs.sh in den cron hängen?
Also, da bin ich mir auch noch nicht klar, was da sinnvoll ist.
Wenn die Statistik "Letzte Stunde" einigermaßen aktuell sein soll, dann
muss ich spätestens alle fünf Minuten die calcemsgraphs.sh laufen
lassen. Damit schaffe ich unnötige Last und unnötigen Schreibzugriff auf
meine SD. Und was die Statistiken ab einem Tag oder länger betrifft, ist
das völliger Unsinn.
Ich denke, ich hänge die Erzeugung der jeweils gewünschten /
erforderlichen Graphen an die jeweilige einzelne Webseite.
Frage: "Wie habt Ihr das denn für Euch gelöst?"
TIA und
Gruß aus der Wetterau
Karl M.
Ich lass die calcemsgraphs alle 5 Minuten laufen.
Ist aber auch ein "richtiger" Server, der eh die ganze Zeit wild auf den
Platten rumrödelt ;)
LG
Moosy
Hiho,
ich würde mich als "Hardwarelieferant" gerne zur Verfügung stellen.
Das EMS Gateway vom Ingo habe ich soweit schonmal herstellen lassen und
habe 4 Stück auf Lager.
Ich spreche gerade mit dem Bestücker was die Herstellung einer solchen
Platine genau kosten würde etc.
Die Absolute Königslösung wäre dann meiner Meinung nach EMS GW =>
Raspberry.
Könnt ihr das soweit bestätigen ? Nicht das ich mich jetzt auf diese
Lösung konzentriere und dann doch was anderes besser sein wird als diese
Kombo.
> Die Absolute Königslösung wäre dann meiner Meinung nach EMS GW =>> Raspberry.
Ideal wäre es, auf der Platine des EMS-GW den CAN Teil zu entfernen und
dafür ein Ethernet-Interface zu platzieren. Dann ist das an einem
Flachbandkabel hängende Netzwerkmodul überflüssig.
Viele Grüße
Jürgen
Kurze Nachfrage: Funktioniert das auch mit dem HT3 Bus? Hat jemand eine
Idee/Liste zu den dekodierungen zu dem Bus. Die sind verdammt ähnlich
finde ich. Kann mir jemand weiterhelfen? Danke!
Hallo,
weiß irgendwer ob man die Daten auch über die 1-wire Schnittstelle bei
Niffkos Platine abfragen kann?
Ich habe nämlich schon ein 1-wire Netzwerk und da wäre das ideal.
Gerd
> Kurze Nachfrage: Funktioniert das auch mit dem HT3 Bus? Hat jemand eine> Idee/Liste zu den dekodierungen zu dem Bus. Die sind verdammt ähnlich> finde ich. Kann mir jemand weiterhelfen? Danke!
Die Hardware sollte wohl laufen. Allerdings haben die Busteilnehmer
andere Adressen und die Telegramme sind wohl anders codiert. Man könnte
also den Code als Basis benutzen und die HT3 Telegramme einbauen.
vg
Jürgen
Für den Nachbau EMS > Adapter > NetIO > Raspi wird hier auf dem
Avr-Net-IO Board ein ATmega644P-20PU wegen der 2 seriellen
Schnittstellen verlangt.
Meine Versuche in den verschiedenen Vergleichslisten zu erkennen ob auch
eine bei mir vorhandene 1284P PU CPU funktionier sind gescheitert.
Deshalb die Frage: hat ATMEGA1284P PU eine 2te serielle Schnittstell
und kann diese CPU ohne weitere Probleme gegen die verlangte
ATmega644P-20PU getauscht werden.
Güße,
Thomas
Thomas Mollowitz schrieb:> Meine Versuche in den verschiedenen Vergleichslisten zu erkennen ob auch> eine bei mir vorhandene 1284P PU CPU funktionier sind gescheitert.> Deshalb die Frage: hat ATMEGA1284P PU eine 2te serielle Schnittstell> und kann diese CPU ohne weitere Probleme gegen die verlangte> ATmega644P-20PU getauscht werden.
Ich würde die Tabelle in
http://avrprogrammers.com/articles/AVR/atmega16-atmega32-atmega644 mal
als 'ja' deuten. Der 1284P hat jedenfalls eine zweite USART; ich habe
jetzt nicht überprüft, ob er pinkompatibel ist, die Vermutung liegt aber
sehr nahe.
Hallo,
sorry für meine schreckliche Deutsch ...
Ich entwarf und erbaut Platinnen von Igor F. Diagramm
(http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io).
Die erste Version der Platte sah aus wie die Zeichnungen und Bilder ...
Obwohl die Montage und führen Sie das ganze System funktioniert
einwandfrei (exakt: sensationell :)), habe ich beschlossen, den Entwurf
in der Weise, dass die größten Teile der Platinnen wurden Masse (GND)
abgedeckt ändern.
Der endgültige Entwurf der Platinen in Eagle kann auch heruntergeladen
werden.
Mit freundlichen Grüßen,
Maciej
PS. I can translate the above mentioned page into English if anyone
would be interested...
Hallo Maciej,
Dein Deutsch ist super, wir haben alles verstanden.
Wünschte, ich könnte halb so gut polnisch schreiben oder lesen.
> Der endgültige Entwurf der Platinen in Eagle kann auch heruntergeladen> werden.
und wo?
Die Bilddatei ist reichlich groß (6MB), hätte man "etwas" reduzieren
können. ;-)
Ansonsten: Gute Arbeit, perfekt!
Gruß aus der Wetterau
Karl M.
Hallo flobo,
ist noch eine Platine zu haben und wie ist der Preis? Mir wäre
allerdings die Platine von Niffko lieber, da diese eine 1-Wire
Schnittstelle hat und das Netzwerkmodul mit dem NetIO auch schon
integriert ist.
Viele Grüße
jschmied schrieb:> Ich habe den collectord zum Testen gerade auf ubuntu 12.4> compiliert.> Dort ist der g++ etwas komisch und braucht die Angabe der lib Dateien> nach den *.o Dateien:>> Geht nicht (orginal Makefile):> collectord: $(OBJS) $(DEPFILE) Makefile> $(CC) $(LIBS) -o collectord $(OBJS)>> Da gibts massenhaft "Nicht definierter Verweis auf">> Folgendes geht:> collectord: $(OBJS) $(DEPFILE) Makefile> $(CC) -o collectord $(OBJS) $(LIBS)>> War etwas schwer zu finden ...>> Viele Grüße>> Jürgen
Kann man das mal im Trunk ändern? Ist ja hammer hart das zu finden :-)
mfg
Lars Rosenberg
LarsRosen schrieb:> jschmied schrieb:>> Geht nicht (orginal Makefile):>> collectord: $(OBJS) $(DEPFILE) Makefile>> $(CC) $(LIBS) -o collectord $(OBJS)>>>> Folgendes geht:>> collectord: $(OBJS) $(DEPFILE) Makefile>> $(CC) -o collectord $(OBJS) $(LIBS)>> Kann man das mal im Trunk ändern? Ist ja hammer hart das zu finden :-)
Done :)
Gibt es eigentlich ein richtige Anleitung zu den ganzen?
Ich versuche als von moosy das Frontend einzurichten aber irgendwie
bekomme ich als die meldung
Exception: Access denied for user 'ems'@'localhost' (using password:
YES)
und die Tabellen hat er auch nicht eingerichtet?
ich gehe im moment nach dieser anleitung vor:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io
LarsRosen schrieb:> Weiss jemand zufällig ob das nur mit der RC35 funktioniert oder auch mit> der RC300?
Wenn RC300 ein Typo ist und du RC30 meintest: Ja, es funktioniert. (Ich
habe auch eine RC30).
larsrosen schrieb:> Nein ich meine die neue Steuerung rc300 mit ems - plus
Von der Beschreibung bei Buderus würde ich zu 'ja' tendieren (da der
zugrundeliegende Bus ja immer noch EMS ist). Probiert hat es meines
Wissens nach aber noch niemand, insofern sind definitive Aussagen etwas
schwierig...
Danny Baumann schrieb:> Probiert hat es meines Wissens nach aber noch niemand ...
Aber na klar doch ... ;)
RC300 wird funktionieren ... wenn auch nicht out-of-the-box.
Es gibt gleiche Telegramme:
Niffko _ schrieb:> Danny Baumann schrieb:>> Probiert hat es meines Wissens nach aber noch niemand ...>> Aber na klar doch ... ;)
Sehr gut :)
> RC300 wird funktionieren ... wenn auch nicht out-of-the-box.>> Es gibt gleiche Telegramme:>
1
10083500010100
Das hätte ich jetzt bei der Kommunikation mit dem UBA auch erwartet.
> Den gleichen Telegrammtyp mit anderer Länge:>
1
100006000E0400100A37020110FF00A5
Hatten wir ja auch schon zwischen RC30 und RC35. Der Datensatz sieht
aber auf den ersten Blick rückwärtskompatibel aus.
> Und komplett neue Telegramme:>
Das hatten wir bei der RC35 auch schon (z.B. für die
Kontaktinformationen).
Es wird wohl darauf hinauslaufen, dass bei der RC300 jemand den gleichen
Reversing-Job, den moosy bei der RC35 gemacht hat, machen muss...
Grundlegende Umstellungen werden wahrscheinlich nicht nötig sein.
larsrosen schrieb:> Was meinst du mit out of the box?
Danny hat es schon ziemlich treffen formuliert:
Danny Baumann schrieb:> Es wird wohl darauf hinauslaufen, dass bei der RC300 jemand den gleichen> Reversing-Job, den moosy bei der RC35 gemacht hat, machen muss...> Grundlegende Umstellungen werden wahrscheinlich nicht nötig sein.
Vielleicht könntest Du ja dieser "Jemand" sein ;)
//Niffko
larsrosen schrieb:> Was meinst du mit out of the box?
Naja, Basisfeatures (z.B. Sensorwerte des UBA) werden wahrscheinlich
einfach funktionieren, aber bei allem, was die RC300 selbst betrifft
(z.B. Schaltprogramme oder neue Features, die das Teil u.U.
bereitstellt) kann es sein, dass noch zusätzlicher Code in den Collector
rein muss, damit die RC300 auf den gleichen Stand wie RC30/35 kommt. Bei
den neuen Modulen gilt das gleiche.
> Ich bin gerne bereit zu helfen die befehle raus zi bekommen?
Na dann mal los ;) Den grundlegenden Ablauf hat moosy hier schon gut
beschrieben: Beitrag "Re: EMS > Adapter > NetIO > Raspi" - ein
paar Details haben sich inzwischen aber geändert:
- Der ems-collector muss mit Raw-Kommando-Support gebaut werden (Zeile 3
des Makefiles auskommentieren, d.h. Raute entfernen)
- Das emsqry-Kommando heißt inzwischen 'raw read <device> <type>
<offset> <len>' (in moosy's Beispiel 2a ist 0 der Offset und 25 die
Länge)
- Das emscmd-Kommando heißt inzwischen 'raw write <device> <type>
<offset> <data0> ... <dataX>'
Für moosy's Punkt 5 melde ich mich freiwillig, wenn Punkt 4 erledigt ist
;) (d.h. das Telegrammformat aufgedröselt ist).
Perfekt das mache ich gerne.
Ich habe mein smd layout jetzt fertig und werde es am we löten.
Wenn ich soweit bin das es halbwegs läuft melde ich mich mit den
Ergebnissen.
Jürgen Schmied schrieb:> "ERROR: Connection blocked??">> was das allerdings bedeutet - keine Ahnung ...
Das bedeutet, dass schon jemand anderes auf dem NetIO-EMS-Port hängt -
der EMS-Code in ethersex akzeptiert nur eine Verbindung. (siehe hier:
https://github.com/maniac103/ethersex/blob/master/protocols/ems/ems_net.c#L52)
Sven, schau mal, ob du mehrere Collector-Instanzen laufen hast, oder was
sonst die Verbindung belegt.
Hallo Jürgen,
danke für den Tip,
bei meinen versuchen scheint sich ein Client nicht richtig getrennt zu
haben.
Nachdem ich alles geresettet habe, bleibt das Logfile LEER,
keine Einträge ?????
Ich hbae jetzt mal in die Tabellen geschaut, leider sind die Tabellen
numeric_data, state_data und boolean_data leer.
Da ich die EMS Adapter selbst gebruzzelt habe, würde ich erstmal gerne
wissen, ob der funktioniert(beim löten/fädeln kann immer mal ein fehler
auftreten), aber ein einfachen Funktionstest habe ich nicht gefunden.
Ich kann mal das Oszi in den Keller schleppen und die Signale mal
nachmessen,
hauptsächlich PIN 1 am LM393 (ich habe die Schaltung
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io 1:1
nachgebaut, mit 1..2 kleinen Änderungen C4 ist 1.2nf anstatt 1nf und
anstatt LM393n habe ich ein lm393)
Ich werde aber erst heute Nachmittag weiter machen können.
mfg.
Sven
Hmmm
irgendwie komme ich nicht weiter.
Ich habe jetzt alles soweit fertig, mit telnet komme ich auf das GW.
Wenn ich jetzt versuche mit emsclient was zu machen schmeißt der mir das
ganze script an den kopf?
ich habe es auchmal versucht über den browser aufzurufen, aber auch dort
bekomme ich nur den Roh text angezeigt?
Vielleicht kann mir ja jemand helfen?
EDIT
folgende struktur
/emsincludes/files owner root
/var/www/ems/graph owner www-data (leer)
/var/www/ems/scripte owner www-data
/home/lars/ems/ems-tools/cli owner lars (auch mit sudo kein erfolg)
Hallo,
in meinem ersten Post geht es mir darum, ein klareres Bild über den
Gesamtzusammenhang zu gewinnen.
Ich kann trotz intensiver Lektüre leider die Funktionen der
Einzelkomponenten (noch) nicht klar zuordnen.
Der Adapter ist nur eine Hardwareanpassung (Pegel, Schnittstelle) um die
EMS-Bus-Signale in verwertbare Signale umzuwandeln.
Jetzt beginnt jedoch meine Konfusion. Das NET-IO ist das nächste
Bindeglied. Wie genau werden hier die Daten umgesetzt? Was wird wie über
den (Netz-) Anschluss (ja, ich weiß, über Port...) übertragen bzw. lässt
sich abrufen?
Mal kurz zu meinen Beweggründen:
Ich betreibe eine Hausautomation via Windows PC mit dem man problemlos
auch serielle Daten wie z. B. Datentelegramme auswerten kann. (Meinen
Automower steuere ich seit einigen Jahren damit.)
Meine Intention ist es vor allem den Kessel über diese Schnittstelle zu
steuern. Wie bekomme ich Datentelegramme aus und fertige Telegramme
wieder in den EMS-Bus? Wie genau sieht das Protokoll des NET-IO nach
außen aus?
Wenn ich das richtig verstanden habe, wird doch der Raspi nur zur
"Weiterverarbeitung" z. B. Visualisierung, Datenmining usw. verwendet.
Das würde ich über den PC machen...
Hier wäre es (nicht nur für mich) schön, wenn jemand noch einmal einen
kleinen Abriss über den Datentransfer zwischen Modulen und die Zuordnung
der Funktionen der einzelnen (logischen) Bestandteile verfassen würde.
Grüße
Fabian
> Jetzt beginnt jedoch meine Konfusion. Das NET-IO ist das nächste> Bindeglied. Wie genau werden hier die Daten umgesetzt? Was wird wie über> den (Netz-) Anschluss (ja, ich weiß, über Port...) übertragen bzw. lässt> sich abrufen?
Der EMS Bus ist ein BUS d.h. es gibt mehrere Teilnehmer, die nur senden
dürfen, wenn sie gefragt werden und ein Protokoll einhalten müssen. Das
macht der NET-IO.
> Wie bekomme ich Datentelegramme aus und fertige Telegramme> wieder in den EMS-Bus? Wie genau sieht das Protokoll des NET-IO nach> außen aus?
Steht alles im WIKI. Das Protokoll des NET-IO hier:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio> Wenn ich das richtig verstanden habe, wird doch der Raspi nur zur> "Weiterverarbeitung" z. B. Visualisierung, Datenmining usw. verwendet.> Das würde ich über den PC machen...
Im Prinzip ja. Das Parsen von Telegrammen und die Ausgabe in lesbarer
Form hab ich auch in Java da - wenns hilft ;-). Ansonsten schau die die
Sourcen von Collectord an (c++).
vg
Jürgen
Hallo Jürgen,
vielen Dank für die Aufklärung. Den verlinkten Abschnitt habe ich
gelesen. Es war hier aber explizit vom EMS-GW die Rede, welches den
NET-IO ersetzen soll.
Jetzt verstehe ich erst, das durch die Änderungen die Funktion des
eigenständigen EMS-GW hier dem NET-IO "nachempfunden" wurde.
Langsam wird die Angelegenheit klarer :)
Da ich bereits ein NET-IO Board habe, brauche ich nur noch das
Interface.
BTW: hat jemand eventuell noch eine passende Platine zu verkaufen? Am
besten die von Niffko. Denn wenn man schon mal einen neuen Kessel
aufstellt, gehören auch gleich eine Hand voll 1-W Sensoren dran :)
Grüße
Fabian
Hi,
Fabian Keppler schrieb:> Da ich bereits ein NET-IO Board habe, brauche ich nur noch das> Interface.
Naja, der collectord samt db läuft auf dem Raspi oder sonst einem linux
server.
> hat jemand eventuell noch eine passende Platine zu verkaufen?
Leider nein, ist aber doch kein Hexenwerk, die <drei> Teile zu verlöten.
Schau Dir doch die Breadboardvorlage noch mal an ;).
> Denn wenn man schon mal einen neuen Kessel> aufstellt, gehören auch gleich eine Hand voll 1-W Sensoren dran :)
Jepp :). Obgleich das NetIO 1-Wire versteht, habe ich meinen 1-Wire-Bus
per DS2482-100 an den Raspi angebunden (vgl. Anlage). Am stromversorgten
Bus hängen 10 Stück DS1820 (Temperatursensoren) und 2 Stück DS2423
(Zähler für Gas, Wasser und Strom). Läuft seit über zwei Jahren ohne
Probs.
Gruß aus der Wetterau
Karl M.
Hi,
bin seit kurzem auf den Thread gestoßen. Genau das was ich gesucht habe!
Nachdem ich bereits einen AVR-NET-IO neben der Heizung habe (12 x 1-wire
+ 4 x PT1000 + Steuerung der Zirkulationspumpe über Relais) könnte ich
hier die Anbindung an EMS gleich mit erledigen. Die benötigten Pins an
der EXT-Buchse sind auch noch frei :-)
Den Adpater (Hardwareanpassung) löte ich gerade auf Lochraster.
Kennt jemand von Euch das Solarmodul von Buderus (heisst SM10 glaub ich
?)
Hängt bei mir ca. 1 m vom Kessel entfernt an der Wand.
An dem SM10 sind 2 Anschlüsse mit der Bezeichnung "EMS" vorhanden.
Der eine Anschluss ist belegt (vermutlich die Verbindung zum Kessel,
bzw. RC30) der andere Anschluß ist frei. Kann ich hier den Adapter
anschließen? Bekomme ich hier alle Daten, also nicht nur die Daten von
dem SM10 sondern auch von der Heizung?
Ich kenn EMS nicht, aber die Bezeichnung "Bus" lässt mich darauf hoffen,
dass alle (physikalischen) Anschlüsse gleich berechtigt sind?!
Und wenn gerade ein "SM10-Spezialist" ;-) das beantwortet:
Kann ich das SM10-Modul ohne Kessel (also ohne RC30, ...) betreiben?
Die Idee: Im Sommer sollte die Solaranlage reichen um das Wasser
zu erwärmen. Da muss die komplette Heizung nicht ständig im standby
laufen
(und Strom verbrauchen). Nur was macht das SM10, wenn es nicht mehr über
EMS kommunizieren kann?
Grüße
Johnny
Ich hätte zum Anschluß auch mal eine Frage. Ich habe an der Heizung mal
die Klappe aufgeschraubt, an der z.B. der externe Temperaturfühler
angeschlossen wird. Kann hier auch der EMS Bus abgegriffen werden ? Ich
hänge mal ein Foto der Klemmen an..
Johnny schrieb:> An dem SM10 sind 2 Anschlüsse mit der Bezeichnung "EMS" vorhanden.
Sind elektrisch durchgeschliffen, kannst die 2. Klemme verwenden.
Johnny schrieb:> Kann ich das SM10-Modul ohne Kessel (also ohne RC30, ...) betreiben?
Manchmal dauert es länger die Frage einzutippen, als einfach mal den
Busstecker abzuziehen und zu schauen was passiert ;)
Ich hatte mal ein SM10 mit defektem Bus-Interface am Wickel ... hat
nicht mehr funktioniert.
//Niffko
Niffko schrieb:> Johnny schrieb:>> An dem SM10 sind 2 Anschlüsse mit der Bezeichnung "EMS" vorhanden.>> Sind elektrisch durchgeschliffen, kannst die 2. Klemme verwenden.
Danke, hab ich gerade gemacht und es sieht gar nicht mal so schlecht
aus.
Die grüne LED (meine natürlich die RK_OK LED) blinkt immer wieder mal
auf.
Über telnet am AVR-NET-IO bekomme ich auch Statistiken vom EMS-Bus:
ems stats
Bytes total:156747
Bytes good:26348
Bytes dropped:0
Packets good:1347
Packets bad:0
Packets 1byte:129053 8657
Packets ack:0 nack:0
Overflow:0
Max fill:3
Ich gehe mal davon aus, das der Selbstbau-Adapter + AVR-NET-IO
funktionieren.
Kann man eigentlich das noch irgendwie testen?
Es gibt ja nur den Befehl "ems stats" im AVR-NET-IO??
Ein Telnet auf den Port 7950 zeigt mir nur kryptische Zeichen?
Jetzt brauche ich wohl mindestens noch den ems-collector?!
Na dann werf ich mal den Compiler auf meinem Server an ...
>> Johnny schrieb:>> Kann ich das SM10-Modul ohne Kessel (also ohne RC30, ...) betreiben?>> Manchmal dauert es länger die Frage einzutippen, als einfach mal den> Busstecker abzuziehen und zu schauen was passiert ;)> Ich hatte mal ein SM10 mit defektem Bus-Interface am Wickel ... hat> nicht mehr funktioniert.
So einfach ist das auch nicht bis ich an den EMS-Bus vom SM10 komme:
Keller gehen, Deckel abschrauben, Modul aufschrauben, Stecker ziehen,
... ;-)
Ok, ich habs probiert, hilft mir aber jetzt am Abend nicht viel weiter.
Das SM10 hat nur eine grüne Lampe, die Betriebsbereitschaft signalisiert
(warscheinlich zeigt die nur an "Strom da ?!)
Wenn ich den EMS-Stecker ziehe leuchtet die grüne Lampe immer noch ??
Was sagt mir das jetzt ?
Hm, ob die Pumpe ohne EMS angesteuert wird kann ich wohl nur bei
Sonnenschein probieren - hoffentlich gibts am Wochenende Sonne, dann
probier ich das noch mal...
>> //Niffko
Johnny
@Niffko: Vielen Dank für die Erläuterung der Klemmen. Ich habe an der
Heizung noch ein Bedienteil RC35 angeschlossen. Kann ich den Bus
trotzdem an den Klemmen RC abgreifen und das Bedienteil parallel
betrieben oder sind die Klemmen RC nur für die Fernmontage des
Bedienteils und ich muß den EMS Bus woanders abgreifen ?
Lg,
Thomas
Thomas I. schrieb:> @Niffko: Vielen Dank für die Erläuterung der Klemmen. Ich habe an> der> Heizung noch ein Bedienteil RC35 angeschlossen. Kann ich den Bus> trotzdem an den Klemmen RC abgreifen und das Bedienteil parallel> betrieben oder sind die Klemmen RC nur für die Fernmontage des> Bedienteils und ich muß den EMS Bus woanders abgreifen ?>> Lg,>> Thomas
Ist kein Problem. Einfach anklemmen. Ist alles der selbe Bus an dem die
Teilnehmer hängen. Man könnte den Bus auch an den Service-Klinkenbuchse
einstecken.
Gruß
IngoF
Also irgendwie komme ich nicht weiter.
Ich habe meine Platine selbst gelötet, und auch mittlerweile das Image
ausm HOWTO fürn Atmega 644 verwendet.
Ich sehe zwar immer wieder die RX Lummi aufleuchten, aber sobald ich
z.b. ein ww request data mache dauert es ein paar sek, dann kommt Error
Timeout.
und wenn ich ne weile gar nix mache steigt der ganze collector aus mit
connection refused?
Kann mir vielleicht noch jemand ein Tip geben wie ich den Aufbau testen
könnte?
An den Bauteilen kan man ja eigentlich nicht viel falsch machen.
evtl muss ich mal mein Oszi dran hängen und gucken was passiert....
Nur mal so ne Frage am rande:
Muss der Bus Stromlos sein beim hinzufügen des adapters oder kann ich
die Heizung an lassen.
Bis jetzt mach ich es immer Stromlos aber immer die Heizung an und aus
hab ich n schlechtes gewissen
Hallo,
ich wollte mich nach langem Lesen des Threads mal daran machen und meine
Platine zusammenlöten. Hat jemand vielleicht eine Bauteilliste ?
Mir fehlt die die Bezeichnung der Diode im Schaltplan
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io
unten links, parallel zu den 3 LEDs ?
Ich versuche gerade den Blackboard Designer unter Ubuntu zu
installieren, um die Vorlage für den diskreten Aufbau auf
Lochrasterplatine. Bislang sträubt sich Ubuntu 14.04 noch etwas. Hat
jemand vielleicht den Schaltplan als PDF ?
Thomas I. schrieb:> Hat jemand vielleicht den Schaltplan als PDF ?> Mir fehlt die die Bezeichnung der Diode im Schaltplan
Siehe Anhang.
Gutes Gelingen!
Gruß aus der derzeit regennassen Wetterau
Karl M.
Vielen Dank !
Ich hänge mal die Bilder und die Teileliste für den Aubau auf einer
Lochrasterplatine hier an. Vielleicht kann es ja mal jemand gebrauchen
und muss dann nicht extra den Blackboard Designer installieren, evtl.
auch fürs Wiki
T. Ihmann
Vielleicht noch ein Nachtrag zur Stückliste der Schaltung:
Immer schön an die Stückliste halten ;-)
Ich hab den Adapter aus dem Wiki nachgebaut
(http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io)
Das Teil hat drei Wochen funktioniert, danach hatte ich einen
"EMS-Busfehler" im RC30-Display und der Adapter war defekt.
Nach dem Abziehen des Selbstbau-Adapters funktionierte auch die Heizung
wieder.
Bei der Fehlersuche bin ich dann auf eine "kleine Änderung" im
Schaltplan gestoßen: D4 (die Diode nach den 4 Gleichrichterdioden, die
negative Spannungen gegen Masse ableitet), war bei mir keine BAT42
sondern eine BAT41 (hatte ich gerade in der Bastelkiste). Und diese D4
ist optisch und meßtechnisch defekt!
Wenn man die verschiedenen aber ähnliche Schaltpläne betrachtet werden
da unterschiedliche Dioden verwendet; BAT42, BAT46, BAT54. Ein Vergleich
der Datenblätter zeigt dann, dass der maximale Strom bei allen Typen
größer 150 mA ist.
(BAT42: 200mA; BAT46: 150 mA; BAT54: 200 mA).
Leider kann meine verwendete BAT41 nur 100mA :-(
Die Vermutung liegt also nahe, dass über den EMS-Bus da mehr als 100 mA
durch die Diode fließen.
Ich hab im Internet nach den technischen Daten des EMS-Buses gesucht
aber nichts gefunden. Nach dem 220 Ohm / 1 Watt - Widerstand im
Sendeteil zu urteilen hätte ich gedacht dass hier maximal
I = SQR(P / R) = SQR(1 W / 220 Ohm) = 68 mA fließen ?!
OK, wenn x Teilnehmer am Bus gleichzeitig versuchen zu senden bekomme
ich
dann x * 68 mA ??!!
Reicht dann eine BAT46? Oder sollte man doch lieber gleich zu einer
SB160 (1N5819) greifen?
Oder war das eine "unplanmäßige Überlast"? (Spannungs- bzw. Stromspitze)
Hatte von denen, die das Teil schon seit längerer Zeit betreiben, schon
mal solche Probleme, bzw. welche Dioden habt ihr eingesetzt?
bye
Johnny
Hi Johnny,
der Schaltplan im Wiki ist (m)eine Anpassung von Niffkos "Abkupferung"
eines MM10-Moduls an einen leicht aufzubauenden through hole Entwurf.
Die Belastbarkeit der thru hole Bauteile wurde auf die in Niffkos Plan
genannten smd Bauteile abgestimmt.
Sonderliche Gedanken habe ich mir dabei nicht gemacht! Ob jetzt z.B. die
4 parallelen smd Widerstände tatsächlich je 1/4 Watt Belastbarkeit
haben, konnte ich aus Niffkos Schaltplan ja nicht entnehmen. Also bin
ich bei der Empfehlung zum 1 Watt Widerstand von Standardwerten
ausgegangen. Darauf (D)eine Stromberechnung aufzubauen ist m.E. ebenso
charmant wie gewagt. ;) Aber theoretisch stimme ich Dir zu. Nur, mehr
als die "theoretischen" 68 mA gehen nicht, selbst wenn im Bus Tango
getanzt wird. ;-) Insoweit hätte die 100 mA Schottky "halten" müssen.
Kurzum: Habe hier eine (Bastelkeller) BAT42 (200mA) verbaut, wie auch in
der Graetzschaltung. Das läuft seit ca. 9 Monaten problemlos.
Mehr vermag ich dazu auch nicht zu sagen, sorry! Aber hier gibt es kluge
Menschen, da kommt bestimmt noch was.
Gruß aus der jetzt wieder vorsommerlichen Wetterau
Karl M.
Hi Karl,
meine Berechnug war mehr als gewagt :-)
Ohne nähere Informationen über den EMS-Bus lässt sich über die
maximale Stromstärke wenig sagen. Ich habe jetzt aus meiner Bastelkiste
eine SB160 eingesetzt - damit sollte ich auf jeden Fall auf der
sicheren Seite sein (max. 1 A).
Dennoch dazu ein paar Überlegungen:
Die 68 mA sind ja der Maximalstrom durch den 1W- Widerstand bei 220 Ohm.
Allerdings wenn mehrere Busteilnehmer gleichzeitig den 220 Ohm mit dem
Transistor gegen Masse schalten, addieren sich die Ströme - immer
vorausgesetzt alle Busteilnehmer verwenden die gleiche Schaltung.
Was mir allerdings komplett fehlt ist die Speisung des Busses.
Irgendwoher muss der Strom ja kommen :-)
Also ohne genaue Spezifikation ist das wie bereits erwähnt, mehr als
gewagt.
Und nochwas: Wenn da mehr als 100mA durch die Diode vom Bus kam, musste
das dann auch durch die Gleichrichterschaltung - und die besteht bei mir
auch aus Dioden vom Typ BAT41 :-|
Aber die haben überlebt! Also vermutlich doch "Materialfehler" :-)
Grüße aus dem sonnigen Franken.
Johnny
Charlie W. schrieb:> Hi Johnny,>> der Schaltplan im Wiki ist (m)eine Anpassung von Niffkos "Abkupferung"> eines MM10-Moduls an einen leicht aufzubauenden through hole Entwurf.> Die Belastbarkeit der thru hole Bauteile wurde auf die in Niffkos Plan> genannten smd Bauteile abgestimmt.> Sonderliche Gedanken habe ich mir dabei nicht gemacht! Ob jetzt z.B. die> 4 parallelen smd Widerstände tatsächlich je 1/4 Watt Belastbarkeit> haben, konnte ich aus Niffkos Schaltplan ja nicht entnehmen. Also bin> ich bei der Empfehlung zum 1 Watt Widerstand von Standardwerten> ausgegangen. Darauf (D)eine Stromberechnung aufzubauen ist m.E. ebenso> charmant wie gewagt. ;) Aber theoretisch stimme ich Dir zu. Nur, mehr> als die "theoretischen" 68 mA gehen nicht, selbst wenn im Bus Tango> getanzt wird. ;-) Insoweit hätte die 100 mA Schottky "halten" müssen.>> Kurzum: Habe hier eine (Bastelkeller) BAT42 (200mA) verbaut, wie auch in> der Graetzschaltung. Das läuft seit ca. 9 Monaten problemlos.>> Mehr vermag ich dazu auch nicht zu sagen, sorry! Aber hier gibt es kluge> Menschen, da kommt bestimmt noch was.>> Gruß aus der jetzt wieder vorsommerlichen Wetterau> Karl M.
Johnny schrieb:> Die Vermutung liegt also nahe, dass über den EMS-Bus da mehr als 100 mA> durch die Diode fließen.
Meiner Meinung nach ist dem nicht so.
Die Diode D4 wird in Sperrrichtung betrieben. Also im Normalfall fließt
dort kein Strom. Ein Verpolen ist auch nicht möglich weil die Diode D4
durch den Gleichrichter D1-D3 und D5 geschützt ist. Es fließt also nur
ein Strom wenn Zum Beispiel eine "Überspannung" oder ähnliches auf dem
Bus liegt.
Johnny schrieb:> Die 68 mA sind ja der Maximalstrom durch den 1W- Widerstand bei 220 Ohm.> Allerdings wenn mehrere Busteilnehmer gleichzeitig den 220 Ohm mit dem> Transistor gegen Masse schalten, addieren sich die Ströme - immer> vorausgesetzt alle Busteilnehmer verwenden die gleiche Schaltung
Der "Original"-Widerstand sind 227,5 Ohm (910/4) damit dürften bei 12
Volt nur 53mA fließen. Aber nur wärend ein Busteilnehmer den Pegel
sendet. Da nur ein Busteilehmer senden kann (Polling) wird auch nie mehr
Strom gezogen.
Johnny schrieb:> Was mir allerdings komplett fehlt ist die Speisung des Busses.
Der Bus wird über die Heizung mit Strom versort (MC10?). Ohne die
Heizung wird also auf dem Bus nichts laufen
Gruß
IngoF
>>>> Johnny schrieb:>>> Kann ich das SM10-Modul ohne Kessel (also ohne RC30, ...) betreiben?>>>> Manchmal dauert es länger die Frage einzutippen, als einfach mal den>> Busstecker abzuziehen und zu schauen was passiert ;)>> Ich hatte mal ein SM10 mit defektem Bus-Interface am Wickel ... hat>> nicht mehr funktioniert.> So einfach ist das auch nicht bis ich an den EMS-Bus vom SM10 komme:> Keller gehen, Deckel abschrauben, Modul aufschrauben, Stecker ziehen,> ... ;-)>> Ok, ich habs probiert, hilft mir aber jetzt am Abend nicht viel weiter.> Das SM10 hat nur eine grüne Lampe, die Betriebsbereitschaft signalisiert> (warscheinlich zeigt die nur an "Strom da ?!)> Wenn ich den EMS-Stecker ziehe leuchtet die grüne Lampe immer noch ??> Was sagt mir das jetzt ?> Hm, ob die Pumpe ohne EMS angesteuert wird kann ich wohl nur bei> Sonnenschein probieren - hoffentlich gibts am Wochenende Sonne, dann> probier ich das noch mal...>>>>>> //Niffko>
Nachtrag zur Info (vielleicht kanns ja jemand brauchen):
Ich hab das heute bei perfektem "Testwetter" (abwechselnd Sonne und
dunkle Wolken) noch mal genauer probiert:
Das SM10 arbeitet ohne RC30! Nach Abziehen der EMS-BUS-Verbindung blinkt
nach mehreren Sekunden die grüne Lampe am SM10 und das RC30 zeigt im
Display: "Keine Verbindung SOLAR". Die LED-Anzeige zeigt Fehler "A51".
Die Solarpumpe wird aber auch ohne EMS-Verbindung angesteuert. Je nach
Temperatur im Warmwasserboiler und in den Kollektoren wird die Pumpe mit
unterschiedlicher Leistung angesteuert. Soweit ich das beobachten konnte
wird die Pumpe "getaktet" (geschätzte 5 Hz).
mfg
Johnny
Hallo Johnny,
deine Beobachtungen decken sich mit den Angaben in der Service-Unterlage
des Moduls (siehe Anhang).
Niffko schrieb:> ... SM10 mit defektem Bus-Interface ... hat nicht mehr funktioniert.
da war dann wohl noch etwas anderes geschrottet ...
// Niffko
Hi Leute,
Ich versuche mir gerade die Bauteile für den NetIO EMS-Adapter aus dem
EMS-Wiki zusammen zu suchen
(http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io). Nur
hab ich leider keinen Plan wo ich die Teile am besten her bekomme. Habe
bei den Klassikern die ich noch aus meiner "Jugendzeit" kenne (conrad,
elv usw) fast keine der Bauteile finden können.
Ich habe mir über Eagle die Partlist exportiert und versucht anhand der
Bezeichnungen die Sachen zu finden - quasi ohne Erfolg.
Part Value Device Package Library
Sheet
C1 100n C5/3 C5B3 capacitor-wima 1
C2 10n C5/3 C5B3 capacitor-wima 1
C3 1.5n C5/3 C5B3 capacitor-wima 1
C4 1n C5/3 C5B3 capacitor-wima 1
C5 10u C5/3 C5B3 capacitor-wima 1
C6 68p C-EU025-050X050 C025-050X050 resistor 1
D1 BAT42BAT42 DO35-10 diode 1
D2 BAT42BAT42 DO35-10 diode 1
D3 BAT42BAT42 DO35-10 diode 1
D4 BAT42BAT42 DO35-10 diode 1
D5 BAT42BAT42 DO35-10 diode 1
IC1 LM393N LM393N DIL08 linear 1
IN EMS FFKV3 FFKV3 con-phoenix-508 1
J1 1-Wire 215877-4 215877-4 !kmw 1
L1 4.7uH MICC12 MICC12 inductors 1
L2 4.7uH MICC12 MICC12 inductors 1
NETIO MA05-2 MA05-2 con-lstb 1
R1 330R R-EU_0207/10 0207/10 resistor 1
R2 330R R-EU_0207/10 0207/10 resistor 1
R3 330R R-EU_0207/10 0207/10 resistor 1
R4 4K7 R-EU_0207/10 0207/10 resistor 1
R5 4K7 R-EU_0207/10 0207/10 resistor 1
R6 4K7 R-EU_0207/10 0207/10 resistor 1
R7 100K R-EU_0207/10 0207/10 resistor 1
R8 360R R-EU_0207/10 0207/10 resistor 1
R9 10K R-EU_0207/10 0207/10 resistor 1
R10 47K R-EU_0207/10 0207/10 resistor 1
R11 910R R-EU_0207/10 0207/10 resistor 1
R12 910R R-EU_0207/10 0207/10 resistor 1
R13 910R R-EU_0207/10 0207/10 resistor 1
R14 10K R-EU_0207/10 0207/10 resistor 1
R15 910R R-EU_0207/10 0207/10 resistor 1
RX_FAIL LED3MM LED3MM led 1
RX_OK LED3MM LED3MM led 1
T1 BC847B -NPN-TO92L TO92L transistor 1
TX LED3MM LED3MM led 1
Hat vielleicht jemand noch eine alte Bestellliste und/oder einen Shop wo
ich die Teile herbekommen kann?
Was für eine Lochplatinen größe/format bräuchte ich für den Adapter? Und
vielleicht noch eine Empfehlung für ein Netzteil, dann bin ich glaub ich
glücklich ;-)
(Freu mich schon drauf endlich mal wieder "rum zu löten" ;-) )
Grüße aus dem Münsterland,
Hi,
Bin gerade dabei schon mal den ems-collector zu installiern. (aus
maniacs, also vermutlich dannys git
https://github.com/maniac103/ems-collector )
collectord an sich startet (also mit -h) und liegt unter
/usr/local/sbin.
Die init datei liegt im /etc/init.d/ems-collector
Die config datei liegt unter /etc/default/ems-collector, in welcher nur
das PIDFILE und die OPTIONS konfiguriert sind:
-------------------------------------------------------------------
# Defaults file for EMS collector daemon
# This is a POSIX shell fragment
# config file location
#CONFIGFILE="/etc/ems-collector.conf"
# Serial device file
#SERIALDEVICE="/dev/ttyUSB0"
# Where to put the PID file
PIDFILE="/var/run/ems-collector.pid"
# Other options
OPTIONS="-C 7777 -D 7778 -u ems -p emscollector -r 60
tcp:192.168.100.200:7950 -d all=/var/log/ems-collector.log"
------------------------------------------------------------------
Wenn ich jetzt versuche das init script zu starten erhalte ich folgende
meldung:
------------------------------------------------------------------
/etc/init.d/ems-collector start
[....] Starting EMS collector daemon: collectordterminate called after
throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info
_injector<boost::program_options::invalid_command_line_syntax> >'
what(): the required argument for option '--file' is missing
Aborted
failed!
------------------------------------------------------------------
Mit moosys git hab ich das gleiche problem...
ich kriegs nicht auf die kette ;-)
In meiner /etc/default/ems-collector steht das hier:
# Defaults file for EMS collector daemon
# This is a POSIX shell fragment
# config file location
CONFIGFILE="/etc/ems-collector.conf"
# Serial device file
SERIALDEVICE="tcp:192.168.100.30:7950"
# Where to put the PID file
PIDFILE="/var/run/ems-collector.pid"
# Other options
OPTIONS=""
Und in /etc/ems-collector.conf das hier:
ratelimit = 120
db-user = emsdata
db-pass = emsdata
command-port = 7777
data-port = 7778
Das funktioniert und ist besser lesbar :)
Die Debug-Option kannst du in OPTIONS lassen; das eigentliche Problem
ist, dass das Target (also "tcp:...") an's Ende der Kommandozeile muss.
Wenn ich den collectord zu fuß mit den parametern starte, scheint es
keine probleme zu geben:
# collectord --pid-file=/var/run/ems-collector.pid -C 7777 -D 7778 -u
ems -p emscollector -r 60 tcp:192.168.100.200:7950 -d
all=/var/log/ems-collector.log
Allerdings natürlich auch keinen output.
# ps -A |grep collectord
17517 ? 00:00:00 collectord
nun ja - es scheint doch tatsächlich am init-script zu liegen....
Hi danny!
dank dir für die schnelle antwort!
recht hatta ;-) kaum macht mans richtig, klappts auch ;-)
nun dann müsste das wiki noch mal angepasst werden - denn wie dort
beschrieben scheint es zumindest bei mir nicht zu funktionieren.
ich schau mal ob ich das dort korrigieren kann.
grüße und schon mal ein schönes und angenehmens pfingswochenende!
Hi,
Ich glaube ich habe den "Fehler" gefunden. Ich habe einen BC-25 als
Basiscontroller am Kessel selbst.
Anscheinend sind hier einige Telegramme anders... Kein Wunder das mir
ein paar Daten fehlen ;-)
Und das ich als Raumbediengerät eine RC-300 habe, macht es auch nicht
einfacher :-)
Mal schauen ob ich es in meinen 2 Wochen schaffe in das EMS-Telegramm
Thema rein zukommen.
Vielleicht finde ich ja die Kandidaten zum erweitern des EMS-Collectors.
Grüße
also irgendwie komm ich mal wieder nicht weiter.
Die platine läuft bei mir ohne Probleme verbindung klappt bekomme auch
übers telnet alles hin.
Jetzt versuche ich als Mosis Werk zum laufen zu bringen aber wenn ich
die ems-tools starte geht kommt:
getversion
1
[ Gems:/> getversion
2
collector version: 2014031201
3
UBA version: 3.06
4
BC10 version: 2.03
5
RC version: 11.05
6
OK
7
[ Gems:/>
req uba:
1
heater maintenancedate = 2004-01-01
2
PHP Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/lars/ems/ems-tools/cli/emsclient on line 84
3
PHP Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/lars/ems/ems-tools/cli/emsclient on line 84
req UBA erledigt mit setzen der Timezone in
/etc/php5/cli/php.ini
date.timezone = " Europe/Berlin"
nun
1
MS-Client V0.1 (c) 2014 by Michael Moosbauer
2
Connecting to EMS-Bus... OK!
3
[ Gems:/> req bau
4
[ Gems:/> req uba
5
heater targettemperature = 7
6
ww targettemperature = 10
7
heater currenttemperature = 58.8
8
returnflow currenttemperature = 64.5
9
ww currenttemperature = 56.2
10
heater settemperature = 90
11
flamecurrent = 0.1
12
pressure = 1
13
burner currentmodulation = 0
14
burner minmodulation = 0
15
heaterpump minmodulation = 30
16
burner maxmodulation = 100
17
heaterpump maxmodulation = 91
18
burner targetmodulation = 0
19
heater onhysteresis = -6
20
heater offhysteresis = 6
21
warmwaterminutes = 60589
22
warmwaterpreparations = 2295
23
heater maintenanceintervalin100hours = 60
24
antipendelminutes = 10
25
heaterpump followupminutes = 5
26
flameactive = off
27
heateractive = off
28
ignitionactive = off
29
heater pumpactive = off
30
zirkpumpactive = off
31
3wayonww = off
32
ww onetimeload = off
33
ww desinfectionactive = off
34
ww boostcharge = off
35
warmwaterpreparationactive = off
36
warmwatertempok = on
37
ww daymode = off
38
zirkpump daymode = on
39
heater masterswitch = on
40
warmwatersystemtype = large
41
heater maintenancereminder = off
42
heater maintenancedate = 2004-01-01
43
servicecode = 0H
44
errorcode = 203
wenn ich die website aufrufe siehe bild...
Vielleicht habt ihr ne idee
Apache meldet:
1
[Thu Jun 19 20:20:17.060760 2014] [:error] [pid 5085] [client 192.168.178.42:38694] PHP Notice: Undefined variable: menus in /var/www/top.php on line 9
2
[Thu Jun 19 20:20:17.060793 2014] [:error] [pid 5085] [client 192.168.178.42:38694] PHP Warning: Invalid argument supplied for foreach() in /var/www/top.php on line 9
3
[Thu Jun 19 20:20:39.472985 2014] [:error] [pid 5084] [client 192.168.178.42:38695] PHP Warning: Invalid argument supplied for foreach() in /var/www/top.php on line 9
4
[Thu Jun 19 20:20:40.273690 2014] [:error] [pid 5084] [client 192.168.178.42:38695] PHP Warning: Invalid argument supplied for foreach() in /var/www/top.php on line 9
@ Danny & Moosy:
Gibt es eine Möglichkeit im Debuglog nur "Unhandled Messages" ausgeben
zu lassen? Das würde das Reversen der fehlenden Telegramme doch sehr
vereinfachen.
Übrigens habe ich mir auch den Collector mit der RAW-Funktion
kompeliert. Allerdings habe ich keinen Plan wie ich die Befehle
ausführen soll ;-)
Gestartet habe ich den Collector mit:
collectord -C 7777 -D 7778 -u ems -p emscollector -r 60
tcp:192.168.100.200:7950 -d all -f
Muss ich mich jetzt per Telnet zum Collector verdinden? Oder kann ich
auch die EMS-Tools verwenden?
Grüße
Danny Baumann schrieb:> larsrosen schrieb:>> Was meinst du mit out of the box?>> Naja, Basisfeatures (z.B. Sensorwerte des UBA) werden wahrscheinlich> einfach funktionieren, aber bei allem, was die RC300 selbst betrifft> (z.B. Schaltprogramme oder neue Features, die das Teil u.U.> bereitstellt) kann es sein, dass noch zusätzlicher Code in den Collector> rein muss, damit die RC300 auf den gleichen Stand wie RC30/35 kommt. Bei> den neuen Modulen gilt das gleiche.>>> Ich bin gerne bereit zu helfen die befehle raus zi bekommen?>> Na dann mal los ;) Den grundlegenden Ablauf hat moosy hier schon gut> beschrieben: Beitrag "Re: EMS > Adapter > NetIO > Raspi" - ein> paar Details haben sich inzwischen aber geändert:> - Der ems-collector muss mit Raw-Kommando-Support gebaut werden (Zeile 3> des Makefiles auskommentieren, d.h. Raute entfernen)> - Das emsqry-Kommando heißt inzwischen 'raw read <device> <type>> <offset> <len>' (in moosy's Beispiel 2a ist 0 der Offset und 25 die> Länge)> - Das emscmd-Kommando heißt inzwischen 'raw write <device> <type>> <offset> <data0> ... <dataX>'>> Für moosy's Punkt 5 melde ich mich freiwillig, wenn Punkt 4 erledigt ist> ;) (d.h. das Telegrammformat aufgedröselt ist).
Hi dany,
ich bin nun endlich soweit das ich die komandos raussuchen kann, jedoch
komme ich mit der anleitung nicht ganz klar, raw read liefert mir
keinerlei aussage.
1. Wie ist der typ für meine RC300 ( ich denke mal die gibt es noch
nicht)
wenn ich 08 für uba nehme zum testen bring ich immer noch keine
anzeige hin, da ich weder weiss welchen typ noch länge ich angeben muss.
Vielleicht kannst du mir ja ein tip oder ei beispiel anhand der alten
analyse geben.
Hat keiner mehr noch ein kleinen Tip wie das mit der Bus analyse
funktioniert?
Es wäre schade wenn die ganze Arbeit jetzt umsonst gewesen wäre und die
RC300 es nie in den collector schaffen würde.
Nochmal folgende schritte habe ich gemacht:
- Collector mit Raw support erstellt
- mit Telnet auf den Collector eingewählt
- dort bekomme ich verschiedenste Telegramm angezeigt die er noch nicht
kennt
- Wenn ich mit raw read arbeiten tue und gebe z.b moosy's beispiel ein
08 19 0 25 bekomme ich weder ein fehler noch eine anzeige.
Also vielleicht rafft sich ja doch noch mal einer der Dev's auf und gibt
ein wenig hilfestellung gerne auch per Telefon oder E-Mail. Das Projekt
hat viel Intresse geweckt und es wäre schade wenn es nur die alten RC's
supporten würde.
Lars Rosenberg schrieb:> Hat keiner mehr noch ein kleinen Tip wie das mit der Bus analyse> funktioniert?>
[...]
Also ich schliesse mich Lars an - würde auch gerne - wie weiter oben
schon geschrieben - aus- bzw mithelfen.
Aber vielleicht sind die beiden ja im Urlaub? ;-)
Gruß
Hi Jürgen,
Danke für die Infos. Durchgelesen haben wir (ich denke Lars auch ;-) )
das Wiki schon.
Nur weiss ich persönlich nicht wie ich den RAW Modus benutzen soll bzw
kann (siehe die letzten 3-6 Beiträge von Lars und mir).
Hier wären ein paar Syntax Beispiele mit den entsprechenden Befehlen
sehr hilfreich.
Die RE Anleitung aus dem Wiki ist doch irgendwie unübersichtlich ;-)
Danke schon mal!
Lars Rosenberg schrieb:> Es wäre schade wenn die ganze Arbeit jetzt umsonst gewesen wäre und die> RC300 es nie in den collector schaffen würde.
Nicht so schnell aufgeben :)
> Nochmal folgende schritte habe ich gemacht:> - Collector mit Raw support erstellt> - mit Telnet auf den Collector eingewählt> - dort bekomme ich verschiedenste Telegramm angezeigt die er noch nicht> kennt> - Wenn ich mit raw read arbeiten tue und gebe z.b moosy's beispiel ein> 08 19 0 25 bekomme ich weder ein fehler noch eine anzeige.
Fast richtig. Mache aus dem 19 mal ein 0x19 und du wirst eine Anzeige
bekommen ;)
19(hex) = 25(dez)
Die Geräteadressen und Telegrammtypen werden üblicherweise hexadezimal
angegeben, wenn man das 0x davorstellt, sollte man also auf der sicheren
Seite sein.
> Also vielleicht rafft sich ja doch noch mal einer der Dev's auf und gibt> ein wenig hilfestellung gerne auch per Telefon oder E-Mail. Das Projekt> hat viel Intresse geweckt und es wäre schade wenn es nur die alten RC's> supporten würde.
Für Telefonsupport fehlt mir persönlich die Zeit. E-Mail-Support finde
ich auch nicht so hilfreich, weil die gewonnenen Erkenntnisse dann auch
nicht jedermann zur Verfügung stehen. Es ist IMHO besser, die
(idealerweise konkreten) Fragen hier zu stellen.
Vielleicht kannst du mir jetzt noch bein aufdröseln kurz helfen.
Laut protokoll sollt das 1.Byte (0x01) der Sender sein?
das wäre in der Tabelle ein RC35 oder?
da ich ja die außentemperatur abgefragt habe sollte die ja irgendwo in
dieser zeile zu finden sein? es waren grade 29°C
Vielleicht kannst du mal anhand eines Beispiels zeigen wie es geht.
Und gibt es eine möglichkeit telegramme abzuhören die auf dem Bus sind,
da ich irgendwie das gefühl habe die ems-plus telegramme sind anders
aufgebaut?
Das wäre auch im WIKI hilfreich. einfach mal ein beispiel wie es sich
aufbaut.
Lars Rosenberg schrieb:> Laut protokoll sollt das 1.Byte (0x01) der Sender sein?> das wäre in der Tabelle ein RC35 oder?
Doppelt nein. Das 1. Byte in der Ausgabe ist das 1. Byte des
eigentlichen Telegramms, d.h. das Byte, das nach dem Offset kommt.
Sender, Empfänger, Typ und Offset werden nicht nochmal mit ausgegeben,
da ohnehin klar (Empfänger ist 0xb = PC, Sender, Typ und Offset stehen
im Befehl).
Das zweite nein bezieht sich auf die Annahme, dass 0x01 die RC35 meint:
Die RCxx-Adresse ist 0x10.
> da ich ja die außentemperatur abgefragt habe sollte die ja irgendwo in> dieser zeile zu finden sein? es waren grade 29°C
Ja. Außentemperatur sind die ersten beiden Bytes des
MonitorSlow-Telegramms, d.h. 0x01 0x23 -> 0x123 = 291 -> 29.1°C. Der
Divisor (hier 10) steht auch im Wiki ;)
> Und gibt es eine möglichkeit telegramme abzuhören die auf dem Bus sind,> da ich irgendwie das gefühl habe die ems-plus telegramme sind anders> aufgebaut?
Nicht mit der Kommandoschnittstelle. Du kannst Message-Debug per
Kommandozeilenparameter im collector anmachen, dann steht's im Log (-d
message -> Ausgabe auf stdout, -d message=/tmp/log.txt -> Ausgabe in
Datei)
telnet 127.0.0.1 7777 (wenn der PC wo collector läuft der selbe ist wie von dem der telnet Befehl aufgerufen wird, ansonsten die IP des collector client)
MESSAGE[04.07.2014 17:12:21]: source 0x10, dest 0x00, type 0xff, offset 15, data: 0x01 0xa5 0x04 0x04
13
MESSAGE[04.07.2014 17:12:26]: source 0x10, dest 0x00, type 0xff, offset 12, data: 0x01 0xf5 0x00
14
MESSAGE[04.07.2014 17:12:27]: source 0x10, dest 0x00, type 0xff, offset 13, data: 0x01 0xf5 0x00 0x00 0x00 0x00 0x00
15
MESSAGE[04.07.2014 17:12:27]: source 0x10, dest 0x00, type 0xff, offset 18, data: 0x01 0xf5 0x00 0x00
16
MESSAGE[04.07.2014 17:12:27]: source 0x10, dest 0x00, type 0xff, offset 11, data: 0x01 0xf5 0x00
17
[/color]
Die letzten 5 telegramme kahmen als ich die einmalladung des Speichers
getopt habe von der RC300. Was mich da stört ist type 0xff sind das
echte typen oder welche die nicht in der collector eingepflegt sind?
wenn nich nämlich versuche diese mit raw read 0x10 0xff 0 40 zu lesen
kommt nur OK sonst nix
und wenn ich die schaltpunke abfragen will bekomme ich auch nur OK
raw read 0x10 0x3d 0 25
Roh daten:
MESSAGE[05.07.2014 06:43:51]: source 0x48, dest 0x10, type 0xff, offset 11, data: 0x01 0xb9 0x01
0x48 ist also der Km200
nur wenn ich jetzt sage:
raw write 0x10 0xff 11 0x01 0xb9 0x02
komtt zwar ok aber im log steht source 0x100 dest 0x00 typ 0xff data
(leer)
und es passiert nix
Hallo liebe Leute,
ich möchte mich auch ein wenig intensiver mit meiner Buderus Heizung GBH
172 14T 75S mit RC300 und Solarunterstützung beschäftigen. Nachdem ich
hier schon eine Weile mitlese, habe ich entschieden, dieses interessante
Projekt auch technisch umzusetzen und ggf. zu unterstützen (je nach
meinen Möglichkeiten). Ganz am Ende ist das Ziel die Integration in die
Heimautomation mittels fhem.
Aber eins nach dem anderen.
Die Adapterplatine ist auf einer Lochrasterplatine fertiggestellt. Dabei
fiel mir eine fehlende Verbindung auf (siehe Bild).
AVR-NetIO läuft mit ATMEGA644p und ethersex im LAN. Das hex-File habe
ich erstellt und geflasht. Raspi ist vorhanden und läuft im LAN, da bin
ich aber noch nicht angekommen. Noch bin ich beim NetIO. Bei mir klemmt
es momentan an der EMS Konfiguration von ethersex. Und da bräuchte ich
einen Tipp: Bei "Status LED" kann ich "Status LED (Transmitted)" noch
auswählen, die Unterpunkte wie "EMS TX" sind aber "not available".
Gleiches Bild für die anderen beiden LEDs. Ethersex ist aktuell, hab ich
gecheckt.
Wenn dadurch die LEDs ohne Funktion blieben, sehe ich die weiteren
Schritte gefährdet.
Was kann das sein ?
LG
Hi,
Du musst im ethersex configmenu zuerst eine andere Option aktivieren
damit du die ems LED status Sachen auswählen kannst.
Welche das was weiss ich leider auch nicht mehr :-) (hatte das selbe
Problem). Stelle erst mal alles nach der Anleitung aus dem wiki ein.
Dann geh zum Schluss noch mal in die Status LED Option. Dann solltest du
es aktivieren können.
Aber selbst ohne LEDs funktionert das ganze. Blinkt halt nur nichts :-)
Gruss
Danke für den Tipp, hat funktioniert.
Man kann nicht die Konfiguration in der Reihenfolge des Wiki bearbeiten,
sondern man muss nach der Einstellung "EMS-Support" unter "Protocols"
noch mal zurück zu den LEDs.
LG
Hi,
Habe jetzt auch mal mein Logfile auseinander gepflügt. Man ist da viel
los auf dem Bus! Ist das bei euch auch so?
Frage dazu: Wie Filtert ihr eure Logfiles? Gibts noch eine Möglichkeit
sich nur die Unhandled Messages Anzeigen zu lassen? Also mit den
Wichtigen Zeilen davor und dahinter?
Fürs RE ist das sonst echt unübersichtlich :-)
Bis jetzt habe ich vier noch nicht im Wiki gelistete Sourcen gefunden:
Source 8
DATA: Unhandled message received(source 0x08, type 0x02).
DATA: Unhandled message received(source 0x08, type 0x04).
DATA: Unhandled message received(source 0x08, type 0x07).
DATA: Unhandled message received(source 0x08, type 0x25).
DATA: Unhandled message received(source 0x08, type 0x2a).
DATA: Unhandled message received(source 0x08, type 0xd1).
DATA: Unhandled message received(source 0x08, type 0xe6).
DATA: Unhandled message received(source 0x08, type 0xe9).
DATA: Unhandled message received(source 0x08, type 0xea).
DATA: Unhandled message received(source 0x08, type 0xef).
Source 9
DATA: Unhandled message received(source 0x09, type 0x02).
DATA: Unhandled message received(source 0x09, type 0x29).
Source: 21
DATA: Unhandled message received(source 0x21, type 0x02).
DATA: Unhandled message received(source 0x21, type 0x1a).
DATA: Unhandled message received(source 0x21, type 0xf6).
DATA: Unhandled message received(source 0x21, type 0xf7).
DATA: Unhandled message received(source 0x21, type 0xff).
Source: 30
DATA: Unhandled message received(source 0x30, type 0x02).
DATA: Unhandled message received(source 0x30, type 0x35).
DATA: Unhandled message received(source 0x30, type 0xf6).
DATA: Unhandled message received(source 0x30, type 0xf7).
DATA: Unhandled message received(source 0x30, type 0xff).
Das sind vermutlich u.a. die Solar Komponenten und die Heizkreise 1 und
2? Gibt es eine Möglichkeit herauszufinden was das ist?
Grüße
wenn du collecotrd mit -d message startest bekommst du nur die roh
daten.
Ich habe es so gemacht, das ich von den unbekannten geräte dienste
gestartet habe z.b WW einmalladung dann siehst du von wo des telegramm
kommt.
Aber ich glaube immernoch das ich mit meiner RC300 kein glück haben
werde. Wenn ich nämlich bei dir sehe sind es fast alles typen die nicht
0xff sind bei mir kommen nur die 0xff typen....
Vielleicht meldet sich danny nochmal zu wort.
Hi Lars,
ich habe den collectord wie folgt gestartet:
./collectord -C 7777 -D 7778 -u meinuser -p meinpassword -r 60
tcp:192.168.100.200:7950 -d all=/var/log/ems-collector.log
Dann habe ich mir "tail -f" das logfile anzeigen lassen und am RC300
dann z.b. die Solar infos ausgewählt.
aber jetzt wo du es sagst, hatte ich gar keine telnet session zum
collector auf ;-)
Habe auch eine KM200 - diese ist aber z.Zt. nicht angeschlossen (glaube
aber nicht das es damit zusammenhängt).
Welche Softwareversion hat denn deine RC300? (Meine: 11.04)
Wenn du anstelle von
-d all
Das machste
-d message
Oder
-d message, io
Bekommst du die klartextmeldungen nicht angzeigt.
Ich denke es hat nicht direkt mit dem km200 zu tun sondern eher daran,
das bei mir die rc300, rc100 und km200 sich auf dem ems-plus
unterhalten. Die sachen die unter ems gehen (uhrzeit, Datum und
brennerzyklen) kann man auslesen. Aber z.b die schaltzeiten ändern die
gehen nicht über das ems sondern jetzt über das ems plus protkoll. Alles
was ich im Moment getestet habe sendet mit dem typ 0xff. Normalerweise
sieht man aber davon ab etwas als byte ff zu deklarieren, da es ja eine
11111111 wäre und so auch ein fehler aussehen würde.
Entweder ist der ems plus typ nicht nur ein byte gross oder er muss
irgendwie noch versorgt werden im quellcode.
Ich habe mir bereits mal angeshen wo der typ herkommt aber finde im code
bislang nicht die stelle wo der m-type geparst wird. Deshalb hoffe ich
das danny sich meldet.
Aber was ich rausgefunden habe
0x38 rc100
0x48 km200
Andre Geheim schrieb:> Bis jetzt habe ich vier noch nicht im Wiki gelistete Sourcen gefunden:> Source 8
Das ist der UBA (sollte im Wiki stehen)
> Source 9
Das ist BC10 (Controller am Brenner; sollte auch im Wiki stehen)
> Source: 21
Das ist der Mischer für HK2 (also MMxx; sollte auch im Wiki stehen)
> Source: 30
Das kenne ich nicht, ist wahrscheinlich das Solarmodul.
Lars Rosenberg schrieb:> Aber ich glaube immernoch das ich mit meiner RC300 kein glück haben> werde. Wenn ich nämlich bei dir sehe sind es fast alles typen die nicht> 0xff sind bei mir kommen nur die 0xff typen....
Naja, was heißt 'kein Glück' - dafür musst du schon selbst sorgen :) Das
ganze ist wahrscheinlich ein neues Protokoll, das Buderus auf den EMS
gesetzt hat; und dafür haben sie den Typ 0xff genommen, um
rückwärtskompatibel zu bleiben (Niffko, klingt das plausibel?). Das
ganze aufdröseln kann aber IMHO nur jemand, der auch das Gerät hat,
damit derjenige (z.B. du ;) ) immer mit dem RC vergleichen kann.
Lars Rosenberg schrieb:> was ich im Moment getestet habe sendet mit dem typ 0xff. Normalerweise> sieht man aber davon ab etwas als byte ff zu deklarieren, da es ja eine> 11111111 wäre und so auch ein fehler aussehen würde.
??? Wie meinst du das?
> Entweder ist der ems plus typ nicht nur ein byte gross oder er muss> irgendwie noch versorgt werden im quellcode.
Mit Sicherheit. Zunächst einmal muss aber herausgefunden werden, in
welcher Form das passieren muss.
> Ich habe mir bereits mal angeshen wo der typ herkommt aber finde im code> bislang nicht die stelle wo der m-type geparst wird. Deshalb hoffe ich> das danny sich meldet.
Was ist der 'm-type'?
> Aber was ich rausgefunden habe> 0x38 rc100> 0x48 km200
Ist doch schon mal etwas :)
Mit dem 0xff kenne ic das nur so, das man so fehler deklriert, da eine 1
auf allen 8 Bits auch zustande kommt wenn z.B.: ein timing Fehler
vorliegt.
Mit dem m_type vergess das einfach, der steht im quellcode bei der
Message ausgabe, ich dachte evlt ist das nur zu klein gewählt, kann aber
nicht sein sonst müssten die fehlenden bytes woander drin auftauchen.
Und das aufdröseln ist mir ja klar das das jemand machen muss.bin ja
dran.
Nur ich kann kein write ausführen mit dem typ 0xff.
Ich schreibe folgenden Befehl:
raw write 0x10 0xff 4 0x01
in log kommt aber nur:
IO: Sending bytes 0x10 0xff 0x4 0x1
IO: Got bytes 0xaa 0x55 0x4 0x10 0xb 0xff 0x1 0xe5
MESSAGE[06.07.2014 14:23:57]: source 0x10, dest 0x0b, type 0xff, offset
1, data:
ich versuche dieses Telegramm ein zu setzten
source 0x48, dest 0x10, type 0xff, offset 11, data: 0x01 0xb9 0x01
Zeitprogramm 1 hk1
oder dies:
raw write 0x10 0xff 11 0x01 0xb9 0x01
IO: Sending bytes 0x10 0xff 0xb 0x1
IO: Got bytes 0xaa 0x55 0x4 0x10 0xb 0xff 0x1 0xe5
MESSAGE[06.07.2014 14:26:50]: source 0x10, dest 0x0b, type 0xff, offset
1, data:
raw read bekomme ich auch nichts ausgegeben auf 0xff.
Deshalb dachte ich es muss erstmal der typ 0xff versorgt werden im
collector damit irgendwie das senden funktioniert?
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten
