Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
Da ich die Firmware sowieso erweitern wollte, entschied ich mich auch noch das letzte grössere Teil zu implementieren.
Auf der Platine befindet sich eine oneWire Schnittstelle, die bereits elektronisch vorhanden ist (okay, ist nun auch nicht gerade die aller schwierigste Aufgabe 😁), gehört für mich aber unbedingt zu einem generischen Sensor Handler.
Da ich bereits bei einer hohen Speicherauslastung auf dem Mikrocontroller bin, entschied ich mich, es simpel zu halten und einfach nur einen Scanner sowie die Temperaturauslesung als Float umzusetzen.
Mit bekannten Arduino Libraries sollte das eine Aufgabe von vielleicht einem Tag werden, wenn überhaupt.
Wäre da nicht noch dieses kleine Problem, dass ich vorher noch nicht kannte....
Da der Scanner sicher die anspruchsvollere Aufgabe ist, startete ich damit.
Nun habe ich, aufgrund einer 100% nicht blockierenden Software, das eine oder andre zu beachten.
Nach ein paar Stunden hatte ich das ganze aufgesetzt und war bereit zum Testen. Ich schloss also ein paar ds18b20 an und begann zu scannen.
Das Ergebnis war, diplomatisch ausgedrückt, "Scheisse!".
Manchmal bekam ich die eine Adresse, dann mal die Andere, aber irgendwie niemals die korrekte Ausgabe.
Das Programm soll folgendermassen funktionieren:
Sobald der Befehlsparser den Befehl "1wire scan" erkennt, setzt er zuerst die Klassen-Variablen zurück, und scannt schrittweise. Nach jeder gefundenen Adresse generiert der Printer einen String, der umgehend über den Bus auf RS485 versendet wird.
Sobald die Busklasse meldet, dass die Nachricht übernommen wurde, wird die nächste Adresse gescannt, usw...
Alles aber immer 100% non-blocking, ansonsten würde ja nicht gleichzeitig die Nachricht verschickt werden können und die nächste Adresse gesucht. Aber genug der Details für den Moment, ich werde demnächst mal das ganze System in ein paar Artikel vorzustellen versuchen, bin aber grad bei diesen Details...
Ich versuche also nun immer wieder die Sensoren zu scannen, werfe die Dallas Library raus, wechsle auf die OneWire Library, aber immer und immer wieder das Selbe. Frustriert musste ich einsehen, dass es heute nix mehr wird und ging pennen.
Am nächsten Tag also weiter: Testen, anpassen, weiter testen, wieder anpassen, ... andere Sensoren, usw...
Auch dieser Tag schien wieder im Frust zu enden und ich war kurz davor alles zu pausieren, da entdeckte ich ein entscheidendes, kleines Detail:
In der Adresse zeigen sich gewisse Muster, die dann nach einer kurzen KI gestützten Recherche zeigten, dass ich von 5 Sensoren einen Original Analog-Devices (vorher Maxim und noch früher Dallas Semiconductor) und vier Fake Klone verwendete. Auch zeigte sich, dass die Beobachtung genau dem entspricht, was bereits diverse Entwickler und Anwender beobachteten: Inkonsistente Datenübermittlung die sich in scheinbar zufälligem "manchmal geht's, manchmal nicht" zeigt. ![]()
![]()
![]()
Schön, nun hatte ich also gute 2 Tage Codeentwicklung hauptsächlich damit verschwendet, zu erkennen wie be******en mal wieder gewisse Klone vom Aliexpress sind. Und einmal erneut bewiesen, dass Angaben chinesischer Händler nicht den Strom wert sind, den es zum anzeigen auf der Webseite braucht. . . . .
Ich mache hier jetzt aber keinen Artikel über meine Erfahrungen mit Aliexpress, darum weiter zur eigentlichen Erkenntnis:
Ich passte meinen oneWire Scanner noch etwas an und implementierte einen zyklischen Befehl "1wire scan step", wodurch jeweils nur eine Zeile ausgegeben wird, und als letztes eine Nachricht, wie viele Geräte gefunden wurden:
Schritt 1:
Hier ein Original ds18b20+
Schritt 2:
Hier ein Fake Klon
Schritt 3:
Der "Step Scan" ist abgeschlossen
So, das heisst aber auch, ich habe ebenso eine Möglichkeit, bereits beim Scannen Fake Sensoren zu erkennen.
Als nächstes aber schauen wir uns an, wie diese Fakes arbeiten. Man beachte, dass Dallas Semiconductor die Sensoren bereits werksseitig so kalibriert, dass sie auf +/- 0.5 °C genau arbeiten, was für die meisten Anwendungen mehr als präzise genug ist.
Vergleichen wir 2 Diagramme:
Links: Ein Fake China-Klon. - - - - - - - - - - - - - - - - - - - - Rechts: Ein Original von Analog Devices
Sofort fallen einem die "Pickel" in der Kurve des Fake auf, was einer Drift von gut +/- 2 °C entspricht, und somit noch gerade ca. 25% der Genauigkeit des Originals erreicht. Wie viel 2°C sind, weiss jeder, der schon mal im Winter seine Wohnung von 20° auf 18° abkühlen liess.
Klar kostet ein China Fake sehr viel weniger als ein Original, und man könnte sagen, wenn man 10 Stk. bestellt und nur einer funktioniert, ist dieser eine immer noch günstiger als ein Original. Aber sie funktionieren auch dementsprechend erbärmlich. Nix mit der versprochenen Präzision. Erschwerend kommt dazu, sie fallen regelmässig bei einer Messung aus, was meine Steuerung zum Abbruch bringt, da der rrd Datenlogger mit der Antwort nichts anfangen kann und darauf das Programm beendet.
Klar ist das ein Fehler in der Busmaster Implementierung auf dem Webserver und ich muss das irgendwie so hinbekommen, dass eine Fehlermeldung des rrd Tool nicht zum sofortigen Programmabbruch führt.
So schnell also muss ich mir kein neues Hobby suchen ![]()
![]()
Habt ihr ähnliche Erfahrungen mit Aliexpress Sensoren gemacht? Oder allgemein mit IC's? (bitte keine Antworten zu Akkus... da geht es von simplem "funktioniert nicht ganz so wie angegeben" schon deutlich in Richtung "gewerbsmässiger Betrug") Das ist ein anderes Thema.
Wie auch immer, geniesst die kommenden, heissen Tage, ich geh jetzt mal zum Fluss und überlasse meine Beete der in Python geschriebenen Automatik.
Beste Grüsse: Mike
Kommentare 2