Posts by nurazur

    Sehe ich das richtig, dass es aktuell nur möglich ist den HTU21D und den SHT3x auszulesen?

    SHT3x SHT2X


    das ist richtig. Aber man kann auch digitale "Ereignisse" wie z.B. einen Fensterkontakt oder das Ausloesen eines Bewegungsmelders übertragen. Ich habe auch Sketches für BMP280, SHT3X und DS18B20 in Vorbereitung (also, funktioniert schon, aber muss in eine Form gebracht werden dass man es auch veroeffentlichen kann).

    Bin derzeit im Urlaub, ich hoffe ich kann es Anfang September auf Github raufladen. Wird ein grosses Update.

    Was muss ich denn für die 1MHz beim Sender bzw. die 8MHz beim Gateway auswählen, jeweils mit und ohne Quarz?

    was meinst du mit Quarz? Moechtest du einen 8MHz Quarz verwenden (bessere Präzision des seriellen Interfaces, hoehere Baudraten moeglich) oder einen Uhrenquarz mit 32,768 kHz (niedrigster moeglicher Ruhestrom)?


    Gateway läuft immer so schnell wie moeglich, also am Besten mit 8MHz Quarz. Das Gateway hat keinen Schlafmodus, man braucht also keinen Uhrenquarz. Mit 8MHz Quarz ausgestattet ist der TiNo mit dem Arduino Pro-Mini identisch. Also in der IDE den Arduino Pro-Mini auswählen (3.3V Variante) und auf "burn Bootloader" klicken.


    Desweiteren musst du dir überlegen ob du lieber mit oder ohne Bootloader arbeitest.

    Geliefert wird der TiNo immer MIT Bootloader.


    Würde es nicht reichen die vier Varianten der AVRDUDE Argumente in der Doku zu hinterlegen?

    sind doch hinterlegt:


    Variante auswählen, COM Port des Programmers einstellen, Programmer Typ einstellen, und auf "Burn Bootloader" klicken. Das muss man auch machen, wenn man keinen Bootloader verwenden will.

    Die Fuses sind in der boards.txt hinterlegt die mit dem TiNo Modul für die Arduino IDE geliefert weden.


    -U lfuse:w:0x63:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m

    leider total daneben, du tust dir keinen Gefallen wenn du da rumprobierst und dich nicht auskennst. Im schlimmsten Fall machst du den TiNo inoperabel!

    Wenn noch jemand noch irgendwelche Ideen hat, immer her damit.

    Spontan fallen mir 2 Dinge ein:


    1. Ueberwachung der VCC der Sensoren. Z.B. eine Warnung ausgeben wenn die Spannung unter 2V gefallen ist. Dann sollte man die Batterie dringend wechseln.


    2. Uberwachung der Synchronisation mit dem Rolling Code. Da muss ich mir allerdings noch Gedanken machen wegen der Re-synchronisation, z.B. nach einem Batteriewechsel. Wenn die Synchronisation verloren ist, eine Warnung ausgeben und den Datenpunkt ignorieren. Denn es kann sich ja um eine Fake-Message des boesen Nachbarn handeln.


    Könnte man auf diesen Sensor (CCS811 CO2 eCO2 TVOC) an den Tino dran hängen?

    selbstverständlich. Allerdings frage ich mich ob das mit Batterie sinnvoll ist, da der Sensor echt viel Strom zieht.

    Das hier finde ich im Datenblatt:

    the conditioning period is the time required to achieve good sensor stability

    before measuring VOCs after long idle period.

    After writing to MEAS_MODE to configure the sensor in mode

    1-4, run CCS811 for 20 minutes, before accurate readings are

    generated.

    Ich habe mir jetzt mal so ein Teil zum Testen bestellt.

    Super! Vielen Dank für den Haufen Arbeit. :thumbup::danke_ATDE:Das ist also der Adapter für TiNo Version 1.01.

    Eine Version 2.0 ist in Vorbereitung mit einer Reihe von Verbesserungen und Ergänzungen. Dabei wollte ich das Interface an das Protokoll vom TinyRx4 anpassen, weil es mir insgesamt besser für zukünftige Erweiterungen gerüstet erscheint.

    die Platine mit Klarlack, Expoxidharz oder PlastiDip versiegeln.

    bloss nicht! HF Komponenten reagieren extrem empfindlich auf sowas. Du musst schauen dass das Gehäuse einigermassen dicht ist, also das ganze Gehäuse in PlastiDip tauchen müsste gehen.

    Ich weiss es auch nicht viel besser, ich mache halt ins Gehäuse ein 5mm grosses Loch und klebe den Filter dahinter. Dass der TiNo trozdem vor Regen und Schnee einigermassen geschützt aufgestellt werden sollte versteht sich von selbst.

    Wenn du einen wasserdichten Temperatursensor brauchst, da gibts diese Dallas DS18B20 Sensoren die versiegelt sind. So einer baumelt bei mir im Teich seit einer Ewigkeit. Die Elektronik dann in ein wasserdichtes Gehäuse ausserhalb.

    so wie es aussieht, ist es aber sogar noch schlimmer geworden:

    sieht fast so aus als würdest du dir den HF Dreck jetzt übers Kabel einschleppen.



    Leider hab ich den Sender schon mit Silikon verlebt und in den Garten verfrachtet.

    Du hast aber schon daran gedacht in das Gehäuse ein Loch zu bohren damit die Luft an den HTU21D ran kann? Und du hast auch eine Filterkappe über den Sensor gesteckt, weil wenn der nass wird, kanns schon mal sein dass er Unsinn misst.


    Ich denke z.Z darüber nach wie man die Konfiguration OTA (over-the-air) machen kann, damit wird vieles einfacher. Dazu muss man am Gateway Daten bereit stellen, und wenn der TiNo einen ACK verlangt die Daten schicken.

    Ja, das ist logisch, denn das Tool setzt einen Puls am DTR Pin voraus. Ich arbeite immer mit FTDI Adaptern, da wird der Puls automatisch beim Oeffnen des seriellen Ports ausgeloest.

    So, wenn du keinen FTDI Adapter hast und so den Empfänger an einen USB Port des Raspberry hängen kannst, musst du den Empfänger NACH dem Start des Tools zurücksetzen. Dies geht mit einem Jumperkabel, indem du Pins 6 (Masse) und Pin 5(Reset) des ISP Adapters kurz verbindest und wieder oeffnest.

    Dann sollte es gehen.

    Im Foto ist die Brücke schwarz eingezeichnet, nicht vergessen sie wieder zu oeffnen, sonst arbeitet der Prozessor nicht.

    Eventuell geht es auch indem du die VCC kurz wegnimmst und den TiNo so neu startest. Das ist dann wahrscheinlich einfacher.

    der Receiver sollte sich dann melden mit calibration mode.. Danach pwd eingeben. Das ist eine Abkürzung um zu vermeiden dass man immer wieder das Passwort eingeben muss. Auch hier gibt es viel Raum für Verbesserungen.


    Turorial für das Tool ist in der Dokumentation auf meinem Github repository. Es ist, ehrlich gesagt, gewoehnungsbedürftig. Da arbeite ich noch dran.

    Es war mal mein Job genau solche Dinge zu automatisieren.


    Um die Frequenz anzupassen muss ich beide Sketche ändern? Sender und Empfänger, oder?

    ja klar! Am Sender 4800 Baud, am Empfänger 38400 Baud, geht aber nur mit dem Tool tinocal.py (Linux) bzw. tinocal_v007.py (Windows). Ist in meinem Github Repository.


    Aber am Kabel bin ich schon dran. Hab hier ein dreiadriges Mikrofonkabel mit Schirmung gefunden, müsste doch gehen wenn ich RX/TX//VCC darüber laufen lasse? Oder die Stromversorgung lieber getrennt lassen?

    Ich verwende Ethernet CAT6 Kabel, für jede Leitung RX,TX, VC ein Päärchen verdrillte Leitungen, eine Leitung jeweils an Masse.

    Mikrophonkabel geht wahrscheinlich auch, aber das Wichtigste ist die räumliche Trennung zwischen Pi und Empfänger!

    Hallo L.E.D.

    für meinen Geschmack hast du zu viele Fehltriggerungen, ca. 2 pro Minute. Versuche doch mal den Empfänger weiter weg von allem was Strahlung abgeben kann aufzustellen, also: mindestens 30cm vom Raspberry Pi, mindestens 50cm von jeder Sorte von LED Bildschirm, 1m vom Ferseher und 1m von Powerline Geräten. Auch jede Form von Schaltnetzteilen kann strahlen, manche mehr, manche weniger. Ich hatte anfangs auf 868.00 MHz gearbeitet, aber im Spektrum Analyzer habe ich dann gesehen was da alles los ist. Ich bin auf 865.00 MHz ausgewichen, da ist es (bei m ir zuhause) wesentlich ruhiger.

    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 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.

    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?

    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 hab deinen source Code angeschaut, ohne alles zu verstehen, deshalb eine Frage:

    Code
    1. if (/r=[0-9]+&/.test(data)) {
    2. 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.

    Die Frage ist allerdings wie sieht das serielle Protokoll beim TiNo Empfänger genau aus?

    Ich habe mich um diese Frage bisher nur am Rande gekümmert. In anderen Worten, es gibt kein festes Protokoll. Das heisst ich kann mich hier einfach dem TinyRx4 anschliessen, hätte aber einige Ergänzungen vorgeschlagen:

    zusätzliche Variable rssi (Signalstärke)

    zusätzliche Variable fo (Frequenzversatz)

    zusätzliche Variable intr (Interrupt, bitcodiert bis zu 8 Interrupts koennen registriert werden, im Moment sind es max 4)

    zusätzliche Variable lqi (link quality Indicator, Erweiterung für die Zukunft)


    Die andere Frage ist, wie reagiert ioBroker auf Debug-Meldungen? Beim Reset des TiNo werden einige Zeilen zur Information über das serielle Interface gemeldet, z.B. Software Version, Datum, und EEPROM Zustand etc.

    Ich gehe mal davon aus dass ioBroker solche Meldungen ignoriert?

    super! - ich hatte zufälligerweise einige Anfragen wegen ioBroker für mein TiNo Projekt. Nachdem TiNo ja aus dem TinyTx4 Projekt entstanden ist, passt das genau.


    Eine Frage habe ich zum seriellen Protokoll:

    Soweit ich das erkennen kann, ist das Protokoll wie folgt:


    <nodeID><Leerzeichen><variable1>=<Wert>&<variable2>=<Wert>...\n


    also z.B.:

    17 v=3302&t=2765&h=6550\n


    Bedeutet: Node 17 meldet eine Batteriespannung von 3.302 V, eine Temperatur von 27.65 Grad C und eine Luftfeuchte von 65.5 %

    richtig?


    Für einige Variablen muss man noch die Skalierung festlegen, oder ist man da frei? Z.B. ist die Variable v in [mV] skaliert, und wird im IoBroker Adapter auf [V] umgerechnet.


    Wenn man jetzt Frequenzversatz und RSSI auch loggen moechte, wäre das moeglich? z.B mit den msg Variablen rssi und fo


    Die msg Variable 'r' ist im Moment 0 oder 1 - Ich habe die TiNo Hardware so erweitert dass man bis zu 4 Reed Kontakte erfassen kann, die dann auf 4 bits gemappt werden, also Kontakt eins auf Bit 0, Kontakt 2 auf bit 1 etc. Bei mir ist die Anwendung eher eine Fernbedienung mit 4 oder mehr Tasten, je nach Mapping. Die Variable 'r=4' sagt also dass Kontakt 2 einen Interrupt ausgeloest hat.


    Wäre diese Erweiterung moeglich?

    ich weiß nicht ob das Projekt jemals fertig wurde..

    Doch, und es ist sogar einwandfrei dokumentiert : Link

    Aber das Projekt wurde inzwischen weiterentwickelt und entscheidend verbessert.


    Aber auch wenn, der Attiny84 ist dafür zu klein.

    Also wenn ich in den Source Code hineinschaue, dann sehe ich Kompilierflags fuer den ATTiny84. Man kann das ja mal unverbindlich mit der Arduino IDE kompilieren und schaun ob es reinpasst.

    Trotzdem würde ich aus den genannten Gründen davon abraten.


    Der JeeLink ist eigentlich nichts anderes als ein Atmega328 + RFM12B / RFM69CW + USB-TTL (3.3V) Adapter. Das kann man sich in 0,nix mit einem Arduino Pro Mini (3V Version!), einem USB-TTL Adapter und einem RFM Modul selbst zusammenloeten.


    Wenn es etwas schicker und/oder professioneller sein soll kann man eine TiNo-LC Platine nehmen. Siehe >>> HIER <<<

    Dazu brauchts noch einen USB-TTL Adapter, z.B. >>>diesen<<<, den kann man direkt auf die TiNo Platine drauf loeten.

    Technisch besser wäre der TiNo-HP, aber der benutzt das RFM69HCW Modul, da müsste man also den HF Treiber anpassen.

    Es handelt sich um die Essenz von dem ganzen Schmarrn der im TV verzapft wird. Da hilft nur eins: abschalten!


    Im Ernst: Man fixiert Spulen oder Drehkos oder sonstige bewegliche Teile die der Kalibrierung dienen mit Industriewachs. Das hat einen Schmelzpunkt von etwa 50 Grad. Wenn der TV also wärmer als 50 Grad wird, koennte Wachs auslaufen.