Entwicklung: Temperatur Funk Sensor

  • Hat jemand eine Ahnung wie es zu den vielen Nachkommastellen kommt? Tritt nur selten auf.

    Rundungsfehler können das nicht sein, im Adapter werden die Werte nur durch 100 geteilt um die Kommastelle richtig zu setzen.

    Ich glaube ich hab das auch schon mal beim Parser-Adapter gesehen. Passiert sehr selten, aber passiert.

    Ich kann ja mal versuchen mit den Datentypen ein bisschen herum zu spielen, vielleicht hilft das.


    Die drei Interupts kann ich verwenden, in dem ich den entsprechenden Pin auf GND ziehe? Der Adapter unterstützt das aber noch nicht, oder?

    Wenn du den Ausgabe-String mit Interrupt postest, kann ich das bestimmt umsetzen.


    Kennt jemand den Xiaomi "Blume Monitor"?

    Könnte man mit dem TiNo und diesen Sensoren etwas ähnliches zusammen bauen?

    Mit ein wenig Bastelarbeit evtl. damit?:

    https://www.makershop.de/senso…nfeuchtigkeit-hygrometer/

  • Wenn du den Ausgabe-String mit Interrupt postest, kann ich das bestimmt umsetzen.

    Da warten wir lieber auf das Update, bzw. auf den Experten :)

    Mit ein wenig Bastelarbeit evtl. damit?:

    Nein, nicht damit. Die korrodieren dir schneller weg als Du gucken kannst. Nur kapazitive Sensoren verwenden, siehe hier.
    Die Frage war, ob der Stromverbrauch gering genug ist um diese sinnvoll mit dem TiNo zu betreiben.


    Gruß

    LED

  • Die drei Interupts kann ich verwenden, in dem ich den entsprechenden Pin auf GND ziehe? Der Adapter unterstützt das aber noch nicht, oder?

    richtig. Im Prinzip sind die Interrupts bereits verwendbar. Sie sind bitcodiert im letzten Parameter des 'data' Teils.

    NodeId,66,s=-52.50,data:OK;1655;195;3140;69.50;1;,FEI=-16,T=37,biterrors=0

    Hier ist es '1'. Die '1' besagt nur dass das System in Ordnung ist ("heart beat"). Interupts sind in den bits 1 bis 4 codiert, eine Null heisst "kein Interrupt ausgeloest" und eine '1' heisst"es wurde ein Interrupt ausgeloest". Also wenn der Parameter '4' ist, ist das binär b0 0100, d.h. der Interrupt #2 wurde ausgeloest. Also, Interupt #1 steht für die 2, Interrupt #2 für die 4, etc.


    Aber ich werde das Anfang September in der Interface Spezifikation genau darstellen. Das gegenwärtige Interface gibt es dann nicht mehr, ich passe mich dem TinyRx4 Interface an.


    Wollte nur "Mal eben" Python unter Windows installieren und ein Skript testen. Google Suche: Python Download Windows... und man bekommt natürlich erst Mal Python3. Dann versuch Mal ein Downgrade auf Python2 zu machen... aaargh und bis dann die serielle Schnittstelle läuft sind aus "mal eben" ein paar Stunden geworden.

    auf dem Raspberry Pi unter Raspbian ist Python in beiden Versionen vorinstalliert.... nur so als Tip.

    Auf dem Windows PC ist das ein wenig komplizierter, aber eigentlich nicht viel. Man muss nicht einmal mehr die Pfad Variable selbst einstellen.

    Die Installation des serial -Moduls ist eigentlich recht einfach, aber ich versteh' schon, wenn man das noch nie gemacht hat, dauert es halt.


    Ich habe übrigens zum Testen Python2.7 und Python 3.7 parallel auf dem Win10 Rechner am Laufen, zu dem Zweck hab ich bei Python 3 die "Python.exe" in "Python3.exe" umbenannt. Das ist zwar brutal, aber so kommen sich die Python Versionen nicht in die Quere.


    Im Anhang das Tool mit Python3 Unterstützung, Python2.7 sollte auch noch funktionieren!

  • Sehr schön, ich brauche dann noch Mal eine genaue Anleitung an welchen Pin ich was anschließen kann. So in Form von Taster, Reed-Kontakt, Relais etc. Im Grunde kann der TiNo für so ziemlich alle Meldungen von Wasserrohrbruch bis Klingel, Briefkasten offen und Brief drin, Garatentor zu oder auf usw. verwendet werden. Und ich könnte einen TiNo ins Auto einbauen und über einen Taster das (Garagen-)Tor öffnen, Licht einschalten und wüsste immer wie warm es im Auto ist. Mit einem Erschütterungssensor (oder direkt einen Kontakt an die Zündung) wüsste ich auch wenn sich mein Auto (autorisiert oder unautorisiert) vom Acker macht :)

    Hätte da noch paar Fragen:

    Kann ich auf dem TiNo LC eigentlich auch ein RFM69-HCW Modul verbauen? In der Konfig kann ich ja das passende RF-Modul auswählen.


    Gibt es Vorgaben für die (beste) Antenne? Material, Dicke, Länge? Welchen Draht verwendest Du?


    Gibt es noch einen Tipp zum löten von dem RF-Modul? Hab das Gefühl, links, der erste Pin von unten und der rechts der zweite Pin von unten lassen sich sehr schlecht löten. Liegt das an der TiNo Platine oder am Modul selber? Masseflächen? Irgendwo muss die Hitze ja hin..


    Wenn man den Filter über dem HTU21D verwenden möchte, kommt der dann auf die Platine oder klebt man den besser ins Gehäuse?


    Ich hab 5 TiNos eine Woche in eine selbstgebaute "Klimadose" gelegt. Styroporbox mit zusätzlicher Isolierung und innen ein Lüfter der für Luftbewegung sorgt. Die Feuchtigkeit interessiert mich nicht, das sind eh mehr oder weniger Schätzwerte. Aber die Temperaturen liegen 2K bis 3K auseinander. Kann man die Sensoren irgendwie besser machen? Mir geht es nicht um absolute Genauigkeit oder eine Kalibrierung. Aber wenn ich 10 Sensoren in eine 20° Kiste lege, will ich das alle ungefähr plus minus 0,5 Grad 19, 21 oder 22 Grad anzeigen. Damit wenn ich die dann in verschiedene Räume lege, die Temperaturen auch untereinander verleichbar sind.


    Ich hab vorher 5 von den Xiaomi E-Ink Thermometern in die Box gelegt und die hatten alle bis auf einen die gleiche Temperatur (eine Kommastelle), einer lag um 0,1K daneben. Das ist beeindruckend. Die Luftfeuchtigkeit lag bei plus minus 10%, ähnlich schlecht wie auch beim HTU21D.


    Gruß
    LED

  • Im Grunde kann der TiNo für so ziemlich alle Meldungen von Wasserrohrbruch bis Klingel, Briefkasten offen und Brief drin, Garatentor zu oder auf usw. verwendet werden. Und ich könnte einen TiNo ins Auto einbauen und über einen Taster das (Garagen-)Tor öffnen, Licht einschalten und wüsste immer wie warm es im Auto ist. Mit einem Erschütterungssensor (oder direkt einen Kontakt an die Zündung) wüsste ich auch wenn sich mein Auto (autorisiert oder unautorisiert) vom Acker macht :)

    richtig. Schoen wäre es zu wissen wer den TiNo wo wie einsetzt und evtl. auch eine Anleitung dazu postet.

    Kann ich auf dem TiNo LC eigentlich auch ein RFM69-HCW Modul verbauen? In der Konfig kann ich ja das passende RF-Modul auswählen.

    nein. Die Konfiguration dient dazu dass man auf den TiNo-LC oder den TiNo-HP die identische Firmware flashen kann. Nenne es Faulheit. Es ist einfach umständlich für jede Konfiguration einen neuen Sketch kompilieren zu müssen. Bei den TinyTx4 Modulen ist das der Fall.

    Gibt es Vorgaben für die (beste) Antenne? Material, Dicke, Länge? Welchen Draht verwendest Du?

    Das ist ein sehr komplexes Thema. Ein paar Faustregeln:

    Die Dicke des Drahtes spielt keine praktische Rolle, ich nehme normalen Klingeldraht.

    Die Länge der Antenne soll lamda/4 sein minus 5%, da wir uns nicht im Vakuum befinden.

    Die Antenne soll nicht komplett ins Gehäuse eingebaut werden, ausser du nimmst erhebliche Sendeverluste in Kauf.

    Die Antenne soll immer von der Leiterplatte wegzeigen, egal in welche Richtung. Sie bildet -sehr vereinfacht ausgedrückt - zusammen mit der Leiterplatte einen Dipol. Ich habe gute Erfahrungen damit gemacht den Antennendraht teilweise ins Gehäuse zu verlegen und ca 25 -30mm herausschauen zu lassen.

    Wenn du externe Antennen verwendest, immer auf den Typ achten. Manche haben ganz erhebliche Richtwirkung. Daumenregel: je hoeher der Antennengewinn (in dBi) desto hoeher die Richtwirkung. Manchmal ist das ja durchaus erwünscht. Viele gekaufte Stabantennen sind in keinster Weise besser als ein Draht. Auch diese Antennen brauchen die Leiterplatte als Gegengewicht.


    Gibt es noch einen Tipp zum löten von dem RF-Modul? Hab das Gefühl, links, der erste Pin von unten und der rechts der zweite Pin von unten lassen sich sehr schlecht löten. Liegt das an der TiNo Platine oder am Modul selber? Masseflächen? Irgendwo muss die Hitze ja hin..

    Das liegt sowohl an der Massefläche des Moduls als auch an der Massefläche der Leiterplatte, wobei letztere auf gute Loetbarkeit entwickelt wurde und wahrscheinlich weniger eine Rolle spielt. Einen besnderen Tipp kann ich dir nicht geben, ausser: du musst geduldig sein... Ich stelle die Loettemperatur etwa auf 300 degC ein, dazu beeile ich mich dann aber auch bei den anderen Loetstellen.



    Wenn man den Filter über dem HTU21D verwenden möchte, kommt der dann auf die Platine oder klebt man den besser ins Gehäuse?

    Ich stecke ihn auf die Platine und klebe die Leiterplatte ins Gehäuse. Da wo der Filter ist mus man vorher natürlich noch ein Loch bohren, ca 6mm Durchmesser.



    Aber die Temperaturen liegen 2K bis 3K auseinander.

    Dann liegen die Temperaturen auch sehr wahrscheinlich soweit auseinander. Ich hatte die TiNo's (ohne Gehäuse) getestet und die Temperaturwerte waren alle OK.

    Hast du für ausreichend Luftzufur in den TiNo Gehäusen gesorgt? Ich hatte keine Loecher in die Gehäuse gebohrt, weil ein bisschen Basteln muss schon sein! Kannst du evtl. den Versuch ohne die Gehäuse wiederholen? Mehr als 0.2 bis 0.3 K sollten die Teile dann nicht unterschiedlich sein. Ich hatte noch nie Probleme damit.

  • Hast du für ausreichend Luftzufur in den TiNo Gehäusen gesorgt?

    Ja, die Platinen lagen natürlich ohne Gehäuse in der Kiste. 0,3K? Hmmm... dann mach ich was falsch :)
    Theoretisch müssten sich ja auch annährend gleiche Temperaturen einstellen, wenn die einfach nur längere Zeit offen auf dem Tisch liegen. Ich werde das Mal protokollieren...

    Die Länge der Antenne soll lamda/4 sein minus 5%

    Also von der Platine gemessen so 80mm bei 868MHz? Danke!

  • Also von der Platine gemessen so 80mm bei 868MHz?

    ja genau.


    Theoretisch müssten sich ja auch annährend gleiche Temperaturen einstellen, wenn die einfach nur längere Zeit offen auf dem Tisch liegen. Ich werde das Mal protokollieren...

    Ich muss gestehen ich habe das nie genau untersucht, und habe den Angaben des Herstellers vertraut. Aber 2 bis 3K Unterschied zwischen 2 Teilen habe ich noch nie gemessen.

  • nurazur

    Da ich für die Aufnahme ins iobroker.repository noch einige Kleinigkeiten am Adapter anpassen muss, wollte ich den heartbeat und die interrupts direkt mit einpflegen.

    Hier die Codierung, wie ich sie verstanden habe:


    Code
    NodeId,66,s=-52.50,data:OK;1655;195;3140;69.50;5;,FEI=-16,T=37,biterrors=0
                                                   |
    +----------------------------------------------+
    |
    5 = 0101
        ||||
        |||+-------Heartbeat
        ||+--------Interrupt#1
        |+---------Interrupt#2
        +----------Interrupt#3


    Bitte nochmal kurz bestätigen.

    Ist die Zahl die übertragen wird in Hex oder Dezimal?

  • ja das ist soweit richtig.

    Aber ich dachte wir hätten uns darauf geeinigt dass ich für die Version 2.0 das Interface dem TinyRX4 angleiche. dann kann man nämlich sowohl den TiNo als auch den TinyRX mit dem selben ioBroker Adapter betreiben. Ich bin gerade dabei die Version2.0 auf Github hochzuladen, mit dem TinyRX Interface.

    Eine Interface Spezifikation habe ich auch, die ist aber leider noch nicht 100%ig fertig.

    Für die Interrupts moechte ich deinen Vorschlag für jeden interrupt 2 bits zu verwenden umsetzen. Das Heartbeat Flag ist in diesem Zusammenhang eigentlich unwichtig, weil es in der jetzigen Form keine Aussagekraft hat:

    Ist das Interrupt Byte Null, dann handelt es sich um ein reguläres Paket, d.h. das Heartbeat Flag ist 1.

    Ist das Interrupt Byte ungleich Null, dann handelt es sich um ein nicht reguläres, von einem Interrupt ausgeloestes Paket.


    Anbei die 2.0 Spec in ihrer jetzigen Form, ich mach's fertig so schnell ich kann, kann aber morgen werden. Ist aber wirklich mitten in der Bearbeitung, koennen also Tippfehler drin sein etc.

  • Keine Panik,


    ich musste sowieso am Adapter paar Kleinigkeiten anpassen und dann sind alle Datenpunkte in ihrer jetzigen Form enthalten.

    Mir ging es jetzt erstmal darum den Adapter in die 'latest'-Liste im offizielle iobroker.repository zu bringen, damit der auch von den Nutzern gefunden werden kann. Und momentan gibt es ja nur die Protokol-Version 1.1.

    Mach die Protokolländerungen und die Doku ganz in Ruhe fertig.

    Wenn du die Protokoll-Version 2 fertig hast kann ich diese immer noch umsetzen bevor ich den Adapter in die 'stable'-Liste eintragen lasse.


    Da ich momentan keinen Urlaub habe und ich nur an den Wochenden daran Arbeiten kann, wird die Umsetzung des neuen Protokolls vermutlich eh nicht ganz so schnell gehen wie vorher.

  • dann kann man nämlich sowohl den TiNo als auch den TinyRX mit dem selben ioBroker Adapter betreiben

    Hab ich jetzt erst richtig verstanden.

    Nur weiss ich nicht ob es eine gute Idee ist, beide in einem Adapter unterzubringen. Das könnte evtl. für die Nutzer schwierig werden den passenden Adapter zu finden. Der kann ja dann nur einen Namen und ein Logo habe. Wenn er TinyRX heisst, werden ihn die Tino Nutzer evtl. nicht finden und umgekehrt. Ich denke nicht, das jemand beide Systeme gleichzeitig betreibt. Aber vielleicht liege ich damit auch falsch? Oder jemand hat eine Idee für einen passenden Adapternamen und ein Logo das irgendwie für beide passend ist. Ich bin da offen für Vorschläge.

  • Und wenn man 2 identische oder zumindest sehr ähnliche/kompatible Adapter unter verschiedenen Namen einreicht?

    Also wenn es nur darum geht, dass der Adapter gefunden wird, kann man auch zwei identische Adapter mit unterschiedlichen Namen veröffentlichen und spart sich die Arbeit beide zu pflegen.

  • Und wenn man 2 identische oder zumindest sehr ähnliche/kompatible Adapter unter verschiedenen Namen einreicht?

    Ich weiss nicht, ob die ioBroker Entwickler das so akzeptieren.

    Um diesem Problemen aus dem Weg zu gehen, wollte ich jetzt die beiden unterschiedlichen Adapter einreichen.

    Daher bin ich auch nicht böse, wenn das TiNo Protokoll Version 2 noch ein bisschen auf sich warten lässt.


    Mir persoenlich ist HEX lieber :)

    Ich meinte welches Format hat diese Zahl im jetzigen Protokoll V1.1?

  • Es gibt eine neue Firmware für das Tino Funksystem!


    Der TiNo Firmware Update 2.0.1 ist jetzt auf github. Die Version ging von 1.x auf 2.x weil es Inkompatibilitäten gibt, die aber NICHT das Funkinterface betreffen. Das heisst, alle TiNo's die mit Sketchen der Versionen 1.x geflasht wurden sind vom Funkprotokoll her voll kompatibel mit der neuen Version.


    Bei dem Update geht es vor allem um zwei Bereiche:

    1. Erweiterung der Funktionalität. TiNo Empfänger koennen jetzt als "Aktoren" dienen, also Licht ein/ausschalten, Thermostaten regeln etc, eigentlich genau wie ein Homematic System. Allerdings muss ich die entsprechende Dokumentation erst noch fertig stellen.


    2. Noch mehr Sensoren: neben den bekannten HTU21D, SHT2x und SHT3x werden jetzt DS18B20 und BME280 unterstützt. Da der Speicherplatz im Atmega328 aber zu klein für alle ist, muss der jeweilige Sensor vor dem Kompilieren mittels Kompiler-Switch ausgewählt werden.


    Wer bereits die "Tiny Nodes" im Board Manager der Arduino IDE installiert hat, kann nun einfach auf Version 2.0 erhoehen.


    Neu ist:

    1. Als Empfänger kann der TiNo Aktionen ausführen, die man frei definieren und im EEPROM ablegen kann. Man kann festlegen, auf welchen der 4 moeglichen Interrupts reagiert werden soll, wie reagiert werden soll, also welcher Port angesprochen werden soll und auf welchen Sender reagiert werden soll. Moegliche Kommandos sind "AN", "AUS" "Toggle" (ändere den Port-Zustand) und "Puls". Die Zeitdauer eines Pulses kann ebenfalls konfiguriert werden.
    2. das serielle Interface des Empfänger-Sketches. Dies ist von jetzt an dem ursprünglichen Protokoll des TinyRx4 sehr ähnlich, mit einer Reihe von Erweiterungen. Ausserdem werden die ankommenden Pakete besser auf Plausibilität geprüft.
    3. Die Prüfsumme des Eeproms ist jetzt CRC-16, das ist zuverlässiger als die 8-bit Prüfsumme bisher.
    4. Die Temperaturdrift des Quarzes auf dem RFM Modul kann kompensiert werden. Das ist eigentlich nicht notwendig, hat aber Vorteile wenn man den TiNo in extremen Umgebungen betreiben will. Im Moment ist die Funktion im Sketch auskommentiert.
    5. Die Batteriespannung wird jetzt während dem Sendepuls gemessen. Das erlaubt eine wesentlich bessere Abschätzung des Zustandes der Batterie. Mit zunehmender Entladung nimmt der Innenwiderstand der Batterie zu, gegen Ende der Lebensdauer wird das der bestimmende Faktor, während die Leerlaufspannung durchaus noch vernünftig ist. Das RFM69 Modul bricht bei etwa 1.7V Betriebsspannung zusammen.
    6. die Python Skripte zum Konfigurieren der TiNo's sind jetzt kompatibel mit Python Version 3. Achtung, diese Skripte sind nicht mit TiNo Version 1.1 kompatibel. wer also noch Sensoren im Netzwerk hat die mit TiNo Version 1.x konfiguriert werden, der sollte sich die alten Tools unbedingt aufheben.
    7. neue Bootloader und neue Fuses: Da der Flashspeicher langsam knapp wird, verwende ich optiboot Bootloader, die benoetigen gerade mal 512 Bytes im Flash.





    Ich meinte welches Format hat diese Zahl im jetzigen Protokoll V1.1?

    HEX

  • nurazur


    Ich habe das Protokoll V2.0 am Wochenende mal bei mir in den ioBroker.adapter eingebaut.

    Da die beide Protokolle anhand der Anfangssequenz einfach zu unterscheiden sind, werden jetzt beide Protokolle unterstützt.

    Bei Protokoll V2.0 werden nur die Datenpunkte angelegt, die anhand der Variablen beim ersten Empfang erkannt werden.

    Bei Protokoll V1.1 wird allerdings wegen der Protokollstruktur immer die fixe Anzahl und Reihenfolge der Daten (wie von L.E.D. gepostet) erwartet.

    Ich hoffe das ist OK so.


    Bevor ich die Änderungen hochlade habe ich aber doch noch einige Fragen bezüglich des Protokolls


    1. Bedeutet der Datenpunkt 'FEI' in Protokoll V1.1 und der Datenpunkt 'Frequency offset' in Protokoll V2.0 das selbe?


    2. Wird die RFM69-Temperatur im Protokoll V2.0 nicht mehr übertragen?


    3. Nochmal zu den Interrupts, aber diesmal im Protokoll V2.0. Dieser ist in deiner Protokollbeschreibung V2.0 (letzte Seite) noch als 8bit hex dargestellt und nicht weiter beschrieben. Wolltest du den nicht erweitern oder ist der gleich zu Protokoll V1.1 geblieben oder hab ich das falsch verstanden?

  • 1. Bedeutet der Datenpunkt 'FEI' in Protokoll V1.1 und der Datenpunkt 'Frequency offset' in Protokoll V2.0 das selbe?

    nicht ganz. "FEI" bedeutet 'Frequency Error indicator' und ist eine Zahl ohne Einheit, die die Anzahl der Schritte angibt die der Empfänger-Oszillator gebraucht hat um sich auf die Senderfrequenz abzustimmen. (ähnlich wie bei einem UKW Radio wo man früher an der Kurbel gedreht hat bis man einen Kanal gefunden hat).

    Die Groesse der Schritte in Hz ist spezifisch für den verwendeten Typ Transceiver IC . Beim RFM69xxx sind das etwa 61Hz, beim CC1101, den ich in Zukunft auch unterstützen moechte, sind es etwa 397 Hz pro Schritt. Deshalb finde ich es besser wenn man den Versatz in Hz ausgibt.


    2. Wird die RFM69-Temperatur im Protokoll V2.0 nicht mehr übertragen?

    Nein. Da die Temperatur mit +/- 3K sowieso sehr ungenau ist und nur als Debug-Wert gedacht war, lasse ich das weg. Man kann trotzdem am Gateway einen richtigen Temperatursensor einsetzen, wenn man das will, aber ich weiss nicht ob das sinnvoll ist. Es ergibt - für mich - mehr Sinn, wenn man so einen Temperatursensor unabhängig vom TiNo am Raspberry Pi anschliesst, der kann per crontab die Messungen regelmäßsig durchführen.


    Der Grund warum ich den Wert überhaupt erfasst hatte war herauszufinden, ob es möglich ist die gemessene Temperatur zur Kompensation der Temperaturdrift des Quarzes zu verwenden.

    (ja, aber nur wenn der Sensor kalibriert ist, aber ich habe bisher keine gute Lösung wie man den kalibrieren könnte)

    3. Nochmal zu den Interrupts, aber diesmal im Protokoll V2.0. Dieser ist in deiner Protokollbeschreibung V2.0 (letzte Seite) noch als 8bit hex dargestellt und nicht weiter beschrieben. Wolltest du den nicht erweitern

    doch... kommt... du sagtest doch ich soll mir Zeit lassen. Entwurf als PN.

  • Der ioBroker-Adapter ist mittlerweile in der Version 0.1.1 im ioBroker latest repository veröffentlicht.

    Diese Version unterstützt sowohl die TiNo Firmware v1.x als auch die neue v2.x.

    Die entsprechende Protokoll-Version wird automatisch anhand der empfangen Daten erkannt.


    Neu in dieser Adapterversion ist ein Timeout des automatischen Anlernmodus.

    Wenn der Anlernmodus aktiviert ist, werden die Sensoren nach dem ersten Nachrichten-Empfang automatisch mit ihrer Node-Id und allen erkannten Datenpunkten angelegt.

    Der Anlernmodus wird nach 10 Minuten automatisch beendet und kann unter "info" über den Datenpunkt "learningMode" für weitere 10 Minuten erneut aktiviert werden.


    Damit der Adapter installiert werden kann, muss im ioBroker auf das latest repository umgeschaltet werden.

    Dafür im ioBroker oben auf das Maulschlüsselsymbol drücken, dann unter dem Reiter "Haupteinstellungen" den "Aktiven Verwahrungsort" auf "latest" umstellen und speichern.

    Danach wird der TiNo-Adapter in der Adapterseite angezeigt und kann wie jeder anderer ioBroker-Adapter installiert werden.


    Wer sich den Adapter-Code anschauen möchte:

    https://github.com/bowao/ioBroker.tino


    Screenshot ioBroker TiNo Adapter mit Unterstützung der TiNo Firmware Version 2:

    Edited 2 times, last by bowao ().

  • Hallo zusammen!

    Meine 6 TiNo Empfänger haben jetzt über ein Jahr super funktioniert. Ich glaube das Update auf die Firmware v2.x. hab ich nie gemacht und jetzt wollte ich endlich auch einen Reed Sensor anschließen. D7 auf GND und es wird ein Telegramm erzeugt, super! Allerdings konnte mein iobroker noch keinen Interrupt auswerten. Also hab ich heute Nacht ein großes Update gemacht... schlimm, wie schnell man doch die einfachsten Sachen vergisst. Es war auf jeden Fall eine lange Nacht... js-controller, Node10, TiNo 1.0...

    Aber obwohl alles richtig aussah, kamen keine Daten an! Hat ein bisschen gedauert bis ich den Fehler gefunden habe.

    Statt /dev/ttyAMA0 hat mein Serial-USB-Wandler jetzt /dev/ttyUSB0. Jemand eine Idee warum das so ist?


    Dann noch den neuen learningMode auf true und zack, es funktioniert! :)



    Ich kann jetzt über ein physisches Ereignis den Interrupt 1 auf true setzen. Aber was ist, wenn ich mehrere Ereignisse loggen oder zählen möchte? Und was bedeutet der Wert unter Heartbeat? Bei Sensor 3 steht er auf true und bei Sensor 5 auf false... !?


    Die Knopfzellen halten übrigens wirklich unglaublich lange, auch draußen und im Gewächshaus mit starken Temperaturschwankungen.

    Viele Grüße
    LED

    PS: Wie lange bleibt der Lernmodus eigentlich aktiv? Für die Sensoren an die ich eigentlich erst in 4 Jahren wieder dran gehen wollte auf jeden Fall zu kurz...

    Edited once, last by L.E.D. ().