HTTP Actor / Sensor für CBPi Projektvorstellung
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Das Kabel Wemos 3,3V zu Level Shifter LV kann ich mir also sparen?
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Für die Nachwelt:DerDerDasBierBraut hat geschrieben: ↑Dienstag 27. August 2019, 15:46 Das Kabel Wemos 3,3V zu Level Shifter LV kann ich mir also sparen?
Nö! Die 3,3V an LV werden gebraucht. Sonst zieht nur das Relais der IDS2 an und die Platte heizt nicht.
Kleine Erfolgsmeldung am Rande.
Ich habe mir gerade das Wasser für meinen Feierabendkaffee auf der IDS2 gekocht. Gesteuert über die MQTT Box und der CBPi.
Der PID überschwingt bei einem Liter Wasser ein echt heftig. Aber das Teil ist ja auch nicht zum Kaffeekochen da
Danke ihr alle
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Glückwunsch!
Ein weiteres Mitglied des "IDS2-Clubs"
Die Werte, die ich in den Screenshots stehen habe passen ganz gut für meinen 57L-Brewpaganda Topf mit ca. 30L Hauptguss. Ansonsten kannst du in deiner Config ja mal das Autotune laufen lassen
BTW: "Feierabendkaffee" um 22:00....
..
gefällt mir.
Ein weiteres Mitglied des "IDS2-Clubs"
Die Werte, die ich in den Screenshots stehen habe passen ganz gut für meinen 57L-Brewpaganda Topf mit ca. 30L Hauptguss. Ansonsten kannst du in deiner Config ja mal das Autotune laufen lassen
BTW: "Feierabendkaffee" um 22:00....
..
gefällt mir.
Immer eine Handbreit Bier unterm.. äh, ne das ging anders.
Allzeit Gut Sud!
Matthias
Allzeit Gut Sud!
Matthias
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Der Kaffee um 22 Uhr war gut, weil um 2 Uhr bekam ich eine PN mit einem Hinweis auf einen Fehler inklusive Korrektur
Läuft bei Dir die Version nun eigentlich?
Innu
Code: Alles auswählen
TimeChangeRule CEST = {"CEST", Last, Sun, Mar, 2, [b]60[/b]}; //Central European Summer Time
TimeChangeRule CET = {"CET", Last, Sun, Oct, 3, [b]120[/b]}; //Central European Standard Time
Innu
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Jepp. Die Version 1.034 läuft gut.
Drei Sachen würden mir noch einfallen, die ich gerne hätte.
Alle aus der Kategorie "Nice to have". Funktionieren tut ja alles
1.
MQTT Box:
WLAN Reconnect bei Verbindungsverlust (alternativ automatischer Reboot des Wemos).
Vielleicht mit "echtem" Ping aufs Gateway. Sobald nicht erreichbar -> Reconnect
2.
MQTT Box:
Im Display steht "Induktion OK", auch wenn keine IDS angeschlossen ist. Sobald man die IDS2 anklemmt zieht ein Relais in der Kochplatte an. Könnte man das Signal nicht irgendwie auswerten und "Induktion disconnected" anzeigen, wenn das Kabel nicht verbunden ist?
3.
CBPi:
Der CBPi mault nicht rum, wenn die MQTT Box nicht erreichbar ist. Vielleicht gibt es dafür irgendein Heartbeat Signal/Plugin, das regelmäßig nachschaut, ob alle Sensoren und Aktoren noch am Leben sind? So wie Mutti, die alle paar Minuten mal aus dem Fenster schaut, ob alle Kinderchen noch auf dem Spielplatz sind?
Ich habe gestern Abend alles abgebaut und der CBPi schwebt im Tal der Ahnungslosen. Kein Fehlerzustand erkennbar und die letzten Temperaturen werden angezeigt....
Drei Sachen würden mir noch einfallen, die ich gerne hätte.
Alle aus der Kategorie "Nice to have". Funktionieren tut ja alles
1.
MQTT Box:
WLAN Reconnect bei Verbindungsverlust (alternativ automatischer Reboot des Wemos).
Vielleicht mit "echtem" Ping aufs Gateway. Sobald nicht erreichbar -> Reconnect
2.
MQTT Box:
Im Display steht "Induktion OK", auch wenn keine IDS angeschlossen ist. Sobald man die IDS2 anklemmt zieht ein Relais in der Kochplatte an. Könnte man das Signal nicht irgendwie auswerten und "Induktion disconnected" anzeigen, wenn das Kabel nicht verbunden ist?
3.
CBPi:
Der CBPi mault nicht rum, wenn die MQTT Box nicht erreichbar ist. Vielleicht gibt es dafür irgendein Heartbeat Signal/Plugin, das regelmäßig nachschaut, ob alle Sensoren und Aktoren noch am Leben sind? So wie Mutti, die alle paar Minuten mal aus dem Fenster schaut, ob alle Kinderchen noch auf dem Spielplatz sind?
Ich habe gestern Abend alles abgebaut und der CBPi schwebt im Tal der Ahnungslosen. Kein Fehlerzustand erkennbar und die letzten Temperaturen werden angezeigt....
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Bei mir noch nicht, ich werde hoffentlich spätestens Freitag nochmal Ruhe haben, das zu testen.
WLAN Reconnect habe ich bei mir schon implementiert, sobald Innuendos Version bei mir läuft werde ich das da einbauen.DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 08:34 WLAN Reconnect bei Verbindungsverlust (alternativ automatischer Reboot des Wemos).
Vielleicht mit "echtem" Ping aufs Gateway. Sobald nicht erreichbar -> Reconnect
Ja, die "Rückantwort" steht ja schon lange auf meiner "Nice-To-Have-Liste", inklusive Auswertung von Fehlermeldungen der Platte. Vielleicht sollte ich mal wenigstens eine "Rückantwort Light" implementieren.Im Display steht "Induktion OK", auch wenn keine IDS angeschlossen ist. Sobald man die IDS2 anklemmt zieht ein Relais in der Kochplatte an. Könnte man das Signal nicht irgendwie auswerten und "Induktion disconnected" anzeigen, wenn das Kabel nicht verbunden ist?
Ja, das nervt mich auch schon lange. Leider sieht CBPi 3.0 das nicht vor, man kann Sensoren nur einen Wert zuweise und nicht z.B. "Error".Der CBPi mault nicht rum, wenn die MQTT Box nicht erreichbar ist. Vielleicht gibt es dafür irgendein Heartbeat Signal/Plugin, das regelmäßig nachschaut, ob alle Sensoren und Aktoren noch am Leben sind? So wie Mutti, die alle paar Minuten mal aus dem Fenster schaut, ob alle Kinderchen noch auf dem Spielplatz sind?
Ich habe gestern Abend alles abgebaut und der CBPi schwebt im Tal der Ahnungslosen. Kein Fehlerzustand erkennbar und die letzten Temperaturen werden angezeigt....
Seitens der MQTT Box wird im Fall "Error" ja einfach nichts gesendet. Man könnte natürlich den klassischen "-127°"-Wert senden, sobald ein Fehler vorliegt. "0" ginge natürlich auch, aber dann sieht man nicht direkt dass es einen Fehler gibt.
Rückantwort der IDS mit Angabe der Power-Stufe hatte ich ja auch mal drin, über einen Workaround als Sensor. Ist dann bei irgendeiner Version hinten rüber gefallen. Könnte man mal wieder reinnehmen.
Will man, dass der MQTT Sensor seitens CBPi regelmäßig schaut, ob es noch Lebenszeichen gibt, müsste man einen "Background Worker" implementieren. Ehrlich gesagt hatte ich das alles schon überlegt, und dann aber verworfen, weil CBPi 4 ja "in den Startlöchern" steht. Leider ja jetzt schon ne ganze Weile. Die Architektur von CBPi 4 würde eine vernünftige Implementierung wesentlich einfacher machen.
Da ich mir die Arbeit nicht doppelt machen will, würde ich damit ehrlich gesagt gerne warten bis CBPi 4 läuft und es dann da weiter optimieren. Es scheint ja aktuell eine funktionierende Entwicklerversion zu geben.
Immer eine Handbreit Bier unterm.. äh, ne das ging anders.
Allzeit Gut Sud!
Matthias
Allzeit Gut Sud!
Matthias
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Hallo zusammen,
Cool das das Projekt wieder weiter geht und optimiert wird.
Nice to have wäre auch eine email Benachrichtigung falls etwas ausfällt, wäre z.b. bei der Gärführung super die über mehrere Tage geht.
Gruß Denis
Cool das das Projekt wieder weiter geht und optimiert wird.
Nice to have wäre auch eine email Benachrichtigung falls etwas ausfällt, wäre z.b. bei der Gärführung super die über mehrere Tage geht.
Gruß Denis
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Wenn ich helfen kann, sag Bescheid. Ein Klassiker für Libfehler ist die Zeile
#include "icons.h"
Wenn Du VSCode verwendest, muss der absolute Pfad angegeben werden.
Gut zu wissen. Hab zum WLAN Reconnect schon was rausgesucht, aber vlt warte ich mal ab und übertrage es dann ins Eventhandling.
Das wäre super! Return codes von der IDS2 könnte ich sehr gut in das Eventhandling gebrauchen. Dann könnte über Events gesteuert werden, was bei welchem return code gemacht werden soll (IDS2 off, Temperatur halten, reboot device, Buzzer on, etc).Ja, die "Rückantwort" steht ja schon lange auf meiner "Nice-To-Have-Liste", inklusive Auswertung von Fehlermeldungen der Platte. Vielleicht sollte ich mal wenigstens eine "Rückantwort Light" implementieren.
Hast Du ArduinoJSON 6.x auf Deinem Plan? Ich würde es bevorzugen, die alte 5.13.4 loszuwerden, damit User einfach aktuelle Libs auf Ihrem System verwenden können. Wenn ich das json handling auf die aktuelle Lib anpasse, laufen aber unsere beiden Versionen immer weiter auseinander. Und mit unterschiedlichen Libs müssten User zum Testen die Bibliotheken Up/Downgraden. Sehr unschön.
Innu
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Ich denke, auch das wäre über das eventhandling machbar. Dafür müsste ich mir mal auf github sourcen zum Thema EMail senden vom ESP8266 anschauen. Wenn die Firmware damit nicht explosionsartig größer wird, könnte man das einbauen. Wenn das klappt, kann man auch Deine Wunsch daily info vom Fermenter senden realisiert werden, also zB Zeitstempel und Temperatur.nursbeschde hat geschrieben: ↑Mittwoch 28. August 2019, 09:35 Nice to have wäre auch eine email Benachrichtigung falls etwas ausfällt, wäre z.b. bei der Gärführung super die über mehrere Tage geht.
Aber wie schon per PN geschrieben macht das die iSPindel echt super, zuverlässig und bei Ubidots edu sogar mit hübschen Grafiken.
Innu
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Das Problem ist halt folgendes:Innuendo hat geschrieben: ↑Mittwoch 28. August 2019, 09:40 Das wäre super! Return codes von der IDS2 könnte ich sehr gut in das Eventhandling gebrauchen. Dann könnte über Events gesteuert werden, was bei welchem return code gemacht werden soll (IDS2 off, Temperatur halten, reboot device, Buzzer on, etc).
Die Kommunikation zwischen Platte und Bedienung läuft im Mikrosekundenbereich. Für ein "High" werden z.B. 5120 Mikrosekunden = 5,12 millisekunden benötigt.
Aktuell läuft die Arbeit des Arduinos im Loop so ab, dass er immer ununterbrochen(!) erst den Befehl an die Platte absetzt und anschließend die Sensoren etc. auswertet und im nächsten Loop wieder an die Platte funkt, sodass die Befehle nicht zu weit auseinander liegen. Wie lange die Befehle genau auseinanderliegen ist zum Glück zweitrangig, sodass der MC zwischendurch gut was anderes machen kann.
Umgekehrt, also empfangen der Antworten, ist leider nicht so einfach, da hier auch die Signallaufzeiten wichtig sind. Immer nur im Loop abfragen klappt nicht. Ich hatte in der ersten Version auf dem Arduino ohne WLan (Die Version auf dem MEGA2560) den Rückkanal mit Interrupts verbunden und dann immer aufgezeichnet, wann die Interrupts kamen und darüber den Befehl ausgewertet. Das hat auch ganz gut geklappt. Das funktioniert aber leider nicht mit dem WEMOS und der WiFi Lösung, weil der MC dann mit der Auswertung der Interrupts so stark beschäftigt ist, dass er die Weboberfläche / MQTT und sonstige Aufgaben nicht mehr "dazwischen bekommt", deswegen habe ich das erstmal rausgenommen. Hier fehlt mir aktuell noch die Idee, wie das funktionieren kann. Das einzige was mir bislang eingefallen ist, ist ein zweiter MC, der nur die Kommunikation mit der Platte durchführt (ähnlich der MEGA-Version) und über Serielle Schnittstelle die entsprechenden Befehle vom WEMOS bekommt, welcher dann nur die Sensoren/ sonstige Aktoren / Weboberfläche etc erledigt.
Ich weiss ehrlich gesagt gar nicht mehr, worin das Problem bei der 6.X lag. Müsste ich mir erst nochmal ansehen.Hast Du ArduinoJSON 6.x auf Deinem Plan? Ich würde es bevorzugen, die alte 5.13.4 loszuwerden, damit User einfach aktuelle Libs auf Ihrem System verwenden können. Wenn ich das json handling auf die aktuelle Lib anpasse, laufen aber unsere beiden Versionen immer weiter auseinander. Und mit unterschiedlichen Libs müssten User zum Testen die Bibliotheken Up/Downgraden. Sehr unschön.
Immer eine Handbreit Bier unterm.. äh, ne das ging anders.
Allzeit Gut Sud!
Matthias
Allzeit Gut Sud!
Matthias
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Ja das mit dem Zeitstempel und der Dauer ( wie lange ist ein Aktor geschaltet ist) ist nicht so wichtig, damit hätte ich nur leichter einen Überblick gehabt wie lange der Chiller und die Pumpen am Tag laufen. Das kann ich mir auch anders wie z.b. über die Ispindel raus schreiben. Wichtiger ist für mich im falle eines Ausfalls informiert zu werden, wenn ich nicht zu Hause bin.Innuendo hat geschrieben: ↑Mittwoch 28. August 2019, 09:48Ich denke, auch das wäre über das eventhandling machbar. Dafür müsste ich mir mal auf github sourcen zum Thema EMail senden vom ESP8266 anschauen. Wenn die Firmware damit nicht explosionsartig größer wird, könnte man das einbauen. Wenn das klappt, kann man auch Deine Wunsch daily info vom Fermenter senden realisiert werden, also zB Zeitstempel und Temperatur.nursbeschde hat geschrieben: ↑Mittwoch 28. August 2019, 09:35 Nice to have wäre auch eine email Benachrichtigung falls etwas ausfällt, wäre z.b. bei der Gärführung super die über mehrere Tage geht.
Aber wie schon per PN geschrieben macht das die iSPindel echt super, zuverlässig und bei Ubidots edu sogar mit hübschen Grafiken.
Innu
Ansonsten bin ich sehr begeistert was ihr da hingezimmert habt, geniales Tool und unendlich weite Möglichkeiten. Ich werde mir auch am Jahresende eine IDS2 zulegen.
Brauen 4.0
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Schick dir doch einfach aus dem CBPi heraus mit den IFTTT Plugin eine Mail oder lass dich anrufen, wenn ein Actor an- oder ausschaltet, oder schreibe die Events mit IFTTT in eine Google Docs Tabelle.nursbeschde hat geschrieben: ↑Mittwoch 28. August 2019, 10:14 Ja das mit dem Zeitstempel und der Dauer ( wie lange ist ein Aktor geschaltet ist) ist nicht so wichtig, damit hätte ich nur leichter einen Überblick gehabt wie lange der Chiller und die Pumpen am Tag laufen.
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Erster Test WLAN reconnect
Eigentlich wollte ich den Urlaubstag für rasenmähen oder sowas nutzen ...
Innu
Code: Alles auswählen
11:57:26.304 -> Loop: event sensors SEN_UPDATE 5000 lastToggledSen 4094622
11:57:28.247 -> Event WLAN connection lost - reconnecting
11:57:28.282 -> *WM:
11:57:28.282 -> *WM: AutoConnect
11:57:28.282 -> *WM: Connecting as wifi client...
11:57:28.282 -> *WM: Using last saved values, should be faster
11:57:32.582 -> *WM: Connection result:
11:57:32.582 -> *WM: 3
11:57:32.582 -> *WM: IP Address:
11:57:32.582 -> *WM: 172.22.100.6
11:57:32.582 -> Wifi.status: WL_CONNECTED
11:57:33.070 -> Loop: event sensors SEN_UPDATE 5000 lastToggledSen 4099623
Innu
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Ok das hört sich gut an mit der google tabelle, das muss ich mir mal anschauen. Ich möchte nur bei zwei drei Gärführungen die Zeiten der Aktoren mitschreiben um zu sehen wie effizient das System arbeitet.DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 11:05Schick dir doch einfach aus dem CBPi heraus mit den IFTTT Plugin eine Mail oder lass dich anrufen, wenn ein Actor an- oder ausschaltet, oder schreibe die Events mit IFTTT in eine Google Docs Tabelle.nursbeschde hat geschrieben: ↑Mittwoch 28. August 2019, 10:14 Ja das mit dem Zeitstempel und der Dauer ( wie lange ist ein Aktor geschaltet ist) ist nicht so wichtig, damit hätte ich nur leichter einen Überblick gehabt wie lange der Chiller und die Pumpen am Tag laufen.
Gruß Denis
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Was ein Quatsch. Brauen würde ich ja noch einsehen.. Übrigens ist Rasenmähen im Moment gar nicht Sinnvoll, weil längerer Rasen bei der Hitze und Trockenheit viel besser überlebt, nur so am Rande. Falls du mal ein Argument brauchstEigentlich wollte ich den Urlaubstag für rasenmähen oder sowas nutzen ...
Immer eine Handbreit Bier unterm.. äh, ne das ging anders.
Allzeit Gut Sud!
Matthias
Allzeit Gut Sud!
Matthias
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Grober Ablaufnursbeschde hat geschrieben: ↑Mittwoch 28. August 2019, 12:09Ok das hört sich gut an mit der google tabelle, das muss ich mir mal anschauen. Ich möchte nur bei zwei drei Gärführungen die Zeiten der Aktoren mitschreiben um zu sehen wie effizient das System arbeitet.DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 11:05Schick dir doch einfach aus dem CBPi heraus mit den IFTTT Plugin eine Mail oder lass dich anrufen, wenn ein Actor an- oder ausschaltet, oder schreibe die Events mit IFTTT in eine Google Docs Tabelle.nursbeschde hat geschrieben: ↑Mittwoch 28. August 2019, 10:14 Ja das mit dem Zeitstempel und der Dauer ( wie lange ist ein Aktor geschaltet ist) ist nicht so wichtig, damit hätte ich nur leichter einen Überblick gehabt wie lange der Chiller und die Pumpen am Tag laufen.
Gruß Denis
------------------
CBPi:
- Plugin IFTTT Webhook Actor installieren
- Plugin Groups Installieren
IFTTT:
1 Account anlegen (falls nicht schon vorhanden)
2 https://ifttt.com/maker_webhooks >>> auf "Documentation" klicken, um den Webhook Key zu sehen
3 https://ifttt.com/ >>> oben auf das Account Icon klicken >>> auf "Create" klicken
4 "If this (+) then that (+)" >>> auf "this" klicken
5 Webhook raussuchen
6 neuen Webhook für ON erstellen, z.B. chiller_on
7 "If this (+) then that (+)" >>> auf "that" klicken
8 Notification raussuchen oder Google Docs oder Phone Call oder was auch immer, und das "That" nach Belieben einrichten
9 Schritt 3-8 für den Webhook "chiller_off" wiederholen
CBPi:
1. neuen Actor erstellen > Typ "IFTTTWebhookActor" > Name (z.B.) "Chiller_Webhook_Actor"
1.1 "Maker Webhook Key" ist der Key von oben -Punkt 2-
1.2 Off Hook Name = "chiller_off", On Hook Name "chiller_on"
2. neuen Actor erstellen > Typ "Actor Group" > Name (z.B. "Chiller mit Webhook")
2.1 Actor 1: "Dein Kühlschrank Actor"
2.2 Actor 2: "Chiller_Webhook_Actor"
3. deinem Kühlschrank den Actor "Chiller mit Webhook" zuweisen, statt "Dein Kühlschrank Actor"
Keine Garantie auf Vollständigkeit.
Bisher habe ich in IFTTT nur Notifications, Emails und Phone Calls genutzt. Keine Ahnung wie man das Google Docs Ziel konfiguriert, aber das findest du schon raus :-)
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
ich hab es an meine Regierung weitergeleitet
Bzgl. WLAN Error handling:
Code: Alles auswählen
// if (WiFi.status() == WL_NO_SHIELD) DBG_PRINTLN("Wifi Status: WL_NO_SHIELD"); // connection result 255
// else if (WiFi.status() == WL_IDLE_STATUS) DBG_PRINTLN("Wifi Status: WL_IDLE_STATUS"); // connection result 0
// else if (WiFi.status() == WL_NO_SSID_AVAIL) DBG_PRINTLN("Wifi Status: WL_NO_SSID_AVAIL"); // connection result 1
// else if (WiFi.status() == WL_SCAN_COMPLETED) DBG_PRINTLN("Wifi Status: WL_SCAN_COMPLETED"); // connection result 2
// else if (WiFi.status() == WL_CONNECTED) DBG_PRINTLN("Wifi Status: WL_CONNECTED"); // connection result 3
// else if (WiFi.status() == WL_CONNECT_FAILED) DBG_PRINTLN("Wifi Status: WL_CONNECT_FAILED"); // connection result 4
// else if (WiFi.status() == WL_CONNECTION_LOST) DBG_PRINTLN("Wifi Status: WL_CONNECTION_LOST"); // connection result 5
// else if (WiFi.status() == WL_DISCONNECTED) DBG_PRINTLN("Wifi Status: WL_DISCONNECTED"); // connection result 6
Ein gängiger Router (zB FritzBox) braucht ca. 120sek für ein Reboot. Ein fehlgeschlagener WLAN Reconnect sollte nach einer Wartezeit von bspw. 20 Sekunden wiederholt werden. Daraus folgt, dass 6 Versuche für ein reconnect notwendig wären. Andere Vorschläge oder Idee?
Innu
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Die WLAN Statuscodes decken viel ab, aber nicht alles.
Zum Beispiel ist mein WLAN stabil, aber die PowerLAN Verbindung zwischen "AccessPoint Küche" und Router spinnt gelegentlich.
Falls die PowerLAN Verbindung spinnt kann es passieren, dass die WLAN Clients in der Küche mit ihrem Meraki AccessPoint verbunden sind, eine valide IP haben, aber auf Grund der fehlenden PowerLAN Verbindung nicht den Router erreichen. Am Router hängt u.a. auch der CBPi.
else if (WiFi.status() == WL_CONNECTED) && ping.canReachTheRouter() // WLAN i.O.
else if (WiFi.status() == WL_CONNECTED) && !ping.canReachTheRouter() // Mach ALARM!
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Wäre es auch ok wenn wir statt Ping den MQTT Status abfragen? Der MQTT Server liegt ja bei allen auf eine. anderen Device.
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Die Frage ist ja was dann passieren soll.
Solange kein WLAN, kann auch kein MQTT funktionieren -> also WLAN Reconnect.
Solange kein MQTT, können auch keine Befehle empfangen werden -> also MQTT Receonnect
Solange eins von beiden nicht da ist -> alle Aktoren auf Standby (=Aus?)
Solange kein WLAN, kann auch kein MQTT funktionieren -> also WLAN Reconnect.
Solange kein MQTT, können auch keine Befehle empfangen werden -> also MQTT Receonnect
Solange eins von beiden nicht da ist -> alle Aktoren auf Standby (=Aus?)
Immer eine Handbreit Bier unterm.. äh, ne das ging anders.
Allzeit Gut Sud!
Matthias
Allzeit Gut Sud!
Matthias
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Die Antwort auf Deine Frage soll jeder individuell treffen. Das event handling gibt die Möglichkeiten vor. Aktuell nur aus, geplant habe ich noch Temp halten
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 12:40 Bisher habe ich in IFTTT nur Notifications, Emails und Phone Calls genutzt. Keine Ahnung wie man das Google Docs Ziel konfiguriert, aber das findest du schon raus :-)
Das hat mir jetzt doch keine Ruhe gelassen.
Als Ziel ("then That") wählt man Google Sheets aus, verbindet einmalig sein Google Konto, gibt den Ordner, den Dateinamen und die zu speichernden Felder in dem "then That" Fenster ein.
Das Protokoll läuft sofort :-)
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Super, vielen Dank das werde ich zeitnah testen . Ich muss immer wieder feststellen das es noch so viel zu entdecken gibt, ich glaube ich nutze nur einen kleinen Bruchteil des möglichen.DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 18:11DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 12:40 Bisher habe ich in IFTTT nur Notifications, Emails und Phone Calls genutzt. Keine Ahnung wie man das Google Docs Ziel konfiguriert, aber das findest du schon raus :-)
Das hat mir jetzt doch keine Ruhe gelassen.
Als Ziel ("then That") wählt man Google Sheets aus, verbindet einmalig sein Google Konto, gibt den Ordner, den Dateinamen und die zu speichernden Felder in dem "then That" Fenster ein.
Das Protokoll läuft sofort :-)
Unbenannt.JPG
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Das sollte mit einer Bluepill gehen. Die Bluepill steuert die Platte als Gateway zum Wemos. Der Liefert die Daten per RS232 TTL. Ich muss mal eine bestellen und ins Referenzhandbuch schauen ob ich den Code von meiner Regelung übernehmen kann. Hier werden die Daten per Timerinterrupt gesendet und Empfangen über PulsbreitenInterrupt. Die Daten könnten dann per RS232 raus und der Wemos muss nur die RS232 Sache machen.matschie hat geschrieben: ↑Mittwoch 28. August 2019, 10:13Das Problem ist halt folgendes:Innuendo hat geschrieben: ↑Mittwoch 28. August 2019, 09:40 Das wäre super! Return codes von der IDS2 könnte ich sehr gut in das Eventhandling gebrauchen. Dann könnte über Events gesteuert werden, was bei welchem return code gemacht werden soll (IDS2 off, Temperatur halten, reboot device, Buzzer on, etc).
Die Kommunikation zwischen Platte und Bedienung läuft im Mikrosekundenbereich. Für ein "High" werden z.B. 5120 Mikrosekunden = 5,12 millisekunden benötigt.
Aktuell läuft die Arbeit des Arduinos im Loop so ab, dass er immer ununterbrochen(!) erst den Befehl an die Platte absetzt und anschließend die Sensoren etc. auswertet und im nächsten Loop wieder an die Platte funkt, sodass die Befehle nicht zu weit auseinander liegen. Wie lange die Befehle genau auseinanderliegen ist zum Glück zweitrangig, sodass der MC zwischendurch gut was anderes machen kann.
Umgekehrt, also empfangen der Antworten, ist leider nicht so einfach, da hier auch die Signallaufzeiten wichtig sind. Immer nur im Loop abfragen klappt nicht. Ich hatte in der ersten Version auf dem Arduino ohne WLan (Die Version auf dem MEGA2560) den Rückkanal mit Interrupts verbunden und dann immer aufgezeichnet, wann die Interrupts kamen und darüber den Befehl ausgewertet. Das hat auch ganz gut geklappt. Das funktioniert aber leider nicht mit dem WEMOS und der WiFi Lösung, weil der MC dann mit der Auswertung der Interrupts so stark beschäftigt ist, dass er die Weboberfläche / MQTT und sonstige Aufgaben nicht mehr "dazwischen bekommt", deswegen habe ich das erstmal rausgenommen. Hier fehlt mir aktuell noch die Idee, wie das funktionieren kann. Das einzige was mir bislang eingefallen ist, ist ein zweiter MC, der nur die Kommunikation mit der Platte durchführt (ähnlich der MEGA-Version) und über Serielle Schnittstelle die entsprechenden Befehle vom WEMOS bekommt, welcher dann nur die Sensoren/ sonstige Aktoren / Weboberfläche etc erledigt.
Die Bluepill an sich kostet ja 2 - 3 €.
Was ich noch machen muss ist das Doublebuffering für das Empfangen, so das die Daten gemütlich ausgewertet werden können.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Anbei noch zweim Screenshots von der Verarbeitung der Daten für die Platte.
Die 1,28 ms für das Bit laufen per Timer ab der wechsel High/Low wird im TimerIRQ gelöst. Wärend den 1,28 ms wird die Regelung ausgeführt, die Eingängeentprellt usw.
Das Laden der neuen Daten für den Ausgang , welches 2x pro gesendetem Bit erfolgt dauer 16,8 µs. Die Cortex M0+ CPU hat also viel Zeit auch den Rest zu machen. Manchmal braucht es etwas länger wenn ein IRQ höhere Prio kommt. aber alles im <40 µs Bereich.
Das sollte auch mit einer Cortex M0 CPU wie dem STM32F103 alias Bluepill gehen.
Die 27,x V ist nur weil der Tastkopf nicht auf 10x stand. Es ind also 2,7V.
Gruß JackFrost
Die 1,28 ms für das Bit laufen per Timer ab der wechsel High/Low wird im TimerIRQ gelöst. Wärend den 1,28 ms wird die Regelung ausgeführt, die Eingängeentprellt usw.
Das Laden der neuen Daten für den Ausgang , welches 2x pro gesendetem Bit erfolgt dauer 16,8 µs. Die Cortex M0+ CPU hat also viel Zeit auch den Rest zu machen. Manchmal braucht es etwas länger wenn ein IRQ höhere Prio kommt. aber alles im <40 µs Bereich.
Das sollte auch mit einer Cortex M0 CPU wie dem STM32F103 alias Bluepill gehen.
Die 27,x V ist nur weil der Tastkopf nicht auf 10x stand. Es ind also 2,7V.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Das klingt vielversprechend! Damit könnte man die IDS2 ja an jeden x-beliebigen Controller anschließen ohne großen Programmieraufwand... Berichte bitte wie es damit läuft!
BTW a propos laufen: die letzte Version von Innuendo kompiliert endlich!
BTW a propos laufen: die letzte Version von Innuendo kompiliert endlich!
Immer eine Handbreit Bier unterm.. äh, ne das ging anders.
Allzeit Gut Sud!
Matthias
Allzeit Gut Sud!
Matthias
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
puh
ich habe auch eine erste Version mit einem Event handling Fehlerstatus WLAN und MQTT fertig.
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Hier ein paar Infos zur ersten Error handling WLAN/MQTT Version. Wenn einer gute Ideen oder Vorschläge: immer her damit!
Schlusswort: Was ein lange Posting.
Ich hoffe, die lange Beschreibung hilft ein bissl, die Event-Schubserei nachzuvollziehen. Wer darauf keine Lust hat kann sich den ganzen Quatsch (wie das Rasenmähen) sparen und überlegen, was es für Möglichkeiten im Fehlerfall WLAN und MQTT Server gibt.
Die Basis in der MQTTDevice.ino
In der loop werden diese Events bei jedem Durchlauf in die Queue geschrieben, die nach dem First In First Out Prinzip abgearbeitet werden:
In der Eventmanager.ino wird im Eventlistener System in der SWITCH-CASE unter dem tag EM_WLAN und EM_MQTT im Fehlerfall ein Reconnect mit den oben angegebenen maximalen Versuchen und Verzögerung durchgeführt. Wenn der Reconnect erfolglos war, wird StopWLANOnError bzw. StopMQTTOnError auf true gesetzt. Diese beiden bool sind global verfügbar.
Aus den tags EM_WLAN und EM_MQTT wird im Fehlerfall immer das Event EM_WLANER bzw. EM_MQTTER in die Queue geworfen.
In den Tags EM_WLANER und EM_MQTTER findet nun die Fehlerbehandlung statt. Hier ist sicherlich viel mehr möglich, als bislang realisiert.
Wenn der User nun ausgewählt hat, dass bei einem Fehler die Aktoren und/oder die Induktionsplatte gestoppt werden soll, werden die Events EM_ACTER vom Eventlistener Aktoren und EM_INDER vom Eventlistener Induktion in die jeweiligen Queues geschrieben. Diese Events schalten dann die Aktoren bzw. die Induktionsplatte aus.
Die Queues werden in jedem Loop abgearbeitet
Im Gegensatz zum Objekt Induktion hat jeder Aktor eine Eigenschaft Switchable. Ein Heizstab kann oder sollte in viele Events abgeschaltet werden. Ein Rührwerk würde ich persönlich auch ohne WLAN oder MQTT Server lieber weiterdrehen lassen.
Innu
Schlusswort: Was ein lange Posting.
Ich hoffe, die lange Beschreibung hilft ein bissl, die Event-Schubserei nachzuvollziehen. Wer darauf keine Lust hat kann sich den ganzen Quatsch (wie das Rasenmähen) sparen und überlegen, was es für Möglichkeiten im Fehlerfall WLAN und MQTT Server gibt.
Die Basis in der MQTTDevice.ino
Code: Alles auswählen
// WLAN and MQTT reconnect parameters
int retriesWLAN = 1; // Counter WLAN reconnects
int retriesMQTT = 1; // Counter MQTT reconnects
unsigned long mqttconnectlasttry = 0; // Timestamp MQTT
unsigned long wlanconnectlasttry = 0; // Timestamp WLAN
#define maxRetriesWLAN 5
#define maxRetriesMQTT 5
#define WLAN_DELAY 10000 // How long should device wait, before try to reconnect
#define MQTT_DELAY 10000 // How long should device wait, before try to reconnect
bool StopWLANOnError = false; // false := WLAN ok btw. MQTT server available
bool StopMQTTOnError = false; // true := WLAN error btw. MQTT server not available
Code: Alles auswählen
cbpiEventSystem(EM_WLAN); // Check WLAN
cbpiEventSystem(EM_MQTT); // Check MQTT
Aus den tags EM_WLAN und EM_MQTT wird im Fehlerfall immer das Event EM_WLANER bzw. EM_MQTTER in die Queue geworfen.
In den Tags EM_WLANER und EM_MQTTER findet nun die Fehlerbehandlung statt. Hier ist sicherlich viel mehr möglich, als bislang realisiert.
Wenn der User nun ausgewählt hat, dass bei einem Fehler die Aktoren und/oder die Induktionsplatte gestoppt werden soll, werden die Events EM_ACTER vom Eventlistener Aktoren und EM_INDER vom Eventlistener Induktion in die jeweiligen Queues geschrieben. Diese Events schalten dann die Aktoren bzw. die Induktionsplatte aus.
Code: Alles auswählen
if ( StopWLANOnError) // WLAN in error state. configured retries and delay unsuccessful
{
// Stop actors on WLAN error
if (StopActorsOnError)
{
cbpiEventActors(EM_ACTER);
}
// Stop induction on WLAN error
if (StopInductionOnError)
{
cbpiEventActors(EM_INDER);
}
break;
}
Code: Alles auswählen
while (gEM.getNumEventsInQueue()) // Eventmanager process queued events
{
gEM.processEvent();
}
Innu
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Wenn kein IDS2 angeschlossen ist, steht im Display nun "off".DerDerDasBierBraut hat geschrieben: ↑Mittwoch 28. August 2019, 08:34 2.
MQTT Box:
Im Display steht "Induktion OK", auch wenn keine IDS angeschlossen ist. Sobald man die IDS2 anklemmt zieht ein Relais in der Kochplatte an. Könnte man das Signal nicht irgendwie auswerten und "Induktion disconnected" anzeigen, wenn das Kabel nicht verbunden ist?
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Kleiner Nachtrag, um die Funktionen zu testen:
In der setup.ino können diese zwei Zeilen aktiviert werden
Wenn nun Aktoren und Induktion "virtuell" konfiguriert sind, werden diese beim Start "eingeschaltet". Mit dem WebIf und den Debug Ausgaben kann man so ohne viel Mühe testen.
In der setup.ino können diese zwei Zeilen aktiviert werden
Code: Alles auswählen
// Testing only!!!
// cbpiEventActors(EM_ACTTEST); // Switch on all actors
// cbpiEventInduction(EM_INDTEST); // Switch on Induction
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Habt ihr zwischen IDS und Pegelwandler bzw. zwischen Pegelwandler und Wemos irgendetwas elektronisch "entkoppelt", abgesichert oder etwas anderes gezaubert?
Vorgestern hatte ich beide MQTT Boxen zum Testen an der IDS2. Beide liefen einwandfrei.
Heute wieder alles angeschlossen und keine der beiden Boxen bootet. Kein Display, nicht per IP erreichbar, ohne IDS am USB Port keine Debugausgaben usw.
Ich habe schrittweise ein Kabel nach dem Anderen ab- und wieder angelötet, um den Übeltäter zu finden.
Sobald das Kabel "blau" zwischen Wemos und Pegelwandler "LV n" abgelötet ist bootet die MQTT Box wieder normal und ist im Netz erreichbar. Wieder angelötet > wieder tot.
Bei der zweiten MQTT Box habe ich das blaue Kabel auch am Wemos abgelötet >> Box läuft auch wieder.
Wie gesagt. Beide Boxen haben auch mit dem blauen Kabel funktioniert und konnten die IDS steuern. Danach ist mit beiden Boxen nichts weiter passiert, außer, dass ich sie von der IDS abgezogen und weggeräumt habe. Heute hatten beide Boxen exakt das gleiche Fehlerbild.
Bei einer Box habe ich anschließend den Wemos getauscht und ohne Verbindung zur IDS getestet. Der Fehler ist noch da, sobald das blaue Kabel dran ist. Daher würde ich meinen, dass die Pegelwandler auf den "blauen Ports" abgeraucht sind.
Ich glaube nicht an Zufälle . Irgendwelche Ideen wie ich das verhindern kann?
Vorgestern hatte ich beide MQTT Boxen zum Testen an der IDS2. Beide liefen einwandfrei.
Heute wieder alles angeschlossen und keine der beiden Boxen bootet. Kein Display, nicht per IP erreichbar, ohne IDS am USB Port keine Debugausgaben usw.
Ich habe schrittweise ein Kabel nach dem Anderen ab- und wieder angelötet, um den Übeltäter zu finden.
Sobald das Kabel "blau" zwischen Wemos und Pegelwandler "LV n" abgelötet ist bootet die MQTT Box wieder normal und ist im Netz erreichbar. Wieder angelötet > wieder tot.
Bei der zweiten MQTT Box habe ich das blaue Kabel auch am Wemos abgelötet >> Box läuft auch wieder.
Wie gesagt. Beide Boxen haben auch mit dem blauen Kabel funktioniert und konnten die IDS steuern. Danach ist mit beiden Boxen nichts weiter passiert, außer, dass ich sie von der IDS abgezogen und weggeräumt habe. Heute hatten beide Boxen exakt das gleiche Fehlerbild.
Bei einer Box habe ich anschließend den Wemos getauscht und ohne Verbindung zur IDS getestet. Der Fehler ist noch da, sobald das blaue Kabel dran ist. Daher würde ich meinen, dass die Pegelwandler auf den "blauen Ports" abgeraucht sind.
Ich glaube nicht an Zufälle . Irgendwelche Ideen wie ich das verhindern kann?
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Steck mal alles ab und miss an den kaputten Kanal die Flussspannung mit dem Diodentest vom Multimeter in beide Richtungen. von LV zu HV sollte die Bodydiode vom Mosfet leiten, in die andere Richtung sperren.
Ich hab nen Pushpull Puffer genommen und nen Mosfet für das Relais. Ist aber ein Eigenbau und SMD und echt klein.
Zur Not kann ich dir so was bauen, das ätzen würde aber gut dauern, da ich es erst erstellen muss und schauen muss ob ich Basismaterial habe.
Gruß JackFrost
Ich hab nen Pushpull Puffer genommen und nen Mosfet für das Relais. Ist aber ein Eigenbau und SMD und echt klein.
Zur Not kann ich dir so was bauen, das ätzen würde aber gut dauern, da ich es erst erstellen muss und schauen muss ob ich Basismaterial habe.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
+ an HV sperrt, + an LV hat Durchgang
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Miss mal von HV+ zu HV1 bis HV4 den Widerstand der SMD Widerstände. das gleiche für die LV Seite.
Gruß JackFrost
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Die liegen alle zwischen 10,1K und 9,45K. Fünf der Acht bei 9,9K
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Das ganze ist mit abgesteckter IDS oder ?
Wenn du die Box am USB hast zum Debuggen ohne die IDS miss mal die Spannung zwischen dem nicht angelötet blauen Kabel und dem LVn wo es rann soll.
Auch mal kurz den Strom der Zwischen dem blauen Kabel und dem LVn fließst. Passiert das auch wenn du das Kabel an den freien LVn hälst ?
Du kanns auch mal kurz die 3,3V messen wenn du das Kabel dranhälst. Es klingt so als würde über den Port zuviel Strom fließen.
Gruß JackFrost
Wenn du die Box am USB hast zum Debuggen ohne die IDS miss mal die Spannung zwischen dem nicht angelötet blauen Kabel und dem LVn wo es rann soll.
Auch mal kurz den Strom der Zwischen dem blauen Kabel und dem LVn fließst. Passiert das auch wenn du das Kabel an den freien LVn hälst ?
Du kanns auch mal kurz die 3,3V messen wenn du das Kabel dranhälst. Es klingt so als würde über den Port zuviel Strom fließen.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Die IDS ist nicht angeschlossen .
2,59V und 143µA sind es zwischen "blauem Kabel" und LV3.
Die 3,3V am Wemos sind genau 3,300 V.
Zum Messen der 3,3V musste ich das blaue Kabel an LV3 anlöten. Sonst hätte eine Hand gefehlt.
Interessant ist, dass die Box nach dem "Anlöten während des Betriebs" nicht einfriert oder spinnt. Nach einem Reset bootet sie allerdings nicht mehr.
2,59V und 143µA sind es zwischen "blauem Kabel" und LV3.
Die 3,3V am Wemos sind genau 3,300 V.
Zum Messen der 3,3V musste ich das blaue Kabel an LV3 anlöten. Sonst hätte eine Hand gefehlt.
Interessant ist, dass die Box nach dem "Anlöten während des Betriebs" nicht einfriert oder spinnt. Nach einem Reset bootet sie allerdings nicht mehr.
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
an welchem Pin hast du das Blaue Kabel am Wemos ? Im Debug auch nichts mehr , oder ?
Gruß JackFrost
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Blau geht bei mir an D8, gelb an D7, weiß an D6. Gelb und Weiß machen keine Sorgen.
Nach einem Reboot mit angeschlossenem blauen Kabel geht nichts mehr. Auch kein Debug.
Lediglich der COM Port wird in Windows sichtbar. Allerdings lässt sich der nicht zum Flashen oder so benutzen. Im Serial Monitor kommen beim Reset noch 10-20 wilde ASCII Zeichen (bei jedem Reset andere). Danach ist Schweigen ...
Nach einem Reboot mit angeschlossenem blauen Kabel geht nichts mehr. Auch kein Debug.
Lediglich der COM Port wird in Windows sichtbar. Allerdings lässt sich der nicht zum Flashen oder so benutzen. Im Serial Monitor kommen beim Reset noch 10-20 wilde ASCII Zeichen (bei jedem Reset andere). Danach ist Schweigen ...
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Der D8 ist der GPIO15 welcher laut der Seite das booten von Flash/Bootloader oder SD-Card einstellt. Wenn GPIO15 beim booten high ist dann will der Wemos von einer SD-Card booten, was ja nicht geht.
Versuche einen anderen freien Port zu nehmen. Wenn du einen 1k Widerstand von D8 auf GND legst dann ist der Port auf 0,3V das sollte für Low reichen. Ich weiss aber nicht ob die Pins vom Wemos 3,3 mA noch ohne Probleme Treiben können. bei 2k wird es schon eng, da kommt an die 0,2 * Vcc was in den "verbotenen Bereich" geht und der Pegel ist nicht mehr definiert.
Gruß JackFrost
Versuche einen anderen freien Port zu nehmen. Wenn du einen 1k Widerstand von D8 auf GND legst dann ist der Port auf 0,3V das sollte für Low reichen. Ich weiss aber nicht ob die Pins vom Wemos 3,3 mA noch ohne Probleme Treiben können. bei 2k wird es schon eng, da kommt an die 0,2 * Vcc was in den "verbotenen Bereich" geht und der Pegel ist nicht mehr definiert.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
- DerDerDasBierBraut
- Posting Freak
- Beiträge: 7890
- Registriert: Donnerstag 2. Juni 2016, 20:51
- Wohnort: Neustadt-Glewe
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Krasser Kerl! Ich habe die LV Pins jetzt auf D5-D6-D7 gelötet. Läuft :-)
Komisch, dass beide Boxen bis zum ersten Livetest funktioniert haben. Da haben die Boxen wohl die Euphorie mit gemessen und trotzdem brav von Flash gebootet.
Komisch, dass beide Boxen bis zum ersten Livetest funktioniert haben. Da haben die Boxen wohl die Euphorie mit gemessen und trotzdem brav von Flash gebootet.
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Ich hatte ähnliches problem mit einem Relais an D8 bin dann auf D0 gegangen, ist dieser dann grundsätzlich nicht zu verwenden?JackFrost hat geschrieben: ↑Donnerstag 29. August 2019, 23:18 Der D8 ist der GPIO15 welcher laut der Seite das booten von Flash/Bootloader oder SD-Card einstellt. Wenn GPIO15 beim booten high ist dann will der Wemos von einer SD-Card booten, was ja nicht geht.
Versuche einen anderen freien Port zu nehmen. Wenn du einen 1k Widerstand von D8 auf GND legst dann ist der Port auf 0,3V das sollte für Low reichen. Ich weiss aber nicht ob die Pins vom Wemos 3,3 mA noch ohne Probleme Treiben können. bei 2k wird es schon eng, da kommt an die 0,2 * Vcc was in den "verbotenen Bereich" geht und der Pegel ist nicht mehr definiert.
Gruß JackFrost
Falls ja sollte man diesen aus der Auswahlliste nehmen.
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Oder den Pin so nutzen das man mit einem Pulldown auskommt. Z.b. Das Relais per Mosfet mit Pulldown 10 - 100k und einem "Angstwiderstand" für den Logic Level Mosfet. Wobei man diesen Pin meiden soll. GPIO 0 wird für den Bootloader genutzt. Da sollte keine zu große Last drann sein, so das CH340 das treiben kann.nursbeschde hat geschrieben: ↑Donnerstag 29. August 2019, 23:37Ich hatte ähnliches problem mit einem Relais an D8 bin dann auf D0 gegangen, ist dieser dann grundsätzlich nicht zu verwenden?JackFrost hat geschrieben: ↑Donnerstag 29. August 2019, 23:18 Der D8 ist der GPIO15 welcher laut der Seite das booten von Flash/Bootloader oder SD-Card einstellt. Wenn GPIO15 beim booten high ist dann will der Wemos von einer SD-Card booten, was ja nicht geht.
Versuche einen anderen freien Port zu nehmen. Wenn du einen 1k Widerstand von D8 auf GND legst dann ist der Port auf 0,3V das sollte für Low reichen. Ich weiss aber nicht ob die Pins vom Wemos 3,3 mA noch ohne Probleme Treiben können. bei 2k wird es schon eng, da kommt an die 0,2 * Vcc was in den "verbotenen Bereich" geht und der Pegel ist nicht mehr definiert.
Gruß JackFrost
Falls ja sollte man diesen aus der Auswahlliste nehmen.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Dann wird es aber langsam eng mit der Anzahl der Anschlussmöglichkeiten. Gibt es dann größere Boards die mit der Software laufen oder erweiterungen?
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Das NodeMCU hat ein paar Pins mehr. Externe Porterweiterungen sind für die IDS2 zu langsam.
Oder was eigenes, da hat man dann alle Freiheiten :)
Mal sehen was mit der Bluepill möglich ist. Was man schauen muss ist , ob die beiden µC dann nicht zu viel Strom von der IDS2 ziehen. Daher hab ich bei meiner Regelung ein externes Netzteil und nutze die 5 V von der IDS2 nur für das Relais und die Pegelwandler.
Gruß JackFrost
Oder was eigenes, da hat man dann alle Freiheiten :)
Mal sehen was mit der Bluepill möglich ist. Was man schauen muss ist , ob die beiden µC dann nicht zu viel Strom von der IDS2 ziehen. Daher hab ich bei meiner Regelung ein externes Netzteil und nutze die 5 V von der IDS2 nur für das Relais und die Pegelwandler.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Firmware 1.036
Das Handling Induktion hat ein falsches Event in die Queue geschrieben. Es war möglich, dass eine durch cbpi eingeschaltete Induktionsplatte nach 2-3 loops durch das falsche Event wieder ausgeschaltet wurde
Vielen Dank an DerDerDasBierBraut für den Hinweis
Das Display zeigt nun den aktuellen Powerstatus der IDS2 an.
off: keine IDS2 bzw. Relay off
0: Powerstate 0 bzw. Delay after power off
1-100: aktueller Wert
Innu
Das Handling Induktion hat ein falsches Event in die Queue geschrieben. Es war möglich, dass eine durch cbpi eingeschaltete Induktionsplatte nach 2-3 loops durch das falsche Event wieder ausgeschaltet wurde
Vielen Dank an DerDerDasBierBraut für den Hinweis
Das Display zeigt nun den aktuellen Powerstatus der IDS2 an.
off: keine IDS2 bzw. Relay off
0: Powerstate 0 bzw. Delay after power off
1-100: aktueller Wert
Innu
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Hallo Ihrs,
ich habe meinen Brewpaganda 68l Topf mit den PIDArduinoPowerOutput Werten von matschie getestet (Post #231).
P = 53,79
I = 0,22
D = 16
Danke für die Werte!
Für den Test habe ich 4x billig-ebay Temperaturfühler und 3x DS18B20 Sensoren in den Topf gehangen, wovon der wichtigste DS18B20 in einer Tauchhülse steckt und die beiden anderen im Wasser hingen. Kein Sensor hat den Boden oder die Topfwand berührt. Die Zieltemperatur am CBPi war 75°C bei ca. 25l Wasser. Aus den Werten der Billigfühlern habe ich das Mittel genommen und das Offset für jeden DS18B20 ermittelt (+1.0 +1.0 und Tauchhülse +2.2). Die Anwärmphase war gefühlt langsamer, als mit der Logic Hysteresis. Ab ca. 73 Grad hat die Logic den Power Output heruntergeregelt. Das funktioniert schon sehr sehr gut (max 0,5 über der Zieltemperatur).
Kann ich mit den Parametern (P ?) die Anwärmphase beschleunigen?
Innu
ich habe meinen Brewpaganda 68l Topf mit den PIDArduinoPowerOutput Werten von matschie getestet (Post #231).
P = 53,79
I = 0,22
D = 16
Danke für die Werte!
Für den Test habe ich 4x billig-ebay Temperaturfühler und 3x DS18B20 Sensoren in den Topf gehangen, wovon der wichtigste DS18B20 in einer Tauchhülse steckt und die beiden anderen im Wasser hingen. Kein Sensor hat den Boden oder die Topfwand berührt. Die Zieltemperatur am CBPi war 75°C bei ca. 25l Wasser. Aus den Werten der Billigfühlern habe ich das Mittel genommen und das Offset für jeden DS18B20 ermittelt (+1.0 +1.0 und Tauchhülse +2.2). Die Anwärmphase war gefühlt langsamer, als mit der Logic Hysteresis. Ab ca. 73 Grad hat die Logic den Power Output heruntergeregelt. Das funktioniert schon sehr sehr gut (max 0,5 über der Zieltemperatur).
Kann ich mit den Parametern (P ?) die Anwärmphase beschleunigen?
Innu
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
P ist die Streckenverstärkung. Je höher P ist desto länger ist die Platte bei 100 % bevor sie die Leistung runter nimmt.
Mit dem oben genannte P heizt die Platte bis 1,859K an den sollwert mit 100 % ran und regelt dann die Leistung runter je näher sie kommt.
Du hast dann aber mehr Nachheizen und ggf einen größeren Überschwinger. Auch wenn die Platte 0,5K drunter ist heizt sie stärker nach.
Schau dir daher auch die Werte über die Zeit einer Rast an wie stark das System schwingt.
Gruß JackFrost
Mit dem oben genannte P heizt die Platte bis 1,859K an den sollwert mit 100 % ran und regelt dann die Leistung runter je näher sie kommt.
Du hast dann aber mehr Nachheizen und ggf einen größeren Überschwinger. Auch wenn die Platte 0,5K drunter ist heizt sie stärker nach.
Schau dir daher auch die Werte über die Zeit einer Rast an wie stark das System schwingt.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Ich würde für die Daten zum STM32F1 Gateway die Daten folgendermaßen Empfangen und Senden
Macht also 15 Bytes/Frame. Würde also auch mit 9600 schnell genug laufen. Daten alle 5s wenn länger als 15s keine Daten kommen Platte ausschalten.
Die CRC32 kann im Sender als LUT vorgehalten werden.
In der Antwort kommt im Dummy Byte der Status der Platte.
Gruß JackFrost
Code: Alles auswählen
STX
Daten/Config Byte
Leistungstufe
Dummy Byte
CRC32 als IntelHex
ETX
Die CRC32 kann im Sender als LUT vorgehalten werden.
In der Antwort kommt im Dummy Byte der Status der Platte.
Gruß JackFrost
Meine Hardware:
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
eManometer
IDS2 ohne CBPi
Magnetrührer
Ss-Brewtech 10 Gal Topf
IDS2 Induktionsplatte
-
- Posting Klettermax
- Beiträge: 217
- Registriert: Montag 6. Februar 2017, 13:37
- Wohnort: Wilhelmsfeld
Re: HTTP Actor / Sensor für CBPi Projektvorstellung
Da ich mehrere Steuerungen über mqtt realisiert habe und mir das Kabelgewurschtel immer auf die nerven geht, möchte ich wie bei anderen Projekten hier eine plug and play platine machen, auf der ich den Wemos stecken kann und Sensoren Relais Display anklemmen kann.
Jetzt meine Fragen:
Kann ich an statt die zwei pins fürs display ( falls ich keins benutze) diese pins auch für aktoren nutzen? Dann würde ich nämlich zwei Schaltungen realisieren welche über Jumper gesetzt werden können.
Und welche pins kann ich definitiv für Aktoren nutzen( hier gab es ja bei dem ein oder anderen probleme).
Wenn ich die ids2 nutze , welche ich noch nicht nutze ( wie muss dann die Pinbelegung sein und welche Bauteile( Widerstände) müssen hinzugefügt werden. Irgendwie fände ich es cool wenn man ein Board hat mit dem ich alles individuell und einfach anschließen kann. Bei anderen Projekten ist das mittlerweile richtig zu plug and play Installation geworden.
Gruß Denis
Jetzt meine Fragen:
Kann ich an statt die zwei pins fürs display ( falls ich keins benutze) diese pins auch für aktoren nutzen? Dann würde ich nämlich zwei Schaltungen realisieren welche über Jumper gesetzt werden können.
Und welche pins kann ich definitiv für Aktoren nutzen( hier gab es ja bei dem ein oder anderen probleme).
Wenn ich die ids2 nutze , welche ich noch nicht nutze ( wie muss dann die Pinbelegung sein und welche Bauteile( Widerstände) müssen hinzugefügt werden. Irgendwie fände ich es cool wenn man ein Board hat mit dem ich alles individuell und einfach anschließen kann. Bei anderen Projekten ist das mittlerweile richtig zu plug and play Installation geworden.
Gruß Denis