Posts by bowao

    Eine neue Version 1.1.1 des Tino-Adpapters für die neue ioBroker Version mit js-controller 3.3 steht auf Github und npm bereit.


    Der js-controller 3.3 ist wesentlich restriktiver im Bezug auf die angelegten Datenpunkttypen und gesendeten Wertetypen.

    Daher mussten einige Anpassungen am TiNo-Adapter durchgeführt werden.


    Es wurden keine neuen Funktionen hinzugefügt.

    Also nur für diejenigen interessant, die den ioBroker auf js-controller 3.3 updaten wollen oder müssen.

    (Das Update auf js-controller 3.3 ist z.B. für die Installation der neuen ioBroker Benutzeroberfläche 'Admin 5' notwendig.)

    Die neue ioBroker-Adapter Version 1.1.0 für die TiNo Protokoll Version 2.2 steht auf Github und npm bereit.


    Für die Auswertung der neuen Variablen 't1' und 't2' wurden die Datenpunkte 'Temperatur_1' und 'Temperatur_2', inklusive einstellbarer Korrekturwerte hinzugefügt.

    Der max. Wert des Datenpunkts 'Temperatur' (Variable 't') wurde auf 600 erhöht.


    Da es für die Luftfeuchte keine neuen Variablen 'h1' und 'h2' gibt, die den Temperaturfühlern 't1' bzw. 't2' zugeordnet sind,

    werden die Werte für die absolute Feuchte und die Taupunkttemperatur weiterhin nur aus den Variablen 't' und 'h' berechnet.

    Ich sehe schon das Problem.

    Es ist nicht nur ein neuer Sensor implementiert worden, sondern zusätzliche Variablen und die Struktur scheint sich geändert zu haben.

    Im Github Repository von nurazur ist leider die Dokumentation nicht angepasst worden, daher brauche ich noch weitere Infos.


    Bei dem Sensor mit PT100/MAX31865 gibt es zwei neue Variablen: 't1' und 't2'.

    Was bedeuten diese? -4000 = -40°C ?


    Sind die Sensordaten jetzt wirklich zweizeilig? (Wenn ja, ist das ein Bug oder ein Feature?)

    Zeile 1: Adresse und Typ --> Die '51' ist wohl die Adresse, aber was bedeutet 'Type 4'?

    Zeile 2: Nur die reinen Sensordaten

    Moin hama,


    ein PT100 Sensor an einem Max31865 Digital-Wandler ist auch nur ein Temperaturfühler.

    Der sollte eigentlich mit der vorhandene Variable 't' bereits erkannt werden.

    Wenn du mir die Rohdaten die auf der seriellen Schnittstelle ankommen zusendest, kann ich mir das die Tage mal ansehen, warum der als invalid gemeldet wird.

    hama :


    Ich denke da hast du recht.


    Der Interruptwert wird nur in dem Moment übertragen, in dem er ausgelöst wird.

    Der Datenpunkt wird dann auf 'CHANGE' geändert.

    Bis zur nächsten Auslösung eines Interrupts, wird kein Wert mehr übertragen, also bleibt der Datenpunkt auf 'CHANGE'.

    Wird der gleiche Interrupt erneut ausgelöst und übertragen, bleibt der Datenpunkt ebenfalls auf 'CHANGE', da ja genau dieser Wert gesendet wird.

    Wird ein andere Interrupt ausgelöst, ist in dieser Nachricht die Information, dass der ehemals ausgelöste Interrupt nun nicht ausgelöst ist und der Datenpunkt ändert sich jetzt erst auf '0'.


    Das scheint mir auch nicht zielführend zu sein.

    Daher habe ich deinen Vorschlag, dass der Interruptwert nach 2 sekunden im ioBroker zurückgesetzt wird umgestetzt.

    Bitte teste mal die Version 1.0.3 von Github

    Also aus Sicht des ioBrokers ist das nur eine weitere Variable.

    Wichtig ist jedoch ob diese in Hex (stat=0xd bis stat=0xf) oder Dezimal (stat=0 bis stat=15) angegeben wird.

    Bitweise ausgelesen kann man dann vier Datenpunkte generieren PCI0, PCI1, PCI2, PCI3.

    Das niederwertigste Bit (LSB) repräsentiert PCI0 und das höchstwertigste Bit (MSB) repräsentiert PCI3.

    hama

    Die neue Version V1.0.2 mit dem Fix für die negativen Temperaturwerte steht auf Github bereit.

    Wäre nett wenn du die mal ausprobierst und mir Feedback gibst, bevor ich sie ins npm hochlade.


    Im ioBroker auf die Adaper-Seite, dann oben auf die 'Github-octocat' (Installieren aus eigener url) drücken,

    den Reiter 'Beliebig' wählen, unter 'URL oder Dateipfad' den github-link:

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

    eintragen und auf installieren drücken.

    Hi hama,


    danke für den fix zur Auswertung der Minustemperaturen, hatte ich bisher nicht bemerkt. Werde das in der nächsten Version anpassen.

    Bezüglich des Interrupts ist mir aufgefallen, das in den Rohdaten der Interrupt plötzlich mit 'intr' anstatt wie im Schnittstellenprotokoll angegeben mit 'int' ausgegeben wird.

    Daher erkennt der ioBroker diesen nicht mehr.


    nurazur : Hat sich hier etwas in der Firmware geändert?


    Der Fehler bezog sich ausschließlich auf die TiNo-Protokoll-Version V2.

    Anhand deiner Screenshots kann man erkennen, das du noch die TiNo-Protokoll-Version V1 benutzt und daher nicht betroffen warst.


    In den log-Dateien von Muchul ist zu sehen, dass im TiNo-Protokoll-Version V2 der Interrupt-Wert immer mit der Angabe des Zahlensystems, also mit vorangestellten '0x' für Hexadezimal, gesendet wird.

    Da die Variablenerkenung im ioBroker-Adapter jedoch einen Hexadezimalwert von 0 bis ffff, also ohne vorangestelltes '0x' erwartete, wurde die Variable nicht erkannt.


    nurazur : In den log-Dateien von Muchul ist auch immer die Variable 'f' vorhanden. Wofür steht diese Variable? In der Protokoll-Beschreibung wird sie nicht erwähnt.

    Hi Muchul,


    ich habe die Fehlerursache in der Interrupt-Erkennung gefunden und beseitigt.

    Bitte mal die neue Github-Version V1.0.1 installieren und testen:


    Im ioBroker auf die Adaper-Seite, dann oben auf die 'github-octocat' (Installieren aus eigener url) drücken,

    den Reiter Beliebig wählen, unter 'URL oder Dateipfad' den github-link:

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

    eintragen und auf installieren drücken.


    In deinem Debug-log sehe ich noch die Variable "f", die sich nach Auslösung der Interrupts auch jedes mal geändert hat.

    Diese Variable ist aber im TiNo Receiver Protokoll ab V2.0 nicht beschrieben und wird daher im Adapter nicht ausgewertet.

    Siehe: https://github.com/nurazur/TiN…rotokoll%20Empfaenger.pdf


    nurazur: Hat es hier eine Änderung bzw. Erweiterung gegeben?

    Hi Muchul,


    wenn ich das richtig interpretiere hast du über die GPIOs einen Interrupt ausgelöst, der aber im ioBroker nicht angezeigt wird.

    Hier scheint ein Problem bei der Erkennung des Interruptwerts im ioBroker-Adapter zu sein.

    Ich glaube ich habe das Problem auch schon erkannt.

    Werde das morgen mal genauer untersuchen und versuchen zu fixen.

    HI L.E.D.


    der Device Pfad /dev/ttyAMA0 zeigt eigentlich auf die erste Serielle Schnittstelle des Raspi an GPIO 14 (Senden) und 15 (Empfangen). Zumindest in der Raspi-Version 1, 2 und beim Zero.

    Ab der Raspi-Version 3 und beim Zero W ist diese jedoch standardmäßig mit dem Bluetooth Modul verbunden und der korrekte Device Pfad zur Seriellen Schnittstelle dann /dev/ttyS0. Aber auch nur wenn du die (zweite) Serielle Schnittstelle über die raspi-config aktiviert hast.

    Genauere Erklärung unter: https://www.raspberrypi.org/do…ion/configuration/uart.md


    Wenn du allerdings einen Serial-USB-Adapter benutzt ist der Device Pfad immer /dev/ttyUSB0. Jedenfalls beim ersten. Bei mehreren Serial-USB-Adaptern wird vom System einfach hochgezählt (ttyUSB1,ttyUSB2,ttyUSB3, usw.).


    Zum loggen der Werte kannst du unter folgenden Iobroker-Adaptern auswählen:

    ioBroker.history, ioBroker.influxdb oder ioBroker.sql.


    Zur Darstellung der aufgezeichneten Werte in einem Diagramm kann ich den Adapter ioBroker.flot empfehlen.


    Zum Zählen würde ich auf der Objekte Seite unter dem Ordner "0_userdata.0" einen virtuellen Datenpunkt anlegen und diesen dann über ein Script bei jeder Änderung deines Interrupt Datenpunktes auf "true" hochzählen lassen. Hierzu wird der Adapter ioBroker.javascript benötigt. Damit lassen sich über Blockly auch ohne Javascript Kenntnisse ganz einfach kleinere Programme erstellen.


    Der Lernmodus bleibt übrigens für 10 Minuten aktiv. Kann aber danach sofort wieder über den Datenpunkt "learningMode" im Ordner "info" für weitere 10 Minuten aktiviert werden.

    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:

    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?

    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?

    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.

    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.

    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?

    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/