Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
projekte:esp8266_power [14.10.2016 03:40] – [s0-Schnittstelle mit dem ESP8266 auslesen] pfoetchenprojekte:esp8266_power [18.10.2016 15:00] (aktuell) – [Probleme und Verbesserungsmöglichkeiten] pfoetchen
Zeile 22: Zeile 22:
 {{:projekte:stromlaufplan.png?200|}} {{:projekte:stromlaufplan.png?200|}}
  
-Wir haben uns für eine Umsetzung mit [[https://github.com/nodemcu/nodemcu-firmware|NodeMCU]] entschieden, einer Umgebung die das Programmieren des ESPs mit lua erlaubt (wie in "Probleme und Verbesserungsmöglichkeiten" angesprochen ist das wohl nicht die ideale Wahl gewesen…) . Die jetzige [[https://code.nerd2nerd.org/pfoetchen/esp8266_power|Firmware]] erstellt für einen erhaltenen Impuls zwei Datenpunkte in der InfluxDB: einen Datenpunkt, der angibt, dass ein Impuls überhaupt stattgefunden hat und einen mit dem Zeitabstand zum letzten Impuls. Der erste Datenpunkt dient zum Zählen der Wattstunden um z.B. den Tagesverbrauch anzeigen zu können. Mit Dem Zeitabstand kann man den Verbrauch seit dem vorhergehenden Datenpunkt sehen und erhält so eine Abschätzung des Momentanverbrauchs.+Wir haben uns für eine Umsetzung mit [[https://github.com/nodemcu/nodemcu-firmware|NodeMCU]] entschieden, einer Umgebung die das Programmieren des ESPs mit lua erlaubt (wie in "Probleme und Verbesserungsmöglichkeiten" angesprochen ist das wohl nicht die ideale Wahl gewesen…) . Die jetzige [[https://code.nerd2nerd.org/pfoetchen/esp8266_power|Firmware]] erstellt für einen erhaltenen Impuls zwei Datenpunkte in der InfluxDB: einen Datenpunkt, der angibt, dass ein Impuls überhaupt stattgefunden hat und einen mit dem Zeitabstand zum letzten Impuls. Der erste Datenpunkt dient zum Zählen der Wattstunden um z.B. den Tagesverbrauch anzeigen zu können. Mit dem Zeitabstand kann man den Verbrauch seit dem vorhergehenden Datenpunkt sehen und erhält so eine Abschätzung des Momentanverbrauchs.
  
 Weiterhin zeigt die Firmware an wenn sie neu gestartet wurde um zu erkennen wie (in-)stabil das System läuft. Weiterhin zeigt die Firmware an wenn sie neu gestartet wurde um zu erkennen wie (in-)stabil das System läuft.
Zeile 31: Zeile 31:
  
 Das Auslesen nur über den Pullup des ESPs ist auf die lange Strecke (~3m Kabel) nicht ideal und führt manchmal zu Doppelpulsen <del>die bisher über die Software abgefangen werden. Diese sollte bald durch eine Schaltung mit einem Optokoppler verbessert werden.</del>. Das Einbauen eines Optokopplers hat für ein bisschen Verbesserung gesorgt aber auch dann kommen Doppelpulse noch vor. Es wäre möglich diese über Hardware auszufiltern aber da eh zwischen den Pulsen mindesten 300ms liegen (~11kW maximal wenn alle drei Phasen genutzt werden) wird weiterhin über Software gefiltert. Das Auslesen nur über den Pullup des ESPs ist auf die lange Strecke (~3m Kabel) nicht ideal und führt manchmal zu Doppelpulsen <del>die bisher über die Software abgefangen werden. Diese sollte bald durch eine Schaltung mit einem Optokoppler verbessert werden.</del>. Das Einbauen eines Optokopplers hat für ein bisschen Verbesserung gesorgt aber auch dann kommen Doppelpulse noch vor. Es wäre möglich diese über Hardware auszufiltern aber da eh zwischen den Pulsen mindesten 300ms liegen (~11kW maximal wenn alle drei Phasen genutzt werden) wird weiterhin über Software gefiltert.
 +
 +{{:projekte:stromlaufplan_optokoppler.png?200|}}
  
 <del>Wie man im Dashboard erkennen kann startet das ESP-Modul recht häufig neu, nach unseren Erkenntnissen liegt das wohl an der darunterliegenden NodeMCU-Firmware. Eine Neuentwicklung direkt in C auf Basis des SDKs wäre ein möglicher Lösungsansatz.</del> Die Instabilität lag hauptsächlich daran, dass der Reset-Pin floating war. Dieser wird nun auf 3.3V gezogen (und die Software vereinfacht und verbessert)und das Board läuft ohne Probleme durch. <del>Wie man im Dashboard erkennen kann startet das ESP-Modul recht häufig neu, nach unseren Erkenntnissen liegt das wohl an der darunterliegenden NodeMCU-Firmware. Eine Neuentwicklung direkt in C auf Basis des SDKs wäre ein möglicher Lösungsansatz.</del> Die Instabilität lag hauptsächlich daran, dass der Reset-Pin floating war. Dieser wird nun auf 3.3V gezogen (und die Software vereinfacht und verbessert)und das Board läuft ohne Probleme durch.