Entwicklung: Temperatur Funk Sensor

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Diese Ergänzungen würden sich vermutlich umsetzen lassen.

    Ich bräuchten von den zusätzlichen Werten aber noch folgende Angaben:

    Zu erwartende min. und max. Werte,

    Einheiten,

    Skalierungen.

    eine Message inklusive aller Zeilenumbrüche oder ähnliches als Beispiel.

    Alle Meldungen in denen nicht mindestens eine Variable gefunden wird, wird momentan im info-log ausgegeben als:

    Invalid Data: $message

    Da sich die Debug Meldungen vermutlich deutlich vom Datenmüll unterscheiden lässt, könnte ich diese in den info-logs auch als solche deklarieren.

    Auch hier wäre ein Beispiel inklusive eventueller Zeilenumbrüche oder ähnliches hilfreich.

    Versprechen will ich nichts, aber wenn ich dieses Informationen habe könnte übernächste Woche (Urlaub) mal testen ob ich das umgesetzt bekomme.

    Ach ja, und du müsstest den Betatester spielen, da ich die Hardware (noch) nicht besitze muss ich das erst mal blind umsetzen.

  • ich hab deinen source Code angeschaut, ohne alles zu verstehen, deshalb eine Frage:

    Code
    if (/r=[0-9]+&/.test(data)) {
            contact = parseInt((data.match(/r=[0-9]+/)[0].substring(2))) / 100;

    wenn ich das recht verstehe, muss eine Sequenz wie z.B."r=1&" im String sein. Ich verstehe das Zeichen '&' nicht - warum MUSS das in der Sequenz sein?

    meigrafd hatte die '&' Zeichen als Trennung verwendet, weil er dann den vom seriellen Port eingegangenen String direkt in PHP weiterverarbeiten kann. Und warum teilst du das Ergebnis durch 100? Ist das ein Bug?

    Die neuen Variablen für TiNo hab ich mir so vorgestellt:

    Variable rssi (Signalstärke): Min -125 Max 0, Einheit: dBm, Skalierung: Faktor 1

    Variable fo (Frequenzversatz): Min -25000, Max +25000, Einheit: Hz, Skalierung: Faktor 1

    Variable intr (Interrupt)

    Nach dem Studium des ioBroker Adapter Source Codes würde ich folgendes vorschlagen:

    4 Variablen intr1, intr2, intr3, intr4.

    Min: 1, Max: 3. Bedeutung: 1= CHANGE, 2=FALLING, 3= RISING (wie Arduino #defines)

    Einheit: keine, Skalierung: keine (Faktor 1)

    Variable lqi (link quality Indicator) Min. 0 Max 127 Einheit: keine, Skalierung: keine

    eine Message inklusive aller Zeilenumbrüche oder ähnliches als Beispiel.

    Beispielstring:

    23 v=3002&c=243&t=3400&h=5650&rssi=-83.5&fo=2014\n

    heisst: NodeID 23, Vcc=3.002 V, Zähler ist 243, Temperatur 34,00 degC, Luftfeuchte 56.5 %, RSSI -83.5 dBm, Frequenzabweichung 2014 Hz.

    Der Zähler inkrementiert jedes mal wenn ein Paket gesendet wird, und dient als "rolling code". Im ioBroker kann man das ignorieren.

    Beispielstring mit interrupt:

    23 v=3002&c=243&t=3400&h=5650&intr1=2&rssi=-83.5&fo=2014\n

    Da sich die Debug Meldungen vermutlich deutlich vom Datenmüll unterscheiden lässt, könnte ich diese in den info-logs auch als solche deklarieren.

    Auch hier wäre ein Beispiel inklusive eventueller Zeilenumbrüche oder ähnliches hilfreich.

    Debug Informationen kann ich komplett unterdrücken, ausser:

    Wenn das Gateway startet, sendet es "CAL?\n" und dann nach 250ms "timeout\n", wobei das Wort "timeout" echt irreführend ist, weil es voellig in Ordnung ist und nur sagt dass der Kalibriermodus übersprungen wurde. Kann man auch komplett weg machen. ich merke gerade dass da viel im Code steht was man jetzt echt nicht mehr braucht.

    Ach ja, und du müsstest den Betatester spielen

    mache ich gerne. Allerdings hab ich keinerlei Ahnung von IoBroker. Kann also dauern.

  • Hi nurazur,

    da hast du Recht, das '&' gehört da nicht hin und durch 100 muss da auch nix geteilt werden.

    War wohl ein copy&paste Fehler.

    Danke, werde ich berichtigen.

    Das mit der interrupt Variable ist mir noch nicht ganz klar. Ich dachte dass wäre wie ein Kontakt mit zwei Zuständen, 0 und 1.

    Was bedeuten die von dir aufgeführten drei Zustände: CHANGE, FALLING, RISING?

    Bei Werten mit Kommastellen, wie rssi in deinem Beispiel, müssen diese zu einer ganzen Zahl multipliziert werden.

    Nach dem Empfang wird die Kommastelle über den Faktor wieder zurückgerechnet.

    So wie es meigrafd mit den anderen Werten gemacht hat.

    Wenn also rssi eine Kommastelle hat muss man den Faktor 10 anwenden.

    Die Zähler-Variable 'c' würde ich auf jeden Fall trotzdem auslesen wollen, damit die Variable in der Liste der bereits genutzten Variablen auftaucht und nicht anders belegt wird.

    Ausserdem ist der Zählwert beim Debugging vielleicht irgendwie hilfreich.

  • Hey Jungs,

    ich spiele gerne den Betatester! iobroker läuft bei mir und die Funk-Hardware ist unterwegs und sollte kurzfristig eintreffen.

    Den Zähler würde ich ebenfalls drin lassen und auslesen, auch wenn es nur als Statistik / Betriebszähler fungiert.

  • OK, rssi werde ich mit 10 multiplizieren.

    Dann sieht der Beispielstring so aus:

    23 v=3002&c=243&t=3400&h=5650&rssi=-835&fo=2014\n

    Die Attiny84 (TinyRx4) und die ATMega328 (TiNo) Prozessoren haben sogenannte Pin-Change Interrupts. Mit denen kann man den Prozessor aus dem Schlaf holen wenn an einem bestimmten Pin etwas passiert ist. Das kann eine Flanke von 0 auf 1 sein (RISING), eine Flanke von 1 auf 0 (FALLING) oder beides (CHANGE). Ich dachte damit koennte man z.B. ein Licht schalten und so dem ioBroker gleichzeitig mitteilen ob das Licht angeschaltet oder abgeschaltet wurde oder ob sich der Zustand geändert hat.

    Hab ich da vielleicht zu kompliziert gedacht?

  • Ich hatte das so verstanden, das beim Arduino die Werte CHANGE, LOW, HIGH, RISING und FALLING den Modus beschreiben wann der Interrupt ausgelöst wird.

    Der Interrupt-Pin selber, den du wie ich dachte, über serielle Schnittstelle ausgeben willst hat aber nur den Zustand 1 oder 0.

    Im Prinzip ist es egal was über die Serielle Schnittstelle ausgegeben wird. Im ioBroker kann man aus fast allem einen Datenpunkt mit den übertragenen Werten machen.

    Ich wollte nur verstehen was der Wert bedeutet. Wenn für die Anwendung diese Werte notwendig sind, kann man diese auch darstellen.

    Macht es eventuell Sinn die Interrupts in einem Wert (bitcodiert) zu übertragen?

    Ich denke da an die Länge der zu übertragenen Message hinsichtlich des Energieverbrauchs.

    Bei evtl. späteren 8 Interrupts wird die Message ja ziemlich lang.

    23 v=3002&c=243&t=3400&h=5650&intr1=1&intr2=2&intr3=3&intr4=1&intr5=1&intr6=2&intr7=3&intr8=1&rssi=-835&fo=2014&lqi=54

    Das könnte man abkürzen indem man pro Interrupt zwei Bit verwendet:

    intr1=2, intr2=2, intr3=3, intr4=1, intr5=1, intr6=2, intr7=3, intr8=1

    binär:

    intr1=10, intr2=10, intr3=11, intr4=01, intr5=01, intr6=10, intr7=11, intr8=01

    Zusammen:

    1010110101101101

    in Hex:

    ad6d

    Würde die Message verkürzen auf:

    23 v=3002&c=243&t=3400&h=5650&intr=ad6d&&rssi=-835&fo=2014&lqi=54

    Im ioBroker würde ich dies natürlich wieder zurückrechnen und den Zustand jedes Interrupts einzeln anzeigen.

    Denke ich da jetzt zu kompliziert?

    Btw:

    Ist dir die Werteanzeige der Interrupts als value (1,2,3) oder als string (CHANGE, FALLING, RISING) lieber?

  • Das ist ja MEGA!
    Hab die neue Version gleich installiert.

    Hast du schon den TinyRX4 an dem ioBroker Adapter ausprobiert?

    Leider habe ich die TinyRX Hardware nicht, aber dafür läuft seit heute die Funkstrecke über zwei TiNos. Hab das erste Mal Kontakt mit Linux und hatte einige Probleme den Empfänger TiNo am Raspberry PI3 anzuschließen und eine Ausgabe zu bekommen.

    Zum testen brauche ich jetzt noch eine neue Firmware für den TiNo Sender (Empfänger auch?). Aktuell sieht die Ausgabe auf der seriellen Konsole so aus:

    Code
    Willkommen zu minicom 2.7.1
    
    Optionen: I18n
    Übersetzt am Aug 13 2017, 15:25:34.
    Port /dev/ttyAMA0, 21:19:16
    
    Drücken Sie CTRL-A  Z für Hilfe zu speziellen Tasten
    NodeId,15,s=-38.00,data:OK;3217;1;2692;66.00;1;,FEI=-2,T=31,biterrors=0
    NodeId,77,s=-106.50,data:FAIL;2402;60;10352;9.00;5E;,FEI=-238,T=31,biterrors=0

    NodeID 15 ist korrekt, woher die 77 kommt kann ich nicht sagen. Kam gleich danach, so was müsste der Adapter dann ignorieren...

    Kann mir jemand sagen wie ich minicom beenden kann, wenn ich per SSH (Putty) minicom mit

    sudo minicom -b 38400 -D /dev/ttyAMA0 -o

    gestartet habe?


    Gruß

    LED

  • Kann mir jemand sagen wie ich minicom beenden kann, wenn ich per SSH (Putty) minicom mit

    sudo minicom -b 38400 -D /dev/ttyAMA0 -o


    gestartet habe?

    normalerweise mit CTRL-A und dann Q, aber das geht bei mir auch nicht, wobei ich den bitvise SSH Client benutze. Da bleibt mir nur ein zweites Terminal zu oeffnen und mit killall minicom den Prozess zu beenden.

    Zum testen brauche ich jetzt noch eine neue Firmware für den TiNo Sender (Empfänger auch?)

    nein, der Sender braucht keine Firmware, weil das eigentliche Funkprotokoll davon nicht betroffen ist. Nur der Empfänger-Sketch muss angepasst werden.

    Der derzeitige String ist so aufgebaut dass ich ihn leicht mit Python zerlegen kann.

    Der String mit NodeId 77 kommt von einer Fehltriggerung des Empfängers. Du kannst sehen dass der RSSI mit -106 dBm extrem niedrig ist, und daher schon viel Rauschen ins Spiel kommt. Manchmal triggert der RFM69(H)CW auf reine Rauschsignale, das ist normal. Aber die Software hat erkannt dass die Datenfehlerhaft sind, daher der Hinweis "FAIL".

    Im Sketch kann man diese Fehltriggerungen unterdrücken, da muss man nur eine Zeile auskommentieren.

    Der Ergebnisstring muss angepasst werden, leider hab ich derzeit wenig Zeit das zu implementieren, auf Github zu laden und zu testen. Ich melde mich wenn ich so weit bin.

    Würde die Message verkürzen

    das ergibt Sinn.

    Denke ich da jetzt zu kompliziert?

    nein, aber ich glaube es bin ich der ein Verständnisproblem hat was der ioBroker ist, bzw. kann. Es ist so dass derzeit im Funkprotokoll tatsächlich nur ein einzelnes bit gesetzt wird wenn ein Interrupt ausgeloest wird. Das heisst, der Empfänger kann (derzeit) gar nicht wissen, ob der Interrupt 1,2,oder 3 ist. Ich dachte das kann man im ioBroker konfigurieren, aber das ist vom Sender abhängig, wie ich diesen konfiguriert habe.

    Im Endeffekt finde ich deinen Vorschlag aber sehr sinnvoll, im Hinblick auf zukünftige Erweiterungen des Funkprotokolls. Aber im Moment reicht eine 1 (Interrupt wurde ausgeloest) oder eine 0 (Interrupt wurde nicht ausgeloest).

    Auf dem TiNo gehe ich etwas verschwenderisch mit Interrupts um (wenn man sie schon hat!). Betrachten wir einen Fensterkontakt: der ist beispielsweise an Pin D7 angeschlossen. Im EEPROM des Senders definiere ich jetzt 2 Interrupts für Pin D7, einen FALLING und einen RISING. Wenn das Fenster geoeffert wird, schliesst der Kontakt und es wird ein FALLING Interrupt ausgeloest, also z.B. das bit fuer Interrupt 1 gesetzt. Wenn das Fenster geschlossen wird, wird ein RISING Interrupt ausgeloest, das ist dann das Bit für Interrupt 2. Den Empfänger kann ich nun per EEPROM so konfigurieren, dass er "Aktionen" durchführt, wenn fuer bestimmte Nodes bestimmte Interrupt Bits gesetzt sind. Diese "Aktion" kann z.B sein dass man dann per String über das serielle Interface die entsprechende Information schickt. Insofern ist dein Vorschlag mit 2 bits pro Interrupt absolut sinnvoll.

    Ich muss es nur entsprechend umsetzen. Ich hoffe damit ist alles klar?

  • Ich habe mal aus Spass auf Grundlage der von L.E.D. geposteten Messages die momentan vom TiNo Empfänger auf der Seriellen Schnittstelle ausgegeben werden einen eigenen ioBroker Adapter gebastelt.

    Ist nur quick&dirty und ich weiss nicht ob ich die Datenpunkte richtig benannt und verstanden habe, aber damit könnte man schon mal ein bisschen herumspielen.

    Auch wieder erst mal nur auf Github:

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

    Sieht bisher so aus:

  • Auch wieder erst mal nur auf Github:

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

    Läuft :)

    Was soll denn die RFM69 Module Temperature sein? Die Temperatur vom Empfänger? Sooo warm kann es dem eigentlich nicht sein.

    normalerweise mit CTRL-A und dann Q, aber das geht bei mir auch nicht, wobei ich den bitvise SSH Client benutze. Da bleibt mir nur ein zweites Terminal zu oeffnen und mit killall minicom den Prozess zu beenden.

    Was für ein schlechtes Programm. Hab auch noch picocom getestet, aber mit

    sudo picocom -b 38400 /dev/ttyAMAO

    bekomme ich nur eine Fehlermeldung das die Datei ttyAMAO nicht gefunden wurde.

    nein, aber ich glaube es bin ich der ein Verständnisproblem hat was der ioBroker ist

    Der iobroker ist die Zentrale für eine Hausautomatisierung, wenn man so will das Gehirn für die ganzen Sensoren und Aktoren. Alle Sensordaten kommen beim iobroker an, werden ausgewertet, verarbeitet, gespeichert, ggf. angereichert und bei bestimmten Schwellwerten oder Ereignissen gibt es Aktivitäten. Zusätzlich gibt es Adapter zur Visualisierung, für Statistiken, für Berechnungen, zur Anbindung an Cloudsysteme, an Sprachassistenten und Messenger. Mann kann zum Beispiel die Temperatur in einem bestimmten Raum per Telegram Messenger abfragen oder Alexa die Rollos auf 50% stellen lassen.
    Seine Heizung abhängig von der Wetterprognose einstellen oder bei Hitzeperioden automatisch den Garten bewässern.

    Ich muss es nur entsprechend umsetzen. Ich hoffe damit ist alles klar?

    Alles klar soweit.
    Ich frage mich allerdings, ob man nicht einfach alle Daten vom Sender 1zu1 an iobroker weiterreichen sollte und dann im Adapter entscheidet, was wie angezeigt wird. So könnte man auch einfach im Webinterface vom Adapter die Debug Infos aktivieren, sich anschauen ob der Standort für den Empfänger ok ist und nicht zu viel Müll empfangen wird und dann die Debug Informationen wieder raus filtern.

    Wenn ich sehe wie schnell bowao das alles umsetzt, wäre das vielleicht eine gute Idee. Keine Ahnung wie groß der Aufwand ist, aber man könnte theoretisch bei neueren Versionen mit weiteren Funktionen im Funkprotokoll diese im Adapter auswählen und so für verschiedene TiNo Versionen gerüstet sein.

    Ist auf jeden Fall der Hammer, dass es so schnell schon zu so tollen Ergebnissen gekommen ist. Respekt!

    Gruß
    LED

    Einmal editiert, zuletzt von L.E.D. (28. Juli 2019 um 21:58)

  • Ich habe mal aus Spass auf Grundlage der von L.E.D. geposteten Messages die momentan vom TiNo Empfänger auf der Seriellen Schnittstelle ausgegeben werden einen eigenen ioBroker Adapter gebastelt.

    Jetzt bin ich echt von den Socken. Wenn ich 5 Likes vergeben koennte haette bich das getan...:thumbup::thumbup::thumbup::thumbup::thumbup:


    Ist auf jeden Fall der Hammer, dass es so schnell schon zu so tollen Ergebnissen gekommen ist. Respekt!

    Dem kann ich mich nur anschliessen!!:):thumbup::danke_ATDE:


    Was soll denn die RFM69 Module Temperature sein? Die Temperatur vom Empfänger? Sooo warm kann es dem eigentlich nicht sein.

    ja genau so ist es. Die Temperatur müsste allerdings kalibriert werden, dann kann die gemessene Temperatur auf +/- 1 Grad genau sein. Unkalibriert kann man mehrere Grad daneben liegen.

    sudo picocom -b 38400 /dev/ttyAMAO

    muss heissen /dev/ttyAMA0 (NULL) nicht AMAO (Buchstabe O)


    Ich frage mich allerdings, ob man nicht einfach alle Daten vom Sender 1zu1 an iobroker weiterreichen sollte und dann im Adapter entscheidet, was wie angezeigt wird.

    Da ich mich mit ioBroker nicht auskenne, kann ich dazu nix sagen. Jedenfalls ist das Funkprotokoll komplett binär und für das menschliche Auge absolut unlesbar. Und das von mir verwendete Protokoll auf dem seriellen Port ist wahrscheinlich nicht 100%ig durchdacht. Da lasse ich euch den Vortritt, ich kann alles gerne umsetzen.

    Mir gefällt eigentlich das ursprüngliche Protokoll vom TinyRX4 ganz gut, das kann man immer wieder erweitern, ohne Probleme mit der Rückwärtskompatibilität. Ich meine die Kompatibilität zwischen älterem TiNo und neuerem Adapter oder neuerem Adapter mit älterem TiNo.

  • Moin!

    Nur zur Info: Windows10 kann schon länger ssh. Einfach in ein CMD-Fenster/powershell-Fenster "ssh user@ip" eingeben.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Der derzeitige String ist so aufgebaut dass ich ihn leicht mit Python zerlegen kann.

    Aaaah, Python kannst Du auch ;) Dann suchst Du vielleicht auch eine stromsparende Möglichkeit die Sensordaten deiner TiNos anzuzeigen? Ich bin da schon ein paar Wochen an einer Umsetzung dran, scheitere aber auf den letzten Metern wegen mangelnder Programmierkenntnisse. Vielleichst schaust Du da Mal rein, wenn Du wieder etwas Zeit hast:
    Amazon Kindle als stromsparendes Statusdisplay

    Da bleibt mir nur ein zweites Terminal zu oeffnen und mit killall minicom den Prozess zu beenden.

    Danke, so funktioniert es.

    muss heissen /dev/ttyAMA0 (NULL) nicht AMAO (Buchstabe O)

    Autsch... kommt davon wenn man nur immer mit copy & paste arbeitet und nicht selbst denkt. Ich bleibe bei minicom, funktioniert erst Mal. Ein kurzer test ergab wieder eine neue Meldung: FATAL: cannot lock /dev/ttyAMA0: Resource temporarily unavailable

    Nur zur Info: Windows10 kann schon länger ssh. Einfach in ein CMD-Fenster/powershell-Fenster "ssh user@ip" eingeben.

    Danke, aber auch da reagiert minicom nicht auf die Tastenkombinationen. Es liegt also nicht an Putty...

    Gruß

    LED

  • Danke für die Blumen, aber das war jetzt kein Hexenwerk, die Grundlagen hatte ich ja schon mit dem tinyrx4 Adapter.

    Im Grunde nehme ich nur die mir auf dem Silbertablett gelieferten Werte von der Seriellen Schnittstelle und mache daraus Datenpunkte im ioBroker.

    Hier mussten keine komplizierten Steuer- oder Abfragesequenzen gebastelt werden.

    Und ob der Adapter auch Fehlerresistent ist muss ein längere Feldtest, am besten mit vielen Nodes und widrigen Empfangsbedingung, noch zeigen.

    Vermutlich müssen hier noch einige Fehlerabfangroutinen nach gestrickt werden.

    Und das wichtigste fehlt auch noch, ein fancy Adapter-Icon.

    Wenn jemand einen Vorschlag hat bin ich da offen, sonst bastle ich selber was, aber wie man am tinyrx4 Adapter-Icon sehen kann bin ich da nicht so kreativ.

    Zum Protokoll an sich kann ich nur sagen, was und wie etwas auf der Seriellen Schnittstelle ausgegeben wird ist prinzipiell egal und kommt auf die Umstände und das gewünschte Ergebnis an.

    Wenn Energieeffizients und Stabilität bei der Datenübertragung wichtig sind, wird man versuchen so viele Informationen und Fehlererkennungsmöglichkeiten mit so wenig Bytes wie möglich zu übertragen.

    Dies wird dann mit Sicherheit kein Menschen lesbarer Klartext mehr sein.

    Da aber diese Daten über den Empfänger bereits aufbereitet werden können und dessen Spannungsversorgung und Kommunikationsschnittelle auf kurze Distanz fest mit dem Raspi verkabelt sind, könnte man auf der 'letzten Meile' vermutlich auf ein kompliziertes Protokoll verzichten.

    Das hätte den Vorteil, dass die grundlegenden Funktionen schnell über ein einfaches Terminal-Programm getestet und die Daten mit einem kurzen Blick auf Plausibilität geprüft werden können.

    Dafür wäre das TinyRX4-Protokoll oder eine Weiterentwicklung davon, auch hinsichtlich der Erweiterbarkeit, sicherlich gut geeignet.

    Die Frage ist jedoch, wie viel Anwender arbeiten bereits mit dem jetzigen Protokoll und wie viel Aufwand würde eine komplette Umstrukturierung bei den Nutzern auslösen?

    Gibt es bereits Programme, die auf die Daten in jetziger Form angewiesen sind und lassen sich diese unproblematisch anpassen?

    Ist eine Funktionserweiterung mit dem jetzigen Protokoll ohne Aufwand möglich oder muss man dann sowieso die externen Anwendungen anpassen?

  • Und das wichtigste fehlt auch noch, ein fancy Adapter-Icon.

    Ich mach mich dran, ich habe eine Idee im Kopf.

    Da aber diese Daten über den Empfänger bereits aufbereitet werden können und dessen Spannungsversorgung und Kommunikationsschnittelle auf kurze Distanz fest mit dem Raspi verkabelt sind, könnte man auf der 'letzten Meile' vermutlich auf ein kompliziertes Protokoll verzichten.

    Das ist sicherlich richtig, mit gewissen Grenzen. Das serielle Protokoll ist jetzt 38400 Bd, was nicht gerade rasend schnell ist. Das kann man mit einem 8MHz auf 57600 Bd aufmotzen. Es ist deshalb so wichtig weil die Ankunft eines Pakets so schnell wie moeglich abgearbeitet werden muss damit ein zweites das unmittelbar darauf folgt ebenfalls korrekt empfangen werden kann. Das heisst es sollte nicht eine Ewigkeit dauern die Daten übers serielle Interface zu bekommen. Auf ein paar mehr oder weniger Bytes kommt es aber nicht an.

    Dafür wäre das TinyRX4-Protokoll oder eine Weiterentwicklung davon, auch hinsichtlich der Erweiterbarkeit, sicherlich gut geeignet.

    denke ich auch.

    Die Frage ist jedoch, wie viel Anwender arbeiten bereits mit dem jetzigen Protokoll

    nicht so viele, wir sind noch in der Anfangsphase.

    Gibt es bereits Programme, die auf die Daten in jetziger Form angewiesen sind und lassen sich diese unproblematisch anpassen?

    ja und ja. Also meine Python Skripte halt. Habe ich aber noch nicht oeffentlich gemacht, muss ich erst ausmisten.

    Ist eine Funktionserweiterung mit dem jetzigen Protokoll ohne Aufwand möglich oder muss man dann sowieso die externen Anwendungen anpassen?

    Eine Funktionsanpassung ist leicht moeglich, aber mal ehrlich: das existierende Protokoll ist nicht in sich konsequent oder konsistent, da ist viel Beliebigkeit drin. Ich habe wirklich nichts dagegen sich eng am TinyRX4 zu orientieren.

  • Ich lese mit und glaube alles zu verstehen, bin mir aber trotzdem unsicher um was es jetzt konkret geht :)

    Speed ist ja schön und gut, aber es muss auch stabil sein. Wenn bei 57600 Bd mehr Störungen auftreten, haben wir auch nichts gewonnen.

    Wie sieht denn das "Protokoll" vom TinyRX4 jetzt genau aus?

    Stabil läuft bei mir die Aufzeichnung übrigens noch nicht. Kann aber nicht sagen ob es jetzt an den vielen Fehlermeldungen liegt die der Empfänger an den iobroker Adapter weiterleitet, oder ob die Funkstrecke nicht ganz perfekt arbeitet. Bei meinem 10h Test über die serielle Schnittstelle gab es keine Verluste. Heute hat der iobroker einmal komplett die Anzeige eingestellt (nix mehr im Log) und einmal waren nur noch Fehlermeldungen im Log und keine korrekten Werte mehr. Nach einem Reboot lief es dann wieder.

    Ich muss Mal abgeschirmte Kabel verwenden und den Empfänger an einen besseren Empfangsplatz stellen.

  • Poste bitte mal das log, am besten als Dateianhang.

    Wenn es am Adapter liegt könnte ich darin evtl. etwas erkennen.

    Falls das nochmal passiert, schau mal bitte auf der Seite 'Instanzen' ob der Kreis links neben dem Adapternamen noch grün ist und dann starte nur mal den Adapter über die Schaltfläche mit den Pfeil im Kreis rechts neben dem Adapternamen neu.

    Und natürlich wieder das log posten.

  • Ja, der Kreis war noch grün und das Log sieht immer gleich aus. Denke da kann man nichts rauslesen:

    Spoiler anzeigen

    Frequenz wechseln, Kabel verlängern und ggf. abschirmen und dann im Sketch die Debug Infos rausnehmen sollte schon viel bringen. Und zum testen vielleicht alle 5 bis 10min senden. Die aktuell 48 Datensätze pro 24h sind etwas wenig.

    Allerdings hatte ich heute über den Tag auch zwei Mal NULL als Wert drin stehen.

    Werd das Mal beobachten...

    Gruß
    LED

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!