HTTP Actor / Sensor für CBPi Projektvorstellung

Benutzeravatar
Innuendo
Posting Klettermax
Posting Klettermax
Beiträge: 198
Registriert: Freitag 2. März 2018, 09:43

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

#301

Beitrag von Innuendo » Freitag 13. September 2019, 10:35

Das OLED Display benutzt D1 an SDL Oled Dispay und D2 an SDA Oled Display. Ist in der config das Display aktiviert, werden die PINS als belegt markiert. ONE_WIRE_BUS an D3 ist, sobald ein Temperatursensor genutzt wird, ebenfalls belegt.

Code: Alles auswählen

    pins_used[DISPLAY_PINS[0]] = true;
    pins_used[DISPLAY_PINS[1]] = true;
    ....
    pins_used[ONE_WIRE_BUS] = true;
Diese Anschlüsse stehen dann in den Dropdown Auswahlfeldern für Aktoren oder IDS2 nicht mehr zur Verfügung. Bevor ein Jumper die Verkabelung von Display, Aktor oder IDS ändert, muss die Konfiguration angepasst werden.

Die GGM Induktionsplatte IDS2 braucht 3 GPIOs:
  • Induction relais (WHITE)
  • Induction command channel (YELLOW)
  • Induction backchannel (BLUE)
Meine IDS2 funktioniert an D5, D6 und D7 problemlos.
Innu

Benutzeravatar
Innuendo
Posting Klettermax
Posting Klettermax
Beiträge: 198
Registriert: Freitag 2. März 2018, 09:43

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

#302

Beitrag von Innuendo » Freitag 13. September 2019, 11:23

Hallöchen,

ich habe ein paar Erweiterungen eingebaut, die mir bislang gefehlt haben. Ich hoffe, es findet jemand interessant und hat etwas Zeit beim Testen zu helfen. In meiner Umgebung funktioniert das schon ganz wunderprächtig. Die Version liegt nicht auf github. Ich würde ein ZIP mit FW und SPIFFS zusenden oder hier anhängen.
  • 1. Änderung: Sensoren und Aktoren haben nun die Eigenschaft bei Fehler schaltbar (on/off)
    Ein zusätzlicher Temperatursensor (benutze ich gerne und der Sensor wechselt beim Brauen auch zw. Induktion und Nachguss hin und her) muss keinen Fehlerevent auslösen. Bei den Aktoren fand ich es nicht gut gelöst, dass zB ein Rührwerk abgeschaltet wird, wenn ein Fehlerevent aufgetreten ist. Nun kann man je Sensor und je Aktor entscheiden, ob das Gerät etwas tun oder so einfach so bleiben soll, wie es ist.
  • 2. Änderung: die Induktionsplatte kann nun auf einen PowerLevel im Fehlerevent gesetzt werden. In der bisherigen Version konnte ich im Fehlerevent die IDS nur ausschalten. Jetzt nutze ich einen Wert zw. 10-20% (P1), um die Temperatur im Kessel zu halten. Im WebIf trägt man den PowerLevel im Fehlerfall ein: 0% (=ausschalten P0) bis 99%. Wenn der Wert 100% eingetragen wird, bleibt die IDS2 im Fehlerevent unverändert.
  • 3. Änderung: Nach einem Ausfall von WLAN oder MQTT wird nun ein auto reconnect durchgeführt. Dafür braucht man gar nix machen.
  • 4. Änderung: wenn ein Fehlerevent behoben ist (zB WLAN oder MQTT ist wieder verbunden), passierte bislang gar nix. Das hilft nicht. Neu ist, dass die Werte für Aktoren und IDS auf den ursprünglichen Wert (also die Werte vor dem Fehlerevent) zurückgesetzt werden.
Beispiel:
IDS steht auf 100%, der Aktor Rührwerk und der Aktor Tauchsieder sind eingeschaltet. Wenn das Fehlerevent MQTT Verbíndung ist unterbrochen eintritt, kann man nun die IDS auf 15% setzen, den Tauchsieder ausschalten und das Rührwerk unverändert belassen. Sobald der MQTT Server wieder erreichbar ist, verbindet sich das ESP automatisch und setzt die IDS zurück auf 100% und schaltet den Tauchsieder ein.

Zusätzlich habe ich das Lesen und Schreiben der config Datei überarbeitet. Da habe ich die wenigen Ressourcen vom ESP8266 verschwendet. Die DEBUG Ausgabe ist gesprächiger geworden.

Innu

Benutzeravatar
Innuendo
Posting Klettermax
Posting Klettermax
Beiträge: 198
Registriert: Freitag 2. März 2018, 09:43

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

#303

Beitrag von Innuendo » Samstag 14. September 2019, 08:09

In Bildern schaut das so aus ...
Über Events simuliere ein Brauen mit Störungen. Hier als Beispiel wird Testsensor1 ausgesteckt und etwas später wieder angeschlossen. Zunächst schalte ich (virtuell) alle Aktoren und die IDS2 ein. Der Debug Output im seriellen Monitor im ersten Bild kommt erst gleich ins Spiel.
event_ok.jpg
Das grüne E bei Testsensor1 und Actor1SW zeigt an, dass für diese beiden Geräte Events aktiviert sind. Das schwarze E bei Testsensor2 und Actor2NS zeigt an, dass für diese Geräte Events deaktiviert sind.
Ein paar loops weiter simuliere ich einen Fehler beim Sensor Testsensor1: ausgesteckt, Sensor im Fehlerstatus. (Bitte die 23°C ignorieren. Der Sensor existiert und hängt an meinem Test D1 mini. Statt ausstecken schalte ich den Sensorstatus true/false)
event_error.jpg
Ein paar loops weiter wird Testsensor1 wieder eingesteckt. Das ist dann die Situation in Bild 1 mit dem Debug Output. Aktoren und Induktion werden auf die ursprünglichen Werte zurückgesetzt.
Der Testsensor2 ist nicht angeschlossen und steht im Error Status. Weil dieser Sensor für Events deaktiviert ist, bleibt sein Status unberücksichtigt. Gleiches gilt für Actor2NS. Im simulierten Fall Sensorfehler bleibt Aktor2NS unverändert.
Ein rotes E zeigt an, dass das Gerät für Events aktiviert ist und dass ein Event eingetreten ist. Der Testsensor1 schaltet in diesem Test alle paar loops zwischen an mit grünem E und aus mit rotem E hin und her. Gleiches macht die IDS2: ON, 15% und P1 in rot und ON, 100% und P5 in grün. Der Actor1SW genauso mit ON:75% und Off

Reihenfolge Event Auslöser:
WLAN (wenn aktiviert -> Wartezeit -> Event)
-> MQTT (wenn aktiviert und WLAN ok -> Wartezeit -> Event)
--> Sensoren (wenn aktiviert und WLAN ok und MQTT ok -> Wartezeit -> Event)

Aktoren und IDS2 sind Event-Empfänger und keine Auslöser. Wenn WLAN,MQTT und alle Sensoren nicht für Events aktiviert sind, ist das Event handling deaktiviert.

Wartezeiten:
WLAN:
meine Fritzbox braucht rund 90 Sekunden für einen Neustart. Daher habe ich bei mir 120s als Wartezeit WLAN Event im WebIf eingetragen (24 * max 5 Versuche = 120) Weil sich CBPi und D1 mini automatisch reconnecten, tritt kein Event ein, wenn WLAN innerhalb von 120 Sekunden wieder verfügbar ist.
Event WLAN: nach 120 Sekunden schalte ich die IDS2 auf 15% Leistung und den Actor1SW aus.

MQTT:
mein raspi benötigt keine Minute für einen Neustart. Ich habe hier ebenfalls 120sek konfiguriert. Das Event ist natürlich das gleiche, wie bei WLAN, weil Events am Aktor/IDS2 konfiguriert werden. Sobald der MQTT Server verfügbar ist, macht das D1 mini automatisch ein MQTT subscribe für alle Aktoren und IDS2 (Sensoren sind nur MQTT Sender).

Sensoren:
Die Wartezeit vor einem Event bei einem Sensorfehler ist abhängig von dem Abfrage-Intervall. Wenn von Sensoren bspw. alle 5 Sekunden Daten abgefragt werden, muss die Wartezeit zum einen natürlich größer als 5 Sekunden sein, zum anderen ist ein vielfaches von 5 Sekunden plausibel.
Außerdem ist die Wartezeit von der Brauanlage abhängig und hier speziell, wie groß der Temperaturunterschied innerhalb eines Intervalls ist. Wenn mein Kessel in einer Minute bei 100% Leistung +2°C erreicht, wird die Event Wartezeit kleiner sein, als bei einer Anlage, die für +2 Grad 5 Minuten benötigt. Die Events nach der Wartezeit sind wieder identisch mit denen bei WLAN und MQTT.
Innu

Benutzeravatar
Innuendo
Posting Klettermax
Posting Klettermax
Beiträge: 198
Registriert: Freitag 2. März 2018, 09:43

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

#304

Beitrag von Innuendo » Montag 16. September 2019, 22:13

Version 1.040 liegt auf git.
Tests beim Brauen: Sensoren abgezogen, CBPi neu gestartet und WLAN abgeschaltet :thumbup

Natürlich kann 1.040 weiterhin komplett ohne irgendwelche (automatischen) Events genutzt werden. Läuft auch besser und schneller als 1.03x
Meine Zentrale (Induktion hat ein eigenes D1)
IMG_3631.jpg
IMG_3631.jpg (92.99 KiB) 77 mal betrachtet
Hier steuer ich primär den Nachguss und einen Tauchsieder beim Boiling. Zusätzlich wird eine Pumpe für den Läuter-Grant gesteuert, die ich am End auch zum Pumpen in den Fermenter nutze.

Benutzeravatar
DerDerDasBierBraut
Posting Freak
Posting Freak
Beiträge: 5614
Registriert: Donnerstag 2. Juni 2016, 20:51
Wohnort: Ahrensburg

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

#305

Beitrag von DerDerDasBierBraut » Montag 16. September 2019, 22:49

Danke. Wird morgen installiert und Ende September mit gebraut :thumbup
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens

Interesse an Flüssighefen ... ?

Antworten