In den letzten 4 Monaten ist beim Terkin nichts mehr passiert. Es gibt noch einen offenen PR - der hat aber mit dem Code direkt nichts zu tun.
Ursache ist, das unser Hauptentwickler derzeit anderweitig beschäftigt ist (und das liest jetzt bitte keiner als Vorwurf). Ohne Entwickler ist ein Softwareprojekt aber tot.
Da sollten wir uns zwei Fragen stellen:
lohnt es sich, Terkin weiter zu entwickeln? Was spricht dafür, was dagegen.
falls ja, was müssen wir tun, damit er weiter entwickelt wird?
Ich hab da auch Ideen dazu, aber bevor ich hier einen Sermon schreibe, würde ich gerne wissen, wer sich dafür interessiert.
Für mich stellt sich – nach den ganzen Problemen mit der PyCom-Software / Firmware als Grundlage eh die Frage, ob das der Weg für die nahe Zukunft ist. PyComs Software war und ist immer wieder banana-ware und die Frage ist, ob wir von dieser Seite weiter so “bedient” werden. Bin da etwas desillusioniert und auch gefrustet.
Wir haben schon wieder viel Zeit und Energie in I2S und FFT – btw Danke an @MKO und @cedric.cfk – gesteckt und sind immer noch am Testen, Probieren, Entwickeln und es ist noch nicht fertig, was wir mit einem Cortex M0 und Arduino in einer halben Stunde hinbekommen hätten.
Mein Präferenz geht momentan weg von MicroPython und hin zu Arduino-C und dem guten und existierenden Ökosystem, das auch viele Maker bedienen können und das gut mit Bibliothken für verschiedene Sensoren versorgt wird, meinetwegen auch mit eine PyCom WiPy oder LoPy, aber mit C-Code und externem GSM/GPRS oder LTE-Modem.
Ich denke, es war damals schon ein Fehler auf den MicroPython-Zug aufzuspringen, aber im Nachhinein ist man immer schlauer. Manchmal ist man einfach als early adopter zu früh dran.
Funktional, wenn der Terkin hiveeyes Datalogger auch von einer breiteren Imker-Basis genutz werden soll, fehlt eine Möglichkeit die Software per web interface / captive portal zu konfigurieren. Wie gesagt ist die Audio-Schiene sicher noch spannen für die Zukunft und auf Sensorik-Seite weitere Sachen wie CO2, Vibration, … Bei der Telemetrie müsste noch LTE so umgebaut werden, dass bei einem Verbindungsabbruch die LTE-Verbindung wieder aufgebaut wird. Und das (lokale) Zwischenspechern von Daten wäre eine gute Sache, um Energie zu sparen.
Was fehlt dir, @poesel denn an Funktionalität bzw. bug fixes, die noch sein müssten?
An sich ist Terkin echt Klasse aufgebaut. Es wird ja auch nicht nur Pycom Nodes unterstützt. An sich fehlt mir aktuell eigendlich nichts. Für die Beute Masse fehlt aber sicherlich noch das Webinterface und evtl ein paar weitere unterstützte Sensoren. So dass man damit z.B. auch eine Wetterstation Bauen könnte.
Terkin hat meiner Meinung aber einen entscheidenden Nachteil, un das ist wie @clemens schon angesprochen hat das Pycom-Micropython. Die Treiberunterstützung ist eher Mies und auch die extrem lange Bootzeit macht Solar oder Akkubetrieb nahezu unmöglich solange Light sleep ebenfalls nicht richtig funktioniert.
Mein Fazit wäre Terkin außerhalb des Pycom Micropython Universums weiter zu entwickeln oder auf eine Firmware mit reinem C Code zu setzen. Wir haben da ja auch schließlich einen Kandidaten.
Beerdigen würde ich Terkin aber noch nicht dafür ist es anderen Datenloggern zu weit vorraus.
Am einfachsten sollte man es erstmal in einer Gabel weiter entwickeln oder dem Chefentwickler fragen, ob ein Auserwählter Zugriffsrechte bekommt.
Erstmal vorweg: ich bin (auch) hier gelandet, weil das Projekt mit uPython programmiert wurde und nicht mit C++. Es gibt da also eine leichte Präferenz.
Die Vorstellung, das mit C++ alles einfach und bug free laufen würde, halte ich für falsch. Gerade wenn es etwas komplexer wird, ist das debuggen mit C++ kein Spaß mehr. Da ist Python deutlich angenehmer - schon weil man nicht kompilieren muss.
Unzweifelhaft ist die Menge an Code für Arduino&Co (noch) deutlich größer. Es wird auch viel mehr Hardware unterstützt.
Da kann man jetzt lange drüber diskutieren. Hängt am Ende von den persönlichen Präferenzen ab. Aber ich finde nicht, das die Entscheidung für Python grundsätzlich falsch war.
Terkin läuft nicht nur Pycom sondern auch auf dem normalen Micropython sowie auf CPython (also auf einem PC/Raspi).
Die Punkte die @clemens oben nennt, sehe ich auch. Webinterface, Audio, Sensoren, … Das fehlt im Terkin.
Die Bootzeit ist lang. Kommt aber auch durch die Komplexität des Programms. Mit weniger Features würde auch schneller gebootet. Persönlich stört mich das aber nicht, da ich keine hohe Messfrequenz brauche. Der Kritikpunkt ist aber gerechtfertigt.
Terkin ohne Python ist IMHO nicht möglich. Dazu baut das zu sehr auf Python spezifische Eigenschaften auf.
Es gibt immerhin 10 Leute, die Schreibrechte auf das Repository haben. Einen Fork kann eh jeder machen. Daran scheiterts nicht.
Mein Kritikpunkt ist, das Terkin zu kompliziert für die Aufgabe ‘Stockwaage’ ist. Das kommt mMn daher, das Terkin versucht, ein allgemeiner Datenlogger zu sein, anstatt sich auf auf die eine Aufgabe zu konzentrieren. Das macht den Code komplexer, als nötig wäre.
Andererseits ist das Programm sehr unflexibel, was den eigentlichen Ablauf angeht.
Das stimmt schon. Unflexibel würde ich nicht zwingend sagen. Allerdings kenne ich mich mit Python und seinen Möglichkeiten auch nicht sonderlich aus. Ich finde Terkin ist schon sehr flexibel, was die Sensoren und die zusätzliche Integration von Treibern an geht. für mich fehlt aber auch ein Mapping der Sensoren für die Übertragung So wie es Terkin bei der BOB Übertragung vormacht. Auch ist die Konfigurierbarkeit zur Laufzeit nicht gegeben.
Das finde ich Persönlich aber auch gut, es wird aber viel zu wenig propagiert. Wenn Terkin z.B. auch als Wetterstation, Überwachung im Haus oder sonst etwas genutzt werden kann ist das Interesse und auch die Breite der Möglichen Anwender und Unterstützer viel höher. Was eine Ausgereiftere Entwicklung bringen sollte.
Wie gesagt das sehe ich eher als ein Problem von Pycom Micropython. Der ESP32 unterstützt ja Light Sleep welches von Seiten Pycom (wie vieles weitere) ja nur sehr Stiefmütterlich behandelt wird. Es verpufft aktuell jedes mal ein vielfaches der Energie fürs Hochfahren, als er für seine eigentliche Aufgabe das Messen und senden Verbraucht.
Von denen nimmt aktuell aber kaum einer aktiv teil. Sicherlich aber auch deshalb, da kein wirklicher Fahrplan und kein Reiseziel existiert. Daher finde ich das klasse, das du die Diskussion hier angestoßen hast.
Persönlich finde ich aber C echt einiges besser, wenn es um sehr komplexe und Universelle Programme geht. Teile die für das Aktuelle Setting nicht gebraucht werden werden gar nicht erst Compiled und Aufgespielt.
Der Vorteil den Terkin dadurch hat das der komplette Code hochgeladen wird, spielt es aktuell nicht aus. Das wäre eine komfortable Konfiguration zur Laufzeit. Also von einem neuen Sensor Stecker rein, Konfigurieren-Fertig. Was auch am Stand und nicht nur am Heimischen PC gehen würde.
Ok, unpräzise ausgedrückt: Terkin ist sehr flexibel bei der Einbindung von neuen Sensoren. Das geht echt super einfach (wenn man die richtigen Stellen gefunden hat).
Mit unflexibel meinte ich vor allem die Ablaufsteuerung. Da rattert der mehr oder minder einfach eine Liste von oben nach unten ab.
Das verlangt aber einiges an Flexibilität, Komplexität und Dokumentation. Da sehe ich ehrlich gesagt nicht, woher die Resourcen dafür kommen sollen.
Man kann ja auch erstmal eine Sache gut machen ohne sich gleich die Erweiterbarkeit zu verbauen.
Micropython ist da aber auch nicht besser, eher schlechter. Ich hab aber 1.13 noch nicht ausprobiert.
Hmm, C hat nicht gerade den Ruf, komplexe Dinge einfach zu machen (außer Du willst sehr hardwarenah programmieren). Treiber für Sensoren gehen bestimmt besser in C, aber das drumherum sicher nicht.
Da stellt sich uPy sogar noch cleverer an: es werden dynamisch nur die Code-Teile geladen, die gebraucht werden. Kompilat ist aber natürlich immer kleiner als Code.
Die eigentliche Frage ist aber eine andere: möchte hier jemand den Funktionsumfang vom Terkin in C(++) nachprogrammieren? Oder gibt es schon gleichwertige Software, die wir anpassen könnten?
Solange niemand Software schreibt, ist es egal, in welcher Sprache er das nicht tut.
Gleichwertig würde ich jetzt nicht gerade sagen sondern ein Programm, welches sich eher auf seine dienste als Stockwaage konzentriert. Es ist aber auch nicht sonderlich sauber aufgebaut und läuft natürlich nicht auf so vielen Plattformen wie Terkin.
Einzige weitere Alternativen in Python die ich sehe wäre die Bob-Software etwas zu erweitern oder HoneyPy einem ESP32 zu portieren.
Ich will Terkin aber eigentlich nicht aufgeben wollen, meiner Meinung wird Mapping und ein relativ gut zu wartendes und erweiterbares Webportal so einiges an neuen Schwung bringen.
Ich habe leider noch keine praktische Erfahrung mit Terkin, da ich mit meinem Setup bis jetzt auf Arduino unterwegs bin und wohl auch bleiben werde, da ich mit der C/C++ etwas vertrauter bin als mit Python.
Es gab da wohl auch mal den Ansatz Terkin zu portieren oder parallel für beide Plattformen zu entwickeln (siehe TerkinData und Terkin). Kann da jemand was dazu sagen @Andreas?
Mein Plan ist es bis im Frühling, für mein Setup eine etwas generischere Basis zu schaffen, mit Web-Config für Wifi/MQTT mit Waage, Temperatur-Rechen und BME280 inkl. RTC für Solarbetrieb.
Ich werde mir Terkin mal etwas genauer anschauen und versuchen zumindest die Konzepte in C++ zu übernehmen. Keine Ahnung ob das klappt, aber mal schauen wo die Reise hingeht.
Ich möchte Terkin auch nicht aufgeben. Dafür kann er schon zu viel. Aber einfach nur mehr Feautures dran nageln macht es nicht besser. Wir sollten schon wissen, wohin die Reise gehen soll.
Ich hätte gerne, das sich Terkin auf die Aufgabe ‘Stockwaage’ konzentriert und den Rest erstmal außen vor lässt. Können wir uns darauf erstmal einigen?
Ob das dann Terkin 2.0 oder anderes heisst, ist mir egal. Da könnte @Andreas vielleicht was dazu sagen.
Ja wäre auch meine Idee. Wichtig wäre zumindest ein einfaches Webconfig welches sich auf die Aufgabe als Stockwaage konzentriert. Und ebenfalls ein Mapping für die Übermittlung der Sensoren, so das man ohne in Grafana rumzubasteln ein “Standard” Dashbord nutzen kann.
Für alles weitere und Spezialaufgaben kann man dann über die Config gehen.
Auf alle Fälle wäre dann die Einstiegsschwelle extrem gesunken.
Das entspricht dem, was ich auch im Kopf habe. Hab mir gestern mal den Aufbau von Terkin etwas genauer angeschaut und werde die Tage mal anfangen ein kleines Design zu machen, was wir dann diskutieren können.
Ich werde dazu dann wohl ein eigenes github Projekt anlegen… lässt sich ja dann später unter hiveeyes integrieren. Da können wir mal die Basis Anforderungen festhalten, bevor es los geht.
