Hobbybrauer.de

Matschie: könntest Du mir zu

if (sens_value == 85.0) { // missing VCC

Deine Quelle nennen. Ich finde dazu nichts in der dallas
Danke

Innuendo hat geschrieben: ↑Mittwoch 9. Januar 2019, 13:21 2.1 Matschie meint vermutlich das Offset wie beim Type One_Wire_Sensor. Im MQTT_Sensor Plugin gibt es die Möglichkeit noch nicht oder?

Ja. Irgendwie bin ich davon ausgegangen dass es das beim MQTT Sensor auch gibt.

Innuendo hat geschrieben: ↑Donnerstag 10. Januar 2019, 07:17 Matschie: könntest Du mir zu
Code: Alles auswählen
if (sens_value == 85.0) { // missing VCC
Deine Quelle nennen. Ich finde dazu nichts in der dallas

Nur Erfahrung. Google sonst mal "DS18B20 85 grad" - der Fehler scheint immer bei unzureichender Stromversorgung aufzutreten. z.B. VCC ab, oder Kabel zu lang, oder im parasitären Betrieb nicht genug Leistung in der Stromversorgung. Ist glaube ich kein echtes "Feature" aber ein reproduzierbares Verhalten.

Super - Danke! PDF

*The power-on reset value of the temperature register is +85°C.

Edit: CRC check hinzugefügt

Ich hab auch nochmal ein bisschen was getan.
Ich denke es macht Sinn, die ganze Kommunikation auf JSON umzustellen und im Frontend mit HTML zu verhübschen. Der Chip hat auch so schon genug zutun. Bisher habe ich es nur für Sensoren und Aktoren (anzeigen) gemacht, werde es aber noch für die restlichen Bereiche nachholen:-)
https://github.com/PedeLa/MQTTDevice/pull/3
Liebe Grüße!

Ich hoffe, es hat keiner Zeit in mein letztes Update investiert. Vermutlich hat die Spielerei mit VS Code/Platformio meine libs/IDE zerschossen. Graythread's pull #2 hat meine ESPs dann komplett lahmgelegt. Das lag aber bestimmt an mir! Nachdem ich alle libs Ordner bereinigt, die IDE neu installiert und den Sketch nochmal ganz von vorne aufgebaut habe, funktioniert er wieder. Obendrein ist der Sketch nun 12% kleiner. Keine Ahnung, was da schief gelaufen ist, aber das hat mir viel Zeit an meinen letzten Urlaubstagen gekostet.

Auch wenn er funktioniert ist der Sketch weiterhin ein Test und ungeeignet für den produktiven Einsatz. Bitte Matschies Version nutzen!

Der EM funktioniert nun "zufriedenstellend". Weil es noch keinen Publisher für die Aktoren gibt, sieht man auf CBPi Seite nicht, wenn der EM einen Aktor ausschaltet. Ich finde den Ansatz Events in eine Warteschlange werfen zu können weiterhin gut, um auf verschiedene Situationen reagieren zu können. Bevor aber die diffs immer größer werden, warte ich mal ab, wie sich das Projekt so entwickelt ;-)
Innu

graythread hat geschrieben: ↑Mittwoch 9. Januar 2019, 12:35 2.1 Temperatur Offset einstellbar: Zumindest meine One-Wire sind alles andere als genau und es wäre doch toll, wenn diese Offsets direkt on-edge berechnet würden und der "richtige" Wert CBP gemeldet würde?

Hallo,
hab mir das mal angeschaut. Quick'n'dirty sind es 2 Zeilen im Plugin

Code: Alles auswählen

d_offset = Property.Number("Offset", configurable=True, default_value="0", description="Offset relative to sensor data")
...
def get_value(self):
        return {"value": self.last_value + float(self.d_offset), "unit": self.unit}

die MQTT Nachricht im mqtt-spy 26.25°C

: offset2.jpg (15.71 KiB) 7303 mal betrachtet

Innu

Klingt doch gut. Packst du es in das cbpi-mqttCompressor Plugin?

Hab es hier hinterlegt

Super, danke Dir!
Hab auch mit dem Frontend-Refactor ein bisschen weiter gemacht.

Es gab noch einen round Fehler. Ist behoben.
Mein Chrome auf Win addiert den Offset beim Reload der Seite. Auf dem RaspPi scheint es korrekt zu sein. Da muss Matschie mal drüber schauen. Habe mich mit dem Thema Plugins noch nicht beschäftigt.

Innuendo hat geschrieben: ↑Samstag 12. Januar 2019, 15:09 Hab es hier hinterlegt

Sieht doch nach einer guten Lösung aus!

graythread hat geschrieben: ↑Samstag 12. Januar 2019, 15:49 Super, danke Dir!
Hab auch mit dem Frontend-Refactor ein bisschen weiter gemacht.

Klappt das gut? Und bringt es was?

Schau da mal drüber

Code: Alles auswählen

    def get_value(self):
        try:
            self.last_value = round(self.last_value + float(self.d_offset), 2)
        except Exception as e:
                pass
        return {"value": self.last_value, "unit": self.unit}

ich denke, die get_value verarbeitet das Addieren vom Offset mehrfach. Ich hatte am cbpi eine korrekte Anzeige und am Win Client wurde offset doppelt addiert.

Achja ... ich hab gestern mit meiner EventManager Version einen Brautag durchgeführt: wunderbar.
Ich habe es aber noch nicht hinbekommen, den Plugin Aktoren ein MQTT Subscribe beizubringen.

matschie hat geschrieben: ↑Montag 14. Januar 2019, 09:48
Innuendo hat geschrieben: ↑Samstag 12. Januar 2019, 15:09 Hab es hier hinterlegt
Sieht doch nach einer guten Lösung aus!

..und funktioniert bei mir auch prima, zumindest auf den ersten Blick:-)

matschie hat geschrieben: ↑Montag 14. Januar 2019, 09:48
graythread hat geschrieben: ↑Samstag 12. Januar 2019, 15:49 Super, danke Dir!
Hab auch mit dem Frontend-Refactor ein bisschen weiter gemacht.
Klappt das gut? Und bringt es was?

Ich denke schon. Es gibt keine Notwendigkeit mehr, Internet Access zu haben, da alle benötigten Dateien jetzt direkt auf dem Chip liegen (was ich zuhause zB in einem eigenen "Brausubnet" ganz praktisch finde). Außerdem wird die Menge an Daten, die mit jedem Request gepullt wird, um einiges reduziert, da der Server nicht mehr HTML-Formatierungskram auspuckt, sondern dies im Frontend passiert. Und die Methoden liefern jetzt alle korrekte Rückgabewerte, vorher gab es im Frontend immer Fehler beim Posten/Löschen von Sensoren/Aktoren. Kleinkram halt, aber hält den Code was übersichtlicher:-).

Ich habe auch versucht, die Dinge in den Commit Messages jeweils ausführlich zu beschreiben.

Grüße!

Ich habe pedelas und meine commits gemerged und auf ein Test-Device geflashed. Das schaut schon ganz gut aus. Auf github liegt der aktuelle Stand aus 3 (Himmels) Richtungen.

Innuendo hat geschrieben: ↑Montag 14. Januar 2019, 09:59 Schau da mal drüber
Code: Alles auswählen
    def get_value(self):
        try:
            self.last_value = round(self.last_value + float(self.d_offset), 2)
        except Exception as e:
                pass
        return {"value": self.last_value, "unit": self.unit}
ich denke, die get_value verarbeitet das Addieren vom Offset mehrfach. Ich hatte am cbpi eine korrekte Anzeige und am Win Client wurde offset doppelt addiert.

Das get_value wird jedes mal ausgelöst, wenn der CBPi den Wert des Sensors abfragt. Dann wird auch jedes mal der offset addiert.

Ich hab es jetzt so gelöst, konnte es aber noch nicht live testen:

Code: Alles auswählen

		
	try:
            self.send_value = round(self.last_value + float(self.d_offset), 2)
        except Exception as e:
                pass
        return {"value": self.send_value, "unit": self.unit}

Innuendo hat geschrieben: ↑Montag 14. Januar 2019, 19:15 Ich habe pedelas und meine commits gemerged und auf ein Test-Device geflashed. Das schaut schon ganz gut aus. Auf github liegt der aktuelle Stand aus 3 (Himmels) Richtungen.

Dann werde ich das am Wochenende auch mal machen. Wenn du einen Pull-Request öffnest, werde ich das dann wenn alles klappt auch zu mir mergen.

matschie hat geschrieben: ↑Dienstag 15. Januar 2019, 07:52 Ich hab es jetzt so gelöst, konnte es aber noch nicht live testen:
Code: Alles auswählen
		
	try:
            self.send_value = round(self.last_value + float(self.d_offset), 2)
        except Exception as e:
                pass
        return {"value": self.send_value, "unit": self.unit}

Probiere ich heute Abend aus. Danke

matschie hat geschrieben: ↑Dienstag 15. Januar 2019, 07:52 Dann werde ich das am Wochenende auch mal machen. Wenn du einen Pull-Request öffnest, werde ich das dann wenn alles klappt auch zu mir mergen.

Pull request ist geöffnet. Weiß nicht, ob es geklappt hat.

Innuendo hat geschrieben: ↑Dienstag 15. Januar 2019, 09:57 Probiere ich heute Abend aus. Danke

Musst natürlich oben wo last_value definiert ist auch noch den neuen send_value = 0 definieren. Wollte nur nicht den ganzen code hier hin kopieren.

VG

Das war fast die Lösung ...

Code: Alles auswählen

self.send_value = round(float(self.last_value) + float(self.d_offset), 2)

Nun funktioniert auch das Offset.

Meine ESPs sind nun alle auf den "merged Stand". Subjektiv finde ich die Module dank der Anpassung von graythread agiler. OTA hat wunderbar funktioniert. Über den FSBrowser die config.json eingespielt. Passt aus meiner Sicht soweit.
Weil html und styles für mich ein graus ist, wäre ich für eine Lösung für die Ideen Button "All MQTT/actors off" und ein Button "Reboot ESP" dankbar.
Innu

Guten abend,
ich lese hier schon ne weile mit.
Ich habe ein grobes Verständnis von arduino, mqtt und python.
Habe hier einen TH16 inkl. DS18B20 den ich gerne per mqtt an meinen raspi anbinden möchte um somit die rasten in CBPI zu steuern.

Mein problem ist das dieser thread für mich sehr unübersichtlich ist, da ja mit http actoren angefangen wurde und es jetzt mqtt basiert läuft.
Daher meine vorsichtige Frage ob sich jemand findet der ein klassisches howto auf jetztigem stand mit den aktuellen repos und plugins erstellen könnte..?

..Und jetzt bitte nicht steinigen ;-)

Guten Abend!

Die Version, die auf meinem Github liegt entspricht dem HowTo, was hier veröffentlicht ist. Damit sollte alles klappen. Viel Erfolg!

Guten abend,

ich habe versucht den Aktoren mqtt sub beizubringen. Das sah laut core.py einfacher aus (switch_actor_off). Aber ich finde nicht heraus, wie die Methoden zu nutzen sind.

Code: Alles auswählen

class MQTTActor(ActorBase):
    topic = Property.Text("Topic", configurable=True, default_value="", description="MQTT TOPIC")
    pPower = 100

    def init(self):
	def on_message(client, userdata, msg):
            json_data = json.loads(msg.payload)
            new_state = json_data['state']
			
			#If new_state != old_state and new_state == 'off':
			
            if new_state == 'off':
                self.api.switch_actor_off(self.id)
                return
            else:
                pass

	on_message.actorid = self.id
	self.api.cache["mqtt"].client.subscribe(self.topic)
	self.api.cache["mqtt"].client.message_callback_add(self.topic, on_message)

 def on(self, power):
....

Das Plugin empfängt die message, wenn ich aus mqtt-spy auf ein topic {"state": "off"} sende. Die Methode switch_actor_off wird auch ausgeführt. Aber die WebIf Anzeige bleibt hängen

Weiß jemand Rat?

matschie hat geschrieben: ↑Mittwoch 16. Januar 2019, 20:53 Guten Abend!

Die Version, die auf meinem Github liegt entspricht dem HowTo, was hier veröffentlicht ist. Damit sollte alles klappen. Viel Erfolg!

Super, danke!
Aber wie verbinde ich den esp vom th16 mit dem arduino?

Innuendo hat geschrieben: ↑Dienstag 15. Januar 2019, 20:35 Das war fast die Lösung ...
Code: Alles auswählen
self.send_value = round(float(self.last_value) + float(self.d_offset), 2)
Nun funktioniert auch das Offset.

Meine ESPs sind nun alle auf den "merged Stand". Subjektiv finde ich die Module dank der Anpassung von graythread agiler. OTA hat wunderbar funktioniert. Über den FSBrowser die config.json eingespielt. Passt aus meiner Sicht soweit.
Weil html und styles für mich ein graus ist, wäre ich für eine Lösung für die Ideen Button "All MQTT/actors off" und ein Button "Reboot ESP" dankbar.
Innu

Zumindest teilweise gemacht: https://github.com/matschie1/MQTTDevice/pull/4

Ich hab noch einen "download config" Button eingefügt, damit kannst du die JSON direkt aus dem Web ziehen und beim nächsten SPIFFS Update automatisch wieder einspielen, sofern du die Datei einfach im "data" Ordner speicherst. Hab sie mal zum .gitignore hinzugefügt, kannst also dauerhaft dann da liegen lassen:-).

MQTT Disable habe ich noch nicht implementiert, nur den Button mit Frontend->Backend Senden des Aufrufs bisher. Wenn ich Zeit hab und so..;-)

Eine Bitte noch, auch wenn's aufwändig ist (und falls Du Zeit findest):
Ich würde Deinen Eventmanager auf Dauer gern mal ausprobieren. Allerdings wäre es dafür super, wenn du von Matschies gemeinsamer Code-Basis ausgehst, sonst ist das Mergen so schwierig. Sprich: Nochmal von Matschie (oder meinem Pull Request;-)) forken und dann Deine Änderungen (und nur die;-)) drauf committen. Geht das?

@Matschie: Was hältst Du eigentlich von Tags/Releases auf GitHub? Auf Dauer dürfte das die Kommunikation vereinfachen (Versionierung..)

@amplitude: Kurzes Googlen hat das hier ausgespuckt: https://www.bastelgarage.ch/index.php?r ... post_id=11 Sieht machbar, aber nicht super-schnell-simpel aus. Aber dafür hast dann auch ein ziemlich cooles Teil wenn es funktioniert. Berichte mal wenn Du Zeit hast:)
Lieben Gruß,
Peter

Über spiffs finde ich gegenüber dem FSBrowser eher nicht so gut. Ich habe 3 ESPs und brauche über OTA nur 3x den Sketch verteilen und aus einem config Ordner die richtige json auswählen. Aber würde natürlich auch gehen.
Mal schauen, ob matschie über das WE Zeit findet eine aktuelle Basis zu erstellen. Je nachdem, wie die Basis ausschaut erstelle ich auch einen neuen pull.
Innu

Ich meinte jetzt vor allem aus Entwicklersicht. Gerade, wenn man am Frontend arbeitet flashed man ja eh andauernd das SPIFFS.

Das kannst Du ja auch machen. Wie geschrieben geht das natürlich auch.
Über den FSBrowser hättest Du die index und Icon Datei einfacher und schneller ausgetauscht gehabt. Insbesondere beim Entwickeln und Testen.
Innu

Ich habe Dir mal ein merge für einen Test erstellt. Das rep beinhaltet alles von matschie, von Dir und meine Kleinigkeiten. Reboot und disable MQTT habe ich in den EM verschoben.

Hey danke, hab es mal ausprobiert. Funktioniert, auf den ersten Blick zumindest, gut.

Und danke für die Anpassung des Temperature Offsets nochmal. Das tuts bei mir prima. Wir sollten mal eine ReadMe schreiben, in der alle benötigten Plugins und Repositories, auch auf CraftbeerPi-Seite, erwähnt werden (wie wäre es mit einer GitHub Organization, in die alle "official" Repos reingepackt werden, auf die wir alle Schreibzugriff haben? Ist bei OpenSource Projekten gratis möglich). Zumindest ich musste am Anfang ein paar durchprobieren bevor ich das PID Autotune und dann die "geregelte" Ansteuerung der Platte hinbekommen hatte.

Anyways..ich werde mich erstmal der PT100 Unterstützung (Mit dem Adafruit-Board) widmen, da ich diese bei mir (auch) im Einsatz habe. Sollte ja parallel zu den DS18B20 Sensoren implementierbar sein:-)

Grüße und habt ein schönes Wochenende,
Peter

Hallo ihr beiden,

tut mir Leid, ich werde dieses WE wenig bis gar nicht weiterkommen. Wenig Zeit und heute nutze ich die Zeit lieber zum brauen statt zum programmieren

graythread hat geschrieben: ↑Samstag 19. Januar 2019, 12:29 Wir sollten mal eine ReadMe schreiben, in der alle benötigten Plugins und Repositories, auch auf CraftbeerPi-Seite, erwähnt werden (wie wäre es mit einer GitHub Organization, in die alle "official" Repos reingepackt werden, auf die wir alle Schreibzugriff haben? Ist bei OpenSource Projekten gratis möglich). Zumindest ich musste am Anfang ein paar durchprobieren bevor ich das PID Autotune und dann die "geregelte" Ansteuerung der Platte hinbekommen hatte.

Die Idee finde ich aber super, würdest du das organisieren?

https://github.com/MQTTDevice

Wenn Ihr beide die Einladung annehmt packe ich euch in die Admin Gruppe. Rest folgt dann im Laufe der Woche. Können wir uns noch darauf einigen, dass wir nur auf nicht-Master Branches committen und uns vorher absprechen, wenn wir etwas da rein mergen? Dann kommen auch keine neuen (Code)Conflicts auf:-)

Habt einen schönen Sonntag Abend noch!
Peter

ok das können wir so mache.
Vielleicht sollten wir mit neuem readme im neuen repo auch ein neuen thread im Forum starten. Die Verwirrung, ob mit arduino oder ohne und http vs mqtt ist schon verständlich. In der fb Gruppe kann man auch darauf aufmerksam machen.

Innuendo hat geschrieben: ↑Montag 21. Januar 2019, 06:01 Vielleicht sollten wir mit neuem readme im neuen repo auch ein neuen thread im Forum starten.

Ja, sehe ich auch so. Aber am besten wenn es "fertig" ist..

Die Version, die im gemeinsamen Projekt liegt, ist die aktuellste? Also die, von der aus wir weiterentwickeln?
Ich habe in der Zwischenzeit seit dem Stand, der auf GitHub liegt, nicht mehr weitergemacht und würde dann jetzt den Stand aus dem gemeinsamen Projekt als Ausgangspunkt für weitere "Arbeiten" nehmen.

Es ist die des letzten Pull-Requests, ja.
Ich bastel gerade an der PT100 Integration, sollte bald soweit sein, dann werde ich das auch in einem neuen Branch pushen. Integriert sich aber bisher ganz gut.

Hallo,
kurzer Zwischenstand

Weil das ESP mit der ersten OLED lib permanent abgestürzt ist, wenn ich die config Parameter zur Laufzeit angepasst habe (SDA, SDL), bin ich auf die AdafruitSSD1306 gewechselt. Leider beginnt das malen nach Zahlen nun von vorne und die lib macht alles irgendwie anders. Die 4 Buttons oben funktionieren soweit bereits. Das Display funktioniert auch, aber eine vernünftige Anzeige braucht noch etwas Zeit. Die Einstellung Display ist in die config.json eingefügt (enabled, address) inkl den entpsrechenden set und req Methoden.

Parallel habe ich die vielen Serial.print Ausgaben in ein #define Debug gepackt. Zur Entwicklungszeit nützlich, aber beim Brauen muss der kleine Proz nicht permanent etwas ausgeben, was eh keine sieht. Leider gibt es nun sehr viele ifdefs. Das macht den Quellcode unleserlich.
Hat hierzu einer von euch eine bessere Lösung? Ich habe mal mit einer DebugUtils herumgespielt, aber das war es nicht.
Innu

Hey Innu,

kannst Du den Quellcode vielleicht einfach in einem Branch hochladen, dann könnte man sich den Fortschritt einfach anschauen?
Hab ich hier auch gemacht: https://github.com/MQTTDevice/MQTTDevice/tree/pt100
Generell fände ich ein Display schon schön, vor allem für eine Anzeige an den Kühlschränken:-).

Ich habe die letzten 2 Abende weiter am Refactoring und der Integration der PT100/1000 gebastelt, funktioniert ansich, es fehlt nur noch das Web Frontend anbinden, aber das wird heute nichts mehr. Der Code ist jetzt (meiner Meinung nach;-)) allerdings schon ein ganzes Stück übersichtlicher geworden, trotz der zusätzlichen Zeilen für die neuen Sensoren. Ich habe versucht, so gut es ging, den Code (neu wie alt) zu dokumentieren.

Desweiteren habe ich mal an ein paaar PCB Board Entwürfen gebastelt, die werde ich die Tage auch noch (nach eigenem Testen) hochladen, vielleicht ist ja der andere daran interessiert, sich seine Platine "machen zu lassen".

Viele Grüße und einen schönen Abend,
Peter

Hallo,
ich glaube nicht, dass ihr das diff haben wollt. Der Grund ist der Eventmanager. Ich denke, da ist für ein Test ein clone auf mein rep der einfachere Weg. Wenn das Projekt ohne EM fortgeführt wird, dann passt das mit meinen aktuellen Sachen (zB Display) nicht zusammen. Das wäre auch völlig ok! Bitte nicht falsch verstehen. Schau Dir nur mal meine 1_LOOP.ino an, dann wirst Du mir zustimmen, dass ein diff wenig Nutzen hat

Code: Alles auswählen

void loop() {
  cbpiEventSystem(20);              // Check WLAN
  cbpiEventSystem(30);              // Display and NTP Update
  cbpiEventSystem(21);              // OTA handle
  cbpiEventSystem(22);              // Check MQTT
  cbpiEventSystem(23);              // Webserver handle
  cbpiEventSystem(24);              // MDNS handle
  cbpiEventSensors(0);              // Sensor handle
  cbpiEventActors(0);               // Actor handle
  cbpiEventInduction(0);            // Induction handle
  while (gEM.getNumEventsInQueue()) // Eventmanager process all queued events
  {
    gEM.processEvent();
  }
  delay(100);
}

Wenn Zeit übrig ist (hahahaha), sollte entschieden werden, ob der EM für nützlich oder überflüssig ist. Das soll jetzt nicht bedeuten, dass ich mich ausklinke, wenn der EM nicht ins Projekt einfließt!
Parallel zu meinem habe ich ja auch einen clone vom gemeinsamen rep. Dort werde ich kleine diffs zeitnah pushen. Bspw. ist der mqttreconnect fehlerhaft, wenn keine subscriptions vorliegen. Die Endlosschleife mit den delays machen das device unheimlich träge. Die Situation tritt vornehmlich bei Erstkonfiguration / nach Erase flash all content auf. Den wlan hostname habe ich auf die bekannte chipid Lösung korrigiert, um den lokalen DNS nicht zu verwirren. Jeweils ein extra diff würde ich für die #Debug Deklarative und den FileBrowser erstellen etc etc.
Ich bin da flexibel - ich mach das so, wie ihr das möchtet ;-)
Innu

ich befürchte, ich habe grad meine Anpassung DEBUG macro ins master gepushed. Sorry ...
Verwendung ist ganz einfach: zum Entwickeln #define DEBUG aktivieren, zum Brauen auskommentieren.
Innu

P.S.: Damit mir das nicht nochmal passiert ... mit welchem git Befehl wäre die Änderung im branch Innuendo gelandet? (ausgehend von einem git clone master)

Hallo,
das Grundgerüst für ein OLED Display auf Basis Adafruit SSD1306 ist fertig

Ich habe dabei die einzelnen Teile der Anzeige in Methoden gekapselt, sodass diese sehr einfach wiederzuverwenden sind.
Bspw Zeitanzeige

Code: Alles auswählen

void showDispTime(String value)
{
#ifdef DISPLAY
  display.setCursor(5, 5);
  display.setTextSize(2);
  display.setTextColor(WHITE);
  display.print(value);
#endif
}

Auf diese Weise lässt sich zB "showDispTime" an jeder Stelle im Code ohne ifdef/endif aufrufen und wenn #DISPLAY nicht aktiviert ist, passiert halt gar nix. Wer x,y und Fontsize ändern oder relativen Koordinaten rumspielen mag, hat eine zentrale Stelle. Die Icons WLAN, MQTT und CBPI sind als uint8 Header Dateien erstellt. Das Ein- und Ausblenden bei WLAN/MQTT Fehlern ist beim booten einfach, im laufenden Betrieb habe ich noch auf der Todo.
Innu

Hey,
kurze Rückmeldung von mir: Sieht alles sehr hübsch aus. Ich werde am Wochenende wieder etwas Zeit haben und die PT100 Integration fertig machen. Vielleicht bist Du bis dahin ja auch komplett durch mit dem Display, dann mergen wir mal Deine und meine Sachen, was meinst du? Klar bauen wir den Event Manager mit ein (wenn Matschie auch zustimmt;-)), nimm mein verzögertes Antworten bitte für das was es ist, ein Zeitproblem, nicht mangelndes Interesse;-).

BTW hier: https://gitter.im/MQTTDevice/general gibt es einen Gitter Chat (Login einfach mit GitHub Account, damit wir das Forum hier nicht mit zuviel Develop-Details zu-spammen:-).

Hallo,
klingt nach einem Plan ;-)
Gitter schau ich mir morgen an. Ich habe heute Abend nochmal einige Verbesserungen umgesetzt (siehe git).
Wenn Du am Wochenende Zeit hast prüfe bitte mein Mist-Geschick im master. Wenn die macro Lösung für Debug Ausgaben unerwünscht ist, mach bitte ein revert. Ich bin hatte noch keine Zeit (aka Lust), um die git docs zu lesen

Innu

Hallo zusammen,
habe das WebIf um ein Misc Menü erweitert

: misc.jpg (50.96 KiB) 6611 mal betrachtet

Für das gemeinsame Repo empfehle ich dringend das delay in der loop durch eine millis() zu ersetzen! Das macht das Device insb. den Webserver sehr viel schneller/agiler.

Edit: pull request erstellt

Nabend,

jetzt hab ich hardwareseitig alles soweit klar das ich flashen könnte. Nur scheine ich ein grundlegendes IDE Problem zu haben.
Beim kompilieren tauchen folgende Fehler auf:

MQTTDevice:33:22: error: 'D3' was not declared in this scope

#define ONE_WIRE_BUS D3

^

C:\Users\********\Desktop\MQTTDevice\MQTTDevice.ino:34:17: note: in expansion of macro 'ONE_WIRE_BUS'
OneWire oneWire(ONE_WIRE_BUS);
0_SETUP:82:23: error: 'D0' was not declared in this scope
ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {
0_SETUP:82:27: error: 'D1' was not declared in this scope
ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {

^
0_SETUP:82:31: error: 'D2' was not declared in this scope
ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {

^

exit status 1
'D3' was not declared in this scope

Edit: Hab den log etwas gekürzt

Okay,

ich bin jetzt soweit das ich weiß dass ich die Pins anders mappen muss da der TH16 nicht die gleichen namen/pinmap aufweist wie das wemo board mit dem ihr arbeitet. Nur woher ich die richtige belegung bekomme weiß ich noch nicht :(
Zudem überlege ich ob ich nicht einfach die tasmota firmware drauf flashe und von da aus per MQTT mit dem CBPi rede. Das müsste genauso gut funktionieren oder nicht?

amplitude hat geschrieben: ↑Freitag 25. Januar 2019, 22:38 Zudem überlege ich ob ich nicht einfach die tasmota firmware drauf flashe und von da aus per MQTT mit dem CBPi rede. Das müsste genauso gut funktionieren oder nicht?

Ohne den Thread jetzt Hijacken zu wollen: ja das funzt. Habe das genau so im Einsatz. Einen Th16 mit Tasmota für den Gärschrank per mqtt mit dem Raspi verbunden.
Baue mir auch grad noch nen zweiten auf für Nachgusstemperatursteuerung/Pumpe.

Guten Morgen zusammen,

Endlich habe ich den Sketch am laufen

.
echt klasse Arbeit!!

Es es möglich auch Funksteckdosen zu schalten??

Gruß
Thomas

irrwisch hat geschrieben: ↑Freitag 25. Januar 2019, 23:29
amplitude hat geschrieben: ↑Freitag 25. Januar 2019, 22:38 Zudem überlege ich ob ich nicht einfach die tasmota firmware drauf flashe und von da aus per MQTT mit dem CBPi rede. Das müsste genauso gut funktionieren oder nicht?
Ohne den Thread jetzt Hijacken zu wollen: ja das funzt. Habe das genau so im Einsatz. Einen Th16 mit Tasmota für den Gärschrank per mqtt mit dem Raspi verbunden.
Baue mir auch grad noch nen zweiten auf für Nachgusstemperatursteuerung/Pumpe.

Ha! könntest du mir verraten wie der topic und payload aussehen müssen im cbpi damit da was passiert?

amplitude hat geschrieben: ↑Samstag 26. Januar 2019, 16:51
irrwisch hat geschrieben: ↑Freitag 25. Januar 2019, 23:29
amplitude hat geschrieben: ↑Freitag 25. Januar 2019, 22:38 Zudem überlege ich ob ich nicht einfach die tasmota firmware drauf flashe und von da aus per MQTT mit dem CBPi rede. Das müsste genauso gut funktionieren oder nicht?
Ohne den Thread jetzt Hijacken zu wollen: ja das funzt. Habe das genau so im Einsatz. Einen Th16 mit Tasmota für den Gärschrank per mqtt mit dem Raspi verbunden.
Baue mir auch grad noch nen zweiten auf für Nachgusstemperatursteuerung/Pumpe.
Ha! könntest du mir verraten wie der topic und payload aussehen müssen im cbpi damit da was passiert?

Kann ich dir leider erst in ca 1 Woche sage da ich momentan keinen Zugriff auf meine Brausteuerung habe.
Man musste auch eine Codezeile im MQTT Plugin ändern.

Vielleicht sollte wir für Tasmota/Sonoff einen extra Thread aufmachen um hier nicht zu sehr abzudriften?

irrwisch hat geschrieben: ↑Freitag 25. Januar 2019, 23:29
Vielleicht sollte wir für Tasmota/Sonoff einen extra Thread aufmachen um hier nicht zu sehr abzudriften?

Habe ich jetzt gemacht ;)

Hallo,
matschie sollte auch das Thema in diesem Faden korrigieren oder zumindest im Topic MQTT erwähnen

Ich habe meine Version nun soweit, dass sie einsatzfähig ist. Die Version bietet nun die grundlegende Konfiguration im WebIf und ist deutlich schneller.

Der Eventmanager lässt sich so recht einfach ein/ausschalten bzw. die Reaktionszeit individuell im laufenden Betrieb anpassen. Das Display und die Debug Ausgaben auf dem ser. Monitor lassen sich ebenfalls im laufenden Betrieb ein- und ausschalten. Wer das event handling oder das Display nicht braucht, bekommt per default einfach ein MQTTDevice

: display3.jpg (7.82 KiB) 6385 mal betrachtet

: display2.jpg (2.54 KiB) 6385 mal betrachtet

: display.jpg (2.96 KiB) 6385 mal betrachtet

: display1.jpg (2.96 KiB) 6385 mal betrachtet

Angepasst:
- das Device hat nun immer einen eindeutigen DNS Namen, auch im AP-Mode und OTA
- über das Web Interface kann die Konfiguration gelöscht werden (reboot mit leerer Konfig)
- über das Web Interface können die WLAN settings gelöscht werden (reboot im AP Mode)
- die Verarbeitung der Daten vom Temp.Sensor angepasst (-127°C, +85°C)
- die Systemdienste Webserver und MQTT werden nicht verzögert
- MQTTreconnect ersetzt
- NTP Time Update
- die Ausgaben auf dem seriellen Monitor sind nun ein/ausschaltbar (ohne reboot)
- das Display kann über ein Menü konfiguriert, ein und ausgeschaltet werden (ohne reboot)
- das Event handling "keine Daten vom Temperatursensor" lässt sich nun frei konfigurieren: ein/aus und Verzögerung für Aktoren
- das Event handling WLAN/MQTT Error lässt sich ein/ausschalten
- Display Ausgabe OTA hinzugefügt (progressbar)
etc.

Innu

Hobbybrauer.de

HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung

Re: HTTP Actor / Sensor für CBPi Projektvorstellung