Entwicklung: Temperatur Funk Sensor

  • Ich mal wieder :)

    Gibt es eine Möglichkeit zu testen, ob ich meinen RFM12BSP gegrillt habe? Optisch sind keine Schäden zu erkennen...

    Kurze Vorgeschichte: Nach einigem hin und her habe ich einen TinyTX3 als Sender und einen als Empfänger zum laufen gebracht. Die Beiden liefen nun über Wochen Problemlos. Jetzt, da ich mal wieder etwas Zeit abzweigen konnte, habe ich weitere Sender gelötet und bin dann tot umgefallen, als ich die Reichweite getestet habe. Mit den Ringelschwanzantennen von ebay, die ich zuvor benutzt habe, kam ich auf keine 2m Reichweite!

    Kurz und (weniger) gut - ich habe den Ringelschwanz eines Senders gegen 16,7cm Klingeldraht ausgetauscht und siehe da - nun gingen schon 5m durch 2 Wände. Also habe ich auch den Ringelschwanz am Empfänger ausgetauscht - nichts geändert, alten Schwanz ab, Klingedraht dran, wieder angeschlossen - nischt...

    Im zweiten Moment dachte ich, ich habe den RFM 12BSP gegrillt - also habe ich nen neuen Empfänger gelötet - nur da ist wieder nischt :(

    Einmal editiert, zuletzt von doing (13. Februar 2015 um 17:21)

  • Wenn du den gekillt hättest würde er nix mehr tun.

    Wahrscheinlicher ist das es mit der Antenne Probleme gibt - löte einfach mal einen 17,3cm Hartkern Draht dran, also Ausschlussverfahren.

    Gewickelte Antennen haben immer eine geringere Reichweite als kerzengerade.

    Gewickelt: bessere Flächenabdeckung, weniger Reichweite
    Gerade: mehr Reichweite, weniger Flächenabdeckung ...


    Vielleicht hast du aber auch die Leiterbahnen kaputt gebrutzelt und jetzt nur noch haardicke Verbindungen...

  • Wie gesagt - optisch kann ich keine Schäden erkennen. Der Sender, den ich mit dem gleichen Klingeldraht bestückt habe, hat auch getan - bis ich den Empfänger umgelötet habe...

    Kann es am Klingeldraht liegen? Das ist einer von C... (Y Klingeldraht, 0,95mm Querschnitt) aber der passt ja nicht ins Lötauge, also habe ich gefeilt bis er gepasst hat. Ist das Blech? Einen Kupferkern hat der ja nicht...

    Aber wieso geht der Sender dann?

    ----------------------------------------

    Nachtrag: Also offenbar liegt es an mir oder an der Himbeere (kann eigentlich nicht sein :) ... Nachdem ich den Attiny mit nem Blink Sketch getestet habe und am Board - auch mit riesiger Lupe - keine Schäden erkennen konnte, habe ich den alten Schweineschwanz wieder angelötet - auch nach Reboot keine Änderung.

    Nach dem ich den Pi dann neu gestartet habe (mit Power disconnect) ging der Schweineschwanz Empfänger wieder. Gleiches Spiel beim neuen Empfänger mit Klingeldraht - nach Reboot keine Änderung - nach Power disconnect und Neustart des Pi geht auch der Empfänger mit Klingeldraht.

    Das, falls jemand ähnliche Probleme haben sollte... :)

    Einmal editiert, zuletzt von doing (13. Februar 2015 um 19:25)

  • Ich bin leider immernoch genervt von dem Conrad Klingeldraht, der sich schlecht in die Lötaugen der TinyTX3 löten lässt - hat jemand einen Tipp für den optimalen Draht?

    Und noch eine Frage: Ich löte nen 17,3cm Klingeldraht an den TinyTX3 sendet der brav von wo auch immer ich den hier im Haus hinstelle - tausche ich aber den Klingeldraht gegen 2cm Kupferlitze und dann 15,3cm Klingeldraht aus geht die Sendeleistung massiv in den Keller. Wie darf ich mir das erklären?

    Einmal editiert, zuletzt von doing (15. Februar 2015 um 19:48)


  • Wenn du hier nichts geändert hast

    Code
    #define LEDpin 8         // D8, PA2 - set to 0 to disable LED

    das Lötauge, das mit der 8 beschriftet ist > das vierte von links :)

    Nein, daran habe ich nichts geändert.
    Halte ich zum Testen eine LED an den Tiny Port 11 und 14 funktioniert die LED und ich sehen wenn ich den Sender einschaltet das die LED leuchtet und beim Senden der Daten ein kurzes Aufblinken.

    Halte ich die LED aber wie von dir beschrieben an das Lötauge 8 und das andere Bein an GND passiert nix. OK, ist die LED ist zwar nicht festgelötet, aber für den kurzen und schnellen Funktionstest sollte das doch ausreichen.
    Was mache ich falsch? :huh:

  • Während ich sehnsüchtig auf die sammelbestellung warte Frage ich mich, wieviele dht22 Sensoren man eigentlich sinnvoll mit einem tinytx4 anschließen kann?

    dann könnte ich z.b in den Keller einen Sender hängen und mit Leitungen zwei oder mehr Sensoren des Typs abfragen.

    Wäre ja super!


  • Halte ich die LED aber wie von dir beschrieben an das Lötauge 8 und das andere Bein an GND passiert nix.

    Welches Lötauge verwendest du denn für sowohl Anode als auch Kathode?
    Bitte mit eigenen Worten beschreiben.
    (wichtig ist auch Anode und Kathode zu unterscheiden, egal ist das nämlich nicht)


    Wie gesagt, die Beschreibung welches Lötauge oben auf dem TinyTX3 oder TinyTX4 über welchen ATtiny angesprochen werden kann, passt. Stellt man im Sketch " LED 9 " ein wird damit D9 gemeint und das ist ganz oben auf der Platine das mit " 9 " beschriftete Lötauge.
    Notfalls einfach messen und den Send_Tester.ino Sketch flashen, oder eben einen Blinker Sketch aus den ArduinoIDE Beispiel Sketches.


    Während ich sehnsüchtig auf die sammelbestellung warte Frage ich mich, wieviele dht22 Sensoren man eigentlich sinnvoll mit einem tinytx4 anschließen kann?

    Diese Frage wurde auch schon mal gestellt, irgendwo in den letzten Seiten dieses Threads... Ich wiederhol mich zwar ungerne aber hier noch mal eine andere Umschreibung:

    Theoretisch kann man so viele anschließen wie es Lötaugen gibt also von 0 bis 10 -> 6.
    Es gibt aber einige Begrenzungen in Form: der vom Sensor benötigten Pins, des damit zusammenhängenden Stromverbrauchs, oder des begrenzen Flash Speichers des ATtiny84 AVR's...

    Bezüglich Pins:
    Einfache ReedSwitches brauchen nur 2 Pins: VCC und GND.
    Sensoren wie DS18B20 oder DHT22 benötigen 3 Pins: VCC, GND und DATA (bzw DQ)
    BMP085 benötigt sogar mind. 4 Pins: VCC, GND, SDA, SCL

    Man kann bei einigen Sensoren zwar VCC und GND gemeinsam auf einen Pin verdrahten, aber nicht oben ins Lötauge VCC, da man den Sensor sonst nicht mehr Stromlos schalten kann (VCC von der Lötaugen-Leiste ist direkt mit VCC des ATtiny und dem Booster verbunden).

    Bedeutet also das ein Pin von 0 - 10 ebenfalls fürs abschaltbare VCC drauf geht, und somit wären es nur noch 5 mögliche Sensoren beim DS18B20 oder DHT22...
    Beim BMP085 verhält sich das etwas anders, da dieser I2C nutzt und dieser Bus bis zu 128 Devices über die selben Pins verwalten kann - vorausgesetzt jedes Device hat eine andere Kennung (i2c Address)


    Bezüglich Flash Speicherplatz:
    Insbesondere 1-Wire Sensoren wie der DS18B20 verbrauchen vergleichsweise sehr viel Speicherplatz, für jeden Sensor benötigt man hier mehr Code als bei den anderen Sensortypen.

    Aber auch beim DHT22 muss man für jeden DATA-pin ein Klassen-Objekt erstellen ( DHT22 myDHT2(DHT22_PIN); usw ), und im loop natürlich auch eine Abfrage einbauen sowie natürlich auch übertragen lassen usw... Vorallem aber weil der Sensor nicht nur Temperatur sondern auch Luftfeuchte erfassen kann, ist hier der Mehraufwand den Code zu erweitern nicht mal eben in 3 Zeilen getan.

    Beim DHT22 stellt das aber kein Problem dar, da dieser Sketch mit der JeeLib ziemlich klein und noch genug Spielraum vorhanden ist. Beim DS18B20 wird das allerdings nichts mehr und beim BMP085 könnte es auch knapp werden. (letzteres hab ich nicht getestet)

    Will man also mehr als nur einen Sensor an einen TinyTX betreiben, muss man am Sketch einige Änderungen vornehmen.


    Da ich aber nicht gewillt bin alle möglichen Kombinationsmöglichkeiten vorgekaut irgendwie durch zu spielen - bitte ich denjenigen das selber auszuprobieren.

    Und davon abgesehen muss die Anzeige dieser Werte ja auch irgendwie beschriftet werden... Hat ein TinyTX 5 Sensoren dran die aber alle unterschiedliche Orte anzeigen sollen, stellt sich die Frage wie eine universelle Anzeige wie FHEM oder auch mein Web-Interface diese speziellen Werte von den anderen unterscheiden können soll... Sicherlich gäbe es beim Selbstbau genug Möglichkeiten, aber eben keine Universelle.
    Auch hier müsste derjenige dann selber Hand anlegen.

  • :danke_ATDE:

    Ich habe den ganzen Thread gelesen und konnte mich nicht an "zweimal der gleiche Sensor" erinnern.

    Hab ich schon wieder was gelernt! War bisher von ausgegangen dass vcc bei den pins für die Sensoren ist (und schaltbar). Muss die Platine mal noch genauer studieren.

    Die Messwerte müsste man dann nicht nur durch den Sender identifizieren sondern durch das Tupel: (senderId, dth22_Nr). Diese hätten dann auch jeweils eigene Location.

    Die Library wird hierbei in die Sketches nur einmal geladen, so meine Annahme. Haben die Teile neben dem flashspeicher auch RAM? Hier denke ich würde dann pro Sensor des gleichen Typs mehr verbraucht. Aber ich werde das in paar Wochen gerne ausprobieren:-)

    Gibt es Erfahrung, wie lange die zuführenden Kabel zwischen dth22 und tinytx sein dürfen?

  • Habe nun endlich den RFM12PI geliefert bekommen.
    Nun wollte ich meinen selbst gelöteten Empfänger durch den RFM12PI ersetzen.

    Leider bekomme ich keine Daten mit den Sketches von Meigrafd übertragen.
    Habe https://github.com/meigrafd/TinyT…Send_Tester.ino ausprobiert. Hier habe ich, da ich 868MHz Module habe den entsprechenden Teil angepasst. Ebenso habe ich die Netzwerkgruppe an den Empfänger angepasst. Jedoch ohne Erfolg.

    Wenn ich das Sketch von Nathan nutze (https://github.com/nathanchantrel…TX_SendTest.ino) dann sehe ich auf der Konsole (Minicom) das Daten ankommen.

    Könnt ihr mir ggf. nen Tipp geben warum das Sketch von Meigrafd nicht und der von Nathan funktioniert?
    Habe ich etwas vergessen? Muss ich den RFM12PI irgendwie anpassen?

    Mittlerweile habe ich die Vermutung das es an der GATEWAY Variable liegen könnte. In dem Sketch von Nathan nutzt er "0" was für Broadcast stehen würde. Meigrafd senden explizit zu dem in der Variable definierten Node.

    Laut Minicom Ausgabe stimmt die Node ID des Empfängers aber mit der Node ID auf dem Sender (GATEWAY) überein. Auch die Frequenz ist korrekt eingestellt.
    Bin ein wenig ratlos. :huh:

    Heute Abend werde ich mal versuchen den Sketch von Meigrafd so anzupassen, dass dieser auch als GATEWAY "0" übergeben bekommt und schauen ob ich dann Daten empfange.

    Welches Lötauge verwendest du denn für sowohl Anode als auch Kathode?
    Bitte mit eigenen Worten beschreiben.
    (wichtig ist auch Anode und Kathode zu unterscheiden, egal ist das nämlich nicht)


    Wie gesagt, die Beschreibung welches Lötauge oben auf dem TinyTX3 oder TinyTX4 über welchen ATtiny angesprochen werden kann, passt. Stellt man im Sketch " LED 9 " ein wird damit D9 gemeint und das ist ganz oben auf der Platine das mit " 9 " beschriftete Lötauge.
    Notfalls einfach messen und den Send_Tester.ino Sketch flashen, oder eben einen Blinker Sketch aus den ArduinoIDE Beispiel Sketches.

    Werde heute Abend nochmals meine jetztige Antwort kommentieren bzw. editieren.
    Aber nur noch eine kleine Frage vorweg. Kann ich auch die zweite Reihe an Lötaugen verwenden? Sprich ist das Lötauge unter D8 gleichwertig wie das D8er?
    Natürlich gilt die Frage auch für das Lötauge unter GND.
    Wenn ich die Pläne des TX Moduls richtig verstanden habe, sollte das der Fall sein. Jedoch bin ich mir halt nicht 100pro sicher und kann es leider mit meinen Mitteln nicht nachmessen. =(

    Einmal editiert, zuletzt von hurr1c4n (17. Februar 2015 um 12:43)

  • hurr1c4n
    Habe das gleiche Problem. Der RFM12Pi empfängt bei mir nur .it dem Script von Nathan etwas.

    Ich nehme mal an, dass es an der Firmware liegt, welche mit den RFM12Pi "mitgeliefert" wird.
    Wenn ich mich richtig erinnere, basiert die Firmware ebenso wie Nathans Script auf der JeeLib

  • Die Firmware des RFM12Pi ist anders aufgebaut. Man muss diesen über UART konfigurieren und die empfangenen Daten sind Binär.

    Meine "Firmware" ist aber fest eingestellt und die empfangenen Daten sind Klartext.

    Ob JeeLib oder nicht spielt dabei keine Rolle.

    Ihr könnt aber problemlos die "Firmware" des RFM12Pi ändern - das Original ist über Github verfügbar.

    Aber wie gesagt, wenn ihr bei den Sendern meine Sketches nutzt, muss der Empfänger ebenfalls Klartext verarbeiten können. Der RFM12Pi erwartet aber eine "struct" also Binär und zeigt dann nichts an wenn er Klartext empfängt.

  • Wenn du am Empfänger dein Script (z.b. Sensor.pl) zur weiteren Bearbeitung der Daten entsprechend anpasst, dass sollte es auch mit Original-RFM12Pi FW (ich habe die Full* - kann auch Funksteckdosen ;-)) funktionieren.
    Ich habe die Sender auf Klartext umgestellt und in meinem Sensor.pl auf dem Pi mache ich die Auswertung/Konvertierung. Müsste dort im Thread beschrieben sein: Funk Magnetkontakt/Reed Switch zur Fenster/Tür Überwachung - TinyTx3


  • Die Firmware des RFM12Pi ist anders aufgebaut. Man muss diesen über UART konfigurieren und die empfangenen Daten sind Binär.

    Meine "Firmware" ist aber fest eingestellt und die empfangenen Daten sind Klartext.

    Ob JeeLib oder nicht spielt dabei keine Rolle.

    Ihr könnt aber problemlos die "Firmware" des RFM12Pi ändern - das Original ist über Github verfügbar.

    Aber wie gesagt, wenn ihr bei den Sendern meine Sketches nutzt, muss der Empfänger ebenfalls Klartext verarbeiten können. Der RFM12Pi erwartet aber eine "struct" also Binär und zeigt dann nichts an wenn er Klartext empfängt.

    Na super! Darauf muss man auch mal kommen.
    Danke für die Info.

    Gibt es irgendwo evtl. eine Anleitung wie man eine neue/andere Firmware auf den RFM12Pi bekommt? Die Anleitung auf OpenEnergyMonitor finde ich nicht gerade gut zu lesen bzw. übersichtlich.

    Außerdem verstehe ich nicht wie ich die .hex Datei erstellen soll, wenn ich z.b. deine Firmware für den Receiver verwenden möchte.

  • Die ISP (ICSP) Sockel sind standardisiert. Auch der RFM12Pi hat für ISP eine Ansteckmöglichkeit.

    Flashen tut man am einfachsten über ArduinoIDE - das compiliert den Sketch, erstellt also eine *.hex und führt dann auch die nötigen Befehle zum flashen mithilfe avrdude durch.

    -> http://wiki.openenergymonitor.org/index.php?titl…_the_Bootloader
    (etwas runter sind auch Bilder zu sehen wo die Belegung des ISP auch beschriftet zu sehen ist)


  • Die ISP (ICSP) Sockel sind standardisiert. Auch der RFM12Pi hat für ISP eine Ansteckmöglichkeit.
    ...


    Der Vollständigkeit halber: der ISP (InSystemProgramming)-Sockel ist ursprünglich von ATMEL und es gibt ihn afaik in zwei Ausführungen: einer sechs- und einer zehnpoligen.
    Näheres dazu z.B. -> hier <-
    cu,
    -ds-

    • Offizieller Beitrag

    By the way:
    Auf Anfrage bei Pollin, wann der RFM12B 433 S1 wieder lieferbar ist:

    Zitat

    Der Artikel ist leider komplett ausverkauft. Wir werden diesen nicht wieder ins Angebot bekommen.


    http://www.pollin.de/shop/dt/Njg4OT…fangsmodul.html


    Aber danke für den Tipp mit CSD Electronic. Der Shop hatte noch 48 Stück vorrätig.

    http://www.csd-electronics.de/200/cgi-bin/sh…43&AnbieterID=2

    Well in my humble opinion, of course without offending anyone who thinks differently from my point of view, but also by looking into this matter in a different way and without fighting and by trying to make it clear and by considering each and every one's opinion, I honestly believe that I completely forgot what I was going to say.


  • Wenn du am Empfänger dein Script (z.b. Sensor.pl) zur weiteren Bearbeitung der Daten entsprechend anpasst, dass sollte es auch mit Original-RFM12Pi FW (ich habe die Full* - kann auch Funksteckdosen ;-)) funktionieren.
    Ich habe die Sender auf Klartext umgestellt und in meinem Sensor.pl auf dem Pi mache ich die Auswertung/Konvertierung. Müsste dort im Thread beschrieben sein: Funk Magnetkontakt/Reed Switch zur Fenster/Tür Überwachung - TinyTx3

    Welchen Vorteil hätte ich denn, wenn ich den RFM12Pi mit dem Empfangs Sketch von meigrafd flashe, als wenn ich nur die Daten im Pealscript entsprechend anpasse?

    Ich meine es wird sicherlich schon einen Vorteil geben, warum meigrafd sich die Mühe gemacht hat einen Sketch für den Empfänger zu coden, als es nur im Perlscript anzupassen?!


  • By the way:
    Auf Anfrage bei Pollin, wann der RFM12B 433 S1 wieder lieferbar ist:


    http://www.pollin.de/shop/dt/Njg4OT…fangsmodul.html

    Pollin ist eh ein Saftladen. Ich werde da eh nix mehr bestellen.
    Laut Auskunft bei dem Hersteller des RFM12B werden die Module weiterhin produziert und es gibt keine Pläne das in den nächsten Jahren zu ändern.


    Welchen Vorteil hätte ich denn, wenn ich den RFM12Pi mit dem Empfangs Sketch von meigrafd flashe, als wenn ich nur die Daten im Pealscript entsprechend anpasse?

    Ich meine es wird sicherlich schon einen Vorteil geben, warum meigrafd sich die Mühe gemacht hat einen Sketch für den Empfänger zu coden, als es nur im Perlscript anzupassen?!

    Der Umgang ist leichter wenn es im Klartext übertragen wird.
    Das was verschickt wird kommt auch 1:1 genau so an. Verschickt man " v=3321&t=1732" kommt das auch genau so an, ohne es noch irgendwie umwandeln zu müssen, und kann auch genau so direkt weiter gereicht werden.

    Nachteil bei der von mir verwendeten Methode ist wäre das mehr Daten übertragen werden müssen, also die Länge/Menge/Größe der Daten ist etwas höher. Das merkt man aber nicht wirklich und hat so auch keine Auswirkungen.

Jetzt mitmachen!

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