2 meters on same unit sometimes don´t work

[mruettgers]

2 meters on same unit sometimes don´t work

[kr0815]

ich probiere das gerne morgen mal aus

momentan schaut es so aus als würde die LED 3 mal blinken . kurze Pause - dann noch 1 x
Aber ist schwer zu sagen - müsste ich mal das Oszi anschließen

Das Throttling habe ich genutzt da mein VZ in der Cloud liegt - will nicht so vielen Traffic dort hin haben

Aber wir forschen das Problem gerne gemeinsam aus :-)

[mruettgers]

Hallo Klaus,

aber wie meinst Du das das jetzt jeder Sensor seinen eigenen MQTT-Client hat? Das man 2 verschiedene Topics angeben kann?

bislang hatte ich eine MQTT-Bibliothek verwendet, die synchron gesendet hat, d.h., während der Kommunikation mit dem MQTT-Broker war die Verarbeitung von weiteren potentiellen Messwerten blockiert.
Das habe ich gestern Abend auf https://github.com/marvinroger/async-mqtt-client umgestellt, dabei aber festgestellt, dass es Probleme gibt, wenn zu viele Messwerte auf einmal von mehreren Sensoren kommen.
Deshalb habe ich für jeden Sensor eine eigene Verbindung zum MQTT-Broker hergestellt.

Einen Verbesserungswunsch habe ich zugegeben noch - brauche ich zwar für mich nicht, funktioniert ja jetzt bei mir dank Deiner Unterstützung - aber es würde es wohl vielen in Zukunft einfacher machen:
MQTT -Topic und Intervall / Throttling per Weboberfläche einstellbar - evtl. sogar Anzahl Zähler und jeweils genutzter GPIO

Das steht bereits auf meiner Roadmap (https://github.com/mruettgers/SMLReader#roadmap) und wird als nächstes angegangen. Ich habe auch schon konkrete Vorstellungen bzgl. der Implementierung, werde das aber vermutlich in einem neuen Projekt realisieren, und auch dann den ESP32 favorisieren (den ESP8266 versuche ich aber weiterhin auch zu unterstützen).
Mittelfristig schwebt mir nämlich auch eine Akku-betriebene Version vor, die vom niedrigen Stromverbrauch des ESP32 im DeepSleep profitieren könnte.

Das Projekt SMLReader hatte ich ursprünglich für mich während der Bauphase unseres Eigenheims erstellt, und da es bei letzterem noch genug Baustellen handwerklicher Art gibt, und meine zwei Söhne auch nicht zu kurz kommen sollen, fehlt mir nur gerade etwas die Zeit. Aber sobald ich die Zeit habe, gehe ich das mal an :-).

Viele Grüße,
Michael

[baranator]

Habe in meinem Fork nun die Grundlagen für den S0-Zähler drin, aber noch komplett ungetestet, weil mein Haus noch Baustelle ist und ich in meinem jetzigen Domizil noch kein Smartmeter habe. Wenn ich mal etwas Luft habe, teste ich das auf dem Bau aus.

Ich habe darüber hinaus auch mal probiert, die Änderungen für PangolinMqtt mit meinen zusammenzuführen, zumindest soweit, dass es kompiliert, aber ebenfalls ungetestet: baranator@33321a3

(wasserstandsmeldung; auch damit man sieht, dass was passiert und ich nicht schon die Flinte ins Korn geworfen habe ;) )

[mruettgers]

Hi kr0815,

thank you for your feedback.
I just tried to reproduce the problem here by connecting one and the same head to two different GPIO pins, but your problem did not occurr here.

Even if the meters send at the same time and SMLReader is not able to read both at the same time, the readings of the electricity meter should be read in the next loop (i.e. one second later) and then published via MQTT.
The throttling of 20sec is done per reading head and should not affect other heads.

So this issue sounds kinda hard to debug remotely.

I assume the issue persists after a reset / cold boot of the ESP8266?
What GPIO pins are you using for attaching the reading heads?

Is it possible to attach a serial console to the ESP8266 while running an SMLReader build with debug output enabled?

Thanks,

Michael

[mruettgers]

After looking at the code again, I found a bug that causes no values to be published at all after about 50 days of runtime if MQTT throttling is enabled.
However, that's a few more weeks than 3.

[kr0815]

Hi Michael,

i also have to confess - this is a really strange problem . both meters were logging to Volkszähler without any problems, then it suddenly startet

By swapping them, i´m sure it´s not a Hardware problem

yes, the issue persists after a reboot

I´m using GPIO D2 and D6

In my MQTT monitor i see messages all 20 seconds from sensor 1 - sensor 2 very seldom

of course i could attach a serial console - not sure what is flashed at the moment, but it brings some hex blocks, then says sending

i wonder why it worked for 3 weeks perfectly ( got new meters) - now it stopped

i´ve attached a screenshot -really strange

if you like, we could also write in german - kr at kr123.de

[kr0815]

"After looking at the code again, I found a bug that causes no values to be published at all after about 50 days of runtime if MQTT throttling is enabled.
However, that's a few more weeks than 3."

that´s definetly not the problem, problem persists even after a hard Reset

[mruettgers]

if you like, we could also write in german

Alles klar.
Tritt das Problem eigentlich auch auf, wenn Du kein MQTT-Throttling machst, also die Werte jede Sekunde ausgeben lässt?

[kr0815]

das habe ich zugegeben noch nicht versucht - werde aber am WE gerne mal paar andere Versionen kompilieren

Überlege auch , mal an einem Zähler die Hauptsicherung kurz raus zu machen - hätte vermutet die leiten den internen Takt aus der Netzfrequenz ab , die driften nie auseinander aber man weiss so was nie...

Ich bin leider kein Code-Experte, aber wenn ein Zähler / Leser eingesteckt ist blinkt die LED am ESP geschätzt 5 mal kurz
Sind beide eingesteckt, dann auch wieder 5 mal kurz - kurze Pause - noch 1 Mal

Ich vermute echt das da der eine Lesekopf den anderen im Code blockiert?

Ist für mich erst mal kein Problem, notfalls kommen da halt 2 ESPs ran, aber interessieren würde mich das Problem schon

[mruettgers]

Falls das Problem nur beim Throttling auftritt, die Logik habe ich gerade eben mal überarbeitet, da das nicht besonders elegant gelöst war.
Kannst Du ja sonst auch mal testen:
https://github.com/mruettgers/SMLReader/tree/throttling-rework

[mruettgers]

Die LED blinkt bei Empfang eines gültigen SML-Telegrams übrigens 3 x kurz. Kannst Du auch pro Lesekopf in der config.h deaktivieren.

[mruettgers]

Ich habe heute auch noch den MQTT-Code überarbeitet.
Nun hat jeder Sensor seinen eigenen MQTT-Client, und die Kommunikation findet zudem asynchron statt.
Bereit zum Testen hier: https://github.com/mruettgers/SMLReader/tree/mqtt-rework.
Die bisherigen Anpassungen sind in dem Branch auch vorhanden.

[kr0815]

Hallo Michael,

das teste ich morgen gerne mal, aber wie meinst Du das das jetzt jeder Sensor seinen eigenen MQTT-Client hat? Das man 2 verschiedene Topics angeben kann?

Einen Verbesserungswunsch habe ich zugegeben noch - brauche ich zwar für mich nicht, funktioniert ja jetzt bei mir dank Deiner Unterstützung - aber es würde es wohl vielen in Zukunft einfacher machen:
MQTT -Topic und Intervall / Throttling per Weboberfläche einstellbar - evtl. sogar Anzahl Zähler und jeweils genutzter GPIO

Ich bin zugegeben sehr verwöhnt von ESPEasy - mache sehr viel damit
Habe früher viel mit Arduino gemacht - kam dann irgendwann an den Punkt das ich an was bestehendem, mehrere Monate / Jahre alt - was ändern muss - bedeutet neu flashen
Wo ist jetzt der richtige Code in meinem Dateichaos? Wie ging das noch mal mit der IDE oder Platformio? Irgendwelche Libs haben sich geändert, funktioniert nicht mehr zu kompilieren,.....
Bei ESPEasy gehe ich halt auf die Weboberfläche und ändere es dort kurz ab

Ich habe Dein Projekt zufällig gefunden - mich gefreut das Du ein fertig kompiliertes Binary hast, aber dann gesehen das ich nur um die Sendeintervalle zu ändern oder einen 2. Kanal hinzuzufügen mich doch in Platformio einarbeiten muss - hat funktioniert, aber ich weiß nicht ob jeder das so hin bekommt

Hoffe du verstehst das jetzt nicht falsch - ganz tolles Projekt

Viele Grüße
Klaus

[baranator]

Hallo Klaus,

aber wie meinst Du das das jetzt jeder Sensor seinen eigenen MQTT-Client hat? Das man 2 verschiedene Topics angeben kann?

bislang hatte ich eine MQTT-Bibliothek verwendet, die synchron gesendet hat, d.h., während der Kommunikation mit dem MQTT-Broker war die Verarbeitung von weiteren potentiellen Messwerten blockiert.
Das habe ich gestern Abend auf https://github.com/marvinroger/async-mqtt-client umgestellt, dabei aber festgestellt, dass es Probleme gibt, wenn zu viele Messwerte auf einmal von mehreren Sensoren kommen.
Deshalb habe ich für jeden Sensor eine eigene Verbindung zum MQTT-Broker hergestellt.

Einen Verbesserungswunsch habe ich zugegeben noch - brauche ich zwar für mich nicht, funktioniert ja jetzt bei mir dank Deiner Unterstützung - aber es würde es wohl vielen in Zukunft einfacher machen:
MQTT -Topic und Intervall / Throttling per Weboberfläche einstellbar - evtl. sogar Anzahl Zähler und jeweils genutzter GPIO

Das steht bereits auf meiner Roadmap (https://github.com/mruettgers/SMLReader#roadmap) und wird als nächstes angegangen. Ich habe auch schon konkrete Vorstellungen bzgl. der Implementierung, werde das aber vermutlich in einem neuen Projekt realisieren, und auch dann den ESP32 favorisieren (den ESP8266 versuche ich aber weiterhin auch zu unterstützen).
Mittelfristig schwebt mir nämlich auch eine Akku-betriebene Version vor, die vom niedrigen Stromverbrauch des ESP32 im DeepSleep profitieren könnte.

Das Projekt SMLReader hatte ich ursprünglich für mich während der Bauphase unseres Eigenheims erstellt, und da es bei letzterem noch genug Baustellen handwerklicher Art gibt, und meine zwei Söhne auch nicht zu kurz kommen sollen, fehlt mir nur gerade etwas die Zeit. Aber sobald ich die Zeit habe, gehe ich das mal an :-).

Viele Grüße,
Michael

Hi!

Ich bin letztes Wochenende auf dein Projekt gestoßen und habe die letzten Tage damit verbracht mich einzulesen.

Als Anwendungszweck habe ich angedacht, den Reader um eine S0-Ausgabe zu erweitern. Mein Smartmeter besitzt keinen S0-Ausgang, für den aktuellen Stromverbrauch, meine PV-Anlage (Wechselrichter von Fronius) könnte einen solchen aber verwenden, um bei ausreichend Stromverbrauch im Haus die durch das EEG vorgeschriebene maximale Einspeiseleistung von 70% der kWp-Leistung der Anlage zu deaktivieren/zu erhöhen.

Ich habe in meinem Fork als Vorbereitung dafür bereits IoTwebconf auf Version 3.0 hochgezogen (ist bereits online) und das Grundgerüst für die Config der Sensoren per iotwebconf erstellt. Ich werde das vermutlich in Richtung des nächsten Wochenendes fortsetzen.

Etwas doof, dass sich die Arbeit nun etwas überschneidet, aber naja ;)

[mruettgers]

Hey Eike,

Als Anwendungszweck habe ich angedacht, den Reader um eine S0-Ausgabe zu erweitern. Mein Smartmeter besitzt keinen S0-Ausgang, für den aktuellen Stromverbrauch, meine PV-Anlage (Wechselrichter von Fronius) könnte einen solchen aber verwenden, um bei ausreichend Stromverbrauch im Haus die durch das EEG vorgeschriebene maximale Einspeiseleistung von 70% der kWp-Leistung der Anlage zu deaktivieren/zu erhöhen.

Ich habe in meinem Fork als Vorbereitung dafür bereits IoTwebconf auf Version 3.0 hochgezogen (ist bereits online) und das Grundgerüst für die Config der Sensoren per iotwebconf erstellt. Ich werde das vermutlich in Richtung des nächsten Wochenendes fortsetzen.

Etwas doof, dass sich die Arbeit nun etwas überschneidet, aber naja ;)

Klingt spannend, und bzgl. des Forks war ich kurz davor zu fragen, ob Du nicht einen Pull-Request machen möchtest ;-).
Allerdings möchte ich in der kommenden Version den API-first-Ansatz verfolgen (der ESP liefert ein React-Frontend zur Konfiguration von WiFi und Sensoren aus), und habe mir deshalb vorgenommen, zunächst einen Blick auf https://github.com/khoih-prog/ESPAsync_WiFiManager zu werfen.

[mruettgers]

Hallo Klaus,

ich habe gerade eben ein neues Release veröffentlicht.
Abgesehen davon, dass dort der 50-Tage-Bug behoben wird und die Überarbeitung der Throttling-Logik enthalten ist, habe ich noch die MQTT Client-Library ausgetauscht. Die jetzt verwendete (https://github.com/philbowles/PangolinMQTT) ist deutlich performanter und arbeitet wirklich asynchron. Damit ist es auch kein Problem mehr, wenn mehrere Sensoren gleichzeitig senden, und so viele Messwerte auf einmal zusammen kommen. Das vermute ich als Ursache für Dein ursächliches Problem.
Du kannst ja mal testen, ob die Probleme damit behoben sind.

Viele Grüße,
Michael

[kr0815]

Hallo Michael, probiere ich gerne die Tage mal aus :-) Bin aber zugegeben momentan sehr zufrieden wie gut alles läuft :-)

Die Pangolin Library sieht spannend aus - versuchen gerade ESPEasy mit 70 Clients gleichzeitig zuverlässig ins Netz zu bekommen - gibt schon gewisse Einschränkungen bei der pubsub Library...

Viele Grüße

Klaus