Entwicklung: Temperatur Funk Sensor

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)

  • Was mir vorschwebt, ist die Möglichkeit, am Pi sowohl Temperaturen von den Sensoren zu empfangen, als auch Steckdosen vom Pi aus zu schalten. Geht das mittlerweile?

    Der RFM12B macht normalerweise nur FSK; ASK/OOK kann er nur mit Mühe. Ein ASK/OOK-Transmitter kostet nur ein paar Euro, dazu evtl. noch ein Booster auf 12V und gut. Die Ansteuerung übernimmt entweder der Pi selbst, oder man benutzt den 328 (z.B. Pro Mini), der gleichzeitig auch den RFM12B-Empfänger ausliest.


  • Hallo!
    Ja interresse an der Software besteht! :bravo2::thumbs1:
    Ich versuche schon länger vergeblich mir eine gut laufende Software zu schreiben die über Websockets läuft (auch Node.js). Bisher bin ich immer gescheitert die Daten im Hintergrund nachzuladen... =(:no_sad:

    Du kannst dir die Software da holen:
    https://drive.google.com/file/d/0BzAhcW…iew?usp=sharing

    Es gibt vier Seiten - ein Display mit den gerade aktuellen Daten, ein 2 Tage-Diagramm, ein 10 Tage-Diagramm mit Stundendurchschnitt und ein Allzeit Diagramm mit Tages-Min/Max. Die beiden ersten sind in Echtzeit mit Websockets, die anderen statisch.
    Ist natürlich für meine speziellen Anforderungen geschrieben, d.h. du wirst das für dich anpassen müssen und alles was du nicht brauchst rauswerfen, zB Taupunktdifferenz usw...
    Voraussetzung ist, dass Node.js am Raspy installiert ist, an Modulen brauchst du express, serialport, mysql, socket.io und swix - du kannst diese auch mit npm installieren - package.json liegt bei.
    Es liegt auch ein sql File bei für die MySQL Tabellenstruktur, anders als meigrafd hab ich alle Daten in einer Tabelle sdata.
    In die zweite Tabelle ddata werden täglich 0 Uhr per cron die Tagesmaxima und Minima geschrieben und der Tag älter 3 Monate in der Haupttabelle wird gelöscht.

  • Hallo,
    ich habe Probleme die TinyTX Boards zu flashen (USBasp). Einmal hats geklappt, aber danach nicht mehr.
    Einen losen Attiny84 direkt programmieren geht in unverändertem Setup immer wieder.
    Hier die Fehlermeldung bei den Tiny Boards aus der Sammelbestellung:

    avrdude: Yikes! Invalid device signature.
    avrdude: Expected signature for ATtiny84 is 1E 93 0C

    Ich habe lange per google gesucht und folgendes gefunden:

    http://www.mikrocontroller.net/topic/350583#3895567
    Nach dem ersten Programmieren wird dein RFM bedient und stört nachfolgend die Kommunikation zwischen Programmer und Tiny. Ich hatte das gleiche Problem mit einem ATMega128 und RFM70. Die Lösung waren zwei Jumper in MOSI und MISO.

    Nun sind die Attinys auf dem TinyTX (aus der Sammelbestellung) als SMD fest verbaut. Jumper sind keine Option.
    Kann jemand die Aussage oben bestätigen? Wie programmiert Ihr Eure Boards mit fest bestückten Attiny?


  • Problem mit dem S7V8A ist nur das die Batterien nicht leer gelutscht werden - unter 2.7V will der nicht mehr arbeiten:


    Inwiefern das allgemein relevant ist weiß ich aber nicht. Davon hab ich zu wenig Ahnung - hab nur mal gelesen das leere Batterien noch 1V hätten, aber keine Ahnung ob man davon dann noch weiter boosten kann


    Kommt doch nur darauf an wieviele Batterien verwendet werden oder nicht? :s Wenn ich 4xAAA Batterien nehme, dann wird doch eine Batterie auf 0.675V leer "gelutscht". Nehme ich 6, bin ich schon bei 0,45V. Irgendwo hier hatte ich das auch mit auslaufenden Batterien gelesen, deswegen würde ich vielleicht nicht ganz so weit runter gehen. Allerdings weiß ich nicht inwiefern das bei den heutigen Batterien noch relevant ist. So wie ich das mitbekommen habe, kann man eine Batterie so zwischen 1,0-1,2V als leer betrachten. Allerdings müsste man diese Werte mal nachprüfen. Wenn ich aber jetzt mal eine Batterie bei 1.0V als leer betrachte, sind doch 0,45V doch gar nicht mal so schlecht!

    Also meine Überlegung wäre das hier. Und so wie ich das sehe, kann man die ja eigentlich einfach an unsere Boards ranhängen. Der Step-Down regelt z.B. dann die 4 oder 6 Batterien runter auf 3.3V.

    EDIT: Link wurde nicht eingefügt.

    Nur durch Zeit vermag die Frucht zu reifen.......oder zu verfaulen!

    Einmal editiert, zuletzt von Heliox (9. September 2015 um 19:53)


  • Hat schonmal jemand 2 Temperatursensoren angeschlossen und die Daten an den Pi gesendet?


    Falls es um den DS18B20 geht: in Send_DS18B20_Watchdog.ino ist ja schon eine auskommentierte Zeile mit temp2 drin. Die temp2 musst Du dann noch an den msg-String pappen (z.B. als t2), und vielleicht vorher schauen, ob in msg genug Platz ist. Und der Empfänger muss natürlich das t2 auch auswerten.

  • Hallo,

    inwischen gibt es die erwähnten Funkmodule in einer neuen Version:

    http://www.seegel-systeme.de/produkt/raspyrfm-ii/

    Diese verwenden einen RFM69 Chip, sind deswegen einfacher anzusprechen und die Kommunikation zum Modul ist nicht mehr so zeitkritisch. Außerdem unterstützt dieser Chip OOK Modulation, d.h. man kann damit Funksteckdosen ansprechen (in der 868 MHz Version z.B. die FS 20 Steckdosen, in der 434 MHz Version die Intertechno, Logilight, etc.)

    Guß & Spaß

  • Ich werd noch weich im Keks .... hab vor einigen Wochen die Tinys beschrieben und alles war gut.
    Jetzt wollte cih was anpassen und testen und habe nur den schon funktionierenden Sendersketch nochmal kompiliert und bekomme jetzt nurnoch diese Kacke und weiss net weiter. Dafür stecke ich nicht tief genug in dem Ganzen drin.
    Die "Candidates" die er da aufzählt finde ich so nicht in meiner Print.h
    Es lief ja auch vorher.


    Code
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\Print.cpp:33: error: prototype for 'void Print::write(const char*)' does not match any in class 'Print'
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\/Print.h:75: error: candidates are: virtual size_t Print::write(const uint8_t*, size_t)
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\/Print.h:74: error:                 virtual size_t Print::write(const char*)
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\/Print.h:73: error:                 virtual size_t Print::write(uint8_t)
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\Print.cpp:40: error: prototype for 'void Print::write(const uint8_t*, size_t)' does not match any in class 'Print'
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\/Print.h:75: error: candidates are: virtual size_t Print::write(const uint8_t*, size_t)
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\/Print.h:74: error:                 virtual size_t Print::write(const char*)
    D:\-=] Progz [=-\Arduino\Sketches\hardware\tiny\avr\cores\tiny\/Print.h:73: error:                 virtual size_t Print::write(uint8_t)
    Fehler beim Kompilieren.

    Print.cpp


    Print.h


  • Die "Candidates" die er da aufzählt finde ich so nicht in meiner Print.h

    In meiner Print.h gibt's diese beiden, die void liefern:

    Code
    virtual void write(const char *str);
        virtual void write(const uint8_t *buffer, size_t size);

    Ich verwende den (älteren?) Core von Google Code.
    In https://github.com/arduino/Arduin…arduino/Print.h und https://github.com/arduino/Arduin…duino/Print.cpp liefert Print::write jeweils size_t.

    Irgendwie scheinen die beiden bei Dir gemischt worden zu sein.


  • Also hier steht was, dass die neuen Versionen OOK im "compatibility mode" nicht unterstützen, was auch immer das heißt... http://openenergymonitor.org/emon/node/10167

    Das bezieht sich auf die Software; wenn diese in den compatibilty mode gestellt wird, verhält sich das RFM69 quasi wie ein RFM12, kann also kein OOK.
    Funksteckdosen kann ich erfolgreich mit dem RFM69 ansprechen:

    http://www.seegel-systeme.de/2015/09/05/fun…rry-pi-steuern/

  • Sooo zwei Sensoren an einer Node laufen.
    Auch das Problem mit der Print.h habe ich behoben bekommen.
    Hab einfach ne komplett neue Arduino Umgebung gezogen und das Sketchbook von meigrafd eingefügt.

    Jetzt aber mal ein anderes Problem: Kann es sein, dass die Grafiken gecached werden? Das muss ich aber wohl sicher in meinem Webserver prüfen oder?
    Mir fehlen heute schon wieder ne halbe Stunde auf den Diagrammen obwohl die Daten auch in der Liste zu finden sind.

    • Offizieller Beitrag

    Brauchst noch jemand fertig verlötete TinyTX und/oder Zubehör?
    TinyTx3 Sender - DHT22 RFM12B 433MHz

    :P

    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.

  • Nabend

    Hat jemand mal die Stromaufnahme von den Sendern gemessen?
    Bei mir zeigt das Multimeter einen schwankenden Wert von deutlich unter 100mA an.
    Aber kann ich das mit einem Multimeter, welches ja auch nur in bestimmten Intervallen misst
    überhaupt richtig messen?

    Gruß Kolja
    Automatisch zusammengefügt:

    Mal recherchiert:
    Stromaufnahme Funkmodul: max 23mA
    http://www.elektronik-keller.de/index.php/atme…rfm12-funkmodul

    Stromaufnahme vom ATtiny84: 3,5mA
    http://www.atmel.com/Images/doc8006.pdf

    Stromaufnahme LED: geschätzt 20mA

    In Summe dürften es also etwas mehr als 50mA sein.

    Die gemessenen Werte schwanken zwischen 40mA und 60mA.

    Einmal editiert, zuletzt von kolja (5. Oktober 2015 um 02:08)


  • Jetzt aber mal ein anderes Problem: Kann es sein, dass die Grafiken gecached werden? Das muss ich aber wohl sicher in meinem Webserver prüfen oder?
    Mir fehlen heute schon wieder ne halbe Stunde auf den Diagrammen obwohl die Daten auch in der Liste zu finden sind.

    Das kommt auf deine Konfiguration an. Drück mal STRG+F5 um den Cache vom Browser zu leeren und ein vollständiges neuladen des Content zu erzwingen.

    Ich werde in nächster Zeit aber noch ein WI auf Basis von HighCharts bereitstellen.. Dort werden keine Bildchen mehr generiert sondern richtiges JavaScript genutzt ;)


    Hat jemand mal die Stromaufnahme von den Sendern gemessen?

    TinyTX3 oder TinyTX4 ? :s

    Beim TX4 können es nur 60mA bis max. 140mA sein da der Booster nicht mehr liefern kann :fies:
    Tatsächlich gemessen hat das aber glaub ich noch niemand... Wenn dann müsste man aber eine Messung ohne Sensor und eine weitere Messung je nach verwendetem Sensor durchführen, da die Sensoren ebenfalls unterschiedlich viel Strom brauchen.

    ATtiny84 oder ATtiny84A ist aber auch ein Unterschied.
    ATtiny84A ist die sog. 'Low Power' Version. Auch mit wie viel MHz er betrieben wird macht sich im Stromverbrauch bemerkbar. Aber auch wie er programmiert wurde (Sketch) spielt eine Rolle:
    Bei 8MHz verbraucht er ca. 10mA im Betrieb. Im Standby (PowerDown) gerade mal 0.3µA. Kommt der Watchdog dazu sind es soweit ich im Kopf hab ca. 6µA plus zB. alle 8 Sekunden kurz ca. 1mA.
    Die von dir genannten 3,5mA treffen nur auf einen Betrieb mit 1MHz zu.

    Was das RFM12B Module im Sleep verbraucht weiß ich allerdings nicht - es ist aber ja auch nur dann an wenn der ATtiny es verwenden will. RFM12 oder RFM12B ist btw auch ein Unterschied, ebenso wie 433MHz oder 868MHz :fies:

    //EDIT: Laut Beitrag#1053 (bezieht sich aber auf die TinyTX3):


    meigrafd

    ich habe nun auch den Stromfluss an den Sendern gemessen, aber auch nur mit billig Mulitmeter. Die Sketches ohne PowerDown ziehen bei mir ca 2mA im Leerlauf und so 7mA beim Senden.

    Mit Watchdog und Powerdown, zieht der Tiny ca 0,07mA.

    Weiter unten auf der Seite:

    RFM12B: 22mA TX current
    RFM12B: 11mA Work current
    RFM12B: 0.3µA Standby current

    Ich meine mich aber irgendwie dran zu erinnern das jemand genauere Messungen vorgenommen hat - finde ich nur grad nicht wieder...

    //EDIT2:
    Beitrag#1008:


    Sender und Empfänger liegen quasi nebeneinander.
    Die 1,02mA beziehen sich übrigens auf den Leerlauf, beim aktiven Senden beträgt der Verbrauch etwa 6-8mA + ca. 10mA für die LED (so genau kann ich das jetzt nich sagen, hab hier zu Hause nur ein einfaches Multimeter zum Messen). Die Werte sind aber denke ich soweit Realistisch. Nur der Leerlaufverbrauch ist viel zu hoch. Also kann es eigentlich nur am ATtiny oder RFM12b liegen, der nicht im korrekten Sparmodus läuft.

    Beitrag#1023:


    Nur nochmal eine kurze Rückmeldung bezüglich des Stromverbrauchs:

    - Originaler Sketch von der Startseite: um die 2mA
    - Sketch mit Watchdog: ~ 1,02mA
    - deine überarbeitete Variante (vor dem edit): ~10-12uA
    - nach dem edit: ~4-6uA

    Bitte beachten das ich das mit einem sehr einfachen Multimeter gemessen habe. Dieses zeigt auch nur Werte mit > 1uA +-1% an. Die Werte sind also nicht besonders genau und noch evtl. von weiteren Faktoren wie Toleranz der Bauteile usw. abhängig (und wie sauber ich gelötet hab ;)
    Sie dienen aber auf jeden Fall zur groben Orientierung.

  • Hallo!
    Meine Tinys mit DHT22 laufen jetzt brav seit ein paar Monaten, nur der Sensor Außen macht Probleme.
    Bei hoher Luftfeuchte > 90% geht der Feuchtesensor auf Maximum (99,9%) und hängt dort stundenlang fest. Dann fällt er auf Minimum (1,4%) (siehe Screenshot leichter Regen von 17:45 - 18:30) oder er wechselt planlos zwischen Max und Min. Nach einigen Tagen normalisiert er sich wieder.
    Der Sensor ist in einer guten Wetterhütte verbaut und bekommt auch bei starkem Regen kein direktes Wasser ab.
    Nach Recherche sind das Kondensatprobleme, der DHT22 dürfte für den Außenbetrieb nicht wirklich geeignet sein, siehe auch http://www.mikrocontroller.net/topic/328251#4033866)

    Meine Frage: Hat jemand andere Sensoren (Temperatur + Feuchte) verbaut, die aussen besser funktionieren?
    zB SHT21, BME280, ... beide sind I2C Sensoren, ist das mit dem ATtiny84 machbar? Der BMP085 is doch auch I2C, da gabs doch Probleme?

    Freu mich über jeden nützlichen Hinweis!!

    Tach'chen,

    ich habe hier längere Zeit nicht reingeschaut, deshalb die späte Antwort. Meine DHT22 am TinyTX4 laufen inzwischen 24/7, zumindest die die
    in Innenräumen stehen. Ich habe einen Außensensor auf dem Balkon, der überdacht und feuchtigkeitsgeschützt auf einem kleinen Tisch steht.
    Der TinyTx4 in dem kleinen dafür vorgesehenen Plastikgehäuse verbaut, dass IMHO auch recht dicht ist. Das Verhalten, dass die Feuchtemessung
    über Nacht hängenbleibt habe ich bei den derzeitigen Temperaturen auch schon beobachet.

    Bei mit hängt der Sensor dann aber komplett, so dass nur noch Ausschalten und wieder Einschalten hilft. Bisher kann man keine Vorhersage
    machen, wann es passiert - mal läuft der Sensor über eine Woche stabil, manchmal passiert es an 2 Tagen in Folge. Irgendwie nervig.

    Gibt es inzwischen neue Hinweise woran das liegen kann?

Jetzt mitmachen!

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