Hallo Leute,
ich plane einen Teil meiner "Hauselektronik" zu erneuern und brauche
einen Ratschlag.
Ist-Zustand: Beck SC13 der über DS2482-800 momentan 20 DS18B20 ausliest
sowie von zwei Quellen (Gas, Strom) zwei S0-Signale empfängt. Der SC13
bzw. die Beck-Libraries erlauben die problemlose Verarbeitung von
externen Interrupts via ISRs, die ich für die Auswertung der S0-Signale
verwende. Der Rest via I2C ist eher Kinderkram. Das ganze wird via
Socket (TCP) an einen Host geschickt der dies wiederum in eine Oracle-DB
schreibt. Die Verwendung der Daten (Heitungssteuerung und Auswertung)
lasse ich an dieser Stelle einfach außen vor da diese ja bleiben soll.
Das Ganze läuft seit ca. 5 Jahren 24/7 mit relativ wenig Problemen.
Warum dann umstellen? Den SC13 gibt es nicht mehr. Relativ hoher
Stromverbrauch (und Wärmeentwicklung). Grottenschlechte
Entwicklungsumgebung. Ich möchte in Zukunft mehr als 2 S0-Signale
verarbeiten (neu: Wasser sowie eine weitere Strom-Messung).
Avisierter Zustand: Ein Raspi, der die o.g. Aufgaben übernimmt aber die
Daten nicht mehr via (proprietärem) Socket-Protokoll abliefert sondern
sie gleich in eine remote (auf dem Host laufende) MySQL-DB schreibt
(leider kein Oracle-Client für ARM verfügbar). Sollte der Kontakt zum
Host abbrechen (Stromausfall, der Pi wird Batterie-gepuffert) wird
solange in eine "lokale" SQLite-DB geschrieben, bis der Host wieder da
ist um dann alle Daten von der lokalen zur remoten DB zu transportieren.
Soweit so gut. Software dafür sowie I2C ist kein Problem. Der alles
entscheidende Punkt sind die S0-Signale. Hier komme ich nicht weiter.
Ich weiß dass es prinzipiell die Möglichkeit gibt, so etwas wie ISR auf
dem Pi zu verwenden. Es wird aber von überall gewarnt dass es hier keine
Priorisierung gibt und u.U. Signale (Flanken) verloren gehen können. Das
aber will ich unbedingt vermeiden. Meine momentane Idee ist es, einen
ATmega328 (Arduino, wegen der Einfachheit der Tool-Chain) zu verwenden,
der die S0-Signale empfängt, die Zeiten (zwischen zwei Flanken ==
Verbrauchs-Momentanwert) misst und diese dann vi UART oder I2C (Slave)
an den Raspi schickt. Softwaremäßig würde ich mir das auch zutrauen und
sehe da auch keine großen Probleme. Aber: ich möchte die Anzahl der
S0-Kanäle auf 4 erweitern und der ATmega328 besitzt nur 2 ext.
Interruptus. Ich könnte auf einen Mega2560 ausweichen, der 8 ext.
Interruptus besitzt, scheue mich aber vor der Idee so ein "Monster"
selbst zu verbauen (PCB-Design, löten). Der ATmega328 (DIL, Fassung,
extern programmieren) wäre mir da deutlich lieber. Vielleicht wäre es
auch möglich ein Eingangsbyte zu pollen (es gibt doch da so eine
Fast-IO-Lib). Wie gestalte ich dann meine Timebase? Eine Möglichkeit
wäre es, Timer1 im Hintergrund (mit Auto-Reload) laufen zu lassen
(Überlauf mitzählen) und dann im 'main' einfach eine Schleife mit max.
Speed laufen lassen, dabei die Eingänge (als Byte) pollen und bei
Veränderung L->H (vorherigen Zustand sowie Timer1-Wert - getrennt für
jeden Kanal bzw. Eingang gemerkt) die abgelaufene Zeit berechnen. Wird
ein bisschen tricky (Überlauf berücksichtigen) aber sollte gehen. Dann
aber noch die Kommunikation mit dem Host. Verwende ich I2C muss ich dem
Host signalisieren, dass Daten zur Verfügung stehen (oder der muss
ständig I2C-pollen, besser nicht). UART wäre hier besser, einfach Daten
senden. Während ich das schreibe, frage ich mich gerade, ob ich nicht
auch mit dem Raspi seine PIOs pollen kann. Ich würde mal sagen, 1k/s
reichen. Wie hoch ist dabei die CPU-Belastung. Muss ich testen. Hat
jemand Ideen oder Anmerkungen dazu? Was ist Eurer Meinung nach der beste
Weg?
Danke für den sehr "freundlichen" Hinweis. Aber um des Friedens Willen,
ich habe mir mehr als die ersten 4 Seiten durchgelesen - und verstehe
immer noch nicht was das mit dem Problem "Interfacing S0 into the
Raspberry.Pi" zu tun hat. Speziell, nachdem ich meine Zielkomponenten
(sowie die Erklärung zur Entscheidung für dieselben) ja relativ deutlich
dargelegt habe. Der CGMMSTICK ist sicherlich kein schlechtes Teil, ich
(ich persönlich also) bleibe aber lieber bei einer überschaubaren Anzahl
von zu verwendenden Controllern. Da ich derer schon einige "im Programm"
habe möchte ich mein Repertoire nur ungern erweitern - und sehe auch
keine Notwendigkeit dazu.
na weil das Teil, basierend auf dem modernsten PIC, das alles kann was
Du benötigst und beispielsweise 20 ext. Interrupts besitzt und auch all
Deine Peripherieanforderungen erfüllt.
Und so ein rasend schneller Interpreter ist für Test und Entwicklung
eine extrem angenehme Umgebung, nebst Eignung als Zielplattform.....
Die Beck Entwicklungsumgebung beschreibst Du ja selbst als sehr
schlecht.
Der Stick kostet übrigens keine 20 Euronen.
Enrico F. schrieb:
..schnipp..
> Aber: ich möchte die Anzahl der> S0-Kanäle auf 4 erweitern und der ATmega328 besitzt nur 2 ext.> Interruptus.
wieso? Jeder PIN ist als Interruptquelle nutzbar >siehe PCINTx
Sascha
@Sascha
Gut recherchiert. Aber wie der Name es vermuten lässt handelt es sich um
"Pin-Change-Ints" die noch dazu alle in einem einzigen Interrupt-Vector
landen. D.h. dass ich in diesem dann als erstes einen Poll machen muss,
um herauszufinden welcher Pin es war. Da kann ich auch gleich
(Loop-)pollen ... Wenn der Chip sonst keine weiteren Tätigkeiten
ausführen soll fände ich das (in diesem speziellen Fall) auch gar nicht
so schlimm ... und ich freunde mich auch immer mehr mit dem Gedanken an
:) In einer solchen (sehr schnellen) Loop könnte man auch problemlos
einen Tiefpass einbauen und spart sich so eine externe Entprellung.
@6502oldpapa
Bitte, bitte nicht falsch verstehen und bitte auch nicht persönlich
nehmen: ich entwickle seit 16J. beruflich in C/C++, auf beinahe jeder
bekannten Plattform (OS) inkl. einiger Exoten, "rasend schnell" ist für
mich Assembler, schnell ist C, evtl. noch C++, aber einen Interpreter
als "rasend schnell" zu bezeichnen ...
"Die Beck Entwicklungsumgebung beschreibst Du ja selbst als sehr
schlecht." Deswegen will ich ja auch weg davon. Für den Rasp.Pi verwende
ich Eclipse, für den Arduino die gleichnamige "IDE". Vielleicht nicht
"top notch", speziell die letzt genannte, aber OK.
Was mich ebenfalls davon abhalten würde den CGMMSTICK zu verwenden, ist
die Verfügbarkeit. Wer weiß wie lange das "Projekt" noch lebt. Einen
Atmega328 wird es sicherlich noch einige Jahre geben ... und dem Rasp.Pi
traue ich auch einen langen live-cycle zu.
das ist doch kein Problem, du schließt alle Eingänge an einen Port an.
In der ISR liest du den ganzen Port ein und machst ein XOR mit einem
gespeicherten Wert vom letzten Durchlauf - und schon hast du den/die
Pins die sich geändert haben.
ODER: du nimmst INT0, INT1 und die zwei restlichen von zwei
verschiedenen Ports - schon hast du 4 INTs mit eigener ISR.
Sascha
....für einen Interpreter ist der mmbasic Interpreter definitiv rasend
schnell.
Abhängigkeiten bezüglich Verfügbarkeit sehe ich hier nicht, oder ist die
Aversion gegen einen PIC in diesem Forum so groß ?
Komplette ERP Lösungen des damaligen Marktführers Nixdorf ( 80 er Jahre)
liefen in einem Interpreter.
Das war schon bemerkenswert wie ein Bekannter damals in laufenden ERP
Umgebungen großer Automobilhersteller on The fly Kundenwünsche in der
Software umsetzte.
Etwas komfortableres ist mir bis heute nicht mehr begegnet.
Ich muss heute zwar keine Eproms mehr unter die Höhensonne legen,
dennoch besteht der Zyklus immer aus programmieren, compilieren,
flashen, testen und wieder von vorn beginnen.....
Es hängt halt immer von den Anforderungen ab, wer heilt hat recht ;-)...
Interpreter schrieb:> Abhängigkeiten bezüglich Verfügbarkeit sehe ich hier nicht, oder ist die> Aversion gegen einen PIC in diesem Forum so groß ?
Nein, zumindest von meiner Seite keine Aversion. Und ich glaube auch,
dass der Interpreter für viele Dinge (die Meisten?) schnell genug ist
(vlt. auch für mein Ziel). Aber das ist nicht so sehr die Frage, sondern
vielmehr wieviel Aufand es mich kostet vs. eine mir (und das nicht nur
oberflächlich) bekannte Plattform (Arduino) zu verwenden, für die ich
sowieso schon "eingerichtet" bin. Bei der Verfügbarkeit meinte ich mehr
das kpl. Board (CGMMSTICK) als den PIC.
Hallo Enrico,
ein interessantes Projekt mit einigen Fragestellungen die mir auch schon
untergekommen sind.
Zum Stromverbrauch:
Der Beck SC13 zieht laut Datenblatt 1,3W.
"Ein Raspberry Pi Modell A verbraucht 2,5W (5V, 500 mA), ein Modell B
3,5W (5V, 700mA)."
Falls Atmega: Der Arduino Ethernet Shield basiert auf dem Wiznet W5100,
der benötigt 150-180mA. Die 3.3V stammen aus Linearreglern, also
5V*180ma -> 0.9W. Dann besser Wiz820IO, basierend auf W5200 -> 0.5W im
Betrieb, und dann entweder den Power Down Modus benutzen oder die
Spannungsversorgung nur für jede Übertragung aktivieren. Für den
Wiz820IO kann die Arduino Ethernet-Lib mit einer kleinen Änderung weiter
verwendet werden.
Wenn der Stromverbrauch wirklich minimal werden soll, solltest du den
uC immer wieder in den Stromsparmodus schicken. Dann kann die Software
aber nicht pollen sondern muss Timer- und Interruptgesteuert gebaut
werden.
Zur S0-Messung:
Ein S0-Impuls hat eine minimale Dauer von 30ms. Das ist eine Ewigkeit.
Es werden dir also keine Impulse verlorengehen. Ich denke, dir geht es
um die Messung der Zeit zwischen zwei Impulsen, um jederzeit den
aktuellen Verbrauch zu ermitteln? Aber wie genau muss es denn sein? Bei
einem S0-Impuls pro Wh bewirkt ein Stromverbrauch von 3600W einen Impuls
pro Sekunde, und eine Änderung auf 3610W bewirkt einen Impulsverkürzung
um 2770uS.
Solch "lange" Zeiten zu messen wird weder für den Raspi noch für einen
uC irgend ein Problem sein. Der Raspi-Prozessor kalibriert zwei Mal pro
Sekunde den SDRAM-Refresh und hält dabei für einige uS an, aber erstens
lässt sich das mit disable_pvt=1 ausschalten (siehe
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=7696) und
zweitens wird der Messfehler (bei obigen Annahmen) unter 1/10W liegen.
Beim Ansatz mit Atmega ist die gemeinsame ISR für alle Pin Change
Interrupts nicht wirklich ein Problem, und auch nicht die auch hier
fehlende Priotisierung.
Zur Datenübertragung:
Bei meiner Hausüberwachung überträgt ein Arduino Ethernet minütlich
Sensor- und Heizkesseldaten über HTTP an ein CGI-Script bei meinem
Webhosting-Provider (DF). Als minimale Sicherheit überprüft das
CGI-Script einen ebenfalls übermittelten Hashcode, der aus dem
Datenpaket und einem Passwort gebildet wird. Das CGI-Script fügt die
Daten dann in eine MySQL-Datenbank ein.
LG, Sebastian
Hallo Sebastian,
Danke für Deine ausführliche Antwort.
>> Der Beck SC13 zieht laut Datenblatt 1,3W.
Ich gebe zu, ich habe die Stromaufnahme noch nicht gemessen, hole ich
morgen Früh nach. Was aber auffällt ist, dass das Teil so heiß wird,
dass man es nur kurz berühren kann. Daher meine Einschätzung.
Mit der Stromaufnahme des B-Modells kann ich leben.
Einen Atmega hatte ich zusätzlich zum R.Pi in Erwägung gezogen, um die
Zeitmessung der S0-Impulse damit zu realisieren und den R.Pi damit zu
entlasten. Irgendwie gefällt mir die Idee immer mehr, vor allem in
Verbindung mit I2C als Kommunikation (Atmega als Slave). Diese
Teilkomponente kann man dann auch recht einfach testen und in Betrieb
nehmen.
Das mit der Länge der S0-Impulse ist klar - und ja, es geht um eine
möglichst hohe (Betonung auf "möglichst" - aber eben nicht mehr als das)
Genauigkeit. Ich habe bei der Berechnung mal max. 10kW zu Grunde gelegt.
Ein Wert, der sicherlich nur selten zustande kommt (Weihnachten,
Backofen, Herd, Waschmaschine und Trockner im Keller sowie Spülmaschine
in der Küche läuft, Licht überall an, so kommen ganz schnell 10kW
zusammen). Bei 1000Imp/kWh kommt man bei 10kW auf eine Zeit zw. zwei
Impulsen von 360ms. Bei einer Ungenauigkeit von 1ms, also einem
gemessenem Wert von (in diesem Beispiel) von 361ms würde ein Wert von
9972W, also 28W zu wenig angezeigt. Bei einem Wert von bspw. 300W wäre
der resultierende Fehler (bei 1ms Messungenauigkeit) deutlich kleiner
(angezeigt: 299,975W). Ich denke, das wäre so in etwa die Genauigkeit
die ich mind. anstrebe.
Man lernt nie aus, das Projekt "Panalyzer - a RaspberryPi based Logic
Analyzer" (Dein Link) ist wirklich bemerkenswert und eine tolle Quelle
für neue Ideen (Softwaretechnisch).
Mit dem Arduino Mega2560 + Ethernet Board habe ich auch ganz gute
Erfahrung gemacht. Es gab auch eine Zeit, in der ich darüber nachdachte,
die aktuelle Konstellation damit zu ersetzten. Ich hätte aber wie
bereits beschrieben ganz gern eine möglichst lückenlose Aufzeichnung
(vor allem der Temperatur sowie zukünftig auch einiger Wetter-Daten).
Hin und wieder muss der Host mal angehalten werden (oder tut es vlt.
auch mal von selbst). Kommt selten vor aber eine "Lücke" in der
Datenbank ärgert mich immer. Vielleicht ist man ja auch mal ein paar
Tage nicht da und kann nicht sofort reagieren. Dafür dann die SQLite
"on-board", das bekommt man mit dem Atmega so nicht hin (natürlich kann
man sich etwas einfallen lassen und auf eine SD-Karte schreiben, die
SQLite ist in dem Moment einfach die "Luxusvariante").
Hallo Enrico,
bei Raspi und Atmega über I2C solltest du beachten: "There is a bug in
the [Raspi] I2C master that it does not support clock stretching ..."
(http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=13771). Bei
meiner Kommunikation zwischen Raspi und Attiny
(http://tilda.googlecode.com) habe ich die I2C-Clockrate auf dem Raspi
ich glaube auf 94kHz reduziert um den Fehler zu umgehen.
LG, Sebastian
Hallo Sebastian,
komme erst jetzt dazu zu Antworten, Sorry.
Also, bitte streiche aus meinem ersten Posting die Bemerkung mit der
Stromaufnahme, erst messen, dann beschweren :) Die kpl. Platine zieht
gerade einmal 150mA, also knapp 3,5W. Der Raspi ist da keine
Verbesserung. Aber, die anderen Punkte (hauptsächlich die Seite der
Entwicklungsumgebung sowie der Entwicklung selbst - Compiler etc.)
stehen eher im Vordergrund.
Vielen Dank für den wertvollen Tipp bezüglich des Clock-Stretching. Ohne
diesen hätte ich sicherlich Stundenlang versucht, den Fehler zu finden.
Und obwohl ich prinzipiell I2C-"Sattelfest" :) bin, weiß ich wie ein
solcher Fehler einen zur Verzweiflung bringen kann. Ich habe ein paar
C++ Klassen geschrieben die nahtlos "ineinander" greifen (bzw.
aufeinander aufbauen) - von der Möglichkeit eigene I2C Hardware zu
verwenden (Bit-Bang oder am PC via RS232), über das Versenden/Empfangen
(inkl. Timing) bis hin zu einzelnen Klassen (die auf die darunter
liegenden aufbauen) für alle von mir verwendeten I2C-Devices. Je nach
Verfügbarkeit von Hardware- bzw. Software-Support im Host setzten meine
Klassen weiter oben oder unten an. So kann ich erst einmal die
Kommunikation mit dem Slave am PC codieren und testen und wenn diese
Lösung dann tut was sie soll auf den Ziel-Host portieren. Mit dem o.g.
Problem hätte ich dann wohl einige Fragezeichen über meinem Kopf gehabt
... und u.U. zu einem Bit-Bang-Mode übergegangen. Speed ist in meinem
Fall glaube ich nicht so sehr das Thema, die 4 S0-Kanäle á 16Bit und
einer geschätzten Impulsfrequenz von max. 2Hz würden mir auch die 50kHz
I2C-Frequenz reichen.
Enrico F. schrieb:> Ist-Zustand: Beck SC13 ...> Das Ganze läuft seit ca. 5 Jahren 24/7 mit relativ wenig Problemen.> Avisierter Zustand: Ein Raspi
Ich hätte da so meine Bedenken, ob ein Raspberry Pi so lange problemlos
läuft. Als Schwachstellen hätte ich die SD-Karte und das Netzteil im
Visier.
Schau Dir mal www.udoo.org an. Da hast Du Linux/Android und Arduino auf
einem Board.
Der Pi ist zwarganz nett, aber auf billig designt, z.B
unterdimensionierte Treiber und Spannungsregler. Für die Lehre oder als
Spielerei ist das egal, für den Dauerbetrieb nicht. Und Ethernet über
USB wäre mir auch nicht zuverlässig genug.
Alternative: BeagleBoneBlack. Die Hardware macht mir auch einen
zuverlässigeren Eindruck, und Du hast viel mehrIOs als beim Pi.
fchk
Frank K. schrieb:> Schau Dir mal www.udoo.org an. Da hast Du Linux/Android und> Arduino auf> einem Board.>> Der Pi ist zwarganz nett, aber auf billig designt, z.B> unterdimensionierte Treiber und Spannungsregler. Für die Lehre oder als> Spielerei ist das egal, für den Dauerbetrieb nicht. Und Ethernet über> USB wäre mir auch nicht zuverlässig genug.>> Alternative: BeagleBoneBlack. Die Hardware macht mir auch einen> zuverlässigeren Eindruck, und Du hast viel mehrIOs als beim Pi.>> fchk
Vielen Dank für den Tip! Das Board auf www.udoo.org sieht
vielversprechend aus. Preislich auch völlig ok bzw. im Rahmen. Die von
Dir angesprochenen Punkte bzgl. Spannungsregler und USB2Eth. gefallen
mir auch nicht sonderlich. Ich würde dem Rasp dennoch (bis auf
Wiederruf, das muss dann einfach die Zeit zeigen) den Vorzug geben.
Warum? Ganz großer Punkt für den Rasp ist die Verfügbarkeit und die
Verkaufszahlen. Hohe Verkaufszahlen sind (mein Empfinden/Meinung) ein
Motor für Weiterentwicklung und Verbesserungen (hoffentlich kompatibel).
Sehr gut gefällt mir BeagleBoneBlack. Ich bekomme seit einiger Zeit
immer wieder Werbemails von TI (hatte mal beruflich mit denen zu tun),
eine Dieser bewarb den BeagleBoneBlack. Cooles Teil. Ich denke ich werde
mir einen besorgen und mal "unter die Lupe" nehmen :) Das wäre für mich
tatsächlich eine Alternative zum Raspi, weil ich hier bzgl. der o.g.
Punkte mind. das gleich Potential sehe (scheinbar auch noch gepusht von
TI). Mit der gleichen CPU habe ich auch ein "AM335x Starter Kit" von TI
hier "rum-liegen" ... allerdings ist mir dieses Teil schon zu "bulky".
Beste Grüße!
Alexander Schmidt schrieb:> Enrico F. schrieb:>> Ist-Zustand: Beck SC13 ...>> Das Ganze läuft seit ca. 5 Jahren 24/7 mit relativ wenig Problemen.>> Avisierter Zustand: Ein Raspi> Ich hätte da so meine Bedenken, ob ein Raspberry Pi so lange problemlos> läuft. Als Schwachstellen hätte ich die SD-Karte und das Netzteil im> Visier.
Hallo Alex,
das mit der SD-Karte macht mir auch "zu schaffen". Allerdings "leiden"
alle solchen "Einplatinen-Computerchen" :) unter diesem Problem. Wie ich
oben schon schrieb, soll der Rasp ja (auch wegen der Bedenken in
Hinblick auf die SD-Card) seine Daten an eine remote MySQL-DB abliefern
und nur im Notfall die Daten lokal speichern. Swapping etc. ausschalten,
alle unnötigen Schreibzugriffe auf die SD unterbinden, evtl SSD via USB
(durch die Größe des SSD und dem ausgefeilten wear-leveling hat diese
dann schon ein beachtliches Leben - in hinblick auf die zu erwartenden
Datenmengen), das sind so meine Ideen um dem Problem zu begegnen.
Beim Netzteil, hmm, wie könnte man es besser machen? Gibt es besser
Komponenten als die drei Spannungsregler auf dem Board? Wenn ja welche?
Und, wie hoch sind die Drei tatsächlich ausgelastet? Wie schon in einem
meiner vorherigen Postings, die Zeit wird zeigen wie gut oder schlecht
das alles für Langzeitanwendungen bemessen ist.
Beste Grüße.
Enrico F. schrieb:> und dem Rasp.Pi> traue ich auch einen langen live-cycle zu.
Ich nicht. Der Broadcom-SOC ist ein Consumerprodukt, und ich glaube
nicht, dass der mehr als 5 Jahre verfügbar ist (und er hat ja schon
einige Jahre rum). Er wurde gewählt, weil er billig ist, und das ist
typisch für den Comsumermarkt: Billig, in kurzer Zeit hohe Stückzahlen
verkaufen, und in einem Jahr kommt wieder was neues. Das siehst Du ja
auch an der PC-Welt. Versuch mal ein, für ein zwei Jahre altes Mainboard
einen exakten Ersatz in der gleichen Revision nachzubestellen. Du wirst
Dich wundern, wie kurz die Produktzyklen hier sind.
Wenn Du Langzeitverfügbarkeit willst, bist Du hier komplett falsch.
Automotive verlangt 15 Jahre Verfügbarkeit, die Industrie 10 Jahre.
Freescale garantiert z.B., dass der iMX.53 bis 2026 verfügbar ist. DAS
sind doch ganz andere Dimensionen, oder?
Weiterer Grund: Der Broadcom-Chip ist nur ein ARM11, also eigentlich
schon veraltet. Aktuell sind die ARM Cortex Architekturen, also hier
A8/A9.
fchk
Ich habe mir den AVR-NetIO
http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html
auf die Hutschiene in meinen Zählerkasten eingebaut. Der hat 4 A/D
Wandler auf seine Schraubleiste herausgeführt, mit denen polle ich die
S0 Ausgänge meiner Stromzähler. Der netio hat ne Ethernet Schnittstelle,
die geht in ein PLC modem im Schaltschrank. Ganze Setup kost nix,
braucht wenig Strom, kann aber nichts speichern. Deswegen lasse ich den
ATMega auf dem netio alle drei Minuten ne email mit den Daten schreiben,
dann brauche ich keinen 'Server' ständig laufen haben und Google zahlt
den Strom für die Speicherung der Daten. Mit nem script hole ich die
Daten gesammelt ab und pflücke sie für die Datenbank auseinander.
Läuft seit Jahren super.
Cheers
Detlef
Detlef _a schrieb:> Ich habe mir den AVR-NetIO>> http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetz...>> auf die Hutschiene in meinen Zählerkasten eingebaut. Der hat 4 A/D> Wandler auf seine Schraubleiste herausgeführt, mit denen polle ich die> S0 Ausgänge meiner Stromzähler. Der netio hat ne Ethernet Schnittstelle,> die geht in ein PLC modem im Schaltschrank. Ganze Setup kost nix,> braucht wenig Strom, kann aber nichts speichern. Deswegen lasse ich den> ATMega auf dem netio alle drei Minuten ne email mit den Daten schreiben,> dann brauche ich keinen 'Server' ständig laufen haben und Google zahlt> den Strom für die Speicherung der Daten. Mit nem script hole ich die> Daten gesammelt ab und pflücke sie für die Datenbank auseinander.>> Läuft seit Jahren super.> Cheers> Detlef
Das Teil kenne ich auch :) Beinahe hätte ich gesagt "warum einfach
wenn's auch umständlich geht" (alle drei Minuten ne email, pflücke sie
für die Datenbank auseinander) ... aber ich sag's nicht :)
Auf die Art und Weise ist aber leider keine Momentanverbrauchsanzeige
möglich ... und auf die möchte ich nicht verzichten :)
Beste Grüße.
Frank K. schrieb:> Enrico F. schrieb:>> und dem Rasp.Pi>> traue ich auch einen langen live-cycle zu.>> Ich nicht. Der Broadcom-SOC ist ein Consumerprodukt, und ich glaube> nicht, dass der mehr als 5 Jahre verfügbar ist (und er hat ja schon> einige Jahre rum).
Deine Argument klingen plausibel und "erschlagend" - es ist aber weniger
der Chip (CPU) selbst auf den ich setzte, sondern vielmehr das Format
(Größe, Pinheader usw.). Falls Rasp irgendwann die CPU gegen eine andere
austauscht aber die Sourcen von meiner Software 1:1 portierbar sind, bin
ich zufrieden.
Enrico F. schrieb:> Deine Argument klingen plausibel und "erschlagend" - es ist aber weniger> der Chip (CPU) selbst auf den ich setzte, sondern vielmehr das Format> (Größe, Pinheader usw.).
Das wird dann Dein geringstes Problem sein, denn das lässt sich per
Adapterkabel innerhalb weniger Minuten anpassen.
fchk
Ein Rasperry wäre mir für den Kleckerkram schon zu viel. Nimm ein Board
mit einem Cortex M3 was Ethernet und SD-Karte an Bord hat. So was oder
was ähnliches:
http://www.embeddedartists.com/products/app/aoa_kit.php
Die Messdaten werden erst mal auf SD geschrieben und parallel versucht
eine weitere Task die Daten an den Server los zu werden. Da kann auch
mal länger die Verbindung fehlen. Das ganze braucht dann deutlich
weniger Strom und ist zuverlässiger. Mir wird immer warm ums Herz wenn
man liest wieviele Zeilen Quellcode (Linux + Treiber + ...) verballert
werden um so eine relativ triviale Aufgabe zu lösen. Nicht das man die
selber schreiben müßte, aber in 10Mil. Zeilen Quellcoden stecken
garantiert mehr Fehler als in 10000.
Hallo Enrico,
ich komme vermutlich etwas spät, aber ich bin einen ähnlichen Weg
gegangen wie Du das willst (oder wolltest). Ich verarbeite die
S0-Impulse auf einem Arduino und sende sie per USB an einen Logger (bei
mir eine Fritz!Box mit der Software FHEM). Mir war es auch wichtig,
keine Signale durch Polling zu verlieren. Als ich die Implementierung
dann fertig hatte, habe ich aber gesehen, dass die Signaldauer meiner
Zähler ca. 70ms beträgt - das ist eine Menge Zeit. Heute sehe ich
deshalb keine Vorteile mehr für die Interrupt-getriebene Verarbeitung -
die Software dafür habe ich trotzdem geschrieben. Die ganze Geschichte
und den Arduino-Code findest Du bei Bedarf unter
http://forum.fhem.de/index.php?t=msg&th=13155
