Von der SPS Heizungssteuerung … zum Raspi digital/analog/Relais/RTC/1wire Board

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallöchen,

    Am Anfang war … nein, sie stand und zwar im Keller. Eine knapp 30 Jahre alte Gasheizung.

    Gesamtanlage.jpg
    Bild 1: Ein uralter Gaskessel, den es zu regeln galt.


    Die Motivation
    Nachdem der Kessel auch im Sommer dauerhaft unter 70°C gehalten werden mußte, damit die Boilerpumpe ungefähr 3x am Tag den Warmwasserspeicher aufladen konnte, waren die Bereitstellungsverluste (5m³ Gas/Tag) enorm. Eine Regelung gab es eigentlich (fast) nicht. Allein einen Kesselthermostat, der diesen auf konstanter Temperatur hielt und einen Boilerthermostat, der die Boilerpumpe einschaltete, wenn das warme Wasser zu kühl war.
    Der Zustand war natürlich dauerhaft nicht zu ertragen und musste abgestellt werden.
    Obgleich ich den Lötkolben nicht als Gegner betrachte, versuche ich Funktionalität doch eher in Software zu gießen und auf käufliche Hardware-Komponenten auszuweichen. Vom Raspi hatte ich vor 3 Jahren auch schon gehört, entschloss mich aber aufgrund der bei SPS’en vorhandenen Schaltschrankfähigkeit zur Sie**ns Klein-SPS „Log*“. Ganz um’s Löten kam ich dennoch nicht, da ich irgendwie 4 Temperaturen messen musste (Außen-, Kessel-, Rücklauf- und Boilertemperatur). Die Sensor-addons für NTC/PTC waren mir allerdings erheblich zu teuer, weswegen ich auf den MCP9701A auswich, der bereits im Temperaturbereich von -10°C bis über 100°C vorverstärkte Signale zwischen 0,4-2,5V erzeugt. Nachdem die SPS mehrere 0..10V Eingänge besaß, spreizte ich das Signal nochmals per OP um den Faktor 4 auf. Das war’s dann aber auch schon. Nach weiteren Optimierungen, auf die ich hier nicht im Einzelnen weiter eingehen will, konnte ich meinen Gasverbrauch drastisch senken und liege jetzt in der gleichen Größenordnung wie die baugleichen Häuser der Nachbarschaft mit ihren Brennwertthermen.

    Jetzt kam der Spieltrieb. Die Heizung sollte in’s Internet – nur wie? Die SPS hatte zwar einen Netzwerkanschluß – nur gab’s keine Protokollbeschreibung dafür. Vermutlich würde ich heute den Kompromiß eingehen und fertige Bibliotheken wie libnodave einsetzen, damals jedoch packte mich der Ehrgeiz, das 2. von der SPS gesprochene Protokoll zu analysieren. Wireshark war zu dieser Zeit mein bester Kumpel… So entstand LogoLib – die Bibliothek zur Kommunikation für die Sie**ns Log*. Jetzt fehlte nur noch ein Gerät, welches das Bindeglied zwischen SPS und Webserver herstellt. Zunächst fiel mir mein Router ein – der ist ja schließlich sowieso immer eingeschaltet (frisst also eh immer Strom) und hat einen Internetzugang. Zu blöd nur, dass es für mein Modell kein openWRT o.ä. gibt. Hm, der Ald* NAS-Server läuft ja auch immer… Also ARM Cross Compiler installiert und einen Proxy geschrieben, welcher zwischen SPS und Webserver vermittelt. Nachdem der Ald*-NAS bereits über einen Apache Webserver verfügt, sollte es eigentlich möglich sein, eigene php Scripte zu installieren und den Ofen per Web zu steuern. Aber da hatte ich die Rechnung ohne die Sicherheitsbeauftragten Ald*s gemacht. Der NAS bootet aus read only gemounteten Images, welche während des Bootens auch noch entpackt werden. Eigene php-Scripte lassen sich somit nicht erstellen (lediglich statische Web-Seiten). Eine Änderung der Images war mir zu heikel, weswegen ich auf einen freien Web-Hoster für mein Frontend umstieg und der SPS-Proxy lediglich als Daemon zwischen SPS und Web-Hoster vermittelt. Um nun nicht dauerhaften Traffic zwischen SPS und Web-Hoster zu erzeugen, ist das Ganze ereignisgetrieben, initiiert durch einen Aufruf der Webseite.

    Fazit
    Das ursprüngliche Problem der hohen Heizkosten war durch die SPS in den Griff zu bekommen. Mittels Ald* NAS-Server und Web-Hoster ließ sich der Weg in’s Internet erschließen. Klingt doch eigentlich nicht schlecht aber…

    Kritik
    Die Lösung ist so unendlich unelegant! Zwar ist die Heizungsregelung per SPS und analogen Temperatursensoren unumstritten robust. Ich hatte nie einen Ausfall innerhalb der 3 Jahre und Remanenz von Betriebszuständen nach einem Stromausfall ist etwas, was man wirklich zu schätzen lernt, wenn man ab und zu mal den FI-Schalter ausknipst, weil man noch an seinem Häuschen Kabel zieht. Dennoch, eine Kurvendiskussion zur Rücklauftemperatur implementiere ich lieber in C++ als in Flip-Flops, Zählern, Timern und Komperatoren. Auch bin ich mittlerweile an der Funktionsbausteingrenze der SPS angelangt. Ein weiterer Ausbau (Warmwasser-Zirkulationsoptimierung) würde schwierig werden …
    Fällt mir mal der NAS-Server aus, dann wird es zwar nicht kalt, das Gateway zum Internet ist dann aber weg. Genauso verhält es sich mit der Verfügbarkeit des Web-Hosters. Ist der nicht erreichbar – nun ja, auch dann sieht man nicht viel (mit Ausnahme der Werte, welche das SPS Programm in dessen Display schreibt).

    Komplexität reduzieren und vereinfachen
    … so hieß das neue Motto, und der Raspberry Pi kam mir über den Weg gelaufen. Tatsächlich hatte ich auch den Arduino in die nähere Wahl gezogen, jedoch aus Performanzgründen wieder verworfen. Nachdem ich mir zum Ziel gesetzt hatte, ein offenes System zu schaffen (also eines welches nicht nur eine Heizung steuern kann, sondern auch weitere Aufgaben hinsichtlich eine Hausautomation übernehmen kann) schien mir der Raspberry Pi der geeignete Kandidat zu sein (wenngleich es auch noch viele andere gute Systeme auf dem Markt gibt). Mit einem TCP/IP Stack und der Vielfalt an Software entfallen damit die Umwege über NAS-Server und Web-Hoster.
    Alles was dem Raspberry Pi fehlte, war eine Hardware, welche alle IO-Anforderungen vereint.

    Das Pflichtenheft zur Hardware
    Analoge Temperatursensoren als zuverlässige Datenquelle einer hardwarenahen Regelung von Brenner und Pumpen müssen möglich sein. 1wire ist ideal, wenn es um die gelegentliche Messung von Temperaturen an entfernten Stellen geht (Zimmertemperaturen). Beides ist also ein „Muß“ und kann nicht durch eine der anderen Technologien ersetzt werden. Das potentialfreie Schalten von Lasten muß ebenfalls möglich sein. Gleichzeitig bedarf es der Erfassung digitaler Signale von Tastern und Schaltern.
    Robustheit ist ein weiterer wesentlicher Aspekt. D.h. Eingänge müssen einen gewissen Schutz gegenüber EMV Störungen (egal, ob aus dem 50Hz Netz oder einem getakteten Netzteil stammend) aufweisen. Eine Echtzeituhr ist unumgänglich und bestehende Hardware (Relaisplatinen, 1wire Verkabelung) sollte nach Möglichkeit wiederverwendet werden können. Kommt es doch mal zu einem ESD Schaden, so sollte man nicht zum Lötkolben greifen müssen und in der Lage sein, Probleme schnell und für wenig Geld beheben zu können.
    Die Lösung muß einfach ausfallen, damit sie jedermann aufbauen, verwenden und warten kann. Zudem sollte sie erweiterbar sein, falls man später mal mehrere Ein- und Ausgänge benötigt.
    Das beinahe Wichtigste zuletzt. Die Lösung muß in einem vernünftigen Gehäuse wohnen! Idealerweise etwas, was man im Schaltschrank „versenken“ kann.

    Hubo – das Hutschienen IO Board für den Raspberry Pi war geboren
    So also entstand Hubo, eine GPIO Hardwareerweiterung zum Raspberry Pi mit den folgenden Eckdaten:
    • 8 x analoge Eingänge per MCP3208 und 12 Bit Auflösung (entspricht 0,61mV)
    • 8 x digitale Eingänge per MCP23017
    • 4 x digitale Relaisausgänge 5A 250VAC
    • 3 (4) x Open Collector Ausgänge per ULN2803; 500mA/50V (bei Verzicht auf den 1wire Ausgang stehen 4 Open Collector Ausgänge zur Verfügung)
    • 1 x 1wire Ausgang
    • 1 x Steckoption für Real Time Clock Modul DS3231
    • 1 x Steckoption für 8 Kanal Lastrelaiskarte 10A, 250VAC
    • 1 x I2C Ausgang zur Kaskadierung weiterer Module
    • Das Ganze in einem Formfaktor, dass es in ein Hutschienengehäuse paßt

    Dank eines herausgeführten I2C-Buses erlaubt sich die Erweiterung des Digital IO’s auf bis zu 4 Module. Damit sind 32 digitale Eingänge, 16 Relaisausgänge und 16 Transistorausgänge mit offenem Kollektor möglich. Hat man bereits eine eigene Lastrelaisplatine (siehe Bild 2), will jedoch kein zweite Board kaskadieren, so besitzt Hubo eine Steckoption für eine solche 8 Kanal Lastrelaisplatine.
    Lastrelaisoption.jpg
    Bild 2: Hubo mit Lastrelaisoption

    Hubo enthält ebenfalls einen Steckplatz für eine batteriegepufferte Echtzeituhr (Bild 3), welche es für unter 2€ in der ‚Bucht’ zu kaufen gibt. Damit verliert Hubo seine Zeit auch nach einem Stromausfall nicht. Ein „muß“ für Lösungen, welche sich nicht auf permanentes Netzwerk mit Zeitsynchronisation verlassen können.
    Hubo_mit_DS3231_Option.jpg
    Bild 3: Hubo mit DS3231 RTC Option

    Das Board verfügt über einen 1wire Anschluß, womit sich u.a. auch Temperatursensoren des Typs DS18x20 direkt anschließen lassen. Hard- und Software wurde sowohl mit dem Raspberry Pi B, als auch dem B+ Modell getestet und sind zu diesen Modellen kompatibel. Das B+ Modell kann zudem im Deckel des Hutschienengehäuses integriert (Bild 4 rechts) werden. Die Notwendigkeit eines separaten Gehäuses für den Raspberry Pi entfällt hiermit.
    Hutschienengehaeuse_geoeffnet.jpg
    Bild 4: Hubo und Raspberry Pi B+ im geöffneten Hutschienengehäuse

    Software
    Da Hubo auf der vielfach beschriebenen Hardware der beiden Chips MCP3208 und MCP23017 aufsetzt, ist es recht verständlich, dass bestehende Software entweder unmittelbar oder mit geringfügigen Anpassungen (z.B. Wahl des Chip-Select für den SPI Chip bzw. I2C-Adresse für den IO Expander) mit Hubo funktioniert.
    Da ich persönlich eine relativ zeit-deterministische Lösung benötigte, um auch meine Heizungkomponenten regeln zu können, entwickelte ich eine, die Hardware etwas weiter abstrahierende Bibliothek in C++. Eine Interpreterspache wie Python schien mir hier nicht das richtige Konzept. Das Grundproblem welches ich lösen wollte war es, eine weitgehend CPU-lastunabhängige Möglichkeit des Hardwarezugriffs vorzuhalten. Das geht nur, wenn es eine einzige Instanz gibt, welche sich um Hardwarezugriffe kümmert und „Clients“ lediglich auf gepufferte Werte zugreifen. Das Problem wurde in ähnlicher Art bereits hier im Forum diskutiert. Zumindest für den multithreaded Betrieb innerhalb eines Prozesses ist das mit der Hubo C++-Lib gelungen. Zudem sollen Ereignisse von Änderungen am digitalen Input berichten, um einen pollenden Betrieb zu vermeiden.

    Die in Doxygen dokumentierte Hubo-C++Lib kann >> hier << heruntergeladen werden.


    Ausblick
    Wie geht es jetzt weiter? Das ist eine gute Frage. Mittlerweile bin ich so weit, dass ich einige Bastelbeutel zusammengestellt habe, welche sich in etwa einer Stunde Lötarbeit zu einem Hubo zusammenlöten lassen.

    Den Bastelbeutel, die Doku (Schaltplan, Löt- und Inbetriebnahmeanleitung, Tips und Tricks zur Verwendung bestehender Hardware, Hubo-C++Lib, Installscript…) einschließlich eines bereits vorinstallierten Raspbian Images habe ich mal in die ‚Bucht’ eingestellt.

    Bastelbeutel in der 'Bucht':
    http://www.ebay.de/itm/Hubo-Raspb…=item2809e38cc2


    Als nächstes stünde wohl ein weiterer Ausbau der C++Lib an – da hätte ich schon noch die eine oder andere Idee. Auch ein spezielles Relais- bzw. I2C-1wire Board wären denkbar als Slave zum Hubo. Elektronische Lastrelais…

    Bin über jeden Vorschlag zur Verbesserung, neue Ideen usw. sehr dankbar!

    Schöne Grüße

    Schnasseldag


    Nachtrag: Der Support aktueller Hard- und Software erfolgt über meiner >> Homepage << .

  • Von der SPS Heizungssteuerung … zum Raspi digital/analog/Relais/RTC/1wire Board? Schau mal ob du hier fündig wirst!

  • Hallöchen,

    aufgrund einiger Rückfragen in der "Bucht" habe ich nun mehrere unterschiedliche Pakete zusammengestellt.

    "Hubo" - die altbekannte IO-Erweiterung (1wire, analoge und digitale Eingänge, digitale Ausgänge, I2C, diverse Steckoptionen...)
    "Hubo-Digital" - im Prinzip wie "Hubo" jedoch ohne den analogen Teil (den kann man später nachrüsten)

    Vielleicht hilft es ja, das eine oder andere Projekt hardwareseitig anzuschieben.

    Schöne Grüße

    schnasseldag

  • Hallo motom001,

    Es hat auch einiges an Zeit und Mühe gekostet z.B. die Störstrahlung des Hutschienennetzteils von den Eingängen des AD-Wandlers wegzubekommen - und das unter der Maßgabe, daß möglichst wenige unterschiedliche Teile zum Einsatz kommen sollten, damit keine Verwechselungsgefahr beim Zusammenlöten besteht.
    Ähnlich verhält es sich mit dem Schaltstrom der Relais, welcher bei Unachtsamkeit des Layouts zum Driften des analogen Ground führen könnte. So kann ich 12 Relais parallel schalten, ohne daß am AD-Wandler etwas zu spüren ist. Dann kommt noch die Einhaltung von Kriechstrecken dazu...

    Noch etwas - auf mehrfache Nachfrage hin, habe ich die Dokumentation und Beispiele noch um Python (lesen und schreiben der digitalen Ein- und Ausgänge sowie lesen des AD-Wandlers) erweitert. Wer sich das Ganze anschauen will, kann hier downloaden:
    - Die komplette Doku inkl. Schaltplan, Aufbauanleitung, Beispielen, Lib... gibt's hier.
    - Ein vorinstalliertes Image gibt's hier.
    - Für den eiligen Leser hier noch der Link zur Dokumentation der Lib, inkl. der Python-Beispiele.

    So, was könnte man denn noch so einbauen. Über Weihnachten muß ich ja schließlich etwas zu tun haben :) Also immer raus mit den Ideen.

    Schöne Grüße

    schnasseldag

  • "Hubo - das Hutschienen IO-board für den Raspi", wie es weiterging...

    Das Projekt "Hubo" hat sich in der Zwischenzeit ein wenig weiterentwickelt. Auf Anregung der "Hubo-Hardwareliebhaber" gibt es eine erweiterte C++ Library, welche die alte Bibliothek um die folgenden Funktionen erweitert:

    Kaskadierung
    Werden bis zu 4 Hubos mittels I2C-Bus hintereinandergeschaltet, so können die einzelnen Digitalkanäle unter Angabe der Modulnummer genauso angesprochen werden, wie die 8 digitalen Ein- und Ausgänge des Mastermodules. Zudem kann die Abtastzeit der kaskadierten Module über einen Taktteiler eingestellt werden.

    Schnelle Abtastung der analogen Kanäle
    Um analoge Signale mit bis zu 8kHz abtasten zu können (z.B. zur Erfassung von Hüllkurven), wurde eine Low-Level Routine eingeführt, die im Zyklentakt des Hintergrundthreads verwendet werden kann, um direkt auf den SPI-Bus zuzugreifen. Buskollisionen werden so vermieden.

    Beispiele
    Neben den bereits existierenden Beispielen zum Zugriff auf den digitalen und analogen IO Bereich und den 1wire-Bus, hat sich die Anzahl der Beispielprogramme mit mehr als zwei Dutzend annähernd verdoppelt. Insbesondere die Kaskadierung wird ausführlich erklärt.

    Namensraum "HuboLib"
    Zur besseren Trennung von Applikations- und Bibliothekscode wurde der namespace "HuboLib" eingeführt.

    Erweiterung der Hardwarebeschreibung
    Die Hardwaredokumentation wurde auf Anregung der Benutzer um viele Punkte erweitert. Diese umfassen das Powermanagement, die Referenzspannungsbildung, den Anschluß digitaler Sensoren sowie die Beschaltung der DS18x20 1wire-Sensoren. An vielen Stellen finden sich neben der Beschreibung auch Beispielbeschaltungen. Ebenso erweitert ist die Inbetriebnahmeanleitung.

    Kompatibilität
    Aufgrund der Einführung des Namensraumes "HuboLib" ist eine geringfügige Änderung des Quellcodes um eben jene Angabe notwendig. Die Beispiele sind selbstverständlich alle nachgezogen.
    Ansonsten sind die Schnittstellen kompatibel zum alten "Hubo" sowie dessen Hardwarenachfolger "Hubo 2". Die Bibliothek wurde mit den Modellen "B", "B+" und "2B" getestet.


    Downloads
    Die Hubo-Bibliothek, einschließlich der Hubo-Hardwaredokumentation, Beispiele, Install-Script können über die Links heruntergeladen werden.

    Ein vollständig vorbereitetes Raspbian Wheezy-Image zum sofortigen Test der Beispiele und zur Eigenentwicklung gibt's >>> hier zum Download <<<.

    Die reine Beschreibung der C++-Bibliothek kann man hier einsehen.
    Hubo-Library

    Fragen jedweder Art bitte hier im Forum oder wenn's schneller gehen soll (ich bin nicht jeden Tag im Forum unterwegs :no_sad:) unter schnasseldag@web.de.

    Schöne Ostern wünscht...

    schnasseldag


  • Hallo Schnasseldag,
    ich möchte erst mal sehr(!) für die Entwicklung des hubo danken. :bravo2:

    Ich habe den hubo nun zwar nicht für unsere Heizung eingesetzt dafür regelt der Raspi zusammen mit dem hubo eine 30 kW Wasser-Turbine bei Bremen.
    Für die Regelung (Drehzahl, Temperaturerfassung, Wasserstand, Energiefluss, Schalt- Ein- und Ausgänge) biete sich hier genau die richtige Kombination.
    Ich habe das ganz mit einem OpenVPN- Kanal gekoppelt, so dass ich mittlerweile die Regelung der Turbin via Internet verfolgen kann, und das ganz auch sehr sicher.
    Das Projekt ist jetzt gerade so richtig am Laufen. Sehr hilfreich war der Support, gerade in der Filterung der miesen Drehzahl-Impulse.
    Soviel erstmal als kurzen Dank.
    :danke_ATDE:
    Super Entwicklung das ganze. Mir persönlich gefällt auch sehr, das in der Ursprungsversion noch alle ICś gesockelt waren und ich so über viele Jahre eine wartungsfreundliche Situation habe.
    Ich habe das ganz auf dem Raspi zusammen mit Raspbian Wheezy laufen lassen. Seit neuestem habe ich nun ein Image mit "Jessie" am laufen. Gerade bin ich noch beim Einrichten von "SystemD". Hier sollen ja die autostart-Möglichkeiten einfacher umzusetzen sein. Mal sehen.

    Gibt es jemanden der schon hier im Forum Erfahrungen mit SystemD hat? Ich will es einsetzen a) um Daten auf einfache weise zu loggen und b) um bei mir via OpenVPN genau selben Display-Inhalt zu sehen, wie der Betreiber vor Ort.

    Gibt hier jemanden der da Erfahrungen hat?
    Danke schon mal!

    :danke_ATDE:

    P.S.: Zur Veranschaulichung noch ein Foto der gesamten Turbinensteuerung. Oben rechts der Raspi + Hubo (im Hutschienengehäuse) + Slave-Erweiterung (offen)
    Das abgesetzte Tableau ist passend zur "alten" Wasserturbine rubust und Secondhand mäßig. Mittlerweile sind auch Blindstrom-Kompensation für den Generator und ein Funkmodem für den OpenVPN Zugang installiert. Wer fragen zum Projekt hat: Fragt nur,.... :thumbs1:

    Einmal editiert, zuletzt von Wasserratte (23. September 2015 um 07:33)

  • Hallo schnasseldag,
    ich bin gerade auf diesen Beitrag "Heizungssteuerung mit Raspi" gestoßen und bin von deinem Erweiterungsmodul begeistert. :bravo2: Ich würde gerne so ein bis zwei käuflich erwerben. Die sind aber in der Bucht oder bei Robin nicht zu bekommen. Am liebsten als Komplettset. Ich würde aber auch mit der Hubo-Barebone Platine vorlieb nehmen.
    Würde mich freuen eine Nachricht von Dir zu bekommen. :^^:

    wolfi999999

  • Hallo zusammen,

    Bin auch über HUBO gestolpert und würde das ganze auch gerne mal ausprobieren.
    Leider sind unter den genannten Seiten keine Artikel mehr gelistet. Ist es trotzdem noch möglich einen HUBO zu erwerben?

    Viele Grüße, HerrnBert

  • Hallöchen,

    nachdem ich im letzten Jahr hin und wieder diese oder ähnliche Anfragen erhalten hatte und es mittlerweile auch ein paar schöne Projekte gibt, so habe ich mich unlängst dazu entschlossen, den Hubo nun in "homöopathischen" Dosen gewerblich anzubieten. Wenngleich dieser Weg einem hierzulande von Behördenseite nicht gerade leicht gemacht wird, so denke ich, daß es dem einen oder anderen Projekt vielleicht einen gewissen hardwareseitigen Entwicklungsschub geben könnte.

    Auch wenn unten ein eBay-Kontakt aufgeführt ist, so bin ich für direkte Anfragen offen. Der Hubo ist für viele Belange sicher eine brauchbare Plattform, er muß es aber nicht immer sein. Um hier die richtige Entscheidung zu treffen, ist es daher immer hilfreich, das Projekt kurz geschildert zu bekommen.

    An der Dokumentation habe ich ein wenig weitergeschrieben.
    Die Hubo C++-Library habe ich zwar auch schon weiterentwickelt, allerdings habe ich noch Ideen, was man zusätzlich einbauen könnte und ein vernünftiger Test soll ja auch nicht fehlen. Das dauert also noch ein wenig. Derweil behält also mein o.g. Link weiter seine Gültigkeit.

    Schöne Grüße

    schnasseldag


    Nachtrag: Der Support aktueller Hard- und Software erfolgt über meiner >> Homepage << .

  • Hey Leute,

    falls jemand interessiert ist:

    Hier habe ich eine Alarmanlage auf Basis 4 kaskadierter Hubo 's aufgebaut, läuft seit Monaten stabil!

    joejo
    13. Oktober 2015 um 09:37

    Fragen&Anregungen gerne jederzeit...

    Schöne Grüße
    Jo

  • Hallo Schnasseldag,

    danke nochmal für die Erfindung des Hubos.
    Der neueste fristet nun sein Dasein bei uns in der Wohnung. :lol:

    Ich habe am Wochenende selbigen mal flux zur Temperatur-Regelung für meinen Brotteig genutzt.
    Zum Gehen lassen des Teiges benötige ich ca. 28,6 Grad. (so genau ist der Sensor zwar nicht justiert, ist aber hier nicht wichtig)
    Bisher habe ich die Temperatur nicht regeln können, da ich nur eine 25 W Glüh(!)birne als Heizung im Ofen hatte.

    Nun habe selbst ich C-Neuling mit Deinen Beispiel-Programmen in 30 Min. die Regelung programmiert. (Hardware Aufbau war schon fertig)
    OK. So sieht das zur Zeit bei mir aus:

    im schönen Hutschienen-Gehäuse: Raspi + Hubo
    Zugriff auf den Hubo per PC über Den Router.
    in einer separaten Box habe ich: 1 x 230 V Eingang, 1x Ausgang zu meiner Lampe, 1x Leitung mit 2 Adern zum Digital-Output vom Hubo.
    (Vorsicht zum Nachbauen und für die Kücke rate ich nur einen 24 V Trafo mit passender Lampe zu steuern, das werde ich auch noch umrüsten)

    Am Hubo habe ich einen MCP-Temperatur Sensor auf den Analog-Eingang des Hubo gelegt. Wie in der Anleitung empfohlen.
    Dank Beispielprogramm zur Abfrage der Temperatur konnte ich dann schnell ein paar Zeilen programmieren. Mittelwert-Bildung und alles habe ich mir gespart. Ich habe eine Hysterese drin. Das heißt

    AN: wenn Temp. < 26 °C,
    AUS: wenn Temp > 28.9 °C

    Und schon ist die Temperaturregelung fertig. Es funktioniert.
    Als nächstes plane ich dann nur noch auf dem Raspi einen Web-Client einzurichten, damit meine Frau bequem das ganze per Web-Brower steuern kann.... Doch da brauche ich wohl noch ein wenig Muße.

    :shy:
    Wasserratte


  • Gibts auch eine Bibliothek für C?

    Jein. Meine Hubo-Lib verwendet intern C++. Nach außen hin werden namespaces eingesetzt. Wolltest Du mit C arbeiten, so müßtest Du die einzelnen Funktionen noch mal wrappen. Du kannst aber geradesogut auch wiringPi oder irgendeine andere C-Lib hernehmen um die Hardware anzusprechen. Klar, den Komfort der HuboLib (Zyklentaktüberwachung, Multithreadingschutz, Vermeidung von Buskollisionen...) hast Du dann natürlich nicht mehr... =(

  • Der Hubo kommt in’s Teeny-Alter…

    Zeit ist vergangen und der Hubo ist mit Ihr gewachsen. Mittlerweile gibt es neben dem oben vorgestellten Modell zwei Weiterentwicklungen. Diese erweitern den Hubo z.B. um:

    • Varistoroption zum Schutz der Relaiskontakte
    • Option für ein 433MHz Sendemodul (die kleinen Dinger aus China)
    • Überspannungsschutz für den 1Wire-Bus


    Auch eine (teilvorbestückte) SMD Variante gibt es mittlerweile. Diese verfügt über einen getrennten AGND und eine interne Spannungsüberwachung.

    Die Hubo-Lib ist ebenfalls stark erweitert. So enthält die Version 2.1.1 neben dem direkten Zugriff auf die GPIO’s auch noch viele neue Beispiele (im Sourcecode), unter anderem auch eines, welches die Verwendung von Hubo und Lib zum Schalten von Funksteckdosen zeigt.

    Aber was erzähl’ ich viel rum…

    Schaut Euch den Vergleich der Hardwareversionen oder die Lib einfach an. Vom Vertrieb in der Bucht bin ich übrigens weg, das geht jetzt auch auf direktem Weg über den Shop in der Homepage. Im Downloadbereich findet sich auch ein fertiges Image, um sofort loslegen zu können.

    Schöne Grüße

    schnasseldag


    PS:


    ... so bin ich für direkte Anfragen offen. Der Hubo ist für viele Belange sicher eine brauchbare Plattform, er muß es aber nicht immer sein. Um hier die richtige Entscheidung zu treffen, ist es daher immer hilfreich, das Projekt kurz geschildert zu bekommen.

    Das gilt natürlich weiterhin! Meldet Euch also, wenn Ihr Fragen habt.

  • In diesem Thread hatte ich bereits einige Daten dargestellt, welche mittels des Hubo AD-Wandlers im o.g. "Turbinenprojekt" gesammelt wurden. Es ging dabei vornehmlich um die Genauigkeit und Auflösung bei der analogen Messung des Drehzahlsignales und Einfluß/Auswirkung eingestreuten 50Hz Netzbrummens.

    Anbei die Bilder von Meßsignal und dessen fouriertransformierten Spektrum.

    Die Störungen lagen bei +-3Digit (bei 2,5V und 12 Bit = +-1,8mV) und einer Primärfrequenz von 49,2Hz (numerischer Wert - entspricht real 50Hz). Für das vorliegende Projekt war das zwar unerheblich, zeigt aber recht schön, welche Genauigkeiten mit dem Hubo im Schaltschrank zu erzielen sind. Anbei noch die vollständige Meßreihe zum "selberspielen".

    Hubo AnalogSample_12.05.2015-FFT-Auswertung.xlsm.zip

    Schöne Grüße

    schnasseldag

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!