Was kommt neu im Release v1.0.0

[s.ochs]

Die aktuelle Software-Version des Nano ist das Release v0.9.9. Mit dem Release v1.0.0 (oder auch v1.0.x, so genau steht das noch nicht fest), wird sich an der Software intern einiges ändern. Der begrenzte Speicher auf dem ESP8285 ist aktuell so gut wie komplett ausgenutzt. Daher müssen, für die Integration weiterer Funktionen, bisheriger Schnittstellen vereinfacht und optimiert werden. Diese Umbaumaßnahmen nehmen einiges an Zeit in Anspruch, vorallem der Umbau der Schnittstelle zum Server, über den Funktionen wie die Nano-Cloud, das Online Update und die Push Benachrichtigung abgewickelt werden, aber z. B. auch die Abfrage der aktuellen Uhrzeit.

Mit den Optimierungen werden auch einige neue Funktionen in die Software einziehen. Über diese werde ich in der nächsten Zeit immer mal wieder berichten, so lange ihr auf das Update wartet.

Solltet ihr daneben noch Anregungen oder Ideen für neue Funktionen oder Verbesserungen bestehender Funktionen haben, dann könnt ihr diese uns hier gerne mitteilen. Ich kann nicht versprechen, dass diese Anregungen alle in die Software einfließen werden, aber das WLANThermo-Projekt lebt von den Ideen seiner Anwender, weshalb wir uns über jede Anregung freuen.

 

[s.ochs]

Und los geht es mit der neuen Firmware v1.0.x. Das erste PreRelease mit der neuen Server-API ist draußen: v1.0.0-alpha. Erstmal nur was für die Mutigen unter euch. Da sich am Code einiges geändert hat, kann es hier und da noch zu ein paar "Fehlfunktionen" kommen. Wer sowas entdeckt, bitte melden.

Wichtig: Durch den Umbau ändern sich teilweise auch die Speicherplätze der Systemeinstellungen, wodurch teilweise manche Einstellungen auch verloren gehen. Daher solltet ihr vorher eure Einstellungen einmal sichern. Entweder die Daten aus dem Webinterface rausschreiben, Screenshots machen oder die Browser-Schnittstellen "IP/data" und "IP/settings" einmal aufrufen und die Textausgabe in einer Datei abspeichern, da stehen alle wichtigen Token, Keys etc. drin. Konkret sind bei einem Update von v0.9.x auf v1.0.0-alpha die Push-Einstellungen betroffen. Am besten sichert man aber alle Werte einmal, da sich auf dem Weg zum offiziellen Release v1.0.0 noch mehr ändern wird.

Was erwartet euch?
Die Schnittstelle zum WLANThermo Server wurde vereinfacht und komplett auf eine JSON-Verarbeitung umgebaut. Ziel war/ist es die Schnittstelle robuster zu gestalten. So wird bei einem Serveradresswechsel nun automatisch auf die neue Adresse umgestellt und die System-Uhrzeit wird jetzt bei jedem Serverkontakt kontrolliert. Zudem können neue Funktionen durch die JSON-API leicht ergänzt werden. An der Bedienoberfläche gab es bisher nur kleine Änderungen, da werdet ihr also keine großen Veränderungen feststellen. Neu ist, dass ein Push Alarm nun wiederholt werden kann, bis zu 10x (für die mit richtig tiefem Schlaf). Im Webinterface wird die Anzahl an Wiederholungen ausgewählt, ein Alarm wird dann entsprechend oft alle 15s erneut gesendet, sofern er noch besteht. Im Zuge des Umbaus habe ich auch noch die Servo-Ansteuerung und den MQTT-Startprozess überarbeitet. Der Pitmaster lief bei Servo-Betrieb früher im 50 Hz-Takt des Steuersignals. Nun sind der Steuertakt und der Pitmasterintervall voneinander getrennt (wie bei SSR und FAN), wodurch der Pitmaster "ruhiger" wird. Die Thingspeak-Anbindung ist noch drin, wurde vom restlichen Code aber schon soweit separiert, dass es leicht entfernt werden kann (siehe hierzu die Umfrage: https://forum.wlanthermo.de/threads/thingspeak-anbindung.171).

Dann erstmal viel Spaß beim Testen, demnächst geht es weiter.
Steffen

 

[s.ochs]

@Epse hat den ersten kleinen Bug gefunden. Wer von einer v0.9.x auf die v1.0.0-alpha updatet, der muss nach dem Update einmal manuell neu starten. Dann wird das Update nochmal wiederholt, danach passt es dann. In der neuen Firmware wird das von der alten Firmware vor dem Update gesetzte Updateende nicht sauber erkannt, weil sich der Prozess geändert hat. Da fehlt eine Zeile im Code. Wird in der nächsten Version korrigiert.

 

[s.ochs]

Weiter geht's mit dem PreRelease v1.0.0-beta.

Dieses mal lagt der Fokus auf dem Pitmaster-Prozess. Der wurde internen nochmal komplett neu strukuriert, sodass es beim Umschalten des Aktors oder des kompletten Profils im laufenden Prozess zu keinem Fehler in der Ansteuerung des Aktors kommen kann. Zudem habe ich den Autotune als eigenen Modus entfernt und ihn stattdessen als Teil des AUTO-Modus ins Profil integriert. Der Autotune wurde dabei komplett überarbeitet, weg vom Relay Feedback Test hin zur Auswertung einer Sprungantwort mit verbesserten (eigenen) Schätzfunktionen. Aktuell lässt sich der Autotune nur für den ersten großen (> 15% Abweichung) Sollsprung aktivieren. Wenn sich das als zielführend erweist, wird das eventuell erweitert, sodass er bei jedem größeren Sprung (Abweichung zur Solltemperatur > 15% von Soll) durchgeführt wird. Das geht, weil der Autotune den eigentlichen Auto-Modus nur geringfügig verlängert. Genaue Details später noch.
Zudem ist der _a PID-Regler entfernt worden. Also aufpassen, wer auf das PreRelease updatet, verliert dabei auch seine _a-Werte für sein System. In den meisten Fällen, wird der _a aber eh nicht gebraucht, weshalb er auch Platz gemacht hat, für neue Funktionen.

Den kleinen Bug beim Updateprozess habe ich korrigiert. Ein Update von einer v0.9.x-Version sollte jetzt also ganz normal ablaufen und am Ende auch richtig beendet werden.

 

[DerPapa]

Das Update wird angezeigt, aber wenn ich es auswähle, passiert nix. Von 1.0 Alpha auf Beta.

Grüßle
Armin

 

[s.ochs]

Armin, kannst du bitte mal versuchen, das Update manuell über "IP/update" und dann "v1.0.0-beta" zu starten? Das sollte auf jeden Fall gehen (habe ich auf jeden Fall schon so gemacht). Eventuell habe ich im automatischen Update noch einen Bug.
[automerge]1541958878[/automerge]
Ok, sieht nach einem Bug im automatischen Update aus. Manuelles Einleiten des Updates funktioniert aber. Betrifft aktuell also nur die Betatester, die das automatische Update angezeigt bekommen. Alle anderen müssen ja eh manuell das Update einleiten.

 

[DerPapa]

Hat geklappt!

 

[s.ochs]

Fehler gefunden. Wird im nächsten Update korrigiert.

 

[Gefrierbrand]

Zwei Dinge sind mir vorhin aufgefallen:
1. Normalerweise steht im Webinterface oben links der Name der Nano. Nach dem Start hatte ich dort aber trotz WLAN-Verbindung und Erreichbarkeit des Webinterface "undefined" stehen.

2. Ich wollte 2 Maverick-Fühler anschließen, diese wurden aber nicht erkannt und nicht im Webinterface angezeigt.
Bei der Ursachensuche ist mir aufgefallen, dass die Buchsen, an die ich die Fühler anschließen wollte, mit dem Profil "iGrill 2" definiert waren.
Das sieht man aber nur, wenn KEIN Fühler angeschlossen ist. Sobald irgendein funktionierender Fühler angeschlossen ist, lassen sich falsche Profile (hab nur von Preset "iGrill 2" mit "Maverick" getestet, nicht andersrum!) nicht umstellen. In v0.9.9 wurden dann zwar falsche Werte angezeigt, ab man konnte das Profil auf das richtige Profil umstellen. Dies funktioniert unter v1.0.0-beta nicht.

 

[s.ochs]

1. Normalerweise steht im Webinterface oben links der Name der Nano. Nach dem Start hatte ich dort aber trotz WLAN-Verbindung und Erreichbarkeit des Webinterface "undefined" stehen.

Einfach das Webinterface noch mal refreshen, dann sollte der Name wieder da stehen

Das sieht man aber nur, wenn KEIN Fühler angeschlossen ist. Sobald irgendein funktionierender Fühler angeschlossen ist, lassen sich falsche Profile (hab nur von Preset "iGrill 2" mit "Maverick" getestet, nicht andersrum!) nicht umstellen.

Ist richtig so. Ist ein Spiel zwischen Übersichtlichkeit und Funktionalität. In Summe wird man weniger oft das falsche Profil haben, wie ungenutzte Kanäle, deshalb der Vorzug bei der Übersichtlichkeit.

In v0.9.9 wurden dann zwar falsche Werte angezeigt, ab man konnte das Profil auf das richtige Profil umstellen. Dies funktioniert unter v1.0.0-beta nicht.

Das kann sein, ich habe beim Umbau auf v1.0.0-x den "sinnvollen" Bereich etwas weiter beschränkt um Fehlmessungen zu vermeiden. Das es bei v0.9.9 "funktioniert" hat, war Zufall, bei anderen Kombinationen aus "falschem" Profil und eingestecktem Fühler wurde da teilweise auch nix angezeigt. Kommt drauf an, wie weit weg die Basiswiderstände sind. Aber da die 1000K und 100K die häufigsten verwendeten sind, schau ich mal, ob ich die Spanne wieder soweit öffne, dass zumindest bei den beiden es wieder funktioniert. Danke für den Hinweis!

Edit: "dass zumindest bei den beiden es wieder funktioniert", bei Raumtemperatur!

 

[Gefrierbrand]

? Alles klar!
Noch was fällt mir gerade unterwegs auf:

So sieht meine Cloud und die Wertebereiche der Cloud momentan aus!?

Thermo läuft seit ca. 14.30h mit 4 Sensoren, weil ich noch auf der Suche nach dem Defekt des einen „Mavericks“ bin!

 

[s.ochs]

Du hast einen Datensatz mit falschem Zeitstempel innerhalb der Aufzeichnung. Ich nehme mal an, der kam beim Update zustande. Gestern Abend gegen 21:26 Uhr, kommt das hin? Leg dir am besten einen neuen Token an.

@Phantomias2006: es sind die Einträge 6975371-6975373. Vermutlich entstanden, als das Update lief, die Zeitstempel passen zu einem Nano, was ohne Zeitabgleich lief. Normalerweise fängst du das ja ab, auch bei der Version mit Memory? Vermutlich nicht, da müssen wir uns was überlegen.

 

[Gefrierbrand]

Zeit könnte stimmen und neues Token behebt es! ?

Edit: naja, fast! ??
Schau mal:





Edit 2:
Nach Neustart des Nano

 

[s.ochs]

Ja, da sind wir schon dran. Da klappt eine neue Funktion noch nicht so richtig.

 

[Gefrierbrand]

Ich wollte gerade auf Thingspeak den Akkuverlauf checken, aber da werden seit 12 Tagen keine Daten mehr geschrieben. Passt mit dem Update auf v1.0.0-beta überein.

Ist die Schnittstelle doch schon deaktiviert?

 

[s.ochs]

Nein, noch ist der Code nur separiert, sodass ich ich ihn leicht abschalten kann. In v1.0.0-beta ist die Schnittstelle noch aktiv, teilt sich aber mit der Cloud einen Client. Schalt mal die Cloud ab oder stell den Sendeintervall der Cloud auf 60s und den von Thingspeak auf 30s.

 

[Gefrierbrand]

Alles klar, funktioniert durch deaktivieren.

 

[s.ochs]

Ich habe "vergessen" zwischen dem Senden von Cloud und Thingspeak einen zeitlichen Versatz zu setzen, der nicht ein Vielfaches des kleinsten Sendeintervalls ist. Da sich beide einen anderen Client teilen und die Cloud Vorrang hat, wird Thingspeak nicht ausgeführt, wenn sie zur gleichen Zeit gesendet werden sollen (gleicher Intervall oder bei jedem treffenden Vielfachen). Da Thingspeak aber ja vermutlich eh fliegt ...

 

[Gefrierbrand]

Momentan finde ich Thingspeak sehr praktisch, weil ich mit Michael an nem Akku-Problem hänge und so gut die Kapazitätsverläufe protokollieren und in Excel exportieren kann!

 

[Phantomias2006]

Momentan finde ich Thingspeak sehr praktisch, weil ich mit Michael an nem Akku-Problem hänge und so gut die Kapazitätsverläufe protokollieren und in Excel exportieren kann!

Schick mir mal deinen Cloud Token oder deine SN der Nano...