Selbstbau Funkthermometer 433Mhz

[juergs]

Hallo Markus,
manchmal ist man schon so in der Materie drin, das einem nicht auffällt das es für Einsteiger
doch einige Stolpersteine gibt. Dann muss man doch etwas "LaCrosse-Sensor"-Aufklärungsarbeit leisten:

1. LaCrosse wird eher mit JeeLink und 868 in Verbindung gesehen-> FSK (!).  Ist aber OOK + 433Mhz mit CUL433

2. LaCrosse bezieht sich hier nur auf das Protokoll und nicht auf den Sensor und das Übertragungsmedium.

3. Die 433 MHz implizieren ja: Empfang über den 433 Mhz Cul. Mit "autocreate" funktioniert das in FHEM recht gut automatisch.

4. Es wird von FHEM ein "CUL_TX"-Device mit der entsprechenden ID angelegt.

5. Die Daten des Devices entstammen aus dem Log, z.B. "FileLog_CUL_TX_115"

6. Klickt man das Log in FHEM an erscheint ein kleiner Text unterhalb des "Regexp parts"-Blocks: mit "Create SVG plot"  erzeugt man die Grafik dazu.

7. Evtl. kann der Signalduino auch dieses Protokoll auch empfangen und dekodieren, habe es aber noch nicht ausprobiert.

Unten habe ich Dir ein Beispiel dazu mit einem Sensor mit der ID=115 beigefügt.
Dieser liefert die Temperatur und eine konstante Luftfeuchte, weil diese im Sensor nicht gemessen wird.

in welchem Modus(1 oder 2)

Kenne ich nicht... CULFW z.B. die V1.66 flashen, in Betrieb nehmen und warten bis die Funk-Telegramme kommen, das wars.

Nun hab ich feststellen müssen, dass der Lacrosse-Empfang gar nicht so einfach ist

Doch isses 

Warum hattest Du TCM als "Basis-Protokoll" verworfen ?

Weil der Initiator des Threads den Code nicht beifügen wollte, und ein anderer Forumteilnehmer war so freundlich, seine Arbeit
wiederum hier ins Forum zu stellen. Danke dafür an dieser Stelle.
Man könnte beide Protokolle mit einbauen, wenn es noch in den ATtiny passt. (z.B. per Jumper wählbar.)
So kommt dann eins zum anderen ...

ausgebauten aus einem Hideki-Funkthermometer behelfen. Klappt aber leider nicht

Kenne das Modul nicht. Stell einfach mal ein Bild des Senders hier ein. Woher weißt Du, dass er nicht funktioniert?

Ich entwickle hauptsächlich unter Windows 10 mit VisualStudio2015 und dem VisualMicro-Addin.
Für das Forum hier baue ich das Ganze um, damit es mit der Arduino-IDE auch funktioniert.

Trotzdem: beherzige mein Vorschlag des eigenen Threads, ich würde Dir beim Fenstersensor helfen,
wenn ich Zeit habe ... 

Anmerkung zu den CUL_TX: Die mit der ID unter 100 sind nicht meine ... 
Die mit H= 56.7 haben keine Luftfeuchte-Sensoren, müssten eigentlich diesen Wert nicht mit senden.
Die im Status "defined" senden seit längerer Zeit nicht mehr (Batterie gewechselt?).

[KölnSolar]

danke für die Info.

Kenne ich nicht

Hier https://forum.fhem.de/index.php/topic,36565.15.html hattest Du Dich aber auch verewigt.  Und da geht es ja um CUL und Lacrosse.
Irgendwo hab ich also noch ne Verständnislücke, wie der CUL(culfw) Lacrosse-433 ohne Aktivierung des native-modes "entdeckt".  Du belässt den CUL ganz "normal" im rfmode=SlowRF ?

Woher weißt Du dass er nicht funktioniert?

Weil mir eben kein device angelegt wird und auch nix im Log mit X67 auftaucht, zumindest nicht im native-mode. Mit rfmode=SlowRF tut sich auch nix. Und gerade hab ich mir wohl den ersten digispark zerschossen 

2. LaCrosse bezieht sich hier nur auf das Protokoll und nicht auf den Sensor und das Übertragungsmedium.

Wie meinst Du das ? Protokoll = Datenstruktur und Übertragungsmedium = Funkprotokoll ? Mit welchem Funkprotokoll wird denn übertragen ?
Schönes Wochenende, Markus

[juergs]

set raw modus 1 (oder 2)

Das bezog sich in der Tat auf die LaCrosse-Sensoren und Benennung "LaCrosse" sei Dank die im 868MHz-Band senden.
Also eigentlich was völlig anderes ... (Empfang via CUL868) . "LaCrosse" ist hier also der Sensor gemeint und nicht das Protokoll (imho).

Irgendwo hab ich also noch ne Verständnislücke, wie der CUL(culfw) Lacrosse-433 ohne Aktivierung des native-modes "entdeckt".  Du belässt den CUL ganz "normal" im rfmode=SlowRF

Da bringst Du zwei Sachen durcheinander:
Für den CUL433 brauchst Du nichts weiter tun, also kein "set CUL raw 1/2" oder ähnlliches (ist für den 868 gedacht.).
SlowRf ist glaube ich, ist nur für die FS20-Aktoren gedacht. Schau da noch mal im FHEM-Wiki  oder Forum nach.
In der Konfiguration des CUL433 ist SlowRF bei mir nicht gesetzt.

Bezeichnung "LaCrosse" ist für mich nur das Protokoll, unabhängig von dem Frequenzband in dem es benutzt wird.
Aber in den Frequenzbändern 868MHz und 433MHz kommen zwei unterschiedliche  Funkprotokolle zum Einsatz: 868=FSK und 433=OOK.

Protokoll = Datenstruktur und Übertragungsmedium = Funkprotokoll

Kann man ambivalent deuten, ich benutze hier den Begriff "Protokoll" nur im Sinne von Datenstruktur.

In meinen Threadantworten findest Du viele Links darauf. Wie z. B. den hier

Bei den 868-Sensor-Typen gibt es wiederum hauptsächlich zwei Varianten: jene die mit dem CC1101 empfangen werden können und solche die
mit dem RFM12/69 arbeiten (unterschiedliches Funkprotokoll!)

Hoffe es ist ein bisschen klarer jetzt.


PS:

Clients
:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:

Hier ist die  CUL_TX-Definition in der CULFW  das Zauberwort 
Diese dürfte aber Standard-mäßig aktiviert sein.

[juergs]

Out-of-the-box:

culfw (Anm.:V1.66) supports following RF protocols:

    "SlowRF" mode (1kHz datarate, AM)
        FS20: send/receive
        There are numerous FS20 devices, AFAIK. all of them are fully supported.
        FHT: send/receive
        Communication to the FHT80b and directly to the FHT8v is supported. Sending out FHT80TF data pakets to FHT80b.
        S300: receive
        Examples of such devices: S300TH, KS300-2
        EM1000: receive
        Devices: EM1000FM, EM1000GZ, EM1000WZ
        HMS: receive
        Devices: There are numerous HMS devices, AFAIK. all of them are fully supported.
        Hoermann: receive
        Some 868 Hoermann garage door openers.
        ESA2000: send and receive
        Lacrosse TX2/TX3: receive
        Intertechno: send
        Somfy RTS: send

[KölnSolar]

Hi Jürgen,
Du legst Dich ja mächtig ins Zeug für mich. Aber Deine Aussagen sind nicht immer ganz richtig oder lassen Spielraum für Interpretationen.

SlowRf ist glaube ich, ist nur für die FS20-Aktoren gedacht.

Ist nicht ganz richtig. In diesem Modus startet der CUL standardmäßig, wenn kein rfmode-Attribut angegeben ist.

Zitat

Clients
:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:



Hier ist die  CUL_TX-Definition in der CULFW  das Zauberwort 

Das Zauberwort kommt aus der 00_CUL und listet nur die hart codierten client Module, mehr nicht. Hat also lediglich die Aussagekraft, dass es ein Client-Modul CUL_TX gibt. Genau wie CUL_IR. Trotzdem kannst Du keine IR Befehle mangels IR-Diode und mangels passender culfw empfangen. 
Welche Protokolle wirklich über die culfw aktiv nutzbar sind, ergibt sich meines Wissens eher über das Reading cmds des CUL. Da findest Du dann auch nicht das "I" für IR-Empfang(Vorsicht: nicht mit dem (kleinen) l für led verwechseln  Sehr wohl aber das kleine "t" für TX2/TX3.

Hoffe es ist ein bisschen klarer jetzt.

Nicht wirklich. Ich kenne dass AM/OOK ja mehr von der IT-Seite und da spielen dann schon in der Erkennung Pulsweiten, Pausen, Wiederholungen etc. eine große Rolle, um überhaupt mal aus den Funkwellen mit Header und Footer abzuleiten, dass es sich um ein IT-bit handelt und erst recht um das Sendeprotokoll zu identifizieren.
Ich guck jetzt mal in ein Datenblatt von so'nem Funksender, vielleicht macht mich das schlauer. Hätte ich doch nur so ein verflixtes Teil hier, dann wäre alles einfacher 
Du hast mir aber auf jeden Fall geholfen, denn jetzt weiß ich, dass Du keine besonderen Einstellungen am CUL433 fürden Empfang vorgenommen hast und ich mir die Mühe hätte sparen können, den native mode in meine culfw zu kompilieren.
Grüße Markus

[juergs]

Man kann es sich aber auch schwer machen 

Dann passt das so.

Aber warum sollte der CUL433  "SlowRF" für FS20 (868MHz)  als Standard einstellen?

... ohne jetzt in den Code schauen zu wollen ...

[KölnSolar]

Hi Jürgen, bin weiter basics am lernen.
Dabei stellen sich mir die Fragen, warum Du nicht gleich die narcoleptics-Lib, wie sie hier http://playground.arduino.cc/Main/LibraryList  unter Testing, Utilities and Power Saving angegeben ist genommen hast. Damit hätte man bei Bedarf auch brown-out-detection abschalten können. Auch verstehe ich nicht, warum Du zusätzlich abschalten von ADC eingebaut has. Das ist doch bereits im power-down per Definition abgeschaltet.
Schönen Sonntag, Markus

[juergs]

Hi Markus,

... erklärt sich einfach:

Narcoleptic durch "Zufall" entdeckt.
Messgerät im mA-Meßbereich angeschlossen und noch > 100uA gemessen.
Nach Ursachen gesucht,  ADC als Ursache erkannt und abgeschalten -> Auswirkung: Stromverbrauch <10 uA im sleep mode!
Das wars für mich gewesen, da ich versuche etwas Ergebnis-orientierter zu programmieren (Faktor: Zeit). 

Aber wie Du schon herausgefunden hast, es gibt immer eine Möglichkeit es besser zu machen, oder eine noch bessere Lib zu verwenden,
deswegen stelle ich mein Code hier auch ins Forum. (nobody seems to be perfect.)
Evtl. wurde in der Lib die ADC-Abschaltung auch noch nachträglich, weil gut, eingebaut? Diese werden ja auch weiterentwickelt.
Ich habe in meiner Lib noch delay_minutes eingebaut. Gab's da nicht.

Vorschlag: besser machen und auch den Code dazu hier wieder einstellen.
Dann haben wir alle was davon ... 

Aber schön, damit Du Dich damit auseinandergesetzt hast.

Interessanterweise tüftle ich gerade auch an diesem Thema im Zusammenhang mit dem Bodenfeuchtesensor mit DS18B20 herum
und bin wieder bei 100uA angelangt und suche einen Weg den Pullup des Dallas-Sensors auszuschalten.
Evtl. kann ich sogar Deine Festellung dabei beherzigen und weitere Erfahrungen damit sammeln.
ArduinoSleepCode

Es gibt ja auch schon fertig in power.h:

Code Auswählen Erweitern

//--- switch AD-converter off
power_adc_disable();

brown-out-detection

schalte ich per Fuse ab.

Grüße,
Jürgen

[KölnSolar]

na prima, dann hab ich es verstanden Habs mangels Funkhardware mal nicht mit "trial and error", sondern mit Theorie büffeln probiert. Im Datenblatt des attiny ist alles ausführlich beschrieben. Ist zwar etwas mühsam zu lesen, aber dann sehr schlüssig und nachvollziehbar. Auch mit den externen INT, die ich ja fürs aufwecken brauche.
Grüße Markus

[juergs]

sondern mit Theorie büffeln probiert. Im Datenblatt des attiny ist alles ausführlich beschrieben. Ist zwar etwas mühsam zu lesen, aber dann sehr schlüssig

Die Zeit hab ich leider nicht 

Das Hobby-Zeitfenster reicht meist dazu nicht aus!

[juergs]

Code Auswählen Erweitern

void NarcolepticClass::sleep(uint8_t wdt_period) {
  wdt_enable(wdt_period);
  wdt_reset();
  WDTCSR |= _BV(WDIE);
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_mode();
  wdt_disable();
  WDTCSR &= ~_BV(WDIE);
}

When the arduino is in SLEEP_MODE_PWR_DOWN the only way to wake it is with either a watchdog timer interrupt,
a level interrupt on pins 2 or 3, or a Pin Change interrupt (see ATmega328 datasheet Table 10-1, including note 3, on pg. 38).

A level interrupt means that the pin has to be held in that state for a certain amount of time before the interrupt is triggered.
In the interrupt service routine (ISR) for a level interrupt, the interrupt must be detached otherwise the interrupt will keep
happening and the ISR will be repeatedly called until the pin changes state.

Da steht aber nichts von ADC? Auch nicht in sleep.h?

http://shelvin.de/arduino-in-den-sleep_mode_pwr_down-schlaf-modus-setzen/
http://donalmorrissey.blogspot.de/2010/04/putting-arduino-diecimila-to-sleep-part.html
http://www.nongnu.org/avr-libc/user-manual/group__avr__sleep.html
http://www.nongnu.org/avr-libc/user-manual/group__avr__power.html
https://www.mikrocontroller.net/articles/Sleep_Mode

[ArduPino]

Im Datenblatt des attiny ist alles ausführlich beschrieben. Ist zwar etwas mühsam zu lesen, aber dann sehr schlüssig und nachvollziehbar. Auch mit den externen INT, die ich ja fürs aufwecken brauche.
Grüße Markus

Benutzt du noch deine Digispark Teile ?
Diese Narcoleptic Library funktioniert bei mir nämlich nicht.
Auch musste ich
#define __AVR_ATtiny85__
einfügen, da sonst die sleep.h nicht läuft.
Benutze die Arduino IDE 1.6.6

Also sind meine Digispark nicht 100% kompatibel zum "normalen" Attiny85.
Die Brown Out Detection hab eich auch aus, das macht einiges beim Stromsparen.
Ist aber im Sketch direkt integriert, bei der Arduino IDE kann man ja keine Fuses setzen.

[juergs]

@Ardupino:
die V1.6.6 ist etwas alt, ich benutze die V1.6.12.

[ArduPino]

@Ardupino:
die V1.6.6 ist etwas alt, ich benutze die V1.6.12.

Hatte sonst auch direkt die neue, aber dann waren wieder einige Librarys die nicht funktioniert haben, war dann etwas nervig.
Schaue ich mir gleich mal an.

[juergs]

Die Narcoleptic-Lib ist auch nur ein Wrapper um die sleep.h
und stellt nur ein C++ Objekt zur Verfügung.

Du kannst das auch ohne Lib mit
http://shelvin.de/arduino-in-den-sleep_mode_pwr_down-schlaf-modus-setzen/
umsetzen.

Müsste leider bei meinem DigSpark-Clone erst mal den Bootloader flashen um inh ansprechen zu können.