• Du musst dich registrieren, bevor du Beiträge verfassen kannst. Klicke auf Jetzt registrieren!, um den Registrierungsprozess zu starten. Registrierte User surfen werbefrei, können Suchen durchführen und sehen die volle Darstellung des Forums mit vielen anderen Unterforen!!!

smarter openAger: Speck, dry Aged, Salami etc.

G

Gast-N9LA9h

Guest
Ahoi!

Ich bin gerade an einem kleinen Bastelprojekt beschäftigt - eine eigene, "smarte" Reifekammer.

Es gibt hier schon das eine oder andere Projekt in dieser Richtung, aber ich möchte bei der Architektur und eingesetzte Hardware/Protokolle einen anderen Weg gehen.

Der Fokus liegt auf Robustheit und einfachem Handling:
  • headless: keine Raspis, keine anfälligen SD-Karten, keine "Betriebsysteme" die man updaten müsste
  • robust: MQTT als bewährtes IOT Nachrichtenprotokoll mit entsprechendem QOS
  • ausfallssicher (ich streichle doch nicht wochenlang das Fleisch um es dann wegen eines kurzen Stromausfalls vergammeln zu lassen *g*)
  • Cloud und Handyanbindung, aber auch offline verwendbar
  • Sicherheit: MQTT via SSL/TLS
  • einfachstes Ändern der "Programme" (Reifetabellen) per Drag&Drop ohne Programmierkenntnisse
  • smart: SmartHome-tauglich (MQTT, openHab etc.) -
  • leicht erweiterbar: wenn jemand z.b. Wasserzeichen oder Mondphase in das Reifeprogramm aufnehmen möchte - naja jedem das seine aber einfachst möglich
  • einfaches Dashboarding
  • einfaches Teilen von Reifeprogrammen ("social")
  • low budget und einfach nachbaubar


Daher würde ich gerne die Gelegenheit hier nutzen und eure Erfahrungen und kreativen Ideen hören: Was erwartet ihr von so einer Reifekammer und wie könnte man das Ding noch besser gestalten? Was ist euch wichtig?


dashboard-1-e1519461690119.png


v2-1.jpg


v2-2.jpg


v2-3.jpg


v2-4.jpg


24-02-2018 23-26-19.jpg
 

Anhänge

  • dashboard-1-e1519461690119.png
    dashboard-1-e1519461690119.png
    612,6 KB · Aufrufe: 2.019
  • v2-1.jpg
    v2-1.jpg
    160,5 KB · Aufrufe: 1.898
  • v2-2.jpg
    v2-2.jpg
    119,7 KB · Aufrufe: 1.820
  • v2-3.jpg
    v2-3.jpg
    147,2 KB · Aufrufe: 1.947
  • v2-4.jpg
    v2-4.jpg
    114,5 KB · Aufrufe: 1.809
  • 24-02-2018 23-26-19.jpg
    24-02-2018 23-26-19.jpg
    102,2 KB · Aufrufe: 1.826
Hallo, ich baue zwar keinen Reifeschrank sondern einen Brutschrank für Hühner aber egal, da kommt bei beiden was zu Essen raus. :wiegeil:
Das mit dem Raspi habe ich auch recht schnell verworfen, wegen der SD-Karten. Obwol, der 3er Raspi kann auch über das Netzwerk booten, hab ich aber noch nicht probiert.
Mittlerweile bin ich beim ESP8266 NodeMcu angekommen. Der hat eigentlich alles was ich brauche.
Ich stelle mir das so vor:
Der ESP8266 holt sich alle paar minuten seine Sollwerte für Temperatur, Luftfeuchte und Wenden von einem Server. (NAS oder Web)
Über die GPIO's schalte ich, über ein 8-Kanal SSR, die Komponenten wie Heizung, Lüfter usw.
Weiterhin werden die gemessenen Daten an den Server geschickt, und dort grafisch ausgegeben.
Das OLED-Display aus dem Video hab ich auch schon am laufen, das soll dann direkt an den Schrank als Infodisplay.
Hier ein erster test auf meiner Webseite. (Klick mich)
Die Kamera ist zwar offline, aber der ESP8266 sendet noch die aktuelle Temperatur. (Saukalt)
Zur Zeit, mache ich die Grafiken mit GoogleChart, wie hast du die hübschen Anzeigen gemacht? Die gefallen mir sehr gut.

Gruß
Andreas
 
Hi! Ich hab den großen Bruder ESP32 in Beschlag für das Projekt... nicht zuletzt wegen des vorhandenen NVRam für das sichere "Backup" der Sollwerte.
Die Steuerung der Relais erfolgt durch die Logik AM ESP32 - die Sollwerte kommen vom Controller der über NodeJS/Node-Red realisiert wurde.
Im Moment warte ich noch auf ein paar Sensoren - das chinesische Neujahr hat mir einen Strich durch die Rechnung gemacht :)

Ehm - wie "wendest" du die Eier per ESP?
 
Ehm - wie "wendest" du die Eier per ESP?

Das macht auch der ESP. An der Wendehorde ist ein Motor 230V 1U/Min, den lasse ich einfach ein paar Sekunden laufen.

Ich hab den großen Bruder ESP32 in Beschlag für das Projekt... nicht zuletzt wegen des vorhandenen NVRam für das sichere "Backup" der Sollwerte.

Den muss ich mir mal anschauen. Ist der NVRam ein Speicher welcher nach "Stromausfall" noch Daten hat? So wie beim ATMaga?
Wie sieht es da mit Treiber aus zum programmieren? (Windows oder Linux)
Geht das auch über die Arduino-IDE?
Bin kein Profi, aber ich bastele schon seit ca. 10 Jahren mit Microcontrollern. Der ESP und die Arduino-IDE ist noch relativ neu für mich. C ist auch noch neu für mich. Ich babe die ganze Zeit mit Bascom programmiert. Basic finde ich bis jetzt noch einfacher als C.
 
Achja, mit der Befeuchtung mit Ultraschallvernebler kann ich nur abraten. Die sind nicht sehr robust. Auch nicht wenn sie mit Destiliertem Wasser betrieben werden. Hab ich schon getestet.
Das beste ist immernoch ein Behälter mit Wasser, und darin eine Heizung. (Meine Meinung)
 
Das mit Ultraschall ist ein guter Tipp - danke! Die Steuerung ist ja so flexibel ausgelegt, dass es egal ist, was dran hängt - dh. ich kann auch was vom Klimatechniker dranhängen wenns nicht klappt :)

Zu deinen Fragen: Ja, Arduino IDE läuft.
Und ja, der NVRam ist der "non volatile" also nicht flüchtige Ram, den du beschreiben kannst.

Unterscheide zu EEPROM:
  • "NVRAM kann ohne vorangehendes Löschen beschrieben werden.
  • Bei NVRAM ist das Schreiben eines neuen Wertes gleich schnell wie der Lesevorgang. Es müssen keine Programmiersequenzen und zusätzliche Wartezyklen beim Beschreiben eingehalten werden.
  • Die Anzahl der Schreibeoperationen ist nicht begrenzt und NVRAMs sind von der Speicherstruktur her normalerweise unsegmentiert organisiert."
-> https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html
 
Coole Idee :ola:
Da bleibe ich bei

Edit:

Ich werde ein weinkühlschrank modifizieren :
IMG_20180227_141555.jpg
IMG-20180225-WA0024.jpeg
IMG-20180225-WA0022.jpeg


Verwendest du auch den Kompressor und den internen Lüfter??
 

Anhänge

  • IMG_20180227_141555.jpg
    IMG_20180227_141555.jpg
    489,1 KB · Aufrufe: 1.684
  • IMG-20180225-WA0024.jpeg
    IMG-20180225-WA0024.jpeg
    223,7 KB · Aufrufe: 1.705
  • IMG-20180225-WA0022.jpeg
    IMG-20180225-WA0022.jpeg
    247,8 KB · Aufrufe: 1.701
Ja, Lüfter und Kompressor werden verwendet. Umluft scheint für das Aging wichtig zu sein wegen der Trocknung der Oberflächen.
Ausserdem haben ja die Umluft / Nofrost Geräte weniger Probleme beim Verdampfer - sprich keine Eisbildung.

Deine Idee mit den LEDs wird ob die todos übernommen... (Wenn, dann eh gleich als RGB Controller).

Persönlich werde ich aber darauf achten, dass der Innenraum so "glatt" wie möglich und gut zu reinigen bleibt...
 
Das ist seeeehr smart - top!!!!
 
naja schaunmermal :) Gibts noch irgendwelche Ideen/Wünsche die es zu berücksichtigen gilt?
 
Ich finde ja beide Ansätze interessant. Ob ich jetzt die GPIOs vom Raspberry oder vom ESP32 steuere sollte jetzt nicht so das Ding sein.
Sprich: ob der Sensor/Aktor Client als Publisher oder Subscriber ein ESP32 oder PI ist, eigentlich egal. Vorteil vom PI: mal schnell ein Image auf SD zu schreiben können die meisten - klar, man könnte von der CT die Lib mit Firmware Update via WLAN nehmen für den ESP, aber wenn es schiefgeht... Spannend wäre es aber, Webserver/Steuerung (incl. Broker) auf einem anderen Gerät laufen zu lassen incl. der Datenbank. Dann ist auf der SD vom PI auch nix mehr los.
Also: was eigentlich geil wäre, sich auf Publish/Subscriber Themen zu einigen. Dann den ganzen Kram Frontend/Backend zentral zu machen (der Broker an sich ist ja trivial). Und inwiefern man dann für die Sensoren/Aktoren getrennt entwickeln muss, also einmal ESP, einmal PI...
Denn das Argument, ESP32 und Verwandte seien robuster für sowas stimmt nicht ganz: denn die Steuern auch nur via GPIOs externe Relais oder lesen Sensoren. Wenn MQTT meldet, dass der Befehl ausgeführt wurde heisst das noch lange nicht, dass das Relais geschaltet hat. Und ob der Subscriber die richtigen Daten hat, weil der Sensor im A***h ist, kann man auch nicht ohne weiteres sicherstellen.
 
Denn das Argument, ESP32 und Verwandte seien robuster für sowas stimmt nicht ganz: denn die Steuern auch nur via GPIOs externe Relais oder lesen Sensoren.

Ich bin bei absolut dir was die Schwäche der Sensoren und Relais angeht... Das versuche ich mit Prüflogiken zu mindern: 2 SHTs mit Abgleich, Validierung zu erwartendem Verhaltens wie zb. beim Lüften etc.

Raspis habe ich etliche im Einsatz wo ich ein grafisches Frontend brauche - aber ich sehe keinen Vorteil von dem ganzen Overhead eines Betriebsystems (auch ein Raspian will gepflegt werden), wenns "nur" darum geht ein paar Schaltungen zu machen :)

Aber selbstverständlich: die Topics sind easy auch von einem Raspi schaltbar... - und wer will kann ja im Modus 99 / Override alles direkt über den Broker machen und die internen Schaltlogiken umgehen: dann ist der ActionNode praktisch ein DumbClient und Jacke wie Hose was für eine Hardware :)
 
Das rennt aktuell auf meinem Server im Netz. Natürlich jederzeit austauschbar gegen einen x-beliebigen Dienst oder wer will auch auf nem Raspi :)

[ActionNode] <---> [Mosquitto] <---> [NodeJS/Node Red]

Also insofern trenne ich genau wie von dir oben angeregt den ActionNode als "Aktorenschalter" und "Sensordatensammler" und den Controller/Frontend/Datenbank, was in der Cloud rennt.

Dazwischen MQTT als Nachrichtenprotokoll.

Würde man einen Raspi zum Schalten nehmen wollen, müsste man "nur" die gleichen Topics verwenden und könnte alles andere übernehmen.

Wobei ich der MCU eine "Grundintelligenz" zur Zielerreichung verpasst habe, damit der Betrieb mit statischen Sollwerten auch offline funktioniert (sowie im Falle eines Netzwerkproblemes).
 
  • Updates / Projektstatus:
    • Umgesetzt
      • ActionNode
        • Basislogik ("Zielstrategie" für Temperatur und Luftfeuchte)
        • Ansteuerung aller Relais
        • Einbindung der Sensoren
          • SHT3x (Temperatur / Luftfeuchte) *
          • DHT11/22 (Temperatur / Luftfeuchte) - testweise
          • BMP180 (Temperatur / Luftdruck) - testweise
          • ACS712 (Stromverbrauch)
          • UV Sensor *
          • CSS811 (Luftqualität) *
          • HX711 Wägzellen (Gewicht)
        • Testmodus mit "emulierten" Sensorenwerten
        • verschiedene Betriebsmodi
          • 0 / manual: statische Zielvorgaben
          • 1-98 /Programme: frei konfigurierbare Agingprogramme
          • 99 / override: keine Logik in der MCU verwenden - alles über den Controller regeln
        • ausfallssicheres Backup der Sollwerte durch NVRAM
        • robuste Wiederherstellung von WLAN/MQTT im Falle eines Problems
        • PWM Drehzahlregelung der Umluft-Lüfter
        • Rudimentäre Selbstkontrolle (Doppelte Sensoren melden Abweichungen sowie zu starke Abweichungen vom erwarteten Verhalten)
        • unterschiedliche ESP32 erfolgreich getestet
        • todo: testen der Logiken
        • todo: RGB-LEDs über MCU steuern
      • Broker
        • Mosquitto installiert
        • sichere Verbindung über MQTTs
        • "Standard"-Topics festgelegt
        • todo: Backups einrichten
      • Controller
        • Programme können erstellt und verändert werden
        • Start / Stop von Programmen
        • komplett frei änderbares Dashboard
        • mobile-tauglich
        • Countdowns
        • der Ager kann zb. auf Facebook, Twitter oder per Email seinen Status posten
        • Webcams werden unterstützt
        • todo: Persistenz / DB Backups einrichten
        • todo: optische Aufarbeitung des prozentuellen Wasserverlustes
        • todo: erweiterte Funktions-Prüfungen
        • todo: Zeitrafferbild
      • "Doing"
        • todo: warten auf Kühlschrank :)
        • todo: Migration vom Breadboard auf PCB
 
Ich war mal ein bisschen Shoppen :
Lufteinlass, Luftauslass Komponenten

IMG-20180309-WA0015.jpeg

Welchen Schwamm und Lüftungsgitter würdest du empfehlen??
 

Anhänge

  • IMG-20180309-WA0015.jpeg
    IMG-20180309-WA0015.jpeg
    290,4 KB · Aufrufe: 1.346
naja schaunmermal :) Gibts noch irgendwelche Ideen/Wünsche die es zu berücksichtigen gilt?

:confused:

jaaa, wenn ihr schon so tolle Projekte plant, umsetzt, baut und hier rein setzt... könntet ihr das bitte bitte nachher vielleicht in einer Version rausbringen, die man auch als nicht- Elektroniker und nicht-Programmierer nachbauen oder sich besorgen kann? Da ich von dem was nach der Einleitung kam, kaum noch etwas verstanden habe, erlaube ich mir als stiller Beobachter ab und zu hier reinzuschauen, in der Hoffnung, dass Du nicht vergisst, was Du am Anfang geschrieben hast:

low budget und einfach nachbaubar

Viel Erfolg!
 
Zurück
Oben Unten