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?
Hallo zusammen,
nachdem der Net-Io läuft habe ich mich dem Raspi beschäftigt und brauche
etwas Starthilfe. Collectord kann ich manuell starten, die DB wird
beschrieben. Der Start über init.d wird mit failed! abgebrochen. Die
Konfiguration habe ich anhand dieses Threads angepasst. Das ist eine
Baustelle. Das Webinterface läuft in Teilen, so sieht das Protokoll
schon gut aus, aber im Livestatus bekomme ich keine Daten. Im log von
lighttpd finde ich u.a. das hier:
2014-07-11 20:07:28: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Notice:
Undefined
index: servicecode in /var/www/lemscnt.ajax on line 36
PHP Notice: Undefined index: errorcode in /var/www/lemscnt.ajax on line
36
PHP Notice: Undefined index: in /var/www/lemscnt.ajax on line 36
PHP Notice: Undefined index: flameactive in /var/www/lemscnt.ajax on
line 49
PHP Notice: Undefined index: 3wayonww in /var/www/lemscnt.ajax on line
50
PHP Notice: Undefined index: ww daymode in /var/www/lemscnt.ajax on
line 52
PHP Notice: Undefined index: zirkpump daymode in /var/www/lemscnt.ajax
on line
53
PHP Notice: Undefined index: hk1 partymode in /var/www/lemscnt.ajax on
line 54
PHP Notice: Undefined index: hk1 pausemode in /var/www/lemscnt.ajax on
line 54
PHP Notice: Undefined index: hk1 holidaymode in /var/www/lemscnt.ajax
on line 5
6
Ich tippe auf Probs mit dem symlink emsincludes und bin mir nicht
sicher wie und wo ich den richtig anlege, oder angelegt habe?
Das Ganze ist zu komplex strukturiert (Anleitung im github und Hinweise
hier) und viel Energie geht bei "try and error" drauf.
Habt Ihr noch eine Starthilfe für mich?
LG
Lorenz
Lorenz G. schrieb:> Ich tippe auf Probs mit dem symlink emsincludes und bin mir nicht> sicher wie und wo ich den richtig anlege, oder angelegt habe?
Moosy hat den symlink ins root gelegt. Sicher gibt es auch Menschen mit
anderen Dateisystemphilosophien. ;) Ich habs jedenfalls auf meiner Kiste
komplett umstrukturiert.
Schau Dir vlt. noch mal in aller Ruhe die Links in den einzelnen Dateien
an. Hat bei mir geholfen und es bringt den Vorteil, dass man einen
Überblick über die Zusammenhänge erhält, der stets hilfreich ist.
> Das Ganze ist zu komplex strukturiert (Anleitung im github und Hinweise> hier) und viel Energie geht bei "try and error" drauf.
Ja, da ist was dran. Wir könnten jemanden gebrauchen, der eine "ems.deb"
zusammenstellt. ;)
hth
Karl M.
Bei mir lagen diese fehler daran, das bei einigen dateien das ? gefehlt
hat bei
<?PHP
dadurch kommt sowas zustande.
guck einfach sämtliche daten(ems-tools und Ems website) durch on die PHP
dekalration stimmt.
bitte mal testen
Beim Löschen lässt es die Datenbank bestehen.
Installiert bislang die init.d setzt sie aber nicht aktiv.
Aufbau
/etc/default
/etc/init.d
/esmincludes
/usr/local/ems/ems-collector
/usr/local/ems/ems-tools
/var/www
Wenn du mir sagen kannst wie die abhängigen pakete genau heisen auf dem
pi dann mach ich es offen für alle systeme.
Oben ist noch ein fehler mit den libs drinne. Fixe ich heut abend
So,
schau jetzt mal.
Ich habe es komplett umgestell, damit es auf allen system selbst
erstellt wird. Ich hoffe meine depencies stimmen.
Wenn ein fehler beim erstellen kommt brauch ich die Namen der Pakete wie
ihr sie braucht um den collectord zu erstellen,
Die Paketinstallation läuft nicht durch, Abbruch bei Erstellung des
symlink mit dieser Meldung:
Verlinke emsincludes
ln: angegebenes Ziel „/emsincludes/“ ist kein Verzeichnis: Datei oder
Verzeichnis nicht gefunden
dpkg: Fehler beim Bearbeiten von ems-buderus (--install):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert
1 zurück
Fehler traten auf beim Bearbeiten von:
ems-buderus
Ich habe verschieden Varianten versucht, mal mit angelegtem Verzeichnis
/emsincludes im root mal ohne, immer das gleiche Bild.
Die Probleme, welche ich manuell hatte, scheint auch die Paketverwaltung
zu haben :-)
LG
Also du brauchst definitv root rechte um den ordner im root zu
erstellen.
Er versucht erstmal den orden esmincludes in / anzulegen,
Was passiert bei dir wenn du
sudo mkdir /emsinclude eintippst?
dann
ls -ls /
und dort sollt ein ordner /emsincludes sein
EDIT
nene quark du hast n Raspi....
das ding musst du erstmal neu mounten, damit du schreiben darfst im root
(/)
sudo mount / -o remount,rw
das eingeben
wenn das geht sag mal bescheid
wenn fertig
sudo mount / -o remount,ro
Ja danke,
fehler erkannt,
muss das fixen.
mach mal fürn anfang
sudo mkdir /emsincludes
sudo dpkg --remove ems-buderus
und dann installier dieses erneut:
sudo dpkg --install ems-buderus
So ich denke so kann man es lassen,
- Es lädt den Collector runter, compiled ihn Normal und mit RAW-support
und kopiert es nach /usr/local/sbin
- Es installiert die website von Moosy ( coding fehler behoben) nach
/var/www/ems und richtet sie bei apache ein und startet diese.
- Es richtet auf wunsch eine SQL-Datenbank mit User ein (ems passwort
buderus)
- Es fragt und editiert die config für die IP des NET-IO
Die autostart funktion muss manuell eingerichtet werden.
sudo update-rc.d ems-collector default
starten mit
/etc/init.d/ems-collector start
/etc/init.d/ems-collector stop
/etc/init.d/ems-collector raw
installieren mit
sudo dpkg --install ./ems-buderus_0-4.deb
deinstall mit
sudo dpkg --remove ems-buderus (löscht nicht die datenbank)
Also ich habe noch mal ausgiebig getestet:
Das Gute: Die Installation läuft durch.
Anschliessend ist aber /usr/local/sbin leer. Ich habe dann collectord
dorthin kopiert. Beim start kommt failed vom collectord. Der Webserver
hat keine Verbindung zum ems-Bus, Telnet auf 7777 geht natürlich auch
nicht.
Dann habe ich collectord manuell gestartet mit:./collectord -u ems -p
buderus -d all tcp:192.168.178.190:7950 -> gleiches Bild.
Nehme ich die die alte Version von maniac103/ems-collector ist die Datei
wesentlich kleiner, aber läuft, allerdings auch nur mit o.g. manuellen
Aufruf, wird aber natürlich bei Statistik im Web-Server als veraltet
angemeckert.
LG
Welche meldung bringt er denn beim installieren?
Ich habe extra jede menge text in den install part gepackt.
Intressant ist der teil direkt nach dem ersten compilen.
Kopiere collectord.
Hast du die libboost installiert?
Es kann natürlich sein das ich die abhängigkeiten nicht richtig drinne
hab und er es gar nicht erstellt bei dir? Geht es denn manuell zu
erstellen?
Hallo,
wie habt Ihr denn die Teile (Adapterplatine > AVRNetIO) bei euch im
Schaltschrank verbaut? Weil ich suche jetzt schon länger noch einem
Vernünftigem Gehäuse finde aber nichts.
Gruß und Danke
Marco
Zum Thema Gehäuse:
Ich habe mir auch Gedanken um ein Gehäuse gemacht, damit der fliegende
Aufbau wegkommt. Ich habe mich jetzt für eine separate Lösung neben der
Heizung entschieden. Die Heizung ist in einem separaten Technikraum im
Keller, da passt das auch vom Design. Ich muss aber noch schrauben. Zur
Ansicht habe ich mal einen Raspi reingelegt. Der NetIO und die
Adapterplatine kommen daneben rein...
Das Gehäuse habe ich bei Amazon gefunden: JS7681 Installationsgehäuse
mit transparentem Deckel Größe 240x190x110mm, Schutzart: IP 65 gem. DIN
EN 60529/DIN 40050; Farbe: Gehäuse grau RAL 7035, Deckel transparent
Material: Gehäuse: ABS (UV geschützt), Deckel: Polycarbonat, Schrauben:
rostfreies Metall, Abmessungen: Breite: 240mm (B) Höhe: 190mm (A) Tiefe:
110mm, Installationstemperatur: -15°C bis +60°C gem. DIN EN 60670
Mit Montageplatte < 30€, ohne < 20€.
Da ist Platz genug drin. Wenn ich das fertig bestückt habe, dann liefere
ich noch ein Bild nach.
LG
Lorenz
Zur Paketinstallation von Lars:
Auf dem Raspi hat es letztendlich fast funktioniert, bis auf das Problem
mit dem nicht selbst startenden Collector auf dem Raspi. Das habe ich
noch nicht im Griff. Z.Zt. erledige ich den Start noch manuell, läuft
dann aber seit Wochen stabil.
Bislang war die nicht funktionierende Grafik für mich noch Nebensache.
Habe mir das aber jetzt angeschaut und gesehen, dass für den Raspi die
Anpassung fehlte:
Die mysql socket Angabe in der config.py:
/var/run/mysqld/mysqld.sock
für RaspberryPi/debian wheezy
wurde hier auch schon geschrieben.
Erledigt und funktioniert, nur der Vollständigkeit halber...
Muss mir jetzt auch noch Gedanken über den Cron-Job machen.
LG
Lorenz
P.S. Mittlerweile habe ich eine Verbindung zu fhem über das Modul ECMD
erfolgreich eingerichtet, über telnet auf dem Port 7778 (nur Lesen),
falls es Jemanden interessiert. Ich habe dazu auch was im Fhem-Forum
geschrieben.
Hi!
Hat eigentlich schon jemand Fortschritte mit den EMS-Plus Telegrammen
gemacht?
Ich selbst komme da leider nicht weiter...
Was mir momentan noch Fehlt sind die beiden Heizkreise HK1 und HK2 und
die ganze Solar-Modul Geschichte...
Was ich noch mal zur Verfügung stellen könnte wären Logfiles...
Grüße
Hallo,
ist es möglich die Daten des AVR Net IO nicht über eine
Netzwerkverbindung sondern über eine Serielle Schnittstelle an den Raspi
zu übertragen?
Ich möchte mir die Schaltung rund um dem ATmega644 selbst zusammenbauen
damit ich kein Net IO benutzen muss. Auf das Board soll die
EMS-Pegelwandlung auch gleich mit drauf...
Nur macht für die 20 cm wo die platinen auseinander sind LAN für mich
keinen sinn. Dann lieber nen Pegelwandler zwischen das Net IO und den
Raspi.
Die Hardware bekomme ich hin, nur mit der Software hapert es...
Kann da jemand helfen und mir erklären wie das geht bzw. was an der Soft
auf dem ATmega644v dann geändert werden muss?
Grüße
Andy
Gibt es eigentlich zwischenzeitlich eine Platine für das Projekt?
Ich denke, das bspw mit dem ESP8266 eine interessante und einfache
Anbindung realisiert werden kann (kein AVR/PIC) und würde da gerne ein
wenig "spielen".
(Die serielle Schnittstelle erkennt Framing-Errors).
Beitrag "Wlan2Serial Modul für 5 euro"http://www.esp8266.com/index.php
Hallo,
nach vielen Stunden intensiver Lektüre habe ich meine "Transfer-Strecke"
zum Laufen gebracht.
Allerdings verhält sich der collector einfach zu ruhig. Die einzige
Ausgabe ca. alle 10 (manchmal auch 20) Sekunden:
IO: Got bytes 0xaa 0x55 0x1 0xff 0xff
MESSAGE[03.10.2014 16:41:23]: source 0x00, dest 0x00, type 0x00, offset
0, data: 0xff
Etwas verwundert habe ich danach mal den Status des NetIO nach etwa
einer Stunde Laufzeit aufgerufen:
Bytes total:149034
Bytes good:201
Bytes dropped:0
Packets good:197
Packets bad:2549
Packets 1byte:129833 229
Packets ack:0 nack:0
Overflow:0
Max fill:4
Warum werden so viele Telegramme verworfen?
eine Konfig:
GB162 (BC10) mit RC300
Ich weiß, die RC300 wird noch nicht direkt unterstützt, aber die Daten
werden ja schon vom Framer gedropt...
Woran könnte das liegen? Oder interpretiere ich die Daten falsch?
Grüße
Fabian
Update:
obiges Problem gelöst!
Nach einigen Messungen mit eine Oszi habe ich bemerkt, dass die
Polarität an den Eingängen des Komparators/OPs falsch war. Grund: ich
hatte die Anschlüsse beim Verschalten vertauscht. Argghhh... Umgelötet,
läuft!
Jetzt hänge ich beim Web-Frontend:
Alles lt. Post von Michael
(Beitrag "Re: EMS > Adapter > NetIO > Raspi") eingerichtet.
EMSCLIENT lief nicht, php nicht gefunden. Klar kein CLI drauf, php5-cli
nachinstalliert >> läuft. Webfrontend in den Ordner vom lighttpd
kopiert.
Erste Unklarheit:
Im www-Ordner ist nur ein Link auf graphs enthalten. Muss das auf das
aktuelle (in den conf Dateien angegebene) Verzeichnis angepasst werden?
Fehler:
Mein Webserver bringt statt der Seite nur die Fehlerseite 503. Im
Serverlog des lighttpd wird ein fehlender socket (/tmp/php.socket)
bemängelt. Lege ich diesen mit touch selbst an, wird vom Webserver
"connection refused" gemeldet. Berechtigungen habe ich bis auf die
graphs wie aus dem Post von Bernd angepasst.
Zweite Unklarheit:
Bernd schreibt, dass er die Berechtigungen der Files im Graphs-Ordner
angepasst hat. Welche Dateien werden in den Graphs-Ordner kopiert?
Irgendwie fehlt mir hier noch ein Stück vom Puzzle...
Grüße
Fabian
Fa Ke schrieb:> Fehler:> Mein Webserver bringt statt der Seite nur die Fehlerseite 503. Im> Serverlog des lighttpd wird ein fehlender socket (/tmp/php.socket)> bemängelt. Lege ich diesen mit touch selbst an, wird vom Webserver> "connection refused" gemeldet.
Hallo Fabian,
Du kennst:
http://www.cyberciti.biz/tips/lighttpd-php-fastcgi-configuration.html
Läuft Dannys Webapplikation?
Ansonsten nochmal Pfade und Berechtigungen in Michaels Frontend checken.
Du bekommst das hin, wir haben es schließlich auch geschafft. ;)
Gruß
Karl M.
Guten Abend,
ich stecke beim make für collectord fest, komme nicht mehr weiter und
hoffe auf einen Tipp.
Ein make für den collectord bringt mir tonnenweise Meldungen wie diese
hier:
main.cpp:(.text.startup+0x360): undefined reference to
`boost::thread::~thread()'
Ja, ich habe zuvor mit apt-get install die libboost1.50 Library
installiert - exakt so, wie im Wiki angegeben. Ich habe auf meinem Raspi
die aktuelle Wheezy drauf, mit allem auf neurstem Stand.
Sachdienliche Hinweise sind hochwillkommen.
Ich bedanke mich schon jetzt für die sicher zahlreichen Tipps.
Danke !
Joshi
Hallo Joshi,
ich hatte mich auch an das wiki gehalten und ein ähnliches Problem. Bei
mir läuft es nur mit der 1.49er libboost Bibliothek.
@all
Update für das lighttpd Server-Problem:
Es lag an dem eingefügten Teil in der lighttpd.conf
1
fastcgi.server = ( ".php" => ((
2
"bin-path" => "/usr/bin/php-cgi",
3
"socket" => "/tmp/php.socket"
4
)))
der Abschnitt war optisch fehlerfrei und ich hatte ihn mit nano händisch
eingetragen, nicht kopiert. Denn gerade bei kopierten Abschnitten hatte
ich schlechte Erfahrungen gemacht, wegen manchmal inkorrekter Zeichen.
Nach dem Kopieren ging es dann. Ich hoffe, es hilft anderen mit
vergleichbaren Problemen.
Gruß
Fabian
Hi Fabian,
danke für den Tipp, probiere ich nachher gleich mal aus. Die Ironie ist,
dass er mir beim Installieren der 1.50 Libs gesagt hat, er würde die
zuvor installierte 1.49 Lib entfernen -haha.
Nochmals vielen Dank!
Ich melde mich nachher mit einem Ergebnis - so oder so ;-)
Joshi
Hi Fabian,
das war's. libboost1.49-all hat's gebracht.
Danke für den Tipp !!!
Vielleicht kann der Maintainer des Wiki einen entsprechenden Hinweis
anbringen, damit sich nicht immer wieder jeder durch den kompletten
Thread durchwühlen muss.
Danke und noch einen schönen Tag
Joshi
Hi Charlie,
danke für das rasche Einbauen ins Wiki.
Ich bin nicht der große c++ Tüftler, deshalb fürchte ich, dass ich nicht
viel zur Problemeinkreisung beitragen. Ich habe bei mir auch mal ein
ldconfig gemacht (weiß nicht, ob das zur Wahrheitsfindung dienen kann),
mit folgendem Ergebnis:
libboost_python-py32.so.1.49.0 -> libboost_python-py32.so.1.49.0
libboost_math_tr1.so.1.49.0 -> libboost_math_tr1.so.1.49.0
libboost_mpi_python-py27.so.1.49.0 -> libboost_mpi_python.so
libboost_graph_parallel.so.1.49.0 -> libboost_graph_parallel.so.1.49.0
libboost_math_c99.so.1.49.0 -> libboost_math_c99.so.1.49.0
libboost_locale.so.1.49.0 -> libboost_locale.so.1.49.0
libboost_thread.so.1.49.0 -> libboost_thread.so.1.49.0
libboost_wserialization.so.1.49.0 -> libboost_wserialization.so.1.49.0
libboost_python-py27.so.1.49.0 -> libboost_python.so
libboost_python-py26.so.1.49.0 -> libboost_python-py26.so.1.49.0
libboost_mpi.so.1.49.0 -> libboost_mpi.so.1.49.0
libboost_serialization.so.1.49.0 -> libboost_serialization.so.1.49.0
libboost_iostreams.so.1.46.1 -> libboost_iostreams.so.1.46.1
libboost_wave.so.1.49.0 -> libboost_wave.so.1.49.0
libboost_timer.so.1.49.0 -> libboost_timer.so.1.49.0
libboost_date_time.so.1.49.0 -> libboost_date_time.so.1.49.0
libboost_prg_exec_monitor.so.1.49.0 ->
libboost_prg_exec_monitor.so.1.49.0
libboost_math_tr1f.so.1.49.0 -> libboost_math_tr1f.so.1.49.0
libboost_filesystem.so.1.49.0 -> libboost_filesystem.so.1.49.0
libboost_unit_test_framework.so.1.49.0 ->
libboost_unit_test_framework.so.1.49.0
libboost_math_c99f.so.1.49.0 -> libboost_math_c99f.so.1.49.0
libboost_iostreams.so.1.50.0 -> libboost_iostreams.so.1.50.0
libboost_graph.so.1.49.0 -> libboost_graph.so.1.49.0
libboost_chrono.so.1.49.0 -> libboost_chrono.so.1.49.0
libboost_signals.so.1.49.0 -> libboost_signals.so.1.49.0
libboost_iostreams.so.1.49.0 -> libboost_iostreams.so.1.49.0
libboost_random.so.1.49.0 -> libboost_random.so.1.49.0
libboost_system.so.1.49.0 -> libboost_system.so.1.49.0
libboost_iostreams.so.1.48.0 -> libboost_iostreams.so.1.48.0
libboost_mpi_python-py32.so.1.49.0 ->
libboost_mpi_python-py32.so.1.49.0
libboost_regex.so.1.49.0 -> libboost_regex.so.1.49.0
libboost_mpi_python-py26.so.1.49.0 ->
libboost_mpi_python-py26.so.1.49.0
libboost_program_options.so.1.49.0 ->
libboost_program_options.so.1.49.0
Interpretieren kann ich es nicht, da muss leider jemand mit mehr als
meinem Basiswissen ran, sorry. Ich bin gerne bereit, noch weiterenfos zu
liefern, aber dann muss mir bitte jemand sagen, welche Befehle ich
eintippen soll ...
Ich habe noch 'ne Frage zum NetIO. Wie kann ich die Netzwerkadresse und
die MAC-Adresse ändern ? Ich habe das Hexfile auf den ATMega644
gebrannt. So, wie es im Wiki steht, kann es doch aber nur gehen, wenn
mein Netz 192.168.0.xxx wäre - ist es aber nicht, sondern
192.168.178.xxx, mit netmask 255.255.255.0
Über den seriellen Port des NetIO draufzugehen geht bei mir nicht, weil
keine COM - Ports, nur USB :-(
Nochmal danke an alle und viele Grüße
Joshi
Joshi schrieb:> mein Netz 192.168.0.xxx wäre - ist es aber nicht, sondern> 192.168.178.xxx, mit netmask 255.255.255.0
Mal die IP auf Deinem PC in 192.168.0.1 ändern, dann mit:
http://192.168.0.0/ecmd?mac „neue MAC“ (Aufkleber ATMega32)
http://192.168.0.0/ecmd?ip „neue IP“ (z.B. 192.168.178.200)
(vgl. WIKI)
Dann PC-IP wieder ändern, wie gehabt.
Dein gcc hatte ja mit:
main.cpp:(.text.startup+0x360): undefined reference to
`boost::thread::~thread()'
eine fehlende libboost_thread.so.xxx angemeckert.
Ich tippe mal auf unerfüllte Abhängigkeiten bei libboost1.50.
Da ist jetzt, nachdem Du auf 1.49 umgestellt hast, natürlich nichts mehr
zu sehen. 8)
Egal, hauptsache es funzt jetzt! :)
Gruß
Karl M.
Danke für die schnelle Antwort. Auf die Idee, den NetIO direkt an den PC
zu klemmen, bin ich nicht gekommen. Ich wollte ihn auf den Switch (der
seinerseits am DSL-Router hängt und massig freie Ports hat) schalten ...
Klar, so gehts ! Manchmal sieht man den Wald vor Switches ;-) nicht
Danke und noch einen schönen Abend
Joshi
Hallo!
Darf ich nochmal meine Frage stellen?
Mal was anderes: kann ich per FHEM die mit Hm-Tc gemessene
Raumtemperatur an den EMS Bus senden? Wenn ja - wie?
Wer kann helfen?
Also, wenn ich die Temperatur mittels Homematic hm-tc gemessen und in
fhem geholt habe, dann möchte ich einen hk2 aufbauen, der über diese
Temperatur gesteuert wird. Ich finde aber in all den Telegrammen den
Punkt nicht, wo ich eine ist-Temperatur per telnet:7777 an den
collectord senden kann, um das Vorhandensein eines RC35 Raumcontrollers
zu simulieren...
Bin ich gedanklich völlig daneben oder müsste das irgendwie gehen?
Ziel soll es sein, die Fußbodenheizung im Erdgeschoss als Heizkreis 2
von der sonstigen Heizung abzukoppeln und die Umwälzpumpe über einen
MM10 zu steuern. Dazu kann ich jetzt entweder die vorhandene Steuerung
von Homematic verwenden oder muss eine Neuanschaffung tätigen, die nicht
ins Schalterprogramm passt...
Guten Abend,
ich habe mir eben mal die Graphen angesehen und habe das Problem, dass
der Brenner mit dem Heizungsgraphen nicht stimmt. Der Brenner hat
teilweise negative Werte. Hat jemand eine Idee woran das liegen könnte,
oder wie man zumindest den Graph so begrenz bekommt, dass man nur 0-120%
sieht?
Gruss
Norbert
Habe soetwas bei mir (EMS-Gateway) auch ab und zu mal festgestellt.
Bei mir tritt das aber sporadisch auf und nicht in so regelmäßigen
Abständen.
Bei mir waren es fehlerhafte Telegramme. Sieht so aus als ob es immer
Bei der Pumpenmodulation auftritt.
Kannst Du bei diesen Telegrammen die Prüfsumme kontrollieren?
Gruß
Ingo
Kann er nicht, da der NetIO schon die Prüfsumme kontrolliert und das
Telegramm verwirft, wenn sie nicht stimmt.
Was genau heißt denn 'fehlerhafte Telegramme' bei dir?
Danny Baumann schrieb:> Kann er nicht, da der NetIO schon die Prüfsumme kontrolliert und> das Telegramm verwirft, wenn sie nicht stimmt.>> Was genau heißt denn 'fehlerhafte Telegramme' bei dir?
Bei mir sind es ab und zu telegramme mit fehlerhafter Prüfsumme schon
auf dem Ems–bus gewesen...
Norbert Schnitzler schrieb:>> ... Der Brenner hat teilweise negative Werte. Hat jemand eine Idee woran> das liegen könnte ...
Nabend,
sieht evtl. nach einem Wertebereich Problem aus. Möglicherweise wird die
Brennerleistung als 8 Bit Signed Integer verarbeitet, da wird dann halt
alles ab 127 negativ.
//Niffko
Niffko _ schrieb:> sieht evtl. nach einem Wertebereich Problem aus. Möglicherweise wird die> Brennerleistung als 8 Bit Signed Integer verarbeitet, da wird dann halt> alles ab 127 negativ.
Mein Code verarbeitet alles als signed int. Das sollte aber kein Problem
sein, da 100% ja deutlich kleiner als 127 ist ;) Es wird übrigens erst
ab 129 negativ, da 128 'nicht verfügbar' ist (..., 126, 127, NA, -127,
-126, ...).
Danny Baumann schrieb:> Mein Code verarbeitet alles als signed int. Das sollte aber kein Problem> sein, da 100% ja deutlich kleiner als 127 ist ;)
Hi Danny,
es gibt Geräte, die mit einem sogenannten Warmwasserboost arbeiten, d.h.
es wird im WW-Betrieb >100% angezeigt. Die WW-Mehrleistung liegt dann
auch durchaus in dem kritischen Wertebereich, über den wir hier reden.
Tja, der Teufel ist ein Eichhörnchen ... ;)
//Niffko
Hmm, ok. Das heißt also, dass die Brenner modulation als unsigned
aufzufassen ist - gilt das sowohl für Ist- als auch Soll-Modulation? Und
ich gehe mal davon aus, dass es in diesem Fall keinen speziellen Wert
für 'nicht verfügbar' gibt, oder?
Hi,
Niffko _ schrieb:> Das Gerät mit dem größten Boost Anteil dürfte derzeit der GB162-25 T40S> sein: Heizleistung 25kW, WW-Leistung 33kW.
Kann ich bestätigen. Habe das obige Gerät. Bei WW-Bereitung geht
"SensorMaxLeistung" auf -114%.
Hat mich nie gestört, da ich die MaxLeistung nicht visualisiere. ;)
Gruß
Karl M.
niffko schrieb:> "Systemdruck" könnte über 12,7bar auch negativ werden ;)
Also Laut der KM200 die ich parallel Abfrage habe ich einen Systemdruck
von 25.5 Bar?!? (/heatSources/systemPressure)
Der Collector zeigt mir -0,1 Bar an...
Ich habe aber auch eine RC300 in meiner GB172-14
...
Ach und komischerweise kann ich mit dem gefixten collectord nicht mehr
auf das WebInterface zugreifen:
FATAL: Keine Verbindung zum EMS-Bus! Grund: Connection refused
Habe den Dienst beendet und neu gestartet. Wenn ich ihn manuell per
Shell starte habe ich keine Probleme und bekomme die Telegramme
angezeigt...
Grüße,
Niffko _ schrieb:> Der GB172 hat keinen Drucksensor, daher 8Bit Maximum -> 255.>> In dem Fall macht es dann doch Sinn, den Parser zu korrigieren.
D.h. bei den unsigned-Werten ist 0xff die Repräsentation von 'nicht
verfügbar'? Das kann ich natürlich auch noch einbauen...
So mein EMS-Platinchen läuft auch.
Habe mir eine einseitige Platine mit dem ATmega644,
Spannungsaufbereitung, dem ENC28J60 Netzwerkbrimborium und der Schaltung
von Niffko gemacht.
Die EMS-RX LED blitzt so 1-2 mal die Minute auf. Schaltung ist mehrfach
kontrolliert, stimmt mit dem Layout überein.
Falls jemand das Layout will kann ichs hier reinstellen. Platine ist
einseitig und nicht zu filigran, kann man also in der heimischen
Hexenküche herstellen (ging bei mir auch).
Nur die Software bekomm ich nicht zum laufen:
Zur Konfig:
Der Raspi läuft unter Wheezy, alle pakete aktuell.
Anbindung ans Heimnetz über Wlan-Stick, feste IP-Adresse (192.168.0.12)
Anbindung der ethersex-Platine über Kabelnetzwerk direkt auf den Raspi,
auch feste IP-Adresse (192.168.0.8)
Netzwerkbrücke mit einem Wlan geht ja leider mit der aktuellen Distri
nicht mehr, wurde aus dem Kerne entfernt.
Trage ich in der ems-collector (die Config-Datei unter /etc/default/ als
IP die 192.168.0.12 ein bekomme ich ein Connection Refused. Trage ich
die 192.168.0.8 ein bekomme ich ein "Host not found (authoritative)"
Eine Feste Kabelgebundene Anbindung kann ich dme Raspi leider nicht
spendieren sind etliche Wände im Weg, Kabelverlegung nicht möglich. Ich
bin also auf Wlan angewiesen.
Was Kann ich tun um das ganze zum laufen zu bekommen?
Grüße
Markus
Hallo Markus,
> Das Ethersex-Board hat die IP 192.168.0.10
"connection refused" kann auf einen belegten Port oder eine falsche oder
unbekannte IP hinweisen.
Versuche doch mal von der Konsole ein:
collectord -u "db_user" -p "password" tcp:192.168.0.10:7950
Hast Du mal probiert, was der httpd Deiner EMS-Platine zu sagen hat:
192.168.0.10
Falls es da auch ein "connection refused" gibt, tippe ich auf Probleme
im Bereich des ENC28J60.
hth
Karl M.
Hallo,
der httpd funktioniert. Stecke ich die ethersex platine an einen switch
an kann ich über die ip darauf zugreifen und sehe die startseite
"ethersex rulez". Der ENC schein also ok zu sein.
ich habe den befehl welchen du oben geschrieben hast eingegeben. es
passiert beim drücken auf enter nichts, kommt auch keine fehlermeldung.
ist das gut oder schlecht?
Hi,
> Der ENC schein also ok zu sein.
das ist auch gut so. ;)
> passiert beim drücken auf enter nichts, kommt auch keine fehlermeldung
auf der console des raspi?
irgendetwas muss er sagen. :)
evtl. mysql checken:
db_user angelegt, rechte eingetragen, passwort vergeben?
hth
@charlie-w
Datenbankuser und Pass habe ich in den Befehl eingetragen. Sollte auch
soweit stimmen User ist ems, Pass ist buderus. Drücke ich dann enter
springt die bash in die nächste zeile und erwartet eingaben. Mehr
passiert nicht...
Ich schau in der mysql Database noch mal nach ob da alles stimmt...
Hab grade noch mal Probiert, allerdings den collectord aufruf mit -f -d
all erweitert
da bekomme ich "Error: no route to host". Was bedeutet das?
Mysql bin ich grade dran, da ich noch nicht viel mit mysql gearbeitet
habe ist das aber recht schwer für mich. Ich fress mich grade durchs
Manual durch... Kann also etwas dauern. Die Datenbank ems_data ist auf
jeden fall da, der benutzer ems hat alle rechte daran. Nur ist in der
Datenbank nix drin. Wenn ich mit dem Select-Befehl den inhalt haben will
bekomme ich ein "no tables used" angezeigt. Sollte der collectord da
nicht die ganzen Sachen anlegen nach dem ersten start?
Markus schrieb:> Die EMS-RX LED blitzt so 1-2 mal die Minute auf.
Ich bin jetzt nicht mit ethersex unterwegs, aber nach kurzem Überfliegen
von Dannys ethersex-framer code, würde ich sagen, dass die RX-LED bei
jedem korrekt empfangenen EMS-Telegramm blinkt.
Wenn das so ist, dann sind "1-2 mal die Minute" zu wenig. Das 0x18er
z.B. kommt schon alle 10 Sekunden.
//Niffko
Oh das klingt nicht gut... Dann werde ich die Schaltung der
EMS-Pegelwandlung noch mal ganz genau Kontrollieren.
Bei der Heizung handelt es sich übrigends um eine mit einem RC300 Modul
drin, habe nachgesehen.
In der EMS-Schaltung habe ich für den 10uF Kondensator einen Kerko
eingesetzt. Oder muss das unbedingt ein Elko sein? Könnte das das
Problem erklären?
Hallo
Ich bin dabei dieses Projekt nachzubauen. Habe jetzt das Problem den
collectord auf meinem Raspberry zu laufen zubekommen.Es währe schön wenn
jemand mir eine Schritt für Schritt anleitung geben könnte.
Meine nächste Frage währe ob die grüne LED der Adapterplatine auch
blinken sollte wenn nur der Net-io dran hängt also ohne Raspberry.
Vielen Dank
Stephan
PS. Super Projekt genau das was ich gesucht habe. Echt tolle Arbeit.
Danke für die schnelle Antwort. Das habe ich schon probiert kann aber
den collectord nicht starten. Ich probiere es grad nochmal aus und melde
mich dann nochmal mit der Fehlermeldung.
Danke
Stephan
Ich habe jetzt versucht den collectord zu installieren. Bekomme aber
eine Fehler meldung beim eingeben von : collectord -h
Fehlermeldung : -bash: collectord: Kommando nicht gefunden.
Stephan
Hallo Stephan,
die meisten Anleitungen setzen einige Grundkenntnisse über Linux voraus.
Da ich nicht sehr oft mit Linux arbeite, musste ich mich auch erst mal
"durchkämpfen".
Also erst solltest Du mal sicher stellen, dass Du im richtigen
Verzeichnis bist. Nach login mittels terminal (z. B. putty) befindet man
sich i. d. R. im home-Verseichnis des Benutzers.
pwd gibt an, in welchem Verzeichnis Du gerade bist. Dann in das
Verzeichnis des EMS-Collector wechseln
Die nächste Hürde ist das Ausführen der Datei: collectord wird dabei
nicht gefunden...
probiere mal:
./collectord
(Optionen und Parameter natürlich nicht vergessen;)
Gruß
Fabian
Hallo zusammen,
ich verfolge den Thread schon einige Zeit.
Den Adapter habe ich nachgebaut und nach einigen Schwierigkeiten mit dem
Ethersex Hexfile aus dem Wiki zum Laufen gebracht.
Ich habe UBA4, BC25, RC300 und SM100 und KM200 am EMS+ Bus.
Leider hat der Adapter nach ca. 3 Wochen die Funktion eingestellt.
Es kommen keine Daten, meistens antwortet das NETIO mit "connection
blocked" und die gelbe LED blinkt nicht mehr.
Hat jemand einen Tip, wo ich anfangen soll, den Fehler zu suchen?
Ich hatte schon ein paar Daten auf dem EMS+ entschlüsselt und wollte
weitersuchen indem ich über den KM200 gezielt Daten abfrage.
Leider stehe ich jetzt wieder (fast) am Anfang.
Grüße, Torsten
Hallo,
vielleicht kann jemand von euch hier besser weiterhelfen... Dort hat
jemand wohl Probleme mit der Adapterplatine vom NetIO.
Beitrag "EMS-NetIO not running"
Hi Torsten,
check noch mal deine Platine - kalte Lötstellen o.ä.
Verbindungen alle sauber gesteckt/verschraubt?
Alles stromlos gemacht?
So die Klassiker halt.
Ich habe auf den Punkt genau dein Setup was die Anlage betrifft ;-)
Läuft seit einigen Monaten ohne Probleme...
Gruß
Hallo,
ich habe das Projekt verfolgt und auch nachgebaut:
Heizung ist die GB172 mit RC300, d.h. ich erwarte, das nicht alle Daten
erkannt werden, da ein EMS+ Anteil dabei sein wird.
An der Heizung ist ein NetIO mit der Anpassungsschaltung auf
Lochrasterplatine. Das scheint auch zu funktionieren. Den Collector
möchte ich auf einem Cubietruck laufen lassen, habe es aber auch auf
meinem Raspberry PI getestet. Aber ich habe jetzt auf beiden Rechnern
folgendes Problem: Wenn ich den Collector mit der Option -f und -d all
starte kommen vernünftige Ausgaben, bis zur ersten Prozentangabe, dann
bricht das Programm ab:
terminate called after throwing an instance of 'boost::bad_get'
30
what(): boost::bad_get: failed value get using boost::get
31
Aborted
Da ich nicht so firm in C++ bin und auch das Collectorprogramm nicht
wirklich durchschaue, hat jemend eine Ahnung was hier los ist? übrigens
ist das Verhalten auf Cubietruck und PI exakt gleich.
Gruß
Heiner
Hallo zusammen,
Erst einmal ein fettes Danke an alle Beteiligten für die bisherige
Arbeit.
Habe die Platine vorhin zusammen gebaut und soeben an meine GB172 mit
RC200 angeschlossen. Was soll ich sagen? Es kamen sofort Daten auf die
Status Seite :) Heiners Problem kann ich dennoch hier reproduzieren:
DATA: Wärmetauscher-Isttemperatur = nicht verfügbar
5
DATA: Abgas-Isttemperatur = nicht verfügbar
6
DATA: Kesselpumpe-Istwert Modulation = 10 %
7
terminate called after throwing an instance of 'boost::bad_get'
8
what(): boost::bad_get: failed value get using boost::get
9
Abgebrochen
Danach beendet sich collectord. Die Version von Moosy läuft hingegen.
Leider scheinen noch Daten wie z.b. Raumtemp ist/soll und Brennerstarts
und Laufzeit zu fehlen. Weiss vielleicht jemand wie ich diese Daten noch
anzeigen lassen kann?
Ich denke mal, der Fehler hängt mit den letzten beiden Commits zusammen,
die Danny gemacht hat (Stichwort: unsigned Int). Habe schon mal über den
Code geschaut, aber C++ ist nicht so meins.
Danny?!
//Niffko
Ok, funktioniert jetzt, Danke.
Allerdings fehlen mir leider noch Daten, siehe angehängtes Bild.
Primär: Brennerstarts, -Laufzeit und Raumtemp.
Hat vielleicht jemand eine Idee woran das liegen könnte?
Hallo,
ich habe mir einen Atmega1284p für den AVR-Net-IO gekauft. Kann ich die
gleichen Fuse Einstellungen wie für den 644p verwenden?
Fuse Low Byte (FLB) = e7
Fuse High Byte (FHB) = dc
Extended Fuse Byte (EFB) = ff
Danke!
Ok, habe ein bissel gesucht.
Es kommen keine Daten der Sensoren 19 und 20 in die Datenbank. Daten von
19 oder 20 kann ich aber über telnet 7778 sehen. Irgendwie schreibt
collectord diese beiden Werte nicht in die Datenbank. Wenn ich "händig"
Werte in die Datenbank schreibe, klappt auch die Anzeige mit diesen
Werten.
Raumtemp habe ich über Telnet auch nicht gefunden.
Zu meiner Konfiguration: GW172 + RC200 (kein RC35).
Dementsprechend sehe ich auch keine Telegramme von 0x10. Nur von 0x8 und
0x18.
Ich glaube letzteres müsste RC200 sein?
Frank S. schrieb:> Ok, habe ein bissel gesucht.> Es kommen keine Daten der Sensoren 19 und 20 in die Datenbank. Daten von> 19 oder 20 kann ich aber über telnet 7778 sehen. Irgendwie schreibt> collectord diese beiden Werte nicht in die Datenbank. Wenn ich "händig"> Werte in die Datenbank schreibe, klappt auch die Anzeige mit diesen> Werten.
Danke für das Debugging - der Moosy hat's kaputt gemacht ;-)
Schau mal, ob es jetzt funktioniert.
> Raumtemp habe ich über Telnet auch nicht gefunden.> Zu meiner Konfiguration: GW172 + RC200 (kein RC35).
Das erklärt die fehlende Raumtemperatur, die wird vom RC3x gemessen.
> Dementsprechend sehe ich auch keine Telegramme von 0x10. Nur von 0x8 und> 0x18.> Ich glaube letzteres müsste RC200 sein?
Davon gehe ich mal aus, zumindest ist mir die Adresse bislang nicht
anderweitig bekannt.
Prima, Danke. Die Anzeige der Brennerstarts und Zeit funktioniert jetzt.
Nunja, da bei mir der RC200 die Raumtemp misst und ich mir deswegen
nicht extra ein RC35 kaufen möchte, muss ich wohl hier ein bissel
forschen...
Leider sind die Ausgaben wohl eher EMS-Plus wie es bisher aussieht.
Moin zusammen,
ich will mir demnächst auch den EMS Adapter inklusive NetIO aufbauen.
Ein Raspi mit FHEM ist schon in Betrieb.
Bezüglich der Spannungsversorgung habe ich noch eine Frage:
Der NetIO soll laut Anleitung über ein 5V/1A Schaltnetzteil an Pin J6
angeschlossen werden.
Was ist mit dem EMS Adapter? Wird dieser über die EXT Klemme des NetIO
mit versorgt, oder benötigt er eine separate Versorgung über die
2-polige Anschlussklemme?
Danke und Gruß,
Ulf
Ah, jetzt hab ichs verstanden. Die 2-polige Klemme ist für den EMS und
die 3-polige für den optionalen 1-Wire Anschluss.
Danke Karl.
Ich melde mich dann wieder wenns läuft (und andernfalls wahrscheinlich
auch ;-) )
Hallo,
hat jemand eine Eagel-Board-Vorlage von Niffkos Schaltplan für mich und
kann mir die zur Verfügung stellen. Würde mir gerne am Wochenenden ein
Board ätzen.
Danke Mirko
Maciej Piliński schrieb:> Ich entwarf und erbaut Platinnen von Igor F. Diagramm> (http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io).
Das Layout ist allerdings nicht von mir. Glaube es war von Niffko.
Danke dass Du Dir die Mühe gemacht hast. Kann ich den auch in den
Download vom Wiki packen?
Edit:
Ups... Der Beitrag ist ja schon etwas älter.... Habe ich erst durch die
Änderung im Wiki mitbekommen...
So, das Gateway ist aufgebaut. Ich bekomme aber immer ein "FATAL: Keine
Verbindung zum EMS-Bus! Grund: Connection refused" kann mir jemand ein
HEX-File für den 1284P schicken?
Gruß
Mirko
Mirko Rüther schrieb:> So, das Gateway ist aufgebaut. Ich bekomme aber immer ein "FATAL: Keine> Verbindung zum EMS-Bus! Grund: Connection refused" kann mir jemand ein> HEX-File für den 1284P schicken?>
Habe das ganze jetzt mit dem 644p am laufen.
Jetzt verwirren mich die ems-stats:
Bytes total:61653
Bytes good:219
Bytes dropped:0
Packets good:53
Packets bad:2512
Packets 1byte:234 0
Packets ack:0 nack:0
Overflow:1793
Max fill:4
Wo kann der Fehler liegen? So viele Packets bad können doch nicht normal
sein.
Gruß
Mirko
Hallo,
bin vor einigen Tagen auf dieses Projekt gestoßen und seitdem versuche
ich es für mich umzusetzen.
bisher habe ich:
- NetIO zusammengebaut
- NetIO gestestet -> OK
- 644P eingebaut und geflasht
- Die Fuse vom 644P sind -> OK
- IP Mac GW! vergeben <- so geht's auch über Powerlan ;-)
- Ethersex Webserver geht auf
- EMS-NetIO-Adapter auf Lochraster aufgebaut (fehlende Brücke
berücksichtigt)
- 1-Wire Sensor am EMS-NetIO-Adapter -> OK
- mySql gedönze auf Raspi installiert
- EMS-NetIO-Adapter an der RC-Buchse meines Buderus G135 mit BC10 und
RC30 angeschlossen.
- collector mit Make kompiliert
- collectord gestartet
Ich bekomme leider keine Telegramme und auch die Led's auf dem
EMS-NetIO-Adapter blitzen nicht auf.
Den Aufbau des EMS-NetIO-Adapter habe ich schon x-mal überprüft, ohne
einen Fehler gefunden zu haben, was aber nichts heisen mag. :-p
Leuchten die Led's sofort auf wenn die Strecke EMS > Adapter > NetIO
aufgebaut wurde oder erst wenn der collectord auf dem Raspi fehlerfrei
läuft?
Grüße
Martin
Hallo Martin,
Martin Berger schrieb:> Led's auf dem EMS-NetIO-Adapter blitzen nicht
Das sollten die aber! Die Led-Blinzelei hat Danny im Ethersex versteckt.
10-pol Stecker korrekt?
Spannung am Adapter?
Wie hoch ist der Ruhestrom zwichen NetIO und Adapter?
Adapter noch mal checken!
Der NetIO scheint ja zu laufen.
Danke für den Hinweis mit dem GW! Hatte ich doch glatt unterschlagen.
;-)
Gutes Gelingen und Gruß
Karl M.
Habe mir mal das Layout der Leiterplatte von Maciej Piliński angeschaut.
Laut Schaltplan kommt der IC weder mit Masse, noch mit +5V direkt in
Verbindung. Auf der Leiterplatte liegen aber sowohl Masse als auch 5+V
am IC an. Da ist was schief gelaufen glaube ich.
Ah... 4 ist Masse und 8 ist +5V....
Sorry bin Anfänger. ;)
aber das im markierten Kreis sieht doch aber aus, als wenn Masse und +5V
zusammenkommen? Ich glaube, ich muss das mal messen.
Das ist ein größeres Problem...
Habe mir die Datei angesehen und musste feststellen dass alle Polygone
im GND Layer sind habe mal bei mir das "+5V"-Netz und die Polygone
hervorgehoben.
Hoffentlich klappt es noch an den Stellen die Polygone frei zu
schneiden...
Hi Karl, vielen Dank für deine Unterstützung. ;-)
Karl M. schrieb:
>Das sollten die aber! Die Led-Blinzelei hat Danny im Ethersex versteckt.>10-pol Stecker korrekt?>Spannung am Adapter?>Wie hoch ist der Ruhestrom zwichen NetIO und Adapter?>Adapter noch mal checken!
- 10-pol Stecker -> OK, habe die Verbindung bis zum 644p durchgemessen.
:-o
- Spannung am Adapter -> 5V -> OK
- Ruhestrom zwischen NetIO und Adapter -> 2,4mA
- Aufbau 3 weitere male überprüft. :-(
- Spannung am EMS-Bus 12,4V
Bei dem Lochrasteraufbau hier aus dem Forum und im Wiki sind übrigens
Comperator A mit B mit dem Schaltplan vertauscht, da sie "Pin"
Kompatibel sind, ist es egal.
Habe mir jetzt ein Oszi von der Firma ausgeliehen.
An den - und + Eingänge des RX Comperators sehe ich die EMS Burst
ankommen, der Pegel wird dabei allerdings nur um ca: 5 Volt gesenkt, ist
das Normal? Der Ausgang des Comperators liegt permanent auf GND sobald
ich das EMS Kabel anschließe, ohne EMS ist der Pegel bei +5V. Den LM393
habe ich schon gewechselt, das einzigste was ich nicht messen (mangels
Messgerät) kann, sind die Kapazitäten. Der 1nF ist ein Kerko und 10uF
ist ein BiPolar, das sind meine Favoriten das der Aufbau nicht
funktioniert. :-(
Grüße
Martin
Ich bastle momentan an einer Lösung, bei der das NETIO Modul vollständig
durch ein ESP8266 (momentan -01, später -012er) ersetzt wird.
Lesender Betrieb vom EMS-Bus läuft bereits - dank einer 128-Byte FIFO
und
einer sauberen BRK-Erkennung in der Hardware war dies trotz mangelnder
Doku relativ einfach umzusetzen. Hier mal ein kleiner Auszug aus den
empfangenen Daten ([timestamp, statusreg, fifolänge] <emsdaten> CRC)
Momentan gibt es ab und an noch kleine Fehler, hauptsächlich bei den
Poll-Requests. Die Ursache hierfür ist mit hoher Wahrscheinlichkeit eine
zu hochohmige Verbindung zwischem dem LM339 und dem Rx-Eingang des ESP,
bei dem das Signal nicht sauber bis auf GND gezogen wird.
Interessanterweise tritt dieses Problem nur bei "Poll-Requests" auf dem
EMS-Bus auf (Bsp: 90 00 10 39 - Break nicht sauber erkannt).
Für das weiter Vorgehen fehlt mir noch die Information, wie NETIO und
collectord zusammenspielen.
Arbeitet das NETIO-Modul als TCP client Richtung collectord? Wenn ja,
welcher Port wird dann für die Telegramme verwendet?
Falls NETIO als Server/Listener arbeitet bräuchte ich noch ein wenig
Info zum verwendeten Protokoll zwischen collectord und NETIO.
Juergen O. schrieb:> Für das weiter Vorgehen fehlt mir noch die Information, wie NETIO und> collectord zusammenspielen.> Arbeitet das NETIO-Modul als TCP client Richtung collectord? Wenn ja,> welcher Port wird dann für die Telegramme verwendet?> Falls NETIO als Server/Listener arbeitet bräuchte ich noch ein wenig> Info zum verwendeten Protokoll zwischen collectord und NETIO.
Das NETIO ist der Server, collectord der Client. Die empfangenen
Telegramme sendet der NETIO in diesem Format:
<0xaa> <0x55> <length> <data0> ... <dataX> <csum>
csum ist dabei ein running XOR über alle Datenbytes. Diese
Checksummen-Prüfung wäre zwar bei TCP nicht nötig gewesen, ich wollte
aber das Protokoll der seriellen Übertragung (frühere Variante mit
Atmega8) und der TCP-Übertragung gleich halten. Die Datenbytes sind das
komplette EMS-Telegramm, d.h. <source> <dest> <type> usw., allerdings
ohne EMS-Prüfsumme, denn die wird vom NETIO überprüft.
Gesendet werden die Telegramme im EMS-Format ohne Angabe der
Quelladresse und EMS-Prüfsumme (beides fügt der NETIO hinzu).
Ok - stark abstrahiert also auf der NETIO-Seite
wait_for_connection()
while connected()
if (ems_rx_full) // EMS liefert Daten
tcp_send_pkg() // Daten an Collectord
if (tcp_rx_full) // collectord liefert Paket
ems_send_pkg() // Paket an EMS senden
end_while
Ich nehme an, das alle Daten (auch die Poll-Requests) gesendet werden
und der collectod selbst die Connection neu aufbaut, sofern diese mal
einschlafen sollte...
Nachtrag:
wie wird das Polling der eigenen Adresse (0x8b) gehandhabt?
Durchreichen und bearbeiten durch den collectord oder "shortcut", d.h.
NETIO antworted mit "nichts zu senden" (0x0b)?
Juergen O. schrieb:> Ok - stark abstrahiert also auf der NETIO-Seite>> wait_for_connection()> while connected()> if (ems_rx_full) // EMS liefert Daten> tcp_send_pkg() // Daten an Collectord> if (tcp_rx_full) // collectord liefert Paket> ems_send_pkg() // Paket an EMS senden> end_while
Jain. Im Prinzip ist es richtig, allerdings empfängt (und zählt) mein
Ethersex-Code auch dann EMS-Traffic, wenn kein Client verbunden ist.
> Ich nehme an, das alle Daten (auch die Poll-Requests) gesendet werden> und der collectod selbst die Connection neu aufbaut, sofern diese mal> einschlafen sollte...
Ja, der collectord hat einen Watchdog, der die Verbindung bei Bedarf neu
aufbaut. Poll-Requests sendet der NETIO allerdings nicht an den
collectord, sondern nur Pakete mit Nutzdaten.
Juergen O. schrieb:> Nachtrag:> wie wird das Polling der eigenen Adresse (0x8b) gehandhabt?> Durchreichen und bearbeiten durch den collectord oder "shortcut", d.h.> NETIO antworted mit "nichts zu senden" (0x0b)?
Shortcut. Der NETIO antwortet normalerweise mit 0x0b. Wenn er Daten via
TCP empfangen hat, sendet er diese und geht danach zu 0x0b über.
Juergen O. schrieb:> und einer sauberen BRK-Erkennung in der Hardware
Was heisst BRK-Erkennung in der Hardware?
Bedeutet dass das Du auch automatisch das Break über Hardware sendest?
Frage nur weil ich auf dem EMS-Bus Probleme am Anfang hatte. Der PIC
kann auch ein Break durch die Hardware senden. Allerdings gab es dabei
Probleme auf dem EMS-Bus. Weiss nicht mehr genau welches Problem es war.
Klingt aber so ähnlich wie Dein Problem.
Der UART im PIC sendet ein sehr langes Break. Vermutlich um sicher zu
gehen dass es auch bei geringerer Baudrate verstanden wird. Ich habe
damals das Break dann über Software gemacht. Also UART ausschalten und
den Port für die Dauer eines Breaks auf "0" gesetzt und dannach wieder
zurückgesetzt und UART wieder eingeschaltet.
Kann es sein dass das auch bei Dir der Fall sein könnte?
Selbst wenn es das nicht sein sollte würde ich auf jeden Fall darauf
achten dass das Break nur so lange gesendet wird wie es nötig ist (also
10 Bitlängen)
Gruß
Ingo
Juergen O. schrieb:> Ich bastle momentan an einer Lösung, bei der das NETIO Modul vollständig> durch ein ESP8266 (momentan -01, später -012er) ersetzt wird.
... äähhm!
Will ja Euch Fachleuten nicht dazwischen reden, aber wäre es nicht
angebracht, für dieses eigene Thema einen eigenen Thread zu
eröffnen?
Just my 0,02$.
Scheiße ;)
Damit war die Leiterplatte glatt fürn Popo :)
Habs auch erst gecheckt, als ich die 4x910 Widerstände löten wollte und
stellte fest, dass die gar nicht an Masse kommen dürfen aber komplett
auf Masse liegen.
Ich glaube ich mach mir nun meine eigene Leiterplatte.
Da ich die sowieso nicht als shuttle auf das netio schraube,
kann ich etwas "freier" sein.
Also nach dem Spiel ist vor dem Spiel ;)
Ich habe jetzt das Problem das die Raumtemperatur bei Konstant +3200°C
liegt und beim WW-Speicher wechselt die Temperatur zwischen -3200°C und
dem reellem Wert. Bei der Regelführungsgröße wird Raumtemperatur an
stelle der Außentemperatur geführten interpretiert. Soweit ich das jetzt
verstanden habe ist dafür der Collector verantwortlich und müsste
angepasst werden? Ich habe eine RC30 V2.02 sowie BC10 2.0 mit UBA 2.01
sowie das Frontend von Mosi installiert.
Zwei Probleme beim Bau des collectord:
1.boost_thread-mt gibt es bei neuerem Boost nicht mehr
2.Linker commandline versagt bei neueren Linkern (Optimierung)
Ich kann kein Issue in moosy/ems-collector öffnen - deshalb der Fix auf
diesem Weg...
Juergen O. schrieb:> Zwei Probleme beim Bau des collectord:> 1.boost_thread-mt gibt es bei neuerem Boost nicht mehr> 2.Linker commandline versagt bei neueren Linkern (Optimierung)>> Ich kann kein Issue in moosy/ems-collector öffnen - deshalb der Fix auf> diesem Weg...
Wie wär's, wenn du das einzige noch gepflegte Collector-Repo nehmen
würdest? ;)
https://github.com/maniac103/ems-collector
(Da sind, neben anderen Dingen, genau diese beiden Dinge schon gefixt.)
Hallo,
ich bin auch gerade dran mir eine komplette Busplatine zu bauen, also
den EMS-Teil (über kleinen DC/DC-Wandler und zwei 6n137 Optokoppler von
uC-Teil isoliert) und den uC Teil mit einem ATmega644P. Da ich nicht
immer mit dem ICSP Flashen will, spricht was gegen den Einsatz von einen
Bootloader? (Der von Chip45.com ist ganz gut, oder meinetwegen auch der
Bascom-Bootloader) Der erste Hardware-UART ist ja noch frei und kann
somit auf eine Stiftleiste geführt werden. Da kann man dann mit einem
USB-TTL-Wandler (FT232 usw) schnell "Andocken" wenn man das Programm
nach Änderungen neu hochladen will.
LG
Martin
Hallo,
ich habe mir den Net-IO incl. EMS Adapter nachgebaut, mit den Bauteilen
aus dem Warenkorb:
https://secure.reichelt.de/index.html?&ACTION=20&AWKID=1000020&PROVID=2084
Grundsätzlich scheint alles zulaufen jedoch habe ich kaum gute Packete:
http://192.168.178.11/ecmd?ems%20stats
Bytes total:4603
Bytes good:3
Bytes dropped:0
Packets good:3
Packets bad:201
Packets 1byte:16 0
Packets ack:0 nack:0
Overflow:343
Max fill:4
Woran kann das liegen? Wie lang darf/soll die Verbindung Net-IO <-> EMS
Platine sein?
Danke
Stimmen die „Fuses“ des ATmega644P den? Sie sollten ja wie folgt
eingestellt sein: Fuse Low Byte (FLB) = e7, Fuse High Byte (FHB) = dc,
Extended Fuse Byte (EFB) = ff.
Da das Verbindungskabel nicht geschirmt ist sollte es meiner Meinung so
kurz wie möglich sein um nicht als Antenne zu fungieren.
Jochen schrieb:> Wie lang darf/soll die Verbindung Net-IO <-> EMS> Platine sein?
Normalerweise dürfte die Verbindung mit RS232 bei 9600 Baud etwa 150m
lang sein. Dort wird allerdings ein Pegel von +-12 verwendet. Bei der
NetIO-Platine sind 0 bis 5V. Wie lang die Verbindung dabei sein kann ist
mir unbekannt.
Welche Länge hast Du denn bei Deiner Verbindung?
Eventuell könnte es ja auch helfen verdillte Adern zu nehmen. Also ein
Ader RX und GND und die andere Doppelader TX und GND. Ein paar cm
sollten wohl kein Problem sein.
Kann aber durchaus sein dass die Baudratenberechnung etwas "verbogen"
sein. Das sind dann wohl die von Martin genannten Fuses sein.
Hallo,
Ich benutze RC35 zum Kessel verbunden mit RC-Terminal. Wie kann ich die
NETIO Adapter an Kessel? Ist das zu gleichen RC Terminal parallel RC35
angeschlossenen Adapter?
vielen Dank für die Infos ...
Taner A. schrieb:> Hallo,>> Ich benutze RC35 zum Kessel verbunden mit RC-Terminal. Wie kann ich die> NETIO Adapter an Kessel? Ist das zu gleichen RC Terminal parallel RC35> angeschlossenen Adapter?>> vielen Dank für die Infos ...
Hallo,
der Adapter kann parallel an der gleichen Klemme zum RC35 angeschlossen
werden
Liebe EMS-Gateway-Freunde,
zuerst das Positive. Ich habe es als Newbie dank eurer Hilfe geschaft,
den AVR-NETIO mit neuem Chip auszustatten und diesen mit dem HEX-File zu
"brennen". :)
ein "http://meinedomain/ecmd?ems stats" gibt aus:
Bytes total:0
Bytes good:0
Bytes dropped:0
Packets good:0
Packets bad:0
Packets 1byte:0 0
Packets ack:0 nack:0
Overflow:0
Max fill:0
Nun habe ich mir vom angebotenen Schaltplan eine Platine erstellt. den
1wire habe ich ganz weggelassen und den 3-pol EMS-Anschluss zu einem
2-pol geändert. Die bestückte Platine findet Ihr im Anhang.
Die o.g. Freude ist natürlich nur "bedingt", da ich auch die Platine
angeschlossen habe und sie offensichtlich nicht funktioniert.
Da ich den Eagle-Schaltplan genommen habe, schließe ich hier Fehler aus.
Ich würde den Fehler wie folgt eingrenzen:
1. Überprüfung auf Bestückungsverwechlung
2. Überprüfun auf "falsche" Bauteile
Da ich bei Widerständen kein großes "Falschteil-Potential" sehe, vermute
ich Fehler bei Transitor und Kondensatoren. (Bezeichnung ist
Reichelt-Artikelnummer)
Ich habe als Transistor:
T1: BC107B
und als Kondensatoren:
C1: Z5U 100n
C2: KERKO 10n
C3: KERKO 1,5n
C4: X7R-5 1n
C5: TANTAL 10/16 (10µ)
C6: KERKO 68p
Ich hatte noch alternativ einen TON 10/63 für den C6 in der
Bauteileliste. Der erschien mir jedoch zu groß und daher habe ich
"eigenmächtig" den TANTAL genommen.
Kann jemand von Euch einschätzen, ob ich was bei den Bauteilen falsch
gemacht habe?
Vielen Dank für die Hilfe.
Hi,
> ob ich was bei den Bauteilen falsch> gemacht habe?
Platine --> nice!
Nur, anhand des Bildes nicht prüfbar.
*Wusste gar nicht, dass es noch Transis im TO-18 gibt. ;-)*
Denke, dass es nicht die Bauteile sind.
Verdrahtung, Anschlüsse checken!
Spannungen nachmessen!
Fuses?
So das Übliche halt.
Gutes Gelingen und Gruß!
Karl M.
Hallo Karl,
http://meineip/ecmd?fuse gibt aus:
Fuses: low=62 high=99 ex=FF lock=FF
Ist das so ok, oder müssen da andere Werte stehen?
Wenn ja, wie kann ich das ändern?
P.S. Ich tue mich schon schwer, das Datum zu ändern, ist immer noch auf:
Thu 01.01.1970 01:00:15 +1:00
Bisherige Checks:
5V auf Bord von NETIO
Lötstellen
den 10 mü in einen TON Kondensator, aber hat nix gebracht
LG Mirko
Hallo Danny,
auf dem Chip steht:
ATMEGA644
20PU
1310
Ich fürchte das "P" bei 20PU ist nicht das, wonach es aussieht?
Oder anders gesagt, ich habe den Falschen?
LG Mirko
Hallo Danny,
das freut mich!
Da kann es ja sogar sein, dass dann alles funktioniert.
Das macht Hoffnung ;)
So, ATMEGA 644P bestellt...
Ich halte Euch auf dem Laufenden.
Hi Mirko,
> Fuses: low=62 high=99 ex=FF lock=FF
Sollten so aussehen:
Fuses: low=E7 high=DC ex=FF lock=FF
> Wenn ja, wie kann ich das ändern?
Hängt vom Progger ab, wie es mit Ponyprog funzt, findest Du unter [1].
Ansonsten natürlich ertst mal auf den 644P warten. ;-)
hth'n greets
Karl M.
[1] http://www.mikrocontroller.net/articles/Pony-Prog_Tutorial
Hurra, hurra... ich empfange Daten!
Hier nun meine Erkenntnisse, damit auch andere etwas davon haben....
Ja, es lag am ATMEGA644, der ein ATMEGA644P sein muss!
Ein "P" ist hier absolut entscheidend!
Außerdem hatte ich keine Ahnung von FUSES.
Als Hardware für den Brenner nutze ich das Atmel Evaluationsboard von
Pollin. Hier sollte man noch ein serielles Verlängerungskabel bestellen
(Amazon). Das Kabel wird NICHT an die serielle Schnittstelle des
Eval.-Boards angeschlossen, sondern an den ISP-Port. Logisch oder? ;)
Zum brennen des HEX-Files habe ich Ponyprog (Version 2.06g Beta)
benutzt,
Tipps kamen von Karl, der mir diesen Link gab:
Beitrag "AVR 644p wird nicht erkannt"
Die Fuses werden gesetzt, indem man zunächst mit "read" die aktuellen
Werte ausliest und dann die geforderten Hexwerte "E7" und "DC" in
Binärzahlen umrechnet:
hight bit "DC" = 11011100
low bit "E7" = 11100111
und dann jeden Wert INVERTIERT in die angehängten (Bildausschnitt) 2
Zeilen von Ponyprogs/Configuration and Security Bits einträgt also:
nix nix haken nix nix nix haken haken und in der unteren Zeile
nix nix nix haken haken nix nix nix
dann "write" und die Fuses sind richtig gesetzt.
Mein TANTAL 10μ arbeitet einwandfrei, so dass ich denke dass der 10μ
kein fetter TON-Elko sein muss. Ich könnte auf Wunsch also mal eine
aktuelle vollständige Bauteilliste erstellen???
Außerdem habe ich festgestellt, dass man nach setzen einer individuellen
IP, eines Gateways und der MAC-Adresse den Strom vom NET-IO trennen
muss, damit diese Angaben gespeichert werden.
Die Befehle:
http://192.168.0.0/ecmd?ip 10.100.0.222
http://192.168.0.0/ecmd?gw 10.100.0.1
http://192.168.0.0/ecmd?mac 00:23:e8:02:df:a4
wurden zwar mit "ok" bestätigt, aber beim Test
http://192.168.0.0/ecmd?ip erschien wieder die 192.168.0.0
Das kann temporär sein, aber wenn jemand Probleme hat, dann bitte meinen
Tipp mit dem Strom versuchen. ;)
Jetzt ist Zeit DANKE zu sagen. Ich bin totaler Idiot/Laie und habe es
gepackt die ganze Sch... ;) zum Laufen zu bringen - Dank Eurer Hilfe,
besonders danny und frank und im allgemeinen, jeden der hier was
beiträgt!
Coole Sache!
nächste Frage:
Ich habe einen Logamax plus GB172 von Buderus mit einer RC35.
Problem:
--------
Bei Moosys-Webfrontend im Bereich von "Livestatus" erscheinen die
Brennerdaten nur "halbrichtig". Unter anderem:
a) Ich habe definitiv Tagbetrieb/Automatik, er zeigt Nachtbetrieb
manuell.
b) Wenn ich auf Schaltfläche "Automatik" klicke erhalte ich die Meldung
"Befehl 'hkmode auto' ausgeführt.", aber es ändert sich nichts. Ähnlich
auch bei Party- oder Pausenmodus.
Vermutung
---------
Ich muss irgendwo noch einstellen, dass ich ein "plus-Protokoll" habe
Ich muss irgendwo noch einstellen, dass mein Heizungsbauer (seltsamer-
oder vlt. auch richtiger Weise) den 2. Heizkreis als mein "ein und
alles" eingerichtet hat.
Hat jemand mit ähnlicher/selber Technik gleiche Erfahrungen gemacht und
evtl. Lösungen bereit?
Mirko Konrad schrieb:> Vermutung> ---------> Ich muss irgendwo noch einstellen, dass ich ein "plus-Protokoll" habe
Falsch :) Es gibt zwar 'EMS plus', aber RC35 ist definitiv das 'normale'
EMS.
> Ich muss irgendwo noch einstellen, dass mein Heizungsbauer (seltsamer-> oder vlt. auch richtiger Weise) den 2. Heizkreis als mein "ein und> alles" eingerichtet hat.
Bingo. Moosy's Code unterstützt nur HK1. Konfigurierbar ist das
allerdings nicht, nur insofern, dass du den Code durchgreppen und alle
'hk1' durch 'hk2' ersetzen kannst. Das betrifft sowohl
ems-php-webinterface als auch ems-tools. Der ems-collector selbst kann
mit allen möglichen Heizkreisen (1-4) umgehen.
Mirko Konrad schrieb:> (seltsamer- oder vlt. auch richtiger Weise)... 2. Heizkreis ...
Um das herauszufinden, beschreib' mal bitte deine
Heizkreisperipherie(z.B. Pumpe, Mischventil etc.).
//Niffko
wow ... Grafik = nice.
Da dein Heizkreis gemischt ist, geht das mit HK2 in Ordnung. HK1 ist mit
RC35 nur ungemischt konfigurierbar.
Aber da du das Frontend erfolgreich anpassen konntest, ist ja alles im
Lack :)
//Niffko
@Karl, Grafik: CorelDraw von Hand ;)
-------------------------
wieder ein Problem ;)
nachdem ich mit "wget
http://www.mikrocontroller.net/attachment/223645/ems-buderus_0-4.deb";
das Install-Scrippt gedownloadet habe, schlägt der Versuch der
Installation fehl:
dpkg --install ems-buderus_0-4.deb
Vormals nicht ausgewähltes Paket ems-buderus wird gewählt.
(Lese Datenbank ... 68022 Dateien und Verzeichnisse sind derzeit
installiert.)
Entpacken von ems-buderus (aus ems-buderus_0-4.deb) ...
Download der Quellen
Cloning into '/tmp/ems-collector'...
error: server certificate verification failed. CAfile:
/etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing
https://github.com/maniac103/ems-collector.git/info/refs
fatal: HTTP request failed
dpkg: Fehler beim Bearbeiten von ems-buderus_0-4.deb (--install):
Unterprozess neues pre-installation-Skript gab den Fehlerwert 128
zurück
Fehler traten auf beim Bearbeiten von:
ems-buderus_0-4.deb
---------
rufe ich https://github.com/maniac103/ems-collector.git/info/refs
separat auf, erscheint:
Please upgrade your git client.
GitHub.com no longer supports git over dumb-http:
https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days
---------
habe ich irgendetwas vergessen?
PS.:
Vorher ausgeführt:
apt-get install build-essential libboost1.49 -all mysql-server
mysql-client libmysql++ php5-mysql
und
apt-get install git telnet php5 php5-cgi gnuplot
Ohne Fehler....
Mirko Konrad schrieb
> @Karl, Grafik: CorelDraw von Hand ;)
... chapeau!
> wieder ein Problem ;)
git clone git://github.com/maniac103/ems-collector
hth
Ja kann sein das github da einiges geändert hat und es jetzt nicht mehr
rennt.
Da ich aber auch davon ausgehe das einiges behoben wurde an den sourcen
was ich weg gepacht hab macht es kein Sinn daß Paket noch so zu
verwenden.
gibts ne step-by-step-Anleitung für die Installation der Software, also
collectord und moosy?
ah, karl, danke?!
git clone git://github.com/maniac103/ems-collector
Moin und vielen Dank für diese tolle Arbeit hier, nutze eine GB142 mit
RC30.
Habe mit viel Mühe Dannys Code zum Laufen bekommen, mit der Hardware gab
es keine Schwierigkeiten.
Ein Problem ist noch übrig:
Die RAUM-IST-Temperatur wird mit 3200°C angezeigt und zwar sowohl auf
dem Web-Interface als auch im "ems-collector.log".
Gesucht habe ich schon ordentlich, aber jetzt könnte ich einen Tipp
richtig gut gebrauchen.
Danke und Gruß
KHS
khs schrieb:> Die RAUM-IST-Temperatur wird mit 3200°C angezeigt und zwar sowohl auf> dem Web-Interface als auch im "ems-collector.log".>> Gesucht habe ich schon ordentlich, aber jetzt könnte ich einen Tipp> richtig gut gebrauchen.
Kann es sein, dass deine RC30 nicht an einen Heizkreis gebunden ist?
Laut diesen Postings wird die Temperatur genau in diesem Fall als
3200.0°C (0x7d00) übermittelt:
Beitrag "Re: Faktensammlung Buderus EMS"Beitrag "Re: Faktensammlung Buderus EMS"
Das ist ein bekanntes Problem, das ich noch fixen muss. Verloren geht
dir dadurch allerdings nix, die korrekte Anzeige in diesem Fall ist dann
'nicht verfügbar'.
Hi Mirko,
Mirko Konrad schrieb:> Adapterplatine
Sag Mirko, möchtest Du Dein Platinen-Layout hier als Download zur
Verfügung stellen? Würd's dann ins Wiki übernehmen.
Mit dem Layout von Maciej Piliński scheint es ja Probleme zu geben, oder
hat das schon jemand gefixt?
Gruß
Karl M.
Karl M. W. schrieb:> Mit dem Layout von Maciej Piliński scheint es ja Probleme zu geben, oder> hat das schon jemand gefixt?
Denke mal an sich ist das Board auch OK. Zumindest wenn ich die Datei
öffne.
Meine irgendwo mal gelesen zu haben dass es Probleme mit Poligonen im
GND-Poligon gab. Keine Ahnung ob Mirko ausversehen unbemerkt was am
Board geändert hat oder Platinenhersteller da irgendwas "verbrochen"
hat. Vielleicht war es ja auch nur eine "falsche" Eagleversion.
Mirkos Platine im Wiki ist eine gute Idee, wenn Mirko das zur verfügung
stellt. Oder ist das sogar irgendwo schon einem Thread angehangen?
Gruß
Ingo
Moin!
Stimmt; die RC30 steckt direkt im Gehäuse.
Die threads sind schon so lang und so viele, das hab ich überlesen.
Vielleicht ein Punkt; sicher etwas OT:
Ich habe entdeckt, dass das Feld "Zirkulations-Pumpe" manchmal grün
erleuchtet war und habe dann einen Umbau gewagt und die
Zirkulations-Pumpe direkt angeschlossen.
Sie läuft nicht, auch auf "Dauer" geändert, es hat nicht geholfen.
Offenbar zieht das Relais nicht an.
Gibt es noch Bit was zu kippen ist oder einen Schalter, den ich noch
betätigen könnte? Habe gesucht, Dr Goggle hat nichts ausgespuckt ;-)
Danke
KHS
Für die Zirkulationspumpe gibt es auch ein Zeitprogramm.
Wenn das bei Dir eingestellt ist läüft die Zirkulationspumpe auch nur in
bestimmten Zeiten.
Wärend die Zirkulationspumpe "grün" wird sollt auch die echte
Zirkulationspumpe laufen.
Gruß
Ingo
Moin!
Genau so hab ich mir das mit der Zirkulationspumpe auch vorgestellt.
Der Relaistest hat es auch nicht gebracht, das Relais zieht nicht. Werde
morgen noch einmal das Releias für die externe WW-Pumpe ausprobieren.
Wenn das auch nicht schaltet bin ich am Ende meiner Weisheit.
sri for OT
Gruß
Knut
KHS schrieb:> Der Relaistest hat es auch nicht gebracht
Wenn der Relaistest nicht funktioniert, ist entweder die elektr.
Verbindung UBA -> Anschlussplatine gestört oder die Sicherung auf der
Anschlussplatine durch.
Beim Relaistest muss eins der beiden Relais auf der Anschlussplatine
hörbar anziehen. Tut es das und die Pumpe läuft trotzdem nicht ->
Sicherung durch. Zieht das Relais nicht an, ist entweder das Relais
defekt -kommt eigentlich nicht vor- oder es wird nicht durch den UBA
angesteuert.
Letzteres könnte an einem Kontaktfehler am Kontaktfuß des UBA liegen.
Prüfe, ob die untere Dichtlippe des UBA bündig auf dem Gerätechassis
aufliegt und die Befestigungsschraube fest angedreht ist.
Ansonsten UBA mal abbauen und den Kontaktfuß(am Gerät) auf aufgeweitete
oder nach unten geschobene Kelche kontrollieren.
Sollte dies alles nicht fruchten, wird es Zeit den Heizungsbauer deines
Vertrauens einzubeziehen ... oder die Z-Pumpe wieder extern anzusteuern
:)
//Niffko
... oder die Z-Pumpe wieder extern anzusteuern :) Nee!
Der Tipp mit dem Kontaktfehler hat es gebracht! Danke!
Das Problem war ein verschwundener "Kelch", so eine Kabelhülse; sie war
nicht da.
UBA raus, Kabelbaum aufgetüddelt, den Kontakt gerichtet (die Federchen,
die ein zurückschieben verhindern sollen waren komplett verbogen, das
hat noch nie funktioniert).
Nun läuft die Zirkulationspumpe wie gedacht.
Vielen Dank!
Knut
Bernd Gewehr schrieb:> Gibt es hierzu einen Tip?>> pi@raspberrypi /usr/local/bin $ ./calcemsgraphs.sh>> gnuplot> set grid lc rgb '#aaaaaa' lt 1 lw 0,5> ^> line 0: ';' expected>> pi@raspberrypi /usr/local/bin $
Hallo, habe ein ähnliches Problem mit den graphs von Moosys Frontend.
Nachdem ich ./calcemsgraphs.sh manuell ausgeführt habe passiert nichts.
Dann kommt nach etwa 2 bis 3 Minuten der selbe fehler.
es wird nur ein hk.png Diagramm ohne Kurven gezeichnet.
wenn ich mir aber calcemsgraphs.sh ansehen ist das die letzte Grafik die
gezeichnet werden soll.
Wenn ich im Frontend die Schaltzeiten aufrufe wird automatisch die Kurve
der schaltzeiten durch das Frontend erzeugt.
Hat jemand eine Idee was da schief läuft?
Haollo,
inzwischen habe ich soweit alle fehlerhaften configurationen gefunden
und behoben. Das größte Problem war ein vergessenes "d" was mir nie
aufgefallen ist.
Dummerweise ist mein SQL-Datenbank auf einem anderen Server.
In der Install.txt steht geschrieben dass die Datenbank auf dem selben
Server sein soll/muss.
Dachte ich bin einfach so schlau und habe in die 'config.py' den Eintrag
mysql_host = "192.168.1.123:3306" ein.
die config.pyc hatte ich vorher auch mit vi bearbeiteit. Habe aber zum
schluss die Datei mit 'phyton -m compileall .' compilieren lassn.
Allerdings bekomme ich immer die Fehlermeldung dass der
'user'@'localhost' keine Berechtigung hat.
Habe in keinen Dateine ein 'localhost', 'mysql_host' oder '127.0.0.1'
finden können.
Ist das nicht möglich auf einen anderen Server umzubiegen in PHP?
Ist mein Gedankengang falsch oder mache ich irgendwas nicht richtig?
HILFE!
Hallo Ingo,
Ingo F. schrieb:> ...> habe in die 'config.py' den Eintrag> mysql_host = "192.168.1.123:3306"> ...
In meiner config.py finde ich keine "mysql_host" Variable.
Vielmehr wird doch der Socket definiert unter "mysql_socket_path".
Da würde ich mal versuchen anzusetzen.
Soweit mir bekannt, wird die *.pyc beim ersten run automatisch
generiert, muss also nicht extra angelegt werden.
Gruß und gutes Gelingen!
Karl M.
Hallo Karl
Karl M. W. schrieb:> In meiner config.py finde ich keine "mysql_host" Variable.
Das stimmt, war bei mir auch nicht drin. Bei PHP kann diese Variable
gesetzt werden um IP und Port vom Server anzugeben.
Allerdings scheint die irgendwo überschrieben oder geändert zu werden.
Oder die Variable wird in den scripten nicht benutzt.
Habe jetzt mal testweise die MySQL-Datenbank auch umgezogen und es
scheint soweit zu funktionieren. Auf die Dauer sollte aber die Datenbank
wieder auf einen anderen Server.
Habe noch ein paar Probleme dass die Konfiguration der RC30 falsch
angezeigt wird und teilweise Kesseltemperaturen von etwa 2200°C. Denke
das muss ein Fehler sein.
Weiss auch nicht ob das zeichnen der Kurven wirklich 20 bis 30 Sekunden
dauern muss. Außerdem werden beim Zeichnen der Kurven Fehler ausgegeben.
Die scheinen aber für die Kurven unwichtig zu sein.
Gruß
Ingo
Ingo F. schrieb:> gnuplot> set grid lc rgb '#aaaaaa' lt 1 lw 0,5> line 0: ';' expected
So, der Fehler ist gefunden!
Die 0,5 steht für die Lienienbreite. Das Dezimaltrennzeichen ist aber
der Punkt.
Den Fehler sieht man aber normalerweise nicht weil er mit "> /dev/null
2>&1" unterdrückt wird.
Da ich aber noch Probleme mit dem pfad von "mysqld.sock" hatte war die
Unterdrückung testweise herausgenommen.
Gruß
Ingo
Ingo F. schrieb:> Hallo Karl>> Karl M. W. schrieb:>> In meiner config.py finde ich keine "mysql_host" Variable.>> Das stimmt, war bei mir auch nicht drin. Bei PHP kann diese Variable> gesetzt werden um IP und Port vom Server anzugeben.>> Allerdings scheint die irgendwo überschrieben oder geändert zu werden.> Oder die Variable wird in den scripten nicht benutzt.
Naja, das PHP-Skript benutzt die Python-Konfig-Datei nicht ;-)
Wenn man die Variable in config.php schreibt, sollte es allerdings
funktionieren.
> Habe noch ein paar Probleme dass die Konfiguration der RC30 falsch> angezeigt wird und teilweise Kesseltemperaturen von etwa 2200°C. Denke> das muss ein Fehler sein.
Wahrscheinlich schon. Logs wären an der Stelle hilfreich.
> Weiss auch nicht ob das zeichnen der Kurven wirklich 20 bis 30 Sekunden> dauern muss.
Siehe dazu meine Ausführungen hier:
Beitrag "Re: Faktensammlung Buderus EMS"Kay F. schrieb:> gibt es schon einen collector der auch die Solar Daten verarbeitet?> Im Wiki stehen ja schon einige Daten...
Nein. Pull Requests sind aber gerne gesehen ;-)
Ich kann das auch einbauen, allerdings muss mir jemand erzählen, welche
Werte davon relevant sind. Außentemperatur haben wir schon,
Pumpenmodulation und Betriebszeit sind wahrscheinlich relevant, aber was
ist 'Speicherunten'?
Ingo F. schrieb:> Ingo F. schrieb:>> gnuplot> set grid lc rgb '#aaaaaa' lt 1 lw 0,5>> line 0: ';' expected>> So, der Fehler ist gefunden!> Die 0,5 steht für die Lienienbreite. Das Dezimaltrennzeichen ist aber> der Punkt.
Das erinnert mich daran, dass ich dafür schon seit Ewigkeiten einen Pull
Request habe: https://github.com/maniac103/ems-collector/pull/2
Den habe ich bislang nur deshalb nicht gemergt, weil die Readme, die der
PR auch noch mit reinbringt, mir noch nicht ganz gefällt. Ich glaube,
ich werde das einfach mal mergen und fixen.
Danny Baumann schrieb:> Naja, das PHP-Skript benutzt die Python-Konfig-Datei nicht ;-)> Wenn man die Variable in config.php schreibt, sollte es allerdings> funktionieren.
Beim Collector ist das ja auch kein Problem. Habe den Host dort irgendwo
in der Config zusätzlich angegeben.
Das Problem liegt an den Scripts von Moosys Frontend. Schaffe es nicht
dass die sich über den mysqld.sock auf einen anderen MySQL-Server
verbinden.
Die Scripte benutzen ja eigentlich die config-Datei. Aber tritzdem
verscuht er sich immer bei localhost anzumelden.
Mit den 2200 °C muss ich mal bei Zeiten die Telegramme mitloggen die
diese Fehler produzieren...
Gruß
Ingo
Ingo F. schrieb:> Das Problem liegt an den Scripts von Moosys Frontend. Schaffe es nicht> dass die sich über den mysqld.sock auf einen anderen MySQL-Server> verbinden.>> Die Scripte benutzen ja eigentlich die config-Datei. Aber tritzdem> verscuht er sich immer bei localhost anzumelden.
Tun sie, ja. Allerdings verwenden die die config.php, nicht die
config.py. Du hattest nur von letzterer gesprochen, war das ein Typo?
Wenn nein, war das der Fehler...
Danny Baumann schrieb:> Kay F. schrieb:>> gibt es schon einen collector der auch die Solar Daten verarbeitet?>> Im Wiki stehen ja schon einige Daten...>> Nein. Pull Requests sind aber gerne gesehen ;-)> Ich kann das auch einbauen, allerdings muss mir jemand erzählen, welche> Werte davon relevant sind. Außentemperatur haben wir schon,> Pumpenmodulation und Betriebszeit sind wahrscheinlich relevant, aber was> ist 'Speicherunten'?
Hi,
"Speicherunten" ist die Temperatur unten im Warmwasserspeicher. Diese
steigt bei mir wenn die Sonne kräftig scheint ;-)
"Aussentemperatur" ist eventuell die Temperatur im Kollektor selbst, bin
mir aber nicht sicher.
Ich habe das alles momentan noch über die KM200 ins openhab gebracht, da
die Werte ja noch nicht über den EMS-Collector kommen :-)
Hier die Werte von der KM200 für Solar (fast selbst erklärend)
"/solarCircuits/sc1/status" (Active)
"/solarCircuits/sc1/solarYield" (Wh)
"/solarCircuits/sc1/collectorTemperature" (Grad Celsius)
"/solarCircuits/sc1/pumpModulation" (%)
"/solarCircuits/sc1/dhwTankTemperature" (Grad Celsius)
Gruß
Danny Baumann schrieb:> Tun sie, ja. Allerdings verwenden die die config.php, nicht die> config.py. Du hattest nur von letzterer gesprochen, war das ein Typo?
Jain, ich hatte auch die Config.php gemeint:
Ingo F. schrieb:> Trotzdem kam aber die Meldung das 'ems'@'localhost' nicht existiert...> Ohne ":3306" hat es aber auch nicht funktioniert..
In welchem Kontext kommt denn die Meldung? Im Webserver-Log? Oder
woanders?
Danny Baumann schrieb:> In welchem Kontext kommt denn die Meldung? Im Webserver-Log? Oder> woanders?
Da die Grafiken nicht erstellt wurden habe ich in der *calcemsgraphs.sh*
die Umleitung ins Nirva rausgeschmissen. Die Fehlermeldung kommt also im
Linux Terminal.
Dort wurde 30 mal die Meldung ausgeworfen wenn ich mich recht erinnere.
Danny Baumann schrieb:>> Weiss auch nicht ob das zeichnen der Kurven wirklich 20 bis 30 Sekunden>> dauern muss.>> Siehe dazu meine Ausführungen hier:> Beitrag "Re: Faktensammlung Buderus EMS"
Das ist ja nicht das Problem. Die ganzen Grafiken für die verschiedenen
Zeitspannen werden alle innerhalb weniger Sekunden erstellt.
Das Problem ist die letzte Kurve in der *calcemsgraphs.sh*. Dort wird
die Heizkennlinie erstellt. Das sind 7 - 9 Datenwerte. Die Kurve
benötigt 20-30 Sekunden. Allerdings ist dann auch nur Das Diagramm OHNE
Kurven in der PNG-Datei.
Kann diese Datei auch nicht im Fronend öffnen weil meine Heizung wohl
Raumtemperaturgeführt ist.
Ingo F. schrieb:> Das Problem ist die letzte Kurve in der *calcemsgraphs.sh*.
Werden denn die vier Daten-Files erzeugt und ist deren Inhalt sinnvoll?
//Niffko
Wie es aussieht, bekommst du 4 Werte nicht rein ($AT,$RTO,$TT,$TN). In
der Low-Level Funktion, die diese Werte holen soll, habe ich beim groben
Überfliegen ein Timeout von 5 Sekunden gesichtet. Würde passen ...
//Niffko
Hallo Niffko,
Wieso 4 Werte? Wegen der vier Leerzeilen in der *temp.dat*?
Vielleicht ist ja meine RC30 auch defekt. Ich komme nicht mehr in das
Menü für in der auch der Urlaub- und Party-Modus aktiviert werden kann.
Alle Tasten dafür funktionieren. Nur die Kombination der Tasten bringt
mir nicht das Menü.
Oder gibt es irgendwelche Einstellung die dieses Menü deaktivieren?
Niffko _ schrieb:> $AT
seltsamerweise kommt seit gestern keine Außentemperatur mehr rein...
Muss aber nicht das selbe Problem sein. Vorher hat es ja auch so lange
gedauert... Auch als die Außentemperatur noch kam...
Ingo F. schrieb:> Wieso 4 Werte? Wegen der vier Leerzeilen in der *temp.dat*?
Erstens das und wenn man sich die Zwischenwerte $ATT, $BTT, $ATN, $BTN
in den erzeugten Daten-Files anschaut ...
//Niffko
Es sieht so aus, als ob die RC30 manche Werte einfach nicht liefert. $AT
ist die Auslegungstemperatur, die in Telegramm 0x3d an Daten-Offset 36
erwartet wird. Mit meiner RC30 passiert aber nur das hier:
# hole 42 Bytes aus 0x3d
IO: Sending bytes 0x90 0x3d 00 0x2a
# es kommen 27 Bytes zurück
MESSAGE[12.03.2015 09:29:07]: source 0x10, dest 0x0b, type 0x3d, offset
0, data: 0x01 0x14 0x2a 0x22 0x00 0x28 0x00 0x02 0x00 0x05 0x05 0x2d
0x01 0x01 0x04 0x46 0x05 0x41 0x01 0x00 0x3c 0xff 0x11 0x05 0x05 0x00
0x02
# hole die restlichen 15 Bytes
IO: Sending bytes 0x90 0x3d 0x1b 0xf
# es kommen aber nur 5 Byte
MESSAGE[12.03.2015 09:29:07]: source 0x10, dest 0x0b, type 0x3d, offset
27, data: 0x00 0x02 0x0f 0x32 0x0a
# hole die restlichen 10 Bytes
IO: Sending bytes 0x90 0x3d 0x20 0xa
# es ist aber nix mehr vorhanden
MESSAGE[12.03.2015 09:29:08]: source 0x10, dest 0x0b, type 0x3d, offset
32, data:
Das heißt, dass die RC30 einige Werte wie Führungsgröße oder
Auslegungstemperatur nicht liefern kann; zumindest nicht an der Stelle,
an der sie bei der RC35 stehen. Ich meine die Auslegungstemperatur bei
mir an Offset 17 zu sehen (HK1 65°C, HK2 43°C) und die max.
Vorlauftemperatur an Offset 15 (70/47°C). Die Führungsgröße könnte evtl.
an Offset 18 stehen (ich kann das gerade nicht testen, da nicht zu
Hause).
(NB: Offsets 9 bis 12 sehen nach Parametern für die Estrichtrocknung
aus)
Kann das mal bitte jemand, idealerweise auch mit einer RC35,
verifizieren?
Mir ist auch noch nicht ganz klar, wo der Unterschied zwischen 'Heizart'
(Offset 0) und 'Heizsystem' (Offset 32) ist. Niffko, hast du da
vielleicht eine Idee?
$RTO (Raumoffset), $TT (Tagtemperatur) und $TN (Nachttemperatur) sollten
allerdings auch so vorhanden sein (und sind es bei meiner RC30 auch).
Vorlauftemperatur und Auslegungstemperatur scheinen korrekt zu sein; ich
habe Wiki und Collector mal entsprechend aktualisiert. Die Führungsgröße
scheint bei der RC30 implizit bestimmt zu sein (Heizsystem Raumvorlauf
ist raumtemperaturgeführt, ansonsten außentemperaturgeführt).
[Thu Mar 12 20:42:50 2015] [error] [client 192.168.178.23] PHP Notice: ob_flush(): failed to flush buffer. No buffer to flush in /opt/EMS Gateway/ems-tools/includes/emsqry.inc on line 20, referer: http://homeserver/EMS/?seite=a_emslog.php
[Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/aussentemp-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php
16
[Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/raumtemp-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php
17
[Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/brenner-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php
18
[Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/kessel-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php
19
[Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/ww-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php
20
[Thu Mar 12 20:43:16 2015] [error] [client 192.168.178.23] File does not exist: /data/apache/EMS/graphs/pumpen-hour.png, referer: http://homeserver/EMS/?seite=a_emshour.php
Danny Baumann schrieb:> $AT ist die Auslegungstemperatur, die in Telegramm 0x3d an> Daten-Offset 36 erwartet wird.
Das ist die Auslegung spezifisch für Fußbodenheizung und existiert nur
bei RC35. Beim RC30 ist nach Offset 31 Schluss. Bis dahin ist die
Datenzuordnung allerdings identisch.
Danny Baumann schrieb:> Ich meine die Auslegungstemperatur bei mir an Offset 17 zu sehen
korrekt ... ist bei RC30 und RC35 gleich.
Danny Baumann schrieb:> ... Unterschied zwischen 'Heizart' (Offset 0) und 'Heizsystem' (Offset 32) ist.
Hmm ... kann ich mir auch nicht so richtig einen Reim drauf machen.
//Niffko
Niffko _ schrieb:> Das ist die Auslegung spezifisch für Fußbodenheizung und existiert nur> bei RC35. Beim RC30 ist nach Offset 31 Schluss. Bis dahin ist die> Datenzuordnung allerdings identisch.
Weißt du da mehr dazu? Mich würde interessieren, wo der Unterschied
zwischen der 'normalen' Auslegungstemperatur und der für die
Fußbodenheizung liegt.
> Danny Baumann schrieb:>> ... Unterschied zwischen 'Heizart' (Offset 0) und 'Heizsystem' (Offset 32) ist.>> Hmm ... kann ich mir auch nicht so richtig einen Reim drauf machen.
OK, dann werde ich 'Heizsystem' mal rauswerfen.
Noch eine Frage, die damit semi-zusammenhängt und zu der du vielleicht
etwas weißt ;-) : An Offset 33 scheint bei der RC35 die Führungsgröße
(raum- vs. außentemperaturgeführt) zu liegen. Bei der RC30 ist diese
Information - so ist zumindest meine Interpretation - im Heizkreis-Typ
enthalten ('Raumvorlauf'/'Raumleistung' ist raumtemperaturgeführt, die
anderen AT-geführt). Ist diese Interpretation richtig?
Wenn ja: Ist das Verhalten der RC35 an der Stelle rückwärtskompatibel?
In anderen Worten: Wenn ich da raumgeführt einstelle (Offset 33 = 1),
taucht dann automatisch Raumvorlauf als HK-Typ auf (Offset 0 = 4)? Und
funktioniert das dann auch andersherum?
(Ziel der Frage ist, ob ich mir das Parsen der Führungsgröße sparen kann
und sie implizit aus dem HK-Typ ableiten kann. Das wäre sehr hilfreich
im Sinne der RC30-Kompatibilität.)
Danke :-)
Hallo,
ich habe das Problem dass bei der Rücklauftemperatur bei meiner RC30
(EMS-Gateway --> collectord --> Moosys Frontend) in den Grafiken falsche
Werte angezeigt werden.
Hänge mal zwei Grafiken an....
Es scheint drei falsche Werte zu geben:
614,4°C, 2179°C und -2193,2°C
Die Werte haben auch keinen bestimmten Abstand zueinander.
Als ich vorhin einen fehlerhaften Wert (2179°C) hatte tauchten im Log
über die USB-Serial-Verbindung keine aus der Reihe fallenden Werte auf.
Die Temperatur ist gleichmäßig gestiegen. Es scheinen wohl nur alle 75
Sekunden vom Collector in die mySQL geschrieben zu werden.
Der vorherige Wert war 0x01d4 = 46,8 und der Wert danach 0x01E4 = 48,4
°C
Habe dann Zeitlich den Mittelwert genommen. Das war dann 0x01DD = 47,7
°C.
Allerdings taucht der Wert 47,7°C aber in der MySQL-Datenbank auf. Also
kann es nicht der Wert 0x01DD sein.
Habe dann mal die Datenbank nach fehlenden Werten zu durchsuchen:
In diesem Bereich fehlten z.B. folgende Werte (die Zweite Reihe ist die
Differenz zum letzten fehlenden Wert). Da es kein gleicher Abstand ist
wird das wohl Zufall sein.
1
41,3
2
42,5 1,2
3
43,5 1
4
44,5 1
5
45,5 1
6
46,7 1,2
7
48 1,3
8
49,3 1,3
9
50,7 1,4
10
52 1,3
11
54,4 2,4
12
55,2 0,8
13
56 0,8
14
56,8 0,8
15
57,6 0,8
16
58,4 0,8
17
59,2 0,8
18
60 0,8
19
60,3 0,3
20
60,8 0,5
21
61,4 0,6
22
61,5 0,1
vermutlich ist das gleichzeitige mitloggen über den Serial-Port vom
EMS-Gateway den Fehler über den Port 7777 zum collectord keine Hilfe.
Wie kann ich mit dem collector zusätzlich ein Logfile mit allen
Telegrammen aufzeichnen kann. Also alle Telegramme die der collector
bekommt?
Ich habe sonst keine Ahnung woher die falschen Werte kommen...
Denke fehlerhafte CRC werden vom EMS-Gateway und/oder collector
ignoriert, oder?
Jemand eine Idee wie so etwas kommt?
Wer hat ähnliche Probleme?
Gruß
Ingo
Danny Baumann schrieb:> ... Unterschied zwischen der 'normalen' Auslegungstemperatur> und der für die Fußbodenheizung liegt.
Wird bei Heizsystem 'Fußboden' gewählt, wird Auslegung 'Fußboden'
verwendet. Alle anderen Heizsysteme verwenden die Auslegung bei Offset
17.
Danny Baumann schrieb:> OK, dann werde ich 'Heizsystem' mal rauswerfen.
Haaaalt :)
Hab hierzu doch noch was: RC30 stellt Heizsystem nur über Offset 0 ein,
ist klar. Mögliche Auswahl:
1
Offset 0
2
0 - Keines
3
1 - Heizkörper
4
2 - Konvektor
5
3 - Fußboden
6
4 - Raumvorlauf
7
5 - Raumleistung
RC35 schreibt bei Änderung des Heizsystems auf Offset 0 UND Offset 32.
Mögliche Auswahl:
1
Offset 32
2
1 - Heizkörper
3
2 - Konvektor
4
3 - Fußboden
'Raumvorlauf' und 'Raumleistung' fällt bei RC35 weg. Einstellung
Führungsgröße über Offset 33. Mögliche Auswahl:
1
Offset 33
2
0 - außentemp.geführt
3
1 - raumgeführt
Danny Baumann schrieb:> [RC35] Wenn ich da raumgeführt einstelle (Offset 33 = 1),> taucht dann automatisch Raumvorlauf als HK-Typ auf (Offset 0 = 4)? Und> funktioniert das dann auch andersherum?
Nein. Bei RC35 wird auf Offset 0 nur 1,2 oder 3 erscheinen. Ansonsten
ist jedes Heizsystem mit jeder Führungsart kombinierbar.
Danny Baumann schrieb:> Danke :-)
Büdde :-)
//Niffko
Hallo
Ich habe jetzt bis zum Raspberry alles am laufen. Beim aufrufen der
Seiten wird immer nur der Ladebalken angezeigt. Die Seiten Statistik,
Fehlerspeicher und Protokoll werden angezeigt.
Niffko _ schrieb:> Danny Baumann schrieb:>> ... Unterschied zwischen der 'normalen' Auslegungstemperatur>> und der für die Fußbodenheizung liegt.>> Wird bei Heizsystem 'Fußboden' gewählt, wird Auslegung 'Fußboden'> verwendet. Alle anderen Heizsysteme verwenden die Auslegung bei Offset> 17.
Bah, warum machen die denn sowas? Da muss ich mir was einfallen
lassen...spricht etwas dagegen, beim Setzen dieses Wertes einfach den
gleichen Wert an beide Stellen zu schreiben?
> Danny Baumann schrieb:>> OK, dann werde ich 'Heizsystem' mal rauswerfen.> RC35 schreibt bei Änderung des Heizsystems auf Offset 0 UND Offset 32.
Ich hab Heizart trotzdem rausgeschmissen ;-) Ein neuer
Kommandozeilenparameter selektiert zwischen RC30 und RC35; im RC30-Modus
wird Offset 0 ausgewertet und geschrieben; im RC35-Modus ist es Offset
32+33.
Danke aber für die Klarstellung :-) Ich glaube, ich muss mich doch mal
um eine RC35 bemühen (und wenn es nur dafür ist, nicht mehr länger ein
von den rauchenden Vorbesitzern vergilbtes Gerät im Wohnzimmer hängen zu
haben...)
Ingo F. schrieb:> Es scheint drei falsche Werte zu geben:> 614,4°C, 2179°C und -2193,2°C> Die Werte haben auch keinen bestimmten Abstand zueinander.>> Als ich vorhin einen fehlerhaften Wert (2179°C) hatte tauchten im Log> über die USB-Serial-Verbindung keine aus der Reihe fallenden Werte auf.> Die Temperatur ist gleichmäßig gestiegen. Es scheinen wohl nur alle 75> Sekunden vom Collector in die mySQL geschrieben zu werden.>> Der vorherige Wert war 0x01d4 = 46,8 und der Wert danach 0x01E4 = 48,4> °C> Habe dann Zeitlich den Mittelwert genommen. Das war dann 0x01DD = 47,7> °C.
Ich kann dir hier nicht folgen. Was haben die Werte um die 40°C mit den
falschen Werten zu tun?
> Wie kann ich mit dem collector zusätzlich ein Logfile mit allen> Telegrammen aufzeichnen kann. Also alle Telegramme die der collector> bekommt?
Mit dem Kommandozeilenparameter -d message=<Pfad>.
> Denke fehlerhafte CRC werden vom EMS-Gateway und/oder collector> ignoriert, oder?
Wenn du mit EMS-Gateway deine Platine samt Code meinst, solltest du das
wissen ;-) Der Collector erwartet zumindest, dass CRC-Fehler vorher
ausgefiltert wurden; er sieht ja auch keine CRC. Mein ethersex-Code
filtert entsprechend.
Danny Baumann schrieb:> Ich kann dir hier nicht folgen. Was haben die Werte um die 40°C mit den> falschen Werten zu tun?
Also ich habe ja über Serial-Port mitgeloggt und dort nur richtige Werte
gesehen. zumindest nichts was Die Werte von etwa +-2000 erklären könnte.
Wahrscheinlich konnte ich da nicht mehr klar denken ;-)
Vermute mal jetzt dass irgendwie doch fehlerhafte Telegramme bei meinem
EMS-Gateway zum collector durchgelassen werden, die allerdings aus dem
Seriellen Port rausgefiltert werden.
Denke Jürgen kennt sich da mit der Firmware besser aus als ich.
Denke mal nicht das der collector ausversehen mal falsche Telegramme
auswertet, oder?
Allerdings habe ich jetzt schon mal einen Fehler gefunden. Da ich durch
den Quellcode von Moosys Frontend und Deinem collector nicht durchblicke
brauchte ich eure Hilfe.
Inzwischen vermute ich den Fehler im collector.
Also wenn ich im Frontend die Schaltzeiten öffne wird die letzte
Schaltzeit vom Sonntag ignoriert. Diese Schaltzeit ist genau auf der
Grenze von zwei Telegrammen!
Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und
bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset
0x1C (=28) abgefragt.
Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag
ausgelassen und daher wohl vom Frontend ignoriert.
Das zweite Telegramm müsste also mit Offset 0x1B abgefragt werden. Kann
die Berechnung des zweiten Offset-Wertes allerdings nirgendwo finden.
Macht diese Berechnung der collector?
Bei meinen Schaltzeiten tauchen als erstes zwei Schaltpunkte auf die
keinen Sinn machen:
1
10 0b 3f 00
Das würde ja eigentlich folgendes bedeuten:
[code]10 0b Tag:Montag, Schaltpunkt:AUS Uhrzeit:1:50
3f 00 Tag:Dienstag, Schaltpunkt:undefiniert Uhrzeit:0:00[/]
Kann es sein dass sich das EEPROM der RC30 verabschiedet und deswegen
unsinnige Werte stehen? Dann würde das f bei 0x3f vermutlich bedeuten
dass alle vorherigen Werte ignoriert werden sollen weil die
Speicherstelle defekt ist. ODer die Bit4 bei 0x10 bedeutet dass diese
Speicherzelle defekt ist und das Bit3 bei 0x3f bedeutet dass diese
Speicherzelle ebenfalls defekt ist. Sonst werden diese Bits in keinen
Schaltzeiten gesetzt.
Das könnte eine Erklärung sein warum ich auf der RC30 nicht mehr in das
Menü für den Party-/Urlaub-/Ferienmodus komme.
Oder die Schaltpunkte werden bei Änderungen nicht neu geordnet und
deswegen nur als gelöscht markiert.. Aber warum dann nicht bei beiden
Schaltpunkten?
Was habt Ihr eigentlich für Softwarestände in der RC35? Müsste mir evtl
einen gebrauchten kaufen.
Kann bei mir keine RC300 einsetzten weil ich kein EMS+ habe.
Kann das wirklich sein dass der Raumcontroller neu fast 700EUR
kostet????
Danny Baumann schrieb:> Mit dem Kommandozeilenparameter -d message=<Pfad>.
Danke, werd ich dann mal gleich testen...
Denke mit Pfad ist auch der Dateiname gemeint.
Stephan Richardt schrieb:> Ich habe jetzt bis zum Raspberry alles am laufen. Beim aufrufen der> Seiten wird immer nur der Ladebalken angezeigt. Die Seiten Statistik,> Fehlerspeicher und Protokoll werden angezeigt.
Mein PC ist ein Hypochonter...
Habe seit dem ich das gelesen habe auch dieses Problem..
Stephan Richardt schrieb:> Ich habe jetzt bis zum Raspberry alles am laufen. Beim aufrufen der> Seiten wird immer nur der Ladebalken angezeigt.
Dort wird die Verbindung zum EMS-Bus aufgebaut. Wenn die gestört ist
bleibt der Ladebalken bei mir auch stehen. Wenn die Verbindung nicht
beteht ist aber auch eine Anzeige unter dem Ladebalken
Allerdings benötigt der "Live Status" bei mir auch 30 Sekunden bis die
Seite angezeigt wird.
Ingo F. schrieb:> Bei meinen Schaltzeiten tauchen als erstes zwei Schaltpunkte auf die> keinen Sinn machen: 10 0b 3f 00
Also für mich sieht das ja wie ein Telegramm-Header aus. Kann doch kein
Zufall sein ... zumal der Telegramm-Typ stimmt.
//Niffko
Niffko _ schrieb:> Also für mich sieht das ja wie ein Telegramm-Header aus. Kann doch kein> Zufall sein ... zumal der Telegramm-Typ stimmt.>> //NiffkoSchäm :-D
Das war wohl ein copy&paste Error. Manchmal sollte man einfach mal eine
Pause machen....
Ich habe ja inzwischen auch Moosys Fronend installiert.
Wie lange dauert bei euch der Aufruf des LiveStatus?
Bei mir sind es etwa 30 Sekunden.
Wenn ich parrallel auf dem EMS-Bus sehe ich z.B. dass das unter anderem
das Telegramm 0x3D fünf mal im Sekundentakt aufgerufen wird und dann
passiert 5 Sekunden lang nichts. Dann werden mehrere Telegramme
abgerufen und dann wieder das Telegramm 0x3d. fünf mal im Sekundentakt.
Dauert dieser Aufruf bei euch nur 10 Sekunden und das Frontend erwartet
irgend einen Wert im Telegramm 0x3d was es nicht findet und macht
deswegen so lange Pausen?
Bei den Schaltzeiten habe ich dann auch das Problem dass je nach
Schaltprogramm nichts angezeigt wird oder die letze Schaltzeit nicht
angezeigt wird. Bei anderen Programmen wird es aber dann doch angezeigt.
Habe ja schon festgestellt dass bei den Zeitprogrammen ein Wert immer
übersprungen wird.
Habe mir zwar schon mal den Quellcode vom collector und Frontend
angesehen. Aber bisher nichts gefunden wo dieser "fehlerhafte" Offset
berechnet wird.
Ein zurückschreiben der geänderten Schaltprogramme klappt auch nicht.
Bei mir funktioniert auch das auf der LiveStatusseite nicht wirklich
viel.
Hatte vor kurzem noch die RC30 und habe auf eine RC35 aufgerüstet.
Dort hat sich dann auch gestern kurz mal was auf der Livestatus-Seite
getan. Jetzt aber wieder nicht.
Nicht dass es Mißverständnisse gibt. Die Daten auf der Rechten Hälfte
funktionieren nur die Linke nicht wirklich.
Bei den Einstellungen funktioniert sind teilweise falsche Werte.
Hatte schon vermutet dass es an der RC30 liegt. Moosy scheint ja auch
eine RC35 zu haben.
Gruß
Ingo
Ingo F. schrieb:> Vermute mal jetzt dass irgendwie doch fehlerhafte Telegramme bei meinem> EMS-Gateway zum collector durchgelassen werden, die allerdings aus dem> Seriellen Port rausgefiltert werden.>> Denke Jürgen kennt sich da mit der Firmware besser aus als ich.>> Denke mal nicht das der collector ausversehen mal falsche Telegramme> auswertet, oder?
Definiere 'falsche Telegramme'. Wenn 'falsch' == 'hatte eine fehlerhafte
CRC' bedeutet, dann wertet der Collector die natürlich trotzdem aus -
woher soll er wissen, dass die CRC falsch war?
> Allerdings habe ich jetzt schon mal einen Fehler gefunden. Da ich durch> den Quellcode von Moosys Frontend und Deinem collector nicht durchblicke> brauchte ich eure Hilfe.>> Inzwischen vermute ich den Fehler im collector.
Woher bist du dir so sicher, dass du einen Fehler gefunden hast, wenn du
nicht weißt, wo? :-P
> Also wenn ich im Frontend die Schaltzeiten öffne wird die letzte> Schaltzeit vom Sonntag ignoriert. Diese Schaltzeit ist genau auf der> Grenze von zwei Telegrammen!>> Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und> bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset> 0x1C (=28) abgefragt.> Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag> ausgelassen und daher wohl vom Frontend ignoriert.
Einspruch. Das hier passiert bei 'hk1 getcustomschedule 1':
IO: Sending bytes 0x90 0x3f 00 0x54 <---- Frage 84 Bytes von
Telegramm 0x3f ab
IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 00 0x1 0x1b 00 0x2d 0x1 0x54
00 0x8a 0x21 0x1b 0x20 0x2d 0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41
0x54 0x40 0x8a 0x61 0x1b 0x60 0xd6
MESSAGE[18.03.2015 15:19:12]: source 0x10, dest 0x0b, type 0x3f, offset
0, data: 0x01 0x1b 0x00 0x2d 0x01 0x54 0x00 0x8a 0x21 0x1b 0x20 0x2d
0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41 0x54 0x40 0x8a 0x61 0x1b
0x60 <---- 27 Bytes kommen rein
IO: Sending bytes 0x90 0x3f 0x1b 0x39 <---- Frage 57 Bytes ab,
Offset 27
IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 0x1b 0x2d 0x61 0x54 0x60 0x8a
0x81 0x1b 0x80 0x2d 0x81 0x54 0x80 0x8a 0xa1 0x1e 0xa0 0x8a 0xc1 0x1e
0xc0 0x8a 0xe7 0x90 0xe7 0x90 0xe7 0x90 0x52
MESSAGE[18.03.2015 15:19:12]: source 0x10, dest 0x0b, type 0x3f, offset
27, data: 0x2d 0x61 0x54 0x60 0x8a 0x81 0x1b 0x80 0x2d 0x81 0x54 0x80
0x8a 0xa1 0x1e 0xa0 0x8a 0xc1 0x1e 0xc0 0x8a 0xe7 0x90 0xe7 0x90 0xe7
0x9 <---- es kommen 27 Bytes rein
An der Stelle wird abgebrochen, da die Ausleseschleife beim ersten
Zeitwert von 0x90 ohnehin abgebrochen wurde.
Zeig mal deine Logs.
> Das zweite Telegramm müsste also mit Offset 0x1B abgefragt werden. Kann> die Berechnung des zweiten Offset-Wertes allerdings nirgendwo finden.> Macht diese Berechnung der collector?
Ja. Für den aktuellen Code: CommandHandler.cpp, Zeile 1561.
Zum allgemeinen Verständnis: Der Collector macht alles, was auf
Telegrammebene passiert, also Telegramme parsen und senden - und zu
letzterem gehört sowohl die Generierung der zu sendenden Telegramme als
auch die Behandlung einer fragmentierten Antwort. Dem Frontend bietet er
eine Schnittstelle zum Abrufen der geparsten Werte und eine
Schnittstelle zum Senden von Kommandos an.
Ingo F. schrieb:> Ich habe ja inzwischen auch Moosys Fronend installiert.>> Wie lange dauert bei euch der Aufruf des LiveStatus?> Bei mir sind es etwa 30 Sekunden.
Bei mir etwa 10 Sekunden.
> Wenn ich parrallel auf dem EMS-Bus sehe ich z.B. dass das unter anderem> das Telegramm 0x3D fünf mal im Sekundentakt aufgerufen wird und dann> passiert 5 Sekunden lang nichts. Dann werden mehrere Telegramme> abgerufen und dann wieder das Telegramm 0x3d. fünf mal im Sekundentakt.
Logs bitte.
> Dauert dieser Aufruf bei euch nur 10 Sekunden und das Frontend erwartet> irgend einen Wert im Telegramm 0x3d was es nicht findet und macht> deswegen so lange Pausen?
Gut möglich. Eventuell die (bisher nur bei RC35 vorhandene)
Auslegungstemperatur. Update den Collector mal auf den neuesten Stand
(und füge rc-type=rc30 zur Config bzw. --rc-type=rc30 zur Kommandozeile
hinzu).
> Bei mir funktioniert auch das auf der LiveStatusseite nicht wirklich> viel.>> Hatte vor kurzem noch die RC30 und habe auf eine RC35 aufgerüstet.> Dort hat sich dann auch gestern kurz mal was auf der Livestatus-Seite> getan. Jetzt aber wieder nicht.>> Nicht dass es Mißverständnisse gibt. Die Daten auf der Rechten Hälfte> funktionieren nur die Linke nicht wirklich.>> Bei den Einstellungen funktioniert sind teilweise falsche Werte.>> Hatte schon vermutet dass es an der RC30 liegt. Moosy scheint ja auch> eine RC35 zu haben.
Moosy's Code scheint an einigen Stellen sehr stark auf sein Setup (RC35,
nur HK1 vorhanden, Fußbodenheizung) ausgerichtet zu sein.
Was genau geht denn nicht?
Danny Baumann schrieb:> Definiere 'falsche Telegramme'. Wenn 'falsch' == 'hatte eine fehlerhafte> CRC' bedeutet, dann wertet der Collector die natürlich trotzdem aus -> woher soll er wissen, dass die CRC falsch war.
Das Problem hat sich erledigt und muss noch gefixt werden....
Der EMS-Gateway filtert die Fehlerhaften-Telegramme wohl nur bei Telnet
und über den SerialPort heraus. Über die collector-Schnittsltelle wohl
nicht.
Danny Baumann schrieb:> Woher bist du dir so sicher, dass du einen Fehler gefunden hast, wenn du> nicht weißt, wo? :-P
Na weil ich, wie alle anderen Menschen auch, eben fehlerfrei bin :-P
Bei der RC-30 habe ich mal mittgeloggt und dann eben gesehen dass ein
Wert fehlt. Wenn ich dann das Telegramm manuell abfrage 0b 90 3f 1b 1c
dann bekomme ich das fehlende Byte.
Habe das jetzt noch mal mit der RC35 getestet. Dort wird wohl nur der
erste Teil des Telegramms geliefert. Hänge mal ein mein log als PNG an.
Danny Baumann schrieb:> Gut möglich. Eventuell die (bisher nur bei RC35 vorhandene)> Auslegungstemperatur. Update den Collector mal auf den neuesten Stand> (und füge rc-type=rc30 zur Config bzw. --rc-type=rc30 zur Kommandozeile> hinzu).
Jetzt habe ich eine RC35. Bei der RC30 kamm ich nicht mehr ins Menü wie
in der ANleitung beschrieben.
Danny Baumann schrieb:> Was genau geht denn nicht?
Also in Einstellungen werde teilweise falsche Daten angezeit. z.B. Als
Führungsgröße "Raum" obwohl bei mir Außengeführt ist. Daher auch keine
Heizkurve.
Schaltprogramme abfragen will nicht richtig. Senden geht auch nicht.
Kommt eine Fehlermeldung. Möchte das jetzt nicht nochmal ausprobieren.
Dann wird jedesmal mein Heizprogramm zerschossen und muss es wieder
manuell an der RC35 eingeben. Kommt sobald ich das lesen erfolgreich
hinbekomme...
Im Livestatus werden die Tag und Nachtemperatur und die eingestellte
Raumtemperatur nciht angezeigt. Gestern lief das mal ganz kurz. Die
RaumSollTemperatur ließ sich aber nicht mi (-) und (+) verstellen.
Party und Pause werden manchmal flasche Werte angezeigt.
Das einizige was wohl richtig funktioniert ist der Status.
Gruß
Ingo
Ingo F. schrieb:> Bei der RC-30 habe ich mal mittgeloggt und dann eben gesehen dass ein> Wert fehlt. Wenn ich dann das Telegramm manuell abfrage 0b 90 3f 1b 1c> dann bekomme ich das fehlende Byte.>> Habe das jetzt noch mal mit der RC35 getestet. Dort wird wohl nur der> erste Teil des Telegramms geliefert. Hänge mal ein mein log als PNG an.
An welcher Stelle wird dieses Log geloggt? Auf deinem Gateway? Spontan
irritieren mich die mehrfachen Kommandowiederholungen. Die sollten da
nicht sein, sondern der Offset sollte ordentlich hochgezählt werden.
Starte den Collector mal bitte mit -d io=<Pfad>, lasse die
Schaltzeitpunkte auslesen und lade die Datei mal bitte hoch. Vielleicht
macht dein Gateway an der Stelle ja etwas falsch (z.B. Senden des
vorhergehenden Sendepuffers, wenn neue Sendedaten eintreffen)? Das würde
zumindest so ziemlich alle von dir beschriebenen Probleme erklären, und
auch, warum z.B. ich diese Probleme scheinbar nicht habe.
> Also in Einstellungen werde teilweise falsche Daten angezeit. z.B. Als> Führungsgröße "Raum" obwohl bei mir Außengeführt ist. Daher auch keine> Heizkurve.
Das hier z.B. könnte auch so ein Problem sein, da die Führungsgröße
hinter Byte 27 steht und Moosy alles, was nicht 'außengeführt' ist (also
auch 'undefiniert') als 'raumgeführt' interpretiert (weshalb das bis vor
kurzem auch nicht mit der RC30 funktioniert hat - die hat diesen Wert
einfach nicht).
Sieht so aus als ob meine Softwarestand der Heizung es nicht mag wenn
zuviele Daten abgefragt werden.
wenn ich z.B. 0b 90 3f 00 54 absende erhalte ich immer nur ein Telegramm
mit 27(=0x1b) Byte Daten. Mehr kommt dann nicht.
Ist das bei Dir anders? Dachte der Collector oder das Frontend fragt
nacheinander alle Telegramme in Stückchen der Reihe nach ab.
Ingo F. schrieb:> Sieht so aus als ob meine Softwarestand der Heizung es nicht mag wenn> zuviele Daten abgefragt werden.>> wenn ich z.B. 0b 90 3f 00 54 absende erhalte ich immer nur ein Telegramm> mit 27(=0x1b) Byte Daten. Mehr kommt dann nicht.>> Ist das bei Dir anders? Dachte der Collector oder das Frontend fragt> nacheinander alle Telegramme in Stückchen der Reihe nach ab.
Das ist bei mir genauso, und wie du schon vermutest, sollte der
Collector die weiteren Daten stückchenweise abfragen. Bei mir tut er das
allerdings auch, weshalb es eigentlich nur 3 Möglichkeiten gibt:
1) dein Checkout des Collectors ist zu alt (unwahrscheinlich, ich habe
die Fragmentbehandlung seit September 2013 drin)
2) dein Gateway macht etwas falsch (d.h. sendet andere Daten, als der
Collector in den Socket gestopft hat)
3) der Collector hat einen Bug, der sich bei mir noch nicht manifestiert
hat
Jetzt gilt es rauszufinden, welche der 3 Möglichkeiten zutrifft - das
ist der Grund, weshalb ich nach dem Collector-IO-Log gefragt habe ;-)
Danny Baumann schrieb:> Vielleicht> macht dein Gateway an der Stelle ja etwas falsch
Will ich nicht ausschließen.
Die Logs kommen vom USB-Port des EMS-Gateways. Aufgenommen mit HTerm.
Denke das Problem ist in beiden Fällen dass nur der erste Brocken der
Daten kommt. Würde jetzt sagen die Sofware meiner Heizung ist das
Problem (von 2003).
Durchaus kann es auch am Senden vom EMS-Gateway liegen... Dann müsste
ich aber doch zumindest einen fehlerhaften Anwortversuch oder
Buskollisonen bekommen?!
Edit:
Also den Collector habe ich ja erst vor einem Monat kompiliert. Ist also
wohl die Fragmentierung drin.
Ingo F. schrieb:> Denke das Problem ist in beiden Fällen dass nur der erste Brocken der> Daten kommt. Würde jetzt sagen die Sofware meiner Heizung ist das> Problem (von 2003).
Glaub ich nicht, meine ist zumindest ähnlich alt, die Anlage ist von
2004.
> Durchaus kann es auch am Senden vom EMS-Gateway liegen... Dann müsste> ich aber doch zumindest einen fehlerhaften Anwortversuch oder> Buskollisonen bekommen?!
Kommt drauf an, wie der Fehler aussieht. Wenn - wie ich oben schon
spekuliert habe - unter bestimmten Umständen (z.B. gleiches Ziel +
gleicher Typ) der Sendepuffer nicht mit den neuen zu sendenden Daten
überschrieben würde, sondern die alten Daten drin stehen blieben, würde
das genau das Fehlerbild erzeugen, das du siehst.
Habe mal mein Log angehangen...
Also vom UBA-Softwarestand wäre das ja möglich dass sie zu alt ist.
Allerdings hat die ziemlich wenig mit dem Telegramm zu tun.
Meine RC30 hat auch 2.05.
Vermutlich gibt es niemanden der den EMS-Gateway und Moosys Frontend
benutzt. Deshalb ist es vermutlich nicht aufgefallen wenn das Problem am
EMS-Gateway liegt.
Habe erst den Livestatus angeklickt und nach dem Laden die
Schaltprogramme... Die Datei ist ja in den 50 Sekunden recht groß
geworden.. hätte ich nie gedacht... Vielleicht nicht mit *-d all...*
loggen sollen???
Edit:
Ist das der aktuelle Stand vom collector? Habe "Main" vom ems-collector
genommen...
Version EMS-Collector 2014031201
Ingo F. schrieb:> Habe mal mein Log angehangen...
Irgendwas läuft da richtig schief.
IO: Sending bytes 0x90 0x3f 00 0x54
IO: Got bytes 0xaa 0x55 0x20
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3f 00 0x54 0xf0
Auf das gesendete Telegramm mit der Abfrage von 84 Bytes aus Telegramm
kommt also
- eine Antwort mit Länge 32, aber ohne Daten
- eine Antwort, die nach einer Kopie des Sendepuffers aussieht
Konsequenterweise versucht es der Collector daraufhin noch ein paar mal,
aber bekommt weiterhin keine sinnvolle Antwort.
Mal zum Vergleich, so sieht es bei mir aus:
IO: Sending bytes 0x90 0x3f 00 0x54
IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 00 0x1 0x1b 00 0x2d 0x1 0x54
00 0x8a 0x21 0x1b 0x20 0x2d 0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41
0x54 0x40 0x8a 0x61 0x1b 0x60 0xd6
Da musst du wohl nochmal in die Gateway-Sourcen schauen ;-)
IO: Sending bytes 0x90 0x3f 0x1b 0x39
Danny Baumann schrieb:> - eine Antwort mit Länge 32, aber ohne Daten> - eine Antwort, die nach einer Kopie des Sendepuffers aussieht
Na dann kann es ja nicht wirklich funktionieren...
Werde mich mal durch die Sourcen durchkämpfen...
Moin,
dass RC30/35 bei Abfrage größerer Telegramme in die Knie gehen ist wohl
normal ... das Thema hatten wir -glaube ich- auch schon mal. Der
Service-Key fragt zumindest die entsprechenden Telegramme auch in
kleineren Chunks ab.
Ich hab mich kürzlich zum ersten mal mit der Abfrage solcher
"Überlängen" beschäftigt. Dabei ist mir etwas aufgefallen, was evtl.
etwas mit Ingos Problem zu tun haben könnte.
Fragt man mehr Datenbytes an, als der RC30/35 liefern kann, wird keine
CRC auf den Bus geechot (siehe Anhang). Kann das jemand verifizieren?
Würde man jetzt das letzte Byte für einen CRC-Check hernehmen, geht das
natürlich schief.
Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge
der abzufragenden Datenchunks von vorn herein auf einen Wert
festzulegen, der auch sicher geliefert werden kann.
//Niffko
Niffko _ schrieb:> Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge> der abzufragenden Datenchunks von vorn herein auf einen Wert> festzulegen, der auch sicher geliefert werden kann.
Die CRC werden im collector ja nicht mehr ausgewertet und deswegen
vermutlich erst mal egal.
Denke dass mit der 00-CRC bei "Überlängen" ist ein spezielles Problem
vom NetIO. Auf dem EMS-Bus werden tzrotzdem CRC gesendet.
Mit dem EMS-Gateway ist es zumindest nicht so.
Denke aber es wäre keine schlechte Idee dass auf eine Datenlänge von
0x1b zu begrenzen. Mehr Daten werden sowieso nicht geliefert.
Kann das mit der CRC mit dem EMS-Gateway nicht nachvollziehen...
Vermute mal das Problem vom EMS-Gateway könnte sich dann nicht mehr so
auswirken. Nur die Telegramme die ein größeres Offset als 0x1b haben
könnten das Problem sein. Kleinere Telegramme gehen ja wohl, so wie es
aussieht, Problemlos durch.
Bin aber natürlich bei der Fehlersuche im EMS-Gateway dabei..
Niffko _ schrieb:> Fragt man mehr Datenbytes an, als der RC30/35 liefern kann, wird keine> CRC auf den Bus geechot (siehe Anhang). Kann das jemand verifizieren?> Würde man jetzt das letzte Byte für einen CRC-Check hernehmen, geht das> natürlich schief.
Ich kann das zwar nicht direkt verifizieren, da der Collector die CRC
nicht sieht und ich am NetIO grade kein RS232 angeschlossen habe.
Allerdings schließe ich daraus, dass
- auf 0x90 0x3d 00 0x2a eine Antwort kommt und
- gleichzeitig die Anzahl an Paketen mit CRC-Fehlern im NetIO gleich
bleibt (d.h. kein neuer CRC-Fehler auftritt) und
- mein ethersex-Code in der Tat das letzte Byte als CRC interpretiert
dass ich das Problem nicht sehe. Das ist allerdings noch mit der RC30,
mit der RC35 habe ich es noch nicht probiert.
BTW, ein paar CRC-Fehler scheinen normal zu sein. Ich habe grad mal in
die EMS-Statistik des NetIO geschaut, und der sagt 32326006 korrekte
Pakete zu
114743 mit CRC-Fehlern, also eine Fehlerrate von ~0.4% kaputten Paketen.
Ich bin mir allerdings nicht ganz sicher, wie das passieren kann...
(Anderer Fun Fact am Rande: nur 15% der übertragenen Daten sind wirklich
Pakete mit Nutzdaten, der Rest ist Polling ohne Datenübertragung.) Auch
noch interessant: mehr als 6000x waren die aufgelaufenen Daten > 64
Byte, was, soweit ich meinen Code noch überblicke, heißt, dass manchmal
doch längere Pakete auf dem Bus sind. Das muss ich nochmal mit einem
größeren Puffer verifizieren)
Ingo F. schrieb:> Niffko _ schrieb:>> Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge>> der abzufragenden Datenchunks von vorn herein auf einen Wert>> festzulegen, der auch sicher geliefert werden kann.> Die CRC werden im collector ja nicht mehr ausgewertet und deswegen> vermutlich erst mal egal.
Es wäre vermutlich nicht egal, wenn der Collector keine Antwort bekäme,
was bei falscher CRC passieren würde ;-)
> Denke dass mit der 00-CRC bei "Überlängen" ist ein spezielles Problem> vom NetIO. Auf dem EMS-Bus werden tzrotzdem CRC gesendet.
???
Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau
siehst du ein NetIO-Problem?
> Vermute mal das Problem vom EMS-Gateway könnte sich dann nicht mehr so> auswirken. Nur die Telegramme die ein größeres Offset als 0x1b haben> könnten das Problem sein. Kleinere Telegramme gehen ja wohl, so wie es> aussieht, Problemlos durch.
Es gibt schon noch andere Telegramme, die in deinem Log komisch
aussehen. Z.B. dieses:
IO: Sending bytes 0x90 0x37 00 0xc
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x37 00 0xc 0xa0
Bei der Wiederholung hat es funktioniert:
IO: Sending bytes 0x90 0x37 00 0xc
IO: Got bytes 0xaa 0x55 0xf 0x10 0xb 0x37 00 0xff 00 0x2 0x2 00 0x1 0x1
00 0x3c 0xff 0x58 0x48
oder hier (erste Antwort kaputt, zweite ok):
IO: Sending bytes 0x90 0xa5 00 0x19
IO: Sending bytes 0x90 0x3f 0x54 0x1
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3f 0x54 0x1 0xf1
IO: Got bytes 0xaa 0x55 0x6 0x10 0xb 0x3f 0x54 00 0x15 0x65
oder hier
IO: Sending bytes 0x88 0x34 00 0xc
IO: Got bytes 0xaa 0x55 0x5 0xb 0x88 0x34 00 0xc 0xbb
oder hier (beide kaputt)
IO: Sending bytes 0x90 0x37 00 0xc
IO: Sending bytes 0x90 0xa5 00 0x19
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x37 00 0xc 0xa0
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0xa5 00 0x19 0x27
IMHO existiert da ein systematisches Problem ;-)
Danny Baumann schrieb:> Es wäre vermutlich nicht egal, wenn der Collector keine Antwort bekäme,> was bei falscher CRC passieren würde ;-)
Hatte Niffkos Screenshot so verstanden dass der NetIO nur in diesem Fall
Telegramme ohne CRC rausschickt. Der collector würde dann das Telegramm
trotzdem mit fehlernder CRC bekommen. Aber der collector ignoriert diese
CRC.
Habe ich das falsch verstanden?
Danny Baumann schrieb:> Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau> siehst du ein NetIO-Problem?
in seinem Screenshots waren bei den Abfragen mit Längen über 0x1b am
Ende immer eine 0x00. Ist das nicht die fehlende CRC? Ist das ein
Datenbayte?
Da bei mir max 0x1b Datenbytes übermittelt werden habe ich angenommen
dass es kein Datenbyte sein kann.
Danny Baumann schrieb:> IMHO existiert da ein systematisches Problem ;-)
Das wollte ich damit nicht ausschließen. Das ist eine Tatsache dass der
EMS-Gateway sich nicht korrekt verhält.
Nur funktionieren bei mir die Telegramm mit weniger als 0x1b Daten. Auch
wenn sie ab und zu ein zweites mal angefragt werden müssen.
Wollte also nicht irgendjemandem die Schuld geben.
Würde vernutlich dann bedeuten dass es bei mir dann vermutlich laufen
würde wenn nur 0x1b Daten angefragt werden.
Habe da so eine Vermutung gehabt was das Problem beim EMS-Gateway
verursachen könnte. Aber das war vermutlich ein Irtum.
Ingo F. schrieb:> Hatte Niffkos Screenshot so verstanden dass der NetIO nur in diesem Fall> Telegramme ohne CRC rausschickt. Der collector würde dann das Telegramm> trotzdem mit fehlernder CRC bekommen. Aber der collector ignoriert diese> CRC.>> Habe ich das falsch verstanden?
Niffko's Screenshot bezieht sich auf die Antwort, die (in seinem Fall)
von der RC30 kommt, nicht darauf, was seine Sendehardware (IIRC
verwendet er kein NetIO) rausschickt.
Und nochmal ;-) Der Collector sieht nie irgendeine CRC. Entweder die
empfangende Hardware (z.B. NetIO) sieht die CRC als OK an und schickt
die Daten an den Collector weiter, oder sie schickt die Daten nicht
weiter und der Collector sieht gar nix.
> Danny Baumann schrieb:>> Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau>> siehst du ein NetIO-Problem?>> in seinem Screenshots waren bei den Abfragen mit Längen über 0x1b am> Ende immer eine 0x00. Ist das nicht die fehlende CRC? Ist das ein> Datenbayte?
Ja, das ist ein Datenbyte. Niffko wollte darauf hinaus, dass bei Länge
25 (0x19) die CRC noch da ist, aber ab Länge 26 (0x1a) fehlt, erkennbar
an der nicht mehr wachsenden Länge der Telegramme.
> Nur funktionieren bei mir die Telegramm mit weniger als 0x1b Daten. Auch> wenn sie ab und zu ein zweites mal angefragt werden müssen.
Das sehe ich eben anders - genau deshalb habe ich ja ein paar Telegramme
mit Länge < 27 rausgepickt, die auch kaputt sind. Soweit ich das
beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas
grundsätzliches kaputt, was ein erfolgreiches Senden - völlig unabhängig
von der angefragten Länge - zur Glückssache macht. Ich denke, dass die
beste Idee wäre, zuerst dieses Problem zu fixen, und dann auf eventuelle
Probleme mit bestimmten abgefragten Längen zu schauen. IMHO besteht eine
nicht allzukleine Wahrscheinlichkeit, dass diese sich nach der Behebung
des generellen Problems in Luft auflösen werden.
Für das Debugging würde ich übrigens empfehlen, das Webfrontend erstmal
komplett wegzulassen und nur die Telnet-Schnittstelle des Collectors zu
verwenden, um die Komplexität runterzubekommen. Dann mit ein paar
einfachen Befehlen anfangen (WW-Temperatur, Tag-/Nachtmodus, Ferienzeit
usw.), um zu schauen, wie sich nicht fragmentierte Pakete verhalten, und
gleichzeitig Gateway- und Collector-IO-Log beobachten. Dann beobachtete
Inkonsistenzen fixen ;-) Wenn das geht, zu fragmentierten Paketen
(Schaltzeitplan, 'hk1 requestdata' usw.) übergehen.
Danny Baumann schrieb:> Soweit ich das> beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas> grundsätzliches kaputt,
Habe doch gesagt dass das eine Tatsache ist....
Danny Baumann schrieb:> und nur die Telnet-Schnittstelle des Collectors zu> verwenden,
Wie bekomme ich dass denn hin?
habe das cli von Moosys ems-tools genommen.
Gibt es noch eine direkt Möglichkeit über telnet? Wenn ja, wie komme ich
da hin? Beim Telnet auf 7777 und 7778 kommt sofort Die Verbindung wurde
abgebrochen.
Wäre der Telnet auf die Ports OK oder liege ich da falsch? Habe noch den
Appache laufen. Aber die Webseite vom Fronend nicht geöffnet also dürfte
der Port doch nicht belegt sein.
Das Log vom EMS-Gateway für den collector-Port gibt es nicht wirklich
soweit ich das sehe. Das Log über den USB-Port sieht ja anders aus.
Müsste da wohl einen Spiegelport einrichten und wireshark nehmen.
Ingo F. schrieb:> Danny Baumann schrieb:>> Soweit ich das>> beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas>> grundsätzliches kaputt,>> Habe doch gesagt dass das eine Tatsache ist....
Ich will's dir ja auch nicht unter die Nase reiben :) Ich wollte einfach
nur sagen, dass es sich IMHO nicht lohnt, sich auf das Längenproblem zu
konzentrieren, wenn das wahrscheinlich nur ein Symptom eines anderen
Problems ist.
>> Danny Baumann schrieb:>> und nur die Telnet-Schnittstelle des Collectors zu>> verwenden,>> Wie bekomme ich dass denn hin?> habe das cli von Moosys ems-tools genommen.>> Gibt es noch eine direkt Möglichkeit über telnet? Wenn ja, wie komme ich> da hin? Beim Telnet auf 7777 und 7778 kommt sofort Die Verbindung wurde> abgebrochen.
Genau das (Telnet auf 7777) sollte gehen {wenn entsprechend konfiguriert
- wenn das nicht der Fall wäre, würde das Frontend aber auch nicht
funktionieren).
> Wäre der Telnet auf die Ports OK oder liege ich da falsch? Habe noch den> Appache laufen. Aber die Webseite vom Fronend nicht geöffnet also dürfte> der Port doch nicht belegt sein.
Der Port akzeptiert auch mehrere gleichzeitige Verbindungen und lauscht
auch auf Verbindungen von anderen Rechnern. Eventuell ein
Firewall-Problem o.Ä.?
> Das Log vom EMS-Gateway für den collector-Port gibt es nicht wirklich> soweit ich das sehe. Das Log über den USB-Port sieht ja anders aus.> Müsste da wohl einen Spiegelport einrichten und wireshark nehmen.
Gut, das kann ich schlecht beurteilen. Das Log, was du oben gepostet
hättest, sah nur ganz brauchbar aus.
Niffko _ schrieb:> Ja seht ihr denn die Zeichen nicht :-)
Ach menno, jetzt lenk den Ingo doch nicht wieder vom eigentlichen
Problem ab ;-)
> Auszüge aus Ingos ems.log :> [snip]
Etwas später im Log:
MESSAGE[18.03.2015 16:44:28]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a
Da wird dann auch ziemlich deutlich, warum keine weiteren
Message-Zeilen kommen.
Bei deinem Problem halte ich bei nochmaligem drüber nachdenken auch
einen Bug im Empfänger-Code für möglich. Zumindest ist auffällig, dass
du nur bis 25 Byte empfangen kannst, während die RC30 bei mir und die
RC35 bei Ingo 27 Bytes schickt [ich teste morgen auch noch mal mit der
RC35]. Eventuell ein Puffer zu klein o.Ä.?
Danny Baumann schrieb:> ... Bug im Empfänger-Code ... Eventuell ein Puffer zu klein o.Ä.?
Tja Danny, was soll ich sagen ... Punktlandung!
Die Diskrepanz von meinen 26 zu euren 27 Bytes ist mir nicht aufgefallen
:(
Jedenfalls ... kaum macht man den Empfangsbuffer etwas größer, klappts
auch mit der CRC * facepalm *
//Niffko
Hallo!
Ich habe ein Heizung mit Solarmodul (SM10). Die Telegramme dazu sind ja
schon im Wiki. Ist eine Aufnahme in den collector geplant? Wenn ja wann?
Habe mir den Sourcecode mal angesehen. Wie müssen die Werte der Tabelle
umgesetzt werden? Wäre das als Beispiel richtig? Gibt es Regeln für die
Werte Namen (Pumpe & Aussentemp ist ja nicht eindeutig)?
Hallo Dany,
wie sollte denn die richtige Kommunikation zwischen EMS-Gateway/NetIO
und collector aussehen?
ALso z.B.
zum zum NetIO:
90 06 00 06 (Empfänger, Typ, Offset, Anzahl)
vom NetIO:
10 0b 06 00 11 22 33 44 55 66
Gruß
Ingo
Kay F. schrieb:> Hallo!>> Ich habe ein Heizung mit Solarmodul (SM10). Die Telegramme dazu sind ja> schon im Wiki. Ist eine Aufnahme in den collector geplant? Wenn ja wann?
Geplant ist da eigentlich nie etwas ;-) Entweder es gibt genügend
(eindeutige) Informationen und jemand spricht mich drauf an, oder es
schickt jemand einen Pull Request.
Für SM10 Monitor hab ich das grad mal gemacht:
https://github.com/maniac103/ems-collector/commit/7c9166f31401c3fab257cc0a3f074c5507ff865f
- probier mal.
Die Offsets im Wiki sehen allerdings komisch aus, so dass es nett wäre,
wenn du mal ein Collector-Log mit Message-Debug, in dem die Nachrichten
0x96 und 0x97 enthalten sind, hochladen könntest.
> Habe mir den Sourcecode mal angesehen. Wie müssen die Werte der Tabelle> umgesetzt werden? Wäre das als Beispiel richtig? Gibt es Regeln für die> Werte Namen (Pumpe & Aussentemp ist ja nicht eindeutig)?
'Type' ist die Art des Wertes, 'Subtype' eine Klassifizierung, wo der
Wert herkommt. Es ist dabei nicht wirklich wichtig, unbedingt mit den
existierenden Bezeichnungen auszukommen; wichtiger ist es, dass der Wert
sinnvoll beschrieben ist. Essenziell ist allerdings, dass jede
Kombination aus Type + Subtype eindeutig ist, da diese Kombination
letztendlich den Sensor beschreibt.
> parseNumeric(0, 2, 10, EmsValue::SollTemp, EmsValue::None);
Ich denke, dass ist die Außentemperatur?
(Interessant ist, dass du Offset 0 verwendest, was nicht zum Wiki passt
- daher mein Kommentar oben)
> parseInteger(2, 1, EmsValue::Mischersteuerung, EmsValue::None);
Das ist doch eine Pumpenmodulation, also EmsValue::IstModulation.
> parseNumeric(3, 2, 10, EmsValue::IstTemp, EmsValue::None);
IstTemp ist richtig, ich habe dafür den Subtype 'SolarSpeicher'
eingeführt.
> parseBool(5, 1, EmsValue::PumpeAktiv, EmsValue::None);
Das braucht noch einen Subtype, ist aber ansonsten korrekt.
> parseInteger(7, 3, EmsValue::Mischersteuerung, EmsValue::None);
EmsValue::Betriebszeit (zumindest laut Wiki)
Ingo F. schrieb:> Hallo Dany,>> wie sollte denn die richtige Kommunikation zwischen EMS-Gateway/NetIO> und collector aussehen?http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio
:-)
> zum zum NetIO:> 90 06 00 06 (Empfänger, Typ, Offset, Anzahl)
Das würde die ersten 6 Bytes des Telegramms 6 vom RC abfragen, ja.
> vom NetIO:> 10 0b 06 00 11 22 33 44 55 66
Da fehlt 0xaa 0x55 + Länge am Anfang und XOR über die Daten am Ende.
Kay F. schrieb:> Im Display der RC35 steht:>> Kollektor 48 Grad> Speicher mitte 46 Grad> Speicher unten 46 Grad> Solar-Pumpe 0%> Betriebsstunden 5064h 38 min>>>
Sieht doch schon mal gut aus. Die Kollektortemperatur steht an Offset 2,
die baue ich morgen noch ein. Wo die RC35 allerdings 2
Speichertemperaturen hernimmt ist mir nicht klar.
> Mir ist nur nicht ganz klar warum die Message teilweise Unhandled ist.
Naja, Nachrichten, die kamen, bevor ich die Behandlung dieser Nachricht
heute eingebaut habe, sind halt ... unbehandelt ;)
Ingo F. schrieb:> Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und> bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset> 0x1C (=28) abgefragt.> Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag> ausgelassen und daher wohl vom Frontend ignoriert.
Hallo Danny,
HURRA, ich habe den Fehler im EMS-Gateway endlich gefunden!!!
Jetzt komme ich wieder zu meinem Problem.
Das Offset der Daten wird falsch berechnet.
Denke die XOR-Prüfsumme wird als Daten angesehen und mitgezählt.
Hier mal das Beispiel der Kontaktdaten. Est kommen 21 Byte Kontaktinfo1
und dann 15 Byte Kontaktinfo2.
Bei mir vorher gesetzt:
abcdefghijklmnopqrstu
ABCDEFGHIJKLMNOPQRSTU
Zurück wird gegeben:
abcdefghijklmnopqrstu
ABCDE`GHIJKLMNOPQRSTU
Das erste Telegramm das abgefragt wird ist dieses:
die XOR-Prüfsumme 0x91 am Ende enstpricht der Position des "F" was als
"`" (0x91) beim auslesen zurückgegeben wird.
Ich habe noch weitere Proleme. Denke die sind vermutlich auch auf diesen
Fehler zurückzuführen. (Schaltzeit die auf dieser Stelle zwischen zwei
Telegramme befindet)
Danny Baumann schrieb:> Bitte einmal IO- und Message-Log :)
kannste haben...
Also ich habe im Frontend die "Einstellungen" Seite geladen und den
collector restartet.
Dann noch mal die beiden Werte gesetzte (Telegramm A4)
abcdefghijklmnopqrstu
ABCDEFGHIJKLMNOPQRSTU
und dann noch mal die Werte abgerufen.
das F wird dann durch die Prüfsumme 0x91 ersetzt.
Gruß
Ingo
Ingo F. schrieb:> und dann noch mal die Werte abgerufen.> das F wird dann durch die Prüfsumme 0x91 ersetzt.
Die Prüfsumme ist nicht 0x91, sondern 0x48. Schau selbst:
1
IO: Sending bytes 0x90 0xa4 00 0x2a
Anforderung von 42 Bytes aus Telegramm 0xa4, Offset 0
Antwort mit 32 Bytes (Quelle 0x10, Ziel 0x0b, Typ 0xa4, Offset 0): 0x61,
0x62, ..., 0x91; Prüfsumme 0x48
Du schickst also ein Byte zu viel - da wirst du doch noch mal in deinen
Code schauen müssen ;-)
War so froh den Fehler gefunden zu haben dass ich erst das Log
hochgeladen habe und erst danach angesehen habe.
Aber das eine Byte abziehen das sollte ich wohl hinbekommen ...
Habe das eine Byte zuviel auch dann genau zu der Zeit gefunden als Du
geantwortet hast...
Danny Baumann schrieb:> Echo des gesendeten Paketes? (das gehört da nicht hin)
Stimmt schon... aber das werde ich mir dannach ansehen.
Im Moment wird alles was auf dem EMS-Bus ankommt zum collector
rübergeschaufelt. Das ist dann auch das Echo des selbst gesendeten
Befehls.
Werde dann die Echos der selbst gesendeten Befehle noch mal
herausfiltern.
Eigentlich dürfte dass kein zu großes Problem sein. Aber mal abwarten...
Aber das scheint der collector erst mal zu ignorieren.
Gruß
Ingo
Danny, hast Du mal ein 0x18 und 0x19 Telegramm aus Deinem Log?
Wäre mal gut ein Telegramm so zu sehen wie es aussehen soll.
Habe das eine Byte "entfernt" jetzt sieht eigentlich alles gut aus, aber
jetzt läuft nichts mehr..
Ingo F. schrieb:> Danny, hast Du mal ein 0x18 und 0x19 Telegramm aus Deinem Log?>> Wäre mal gut ein Telegramm so zu sehen wie es aussehen soll.
Bitteschön:
> Habe das eine Byte "entfernt" jetzt sieht eigentlich alles gut aus, aber> jetzt läuft nichts mehr..
Definiere 'nichts mehr' ;-) Auslesen wird doch schon noch gehen, oder?
Danny Baumann schrieb:> 'nichts mehr'
Bedeutet das nichts mehr geht ;-)
Das waren aber zwei andere Fehler.
Mein provisorischer Server ist mit WLAN angebunden und hatte die
WLAN-Verbindung verloren.
Der Collector ließ sich wie immer mit Restart neustarten und zeigt OK
an.
Als ich dann aber mal "service ems-collector stop" abgesetzt habe hieß
es dann "Kill: Kein laufender Service gefunden [Fail]"
Nach einem Neustart funktioniert schon fast alles.
Nur die Einstellungen werden ab 50% langsamer. Einige Telegramme haben
jetzt wohl Probleme...
Aber die Schaltzeiten, LiveStatus, Protokoll laufen Problemlos. Werde
erst mal das Befehls-Echo rausnehmen und mir das noch mal genauer
ansehen.
So, jetzt funktioniert fast alles.
Einfach ein Byte weglassen war nciht ganz so einfach. Musste doch mehr
geändert werden.
Das Befehlsecho und das überflüssige Byte sind jetzt auch weg.
Wenn ich die Schaltzeiten auslese werden sie jetzt auch korrekt
angezeigt.
Nur das schrieben klappt nicht.
Muss mir mal nächste Zeit das Log ansehen.
Moosys Frontend möchte einen Wert setzten un bekommt nur als Antwort den
Status 01 = OK. So wie es aussieht ist der Frontend damit nicht
zufrieden und setzt dann noch vier weitere Male den Wert.
Dann stürzt bei mir der collectord ab und ich muss den service stoppen
und neu starten, sonst meckert das Frontend dass keine Verbindung zum
EMS-Bus vorhanden ist. Und es läuft wieder nichts.
Ingo F. schrieb:> Moosys Frontend möchte einen Wert setzten un bekommt nur als Antwort den> Status 01 = OK. So wie es aussieht ist der Frontend damit nicht> zufrieden und setzt dann noch vier weitere Male den Wert.
Komisch. Welcher Wert ist das? Status 01 sollte dazu führen, dass der
Collector 'OK' meldet, vielleicht ist da irgendwas kaputt. Schick mal
das Log von der Stelle, dann schau ich mir das mal an.
> Dann stürzt bei mir der collectord ab und ich muss den service stoppen> und neu starten, sonst meckert das Frontend dass keine Verbindung zum> EMS-Bus vorhanden ist. Und es läuft wieder nichts.
Wann genau ist 'dann'? Ist der Absturz reproduzierbar? Wenn ja, Log
bitte ;) An der Stelle sind gleich 2 Dinge komisch: der Collector sollte
nicht abstürzen ;) und wenn er es schon tut, sollte er doch vom
Init-System neu gestartet werden?
Danny Baumann schrieb:> vielleicht ist da irgendwas kaputt. Schick mal> das Log von der Stelle
Werde ich dann machen wird aber noch etwas dauern...
Danny Baumann schrieb:> Wann genau ist 'dann'? Ist der Absturz reproduzierbar?
Habe es zwei mal ausprobiert. Zweimal sah es so aus als ob der collector
abgestürzt ist. Frontend sagte dannach immer "FATAL: keine Verbindung
zum EMS-Bus" (oder ähnlich).
Danny Baumann schrieb:> und wenn er es schon tut, sollte er doch vom> Init-System neu gestartet werden?
kenne mich damit nicht so genau aus. Dauert das länger? Hatte eigentlich
gedacht dass der collector nach dem Rechnerstart automatisch startet.
Muss aber immer mit service ems-collector nach dem Booten starten.
dachte durch das eintragen mit „update-rc.d ems-collector defaults“
würde der automatisch starten..
Ingo F. schrieb:>> Wann genau ist 'dann'? Ist der Absturz reproduzierbar?>> Habe es zwei mal ausprobiert. Zweimal sah es so aus als ob der collector> abgestürzt ist. Frontend sagte dannach immer "FATAL: keine Verbindung> zum EMS-Bus" (oder ähnlich).
Was genau hast du an der Stelle gemacht?
> Danny Baumann schrieb:>> und wenn er es schon tut, sollte er doch vom>> Init-System neu gestartet werden?>> kenne mich damit nicht so genau aus. Dauert das länger? Hatte eigentlich> gedacht dass der collector nach dem Rechnerstart automatisch startet.> Muss aber immer mit service ems-collector nach dem Booten starten.>> dachte durch das eintragen mit „update-rc.d ems-collector defaults“> würde der automatisch starten..
Ich bin mir nicht sicher. Ein service ems-collector enable wird das aber
sicherstellen.
Danny Baumann schrieb:> Ich bin mir nicht sicher. Ein service ems-collector enable wird das aber> sicherstellen.
enable kennt er nicht bei mir...
Habe es heute noch mal getestet und kann sagen der Fehler ist nicht
reproduzierbar.
Also muss dass gestern an meinem Rechner oder mit der WLAN-Anbindung
zusammengehangen habe?! Vielleicht habe ich auch mit VI in der Logdatei
herumgespielt als der collector in die Logdatei schreiben wollte.
Also ich habe gestern und heute im Frontend unten eine Zeit von 23:30
auf 23:00 (ohne Enter zu drücken) geändert und oben rechts auf senden
geklickt.
Dann wurde mehrfach 10 3F 00 01 1E gesendet und als Antwort kam immer
die 01
Nach insgesamt etwa 10 Sekunden kommt
*Error while programming!*
In Deinem Log sah es dann etwa so aus:
MESSAGE[01.04.2015 11:33:41]: source 0x00, dest 0x00, type 0x00, offset
0, data: 0x01
IO: Sending bytes 0x10 0x3f 00 0x1 0x1e
IO: Got bytes 0xaa 0x55 0x1 0x1 0x1
Hatt einmal aber auch die Antwort im Log vor dem absenden der Nachricht.
Aber das wird vermutlich am Logging liegen, oder. Beim senden ist kein
Zeitstempel dabei.
Die Bestäütigung müsste so doch richtig sein, oder?
Andere Daten kann ich schreiben.
Beim Frontend gibt es noch das Problem dass beim ändern und lesen der
max.Vorlauftemperatur immer das Offset von 0x23 verwendet wird. Und
nicht das Offset 0x1E aus dem Wiki. Bei meiner RC35 liegt der auch wohl
dort.
Das scheint aber eine schreibgeschütze Stelle im Telegramm zu sein die
immer auf 0x32=50 steht.
Ingo F. schrieb:> In Deinem Log sah es dann etwa so aus:>> MESSAGE[01.04.2015 11:33:41]: source 0x00, dest 0x00, type 0x00, offset> 0, data: 0x01> IO: Sending bytes 0x10 0x3f 00 0x1 0x1e> IO: Got bytes 0xaa 0x55 0x1 0x1 0x1
Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors
;-)
Ich mache aus den ACK und NACK ein Fake-Paket, damit der Parsing-Code
das direkt ohne Spezialfälle verabeiten kann. Das heißt, dass das
Gateway aus dem 0x1 folgendes machen muss:
<source> 0x0b 0xff 0x01
<source> ist dabei das Ziel der letzten Schreiboperation, in deinem
konkreten Fall also 0x10. Für 0x4 gilt das Ganze entsprechend.
Meinen Code dafür kannst du hier finden:
https://github.com/maniac103/ethersex/blob/master/protocols/ems/ems_proto.c#L62
Ich habe das gleich mal im Wiki entsprechend dokumentiert.
> Beim Frontend gibt es noch das Problem dass beim ändern und lesen der> max.Vorlauftemperatur immer das Offset von 0x23 verwendet wird. Und> nicht das Offset 0x1E aus dem Wiki. Bei meiner RC35 liegt der auch wohl> dort.
Soweit ich das sehe, sendet Moosy bei der max. Vorlauftemperatur das
Kommando "hk1 heatflowtemperature <value>", was der Collector auf
Telegramm 61, Datenoffset 15 mappt, was wiederum laut Wiki korrekt ist
(im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen
Offset 20). Wie kommst du auf die 0x23 und die 0x1e? 0x1e = 30 ist - je
nach Zählung - entweder undefiniert oder die Betriebsart, aber auf
keinen Fall die maximale Vorlauftemperatur.
Danny Baumann schrieb:> Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors> ;-)
Wie wird dass den beim NetIO gemacht? sendet der auch so ein
"Pseudo-Frame"?
Sonst müsste das ja auch noch dort geändert werden.
Das heisst also dass die anderen "Schreibbefehle" funktionieren weil
dort die Bestätigung nicht abgewartet wird?
Danny Baumann schrieb:> 0x23 und die 0x1e? 0x1e = 30
weil dort fünf mal ein Schreibbefehl an das Offset 0x23 kommt.
das 0x1E war nur geistige Verwirrung ;-) sollte 0x0F heissen was ja die
15 ist.
Danny Baumann schrieb:> im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen> Offset 20
Hatte auch schon mal überlegt dass komplett zu ändern. Meistens benötigt
man ja auch das Datenoffset und nicht das Telegrammoffset.
Ingo F. schrieb:> Danny Baumann schrieb:>> Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors>> ;-)>> Wie wird dass den beim NetIO gemacht? sendet der auch so ein> "Pseudo-Frame"?
Ja klar, sonst hätte ich doch den Collector nicht so gebaut :) Die
Stelle im Code, die dieses Fake-Telegramm erzeugt, hatte ich ja schon
verlinkt.
> Das heisst also dass die anderen "Schreibbefehle" funktionieren weil> dort die Bestätigung nicht abgewartet wird?
Ich weiß aus dem Stegreif nicht, was Moosy da tut, aber ich vermute mal,
dass das stimmt. 'Einteilige' Zugriffe funktionieren, mehrteilige nicht.
> Danny Baumann schrieb:>> 0x23 und die 0x1e? 0x1e = 30>> weil dort fünf mal ein Schreibbefehl an das Offset 0x23 kommt.
Kann ich dafür bitte ein Log haben? Ich finde spontan keine Referenz auf
Offset 0x23 bzw. 35 im Code.
> Danny Baumann schrieb:>> im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen>> Offset 20>> Hatte auch schon mal überlegt dass komplett zu ändern. Meistens benötigt> man ja auch das Datenoffset und nicht das Telegrammoffset.
Jup. Ich werde das mal umstellen, wenn ich mal die Zeit finde.
> Kann ich dafür bitte ein Log haben? Ich finde spontan keine Referenz auf> Offset 0x23 bzw. 35 im Code.
Sicher.. Aber vor Montag/Dienstag wird sich nichts mehr tun..
Danny Baumann schrieb:> Ich finde spontan keine Referenz auf> Offset 0x23 bzw. 35 im Code.
Moin die Herren,
0x3D->0x23 ist die maximale Vorlauftremperatur speziell für
Fußbodenheizung (RC35 only). Ist ein anderes Heizsystem eingestellt,
muss der bekannte Offset benutzt werden.
Schöne Ostern.
//Niffko
Niffko _ schrieb:> 0x3D->0x23 ist die maximale Vorlauftremperatur speziell für> Fußbodenheizung (RC35 only). Ist ein anderes Heizsystem eingestellt,> muss der bekannte Offset benutzt werden.
Danke für die Erinnerung. Dann ist klar dass ich das nicht sehe, weil
ich das erst vor kurzem (noch nicht vollständig) umgestellt habe und
Moosy vorher immer 0x23 verwendet hat. Das ist ein noch offenes TODO.
> Schöne Ostern.
Danke gleichfalls :)
Danny Baumann schrieb:>> Schöne Ostern.
Wünsche ich auch allen..
Danny Baumann schrieb:> Ja klar, sonst hätte ich doch den Collector nicht so gebaut :) Die> Stelle im Code, die dieses Fake-Telegramm erzeugt, hatte ich ja schon> verlinkt.
Hatte das mal wieder falsch verstanden. Dachte es wäre der
Collcetor-Code und nicht vom NetIO.
Also beim EMS-Gateway wird jetzt auch das ACK/NACK richtig zum Collcetor
gesendet z.B.: AA 55 04 10 0B FF 01 E5
Schreiben klappt jetzt auch mit dem EMS-Gateway über Moosys Frontend.
Noch mal eine Frage zum PseudoTelegramm vom NetIO.
Werden andere NACK/ACK herausgefiltert? Oder was passiert dann?
Es könnte ja passieren dass der collector und ein anderer direkter
EMS-Busteilnehmer an den selben Teilnehmer einen Set-Befehl sendet. Wenn
einer mit ACK und der andere mit NACK betsätigt wird kann es ja zu
Problemen kommen. Welches ist jetzt für den collector?
Gibt zwei Möglichkeiten: Andere Bestätigungen komplett rausfiltern oder
alle ACK NACK die kommen mit 0x00 statt der Adresse im Pseudotelegramm
zu setzen. Damit wäre ein unterscheiden wieder möglich.
Danny Baumann schrieb:> Moosy vorher immer 0x23
Wo ist denn das aktuelle Frontend? dass von Moosy oder irgend ein Fork
davon? Auf dem Master sind ja schon lange keine Aktivitäten mehr, oder
habe ich die Übersicht bei GIT falsch interpretiert?
@Danny, würde gerne meine anderen Telegramme auch über den Collector
laufen lassen. Wie könnte ich am besten andere Telegramme über den
Collector abarbeiten lassen?
Also am einfachsten wäre eine Abarbeitung über eine extra
Quellcode-Datei?
Möchte ja nicht jedesmal wenn Du was am collector änderst auch den
ganzen Code an meinem Fork ändern.
Ein Telegramm sieht z.B. so aus:
81 11 23 45 00 08 0f 00 16 0d 42 09 15 0a
(Extended-CAN. Normales Standart-CAN = 0x80)
Sind ein paar 1Wire-Sensoren und andere Daten die ich auch in eine
MySQL-Datenbank schieben würde.
Ingo F. schrieb:> Noch mal eine Frage zum PseudoTelegramm vom NetIO.> Werden andere NACK/ACK herausgefiltert? Oder was passiert dann?
Die werden ignoriert.
> Es könnte ja passieren dass der collector und ein anderer direkter> EMS-Busteilnehmer an den selben Teilnehmer einen Set-Befehl sendet. Wenn> einer mit ACK und der andere mit NACK betsätigt wird kann es ja zu> Problemen kommen. Welches ist jetzt für den collector?
Wenn das NETIO gerade einen Befehl abgesetzt hat (nachdem es vom Master
dazu aufgefordert wurde), weiß es, dass das nächste ACK oder NACK das
kommt, die Antwort auf den Befehl ist. Jemand anderes kann in diesem
Moment nix senden (zumindest nicht, wenn er sich korrekt verhält), da er
ja nicht 'dran' ist.
> Gibt zwei Möglichkeiten: Andere Bestätigungen komplett rausfiltern oder> alle ACK NACK die kommen mit 0x00 statt der Adresse im Pseudotelegramm> zu setzen. Damit wäre ein unterscheiden wieder möglich.
Ja, oder die (N)ACKs denen zuordnen, die zuletzt kommuniziert haben. Ist
aber IMHO sinnlos, da diese Antworten ohnehin uninteressant sind.
> Danny Baumann schrieb:>> Moosy vorher immer 0x23>> Wo ist denn das aktuelle Frontend? dass von Moosy oder irgend ein Fork> davon? Auf dem Master sind ja schon lange keine Aktivitäten mehr, oder> habe ich die Übersicht bei GIT falsch interpretiert?
Ja, das von Moosy, und nein, das hast du schon richtig gesehen. Ich habe
das Interface zwischen Collector und Frontend allerdings auch ewig nicht
(inkompatibel) verändert, so dass diesbezüglich keine Änderungen nötig
waren. Meine Ausführungen bzgl. 0x23 bezogen sich auf die
Implementierung des Auslegungstemperaturkommandos im Collector.
> @Danny, würde gerne meine anderen Telegramme auch über den Collector> laufen lassen. Wie könnte ich am besten andere Telegramme über den> Collector abarbeiten lassen?
Mit einer neuen Message-Klasse, die im IOHandler entsprechend angelegt
wird. Dafür braucht es natürlich ein Unterscheidungsmerkmal zu den
EMS-Telegrammen.
> Also am einfachsten wäre eine Abarbeitung über eine extra> Quellcode-Datei?> Möchte ja nicht jedesmal wenn Du was am collector änderst auch den> ganzen Code an meinem Fork ändern.
Naja, das wäre im Zweifelsfall auch kein größeres Problem. 'git merge'
ist recht mächtig :)
> Ein Telegramm sieht z.B. so aus:> 81 11 23 45 00 08 0f 00 16 0d 42 09 15 0a
Ich überblicke das Format zwar spontan nicht, aber ich muss es ja auch
nicht implementieren ;)
Hallo zusammen,
nachdem ich das Thema NETIO und EMS schon seit Jahresanfang beobachte,
habe ich mir nun auch eine eigene Platine mit AVR und EMS-Anschaltung
gebaut.
Das Empfangen funktioniert nun auch schon mehrere Wochen prima, die
Werte werden einwandfrei in fhem mithilfe des collectord
mitprotokolliert.
Nun wollte ich mal das Senden testen und - es klappt nicht.
Ich habe in ethersex den EMS-Code mit Debugging etwas erweitert und
gesehen, daß ca. alle 3 Sek. auf die Adresse 0x0B reagiert wird und das
gleiche Byte auch wieder rausgeschickt wird. Auch längere Codesequenzen
werden (zumindest vom Controller aus) verschickt.
Aber z.B. ein einfaches "getversion" läuft auf Timeout.
Nun habe ich mein Oszi rangeklemmt und etwas seltsame Kurven angezeigt
bekommen. Meiner Meinung nach zieht der Transistor mit den Widerständen
(4x910 Ohm) den Bus nicht weit genug runter. Ich bin bei den
Widerständen bis auf (Gesamtwiderstand) 100 Ohm runtergegangen - kein
Erfolg.
Siehe Bilder anbei.
Die gelbe Kurve ist am Kollektor des BC847B gemessen, die grüne Kurve
hinter den Widerständen zu den Dioden hin (zwei Rote Kreise im Bild P0).
Man sieht den Empfang eines Bytes und dann den Echoversuch.
Bei der Messung P1 waren 3x470 Ohm parallel geschaltet, beim Bild P2
dann noch mehr (Gesamtwiderstand 100 Ohm), bei P3 wieder Original 2x470,
aber mit höherem Kondensatorwert (1.5nF SMD + 2,7nf MKS
parallelgeschaltet).
Der Bus kann doch nicht so viel Strom liefern?
Ich habe eine Logamax plus GB 172-14 mit RC300 dran.
Weiss jemand Rat?
Viele Grüße,
Martin
Noch ein Nachtrag.
Im Thread Beitrag "Re: Logamatic 2107 Schnittstelle" wird u.a.
davon berichtet, daß die RC30 auf dem Bus nur mit 0,5 bis 1V sendet.
Dann würde bei mir die Hardware ja funktionieren.
Kann das jemand bestätigen, daß nur mit so geringem Spannungshub
gesendet wird?
Viele Grüße,
Martin
Moin Martin,
beim Senden ist der Spannungshub nicht entscheidend. Wir haben
irgendwann mal den Konsens gefunden, dass das Senden über eine
Stromschnittstelle läuft. Dies erklärt auch, warum der Master simultan
empfangen und Echos auf den Bus absetzten kann. Er empfängt über
Stromschnittstelle und echot über Spannungsschnittstelle.
//Niffko
Martin Patzel schrieb:> Ich habe in ethersex den EMS-Code mit Debugging etwas erweitert und> gesehen, daß ca. alle 3 Sek. auf die Adresse 0x0B reagiert wird
Da ist schon der Fehler. Am Anfang wird nach mehreren Sekunden jede
Busadresse abgefragt. Auch die nicht mit dem EMS-Bus verbunden sind.
Sobald ein Polling beantwortet wurde wird diese Busadresse regelmäßig
abgefragt.
Bei mir ist es gerade fünf mal in der Sekunde (~200ms).
Was zeigt denn bei dir die RC30/35/300. Wenn das stimmt dürfte die
Adresse 11 (0x0B) dort nicht im Busstatus auftauchen.
Entweder stimmt wirklich was nicht mit der Sendefunktion, oder Deine
Code-Erweiterung funktioniert nicht bei jedem Polling.
Der Sendepegel beim senden ist wirklich so schwach. Das ist ganz normal.
Wichtig ist nur dass das die gesendete PollingAntwort vom NetIO auch vom
Bus widerholt wird. Jedes gesendete Byte von EMS-Bus-Teilnehmern wird
vom Master sofort widerholt. Deine gesendeten Bytes sieht ohne das Echo
nur der Busmaster (BC10/MC10?). Wenn Du den Bildausschnitt von deinem
DOS etwas weiter nach rechts verschieben könntest solltest Du diese Echo
auch sehen.
Ein Beispiel für die Sendefunktion ist hier zu sehen:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-telegramme
Einfach mal auf das erste Bild klicken und dann nochmals klicken um es
in voller Größe zu sehen. Unten ist jeweils die Senderichtung (vor der
"Sendestufe") und darüber ist das EMS-Bus-Echo. Auf Deinem DSO solltest
Du dann noch deine "schwachen" Sendeversuche auf dem EMS-Bus sehen.
Dieses Sendeversuche sind dort nicht zu sehen weil der Logiktester nur
High und Low augenommen hat und keine Spannungswerte.
Habe auch mal mein kleines collector-Test-Tool in den Softwaredownload
vom Wiki gestellt.
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:software_download
vielleicht hilft es ja ein wenig...
Gruß
Ingo
Hallo Ingo,
anbei nochmal ein kompletteres Bild. Sieht ähnlich aus, wie auf dem von
Dir beschriebenen, aber nicht ganz...
Zum Coding im Ethersex nochmal: da habe ich nur Debugging dazugebaut.
Am Ablauf mit Senden/Empfangen habe ich nichts geändert.
Auf dem Bild sieht man, daß der Master das 0x0B sendet, dann (länger als
im Beispielbild) den Bus auf High beläßt und anschließend vermutlich ein
Break (langes Low) sendet (gleich wie im Beispiel).
Dann sendet meine Schaltung das 0x0B. Das wird im Unterschied zum
Beispiel nicht sofort vom Master wiederholt, sondern erst nach einer
kurzen High-Phase des Busses. Zum Abschluß des Master-Echos sendet dann
mein Ethersex nochmals einen kurzen Impuls - ist das überhaupt korrekt??
Dann ist Ruhe auf dem Bus.
In meiner RC300 sehe ich als Busteilnehmer nur die RC300 selbst und den
Basiscontroller BC25.
Jetzt werde ich nochmal ans Debugging in Ethersex ran gehen.
Viele Grüße,
Martin
Martin Patzel schrieb:> Dann sendet meine Schaltung das 0x0B. Das wird im Unterschied zum> Beispiel nicht sofort vom Master wiederholt, sondern erst nach einer> kurzen High-Phase des Busses. Zum Abschluß des Master-Echos sendet dann> mein Ethersex nochmals einen kurzen Impuls - ist das überhaupt korrekt??> Dann ist Ruhe auf dem Bus.
An der Stelle, an der du den kurzen Impuls siehst, sollte ein Break
gesendet werden. Überprüfe mal, ob du den Pin EMS_UART_TX richtig ins
Pinning eingetragen hast.
Siehe
https://github.com/maniac103/ethersex/blob/master/pinning/hardware/netio.m4
Zeile 89 bis 91
Hallo Danny,
ja, Pinning stimmt:
dnl
dnl port config for EMS, pin must match USART1 TX line
dnl
ifdef(`conf_EMS', `
pin(EMS_UART_TX, PD3)
')
ifdef(`conf_STATUSLED_EMS_TX', `
pin(STATUSLED_EMS_TX, PD4, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_OK', `
pin(STATUSLED_EMS_RX_OK, PD5, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_FAIL', `
pin(STATUSLED_EMS_RX_FAIL, PD6, OUTPUT)
')
ansonsten würde das Senden ja wohl generell nicht funktionieren?
Viele Grüße,
Martin
Martin Patzel schrieb:> Hallo Danny,>> ja, Pinning stimmt:>> dnl> dnl port config for EMS, pin must match USART1 TX line> dnl> ifdef(`conf_EMS', `> pin(EMS_UART_TX, PD3)> ')> ansonsten würde das Senden ja wohl generell nicht funktionieren?
Das stimmt so nicht, EMS_UART_TX wird nur und ausschließlich für die
Break Condition verwendet. In diesem Umfeld würde ich auf alle Fälle
debuggen. Zum Senden des Breaks wird der Transmitter ausgeschaltet,
womit der Pin als normaler GPIO arbeitet, und der wurde bei der
Initialisierung auf Output + Low gescchaltet
Du kannst ja spaßeshalber das ganze mal testen: usart_init() aus
kommentieren und sicherstellen, dass ein Pullup an der TX-Leitung
anliegt -> Ausgang sollte Dauer-Low sein. Mach das aber nicht am EMS :)
Sendet der NetIO sooo schnell nach dem Break vom Polling?
Wäre da nicht etwas mehr Pause schöner?
Aber dass scheint den EMS-Bus ja nicht zu stören..
Auf jeden Fall liegt es am Break was da wohl kommen sollte..
Der Tipp mit dem Break war Gold wert!!!
Daran lags. Problem ist: Bei mir läuft der AVR mit 20 MHz. Das hat in
der Berechnung von BIT_TIME in ems_uart.c zu einem berechneten Wert von
260 geführt - ist natürlich zu viel für 8 Bit.
Drum war bei mir der Break dann auch so kurz.
Als Quick-und Dirty-Hack habe ich BIT_TIME halbiert und dafür den Break
dann 22 Bit breit gemacht. Kommt zeitlich dann auf's Gleiche raus.
Und siehe da - meine Heizung redet mit mir.
Vielen Dank für die Hilfe! Echt toll, was ihr da auf die Beine gestellt
habt!
Jetzt kann ich weiter basteln...
Viele Grüße,
Martin
Hallo,
ich habe jetzt Probleme mit Moosys Frontend.
Also EMS-Collector habe ich kompiliert und erfolgreich installiert.
Telnet auf 7777 klappt.
Moosys EMS-Tools habe ich auch erfolgreich installiert. Das
CLI-Interface klappt auch mit dem ems-collector.
Dann habe ich Moosys webinterface/frontend installiert.
PHP läuft (mit test.php getestet) und die Webseite wird auch so weit
angezeigt. Habe mal die Bilder der Kurven in den graphs-ordner kopiert.
Aber die werden auch nicht angezeigt.
Alle Config-Dateien sind auch richtig angepasst.
Dummerweise findet auf dem EMS-Bus keine Kommunikation statt.
Bei der LiveANsich kommt nur der erste Balken mit 10% und bei den
Schaltpunkten nur 90%
Hat jemand eine Idee was das Problem sein könnte???
> Bei der LiveANsich kommt nur der erste Balken mit 10% und bei den> Schaltpunkten nur 90%
Schau doch mal im Quelltext *.php der Seiten, was nach "progress(10);",
bzw. "progress(90);" an Variablen aufgerufen wird.
Danny Baumann schrieb:> Was sagt denn dein Webserver-Protokoll, im Falle von Apache speziell> error.log?
Nach meinem Log funktioniert der Zugriff nicht auf die emsincludes.
Keine Ahnung warum...
Die Dateien sind vorhanden und haben die selben Rechte und user wie auf
dem anderen Testserver auf dem es funktioniert...
1
[Mon May 25 17:52:11.265865 2015] [:error] [pid 5645] [client 192.168.11.22:61985] PHP Warning: require(/emsincludes/emssetvalue.inc): failed to open stream: Permission denied in /var/www/html/a_emslive.php on line 25, referer: http://192.168.11.33/?seite=main.php
2
[Mon May 25 17:52:11.265962 2015] [:error] [pid 5645] [client 192.168.11.22:61985] PHP Fatal error: require(): Failed opening required '/emsincludes/emssetvalue.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/a_emslive.php on line 25, referer: http://192.168.11.33/?seite=main.php
3
[Mon May 25 17:52:13.135235 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Warning: include(/emsincludes/emsqry.inc): failed to open stream: Permission denied in /var/www/html/a_emssched.php on line 31, referer: http://192.168.11.33/?seite=a_emslive.php
4
[Mon May 25 17:52:13.135325 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Warning: include(): Failed opening '/emsincludes/emsqry.inc' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/a_emssched.php on line 31, referer: http://192.168.11.33/?seite=a_emslive.php
5
[Mon May 25 17:52:13.135394 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Fatal error: Call to undefined function flush_buffers() in /var/www/html/a_emssched.php on line 64, referer: http://192.168.11.33/?seite=a_emslive.php
1
root@ems-server:/emsincludes# ls -la
2
insgesamt 80
3
drwx------ 2 user user 4096 Mai 25 17:47 .
4
drwx------ 7 user user 4096 Mai 24 22:11 ..
5
-rw-r--r-- 1 root root 248 Mai 24 21:18 config.php
Karl M. W. schrieb:> Schau doch mal im Quelltext *.php der Seiten, was nach "progress(10);",> bzw. "progress(90);" an Variablen aufgerufen wird.
Scheint wohl an den emsincludes zu liegen. Das ist die erste Anzeige vom
Fortschrittsbalken.
ingof schrieb:> -rw-r--r-- 1 root root 12859 Mär 3 19:44 emsqry.inc
vorher waren sie auf user:user habe sie dann wie auf dem anderen Server
auf root:root geändert. SIcherheitshalber Apache2 neugestartet.
Hat sich aber nicht geändert...
Hallo Ingo,
wenn ich mich nicht irre ist in Mossys Sourcen eine Datei die nur die
PHP Short Tags verwendet <? statt <?php ...
Danach hat es bei mir geklappt.
Gruß JayKay
Kay F. schrieb:> PHP Short Tags verwendet <? statt <?php ...
Das hatte hatte auch gedauert bis ich das herausgefunden hatte.. Habe
ich aber schon geändert... Keine Ahnung warum er nicht auf die
emsincludes zugreifen kann...
Die Dateien werden angezeigt und lassen sich auch mit "vi
/emsincludes/emsqry.inc" öffnen.
Danny Baumann schrieb:> SELinux aktiv?
Nein, jabe ich auch bisher noch nie was von gehört...
Habe Ubuntu 14.04.2 LTS Ist bei beiden auf einem Laptop installiert.
Auf Laptop wo es im Moment läuft ist es ein 64-Bit und auf dem jetztigen
ein 32-Bit. ABer das sollte ja nichts ändern...
Ja, ist nicht ausführbar. Ist aber auf dem anderen Server auch nicht so.
Un da funktioniert es..
ingof schrieb:> Ist aber auf dem anderen Server auch nicht so.
sollte heissen dass es auf beiden nicht ausführbar ist (x). Aber ist ja
nur eine include-Datei. Die ja nicht ausgeführt werden muss, oder?
Danny Baumann schrieb:> Das Verzeichnis /emsincludes (nicht die Dateien darin) muss ausführbar> sein, da es ansonsten nicht durchsuchbar ist.
Stimmt, da war noch ein Unterschied. Beim neuen Server hatte das
Verzeichnis "includes" die Rechte 700. Habe dann includes und das
"ems-tools" Verzeichnis drüber gleich auch auf "755" gesetzt.
Habe auch Besitzer auf "root:root" geändert.
Nach Apache2 neustart hat sich aber auch nichts geändert...
Also mal eine zusammenfassung:
OK...
Habe den Fehler gefunden.
/home/user/ems/ems-tools/ war noch auf "700" und "user:user".
Hatte das beim letzten Beitrag als letztes geändert. Hatte aber
vergessen den Apache2 neu zu starten.
Nach einem Neustart von Apache kam "FATAL! keine Verbindung".
Dann den ems-collector neugestartet und jetzt scheint es zu laufen.
Aber warum der Ordner darüber auch diese Rechte haben muss ist mir nicht
ganz klar.
der Ordner "user" über den "ems-tools" besitzt immer noch die Rechte
"700" und "user:user"
bei den Graphs Ordner gab es das selbe Problem. Das x ist also bei
Verzeichnissen nicht "ausführbar" sondern "durchsuchen erlaubt". Aber
nur wenn das r auch gesetzt ist...
DANKE an alle
Dear Ingo,
I had same type of problem after an update of my Avira antivirus SW.
When I switch off the antivirus everthing runs fine.
What I understand isthat it has to do with the ob_flush command, when I
comment this out in emsqry.inc the a_emslive.php runs fine, even with
Avira running, however this doesn't help for settings.
Success Maarten
Hello Marten,
I do not know Avira. try to find the logfile and check for errors with
the IP, Port or the collector.
I do not know whats the problem.
If there is an integrated firewall. Then try to set your Port an
IP-address on a white list.
If not try to set the collector / webserver on a whitelist, if possible.
Hallo,
kann ich den Collector auch auf meinem Synology laufen lassen?
Ich habe darüber im Wiki gelesen, aber es soll noch nicht laufen?
Ich würde ungern einen Raspberry installieren...
Meine ersten gehversuche haben noch nicht so ganz geklappt.
Auf der Synology kompilieren geht wegen dem zu alten GCC.
Es muss wohl auf einem Linux-PC kompiliert werden.
Hatte dann auch die Versuche erst mal auf Eis gelegt.
Aber vielleicht können wir ja mal einen Versuch zusammen wagen das dort
zum laufen zu bekommen.
Auf welcher Diskstation möchtest Du es denn zum laufen bekommen?
Gruß
IngoF
Hallo!
Ich nutze die Lösung nun schon lange auf meinem Pi und in bin immer noch
allen, die sowas möglich machen, sehr dankbar!
Zur optimalen Einstellung habe ich Fragen:
Welche Werte sollte man Eurer Meinung für die Parameter auf den Bildern
verwenden, um einen guten Kompromiss zwischen Komfort und Energiesparen
zu erreichen?
Gruß Bernd
IngoF schrieb:> Auf welcher Diskstation möchtest Du es denn zum laufen bekommen?
Hallo Ingo,
ich würde es dann auf einer synology ds215j laufen lassen wollen.
Ich muss mir aber zunächst einen Adapter bauen.
Bevor ich das in Angriff nehme wollte ich wissen ob ich unbedingt einen
Raspberry benötige, oder es auch anders geht.
Alternativ hätte ich noch die Möglichkeit über einen 24/7 Windows PC die
Daten abzufragen. Wie ich gelesen habe, geht dies über Telnet?
Gruß
Dennis
Sagen wir es mal so.
Es sollte machbar sein den CollectorD für die Diskstation zu
kompilieren...
Im Moment habe ich ein altes Notebook und den CollectorD dafür
kompiliert.
Aber das ist nur eine Notlösung und soll hinterher auf meiner 415+
laufen.
Notfalls ist ein RasbPi auch schnell gekauft. Die gibt es ja an jeder
Ecke ;-)
Hallo,
ich habe mir die Hardware auf Basis des AVR-Net-IO mit der
Adapterelektronik für den EMS selbst zusammengebaut und die ethersex
Software aufgespielt.
Die Elektronik funktioniert auch mit dem Testtool für Collector wenn ich
eine Crossover-Netwerk-Verbindung zum PC habe.
Wenn ich die Elektronik aber mit einem Patchkabel an meinen Router
stecke habe ich keine Verbindung. Nicht einmal einen Ping.
Wo könnte denn da der Fehler liegen?
Gruß
Dennis
Hallo,
ich habe es heute geschafft eine Verbindung herzustellen.
Mit dem Testtool kommen Telegramme an... :-)
Ich habe nun mal einen TCP-Client aufgemacht um zu sehen was ich direkt
empfangen kann.
Ich kann das ganze aber noch nicht interpretieren. Gibt es dazu irgendwo
eine Beschreibung?
Gruß
Dennis
Chris schrieb:> Hallo,> ich habe es heute geschafft eine Verbindung herzustellen.> Mit dem Testtool kommen Telegramme an... :-)
Von welchem Testtool sprichst due?
> Ich habe nun mal einen TCP-Client aufgemacht um zu sehen was ich direkt> empfangen kann.> Ich kann das ganze aber noch nicht interpretieren. Gibt es dazu irgendwo> eine Beschreibung?
Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?
Danny B. schrieb:> Von welchem Testtool sprichst due?
Testtool Collector (Testtool für die Collector-Schnitstelle vom NetIO)
Danny B. schrieb:> Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?
Zum AVR-Net-IO auf dem Port 7950.
Es kommen Pakete an, diese sind aber deutlich länger als ich sie beim
Testtool Collector sehe.
Aufgefallen ist mir das die Datenbytes immer durch eine 0 getrennt
gesendet werden.
Aber wie kann ich die Pakete den Telegrammen zuordnen? (wie im Testtool
auf der Rechten Seite)
Werden da noch Befehle an den Net-IO gesendet damit er die Telegramme
des EMS an den Verbundenen Telnet-Teilnehmer weitergibt?
Gruß
Dennis schrieb:> Danny B. schrieb:>> Von welchem Testtool sprichst due?>> Testtool Collector (Testtool für die Collector-Schnitstelle vom NetIO)
Davon habe ich ehrlich gesagt noch nie gehört. Wo findet man das?
> Danny B. schrieb:>> Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?>> Zum AVR-Net-IO auf dem Port 7950.> Es kommen Pakete an, diese sind aber deutlich länger als ich sie beim> Testtool Collector sehe.> Aufgefallen ist mir das die Datenbytes immer durch eine 0 getrennt> gesendet werden.> Aber wie kann ich die Pakete den Telegrammen zuordnen? (wie im Testtool> auf der Rechten Seite)> Werden da noch Befehle an den Net-IO gesendet damit er die Telegramme> des EMS an den Verbundenen Telnet-Teilnehmer weitergibt?
Nein. Der Ethersex-Code blubbert auf Port 7950 immer genau das heraus,
was hier beschrieben ist:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio
... 0xaa 0x55 ist dabei der Trenner zwischen den einzelnen Telegrammen.
Dennis schrieb:> Die Beschreibung hatte ich übersehen, sorry.> Dann werde ich es damit mal probieren... :-)
Hallo,
ich kann inzwischen die Telegramme auslesen und interpretieren.
Was mir nun noch fehlt ist das geziehlte Abfragen bzw. Senden von
Parametern.
Es scheitert glaube ich an der CRC.
Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich
folgendes
0B 10 3F 91 01 01 <CRC>
Wie bildet man denn die CRC?
Bei einer Byteweisen XOR würde als CRC B5 herauskommen, dies scheint
aber nicht zu funktionieren... :-(
Gruß
Dennis
Dennis schrieb:> ich kann inzwischen die Telegramme auslesen und interpretieren.> Was mir nun noch fehlt ist das geziehlte Abfragen bzw. Senden von> Parametern.>> Es scheitert glaube ich an der CRC.> Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich> folgendes>> 0B 10 3F 91 01 01 <CRC>>> Wie bildet man denn die CRC?> Bei einer Byteweisen XOR würde als CRC B5 herauskommen, dies scheint> aber nicht zu funktionieren... :-(
Benutzt du nicht Ethersex? Wenn ja, brauchst du da doch keine CRC beim
Senden?
(Gibt es einen speziellen Grund, warum dunnicht den Collector verwenden
willst? Der abstrahiert diese Dinge alle komplett weg...)
Danny B. schrieb:> Benutzt du nicht Ethersex? Wenn ja, brauchst du da doch keine CRC beim> Senden?
Doch, ich habe die Ethersex Firmware aus dem ems-wiki.
Aber ich bekomme keinen Response auf meine Anfragen... (Auch ohne CRC,
wie oben beschrieben)
Mache ich da noch was falsch?? :-(
Danny B. schrieb:> (Gibt es einen speziellen Grund, warum dunnicht den Collector verwenden> willst? Der abstrahiert diese Dinge alle komplett weg...)
Ich habe einen 24/7 PC zur Hausautomation und möchte mir nicht noch
einen RaspberryPi installieren um den EMS abzufragen bzw. zu steuern...
ingof schrieb:> Den Collector habe ich zur Zeit nauch auf einem PC laufe
Ich hatte das so verstanden das der nur auf einem Linux System läuft?
Wie installieren ich den auf einem Windows PC?
Dennis schrieb:> Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich> folgendes>> 0B 10 3F 91 01 01 <CRC>
ich gehe davon aus, dass du den offset (91) aus der wiki hast.
1. du must ihn in hex senden
2. der angegebene offset ist nicht nativ ems, es wird hier der header
mitgezählt. ich weiß jetzt aber nicht, inwieweit ethersex das ausbügelt.
um die partyfunktion für 6h zu aktivieren, muss der rc folgendes über
den bus empfangen: 0B 10 3F 56 06 <CRC> (getestet)
// niffko
Niffko _. schrieb:> 1. du must ihn in hex senden
Du hast Recht, die 91 ist ja dezimal...!
Das teste ich morgen früh gleich mal!
Danke für den Anstoß... ;-)
Dennis schrieb:> Ich hatte das so verstanden das der nur auf einem Linux System läuft?
Ist auch wohl so.. Habe wohl mal wieder zu schnell geschrieben und erst
dann nachgedacht ;-)
Dennis schrieb:> Ich hatte das so verstanden das der nur auf einem Linux System läuft?> Wie installieren ich den auf einem Windows PC?
Prinzipiell sollte der Collector auch auf Windows laufen: Er hat als
Abhängigkeiten nur Boost (gibt's auch für Windows) und mysql++ (kann man
gegebenenfalls rauscompilieren). Ich schau mal, was ich da machen kann,
wenn ich mal Zeit finde.
Niffko _. schrieb:> 2. der angegebene offset ist nicht nativ ems, es wird hier der header> mitgezählt. ich weiß jetzt aber nicht, inwieweit ethersex das ausbügelt.> um die partyfunktion für 6h zu aktivieren, muss der rc folgendes über> den bus empfangen: 0B 10 3F 56 06 <CRC> (getestet)
Ausgebügelt wird da nix. Ethersex fügt die Absenderadresse und die CRC
hinzu, der Rest landet 1:1 auf dem Bus.
Hallo,
ich habe nun die für mich wichtigsten Werte und Steuerungsfunktionen
zusammengesammelt.
Damit ihr auch seht warum ich soviel gefragt habe, hier ein Screenshot
von meinem Testtool...
Werde die Daten nun in die Visualisierung der Hausautomation
implementieren.
Vielen Dank noch einmal an alle! :-)
Gruß
Dennis
Ich habe den Collector mal auf Windows compilierfähig gemacht. Mysql
kann er in diesem Fall nicht, und er läuft nur im Vordergrund; für das
Ausführen als Service braucht man also noch ein Extra-Tool.
Wenn es jemand probieren möchte:
https://www.dropbox.com/s/xmdpncj8xmkmnyw/collectord.exe?dl=0
(etwa 6.3 MB groß, weil ich alles statisch linke, damit man nicht noch
ein DLL-Package braucht)
Hallo,
ich habe mir die AVR-NET IO Platine mit dem Adapter zusammengebaut und
an meiner GB142 getestet. Sie funktioniert! Ich kann empfangen und
senden... :-)
Nun habe ich diese Platine an eine GB132T an den RC-Anschluss
angeschlossen und kann auch Telegramme empfangen. Das senden geht aber
nicht!
In den Monitorwerten (Busteilnehmer) wird mir auch nicht, wie bei der
GB142, der Service-Key (Adresse 11) angezeigt.
Muss man das noch irgendwie aktivieren???
Gruß
Dennis
Dennis schrieb:> Hallo,> ich habe mir die AVR-NET IO Platine mit dem Adapter zusammengebaut und> an meiner GB142 getestet. Sie funktioniert! Ich kann empfangen und> senden... :-)>> Nun habe ich diese Platine an eine GB132T an den RC-Anschluss> angeschlossen und kann auch Telegramme empfangen. Das senden geht aber> nicht!> In den Monitorwerten (Busteilnehmer) wird mir auch nicht, wie bei der> GB142, der Service-Key (Adresse 11) angezeigt.> Muss man das noch irgendwie aktivieren???>> Gruß> Dennis
Das sollte genau wie an der GB142 gehen.
Wenn die Platine angeschlossen wird sollte die MC10 das mitbekommen und
die Adresse häufiger Pollen. Dann wird auch die Platine erkannt und im
RC angezeigt. Wenn die Dort nicht im Raumcontroller steht kann man auch
nicht senden.
Beide haben ja den EMS-Bus. Oder ist an der GB132T eine RC300 oder RC350
angeschlossen? Dann wäre das der EMS+-Bus
IngoF schrieb:> Beide haben ja den EMS-Bus. Oder ist an der GB132T eine RC300 oder RC350> angeschlossen? Dann wäre das der EMS+-Bus
GB132T hat EMS (und funktioniert bei mir einwandfrei)
Danny B. schrieb:> GB132T hat EMS (und funktioniert bei mir einwandfrei)
Ich hatte eine ca. 10m 3x0,75 Leitung angeschlossen. (Vielleicht war es
auch nur 0,5mm2)
Könnte die Verbindung vielleicht nicht gut gewesen sein und ich deshalb
nur Signale empfangen, aber nichts senden?
Gruß
Dennis schrieb:> nur Signale empfangen, aber nichts senden?
Wäre möglich...
Unterscheidet sich denn die EMS-Verkabelung bei den beiden Heizungen
stark?
Wo ist denn die Platine angeschlossen? Direkt an der Heizung oder am
Ende beim Raumcontroller?
Ist dort ein längeres oder anderes Kabel zur RC30/35. Eventuell dann mal
direkt an der Heizung anschließen.
Eventuell mal an der Diagnosebuchse (Stereo Klinkenbuchse) versuchen.
Die +12V dann nicht anschließen. Ich habe gerade die STeckerbelegung ins
Wiki gepackt:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-bus
Dann müsste die Verkabelung außen vor sein?!
Dennis schrieb:> Ich hatte eine ca. 10m 3x0,75 Leitung angeschlossen.
da das senden - anders als das empfangen - über eine stromschnittstelle
realisiert ist, könnte der leitungswiderstand mglw. relevant sein ...
//niffko
Niffko _. schrieb:> könnte der leitungswiderstand mglw. relevant sein ...
Meine RC ist über 20 Meter 0,5mm Kabel angeschlossen und funktioniert
problemlos. Ist aber durchaus möglich dass es daran liegt. Verdrillt
wird das Kabel ja wohl gewesesen sein..
Niffko _. schrieb:> leitungswiderstand
Hallo Ihr EMS'ler,
meine beiden Leitungen, y-förmig von der Heizung abgehend, das
1. NYFAZ, 2*0.75, ca. 12 m, zur RC35
2. NYLHY, 3*0.5, zwei belegt, ca. 15 m, zum NetIO
also beide nicht verdrillt.
Alles funktioniert problemlos, dank Eurer genialen Arbeit!
Ich freue mich jeden Tag drüber!
Gruß aus der Wetterau
Karl M.
ingoF schrieb:> Verdrillt> wird das Kabel ja wohl gewesesen sein..
Hallo,
verdrillt war das Kabel nicht.
An der GB142 verwende ich ein LiYCY 2 × 2 × 0,75 wovon ein Aderpaar für
den EMS-Bus genutzt wird.
Ich werde es zunächst über ein kurzes Kabel über den Klinkenstecker
testen und dann im 2. Step noch einmal ein anderes Kabel an der
RC-Anschluß anschließen.
Das wird aber erst morgen etwas.
Ich werde berichten. Erst einmal danke für die Hilfe!
Gruß
Dennis schrieb:> 2. Step noch einmal ein anderes Kabel an der
Also Laut Handbuchern steht dort nichts von verdrillten Adern.
1
• 100 m mit 0,50 mm2 Leiterquerschnitt
2
• 300 m mit 1,50 mm2 Leiterquerschnitt.
Hatte nur mal bei einem 2-Meter Seriell-Kabel Probleme weil die Adern
nicht oder falsch verdrillt waren.
Allerdings war das auch eine höhere Bitrate und ein schwächerer Pegel.
Hallo,
ich habe heute nun noch einmal versucht eine Verbindung zu der GB132T
herzustellen. Leider hatte ich noch keinen Klinkenstecker, weshalb ich
dann noch einmal ein anderes Kabel angeklemmt habe. Ohne Erfolg!
Selbst mit nur 10cm Kabeln zwischen dem Net-IO und dem orangenen
RC-Stecker kann ich zwar Telegramme empfangen, aber der Servicekey
erscheint nicht bei den Busteilnehmern.
Bei meiner GB142 habe ich die Platine noch einmal getestet, dort geht
alles wie gewünscht.
Woran kann das denn liegen? Kennt die GB132T vielleicht noch gar keinen
Servicekey weil sie eine andere/ältere Firmware hat?
Ich bin gerade ratlos wie ich dem EMS denn nun beibringen kann das nun
ein "Servicekey" vorhanden ist.
Hat von euch vielleicht noch jemand eine Idee??? :-(
Gruß
Danny B. schrieb:> Benutzt du being beiden Brennern die selbe RC3x? Was sind denn deine> Firmwareversionen?
Nein, es ist jeweils eine RC35 vorhanden. Bei der GB132T wurde die RC30
mal gegen eine RC35 getauscht.
Die Versionen sind wie folgt:
GB132T:
RC35 1.06
UBA3 3.02
BCM Version 12
BCM Nummer 1006
BC10 2.01
GB142:
RC35 1.06
UBA3 3.05
BCM Version 14
BCM Nummer 1002
BC10 2.03
Die GB132 ist ein oder 2 Jahre älter als die GB142...
An den Versionen liegt es dann schon mal nicht. Ich habe UBA 2.05, BCM 9
und BC10 2.00. Meine RC35 ist neuer (1.16), aber da 1.06 bei dir an der
GB142 geht, ist es das wohl auch eher nicht.
Die EMS-Adapter-Platine ist in beiden Fällen die selbe, richtig?
Ansonsten fällt mir auch nicht viel ein :(
Danny B. schrieb:> Die EMS-Adapter-Platine ist in beiden Fällen die selbe, richtig?
Ja, das ist die selbe...
Dann kann ich nur hoffen das es am Klinkenstecker geht. Da muss ich mir
aber noch einen Stecker besorgen.
Hast Du die EMS-Adapter-Platine auch an dem orangenen Stecker am
Klemmbrett auf der linken Seite angeschlossen?
Kann ich grad nicht nach schauen; auf alle Fälle hängt die Platine bei
mir an der Leitung, an der auch die RC35 hängt (letztere hängt im
Wohnzimmer, nicht an der Heizung).
Danny B. schrieb:> (letztere hängt im> Wohnzimmer, nicht an der Heizung)
Die RC35 hängt bei mir in beiden Fällen an der Heizung.
Der RC Anschluss wird aber ja bestimmt einfach nur parallel zum Bus
liegen...
Hallo,
Die EMS-Wiki URL hat sich geändert:
http://wiki.thefischer.net
Die alte URL wird noch einge Zeit auch noch funktionieren
Falls noch die alte URL in der Adressleiste erscheint liegt das am Cache
vom Browser.
Gruß
IngoF
Ich habe jetzt nach einigen Problemen mein System mit dem Board von
Jürgen und einem NetIO zum Laufen gebracht. Ich habe eine GB152 mit
RC30. Es gibt 2 Heizkreise, HK1 ist ungemischt, HK2 gemischt. Der
Raumtemperaturfühler am RC30 wird HK2 zugeordnet. Dieser wird an der
RC30 auch richtig angezeigt aber nicht im Frontend. Hier kommt das
berühmte 3200, wobei das auch nicht konstant ist. Bei mir fehlt der
Telegramtyp 0xA3 (bzw. ist nur ganz kurz).
Ich habe jetzt festgestellt, dass 2 Telegramme mit der Raumtemperatur
gelesen werden, einmal für HK1 (mit 0x7d = 3200) und für HK2 ( der
richtige Wert.
IO: Got bytes 0xaa 0x55 0x13 0x10 00 0x3e 00 0x4 00 00 0x7d 00 00 00 0x5
0x5 0xd 00 00 00 00 0x5 0x5f
MESSAGE[24.10.2015 23:47:06]: source 0x10, dest 0x00, type 0x3e, offset
0, data: 0x04 0x00 0x00 0x7d 0x00 0x00 0x00 0x05 0x05 0x0d 0x00 0x00
0x00 0x00 0x05
DATA: Raum-Solltemperatur = 0 °C
DATA: Raum-Isttemperatur = 3200 °C
DATA: HK1-Kennlinie = -10 °C: 5 °C / 0 °C: 5 °C / 10 °C: 13 °C
DATA: HK1-Solltemperatur = 5 °C
IO: Got bytes 0xaa 0x55 0x13 0x10 00 0x48 00 0x4 00 00 00 0xd7 00 00 0x5
0x5 0x9 00 00 00 00 0x5 0x87
MESSAGE[24.10.2015 23:46:06]: source 0x10, dest 0x00, type 0x48, offset
0, data: 0x04 0x00 0x00 0x00 0xd7 0x00 0x00 0x05 0x05 0x09 0x00 0x00
0x00 0x00 0x05
DATA: Raum-Solltemperatur = 0 °C
DATA: Raum-Isttemperatur = 21.5 °C
DATA: HK2-Kennlinie = -10 °C: 5 °C / 0 °C: 5 °C / 10 °C: 9 °C
DATA: HK2-Solltemperatur = 5 °C
Es müsste also der Wert 0x7d für die Raumtemperatur ignoriert werden. An
einem RCxx kann nur ein Raumfühler hängen.
Ist eigentlich geplant, das Web-Frontend mal auf 2 Heizkreise zu
erweitern, oder wie könnte ich statt dem HK1 den HK2 verwenden ?
Andreas Z
Meine Versionen sind wie folgt :
UBA 3.05
BC10 2.02
RC30 2.08
In meinem Repo wird 0x7d00 schon länger ignoriert. Siehe hier:
https://github.com/maniac103/ems-collector/blob/master/collector/EmsMessage.cpp#L586
- d.h. du musst nur mal deinen Collector updaten :)
Aus Telegramm 0xa3 wird nur die gedämpfte Außentemperatur entnommen, es
ist also OK, wenn dieses Telegramm nur kurz ist.
An einer Unterstützung für HK2 im Frontend wäre ich auch interessiert,
habe aber leider keine Zeit, das selber zu machen.
@ Danny
Vielen Dank für die Hilfe. Ich habe den Collector von Moosy verwendet,
da ist das nicht drin. Ich habe heute Nacht noch eine andere Lösung
gefunden. Beim Subtype HK1 parse ich die Raumtemperatur einfach nicht.
Was ist denn der Unterschied / Vorteil der beiden verschiedenen
"Collectoren" ?
Für jemand der hier neu einsteigt ist es ein bisschen schwierig
einigermaßen durchzublicken.
Trotzdem ist eine tolle Leistung was ihr da auf die Beine gestellt habt.
Ich konnte gestern bei mir schon die Brenneraufzeit verlängern indem ich
die Hysterese erhöht habe.
Jetzt will ich das Ganze noch für die WW-Bereitung machen, da hier kurz
vor erreichen des Sollwertes ganz schönt getaktet wird.
Andreas
Andreas Z. schrieb:> Vielen Dank für die Hilfe. Ich habe den Collector von Moosy verwendet,
Ah, da ist der Fehler ;)
> Was ist denn der Unterschied / Vorteil der beiden verschiedenen> "Collectoren" ?
Vorteil bei meinem Repo ist, dass es aktuell ist :)
Im Ernst: Es gibt inzwischen überhaupt keine Grund mehr, Moosys Repo zu
verwenden. Zwischenzeitlich (aber schon einige Zeit her) hatte er darin
neue Features entwickelt, aber die habe ich inzwischen alle übernommen.
Bugfixes wiederum landen nur in meinem Repo, da Moosy ja inzwischen
'verschwunden' ist.
> Für jemand der hier neu einsteigt ist es ein bisschen schwierig> einigermaßen durchzublicken.
Karl hat mal ein nettes How-To für das 'Standard-Setup' mit dem Net-IO
gemacht: http://wiki.thefischer.net/doku.php?id=wiki:ems:net_io
Wenn du anderweitige Ideen zu einer einsteigerfreundlichen Präsentation
hast, nur raus damit ;)
Danny B. schrieb:> Karl hat mal ein nettes How-To für das 'Standard-Setup' mit dem Net-IO> gemacht: http://wiki.thefischer.net/doku.php?id=wiki:ems:net_io> Wenn du anderweitige Ideen zu einer einsteigerfreundlichen Präsentation> hast, nur raus damit ;)
Hast ja schon den neuen Link genommen.
Leider muss ich gestehen dass dieser Link sehr oft nicht funktioniert.
Habe noch mehr Probleme damit beide Webserver auf eine Domain laufen zu
lassen.
Also bis auf weiteres erst mal der alte Link
in diesem Fall also
http://ems-gateway.myds.me/doku.php?id=wiki:ems:net_io
Allerdings wird diese alte URL auch erst heute abend wieder richtig
funktionieren...
Fall die neue URL funktioniert kann es sein dass man noch auf einer
etwas älteren Sicherheitskopie landet.
Gruß
Ingo
So die EMS-Wiki ist jetzt über die neue Adresse erreichbar:
http://emswiki.thefischer.net
Das Problem war in meinem Firefox-Pofil. Es lief also von Anfang an
Fehlerfrei...
Hallo Danny,
es läuft jetzt alles. Vielen Dank für deine Hilfe.
Kompilieren auf dem Raspberry Pi ist wirklich ein Geduldsspiel. Ich habe
einen ganz alten mit nur 256MB Ram. Der ist wirklich an der Grenze.
Andreas
Andreas Zöller schrieb:> es läuft jetzt alles
... schön! Und der Hintergrund? Dannys Repo, oder was?
> Der ist wirklich an der Grenze.
Beim kompilieren "ja". Ansonsten kann ich das nicht bestätigen. Hab'
auch so einen, der macht noch ein paar andere Dinge (lighty, owfs,
mysql, etc.) nebenbei. :-)
Gruß aus der Wetterau
Danny B. schrieb:> Kann ich grad nicht nach schauen; auf alle Fälle hängt die Platine bei> mir an der Leitung, an der auch die RC35 hängt (letztere hängt im> Wohnzimmer, nicht an der Heizung).
Hallo,
ich habe heute den von Danny beschriebenen Zustand hergestellt.
RaumController über ein Kabel an Klemme RC verbunden.
Dazu parallel die AVR NET-IO Platine.
Ergebnis:
RaumController funktioniert
NET-IO kann nur empfangen, nicht senden!
Monitorwerte "Busteilnehmer" wird kein ServiceKey angezeigt
Wenn nun niemand mehr eine Idee hat werde ich an dieser Stelle wohl
aufgeben müssen! :-(
Gruß
Dennis
Dennis schrieb:> Wenn nun niemand mehr eine Idee hat werde ich an dieser Stelle wohl> aufgeben müssen! :-(
Was hast Du denn für Messmöglichkeiten?
Digitales Seicher Oszilloskop (DSO) oder ähnliches ist vermutlich nicht
vorhanden, oder?
Schon mit dem Klinkenstecker probiert?
Schon seltsam dass es an der einen Heizung funktioniert und an der
anderen nicht.
Was hast Du denn für Busteilnehmer am Bus an der Heizung die nicht
funktioniert? Gibt es da vielleicht schon ähnliche Hardware?
Sind auch alle vier parallel geschalteten Wiederstände im Sendeteil
richtig angelötet. Könnte ja sein dass einer keinen richtigen Kontakt
hat und die andere Anlage nur wegen anderen Toleranzen funktioniert. Hat
die NetiO-Adapterplatine auch vier Widerstände?
Danny, hattest Du nicht auch die Software für den NetIO programmiert?
Gibt es da noch weitere Debugging-Optionen? Könnte man eventuell was
"basteln"?
Das erinnert mich an meine (Marken)-HiFi-Anlage. Bei mir war die extrem
stark am Rauschen. Beim Händler, Nachbarn und Freunden lief die
einwandfrei. Störende Verbraucher waren auch nirgend zu sehen.
Habe nie herausbekommen woran es lag. Musste das nächst größere Modell
kaufen.
Schätze mal die Stromversorgung/Das Netzteil für den NetIO ist das selbe
wie bei an der anderen Anlage, oder?
Vielleicht zum Spass mal mit Batterien ausprobieren?
Irgendwelche Seventuell störenden Geräte sind nicht in Nähe?
Ingo F. schrieb:> Was hast Du denn für Messmöglichkeiten?> Digitales Seicher Oszilloskop (DSO) oder ähnliches ist vermutlich nicht> vorhanden, oder?
Leider nur ein ganz einfaches analoges...
Ingo F. schrieb:> Schon mit dem Klinkenstecker probiert?
Nein, aber da habe ich dann ja auch fast keine Hoffnung mehr...
Ingo F. schrieb:> Was hast Du denn für Busteilnehmer am Bus an der Heizung die nicht> funktioniert? Gibt es da vielleicht schon ähnliche Hardware?
Es sind in beiden Fällen immer eine UBA ein BC10 und ein RC35 vorhanden.
Ingo F. schrieb:> Sind auch alle vier parallel geschalteten Wiederstände im Sendeteil> richtig angelötet. Könnte ja sein dass einer keinen richtigen Kontakt> hat und die andere Anlage nur wegen anderen Toleranzen funktioniert. Hat> die NetiO-Adapterplatine auch vier Widerstände?
Ich habe inzwischen auch 2 Adapterplatinen, bei beiden zeigt sich dieses
Verhalten. Als Transistor wurde ein BC107 verbaut.
Ingo F. schrieb:> Schätze mal die Stromversorgung/Das Netzteil für den NetIO ist das selbe> wie bei an der anderen Anlage, oder?> Vielleicht zum Spass mal mit Batterien ausprobieren?> Irgendwelche Seventuell störenden Geräte sind nicht in Nähe?
Bei der funktionierenden Anlage habe ich es zunächst mit dem USB
Anschluss vom Laptop getestet und nutze nun den USB Anschluss der
Fritzbox als 5V Spannungsversorgung.
Bei der nicht funktionierenden habe ich es nun nur mit dem Laptop
getestet.
Ohne EMS-Bus nimmt die Platine ca. 150mA auf...
Danke das Du Dir die Mühe machst und mir Hilfestellung gibst. :-)
Dennis schrieb:> eider nur ein ganz einfaches analoges...
Na das hilft doch schon mal.
Am besten auf das Eingangssignal des Sendetransistors triggern und sehen
was passiert.
Evtl mit Trenntrafo messen?!
In diesem Beitrag im zweiten Bild sieht man oben das Sendesignal. Der
Busmaster wiederholt dann die Telegramme.
Beitrag "Re: Logamatic 2107 Schnittstelle"
zum generellen Telegrammaufbau:
http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegrammeDennis schrieb:> Nein, aber da habe ich dann ja auch fast keine Hoffnung mehr...
Da hilft nur ein Test um das herauszufinden.
Dennis schrieb:> Bei der funktionierenden Anlage habe ich es zunächst mit dem USB> Anschluss vom Laptop getestet und nutze nun den USB Anschluss der> Fritzbox als 5V Spannungsversorgung.> Bei der nicht funktionierenden habe ich es nun nur mit dem Laptop> getestet.> Ohne EMS-Bus nimmt die Platine ca. 150mA auf...
Na dann sollte das wohl nicht das Problem sein..
Ingo F. schrieb:> Danny, hattest Du nicht auch die Software für den NetIO programmiert?> Gibt es da noch weitere Debugging-Optionen? Könnte man eventuell was> "basteln"?
Nicht wirklich :( Der NetIO-Code schiebt die auf dem Socket empfangenen
Daten einfach in die serielle Schnittstelle rein, wenn er gepollt wird,
da ist keine riesige Logik dahinter. Insofern ist dein Vorschlag, an der
Basis des Sendetransistors zu messen, schon der richtige.
Das einzige relevante, was man an Debugging anschalten könnte, wäre die
EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem
ECMD-Port absetzen; die zweite Zahl hinter 'Packets 1byte' ist dann die
Anzahl, wie oft der Master Adresse 0xb gepollt hat. Wenn das auf 0
bleibt, stimmt etwas an der Heizungs-Konfiguration nicht (kann ich mir
ehrlich gesagt aber nicht vorstellen).
Danny B. schrieb:> Das einzige relevante, was man an Debugging anschalten könnte, wäre die> EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem> ECMD-Port absetzen
Die Option muss ich dann im Ethersex auf 1 setzen und mit kompilieren,
oder?
Aktuell nutze ich nämlich das Hexfile aus dem Wiki...
du könntest, je nach lust und laune, auch noch den bus-stecker testen,
der für den anschluss von funktionsmodulen vorgesehen ist und hinten im
gerät rumfliegt (siehe anhang).
//niffko
Niffko _. schrieb:> du könntest, je nach lust und laune, auch noch den bus-stecker testen,> der für den anschluss von funktionsmodulen vorgesehen ist und hinten im> gerät rumfliegt
Hallo,
ich habe gerade den Net-IO an die hintere Klemme angeschlossen. (Nachdem
wir eine viertel Std. gesucht haben)
Leider wird er immer noch nicht erkannt.
Danny B. schrieb:> Das einzige relevante, was man an Debugging anschalten könnte, wäre die> EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem> ECMD-Port absetzen; die zweite Zahl hinter 'Packets 1byte' ist dann die> Anzahl, wie oft der Master Adresse 0xb gepollt hat. Wenn das auf 0> bleibt, stimmt etwas an der Heizungs-Konfiguration nicht (kann ich mir> ehrlich gesagt aber nicht vorstellen).
Statistik sieht wie folgt aus:
Bytes total:12134
Bytes good:2008
Bytes dropped:0
Packets good:91
Packets bad:0
Packets 1byte:10046 61
Packets ack:0 nack:0
Overflow:0
Max fill:2
Das heißt doch die Adress 0x0b wurde 61x gepollt, oder?
Gruß
So wie Danny das beschrieben hat ist das wohl die Anzahl wie oft die
Busadress 0x0b (11) gepllt wurde.
Wichtig ist allerdings dabei die Zeit.
Es werden alle möglichen Adressen der Reihe nach angepollt. Weiß nicht
mehr wie oft das ist. Meine es wären irgendwas über zwei Sekunden.
Wenn ein Busteilnehmer auf diese Anfrage Antwortet wird kurz darauf das
Polling erhöht und wird mehrmals pro Sekunde gepollt.
Also scheint es wohl Probleme mit dem Sendeteil zu geben.
Der NetIO bekommt das Polling und antwortet darauf.
Wenn ich Danny richtig verstanden habe wird der Counter nur erhöht wenn
der NetIO auf sein Polling sendet.
Also wird wohl kein Weg am Oszilloskop vorbeigehen. Am besten auf das
Sendesignal vom NetIO am NetIO-Ausgang triggern lassen und dann am
EMS-Bus mitloggen. Der EMS-Bus sollte dann um einige Millivolt
zusammenbrechen. Hatte ja den Link zum Oszillogramm genannt.
Ein Test über Klinkenstecker kann auch nciht schaden, wird aber
vermutlich auch kein anderes Ergebnis liefern.
Gruß
Ingo
Ingo F. schrieb:> Wenn ein Busteilnehmer auf diese Anfrage Antwortet wird kurz darauf das> Polling erhöht und wird mehrmals pro Sekunde gepollt.
Dann erscheint der Busteilnehmer auch im RC
Ingo F. schrieb:> Also wird wohl kein Weg am Oszilloskop vorbeigehen
Habe ich gerade schon angeschlossen... :-)
Die Signale des Bus sehe ich.
An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!
Deshalb kommt auch nix auf dem Bus an.
Aber wieso wird der Transistor nicht angesteuert???
Dennis schrieb:> Die Signale des Bus sehe ich.> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!
Hier mal ein Versuch ein Bild von dem Bus (Kanal B) und der
TransistorBasis (Kanal A) zu machen.
Man kann leider nicht ganz so gut die Signale sehen...
Dennis schrieb:> Dennis schrieb:>> Die Signale des Bus sehe ich.>> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!>> Hier mal ein Versuch ein Bild von dem Bus (Kanal B) und der> TransistorBasis (Kanal A) zu machen.> Man kann leider nicht ganz so gut die Signale sehen...
Bei der Y-Auflösung kannst Du dort nichts sehen. Das Signal was gesendet
wird ist unter 1V.
Die X-Auflösung ist auch viel zu klein.
Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen
(kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern.
Aber scheinbar hat es zum triggern gereicht, Aber die Y-Auflösung ist
auch zu gering um was erkennen zu können.
Hallo,
ich implementiert Adapter mit AVR-NET-IO Board für meine Buderus GB112
Kessel mit RC35. Zunächst Ethersex, die aus dem Wiki heruntergeladen
wird, wurde verbrannt und ATmega644P Sicherungen sind festgelegt, wie
beschrieben. Ich überprüfte, dass AVR-NET mit Ethersex läuft
erfolgreich. aber keine LED-Leuchten eingeschaltet am Adapter, wenn ich
ihn zu RC in paralel mit RC35. Ich konnte keine Daten von Testkollektor
nicht sehen, auch.
Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft
es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,
Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem
nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die
Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...
Nochmals vielen Dank für das Projekt gerne ...
PS: Sorry für mein Deutsch
Dennis schrieb:> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!> Deshalb kommt auch nix auf dem Bus an.> Aber wieso wird der Transistor nicht angesteuert???
Was sagt denn der entsprechende Pin auf dem Pfostenstecker?
Taner A. schrieb:> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...> Nochmals vielen Dank für das Projekt gerne ...
Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung
kommen mir zu wenig vor. IIRC sind das doch 12V?
Ingo F. schrieb:> Wichtig ist allerdings dabei die Zeit.> Es werden alle möglichen Adressen der Reihe nach angepollt. Weiß nicht> mehr wie oft das ist. Meine es wären irgendwas über zwei Sekunden.
Mal schnell nachgeschaut:
bei inaktiven Adressen liegt das Polling-Intervall bei ca 1,25sec.
15-11-06 6:47:09 49917.433 83 81 {4} 55 AA 83 81 DD 3E 3C 56 F9 AD F9 02 04 00 |90 00 E5 1A
5
15-11-06 6:47:09 49968.740 83 81 {4} 55 AA 83 81 DD 3E 3C 56 64 76 FA 02 04 00 |90 00 E5 1A
> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung> kommen mir zu wenig vor. IIRC sind das doch 12V?
Hier sind's ca 15V mit einer ESP-Bridge, 13V wenn zwei Bridges
angeschlossen sind. Der Signalhub (eingehend) liegt bei ca 4-5V.
Die ESP-Bridge, die vom EMS-Bus versorgt wird, zieht ca. 50mA.
Ingo F. schrieb:> Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen> (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern.
Ist es nicht so das die Basis vom OP mit 5V angesteuert wird?
Deshalb hatte ich Kanal A mit 5V/d eingestellt...
Als ich es dann wieder abgebaut hatte habe ich auch daran gedacht doch
besser noch einmal den Eingang des OP bzw. den TX-Pin des µC zu messen.
Werde ich heute noch einmal versuchen...
Schade nur das ich den Verlauf nicht speichern kann. :-(
Dennis schrieb:> Ist es nicht so das die Basis vom OP mit 5V angesteuert wird?> Deshalb hatte ich Kanal A mit 5V/d eingestellt
Habe mir gerade mal die Schaltung angesehen.
http://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io#hardware
Normalerweise sollte der OP-Ausgang hochohmig sein und wird über einen
4,7KOhm Widerstand auf +5Volt gezogen. Der OP zieht beim Senden die
Basis vom Transistor auf 0V.
Vermutlich hast Du mit Deiner Messchnur den Eingang auf Dauerhaft-0
gezogen.
Wenn ich das Bild richtig Deute hast Du dort durchgehen 0,17V
Also am besten vor dem OP messen.
Für den EMS-Bus musst Du allerings die Empfindlichkeit erhöhen. Die
Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann
vom Master nochmals für alle wiederholt wird.
Aber die Zeitachse sollte auch weiter auseinander gezogen werden.
Ingo F. schrieb:> Normalerweise sollte der OP-Ausgang hochohmig sein und wird über einen> 4,7KOhm Widerstand auf +5Volt gezogen. Der OP zieht beim Senden die> Basis vom Transistor auf 0V.> Vermutlich hast Du mit Deiner Messchnur den Eingang auf Dauerhaft-0> gezogen.
Das würde ja bedeuten der Bus ist dauerhaft mit den 220 Ohm belastet und
wird beim senden dann "entlastet"?
Ingo F. schrieb:> Die> Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann> vom Master nochmals für alle wiederholt wird.
Wie muss ich mir das vorstellen?
Wie man auf dem Bild sieht wird der Bus von ca. 14,85V bei Telegrammen
auf ca. 14,3V runtergezogen.
Würde man beim senden dann die Telegramme oberhalb der 14,85V Linie
sehen?
Dennis schrieb:> Das würde ja bedeuten der Bus ist dauerhaft mit den 220 Ohm belastet und> wird beim senden dann "entlastet"?
Ups. habe mich vom GND täuschen lassen das oben liegt.
Das ist ein NPN-Transistor. Also die Basis vom Tranistor wird vom OP
dauerhaft auf 0 gezogen. Im Sendefall zieht der 4,7kOhm Widerstand die
Basis hoch. Das bedeutet aber auch dass an der Basis etwa 0,7V abfallen
Dennis schrieb:> Ingo F. schrieb:>> Die>> Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann>> vom Master nochmals für alle wiederholt wird.>> Wie muss ich mir das vorstellen?
Wie in diesem Bild:
https://www.mikrocontroller.net/attachment/191441/EMS_Burst2.jpg
Die Grüne Kurve ist der EMS-Bus. Das große Signal ist der Master und das
kleine Signal oben ist der NetIO
Ingof schrieb:> Die Grüne Kurve ist der EMS-Bus. Das große Signal ist der Master und das> kleine Signal oben ist der NetIO
Man sieht dort zwei Byte Polling. Das wird dann vom NetIO beantwortet.
Der Master widerholt sofort darauf jedes Byte.
insgesamt also 6 Bytes.
Danny B. schrieb:> Taner A. schrieb:>> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft>> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,>> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem>> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die>> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...>> Nochmals vielen Dank für das Projekt gerne ...>> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung> kommen mir zu wenig vor. IIRC sind das doch 12V?
wenn ich ziehen Sie das RC35 ist die Spannung am RC 12 Volt. Aber wie
gesagt, bevor die Spannung ist etwa 5-6 Volt, wenn RC35 verbunden
Taner A. schrieb:> Danny B. schrieb:>>> Taner A. schrieb:>>> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft>>> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,>>> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem>>> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die>>> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...>>> Nochmals vielen Dank für das Projekt gerne ...>>>> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung>> kommen mir zu wenig vor. IIRC sind das doch 12V?>> wenn ich ziehen Sie das RC35 ist die Spannung am RC 12 Volt. Aber wie> gesagt, bevor die Spannung ist etwa 5-6 Volt, wenn RC35 verbunde
Sorry nicht so ganz vertstanden. Am Bus sollte immer etwas über 12 Volt
sein.
Wann sind es 5-6 Volt? Wenn Du die Platine Anschließt? Wenn das so ist
stimmt irgendwas mit der Platine nicht.
Ingo F. schrieb:> Bei der Y-Auflösung kannst Du dort nichts sehen. Das Signal was gesendet> wird ist unter 1V.> Die X-Auflösung ist auch viel zu klein.>> Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen> (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern.>> Aber scheinbar hat es zum triggern gereicht, Aber die Y-Auflösung ist> auch zu gering um was erkennen zu können.
Hallo,
ich habe gerade Vergleichsmessungen zwischen meiner funktionierenden
GB142 und der GB132T gemacht.
Leider kann ich das Scopemeter nicht kleiner als 20ns/d auf der
Zeitachse einstellen.
Ich sehe aber in beiden Fällen ähnliche Signale:
- an der Transistorbasis liegen ca. 60mV an und man sieht dann Peaks von
700mV
- am Pin5 des OP liegen in beiden Fällen ca. 630mV
- an Pin6 des OP liegen ca. 5V und man sieht auch Peaks in Richtung 0V
Einzig der Intervall in der diese Peaks an Basis bzw. TX Ausgang des µC
kommen unterscheidet sich. Vermutlich weil bei der GB142 die Adresse 11
als vorhanden erkannt wurde.
Ohne Speicher Oszilloscop werde ich hier aber wohl nicht mehr weiter
kommen, richtig? Wieviel MHz sollte das Oszilloscope denn können?
Gruß
Ingof schrieb:> Sorry not quite vertstanden. At the bus should always about 12 volts> be.> When there are 5-6 Volt? If you connect the board? If so> Is something wrong with the board.
beim RC35 ist verbunden GB112, die RC voltzahl 5-6 Volt. (der adapter
ist nicht angeschlossen)
RC35 ist mit GB112 mit 20 Meter kabel verbunden ...
@Taner
bad news ... im GB112 arbeitet ein UBA1.5 und der kommuniziert nicht
über EMS. mir ist leider auch nicht bekannt, dass das dort verwendete
protokoll schon "reversed" wurde.
//niffko
Niffko _. schrieb:> @Taner> bad news ... im GB112 arbeitet ein UBA1.5 und der kommuniziert nicht> über EMS. mir ist leider auch nicht bekannt, dass das dort verwendete> protokoll schon "reversed" wurde.>> //niffko
Oooopsss.... :(
gibt es eine andere andere Protokoll vom RC35 verwendet?
soweit ich weiß, RC35 nutzen nur EMS-Bus
Taner A. schrieb:> Ingof schrieb:>> Sorry not quite vertstanden.
do you use google-translator?
I think it is better to write in english.
Do you have 12V at the bus if nothing is connected?
And if you connect the RC35 there are at first 12V and after a while
there is only 5V?
In the RC35 manual i can only find the EMS-Bus.
Maybe the RC35 switches to an other Bussystem.
But it seems that the RC35 changes the bussystem.
gb112 definitely cant't talk ems! there's a reason why rc35 can handle
this. rc35 is the replacement unit for the obsolete erc-controller, so
it can switch protocol and hw-interface. rc30 can neither be plugged on
pre-ems systems.
//niffko
Ingof schrieb:> Do you use Google translator?> I think it is better to write in English.>> Do you have 12V at the bus if nothing is connected?> And if you connect the RC35 there are at first 12V and after a while> there is only 5V?>> In the RC35 Manual I Can Only Find the EMS bus.> Maybe the RC35 switches to an other bus system.>> But It Seems That the RC35 changes the bus system
Yes that's right. First 12V, after I connect GB112 RC to RC35, it
reduces to 5-6 volts.
Niffko _. schrieb:> GB112 definitely cant't talk ems! There's a reason why RC35 can handle> this. RC35 is the replacement unit for the obsolete ERC controller, so> it can switch protocol and hardware interface. RC30 can neither be> plugged on pre-ems system.>> // niffko
Thanks for the info, niffko.
But km200 web system can talk with rc35 (I think via ems) so that, when
rc35 is connected to gb112, can I talk with rc35 via ems ?
not sure i get you right, but both km200 and rc35 are in fact
bus-clients. bus functionality is provided by the burner-automat acting
as bus-master (UBA1.5 in your case, non-ems). so if there's no
ems-bus-master, no client can talk ems to one another.
//niffko
Hallo, ich benutze vom Ingo die EMS-Gateway Hardware, mit ENC28J60
Netzwerkmodul. Mich würde interessieren wie ich die Seite
"ems-php-webinterface-master" benutzen kann. Ich habe kein Raspi. Ist es
möglich direkt vom PC mit der Web-Seite über Gateway auf die Heizung
zuzugreifen? Wie gebe ich den Port und die IP-Adresse ein? Kann man auch
die Heizungseinstellungen vornehmen? Benötige ich evtl. noch den
ems-collector?
Ja, genauso läuft es bei mir....
EMS–Gateway am Linux-PC mit Collector, Frontend und mySQL. Habe es aber
nicht hinbekommen MySQL und Frontend auf verschiedenen Servern laufen zu
lassen.
Mit dem Windows-PC gibt es laut Danny eine Version ohne MySQL.
Hallo zusammen,
Ich habe versucht nach dem Wiki und den Forenbeiträgen ein System aus
Adapterplatine, AVR NET IO und Raspberry aufzubauen. Leider nur mit
dürftigem Erfolg, denn scheinbar haben alle Teilsysteme Fehler:
1. Adapterplatine
Leider bin ich mit dem Schaltplan und den Layouts weniger gut
zurechtgekommen als meine Vorredner. Meiner Meinung nach hat sich auch
ein Fehler im Eagle Schaltplan oder im Platinenlayout eingeschlichen, da
die Operatoren vertauscht sind. Zumindest passt das Layout nicht zum
Schaltplan. Ich habe mich daher zunächst schwer getan, alle Bauteile auf
dem Layout zu identifizieren. Anbei mein Bestückungsplan und Korrekturen
im Eagle Schaltplan. Wäre schön wenn sich jemand diese ansehen könnte,
da ich wenig Erfahrung habe und vielleicht schon hier ein Fehler liegt.
2. AVR NET IO
2.1. ATMEGA 644P getauscht mit Hex aus dem WIKI geflasht
2.2. Fusebits gebrannt und auch überprüft
2.3. IP und MAC Adresse entsprechenf geändert. Was ist mit dem
Gateway? Trage ich hier meine Routeradresse ein? Sobald ich das mache,
ist mein AVR NET IO selsbt nach einem restart nciht mehr ansprechbar un
einzige Abhilfe ist ihn erneut zu flashen..
Ich habe das Gateway daher zunächst auf dem Standartwert gelassen.
2.4. ethersex page angesprochen : funktioniert
2.5 http://<meineIP>/ecmd?ems%20stats :
mit angeschlossenem Adapter und EMS BUS:
Bytes total:0
Bytes good:0
Bytes dropped:0
Packets good:0
Packets bad:0
Packets 1byte:0 0
Packets ack:0 nack:0
Overflow:0
Max fill:0
mit angeschlossener Platine ohne angeschlossenem EMS BUS:
Bytes total:4470
Bytes good:19
Bytes dropped:0
Packets good:19
Packets bad:838
Packets 1byte:2670 0
Packets ack:0 nack:0
Overflow:0
Max fill:4
Die Platine habe ich überprüft, optisch scheint alles in Ordnung zu
sein. Der EMS Anschluss scheint durch die Dioden verpolunempfindlich,
richtig? Vielleicht habe ich die Platine doch falsch bestückt?
3. Raspberry
später mehr dazu. Ich möchte euch nicht verwirren
Habe noch vergessen zu erwähnen welche Heizungskonfiguration ich
verwende:
Buderus Logamatic U124-11 mit UBA und RC(weder 30 noch 35!!).
Hier die Beschreibung meiner RC:
http://documents.buderus.com/download/pdf/file/5646994.pdf
Ist aber wohl auch ein EMS BUS Gerät.
Seppl F. schrieb:> Buderus Logamatic U124-11 ...
die U124 ist kein ems-gerät. das wird nix, sorry ...
@ingo
ich denke, es wird langsam zeit für eine blacklist in der wiki.
//niffko
Niffko _. schrieb:> Seppl F. schrieb:>> Buderus Logamatic U124-11 ...>> die U124 ist kein ems-gerät. das wird nix, sorry ...>>> @ingo> ich denke, es wird langsam zeit für eine blacklist in der wiki.>>> //niffko
Oh jeh. Das wäre natürlich mehr als ungünstig. Kann es aber immer noch
nicht ganz glauben.
Laut Buderus Kundendienst kann ich meine U124 auf eine RC35
Bedieneinheit umrüsten. Das war mir allerdings zu teuer und auch nicht
ausreichend funktionell, daher habe ich mich nach Alternativen
umgeschaut. So kam ich zum EMS Gateway...
Ich schreibe dem Buderus Kundendienst jetzt erst einmal....
Seppl F. schrieb:> Laut Buderus Kundendienst kann ich meine U124 auf eine RC35> Bedieneinheit umrüsten.
das ist korrekt. heißt aber nicht, dass die kommunikation über ems
erfolgt. siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" .
Seppl F. schrieb:> Ich schreibe dem Buderus Kundendienst jetzt erst einmal....
tust du hier gerade ;)
IngoF schrieb:> [Blacklist]Hoffe ich habe nicht falsches geschrieben...
passt. ich mach mal die komplette liste fertig und stelle sie hier rein.
//niffko
Hatte mir gerade die Serviceanleitung der RC35 durchgelesen und da fiel
es mir wie Schuppen von den Augen. Nachrüstbar heißt, wie du schon
geschrieben hast, nicht zwangsläufig, dass meine Anlage auch EMS
spricht. ?UCK..
Gibt es Erkenntnisse ob man die RC35 als Gateway nutzen kann und sich
mit dem hier beschriebenen System draufsetzen kann?
Hallo Ingo F.,
hallo Zusammen,
ich versuche mich auch an der Anschaltung. Adapterplatine muss ich noch
zusammen bauen, dann ...
Leider bin ich im Wiki (wiki:ems:net_io) auf so manche "Eigenheiten"
gestoßen. Welche ich wohl nicht verstehe. Bzw. mit der Bitte um
Korrektur.
Bei der Ethersex-Software sind die Konfigurationsschritte gut erklärt.
Aber was muss bei
Protocols ---> [*] EMS Support ---> EMS USART
auswählen/eintragen werden? Ich habe dort jetzt eine 1 stehen. Richtig?
Software auf dem Linux-Rechner (Raspian/Debian). Hier fehlt IMHO einige
„-dev“
Wenn man „libmysql++“ installieren will klappt das hier* nicht, weil
apt-get meint alles zu nehmen was libmysql zu tun hat/anfängt. Das war
hier unauflösbar.
(Auch müsste bei libboost1.50-all / libboost1.49-all noch ein „-dev“
dran)
Auf der Wiki-Seite ist zur Datei „/etc/default/ems-collector“ ein
Eintrag falsch:
SERIALDECIVE="tcp:192.168.XXX.XXX"
Dieses sollte sicherlich SERIALDEVICE="tcp:192.168.XXX.XXX:7950" heißen.
(V und C vertauscht und Port nicht vorhanden)
Sonst bekomme ich den collectord nicht am laufen. Bzw. beendet sich
sofort wieder.
Viele Grüße
Olaf
hier* = Rasperry PI mit Raspian 7.8 oder x86er mit Debian 7.9
ingof schrieb:> Mit dem Windows-PC gibt es laut Danny eine Version ohne MySQL.
Hallo Ingo,
ich bekomme keine Verbindung zu ems-php-webinterface-master mit Windows
PC. Gibt es eine Möglichkeit die IP einzustellen? Habe die IP mit
collectord.exe eingegeben. Wie ich Mysql einrichte weiß ich auch nicht.
Ich habe eine kostenlose Website mit bplaced eingerichtet. Außerdem
würde ich auch gerne mit dem Android Handy auf die Werte zugreifen.
Im Moment benutze ich die von mir erweitere HTML Seite von Jürgen S.
Hier kann ich die IP einstellen und auch übers Internet die Werte
abfragen.
Viele Grüße
Franz
Hallo Leute,
habe vor einiger Zeit diesen Thread und das dazugehörige Wiki gefunden
und bin begeistert.
Also habe ich mir die Komponenten bei Pollin und Reichelt bestellt und
habe mit der NetIO Platine dem Flashen des ATmega644P begonnen - und
stoße bereits auf die ersten Probleme :-(
Habe das fertige Hex-File mit PonyProg und einem AMTEL Evaluations-Board
auf den 644P geflasht - auch die Fuses gemäß dem Thread angepasst.
Der Zugriff per LAN funktioniert - ich kann per ECMD Kommando die Werte
(MAC, IP, Gateway etc.) setzen und sie auch per ECMD?reset aktivieren,
doch leider werden die eingestellten Werte nicht dauerhaft gespeichert.
Sobald ich die Spannungsversorgung des NetIO Boards unterbreche
'vergisst' es alle zuvor gemachten Einstellungen und setzt sich wieder
auf die Standardeinstellungen zurück.
Habe schon verschiedene Vorgehensweisen durchprobiert - leider bisher
ohne Erfolg :-(
Hat jemand eine Idee, woran das liegen könnte und was ich machen kann,
um die Netzwerkeinstellungen dauerhaft zu speichern?
Danke für die Unterstützung :-)
piet
Peter W. schrieb:
< ... kann per ECMD Kommando die Werte (MAC, IP, Gateway etc.) setzen
< und sie auch per ECMD?reset aktivieren. ...
Hi Piet,
"reset" weglassen. ;)
hth
Karl M.
Hallo Karl,
vielen Dank für die schnelle Rückmeldung - aber an dem Reset Befehl
liegt es wahrscheinlich nicht.
Wenn ich die Stromversorgung vom NetIO Board mit dem geflashten 644P
einschalte, dann sind die default Netzwerkeinstellungen aktiv.
Ich kann dann mit den ECMD Kommandos über den WEB Browser die
Einstellungen verändern. Die geänderten Einstellungen werden aber nicht
aktiv (bis auf die MAC Adresse).
Bei der Abfrage der geänderten Werte werden immer noch die Default
Einstellungen zurückgegeben (IP, Gateway).
In diesem Thread wird der Hinweis gegeben, dass ein Neustart
erforderlich ist, um die geänderten Einstellungen zu aktivieren. Dies
funktioniert bei mir aber leider nicht. Wenn ich nach der Anpassung die
Stromversorgung unterbreche, sind nach dem Neustart wieder die
Standardeinstellungen aktiv.
Wenn ich nach der Anpassung der Netzwerkeinstellungen den Reset Befehl
sende, dann sind die neuen Einstellungen aktiv - das Board ist dann auch
über die geänderte IP erreichbar und die Abfrage der Parameter über ECMD
liefert auch die geänderten Einstellungen zurück.
Aber ein anschließender Neustart (durch unterbrechender Stromversorgung)
setzt alle Einstellungen wieder zurück.
Bin für jeden Tip dankbar :-)
Viele Grüße
Piet
Hallo Karl, hallo Forum,
frohe Weihnachten 2. Teil an alle ;-)
Bei mir sieht es folgendermaßen aus:
NetIO Adapterplatine direkt verbunden mit dem LAN Anschluss von einem
PC.
Netzwerkadresse am PC auf 192.168.0.1 eingestellt
http://192.168.0.0/ecmd?ip
-> 192.168.0.0
http://192.168.0.0/ecmd?ip 192.168.1.60
-> OK
Reboot
IP Adresse vom PC umstellen auf 192.168.1.61
http://192.168.1.60/ecmd?ip
-> 192.168.1.60
http://192.168.1.60/ecmd?mac
-> ff:ff:ff:ff:ff:ff
http://192.168.1.60/ecmd?mac 00:22:f9:01:d1:e2
-> OK
http://192.168.1.60/ecmd?mac
-> 00:22:f9:01:d1:e2
Reboot
http://192.168.1.60/ecmd?ip
-> Keine Antwort von der Net-IO Platine
IP Adresse vom PC umstellen auf 192.168.0.1
http://192.168.0.0/ecmd?ip
-> 192.168.0.0
Die Platine hat die gemachten Einstellungen 'vergessen'.
Gibt es bei den Einstellungen eine bestimmte Reihenfolge, die
einzuhalten ist?
Ich habe schon verschiedene Varianten ausprobiert, leider bisher ihne
Erfolg. Ich schaffe es nicht, die Netzwerkeinstellungen der NetIO
Platine dauerhaft zu speichern.
Beim Durchtesten der verschiedenen Parameter habe ich festgestellt, dass
ein 'ecmd?reset' die eingestelten Parameter aktiviert - ich kann also
die MAC Adresse, die IP Adresse, die Netzwerkmaske und das Gateway
einstellen und nach einem 'ecmd?reset' sind die eingestelltn Parameter
aktiv und die Platine ist in meinem Netzwerk problemlos erreichbar -
nach einem PowerCycle sind allerdings wieder die Default Einstellungen
aktiv.
Wo genau werden diese Daten eigentlich gespeichert?
Oder kann jemand sagen, an welcher Stelle die Netzwerkparameter in dem
Hex File hinterlegt sind? Dann könnte ich die direkt in das Hex-File
integrieren...
Oder hat jemand noch eine andere Idee, wie ich die Netzwerkparameter
dauerhaft gespeichert bekomme?
Vielen Dank!
piet
Hallo,
ich wollte mich herzlich bei allen beteiligten Personen bedanken.
Gestern habe ich endlich die Platine anschließen können. Provisorisch.
Nach ein paar „Streitigkeiten“ mit meinem Linuxserver läuft heute alles
wie gewünscht.
Vielen Dank!
Viele Grüße
Olaf
Hallo,
Ich habe die EMS-Adapterplatine zweimal vergeblich aufgebaut. Ich habe
leider zwei linke Hände dafür.
Ich bekomme via telnet auf collectord (tcp:7777) nur ein Timeout auf
getversion.
Via ecmd ems stats bleiben alle Werte auf Null.
Der EMS-Bus gehört zu einer GB-172 und sollte prinzipiell funktionieren.
Wenn jemand einmal eine Platine (bestückt oder unbestückt ist egal) an
mich veräußern könnte und sich bei mir meldet, wäre ich sehr dankbar.
Hallo Matthias,
> Via ecmd ems stats bleiben alle Werte auf Null.
Ist in dem NET-IO (o.ä.) ein ATmega644P bzw. ATmeda1284P gesteckt?
(Der ATmega644-20PU ist falsch es muss mindestens der ATmega644P
-20PU sein)
Matthias F. schrieb:> Ist der zweite usart hier entscheidend?
Da ich mal nicht davon ausgehe, dass du die RS232-Buchse samt MAX232
runtergerissen hast: ja, ist sie, da darüber die EMS-Kommunikation
läuft. Wenn du den MAX232 abbaust, kannst du natürlich auch den EMS
daran anschließen und Ethersex entsprechend umkonfigurieren, dann reicht
auch ein 644 ohne P.
Ein frohes neues Jahr wünsche ich.
Danny B. schrieb:> Da ich mal nicht davon ausgehe, dass du die RS232-Buchse samt MAX232> runtergerissen hast: ja, ist sie, da darüber die EMS-Kommunikation> läuft. Wenn du den MAX232 abbaust, kannst du natürlich auch den EMS> daran anschließen und Ethersex entsprechend umkonfigurieren, dann reicht> auch ein 644 ohne P.
Ich habe den MAX232 nun runtergerissen und die Pins des Atmega644 so
verdrahtet:
m644 |LM393P
==================
14 (RXD)PD2 | Pin4
15 (TXD)PD1 | Pin6
Es werden Daten auf dem EMS-Bus empfangen wo auch die Regelung
RC300/GB172 sitzt.
Allerdings kann ich auf dem Bus nicht schreiben.
Bspw. bringt ein 'getversion' in der Konsole des collectord:7777 dann
ein timeout:
```
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
ERRTIMEOUT
```
So etwas kam auch mal rein
```
IO: Got bytes 0xaa 0x55 0x19 0x8 00 0x2a 00 00 00 00 00 00 00 00 0x1 0xd
0x1 0xd 0x80 00 00 0x80 00 0x80 00 0x80 00 00 0x22
MESSAGE[01.01.2016 17:56:33]: source 0x08, dest 0x00, type 0x2a, offset
0, data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x0d 0x01 0x0d 0x80
0x00 0x00 0x80 0x00 0x80 0x00
0x80 0x00 0x00
DATA: Unhandled message received(source 0x08, type 0x2a).
IO: Got bytes 0xaa 0x55 0x17 0x8 00 0x34 00 0x3c 0x2 0x4a 0x2 0x4a 0x21
00 0x1 0x3 00 00 0x2 0x63 00 00 0x5c 00 0x80 00 0x9e
MESSAGE[01.01.2016 17:56:34]: source 0x08, dest 0x00, type 0x34, offset
0, data: 0x3c 0x02 0x4a 0x02 0x4a 0x21 0x00 0x01 0x03 0x00 0x00 0x02
0x63 0x00 0x00 0x5c 0x00 0x80
0x00
```
```
Scheitert es nun an der Pin-Zuordnung? Hardcoded ist es in ethersex ja
nicht. USART0 habe ich unter
Protocols/EMS/UART 0
ausgewählt.
Vielen Dank im Voraus für eure Hilfe.
Wie alt ist dein Ethersex-Checkout, und welches Repo verwendest du? Bis
vor kurzem musste man im Pinning den TX-Pin für die Generierung der
Break-Condition nochmal separat konfigurieren.
Hallo liebe EMS Gemeinde,
habe mir auch die Platine im freien Layout aufgebaut, und ebenfalls das
Problem, das die EMS STATS auch leer sind, es ist aber ein 664p auf
einem AVR NET IO verbaut.
Die Platine habe ich schon zwei mal kontrolliert.
Ich habe das fertige HEX file von der EMS Wiki Seite mit einem MKII und
Atmel Studio 7 programmiert.
Anschliessen habe ich auch die Fuses kontrolliert.
Fuses: low=E7 high=DC ex=FF lock=FF.
Was mich auch etwas stuzig macht unter HTTP://x.x.x.x/adc.ht haben die 8
Kanäle immer so um die 30 %.
Auch wenn ich über das Testcollektor JAVA Tool mal eine Uhrzeit sende
Blinkt keine sende leuchte.
Hat noch jemand eine Idee, oder eine fertige Adapterplatine die getestet
ist zum erweben.
Als Heizkessel ist hier ein LOGAMAX GB132 mit RC30 die auch
Funktionsfähig ist.
Bytes total:3
Bytes good:0
Bytes dropped:0
Packets good:0
Packets bad:0
Packets 1byte:3 0
Packets ack:0 nack:0
Overflow:0
Max fill:1
Hallo Zusammen,
habe mir jetzt (nach Aufsetzen eines Ubuntu Rechners) das Hexfile mit
den richtigen Netzwerkeinstellungen selbst erstellt. Nun funktioniert
die NetIO Platine wir erwartet.
Trotzdem komisch, dass die Netzwerkparameter nicht dauerhaft gespeichert
werden :-(
Nun habe ich leider noch ein Problem bei der Installation der EMSTools
auf dem Raspi.
Ich nutze einen Raspi2 Modell B mit Raspian Jessie.
Die Installation von libmysql++ funktioniert schon nicht. Ich habe die
Meldung mal als Text File angehängt.
Ich habe hier im Forum einen Eintrag gefunden, dass ein '-dev' angehängt
werden muss - also "sudo apt-get install libmysql++-dev" - das ist dann
ohne Fehler durchgelaufen.
Nach der Installation der anderen Pakete, habe ich die Installation der
EMS Tools mit "sudo dpkg --install ./ems-buderus_0-4.deb" gestartet.
Die Installation läuft bis zu einem bestimmten Punkt bei dem Compilieren
des Collectors mit RAW support - da bricht er dann ab (siehe angehängte
Datei).
Ich würde mich über Tips, wie ich das Problem lösen kann, sehr freuen.
Viele Grüße
piet
Wer auch immer das deb-Package erstellt hat, muss sein Makefile
aktualisieren. Da fehlt ein -DHAVE_MYSQL. Der erste Compilevorgang läuft
wahrscheinlich mit meinem Makefile (und funktioniert deshalb), der
zweite Compilevorgang benutzt wahrscheinlich ein eigenes Makefile.
Hallo Danny,
vielen Dank für die Rückmeldung :-)
Das deb-Paket wurde von Lars_r48 erstellt. Was mich nur wundert ist,
dass bisher offensichtlich sonst niemand das Problem hatte - oder kann
es sein, dass es nur bei mir nicht funktioniert?
@Lars_r48
hättest Du Zeit und Lust, das deb-Package anzupassen? Ich würde mich
über eine kurze Rückmeldung freuen, da ich ansonsten versuchen würde,
die Komponenten "zu Fuß" zu installieren.
piet
Ich glaube das ist so alt, da wird einiges nett mehr Funktionieren.
Ich sehe es mir heute Abend mal an, aber da ich es selbst nicht mehr
nutzen kann wegen meiner Rc300 hatte ich es auch aus den Augen verloren.
Hallo,
mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der
644p-20pu der richtige Processor.
low=E7 high=DC ex=FF lock=FF.
Des weiteren wenn ich mit der JAVA Collektor Software sende,
muss dann auf jeden fall die LED Blinken ????
Das tut sie auch nicht.
Danke für eure hilfe
Denis L. schrieb:> mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der> 644p-20pu der richtige Processor.
Der controller passt.
Erstelle das hexfile besser mal selbst aus ethersex'github
Ich habe auch noch das Problem,dass ich keine Daten senden kann. Empfang
klappt aber.
Wahrscheinlich die selbst gebaute Platine...
Wenn da wer mal eine für mich übrig hat, wäre ich sehr froh...
Hallo Forum,
nach einigen Fehlschlägen und einigem Rumprobieren habe ich den
"collectord" nun compiliert bekommen...
Und was soll ich sagen - ES FUNKTIONIERT (weitestgehend) :-)
Ein riesengroßes Dankeschön schonmal an Alle, die hier Fragen
beantworten und Ihre Zeit und Ihr Wissen zur Verfügung stellen!!!
Leider gibt es noch ein paar Dinge, die nicht ganz rund laufen und daher
habe ich noch einige Fragen.
Zunächst mal bekomme ich den "collectord" nicht als Service gestartet.
Beim Versuch passiert folgendes:
1
sudo service ems-collector start
2
Job for ems-collector.service failed. See 'systemctl status ems-collector.service' and 'journalctl -xn' for details.
"Zu Fuß" kann ich den "Collectord" problemlos starten und er empfängt
auch Daten über den NetIO vom EMS Bus.
Die Dazugehörigen Konfigurationsdateien habe ich an diesen Post
angehängt.
/etc/ems-collector.conf
/etc/init.d/ems-collector
/etc/Default/ems-collector
Das "collectord" Binary liegt im Verzeichnig /usr/local/sbin
Vielleicht kann ja jemand helfen...
Vielen Dank und viele Grüße
piet
Was sagt denn journalctl -xn? Ansonsten fällt mir außer der Tatsache,
dass die meisten Parameter (-u, -p, -r, -C, -D) sowohl in OPTIONS als
auch in der Konfigurationsdatei enthalten sind (wozu?) erst mal nicht
viel auf.
Hallo Forum,
so, habe nun noch Moosys WEB Interface installiert. Super Darstellung
der verschiedenen Werte - echt klasse!
Das Problem mit dem collectord als Service besteht immer noch, habe ich
aber erstmal zurückgestellt...
Meine Heizungsanlage ist eine GB132 mit RC30 Controller und 2
Heizkreisen (HK1 Heizkörper, HK2 Fußboden) und Warmwasserboiler.
Ich habe gelesen, dass Moosys WEB Interface nur für einen Heizkreis
gedacht ist (es werden ja auch nur die Werte von HK1 angezeigt).
Hat schonmal jemand die Anpassungen für 2 Heizkreise vorgenommen oder
kann mir jemand einen Tip geben, worauf dabei zu achten ist (kenne mich
leider mit PHP und AJAX nicht aus)?
Leider funktionieren nicht alle Anzeigen im WEB Interface fehlerfrei.
- Keine Temperaturanzeige beim Livestatus (Heizkreis)
- Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B.
fehlen die Temperaturwerte)
- Heizkurve wird nicht angezeigt. Das WEB Interface sagt, die Anlage sei
raumtemperaturgeführt - ich habe im Servicemenü vom RC30 nochmal
kontrolliert, dort ist für beide Heizkreise "keine" Fernbedienung
eingetragen.
- Unter "erweiterte Einstellungen" werden nicht alle Änderungen in das
System übernommen - z.B. "Nachtabsenkung abbrechen unter". Dagegen
werden andere Parameter (z.B. Nachlaufzeit der Kesselpumpe) sehr wohl
übernommen. Hier wird übrigens auch 'raumtemperaturgeführt' angezeigt,
eine Änderung wird aber nicht übernommen.
- Bei der Statistk fehlen immer die Werte in der Letzten Tabelle und die
Graphen werden nicht generiert
Im Anhang mal einige Screenshots von den Anzeigen im WEB Interface.
Viele Grüße
piet
Peter W. schrieb:> Hallo Danny,> vielen Dank für die schnelle Antwort :-)> journalctl -xn sagt: $ sudo journalctl -xn> -- Logs begin at Mon 2016-01-11 20:18:37 CET, end at Mon 2016-01-11> 21:11:24 CET. --> Jan 11 21:10:56 raspi2 ems-collector[2358]: -u [ --db-user ] arg> Database user name> Jan 11 21:10:56 raspi2 ems-collector[2358]: -p [ --db-pass ] arg> Database password> Jan 11 21:10:56 raspi2 ems-collector[2358]: TCP options:> Jan 11 21:10:56 raspi2 ems-collector[2358]: -C [ --command-port ] arg> TCP port for remote command interface (0 to> Jan 11 21:10:56 raspi2 ems-collector[2358]: disable)> Jan 11 21:10:56 raspi2 ems-collector[2358]: -D [ --data-port ] arg> TCP port for broadcasting live sensor data (0 to> Jan 11 21:10:56 raspi2 ems-collector[2358]: disable)> Jan 11 21:10:56 raspi2 ems-collector[2358]: failed!> Stören die doppelt eingetragenen Parameter?
Die Ausgabe deutet schon daraufhin.
> Welche Parameterdatei sollte man nutzen?
Das ist prinzipiell egal, solange man jeden Parameter nur 1x angibt. Ich
persönlich habe alles in ems-collector.conf, d.h. OPTIONS ist bei mir
leer.
> Ich habe gelesen, dass Moosys WEB Interface nur für einen Heizkreis> gedacht ist (es werden ja auch nur die Werte von HK1 angezeigt).> Hat schonmal jemand die Anpassungen für 2 Heizkreise vorgenommen oder
Nicht dass ich wüsste. Ich würde aber auch Interesse daran anmelden.
> kann mir jemand einen Tip geben, worauf dabei zu achten ist (kenne mich> leider mit PHP und AJAX nicht aus)?
Das sind dann leider keine guten Startvoraussetzungen :(
> Leider funktionieren nicht alle Anzeigen im WEB Interface fehlerfrei.>> - Keine Temperaturanzeige beim Livestatus (Heizkreis)
Das hängt an den fehlenden Werten (wird aus 'hk1 daymode', 'hk1
daytemperature' und 'hk1 nighttemperature' bestimmt). Siehe unten.
> - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B.> fehlen die Temperaturwerte)
Das ist teilweise normal und teilweise komisch. Speziell die
Temperaturwerte sollten auf alle Fälle da sein. Probier mal, dich mit
Telnet auf Port 7777 zu verbinden und da das Kommando 'cache fetch hk1'
aufzurufen. Sind dort daymode, daytemperature und nighttemperature
vorhanden? Wenn ja, gucke ich nochmal in Moosy's Code nach, wie er das
verarbeitet. Wenn nein, mache mal bitte folgendes:
- führe den Collector mit den Parametern '-d message' und '-f' aus
- verbinde dich zu Port 7777 (auf einem anderen Terminal)
- 'hk1 requestdata'
- wenn das fertig ist, poste bitte die Debug-Ausgaben des Collectors
> - Heizkurve wird nicht angezeigt. Das WEB Interface sagt, die Anlage sei> raumtemperaturgeführt - ich habe im Servicemenü vom RC30 nochmal> kontrolliert, dort ist für beide Heizkreise "keine" Fernbedienung> eingetragen.
Trag mal 'rc-type = rc30' in die Config ein, dann wird's wahrscheinlich
gehen. Ich sollte mal eine Warnung hinzufügen, wenn dieser Wert nicht
gesetzt ist.
> - Unter "erweiterte Einstellungen" werden nicht alle Änderungen in das> System übernommen - z.B. "Nachtabsenkung abbrechen unter". Dagegen> werden andere Parameter (z.B. Nachlaufzeit der Kesselpumpe) sehr wohl> übernommen. Hier wird übrigens auch 'raumtemperaturgeführt' angezeigt,> eine Änderung wird aber nicht übernommen.
Funktioniert denn z.B. ein 'hk1 reducedmodethreshold 5' auf Port 7777?
> - Bei der Statistk fehlen immer die Werte in der Letzten Tabelle und die> Graphen werden nicht generiert
Wenn die Raumtemperatur nicht gemessen werden kann, kann auch keine
Statistik darüber geführt werden ;-)
Die Graphen habe ich früher über einen Cronjob alle paar Minuten
erzeugt; ich bin mir allerdings nicht sicher, ob das bei Moosy noch
genauso ist.
Peter W. schrieb:> - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B.> fehlen die Temperaturwerte)
Probier mal deine emsdetail.ajax mit der angehängten Version zu
ersetzen.
Hallo Danny,
habe in der /etc/ems-collector.conf den Parameter "rc-type = rc30"
ergänzt und in der /etc/default/ems-collector die Zeile OPTIONS="...."
auskommentiert.
Leider immer noch der gleiche Fehler beim Versuch, den collectord als
Service zu starten...
Habe mal Deine "emsdetail.ajax" genommen - und siehe da, die Werte sind
nun vorhanden...
Ich habe den collectord nun mal mit dem Parameter "-R rc30" gestartet
und nun erkennt er auch, dass das System außentemperaturgeführt
arbeitet. Allerdings wird die Heizkurve immer noch nicht gezeichnet :-(
- ebenso wie die Graphen auf der Statistikseite. Wie lässt ma die denn
per Cron Job zeichnen?
Der Befehl "hk1 reducemodethreshold 5" wird im Telnet Fenster akzeptiert
1
telnet localhost 7777
2
Trying ::1...
3
Trying 127.0.0.1...
4
Connected to localhost.
5
Escape character is '^]'.
6
hk1 reducedmodethreshold 5
7
OK
...aber welchem Wert enspricht dies auf Moosys Webinterface - dem
"Nachts reduzierter Betrieb unter"? Falls ja, dann wird der Wert nicht
übernommen, denn in der Weseite (nach einem Refresh) steht dort wieder 0
Grad.
Wenn ich z.B. den Wert "Nachtabsenkung abbrechen unter" auf der Webseite
auf -5 setze, dann steht unten auf der Seite
1
Wert 'absquit' gesetzt auf '-5'.
Der Wert im Browser auf der Seite "Einstellungen" 'überlebt' auch einen
Reload der Seite - allerdings nicht den Wechsel auf z.B. die Livestatus
Seite und zurück.
Die Heizkreistemperatur auf der Livestatus Seite wird auch trotz des
RC30 Parameters nicht angezeigt - möglicherweise hängt das ja mit den 2
Heizkreisen zusammen...
Habe dann noch den collectord mit den von Dir genannten Parametern
gestartet:
... und in einem anderen Fenster ein Telnet gestartet und den Befehl
'hk1 requestdata' eingegeben - erstaunlicherweise bekomme ich in dem
Telnet Fenster dazu keinen Output...
1
telnet localhost 7777
2
Trying ::1...
3
Trying 127.0.0.1...
4
Connected to localhost.
5
Escape character is '^]'.
6
hk1 requestdata
7
OK
Das Logfile vom collectord enhält nicht viel Informationen - ich habe es
trotzdem mal angehängt - vielleicht sind es ja die entscheidenden Infos
;-)
Viele Grüße
piet
Matthias F. schrieb:> Denis L. schrieb:>> mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der>> 644p-20pu der richtige Processor.>> Der controller passt.> Erstelle das hexfile besser mal selbst aus ethersex'github>> Ich habe auch noch das Problem,dass ich keine Daten senden kann. Empfang> klappt aber.> Wahrscheinlich die selbst gebaute Platine...> Wenn da wer mal eine für mich übrig hat, wäre ich sehr froh...
Ja ich empfange mittlerweile auch endlich mal Daten mit der
Lochrasterplatine, hab mir eine Platine nun Ätzen lassen.
Kannst Du mir ein Hexfile erstellen, hier will die aktuelle Github mir
keins rauswerfen, bekomme immer Fehlermeldungen.
IP 192.168.2.41
SUB 255.255.255.0
GW 192.168.2.1
Das wäre super von euch.
Liebe Grüsse Denis
Zeig mal die Logs her, was da beim Kompilieren schief geht.
Ich habe im Anhang trotzdem mal ein hex-file für 644p@16MHz mit EMS auf
USART1 gebaut. Hardware Pollin-AVR.
Peter W. schrieb:> Hallo Danny,> habe in der /etc/ems-collector.conf den Parameter "rc-type = rc30"> ergänzt und in der /etc/default/ems-collector die Zeile OPTIONS="...."> auskommentiert.>> Leider immer noch der gleiche Fehler beim Versuch, den collectord als> Service zu starten...
Schau doch mal, ob du den kompletten Fehler siehst, wenn du journalctl
-f in einem zweiten Terminal laufen lässt.
> arbeitet. Allerdings wird die Heizkurve immer noch nicht gezeichnet :-(> - ebenso wie die Graphen auf der Statistikseite. Wie lässt ma die denn> per Cron Job zeichnen?
So oder so ähnlich: https://gist.github.com/maniac103/8486528 (zu
/etc/crontab hinzufügen oder als Datei in /etc/cron.d anlegen) ...
ems-gen-graphs.py kommt aus ems-tools/scripts, /var/tmp/heizung
entspricht dem Graph-Verzeichnis aus der Config.
> ...aber welchem Wert enspricht dies auf Moosys Webinterface - dem> "Nachts reduzierter Betrieb unter"?
Genau dem.
> Falls ja, dann wird der Wert nicht> übernommen, denn in der Weseite (nach einem Refresh) steht dort wieder 0> Grad.
Dann gehe ich mal davon aus, dass die RC30 das einfach nicht kann. Dein
Log deutet auch stark darauf hin: Dieser Wert steht in Telegramm 0x3d,
Offset 39, während deine RC30 nur 32 Bytes kennt. Das dürfte dann auch
auf 'Nachtabsenkung abbrechen unter' (Offset 38) und 'Nachts reduzierter
Betrieb unter' (Offset 40) zutreffen.
> Die Heizkreistemperatur auf der Livestatus Seite wird auch trotz des> RC30 Parameters nicht angezeigt - möglicherweise hängt das ja mit den 2> Heizkreisen zusammen...
Nein, da muss es noch eine andere Ursache geben. Moosy fragt einfach
immer nur HK1 ab, HK2 wird ignoriert. Bei mir wird die Temperatur
angezeigt, und ich habe auch 2 Heizkreise.
Erzeugt wird der ausgegebene Wert ja aus diesem Stück Code in
a_emslive.php:
1
$temptemp = getHKInfo("temptemp");
2
if ($temptemp==0){
3
if (getHKInfo("tagbetr")=="on"){
4
$temptemp = getHKInfo("day");
5
} else {
6
$temptemp = getHKInfo("night");
7
}
8
}
"temptemp" ist "hk1 temperatureoverride", "tagbetr" ist "hk1 daymode",
"day" ist "hk1 daytemperature" und "night" ist "hk1 nighttemperature".
Was dabei auffällt, ist dass 'hk1 temperatureoverride' bei dir nicht
vorhanden ist; d.h. dessen Wert ist nicht 0, sondern 'nicht gesetzt'.
Probier doch mal, die 2. Zeile an dieser Stelle so zu schreiben:
1
if (!isset($temptemp) || $temptemp == 0) {
Das sollte wahrscheinlich helfen. Das sind halt die subtilen
Unterschiede zwischen RC30 und RC35 :-/
Hallo Danny,
das Erstellen der Grafiken - auch der Heizkurve - funktioniert nun
einwandfrei. Ich lasse die auch per Cron Job alle 5 Minuten neu
zeichnen. Das Problem war der falsche Pfad zu der MYSQL Socket Datei in
der config.py Datei (da stand mysql.sock statt mysqld.sock)
Im Livestatus wird die Temperatur leider nicht angezeigt. Ich habe
nochmal einen Screenshot davon angehängt.
In der a_emslive.php Datei habe ich das Statement wie von Dir
vorgeschlagen abgeändert - also
1
$temptemp = getHKInfo("temptemp");
2
if (!isset($temptemp) || $temptemp == 0) {
3
if (getHKInfo("tagbetr")=="on"){
4
$temptemp = getHKInfo("day");
5
} else {
6
$temptemp = getHKInfo("night");
7
}
8
}
- aber leider ohne Erfolg.
Zur Sicherheit habe ich noch aus diesem Block alles mal rausgenommen und
nur
1
$temptemp = getHKInfo("day");
dringelassen - die Anzeige auf der Webseite bleibt leider die gleiche -
also "NaN" - wo immer das auch herkommt :-(
Bezüglich des Service Problems habe ich in einem Terminal "sudo
journalctl -f" eingegeben und dann in einem 2. Fenster "sudo service
ems-collector start".
Der Output von "journalctl -f" sieht so aus:
1
Jan 13 17:28:46 raspi2 sudo[28367]: peter : TTY=pts/2 ; PWD=/var/www/ems ; USER=root ; COMMAND=/usr/sbin/service ems-collector start
2
Jan 13 17:28:46 raspi2 sudo[28367]: pam_unix(sudo:session): session opened for user root by peter(uid=0)
3
Jan 13 17:28:47 raspi2 systemd[1]: Starting LSB: EMS collector daemon...
Matthias F. schrieb:> Zeig mal die Logs her, was da beim Kompilieren schief geht.>> Ich habe im Anhang trotzdem mal ein hex-file für 644p@16MHz mit EMS auf> USART1 gebaut. Hardware Pollin-AVR.
Danke für die Compilierung.
Warum sind in deinem Hexfile folgende Module unter Showconfig nicht
gelistet.
STATUSLED_EMS_RX_FAIL *
STATUSLED_EMS_RX_OK *
STATUSLED_EMS_TX *
STATUSLED_ERROR *
STATUSLED_RX *
STATUSLED_TX
Gruss Denis
Peter W. schrieb:> Zur Sicherheit habe ich noch aus diesem Block alles mal rausgenommen und> nur
1
$temptemp = getHKInfo("day");
dringelassen - die
> Anzeige auf der Webseite bleibt leider die gleiche - also "NaN" - wo> immer das auch herkommt :-(
Naja, erzeugt wird das ja in Zeile 290:
1
<spanid=cnt>
2
<?php
3
printf("%1.1f",$temptemp);
4
?>
D.h. wenn da NaN steht, ist $temptemp nicht (richtig) gesetzt. Guck doch
mal in den Seitenquelltext (Strg+U) ... was steht da hinter 'var ttemp
='?
> Bezüglich des Service Problems habe ich in einem Terminal "sudo> journalctl -f" eingegeben und dann in einem 2. Fenster "sudo service> ems-collector start".> Für mich sieht das so aus, als würden die Parameter nicht korrekt> übergeben weil die "Usage" angezeigt wird.
Definitiv. Was mir grade einfällt ... du hast gesagt, dass du OPTIONS
komplett auskommentiert hast. An sich auch richtig, aber hast du danach
SERIALDEVICE auf 'tcp:<host>:7950' gesetzt? Wenn nein, mach das mal ;-)
var sources = new Array('heizactive','wwactive','redmode','tagbetr','autobetr','party','day','night','pause','wwtag','wwmode','zirmode','temptemp');
6
var selsources = new Array('party','day','night','pause','wwtag','wwmode','zirmode');
7
var ttempoff = 23 ;
8
var qenabled = new Array();
9
var currsrc = 0;
10
var activereq = false;
11
var activeRequest = false;
12
var uline = "";
13
.
14
.
15
.
was ja eigentlich richtig wäre - oder?
Wenn ich mit "Firebug" den Quelltext anzeigen lasse dann fällt mir auf,
dass die variable "ttempoff" den Wert "23" als String (mit
Anführungszeichen) enthält, wogegen "ttemp" die 23 ohne
Anführungszeichen enthält...
Hat das was zu bedeuten?
Hmm, bei der Funktion dispv() ist schon alles zu spät - die Varialbe
ttemp hat schon den Inhalt NaN...
Ich bin dann wirklich Schritt für Schritt durch das Script getraced und
die ttemp varialbe wird in Zeile 132 von a_emslive.php auf diesen Wer
gesetzt - zuvor hatte sie den Wert 23 (bzw. mittlerweile 17 da die
Anlage schon im Nachtbetrieb läuft...)
Der Code lautet:
1
} else if (src == "temptemp"){
2
ttemp=parseFloat(val);
3
var ttbgcol = document.getElementById("ttbgcol");
4
if (ttemp == 0){
5
ttbgcol.style.backgroundColor="#eeeeee";
6
} else {
7
ttbgcol.style.backgroundColor="#ffffaa";
8
}
und die fragliche Zeile ist die
1
ttemp=parseFloat(val);
wobei die Variable 'val' leer ist.
Weiter vorne im Code, ab Zeile 94, wird die Variable 'val' normalerweise
bestückt.
1
var rline = xmlhttp.responseText.split("\n");
2
for (r=0; r<rline.length; r++){
3
if (rline[r].length < 3) continue;
4
var info = rline[r].split("=");
5
var src = info[0];
6
var val = info[1];
Das Array 'rline' hat bei mir folgenden Inhalt:
1
0 "heizactive="
2
1 "wwactive=on"
3
2 "redmode=aussenhalt"
4
3 "tagbetr=off"
5
4 "autobetr=on"
6
5 "party=0"
7
6 "day=23"
8
7 "night=17"
9
8 "pause=0"
10
9 "wwtag=52"
11
10 "wwmode=auto"
12
11 "zirmode=auto"
13
12 "temptemp="
14
13 ""
und der Variablen 'val' wird der Wert nach dem Gleichheitszeichen
zugewiesen - was bei "temptemp" fehlschlägt...
Ich werde mal weitersuchen...
Denis L. schrieb:> Matthias F. schrieb:>> Zeig mal die Logs her, was da beim Kompilieren schief geht.>>>> Ich habe im Anhang trotzdem mal ein hex-file für 644p@16MHz mit EMS auf>> USART1 gebaut. Hardware Pollin-AVR.>> Danke für die Compilierung.> Warum sind in deinem Hexfile folgende Module unter Showconfig nicht> gelistet.>> STATUSLED_EMS_RX_FAIL *> STATUSLED_EMS_RX_OK *> STATUSLED_EMS_TX *> STATUSLED_ERROR *> STATUSLED_RX *> STATUSLED_TX>>> Gruss Denis
Ich habe keine LEDs installiert.
Neu kompiliertes Hexfile im Anhang.
So long,
Matthias
d.H., für "temptemp" wird "hk1 temperatureoverride" abgefragt, was es ja
bei mir nicht giebt... da schließt sich der Kreis - aber wie komme ich
da raus? Kann man einfach einen anderen Prameter in der 'emsgetinfo.inc'
abfragen? Falls ja, welcher kommt denn in Frage?
Peter W. schrieb:> d.H., für "temptemp" wird "hk1 temperatureoverride" abgefragt, was es ja> bei mir nicht giebt... da schließt sich der Kreis - aber wie komme ich> da raus? Kann man einfach einen anderen Prameter in der 'emsgetinfo.inc'> abfragen? Falls ja, welcher kommt denn in Frage?
Da deine RC die Funktion nicht unterstützt, kannst du keinen anderen
Parameter abfragen. Was aber gehen sollte, ist das print in
emsgetval.ajax so zu ändern:
1
if (isset($inf)) {
2
print($source."=".$inf."\n");
3
}
Was in a_emslive.php auch noch fehlt, ist das Aktualisieren des groß
dargestellten Wertes, wenn sich 'tagbetr', 'day' oder 'night' ändern...
Ich würde mir mal die Zeit wünschen, das 'richtig' zu machen ... d.h.
mit einem Cache aller vom Collector gelieferten Werte in einem Cache
auf Clientseite (d.h. im Javascript) und Ausgabe der Werte rein durch
Javascript. PHP wäre dann nur noch für die Aktualisierung dieses Caches
zuständig (Verbinden zum Collector und Abfragen der Werte). Das dürfte
aber ein größeres Projekt sein :-/
Das erschien mir von allen zur Verfügung stehenden Werten der
geeignetste zu sein. Nun ist die Anzeige auf der Livestatus Seite
richtig - auch der Wechsel zwischen Tag- und Nachttemperatur
funktioniert.
Ich möchte mich nochmal bei Dir für Deine Geduld und Deine große
Unterstützung bedanken :-) Ohne Deine Hilfe hätte ich das nicht so
hinbekommen.
Ich werde hier weiter mitlesen - vielleicht kann ich ja nun auch mal den
einen oder anderen Tip beisteuern...
Ich selbst bin natürlich auch für weitere Hinweise dankbar ;-)
Viele Grüße
piet
Hallo,
ich hab endlich alles am laufen, klasse Arbeit von euch :-).
Ich hab da noch zwei dinge die mich etwas stuzig machen in den ems stats
habe ich ein paar dropped packets
Bytes total:1610670
Bytes good:244151
Bytes dropped:2714
Packets good:13007
Packets bad:1
Packets 1byte:1350830 106353
Packets ack:41 nack:0
Overflow:0
Max fill:4
Ich habe einen 10µf elko genommen kan das daher kommen oder muss es
nicht ein kerko sein.
Das zweite ist ist es möglich von der Idee her noch ein Display auf den
AVR zu packen, um alles neben die Heizung ZUM Montieren.
des weiteren habe ich noch zwei unhandles messages im Protokoll.
DATA Unhandled message received(source 0x10, type 0xa4
kommt immer beim auslesen der einstellungen ich hänge die tage mal ein
logfile hier ins forum.
Grüße Denis
Ach, ich habe wieder mal ein Problem.
Nach einigen Stromausfällen, will sich mein NetIO nicht mehr über die
eingestellte IP ansprechen lassen.
Test mit Original ATMEGA3216PU funktioniert. Komme sowohl mit seriell,
als auch mit LAN drauf.
Steck ich um auf ATMEGA644P oder testweise auf einen ATMEGA644 (hatte
ich noch von einem Fehlkauf, da ohne "P") dann habe ich keinen Zugriff,
selbst wenn ich das HEX-File "ems-netio-644p-deploy" mit Ponyprog
fehlerfrei schreibe. Dort ist die IP dann 192.168.0.0. Meinen PC stelle
ich dann immer auf 192.168.0.100 und 255.255.255.0 ein, aber unter
http://192.168.0.0/ecmd tut sich gar nix (Fehler:Verbindung
fehlgeschlagen)
Ist es theoretisch möglich, dass der NET-IO defekt ist, aber das Problem
nicht mit dem ATMEGA3216PU auftaucht? Oder habt Ihr noch andere Ideen,
was ich testen könnte oder wisst Ihr vlt. auch was die Ursache sein
könnte?
Das der Net-IO die eingestellte IP nach einer Stromunterbrechung
vergisst, hatte ich leider auch schon. Es liegt mit ziemlicher
Sicherheit an der einkompilierte IP-Adresse bzw. daran das der
verwendete PC oder bzw. Switch/Router mit der einkompilierte 192.168.0.0
nicht umgehen kann. Mein Vorschlag wäre ein neues HEX-File mit der
gewünschten IP-Adresse und der passenden Gateway IP zu kompilieren,
damit wäre das Problem für alle Zeiten gelöst. An ansonsten mal einen
anderen Switch/Router verwenden, oder den Net-IO direkt über Ethernet an
den PC anschießen. Die Netzwerkkarte im PC muss dann allerdings Auto
MDI-X können oder du benötigst ein Crosskabel/Crossoverkabel, zusätzlich
musst bei direkter Verbindung Netzwerkeinstellungen also die IP fest
z.B. auf 192.168.0.100 und 255.255.255.0 vorgegeben werden. Wenn du ein
Router zwischen PC und Net-IO hast muss der natürlich auch in den IP
Bereich von 192.168.0.x liegen.
Hallo Martin,
habe heute aus familiären Gründen meine Bastelei aufgegeben ;)
Trotzdem vielen lieben Dank für Deine Hinweise, die ich gern mal
getestet hätte, aber hab Verbot g...
Hallo,
kann ich den ems Collector seine Daten an einen fremdem SQL Server
schicken lassen.
Ich habe keine kommando Übergabe dafür gefunden.
--db-path arg Path or server:port specification of database
server
-u [ --db-user ] arg Database user name
-p [ --db-pass ] arg Database password
Ist das implementiert.
Danke für die Info
Hallo, das ^^ habe ich mich auch schon gefragt. Ich habe mich jetzt in
SQL etwas eingelesen und habe eine Datenbank von 2GB auf bplaced.net
generiert. Ich benutze vom Ingo die Gateway-Platine. Ich habe aber keine
Ahnung wie ich die Daten in die Datenbank bringe und wie die Datenbank
formatiert sein muß. Am liebsten wäre es mir, wenn ich die Daten mit
Ingos Platine entsprechend aufbereiten und direkt in die DB schreiben
könnte. Als Übergangslösung würde ich erstmal den Collector benutzen,
den ich unter Windows nicht zum Laufen gebracht habe.
Denis L. schrieb:> kann ich den ems Collector seine Daten an einen fremdem SQL Server> schicken lassen.
Hatte das schon mal so am laufen. Die NAS war mein SQL-Server und auf
dem Notebook lief der EMS-Collector.
Mein Problem war aber damals dass ich Moosys-Frontend nicht dazu bewegen
konnte eine Verbindung zu einem MySQL-Server auf einem andern Host
aufzubauen.
Hie mal meine aktuelle Konfig /etc/ems-collector.conf:
1
ratelimit = 60
2
rc-type = rc35
3
#db-path = 192.168.1.10:3306
4
#db-path = localhost:3306
5
db-user = ems
6
db-pass = istGeheim
7
command-port = 7777
8
data-port = 7778
Meine die erste sukommentierte Zeile könnte Wunder bewirken.
F. F. schrieb:> Am liebsten wäre es mir, wenn ich die Daten mit> Ingos Platine entsprechend aufbereiten und direkt in die DB schreiben> könnte. Als Übergangslösung würde ich erstmal den Collector benutzen,> den ich unter Windows nicht zum Laufen gebracht habe.
Das war auch ursprünglich mein erster Gedanke.
Aber bin nie dazu gekommen mich damit zu beschäftigen weil ich den
emscollector dann am laufen hatte.
Ich hatte vor dem Collector mal ein Java-Programm dass mir die Daten vom
Windows-PC in eine MySQL-Datnbank schrieb.
Hatte den EMS-Gateway über USB-Serial am Windows-PC angeschlossen und
dann über das Java-Programm die Daten in die MySQL-geschrieben.
Das war aber ein leicht anderes Datenformat. Die Programm sollten noch
im Downloadbereich der EMSWIKI sein. (ems-tools??)
Dabei ist auch ein Prpgramm dass die Daten aus der MySQL ausliest und
grafisch darstellt.
Matthias F. schrieb:> Im EMS-Wiki steht alles drin:
Ups.. ich hatte immer mal vorgehabt das in die Wiki einzutragen...
Habs wohl gemacht und wieder vergessen oder ein anderer hat es
eingetragen.
Hallo IngoF.
ich brauche die Möglichkeit den Collector ohne config file mit einem
fremden Datenbankserver zu verbinden da ich das ganze auf einen Docker
Image Viritualisier.
Der Hintergrund ist ich habe hier die Möglichkeit über die
Visualisierung direct SQL anzusprechen und abzufragen.
Also das ganze sollte nachher so aussehen.
docker Image nur Collector.
Nas mit Webserver und SQL Server und einer Gebäudeleittechnik Visu.
Deshalb wäre es interresant ob ich den DB-Connect direkt an der Konsole
weitergeben kann ohne conf file.
Also eigentlich brauche ich nur den Kommandozeilenparameter für den sql
connct.
Danke und Gruß
Denis
Denis L. schrieb:> docker Image nur Collector.
Habe docker zum ersten mal gehört...
Warum kann man dort keine Config-Datei benutzen?
Notfalls einfach die .PHP .py Dateien vom collector nach dem Datenbank
aufbau durchsuchen.
Irgendwo muss die Config Datei ja auch importiert werden. Dort dann
notfalls die Werte selber eintragen.
IngoF schrieb:> Habe docker zum ersten mal gehört...> Warum kann man dort keine Config-Datei benutzen?
Doch Docker kann auch config Dateien.
Aber so hast du nur ein File im etc/init.d und gut ist
die ganze Geschichte hängt zur Zeit bei mit nur daran das es kein
Kanndozeilenparameter gibt für den SQL Connect gibt.
#!/bin/bash
/etc/init.d/mysql start
/etc/init.d/lighttpd start
/ems-collector/collectord -u user -p password -f -d
all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P /var/www/pid/ems.pid
-R rc30 -C 7777 -D 7778 > /dev/null 2>1 &
-u
-p
und die SQL ip ???????
Das ist die ganze Hexerei.
Vielleicht sollte beim nächsten release des Collector das mal
eingepflegt werden.
Denis L. schrieb:> IngoF schrieb:>> Habe docker zum ersten mal gehört...>> Warum kann man dort keine Config-Datei benutzen?>> Doch Docker kann auch config Dateien.>> Aber so hast du nur ein File im etc/init.d und gut ist> die ganze Geschichte hängt zur Zeit bei mit nur daran das es kein> Kanndozeilenparameter gibt für den SQL Connect gibt.>> #!/bin/bash> /etc/init.d/mysql start> /etc/init.d/lighttpd start> /ems-collector/collectord -u user -p password -f -d> all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P /var/www/pid/ems.pid> -R rc30 -C 7777 -D 7778 > /dev/null 2>1 &>> -u> -p>> und die SQL ip ???????>> Das ist die ganze Hexerei.> Vielleicht sollte beim nächsten release des Collector das mal> eingepflegt werden.
Achso.. Es funktioniert mit den Konfig-File und Du möchtest das einfach
nur einsparen..
Soweit ich weiss wird das Config-File ja nur importiert.
Statt das Config-File zu importieren kannst Du ja statt des Imports
einfach die Konfiguration selber in die .PY oder .PHP Datei eingeben.
IngoF schrieb:>> Soweit ich weiss wird das Config-File ja nur importiert.> Statt das Config-File zu importieren kannst Du ja statt des Imports> einfach die Konfiguration selber in die .PY oder .PHP Datei eingeben.
du meinst in dem collector selbst, denn der kollector muss ja schon auf
einen fremden SQL Server schreiben
IngoF schrieb:> Ja, den habe ich gemeint...
Ich schau mir das mal an,
aber vielleicht tut Danny Baumann das mal implementieren, dann kannst du
dir den ganzen config quatsch sparen da alle Parameter bein start an den
collector deamon übergeben werden können
Denis L. schrieb:> IngoF schrieb:>> Ja, den habe ich gemeint...>> Ich schau mir das mal an,> aber vielleicht tut Danny Baumann das mal implementieren, dann kannst du> dir den ganzen config quatsch sparen da alle Parameter bein start an den> collector deamon übergeben werden können
Hab ich doch schon lange...
collectord --db-path sqlserver:port -u sqluser -p sqlpass ...
(Steht aber doch auch so im Hilfetext?)
Danny B. schrieb:> Denis L. schrieb:>> IngoF schrieb:>>> Ja, den habe ich gemeint...>>>> Ich schau mir das mal an,>> aber vielleicht tut Danny Baumann das mal implementieren, dann kannst du>> dir den ganzen config quatsch sparen da alle Parameter bein start an den>> collector deamon übergeben werden können>> Hab ich doch schon lange...> collectord --db-path sqlserver:port -u sqluser -p sqlpass ...> (Steht aber doch auch so im Hilfetext?)
es gibt aber kein kommandozeilen Parameter für den SQL connect
der user ist mit -u definiert.
das Password mit -p definiert.
und der SQL Server also -? 192.168.2.2:3306.
denn das Kommando "collectord --db-path 192.168.2.2:3306 -u user -p pw
geht irgendwie nicht.
>> /ems-collector/collectord -u user -p password -f -d>> all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P /var/www/pid/ems.pid>> -R rc30 -C 7777 -D 7778 > /dev/null 2>1 &
Wenn du das -f weg lässt, kannst du auch das & weglassen ... wozu erst
im Vordergrund starten und dann in den Hintergrund verschieben, wenn man
auch gleich als Daemon starten kann?
> Soweit ich weiss wird das Config-File ja nur importiert.> Statt das Config-File zu importieren kannst Du ja statt des Imports> einfach die Konfiguration selber in die .PY oder .PHP Datei eingeben.
Bitte was? Python und PHP gibt es im Collector nicht...
Hi,
ich will mir den EMS-Adapter
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io
bauen. Bei Reichelt ist der 10µF 63 V bipolar-Elko (Tonfrequenzelko) im
Moment nicht lieferbar.
Gibt es Alternativen?
Ich hätte hier noch einen WIMA 10µF MKS 4 100 V, aber der ist riesig.
Danke!
Alex
>> Hab ich doch schon lange...>> collectord --db-path sqlserver:port -u sqluser -p sqlpass ...>> (Steht aber doch auch so im Hilfetext?)>> es gibt aber kein kommandozeilen Parameter für den SQL connect
Doch: --db-path.
> der user ist mit -u definiert.> das Password mit -p definiert.
Richtig.
> und der SQL Server also -? 192.168.2.2:3306.
--db-path 192.168.2.2:3306
> denn das Kommando "collectord --db-path 192.168.2.2:3306 -u user -p pw> geht irgendwie nicht.
Geht das noch etwas genauer?
Danny B. schrieb:> --db-path 192.168.2.2:3306>>> denn das Kommando "collectord --db-path 192.168.2.2:3306 -u user -p pw>> geht irgendwie nicht.>> Geht das noch etwas genauer?
Also wenn ich den collector so starte:
/ems-collector/collectord --db-path 192.168.2.7:3306 -u user -p password
-d all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P
/var/www/pid/ems.pid -R rc30 -C 7777 -D 7778 > /dev/null 2>1
dann kommt die Hilfe in der Kommandozeile des Collectord
Denis L. schrieb:> Also wenn ich den collector so starte:>>> /ems-collector/collectord --db-path 192.168.2.7:3306 -u user -p password> -d all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P> /var/www/pid/ems.pid -R rc30 -C 7777 -D 7778 > /dev/null 2>1>> dann kommt die Hilfe in der Kommandozeile des Collectord
Ja, weil 'target' (d.h. tcp:192.168.2.41:7950) die letzte Option sein
muss. Steht auch so im Hilfetext.
Danny B. schrieb:> Bitte was? Python und PHP gibt es im Collector nicht...
Sorry, war schon länger her das ich mich damit beschäftigt hatte ....
Habe mich mit dem Frontend vertan.
Danny B. schrieb:> Denis L. schrieb:>> Also wenn ich den collector so starte:>>>>>> /ems-collector/collectord --db-path 192.168.2.7:3306 -u user -p password>> -d all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P>> /var/www/pid/ems.pid -R rc30 -C 7777 -D 7778 > /dev/null 2>1>>>> dann kommt die Hilfe in der Kommandozeile des Collectord>> Ja, weil 'target' (d.h. tcp:192.168.2.41:7950) die letzte Option sein> muss. Steht auch so im Hilfetext.
Ok
Danke probier das später mal aus.
d.H:
collectord --db-path 192.168.2.7:3306 -u user -p Password -d
all=/var/www/logs/ems.log -P /var/www/pid/ems.pid -R rc30 -C 7777 -D
7778 tcp:192.168.2.41:7950 > /dev/null 2>1
sollte alles funktionieren.
Danke gruß Denis
Alex schrieb:> Bei Reichelt ist der 10µF 63 V bipolar-Elko (Tonfrequenzelko) im> Moment nicht lieferbar.> Gibt es Alternativen?
Nimm doch einfach nen 10uF SMD-Kondensator:
Reichelt Artikel-Nr.: X7R-G1206 10/16
Denis L. schrieb:> Danny B. schrieb:>>> --db-path 192.168.2.2:3306>>>>> denn das Kommando "collectord --db-path 192.168.2.2:3306 -u user -p pw>>> geht irgendwie nicht.>>>> Geht das noch etwas genauer?>> Also wenn ich den collector so starte:>>> /ems-collector/collectord --db-path 192.168.2.7:3306 -u user -p password> -d all=/var/www/logs/ems.log tcp:192.168.2.41:7950 -P> /var/www/pid/ems.pid -R rc30 -C 7777 -D 7778 > /dev/null 2>1>> dann kommt die Hilfe in der Kommandozeile des Collectord
Hab das ganze nun am laufen läuft super.
Collector im docker image aus NAS Server
und webseite aus Webserver des NAS.
Super Arbeit Danny B. :-)
Hallo,
habe heute gesehen es gibt einen neuen COllector auf Github.
was ist das für eine option und was macht SIe.
--mqtt-broker arg MQTT broker address (<host>:<port>)
Danke gruss Denis
Denis L. schrieb:> habe heute gesehen es gibt einen neuen COllector auf Github.> was ist das für eine option und was macht SIe.>> --mqtt-broker arg MQTT broker address (<host>:<port>)
MQTT ist ein Messaging-Protokoll. Ich benutze das, um die EMS-Daten in
OpenHAB reinzubringen. Irgendwann will ich auch noch die andere Richtung
machen (d.h. EMS-Steuerbefehle aus OpenHAB absetzen), aber dafür muss
ich noch einiges umbauen ... ist mir im Moment zu viel Aufwand.
Wenn du nach MQTT und OpenHAB googlest, findest du einige Blogeinträge
und Tutorials dazu, die auch die Begriffe erklären ... z.B.
hier:https://openhardwarecoza.wordpress.com/2015/03/29/openhab-mqtt-arduino-and-esp8266-part-1-setting-up-your-environment/
Danny B. schrieb:> Denis L. schrieb:>> habe heute gesehen es gibt einen neuen COllector auf Github.>> was ist das für eine option und was macht SIe.>>>> --mqtt-broker arg MQTT broker address (<host>:<port>)>> MQTT ist ein Messaging-Protokoll. Ich benutze das, um die EMS-Daten in> OpenHAB reinzubringen. Irgendwann will ich auch noch die andere Richtung> machen (d.h. EMS-Steuerbefehle aus OpenHAB absetzen), aber dafür muss> ich noch einiges umbauen ... ist mir im Moment zu viel Aufwand.>> Wenn du nach MQTT und OpenHAB googlest, findest du einige Blogeinträge> und Tutorials dazu, die auch die Begriffe erklären ... z.B.>
hier:https://openhardwarecoza.wordpress.com/2015/03/29/openhab-mqtt-arduino-and-esp8266-part-1-setting-up-your-environment/
Das ist doch mal eine nette sache viel erfolg bei der Arbeit.
Hab den Collector nun isoliert auf einen docker image im NAS Server
laufen.
Web fontend läuft auf dem Webserver des NAS.
Moosy Webfont läuft super musste nur die DB adressen anpassen.
Danke Denis
Dennis schrieb:> Ohne Speicher Oszilloscop werde ich hier aber wohl nicht mehr weiter> kommen
Hallo,
ich wollte mich auf meine Beiträge vom November einmal zurückmelden.
Ich konnte an einer GB132T keine Verbindung mit dem NET-IO aufbauen, an
meiner GB142 aber schon.
Durch einen "Zufall" wissen wir nun grob woran es lag. Es gab sporadisch
immer einmal Fehlermeldungen was den Brenner betraf.
Wir haben nun daraufhin die UBA getauscht, und siehe da alles geht!
Keine Störungen mehr und der NET-IO wird auch als Busteilnehmer
angezeigt...!
Mich würde nun nur interessieren was da auf der UBA wohl defekt ist...
:-(
Gruß
Dennis
Denis L. schrieb:> Hab das ganze nun am laufen läuft super.> Collector im docker image aus NAS Server> und webseite aus Webserver des NAS.>> Super Arbeit Danny B. :-)
Hallo Denis,
habe mal ein wenig geforscht. Wie hast Du dass denn im Docker zum laufen
bekommen? Auf Ubunuto kompiliert und dann in einem Ubuntu-Container am
laufen?
Wäre daran auch interessiert. Wollte collectorD schon immer auf einer
von meinen Diskstations zum laufen bekommen.
Habe direktes Kompilieren geht wegen dem veralteten GCC nicht. Und alle
anderen Möglichkeiten habe ich auch nicht zum laufen bekommen. Was hast
Du denn für eine DS?
Habe eine 212+ und 415+
IngoF schrieb:> Denis L. schrieb:>> Hab das ganze nun am laufen läuft super.>> Collector im docker image aus NAS Server>> und webseite aus Webserver des NAS.>>>> Super Arbeit Danny B. :-)>> Hallo Denis,>> habe mal ein wenig geforscht. Wie hast Du dass denn im Docker zum laufen> bekommen? Auf Ubunuto kompiliert und dann in einem Ubuntu-Container am> laufen?>> Wäre daran auch interessiert. Wollte collectorD schon immer auf einer> von meinen Diskstations zum laufen bekommen.> Habe direktes Kompilieren geht wegen dem veralteten GCC nicht. Und alle> anderen Möglichkeiten habe ich auch nicht zum laufen bekommen. Was hast> Du denn für eine DS?>> Habe eine 212+ und 415+
Nimm dir Docker auf DSM,
dann nimm ein Debian wheezy Docker image, installier mit apt wie in der
Beschreibung für den raspi alle nötigen Packete.
Dann habe ich wie Du oben lesen kannst ein startscript und dann muss du
nur noch deine docker ip wissen vom host.
der Hostserver braucht dann noch mariadb.
Dann das web fontend drauf und gut.
Gruss Denis
Hallo,
ich habe jetzt auch alles soweit aufgebaut,
leider habe ich auch Probleme mit den Packets.
Bytes total:20046
Bytes good:75
Bytes dropped:0
Packets good:8
Packets bad:886
Packets 1byte:34 0
Packets ack:0 nack:0
Overflow:165
Max fill:3
Ich habe schon 2 mal alles überprüft und finde den Fehler nicht,
das einzige was ich anders habe ist C5, da habe ich einen normalen
Elko genommen mit + nach R14, sollte so richtig sein.
Falls noch jemand eine Platine los werde möchte, so würde ich sie gerne
nehmen, bevor ich noch Stunden der Suche verbruzzel,
oder hat jemand eine Idee wo ich welches Signal messen kann um den
Fehler zu finden, Oszi ist vorhanden.
Danke
Sven
Liebe EMS-Gemeinde
ich habe verzweifele gerade an der Bestückung der Platine, weil mir
a) eine Bestückungsplan fehlt (der Breadbord Designer schmiert sowohl
unter OSX, als auch unter Debian und Windows mit der im Wiki
hinterlegten .bb-Datei mit java-Fehlern ab)
b) es für mein Gefühl Diskrepanzen zwischen dem im Wiki hinterlegten
Schaltplan und dem Lochraster-Layout gibt, so dass ich die Bauteile auch
auf diesem Weg nicht identifizieren kann.
Könnte bitte jemand einen Bestückungsplan (wenn das der richtige
Ausdruck für "Ein Bild von der Lochrasterplatine mit Bezeichnung und
Wert der Bauteile") posten? Oder den beigefügten Plan (xml zu bearbeiten
auf draw.io) verifizieren und korrigieren?
In einem Beitrag vom 15.11.15 hat der User "Passuff" einen solchen
gepostet, dieser wurde jedoch nie verifiziert und enthält einige
Modifikationen zum Original.
Danke & Viele Grüße
T.
(Edit: eigener Stand Bestückungsliste hinzugefügt)
(Edit2: Sorry, finde keinen Weg die überflüssigen Bilder zu löschen)
Hi,
mein Net-IO hat zuletzt die Konfiguration verloren. Eventuell liegt das
an der Brown out detection, die war bei mir nämlich aus (ich habe mich
bei den Fuses an die Angaben von http://emswiki.thefischer.net/
gehalten).
Gibt es die Möglichkeit, die Funktionalität der Net-IO Platine in den Pi
zu integrieren? Ich habe keine Netzwerkports mehr frei...
Grüße,
Chris
Christian schrieb:> Hi,>> mein Net-IO hat zuletzt die Konfiguration verloren. Eventuell liegt das> an der Brown out detection, die war bei mir nämlich aus (ich habe mich> bei den Fuses an die Angaben von http://emswiki.thefischer.net/> gehalten).>> Gibt es die Möglichkeit, die Funktionalität der Net-IO Platine in den Pi> zu integrieren? Ich habe keine Netzwerkports mehr frei...
Nein, weil Standard-Betriebssysteme keine sinnvolle Möglichkeit für die
Verarbeitung der Break-Conditions haben.
Guten Abend,
habe mich in Tagelanger Aktion durch das EMS Wiki gequält und bin jetzt
beim Server auf dem Raspberry angelangt. Net-IO bis zum testtool
funktioniert glücklicherweise.
Leider schmeißt mir das "make" zum Erstellen des collectord immer ein
paar Fehler:
CommandHandler.h:70:51: error: expected ‘;’ at end of member declaration
5
CommandHandler.h:70:53: error: ‘override’ does not name a type
6
In file included from main.cpp:35:0:
7
TcpHandler.h:34:52: error: expected ‘;’ at end of member declaration
8
TcpHandler.h:34:54: error: ‘override’ does not name a type
9
TcpHandler.h:35:56: error: expected ‘;’ at end of member declaration
10
TcpHandler.h:35:58: error: ‘override’ does not name a type
11
Makefile:48: recipe for target 'main.o' failed
12
make: *** [main.o] Error 1
Die EMC-Collector files von github sind aktuell von heute. Spontan
konnten meine rudimentären Kenntnisse keine Fehler in der
CommandHandler.h und TcpHandler.h erkennen.
Hat jemand einen Lösungsansatz?
Gruß Florian
PS: Volle Ladung mitgenommen... Billiger Diamex ISP Programmer lief
nicht. NetIO wollte nicht ins Netzwerk, Fusebits auf dem ATMega32 von
Pollin waren falsch, Dann zunächst einen ATMega 644 20PU bestellt. Geht
natürlich nicht. Also noch einen 644p.Irgendwann lief dann Ethersex. Auf
meinem Raspberry2 lief noch ein apache2. Also startete der lighttpd
nicht weil Port 80 belegt war. Und jetzt der Fehler beim Compilieren :/
Geht das allen so?
War auf gcc 4.6. Standard wheezy wie ich lesen konnte.
Habe noch 4.9 installiert und als default eigerichtet. Bis auf ein paar
"warning: swp{b} use is deprecated for ARMv6 and ARMv7" lief es durch.
Danke!
Nächstes Problem:
collectord ließ sich nach dem Kompilieren im /ems-collector/collector
nicht ausführen. Datei wurde nicht gefunden, war aber im Verzeichnis
vorhanden.
Habe dann gemäß Readme die Punkte Install, Config und Service ausgeführt
und daraufhin war die collectord auch über die Konsole ausführbar. Gibt
aber bei egal welchem Befehl nur die Hilfe aus.
1
service ems-collector start
gibt ebenso die Hilfe aus und endet mit einem "failed". Der collector
wird also nicht gestartet.
-> Woran kann das liegen?
-> Welche Daten müssen bei db-user und db-pass in die config? Der mysql
login, welcher im Wiki unter "MySql Benutzer anlegen" erzeugt wird? Ich
kenne mich mit Datenbanken und Servern kaum aus.
Wenn mir jemand die grobe Struktur mit Standardverzeichnissen erläutern
kann, wäre ich sehr dankbar.
-> Hab ich es richtig verstanden, dass es sich beim Frontend von Moosy
um eine fertige GUI handelt? Wie wird darauf zugegriffen - sprich wie
entsteht der Link zum /var/www, aus welche bei Aufrufen der Pi-IP die
index.php ausgeführt wird?
Viele Grüße und angenehmen Sonntag
Florian
Denis L. schrieb:> dann nimm ein Debian wheezy Docker image, installier mit apt wie in der> Beschreibung für den raspi alle nötigen Packete.
habe z.B. pacour/debuian-wheezy genommen.
Allerdings wird es sofort wieder unerwartet beendet.
Wie bekomme ich denn ein Terminal oder irgendwas um die Sachen per APT
nachzuinstallieren? Terminal soll ja auf der Diskstation nicht gehen,
oder?
Was hast Du denn für ein Wheezy-Image genommen? In der Sucher werden ja
>24000 Docker Wheezy-Images angezeigt.
Hast Du Dir den Container auf einem anderen Rechner zusammengebastelt,
oder direkt auf der Diskstation?
Gruß
Ingo
Hallo Freunde,
da mein zukünftiges Haus eine Viessmann Heizung hat, wäre hier eine EMS
Platine + NetIO zu haben. Gewinnt zwar keinen Schönheitswettbewerb, aber
funktioniert einwandfrei und ist somit kampferprobt :)
Wenn Interesse bitte Ich um ein faires Gebot per PN. Gruß
Torsten G. schrieb:> Könnte bitte jemand einen Bestückungsplan (wenn das der richtige> Ausdruck für "Ein Bild von der Lochrasterplatine mit Bezeichnung und> Wert der Bauteile") posten? Oder den beigefügten Plan (xml zu bearbeiten> auf draw.io) verifizieren und korrigieren?
Da bisher keiner helfen konnte habe ich mich mal daran gewagt.
Habe mein Ergebnis als XML und Screenshot angehangen.
Bin mir ziemlich sicher dass es so stimmt. Die Komperatoren im Layout
sind zum Schaltplan vertauscht. Vielleicht kam daher die Fehlzuordnung.
Ich habe die Schaltung aber nie aufgebaut da ich kein NetIO habe.
Habe den C6 auch noch eingezeichnet. Auch bitte die fehlende Leiterbahn
zwischen den beiden BAT42 nicht vergessen.
Bitte mal Rückmeldung geben wenn Deine Platine erfolgreich getestet
wurde.
Gruß
Ingo
@IngoF: Vielen Dank - ich werde testen und Feedback geben. Ich würde
mich dann drum kümmern, dass der verifizierte Plan in's ems_netio Wiki
kommt (gleich auch in der gespiegelten Version sight ;-) )
Torsten G. schrieb:> @IngoF: Vielen Dank - ich werde testen und Feedback geben. Ich> würde> mich dann drum kümmern, dass der verifizierte Plan in's ems_netio Wiki> kommt (gleich auch in der gespiegelten Version sight ;-) )
Habe ich schon gemacht. Eventuell Seite nochmal aktualisieren falls die
Änderungen noch nicht zu sehen sind.
Hallo zusammen,
Ich habe nach dem Wiki und den Forenbeiträgen ein System aus
Adapterplatine, AVR NET IO und zur Zeit Ubuntu ( wird später Raspberry)
aufgebaut. Ich teste im Moment die Kommunikation mit dem Collector
Testtool.
Dabei habe ich folgendes Probelm:
Die RX LED auf der Adapterplatine leuchtet von Zeit zu Zeit.
Mit dem Collector Testtool (V0.4)bekomme ich nach dem Verbinden
folgendes Telegramm:
4F 52 3A 20 43 6F 6E 6E 65 63 74 69 6F 6E 20 62 6C 6F 63 6B 65 64 0A
Die Abfrage der Uhrzeit mit:
0B 90 06 00 08
antwortet mit …
Das Testprogramm
collectord -u ems -p geheim -f -d all tcp:192.168.178.100:7950
bringt:
helmut@helmut-VirtualBox:~$ collectord -u ems -p geheim -f -d all
tcp:192.168.178.100:7950
IO: Got bytes 0x45 0x52 0x52 0x4f 0x52 0x3a 0x20 0x43 0x6f 0x6e 0x6e
0x65 0x63 0x74 0x69 0x6f 0x6e 0x20 0x62 0x6c 0x6f 0x63 0x6b 0x65 0x64
0xa 00
Error: End of file
IO: Got bytes 0x45 0x52 0x52 0x4f 0x52 0x3a 0x20 0x43 0x6f 0x6e 0x6e
0x65 0x63 0x74 0x69 0x6f 0x6e 0x20 0x62 0x6c 0x6f 0x63 0x6b 0x65 0x64
0xa 00
Error: End of file
IO: Got bytes 0xaa 0x55 0x5 0xce 0xfd 0xd3 0xee 0x96 0x98
MESSAGE[07.03.2016 18:59:44]: source 0xce, dest 0xfd, type 0xd3, offset
238, data: 0x96
IO: Got bytes 0xaa 0x55 0x6 0xf6 0x1 0x24 0xff 0xff 0x31 0xe2
MESSAGE[07.03.2016 19:00:07]: source 0xf6, dest 0x01, type 0x24, offset
255, data: 0xff 0x31
DATA: Unhandled message received(source 0xf6, type 0x24).
Hat jemand eine Idee was das zu bedeuten hat? Übertragungsprobleme?
Helmut J. schrieb:> Die RX LED auf der Adapterplatine leuchtet von Zeit zu Zeit.> Mit dem Collector Testtool (V0.4)bekomme ich nach dem Verbinden> folgendes Telegramm:>> 4F 52 3A 20 43 6F 6E 6E 65 63 74 69 6F 6E 20 62 6C 6F 63 6B 65 64 0A
Das ist 'Connection blocked'. Du hast mehrere Programme laufen, die sich
mit dem NetIO verbinden. Das geht nicht, d.h. du musst das überzählige
Programm beenden.
>> Die Abfrage der Uhrzeit mit:> 0B 90 06 00 08> antwortet mit …>> Das Testprogramm> collectord -u ems -p geheim -f -d all tcp:192.168.178.100:7950> bringt:> helmut@helmut-VirtualBox:~$ collectord -u ems -p geheim -f -d all> tcp:192.168.178.100:7950> IO: Got bytes 0x45 0x52 0x52 0x4f 0x52 0x3a 0x20 0x43 0x6f 0x6e 0x6e> 0x65 0x63 0x74 0x69 0x6f 0x6e 0x20 0x62 0x6c 0x6f 0x63 0x6b 0x65 0x64> 0xa 00> Error: End of file> IO: Got bytes 0x45 0x52 0x52 0x4f 0x52 0x3a 0x20 0x43 0x6f 0x6e 0x6e> 0x65 0x63 0x74 0x69 0x6f 0x6e 0x20 0x62 0x6c 0x6f 0x63 0x6b 0x65 0x64> 0xa 00
Das hier ist das gleiche.
IngoF schrieb:> Denis L. schrieb:>> dann nimm ein Debian wheezy Docker image, installier mit apt wie in der>> Beschreibung für den raspi alle nötigen Packete.>> habe z.B. pacour/debuian-wheezy genommen.> Allerdings wird es sofort wieder unerwartet beendet.>> Wie bekomme ich denn ein Terminal oder irgendwas um die Sachen per APT> nachzuinstallieren? Terminal soll ja auf der Diskstation nicht gehen,> oder?>> Was hast Du denn für ein Wheezy-Image genommen? In der Sucher werden ja>>24000 Docker Wheezy-Images angezeigt.>> Hast Du Dir den Container auf einem anderen Rechner zusammengebastelt,> oder direkt auf der Diskstation?>> Gruß> Ingo
Nimm Dir mal im Docker Menu auf DSM Das Orginal Debian Image.
Du erkennst das an dem auszeichnungs Symbol
Dann kann DU auch auswählen ob jeesy oder Wheezy.
Ich benutze im Docker den Terminal, DU kannst aber auch einen SSH zugang
zum Image einrichten.
Denk daran dann den Port 22 im DOcker Image freizugeben
Helmut J. schrieb:> Ich habe nach dem Wiki und den Forenbeiträgen ein System aus> Adapterplatine, AVR NET IO
Warum hast Du denn eine gespiegeltes Layout angehangen?
Denis L. schrieb:> Ich benutze im Docker den Terminal,
Das war mein Problem ich habe das Terminal im Docker auf der DS nicht
gefunden....
Habe es aber jetzt per Zufall gefunden:
container > details > terminal
Hallo in die Runde
so, next step: der Net-IO!
ich hoffe, dass das nicht allzu off-topic ist, aber da ich für das eine
Mal die Anschaffung eines dedizierten ISP-Programmers scheue, würde ich
den 644p mit der low-cost-variante "ArduinoISP" programmieren wollen
(https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard)
Jetzt die Noob-Frage: muss ich auf den 644p auch zuerst einen bootloader
drauf machen oder reicht es, das hex-File aus dem wiki mit avrdude zu
brennen?
Viele Grüße
Torsten
Hallo an die Runde,
ich versuche gerade unter XUbuntu auf meinem alten Rechner den Collector
zu installieren. Ich komme leider mur bis zum make im Wiki:
"... MySQL database support' sagt, und entfernen die Raute am Anfang der
3 Zeilen danach.
Danach sollte Ein „make“ die ausführbare Datei „collectord“ erzeugen.
Bis der Raspberry das erledigt hat, könnt Ihr Euch eine Tasse Kaffee
genehmigen. ;-)"
Fehlermeldung:
root@helmut-SCENIC-L:/home/helmut/ems-collector/collector# make
g++ -Wall -c -O2 -std=c++0x -DHAVE_DAEMONIZE -DHAVE_MYSQL -MM main.cpp
IoHandler.cpp SerialHandler.cpp TcpHandler.cpp CommandHandler.cpp
ApiCommandParser.cpp CommandScheduler.cpp DataHandler.cpp EmsMessage.cpp
ValueApi.cpp ValueCache.cpp Options.cpp PidFile.cpp Database.cpp >
.depend
g++ -Wall -c -O2 -std=c++0x -DHAVE_DAEMONIZE -DHAVE_MYSQL main.cpp
In file included from main.cpp:28:0:
Database.h:25:38: fatal error: mysql/mysql++/connection.h: Datei oder
Verzeichnis nicht gefunden
#include <mysql/mysql++/connection.h>
^
compilation terminated.
make: *** [main.o] Fehler 1
Die einzige Besonderheit bei der Installation war: Statt der
libboost1.50-all musste ich die libboost1.54-all nehme, da es unter
XUbuntu die 50 und auch 49 nicht gab.
Hat jemand eine Idee, ich bin leider kein Linux Spezialist????
Helmut J. schrieb:
> fatal error: mysql/mysql++/connection.h: Datei oder> Verzeichnis nicht gefunden
... er findet /usr/include/mysql/mysql++/connection.h nicht.
Danny hat in seinem letzten commit ein paar Pfade geändert. (Danny?)
Setze mal bitte folgende Befehle ab und versuche es dann nochmal:
cd /usr/include/mysql
ln -s /usr/include/mysql++ mysql++
hth
Fixed, sorry :-/
Damit Raum-Ist- und -Solltemperatur ordentlich in die DB geschrieben
werden, werde ich demnächst mal noch eine Option für die Anzahl der
angeschlossenen Heizkreise einführen (die beiden Temperaturen sind jetzt
HK-spezifisch, da das auf dem Bus auch so ist).
Karl M. W. schrieb:> Helmut J. schrieb:>> fatal error: mysql/mysql++/connection.h: Datei oder>> Verzeichnis nicht gefunden>> ... er findet /usr/include/mysql/mysql++/connection.h nicht.>> Danny hat in seinem letzten commit ein paar Pfade geändert. (Danny?)>> Setze mal bitte folgende Befehle ab und versuche es dann nochmal:>> cd /usr/include/mysql> ln -s /usr/include/mysql++ mysql++
Das funktioniert leider nicht.
der make bleibt jetzt bei:
/usr/include/mysql++/common.h:131:28: fatal error: mysql_version.h:
Datei oder Verzeichnis nicht gefunden
hängen.
Warum ist in der aktuellen Collector Build kein SQL Support mehr
enthalten.
Wenn ich die Hilde des COllectors aufrufe wird auch nut noch die mqtt
Option aufgelisteet, aber die --db-path Option gibt es irgend wie nicht
mehr warum.
Make benutzt auch nicht mehr die Database files.
Gruss Denis
Denis L. schrieb:> Warum ist in der aktuellen Collector Build kein SQL Support mehr> enthalten.> Wenn ich die Hilde des COllectors aufrufe wird auch nut noch die mqtt> Option aufgelisteet, aber die --db-path Option gibt es irgend wie nicht> mehr warum.>> Make benutzt auch nicht mehr die Database files.
Weil es jetzt optional ist - siehe Makefile.
Danny B. schrieb:> Denis L. schrieb:>> Warum ist in der aktuellen Collector Build kein SQL Support mehr>> enthalten.>> Wenn ich die Hilde des COllectors aufrufe wird auch nut noch die mqtt>> Option aufgelisteet, aber die --db-path Option gibt es irgend wie nicht>> mehr warum.>>>> Make benutzt auch nicht mehr die Database files.>> Weil es jetzt optional ist - siehe Makefile.
Wie include ich das jetzt ??????
Denis L. schrieb:> Danny B. schrieb:>> Denis L. schrieb:>>> Warum ist in der aktuellen Collector Build kein SQL Support mehr>>> enthalten.>>> Wenn ich die Hilde des COllectors aufrufe wird auch nut noch die mqtt>>> Option aufgelisteet, aber die --db-path Option gibt es irgend wie nicht>>> mehr warum.>>>>>> Make benutzt auch nicht mehr die Database files.>>>> Weil es jetzt optional ist - siehe Makefile.>> Wie include ich das jetzt ??????
Steht doch im Makefile drin - einfach die Raute am Anfang der
entsprechenden 3 Zeilen entfernen.
Danny B. schrieb:> Denis L. schrieb:>> Danny B. schrieb:>>> Denis L. schrieb:>>>> Warum ist in der aktuellen Collector Build kein SQL Support mehr>>>> enthalten.>>>> Wenn ich die Hilde des COllectors aufrufe wird auch nut noch die mqtt>>>> Option aufgelisteet, aber die --db-path Option gibt es irgend wie nicht>>>> mehr warum.>>>>>>>> Make benutzt auch nicht mehr die Database files.>>>>>> Weil es jetzt optional ist - siehe Makefile.>>>> Wie include ich das jetzt ??????>> Steht doch im Makefile drin - einfach die Raute am Anfang der> entsprechenden 3 Zeilen entfernen.
Ok das geht bekomme aber nach ein paar Sekunden die Meldung:
Exception: boost::bad_get: failed value get using boost::get
was ist das ???
Danke Danny im vorraus
Danny B. schrieb:> Ist das alles oder steht da noch mehr?
MESSAGE[13.03.2016 19:48:15]: source 0x10, dest 0x00, type 0x3e, offset
0, data:
0x04 0x02 0x2e 0x00 0xed 0x3d 0x3c 0x1f 0x27 0x2e 0x00 0x00 0x64 0x11
0x21
DATA: HK1-Ausschaltoptimierung = AUS
DATA: HK1-Einschaltoptimierung = AUS
DATA: HK1-WW-Vorrang = AUS
DATA: HK1-Estrichtrocknung = AUS
DATA: HK1-Frostschutzbetrieb = AUS
DATA: HK1-Sommerbetrieb = AUS
DATA: HK1-Tagbetrieb = AN
DATA: HK1-Betriebsart = immer Tagbetrieb
Exception: boost::bad_get: failed value get using boost::get
immer wenn er den HK1 abfrägt genau an der stelle ist eine gb132 mit
rc30
alle abfragedaten des hk1 sind irgendwie falsch haben also nix mit den
Parametern ds kessel zu tun
Hallo,
ich muss nochmal eure Hilfe in Anspruch nehmen,
ich bekomme mein NetIO nicht zum laufen.
Ich habe jetzt die zweite Platine aufgebaut und bekomme immer noch
Bytes total:1620555
Bytes good:7773
Bytes dropped:0
Packets good:1240
Packets bad:69553
Packets 1byte:6988 0
Packets ack:0 nack:0
Overflow:103418
Max fill:7
Ich habe ein GB162 mit der RC300 EMS Plus Steuerung.
Ich habe mal ein Oszi angeschlossen, und würde sagen das Signal sieht
gut am Ausgang des OP's.
Kann es sein, das es einfach an dem EMS+ Protokoll liegt, das ich gar
kein Hardware Problem habe?
Vielen dank schon mal im vorraus.
Sven
Grünbacher schrieb:>> Ich habe ein GB162 mit der RC300 EMS Plus Steuerung.> Ich habe mal ein Oszi angeschlossen, und würde sagen das Signal sieht> gut am Ausgang des OP's.>> Kann es sein, das es einfach an dem EMS+ Protokoll liegt, das ich gar> kein Hardware Problem habe?>
Hallo Sven,
es liegt definitiv nicht daran.
Ich habe eine ähnliche Konfiguration und bei mir funktioniert das Netio
Gateway.
Allerdings habe ich es nicht hingekriegt das mit einem selbst
kompilierten Hex File zum Laufen zu bringen.
Grüße, Torsten
Denis L. schrieb:> Danny B. schrieb:>> Ist das alles oder steht da noch mehr?> DATA: HK1-Betriebsart = immer Tagbetrieb> Exception: boost::bad_get: failed value get using boost::get
Fixed, sorry. Man merkt glaube ich, dass ich das DB-Interface selber
nicht mehr verwende :-/
> alle abfragedaten des hk1 sind irgendwie falsch haben also nix mit den> Parametern ds kessel zu tun
Wie meinst du das?
Ich habe hier mal ein paar
OSZI Bilder vom Ausgang der OP's.
Wenn die Baudrate mit 9600 Baud stimmt,
dann ergibt sich eine Bitbreite von etwas mehr als 100µs,
wo ich eigentlich sagen würde,
das es stimmt.
Aber warum habe ich dann die ganzen Fehler?
Grünbacher schrieb:> @Torsten>> Wie hat sich das bei dir geäusert mit dem kompilieren,> lief der AVR gar nicht oder hattest du ähnliche Fehler?
Daten hatte ich nur mit dem Hex File aus dem Wiki
Grüße, Torsten
Karl M. W. schrieb:> Helmut Jato(Helmbrot) schrieb:>> Das funktioniert leider nicht.>> sorry! :-/>> Aber Danny hat's ja gefixt. :-)
#####################
Ich habe den Fix eingebaut, der make funktioniert. In meiner Ubuntu
Virtual Box funktioniert der ems-collector dienst auch, auf meinem
Zielrechner (xubunto) lässt sich der Dienst nicht starten.
helmut@helmut-SCENIC-L:/etc/init.d$ sudo service ems-collector start
* Starting EMS collector daemon collectord
Usage: /usr/local/sbin/collectord [options] <target>
General options:
-h [ --help ] Show this help message
-R [ --rc-type ] arg Type of used room controller (rc30 or
rc35)
-r [ --ratelimit ] arg (=60) Rate limit (in s) for writing numeric
sensor
values into DB
...
Hat Jemand eine Idee??
Danny B. schrieb:> Denis L. schrieb:>> Danny B. schrieb:>>> Ist das alles oder steht da noch mehr?>> DATA: HK1-Betriebsart = immer Tagbetrieb>> Exception: boost::bad_get: failed value get using boost::get>> Fixed, sorry. Man merkt glaube ich, dass ich das DB-Interface selber> nicht mehr verwende :-/>>> alle abfragedaten des hk1 sind irgendwie falsch haben also nix mit den>> Parametern ds kessel zu tun>> Wie meinst du das?
Der Modus Betriebsart Automatik wird in Moosy´s Webfont immer in manuel
angezeigt grade letztes git von Dir gezogen und getestet. das war vorher
nicht. hab auch noch ein unhandled data message 0x08 type 0x07
Denis L. schrieb:> Danny B. schrieb:>> Denis L. schrieb:>>> Danny B. schrieb:>>>> Ist das alles oder steht da noch mehr?>>> DATA: HK1-Betriebsart = immer Tagbetrieb>>> Exception: boost::bad_get: failed value get using boost::get>>>> Fixed, sorry. Man merkt glaube ich, dass ich das DB-Interface selber>> nicht mehr verwende :-/>>>>> alle abfragedaten des hk1 sind irgendwie falsch haben also nix mit den>>> Parametern ds kessel zu tun>>>> Wie meinst du das?>> Der Modus Betriebsart Automatik wird in Moosy´s Webfont immer in manuel> angezeigt grade letztes git von Dir gezogen und getestet. das war vorher> nicht.
Meine letzten Collector-Änderungen brauchen Änderungen im Frontend. Da
Mossy MIA ist, habe ich diese Änderungen in ingof's Form eingepflegt,
d.h. du solltest dieses Repo verwenden.
> hab auch noch ein unhandled data message 0x08 type 0x07
Wenn du mir sagst, was da drin steht, kann ich auch Handling einbauen ;)
Im Ernst: der Inhalt dieses Telegramms ist auch dem Wiki unbekannt, d.h.
du kannst das einfach ignorieren.
Hallo,
wollte mich nur nochmal kurz melden,
bei mir geht es mittlerweile.
Ich habe vergessen die Fuses zu programmieren(ICH IDIOT !!!)
Danke für die Hilfe.
Sven
Danny B. schrieb:> Was ist denn der Inhalt von /etc/default/ems-collector? Irgendwo> wird> irgendeine Option nicht passen ;)
Ja, richtig ich hatte einen Schreibfehler in der ems-collector.conf. Ich
habe jetzt noch das Problem, dass keine Werte in die Datenbank kommen.
Dazu habe ich noch ein paar Fragen:
1. muss in der ems-collector.conf der db-path eingegeben werde?
2. wie wird der der db-path beim Starten von collectord als Argument
übergeben? Z.B um zu debuggen?
Ich meine: collectord db-path:localhost:3306 -u ems -p
*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 -f tcp:192.168.178.100:7950
Helmut Jato(Helmbrot) schrieb:> Ich habe jetzt noch das Problem, dass keine Werte in die Datenbank kommen.
Falls du den Collector in den letzten Tagen ausgecheckt/aktualisiert
hast: Hast du die DB-Unterstützung im Makefile angemacht?
> Dazu habe ich noch ein paar Fragen:> 1. muss in der ems-collector.conf der db-path eingegeben werde?
Nein. Standardmäßig wird der lokale MySQL-Socket verwendet. Man muss
diesen Parameter eigentlich nur dann angeben, wenn der MySQL-Server auf
einem anderen Rechner als der Collector läuft.
> 2. wie wird der der db-path beim Starten von collectord als Argument> übergeben? Z.B um zu debuggen?> Ich meine: collectord db-path:localhost:3306 -u ems -p> *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 -f tcp:192.168.178.100:7950
collectord --db-path localhost:3306 ...
Danny B. schrieb:> Helmut Jato(Helmbrot) schrieb:>> Ich habe jetzt noch das Problem, dass keine Werte in die Datenbank kommen.>> Falls du den Collector in den letzten Tagen ausgecheckt/aktualisiert> hast: Hast du die DB-Unterstützung im Makefile angemacht?
Ja hab ich. Ich habe nochmal laut dem Wiki ab dem make alles
durchexerziert. Dem MySql Benutzer habe ich gelöscht und nochmal
angelegt.
Der ems-collector Dienst läuft, ich sehe im http://localhost/status.php
keine neuen Daten, nur die Voreinstellung. Die Telegramme sehen
eigentlich richtig aus? Die Datenbank bleibt leer, ich benutze das tool
MySql Workbench.
Helmut Jato(Helmbrot) schrieb:> Der ems-collector Dienst läuft, ich sehe im http://localhost/status.php> keine neuen Daten, nur die Voreinstellung. Die Telegramme sehen> eigentlich richtig aus? Die Datenbank bleibt leer, ich benutze das tool> MySql Workbench.
Nein, die Telegramme sehen komplett kaputt aus. Du hast nicht zufällig
ein EMS Plus-System, oder?
Danny B. schrieb:> Helmut Jato(Helmbrot) schrieb:>> Der ems-collector Dienst läuft, ich sehe im http://localhost/status.php>> keine neuen Daten, nur die Voreinstellung. Die Telegramme sehen>> eigentlich richtig aus? Die Datenbank bleibt leer, ich benutze das tool>> MySql Workbench.>> Nein, die Telegramme sehen komplett kaputt aus. Du hast nicht zufällig> ein EMS Plus-System, oder?
Nein ich hab was älteres, einen GB125 mit RC35.
Na dann muss ich mir nochmal den Adapter und den NET-IO vornehmen. Ich
habe bei den Net-IO Adapter für den C5 Koppelkondensator statt den 10
uF Tonfrequenz Kondensator einen normalen ELKO genommen, kann das daran
liegen?
Helmut Jato(Helmbrot) schrieb:> [...] einen GB125 mit RC35.
oha ... unerforschtes terrain.
was wir hier machen, basiert auf einem busmaster UBA3(feuerungsautomat).
du hast einen ölkessel, der mit einer kombo mastercontroller MC10 +
feuerungsautomat SAFe arbeitet.
dass die telegramme, mit ausnahme derer vom RC35, nicht kompatibel sind,
halte ich für sehr wahrscheinlich.
//niffko
> oha ... unerforschtes terrain.>
Huch... was verstehe ich jetzt nicht?
Habe hier
Buderus Logano plus GB125-18
• RC35 v1.11
• Logamatic MC10 v2.07
• SAFe v4.28
Habe zwar den collectod noch nicht implementiert, aber die Telegramme,
die bisher mit meinem ESP-EMS Interface empfange, unterscheiden sich
nicht von denen, die im WIKI angegeben sind.
hätte ich jetzt echt nicht gedacht ... um so besser.
was mich mal interessieren würde: haben MC10 und SAFe jeweils eigene
busadressen? wenn ja, von wem kommen die monitor-telegramme(0x18, 0x19)?
und wer ist der master, MC10 oder SAFe? kannst du das erkennen, juergen?
//niffko
gerade mal im ESP-thread geschaut...
den fast-monitor(0x18) gibts bei juergen einmal mit offset 0 und einmal
mit offset 1B. UBA3 sendet nur einmal mit offset 0.
//niffko
Grundsätzlich scheint in dieser Konstellation die Blocklänge auf 32 Byte
begrenzt zu sein und wird deshalb segmentiert übertragen.
UBAErrorMessage1 kommt beispielsweise bei mir in 4 Blocks an:
Niffko _. schrieb:> Helmut Jato(Helmbrot) schrieb:>> [...] einen GB125 mit RC35.>> oha ... unerforschtes terrain.>> was wir hier machen, basiert auf einem busmaster UBA3(feuerungsautomat).>> du hast einen ölkessel, der mit einer kombo mastercontroller MC10 +> feuerungsautomat SAFe arbeitet.>> dass die telegramme, mit ausnahme derer vom RC35, nicht kompatibel sind,> halte ich für sehr wahrscheinlich.>> //niffko
Ich bekomme jetzt auf jedenfall Daten, die Fuses beim Atmega waren nicht
richtig gesetzt. Ob Telegramme inkompatibel sind muss ich noch
überprüfen.
Hallo,
da ja bei mir alles läuft,
bin ich ein wenig dran die Solaranlage zu implementieren.
Ich habe GB162 + RC300 + SM200.
Hat schon mal jemand angefangen damit?
Hier mal kurz meine Erkenntnisse:
MESSAGE[21.03.2016 11:51:20]: source 0x30, dest 0x00, type 0xff, offset
0, data: 0x02 0x62 0x01 0x75 0x01 0x28 0x80 0x00 0x80 0x00 0x80 0x00
0x80 0x00 0x80 0x00 0x80 0x00 0x02 0x2f 0x80 0x00 0x80 0x00 0x80 0x00
MESSAGE[21.03.2016 11:51:20]: source 0x30, dest 0x00, type 0xff, offset
24, data: 0x02 0x62 0x80 0x00
Das sind die Temperatursensoren
TS1 0175h = 37,3°
TS2 0128h = 29,6°
TS5 022fh = 55,9°
den Rest weis ich hier noch nicht, ich nehme aber an, das es alles
Teperatursensoren sind, die ich nicht angeschlossen habe, wobei das
SM200 nur 8 Sensoreingänge hat, passt also nicht ganz.
MESSAGE[21.03.2016 12:05:00]: source 0x30, dest 0x00, type 0xff, offset
0, data: 0x02 0x8e 0x00 0x00 0x61 0xd2 0x00 0x00 0x13 0x40 0x00 0x00
0x53 0x20
Die letzten beiden Bytes 0x5320 ist der angezeigte Solarertrag im
Display (
2128,0 KWh)
Bei mir ist noch ein 3 Wege Ventil sowie die Solarpumpe angeschlossen,
die habe ich aber noch nicht gefunden im Protokoll.
Falls ich noch was finde, melde ich mich wieder.
Evtl. hat jnoch jemand eine SM200 zum Erfahrungsaustausch.
Gruß
Sven
Grünbacher schrieb:> Ich habe GB162 + RC300 + SM200.>> Hat schon mal jemand angefangen damit?
Ich bin mit GB172 + RC300 ausgestattet und würde das auch gerne
implementieren, um bspw. Zirkulation u.ä. manuell zu triggern.
Allerdings sind die Telegramme noch etwas schwer zu verstehen, aber
vielleicht können wir uns trotzdem austauschen.
Grünbacher schrieb:> Hier mal kurz meine Erkenntnisse:> MESSAGE[21.03.2016 11:51:20]: source 0x30, dest 0x00, type 0xff, offset> 0, data: 0x02 0x62 0x01 0x75 0x01 0x28 0x80 0x00 0x80 0x00 0x80 0x00> 0x80 0x00 0x80 0x00 0x80 0x00 0x02 0x2f 0x80 0x00 0x80 0x00 0x80 0x00> MESSAGE[21.03.2016 11:51:20]: source 0x30, dest 0x00, type 0xff, offset> 24, data: 0x02 0x62 0x80 0x00
Die 0xff-Telegramme sind EMS plus-Telegramme mit 2 Byte langen
Typnummern, die funktionieren mit dem Collector im momentanen Zustand
nicht. Ich hatte damit mal angefangen
(https://github.com/maniac103/ems-collector/commits/emsplus), kann das
aber nicht wirklich sinnvoll fortführen, da ich das nicht testen kann.
Mit dem o.g. Branch müsste das Parsen der Telegrammnummern
funktionieren, allerdings müssen sämtliche EMS plus-Telegramme noch
entschlüsselt werden.
@Matthias Feistel
ich wollte erstmal nur die Daten Sammeln und auswerten.
Ich habe keine Ambition die Heizungssteuerung zu ersetzten, dh.
ich möchte keine Kommandos an die Heizung senden.
Wenn dir das reicht, können wir uns gerne zusammen an die Sache dran
machen.
@Danny Baumann
Ich habe mir dein Code gerade mal angeschaut und mit dem aktuellen aus
dem Master Zweig verglichen, ich glaube ich werde es 'strait forward' in
die einzelnen Kommandos einbauen die ich habe/brauche.
Kurze Frage Danny,
bool isRead = m_data[1] & 0x80;
bool isPlus = m_data[2] >= 0xf0 && m_data.size() >= (isRead ? 7 :
6);
woher hast du die Erkenntnis das im ersten Byte &0x80 ein Read Kommando
ist?
Noch eine kurze Geschmacksfrage,
soll ich die EMS+ Kommandos in jeder Funktion unterscheiden,
oder so wie es Danny schon angefangen hat, im Konstruktor
EmsMessage::EmsMessage die Unterscheidung fällen und für alle EMS+
Kommandos neue Funktionen erstellen (zB.
parseSolarMonitorMessagePlus())?
Falls es jemand später nochmal schön schreiben und einchecken möchte
gebe ich natürlich meine Sourcen weiter, alles andere wäre assozial.
mfg.
Sven
Sven G. schrieb:> Kurze Frage Danny,> bool isRead = m_data[1] & 0x80;> bool isPlus = m_data[2] >= 0xf0 && m_data.size() >= (isRead ? 7 :> 6);>> woher hast du die Erkenntnis das im ersten Byte &0x80 ein Read Kommando> ist?
Das ist allgemein gewonnene Erkenntnis :)
http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme#anfragen> Noch eine kurze Geschmacksfrage,> soll ich die EMS+ Kommandos in jeder Funktion unterscheiden,> oder so wie es Danny schon angefangen hat, im Konstruktor> EmsMessage::EmsMessage die Unterscheidung fällen und für alle EMS+> Kommandos neue Funktionen erstellen (zB.> parseSolarMonitorMessagePlus())?
Mir wäre es lieb, wenn du die angefangene Struktur beibehältst, d.h.
eine Parsing-Funktion pro Telegrammtyp, zwischen denen in dem Switch in
EmsMessage::handle() ausgewählt wird (dem Konstruktor ist das egal).
Falls sich später rausstellen sollte, dass EMS-Plus- und EMS-Telegramme
praktisch gleich sind, können wir das immer noch ändern, aber ich glaube
da nicht so richtig dran.
Hallo Danny,
das mit dem Konstruktor war falsch von mir.
Werde es in der handle() Routine unterscheiden z.B.:
.........
case EmsProto::addressSM10:
/* SM10 message */
if(isPlus){
/* handle EMS Plus messages */
...........
} else {
switch (m_type){
case 0x97: parseSolarMonitorMessage(); handled = true; break;
}
}
.......
Können wir evtl. auch mal anders in Kontakt treten.
Alles hier so zu posten macht den Thread unübersichtlich und zieht ihn
in die Länge.
Gruß
Sven
Nachdem ich jetzt dem laut dem Wiki den ems-collector mit den Web zum
laufen gebracht habe, möchte ich das neue Frontend zum laufen bringen.
Ich scheitere im Moment an der Installations Anleitung "EMS-Tools
(c) 2014 by Michael Moosbauer" punkt:
5. Start the x emsclient in the CLI-Subdir.
Ich bekomme folgende Fehlermeldung:
helmut@helmut-VirtualBox:~/ems-collector/ems-tools/cli$ bash emsclient
emsclient: Zeile 2: ?php: Datei oder Verzeichnis nicht gefunden
emsclient: Zeile 3: Syntaxfehler beim unerwarteten Wort
»"emsincludes/emsqry.inc"«
emsclient: Zeile 3: `require("emsincludes/emsqry.inc");'
PHP ist installiert, der Pfad ist auch richtig.
P.s.: bin leider kein Linux Kenner, ich habe vermutlich wieder einmal
was nicht richtig verstanden.
Helmut Jato(Helmbrot) schrieb:> emsclient: Zeile 2: ?php: Datei oder Verzeichnis nicht gefunden
kann es sein dass in Zeile 2 nur ?PHP und nicht <?PHP steht?
Hats Du das Original GIT oder das von mir geforkte und von Danny
weiterentwickelte genommen?
IngoF schrieb:> Helmut Jato(Helmbrot) schrieb:>> helmut@helmut-VirtualBox:~/ems-collector/ems-tools/cli$>> Das hört sich nach dem ems-collector an.> Müsste es nicht das Frontend (von Mossys Frontend geforkt) sein:> https://github.com/ingof/ems-php-webinterface
Hallo IngoF, ich verwende die aktuellen ems-tools aus dem Wiki.
Zu "Start the x emsclient in the CLI-Subdir":
Was bedeutet das x ? emsclient ist doch ein script und wird einfach
durch < emsclient <return> gestartet. Wenn ich das mache kommt:
helmut@helmut-VirtualBox:~/ems-collector/ems-tools/cli$ emsclient
emsclient: Befehl nicht gefunden.
Helmut Jato(Helmbrot) schrieb:> IngoF schrieb:> durch < emsclient <return> gestartet. Wenn ich das mache kommt:> helmut@helmut-VirtualBox:~/ems-collector/ems-tools/cli$ emsclient> emsclient: Befehl nicht gefunden.
das schon versucht:
./emsclient
vermutlich sucht er sonst emsclient im Pfad und nicht im lokalen
Verzeichnis.
Keine Ahnung was das x bedeuten soll..
IngoF schrieb:> Helmut Jato(Helmbrot) schrieb:>> IngoF schrieb:>>> durch < emsclient <return> gestartet. Wenn ich das mache kommt:>> helmut@helmut-VirtualBox:~/ems-collector/ems-tools/cli$ emsclient>> emsclient: Befehl nicht gefunden.>> das schon versucht:> ./emsclient>> vermutlich sucht er sonst emsclient im Pfad und nicht im lokalen> Verzeichnis.>> Keine Ahnung was das x bedeuten soll..
Ja das war ein guter Tipp, danke. Der emsclient läuft jetzt wie in der
Installationsanleitung beschrieben.
Mit dem ems-php-webinterface habe ich jetzt noch ein Problem, siehe
Anlage.
Das muss irgendwas mit der Funktion menu() in top.php zu tun
haben,eventuell rechte?
Guten Morgen :)
Nachdem ich den Thread jetzt mehrfach gelesen habe, blicke ich leider
immer noch nicht zu 100% durch, was ich jetzt benötige um meine
Adapterplatine von Ingo (1. Version ohne Ethernet) an einen Raspi zu
bekommen.
Brauche ich dafür einen Umbau meiner Platine (auf Ethernet) oder reicht
der Originalzustand ?
Und dann benötige ich noch zusätzlich den NetIO oder benötige ich den
dann nicht mehr, sondern nur einen Raspi?
Wäre toll jemand mir das jemand für einen DAU erklären könnte :D
Gruß
Jens
Eigentlich nur ein ENC28J60 Ethernet-Platine und ein paar Kabel.
Und neue Firmware.
Notfalls muss noch der Spannungsregler ausgetauscht werden.
Werde mir noch mal das Layout ansehen und eine kleine Anleitung
"basteln"..
Na das klingt doch fast zu einfach :)
So etwas geht?
ENC28J60 Ethernet LAN Network Module For Arduino
Chip board ENC28J60-I/SO<
The board 25MHZ crystal
The network interface board HR911105A
3.3 V power supply pin
3.3 V power supply pin bedeutet dann entweder 5v oder 3,3V oder bedeutet
es NUR 3,3V ?
Unter welchen Umständen muss denn der Spannungsregler ausgetauscht
werden ?
Gruß
Jens
Der ENC28J60 darf nur mit einer Versorgungsspannung von 3,3V betrieben
werden. Die Eingänge sind 5V tolerant. Man kann den ENC28J60 deshalb
direkt am 5V Datenbus betreiben.
Meinst Du die Platine vom Ingo; EMS Gateway? Da habe ich die Spannung
nach dem 5V Spannungsregler abgegriffen. Allerdings habe ich die
Versorgungsspannung vom Netzteil vermindert, damit die Verlustleistung
geringer wird und der Spannungsregler nicht zu heiß wird. Der ENC28J60
kann, so weit ich weiß, bis 200mA Strom ziehen.
@Ingo, ich habe noch nicht herausgefunden wie ich die Daten in die
Datenbank bekomme, da ich kein Raspi habe. Ist es möglich mit deiner
Platine direkt die Daten in die Datenbank zu schreiben?
Jens schrieb:> Unter welchen Umständen muss denn der Spannungsregler ausgetauscht> werden
Der Spannungsregler der in der Platine verbaut wurde kann nur 100mA
Strom liefern.
Also wenn der Strom für die Ethernet-Platine hinter diesem Regler
entnommen wird muss der alte Spannungsregler ausgetauscht werden. Es
gibt allerdings keinen Pinkompatiblen Spannungsregler.
Durch Ausbau von Gleichrichter und Spannungsregler und schließen von
Lötbrücken kann die Platine auch mit 5V aus dem Netzteil versorgt
werden. Das Schaltnetzteil muss dann auf 5Volt umgestellt werden.
Habe ich noch nicht probiert. Sollte aber gehen.
Dann eine Ethernetplatine mit 3,3 Volt SPannungsregler an die 5Volt
anbinden.
Oder aber die Spannung für die 3,3 Volt von der Eingangsspannung nehmen.
Allerdings sollte das Schaltnetzteil auf 9 Volt stehen bleiben. Beim
herunterdrehen der Eingangsspannung kommen hinter dem 5-Volt
Spannungsregler keine 5 Volt mehr heraus.
F. F. schrieb:> Der ENC28J60 darf nur mit einer Versorgungsspannung von 3,3V betrieben> werden. Die Eingänge sind 5V tolerant.
Das stimmt so. Allerdings gibt es auch wenige Platinen die umschaltbar
zwischen 5 und 3,3 Volt sind. Dort ist dann noch ein 3,3Volt-Regler auf
der Platine.
Ich kann nur den von ElekFreak empfehlen weil ich ihn schon mehrfach
verwendet habe:
http://www.elecfreaks.com/estore/enc28j60-mini-ethernet-module-3-3v-5v-bk-enc28m.html
Ist nur lange auf dem Versandweg...
Es gehen auch andere mit 5Volt. Oder eben 3,3 Volt und Du musst Dich um
den Spannungsregler selber kümmern.
F. F. schrieb:> @Ingo, ich habe noch nicht herausgefunden wie ich die Daten in die> Datenbank bekomme, da ich kein Raspi habe. Ist es möglich mit deiner> Platine direkt die Daten in die Datenbank zu schreiben?
Nein, bisher nicht.
Möglich wäre es aber bestimmt mit der richtigen Programmierung.
Bisher geht nur der Weg über ein Programm auf einer Linux-maschine
(RASPI, Diskstation (über Docker), PC/Notebook, ....)
Inzwischen soll das eventuell auch auf Windows gehen.
Hallo F.F., danke für die Antwort ... ja, Ich meine die EMS Gateway
Platine von Ingo.
Dann warte ich mal auf eine Anleitung von Ingo, da ich weder weiß wo ich
was abnehmen müsste, noch auf was ich sonst zu achten habe ;)
Hmm .. jetzt habe ich doch zu lange für die Antwort gebraucht !? Könnte
schwören eben war die von Ingo noch nicht da.
@Ingo: Würdest du eine detaillierte Anleitung zur Verfügung stellen
incl. Liste der benötigten Bauteile ? liebguck
Ich möchte nämlich von der USB Schnittstelle und vom Windows Rechner weg
und auf einen Raspi umziehen.
Jens schrieb:> @Ingo: Würdest du eine detaillierte Anleitung zur Verfügung stellen> incl. Liste der benötigten Bauteile ? liebguck> Ich möchte nämlich von der USB Schnittstelle und vom Windows Rechner weg> und auf einen Raspi umziehen
Gene... Muss nur die alten Eagle-Dateien wiederfinden.... Kann noch
etwas dauern...
Jens schrieb:> Dann warte ich mal auf eine Anleitung von Ingo,
So, die Anleitung besteht aus schönen bunten Bildern:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:emsgwumbau#ethernet_nachruestung
Bei V2.1 muss eigentlich nur ein 1:1 Verbindungskabel genommen werden.
Allerdings sind Kabel 6(blau) und 7(violett) vertauscht.
Bei der Platine V2.0 muss man sich an mehreren verschiedenen
Steckeverbindern "bedienen".
Dabei muss reicht es nur einen gleichfarbigen Puntk auszusuchen.
Je nachdem welche noch frei sind oder welche gerade am besten passen.
Und der Spannungsregler von der Platine muss ausgelötet werden und eine
TO220-Version "eingebaut" werden. Habe jeweils alle möglichen Punkte
gekennzeichnet.
Dabei auf jeden Fall auf Stabilität und und Kurzschlusssicherheit
achten.
Denke es wäre am einfachsten die Beine zurechtzubiegen und auf der
Platine anzulöten. Und dann die Beine mit Heisskleber gegen Sichern.
Das Sichern mit Heisskleber ist auch bei den Kabeln zu empfehlen wenn
die direkt in die Lötpunkte angelötet werden.
Gruß
Ingo
Hallo Ingo,
werde heute anfangen die Platine umzubauen und hätte da noch ne Frage
zur Firmware. Ich benötige ja in meinem Fall die FW für die alte Platine
mit Eth. Support, wie komme ich daran (ist nicht im WIki hinterlegt) und
wann muss ich die aufspielen, vor dem Umbau oder danach oder ist das
egal ? Gibts dabei noch etwas zu beachten ?
Gruß
Jens
Nur aus Neugier: habt Ihr schon mal über ein ESP8266 WLAN Modul
nachgedacht? Das ist billig und praktisch.
Für den Datenverkehr wünsche ich mir eigentlich ein Gerät im Zentrum
(Raspi, Syno NAS usw.), das als MQTT Message Broker von allen SmartHome
Geräten Messages empfängt und allen erlaubt, andere Messages zu
abonnieren. Das würde die Integration verschiedener Dinge erheblich
vereinfachen...
Was meint Ihr?
Hmm,
so (Beitrag "EMS > ESP8266-12 WLAN-Modul") in etwa?
Mit der esp-link Basis von TvE sind bereits folgende Funktionalitäten
vorhanden: Web-Server, MQTT Client, syslog Client, telnet Interface,
SNTP
Aber ich denke, das ist in dem zitierten Thema besser aufgehoben - ich
will hier nicht hijacken oder das Thema verwässern...
Jens schrieb:> Äh .. wie jetzt ? geht nicht oder doch? Du musst erst noch basteln> oder> ich kann eine davon benutzen ?? verwirrt bin
Die Firmware ist damals für die größeren PIC erstellt worden.
Der alte PIC hat weniger Speicher.
Muss mir das mal genauer ansehen wieviel Speicherplatz die Firmware
verwendet und ob das mit dem alten PIC noch passt.
Auf meinem Rechner will er gerade die Firmware nicht mehr kompilieren.
Und heute habe ich keine Zeit dazu....
Erst mal sehen wie der Stand der Dinge ist...
IngoF schrieb:> Bitte mal Rückmeldung geben wenn Deine Platine erfolgreich getestet> wurde.>
Heureka! Die Platine funktioniert!
Hab mir zwischenzeitlich aus Frust die fertige, gebrauchte Platine von
Frank gekauft, aber nun ist mein eigenes Platinchen fertig, der NetIO
geflashed und auch der collectord läuft rund.
*Damit habe nun ich eine fertige Platine und einen fertig mit ethersex
geflashten 644p abzugeben. Falls jemand Interesse hat, PM an mich.*
Über folgende Dinge bin ich beim erstellen der Software gestolpert und
würde daher folgendes im Wiki ändern:
- beim "apt-get" /libboost1.50-all/ in libboost-all-dev ändern (auf
den aktuellen Raspbians ist die aktuell V1.55 in diesem Meta-Package
drin)
- die Konfiguration des Mysql-Users aus dem "Tipps"-Abschnitt direkt
nach der (berechtigten) Kaffee Bemerkung einfügen
Grüße
Torsten G.
Torsten G. schrieb:> Über folgende Dinge bin ich beim Erstellen der Software gestolpert und> würde daher folgendes im Wiki ändern:> ...
... erledigt!
Danke für den Hinweis!
Helmut J. schrieb:> Mit dem ems-php-webinterface habe ich jetzt noch ein Problem, siehe> Anlage.> Das muss irgendwas mit der Funktion menu() in top.php zu tun> haben,eventuell rechte?
Hallo Helmut
wurde in einem frühen Post schonmal erwähnt, man muss folgende Änderung
vornehmen:
Datei: mconfig.php, erste Zeile
<?
ändern in
<?php
Der Fix ist noch in keinem der GIT-Repositories gelandet (und ich hab
keine Ahnung von forken und einchecken ;-) )
Grüße
T.
Torsten G. schrieb:> Datei: mconfig.php, erste Zeile> <?
Eigentlich hatte ich bei verschiedenen Dateien das schon ergänzt. Diese
hatte ich wohl vergessen.
Ist jetzt geändert und die Github-Links am Ende sind auch angepasst.
Bei den anderen Änderungen war Karl schneller...
ingof schrieb:> Auf meinem Rechner will er gerade die Firmware nicht mehr kompilieren.> Und heute habe ich keine Zeit dazu....
Habs gerade noch mal probiert.
Die Software benötigt 2240 Byte RAM und der alte PIC hat nur 1536.
So stark kann man den RAM-Verbrauch mal nicht so einfach einschränken.
Also werden noch folgende Bauteile benötigt (Bauform in Klammern):
2x 22pF Kondensator für Quartz (0805)
1x PIC 18F4685 (TQFP-44)
1x 10 MHz-Quartz (SM49)
Habe nur mal kurz überflogen. Bei Reichelt habe ich den PIC nicht
gefunden.
Bei HBE-Shop (farnel) sind dann für Bauteile und Versand etwa 32 Euro
fällig.
Dann wird aber noch ein Programmiergerät für den PIC notwendig.
Könnte das wohl für Dich einbauen und programmieren.
Müsstest dann nur Hin und Rückversand bezahlen.
Entweder Bauteile selber bestellen und mitschicken oder ich würde sie
dann für Dich bestellen
ingof schrieb:> ingof schrieb:>> Bei HBE-Shop (farnel) sind dann für Bauteile und Versand etwa 32 Euro>> fällig.>> Versand sind alleine 15 Euro....
Conrad:
1084328 - 62
155561 - 62
1279314 - 62
für 17EUR inkl Versand
Hallo Ingo,
vielen Dank.
Werde die Teile bestellen und Dir dann alles zuschicken.
Melde mich noch mal wenn die Teile da sind, der Pic hat leider
Lieferzeit von 1,5 Wo
Gruß
Jens
Hallo
nachdem nun alles läuft, soll das ganze noch einen höheren WAF bekommen
;-)
1.) Kann man den Raspi als 5V-Spannungsquelle für den NetIO nehmen? Ich
würde mir gerne ein Netzteil einsparen...
2.) Hat jemand seine Platine + NetIO in einem Gehäuse untergebracht?
Welches habt ihr da genommen?
Viele Grüße,
Torsten G.
Torsten G. schrieb:> ...> 1.) Kann man den Raspi als 5V-Spannungsquelle für den NetIO nehmen? Ich> würde mir gerne ein Netzteil einsparen...
NetIO (J6) und Raspi an einem Netzteil sollten kein Problem sein, wenn
das Teil ausreichend Leistung bringt; 2A sollten genügen.
> 2.) Hat jemand seine Platine + NetIO in einem Gehäuse untergebracht?
Nö, liegt noch offen. Mein Bastelkeller ist WAF-intolerant. ;-)
Gruß
Karl M.
Moin
bin mir nicht klar ob das bug oder feature ist:
Ich bekomme keine Raumtemperatur angezeigt. Die Variable
"roomcurrenttemperature" wird immer als "unbekannt" angezeigt. Da ich
eine Raumtemperatur geführte Heizung nutze und meine Bedieneinheit eine
Wert anzeigt, vermute ich ein Problem im EMS-Collector.
Any Ideas?
@Karl: meine Konstruktion steht in Sichtrichtung vom Bügelbrett und wenn
ich die tradierte Rollenverteilung beibehalten will, muss ein Gehäuse
her ;-)
Grüße
Torsten G.
Torsten G. schrieb:> bin mir nicht klar ob das bug oder feature ist:> Ich bekomme keine Raumtemperatur angezeigt. Die Variable> "roomcurrenttemperature" wird immer als "unbekannt" angezeigt. Da ich> eine Raumtemperatur geführte Heizung nutze und meine Bedieneinheit eine> Wert anzeigt, vermute ich ein Problem im EMS-Collector.
Wo genau wird dir etwas als 'unbekannt' angezeigt?
Zum Eingrenzen von Fehlern in Collector vs. Frontend ist es immer
hilfreich, sich mal mit Telnet auf den Daten-Port (meistens 7778) des
Collectors zu verbinden. Fällt der gesuchte Wert dort raus, ist das
Problem im Frontend, ansonsten im Collector.
>> (nicht "unbekannt", wie ich ursprünglich geschrieben habe)
Und du hast nur einen Heizkreis?
Starte den Collector mal bitte mit '-d message' und lade das Log mal
irgendwo hoch - ich guck dann mal rein.
Ein Tipp zum Gehäuse:
Im Beitrag "Re: EMS > Adapter > NetIO > Raspi" und ff.
hatte ich meine Lösung beschrieben. Sieht gut aus und nimmt alle
Komponenten auf. WAF ist auch OK, fast schon overkill, da im
Technikkeller installiert und das ist eigentlich mein Hoheitsgebiet.
Aber das Auge isst ja auch mit :-)
LG
N'Abend
Ich bin auf der Suche nach den nächsten Käfern im WebInterface, komme
aber nicht dahinter:
Im Webserver-Log kommen im 10-sekunden-Rhythmus folgende Fehler:
1
2016-04-19 21:10:44: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Notice: Undefined index: heater maintenancedue in /var/www/html/ems-php-webinterface/www/lemscnt.ajax on line 63
2
2016-04-19 21:10:44: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Notice: Undefined index: hk1 automode in /var/www/html/ems-php-webinterface/www/lemscnt.ajax on line 67
wenn ich die Seite "Livestatus" aufrufe.
@Danny: Ja, ich habe nur einen Heizkreis. Wg Log->PM
@Lorenz: Danke für den Hinweis - hab ich überlesen. So langsam wird der
Thread unübersichtlich ;-)
Servus
Torsten G.
Hallo,
Ich habe noch ein Problem mit Mosis ems-php-webinterface. Ich kann Daten
empfangen,aber scheinbar keine Anforderungen senden. Die TX LED leuchtet
nicht auf.
Leuchtet die TX LED auf, wenn eine Anforderungen versucht wird, oder
wenn die Anforderung erfolgreich gelaufen ist?
Fehlermeldung in Mosis emsclient:
z.B:
ems:/> hk1 getholiday
ERRTIMEOUT
ems:/>
der req uba geht.
ems:/> req uba
heater targettemperature = 30
ww targettemperature = 10
heater currenttemperature = 70.3
...
Konfiguration: Ölkessel GB125 mit RC35 und 2 Heizkreisen
Die Raumtemperatur steht an Offset 3, und 0x7d 0x00 ist 'nicht
verfügbar'. Warum das bei dir so ist, kann ich dir allerdings nicht
sagen; ich vermute aber mal, dass die RC (welche?) nicht dem Heizkreis
zugeordnet ist. Bei der RC30 steht der entsprechende Punkt in Abschnitt
5.8.4 der Serviceanleitung, bei der RC35 ist das Abschnitt 6.4.1.
Danny B. schrieb:> Die Raumtemperatur steht an Offset 3, und 0x7d 0x00 ist 'nicht> verfügbar'. Warum das bei dir so ist, kann ich dir allerdings nicht> sagen; ich vermute aber mal, dass die RC (welche?) nicht dem Heizkreis> zugeordnet ist. Bei der RC30 steht der entsprechende Punkt in Abschnitt> 5.8.4 der Serviceanleitung, bei der RC35 ist das Abschnitt 6.4.1.
Das war's! Meine RC30 war dem HK1 nicht zugeordnet. Das könnte eventuell
auch erklären, warum die Heizung bei 20,5° Solltemperatur immer noch
gebollert hat, obwohl die Bude auf 23° geheizt war...
roomcurrenttemperatur wird jetzt angezeigt und (oh wunder) die Heizung
folgt jetzt auch der Raumtemperatur.
* Danke Danny! *
Hallo zusammen,
ich habe jetzt mal versucht die alte Version der EMS Platine von Ingo
über USB (serial Port) mit einem Pi zu verbinden.
Installation nach Anleitung und scheinbar erfolgreich:
Mai 01 17:34:47 raspberrypi ems-collector[1470]: Starting EMS collector daemon: collectord.
10
Mai 01 17:34:47 raspberrypi systemd[1]: Started LSB: EMS collector daemon.
Die Firmware ist die aus dem Wiki (2.1 Beta 131118) und Ausgabemodus ist
RAW (getestet mit Putty über USB direkt an der Platine).
Auf der Webseite wird allerdings nix angezeigt, außer "Bitte warten
(10%)"
Das Rohdatenfenster bleibt auch leer.
Ausgabe der Daten im Terminalfenster:
pi@raspberrypi:~ $ sudo collectord -u ems -p password -f -d all
serial:/dev/ttyUSB0
IO: Got bytes 0x30 0x38 0x20
IO: Got bytes 0x30 0x30 0x20 0x31 0x39 0x20
IO: Got bytes 0x30 0x30 0x20 0x30 0x30 0x20 0x39 0x66 0x20 0x30 0x31
0x20 0x35 0x65 0x20
IO: Got bytes 0x38 0x30 0x20
IO: Got bytes 0x30 0x30 0x20 0x30 0x30 0x20 0x30 0x30 0x20 0x30 0x30
IO: Got bytes 0x20 0x33 0x66 0x20
Ist jetzt einfach nur das Datenformat noch nicht passend, so das der
Collector damit etwas anfangen kann oder habe ich Dinge bei der
Installation vergessen bzw. falsch gemacht.
Was kann ich noch tun um zu testen ob alles korrekt ist ?
Gruß
Jens
Jens H. schrieb:> Die Firmware ist die aus dem Wiki (2.1 Beta 131118) und Ausgabemodus ist> RAW (getestet mit Putty über USB direkt an der Platine).
Was hat denn der Test ergeben, was wurde denn da ausgegeben? Das was ich
hier sehe ist ASCII, nicht raw.
> Ausgabe der Daten im Terminalfenster:>> pi@raspberrypi:~ $ sudo collectord -u ems -p password -f -d all> serial:/dev/ttyUSB0> IO: Got bytes 0x30 0x38 0x20
08<space>
> IO: Got bytes 0x30 0x30 0x20 0x31 0x39 0x20
00 19
> IO: Got bytes 0x30 0x30 0x20 0x30 0x30 0x20 0x39 0x66 0x20 0x30 0x31> 0x20 0x35 0x65 0x20
00 00 9f 01 5e
> IO: Got bytes 0x38 0x30 0x20
80
usw.
Da ist im Gateway noch was schief...
Das sieht prinzipiell richtig aus, ist aber Ingo's (zu meinem
inkompatibles) Format (aa 55 data len 55 aa statt aa 55 len data
checksum). Darüber hatten wir ja schon mal gesprochen.
Ingo, hängst du noch an diesem Format oder könntest du das mit dem
Netz-Protokoll glattziehen?
Jens H. schrieb:> Ok, habe jetzt an statt der DIP Schalter das Ganze über Putty umgestellt> auf Kr 1 ... sollte dann jetzt aber RAW sein.
Dann hattest Du auch schon nicht mehr die erste Firmware drauf hatte ich
ncicht dran gedacht.
Danny B. schrieb:> Ingo, hängst du noch an diesem Format oder könntest du das mit dem> Netz-Protokoll glattziehen?
Nö, hatte historische Gründe. Werde das in der nächsten Zeit ändern.
Kann noch ein paar Tage dauern..
IngoF schrieb:> Nö, hatte historische Gründe. Werde das in der nächsten Zeit ändern.> Kann noch ein paar Tage dauern..
Das wäre toll, habe nämlich Urlaub und könnte dann weiter machen :)
Gruß
Jens
Jens H. schrieb:> Das wäre toll, habe nämlich Urlaub und könnte dann weiter machen :)
Kann natürlich keine Terminzusage machen.
Ist gerade schönstes Wetter und der Vorgarten ist gerade fertig
geworden..
Hallo,
ich habe den Raspberry Pi und den Net IO soweit zum laufen gebracht,
dass der CollectorD die Rohdaten anzeigt und richtig interpretiert.
Mein Problem: das Einrichten der ems-tools und des ems-php-webinterface
Beim starten des "emsclient" findet das Programm die
"emsincludes/emsqry.inc" nicht, obwohl ich im Linux root Verzeichnis ein
Symlink mit "ln -s" auf /home/pi/ems-tools/includes erstellt habe.
Unter emsincludes werden auch alle Dateien angezeigt.
Wozu wird der Symlink erstellt? Kann das Programm nicht einfach aus dem
Ausführordner auf die includes zugreifen?
Kann mir jemand einen Tip geben?
Gruß
Arnold
Arnold P. schrieb:> Hallo,> ich habe den Raspberry Pi und den Net IO soweit zum laufen gebracht,> dass der CollectorD die Rohdaten anzeigt und richtig interpretiert.>> Mein Problem: das Einrichten der ems-tools und des ems-php-webinterface>> Beim starten des "emsclient" findet das Programm die> "emsincludes/emsqry.inc" nicht, obwohl ich im Linux root Verzeichnis ein> Symlink mit "ln -s" auf /home/pi/ems-tools/includes erstellt habe.> Unter emsincludes werden auch alle Dateien angezeigt.>> Wozu wird der Symlink erstellt? Kann das Programm nicht einfach aus dem> Ausführordner auf die includes zugreifen?>> Kann mir jemand einen Tip geben?>> Gruß> Arnold
Welche Quellen hast Du genommen? github.com/ingof/... ??
Ich habe ja aus verschiedenen Quellen Bugfixes und Änderungen
eingepflegt.
Ich hatte zumindest mal gesehen dass die emsincludes relativ statt
absolut angegeben wurden. Hatte überlegt ob ich das eingepflegt hatte.
Also statt "/emsincludes" "emsincludes". Dann müsstest Du also in dem
Pfad in dem auf die emsincludes zugegriffem wird den link setzen un
nicht im root-Verzeichnis.
Kannst ja mal nachsehen in welcher Datei der Fehle gemeldet wird. Diese
Dateien öffnen und nachsauchen ob dort /emsinlcudes oder emsincludes
angegeben ist.
Ich habe gerade mal einige Dateien durcsucht aber weder /emsincludes
noch emsincludes gefunden.
Dann muss ich aber noch das Wiki anpassen...
Habe es gerade gefunden.
Die Pfade sind jetzt relativ. in Emsincludes steht folgendes:
1
require("emsincludes/emsqry.inc");
es würde reichen einfach den Order emsincludes ins Verzeichnis vom
emsclient zu verschieben oder zumindest den link dorthin zu erstellen.
Vielleicht kann ich das ja schon direkt github ändern.
Ingo F. schrieb:> Vielleicht kann ich das ja schon direkt github ändern.
Also ich habe den emsincludes dort gelassen wo er ist.
habe dann in emsclient den Pfad auf ../emsincludes geändert.
Genaus die Pfade in den Dateien im Scripts Ordner.
Ich hoffe ich habe nichts "verschlimmbessert"
Arnold P. schrieb:> Kann mir jemand einen Tip geben?
Sag mal bescheid ob es jetzt läuft.
Habe jetzt keinen Verweis im ems-php-webinterface auf /emsincludes
gefunden.
Falls doch kann man vermutlich nicht ganz so einfach komplett auf den
link im Wurzelverziehnis zu emsincludes verzichten...
Jens H. schrieb:> Das wäre toll, habe nämlich Urlaub und könnte dann weiter machen :)
So, habe mich bei dem schönen Wetter mal in den Keller verkrochen damit
Du Dich auch in den Keller verkriechen kannst ;-)
So sieht jetzt die Ausgabe aus:
1
AA 55 09 10 08 1A 00 00 00 00 00 91 93
2
AA 55 01 01 01
3
AA 55 01 01 01 AA 55 07 10 08 35 00 11 11 30 1D
@Danny sollte doche schon mal ganz gut aussehen, oder?
Denke das ACK muss noch anders gesendet werden (01)
Die Richtung emscollector Richtung EMS-Gateway ist noch unverändert.
Aber vielleicht hilft die Richtung emscollector schon mal etwas
weiter...
Werde Dir den ersten Versuch heute abend mailen.. Jetzt muss ich erst
mal wieder ans Tageslicht...
>> @Danny sollte doche schon mal ganz gut aussehen, oder?
Ja. Die Prüfsumme hab ich nicht nachgerechnet, ich traue dir allerdings
zu, ein running XOR zu implementieren ;)
> Denke das ACK muss noch anders gesendet werden (01)
Jup. Das sende ich als Fake-Paket: <source> <dest = 0xb> <type = 0xff>
<0x1 oder 0x4> - und das Framing natürlich noch außendrum. Ist für das
serielle Interface aber eh egal, da ich da senden im Moment nicht
unterstütze.
Jens H. schrieb:> Oh oh .. senden geht seriell nicht ? :(> Also muss ich doch auf Ethernet umbauen ?
Wenn du (in absehbarer Zeit) zur Heizung senden willst schon. Ich hatte
das nie implementiert, da meine damalige serielle Hardware (ein Atmega8)
nur eine serielle Schnittstelle hatte, man aber 2 gebraucht hätte. Das
kann man alles noch nachziehen, allerdings macht mir das aus 2 Gründen
im Moment Probleme: Zeitmangel und die fehlende Möglichkeit, das zu
testen. Wenn du etwas Geduld mitbringst (2-3 Wochen), kann ich das mal
testweise implementieren, damit du das verifizieren kannst.
Danny B. schrieb:> Jup. Das sende ich als Fake-Paket: <source> <dest = 0xb> <type = 0xff>> <0x1 oder 0x4>
Um Unklarheiten auszuschließen:
DU, als NetIO, sendest das Fake-Paket und nicht DU, als Collector?
Die ACK NACK werden ja auf dem EMS-Bus vom Bus-Master gesendet wenn ein
Telegramm beim Busmaster empfangen wurde. Der Bus-Teilnehmer sendet ja
diese Telegramme nicht.
Oder sendet der collector die Telegramme auch noch an den NetIO. Wenn
dann werden die nur vom NetIO ausgewertet und nicht an den EMS-Bus
weitergeleitet?!
Denke dann muss ich "EMS > EMS-GW > Raspi" im Wiki auch noch anpassen...
Danny B. schrieb:> ich traue dir allerdings zu, ein running XOR zu implementieren
Danke für das Vertrauen :-D
Danny B. schrieb:> und die fehlende Möglichkeit, das zu> testen.
Notfalls hätte ich noch zeitweise einen EMS-Gateway den ich dir
ausleihen könnte. Aber die hin und her schickerei lohnt sich wohl eher
nicht.
Das umbauen der Empfangsfunktion könnte bei mir auch so 2-3 Wochen
daueren.
Daten werden also größtenteils entschlüsselt.
Ne Idee was der Rest dazwischen ist, muss das so sein oder habe ich noch
Einstellungen zu ändern ?
Ich musste nämlich im Gateway die Option CatchAll auf 1 setzen, damit
über etwas ankommt.
Gruß
Jens
Hallo Jens,
schön zu hören dass es schon läuft.
Unhandled Message bedeutet nur dass das Telegramm dem Collector nicht
bekannt ist.
Aber das Telegramm 0x07 scheint generell noch nicht bekannt zu sein.
Das IOBytes sind die Daten die empfangen wurden
Sobald ein *MESSAGE[Zeitstempel]* ausgegeben wird hat der collector die
Nachricht (IOBytes) korrekt empfangen.
Das CatchAll ist defaultmäßig immer deaktiviert und muss erst aktiviert
sein.
Hat den Grund dass nicht sofort massenhaft Daten ausgegeben werden bevor
der EMS-Gateway richtig konfiguriert wurde.
Sonst ist aber schon alles eingestellt und muss/soll nicht mehr
verändert werden.
Hallo IngoF;
ich habe noch ein Problem im dem ems-php-webinterface gefunden:
Im Bild Live Status Bild unter Betriebsart wird der Automatik Betrieb
nicht angezeigt. Lösung:
In lemscnt.ajax zeile 67)
Den hk1 automode gibt es nicht. es gibt den hk1 opmode
67 print("<tr><td valign=top>Betriebsart</b><br><font size=+1>".($d["hk1
daymode"]=="on"?"Tag":"Nacht")."</font><br> ".($d["hk1
opmode"]=="auto"?"Automatik":"Manuell"));
Das Problem vom Arnold P. mit dem Symlink mit "ln -s" hatte ich auch.
"Beim starten des "emsclient" findet das Programm die
"/emsincludes/emsqry.inc" nicht".
Lösung: Habe unter Nautilus (Ubuntu) im Ordner
/home/helmut/ems-collector/ems-tools/includes eine Verknüpfung gesetzt
und diese ins /var/www/html kopiert.
Wie das über das Terminal geht würde mich sehr interessieren.
Die Änderungen mit dem "opmode" habe ich gerade so übernommen.
Dummerweise ist Github gerade nicht erreichbar...
Helmut J. schrieb:> as Problem vom Arnold P. mit dem Symlink mit "ln -s" hatte ich auch.
habe gerade gesehen dass es auch noch im ems-php-webinterface massenhaft
verknüpfungen nach /emsincludes gibt.
Wo kann man denn am besten den Link generell hinsetzen?
/emsincludes ist nicht soooo toll, oder?
Wohin packt man denn sowas am besten /opt/emsinludes, /etc/emsinclude,
/var/emsincludes oder vielleicht /home/user/emsincludes?
Oder wäre es nicht besser gleich den ganzen Order an einem bestimmten
Ort zu packen?
vielleicht kann ich dann ja eine install.sh Datei oder ähnliches
erstellen.
Gruß
Ingo
[quote]
pi@raspberrypi:~/ems-tools/cli $ ./emsclient
PHP Warning: require(../emsincludes/emsqry.inc): failed to open stream:
No such file or directory in /home/pi/ems-tools/cli/emsclient on line 3
PHP Fatal error: require(): Failed opening required
'../emsincludes/emsqry.inc'
(include_path='.:/usr/share/php:/usr/share/pear') in
/home/pi/ems-tools/cli/emsclient on line 3
[/quote]
Jens H. schrieb:> Helmut bei mir nicht funktioniert :(
Dieser symbolische Link ist für das php-webinterface. Also die Dateien
die im Webverzeichnis liegen und den zugriff zu den Dateien benötigen.
(aber sind dort wird doch auch auf die /emsinlcudes zugegriffen, oder?!)
Bei Dir meckert "emsclient"
Habe jetzt die Pfade wieder im GIT auf /emsincludes geändert.
Also einfach den symbolischen Link im Wurzelverzeichnis erzeugen wenn Du
die Dateien neu aus dem GIT geholt hast.
also:
Hallo Ingo,
Zu)
Wo kann man denn am besten den Link generell hinsetzen?
/emsincludes ist nicht soooo toll, oder?
Ich meine /usr/local/lib ist nicht schlecht.
Gruß
Helmut
Helmut J. schrieb:> Ich meine /usr/local/lib ist nicht schlecht.> Gruß> Helmut
Ja, denke das ist generell schon mal ganz gut.
Allerdings sind (noch) alle Dateien auf "/emsincludes" gesetzt.
Dann müsstest Du jetzt erst mal selber sämtliche Dateien in den
ems-tools (4-5) und in ems-php-webinterface anpassen auf
"/usr/local/lib/"
oder eben erst einmal auf "/emsincludes" lassen und dann im
Wurzelverzeichnis erstellen.
Ich hatte den Link schon im Wurzelverzeichnis und auch schon mit dem /
vorne und auch ohne.
Den emsclient muss ich eigentlich wo hin kopieren? Ich habe die
ems-tools jetzt erst mal nur in /home/pi/ems-tools und habe im
Unterordner CLI dann den client gestartet!?
Bin aus der Installationsanleitung nicht schlau geworden :(
tcp 0 0 0.0.0.0:7778 0.0.0.0:* LISTEN aus (0.00/0/0)
Wie man sieht geht der 7778 einwandfrei, der 7777 ist nicht vorhanden,
wird also trotz Eintrag in der Config gar nicht erst gestartet. Hängt
das mit der fehlenden Sendeunterstützung per USB zusammen ? Falls nicht,
wo kann ich suchen um den Fehler zu finden ?
Dadurch das der 7777 nicht geht, wird im WebIf natürlich auch nix
angezeigt. Lediglich das Protokoll der Servicecodes geht.
Gruß
Jens
Jens H. schrieb:> Wie man sieht geht der 7778 einwandfrei, der 7777 ist nicht vorhanden,> wird also trotz Eintrag in der Config gar nicht erst gestartet. Hängt> das mit der fehlenden Sendeunterstützung per USB zusammen ? Falls nicht,> wo kann ich suchen um den Fehler zu finden ?
Ja, tut es. Ohne Sendeunterstützung ist der Kommando-Port vollkommen
sinnlos, weil sämtliche Kommandos senden können müssen, um zu
funktionieren; aus diesem Grund wird er ohne Sendeunterstüzung auch
nicht angeknipst.
Ok, so etwas hatte ich mir schon gedacht, schade. Dann muss ich warten
bis zu Zeit findest das einzubauen.
Auf die Daten kann ich mir zumindest schon mal über eine Verbindung zur
SqlDB von extern lesend zugreifen.
Wie ist das, besteht eigentlich die Möglichkeit die Daten, die auf dem
7778 angezeigt werden auch auf einem Port nach extern verfügbar zu
machen? Der 7778 geht ja nur lokal auf dem Raspi.
Gruß
Jens
Jens H. schrieb:> Wie ist das, besteht eigentlich die Möglichkeit die Daten, die auf dem> 7778 angezeigt werden auch auf einem Port nach extern verfügbar zu> machen? Der 7778 geht ja nur lokal auf dem Raspi.
Der muss auch von anderen Rechnern im Netzwerk erreichbar sein (und ist
es in meiner Installation auch). Sieht man ja auch in deiner
netstat-Ausgabe oben, dass er auf die IP 0.0.0.0 (= alle) gebunden ist.
Davon war ich ausgegangen, habe aber die Verbindung nicht hinbekommen,
aber ich habe die ganze Zeit den Port falsch übergeben. Kaum macht man
es richtig, schon funktioniert's.
Ich sollte das lieber tagsüber machen und nicht mitten in der Nacht. ;)
Vielen Dank für die schnellen Antworten.
Habe inzwischen durch die Pfandanpassungen die EMS Tools zum laufen
gebracht.
Im Moment komme ich mit dem Webinterface nicht weiter. Als Webserver
verwende ich den Lighttpd mit PHP addon.
Habe die www-Dateien von "https://github.com/ingof/ems-php-webinterface";
in den html Ordner des lighttpd kopiert(und die Konfigurationsdateien
angepasst). Im Webbrowser lassen sie sich öffnen, bekomme jedoch keine
EMS Daten angezeigt. Die Seite "EMS-Rohdaten" bleibt leer. Auch der
Funktionstest zeigt nichts an.
Im lighttpd log befinden sich auch keine Fehler.
Irgendwie klappt die Schnittstelle Webbrowser->EMS-Tools nicht.
Hat jemand eine Idee?
Gruß
Arnold
Also wenn die EMS-Tools einwandfrei laufen, dann sollte das klappen.
Siehst du den auf keiner Seite im Webfront etwas, auch keine
Fehlermeldung ?
Wie hast Du geprüft ob die Tools laufen ? Telnetverbindung zu 7777 und
7778 klappt ?
Gruß
Jens
Habe den Fehler gefunden. Durch eine falsche Zeiteinstellung auf dem Pi
habe ich die lighttpd server logs falsch interpretiert. Es war doch ein
Fehler eingetragen. Er hat eine Datei nicht gefunden.
Habe übersehen den Pfad in der Datei emsdetail.ajax zu korrigieren.
Scheint alles, bis auf die Statistik graphs, zu funktionieren.
Ingo, welches Format hättest du denn gerne als Input zum Senden über die
serielle? Ich hätte an etwas ähnliches gedacht wie beim Empfangen, nur
ohne Senderadresse ... also so in etwa:
0xaa 0x55 <len> <dest> <type> <payload0> ... <payloadX> <checksum>
wobei Checksum wieder das running XOR ist. Ich kann auch gerne noch die
Absenderadresse mit einfügen, dann ist's ganz konsistent.
Meinungen?
Danny B. schrieb:> 0xaa 0x55 <len> <dest> <type> <payload0> ... <payloadX> <checksum>
klingt doch gut. Und das running XOR startet dann auch bei <dest>.
Denke ich setze den Pfad bei den ems-tools und ems-php-webinterface auf:
1
/usr/local/lib/ems/include
Wie meintest Du das mit $PREFIX. Wo und wie hast Du das PREFIX gesetzt?
am liebsten würde ich auch dazu tendieren emstools und das
ems-php-webinterface in ein github-repository zu packen. Eigentlich wird
ja immer nur beides zusammen benötigt, oder?
Ingo F. schrieb:>> 0xaa 0x55 <len> <dest> <type> <payload0> ... <payloadX> <checksum>>> klingt doch gut. Und das running XOR startet dann auch bei <dest>.
Bin gerade dabei das neue Empfangsformat "einzubauen".
Denke es wäre besser doch noch die Quelladresse vom EMS-Bus einzubauen.
Sonst muss ich zuviel umbauen. Das erste Byte benutze ich zum erkennen
ob EMS-Daten oder CAN-Daten empfangen wurden.
also
Ingo F. schrieb:> 0xaa 0x55 <len> <src> <dest> <type> <payload0> ... <payloadX> <checksum>
Hallo Danny,
der "Serial Collector Support" ist jetzt drin und läuft
z.B die Abfrage für Datum und Zeit:
Guten Tag,
nach dem ersten Fehlschlag vor einigen Wochen habe ich nun mit einem
sauberen Raspbian Jessie neu gestartet. Das lief gleich vieeeeel besser
:) Momentan hängts beim Einrichten des Service und der Erreichbarkeit
auf Port 7777.
collectord wurde kompiliert und liegt nunmehr im Pfad
sudo /home/pi/ems-collector/collector/collectord -u ems -p *** -f -d all tcp:****:7950
ausführen. Dann funktioniert die Verbindung zum NetIO problemlos und die
Daten des EMS-Bus kommen an.
Jetzt habe ich die Configs wie im Wiki beschrieben angelegt.
1
/etc/default/ems-collector
und
1
/etc/ems-collector.conf
und jeweils das SERIALDEVICE sowie db-user und db-pass angepasst.
Die Datei
1
/etc/init.d/ems-collector
habe ich auch angelegt, aber Zeile 21 nicht angepasst. Dort steht
unverändert
1
PROG="/usr/local/sbin/$PROGNAME"
Einbindung in die Startscripte ist ebenfalls erfolgt.
1
service ems-collector
funktioniert auch. Dienst wird gestartet und gestoppt, Statusabfrage
funktioniert.
Aber Port 7777 ist nicht erreichbar. Ich habe die vage Vermutung, dass
die Verknüpfung von collectord und ems-collector nicht vorhanden ist?!
In welchen Pfad wird der ems-collector Ordner von Github normalerweise
abgelegt? Und wo muss die collectord hin? Kann die überhaupt unter
Nutzer "pi" verbleiben?
Wie muss ich jetzt beim Einrichten des Website verfahren? Sowohl
emstools als auch das Webinterface von Github laden und einrichten? Oder
reicht das Webinterface als standalone?
Der Server-Ordner wird im Wiki mit "srv/www" angegeben. Ist das bei
Verwendung von lighttpd analog der Ordner /var/www/html, aus welchem
aktuell das php-Skript für den Webserver geladen wird?
Freue mich auf eure Antworten!
Viele Grüße
Florian
Florian R. schrieb:> und jeweils das SERIALDEVICE sowie db-user und db-pass angepasst.jeweils ist bestimmt nicht gut. Such Die einen Ort für die
Konfiguration aus.
Ich fand es am besten in der einen Datei nichts anzugeben und Link zur
Konfigdatei zu aktivieren und dort dann alles festzulegen.
Probleme wird es spätestens dann geben wenn in einer Datei was anderes
Konfiguriert ist. Keine Ahnung was der collector dann daraus macht.
Habe das jetzt gerade mal im Wiki geändert
Florian R. schrieb:> Wie muss ich jetzt beim Einrichten des Website verfahren?
Zuerst die ems-tools "installieren" und testen.
Das ems-php-webinterface benötigt zwingend die ems-tools.
Florian R. schrieb:> Server-Ordner wird im Wiki mit "srv/www"
Das ist der Ordner in dem die Dateien für den Webserver liegen. Je nach
webserver gibt es einen anderen Pfad der angepasst werden muss.
Ingo F. schrieb:> Probleme wird es spätestens dann geben wenn in einer Datei was anderes> Konfiguriert ist. Keine Ahnung was der collector dann daraus macht.
Bislang haben Config-Datei-Optionen Kommandozeilenoptionen
überschrieben. Da das eher unüblich ist, habe ich das grade mal
geändert.
Vielen Dank für deine baldige Antwort Ingo!
Ingo F. schrieb:> Florian R. schrieb:>> und jeweils das SERIALDEVICE sowie db-user und db-pass angepasst.>> jeweils ist bestimmt nicht gut. Such Die einen Ort für die> Konfiguration aus.> Ich fand es am besten in der einen Datei nichts anzugeben und Link zur> Konfigdatei zu aktivieren und dort dann alles festzulegen.
Missverständnis. Wie in der Vorlage ist das SERIALDEVICE im
ems-collector eingetragen und alle übrigen OPTIONS Parameter im
ems-collector.conf. Nicht doppelt.
Aber was muss in Zeile 21 der /init.d/ems-collector rein? Der Pfad in
dem die collectord liegt? Und in welchem Verzeichnis legt man die
collectord am besten ab? Ich hab einfach zu wenig Erfahrung mit Linux,
um hier sinnvolle Schlüsse zu ziehen.
Hi Danny,
vielen Dank für die Erweiterung.
Leider habe ich mit der Verwendung vom Github und Linux nicht so viel
Erfahrung, weiß also gerade nicht so recht wie ich das Testen soll :(
Muss ich alles noch mal runter laden und das "make" neu ausführen oder
muss ich den Inhalt der Dateien manuell ändern/aktualisieren ? oder
beides ?
Gruß
Jens
Jens H. schrieb:> Leider habe ich mit der Verwendung vom Github und Linux nicht so viel> Erfahrung, weiß also gerade nicht so recht wie ich das Testen soll :(> Muss ich alles noch mal runter laden und das "make" neu ausführen oder> muss ich den Inhalt der Dateien manuell ändern/aktualisieren ? oder> beides ?
Ein 'git pull' im Collector-Verzeichnis sollte die Dateien
aktualisieren. Danach musst du make nochmal ausführen, um die geänderten
Dateien neu zu compilieren.
Ok, habe ich soweit erledigt.
Allerdings klappt irgendetwas noch nicht.
Den manuellen Aufruf (sudo collectord -u ems -p password -f -d
tx-serial:/dev/ttyUSB0) habe ich von 'serial:' auf 'tx-serial:'
geändert, aber der Aufruf klappt nicht, erst ohne den DB User und mit
serial: klappt es. Die Daten werden auch angezeigt. Warum dann die
unterschiedlichen Optionen in der Hilfe ?
1
pi@raspberrypi:~ $ sudo collectord -f -d all tx-serial:/dev/ttyUSB0
2
Exception: Target tx-serial:/dev/ttyUSB0 is invalid.
1
pi@raspberrypi:/ $ collectord
2
Usage: collectord [options] <target>
3
4
Possible values for target:
5
serial:<device> Connect to serial device <device> without sending support (e.g. Atmega8)
6
tx-serial:<device> Connect to serial device <device> with sending support (e.g. EMS Gateway)
7
tcp:<host>:<port Connect to TCP address <host> at <port> (e.g. NetIO)
8
9
General options:
10
-h [ --help ] Show this help message
11
-R [ --rc-type ] arg Type of used room controller (rc30 or rc35)
12
-r [ --ratelimit ] arg (=60) Rate limit (in s) for writing numeric sensor
13
values into DB
14
-d [ --debug ] arg (=none) Comma separated list of debug flags (all, io,
15
message, data, stats, none) and their files,
16
e.g. message=/tmp/messages.txt
17
18
Daemon options:
19
-P [ --pid-file ] arg (=/var/run/collectord.pid)
20
Pid file path
21
-f [ --foreground ] Run in foreground
22
-c [ --config-file ] arg File name to read configuration from
23
24
TCP options:
25
-C [ --command-port ] arg TCP port for remote command interface (0 to
26
disable)
27
-D [ --data-port ] arg TCP port for broadcasting live sensor data (0 to
Beim starten vom Service (service ems-collector start) bekomme ich keine
Fehlermeldung, aber selbst eine Telnetverbindung zu 7778 geht nicht
mehr. Also muss noch irgendwo ein Fehler sein bzw. ich mache irgendwo
noch einen Fehler :(
Wie muss der korrekte Eintrag in /etc/default/ems-collector sein? Denn
egal wie ich das eintrage, es klappt nicht.
SERIALDEVICE="tx-serial:/dev/ttyUSB0"
SERIALDEVICE="serial:/dev/ttyUSB0"
SERIALDEVICE="/dev/ttyUSB0"
Starte ich wie oben angegeben und incl. Angabe der Ports:
sudo collectord -C 7777 -D 7778 -f -d all serial:/dev/ttyUSB0
dann kann ich mich auf den 7778 verbinden, aber nicht auf den 7777.
Also, ich konnte mittlerweile auf den Port 7777 zugreifen, nachdem ich
die collectord wie im readme vom ems-collector beschrieben in den neuen
Pfad /usr/local/sbin/ verschoben habe.
Diese Info fehlt eindeutig im Wiki.
Alternativ hat aber auch der Verweis auf den Pfad
/home/pi/ems-collector/collector/ funktioniert.
Das Webinterface ist nun auch aufrufbar, aber mangels erfolgreicher
ems-tools Installation bisher nicht funktionsfähig.
Irgendwie ist das alles ein seeehr unübersichtliches Unterfangen. Für
jemanden, der nicht mit allen Themenbereichen gleichermaßen
Berührungspunkte hat, echt nicht so easy zu händeln.
Momentan hängts beim emsincludes symlink. Das Verzeichnis steht,
Verknüpfung ist vorhanden, aber beim Ausführen des emsclient wird
folgender Fehler ausgeworfen:
1
$ sudo /home/pi/ems-tools/cli/emsclient
2
PHP Warning: require(/emsincludes/emsqry.inc): failed to open stream: No such file or directory in /home/pi/ems-tools/cli/emsclient on line 4
3
PHP Fatal error: require(): Failed opening required '/emsincludes/emsqry.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /home/pi/ems-tools/cli/emsclient on line 4
Wo soll diese emsqry.inc denn herkommen? Berechtigung für /emsincludes
habe ich auf 775 gesetzt. Sollte also nicht das Problem sein?!
Bleiben die Datein der ems-tools im Verzeichnis /home/pi/ems-tools oder
müssen die auch woanders hin?
Jens H. schrieb:> Ok, habe ich soweit erledigt.> Allerdings klappt irgendetwas noch nicht.>> Den manuellen Aufruf (sudo collectord -u ems -p password -f -d> tx-serial:/dev/ttyUSB0) habe ich von 'serial:' auf 'tx-serial:'> geändert, aber der Aufruf klappt nicht, erst ohne den DB User und mit> serial: klappt es. Die Daten werden auch angezeigt. Warum dann die> unterschiedlichen Optionen in der Hilfe ?>>
1
> pi@raspberrypi:~ $ sudo collectord -f -d all tx-serial:/dev/ttyUSB0
2
> Exception: Target tx-serial:/dev/ttyUSB0 is invalid.
3
>
Oops. Fixed:
https://github.com/maniac103/ems-collector/commit/ff29e651909d8013e9628fa126d60f430f8d270e
Sorry, ich hätte es mal probieren sollen. :-/
> Wie muss der korrekte Eintrag in /etc/default/ems-collector sein? Denn> egal wie ich das eintrage, es klappt nicht.>> SERIALDEVICE="tx-serial:/dev/ttyUSB0"
Für deinen Fall das hier ^
> Starte ich wie oben angegeben und incl. Angabe der Ports:> sudo collectord -C 7777 -D 7778 -f -d all serial:/dev/ttyUSB0>> dann kann ich mich auf den 7778 verbinden, aber nicht auf den 7777.
Das wiederum ist normal, da 'serial' nicht senden kann.
Ok, make läuft, Rückmeldung kommt nachher.
Aber noch mal eine Frage zum 'make' ... in der Anleitung (readme) steht
das mehrere Optionen im makefile zur Verfügung stehen.
Beim ersten mal (und auch jetzt) habe ich dort nichts verändert, aber
trotzdem hat beim ersten Mal der MySql Datenbanksupport funktioniert
(Daten waren in der DB vorhanden und somit funzt ja auch das lesen der
RAW Daten).
Ist das ein Fehler in der Anleitung oder wie muss man die Optionen im
Makefile verstehen ? Denn das ist ja Default alles auskommentiert und
trotzdem lief es beim ersten Mal !? Hätte ich dort etwas auskommentieren
müssen oder nicht?
Gruß
Jens
Jens H. schrieb:> Ok, make läuft, Rückmeldung kommt nachher.>> Aber noch mal eine Frage zum 'make' ... in der Anleitung (readme) steht> das mehrere Optionen im makefile zur Verfügung stehen.> Beim ersten mal (und auch jetzt) habe ich dort nichts verändert, aber> trotzdem hat beim ersten Mal der MySql Datenbanksupport funktioniert> (Daten waren in der DB vorhanden und somit funzt ja auch das lesen der> RAW Daten).> Ist das ein Fehler in der Anleitung oder wie muss man die Optionen im> Makefile verstehen ? Denn das ist ja Default alles auskommentiert und> trotzdem lief es beim ersten Mal !? Hätte ich dort etwas auskommentieren> müssen oder nicht?
Früher war MySQL-Unterstützung unkonditional eincompiliert, inzwischen
nicht mehr.
So Rückmeldung
Starten mit :
sudo collectord -C 7777 -D 7778 -u ems -p password -f -d all
tx-serial:/dev/ttyUSB0
klappt, beide Ports erreichbar und auch das Webinterface läuft!
Was nicht klappt ist den Service zu starten !?
1
pi@raspberrypi:~/ems-collector/collector $ sudo service ems-collector start
2
Job for ems-collector.service failed. See 'systemctl status ems-collector.service' and 'journalctl -xn' for details.
3
4
pi@raspberrypi:~/ems-collector/collector $ systemctl status ems-collector.service
Ich weiß leider nicht wo ich suchen soll, ein Journal wird nicht
gefunden.
/etc/default/ems-collecter
1
# Defaults file for EMS collector daemon
2
# This is a POSIX shell fragment
3
4
# config file location
5
CONFIGFILE="/etc/ems-collector.conf"
6
7
# Serial device file
8
SERIALDEVICE="tx-serial:/dev/ttyUSB0"
9
10
# Where to put the PID file
11
PIDFILE="/var/run/ems-collector.pid"
12
13
# Other options
14
OPTIONS=""
/etc/ems-collector.conf
1
ratelimit = 120
2
rc-type = rc30
3
db-user = ems
4
db-pass = password
5
command-port = 7777
6
data-port = 7778
edit
Ok, habe nun DB User+Pass und die beiden Ports bei den Options mit
eingetragen, nun gehts! Irgendwie wird die Config Datei nicht richtig
eingebunden. Was ist mit ratelimit und rc-type, das habe ich noch in der
Config drin gelassen !?
Danny B. schrieb:> Ein 'git pull' im Collector-Verzeichnis sollte die Dateien> aktualisieren. Danach musst du make nochmal ausführen, um die geänderten> Dateien neu zu compilieren.
Hallo Dany,
leider klappt das so nicht.
Weil ich das Makefile ja lokal verändert habe meckert GIT dass ich meine
änderungen erst comitten soll...
Ich möchte aber einfach nur alles überschreiben, das Makefile verändern
und das make starten.
Wie bekommt man das hin ohne manuell den Ordner zu löschen und neu zu
clonen?
"git fetch -all" hat auch nicht geholfen.
Es muss doch auch ohne löschen des GIT-Ordners gehen, oder???
Ich habe gerade mal den collectord neu kompiliert.
Leider lässt der sich nicht mehr starten.
Bekomme dann folgendes:
1
[.....] Starting EMS collector daemon: collectordException: Can't connect to local MySQL server throug Socket '/var/run/mysqld/mysqld.sock' (2)
Mit den alten quellen funktioniert es aber problemlos.
Habe noch mal apt-get update und upgrade gemacht. Immer noch das selbe.
kann die alten und neuen Quellen kompilieren.
Beim alten collectord läuft alles (auch neu kopmiliert). Beim neuen
collectord bekomme ich ihn mit [code]service ems-collector start[code]
nicht neu gestartet.
Die Config-files und alles habe ich so belassen. nur ems-collector
gestoppt collectord in /usr/local/sbin kopiert und neu gestartet.
Auch wenn ich ems-collector.init in /etc/init.d kopiere umbenenne und in
die Startscripte einarbeite ändert sich nichts.
Edit:
Habe natürlich auch in beiden Makefiles die selben Zeilen "aktiviert"
Ingo F. schrieb:> Danny B. schrieb:>> Ein 'git pull' im Collector-Verzeichnis sollte die Dateien>> aktualisieren. Danach musst du make nochmal ausführen, um die geänderten>> Dateien neu zu compilieren.>> Hallo Dany,>> leider klappt das so nicht.> Weil ich das Makefile ja lokal verändert habe meckert GIT dass ich meine> änderungen erst comitten soll...
Ja dann tu das doch ;-)
git commit -a
git fetch
git rebase
alternativ wegsichern und nach dem Update wiederherstellen:
git stash
git pull
git stash apply
>> Mit den alten quellen funktioniert es aber problemlos.
Was genau ist 'neu' und was ist 'alt'?
Existiert denn die entsprechende Socket-Datei? Der Pfad in der
Fehlermeldung kommt nicht aus meinem Code, sondern aus den
MySQL-Bindings. Wenn der nicht passt, ist es unwahrscheinlich, dass das
Problem in meinem Code liegt. Du kannst den Pfad aber mit --db-path
überschreiben.
Danny B. schrieb:> Ingo F. schrieb:>> Ich habe gerade mal den collectord neu kompiliert.>> Leider lässt der sich nicht mehr starten.>> Bekomme dann folgendes:>>[.....] Starting EMS collector daemon: collectordException: Can't>> connect to local MySQL server throug Socket>> '/var/run/mysqld/mysqld.sock' (2)>>> Mit den alten quellen funktioniert es aber problemlos.>> Was genau ist 'neu' und was ist 'alt'?
Also "Alt" laut "git log" der letzte commit von Dir vom 14.03.2016.
"neu" ist von heute (23.05.2016).
Habe keine Ahnung
> Existiert denn die entsprechende Socket-Datei? Der Pfad in der> Fehlermeldung kommt nicht aus meinem Code, sondern aus den> MySQL-Bindings. Wenn der nicht passt, ist es unwahrscheinlich, dass das> Problem in meinem Code liegt. Du kannst den Pfad aber mit --db-path> überschreiben.
Habe damals die Sourcen im Docker Container auf meiner Diskstation
testweise installiert.
jetzt habe ich den alten Git-Ordner auf ems-collector-alt umbenannt und
neu ausgechecked. Beim Kompilieren kommt bei beiden Sourcen kein Fehler.
Auch wenn ich die alten Sourcen neu kompiliere ändert sich nichts.
Am Anfang habe ich nur collectord mit den neuen und alten Quellen neu
kompiliert. ALso erst "make clean" und dann "make all". Dann nur den
ems-collector gestoppt, Datei ersetzt und dann neu gestartet.
Also im selben Docker Container ohne irgendwas neu zu installieren oder
zu löschen.
Habe dann auch mal ein apt-get update und upgrade durchgeführt. Es hat
sich daran nichts geändert.
Habe auch mal versucht dann die Datei aus den Sourcen in die /etc/init.d
kopiert und umbenannt. hat sich auch nichts geändert.
Edit:
Kannst Du den Wiki-Link im Install-Text in Github ändern.
ems-gateway.myds.me ist nur noch meine Spiel-Url. Aber auf den Richtigen
Dokuwiki-server landet man nicht mehr.
also "emswiki.thefischer.net/......"
Ingo F. schrieb:> Also im selben Docker Container ohne irgendwas neu zu installieren oder> zu löschen.
Ein Bild sagt mehr als tausend worte...
a steht für alte Quellen
n steht für neue Quellen
1 war für den Durchgang vor apt-get Update/Upgrade
2 war der komilierdurchgang nach apt-get Update/upgrade
Edit:
sorry... ist dreimal der selbe Anhang...
Jens H. schrieb:> wie sind die> Einstellungen
Werde mich morgen eventuell noch mal dransetzen.
Habe heute das Webinterface auf der Diskstation mit dem "alten"
collector fast komplett zum laufen gebracht. Irgendwie wird nur das Bild
für Heizkennline erstellt. Vermutlich bricht GnuPlot bei calcemsgraps.sh
ab weil er die Schriftart "Arial" nicht findet ?!
Habe dann auch eine Anleitung für das Webinterface zusammengebastelt...
http://emswiki.thefischer.net/doku.php?id=wiki:ems:webinterface
Ingo F. schrieb:> Danny B. schrieb:>> Ingo F. schrieb:>> Existiert denn die entsprechende Socket-Datei? Der Pfad in der>> Fehlermeldung kommt nicht aus meinem Code, sondern aus den>> MySQL-Bindings. Wenn der nicht passt, ist es unwahrscheinlich, dass das>> Problem in meinem Code liegt. Du kannst den Pfad aber mit --db-path>> überschreiben.
Habe jetzt erst Zeit gefunden das Problem einzugrenzen.
den "alten" collector habe ich so gestartet und konfiguriert dass er
problemlos lief.
den "neuen" collector habe ich jetzt testweise im Vordergrund am laufen.
Dazu musste ich erstmal mit "service mysql start" den SQL-Server
starten.
Dann kommt die Meldung dass user@localhost keine Berechtigungen hat.
Der manuelle Test klappt problemlos:
Also baute der "alte" collector ohne laufenden mysql-server die
Verbindung über den db-path auf.
Der "neue" collector benötigt einen laufenden mysql-server und er
übernimmt den "db-path" aus der Configurationsdatei nicht so wie der
alte collector.
hier mal meine Konfigurationen:
/etc/default/ems-collector:
1
# Defaults file for EMS collector daemon
2
# This is a POSIX shell fragment
3
4
# if you need further configuration
5
# config file location
6
CONFIGFILE="/etc/ems-collector.conf"
7
8
# Serial device file
9
# SERIALDEVICE="/dev/ttyUSB0"
10
SERIALDEVICE="tcp:192.168.1.3:7950"
11
12
# Where to put the PID file
13
PIDFILE="/var/run/ems-collector.pid"
14
15
# Other options -- command-port, data-port, db-user, db-pw, rate-limit (s) to write to db, target
16
# For debugging purposes insert "-d all=/var/log/ems-collector.log" before "tcp:...."
Edit : habe gerade den Parameter "-c" gefunden...
der alte collector läuft mit Angabe der Config-Datei. Der "neue"
collector läuft damit nicht.
1
collectord -c /etc/ems-collector.conf -f -d all tcp:192.168.1.3:7950
der "neue" collector bringt folgende Fehlermeldung:
1
Exception: Access denied for user 'root'@'localhost' (using password:NO)
Seltsamerweise scheint der "neue" collector über die Angabe config-Datei
über den Eintrag in der Datei "/etc/default/ems-collector" zumindest
schon mal den Usernamen "ems" zu übernehmen. Bei Angabe über Parameter
"-c" versucht er sich als "root" anzumelden.
Also auf meiner Diskstation läuft der eigentliche mySql-Server. Der
collector läuft auf der selben Diskstation unter Docker in einem
Container.
Habe beide Versionen im selben Container laufen gehabt. Es sollte
demnach nicht an unterschiedlichen Konfigurationen oder Bibliotheken
liegen.
Habe den "neuen" collector auch noch mal testweise einen neuen Container
spendiert und habe von vorne angefangen. Dort gibt es die selben
Probleme.
Es scheint ja fast so als ob der "alte" collector keine Socket
benötigt...
Oder doch irgendwie den Socket direkt von der Diskstation verwendet.
Aber das dürfte doch im Docker Image nicht möglich sein.
Aber warum gibt es diese Probleme wenn der "neue" collector die
Konfiguration aus der Datei laden soll?
Moin Ingo,
so tief stecke ich da zwar nicht drin, aber diese Problematik (hört sich
für mich zumindest so an) hatte ich auch schon angesprochen. Gelöst
hatte ich das mit der Eingabe der Parameter in den Options="" , danach
ging es dann!
Gruß
Jens
Ingo F. schrieb:> den "neuen" collector habe ich jetzt testweise im Vordergrund am laufen.> Dazu musste ich erstmal mit "service mysql start" den SQL-Server> starten.> Dann kommt die Meldung dass user@localhost keine Berechtigungen hat.> Der manuelle Test klappt problemlos:>
1
collectord -u ems -p geheim --db-path 192.168.1.2:3306 -f -d all
2
tcp:192.168.1.3:7950
>> Also baute der "alte" collector ohne laufenden mysql-server die> Verbindung über den db-path auf.
Nee, sorry, das ist Quatsch. Wie soll der Collector mit einem nicht
laufenden MySQL-Server kommunizieren? Eine theoretische Möglichkeit
dafür gäbe es mit systemd (der kann Daemons starten, wenn deren Socket
geöffet wird), aber ich glaube nicht, dass auf der Diskstation systemd
läuft. (Und ich bin mir auch nicht sicher, ob die Unterstützung dafür
überhaupt in MySQL drin ist)
> Der "neue" collector benötigt einen laufenden mysql-server und er> übernimmt den "db-path" aus der Configurationsdatei nicht so wie der> alte collector.
Der alte braucht auch einen laufenden MySQL-Server, s.o.
> Edit : habe gerade den Parameter "-c" gefunden...> der alte collector läuft mit Angabe der Config-Datei. Der "neue"> collector läuft damit nicht.>>
1
collectord -c /etc/ems-collector.conf -f -d all tcp:192.168.1.3:7950
>> der "neue" collector bringt folgende Fehlermeldung:>
1
Exception: Access denied for user 'root'@'localhost' (using
Danny B. schrieb:>> Also baute der "alte" collector ohne laufenden mysql-server die>> Verbindung über den db-path auf.>> Nee, sorry, das ist Quatsch.
Nee nicht so ganz. Vielleicht nicht so gut formuliert.
für den "alten" collector musste ich im Docker-Container keinen
mySql-Service starten.
Ob er jetzt über den laufenden mySQL-Server auf der Diskstation selber
Kontakt aufbauen konnte oder wie er das sonst geschafft hat ist mir
unbekannt.
Eigentlich ist es ja sogesehen Unsinn dass auf dem selben System zweimal
mySql läuft. Einmal auf Hauptrechner und dann nochmal im Container...
Natürlich kann man kein Gebäude betreten das keine Tür hat ;-)
Mit Linux kenne ich mich bisher nicht wirklich gut aus und habe keine
Ahnung ob systemd auf der Diskstation läuft
Danny B. schrieb:> Das ist das Problem: der neue Collector liest die Config-Datei nicht> mehr.
Das klingt schon mal sehr gut.
Werde das aber vermutlich erst nächste Wochen den collector neu
kompilieren können.
Ingo F. schrieb:>> Das ist das Problem: der neue Collector liest die Config-Datei nicht>> mehr.
Hallo Danny,
danke für die Änderungen.
Jetzt läuft auch der Collector, im Docker Container, so wie er soll...
Bei mir werden nur die Raumtermperaturen (Soll/Ist) nicht in der
Datenbank geloggt. Sensor 13 und 14 haben keinen einizigen Datenwert.
Im Webinterface werden die in den EMS-Rohdaten unter HK1 aufgelistet.
Die Schaltzeiten werden auch nicht erzeugt. Denke da wird es noch ein
Fehler im php-Webinterface geben,
Jens H. schrieb:> /graphs/schedule.png?
Kenn das Problem. Dachte es wäre nur bei mir so.
Habe aber noch keine Ursachenforschug gemacht.
Die shedule.png wird in a_emsshed.php ab Zeile 109 erzeugt.
Die Heizkurve wird bei mir aber angezeigt.
Wird denn die Grafik der Heizkurve bei Dir erzeugt?
Also das Script "calcheizkurve.sh"
Nein, wird scheinbar nicht erzeugt.
Es gibt allerdings auch keinen Ordner der Graphs heißt. In dem sollte
dann doch die Grafik liegen wenn ich das Script richtig interpretiert
habe !?
Kann das wieder mit irgendwelchen Include Pfaden zusammen hängen ?
Jens H. schrieb:> Nein, wird scheinbar nicht erzeugt.> Es gibt allerdings auch keinen Ordner der Graphs heißt. In dem sollte> dann doch die Grafik liegen wenn ich das Script richtig interpretiert> habe !?> Kann das wieder mit irgendwelchen Include Pfaden zusammen hängen ?
Denke nicht. Der Pfad ist in der a_emssched.php zumindest richtig
angegeben.
Wenn Du das Webinterface richtig installiert hast sollte der Unterordner
graphs im Webordner für das Webinterface erstellt worden sein.
Hier mal eine Anleitung für eine Diskstation:
http://emswiki.thefischer.net/doku.php?id=wiki:ems:webinterface
Die meisten Graphiken werden über ein Script der EMS-Tools erstellt. Das
Script sollte über einen Cron-Job automatisiert werden. zum testen kann
das script auch manuell gestartet werden
1
/usr/local/ems-tools/scripts/calcemsgraphs.sh
Die Grafik shedule.png wird über die Datei a_emssched.php im
Webinterface gestartet.
Hat jemand den ganzen "kram" in einem docker-container zum Laufen
gebracht?
Dann würde ich mich über eine Veröffentlichung freuen!
Ich würde es einfach als docker container auf der diskstation starten
und alles läuft? Wahnsinnig praktisch!
Falls das so noch nicht ist: wie kann ich dazu beitragen? Was ist der
Stand der Dinge bzgl. docker?
Bernd G. schrieb:> Ich würde es einfach als docker container auf der diskstation starten> und alles läuft?
JA
Hänge mal meinen Mittschnitt an.
Habbe es bei mir auf einem debian:wheezy Abbild am laufen.
Und dann musst Du Dich nur an meinem "Docker_Collector.txt"-Mitschnitt
orientieren...
Habe es noch nicht dokumentiert. Ist eben nur ein Mitschnitt der
benötigten Befehle.
die Anleitung für das Webfrontend ist hier:
http://emswiki.thefischer.net/doku.php?id=wiki:ems:webinterface
Wenn Du willst kannst Du auch gerne im Wiki die Diskstation-Anleitung
mit dem "Warnhinweis" durch eine Anleitung ersetzen.
Wenn Deine Diskstation den richtigen Prozessor hat sich Docker
installieren lässt sollte es keine Probleme geben.
Habe bisher nur noch das Problem dass sich die Schedule-Grafik nicht
erstellen lässt. Alles andere Läuft soweit. Bin nur noch nicht dazu
gekommen die Anleitung komplett zu erstellen und ins Wiki zu packen.
Ingo F. schrieb:> Wenn Du das Webinterface richtig installiert hast sollte der Unterordner> graphs im Webordner für das Webinterface erstellt worden sein.> Hier mal eine Anleitung für eine Diskstation:> http://emswiki.thefischer.net/doku.php?id=wiki:ems:webinterface
Hallo Ingo, warum genau muss der Ordner erzeugt werden, der Rest wird
doch auch nur einfach kopiert?
Das habe ich bisher immer überlesen, weil es für die Diskstation
beschrieben war und ich für nicht relevant gehalten habe -.-
Wenn man das Paket herunter lädt(Win Rechner) ist nur eine Datei die so
heißt dabei !? und auf dem Linux Rechner ist da lediglich eine
Verknüpfung auf "Graphs".
Jetzt muss ich den Ordner doch noch für den User pi frei geben, oder?
Werden die Grafiken dann bei Aufruf einer Seite erzeugt oder ist ein
Eintrag im Crontab dafür notwendig ?
edit
Ok, habe den Ordner erzeugt ... jetzt habe ich versucht das Script
manuell auszuführen und bekomme folgende Fehlermeldung:
Jens H. schrieb:> warum genau muss der Ordner erzeugt werden, der Rest wird> doch auch nur einfach kopiert?
Der Ordner existiert auch nicht im geklonten GIT. Also kann sie auch
nicht kopiert werden.
Eventuell der Symbolische Link "/emsincludes" nicht vorhanden oder fehlt
die config-Datei? Die Config-Datei müsste "config.py" heissen.
Vielleicht Rechte nicht vorhanden?
Was mich wundert ist der doppelte Schrägstrich "//"
Also der Symlink ist da und die config.py ist auch da.
Das mit dem Schrägstrich ist mir auch aufgefallen, kann ich mir mangels
Wissen dazu aber nicht erklären. Dachte für euch ist klar an was das
liegt und hatte auf eine Art: "Das kann auch nicht funktionieren weil
..." gehofft ;-)
Ich könnte noch mal versuchen den ganzen Kram neu zu machen, habe aber
im Moment etwas Bedenken das danach gar nix mehr läuft -.-
Gruß
Jens
Ok, der Fehler ist entweder in der Config oder im Script.
In der Config muss der Pfad (die Pfade?) mit abschließendem / eingegeben
werden oder nicht ?
Das Beispiel sagt ja ... dann müsste aber im Script der / im Aufruf von
"/ems-heizkurve.py" weg !?
Jens H. schrieb:> Ok, der Fehler ist entweder in der Config oder im Script.
In einer Konfiguration steht der ems-scriptpath. Dort ist bestimmt am
Ende ein "/".
Das einfach entfernen. Denke dann läuft es
Wie ist das denn mit dem Rest ?
Also mit dem Pfad zu tmp und Graph .. ebenfalls den abschließenden / weg
lassen ?
Beim Scriptpfad habe ich das gemacht, bei den beiden anderen
vorsichtshalber auch.
edit
Ich glaube das hängt mit emsincludes zusammen ... mein Ordner heißt
nämlich Includes (alte Version), aber ich habe in diversen Dateien schon
Änderungen vorgenommen. Dann muss ich wohl noch mal suchen bzw. doch
alles neu aufsetzen.
Schriftart hinzufügen habe ich hinbekommen (glaube ich).
1
sudo apt-get install ttf-mscorefonts-installer
Wenn ich jetzt
1
./calcemsgraphs.sh
ausführe, dann kommt keine Fehlermeldung, aber auch keine Grafik !?
Davon abgesehen ist aber noch die Sache mit dem Gnuplot. Die neueste
Version ist bereits installiert, wie dann weiter auf dem Raspi oder gilt
hier auch
Ok, Fehler gefunden ... in der config.py habe ich Tabellenname und
Passwort vertauscht -.-
Jetzt wird die Grafik der Heizkurve erzeugt, aber die die Schaltpunkte
weiterhin nicht.
Gruß
Jens
Jens H. schrieb:> Jetzt wird die Grafik der Heizkurve erzeugt, aber die die Schaltpunkte> weiterhin nicht.
Das ist im Moment bei mir auch so.
Habe noch keine Zeit gehabt zu Suchen wo das Problem liegt.
Der gnuplot-Link muss nicht erstellt werden und der Font muss auch nicht
installiert werden. Habe das im Text zwar geschrieben aber kann man
schnell überlesen. Habe noch mal einen Hinweis dafür eingefügt.
@maniac103:
Ich habe die Anleitung mit dem MQTT aus
https://emswiki.thefischer.net/doku.php?id=wiki:ems:openhab
nachvollziehen wollen, komme aber auf folgenden Fehler:
root@fhem:/home/bananapi/ems-collector/collector# make
g++ -Wall -c -O2 -std=c++0x -DHAVE_DAEMONIZE
-I../../mqtt_client_cpp/include -DMQTT_NO_TLS -DHAVE_MQTT main.cpp
In file included from
../../mqtt_client_cpp/include/mqtt/client.hpp:30:0,
from
../../mqtt_client_cpp/include/mqtt_client_cpp.hpp:8,
from MqttAdapter.h:28,
from main.cpp:31:
../../mqtt_client_cpp/include/mqtt/endpoint.hpp: In member function
‘bool mqtt::endpoint<Socket, Strand, Mutex,
LockGuard>::handle_connack(const async_handler_t&)’:
../../mqtt_client_cpp/include/mqtt/endpoint.hpp:1954:35: warning: use of
‘auto’ in lambda parameter declaration only available with -std=c++1y or
-std=gnu++1y
[this](auto& e){
^
In file included from main.cpp:31:0:
MqttAdapter.h: At global scope:
MqttAdapter.h:69:43: error: wrong number of template arguments (1,
should be 2)
mqtt::client<boost::asio::ip::tcp::socket> m_client;
^
In file included from
../../mqtt_client_cpp/include/mqtt_client_cpp.hpp:8:0,
from MqttAdapter.h:28,
from main.cpp:31:
../../mqtt_client_cpp/include/mqtt/client.hpp:39:7: error: provided for
‘template<class Socket, class Strand> class mqtt::client’
class client : public endpoint<Socket, Strand> {
^
Makefile:49: recipe for target 'main.o' failed
make: *** [main.o] Error 1
root@fhem:/home/bananapi/ems-collector/collector#
Hat der Autor von dem MQTT CPP git Änderungen gemacht, die noch nicht im
collectord enthalten sind?
Hallo zusammen,
da ich ziemlicher Laie bin was Mikrokontroller betrifft, möchte ich den
Adapter ungern selber bauen. Deswegen dachte ich, die Eagle Datei von
Maciej einem Leiterplattenhersteller zu senden, damit dieser mir einen
Prototypensatz daraus fertigt.
Denkt ihr das wär sinnvoll oder gibts es kostengünstigere Möglichkeiten,
wenn man nicht selber löten möchte?
Und hat schon jemand auf Basis dieser Eagle Datei eine Platine erstellt?
Ich möchte einfach ausschließen, dass sich darin ggf. Fehler befinden.
Hallo Christian,
Christian E. schrieb:
...
> Denkt ihr das wär sinnvoll oder gibts es kostengünstigere Möglichkeiten,> wenn man nicht selber löten möchte?
...
Wenn Du nicht selber löten willst, nützt Dir auch die fertige,
unbestückte Platine nichts. ;) Oder wie muss ich das jetzt verstehen?
Unter:
Beitrag "Re: EMS > ESP8266-12 WLAN-Modul"
bietet Jürgen seine EMS2ESP Platinen für kleines Geld an.
Der Adapter ist Teil der Platine, einige Bauteile kannst Du weglassen,
die Adaption an den AVR-NetIO (Ext1) müsstest Du entsprechend anpassen.
Hab's jetzt nicht detailliert gecheckt, sollt m. E. aber relativ einfach
anzupassen sein.
hth'n greets
Karl M.
Hallo Karl,
> Wenn Du nicht selber löten willst, nützt Dir auch die fertige,> unbestückte Platine nichts. ;) Oder wie muss ich das jetzt verstehen?
da habe ich mich wohl unklar ausgedrückt. Ich meinte natürlich die
bereits bestückte Platine bestellen :)
> Beitrag "Re: EMS > ESP8266-12 WLAN-Modul"> bietet Jürgen seine EMS2ESP Platinen für kleines Geld an.
Danke für den Hinweis. Hab jetzt einen Bekannten dazu gebracht, mir das
Teil zu löten. Wenn das nicht klappt, schau ich mir Jürgens Platine an.
Moin zusammen :)
Nach lager Zeit habe ich den Raspi mal wieder aktualisiert und nun läuft
einiges nicht mehr. Livestatus, Heizkurve und Einstellungen zeigen nix
mehr an. Statistik ist aber aktuell und läuft und auch die Rohdaten
werden angezeigt.
Wurden durch update&upgrade auch Dateien für oder vom Collector
verändert? Wo könnte ich anfangen zu suchen ? Denke mal das es wieder um
die richtige interne Verlinkung geht.
Gruß
Jens
Jens H. schrieb:> Raspi mal wieder aktualisiert und nun läuft> einiges nicht mehr.
Never touch a running System :-P
Welche Statistik meinst Du denn? Vermutlich die auf der Webseite?
Wenn Du denn emsclient startest funktioniert der vermutlich auch, oder?
Oder ist die Statistik Die Du meint nur die letzten Werte aus der
MySQL-Datenbank?
Hallo an die Runde,
Ich habe einen Ölkessel GB125 mit RC35.
Der ems-collector mit ems-php-webinterface läuft soweit.
Ich habe allerdings das Problem, dass im Heizungs Livestatus die
Betriebsart "Manuell" angezeigt wird, wenn die RC35 "Automatik" anzeigt
und ungekehrt.
Siehe dazu den Screenshot von Eclipse.
Hallo zusammen,
ich habe eine GB172 mit der RC 35 und möchte diese nun gerne über meine
FHEM steuern. Hierzu habe ich mir den EMS Adapter zusammengelötet.
Nun habe ich jedoch mehrere Fragen:
1. Kann ich mir die Heizung kaputt machen falls ich einen Fehler auf der
Platine habe?
2. Kann ich die Platine vorher testen bevor ich diese an meine Heizung
anschließe?
3. Wie wird die Platine genau angeschlossen? Kann ich diese einfach an
meine RC 35 (siehe Bilder) dazu klemmen? Also einfach an die Anschlüsse
zwei Kabel dazu klemmen und diese dann an meine Platine?
4. Wie sieht es mit der Polarität vom EMS Bus aus? Ist es egal wie das
geklemmt wird?
Fragen über Fragen :-)
Danke schon im Vorraus für die Beantwortung.
Viele Grüße
Johannes
Hallo Johannes,
1) Ist schon schwer die Heizung damit kaputt zu bekommen.
Die einzige Möglichkeit ist vermutlich wenn die Platine auf dem EMS-Bus
einen Kurzschluss machen würde oder Spannung herausgibt.
2) Das lässt sich aber mit einem Multimeter schnell feststellen ob
Kurzschluss oder Spannung.
3)Einfach parallel anklemmen
4)Durch den eingebnauten Gleichrichter kann die Platine nicht verpolt
werden.
Viel Spaß mit der Platine...
Hi,
ich habe die Kombination net-io + pi mit collectord, ems-tools und dem
neuen Webinterface eingerichtet und mich dabei an die Anleitung im wiki
gehalten. Hier mal ein Feedback mit Anregungen fürs die
Installationsanleitung und am Ende mit Fehlern, die ich noch nicht lösen
konnte.
Anlegen der Datenbank:
Etwas unklar fand ich das setzen des Passworts für die Datenbank. Da
wäre ein Hinweis gut, dass man mit mysql> select password('password');
einen Hash erzeugt. Das 'password' würde ich zum besseren Verständnis
durch "geheim" ersetzen.
Nach dem kompilieren des Collectors und testen mit ./collectord -u ems
....
fehlt der Hinweis, dass man collectord nach /usr/local/sbin/ kopieren
muss.
Macht man das nicht, zeigt das Webinterface später "connection refused"
an. Das init-Skript für den Collector gibt komischerweise keine
Fehlermeldung aus, wenn das Executable nicht vorhanden ist?...
Nachdem ich diese Dinge herausgefunden hatte, lief das Webinterface und
lieferte auch die aktuellen Daten.
Das Unterverzeichnis graphs im html-Verzeichnis muss vom User des
Webservers (www-data) beschreibbar sein (chwon www-data:www-data), sonst
gibt es Fehlermeldungen von gnuplot in den logs.
Aus a_emshk.php und emshkpic.ajax habe ich den Aufruf von
calcheizkurve.sh entfernt und lasse ihn von cron erledigen, denn der
Aufruf von sudo vom webserver aus funktioniert ja ohne weitere
Änderungen nicht.
Nun läuft soweit alles.
Beim Aufruf der Statistik-Seite gibt es ein paar Meldungen in den Logs:
1
[Sat Nov 12 12:28:07.115282 2016] [:error] [pid 5424] [client 192.168.10.30:47472] PHP Notice: Trying to get property of non-object in /var/www/html/ems/sensor_utils.php.inc on line 21, referer: http://pi1/ems/?seite=a_emstime.php
2
[Sat Nov 12 12:28:07.116255 2016] [:error] [pid 5424] [client 192.168.10.30:47472] PHP Warning: strftime() expects parameter 2 to be long, string given in /var/www/html/ems/utils.php.inc on line 11, referer: http://pi1/ems/?seite=a_emstime.php
Sowohl auf der Seite der Heizkurve als auch auf der Seite Einstellungen
steht die minimale Aussentemperatur auf 0. Bei der Heizkurve steht die
Auslegungstemperatur auf "bitte wählen".
Hi Chris,
hast du dir die Platine selber gelötet? Ich bin auch gerade dran das
ganze Zeug zum Laufen zu bekommen, jedoch will es nicht so wie ich es
will ;-)
AVR Net IO und Cubietruck laufen und kommunizieren. Leider bekomme ich
keine Verbindung zum EMS Bus hin. Vielleicht habe ich einen Fehler auf
der Platine.
Hast du dir das Ethersex selber konfiguriert, oder hast du das fertige
File aus dem Forum genommen?
Danke und Grüße
Johannes
Hi Johannes,
die Schaltung ist selbst gelötet. Was mich noch stört ist, dass man am
Net-IO ein Netzwerkkabel braucht. Der Raspberry Pi sitzt im gleichen
Gehäuse und ist per Wlan angebunden, so dass eine Seriellverbindung
zwischen Net-IO und Raspberry die bessere Lösung wäre....
Ich habe das Ethersex-Hex aus dem Wiki geflasht und natürlich die Fuses
angepasst. Dann wie beschrieben die Netzwerkeinstellungen festgelegt.
Das Interface zum EMS-Bus ist selbst gelötet. Blinkt denn bei dir die
RX-LED?
Gruß,
Chris
Hi Chris,
nein die LED's blinken nicht wenn ich die Platine am BUS angeklemmt hab.
Manchmal blinken die willkürlich.
Kannst du mir mal ein Foto von deiner Platine schicken bzw. posten? Hast
du den Warenkorb aus dem Forum von reichelt verwendet?
Wenn ich das fertige Ethersex nehme, kann ich wie im Forum beschrieben
nur die MAC ändern. Wenn ich die IP ändere schreibt er zwar auch OK, die
IP ist dann aber weiterhin die 192.168.0.0.
Sehr seltsam das ganze...
Entweder habe ich einen Fehler auf der Platine, oder mein selbst
konfiguriertes hex ist falsch.
Grüße
Johannes
Es klappt jetzt :-)
Ich hatte eine Lötverbindung vergessen. Ich kann über den telnet
localhost 7777 jetzt Informationen abfragen.
getversion
collector version: 2016030701
UBA version: 4.05
BC10 version: 1.05
RC3x version: 1.15
Sehr schön. Jetzt kommt die Anbindung an meine FHEM.
Hallo Ingo,
der Fehler mit graphs/schedule.png scheint daran zu liegen, das die
Grafik im Html Verzeichnis erzeugt wird und zwar unter dem Namen
Graphsschedule.png.
Da scheint im Code zum Erzeugen der Grafik ein / zu fehlen, daher wird
das Bild nicht im richtigen Ordner erstellt.
Hab leider nicht gefunden wo genau das Bild erstellt wird ...
Gruß
Jens
Ok gefunden ... emsquery.inc Zeile 282, es reicht aber wenn man in der
Config Datei den Pfad zum Graphs Ordner mit einem abschließenden /
konfiguriert, dann gehts -.- omg
Danke für den Hinweis.
Werde mir das mal ansehen und beheben. Die anderen Anregungen werden
dann auch ins wiki eingearbeitet.
Weiß nur noch nicht wann ich dazu komme.
Chris schrieb:>Was mich noch stört ist, dass man am> Net-IO ein Netzwerkkabel braucht. Der Raspberry Pi sitzt im gleichen> Gehäuse und ist per Wlan angebunden, so dass eine Seriellverbindung> zwischen Net-IO und Raspberry die bessere Lösung wäre....
Das der AVR Net IO per Kabel angebunden werden muss, stört mich aktuell
auch. Ich werde mal dieses Teil hier testen:
https://www.amazon.de/TP-Link-TL-WA850RE-Repeater-Deutsche-Version/dp/B00Q6CC2J8/ref=sr_1_3?ie=UTF8&qid=1479027240&sr=8-3&keywords=repeater+lan+port
Der sollte den AVR Net IO ins wlan bringen. Somit dürfte die
Kabelverlegung von der Heizung zum Router entfallen.
Hat jemand so ein Konstrukt schon im Einsatz?
Grüße
Johannes
Chris schrieb:> Das 'password' würde ich zum besseren Verständnis> durch "geheim" ersetzen.>> Nach dem kompilieren des Collectors und testen mit ./collectord -u ems> ....> fehlt der Hinweis, dass man collectord nach /usr/local/sbin/ kopieren> muss.
Das habe ich schon mal im Wiki geändert.
Den Rest muss ich noch überlegen wo ich das einarbeite.
Jens Heruth schrieb:> Ok gefunden ... emsquery.inc Zeile 282, es reicht aber wenn man in der> Config Datei den Pfad zum Graphs Ordner mit einem abschließenden /> konfiguriert, dann gehts -.- omg
Wie hast Du das gelöst?
vermutlich wäre es am einfachsten in der Zeile 282 das / einzufügen,
oder?
Befürchte aber dass man dann zwei hat wenn der graphpath mit
abschließt.
in der config.php ist der abschließende / vorhanden.
Einfügen in der Zeile hat nicht geklappt oder ich habs falsch gemacht !?
Bei mir hat das Einfügen des abschließenden / in der Config.php das
Problem gelöst !?
IngoF schrieb:> folgendes gemacht:fwrite($p,"set output '$graphpath/$outfn'\n");
Das hatte ich versucht, dann wird die Datei aber weiterhin im
Stammordner erstellt und heißt dann lediglich graphs/schedule.png
Die 2. Version wäre mein nächster Versuch gewesen, aber dann hatte ich
einfach mal den / in der Config gesetzt und da es dann ging habe ich
nicht weiter getestet.
Jens Heruth schrieb:> Das hatte ich versucht, dann wird die Datei aber weiterhin im> Stammordner erstellt und heißt dann lediglich graphs/schedule.png
Das hätte ich jetzt nicht erwartet...
Hätte eher gedacht dass der Schrägstrich irgendwie herausgefiltert
wird...
Hallo zusammen,
ich bin aktuell dabei das ganze in meine FHEM zu integrieren. Das klappt
bisher auch super. Begonnen habe ich mit den Readings zum auslesen der
aktuellen Werte.
Nun bin ich dabei, auch die Heizung über Fhem zu steuern.
Kann mir jemand sagen ob es einen telnet command gibt für den Heizkreis
abzuschalten?
In der RC35 kann ich bei Sommer / Winter Schwelle auch "ständig aus"
wählen.
Danke und Grüße
Johannes
Hallo Jens Heruth,
die Abweisung "fwrite($p,"set output '$graphpath$outfn'\n");", läuft bei
mir sowohl auf der Himbeere als auch unter Ubuntu. Wichtig ist der
$graphpath in config.php,z.B. „var/www/html/graphs/" .
Hallo Patric,
eine weitere Platine habe ich nicht. Ich stand jedoch vor paar Tagen vor
dem gleichen Problem. Bei mir hat letztendlich eine Verbindung gefehlt
die ich schlicht übersehen hatte. Und im reichelt Warenkorb war auch ein
Teil (MKP10-1600 1,5N) was gefehlt hat.
Ich würde einfach noch mal alles systematisch durchgehen.
Grüße
Johannes
Hallo Johannes,
danke für die schnelle Antwort.
Der Kondensator ist mir gar nicht aufgefallen, da im Reichelt Warenkorb
ein anderer vorhanden war. Zwar die selbe Kapazität aber anderer Typ.
Ich hätte da noch eine Frage zum Hexfile. Ich kann den Onewire device
detection support nur aktivieren wenn Enable Debugging gesetzt ist, dann
kann ich es aber nicht Kompilieren.
Gruß
Ola Zusammen!
Ich bekomme seit einigen Tagen / Wochen beim versenden von commandos per
telnet zum collectord bei einigen Befehlen ein ERRTIMEOUT
1
telnet localhost 7777
2
Trying ::1...
3
Trying 127.0.0.1...
4
Connected to localhost.
5
Escape character is '^]'.
6
help
7
Available commands (help with '<command> help'):
8
hk[1|2|3|4]
9
ww
10
uba
11
rc
12
raw
13
cache
14
getversion
15
OK
16
getversion
17
collector version: 2016030701
18
ERRTIMEOUT
19
rc geterrors
20
ERRTIMEOUT
Allerdings werden mir z.B. übers WI Punkt "EMS-Rohdaten"
werden einige Werte (Uhrzeit, Betriebsminuten usw) richtig angezeigt.
Unter Statistiken werden aber auch nicht mehr die Versionen angezeigt:
Softwareversion UBA offline
Softwareversion BC10 offline
Softwareversion RC35 offline
Das hatte früher definitiv funktioniert.
OS: Debian 8
M644p mit ethersex und dem Stand von heute (nachdem es 3 Jahre lief hab
ich vorsichtshalber mal eine Aktuelle Version gebrannt)
EMS-Tools, Collectord usw auf Stand des aktuellen GITs von IngoF.
GB 172 mit RC100 und BC10
Ich kann also Daten empfangen, nur fehlen offensichtlich einige.
Hat jemand noch einen (Debug)Tipp für mich?
Grüße
Hallo Gemeinde,
bei dem installieren von dem Paket ems-buderus-0.5 tritt immer folgender
Fehler auf : pkg: Fehler beim Bearbeiten des Archivs ems-buderus_0.5.deb
(--install):
Unterprozess neues pre-installation-Skript gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
ems-buderus_0.5.deb
Ich kann ems-collector zwar starten, bekomme aber keine Verbindung über
Telnet.
Manuel kann ich mit collectord -u ems -p geheim -f -d all
tcp:192.168.xxx.xxx:7950 die Telegramme starten, das wars dann aber
schon.
Evl. hat ja jemand von euch eine Idee, ich stehe momentan echt auf dem
Schlauch was den Fehler angeht.
Das Testsystem ist Ubuntu 16.10.
Gruß Patric
Servus Patric,
soweit ich das verstanden habe, wird das Paket "ems-buderus_0.5.deb"
nicht mehr gepflegt.
Manuelle Installation ist der beste Weg. Wie das geht, ist unter [1]
ausführlich beschrieben.
Gruß
Karl M.
[1]
http://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io#raspberry_pi
Hallo Danny Baumann,
ich sehe in der Statistik des ems-php-webinterface keine Werte für die
Raumtemperatur. Das gilt auch für die Datenbank, hier gibt es zwar den
Sensor 13 und 14. In der Tabelle numeric_data gibt es aber keine
Einträge dazu.
'13', '1', 'Raum-Soll-Temperatur', '1', '°C', '1'
'14', '1', 'Raum-Ist-Temperatur', '1', '°C', '1'
Hast da eine Lösung?
Helmut J. schrieb:> Hallo Danny Baumann,> ich sehe in der Statistik des ems-php-webinterface keine Werte für die> Raumtemperatur. Das gilt auch für die Datenbank, hier gibt es zwar den> Sensor 13 und 14. In der Tabelle numeric_data gibt es aber keine> Einträge dazu.>> '13', '1', 'Raum-Soll-Temperatur', '1', '°C', '1'> '14', '1', 'Raum-Ist-Temperatur', '1', '°C', '1'>> Hast da eine Lösung?
Schau mal in Database.cpp, Zeile 342/343 und mach aus dem HK2 ein HK1.
Dann sollte es gehen ;-) Meine RC35 hängt an HK2, deshalb ist der Code
so wie er ist. Ich wollte schon ewig mal einen Parameter für den
Collector einbauen, der den Default für solche Dinge festlegt, bin aber
noch nicht dazu gekommen.
Andre G. schrieb:> Hey Danny,> Wie finde ich denn raus an welchem KH der RC hängt?> Ich hab 2 HKs, 1x FBH und 1x Heizkörper(vermute ich :-)) und nen> RC100...
Das lässt sich in den RC-Einstellungen einstellen (bei der RC35 ist das
unter Wartungsmenü -> Heizkreis x). Wenn die RC mehreren Heizkreisen
zugeordnet ist, sollte die Raumtemperatur in allen zugeordneten
Heizkreisen auftauchen. Ein Message-Log schafft im Zweifelsfall Klarheit
;-)
Danny B. schrieb:> Schau mal in Database.cpp, Zeile 342/343 und mach aus dem HK2 ein HK1.> Dann sollte es gehen ;-) Meine RC35 hängt an HK2, deshalb ist der Code> so wie er ist. Ich wollte schon ewig mal einen Parameter für den> Collector einbauen, der den Default für solche Dinge festlegt, bin aber> noch nicht dazu gekommen.
Hallo Danny,
das wars leider nicht. Die Raum-Ist-Temperatur /Raum-Soll-Temperatur
wird in den Rohdaten sowohl für HK1 und HK2 angezeigt.
Gruß
Helmut J. schrieb:> Danny B. schrieb:>> Schau mal in Database.cpp, Zeile 342/343 und mach aus dem HK2 ein HK1.>> Dann sollte es gehen ;-) Meine RC35 hängt an HK2, deshalb ist der Code>> so wie er ist. Ich wollte schon ewig mal einen Parameter für den>> Collector einbauen, der den Default für solche Dinge festlegt, bin aber>> noch nicht dazu gekommen.>> Hallo Danny,> das wars leider nicht. Die Raum-Ist-Temperatur /Raum-Soll-Temperatur> wird in den Rohdaten sowohl für HK1 und HK2 angezeigt.> Gruß
Hallo Danny,
ich habe mir das Problem einmal im Debugger angesehen. Dabei ist mir
folgendes Aufgefallen:
Database.cpp
Zeile 324
NUMERICMAPPING[]
Die RaumIstTemp ist auf Position 12 -> EmsValue::IstTemp, EmsValue::HK1,
SensorRaumIstTemp
Der SensorRaumIstTemp ist in der DB aber auf Sensor 14 !
Bei anderen Messwerten wie z.B. SollTemp Kessel ist das gleich, also
SollTemp Kessel ist auf Pos 1 und auch Sensor 1.
In Database.cpp wird ab Zeile 411 mit addSensorValue der Wert in die DB
geschrieben,
bei der RaumIstTemp kommet er da nicht hin!
for (size_t i = 0; i < sizeof(NUMERICMAPPING) /
sizeof(NUMERICMAPPING[0]); i++) {
if (type == NUMERICMAPPING[i].type && subtype ==
NUMERICMAPPING[i].subtype) {
addSensorValue(NUMERICMAPPING[i].sensor, value.getValue<float>());
return;
Gruß
Helmut J. schrieb:> Helmut J. schrieb:>> Danny B. schrieb:>>> Schau mal in Database.cpp, Zeile 342/343 und mach aus dem HK2 ein HK1.>>> Dann sollte es gehen ;-) Meine RC35 hängt an HK2, deshalb ist der Code>>> so wie er ist. Ich wollte schon ewig mal einen Parameter für den>>> Collector einbauen, der den Default für solche Dinge festlegt, bin aber>>> noch nicht dazu gekommen.>>>> Hallo Danny,>> das wars leider nicht. Die Raum-Ist-Temperatur /Raum-Soll-Temperatur>> wird in den Rohdaten sowohl für HK1 und HK2 angezeigt.>> Gruß>> Hallo Danny,
Ich habe dazu noch etwas geforscht, Database.cpp sollte so aussehen:
344 { EmsValue::RaumSollTemp, EmsValue::HK1, SensorRaumSollTemp
},//geändert von HK2 nach HK1 SollTemp nach RaumSollTemp
355 { EmsValue::RaumIstTemp, EmsValue::HK1, SensorRaumIstTemp
},//geändert von HK2 nach HK1 IstTemp nach RaumIstTemp
Damit geht es dann.
Die EMS-Wiki ist zur Zeit erst einmal offline.
Mein Server ist gestorben und ich habe mit der Wiederbelebung bekommen.
Kann also noch nicht sagen ab wann das emswiki wieder läuft...
So,
zeitweise ist schon mal eine Wiki auf einem Testserver in Betrieb.
Keine Ahnung wie aktuell der ist.
Melde mich hier wenn er wieder richtig läuft..
Gruß
Ingo
IngoF schrieb:> Melde mich hier wenn er wieder richtig läuft..
Das Wiki läuft seit gestern wieder auf dem richtigen Server.
Hat etwas länger gedauert. Wenn jetzt noch Fehler auffallen einfach
melden oder im Wiki selber ändern.
Fall noch die "Wartungsmeldung" erscheint einfach noch mal im Browser
aktualisieren.
Hallo!
Ich habe nach dem WIKI alles nachgebaut bei meiner GB172 mit RC35 und es
funktioniert grundsätzlich alles, vielen Dank!
Ich habe aber ein paar Probleme:
1. Wenn ich im Web Interface auf "Einstellungen" klicke verliert er die
Verbindung zum EMS Bus bis zum Neustart des Linux Servers
2. Wenn ich auf "Heizkurve" klicke kommt die Meldung "Anlage ist
raumtemperaturgeführt!" obwohl im RC35 außentemperaturgeführt
eingestellt ist
3. In der Statistik ist die Raumtemperatur dauerhaft 0, obwohl in den
Rohdaten diese richtig angezeigt werden
4. In der Statistik zeigt er mir die anderen Bus Teilnehmer als offline
an:
Softwareversion UBA offline
Softwareversion BC10 offline
Softwareversion RC35 offline
obwohl sie definitiv online sind. Die Graphen werden auch nicht
angezeigt
Hat jemand eine Idee, woran das liegen könnte? Ich bin sonst total
begeistert, dass es so reibungslos ging.
Marco schrieb:> 2. Wenn ich auf "Heizkurve" klicke kommt die Meldung "Anlage ist> raumtemperaturgeführt!" obwohl im RC35 außentemperaturgeführt> eingestellt ist
Das liegt vermutlich daran dass die RC35 nicht eingestellt wurde. Meine
sowas irgendwann gelesen zu haben.
Wegen der anderen Sachen:
Funktionieren denn die Tests mit Telnet auf den EMS-Collector oder den
EMS-Tools (emsclient) fehlerfrei?
Marco schrieb:> aber mit einigen Fehlern
Das sind vermutlich keine Fehler.
So wie es aussieht sind das die Fehlereinträge Deiner Heizung.
Die sollten auch an der RC35 auslesbar sein.
Das zweite Bild ist meiner Meinung nach voll OK.
B00 bis B04 sind wohl die blockierenden Fehler Deiner Heizung.
Hi,
ich habe in den letzten Tagen das Gateway mit Net-IO, das neue
Webinterface und nachtürlich collectord und die ems-tools aufgesetzt.
Geniales Projekt, vielen Dank an alle Entwickler!
Aktuell jage ich noch folgende Fehler:
1.) Der Graph der Heizkurve ist oben irgendwo bei 45 oder 48 Grad
abgeschnitten. Ich hätte jetzt erwartet, dass das dynamisch ist, je nach
Heizkurve. Tatsächlich sind die Maximum-Werte aber fest in den Skripten
hinterlegt, so dass man das einfach ändern kann.
Vielleicht wären hier andere Default-Werte sinnvoll. 10-90°C sollten
alle Heizungssysteme abdecken.
2.) Calcheizkurve.sh hat irgend ein Problem bei mir. Ich muss den
Prozess mehrmals am Tag killen, da er die CPU voll auslastet und sich
selbst nicht mehr beendet (und dadurch auch mehrfach läuft). Vermutlich
passiert das, wenn mein Net-IO nicht erreichbar ist (fällt immer mal
wieder wegen Unterspannung aus, aber das ist eine andere Baustelle).
Cron mailt mir dann folgendes zu:
1
PHP Warning: socket_write(): unable to write to socket [32]: Broken pipe in /usr/local/ems-tools/includes/emsqry.inc on line 69
2
PHP Warning: socket_write(): unable to write to socket [32]: Broken pipe in /usr/local/ems-tools/includes/emsqry.inc on line 69
Vielleicht fehlt da eine Abbruchbedingung bei Fehler, oder ein
Timeout-Wert.
3.) Ich sehe in der Statistik keine Werte für die Raumtemperatur. Bei
den EMS-Rohdaten ist sie als "hk1 roomcurrenttemperature" aufgeführt.
Muss ich das noch irgend wie zuordnen?
4.) In den Einstellungen wird die "minimale Außentemperatur" als 0°C
ausgelesen. Die Anlage steht aber auf -10. Ich kann den Wert über das
Webinterface erfolgreich setzen, aber auch dann wird wieder 0°C
angezeigt. In den Rohdaten tauchen die -10 Grad unter "mintemperature"
auf.
Gruß,
Carsten
Marco schrieb:> Der RC35 ist in der ems-collector.conf ausgewählt.> Scheinbar liegt es am Telnet, dort bekomme ich die Fehlermeldungen aus> dem angehängten Bild
Deine Befehle sind ja auch nicht komplett. ;) Probier z.B. mal 'ww
help'. Der Timeout bei getversion ist aber verdächtig - sicher, dass
deine Sendeschaltung funktioniert? Du kannst z.B. mal 'hk1 mode night'
probieren und gucken, wie die RC35 reagiert ... wenn die Sendeschaltung
funktioniert, sollte die RC35 anzeigen, dass der HK im Nachtmodus ist.
Carsten schrieb:> 3.) Ich sehe in der Statistik keine Werte für die Raumtemperatur. Bei> den EMS-Rohdaten ist sie als "hk1 roomcurrenttemperature" aufgeführt.> Muss ich das noch irgend wie zuordnen?
Jain. Du solltest das nicht zuordnen müssen, musst(est) das auf Grund
meiner Faulheit aber :-(
Siehe
https://github.com/maniac103/ems-collector/commit/2636a97a5766bb5fe574dc8d05e9db5f218943a0
... ich hatte das ursprünglich mal so gemacht, weil ich 2 Heizkreise
habe und die RC bei mir im Wohnzimmer hängt, das zu HK2 gehört. Die RC35
sendet die Raumtemperatur aber ohnehin für jeden zugeordneten Heizkreis
mit ... keine Ahnung, ob mir das damals nicht aufgefallen war oder ob
sich die RC30 (die ich damals noch hatte) diesbezüglich anders verhalten
hat.
Bei dir sollte ein 'git pull' + compilieren des Collectors jedenfalls
helfen.
> 4.) In den Einstellungen wird die "minimale Außentemperatur" als 0°C> ausgelesen. Die Anlage steht aber auf -10. Ich kann den Wert über das> Webinterface erfolgreich setzen, aber auch dann wird wieder 0°C> angezeigt. In den Rohdaten tauchen die -10 Grad unter "mintemperature"> auf.
Ich gehe mal davon aus, dass sie dort als 'rc mintemperature' auftaucht?
Wenn ja, ist das ein Frontend-Problem, da kann ich dir leider nicht
helfen.
Hallo Danny,
Temperatur ist nun vorhanden, vielen Dank! Schade, dass man sie nicht
auch im Livestatus sieht.
Bei den Rohdaten habe ich keine Werte die mit "rc" beginnen. Der Eintrag
heißt "mintemperature".
Carsten schrieb:> Hallo Danny,> Temperatur ist nun vorhanden, vielen Dank! Schade, dass man sie nicht> auch im Livestatus sieht.>> Bei den Rohdaten habe ich keine Werte die mit "rc" beginnen. Der Eintrag> heißt "mintemperature".
Ah, doch ein Bug im Collector ;-) Hab's gefixt, sollte nach
Collector-Update funktionieren.
Carsten schrieb:> Hi,>> ich habe in den letzten Tagen das Gateway mit Net-IO, das neue> Webinterface und nachtürlich collectord und die ems-tools aufgesetzt.> Geniales Projekt, vielen Dank an alle Entwickler!>> Aktuell jage ich noch folgende Fehler:>>> 3.) Ich sehe in der Statistik keine Werte für die Raumtemperatur. Bei> den EMS-Rohdaten ist sie als "hk1 roomcurrenttemperature" aufgeführt.> Muss ich das noch irgend wie zuordnen?>> 4.) In den Einstellungen wird die "minimale Außentemperatur" als 0°C> ausgelesen. Die Anlage steht aber auf -10. Ich kann den Wert über das> Webinterface erfolgreich setzen, aber auch dann wird wieder 0°C> angezeigt. In den Rohdaten tauchen die -10 Grad unter "mintemperature"> auf.>> Gruß,> Carsten
Hallo Carsten,
Zu3)Das Problem hatte ich auch.
Schau mal in Database.cpp ob dort noch HK1 IstTemp steht?
Es sollte so aussehen:
344 { EmsValue::RaumSollTemp, EmsValue::HK1, SensorRaumSollTemp
},//geändert von HK2 nach HK1 SollTemp nach RaumSollTemp
355 { EmsValue::RaumIstTemp, EmsValue::HK1, SensorRaumIstTemp
},//geändert von HK2 nach HK1 IstTemp nach RaumIstTemp
Zu4) Ich habe das gleiche Verhalten. Ich werde mir das mal genauer
ansehen, dauert aber noch etwas.
Gruß
Helmut
Moin Moin,
ich habe jetzt alles seit Dezember am laufen.
Super Arbeit vielen Dank dafür.
Ist es möglich, bei einem Fehler der Therme, eine Fehlermeldung starten
zu können oder einen Kontakt schalten zu lassen?
Gruß
Du kannst eigentlich mit Scripts (z.b. PHP) alles machen( cron Job
gesteuert alle 5 min). Frage die Datenbank nach Fehlern die du gemeldet
haben möchtest einfach ab.
Ich nutze das z.b. um mir Daten im openHAB anzeigen zu lassen um dann
zum Beispiel per Telegram Bot eine Nachricht aufs Telefon zu schicken.
Gruß
Andre G. schrieb:> Du kannst eigentlich mit Scripts (z.b. PHP) alles machen( cron Job> gesteuert alle 5 min). Frage die Datenbank nach Fehlern die du gemeldet> haben möchtest einfach ab.
Ich glaube, du hast ihn da falsch verstanden. EMS-Fehler landen in
keiner Datenbank. Man kann sich natürlich trotzdem etwas bauen (zyklisch
'geterrors' senden, Antwort parsen und schauen, ob etwas aktuelles dabei
ist).
> Ich nutze das z.b. um mir Daten im openHAB anzeigen zu lassen um dann> zum Beispiel per Telegram Bot eine Nachricht aufs Telefon zu schicken.
OpenHAB per MySQL anzubinden, erscheint mir etwas umständlich ;) Ich
lasse MySQL bei mir komplett weg, binde OprnHAB via MQTT an (dafür hatte
ich das geschrieben) und schreibe die Sensordaten, die mich
interessieren, dann in eine influxdb-Datenbank (dir ich dann für
Visualisierung mit Grafana auslese)
Auch ne coole Idee :-) Habe nur keinen blassen Schimmer was MQTT ist :-)
lese ich mich mal ein.
Hast du da Beispiele?
Ich dachte es wären die Fehlern oder gemeint. Und die Meldungen sind
doch in der Datenbank? Ach ich hab das mit dem Protokoll verwechselt.
Ist ja auch schon spät:-)
Ich hab mir einfach ein PHP Script gebaut welches die von mir
gewünschten Daten sammelt und dann per REST API und curl an openHAB
sendet. Ich kann morgen mal einen Link mit Beispielen bereitstellen...
Danke und Gruß
Hallo zusammen,
ich habe Wochen verbracht zu recherchieren, wie man das KM200 so zurecht
biegt, dass es meinen Ansprüchen genügt und finde heute durch Zufall
diese alternative Lösung und bin begeistert.
Ich finde das großartig, dass Ihr Euer Wissen und Eure Zeit zur
Verfügung stellt, um so etwas der Allgemeinheit zur Verfügung zu
stellen!!!
Ich komme von der Anleitung im Wiki und habe aber bevor ich loslegen
will die einfache Frage, wie das mit der Programmierung des ATmega644p
genau funktioniert. Ich habe gesehen, dass es eine fertige HEX-Datei
gibt und habe herausgefunden, dass es bei Pollin ein Programmierboard
gibt. Das hat aber nur eine RS232 Schnittstelle, die ich sicher mit
einem entsprechenden Adapter USB=>RS232 ansprechen kann ... Aber ab da
werde ich hilflos, wie man den Rechner (Win, Mac oder Ubuntu)
einrichtet, um das HEX File ordentlich auf den Chip zu brennen.
Löten und Raspberry Pi kann ich, aber gibt es eine Anleitung für die
Chip-Programmierung für Dummies?
Es wäre toll, wenn Ihr mir dabei etwas unter die Arme greifen könntet.
Grüße
Justus
P.S. da habe ich doch noch eine Frage: Ich habe nur einen Heizkreis und
Warmwasser. Lassen sich auch die Heizzeiten für beides über dieses
Gateway programmieren? - Vielen Dank!
Hallo hth,
Vielen Dank für die schnelle Antwort.
Das Programmierboard von Pollin, auf das bei Deinem Link hingewiesen
wird, hatte ich schon gefunden. Hab dann von da den Thread weitergelesen
und der wichtige Hinweis für mich war dann in diesem Beitrag:
Beitrag "Re: EMS > Adapter > NetIO > Raspi"
... der Verweis auf die Software AVR Studio (mittlerweile in der
Version 7) zum Brennen des Controllers.
Ich gehe mal davon aus, dass ich auf einem Windows PC (Win 7 oder Win
10) mit einem USB=>RS232 Adapter das Evalutation Board von Pollin
anschließen kann (wahrscheinlich vorher den zu programmierenden 644p
aufstecken) und dann das heruntergeladene HEX File in der Software
selbsterklärend auf den Chip übertragen kann (d.h. also keine weiteren
Häkchen oder Optionen in der Software beim Brennen einschalten muss).
Stimmt das in etwa so?
Danke und Gruß
Justus
Ich habe den emscollectord auf einem Raspi der ersten Generation mit
256Mb Ram laufen. Es ist die Version 2015031501. Der Raspi hat sich
schon damals mit dem compilieren ganz schön schwer getan. Die neueste
Version kann ich gar nicht mehr übersetzen. Nach kurzer Zeit ist kein
Speicher mehr frei und er swapptz nur noch. Kann mir jemand die neueste
Version fertig compiliert zukommen lassen ?
Die Alternative wäre dass ich mir einen zweiten RasPi 3 zulegen würde.
Kann ich die Software mit diesem übersetzen (mit Raspian Jessie) und auf
dem alten laufen lassen (mit Raspian Wheezy) ?
Vielen Dank im voraus für eure Hilfe
Andreas
Hallo Andreas,
als Gast ohne Email wird das 100% nix mit dem zukommen lassen.
Ich bin kein Linux-Spezialist und kämpfe selbst immer ein bisschen mit
dem Compilieren weil die Quellen vom Raspi Wheezy gegenüber dem Debian
Wheezy vom Denny total veraltert sind. :-P Ich würde gerne das MQTT
verwenden doch leider braucht es die boost version 1.57 die ich für den
Raspi Wheezy bzw. Jessie noch nicht gefunden habe.
Grüße
Martin
Hallo Martin,
ich habe mich jetzt mal angemeldet.
Hast du eine neuere Version die du mir übersetzt zukommen lassen
könntest ?
Welche Version lässt sich den auf dem Raspberry compilieren ?
Weisst du wie es aussieht mit übersetzen auf einem RasPi 3 und laufen
lassen auf einem RasPi 1 ?
Gruß
Andreas
Hallo Zusammen,
leider stehe ich auch gerade vor dem Problem, mit der Himbeere das
Compilieren nicht hinzubekommen.
Zwar habe ich mir von der Debian Seite die Boost1.63 geladen, aber das
Make stoppt mit mir nicht erklärbaren Fehlern in der Options.cpp Datei.
Geht wohl auch nicht, wenn ich ohne MQTT Support ein Compile machen
möchte. Mag auch evtl. an der Libboost Version liegen?!?
Kann mir evtl. jemand das fertige File mit MQTT Support für die Himbeere
zukommen lassen?
Oder einen Hinweis, wie man das selbst fehlerfrei compilieren kann?
Beste Grüße
Sebastian
Sebastian Z. schrieb:> Hallo Zusammen,>> leider stehe ich auch gerade vor dem Problem, mit der Himbeere das> Compilieren nicht hinzubekommen.> Zwar habe ich mir von der Debian Seite die Boost1.63 geladen, aber das> Make stoppt mit mir nicht erklärbaren Fehlern in der Options.cpp Datei.> Geht wohl auch nicht, wenn ich ohne MQTT Support ein Compile machen> möchte. Mag auch evtl. an der Libboost Version liegen?!?>> [...]> Oder einen Hinweis, wie man das selbst fehlerfrei compilieren kann?
Für die Beantwortung dieser Fragen wäre die Kenntnis der auftretenden
Fehlermeldungen durchaus hilfreich ;-)
Ich würde mal spontan sagen, dass deine Boost-Header (*.h) nicht zu den
Boost-Libs (*.so) passen. Was genau meinst du mit 'habe ich mir von der
Debian Seite die Boost1.63 geladen'?
Sebastian Z. schrieb:> Hi,>> bin wie folgt vorgegangen. Habe das Pack von hier eingebunden:> https://packages.debian.org/de/sid/arm64/libboost-dev/download>>> Mit apt-get install dann entsprechend das libboost1.63 installiert.
Nur libboost oder auch die entsprechenden Devel-Pakete? Ersteres würde
das Problem erklären... was sagt denn jetzt 'dpkg -l | grep boost'?
>> VG> Sebastian
Das war libboost1.63-all-dev
Command dpkg -l | grep boost ergab folgendes:
rc libboost-atomic1.55.0:armhf 1.55.0+dfsg-3
armhf atomic data types, operations, and memory
ordering constraints
ii libboost-atomic1.63-dev:armhf 1.63.0+dfsg-1
armhf atomic data types, operations, and memory
ordering constraints
ii libboost-atomic1.63.0:armhf 1.63.0+dfsg-1
armhf atomic data types, operations, and memory
ordering constraints
rc libboost-chrono1.49.0 1.49.0-4+b2
armhf C++ representation of time duration, time
point, and clocks
rc libboost-chrono1.55.0:armhf 1.55.0+dfsg-3
armhf C++ representation of time duration, time
point, and clocks
ii libboost-chrono1.63-dev:armhf 1.63.0+dfsg-1
armhf C++ representation of time duration, time
point, and clocks
ii libboost-chrono1.63.0:armhf 1.63.0+dfsg-1
armhf C++ representation of time duration, time
point, and clocks
rc libboost-context1.55.0:armhf 1.55.0+dfsg-3
armhf provides a sort of cooperative multitasking
on a single thread
ii libboost-context1.63-dev:armhf 1.63.0+dfsg-1
armhf provides a sort of cooperative multitasking
on a single thread
ii libboost-context1.63.0:armhf 1.63.0+dfsg-1
armhf provides a sort of cooperative multitasking
on a single thread
ii libboost-coroutine1.63-dev:armhf 1.63.0+dfsg-1
armhf provides a sort of cooperative multitasking
on a single thread
ii libboost-coroutine1.63.0:armhf 1.63.0+dfsg-1
armhf provides a sort of cooperative multitasking
on a single thread
rc libboost-date-time1.49.0 1.49.0-4+b2
armhf set of date-time libraries based on generic
programming concepts
rc libboost-date-time1.55.0:armhf 1.55.0+dfsg-3
armhf set of date-time libraries based on generic
programming concepts
ii libboost-date-time1.63-dev:armhf 1.63.0+dfsg-1
armhf set of date-time libraries based on generic
programming concepts
ii libboost-date-time1.63.0:armhf 1.63.0+dfsg-1
armhf set of date-time libraries based on generic
programming concepts
ii libboost-exception1.63-dev:armhf 1.63.0+dfsg-1
armhf library to help write exceptions and
handlers
ii libboost-fiber1.63-dev:armhf 1.63.0+dfsg-1
armhf cooperatively-scheduled
micro-/userland-threads
ii libboost-fiber1.63.0:armhf 1.63.0+dfsg-1
armhf cooperatively-scheduled
micro-/userland-threads
rc libboost-filesystem1.49.0 1.49.0-4+b2
armhf filesystem operations (portable paths,
iteration over directories, etc) in C++
rc libboost-filesystem1.55.0:armhf 1.55.0+dfsg-3
armhf filesystem operations (portable paths,
iteration over directories, etc) in C++
ii libboost-filesystem1.63-dev:armhf 1.63.0+dfsg-1
armhf filesystem operations (portable paths,
iteration over directories, etc) in C++
ii libboost-filesystem1.63.0:armhf 1.63.0+dfsg-1
armhf filesystem operations (portable paths,
iteration over directories, etc) in C++
rc libboost-graph-parallel1.49.0 1.49.0-4+b2
armhf generic graph components and algorithms in
C++
rc libboost-graph-parallel1.55.0 1.55.0+dfsg-3
armhf generic graph components and algorithms in
C++
ii libboost-graph-parallel1.63-dev 1.63.0+dfsg-1
armhf generic graph components and algorithms in
C++
ii libboost-graph-parallel1.63.0 1.63.0+dfsg-1
armhf generic graph components and algorithms in
C++
rc libboost-graph1.49.0 1.49.0-4+b2
armhf generic graph components and algorithms in
C++
rc libboost-graph1.55.0:armhf 1.55.0+dfsg-3
armhf generic graph components and algorithms in
C++
ii libboost-graph1.63-dev:armhf 1.63.0+dfsg-1
armhf generic graph components and algorithms in
C++
ii libboost-graph1.63.0:armhf 1.63.0+dfsg-1
armhf generic graph components and algorithms in
C++
ii libboost-iostreams1.49.0 1.49.0-4+b2
armhf Boost.Iostreams Library
ii libboost-iostreams1.50.0 1.50.0-1+b2
armhf Boost.Iostreams Library
ii libboost-iostreams1.53.0 1.53.0-6+b2
armhf Boost.Iostreams Library
ii libboost-iostreams1.54.0:armhf 1.54.0-5
armhf Boost.Iostreams Library
ii libboost-iostreams1.55.0:armhf 1.55.0+dfsg-3
armhf Boost.Iostreams Library
ii libboost-iostreams1.63-dev:armhf 1.63.0+dfsg-1
armhf Boost.Iostreams Library development files
ii libboost-iostreams1.63.0:armhf 1.63.0+dfsg-1
armhf Boost.Iostreams Library
rc libboost-locale1.49.0 1.49.0-4+b2
armhf C++ facilities for localization
rc libboost-locale1.55.0:armhf 1.55.0+dfsg-3
armhf C++ facilities for localization
ii libboost-locale1.63-dev:armhf 1.63.0+dfsg-1
armhf C++ facilities for localization
ii libboost-locale1.63.0:armhf 1.63.0+dfsg-1
armhf C++ facilities for localization
rc libboost-log1.55.0 1.55.0+dfsg-3
armhf C++ logging library
ii libboost-log1.63-dev 1.63.0+dfsg-1
armhf C++ logging library
ii libboost-log1.63.0 1.63.0+dfsg-1
armhf C++ logging library
rc libboost-math1.49.0 1.49.0-4+b2
armhf Boost.Math Library
rc libboost-math1.55.0:armhf 1.55.0+dfsg-3
armhf Boost.Math Library
ii libboost-math1.63-dev:armhf 1.63.0+dfsg-1
armhf Boost.Math Library development files
ii libboost-math1.63.0:armhf 1.63.0+dfsg-1
armhf Boost.Math Library
rc libboost-mpi-python1.49.0 1.49.0-4+b2
armhf C++ interface to the Message Passing
Interface (MPI), Python Bindings
rc libboost-mpi-python1.55.0 1.55.0+dfsg-3
armhf C++ interface to the Message Passing
Interface (MPI), Python Bindings
ii libboost-mpi-python1.63-dev 1.63.0+dfsg-1
armhf C++ interface to the Message Passing
Interface (MPI), Python Bindings
ii libboost-mpi-python1.63.0 1.63.0+dfsg-1
armhf C++ interface to the Message Passing
Interface (MPI), Python Bindings
rc libboost-mpi1.49.0 1.49.0-4+b2
armhf C++ interface to the Message Passing
Interface (MPI)
rc libboost-mpi1.55.0 1.55.0+dfsg-3
armhf C++ interface to the Message Passing
Interface (MPI)
ii libboost-mpi1.63-dev 1.63.0+dfsg-1
armhf C++ interface to the Message Passing
Interface (MPI)
ii libboost-mpi1.63.0 1.63.0+dfsg-1
armhf C++ interface to the Message Passing
Interface (MPI)
rc libboost-program-options1.49.0 1.49.0-4+b2
armhf program options library for C++
rc libboost-program-options1.55.0:armhf 1.55.0+dfsg-3
armhf program options library for C++
ii libboost-program-options1.63-dev:armhf 1.63.0+dfsg-1
armhf program options library for C++
ii libboost-program-options1.63.0:armhf 1.63.0+dfsg-1
armhf program options library for C++
rc libboost-python1.49.0 1.49.0-4+b2
armhf Boost.Python Library
rc libboost-python1.55.0 1.55.0+dfsg-3
armhf Boost.Python Library
ii libboost-python1.63-dev 1.63.0+dfsg-1
armhf Boost.Python Library development files
ii libboost-python1.63.0 1.63.0+dfsg-1
armhf Boost.Python Library
rc libboost-random1.49.0 1.49.0-4+b2
armhf Boost Random Number Library
rc libboost-random1.55.0:armhf 1.55.0+dfsg-3
armhf Boost Random Number Library
ii libboost-random1.63-dev:armhf 1.63.0+dfsg-1
armhf Boost Random Number Library
ii libboost-random1.63.0:armhf 1.63.0+dfsg-1
armhf Boost Random Number Library
rc libboost-regex1.49.0 1.49.0-4+b2
armhf regular expression library for C++
rc libboost-regex1.55.0:armhf 1.55.0+dfsg-3
armhf regular expression library for C++
ii libboost-regex1.63-dev:armhf 1.63.0+dfsg-1
armhf regular expression library for C++
ii libboost-regex1.63.0:armhf 1.63.0+dfsg-1
armhf regular expression library for C++
rc libboost-serialization1.49.0 1.49.0-4+b2
armhf serialization library for C++
rc libboost-serialization1.55.0:armhf 1.55.0+dfsg-3
armhf serialization library for C++
ii libboost-serialization1.63-dev:armhf 1.63.0+dfsg-1
armhf serialization library for C++
ii libboost-serialization1.63.0:armhf 1.63.0+dfsg-1
armhf serialization library for C++
rc libboost-signals1.49.0 1.49.0-4+b2
armhf managed signals and slots library for C++
rc libboost-signals1.55.0:armhf 1.55.0+dfsg-3
armhf managed signals and slots library for C++
ii libboost-signals1.63-dev:armhf 1.63.0+dfsg-1
armhf managed signals and slots library for C++
ii libboost-signals1.63.0:armhf 1.63.0+dfsg-1
armhf managed signals and slots library for C++
rc libboost-system1.49.0 1.49.0-4+b2
armhf Operating system (e.g. diagnostics support)
library
rc libboost-system1.55.0:armhf 1.55.0+dfsg-3
armhf Operating system (e.g. diagnostics support)
library
ii libboost-system1.63-dev:armhf 1.63.0+dfsg-1
armhf Operating system (e.g. diagnostics support)
library
ii libboost-system1.63.0:armhf 1.63.0+dfsg-1
armhf Operating system (e.g. diagnostics support)
library
rc libboost-test1.49.0 1.49.0-4+b2
armhf components for writing and executing test
suites
rc libboost-test1.55.0:armhf 1.55.0+dfsg-3
armhf components for writing and executing test
suites
ii libboost-test1.63-dev:armhf 1.63.0+dfsg-1
armhf components for writing and executing test
suites
ii libboost-test1.63.0:armhf 1.63.0+dfsg-1
armhf components for writing and executing test
suites
rc libboost-thread1.49.0 1.49.0-4+b2
armhf portable C++ multi-threading
rc libboost-thread1.55.0:armhf 1.55.0+dfsg-3
armhf portable C++ multi-threading
ii libboost-thread1.63-dev:armhf 1.63.0+dfsg-1
armhf portable C++ multi-threading
ii libboost-thread1.63.0:armhf 1.63.0+dfsg-1
armhf portable C++ multi-threading
rc libboost-timer1.49.0 1.49.0-4+b2
armhf C++ wall clock and CPU process timers
rc libboost-timer1.55.0:armhf 1.55.0+dfsg-3
armhf C++ wall clock and CPU process timers
ii libboost-timer1.63-dev:armhf 1.63.0+dfsg-1
armhf C++ wall clock and CPU process timers
ii libboost-timer1.63.0:armhf 1.63.0+dfsg-1
armhf C++ wall clock and CPU process timers
ii libboost-type-erasure1.63-dev:armhf 1.63.0+dfsg-1
armhf C++ runtime polymorphism based on concepts
ii libboost-type-erasure1.63.0:armhf 1.63.0+dfsg-1
armhf C++ runtime polymorphism based on concepts
rc libboost-wave1.49.0 1.49.0-4+b2
armhf C99/C++ preprocessor library
rc libboost-wave1.55.0:armhf 1.55.0+dfsg-3
armhf C99/C++ preprocessor library
ii libboost-wave1.63-dev:armhf 1.63.0+dfsg-1
armhf C99/C++ preprocessor library
ii libboost-wave1.63.0:armhf 1.63.0+dfsg-1
armhf C99/C++ preprocessor library
ii libboost1.63-all-dev 1.63.0+dfsg-1
armhf Boost C++ Libraries development files (ALL)
ii libboost1.63-dev:armhf 1.63.0+dfsg-1
armhf Boost C++ Libraries development files
ii libboost1.63-tools-dev 1.63.0+dfsg-1
armhf Boost C++ Libraries development tools
Sebastian Z. schrieb:> Das war libboost1.63-all-dev>> Command dpkg -l | grep boost ergab folgendes:> [...]
Hmm, das sieht erst mal ok aus. Keine Ahnung, was da das Problem ist :-/
Selber verwende ich Boost 1.58 (in Ubuntu 16.04) und 1.60 (in Fedora 24)
ohne Probleme. 1.63 habe ich (mangels entsprechender
Installationsquellen auf meinen Rechnern) noch nicht getestet.
Hmmm. Doof das ganze.
Habe noch gelesen, dass evtl. die GCC Version nicht zur Lib passen kann.
Da muss ich nochmal spielen und evtl. auf GCC 5+ wechseln.
Aber nochmal die Frage an die Runde: Kann mir jemand eine fertiges
compile des collectors zukommen lassen?
VG
Sebastian
Bei mir steigt der Collectord unregelmäßig aus. Mal nach Wochen, mal
nach Stunden. Vermutlich läuft das NetIO nicht stabil und resettet die
Verbindung. Der Collectord sollte dann aber eigentlich weiter laufen und
nicht aussteigen.
Hat zufällig jemand ein systemd Unit-File für den collectord? Damit kann
man nämlich recht leicht (eine Zeile oder so) definieren, dass ein
Dienst automatisch neu gestartet wird. Ansonsten mache ich mich da
morgen mal dran, wenn Zeit...
Guten Morgen Zusammen,
die Hinweise aus dem Netz auf die GCC Version in meinem Fall waren
korrekt.
Nachdem ich Version 5 aus den Testing Repos der Himbeere geladen hatte,
lief das compile fehlerfrei durch.
Somit bestätigt sich, dass die libboost Version ~1.6 auch nur mit GCC >
5 läuft.
Schönes WE und danke für die Hilfe.
Sebastian
Hallo Sebastian
unter welcher Version (wheezy oder jessie) hast du das denn jetzt
compiliert ?
Könntest du mit mal die fertig compilierte Datei schicken ?
mfg
Andreas
Hallo Sebastian,
vielen Dank, ich werde es in der nächsten Zeit mal testen. Ich denke
allerdings dass ich meine Installation erst etwas aufrüsten muss.
mfg
Andreas
Hello,
excuse me but i don't speak german, but i have a simple short question.
I have made the gateway circuit, is it possible to connect RX/TX
directly to a raspi/Arduino??? Or is the NETIO circuit also needed???
Hallo Zusammen,
in den letzten Tagen hatte ich Zeit, das Projekt etwas nach Vorne zu
treiben. Alles lief mit der Anleitung relativ problemlos. Besten Dank
dafür!
AVR-NET mit selbst gebauter Adapterplatine an einem Raspi, welcher
gleichzeitig mein openHAB beherbergt.
Die EMS Telegramme kommen sauber über MQTT rein und werden in openHAB
angezeigt.
Soweit sehr schön. Nur ist das ja nur die halbe Miete. Natürlich möchte
ich die Heizung auch ansteuern können. Hier komme ich aktuell nicht
weiter.
Mit
telnet localhost 7777
komme ich zwar auf die Kommandoebene, jedoch werden alle Anfragen mit
einem
ERRTIMEOUT
beantwortet. Auf der Platine leuchtet auch keine TX LED. Einen Fehler
auf der Platine sehe ich eigentlich nicht - nur der 1W Widerstand ist
schon recht warm.....
Die RX LED leuchtet immer mal wieder, so wie auch die Telegramme
reinkommen.
Könnt Ihr mir einen Tipp geben, woran es liegen könnte?
Muss ich das EMS Gateway noch irgendwie in meinem RC30 aktivieren oder
prüfen, ob es da ist?
Danke und VG
Sebastian
Sebastian Z. schrieb:> auf der Platine sehe ich eigentlich nicht - nur der 1W Widerstand ist
Dass der Widerstand warm wird wundert mich.
Der Widerstand wird benutzt um den EMS-Bus zu belasten wenn Deine
Platine sendet. Und das sollte nicht wirklich viel sein.
Würde jetzt einfach mal sagen Deine Platine sendet dauerhaft.
Wird dort denn eine dauerhaft eine weitere Adresse in der Info zum
EMS-Bus auf der RC30 angezeigt wenn Du Dein NetIO mit Platine
anschließt?
Dort müsste dann ein weiterer Busteilnehmer auftauchen.
Wenn das so ist funktioniert das Senden so wie es soll und ich habe
daneben geraten.
Danke IngoF,
das war der richtige Tipp.
Ein Lötpunkt vom OP in Richtung Basis des Transistors war nicht ganz
sauber von mir gelötet. Dadurch hat der PullUp Widerstand den Transistor
auf dauerhaft auf Durchgang, als auf Dauersenden geschaltet.
Nun läuft alles prima.
Besten Dank und VG
Sebastian
Hi all,
Isn't there still not someone who has ported the netio part to a simple
arduino?
I think it's possible but why didn't someone made it I ask myself.
I have seen the esp8266 solution from juergen, but that's not complete
yet. I saw another arduino solution but it's very basic. Why isn't it
possible to just rewrite the whole netio part to arduino. My programming
skill are limited and I'm stuck at the whole serial part and detecting
the frame error/break part. Isn't there a similar protocol of buderus so
I can search more options? CANBUS or Dmx protocol?
Delchrys schrieb:> I'm stuck at the whole serial part and detecting> the frame error/break part.
The stop-bit is inverted at the end of any command or reply.
That is the reason why your serial port must abe able to check this type
of error.
The arduino must allow to check the error status of the serial port for
each received byte.
You can not use the rx-buffer of the serial-port.
But aren't all atmegas capable of doing the same stuff.
Now I have juergens esp8266 solution running but that doesn't decode the
data to usable values like inlettemperature = 29.5 or something like
that.
I still not understand completely the whole serial Bit,byte and stop its
stuff. That makes it hard to understand what I need to do. Like to get a
arduino or esp8266 based gateway, so I can use all the rest of the
collectord like software
Delchrys schrieb:> But aren't all atmegas capable of doing the same stuff.
Maybe. I do not know anything about arduino. Do they all have atmega?
Check the datasheet of the used atmega to be shure.
How can I figure out what data my heater is sending every 10 seconds?
I like to know which of the parameters are sent by default.
I have only made the rx part of the gateway so I'm only listening.
I had some working arduino code but I can't figure out what complete
message is sent.
I also have some raw data direct read from the bus, by there's lots of
data so I don't know what to look for exactly. So I like to know which
parameters I can get without sending to the bus.
Delchrys schrieb:> How can I figure out what data my heater is sending every 10> seconds?> I like to know which of the parameters are sent by default.
The UBA sends two types of data without request:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme#ubamonitorslowhttps://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme#ubamonitorfast> I have only made the rx part of the gateway so I'm only listening.> I had some working arduino code but I can't figure out what complete> message is sent.
You must check the error-condition of the serial-port for each byte. The
end of the message is reached if a 0x00-Byte is received with this error
condition.
> I also have some raw data direct read from the bus, by there's lots of> data so I don't know what to look for exactly. So I like to know which> parameters I can get without sending to the bus.
You must check the error-condition of each byte to see the end of each
message.
How do you check the error-condition. Do you have some code?
Hi,
yes i have some code, it's kind off copy and pasted from several
different projects.
It uses a editted serial library, my cod now works with an ES8266 for
the wifi connection i'll post it here. For the library you can look at:
https://github.com/bbqkees/Nefit-Buderus-EMS-bus-Arduino-Domoticz
my code untill now is:
1
2
#include "WiFiEsp.h"
3
#define NEFIT_REG_MAX 17
4
#include <NefitSerial.h>
5
6
char ssid[] = "geheim"; // your network SSID (name)
7
char pass[] = "geheim"; // your network password
8
int status = WL_IDLE_STATUS; // the Wifi radio's status
9
10
char server[] = "arduino.cc";
11
12
// Initialize the Ethernet client object
13
WiFiEspClient client;
14
15
// MAC and IP of the Arduino
16
byte mac[] = {
17
0xDE, 0xAD, 0xBE, 0xEF, 0x00, 0x01}; // Set this to your preferred MAC address
18
IPAddress ip(192,168,1,80); // Set this to your preferred IP.
19
20
// IP address and port of Domoticz
21
IPAddress domoticz(192,168,1,67); // Set this to the IP address of your Domoticz
22
int port = 8080; // This is the default port of Domoticz.
23
24
25
PROGMEM const unsigned char regNefitCoding[]={
26
27
0x08,0x18,0x01,0x05, //#1 0 temperature water out (uitgaand) x 10
28
0x08,0x18,0x04,0x01, //#2 1 burner power
29
0x08,0x18,0x07,0x00, //#3 2 burner of/off
30
0x08,0x18,0x07,0x50, //#4 3 heating pump on/off
31
0x08,0x18,0x07,0x60, //#5 4 tap water heating on/off
32
0x08,0x18,0x0B,0x05, //#6 5 boiler temperature x 10
33
0x08,0x18,0x0D,0x05, //#7 6 temperature water in (cvreturn) x 10
34
0x08,0x18,0x11,0x06, //#8 7 water pressure x 10
35
0x08,0x18,0x12,0x02, //#9 8 status code 1st letter
36
0x08,0x18,0x13,0x02, //#10 9 status code 2nd letter
37
0x08,0x34,0x01,0x05, //#11 10 tap water temperature x 10
all the important error detection is in the library, i do not fully
understand it but i'm getting there. I really like to make the arduino
platform fully working with ems bus.
Thinking about making the TX part also so i can see if i can get some
more info out of the bus, so will be working on that later.
For now it works and i have integrated it into my domoticz application
to get some graphs.
still looking for a good serial port analyzer to sniff the port and look
at the raw bus data to see which parameter i can get without requesting.
or is it always the same??? Also like to know if my thermostat
communicates with the bus, i have a nefit moduline 100 or buderus rc10.
I thought the problem was the reading from the serial-port and finding
the end of the telegrams.
For a simple look on the bus you can use hterm to see the data like
this:
Beitrag "Re: Logamatic 2107 Schnittstelle"
you must
the busmaster polls the bus and the clients send their data if the have
their time. The busmaster sends itself the both telgrams periodically
without polling.
You can also read all other telegrams if they are send to the busmaster.
so i did hterm and read the port.
Any strange things in it or is it normal????
i see the 00 08 00 34 part and 00 08 00 18 part
so i guess that's good???
now only nee to separate the rest of the parameters.
delchrys schrieb:> so i did hterm and read the port.> Any strange things in it or is it normal????> i see the 00 08 00 34 part and 00 08 00 18 part> so i guess that's good???> now only nee to separate the rest of the parameters.
You muist activate the checkbox show errors. then the bytes with error
are marked red.
You must deaktivate the inputbuffer of the serial-port in windos. Set
receiverbuffer size to 1.
Maybe your computer ist too slow to check each byte and you get this
result:
Beitrag "Re: Logamatic 2107 Schnittstelle"
then you can resize the hterm-window to the minimum-size and you schould
work much more better.
Maybe the "newline after ... ms" will help to seperate the data optical.
I did newline at 00 08
Serial buffer will look in to that since I'm using a arduino in bridge
mode to simulate a serial usb connection.
Don't think my laptop i7 is too slow, gaming laptop.....
Will only use this to identify the messages so I can adapt them in my
arduino code. I like to read out everything my bus Is sending without
using tx part.
First identify all the messages....
now i did newline and fifobuffer at 1.
still no red colring on the 00 bit error.
but now i'm going to decode and see what exactly the message means.
any shortcuts on that??? so now i have to decode hex to decimal and make
something out of it
Hehe yes I see I made the screenshot with the checkbox unchecked. But it
didn't make any difference.
I'm looking in to some python scripts from the heatronic topic. Maybe
that can help me sort out the data.
seems my code or my gateway has some sort of error because i cannot find
my hotwater temperature in my arduino sketch the value of register 10
stays a negative number, it must be the 0x08,0x34,0x01,0x05, value.
also when i look at my RAW data it seems to be a bit off.
think i will solder myself a new gateway, maybe i have made some
mistake.
Strange because the rest of the data seems ok.
First i'm going to make myself a nice schematic which can easily be put
on a protoboard pcb. I then add also the TX part.
Really like to figure this out but it must work with an arduino...
Found another great project with arduino and a WiFLy RN/XV module:
https://github.com/danidata/Calduino-WiFly-Arduino-EMS-Buderus/tree/master/Calduino
He used some great code also, maybe i can use bits of it.
Hallole,
Über dem Sommer ist bei mir die Heizung vom Netz getrennt, nach dem die
Heizung wieder mit Strom versort wird kommt es zu einer Fehlermeldung
weil die Uhrzeit und Datum nicht merh stimmen. Ich würde gerne über den
Aufbau mit möglichst wenig Aufwand das Datum und Uhrzeit setzen. Das
NetIO ist über Telenet mit FHEM verbunden auf dem auch Dannys Collector
läuft. Hat jemand eine Idee wie man das Umsetzten könnte?
Danke und VG
Martin
Woher kommt die Fehlermeldung dass Uhrzeit und Datum nicht mehr stimmen?
Ist das FEHM?
Das einfachste wäre vermutlich über den Telnet-Port vom collectord. Dort
über das Datum/Uhrzeit-Telegramm die richtigen Werte setzen.
Beim telegramm müssen mehrere Werte angegeben werden. Der Command-Port
vom EMS-collector ist normalerweise 7777. Kann gerade keine Auflistung
finden wie man das Telegramm sendet. Einfach mal über telnet auf Port
7777 mit dem collectord verbinden. Vielleicht reicht die Hilfe vom
collectord aus. Einfach mal help eingeben.
https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme#rctimemessage
Kann es leider nicht testen weil der collectord zur Zeit bei mir nicht
läuft.
Auf dem Display vom BC10 steht der Servicecode A11 und auf dem Display
vom RC35 steht: "Klappe öffnen um Datum/Uhrzeit mit OK-Taste
einzustellen. Eingestelltes Datum 01.01.2000
Eventuell würde der Brenner sogar mit dieser Meldung irgendwann starten,
vielleicht war ich da immer nur zu ungeduldig. :-P
Wenn ich im Command-Port die Zeichenfolge 0b 90 06 00 08 eingebe kommt
ERRCMD zurück, muss dazu der RAW Modus aktiv sein? Das ist schon eine
weile her als ich da das letzte mal mit rumgespielt habe. ;-)
@Danny: Vielen Dank für deine schnelle Umsetztung!!
Vielen Dank an alle die sich an diesem Projekt seither so fleissig
beteiltigt haben.
Danke und Viele Grüße
Martin
martin_b13 schrieb:> Wenn ich im Command-Port die Zeichenfolge 0b 90 06 00 08 eingebe kommt> ERRCMD zurück, muss dazu der RAW Modus aktiv sein? Das ist schon eine> weile her als ich da das letzte mal mit rumgespielt habe. ;-)
Ich würd's (nach Update des Collectors) eher mal mit 'rc settime
2017-09-11 21:12:00‘ probieren ;-)
Bevor ich dem collector neu compeliert hatte, habe ich mit der
Zeichenfolge 0b 90 06 00 08 rumgespielt, wie gesagt habe ich da nur
ERRCMD zurück bekommen. :-(
Der neue "rc settime" Befehl im collector funktioniert bei mir perfekt.
Vielen Dank nochmal! ;-)
Mein GB135-25 Öler hat ja auch so ein SAFe Feuerungsautomaten verbaut,
als ich vor knapp 2 Jahren dieses Projekt nachgebaut habe, habe ich mir
über die Hardware BC10, MC10, RC20, SAFe etc. gar kein Kopf gemacht. :-o
Die zum kleinen Teil unterschiedliche Telegramme zu den hier
veröffentlichen Telegramme habe ich seither der RC20 zugeschrieben, seit
ich auch eine RC35 habe weis ich das es nicht nur an der RC20 liegt. ;-)
Aber das ist nicht schlimm, die meisten Funtionen tun was sie sollen,
wie gesagt tolles Projekt.
Danke und Viele Grüße
Martin
Hallo!
Meine Probleme mit dem Senden sind behoben. Es lag an einer fehlenden
Lötverbindung :-(
Ein Problem ist aber noch da: Unter Heizkurve zeigt er mir bei "Minimale
Aussentemperatur" 0°C und bei Auslegungstemperatur "wählen" an. Tag- und
Nachttemperatur steht auch auf "wählen", meine Anlage ist aber
außentemperatur geführt. Eine Verstellung der Temperaturen bringt auch
keine Änderung an der RC35.
Eingestellt an der RC35 sind 32°C @-12°C.
Hat jemand eine Idee, woran das liegen kann? Die Graphen werden bei mir
auch nicht angezeigt, das ist aber noch ein anderes (nicht so wichtiges)
Problem (und liegt vermutlich an GnuPlot).
Viele Grüße,
Marco
Hallo,
besteht eigentlich die Möglichkeit, bei Fehlern (Therme)
eine Mail zu generieren oder eine andere Möglichkeit bei Fehlern
automatisch benachrichtigt zu werden ?
Gruß
Marco schrieb:>> Ein Problem ist aber noch da: Unter Heizkurve zeigt er mir bei "Minimale> Aussentemperatur" 0°C und bei Auslegungstemperatur "wählen" an. Tag- und> Nachttemperatur steht auch auf "wählen", meine Anlage ist aber> außentemperatur geführt. Eine Verstellung der Temperaturen bringt auch> keine Änderung an der RC35.
Mein Problem hat sich gelöst. Es lag daran, dass die Graphen nicht
gezeichnet wurden. Seit die Graphen gehen, funktioniert auch die Anzeige
der richtigen Werte bei der Heizkurve.
Hallo
erst mal ein großes Lob an alle die zu diesem tollen System beigetragen
haben.
Habe es in dieser Woche endlich umgesetzt und es läuft fast ohne
Probleme.
Nun zu meinem Problem / Wunsch.
Ist es möglich den Collector so einzustellen dass er auch die
Betriebszeit der Solaranlage in die Datenbank schreibt.
Dominik H. schrieb:> Ist es möglich den Collector so einzustellen dass er auch die> Betriebszeit der Solaranlage in die Datenbank schreibt.
Kaum hatte ich die Frage gestellt habe ich schon die Lösung gefunden.
Hallo zusammen,
ich überlege ob ich mir auch so ein Konstrukt bauen soll.
Nur stellen sich mir nun einige Fragen. Ich weiß, jetzt kommt ließ doch
das Wiki! Aber da habe ich schon meine Erste Frage:
Sind die beide ganz Offline?
Ich kann sie seit ein paar Tagen nicht erreichen.
Des weiteren, ich habe eine ganz neue Heizung, eine GB212 mit einer
RC310 Steuerung. Wenn ich das richtig herausgefunden habe, spricht die
EMS+.
Aber hilft mir das weiter?
Diese Steuerung besitzt auch einen Lan-Anschluß, da komme ich aber noch
nicht dran, da ich dahin noch ein Kabel ziehen muss und der Wlan-AP ist
noch nicht geliefert (der soll da übergangsweise dran).
Könnte ich darüber denn auch schon alles machen, was hier so beschrieben
wird?
Oder muss ich dass alles probieren?
Was ich dann natürlich mache, wenn das noch keiner hat (und ja, ich
würde dazu auch etwas schreiben, wenn ich Erkenntnisse habe)!!
Also, die Frage lautet auch, welchen Weg sollte ich gehen?
Tipps werden gern genommen ... :-)
Gruß,
Helmut
Schönen Abend!!
Helmut B. schrieb:> Sind die beide ganz Offline?> Ich kann sie seit ein paar Tagen nicht erreichen.
Wiki war bis gestern abend 22:00 noch erreichbar und ist dann
abgeschmiert.
Hatte heute morgen den Server wieder am laufen aber die Wiki
"vergessen".
Konnte ich jetzt nicht so schnell zum laufen bekommen und versuche es
morgen früh wieder...
Helmut B. schrieb:> spricht die EMS+
Das sollte auch klappen kann dazu aber nichts sagen weil ich nur EMS
habe.
Es gab aber noch einen Thread mit einem WLAN-Modul (ESP?)
Hallo
ingof schrieb:> Helmut B. schrieb:>> Sind die beide ganz Offline?>> Ich kann sie seit ein paar Tagen nicht erreichen.>> Wiki war bis gestern abend 22:00 noch erreichbar und ist dann> abgeschmiert.
Einspruch euer Ehren. :-)
Das Wiki war am Samstag und gestern SICHER zwar vorhanden, aber leer.
Das es dann ab 22:00 Uhr gar nicht mehr ging kann sein ...
> Hatte heute morgen den Server wieder am laufen aber die Wiki> "vergessen".
Ist doch kein Problem!!
Dann freue ich mich um so mehr wenn es wieder geht!! ;)
>> Konnte ich jetzt nicht so schnell zum laufen bekommen und versuche es> morgen früh wieder...>
Auch kein Problem, nun weiß ich ja "es soll so nicht sein".
Dann probier ich eben immer wieder mal, damit habe ich keinerlei
Probleme!
> Helmut B. schrieb:>> spricht die EMS+>> Das sollte auch klappen kann dazu aber nichts sagen weil ich nur EMS> habe.>
Danke für Deine Auskunft und deine Mühen!!
Und bitte KEINE Hektik!
>> Es gab aber noch einen Thread mit einem WLAN-Modul (ESP?)
Und genau das glaube ich auch gefunden zu haben, aber ich finde es nicht
mehr wieder. Na ja ich werde noch mal suchen, sonst frage ich noch mal.
Danke und noch einen schönen Abend!
Gruß,
Helmut
Helmut B. schrieb:> Einspruch euer Ehren. :-)
Wir sind hier ja nicht vor Gericht :-)
Ich wurde von der Technik gemobbt. Erst hat mich mein Internetanschluss
mit längeren Aussetztern gemobbt. Als dann mein Server auch noch anfing
mich zu mobben hatte ich die Internetproblerme schon vergessen.
Helmut B. schrieb:>> Konnte ich jetzt nicht so schnell zum laufen bekommen und versuche es>> morgen früh wieder...
Das Wiki lief wohl schon seit gestern wieder. Musste nur den Cache im
Browser löschen damit es bei mir auch wieder lief.
Helmut B. schrieb:> Und genau das glaube ich auch gefunden zu haben, aber ich finde es nicht> mehr wieder.
Da ist er:
Beitrag "EMS > ESP8266-12 WLAN-Modul"
ingof schrieb:> Da ist er:> Beitrag "EMS > ESP8266-12 WLAN-Modul"
Huch... da habe ich schon seit langem nichts mehr daran gemacht.
Das Teil schiebt einfach ganz brutal alle Telegramme, die es auf dem
EMS-Bus sieht, an einen Telnet-Listener.
Ich habe seit längerem eine einfache JAVA-App laufen, die die Daten ein
wenig aufbereitet und in einen Logserver transferiert, da dies für meine
Zwecke ausreicht.
Hallo Ingo,
ingof schrieb:> Helmut B. schrieb:>> Einspruch euer Ehren. :-)>> Wir sind hier ja nicht vor Gericht :-)
Das war mir sehr wohl bewusst!
Aber mir viel gerade nichts besseres ein. :-)
>> Ich wurde von der Technik gemobbt. Erst hat mich mein Internetanschluss> mit längeren Aussetztern gemobbt. Als dann mein Server auch noch anfing> mich zu mobben hatte ich die Internetproblerme schon vergessen.
Das ist aber nicht schön, wenn man von der eigenen Hardware gemobbt wird
... ;)
>> Helmut B. schrieb:>>> Konnte ich jetzt nicht so schnell zum laufen bekommen und versuche es>>> morgen früh wieder...>> Das Wiki lief wohl schon seit gestern wieder. Musste nur den Cache im> Browser löschen damit es bei mir auch wieder lief.
Darin hatte ich Gestern schon mal gelesen und heute weiter. Das hat
schon mal sehr geholfen. Aber so ganz klar bin ich mir noch nicht wie
das geht, dazu muss ich mich noch weiter mit der Materie befassen.
Ach und danke für das Einstellen des tollen Wiki's!
Damit werde ich bestimmt noch zu tun haben!
Auch würde mich sehr interessieren, was mit der eingebauten Lan
Schnittstelle alles zu machen ist. Aber da warte ich noch auf einen Wlan
AP, den ich bestellt habe. Ich wollte mich nicht im Keller vor die
Heizung setzen ... :-)
>> Helmut B. schrieb:>> Und genau das glaube ich auch gefunden zu haben, aber ich finde es nicht>> mehr wieder.>> Da ist er:> Beitrag "EMS > ESP8266-12 WLAN-Modul"
Ja, danke ich hatte es dann auch irgendwann gefunden! ;)
Mal sehen, wie weit ich komme, wenn ich doch noch fragen oder Probleme
habe melde ich mich wieder.
Gruß,
Helmut
Hallo Juergen,
Juergen O. schrieb:> ingof schrieb:>> Da ist er:>> Beitrag "EMS > ESP8266-12 WLAN-Modul">> Huch... da habe ich schon seit langem nichts mehr daran gemacht.
Schade, aber wenn es das macht, was Du erwartest ...
Warum solltest Du auch!
> Das Teil schiebt einfach ganz brutal alle Telegramme, die es auf dem> EMS-Bus sieht, an einen Telnet-Listener.
D.h. Du liest nur die Daten aus und legst sie dann irgend wo ab?
Du machst über diese Schnittstelle keine Änderungen an dem System?
> Ich habe seit längerem eine einfache JAVA-App laufen, die die Daten ein> wenig aufbereitet und in einen Logserver transferiert, da dies für meine> Zwecke ausreicht.
Die App macht die Daten also für Menschen lesbar, richtig?
Ist diese App irgendwo zu bekommen?
Na ja, ich würde schon gern schreibend zugreifen wollen, ich hab da so
ein paar Ideen. Aber ob die machbar sind, weiß ich noch nicht.
So als Beispiel:
Ich möchte die WW Zirkulationspumpe schlafen schicken wenn keiner zu
hause ist. Auch ein Absenken der Virtuellen Raumtemperatur wenn keiner
zuhause ist wäre denkbar.
Aber naja, dafür muss ich die Funktion erst mal verstehen.
Danke für die Hinweise!
Gruß,
Helmut
Die App baut eine Telnet-Verbindung zum Interface auf und filtert (die
für mich) interessanten Daten aus. Diese werden (momentan) dann via
syslog an meine Syno geschoben.
Der Java-Code ist mit im Git. Kann relativ leicht auf bspw. MySql
umgeschrieben werden.
Der schreibende Zugriff auf den EMS-Bus ist nicht ganz so einfach (für
mich) zu implementieren, da der ESP eine 128 Byte FIFO hat, aber die
Logik ein Read after Write erfordert - mit Break-Erkennung.
Mal schauen ob ich über Weihnachten dazu komme.
Allerdings gibt mir Susi immer die Prio-1 Projekte vor :)
Guten Tag,
Gerne möchte ich mich hier melden, aus die Niederlande. Seit längere
Zeit beobachte ich diese Thread schon, weil ich ein Nefit Gas Heizung
habe die auch EMS spricht. Der arbeitet zusammen mit eine OEG
Solarthermie Anlage die mit eine (vom OEG angesteuerte) 3-wegventil
zusammen gebunden sind. Also Solar Warmwasser Bereitung mit
Heizungsunterstützung.
Jetzt aber macht der Steuerung vom 3-Wegventil mich ärger, Funktioniert
nur wenn es nicht soll funktionieren und umgekehrt. Meine Installateur
ist noch dran. Aber ich möchte gerne selber sehen was zumindest der
Nefit Heizung macht.
Also bin ich auf der Suche nach eine (hoffentlich einfache) Weg um die
Heizung aus zu werten. Ich möchte nur auswerten, nicht von außen
steuern. Etwas mit eine Raspberry Pi werde Bevorzugt, damit kenne ich
mir aus.
Softwaremäßig möchte ich gerne mit der SW von Danny Baumann arbeiten,
seht ja gut aus. Also brauch ich noch Hardware.
Es gibt ja hier oben ein Schaltplan, aber ich bin nicht gut im Sache
Hardware. Hat jemand noch etwas liegen was ich erwerben kann?
Funktioniert der SW vom Danny auch mit der ht_pitiny-Adapter vom Norbert
im Nachbar Thread (Beitrag "Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi")?
Gruß, Ferdinand
Hallo,
Mittlerweile gibt es ein neue Möglichkeit für die Hardware Link. Im
Domoticz Forum gibt es jetzt ein Platine zum Umsetzung vom EMS auf UART:
http://www.domoticz.com/forum/viewtopic.php?f=38&t=14132&start=100
Diese ist gedacht für ein Arduino Anbinding, sollte aber auch an ein
Raspberry Pi funktionieren. Entweder über direkte UART Verbindung oder
UART-USB adapter wie:
http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm
Der Platine habe ich mir besorgt. Jetzt komt der Umsetzung von Software.
Ich habe for der Platine an ein Raspberry Pi zu verknöpfen um dan mit
der EMS Collector von Maniac103 der Bus aus zu werten. Zu dies wird ich
noch Fragen im Buderus Faktensammlung Thread
(Beitrag "Faktensammlung Buderus EMS") stellen.
Gruß
Hi Leute,
bin neu und unerfahren. Spiele mich seit tagen mit dem Net-IO.
Ich habe die Software gebrannt mit dem HEX file. der Net-IO lässt sich
auf
192.168.0.0 anpingen. Ich bekomme aber keine Verbindung über Safari,
geschweige denn kann ich die ip, etc. änder. was mache ich falsch?
Hallo
Die IP 192.168.0.0 lässt sich deswegen an pingen da dies eine
Netzadresse und den Rechner selber antwortet und nicht als IP-Adresse
für ein Gerät verwendbar ist. Ebenfalls die IP 192.168.0.255 kann nicht
verwendet werden.
Wähle bitte eine andere z.B.: 192.168.0.245 aus und flashe den Net-IO
nochmals neu mit der dieser IP.
Hi RaspiNick,
ich habe das hex-file vom Ems-wiki genommen, da ich das hex-file nicht
erstellen konnte. Hast du evtl ein Hex-File, welches ich flashen kann?
Danke.
Hi zusammen,
nun stehe ich vor dem nächsten Problem. Nachdem im Wiki immer von Wheezy
ausgegangen wird und mein Raspi 3b+ das aber nicht unterstützt bin ich
etwas ratlos. Im Forum finde ich auch nicht wirklich was. Leider habe
ich keinen "alten" Raspi. Gerne würde ich das aktuell Openhabian-Image
nehmen, denn der collector und openhab sollen darauf gemeinsam arbeiten.
Hat jemand einen Rat für mich.
Danke an Alle, auch für die tolle Arbeit die hier geleistet wurde und
wird.
AS
Hallo,
nachdem hier alles jahrelang einwandfrei funktionierte ist mir vor
einigen Tagen der kleine Server "stehen" geblieben.
Alles tot.
Also flugs ein Cubieboard mit einer Dauerlauf festen Platte
ausgestattet und tapfer eine Neuinstallation gemacht.
Diesmal mit PHP7 statt PHP5, aber jetzt tauchen Fehler im Serverlog auf,
die ich auch nach längere Suche nicht abstellen konnte.
Funktioniert:
Lifestatus
Schaltpunkte
Heizkurve
Einstellungen
Statistik
Also die wesentlichen Funktionen.
Fehler treten auf bei (Auszüge aus dem Serverlog ohne Datum):
Fehlerspeicher
(mod_fastcgi.c.2543) FastCGI-stderr: PHP Notice: Undefined index: A0800
in /var/www/html/a_emserr.php on line 53
Protokoll
mod_fastcgi.c.2543) FastCGI-stderr: PHP Fatal error: Uncaught Error:
Call to undefined function mysql_connect() in
/usr/local/emsincludes/includes/emsqry.inc:404
(mod_fastcgi.c.2543) FastCGI-stderr: Stack trace:
(mod_fastcgi.c.2543) FastCGI-stderr: #0 /var/www/html/a_emslog.php(16):
getEmsStatusCodes()
(mod_fastcgi.c.2543) FastCGI-stderr: #1 /var/www/html/index.php(31):
require('/var/www/html/a...')
(mod_fastcgi.c.2543) FastCGI-stderr: #2 {main}
(mod_fastcgi.c.2543) FastCGI-stderr: thrown in
/usr/local/emsincludes/includes/emsqry.inc on line 404
Bin dankbar für jeden Tipp.
Gruss Knut
Hallo Knut
Das Problem kommt daher das im php7 leider das mysql_connect entfernt
wurde.
Hatte das selbe Problem und die Datei
"/usr/local/ems-tools/includes/emsqry.inc" geändert.
Nachfolgend der Teil des Codes ca. ab Zeile 404 den ich geändert habe.
function getEmsStatusCodes(){
global $mysql_host, $mysql_user, $mysql_pass;
//$link=mysql_connect($mysql_host, $mysql_user, $mysql_pass)
//or die("Keine Verbindung zur Datenbank moeglich: " .
mysql_error());
//mysqli_query("use ems_data");
$mysqli = new mysqli($mysql_host, $mysql_user, $mysql_pass,
'ems_data');
if ($mysqli->connect_error) {
die('Connect Error (' . $mysqli->connect_errno . ') '
. $mysqli->connect_error);
}
/*$result = mysql_query("SELECT a.value as sc, b.value as fc,
a.starttime as time ".
"FROM state_data a, state_data b ".
"WHERE a.sensor = 200 and b.sensor = 201 ".
" and a.starttime = b.starttime ".
"ORDER BY time DESC" )
or die("Abfrage fehlgeschlagen! ". mysql_error());*/
$query = "SELECT a.value as sc, b.value as fc, a.starttime as time
FROM state_data a, state_data b WHERE a.sensor = 200 and b.sensor = 201
and a.starttime = b.starttime ORDER BY time DESC";
if ($result = $mysqli->query($query)) {
$res = array();
while($row = mysqli_fetch_assoc($result) ){
$res[]=str_replace("
","|",trim($row['time']))."|".$row['sc']."|".$row['fc'];
}
return $res;
}
}
Danach werden die Meldungen im Protokoll wieder ausgegeben.
Das Problem mit dem fehlenden Statuscode konnte ich bislang auch bei mir
nicht direkt lösen. Habe da einfach in der Datei
"/usr/local/ems-tools/includes/emsscdes.inc" , vor der schließenden
Klammer am Ende der Datei die fehlenden Codes eingetragen z.B.:
"A0800" => "Unbekannter Status der Heizung.",
Schöne Grüße
Dominik
Danke Dominik,
jetzt spielt wieder alles wie ich es in Erinnerung hatte.
Da wäre ich nie allein drauf gekommen.
Vielleicht fühlt sich ja mal jemand in der Lage die SW zu aktualisieren,
denn das Programm ist doch wirklich klasse und ich denke, dass ich
nicht der Einzige bin, der solche Probleme hatte.
Gruss
Knut
dk6lg schrieb:> Vielleicht fühlt sich ja mal jemand in der Lage die SW zu aktualisieren,
habs mal ungetestet übernommen.
Moosy pfleg sein Repository ja nicht mehr. Ich hatte die EMS-Tools
damals etwas modifiziert aber länger nicht mehr wirklich benutzt.
Habe es gerade mal upgedatet:
https://github.com/ingof/ems-tools
Oder hattet Ihr noch eine andere alte Quelle
Wenn jemand was geändert am besten ein PullRequest loslassen und ich
übernehme es dann so...
Hallo Dominik,
jetzt habe ich doch noch eine Frage: Wie werde ich die messages los?
Er müllt mir das /lighttpd/errorlog mit folgenden Nachrichten zu:
FastCGI-stderr: PHP Notice: Trying to get property of non-object in
/var/www/html/sensor_utils.php.inc on line 11
und auch für die Zeilen 12, 20, 21, 85, 87
Meine Suche ergab, dass es ja nur eine "Notice" sei, aber mich stört es
;-)
Falls Du eine Idee hast bitte immer her damit!
Gruss
Knut
Hallo Knut
das Kannst du deaktivieren, indem du in der php.ini
bei mir im Pfad unter "/etc/php/7.0/apache2"
den Eintrag "error_reporting= E_ALL"
auf
"error_reporting= E_ALL & ~E_DEPRECATED & ~E_STRICT"
änderst.
Das ist die empfohlene Einstellungen für Produktivsysteme. Dann werden
Notizen und Warnungen wegen veraltetem Code nicht mehr angezeigt und
geloggt.
Du kannst es aber auch über die Einstellungen
"display_errors = Off" und log_errors = "Off" komplett abschalten.
"display_errors" sollte sowieso auf "Off" stehen um keine Zugangsdaten
zu veröffentlichen bei Datenbank- oder Skript-Fehlern.
Schönes Wochenende
Dominik
Hallo,
vielleicht wisst Ihr Rat:
Seit ich mit den Einstellungen im EMS-php UI und am RC35 rumgespielt
habe, springt meine Einstellung immer wieder auf
raumtemperaturgesteuert, obwohl ich immer wieder
aussentemperaturgesteuert auswähle.
Einstellung im RC35 ist für nur einen Heizkreis auf
außentemperaturgesteuert.
Bei Starten meckert die Heizung jedoch, dass die Einstellung für
raumtemperaturgesteuert gewählt ist, aber keine Fühler angeschlossen
sind.
Was kann das sein? Ideen?
Hallo Dominik,
es hat geholfen.
log_errors = "Off"
stand auf "On", die anderen Einstellungen stimmten schon.
Nun ist endlich wieder Ruhe im log.
Danke!
Gruss
Knut
Hallo Bernd, das Problem taucht bei mir auch auf ... eine Lösung habe
ich bisher noch nicht gefunden. Evtl. weiß ja jemand anderes Rat !?
Evtl. wird in den erweiterten Einstellungen ein falscher Wert übergeben
(Regelung/Führungsgröße) ?
Nach langem Suchen bin ich auf folgende Seite gestossen:
https://github.com/Th3M3/buderus_ems-wiki
Hier sind die Telegramme von MC110, RC310 und MM50 dokumentiert. Diese
haben mir sehr geholfen.
Kennt jemand die Telegramme vom Mischermodul MM100?
Danny B. schrieb:> Marco schrieb:
....
>>> 4.) In den Einstellungen wird die "minimale Außentemperatur" als 0°C>> ausgelesen. Die Anlage steht aber auf -10. Ich kann den Wert über das>> Webinterface erfolgreich setzen, aber auch dann wird wieder 0°C>> angezeigt. In den Rohdaten tauchen die -10 Grad unter "mintemperature">> auf.>> Ich gehe mal davon aus, dass sie dort als 'rc mintemperature' auftaucht?> Wenn ja, ist das ein Frontend-Problem, da kann ich dir leider nicht> helfen.
Hallo Danny B.: Ich beziehe mich auf den obrigen Beitrag #4903983:.
In emssetvalue.inc und emsgetvalue.inc steht tatsächlich rc ..
"gebaeude" => "rc buildingtype",
"daempfung" => "rc outdoortempdamping",
"minaussentemp" => "rc mintemperature",
Nachdem löschen von dem rc wird der Wert „gebaede“ und „daempfung“ auch
tatsächlich richtig angezeigt. Nur "mintemperature" ist aber immer noch
falsch!
Ich dachte das Problem mit der mintemperature ist gefixt, ich habe die
aktuelle collector Version installiert.
An IngoF: könntest du die Bugs in emssetvalue.inc und emsgetvalue.inc
korrigieren?
Helmut J. schrieb:> Danny B. schrieb:>> Marco schrieb:> ....>>>>> 4.) In den Einstellungen wird die "minimale Außentemperatur" als 0°C>>> ausgelesen. Die Anlage steht aber auf -10. Ich kann den Wert über das>>> Webinterface erfolgreich setzen, aber auch dann wird wieder 0°C>>> angezeigt. In den Rohdaten tauchen die -10 Grad unter "mintemperature">>> auf.>>>> Ich gehe mal davon aus, dass sie dort als 'rc mintemperature' auftaucht?>> Wenn ja, ist das ein Frontend-Problem, da kann ich dir leider nicht>> helfen.>> Hallo Danny B.: Ich beziehe mich auf den obrigen Beitrag #4903983:.> In emssetvalue.inc und emsgetvalue.inc steht tatsächlich rc ..> "gebaeude" => "rc buildingtype",> "daempfung" => "rc outdoortempdamping",> "minaussentemp" => "rc mintemperature",>> Nachdem löschen von dem rc wird der Wert „gebaede“ und „daempfung“ auch> tatsächlich richtig angezeigt. Nur "mintemperature" ist aber immer noch> falsch!> Ich dachte das Problem mit der mintemperature ist gefixt, ich habe die> aktuelle collector Version installiert.>> An IngoF: könntest du die Bugs in emssetvalue.inc und emsgetvalue.inc> korrigieren?
Mit dem aktuellen collectord ist das Probelm behoben. Es muss jetzt
wieder wie im Original:
"rc buildingtype",
"rc outdoortempdamping",
"rc mintemperature",
heißen.
Jens Heruth schrieb:> Hallo Bernd, das Problem taucht bei mir auch auf ... eine Lösung habe> ich bisher noch nicht gefunden. Evtl. weiß ja jemand anderes Rat !?> Evtl. wird in den erweiterten Einstellungen ein falscher Wert übergeben> (Regelung/Führungsgröße) ?
Ich habe jetzt den Collectord von Moosy aus
https://github.com/moosy/ems-collector eingesetzt und auch seinen Stand
des Web-Interfaces. Dort habe ich das Problem nicht mehr. Grund bisher
unbekannt.
Welche Parameter für die Heizkurve verwendet Ihr?
Insbesondere Eure mindest-Außentemperatur und die Auslegungstemperatur
interessiert mich. Warum ist die Einstellung Auslegungstemperatur auf
50° beschränkt? Das ist doch die maximale Vorlauftemperatur bei der
minimalen Außentemperatur, oder? Scheint mir wenig zu sein... Oder
verstehe ich das falsch?
Hallo ins Forum,
ich verwende den ems-collector und das WEB-frontend seit knapp 4 Jahren
an meinem Buderus-Heizkessel und bin damit sehr zufrieden.
Damals habe ich alles auf einem Raspberry Pi 3B installiert, auf
Raspbian Jessie. Alles prima, damals.
Nun gab es ja mehrfach Updates u.a. auf Buster und da das Upgrade von
Jessie auf Buster nicht wirklich unterstützt wurde, wollte ich das neu
aufsetzen, auf einem Raspberry 4.
Tja, war nicht ganz einfach, aber ich habe fast alles hingekriegt (auch
die Sache mit PHP7), nur an zwei Problemen beisse ich mir noch die Zähne
aus:
- a)
der ems-collector läßt sich auf Buster nicht mehr compilieren, da das
Paket libmysql++-dev nicht mehr zur Verfügung steht. Das stellt doch
eigentlich alle User, die die Software neu installieren wollen vor
Probleme. Läßt sich da was dran machen?
Ich habe mir geholfen, indem ich den collectord vom alten System kopiert
habe und dann die Komponenten rübergezogen habe, nach denen er beim
Starten geschrieen hat. Das waren:
+ /usr/lib/arm-linux-gnueabihf/libboost_system.so.1.62.0
+ /usr/lib/arm-linux-gnueabihf/libboost_program_options.so.1.62.0
+ /usr/lib/libmysqlpp.so.3
+ /usr/lib/libmariadbclient.so.18
Dann lief wieder alles und ich hab mich schon gefreut, leider etwas zu
früh und damit kommen wir zu meinem zweiten Problem:
-b)
es sieht so aus als ob der ems-collector (collectord) immer mal wieder
unregelmäßig, so alle 10-15 Minuten für ein paar Minuten einfriert. Das
erkennt man beispielsweise dran, dass die normalerweise gelben Parameter
der Live-Rohdatenanzeige nicht mehr aktualisiert und so mit der Zeit
grau werden.
Nach einer Weile schüttelt sich dann der collectord und kappt
beispielsweise die telnet localhost 7777 Verbindung. Man kann aber bis
kurz vorher mit "cache fetch" Daten holen. Nur neue Rohdaten werden
nicht weitergegeben obwohl die entsprechenden LEDs am NetIO Gateway brav
alle paar Sekunden blinken.
PHP meldet dann "connection reset by peer" und dann geht es wieder für
ein paar Minuten gut. Damit ist die Aufzeichnung in der Datenbank etwas
lückenhaft, soweit immer noch brauchbar aber es stört mich ungemein,
wenn was nicht sauber funktioniert.
Ich habe den collectord auch mit der debug-Option -d
all=/home/pi/collector.log laufen lassen und beobachtet, ob während des
Einfrierens Ausgaben kommen. Nein, die Ausgabe friert ein, aber ohne
Fehlermeldung: die letzte Zeile ist beispielsweise "DATA:
Zirkulation-Bertriebsart = Automatik". Irgendwann geht es dann nahtlos
weiter aber die Rohdaten-Telegramme in der Zwischenzeit gehen wohl
verloren. Beispiel:
IO: Got bytes 0xaa 0x55 0x1f 0x8 00 0x18 00 0xb 0x1 0x1e 0x64 00 00 00
00 00 0x2 0x16 0x7d 00 0x1 0x53 00 0x1 0x13 0x30 0x48 00 00 0xff 00 00
0x80 00 0x4e
MESSAGE[31.08.2020 19:29:38]: source 0x08, dest 0x00, type 0x18, offset
0, data: 0x0b 0x01 0x1e 0x64 0x00 0x00 0x00 0x00 0x00 0x02 0x16 0x7d
0x00 0x01 0x53 0x00 0x01 0x13 0x30 0x48 0x00 0x00 0xff 0x0$
DATA: Kessel-Solltemperatur = 11 °C
DATA: Kessel-Isttemperatur = 28.6 °C
DATA: Brenner-Sollwert Modulation = 100 %
DATA: Brenner-Istwert Modulation = 0 %
DATA: Flamme = AUS
DATA: Brenner = AUS
DATA: Zündung = AUS
DATA: Kessel-Pumpe = AUS
DATA: 3-Wege-Ventil auf WW = AUS
DATA: Zirkulation = AUS
DATA: Rücklauf-Isttemperatur = 33.9 °C
DATA: Flammenstrom = 0.1 µA
DATA: Systemdruck = 1.9 bar
DATA: Ansaugluft-Isttemperatur = nicht verfügbar
DATA: Servicecode = 0H
DATA: Fehlercode = 0
IO: Got bytes 0xaa 0x55 0xe 0x8 00 0x18 0x1b 00 00 00 00 00 00 00 0xb 00
00 00
MESSAGE[31.08.2020 19:29:39]: source 0x08, dest 0x00, type 0x18, offset
27, data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0b 0x00 0x00
IO: Got bytes 0xaa 0x55 0x14 0x8 00 0x34 00 0x3a 0x2 0x16 0x7d 00 0x21
00 0x1 0x3 00 0x3 0x15 0xb4 00 0x23 0x61 0xac
MESSAGE[31.08.2020 19:29:39]: source 0x08, dest 0x00, type 0x34, offset
0, data: 0x3a 0x02 0x16 0x7d 0x00 0x21 0x00 0x01 0x03 0x00 0x03 0x15
0xb4 0x00 0x23 0x61
DATA: Warmwasser-Solltemperatur = 58 °C
DATA: Warmwasser-Isttemperatur = 53.4 °C
DATA: Warmwasser-Tagbetrieb = AN
DATA: Warmwasser-Einmalladung = AUS
DATA: Warmwasser-Therm. Desinfektion = AUS
DATA: WW-Bereitung = AUS
DATA: Warmwasser-Nachladung = AUS
DATA: WW-Temperatur OK = AN
DATA: Warmwasser-Fühler 1 defekt = AUS
DATA: Warmwasser-Fühler 2 defekt = AUS
DATA: Warmwasser-Störung = AUS
DATA: Warmwasser-Störung Desinfektion = AUS
DATA: Zirkulation-Tagbetrieb = AN
DATA: Zirkulation = AUS
DATA: Warmwasser-Ladevorgang = AUS
DATA: WW-System-Typ = groß
DATA: Warmwasser-Durchflussmenge = 0 l/min
DATA: WW-Bereitungszeit = 202164 min
DATA: WW-Bereitungen = 9057
DATA: Zirkulation-Betriebsart = Automatik
Hallo Sven,
erst mal vielen Dank für die schnelle Reaktion.
Ja, das Paket default-libmysqlclient-dev wird gefunden und erfolgreich
installiert. Aber das Problem beim compilieren bleibt das gleiche ...
;-( Es fehlen leider immer noch die mysql C++ header.
Hallo Forum,
das Problem #b (Einfrieren des Collectors) in meinem Posting vom
31.08.2020 20:06 ist vorerst verschwunden. Es war über zwei Tage
reproduzierbar alle 10-15 Minuten zu beobachten. Jetzt wollte ich nach
einer Woche der Sache nochmal weiter nachgehen, aber im Moment
funktionert es.
Ich mag Fehler nicht, die von selbst verschwinden. ;-(
Aber das Problem #a (Neukompilieren des Collectors geht nicht weil das
Paket libmysql++-dev auf Raspbian Buster nicht zur Verfügung steht) ist
noch offen.
Viele Grüße
Paul
Thread beobachten
Seitenaufteilung abschalten
