gemu2015
Verbesserung der Lesbarkeit der Dokumentation für Scripting (TAS)
ToDo:
Einarbeiten der folgenden Referenzen: [ ] https://github.com/gemu2015/Sonoff-Tasmota/issues/67#issuecomment-3437246763 [ ] https://github.com/arendst/Tasmota/discussions/24039 [ ] https://github.com/ottelo9/tasmota-sml-script/issues/12 [ ] Tabelle mit "feature comparison" von rules, Berry und TAS einfügen [ ] automatisch erzeugte interne code Doku Referenz einfügen [ ] syntax für KI LLMs verständlich machen (analog .doc_for_ai)
Originally posted by @mi-hol in #6
Hier als Erinnerung für weitere Verbesserungen angelegt um das Issue im nicht passenden Repository von Ottelo9 zu schliessen.
Dort sind die Scripte "eingeklappt" und stören beim Scrollen nicht. Das wäre meiner Meinung nach die bessere Option auf bei der Scripting Doc für alle Scripte. Da würden auch die sehr grossen Scripte nicht stören.
Aus meiner Sicht ist "nicht stören" der falsche Ansatz für das erlernen neuer Fähigkeiten. "eingeklappter" code funktioniert für die im Durchschnitt nur ca 15 Zeilen langen Skripte gut, aber schon bei dem folgenden Beispiel nicht mehr gut, da nur Teile des codes in das sichtbare Fenster passen. Der Rest wird sowohl vertikal, als auch horizonal, abgeschnitten! Wenn ich aber unbekannten code verstehen will, brauche ich die vollständige und spezielle Ansichten, das geht aber nMn nur sinnvoll in einem Editor (zB VS Code).
Habe gerade extrem wenig Zeit und kann mich nicht selbst darum kümmern.
Meine Hilfe habe ich ja angeboten, wie kommen wir da weiter?
Schlechtes visuelles Beispiel für "embedded code":
Kleine Verbesserung durch "replace dropbox with github link" siehe Details in https://github.com/ottelo9/tasmota-sml-script/pull/9
@gemu2015 in der offiziellen Doku gibt es die Image gallery of various Tasmota scripts und das Versprechen "i will provide the sources later."
-
Mir scheint dieser source code ist bereits im Ordner tasmota/scripting vorhanden. Ist das richtig?
-
Dein fork von Tasmota wird aber wohl nie mit dem Original synchronisiert und zeigt deshalb für erfahrene git user beunruhigende Statistiken.
Um für die Doku ein stabile Umgebung zu habe, würde ich folgende Änderungen vorschlagen:
- diesen Ordner in ein eigenes Repo zu verschieben
- ich verschiebe dann die Bilder aus der Doku in dieser Repo
- referenziere in der offiziellen Doku dann dieses Repo
- lösche das "Versprechen"
Was meinst Du zu dem Vorschlag?
@gemu2015 in der offiziellen Doku gibt es die Image gallery of various Tasmota scripts und das Versprechen "i will provide the sources later."
- Mir scheint dieser source code ist bereits im Ordner tasmota/scripting vorhanden. Ist das richtig?
- Dein fork von Tasmota wird aber wohl nie mit dem Original synchronisiert und zeigt deshalb für erfahrene git user beunruhigende Statistiken.
Um für die Doku ein stabile Umgebung zu habe, würde ich folgende Änderungen vorschlagen:
- diesen Ordner in ein eigenes Repo zu verschieben
- ich verschiebe dann die Bilder aus der Doku in dieser Repo
- referenziere in der offiziellen Doku dann dieses Repo
- lösche das "Versprechen"
Was meinst Du zu dem Vorschlag?
@gemu2015 würde mich über Feedback freuen, ansonsten bleibt mir nur das Thema zu schließen.
es haben sich so gut wie keine user für diese komplexen scripte interessiert. deshalb habe ich das nicht weiter verfolgt zumal das Tasmota Team nur Berry Scripting haben möchte. Ich habe ja meine IObroker Installation auf einem Raspberry komplett eingestellt und alles auf ESP implementiert inclusive Datenbank. Das läuft bei mir schon seit Jahren. Das hat aber keine Nachahmer gefunden. Wenn du willst kannst du gerne die scripting Doku aufräumen. Allerdings kann ich nicht alle Sourcecodes veröffentlichen da dort teilweise interne Referenzen vorkommen die man zuerst unkenntlich machen müsste.
es haben sich so gut wie keine user für diese komplexen scripte interessiert. deshalb habe ich das nicht weiter verfolgt zumal das Tasmota Team nur Berry Scripting haben möchte.
Danke für die Offenheit. Dann überdenke ich das nochmal. Ich bin auf deine "Tasmota scripting language" via https://ottelo.jimdofree.com gekommen.
Wären es denn machbar die Stromzähler Scripte von Ottelo9 auf Berry zu konvertieren ohne Funktionen zu verlieren?
Wären es denn machbar die Stromzähler Scripte von Ottelo9 auf Berry zu konvertieren ohne Funktionen zu verlieren?
Ich bin nicht direkt von eurer Diskussion betroffen, bin aber als follower von @gemu2015 darauf aufmerksam geworden. Ich habe selbst Strom- und Gaszähler per Scripting in Betrieb und beschäftige mich seit Wochen mit Berry. Fazit von mir ist, dass Gerhard (zu der entsprechenden Zeit) tolle Arbeit geleistet hat, aber der Zahn der Zeit Richtung ESP32 und Berry ab geht. Beide (Scripting und Berry) uptodate zu halten wäre Resourcen-Verschwendung. So wird die Transformation nach Berry sinnvoll und dringend. Daher hoffe ich, dass Gerhard die Muße findet, sein Baby mit Berry zukunftsfähig zu machen. Das schreibe ich als moralische Unterstützung ohne Kenntnis, ob einfache Scripte schon in einer Berry-Version existieren. Zu den aufwendigeren Scripten von Ottelo sollte man ein Script herauspicken und beim Umschreiben in Berry feststellen, wo es vielleicht hakt. Just my 2 cents
Zu den aufwendigeren Scripten von Ottelo sollte man ein Script herauspicken und beim Umschreiben in Berry feststellen, wo es vielleicht hakt.
@pewibe das ist ein sehr guter Vorschlag, ich habe https://github.com/ottelo9/tasmota-sml-script/blob/main/2_SML_Script_Chart_PV.tas im Einsatz Welches verwendest Du?
Die Frage nach den Scripts führt uns (in meinem Fall) nicht weiter, da ich selbstgeschriebenes (z.B. für einen Gaszähler) verwende, das keine schönen Diagramme produziert, was die meisten wohl haben wollen:
Tasmota Gasmeter 3.42 (script).txt
So kommen wir zurück auf die Suche nach einem Freiwilligen, der ein Script in Berry transferieren könnte. Hier kämen zuerst Personen in Frage, die den größten Druck nach einer Script-Transformation haben oder Gerhard in der Hoffnung, dass es ihm als Insider am leichtesten von der Hand geht. :-)
Ich selbst bin momentan noch im Berry-Lernstadium und mit einer Steuerung für eine Wasserstandsregelung mit Berry beschäftigt. Danach (Zeitpunkt noch unbekannt) würde ich sogar mein o.a. Script in Berry umsetzen, um das Gelernte anzuwenden und das alte Script loszuwerden. Ich bin sicher, das geht, hilft aber dir in deinem Script nicht komplett.
Schwieriger wird es mit /meinem Stromzählerscript, was zumindest vom Kern eher deinem Script entspricht. Hier weiß ich heute nicht, wie man die Meter-Section ">M" und das Initialisieren des Sensors in Berry umsetzt, bzw. nehme an, es geht nicht ohne tiefe Kenntnisse der SML. Event. könnte https://github.com/chhartmann/tasmota_berry_sml_driver/blob/main/smlparser_test.be Teil einer Lösung sein. Leider hat der Urheber des Treibers Code ohne eine einzige Kommentarzeile veröffentlicht und das Readme besteht aus einer Überschrift. Hier wird wohl die Hilfe von @gemu2015 benötigt. Warten wir ab, bis er sich hierzu nochmals meldet.
Ich frage mich warum ihr funktionierende Scripte auf Berry umschreiben wollt ? Es gibt dadurch keine funktionellen Vorteile. Der SML Treiber würde rein in Berry sicher nicht funktionieren weil viel zu langsam. Es gab mal einen Versuch dazu bei dem sich gezeigt hat dass der Treiber dauernd stockt. Der SML Treiber ist aber eng verwoben mit scripting so das es wenig Sinn ergeben würde das zu trennen. Berry kann und wird Prinzip bedingt kein Multitasking können was ich in scripting oft verwende damit es nicht stockt. Ausserdem habe ich noch viele ESP8266 laufen die nur mit scripting laufen. Meine Geräte kommunizieren auch alle mit globalen Variablen die es bei Berry nicht gibt. Auch gibt es einige andere features die ich verwende die Berry nicht hat. (z.B. Datenbank) Ich werde also definitiv nichts nach Berry konvertieren. Auch verstehe ich nicht warum einige immer unbedingt die neueste Variante einer Software haben wollen wenn die bisherige doch einwandfrei arbeitet und das tut was ich brauche. Bei einigen ESPs habe ich noch alte Tasmota Versionen laufen und werde sie auch ohne Not nicht ändern. Ich selbst arbeite gerade an anderen Dingen aber falls jemand ein feature in scripting braucht oder einen Fehler findet werde ich natürlich helfen.
PS da sich scripting und Berry im Prinzip vertragen kann ja wer will beides parallel benutzen.
Updated:
Ich frage mich warum ihr funktionierende Scripte auf Berry umschreiben wollt ?
@gemu2015 ich möchte funktionierende Scripte erweitern/verbessern, stoße aber dabei immer wieder an Grenzen, da ich die Skripte nicht vollständig verstehe. Ich habe Programmieren in den 1980er Jahren gelernt und bei verschiedenen Scriptsprachen bis heute angewendet. Bin also der Meinung, dass ich scripten kann :)
"Verstehen" erreicht man durch gute Dokumentation und heute vor allem durch Hilfe von KI. Bei beiden Punkten hat Berry mMn einen deutlichen Vorsprung gegenüber Tasmota scripting (TAS). KI erfordert eine "maschinenlesbare Syntax Definition der Programmiersprache" (Reference Manual) & .doc_for_ai folder referenziert im Kommentar https://github.com/arendst/Tasmota/discussions/23565#discussioncomment-14064131), die fehlen bisher bei TAS! Für Berry ist das Reference Manual auf https://berry.readthedocs.io/en/latest/source/en/Reference.html
Um also den beschriebenen "Rückstand" auszugleichen, erfordert es für TAS viel Arbeit.
Der SML Treiber würde rein in Berry sicher nicht funktionieren weil viel zu langsam. Es gab mal einen Versuch dazu bei dem sich gezeigt hat dass der Treiber dauernd stockt. Der SML Treiber ist aber eng verwoben mit scripting so das es wenig Sinn ergeben würde das zu trennen. Berry kann und wird Prinzip bedingt kein Multitasking können was ich in scripting oft verwende damit es nicht stockt. Ausserdem habe ich noch viele ESP8266 laufen die nur mit scripting laufen. Meine Geräte kommunizieren auch alle mit globalen Variablen die es bei Berry nicht gibt.
Danke, das ist eine sehr gute Zusammenfassung der Vorteile von TAS gegenüber Berry! Gibt es das vielleicht schon anderswo geschrieben, so dass man es in ein Reference Manual einfügen kann?
Auch gibt es einige andere features die ich verwende die Berry nicht hat. (z.B. Datenbank)
Was meinst Du mit "Datenbank"? Gerne Referenz auf Forum post, etc
falls jemand ein feature in scripting braucht oder einen Fehler findet werde ich natürlich helfen.
@gemu2015 das ist super, damit das Angebot genutzt werden kann, wäre es hilfreich das "how to get help" in der Doku zu definieren. Ich selbst bin mir da auch unsicher wie & wo man da am besten schreibt. Ist das discussion forum https://github.com/arendst/Tasmota/discussions/categories/scripter-sml die richtige Stelle?
Das wichtigste neue Dokument für TAS scheint mir ein Äquivalent für .doc_for_ai/FOR_DEVELOPERS.md zu schreiben. @gemu2015 wie siehst Du das?
Datenbank: ich schreibe alle 15 Minuten sämtliche gemessenen Werte meines Hauses mit einem ESP32 auf SD Karte mit zusätzlicher Indexdatei. Die Datenbankfuntion kann dann jedes beliebige Datum mit Range extrahieren und auch zusammenfassen damit man das Anzeigen kann. Funktion fxt()
Du kannst Fragen bei Tasmota posten oder auch hier bei mir.
Wenn du willst kannst du gerne in meinem Repository eine eigene Docs Sektion aufbauen die wir dann unabhängig von Tasmota bearbeiten können. Wenn es dann mal fertig ist kann man überlegen das zu Tasmota zu transferieren.
Man kann wohl inzwischen mit Hilfe von AI sich sehr viel Arbeit abnehmen lassen.
Die Datenbankfuntion kann dann jedes beliebige Datum mit Range extrahieren und auch zusammenfassen damit man das Anzeigen kann. Funktion fxt()
Das muss unbedingt in https://tasmota.github.io/docs/Scripting-Language/#features Obwohl ich mich seit über einem Jahr mit TAS beschäftige, ist mir das bisher nicht aufgefallen!
"Other commands (+?? flash)" hört sich dafür viel zu unscheinbar an! Wäre "time series database" der richtige Begriff dafür?
Fragen bei Tasmota posten
Ich präferiere nur eine häufig frequentierte Stelle zu dokumentieren. Es wird also das Tasmota discussion forum https://github.com/arendst/Tasmota/discussions/categories/scripter-sml
Wenn du willst kannst du gerne in meinem Repository eine eigene Docs Sektion aufbauen die wir dann unabhängig von Tasmota bearbeiten können. Wenn es dann mal fertig ist kann man überlegen das zu Tasmota zu transferieren.
Wegen der in https://github.com/gemu2015/Sonoff-Tasmota/issues/67#issuecomment-3207926494 dargelegten Gründen 1.) & 2.) und deiner Admin Berechtigung präferiere ich inzwischen direkt das offizielle Tasmota Repo zu verändern. Passt das?
@gemu2015
Ich frage mich warum ihr funktionierende Scripte auf Berry umschreiben wollt ? Es gibt dadurch keine funktionellen Vorteile.
Richtig, aber die Antwort gibst du dir selbst, weil es auch andere Vorteile gibt. Ich verstehe z.B. nach einem Jahr meine eigenen Scripte (fast) nicht, weil halt alles sehr kryptisch anmutet.
Der SML Treiber ist aber eng verwoben mit scripting so das es wenig Sinn ergeben würde das zu trennen.
Auch richtig, aber das "eng verwobene" ist gleichzeitig die Crux. Jeder weiß, dass man eine Software erst zum funktionieren bringt und dann nochmals schreiben müsste, um sie übersichtlich und gut strukturiert zu haben. Warum nicht deinen Treiber im Realzeitteil so lassen, ihm mit einer Initialisierung die Parameter aus der Meter-Section mitgeben und die Darstellung der gelesenen Werte an der Oberfläche mit einer Callback-Function versehen?
PS da sich scripting und Berry im Prinzip vertragen kann ja wer will beides parallel benutzen.
Hierzu noch eine Frage: Ich bin in das Scripting mit einem Fork von V12.4.0 von dir eingestiegen und habe die immer noch am Laufen, weil ich nicht weiß, ob die Korrekturen von dir von damals mittlerweile in der offiziellen Tasmota-Version enthalten sind?
ob die Korrekturen von dir von damals mittlerweile in der offiziellen Tasmota-Version enthalten sind?
Nein, denn die offiziellen Tasmota-Versionen haben TAS nicht aktiviert/inkludiert. Die korrigierte Version (inklusive TAS) ist auf https://github.com/ottelo9/tasmota-sml-images/releases
@Pewibe die scripter Version in Tasmota dev ist aktuell vor 2 Wochen das letzte Mal von mir aktualisiert worden.
"Other commands (+?? flash)" hört sich dafür viel zu unscheinbar an! Wäre "time series database" der richtige Begriff dafür?
@gemu2015 es geht ja schnell was unter in aktiven Diskussion, das passiert einfach. Darf ich dich an diese offene Frage erinnern?
Ja ist schon besser, aber ist nicht nur data base sondern auch time format conversion functions.
offene Frage:
- wieviel kB verbraucht die Aktivierung von USE_FEXTRACT
geplante Änderung der Doku:
- Reihenfolge von "Features" und "optionally enabled Features" umkehren
- statt der Tabelle "optionally enabled Features" am Anfang, lösche ich die Tabelle und erzeuge für jeden einzelnen "compiler directive" einen Unterpunkt in "optional Features"
- Dort kommt ein "short feature name", description und das zugehörigen "compiler directive"
Beispiel:
statt: USE_FEXTRACT | enables array extraction from database fxt(...), fxto() and tso(), tsn(), cts(), s2t() functions
neu:
Features
optional Features (require enabling at compile time)
time series database
enables a time series database with associated time-based functions
compiler directive: USE_FEXTRACT
Passt das besser? Falls nein, bitte das wording anpassen, sonst wird das nix!
@gemu2015 weisst Du vielleicht warum "For ESP32 builds it is recommended to use Berry"" in der Doku steht oder von wem es reingemacht wurde?
USE_FEXTRACT braucht ca 2kB
"For ESP32 builds it is recommended to use Berry"
stammt nicht von mir, ist plötzlich mal drin gewesen.
Es gibt einige die Berry als Standard durchsetzen wollen und scripter als Konkurrenz empfinden.
Es gibt einige die Berry als Standard durchsetzen wollen und scripter als Konkurrenz empfinden.
Meine Wahrnehmung war auch, dass es da "persönliche Präferenzen" gibt. Deshalb wollte ich eine Tabelle mit "feature comparison" von rules, Berry und TAS einfügen, dann kann jeder Nutzer informiert für sich entscheiden.
Beispiel: bei den Punkten mit ? bin ich mir nicht sicher!
| Scripting language availability | ESP8266 (OOB image) | ESP32 (OOB image) | ESP8266/ESP32 (Custom image) |
|---|---|---|---|
| rules | Yes | Yes | Yes/Yes |
| Berry | No | Yes | No/Yes |
| TAS | No | No | Yes 1.) /Yes |
1.) script size limits apply!
feature comparison of available Scripting languages
| Feature availability | TAS | Berry | rules |
|---|---|---|---|
| SmartMeter Language (SML) | Yes | Yes 2.) | No |
| multitasking | Yes | No | No |
| time series database | Yes | No | No |
2.) certain SmartMeters have interface requirements beyond Berry capabilities!
rules sind so gut wie immer dabei. Das hat Theo "erfunden" und deshalb da es nur alternativ zu scripter geht ist er nicht für scripting
rules sind so gut wie immer dabei. Das hat Theo "erfunden" und deshalb da es nur alternativ zu scripter geht ist er nicht für scripting
Bin nicht sicher, dass ich die Antwort vollständig verstehe. Darf ich dich deshalb bitten, diese Aussage als Korrektur der obigen Tabelle zu posten? Damit "wandert" es dann auch automatisch richtig in die Doku :)
Vergiss bitte nicht auf https://github.com/gemu2015/Sonoff-Tasmota/issues/67#issuecomment-3437246763 zu antworten
siehe oben editiert
Perfekt! So funktioniert die Zusammenarbeit! PR kommt nächste Woche
Nur mal so 2 Bemerkungen aus Sicht eines kaum Beteiligten:
- Man kann meiner Erfahrung nach eine Dokumentation nicht ohne enge Bindung mit dem Urheber der Software machen. Ihr solltet dazu z.B. einige Sitzungen mit gemeinsamen Zugriff auf das gleiche Dokument haben, sonst geht das noch bis Sankt Nimmerlein.
- Die Industrie stellt kaum noch (oder garnicht mehr?) neue Geräte mit ESP16 her. Die biologische Lösung wird sein, dass der ESP32 und der innere Kreis von Tasmota Berry so nach vorn bringen, dass der Scripter - so gut und einzigartig er mal war - wie ein Mauerblümchen vertrocknen wird.