Hallo zusammen.
Ich hatte mir vor einigen Jahren zur Raumklima und Heizungsüberwachung Funkthermometer selber gebau.
Die Temperatur und Luftfeuchteanzeige wurde über eine Webseite die auf eine Raspberry Pi läuft dargestellt.
Nun hatte ich FHEM für mich entdeckt und wollte die Funkthermometer gerne dort mit integrieren. Dazu habe ich mir erstmal einen nanoCul mit 433Mhz Funkmodul gebaut um schon mal ein Grundlage für den Empfang zu haben.
Da FHEM und Perl für mich absolutes Neuland sind war es für mich erstmal einfacher meine Funkthermometer umzuprogrammieren.
Ich hatte dann ein Thema zu TCM Funkthermometer und deren Protokolle die über ein Modul mit eingebunden werden gefunden, und dort die zwei Sachen gepostet.
Nun kam der Wunsch auf ein Thema zu den Funkthermometer zu eröffnen. Das möchte ich nun hiermit tun :)
Nun zum Funkthermometer.
Da ich nicht gerne auf Lochstreifenplatine rumbastel, lasse ich mir immer sobald alles auf einem Breadboard erfolgreich getestet wurde, Leiterplatten anfertigen.
Diese beziehe ich aus China von der Fa. Itead. (https://www.itead.cc/open-pcb/pcb-prototyping/2layer-green-pcb-5cm-x-5cm-max.html) Da kosten 10 Leiterplatten im Format 5cm x 5cm ca. 14,50USD ink. Porto (ca. 12,80€).
Der Bestellvorgang ist recht simple. Hierzu muss man sich einmalig Registrieren, dann ein Leiterplattenformat auswählen und Bezahlen (Z.B mit Paypal).
Danach bekommt man eine Bestellnummer, diese füge ich dann als Benennung der Leiterplattendaten des entsprechenden Zip-Archives ein (Bsp. order_012345678.zip)
Das Zip-Archiv enthält dann alle relevanten Files im Gerberformat die der Leiterplattenhersteller benötigt. Das alles ist auch sehr gut auf der Webseite beschrieben.
Das Zip-Archiv muss dann noch unter der entsprechenden Bestellnummer auf die Firmenserver hochgeladen werden. Da ich die Leiterplatten ja schon mal bestellt habe und die Gerberdateien noch vorliegen habe, füge ich sie am Ende mit ein ein Archiv ein, so das nur noch die Bestellnummer aktualisiert werden muss.
Zur Hardware.
Die Leiterplatte ist wie oben beschrieben, professionell gefertigt, das Layout habe ich obwohl SMD Bauteile zum Einsatz kommen extra etwas
großzügig dimensioniert damit auch der ungeübte Bastler die Komponenten mit einem handelsüblichen Lötkolben (mit kleiner Spitze) aufbringen kann.
Das funktioniert bei mir sehr gut mit 0,5mm Durchmesser Lötzinn. Auch der Microkontroller lässt sich Bein für Bein prima aufbringen.
Als Temperatur/Feuchtesensor kommt ein DHT22 Sensor zum Einsatz. Alternativ wo keine Luftfeuchte gebraucht wird (bei mir für Heizung Vor- und Rücklauf)
kann auch ein DS1820 Temperatursensor eingesetz werden. Diese lassen sich dann prima mit einem Kabelbinder an die entsprechenden Rohre fest strapsen.
Auf der Leiterplatte ist dazu ein Steckbrücke vorhanden. Kontakte offen = DHT22, Kontakte geschlossen = DS1820.
Angetrieben wird das ganze von einem Atmel Attiny84 mit 8Mhz internen Takt. Programmiert wurde das ganze in Bascom.
Hauptproblem ist das sobald die Leiterplatte fertig bestückt wurde die sogenannten Fusebits gesetz und das Hex file geschrieben werden muss.
Dazu ist auf der Leiterplatte ein 10 Poliger ISP Anschluss vorhanden. Ich nutze zum Flashen den MK2 von myavr.de (http://shop.myavr.de/index.php?sp=pages/programmer.htm) da dieser auch direkt aus Bascom heraus funktioniert.
Dafür gibt es auch ein entsprechendes Flashtool das ich mit in das Archiv packe. Mit dem Flashtool lassen sich auch die Fusebits bearbeiten.
Mit den Fusebits läßt sich das Verhalten des Microkontroller steuern. Takt intern/extern, Resetpin ja/nein, Schreib und Leseschutz ein/aus usw...
Spiel da bloß nicht mit rum, im schlimmsten Fall ist der Attiny84 dann für euch unbrauchbar.
Für dieses Projekt muss nur der interne Takteiler 'divide clock by 8 internally' deaktiviert werden da sonst der Takt noch durch 8 geteilt wird und der Controller nur
mit 1Mhz läuft. Von der Sache währe das nicht schlimm, nur stimmen dann die Timings nicht mehr die für das Übertragungsprotokoll verantwortlich sind.
Also nur einmal die Fusebits auslesen, Haken weg bei 'divide clock by 8 internally' und wieder schreiben(Bild im Archiv). Dann noch das Hexfile schreiben.
Hierzu habe ich erstmal 15 verschiedene Files vorbereitet mit unterschiedlicher Sender ID's.
Der Sender selber besteht aus einem kleinen Modul, nennt sich RF-Link und sendet auf 433Mhz. Zu beziehen ist der Sender bei Watterott.com (http://www.watterott.com)
Zur Stromversorgung nutze ich eine 3.6V Lithium AA Batterie, diese hält ca. 1,5 Jahre.
Im Archiv findet sich auch eine Preisliste mit allen Komponenten + Bestellnummer + Bezugsquelle.
Die kosten pro Sender liegen ohne Gehäuse,Batterie und ggv. Batteriehalter bei ca. 12€/Stück ohne Porto.
Das Archiv hat folgenden Inhalt
. 15 Hexfiles zum Flashen des Attiny84 mit unterschiedlichen Sender ID's
. Gerberfiles zur Leiterplattenherstellung
. Layoutdaten im Eagle format (www.cadsoft.de)
. Flashtool für Windows
. Bild Fusebits
. Preisliste in Excel
So nun ein fröhliches Nachbauen
Achtung! das Thema ist noch in Erstellung, und wird in wenigen Tagen fertiggestellt.
Es folgen noch Bilder der Sender und ein Downloadlink für das Archiv mit den Dateine.
Gruß matlen67
(http://abload.de/thumb/temperatursensor123es7.jpg) (http://abload.de/image.php?img=temperatursensor123es7.jpg) (http://abload.de/thumb/temperatursensor123es7.jpg) (http://abload.de/image.php?img=temperatursensor123es7.jpg)
Sendetelegramm
(http://abload.de/thumb/signaldgs30.jpg) (http://abload.de/image.php?img=signaldgs30.jpg)
Downloadlink files
klick (https://drive.google.com/open?id=0B8ofP_TYMFieUm9KcDFTa0FXc0k)
Update 11.01.2020:
Oha lange nicht mehr hier gewesen (seit 2016)(gab kein Grund da die Tempsensoren bis heute einwandfrei funktionien)
ABER, irgendwann wird es doch langweilig :)
Ich hatte seit Ewigkeiten mal wieder ein update von FEHM eingespielt und muste feststellen das sich da wohl einiges in der 14_CUL97001.pm geändert hat und dadurch meine Sensoren in FHEM nicht mehr funktionierten, da ich meine Änderungen in der pm ja immer selber vorgenomme habe. Ich habe dann zwar meine Modifikationen wieder in die aktuelle pm integriert fand das aber ziemlich bescheiden jedesmal hier was zu ändern.
Deshalb hatte ich mich dazu entschlossen ein vorhandenes Protokoll zu verwenden.
Es ist das Ventus W044 geworden.
Da auch meine Programmierumgebung BASCOM unter Win10 alles andere als schön zu bedienen und zu installieren ist habe ich das dann auch gleich als Sketch für Arduino umgesetzt.
Ich poste das hier nur der Vollständigkeit halber. evtl kann ja auch jemand damit so was anfangen für andere Projekte.
Stand heute 11.01.2020 ist es voll funktionsfähig. Ich werde es aber bestimmt code-mäßig noch optimeren und verfeinern.
Gruß matlen67
// matlen67 11.01.2020
//
// used lib's
// ATtiny84: https://github.com/SpenceKonde/ATTinyCore
// ATtiny84 Pinout: https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/extras/ATtiny_x4.md
// DHT22 lib: https://arduino.cc/playground/Main/DHTLib
// OneWire: https://github.com/PaulStoffregen/OneWire
// ds18b20: https://github.com/milesburton/Arduino-Temperature-Control-Library
//
// flash Attiny84 over ISP
// my programmer: myAVR MK2/AVR910
//
// Edit Arduino-IDE settings: (open path: Arduino IDE Voreinstellungen -> Einstellungen unten)
//
// edit preferences.txt_: (C:\Users\xxxxx\AppData\Local\Arduino15)
// upload.using=mySmartUSB
// upload.verbose=true
//
// edit programmers.txt: (C:\Users\xxxx\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.1)
// mySmartUSB.name=mySmartUSB
// mySmartUSB.communication=serial
// mySmartUSB.protocol=avr910
// mySmartUSB.program.protocol=avr910
// mySmartUSB.program.speed=19200
// mySmartUSB.program.tool=avrdude
// mySmartUSB.program.extra_params=-P{serial.port} -b{program.speed} -F
//#########################################################################################################
#include <avr/sleep.h>
#include <avr/power.h>
#include <avr/wdt.h>
#include <dht.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#define DHT22_PIN 1 // DHT sensor is connected on ATtiny pin 12 (PA1) Arduino Pin 1
#define ONE_WIRE_BUS 1 // DS18b20 sensor is connected on ATtiny pin 12 (PA1) Arduino Pin 1
#define DATA_PIN 2 // RFLink Data Pin ATtiny pin 11 (PA2)
#define TASTER_PIN 3 // Taster Pin ATtiny pin 10 (PA3)
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
dht DHT;
// watchdog interrupt
ISR(WDT_vect){
wdt_disable(); // disable watchdog
}
//##############################
//# Sender ID's #
//##############################
// müssen zweistellig sein
//byte id = 11; // Aussen
byte id = 12; // Wohnzimmer
//byte id = 13; // Schlafzimmer
//byte id = 14; // Kinderzimmer
//byte id = 18; // Heizung vorlauf
//byte id = 19; // Heizung ruecklauf
byte battery = 12;
int temp_int = 0;
double temp_double;
int hum_int = 0;
double hum_double;
byte hum_byte = 0;
byte rh_ones = 0;
byte rh_tens = 0;
byte n0 = 0;
byte n1 = 0;
byte n2 = 0;
byte n3 = 0;
byte n4 = 0;
byte n5 = 0;
byte n6 = 0;
byte n7 = 0;
byte n8 = 0;
void setup() {
pinMode(DATA_PIN, OUTPUT); // Arduino Pin 2, ATtiny84 Pin 11 (A2) RFLink data
pinMode(TASTER_PIN, INPUT);
if ( digitalRead(TASTER_PIN) == 0 ){
sensors.begin();
}
}
void loop() {
delay(3000);
if ( digitalRead(TASTER_PIN) == 0 ){
myReadDS18B20();
}else{
myReadDHT22();
}
//Sende Daten 5 mal
calc_checksum();
for (int i=0; i<5; i++){
send_sync();
send_data();
}
// ATtinny goes sleep 70 ca. 10 min.
for (int i = 0; i < 70; i++){
EnableWatchdog();
}
}
void myReadDS18B20(){
sensors.requestTemperatures(); // start temperatur request
delay(750); // wait for conversation Temperatur inside sensor
float temperatur_float = sensors.getTempCByIndex(0); // get the temperature (if temp 85.0 error wait for conv to short?)
temp_int = temperatur_float * 10;
temp_int = convert_temperatur(temp_int);
rh_ones = convert_humidity(0); // DS18b20 hat keine Luftfeuchte
rh_tens = convert_humidity(0); // DS18b20 hat keine Luftfeuchte
}
void myReadDHT22(){
int chk = DHT.read22(DHT22_PIN);
switch (chk){
case DHTLIB_OK:
temp_double = DHT.temperature;
temp_int = temp_double*10;
temp_int = convert_temperatur(temp_int);
hum_double = DHT.humidity;
hum_int = hum_double*10;
if(hum_int >= 100){
hum_int = hum_int / 10;
hum_byte = hum_int % 10;
rh_ones = convert_humidity(hum_byte);
hum_byte = hum_int / 10;
rh_tens = convert_humidity(hum_byte);
}else{
hum_int = hum_int / 10;
hum_byte = hum_int;
rh_ones = convert_humidity(hum_byte);
hum_byte = 0;
rh_tens = convert_humidity(hum_byte);
}
break;
default:
temp_int = convert_temperatur(999);
rh_ones = convert_humidity(9);
rh_tens = convert_humidity(9);
break;
}
}
void EnableWatchdog(){
// sleep bit patterns:
// 1 second: 0b000110
// 2 seconds: 0b000111
// 4 seconds: 0b100000
// 8 seconds: 0b100001
byte interval = 0b100001; // 8 second
MCUSR = 0; // reset various flags
WDTCSR |= 0b00011000; // see docs, set WDCE, WDE
WDTCSR = 0b01000000 | interval; // set WDIE, and appropriate delay
wdt_reset();
set_sleep_mode (SLEEP_MODE_PWR_DOWN);
sleep_mode(); // now goes to Sleep and waits for the interrupt
}
int convert_temperatur (int temp_org){
// reverse temperature (26,8°C) = ( int 268 / 12bit:000100001100) reverse int 776 / 12bit:001100001000 )
int temp_rev = 0;
byte r = 0;
for (int i=11; i>=0; i--){
if (bitRead(temp_org,i)){
bitSet(temp_rev,r);
}
r++;
}
return temp_rev;
}
int convert_humidity (int hum_org){
int rh_rev = 0;
byte r = 0;
for (int i=3; i>=0; i--){
if (bitRead(hum_org,i)){
bitSet(rh_rev,r);
}
r++;
}
return rh_rev;
}
void calc_checksum(){
// n0 n1 n2 n3 n4 n5 n6 n7 n8
// 1 5 4 14 8 0 0 4 8
// 154E800480 = 0001 0101 0100 1110 1000 0000 0000 0100 1000
// reverse all = 1000 1010 0010 0111 0001 0000 0000 0010 0001
int checksumme = 0;
byte r = 0;
//sender id n0
n0 = 0;
r = 0;
for (int i=7; i>=4; i--){
if (bitRead(id,i)){
bitSet(n0,r);
}
r++;
}
//sender id n1
n1 = 0;
r = 0;
for (int i=3; i>=0; i--){
if (bitRead(id,i)){
bitSet(n1,r);
}
r++;
}
//batterie n2
n2 = 0;
r = 0;
for (int i=3; i>=0; i--){
if (bitRead(battery,i)){
bitSet(n2,r);
}
r++;
}
//temperatur n3
n3 = 0;
r = 0;
for (int i=11; i>=8; i--){
if (bitRead(temp_int,i)){
bitSet(n3,r);
}
r++;
}
//temperatur n4
n4 = 0;
r = 0;
for (int i=7; i>=4; i--){
if (bitRead(temp_int,i)){
bitSet(n4,r);
}
r++;
}
//temperatur n5
n5 = 0;
r = 0;
for (int i=3; i>=0; i--){
if (bitRead(temp_int,i)){
bitSet(n5,r);
}
r++;
}
//humidity ones n6
n6 = 0;
r = 0;
for (int i=3; i>=0; i--){
if (bitRead(rh_ones,i)){
bitSet(n6,r);
}
r++;
}
//humidity tens n7
n7 = 0;
r = 0;
for (int i=3; i>=0; i--){
if (bitRead(rh_tens,i)){
bitSet(n7,r);
}
r++;
}
checksumme = 0xF - n0;
checksumme -= n1;
checksumme -= n2;
checksumme -= n3;
checksumme -= n4;
checksumme -= n5;
checksumme -= n6;
checksumme -= n7;
checksumme = checksumme & 0xF;
//checksum n8
n8 = 0;
r = 0;
for (int i=3; i>=0; i--){
if (bitRead(checksumme,i)){
bitSet(n8,r);
}
r++;
}
}
void send_data(){
//Sendetelegramm
// n0 n1 n2 n3 n4 n5 n6 n7 n8
// Bit 0..........................................35
// 0001 0101 0100 1110 1011 0000 0100 1010 0000
// dez 01 05 04 0E 0B 00 04 0A 00
//
//Bit 0 - 7 = Sender ID Bsp:00001111 = 21
//Bit 8 = Batterie 0 = Bat ok, 1 = Low Bat
//Bit 9 = x0 = 1 (wenn x0 und x1 gleich dann Regensensor)
//Bit 10 = x1 = 0
//Bit 11 = 0 = Scheduled transmission / 1 press button on Sender
//Bit 12 - 23 = Temperatur 12Bit Two's Complement: 000011010111 = 215 (21,5°C) must reversed to 111010110000 (-336)
//Bit 24 - 27 = Luftfeuchte einer 2 = 0010 -> must reverse 0100 = 4
//Bit 28 - 31 = Luftfeuchte zehner 5 = 0101 -> must reverse 1010 =-6 (Bsp. 52%)
//Bit 32 - 35 = Checksumme = n8 = (0xf - n0 - n1 - n2 - n3 - n4 - n5 - n6 - n7) & 0xF
//sender id n0
for (int i=7; i>=4; i--){
if (bitRead(id,i)){
send_1();
}else{
send_0();
}
}
//sender id n1
for (int i=3; i>=0; i--){
if (bitRead(id,i)){
send_1();
}else{
send_0();
}
}
//batterie n2
for (int i=3; i>=0; i--){
if (bitRead(battery,i)){
send_1();
}else{
send_0();
}
}
//temperatur n3
for (int i=11; i>=8; i--){
if (bitRead(temp_int,i)){
send_1();
}else{
send_0();
}
}
//temperatur n4
for (int i=7; i>=4; i--){
if (bitRead(temp_int,i)){
send_1();
}else{
send_0();
}
}
//temperatur n5
for (int i=3; i>=0; i--){
if (bitRead(temp_int,i)){
send_1();
}else{
send_0();
}
}
//humidity ones n6
for (int i=3; i>=0; i--){
if (bitRead(rh_ones,i)){
send_1();
}else{
send_0();
}
}
//humidity tens n7
for (int i=3; i>=0; i--){
if (bitRead(rh_tens,i)){
send_1();
}else{
send_0();
}
}
//checksum n8
for (int i=3; i>=0; i--){
if (bitRead(n8,i)){
send_1();
}else{
send_0();
}
}
}
void send_sync(){
//************************************
//Syncbit
//
//| 500us| 9000us |
// ------
//| |_____________
//
//************************************
digitalWrite(DATA_PIN, HIGH);
delayMicroseconds(530);
digitalWrite(DATA_PIN, LOW);
delayMicroseconds(9100);
}
void send_0(){
//************************************
//Logisch 0
//
//| 500us| 2000us |
// ------
//| |_____________
//
//************************************
digitalWrite(DATA_PIN, HIGH);
delayMicroseconds(530);
digitalWrite(DATA_PIN, LOW);
delayMicroseconds(2100);
}
void send_1(){
//************************************
//Logisch 1
//
//| 500us| 4000us |
// ------
//| |_____________
//
//************************************
digitalWrite(DATA_PIN, HIGH);
delayMicroseconds(530);
digitalWrite(DATA_PIN, LOW);
delayMicroseconds(4100);
}
He he es gibt noch Leute die Bascom benutzen ja ;-) Aber man kann sagen was man will, der Compiler von Bascom ist echt besser was das Ergebnis angeht, sprich die Speicherbelegung.
/Daniel
Hi,
in diesem Thread wird ja etwas Ähnliches behandelt:
https://forum.fhem.de/index.php/topic,50333.0.html (https://forum.fhem.de/index.php/topic,50333.0.html)
Das was Du da geplant hast, passt da prima mit rein.
Wäre auf alle Fälle mit Platinenbestellung dabei.
Grüße,
Jürgen
http://s6z.de/cms/index.php/homeautomation-homecontrol/infrastruktur/aktorensensoren/eigenbau/56-tinytx-wireless-sensor-nodes (http://s6z.de/cms/index.php/homeautomation-homecontrol/infrastruktur/aktorensensoren/eigenbau/56-tinytx-wireless-sensor-nodes)
Hi,
Nathan Chantrell hat da schon vor vielen Jahren Pionierarbeit geleistet.
Viele Projekte lassen sich damit realisieren.
Ich würde die Technik aber heute nur noch für Battery Only Projekte verwenden.
@matlen67: die letzten posts verweisen ja auf jeelink Entwicklungen. hardwaretechnisch vermutlich ähnlich, und auch Entwicklungen zu mysensors, fhemduino, signalduino, ESP8266 ..... haben sicherlich ihre Berechtigung. Die Besonderheit Deiner tollen Entwicklungsarbeit ist aber doch meiner Meinung nach, dass die Einbindung via a-culfw für 433MHz CULs erfolgt !!! Und den haben viele Anwender und wollen nicht noch einen weiteren transceiver (basteln=Fehlerquelle).
Vielleicht im Betreff ergänzen ?
Grüße Markus
Edit: Und batteriebetrieben m. 1,5 Jahren ist auch noch eine Besonderheit oder ?
und nun, nachdem ich jetzt wirklich verstanden hab, wie Dein Projekt funktioniert, ein paar Fragen dazu.
Temp.- u. Feuchtigkeitssensoren habe ich schon zur Genüge. 8) Dein professionelles Hardwaredesign ist mir auch nicht so wichtig, da würde ich eher basteln. Ich würde u.U. mit ein paar Modifikationen Deine "Firmware" für die Übertragung von Schaltzuständen missbrauchen wollen.
1.) Unwissend wie ich bin: Wäre es für Dich zu aufwändig so etwas zu programmieren, also anstatt Temperatur die Schaltzustände Ein/Aus zu senden und dann auch als HEX-File hier zur Verfügung zu stellen ?
Sicherlich könnte ich aber auch den Temp./Feuchtigkeitswert entsprechend missbrauchen. Ist halt etwas weniger chic.
2.) Ist Deine Software auf den Attiny84(lt. Stückliste Attiny84A) beschränkt oder ginge da auch ein Attiny85 ? (Sorry, null Ahnung von µC's :'()
3.) oder ginge auch so etwas mit nem Attiny841
http://www.watterott.com/de/Wattuino-Nanite841?x10bad=1558202427f0e739f43ea5418e3664aa
oder eben gar mit Attiny85
http://www.watterott.com/de/Wattuino-Nanite841?x10bad=1558202427f0e739f43ea5418e3664aa
http://www.watterott.com/de/Wattuino-Nanite85?x10bad=1558202427f0e739f43ea5418e3664aa
zu flashen ? Würde ja dann den MK2 überflüssig machen, richtig ?
4.) das von Jürgen oben verlinkte Projekt von Simonberry basiert ja noch auf einem Arduino, ist aber nach meinem Verständnis aufgrund der gewählten Entwicklungsumgebung auch für Endanwender handel-/modifizierbar, so dass 1.)-3.) sich erledigen würden, im Gegensatz zu Deiner Umgebung mit Bascom. Umgekehrt hast Du es bereits auf nem Attiny mit Batteriebetrieb implementiert, was simonberry noch in Angriff nehmen möchte. Wenn ich damit richtig liege, mein Gedanke: Könnt Ihr Euch zusammentun und wir bekämen eine individuelle Plattform für batteriebetriebene Eigenbau-Sensoren, die via CUL in fhem mit dortigen Bordmitteln integrierbar sind ?
5.) Könntest Du vielleicht irgendwann wenn Zeit ist, das Layout im "Bildformat" bereitstellen. Ist immer so aufwändig nur für einen Fall eine neue Software(cadsoft) zu installieren.
Bitte nicht hauen, sind nur die Gedanken eines µC-Laien.
Schönes Wochenende
Markus
Hallo.
@SpenZerX
Dein Bild finde ich sehr interessant. Was ist das für ein µC? Welche Software?
Dank und Gruß
Dirk
Zitat von: beSmart am 29 April 2016, 12:49:23
Hallo.
@SpenZerX
Dein Bild finde ich sehr interessant. Was ist das für ein µC? Welche Software?
Dank und Gruß
Dirk
Ist ein Prototyp zu dem Thema hier - der wirklich funktioniert!
- Flashupdate über Pins
- gute Reichweite
- digitale Temperatur
- 1 Jahr Batterielaufzeit (bei 5 min Zyklus)
nur der WAF-Factor passt so erstmal nicht
Materialkosten 2,-
ATtiny 84A-PU
STX882 ASK Transmitter
Pullwiderstand
db18b20
+ggf. Kondensator
@KölnSolar
bei meinem Projekt bin ich zwar schon ein bißchen weiter. Sprich ich habe es auf einen ATTiny85 portiert und schon erste Ehrfahrungen gesammelt. Leider bin ich mit dem PowerSafe modus noch nicht ganz so zufrieden, das es wirklich mit Batterie geht umd das öffentlich zu machen.
Schaltzustände müsste man auch relativ einfach mit nem tiny und 433 MHz ans FHEM bringen können. Da gibt es für IT schon eine fertige Bibliothek "RC-Switch". Das kann dann allerdings nur mit der a-culfw empfangen werden.
@matlen
Das ist auch ein feines Projekt was Du da vorstellst. Kompliment!!
Ich bastle aber selber rum, weil das basteln schon so viel spaß macht.
Viele Grüße
Simonberry
@ KölnSolar
Die jetzige Software (hex file) dürfte nur auf dem ATtiny84 laufen. Für andere µC's muss das die Software angepasst und neu kompiliert werden.
Der ATtiny85 hat ja auch nur 8 Beine die sind ja anders belegt. Der ATinny841 müsste Pinkompatible sein aber auch hier muss die Software angepasst werden da der mehr funktionen hat wie
z.B 2 x16Bit Timer, 2 x USART usw...
Schaltzustände senden sollte natürlich machbar sein, die µC's habe ja genug i/o Pins da kann mal ja alles mögliche abfragen und dan per funk auch senden. Musst dir dann nur ein Übertragungsprotokoll
ausdenken und eine entsprechende empfangssoftware die das Protokoll auswertet.
Meine ursprünglichen Temperaturfunksender hatte ich mit einer serielle Übertragung ausgestattet (wusste nur nicht wie man in FHEM ein Modul baut das die Daten auswertet, deshalb hatte ich die Sender ja umprogrammiert) da könnteste dann einfach plain text senden z.B. schalter1=ein / schalter1=aus. Sowas läßst easy auswerten.
Ja das Hauptproblem ist halt das Flashen der µC. Ich hatte vor Jahren mir mal für nen Satreciver ein Display gebaut das Sender, Sendung, Sendungsfortschritt usw anzeigt. Das lief über ein Atmega16.
Da hatte ich ein Bootloader und USB integriert so das ich mit einem selbstgeschriebenen Flashtool die Firmware direkt über den Reciver flashen kann(konnte).
Also machbar ist alles. Aber da die Temperaturfunksender sind halt nur mit den nötigsten Komponenten ausgestattet. Und da ist halt ISP die erste wahl weil das in den ATtinny's integriert ist.
Nachtrag. Ein USB ISP programmer gibts in der Bucht für weniger als 4€. Also den sollte sich dann jeder Bastler auf Lager legen ;)
Layout als PDF (https://drive.google.com/open?id=0B8ofP_TYMFieVmwyZXBYdm52VEU)
@beSmart
µC = Atmel ATtiny84, Programiersprache = Bascom
@juergs
Die Sourcen kommen noch wenn ich der Meinung bin das alles fertig ist. Ich habe gerade heute noch einiges geändert.
gruß matlen67
Hallo Zusammen,
offensichtlich hat jeder seinen eigenen Beweggründe warum er irgendwelche (Bastel) -Dinge umsetzt.
@KölnSolar:
Gute und klare Einschätzung, der ich mich nur anschließen kann.
Für diejenigen, die noch Eigenschaten von den ATtinies suchen (ohne Werbungsabsicht)
Hier sind die Eigenschaften der "Kleinen" schön aufgezeigt:
https://guloshop.de/shop/Mikrocontroller:::3.html?XTCsid=jav8gbmu0qi8gnevd93urq25l5 (https://guloshop.de/shop/Mikrocontroller:::3.html?XTCsid=jav8gbmu0qi8gnevd93urq25l5)
und nebenbei etwas billiger, als sonstwo.
Dann gäbe es noch die Arduino-Variante zur Programmierung der ATtinies:
http://highlowtech.org/?p=1695 (http://highlowtech.org/?p=1695)
Als weitere Möglichkeit würde ich die Verwendung von Thermoelementen vom Typ K ebenfalls vorschlagen:
http://ebay.to/1VXJrTS (http://ebay.to/1VXJrTS)
1.Working voltage: DC5V
2, Operating Current: 50mA
3, the temperature measuring range: -200°C - 1300 °C [Test procedure for 0-1023 °C]
4, the temperature measurement accuracy: ± 1.5 °C
5, the temperature resolution: 0.25 °C
Ok, wäre nicht gerade sinnvoll für Batteriebetrieb, aber der Temperaturbereich ...
@matlen
Du hast auf die Bascom-Sourcen leider verzichtet, dann hätte man das auch entsprechend für Arduino,
AtmelStudio oder VisualMicro in C(++) einfach portieren und als Basis für Erweiterungen verwenden können
... schade eigentlich.
@SpenZerX
Vielleicht kannst Du evtl. ein Beitrag leisten. Die spartanische Umsetzung find ich klasse (;-)
Über den Sleep-Mode des ATtiny85 gib es schöne Abhandlungen:
http://www.re-innovation.co.uk/web12/index.php/en/blog-75/306-sleep-modes-on-attiny85 (http://www.re-innovation.co.uk/web12/index.php/en/blog-75/306-sleep-modes-on-attiny85)
http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/arduino-atmel/9-winterschlaf-fuer-arduino (http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/arduino-atmel/9-winterschlaf-fuer-arduino)
oder hier
https://www.insidegadgets.com/2011/01/03/building-a-standalone-temperature-logger-part-1/ (https://www.insidegadgets.com/2011/01/03/building-a-standalone-temperature-logger-part-1/)
Habe leider noch keinen ATTiny8x o.Ä., muss daher noch ein bisschen abwarten ....
Als weiteren Anwendungsfall könnte ich mir auch sowas vorstellen:
http://hackaday.com/2013/04/18/pulse-oximeter-from-lm324-led-and-photodiode/ (http://hackaday.com/2013/04/18/pulse-oximeter-from-lm324-led-and-photodiode/)
Hier noch einge Ratschläge zur Reichweitenerhöhung der 433 MHz Sender (bei 3V3 etwas dünne Reichweite)
http://avr.börke.de/Funksteckdosen.htm (http://avr.xn--brke-5qa.de/Funksteckdosen.htm)
http://www.gsurf.de/avr-elro-funksteckdosen-mit-attiny-2313-schalten/ (http://www.gsurf.de/avr-elro-funksteckdosen-mit-attiny-2313-schalten/)
Hier könnte ich mir eine Ladungspumpe für den Sendevorgang vorstellen um z.B. kurzzeitig von 3V3 auf 9V zu kommen ....
Das hier das Prinzip:
http://www.sprut.de/electronic/switch/schalt.html (http://www.sprut.de/electronic/switch/schalt.html)
http://www.sprut.de/electronic/switch/smallup/smallup.html (http://www.sprut.de/electronic/switch/smallup/smallup.html)
Zitat von: simonberry am 29 April 2016, 14:21:36
@KölnSolar
bei meinem Projekt bin ich zwar schon ein bißchen weiter. Sprich ich habe es auf einen ATTiny85 portiert und schon erste Ehrfahrungen gesammelt. Leider bin ich mit dem PowerSafe modus noch nicht ganz so zufrieden, das es wirklich mit Batterie geht umd das öffentlich zu machen.
Schaltzustände müsste man auch relativ einfach mit nem tiny und 433 MHz ans FHEM bringen können. Da gibt es für IT schon eine fertige Bibliothek "RC-Switch". Das kann dann allerdings nur mit der a-culfw empfangen werden.
@matlen
Das ist auch ein feines Projekt was Du da vorstellst. Kompliment!!
Ich bastle aber selber rum, weil das basteln schon so viel spaß macht.
Viele Grüße
Simonberry
Ja das mit dem Powerdown mode gefällt mir bei mir auch nicht wirklich. Den µC schlafen legen ist ja kein Problem allerdings braucht man dann einen exteren Interrupt um ihn wieder zum leben zu erwecken. Oder halt über Watchdog der läuft aber längstens 8 Sekunden.
Also bei mir sieht das so aus:
Watchdog initialiesieren
Daten per Funk senden
und dann eine Schleife
for i = 1 To 70 '70 ca 10 min
Config powermode = powerdown
next i
Schleifen start -> powerdown starten -> Watchdog weckst den µC nach 8 sek. -> schleife kleiner 70 (10min bei mir) sofort wieder für 8 sek. powerdown usw..
Also nicht wirklich schön da der µC alle 8sek kurz aufwacht. Aber egal Batterie hält ca 1,5 Jahre :)
Passendes Gehäuse?
http://tinyurl.com/j4ewdgr (http://tinyurl.com/j4ewdgr)
Tip von hier http://tinyurl.com/gobds5s (http://tinyurl.com/gobds5s)
@Matlen67:
habe Dein Parallelthread leider erst zu spät gesehen ... https://forum.fhem.de/index.php/topic,28519.msg444165.html#msg444165 (https://forum.fhem.de/index.php/topic,28519.msg444165.html#msg444165)
Habe meine bestellten ATtiny84 + 85 bekommen und die Programmier-Infrastruktur aufgebaut ... (;-)
Obwohl der DS10B20 erfassst wird und der Sender Bitfolgen sendet, wird nichts von FHEM erkannt,braucht man da noch ein weiteres Perl-Modul?Welchen LogAnalyzer verwendest Du (welche Software dazu?) -> scheint besser als die Salae-Version zu sein....
LogAnalyzer: https://www.ikalogic.com/ (https://www.ikalogic.com/)
Dannt stricke ich das Ganze mal auf das LaCrosse-Protokoll um.
Noch etwas Interessantes:
https://www.itead.cc/sonoff-th.html (https://www.itead.cc/sonoff-th.html)
https://www.itead.cc/blog/itead-intelligent-switch-433mhz-communication-protocol (https://www.itead.cc/blog/itead-intelligent-switch-433mhz-communication-protocol)
Grüße,
Jürgen
Hallo,
ich habe mal den Arduino-Code von hier https://forum.fhem.de/index.php?action=dlattach;topic=50333.0;attach=50293 (https://forum.fhem.de/index.php?action=dlattach;topic=50333.0;attach=50293) genommen und als ATtiny85-Typ eingestellt
und die seriellen Ausgaben entfernt. Protokoll: "LaCrosse" , "TCM" funktionierte bei mir nicht.
Der ATtiny hat 8 KB Flash-Speicher und 512 Bytes Ram und EEPROM. Der Code braucht unoptimiert 5634 Bytes.
Evtl. noch Platz für einen Bootloader (ca. 1900 Bytes) : http://electronics.stackexchange.com/questions/161361/burn-micronucleus-bootloader-to-use-attiny85-via-usb-avrdude (http://electronics.stackexchange.com/questions/161361/burn-micronucleus-bootloader-to-use-attiny85-via-usb-avrdude)
Dazu mehr Infos: http://docs.aakashlabs.org/anuduino/getting_started.html#burning-micronucleus-hex-and-setting-fuses (http://docs.aakashlabs.org/anuduino/getting_started.html#burning-micronucleus-hex-and-setting-fuses)
Arduino-IDE-Konfigurationserweiterung: http://highlowtech.org/?p=1695 (http://highlowtech.org/?p=1695)
Zum Entwickeln kann ich VisualStudio mit VisualMicro + USBAsp-Programmer empfehlen (einfach F5 drücken ...)
Konfiguration:
Der DQ-Pin des DS18B20 Sensors: PB2 (Arduino D2) => Pin 7 des ATtiny85
Der Sende-Pin auf den 433MHz-Sender: PB0 (Arduino D0) => Pin 5 des ATtiny85
Todo: Für Batteriebetrieb noch Sleep-Modus implementieren. (Siehe Code, bin noch am Einarbeiten ...).
Beta-Code:
Um Powersave erweitert, liest nur 1 Sensor ein. (+ Fehler bereinigt.)
Allerdings immer noch etwas Beta ...
Senden: kurz 10 mA.
Sensor einlesen kurz: 0,21 mA
Idle: unter 0,00 mA.
Funktioniert auch noch mit durchaus leerer Batterie mit ca. 2.85 V ...
Reichweite ca. 10 m.
Zum Programmieren den Jumper von der Batterie ziehen und Sensor entfernen,
sonst meckert der Programmer ...
(-> weil SCK und DQ des DS18B20 zusammen gelegt sind. Besser DQ auf PB3 oder PB4 legen)
weitere Infos:
http://interface.khm.de/index.php/lab/interfaces-advanced/sleep_watchdog_battery/ (http://interface.khm.de/index.php/lab/interfaces-advanced/sleep_watchdog_battery/)
http://blog.rot13.org/2013/08/monitoring-room-temperature-using-arduino.html (http://blog.rot13.org/2013/08/monitoring-room-temperature-using-arduino.html)
https://www.insidegadgets.com/projects/standalone-temperature-logger/ (https://www.insidegadgets.com/projects/standalone-temperature-logger/)
https://www.insidegadgets.com/projects/standalone-voltage-logger/ (https://www.insidegadgets.com/projects/standalone-voltage-logger/)
https://www.insidegadgets.com/projects/low-voltage-battery-monitor/ (https://www.insidegadgets.com/projects/low-voltage-battery-monitor/)
http://interface.khm.de/index.php/lab/interfaces-advanced/nonlinear-mapping/ (http://interface.khm.de/index.php/lab/interfaces-advanced/nonlinear-mapping/)
https://www.insidegadgets.com/code-snippets (https://www.insidegadgets.com/code-snippets)
http://arduino-info.wikispaces.com/Brick-Temperature-DS18B20?responseToken=e43b79ee6aff5960bbc5d1f1eb7bdde3 (http://arduino-info.wikispaces.com/Brick-Temperature-DS18B20?responseToken=e43b79ee6aff5960bbc5d1f1eb7bdde3)
https://github.com/chrisfeltman/Arduino/tree/master/libraries/Narcoleptic (https://github.com/chrisfeltman/Arduino/tree/master/libraries/Narcoleptic)
https://github.com/nathanchantrell/TinyTX/blob/master/TinyTX_SRF_DS18B20/TinyTX_SRF_DS18B20.ino (https://github.com/nathanchantrell/TinyTX/blob/master/TinyTX_SRF_DS18B20/TinyTX_SRF_DS18B20.ino)
Achtung: Im Netz kursieren falsche Arduino-Pinbelegungen des ATtiny85!
Hi,
habe die Software etwas aufgeteilt:
1.) Arduino Lib: LaCrosse (433 Mhz LaCrosse Protokoll als Cpp-Library umgesetzt.)
2.) Arduino Lib: Narcoleptic (Powerdown Lib (nicht das Orginal!) , erweitert mit Minuten-Sleep-Vorgabe + AD-Wandler OFF während der Sleep-Phase. Gewinn: von 2 mA auf kleiner 10yA). Siehe auch hier: http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/arduino-atmel/9-winterschlaf-fuer-arduino (http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/arduino-atmel/9-winterschlaf-fuer-arduino)
3.) VisualMicro-Projekt. ( 5 Minuten Sleep-Phase, fertig kompilierte HEX-Dateien im "Debug"-Verzeichnis)
4.) Multi-Sensor-Betrieb habe ich noch nicht implementiert.
Falls nicht mit VisualMicro kompiliert werden kann/will:
--> Includes anpassen, vorher die Libs in der Arduino-Ide installieren. Dann sollte es auch über Arduino-IDE zu kompilieren sein.
Konfiguration für ATtiny85:
D3 = PB3 = DS18x20-DQ (4K7 Pullup)
D4 = PB4 = TX-PIN 433MHz-Sender
Hier noch ein weiteres Projekt mit RFM69:
von hier:
http://johan.kanflo.com/the-aaduino/ (http://johan.kanflo.com/the-aaduino/)
und der Sketch:
https://github.com/kanflo/aaduino
... und Powersave Gedanken:
https://harizanov.com/2013/08/every-%CE%BCa-counts/ (https://harizanov.com/2013/08/every-%CE%BCa-counts/)
http://electronics.stackexchange.com/questions/49182/how-can-i-get-my-atmega328-to-run-for-a-year-on-batteries (http://electronics.stackexchange.com/questions/49182/how-can-i-get-my-atmega328-to-run-for-a-year-on-batteries)
Hier die Version mit DHT22@3V .
DHT22:
1 - Vcc ------- 10K.1--- 3V
2 - Data ---- 10K.2 ---- Pin2 = D3
3 - not connected
4 - GND
433 TX an PIN 3 = D4
Batterie: CR2450P-H (u.A. @Reichelt)
Die rote SMA-Abdeckung erhöht den WAF. ;D
Hinweis zum Auslesen des DHT22:
https://forum.fhem.de/index.php/topic,47090.0.html (https://forum.fhem.de/index.php/topic,47090.0.html)
Sollte (bei korrektem Aufruf) der DHT22-Treiber schon beim ersten Versuch einen Wert zurückliefern, so handelt es sich nicht um einen aktuellen Messwert. Der DHT22 liefert nämlich beim Aufruf den abgespeicherten Messwert der zurückliegenden Messung und startet parallel einen neuen Messvorgang. Der Hersteller empfiehlt, den Sensor zweimal aufzurufen und nur den letzten Rückgabewert zu verwenden.
Noch ein paar weitere Anregungen:
https://buildthings.wordpress.com/attiny-wireless-weather-station-anemometer-wind-vane-temperature-rain-gauge-remote-outdoor-sensor/ (https://buildthings.wordpress.com/attiny-wireless-weather-station-anemometer-wind-vane-temperature-rain-gauge-remote-outdoor-sensor/)
oder
https://buildthings.wordpress.com/#WX (https://buildthings.wordpress.com/#WX)
mit und für ATtiny. Mit TinyDebugSerial-Library: http://arduino-for-beginners.blogspot.de/2013/04/added-tinydebugserial-to-attiny85.html (http://arduino-for-beginners.blogspot.de/2013/04/added-tinydebugserial-to-attiny85.html)
Und hier: http://www.ernstc.dk/arduino/tinycom.html (http://www.ernstc.dk/arduino/tinycom.html)
Bootloader für ATtiny84:
http://jtxp.org/tech/tinysafeboot_en.htm (http://jtxp.org/tech/tinysafeboot_en.htm)
WiFiLoggerOneWire:
http://www.rudiswiki.de/wiki9/WiFiLoggerOneWire (http://www.rudiswiki.de/wiki9/WiFiLoggerOneWire)
Micro ATtiny Sensor Node mit RFM12B:
http://arduino-praxis.ch/2015/01/micro-attiny-sensor-node/ (http://arduino-praxis.ch/2015/01/micro-attiny-sensor-node/)
Anbei überarbeiteter Arduino Sensor DHT22-Code.
Die Fuses für den ATtiny85 sollten auf:
Zitat
LF = 0xF1 ( PLL-Clock, not internal 8 MHz)
HF = 0xDF
EF = 0xFF
LB = 0x03
eingestellt werden.
Der fertige Hex-Code ist für Sensor-ID 123 gesetzt. Timing-Daten des Protokolls im Zip.
Gehäuse: KEMO "G023N"
Varianten:
https://hackaday.io/project/1552-lofi (https://hackaday.io/project/1552-lofi)
das ist natürlich gerade größenmäßig sehr gut.
Ich bin schon länger auf der Suche nach etwas um meine normalen Lichtschalter in die HA einzubinden, aber eigenbau 230 Sachen will ich nicht einbauen und UP ist halt wenig platz.
Die Ideen dort finde ich auch super, allerdings konnte ich den Code dazu nicht endecken .. :(
Die Idee der Reverse-Schutz-Diode hatte ich auch schon gesucht, um eine FET Lösung beim Programmieren zu umgehen.
Das spart ja einen Jumper.
Diese ist mit 0.1 Volt scheint sehr gut geeignet zu sein, oder die der Arduinos: MBR0520LT.
http://www.nxp.com/documents/data_sheet/PMEG1030EH_EJ.pdf (http://www.nxp.com/documents/data_sheet/PMEG1030EH_EJ.pdf)
Mal schauen wo es die gibt.
Vielleicht weiß auch schon jemand, wie bzw. mit welchem Protokoll (On-Off) das in FHEM einzubinden geht?
Z.B. der Garagentor-Sensor:
https://hackaday.io/project/1552-lofi/log/4918-garage-door-monitor (https://hackaday.io/project/1552-lofi/log/4918-garage-door-monitor)
Lacrosse-Temperatur-Erfassung für 4 Dallas 18B20 Sensoren mit Arduino NANO.
Pro Sensor eine separate LaCrosseId, ausgehend ab einer BasisID (z.B. 105 .. 108).
Sensor _1 = D2
Sensor _2 = D3
Sensor _3 = D4
Sensor _4 = D5
Für jeden Sensor ist ein 4K7 Pullup erforderlich.
Der SendePort ist D12.
Das Sende-Intervall ist auf 30s + Random (10000) eingestelt, so dass die Sendeintervalle unterschiedlich ausfallen.
Das beugt Konflikten mit anderen mit festen Intervallen sendenden Sensoren vor.
Um das Problem der Zuordnung SensorID == LaCrosseID zu umgehen bin ich auf feste Portvorgabe
ausgewichen. So benötigt man keine (externe) Konfiguration der Zuordnung mehr und man kann auf definierte Sensoren
über FHEM, mit nur einem Sender zugreifen.
SensorID: 105 First: 22.56
SensorID: 106 Second: 22.50
SensorID: 107 Third: 22.75
SensorID: 108 Fourth: 22.62
Rand: 32907
Die verwendete Onewire-Library habe ich noch hinzugefügt.
ohne "-master" entpacken und ins Arduino Library Verzeichnis legen.
Oder über "Sketch - Include Library - Add Zip Libary"
https://www.arduino.cc/en/Guide/Libraries (https://www.arduino.cc/en/Guide/Libraries)
ist der sensor mit dem cul empfangbar? https://forum.fhem.de/index.php?topic=36565.0
Yep, dafür ist er gemacht. Das LaCrosse-Protokoll (433MHz !) geht "out-of-the-box" .
Das Prinzip lässt sich auch auf noch mehr Sensoren anwenden.
Die Temp-Ausschläge stammen noch von meinen Tests. "Hello World" ...
Danke für den Hinweis auf den anderen Thread. Dort ist aber die 868Mhz-Variante diskutiert?
Kein JeeLink! Bewusst ohne OW-Gateway und Kabel.
Hier die Selbstbau-Variante für die Hülsen-Sensoren ohne DeepSleep und externer Spannungsversorgung:
Gehäuse: https://www.luedeke-elektronic.de/de/Gehaeuse/Klarsichtgehaeuse/Klarsichtdeckel-Gehaeuse-Kemo-G088-120-x-70-x-15-mm.html (https://www.luedeke-elektronic.de/de/Gehaeuse/Klarsichtgehaeuse/Klarsichtdeckel-Gehaeuse-Kemo-G088-120-x-70-x-15-mm.html)
oder :
https://www.luedeke-elektronic.de/de/Gehaeuse/Klarsichtgehaeuse/Gehaeuse-G368C-ABS-grau-transp--IP65-160-x-80-x-55mm.html (https://www.luedeke-elektronic.de/de/Gehaeuse/Klarsichtgehaeuse/Gehaeuse-G368C-ABS-grau-transp--IP65-160-x-80-x-55mm.html)
für PG-Kabelverschraubungen:
http://www.distrelec.de/de/kabelverschraubung-m12-mm-mm-polyamid-silber-grau-ip68-69-53111100-lapp-skintop-str-12x1-ral-7001-sgy/p/15519367?channel=b2c&utm_source=gshopCHen&utm_medium=feed&price_gs=EUR%201&gclid=CNCpl-GV-M0CFdZsGwodw1wAmw (http://www.distrelec.de/de/kabelverschraubung-m12-mm-mm-polyamid-silber-grau-ip68-69-53111100-lapp-skintop-str-12x1-ral-7001-sgy/p/15519367?channel=b2c&utm_source=gshopCHen&utm_medium=feed&price_gs=EUR%201&gclid=CNCpl-GV-M0CFdZsGwodw1wAmw)
Warum das Ganze:
http://www.bosy-online.de/Einstellen_der_Heizkurve.htm (http://www.bosy-online.de/Einstellen_der_Heizkurve.htm)
Kombinieren von Plots:
https://forum.fhem.de/index.php/topic,55741.0.html (https://forum.fhem.de/index.php/topic,55741.0.html)
Wenn Probleme mit VisualMicro, hier die Arduino-Ide-(NANO)-Version:
- ohne Deep-Sleep
- Netzteil-Versorgung statt Batterie.
- RCSwitch vorbereitet: Schalten von Relais.
Die Arduino Libs liegen lokal eingebunden und müssen nicht ins Library-Verzeichnis kopiert werden.
https://alexbloggt.com/funkthermometer-sdr/ (https://alexbloggt.com/funkthermometer-sdr/)
http://www.kompf.de/weather/rtlsdrsensor.html (http://www.kompf.de/weather/rtlsdrsensor.html)
das hört sich ja alles ganz schick an aber 4 tempsensoren auf emgem raum sind jetzt denke ich nicht sonderlich sinnvoll. kannman da problemlos auch auf luftfeuchte erweitern?
Die Anwendung, die Jürgen und ich im Auge haben, ist die Temperaturmessung an der Heizung. Da kommen auch schnell mehr als 4 Messstellen zusammen. Je Heizkreis Vor- und Rücklauf, Kessel, Warmwasser etc.
Gesendet von meinem A0001 mit Tapatalk
Korrekt! Die so angeordneten Sensoren sind ja der Testcase. Gedacht für die wasserdichten 1820 im Metalltubus.
Beisp.: https://www.adafruit.com/product/381 (https://www.adafruit.com/product/381)
DHT22 lässt sich einfach integrieren. Ports und Platz ist ja noch üppig da.
DHT.h + .cpp ins Library-Verzeichnis legen oder lokal ins 4Fach-Verzeichnis. Über Sketch -> Add file die Header Datei hinzufügen.
DHT mit neuem Pin verbinden (Pullup).
#include "DHT.h" Neue DHT Instanz und LaCrosse-Instanz mit neuer ID anlegen und Temp+HUM-Werte senden, thats it.
Im LaCrosse-Gateway ist, glaube ich, auch Code dabei mit dem Dallas und/oder DHT dynamisch gesucht werden, mit dabei.
Hat jemand den Link?
Ebenfalls als Erweiterung denkbar:
ZitatThermoelement Typ K an Arduino
Um ein paar Typ K Thermoelemente an das Arduino Duemilanove anzuschließen gibt es mehrere Möglichkeiten.
Ich will damit Temperaturen von 0°C bis zu 1200°C messen. Genauigkeit wäre +-5°C bis 100°C und +10°C bei 1200 wünschenswert.
http://www.ebay.de/itm/like/272260523708?lpid=106&chn=ps&ul_noapp=true (http://www.ebay.de/itm/like/272260523708?lpid=106&chn=ps&ul_noapp=true)
Grüße,
Jürgen
http://nerdralph.blogspot.de/2015/11/ds18b20-temperature-sensor-calibration.html (http://nerdralph.blogspot.de/2015/11/ds18b20-temperature-sensor-calibration.html)
BMP180: Temperatur, Luftdruck + Delta
http://shelvin.de/barometer-mit-1h-differenz-und-temperatur-ausgabe/ (http://shelvin.de/barometer-mit-1h-differenz-und-temperatur-ausgabe/)
passendes Sensor-Gehäuse:
https://www.darisusgmbh.de/shop/product_info.php/info/p1241_PP42WS-----Commandergeh--use-71x71x27-mm-wei--.html/XTCsid/ca1524ca43e5185d3f26ba81e9d5e873 (https://www.darisusgmbh.de/shop/product_info.php/info/p1241_PP42WS-----Commandergeh--use-71x71x27-mm-wei--.html/XTCsid/ca1524ca43e5185d3f26ba81e9d5e873)
Also 4 Sensoren bräuchte ich zwar nicht, aber ich hätte gerne Temperatur und Luftfeuchtigkeit mit DHT11, und zwei Kontakte für Fenster auf und Fenster gekippt.
Leider ist mein Englisch nicht so gut, ich habe auch nichts auf der Seite gefunden. Muss man diese LoFi Teile da kaufen oder ist das zum selber bauen. Code hab ich keinen gefunden.
Bin schon seit ner Woche irgend was am suchen was funktioniert.
Das hier sieht ja gut aus.
Wie wird das denn in FHEM angelegt?
Die Anleitungen die ich finde setzen immer auf Autoconfig.
Das nützt mir aber nichts.
Ich hab jetzt so viel ausprobiert und gelesen, ich kapier gar nichts mehr
EDIT: Pearl sagt mir gar nicht zu. Bin mehr der Arduino Typ. Deshalb stellt sich die Frage, ob es überhaupt Sinn macht, weiter in FHEM zu bleiben. Habe noch Home Assistant gefunden, sieht ganz gut aus.
Vielleicht komme ich damit besser zurecht. Kennt das jemand?
EDIT2: Habe jetzt noch einiges gelesen. Irgendwie hatte ich den Sinn vom nanoCUL falsch verstanden.
Diese Lofi Sender mit diesen billig 433 Transmittern funktionieren dann damit?
Funktioniert ein DHT11 an diesen LoFi ?
Wenn ja, könnte ich dann mit einem Sender Temp./Hum. und zwei Taster/Kontakte erfassen?
Ok dann müssen wir mal trennen:
FHEM ist die konfigurierbare Web-Anwendung unter deren Haube Perl-Code werkelt.
Als normaler Nutzer hast Du da nur mit der Konfiguration und evtl. mit ein paar Anpassungen zu tun.
Du musst also gar nicht Perl programmieren können.
FHEM nutzt u.A. den CUL als Empfänger. Der nanoCUL ist die günstige Selbstbau-Variante.
Die Empfänger gibt es in 2 Ausprägungen: 433MHz + 868MHz je nach verwenderter Aktor/Sensor-Technologie.
Wenn Du was mit 433Mhz-Transmittern machen möchtest empfehle ich Dir die 433-CUL-Variante.
Hier kannst Du auch den DHT mit anbinden. (Eigentlich jeden Sensor)
Mit den Funksensoren und meinen Beispielen kannst Du praktisch alle denkbaren Anwendungsfälle abdecken.
Der Standard des LaCrosse-Protokolles bietet eine Meßstelle, wie die in FHEM interpretiert wird obliegt Dir.
Im Normalfall 99.99 Digits, die man aber durch geschicktes Umsetzen beliebig skalieren kann.
Deine LoFi Teile kann ich gerade nirgendwo zuordnen.
Ich benutze jetzt etwas kräftigere LiPo-Accus die sich per USB laden lassen und genügend Energie
für Monate/Jahre Funkbetrieb bereitstellen. Zwar etwas größer sind, dafür aber auch länger halten, und etwas mehr Spannung (3.7..4.1 Volt) liefern,
besonders mit den DHT11, der mit 3V3 eher schlecht arbeitet und eigentlich für 5V-Betrieb ausgelegt ist.
Schau dazu (DHT) mal hier rein:
https://forum.fhem.de/index.php/topic,43672.885.html (https://forum.fhem.de/index.php/topic,43672.885.html)
Zitat von: juergs am 15 September 2016, 21:14:05
Deine LoFi Teile kann ich gerade nirgendwo zuordnen.
https://hackaday.io/project/1552-lofi
Dein eigener Link ;-)
Aber ich mach das so wie du hier gezeigt hast !
Ok, ich bau dann mal den nanoCUL und dann sehen wir weiter.
:). Genau in der Ausprägung..... mehr brauch man ja fast gar nicht.
Die Platinen dazu kann man sich ja auch machen lassen.
Die 433Mhz Module gehen zwar, es gibt aber bessere ... (STX882)
Hallo juergs,
habe deine Lacrosse-Temperatur-Erfassung für 4 Dallas 18B20 Sensoren mit Arduino NANO nachgebaut.
Leider erscheint in fhem kein Temperatursensor.
Muss ich noch etwas beachten?
Benutze die a-cul Firmware mit einem nanocul auf 433MHz-Basis.
Gruß rippi
PS: kaum macht man es richtig, funktioniert es. Hatte den flaschen Sende-Pin!!!
Ja, den TX-Pin muss man bei Bedarf im Code nachschauen.
Bei einem Pin habe ich mir ein Schaltbild gespart ;)
So viele hat der ATtiny auch nicht zur Auswahl </schmunzel>
Den Rest erledigt FHEM mit "autocreate".
Es gibt ja mehrere Varianten mit den 1Wire Bus umzugehen:
Einmal mit einem eigenem Dallas-Busmaster-Chip (gibt es auch in FHEM)
oder als Softwarelösung in einen richtigen 1Wire-Konzept.
Dies hat aber den "Nachteil" jeden Sensor mit seiner ID identifizieren und zuordnen zu müssen, um ihn anzusprechen.
Die Lösung mit eigenem Port pro 1Wire-Instanz erschien mir die unkomplizierteste Umsetzung (solange man freie Ports zur Verfügung hat).
Grüße,
Jürgen
Hallo juergs,
funktioniert jetzt alles so wie es soll.
Gibt es eine Möglichkeit noch einen Fensterkontakt zu implementieren?
Gruß rippi
Ja, eigentlich schon.
Du kannst einen Port, egal ob Digital oder analog, ja mit einem PullUp-Widerstand von ca. 10KOhm auf Versorgungsspannung legen
und den Port auf Eingang schalten.
http://madgyver.de/de/2015/06/15/arduino-taster-abfragen-und-entprellen/ (http://madgyver.de/de/2015/06/15/arduino-taster-abfragen-und-entprellen/)
http://www.do-it-neat.com/arduino-mehrere-schalter-abfragen-ueber-einen-analogeingang/ (http://www.do-it-neat.com/arduino-mehrere-schalter-abfragen-ueber-einen-analogeingang/)
Im Ruhezustand ist der Wert "High" also "1" und bei einem angeschlossenem Kontakt, der gegen Masse schaltet und im
geschaltenenem Zustand ein "Low" oder "0" liefert.
Das Protokoll bringt das so nicht mit, aber man könnte diese beiden Zustände per Software ja in "magic numbers" kodieren.
Wie z.B. "0.0" und "100.0" und senden. Darauf kann man dann in FHEM reagieren, da nur diese zwei Zustände übertragen werden würden.
Evtl. wäre sogar ein BCD -> Binärcode denkbar, mit 4-Digits Auflösung ließe sich einiges an Schaltzuständen kodieren :)
Evtl. gäbe es andere Protokolle, die das eher in FHEM abbilden. Auf Anhieb fallen mir da z.B. die IT-Steckdosen-Protokolle ein oder die
FHTTK-Protokolle. Damit habe ich mich aus Zeitmangel aber noch nicht beschäftigt.
Vielleicht hat jemand noch eine bessere Idee?
Grüße,
Jürgen
PS: Bei Verwendung von Analog-Eingang zur Schaltererkennung auf alle Fälle eine Entstörung
vorsehen, sonst schalten die Eingänge von selbst :)
http://www.elektronik-kompendium.de/public/schaerer/pullr.htm (http://www.elektronik-kompendium.de/public/schaerer/pullr.htm)
http://www.netzmafia.de/skripten/hardware/Control/ein_ausgabe.pdf (http://www.netzmafia.de/skripten/hardware/Control/ein_ausgabe.pdf)
Danke für die schnelle Antwort. :)
Werde das ganze mal testen. In Verbindung mit Attiny85
würde ein sehr keiner Sensor entstehen, mit dem man die z.B. Luftfeuchtigkeit und Temperatur messen könnte und noch
überprüfen könnte, ob das Fenster offen oder geschlossen ist.
Gruß rippi
Zitatwürde ein sehr keiner Sensor entstehen, mit dem man die z.B. Luftfeuchtigkeit und Temperatur messen könnte und noch
überprüfen könnte, ob das Fenster offen oder geschlossen ist.
Mein Gedankengang ging Richtung "Verkabelung" zum Fensterkontakt und die damit verbundene notwendige Entstörung.
Die einfachere Variante ist natürlich, den FK selbst als Sensor mit oder ohne Beiwerk Temp/Feuchte-Messung zu nutzen.
Du kannst den Sensor ja mit 2 ID's senden lassen. Die erste T+H und die zweite den Kontakt (wären so auch 2 Kontakte, mit einfacher Kodierung möglich).
Die digitale-Input-Variante wäre hier störungsempfindlicher. Dennoch würde ich hier ebenfalls einen
gewissen Schutz z.B. mit einen 10..100nF-Kondensator vorsehen und auch die Versorgungspannung
(Batterien) mit ca. 100...470uF puffern. Sonst erlebt man bei Gewitter oder Störungen unangenehme Überraschungen :)
Batterien mögen es nicht, Impuls-mäßig belastet zu werden.
Hallo juergs,
habe den Code etwas abgeändert, damit ich 100.0 bzw 0.0 senden kann.
Da mir die 30 Sekunden für ein Fensterkontakt zu lange erschien, habe ich den Pin 2 des Arduino als Eingang benutzt.
Somit kann ich bei einer Änderung an Pin 2 einen Interrupt auslösen und den entsprechenden Wert senden.
unter void setup() habe ich folgendes eingefügt:
pinMode(PIN_FK, INPUT);
attachInterrupt(0, readFK, CHANGE);
und die Funktion readFK definiert:
void readFK()
{
if (digitalRead(PIN_FK)==HIGH){
LaCrosse.t=100;
} else {
LaCrosse.t=0;
}
//Serial.println(LaCrosse.t);
LaCrosse.bSensorId = SENSOR_ID_0;
LaCrosse.sendTemperature();
}
so funktioniert es erst einmal.
Sicher kann man das ganze auch etwas eleganter lösen, aber meine Progammierkenntnisse sind nicht berauschen. :)
Danke für den Denkanstoß.
Gruß rippi
Sieht gut aus,
nur sicherstellen, wenn Temperatur
und Fensterkontakte, dann evtl. die
ZitatLaCrosse.bSensorId = SENSOR_ID_0
SensorId dazu ändern ... dann senden sie unabhängig.
Du kannst mal im Forum nach DOIF suchen, dann kannst Du entsprechend im FHEM darauf reagieren
oder z.B. Status-Icons entsprechen anzeigen.
Z.B. ähnlich hier:
Suche nach "Icons" + "Status" (https://forum.fhem.de/index.php/topic,7740.msg37045.html#msg37045)
Noch eine Anmerkung: in der PauseZeit geht der ATtiny ja in "Winterschlaf" um auf Port-Interrupts zu reagieren, muss dieser evtl. auch wieder aufwachen können!
Das habe ich noch nicht getestet und müsste das auch erst erforschen ...
Man könnte auch öfters aufwachen, das geht aber in die Lebensdauer der Batterie....
Wobei das Senden wohl am meisten Energie verbraucht (~ 25mA). Aufwachen und auf Interrupt warten sollte eher geringer belastend sein.
Ist aber die Frage ob ein Öffnen des Fensters wirklich sofort angezeigt werden muss, oder ob 3..5 Minuten Latenz "in favor" der Batterie ausreichend wären ...
in fhem sieht das dann so aus:
Internals:
CODE 105
DEF 105
LASTInputDev cul433
MSGCNT 592
NAME CUL_TX_105
NR 745
STATE closed
TYPE CUL_TX
corr 0
cul433_MSGCNT 592
cul433_RAWMSG TXA0D2500502
cul433_RSSI -20
cul433_TIME 2016-09-18 15:27:00
lastH 0
lastT 1474205220.97299
minsecs 0
sduino_DMSG TXA0D2500502
sduino_MSGCNT 20
sduino_RAWMSG MU;P0=236;P3=1023;P4=-1243;P7=-21466;D=73434343404340434343434340404340434340434340434043434343434343434340434043434343434340407343434340434043434343434040434043434043434043404343434343434343434043404343434343434040734343434;CP=3;
sduino_TIME 2016-09-18 15:13:51
Readings:
2016-09-18 15:27:00 state T: 0.0
2016-09-18 15:27:00 temperature 0.0
Attributes:
alias Fensterkontakt
devStateIcon closed:fts_window_1w@lightgreen opened:fts_window_1w_open@red
eventMap ^100.0:opened ^0.0:closed
group Temperatur
room Büro,CUL_TX
stateFormat temperature
Wahrscheinlich hast du recht wenn eine gewisse Latenz von 3 bis 5 Minuten zwischen dem Fenster öffnen und dem Anzeigen in fhem liegen.
Das mit dem Interrupt und "Winterschlaf" muß ich auch erst einmal anschauen. Aber ein Anfang ist gemacht.
Gruß rippi
P.S. Momentan läuft das ganze noch auf einem Nano bis die Attiny da sind.
Bin mir gerade nicht ganz sicher,
aber möglicherweise waren die "100.0" zu schnell geschossen.
Besser "99.99" ? Oder funktioniert es dennoch?
(Ohne gerade in den Code schauen zu können ...)
Könntest Du Deine Icon-Definition mit angeben? Oder reichen die obigen Attribute aus?
Grüße,
Jürgen
So wie es aussieht funktioniert es mit den 100.0 und auch die obigen Definitionen reichen aus.
Hatte nur am Anfang das Problem mit dem eventmap, dass da "." Punkte und ":" Doppelpunkte und " " Leerzeichen drin sind.
Also T: 0.0 oder T: 100.0 für state und 0.0 und 100.0 für temperature.
Gruß rippi
Schöne Lösung :D
Sehe gerade in Deiner Signatur die Intertechno-LAN Lösung:
https://www.amazon.de/ConnAir-433-Home-Automation-Gateway/dp/B008W1G620 (https://www.amazon.de/ConnAir-433-Home-Automation-Gateway/dp/B008W1G620)
http://wiki.simple-solutions.de/de/products/Conn_Air (http://wiki.simple-solutions.de/de/products/Conn_Air)
Die kannte ich noch nicht :)
Habe den Connair zwar noch im Einsatz, aber das Projekt wurde schon vor längerer Zeit von Simple Solution eingestampft bevor die Empfangsfunktion implementiert war. Der Vorteil war, dass er günstig war und ich ihn irgendwo platzieren konnte.
Ich glaube das Projekt wurde von Brennenstuhl aufgekauft.
Gruß rippi
Genau das habe ich auch vor.
Ich möchte aber noch einen Neigungsschalter mit einfügen, der dann zeigt ob das Fenster gekippt ist.
Müsste man per Widerstände (Spannungsteiler) erreichen können, bis da aber noch nicht so weit.
Interrupt wäre wichtig um einen Alarm auszulösen, aber nur wenn das Fenster ganz auf ist...mal sehen ob das so machbar ist.
@rippi46
Also es muss ja eine IF...THEN abfrage in FHEM möglich sein.
Bei dir: Wenn Temperatur 100 Grad dann Fenster rot
Kannst du das mit dem Fenster mal kurz hier zeigen wie das in FHEM gemacht wird ?
Ein mechanischer NeigungsSensor hat meines Wissens auch nur zwei Zustände: offen und geschlossen (Reed-Kontakt).
Ein digitaler Sensor könnte natürlich alles von 0..180/360 Grad erfassen. :)
(Ist das nicht etwas overkill? Offen/Zu reicht doch für ein Fenster, oder?)
Beide Sensoren ließen sich "umbiegen", so dass es mit dem LaCrosse-Protokoll harmoniert.
Interrupt ist nicht zwingend erforderlich. Wir müssen noch klären, ob während der Schlafphase der Interrupt
zum Aufwachen zugelassen ist, oder nicht. Ein Polling ohne Interrupt würde meiner Meinung
bei einer Schlafphase von ca. 2 Minuten völlig ausreichen. (Alarmanlage?! Wären da 2 Minuten relevant?)
Man könnte auch wechseln, also nur dann wirklich senden, wenn sich der Status ändert,
ansonsten nur nachschauen....
Grüße, Jürgen
PS: nur Attribute für das entsprechende CUL_TX_XYZ definieren:
ZitatAttributes:
alias Fensterkontakt
devStateIcon closed:fts_window_1w@lightgreen opened:fts_window_1w_open@red
eventMap ^100.0:opened ^0.0:closed
group Temperatur
room Büro,CUL_TX
stateFormat temperature
Hallo juergs,
du warst etwas schneller mit dem Antworten. :)
Danke!
War noch mit dem Zug unterwegs.
Gruß rippi
:) Dafür bin ich gleich auf den Autobahn ....
Zitat von: juergs am 19 September 2016, 17:46:50
Ein mechanischer NeigungsSensor hat meines Wissens auch nur zwei Zustände: offen und geschlossen (Reed-Kontakt).
Ein digitaler Sensor könnte natürlich alles von 0..180/360 Grad erfassen. :)
(Ist das nicht etwas overkill? Offen/Zu reicht doch für ein Fenster, oder?)
Ja das wäre bestimmt overkill, so ein einfacher mit Kugel der nur ein und aus kennt, reicht denke ich.
An einem Analog Input kann man per Widerstände (Spannungsteiler) mehrere Schalter abfragen, das ist kein Problem.
Bei dem Sketch muss man dann nur einen gewissen Bereich definieren, die Spannung der Batterie ändert sich ja, dann auch die Werte 0-1024
http://forum.arduino.cc/index.php/topic,8558.0.html
if(wert >= 440 && wert <= 450)...
dann sollte das gehen.
Hab mal so ein "Samon Say" oder wie bei uns "Senso" aus den 80ern nachgebaut mit einem Attiny85
4 LED, 4 Taster, einen Summer. Die LED als Charlieplexing, die Taster mit Spannungsteiler.
@ArduPino man könnte das ganz mit einem Attiny erschlagen.
1 Pin Temperatur
1 Pin Fensterkontakt (http://www.ebay.com/itm/350944895445?rmvSB=true (http://www.ebay.com/itm/350944895445?rmvSB=true))
1 Pin Neigungssensor (http://www.ebay.de/itm/10x-Neigungssensor-Pegelschalter-Niveauschalter-Beschleunigungssensor-Sensor/331145950503?_trksid=p2141725.c100338.m3726&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D20150313114020%26meid%3D0b280eca99b74ab3b83ee336517a77de%26pid%3D100338%26rk%3D1%26rkt%3D4%26mehot%3Dpp%26sd%3D371235639529 (http://www.ebay.de/itm/10x-Neigungssensor-Pegelschalter-Niveauschalter-Beschleunigungssensor-Sensor/331145950503?_trksid=p2141725.c100338.m3726&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D20150313114020%26meid%3D0b280eca99b74ab3b83ee336517a77de%26pid%3D100338%26rk%3D1%26rkt%3D4%26mehot%3Dpp%26sd%3D371235639529))
... oder mit Schiebregister ... :)
So meine Attiny sind jetzt endlich da.
Programmieren konnte ich ihn auch schon, aber leider wurde noch kein Device in fhem angelegt.
Muss mann noch etwas beachten.
Gruß rippi
Den richtigen TX-Pin erwischt?
Ich denke schon. PB4 --> Pin3 am attiny oder?
Ist es wichtig ob ich auf 1Mhz oder 8Mhz flasche?
Gruß rippi
Ja! FHEM kann keine Zeitlupe :D
Setze Clock auf "internal 8MHz" oder besser 16MHz über PLL:
https://www.hackster.io/porrey/attiny-16mhz-610d41 (https://www.hackster.io/porrey/attiny-16mhz-610d41)
http://www.engbedded.com/fusecalc (http://www.engbedded.com/fusecalc)
Für dieses Projekt muss nur der interne Takteiler 'divide clock by 8 internally' deaktiviert werden da sonst der Takt noch durch 8 geteilt wird und der Controller nur
mit 1Mhz läuft. Von der Sache währe das nicht schlimm, nur stimmen dann die Timings nicht mehr die für das Übertragungsprotokoll verantwortlich sind.
Also nur einmal die Fusebits auslesen, Haken weg bei 'divide clock by 8 internally' und wieder schreiben(Bild im Archiv).
Hallo juergs
habe es jetzt geschafft. In der .ino stehen die Fuses mit "avrdude: safemode: Fuses OK (H:FF, E:DF, L:E2)" --> dann geht aber nichts mehr. :(
Habe zwei Attinys vermutlich geschrottet. Mit "avrdude: safemode: Fuses OK (H:DF, E:FF, L:E2)" funktioniert es dann mit neuen Attinys.
Vielleicht kann man die "Verfuseten" mit der High-Voltage-Methode wiederbeleben.
Kann ich jeden Pin des Attiny für den Transmitter verwenden oder gibt es bevorzugte Pins? Ebenso für die Onewire-Devices?
Danke trotzdem für den Hinweis!
Gruß rippi
Ich flashe meine Attiny über die Arduino IDE per USB Programmer.
Da kann man gar keine Fuses (selber) setzen. Einfach auf 8Mhz stellen und Bootloader brennen.
Dann den sketch.
Es gibt einen Arduino ISP2 Sketch , mit dem könnte man mal versuchen den Attiny wiederzubeleben.
Das geht z.B. wenn man aus versehen 8Mhz external gewählt hat, anstatt z.B. 8Mhz internal.
Ob das in deinem Fall auch hilft, müsste man testen.
Ich benutze USBasp oder
http://www.ebay.de/itm/like/272212754039?lpid=106&chn=ps&ul_noapp=true
oder eher den hier:
http://shop.myavr.de/Topseller/mySmartUSB%20light%20-%20AVR%20ISP%20Programmer.htm?sp=article.sp.php&artID=200006
und dessen SW, die auch USBasp programmieren kann /Windows
Aber Fuses mit AVRDude:
http://heliosoph.mit-links.info/arduinoisp-reading-writing-fuses-atmega328p/
http://electronics.stackexchange.com/questions/7859/how-do-i-set-the-clock-speed-fuses-on-an-attiny85-when-using-an-arduino-as-a-pro
aber auf "8 MHz internal" setzen !
Sorry,bin leider nicht @home und kann es nicht checken.
Also mein Attiny85 läuft auf 8Mhz.
Leider läuft diese Narcoleptic Library nicht auf meinem Digispark...hatte da aber schon was mit dem whatchdog usw. gemacht.
Ob das genau so gut ist wie das andere weiß ich nicht. Per whatchdog kann man den Attiny nur 8 Sekunden schlafen legen, ich habe es so gemacht, das diese sleep routine direkt mehrmals hintereinander aufgerufen wird. So wacht er auf, und schläft wieder.
Auch hatte ich damals eine Spannungsmessung eingebaut um den Akku zu überwachen. Diese funktioniert jetzt aber nicht mehr. Ich wollte das mit einer eigenen Sender ID machen und dann einfach als Temperatur übertragen. Die erste Übertragung ist richtig, beim zweiten mal senden aber nicht mehr. Andere Librarys hab eich nicht. Sogar eine weniger weil hier das senden per digitalWrite gemacht wird...egal,wird verschoben.
Mit dem Neigungsschalter war ja mal eine blöde Idee :o
Eigentlich sollte das Teil mit den Kabeln ja am Fensterrahmen befestigt werden, am Fenster selber dann das Gegenstück (Magnet).
Wenn ich nun irgend was mit einem Neigungsschalter machen will, muss ich schon an dem Teil mit den Anschlusskabeln was machen...also müsste das Teil dann ans Fenster, was aber wegen den Kabeln eher schlecht ist...tja, denkfehler.
Falls mir nichts besseres einfällt,werde ich zwei Fensterkontakte befestigen um gekippt und offen zu unterscheiden, mal sehen. Das dann aber nur bei wichtigen Fenstern.
Hauptsächlich geht es mir um eine Alarmanlage. Nun muss ich mal schauen, wie man überhaupt eine Alarmanlage aufbauen könnte.
Da gibt es doch einiges was man beachten muss: Scharfschaltung, Alarmmeldung auf´s Smartphone, Abschaltmöglichkeiten bei Fehlalarm usw.
Wenn jemand dazu ein Projekt kennt, immer her damit.
Ansonsten passt das jetzt nicht wirklich hier rein, deshalb höre ich jetzt auf :)
Hallo,
bin gerade noch dabei bei den Funkthermometer (mit Fensterkontakt) eine Batterieüberwachung zu realisieren.
Habe aber immer wieder das Problem, das mir sowohl Batteriewerte als auch Fenster offen bzw. geschlossen Werte in der normalen Temperaturanzeige erscheinen.
Wie kann ich explizit festlegen mit welcher ID die Werte gesendet werden?
Oder lässt das Protokoll einen Batteriestatus zu?
Gruß rippi
Um das Verständnis des LaCrosse-Objektes etwas zu erläutern:
Es gibt mehrere Möglichkeiten diese Applikation einzusetzen und hoffe die Übersicht trägt etwas zum Verständnis
des Codes bei.
FHEM kann mit gleicher ID Temp + Hum-Messtellen unterscheiden. Diese werden einzeln versendet und FHEM setzt diese dann wieder unter einer ID zusammen.
Also kann man das Protokoll mit einer ID für eine Meßstelle oder 2 Meßstellen verwenden, wenn man diese mit der gleichen ID hintereinander sendet.
D.h. alle anderen Mischformen wären auch möglich. Also eine Meßstelle, eine ID. ZweiMeßstellen eine ID. n * zwei Meßstellen n* IDs ... usw.
Wenn die Funktionalität vom Standard abweicht, muss das in FHEM entsprechen konfiguriert werden (Bezeichnung, Skalierung).
ABER:
das LaCrosse-Protokoll hat nur ein 7Bit-Adressraum, kann also max. 127 IDs erkennen!Hoffe es nicht zu kompliziert 'rüber gebracht zu haben.
Zum konkreten Problem:
Natürlich darf man die Batteriespannungsmessung nicht mit der gleichen ID versenden, wenn diese schon mit zwei anderen Messungen belegt ist.
-> Woher soll FHEM wissen, was jetzt an welcher Stelle anzuzeigen ist?
Also: Batteriespannung einfach mit weiterer ID versenden.
ZitatWie kann ich explizit festlegen mit welcher ID die Werte gesendet werden?
Einfach definieren und vor dem Versenden dem LaCrosse-Objekt mitgeben und dafür sorgen, dass jeder Meßwert mit "seiner" ID versendet wird!
Eigentlich gleiches Prinzip wie beim 4fach-DS18B20-Sensor: hier (https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=55141)
Grüße,
Jürgen
Noch eine Anmerkung zu den ATtiny85-Fuses:
8MHz internal ist richtig!
Die Screenshots sind meine gewählten Einstellungen.
Hallo juergs,
Danke für deine ausführliche Beschreibung. Ich denke, dass ich das soweit verstanden habe.
Ich habe eher das Problem, dass ich auf eine andere ID umschalte und dann meine Werte sende. Dann kann es passieren, dass die Werte bei der zuvor eingestellten ID landen. Entweder ist es ein Timingproblem (habe auch schon Delays eingefügt) oder ich schalte nicht richtig auf die neue ID um.
z.B. benutze ich folgende Befehle zum wechseln der ID und zum senden der Werte
LaCrosse.bSensorId = SENSOR_BASIS_ID;
LaCrosse.sendTemperature();
delay(2000);
LaCrosse.bSensorId = SENSOR_ID_1;
LaCrosse.sendTemperature();
delay(2000);
Leider kommen nicht immer alle Werte bei der richtigen ID an.
Gibt es noch einen anderen Befehl um explizit die ID zu setzen?
Gruß rippi
P.S. hast du zufällig einen funktionierenden Code für das Messen der Batteriespannung.(das sollte ja ohne zusätzliche Beschaltung an den Pins funktionieren)
Ich glaube nicht, dass es ein Timing-Problem ist.
Dafür laufen bei mir ca. 7 Sensoren ohne Probleme.
Evtl. könnte es sein, dass andere Sender "dazwischenfunken"? Vielleicht vom Nachbar?
Bei gleichen Zeitabständen kann das durchaus der Fall sein, deshalb habe ich im Code noch
eine Random-Funktion eingebaut um die Intervalle variieren zu können und nicht im
starren Zeitmuster zu verharren.
Außerdem habe ich für Narcoleptic noch eine Erweiterung eingebaut um Minuten lang den Controller schlafen zu legen können:
void delay_minutes(int minutes); Zitathast du zufällig einen funktionierenden Code für das Messen der Batteriespannung.(das sollte ja ohne zusätzliche Beschaltung an den Pins funktionieren)
... baue morgen mal was zusammen ...
Grüße,
Jürgen
Erst mal "Batteriespannung messen" vorne weg:
measure-battery-voltage (http://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/)
ZitatVcc = 1.1 * 1023 / ADC-measurement
long readVcc() {
// Read 1.1V reference against AVcc
// set the reference to Vcc and the measurement to the internal 1.1V reference
#if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ADMUX = _BV(MUX5) | _BV(MUX0);
#elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
ADMUX = _BV(MUX3) | _BV(MUX2);
#else
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#endif
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuring
uint8_t low = ADCL; // must read ADCL first - it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high<<8) | low;
result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
return result; // Vcc in millivolts
}
Die Konstante 1125300L muss ggf. angepasst werden. (für genauere Werte präzise Spannungsmesser benutzen und gegen messen.)
Siehe auch
Improving AccuracyIch benutze u.A. diese IDE-ATtiny-Preferences-Einstellungen:
attiny-support-unter-arduino-1-6-installieren (http://fluuux.de/2015/08/attiny-support-unter-arduino-1-6-installieren/)
und nicht die Digispark (mit USB-Bootloader).
Bei mehreren Einträgen (z.B. ESP8266) durch Komma separiert eingeben.
Wenn man verschiedene Version implementiert hat,
muss man doch genauer in die Code-Kommentare schauen:
Bei meiner DHT22-Version habe ich u.A. folgende Fuse-Einstellungen für den ATtiny mit 16MHz Taktrate genommen:
http://www.netz39.de/2014/attiny85-with-16mhz/ (http://www.netz39.de/2014/attiny85-with-16mhz/)
https://www.hackster.io/porrey/attiny-16mhz-610d41 (https://www.hackster.io/porrey/attiny-16mhz-610d41)
Zitat/*
Fuse-Einstellungen beim ATtiny85 für interne 16 MHz:
====================================================
LF = 0xF1 ( PLL-Clock, not internal 8 MHz)
HF = 0xDF
EF = 0xFF
LB = 0x03
*/
Das erklärt vielleicht den Unterschied der Timings zwischen Leonardo (16Mhz) und ATtiny (16MHz
oder 8MHz).
D.h. wenn 16MHz vom Timing gefordert waren, ist die 8 MHz-Einstellung natürlich nicht unbbedingt die Richtige (aber *)!
Das richtige Timing ließe sich aber mit einem LA oder Oszi schnell nachprüfen. (siehe LaCrosse-Protokoll)
Die Angaben stehen allerdings auch im Code zum Nachlesen!
(*) Dennoch: die Funktion "
delayMicroseconds" sollte eigenlich unabhängig von der Taktrate sein und
somit mit allen möglichen Taktraten-Einstellungen funktionieren.
Grüße,
Jürgen
Da das Projekt für BMP180 + DHT22 + DS18B20 etwas aufwändiger (spezifische ATtiny-I2C-Anbindung) wird,
hier mal in der Zwischenzeit etwas Orientierungshilfe:
1. Arduino Collection: X10 Wireless Temperature Transmitter
http://brohogan.blogspot.de/2009/05/x10-wireless-temperature-transmitter.html (http://brohogan.blogspot.de/2009/05/x10-wireless-temperature-transmitter.html)
Battery-Life-Time-Calculation (http://interface.khm.de/index.php/lab/interfaces-advanced/sleep_watchdog_battery/)
2. The Compleat ATtiny13 LED Flasher: Part 3 - Low Power Mode - Brownsofa
http://brownsofa.org/blog/2011/01/09/the-compleat-attiny13-led-flasher-part-3-low-power-mode/ (http://brownsofa.org/blog/2011/01/09/the-compleat-attiny13-led-flasher-part-3-low-power-mode/)
3. Reduce ATtiny power consumption by sleeping with the Watchdog Timer « insideGadgets
http://www.insidegadgets.com/2011/02/05/reduce-attiny-power-consumption-by-sleeping-with-the-watchdog-timer/ (http://www.insidegadgets.com/2011/02/05/reduce-attiny-power-consumption-by-sleeping-with-the-watchdog-timer/)
4. Google Code Archive - ATTiny-TWI-Library.
https://code.google.com/archive/p/arduino-tiny/ (https://code.google.com/archive/p/arduino-tiny/)
5. X10 Remote Temp Sch.png (PNG-Grafik, 1350 × 1032 Pixel)
https://dl.dropboxusercontent.com/u/3572198/Blog%20Files/X10%20Remote%20Temp%20Sch.png (https://dl.dropboxusercontent.com/u/3572198/Blog%20Files/X10%20Remote%20Temp%20Sch.png)
6. Alternative I2C-Lib
http://www.eevblog.com/forum/microcontrollers/good-usi-i2c-master-slave-attiny85-library-(optionally-master-arbitration-)/ (http://www.eevblog.com/forum/microcontrollers/good-usi-i2c-master-slave-attiny85-library-(optionally-master-arbitration-)/)
7. I2C
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/
8. ATtiny85 support
http://highlowtech.org/?p=1695 (http://highlowtech.org/?p=1695)
9. Manchester
http://www.instructables.com/id/Receiving-and-sending-data-between-Attiny85/ (http://www.instructables.com/id/Receiving-and-sending-data-between-Attiny85/)
http://www.instructables.com/id/Attiny85-RF-Transmitter-to-Arduino-Uno-Receiver-Ma/?utm_source=base&utm_medium=related-instructables&utm_campaign=related_test (http://www.instructables.com/id/Attiny85-RF-Transmitter-to-Arduino-Uno-Receiver-Ma/?utm_source=base&utm_medium=related-instructables&utm_campaign=related_test)
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/ (http://www.instructables.com/id/Mini-weather-station-with-Attiny85/)
http://www.instructables.com/id/Reading-the-BMP180-Pressure-Sensor-With-an-Attiny8/ (http://www.instructables.com/id/Reading-the-BMP180-Pressure-Sensor-With-an-Attiny8/)
Anmerkung: Bin selbst überrascht, dass die Portierung Leonardo -> ATtiny sich doch etwas aufwändiger gestaltet.
Anbei der ATtiny85-Vorabsketch mit BMP180 + DHT22 + VCC-Reading für eigene Experimente.
Fensterkontakt + DS18B20 fehlen noch. Mal schauen, ob dann alles noch ins Flash passt ?
Habe leider immer noch das Problem, dass z.B. die Batterispannung bei der Temperatur auftaucht, obwohl ich die ID gewechselt habe.
Wird die ID nicht zusammen mit den Temperatur und Luftfeuchtigkeitswerten versendet?
hier mein Sketch mit Fensterkontakt und Interrupt.
Gruß rippi
PS: Leider konnte ich deinen Sketch noch nicht testen. Muss jetzt grillen.
Hi,
habe etwas aufgeräumt.
Als Hinweis: den Code modular aufbauen:
- In Arduino Loop muss die Funktionalität ersichtlich sein und so wenig Low-Level-Code wie möglich dort unterbringen.
- In Loop immer in Funktionen Ergebnisse holen und in Loop weiter verarbeiten. Entweder wieder in Funktionen oder auch dort, wenn's übersichtlich bleibt.
- Den Interrupt-Code habe ich entsorgt, da ich der Meinung bin: hier nicht erforderlich! Die Wiederholungsrate in loop ist dafür völlig ausreichend. Es sei denn, das Fenster bewegt sich im uS/mS-Takt ;D
Das Ganze dient der Übersichtlichkeit, weil ich glaube, Du hast den Überblick verloren, wo Du was setzt.
Also habe ich versucht das Ganze etwas aufzuräumen und die Funktionalität an der richtigen Stelle zu bearbeiten. ;)
Das schont bei zunehmender Komplexität die Nerven...
Das Protokoll sendet ja TEMP und HUM unter der gleichen ID=109.
TEMP ist der DALLAS-18B20-Sensor
HUM ist bei Dir ja der Fensterkontakt mit den zwei Zuständen "0.0" und "100.0".
VCC wird noch als Temperatur mit der ID=111 gesendet.
Ich vermute, daß FHEM die ID/Sensor-Reihenfolge logisch in aufsteigender Reihenfolge erwartet.
Vermutlich machen das die kommerziellen Sensoren auch so.
Das Umbiegen der Bezeichnung machst Du ja dann in FHEM.
Leider hatte ich keine Zeit mehr zu Testen, weil mit meiner IDE-Version der Compile zwar durchgeht,
aber einige Low-Level-Libs noch mit Mehrfach-Deklartionen dazwischenfunken. (Arduino-Version?)
Also für eine endgültige Version noch etwas Geduld.
Grüße,
Jürgen
Hallo juergs,
ich bin jetzt endlich dazu gekommen deine Version zu testen.
Im Prinzip funktioniert der Temperatursensor mit Fensterkontakt und Batterieanzeige.
Bei der Berechnung wird schon der Wert in mV zurückgegeben, deswegen kann die Berechnung außerhalb der read_vcc weggelassen werden.
Der Wert der Batterieanzeige taucht dann nach dem ersten Aufwachen bei der Temperatur des Temperatursensors auf.
Es sieht so aus, als ob im Puffer noch der Wert der Batterieanzeige steht. Also beim Übertragen der Temperatur steht der aktuelle Wert des Temperatursensors noch nicht zur Verfügung.
Wenn ich mehrfach den Wert des Temperatursensor vor dem Senden der Temperatur auslese, wird der richtige Wert übergeben.
Vielleicht hast du ja noch eine Idee?
Trotzdem Danke für deine Unterstützung. :)
Gruß rippi
Achtung: Lacrosse erwartet ein Float-Datentyp als Temperatur
und ein Long lässt sich zwar implizit als Float darstellen, aber die max. Stellenanzahl für
das Protokoll wird bei VCC als Millivolt überschritten.
Deshalb die Umrechnung in Volt mit Nachkommastellen!
Hallo juergs,
habe natürlich den wert noch durch 100 geteilt bevor ich ihn übergeben habe.
Hier mal ein Bild vom ersten Prototyp.
Cool + nicht schlecht! :)
Da würde sich die ganze Sache in SMD anbieten:
Sender 433MHZ-STX882 (http://www.ebay.de/itm/433MHZ-STX882-High-power-ASK-Precise-Wireless-Transmitter-Module-/371729356157?hash=item568ccbd57d) + Sensor DALLAS-DS1620S (http://www.ebay.co.uk/itm/DALLAS-DS1620S-Temperature-Sensor-IC-3-Wire-SO-8-NEW-10-PCS-/322048672584) und ATTiny.
Was für eine Batterie und Gehäuse hast Du ausgewählt?
Grüße,
Jürgen
Das ganze habe ich auf einer Lochrasterplatine aufgebaut. Als Batterie verwende ich momentan eine AAA 1,5V.
mit einem DC-DC Step Up Boost Module 3v3 versorge ich dann die ganze Schaltung.
Das Gehäuse ist von einem Homematik Fenstersensor (optisch). Dieser passt von der Breite auch in den Rahmen meiner normalen Fenster.
In SMD-Technik würde das Ganze natürlich besser in das Gehäuse passen.
In der endgültigen Version verschwinden nätürlich die Kabel und der Reedkontakt kommt mit ins Gehäuse.
Aber das ist erst einmal der Anfang.
Ich habe die Interruptroutine für den Fensterkontakt momentan noch drin, da an den Fenstern Velux-Rollläden sind und ich mitbekommen will,
wenn meine Kinder gerade das Fenster öffnen.
Gruß rippi
Da bin ich mal auf die Laufzeit gespannt.
1.5Volt + StepUp .... Grübel + Stirnrunzel. ;)
Ich auch :)
Habe auch noch immer das Problem mit der Batteriespannung.
Ich habe allerdings nicht den code hier verwendet, sondern hatte das ja schon auf meinem Digispark (Attiny85) am laufen.
Ist aber das gleiche vermute ich mal.
Ich lasse zuerst Temp. und Hum. senden.
Warte 200 Millisekunden, gebe dann t=0.0 einen Festwert (nur zum testen) lasse den senden und dann gebe ich t=Spannung.
t=0.0 ist zur Fenster Erkennung. Das habe ich mit einem Poti mal schnell getestet. 0 = Fenster zu, 50 = gekippt, 100 = auf. Läuft !
Nur die Spannungsmessung funktioniert nur ein mal.
Ich erhalte z.B. 4.1V (keine Ahnung warum das am USB Port so niedrig ist), das wird auch so in FHEM angezeigt. Danach bleibt der Wert auf 1.0
Setze ich das fest t=4.875 wird mir in FHEM schön 4.8 angezeigt und zwar immer.
Also muss da irgend was mit der Spannungsmessung nicht funktionieren. Habe schon mehrere delay eingebaut um das ganze etwas zu verlangsamen.
Am senden kann es nicht liegen, sonst wäre der feste Wert auch falsch und den habe ich extra mal mit 3 Nachkommastellen getestet.
Die Spannungsausgabe laut Serial.Print ist nur zweistellig nach dem Komma.
Weiß echt nicht was da falsch sein könnte.
delay(200);
int t2 = analogRead(analogpin); // Widerstand / Fensterkontakt an Sensor xxx+1
//t2 = map(t2, 0, 1023, 0, 100);
t_old = t; // alte Temperatur speichern um falsche Werte zu vermeiden
t=0.0; // zum testen Fenster zu
SENSORID = SENSORID_A; //übergeben der neuen Sensor ID 112
sendTemperature();
delay(500);
// Spannung an Sensor xxx+2
SENSORID = SENSORID_B; //übergeben der neuen Sensor ID 113
t=decimalVcc; //4.88 ;
sendTemperature();
t = t_old; // alter Wert zurück, um Fehlanzeigen zu vermeiden
SENSORID = SENSORID_ID; //übergeben der haupt Sensor ID 111
Vermute mal das da irgend was mit den Variablen nicht funktioniert. Die Spannung verwendet double t und t_old float
Werde das mal gleich setzen, mal sehen was dann passiert.
EDIT: War ja klar, kaum den Beitrag geschrieben, schon den Fehler gefunden...war ja vorher nur Stunden da dran :o
In der system_sleep() routine habe ich die Analog-Digital Converter aus geschaltet. Das geht anscheinend, solange keine Spannungen gemessen werden ;D
sbi(ADCSRA,ADEN);
schaltet diese wieder ein. Dann funktioniert das auch !
Zitat von: rippi46 am 29 September 2016, 08:37:40
Hier mal ein Bild vom ersten Prototyp.
Das Batteriesymbol habe ich auch, ein dummy angelegt, Icons mit devStateIcon gesetzt für low und high und dann ein DOIF angelegt mit
define di_Batterie1 DOIF ([CUL_TX_113:temperature] <3.0) (set Batterie1 low) DOELSE (set Batterie1 high)
Ok so ? Funktioniert auf jeden Fall :)
Aber wie bekommt man denn mehrere Werte in eine Zeile ? Habe jetzt alles getrennt.
Wobei das für das Webinterface eigentlich nicht soooo wichtig ist. Auf jeden Fall möchte ich dieses TabletUI verwenden und dann auch ein Tablet an die Wand hängen...schön alles auf einen Blick, mit Wetter, Unwetterwarnung, Fenster auf/zu, Temp. /Hum / Batterie , Müllkalender...und ein oder zwei Funksteckdosen...falls mal eine nicht so schaltet wie FHEM (oder ich) das will...also eigentlich ganz einfach :D
Was bedeutet denn die -85 ? Luftfeuchtigkeit ?
Hallo ArduPino,
habe das ganze mit readingsGroup gemacht.
Die -85 kommt von Empfangsqualität RSSI. Das sind ca. 13m durch 3 geschlossene Türen.
Da der Tranceiver nur mit 3,3V betrieben wird finde ich das eigentlich ganz ok.
Ich sende nicht 3,3 über die Temperatur sondern eine 10er Potenz höher, und mache die Umwandlung dann in fhem.
Gruß rippi
Hallo Jürgen,
hast Dich ja seit Mai mächtig ins Zeug gelegt. Ich hab nun auch meinen ersten 85er flashen können :D Das war schon extrem nervenaufreibend:
https://forum.fhem.de/index.php/topic,58746.0.html
Leider hab ich aber noch kein Funkmodul. Welches nutzt Du eigentlich ? RFM12B ? Ich wird es vielleicht mal mit einem Hideki-Sender aus einem Wettersensor probieren. Kann es gar nicht erwarten meinen stromsparenden, selbstgebauten "Post-ist-da-Taster" mit Deinem (dann endgültigen ?) Sketch fertigzustellen. Ahh noch ne Frage: wenn im Sketch die Pins angegeben werden, so ist das immer die PBX-Nr. oder ? Ich würd dann 3 und 4 nehmen.
Grüße Markus
Hi Markus,
schön wieder mal was von Dir zu höhren...
Algemein habe ich mich auf die wohl auf die 433MHz-Sender eingeschossen,
weil die wohl am billigsten und am unaufwendigsten (sowohl RX, als auch TX) sind.
Den RFM oder CC1101 wäre zwar auch möglich (z.B. Panstamp-Lib), erschien mir
aber wegen des Verwendungszwecks zu aufwendig.
Für das 85er-Pinout kann ich Dir diese Seite ATtiny-Pinouts (http://www.pighixxx.com/test/portfolio-items/tiny/)
bzw. das hier: als PDF (http://www.pighixxx.com/test/pinouts/processors/attiny.pdf) empfehlen. Oder hier: flickr (https://www.flickr.com/photos/28521811@N04/sets/72157632703854644)
Da scheint mir auch das Pinout zu stimmen und sie ist allgemein sehr interessant (;-)
Auch die Zuordnung "physikalischer Prozessor-Pin" zu "Arduino-Pin" ist hier ersichtlich (graue Pin-Nrn zu denen in lila). Im Code ist natürlich nur der Arduino Pin gültig.
Im Kommentar steht meist der physikalische mit dran.
Da ich aber mehere Versionen erstellt habe, kann das manchmal aber auch nicht ganz aktuell sein.
Evtl. wäre es wohl besser auf GitHub zu verwalten ... (Wenn ich dazu komme...)
Die zweite, eigentlich aktuellere SW-Version ist hier: https://forum.fhem.de/index.php/topic,56660.0.html (https://forum.fhem.de/index.php/topic,56660.0.html)
Wenn ich dazu komme, fasse ich beide Versionen zusammen und baue den Fensterkontakt mit ein.
Aber die kalte Jahreszeit beginnt ja gerade ... (;-((
Zu "meine Erfahrung mit Digispark aus China" kann ich nur sagen, das es das klassische Henne-Ei problem ist.
Da ich mehrere ISP-Programmer habe, ist es bei mir einfacher gewesen das zu raffen.
Aber das passiert dir ja mit den NANO-Boards auch.
Apropos Empfindlichkeit: Ein Kurzschluss, der natürlich keinem Profi passiert ;D
geht auf dem Digispark die Schottkydiode mit exact 0.5 A Durchlaßstrom kaputt (USB-Hub!).
Da macht es Sinn, besonders wenn man öfters experimentiert, davon mal einige Stück vorsorglich anzuschaffen. :D
Die Temperatursensoren sind allerdings eher Batterie gespeist, deshalb braucht man den USB-Port da eigentlich nicht.
Außer zum Programmieren des Chips. Nachteil, es fehlen dann ein paar Bytes für das Hauptprogramm.
Grüße,
Jürgen
Hier ein Beispiel für das Verhalten bei Batterie-Spannung von 2.6V (!) mit DS18B20 Sensor.
Da macht es schon Sinn die Batteriespannung mitzusenden ;)
Das waren aber flotte Kurztrips an die Pole ;)
ZitatAlgemein habe ich mich auf die wohl auf die 433MHz-Sender eingeschossen,
weil die wohl am billigsten und am unaufwendigsten (sowohl RX, als auch TX) sind.
Meinst Du damit es müsste grundsätzlich mit jedem billigen China-Sender funktionieren ?
Zitat(graue Pin-Nrn zu denen in lila)
So hatte ich es verstanden und ist ja gleich PBx, aber was sind die Ax's in grün ?
Hast Du eigentlich auch schon was mit Empfang gemacht ? Mir schwebt da eine aus fhem gesteuerte 433Mhz-->IR Fernbedienung für meine alte B&O vor. Die IRMP gibt das her. Ist in der culfw implementiert und soll auch mit attiny85 funktionieren. Nur wohl (noch) nicht über die Arduino IDE >:( Ich recherchiere dazu mal weiter....
Grüße Markus
Zitat... müsste grundsätzlich mit jedem billigen China-Sender funktionieren
Yep. Z.B. STX882.
Zitat... aber was sind die Ax's in grün
Alternative PIN-Funktionen. (z.B. Analog-Input)
ZitatMir schwebt da eine aus fhem gesteuerte 433Mhz-->IR Fernbedienung für meine alte B&O vor.
Warum nicht?
433-receiver-to-infrared-gateway sozusagen ...
Man muss nur die FHEM-Kommandos (falls existent) empfangstechnisch dekodieren und als IR-Kommandos weitergeben. (Signalduino oder FHEMduino?)
Sollte also leicht zu implementieren sein ...
Mach doch dafür am Besten einen eigenen Thread auf....
Zitat von: juergs am 09 Oktober 2016, 19:20:46
Hier ein Beispiel für das Verhalten bei Batterie-Spannung von 2.6V (!) mit DS18B20 Sensor.
Da macht es schon Sinn die Batteriespannung mitzusenden ;)
Hab gerade nachgesehen, ein normaler Attiny85 ist mit 2,7V Mindestspannung angegeben, die Attiny85V sind mit 1,8V angegeben.
Weiß aber nicht bei wie viel Mhz.
Ich habe einen 3,6V LiIon Akkus an meinem Digispark, damit hat er aber nur 8 Tage gehalten.
Dieser war längere Zeit bei 2,9V, dann von einem Tag auf den anderen ist er aus gegangen.
Welche Kapazität der Akku noch hat weiß ich nicht, ist ein alter aus einem Laptopakku, bei einem Ladestrom von 0,5A sind da irgend was um die 900mAh rein gegangen.
Was wieder raus kommt ist dann auch noch was anderes.
Die Digispark sind super zum Programmieren. USB Verlängerungskabel dran und fertig. In den normalen USB Stecker passen die irgend wie nicht bei mir, sind anscheinend etwas dicker als die Norm erlaubt.
Aber eigentlich sind die "zu schade" um fest eingebaut zu werden. Werde mal schauen ob ich die anderen Sender mit einem Attiny85V baue, je nach dem welche Mindestspannung die bei 8Mhz haben.
EDIT:
Habe mal nach diesen Attiny85V gsucht, aber die sind recht teuer (im Vergleich zu einem normalen Attriny85). Preise extrem unterschiedlich, gesucht bei den üblichen eBa.. Amaz.... Aliexp....
Dann habe ich diesen Digispark für 1€ gesehen ! Da noch was selber basteln ??? Ob diese V Typen auch weniger Strom verbrauchen ? Einmal pro Woche Akkus laden wäre etwas nervig.
@rippi46
Wie läuft es mit deinem StepUp ?
Mein attiny85 läuft seit 2 Wochen mit einem eneloop akku AAA. Die Spannung des akku liegt immer noch bei 1.24V.
Anfänglich hatte ich die StepUp-Spannung übertragen, was natürlich kein Sinn machte. Momentan übertrage ich die tatsächliche Akkuspannung.
Die CR2032-Batterien halten bei mir ca. 6 Wochen durch.
Das liegt wohl daran, dass ich noch nicht alles Potenzial ausgenutzt habe.
Zwischen den Messungen/Sende-Vorgängen-Pausen wird noch nicht in den Sleep-Modus gegangen.
An und für sich verhält sich der Stromverbrauch ja eigentlich sehr gut (ca. 9mA für die Dauer der Sendevorgänge).
Der Rest ist unter der Meßgrenze des mA-Meßbereichs meines Meßgerätes.
Dennoch das Delta der Batterie ist ist ja sehr eng: 3V im vollen Zustand, bei 2.6V fängt der DS1820 an zuerst einzuknicken.
Mit einem 18650 habe ich das Problem nicht: 4.2 V im vollen Zustand. Bei Bedarf per USB wiederaufladbar.
Nebeneffekt: die zusätzlichen 1,2V ergeben auch mehr Sende-Power.
Deshalb sah ich jetzt (noch) nicht den Bedarf, den Strom-Konsum per Code weiter zu optimieren.
Die Specs der CR2032, etwas "dünn" (Laufzeit ca. 6 Wochen.):
ZitatSpannung 3V
Kapazität 230mAh
besser: 2 * AAA: Specs AAA_battery (https://en.wikipedia.org/wiki/AAA_battery) mit ca. 540 mAh als Zink/Carbon-Batterie.
Specs AA_battery (https://en.wikipedia.org/wiki/AA_battery):
misconceptions power-source/ (http://cybergibbons.com/uncategorized/arduino-misconceptions-6-a-9v-battery-is-a-good-power-source/)
oder hier, zitiere PeMue (https://forum.fhem.de/index.php/topic,49800.msg483238.html#msg483238)
Grüße,
Jürgen
Habe heute die Version 2.6.12 der Arduino IDE installiert.
Da ständig diese Fehler im Zusammenhang mit ATtiny85 Compiles auftauchten:
ATtiny85_LaCrosse_TempSensor:1: error: stray '\357' in program
ATtiny85_LaCrosse_TempSensor:1: error: stray '\273' in program
ATtiny85_LaCrosse_TempSensor:1: error: stray '\277' in program
exit 1
Die Version 2.6.12 hat es aber auch nicht behoben ...
Ursache: der Text war in UTF-8 codiert. Warum die IDE das plötzlich nicht mehr verarbeitet?
Encoding auf ANSI im Editor gestellt, Texte convertiert (NP++) -> geht wieder.
Puhhh, ist das schwierig für einen µC Anfänger :o
So laaaaaangsam fange ich an zu verstehen.
@juergs: Du hattest mich ja auf den _attiny85_BMP180_433 V2 Sketch hingewiesen. Nur finde ich da gar nicht mehr den Stromsparmodus über narcoleotics, sondern simple delays :( Bin ich blind oder noch zu dumm ? Und was ist dieses "neue" twi ? Und dann verlierst Du mich immer bei den PIN-Zuordnungen. Liegt das vielleicht daran, dass der Ursprung für den Leonardo entwickelt ist ?
Danke&Grüße Markus
Hallo Markus,
kannst Du mal schildern, was Du genau machen möchtest (Nano, ATtiny oder Leonardo)?
Ich habe drei Threads einen mit Dallas-DS18B20-Sensor (+ 4-fach-Version)
einen mit DHT22, sowie einen mit BMP180 und jetzt auch noch den Bodenfeuchtesensor.
Das Prinzip LaCrosse/Narcoleptic und Sketch ist doch immer das Gleiche.
Du musst Dir nur bewusst sein, wann Du den Tiefschlaf einschaltest und wieder aufhebst.
Insbesondere um Strom zu sparen. Beim Messen+Senden darfst du nicht Narcoleptic mit aufrufen,
sondern erst wenn alles getan ist, bis zum nächsten Durchlauf. Also einfach: Probieren!
Schau Dir das Prinzip einfach bei den anderen Versionen ab, dann sollte es funktionieren.
Die älteren habe ich einfach zum Testen mit dem Leonardo gemacht, um den seriellen Output zu haben.
Außerdem: würde es Spaß machen, wenn gleich alles auf Anhieb funktioniert? ;D
So lernt man, wie auch ich, immer was Neues dazu ... ;)
Z.B. den Gegensatz "C" zu "C++", wann Objekte instanziiert sind, wann nicht und warum ... etc,etc + pp ...
Aber jeder fängt mal an...
Jürgen
Zitat(Nano, ATtiny oder Leonardo)?
attiny85
eigentlich nur batteriebetrieben einen schalterzustand einlesen und senden. Am liebsten(Version 2.0) noch: kein zyklisches Lesen, sondern Aufwecken aus dem Sparmodus bei Schalterbetätigung. Da ist Interrupt das Stichwort, oder ?
Und Du hattest so
ZitatDie zweite, eigentlich aktuellere SW-Version ist hier: https://forum.fhem.de/index.php/topic,56660.0.html
verwiesen. Nur da find ich gar nix mehr von Stromsparmodus :( Daher meine Frage. Und dann schreibst Du jetzt, das sei die Ältere. I'm confused. ??? Eigentlich möchte ich nur Deinen aktuellsten Sketch mit Stromsparmodus und attinyx5 als Startpunkt nutzen. Aber wo finde ich den ?
Danke u. Grüße Markus
Ah, das ist eine andere Geschichte!
Der Kontakt wird mit der Temperatur ausgelesen, das ist ein 2..5 Sekunden Intervall, danach legt sich der ATtiny wirklich z.B. für ca. 30s schlafen.
Ein Aufwachen aus dieser Phase habe ich noch nicht implementiert und müsste ich auch erst Testen.
Vielleicht kann Dir da rippi46 mit seiner Version weiterhelfen, der möglicherweise diesen Modus bei sich implementiert hat.
@KölnSolar:
Vorschlag: Stelle einfach einen neuen Thread ein z.B. "Eigenbau 433 MHz-Kontakt-Sensor".
und stelle Deinen Code mit ein, unabhängig welcher Zustand, dann kann ich Dir gezielter
dabei helfen und es interessiert ja vielleicht auch noch andere ...
Jürgen
Mit ATTINY84 und rfm69cw:
http://raspberry.tips/raspberrypi-tutorials/diy-temperatur-und-leuftfeuchte-sensoren-mit-rfm69cw-funksender/ (http://raspberry.tips/raspberrypi-tutorials/diy-temperatur-und-leuftfeuchte-sensoren-mit-rfm69cw-funksender/)
Zitatkann ich Dir gezielter dabei helfen
Ja danke und gerne, nur: mein Problem ist nicht ein nicht funktionierender Code, sondern das Aufsetzen meines "Entwicklungssystems"(Arduino IDE, digispark, attiny85, flash bootloader über Rpi-SPI, Basis-Sketch....)
Hab jetzt den Status, dass ich so richtig ins programmieren und testen komme. Leider hab ich immer noch kein Funkmodul und wollte mir mit einem ausgebauten aus einem Hideki-Funkthermometer behelfen. Klappt aber leider nicht :(
Nun hab ich feststellen müssen, dass der Lacrosse-Empfang gar nicht so einfach ist. In meinem RFXTRX hab ich Lacrosse aktiviert, kommt aber nix an. Ein CUL433 ist ja noch problematischer. Zwar sollte der Empfang funktionieren, aber nur im "native" mode, so dass keine anderen Protokolle mehr gleichzeitig empfangen werden können. GANZ schlecht, wenn man den Ausgangspunkt dieses Threads betrachtet. :o Warum hattest Du TCM als "Basis-Protokoll" verworfen ?
Womit empfängst Du LaCrosse, CUL433 ? Wenn ja in welchem Modus(1 oder 2) ? Oder ist dieser native mode überhaupt nur für 868 Lacrosse ?
Grüße Markus
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.
Zitatin 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.
ZitatNun hab ich feststellen müssen, dass der Lacrosse-Empfang gar nicht so einfach ist
Doch isses ;)
ZitatWarum 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 ... :)
Zitatausgebauten 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 ... 8)
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?).
danke für die Info.
ZitatKenne 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 ?
ZitatWoher 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 :(
Zitat2. 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
Zitatset 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).
ZitatIrgendwo 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.
ZitatProtokoll = 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 (http://www.f6fbb.org/domo/sensors/tx3_th.php)
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:
ZitatClients
: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.
Out-of-the-box:
Zitatculfw (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
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.
ZitatSlowRf 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
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.
ZitatHoffe 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
Man kann es sich aber auch schwer machen ;) ;) ;)
Dann passt das so. 8)
Aber warum sollte der CUL433 "SlowRF" für FS20 (868MHz) als Standard einstellen?
... ohne jetzt in den Code schauen zu wollen ...
Hi Jürgen, bin weiter basics am lernen. ;D
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
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 ... :D
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 (http://playground.arduino.cc/Learning/ArduinoSleepCode)
Es gibt ja auch schon fertig in
power.h:
//--- switch AD-converter off
power_adc_disable(); Zitatbrown-out-detection
schalte ich per Fuse ab.
Grüße,
Jürgen
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
Zitatsondern 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!
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://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://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__sleep.html)
http://www.nongnu.org/avr-libc/user-manual/group__avr__power.html (http://www.nongnu.org/avr-libc/user-manual/group__avr__power.html)
https://www.mikrocontroller.net/articles/Sleep_Mode (https://www.mikrocontroller.net/articles/Sleep_Mode)
Zitat von: KölnSolar am 30 Oktober 2016, 12:32:22
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.
@Ardupino:
die V1.6.6 ist etwas alt, ich benutze die V1.6.12.
Zitat von: juergs am 30 Oktober 2016, 14:37:32
@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.
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/ (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.
Die Standard Narcoleptic geht für mich auch nicht zu kompilieren,
deshalb hatte ich auch meine Version beigegegeben:
Das hier fehlte noch im Original in Narcoleptic.cpp:
// mod to support attiny85
#if defined(__AVR_ATtiny85__)
#define WDTCSR WDTCR
#endif
Dann funktioniert Narcoleptic mit Digispark!
Hmm, das ist aber nicht die Version, die ich meinte ;-(
Zitat#ifdef BODSE
// Turn off BOD in sleep (picopower devices only)
MCUCR |= _BV(BODSE);
MCUCR |= _BV(BODS);
#endif
ist ín Deiner Version gar nicht enthalten :( Unter dem Link von mir gibt es irgendwie 3 Versionen. 1(14.7.10) und 1a(15.7.10) unter downloads, die sehen aber ganz anders aus als die Version, die ich mir über den Source link heruntergeladen hab. Die scheint identisch mit https://github.com/rcook/narcoleptic vom 21.10.10. Diese bekam ich nicht kompiliert. Ne Menge Register-Bits, die nicht definiert waren, weil wohl für den attiny85 nicht vorhanden. Hab ich dann alle mit ifdef "auskommentiert". Auch das WDTCSR(heißt im Attiny WDTCR). Dann ließ es sich kompilieren. Nun schaue ich morgen mal weiter, was die Bits zu bedeuten haben. Tw. sind es wohl nur mehrfach vorhandene Funktionen bzw. im attiny nur einfach vorhanden. Hab ich geflucht....
Aber so lernt man dazu ::)
Kannst ja mal gucken, ob Du mit der beigefügten Fassung schon was anfangen kannst/möchtest.
Grüße Markus
So, ich gebs wohl erst einmal auf mit Lacrosse >:( Ich kann mittlerweile problemlos IT V3 senden. Wird am CUL mit a-culfw und dem RFXTRX auch empfangen und entschlüsselt. Aber das Lacrosse zeigt sich nirgends. Habe mittlerweile verschiedene firmwares ausprobiert, u.a. die 1.66 im Original, aber nix kommt an. Hab keine Idee mehr, woran es liegen könnte. Mehrere Werte zu senden hätte mir besser gefallen, als nur ein einfaches an oder aus mit IT-Protokoll :(
Ähm, letzte blöde Idee: Lacrosse ist doch wohl autocreate-fähig ?
Grüße Markus
Hallo Markus,
wie gesagt mit "autocreate" + CUL433 (nicht a-culfw) kein Problem bei mir. Hab jetzt einige Sensoren am "funken".
Hast Du evtl. Probleme mit den Fuse-Einstellungen des ATtiny. Wenn Du da falsch liegst,
dann geht natürlich im Timing auch nichts ... ;)
Meine Standalone Tinies (also nicht Digispark) laufen mit 8 MHz internal Clock - Fuse gesetzt.
Die Digispark-Dinger laufen mit 16,5 MHz mit einer PLL-Clock-Einstellung und die "divide by 8" abwählen nicht vergessen!
Du kannst das Timing auch prüfen, wenn Du mal einen Portpin toggeln lässt (Intervall z.B. delay(2000) ) dann kannst Du das ja kontrollieren.
Hast Du in der LaCrosse.cpp auch die richtige LaCrosseID gesetzt/definiert?
Grüße,
Jürgen
Hi Jürgen,
da hast Du mich aber jetzt wieder ordentlich verunsichert ;) Aber an die Fuses hatte ich auch schon gedacht. Hab also jetzt nochmal geprüft und tatsächlich L:0xE1. Also auf E2 gesetzt und wieder probiert. Nix. Mit meinem IT-Sketch probiert. Ging jetzt auch nicht mehr. Mit attiny85, 8MHz internal kompiliert und die Hex auf dem Rpi geflashed. Auch nix. Und nun verstehe ich wenigstens, was ich heute morgen noch in meinem digispark-Thread zum Besten gab, nicht wissend, wie der Zusammenhang ist: die L-fuse muss mit dem gewählten Board/Taktfrequenz fürs kompilieren übereinstimmen, sonst klappt das Timing nicht. Also müsste L:0xE1 stimmen, wenn ich mit digispark 16,5 kompiliere, was ja durch das Funktionieren mit IT-V3 bestätigt wird. Warum nur nennen die das 16,5 und nicht 16 ?
Aus dem Internet hab ich "toggelt der DigiSpark schnellstmöglich, aber an dem Pin liegen (bei 8 MHz Prozessortakt) nur schlappe 62 kHz an, weil das Toggeln 2 * 8 µs dauert" als Information. Also ein grundsätzliches Problem des digispark ? Eher nicht, denn die kleinste Pulslänge ist beim IT_V3 260 µs und Lacrosse sogar 500.
Jetzt widme ich mich erst mal meinen Projekten, aber irgendwann gehe ich der Ursache auf den Grund. Fazit bleibt für mich: Für einen µC Anfänger ist es besser mit Steckbrett und ISP zu beginnen :'(
Yep, oder man hat Spaß an Suchen ...
Ohne passendes "Werkzeug" geht halt nichts ... ;)
Falls Du 2 Arduinos hast -> xOszillo mal den Sende/Tx pin checken.
Vielleicht liegt das Problem bei Dir ganz woanders? Dallas-Sensor z.B. ?
http://hackaday.com/2011/05/21/xoscillo-turns-arduino-in-an-oscilloscope/ (http://hackaday.com/2011/05/21/xoscillo-turns-arduino-in-an-oscilloscope/)
Scopino .. besser (https://sourceforge.net/projects/scopino/)
http://physudo.blogspot.de/2013/08/arduino-als-logic-analyzer.html (http://physudo.blogspot.de/2013/08/arduino-als-logic-analyzer.html)
Ok, Windows, könnte aber auch unter dem RASPi (Mono) gehen.
Mal schauen ob ich Dir fürs WoE ein Compile machen kann ... (;-))
Dabei stößt man wiederum auch auf das hier: arduino-i2c-sniffer (http://hackaday.com/2011/05/21/arduino-i2c-sniffer/)
I C H g l a u b e s n i c h t ! ! ! ! !
Nachdem mein Projekt auch nicht so recht wollte, hab ich natürlich den digispark im Verdacht. Also noch mit L:0xE2 und in der IDE mit "Digispark - 8 MHz ohne USB" geflashed. LED leuchten geht, IT-V3 geht,nur Lacrosse geht nicht. Abweichung bei einer min. narcolptics war ca. +8%. Guck ich zum 1.000ten mal in den Lacrosse-Code
Zitat#include <Arduino.h>
#include "LaCrosse.h"
#ifndef PIN_SEND
#define PIN_SEND 2 //set TX to Arduino-D4 on PIN 3
#endif
und weil ich im main
Zitat#include "Narcoleptic.h"
#include "LaCrosse.h"
#define TX_433_PIN 1 // Pin 6 = PB2
#define PIN_SEND TX_433_PIN //--- where digal pin 433 Sender is connected PB0 on ATtiny-85 pin 5 = PB0
stehen hab, ändere ich im Lacrosse die Pin_SEND auf 1. Den Gedanken hatte ich schon zig mal, aber immer wieder verworfen, weil für mich doch eindeutig der Sendepin auf 1 gesetzt ist und im Lacrosse doch nur überschrieben wird, wenn noch nicht definiert. Pustekuchen. Lacrosse funktioniert und vorher hab ich wohl immer über PB2 gesendet. Hab ich da was falsch am Programmcode verstanden/interpretiert ? :-\
Außerdem kann ich nun klarer Aussagen treffen zum digispark und timing treffen. Hatte vorher nachgelesen und festgestellt, dass der attiny85 über den USB auf 16,5 MHz kalibriert wird. Nun: Neben der 8MHz-Variante funktioniert auch die 16,5MHz-Variante mit L:0xE1 problemlos. Der über digspark geflashte attiny auch problemlos ohne digispark an Stromquelle != USB. Meine Herren, was für eine Geburt ::)
Nun meine 2. Frage: Interessant im Lacrosse-Code fand ich ja die Berechnung der Quellspannung. Wird bei mir mit 0,2 übertragen. Was soll mir das sagen ?
Ah und noch ne Info: der RFXTRX empfängt mit eingestelltem Lacrosse-Protokoll: nix. Der CUL-V3 sowohl mit culfw 1.66, als auch a-culfw 1.21
Grüße Markus
ZitatHast Du in der LaCrosse.cpp auch die richtige LaCrosseID gesetzt/definiert?
.. und auch den Portpin ? :-[ Ok, mia Culpa.
Manche Dinge setzt man einfach als gesetzt voraus, was aber wohl nicht immer und bei jedem klappt...
Betriebsspannung: nimm mal den Code aus dem Bodenfeuchtesensor, der funktioniert sehr gut und ist schon länger bei mir im Betrieb....
Quintessenz: Nicht immer geht nur Copy&Paste :-\ und Code verbessern und hier wieder einstellen ;)
Bei Gelegenheit schau ich noch mal über den Code drüber und versuche die "Hürden" zu glätten ...
Jürgen
// -------------------------------------------------------------------- -
//--- Helpers
//---------------------------------------------------------------------
long readVcc(void)
{
//--- read 1.1V reference against AVcc
//--- set the reference to Vcc and the measurement to the internal 1.1V reference
#if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ADMUX = _BV(MUX5) | _BV(MUX0);
#elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
ADMUX = _BV(MUX3) | _BV(MUX2);
#else
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#endif
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA, ADSC)); // measuring
uint8_t low = ADCL; // must read ADCL first - it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high << 8) | low;
/***************************************************************************************
* Berechnung/Skalierung mit manueller Messung der Betriebsspannung:
*
* internal1.1Ref = 1.1 * Vcc1 (per voltmeter) / Vcc2 (per readVcc() function)
* = 1.1 * 5126 / 5258 => 1.09 ==> 1.09*1023*1000 = 1097049
****************************************************************************************/
result = 1042494L / result;
//result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
//result = 1097049L / result; // korrigierter Wert bei 3V3 muss fuer jeden Controller bestimmt werden, obiger Wert scheint allgemeiner zu sein.
return result; // Vcc in millivolts
}Schaue Dir dazu aber auch die UserReading-Transformation dazu an ...
Hier die "ohne" Userreading-Variante:
//--- Betriebsspannung auslesen
vcc_reading = readVcc();
//float controllerVCC = 1.1 * 1023 / vcc_reading;
float controllerVCC = vcc_reading / 1000.0; // mV in Volt
LaCrosse.t = float(bodenfeuchte)/1000;
LaCrosse.sendTemperature();
LaCrosse.sleep(1); //--- 1 second, no power-reduction! see impact on powersave
LaCrosse.h = controllerVCC; //--- alias humidity;
LaCrosse.sendHumidity();
ZitatAh und noch ne Info: der RFXTRX empfängt mit eingestelltem Lacrosse-Protokoll: nix. Der CUL-V3 sowohl mit culfw 1.66, als auch a-culfw 1.21
Also doch ... (;-))
RFXTRX habe ich nicht, deshalb auch keine Aussage dazu ...
Hab den Bodenfeuchte-Thread 3mal rauf und runter. Wo kann ich mir denn das ominöse Userreading ansehen ?Hab jetzt nur noch Humidity=03.3 bei berechnetem result = 907431L / result; in read_Vcc() und float controllerVCC = vcc_reading / 1000.0; :-[
Kennst Du die FHEM SuFu - Suchfunktion?
Dort:
https://forum.fhem.de/index.php/topic,56660.msg482785.html#msg482785 (https://forum.fhem.de/index.php/topic,56660.msg482785.html#msg482785)
Ähhhm,
erst Bodenfeuchte-Sensor, jetzt Luftdruck
und was hat das Luftdruck-Userreading nun mit Vcc zu tun ? Was hab ich übersehen oder nicht verstanden ?
ZitatWas hab ich übersehen oder nicht verstanden ?
Beides ... :) ;) :D
Was genau geht denn bei dir nicht ?
Auslesen am Attiny/Digispark funktioniert ?
Die Spannung kann eigentlich nur per eigenem Sensor übertragen werden und dann als Temperatur oder Feuchte.
Ich lasse das einfach als Temperatur laufen, so wie sie aus dem Attiny raus kommt, 3,5 Grad C und das ist dann meine Spannung.
Oder das Lacrosse Protokoll kann das und macht das anders...weiß ich nicht, wenn ja, meinen Text einfach ignorieren ;D
EDIT:
@juergs
Ich habe das per sleep und watchdog gemacht.
Also ist das ja eigentlich egal, ob ich eine Library wie Nacroleptics (was für ein Name!) oder eben "von Hand".
Benutze die längste Zeit und den höchsten Modus PWR_DOWN.
Ist die Zeit vorbei, wird sleep() direkt wieder aufgerufen. Das sind dann nur millisekunden (wenn überhaupt) die der Attiny dann wieder wach ist.
Da die Zeit limitiert ist auf 8 Sekunden, wird das die Library sicher auch so machen.
@Ardupino
ich glaube er bekommt noch keine Werte überhaupt geliefert.
Das Problem: LaCrosse wird ja benutzt um TEMP+HUM Werte zu übertragen.
Die liegen meist im Bereich 0..100 Grad/% etc...
ReadVcc liefert den Wert in mV als uint z.B. 5V sind 5000mV, dass passt natürlich nicht ins Protokoll.
Dann muss man skalieren, am besten mit float-cast und z.B. einer Division durch 1000.
Das kann man dann per UserReading, wenn man es braucht, wieder zurückbiegen.
Wie ich es z.B. beim Luftruck (ca. 700...1200 mBar) gemacht habe.
Ebenfalls sind negative Werte zu vermeiden, das geht mit Offset-Addition vor dem Versenden und hinterher in FHEM wieder zurückwandeln.
Also eigentlich recht einfach, wenn man weiß wie es geht ... :D
Aber im Ernst, auch bei mir kann sich mal ein Fehler im Code einschleichen, den kann man ja verbessern ...
Außerdem habe ich ja mehrere Sensoren umgesetzt und bei jeden Projekt kommt immer ein Stückchen mehr
an Funktionalität dazu. Das ist aber eigentlich normal.
Man darf aber nicht den Fehler begehen, nur auf eine Version zu schauen,
man muss wie so oft in der IT auch mal rechts und links der Autobahn schauen ... 8)
Vor allem darf man nichts als endgültig gesetzt ansehen.
Das liegt natürlich auch ein "kleines" bisschen an der Erfahrung die man damit hat....
und wie man damit umgehen kann.
Grüße
Jürgen
Zitatich glaube er bekommt noch keine Werte überhaupt geliefert
ich bin er ? Ich schrieb doch
ZitatHumidity=03.3
::)
ZitatDa die Zeit limitiert ist auf 8 Sekunden, wird das die Library sicher auch so machen.
tut sie. Hat aber weitere Optionen über power_down hinaus, wie z.B. BOD abzuschalten. Wenn ich so weit bin, beschreibe ich das ausführlicher in einem separaten Thread.
Grüße Markus
Ja ja, FHEM ist so ne Sache. Recht komplex und kompliziert. Dafür offener...sagen alle. Ich wollte auch schon alles hin schmeißen.
Vielleicht ist das ja besonders toll für Programmierer, ich weiß es nicht.
BOD hab ich auch aus :P
War am überlegen das auf 2,7V zu setzen, aber wenn ich jetzt irgend wann mal das Alarmanlagen Modul am laufen habe (glaube ich fast nicht dran), lasse ich mir ne Nachricht über WhatsApp senden, dann vergesse ich das nicht mehr und dann nudelt der Digispark mir den Akku auch nicht mehr auf unter 2V leer (was im übrigen schädlich für LiIon Akkus ist).
03.3 sieht doch sehr nach 3.3V aus ?
Es sei denn du betreibst den mit ner anderen Spannung :o
Schau mal, ob der Wert von Anfang an falsch ist, oder erst nach dem 2. Senden.
Wenn von Anfang an, dann zeig mal den Teil im Sketch der bei dir diese Vcc Auslesung macht. Dann könnte man mal vergleichen.
long readVcc() {
// Read 1.1V reference against AVcc
// set the reference to Vcc and the measurement to the internal 1.1V reference
#if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ADMUX = _BV(MUX5) | _BV(MUX0);
#elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
ADMUX = _BV(MUX3) | _BV(MUX2);
#else
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#endif
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuring
uint8_t low = ADCL; // must read ADCL first - it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high<<8) | low;
result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
return result; // Vcc in millivolts
}
Und das hier noch in die LOOP:
long voltage = readVcc();
double decimalVcc = doubleMap(double(voltage),0,6000,0,6);
decimalVcc ist dann schon die richtige Ausgabe wie z.B. 3,8V
@Ardupino
Zitatdann nudelt der Digispark mir den Akku auch nicht mehr auf unter 2V leer (was im übrigen schädlich für LiIon Akkus ist).
Hast du mal den Stromverbrauch mit Deinen PowerSave-Einstellungen gemessen?
Evtl. müsstes Du den Spannungsregler 78L05 oder 78M05 auf dem Digispark (http://www.instructables.com/id/Digispark-DIY-The-smallest-USB-Arduino/step4/Digispark-schematic/) gegen etwas effizienteres (MCP1702) (http://www.microchip.com/wwwproducts/en/en028178) tauschen.
Stichwort (Quiescent Current).
Die 78x05er haben schon einen hohen Ruhestrom, wenn der im > 2 mA Bereich ist hast Du schon verloren. Das wäre wohl für den Batteriebetrieb kontraproduktiv.
Gut ist, wenn er im Sleep-Modus < 10uA kommt.
Die LaCrosse-Lib hat auch Repetitions implementiert und sendet, glaube ich je nach Konfiguration 3..5 Mal den Wert raus.
Dazischen liegen Sekunden Pause. Da könnte man auch Power sparen, wenn man die Anzahl der Sendungen verringert.
Je nach Reichweite des Empfängers und Störung durch andere Sensoren würde das gehen.
Zitatdouble decimalVcc = doubleMap(double(voltage),0,6000,0,6);
Wenn es nicht auf Geschindigkeit ankommt ist das auch ok. :)
Was hattest Du gegen den impliziten Cast?
Jürgen
Zitat von: juergs am 09 November 2016, 20:41:41
@Ardupino
Hast du mal den Stromverbrauch mit Deinen PowerSave-Einstellungen gemessen?
Also ich habe gerade noch mal gemessen (einfaches Multimeter). Beim starten habe ich ca. 9mA, wenn er dann im Sleep ist, habe ich 2,5mA.
Ich benutze direkt den USB Stecker, damit (so dachte ich mir) umgehe ich ja den 7805, da dieser ja dann gar nicht verwendet wird.
Deine 10uA ja doch erheblich weniger.
Ich hatte damals die sleep Funktion so weit angepasst, das noch alles funktioniert.
Ich benutze ja auch noch einen Eingang als Interrupt, der muss deshalb an bleiben.
Deshalb denke ich eher nicht, das es bei mir am Sketch liegt, sondern wie du geschrieben hast, am 7805 ?
Ich bau den gleich mal aus, brauche den eh nicht.
Zitat
Was hattest Du gegen den impliziten Cast?
Verstehe nicht was du meinst, immer diese Fremdwörter :)
Ich hatte die Vcc Messung wie gesagt schon vorher in meinem Sketch. Das habe ich mir aus dem Internet so zusammengesucht und es so gelassen.
EDIT:
So, habe den 7805 entfernt, liege jetzt bei 0,78mA !
Zu meinen 2,5mA schon mal eine Steigerung.
Sehe im Schaltplan aber noch eine Diode und einige Widerstände an PB3 und PB4. Außerdem noch zwei Z Dioden gegen GND.
Mein Akku hat 3,67V der Attiny bekommt davon nur noch 3,46V
Das war auch die Differenz die ich zwischen Messung am Akku und Messung durch den Attiny selber hatte.
Dachte das wären Ungenauigkeiten. Also sind diese Digispark eher nicht so gut wenn man mit Batterien arbeitet.
Aber ok, durch deinen Tipp hat sich das doch schon um einiges gebessert.
Das bleibt nun mal so, wenn ich nun FHEM soweit habe das ich das ganze auch nutzen kann, und weitere Sensoren benötige,werde ich nur den "nackten" Attiny85 verwenden, mal sehen.
EDIT:
Habe sogar "nur" noch 0,59mA , hatte vergessen, das wenn die Tür/Fenster zu ist, das ganze weniger verbraucht als wenn das Fenster oder die Tür auf ist, wegen dem verwendeten PullDown am Reed Kontakt.
ZitatAlso sind diese Digispark eher nicht so gut wenn man mit Batterien arbeitet.
Ja, darauf wollte ich hinaus ;)
Du kannst evtl. die "Verbraucher" mit einem 2N7002 von Vcc abhängen, dann fließt kein Ruhestrom, sondern nur dann,
wenn Du es brauchst und einschaltest. Das mach ich jetzt z.B. mit meinem Dallas 18B20.
Mit angemessener "Vorwärm-Phase" natürlich. bei dem 1K5 USB-Pullup- Widerstand fließt auch noch Strom ....
USB brauchst Du ja nur einmal zu programmieren dann ist es funktionslos ....
Aber für andere Typen von Anwendungen sind die Digispark-Teile ja wiederum besser geeignet und
zwar dann wenn sie vom Bus gespeist werden ;)
Hallo Jürgen,
hast du ein Schaltungsbeispiel, wie du die Dallas 18B20 mit dem 2N7002 von VCC abhängst?
Und wie schaltest du ihn wieder ein? Wird dadurch ein zusätzlicher Pin benötigt?
Gruß
Hartmut
PS: Mein Fenstersensor liegt jetzt bei 1,04 V und funktioniert immer noch.
Zitat von: rippi46 am 11 November 2016, 10:41:11
PS: Mein Fenstersensor liegt jetzt bei 1,04 V und funktioniert immer noch.
Oh das ist echt wenig. Was kommt denn am StepUp raus ? Bestimmt weniger als 5V ?
Ich habe mir gestern noch schnell irgend was abgeschossen.
Das die Digispark 2 Pins für USB benutzen, wusste ich. An einem habe ich den Reed Kontakt.
Habe gestern noch was am Sketch geändert und vergessen, den Magneten weg zu legen, als ich das Programm neu übertragen habe.
Durch den Reed wird der Pin auf GND geschaltet, was (nach 3x) dann wohl doch nicht so gut war.
Nun ja, Programmieren geht noch, benutze jetzt einen anderen Pin für den Reed und fertig ;D
Hallo ArduPino,
Ich betreibe den Fenstersensor mit einem Eneloop AAA Akku und einem StepUp 3,3V.
Zum Senden wären natürlich 5V besser. Aber das war jetzt mein erster Fenstersensor.
Ich sende all 5 Minuten Temperatur und und die Spannung des Akku. Wenn in der Zwischenzeit das Fenster geöffnet oder geschlossen wird, sende ich auch noch den Status des Fensterkontakts.
Das Ganze läuft jetzt seit ca 5 Wochen.
Gruß
Hartmut
ZitatGut ist, wenn er im Sleep-Modus < 10uA kommt.
Das hast Du so aus dem Datenblatt, oder ? Ich komme mit avr-sleep auf 0,28 mA und vollausgereiztem Narcoleptic(nur noch WDT) mit nem "nackten" 85er auf 0,26 mA :'( Was hast Du für Werte ?
Grüße Markus
@rippi46, hallo Hartmut
anbei mein "Prototyp" :-[ -> bin auch noch am Experimentieren, aber diese Schaltung geht.
Dallas Sensor per Portpin mit 2N7002 (http://www.reichelt.de/2N-Transistoren/2N-7002-SMD/3/index.html?ACTION=3&LA=446&ARTICLE=41142&GROUPID=2879&artnr=2N+7002+SMD&SEARCH=2N7002) geschalten: High = EIN.
Spart, nach Datenblatt, im Standby noch mal 1mA ein.
wenn man genauer darüber nachdenkt und das Datenblatt des Sensors konsultiert ,
liefert der Port des '85ers bei 3V3 glaube ich 5 mA, @5V 10mA, vieleicht reicht das schon aus, um ihn zu betreiben ???
(Mal nachschauen ...)
Ui, Sensor knapp 4 mA ... müsste man mal probieren ;) FET -ist auf alle Fälle sicherer.
Bei Vcc = 2.86Volt macht der Sensor aber schlapp und will nicht mehr ...
Bei einer leereren 3V -Batterie stößt das schnell an die Grenze.
Grüße,
Jürgen
PS: Kabeldicke, viele benutzen teilweise viel zu dicke Litze -> schwer zu löten. Tipp: ein altes 80 poliges P-ATA PC-HD-Kabel auseinander nehmen.
Hat einen CU-Kern und lässt sich prima verarbeiten und abisolierenund ist nicht so "dick", so 0,05 mm Durchmesser. (was die Bastelkiste so hergibt ...)
Stromverbrauch beim Senden. ;)
Ok, das Multimeter ist ein bisschen lahm, ist nicht hypergenau, zeigt aber das Wesentliche.
Zitat von: rippi46 am 11 November 2016, 17:16:00
Hallo ArduPino,
Ich betreibe den Fenstersensor mit einem Eneloop AAA Akku und einem StepUp 3,3V.
Zum Senden wären natürlich 5V besser. Aber das war jetzt mein erster Fenstersensor.
Ich sende all 5 Minuten Temperatur und und die Spannung des Akku. Wenn in der Zwischenzeit das Fenster geöffnet oder geschlossen wird, sende ich auch noch den Status des Fensterkontakts.
Das Ganze läuft jetzt seit ca 5 Wochen.
Gruß
Hartmut
Ich sende auch nur mit 3,6V eben LiIon Akku.
Mit der Reichweite komme ich so ganz gut zurecht, hab nur ein Kabel am Sender, keine richtige Antenne. Kabel hat aber die richtige Länge (glaube 17cm?) für 433Mhz.
Habe nun auf eine Minute reduziert ! Vorher habe ich ca. 30 Sekunden gehabt. Das war aber noch aus der Testphase, damit ich mal Werte bekomme.
Mein Log ist über 10MB groß :) Kann man das eigentlich einfach so löschen und es wird ein neues angelegt ?
Werde mal sehen ob ich das noch auf 2 oder 3 Minuten setze. 5 ist mir etwas zu viel...obwohl für Temperatur eigentlich auch noch egal.
Der Fensterkontakt arbeitet eh über Interrupt, bedeutet, das der Attiny ja sowieso direkt aufwacht und direkt den Code für Fenster auf oder Fenster zu, sendet.
Würde bestimmt noch einiges an Akku Kapazität sparen.
Große Logfiles machen FHEM etwas langsamer im Seitenaufbau. Bei mir sind die Files auch etwas größer,
stört aber noch nicht richtig. Wenn Du FHEm runterfährst kannst Du sie ja umbenennen, wenn so geht -> dann löschen.
hier (http://blog.gestreift.net/2015/04/fhem-temperatur-fuehlen-mit-jeelink/)
ZitatWie schon im Artikel über die Max!-Thermostate geschrieben, muss auch hier das Logging etwas eingeschränkt werden. Per Gerät ist mittels ,,event-on-change-reading" und ,,event-min-interval" dafür zu sorgen, dass zwar permanent, aber nur das notwendige geloggt wird.
Hier noch eine weitere Möglichkeit der Stromversorgung:
solar-pb-akku-lader-mit-attiny13/ (http://blog.thomasheldt.de/solar-pb-akku-lader-mit-attiny13/)
Bin jetzt auf 5µA runter ;) Die werden vom WDT verursacht. Mein Problem war, dass ADC nicht abgeschaltet hatte, obwohl das eigentlich im power_down so sein soll. Machte also 260 µA !!. Schau ich mir noch einmal in Ruhe an.
Ohne WDT, also mit reinem Interrupt-wake-up läuft mit 0 µA(also mein Schätzeisen zeigt nix mehr an). Ideal für meine geplanten Postmelder ;)
Grüße Markus
Ach soooooo :) :) :) :) :) :) :) :) :) :) :) :)
Für den Fensterkontakt könnte ich mir diese Bauform ebenfalls Gehäuse-nah vorstellen:
https://www.reichelt.de/?ARTICLE=27688&PROVID=2788&wt_mc=amc141526782519998&gclid=CKf8qqrDpdACFUVmGwod8bsHHA (https://www.reichelt.de/?ARTICLE=27688&PROVID=2788&wt_mc=amc141526782519998&gclid=CKf8qqrDpdACFUVmGwod8bsHHA)
oder über einen Hallsensor mit Neodym-Magnet:
TLE4905L, ein Unipolar-Typ: TLE4905L (http://cdn-reichelt.de/documents/datenblatt/B400/TLE4905L_TLE4935L_TLE4945L_TLE4935-2L%23SIE.pdf)
Das würde die Bauform wesentlich verkleinern ;)
Zitat von: KölnSolar am 12 November 2016, 19:27:44
Bin jetzt auf 5µA runter ;) Die werden vom WDT verursacht. Mein Problem war, dass ADC nicht abgeschaltet hatte, obwohl das eigentlich im power_down so sein soll. Machte also 260 µA !!. Schau ich mir noch einmal in Ruhe an.
Ohne WDT, also mit reinem Interrupt-wake-up läuft mit 0 µA(also mein Schätzeisen zeigt nix mehr an). Ideal für meine geplanten Postmelder ;)
Grüße Markus
Mit deinem Digispark oder eigenbau Attiny85?
Also ADC schalte ich (eigentlich) ab. Wenn denn der code dafür stimmt:
void system_sleep() {
GIMSK |= _BV(PCIE); // Enable Pin Change Interrupts
PCMSK |= _BV(PCINT4); // Use PB4 as interrupt pin
cbi(ADCSRA,ADEN); // switch Analog to Digitalconverter OFF
set_sleep_mode(SLEEP_MODE_PWR_DOWN); // sleep mode is set here
sleep_enable();
sei(); // Enable interrupts
sleep_mode(); // System sleeps here
sleep_disable(); // System continues execution here when watchdog timed out
//sbi(ADCSRA,ADEN); // switch Analog to Digitalconverter ON
}ADC schalte ich nun sogar erst nach dem letzten sleep(); an. Habe mehrere hintereinander um die Zeit zu verlängern.
Habe aber wie gesagt ca. 0,6 mA mit meinem Digispark. Wenn du den auch verwendest, denke ich liegt es bei mir an was anderem. Hatte die verschiedenen Komponenten im Verdacht.
ZitatMit deinem Digispark oder eigenbau Attiny85?
Ich hab doch das digispark-Derivat mit Dip-Sockel ;) Gemessen hab ich dann "außerhalb" des Digispark. Wüßte jetzt auch gar nicht, wie ich mit Digispark messen kann, da der doch am USB hängt. Wie machst Du das denn ?
Zu ADC: Ich hab ja die "Vollversion" von narcoleptic aus dem Inet. Dort gibt es ein disable-ADC-Funktion, welches das PRADC im PRR-Register setzt. Das führte aber genau zu dem Problem. Ich mach es jetzt explizit über ADEN, so wie Du. Daran sollte es bei Dir also nicht liegen :(
Grüße Markus
//----------------------------------------------------
void NarcolepticClass::sleep(uint8_t wdt_period)
{
wdt_enable(wdt_period);
wdt_reset();
WDTCSR |= _BV(WDIE);
cbi(ADCSRA, ADEN); //20160508_juergs added, switch Analog to Digitalconverter OFF
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode(); <-------- hier bleibt der ATtiny im Code stehen, bis er wieder aufwacht.
wdt_disable();
sbi(ADCSRA, ADEN); //20160508_juergs added, switch Analog to Digitalconverter ON
WDTCSR &= ~_BV(WDIE);
}
Hallöchen, war doch die ganze Zeit bei mir in der Lib drin. ;)
Grüße,
Jürgen
Zitat von: KölnSolar am 13 November 2016, 16:09:54
Ich hab doch das digispark-Derivat mit Dip-Sockel ;) Gemessen hab ich dann "außerhalb" des Digispark. Wüßte jetzt auch gar nicht, wie ich mit Digispark messen kann, da der doch am USB hängt. Wie machst Du das denn ?
Ich betreibe den Digispark mit einem 3,6V LiIon Akku, dafür gibt es ja auch Batteriehalter.
Daran habe ich mir eine USB Buchse gelötet, so kann ich den Digispark schnell entfernen und event. am Programm was ändern...und auch den Strom messen.
Also ein Stück Papier zwischen die Kontakte Batterie zu Halter und da dann gemessen ;)
LowPowerLib
http://www.rocketscream.com/blog/2011/07/04/lightweight-low-power-arduino-library/ (http://www.rocketscream.com/blog/2011/07/04/lightweight-low-power-arduino-library/)
Hey, hab grade den Thread gefunden.
Ich hab sowas auch gebaut, also Attiny, 433Mhz Funkchip, Reed/Kupfer Kontakt.
Verbrauch bei geschlossenem Fenster 4 uA, bei offenem Fenster 6uA.
Hatte erst den internen PULL-UP Widerstand verwendet, der verbraucht aber zu viel bei offenem Fenster bei mir.
Interrupt hat bei mir das Aufwachen nicht zuverlässig funktioniert, also wache ich 1x pro Sekunde auf und checke den Status. Bei Änderung wird dann gesendet.
Alles im Intertechno Protokoll, eine CR2032 sollte n paar Jahre reichen nach großben Berechnungen.
Habe im Garten sowas auch als Bewegungsmelder - funzt mittlerweile über ein Jahr ohne Probleme.
Sketch:
#include <NewRemoteTransmitter.h>
#include <avr/sleep.h>
#include <avr/wdt.h>
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
byte REED_PIN=2;
byte SEND_PIN=3;
boolean Status=false;
NewRemoteTransmitter transmitter(50630001, SEND_PIN, 290, 2); // 300us Pulslaenge an PIN 3
void setup() {
pinMode(REED_PIN, INPUT);
setup_watchdog(6); // approximately 1 seconds sleep
cbi(ADCSRA,ADEN); // switch Analog to Digitalconverter OFF
set_sleep_mode(SLEEP_MODE_PWR_DOWN); // sleep mode is set here
}
void loop() {
system_sleep();
}
void system_sleep() {
sleep_enable();
sleep_mode(); // System sleeps here
sleep_disable(); // System continues execution here when watchdog timed out
//sbi(ADCSRA,ADEN); // switch Analog to Digitalconverter ON
}
// 0=16ms, 1=32ms,2=64ms,3=128ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec
void setup_watchdog(int ii) {
byte bb;
int ww;
if (ii > 9 ) ii=9;
bb=ii & 7;
if (ii > 7) bb|= (1<<5);
bb|= (1<<WDCE);
ww=bb;
MCUSR &= ~(1<<WDRF);
// start timed sequence
WDTCR |= (1<<WDCE) | (1<<WDE);
// set new watchdog timeout value
WDTCR = bb;
WDTCR |= _BV(WDIE);
}
// Watchdog Interrupt Service / is executed when watchdog timed out
ISR(WDT_vect) {
if (digitalRead(REED_PIN)==LOW && Status==true){
Status=false;
transmitter.sendUnit(6, false);
//pinMode(REED_PIN, INPUT);
}else if (digitalRead(REED_PIN)==HIGH && Status==false) {
Status=true;
//pinMode(REED_PIN, INPUT_PULLUP);
transmitter.sendUnit(6, true);
}
}
Hi, schöner Beitrag.
Verräts Du noch, mit welchem Transceiver Du empfängst und was sich dort #include <NewRemoteTransmitter.h> verbirgt. Ich interessiere mich ja fürs IT senden.
Grüße Markus
Hey,
ja, das ist die Library https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home (https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home)
Ich habe sie noch etwas modifziert (Akzeptanzniveaus für Empfang z.B.). Damit ließen sich noch ein paar "Prozent" mehr rausholen.
Wichtig ist, dass man die NEWRemoteLibrary verwendet.
Was ich besonders tolle finde ist, dass es auch Temp Sensoren und Empfänger gibt, die in FHEM als Hideki erkannt werden.
Und, es gibt auch Möglichkeiten zum Repeater-Bau, sowohl für IT als auch für Temp/Hum.
Somit läuft bei mir zu Hause jetzt alles tiptop, komplett selbstgebaut.
KLASSSSSSEEEEEEE.
Genau eine solche Lib, mit der man IT V3 in Bastelprojekten verschicken kann, hab ich lange gesucht !!! Nicht nur, dass ich Lacrosse als ziemliche Krücke für Schalter empfunden hab, sondern mein RFXTRX, den ich produktiv einsetze, hatte das Protokoll aus unerfindlichen Gründen nicht erkannt, obwohl mein ausgemusterter CUL433 alles empfing.
DANKE
kein Problem, falls Du noch Fragen hast. Ich experimentiere auch ständig mit allem möglichen rum.
Zitat von: meggih am 21 November 2016, 10:01:31
Hey, hab grade den Thread gefunden.
Ich hab sowas auch gebaut, also Attiny, 433Mhz Funkchip, Reed/Kupfer Kontakt.
Verbrauch bei geschlossenem Fenster 4 uA, bei offenem Fenster 6uA.
Hatte erst den internen PULL-UP Widerstand verwendet, der verbraucht aber zu viel bei offenem Fenster bei mir.
Interrupt hat bei mir das Aufwachen nicht zuverlässig funktioniert, also wache ich 1x pro Sekunde auf und checke den Status. Bei Änderung wird dann gesendet.
Mein Sketch ist bestimmt drei mal so lang !
Ich habe das auch per Interrupt gemacht, weil ich dachte dann könnte ich die Sleep Phase länger laufen lassen.
Dieser funktioniert bei mir aber ohne Probleme, scheint aber nichts zu bringen, was Verbrauch betrifft, wenn ich das hier so sehe.
Was braucht man denn an minimal Hardware außer Attiny85, Sender Modul ?
Hast du auch einen Kondensator zwischen GND und Vcc
Ach da sehe ich gerade das es ein reiner Türkontakt ist...ok...könnte man ja leicht erweitern.
Hallo,
ich hab den Thread Titel eben erst gesehen - ich dachte, es ginge nur um die Fensterkontakte.
ich hab als gleiche Art, Temp/Hum-Sensoren, Tür/Garagen-Kontakte und Bewegungsmelder. Entweder mit Akku/Batterie oder 5V-AC-DC Wandler, je nach Ort.
Dazu auch: Repeater für IT und Hideki, Dachbodenklappensteuerung mit Licht/Mikroschalter und altem Akkuschrauber mit Bandaufwickeln als Motor.
-Attiny85 + 100nF Kondensator
-433Mhz Sender und/oder Empfänger: http://www.ebay.de/itm/282162804057?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/282162804057?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT) meist so ein Set
Die billigen Sender sind aber auch gut. Jedoch taugen bei mir nur die "teuren" Empfänger was.
-Sensor/Aktor(z.B. Relais mit Transistor Vorschaltung)
Zahlen werden über das Hideki Protokoll gesendet (Temp/Hum/Batterie-Spannung = 5,53V -> 55,3 Grad)
Alle digitalen Zustände werden über das IT Protokoll gesendet (Sensoren, auf/zu, Garagentor auf/zu machen, etc)
Erfahrung: Externe Interrupts funktionieren bei dem Attiny nicht zuverlässig bei mir. Beim Fensterkontakt, der geschlossen zu ist, 1M-Ohm PullUp Widerstand verwenden, da der interne ca 100 uA zieht. Am besten funktioniert das Watchdog 1 sec Schlafen bei Fensterkontakten und Status checken. Bei Tempsendern das Maximum 8s schlafen, aufwachen, Variable hochzählen, wieder schalfen und dann alle 10 mins n Wert senden.
Lustig, die Library hatte ich mir schon vor `nem Monat aus dem Netz gesaugt. Da aber nicht auf Intertechno verwiesen war, hatte ich es erstmal liegen lassen, denn ich dachte, dass es irgendwas Eigengestricktes ist. :-\
Die Lib funktioniert perfekt. Hab sendDim getestet. Ganz simpel zu nutzen ;D Empfang sowohl im CUL, als auch RFXTRX.
@meggih: kann es sein, dass Deine Interrupt-Probleme daher kamen, dass Du in der Interrupt-Routine die komplette Verarbeitung machst ? Soll man ja eigentlich vermeiden, wie man immer wieder liest.
ZitatLustig, die Library hatte ich mir schon vor `nem Monat aus dem Netz gesaugt. Da aber nicht auf Intertechno verwiesen war, hatte ich es erstmal liegen lassen,
Ging mir auch so..... :D
@meggih
Der Verweis
Zitatdie in FHEM als Hideki erkannt werden
ZitatSupports Sending and receiving signals from and to weather stations, made by Hideki Electronics.
These weather stations are sold under the brand names Cresta, Mebus, Irox, Honeywell and RST.
They have a remote outdoor 3 or 5 channel sensor for temperature and humidity.
More expensive variants also support a rain-sensor, anemometer and UV-sensor.
Ist ja sehr interressant. Ich schaue mir mal die Unterschiede zum Lacrosse-Protokoll an.
Interessant finde ich auch die Idee des IT-Reppeaters bei zu grossen Distanzen zwischen Sender + Empfänger.
Die Module scheinen etwas teurer zu sein, aber die Abschirmung scheint es wohl auszumachen...
Die 100nF am ATTiny scheinen mir etwas dünn, aber besser als keiner.
Meine 100uF zu hoch ... 1 uF scheint mir ausreichend zu sein.
Ist eher gedacht, das TX-Modul zu unterstützen ....
Ich habe auch noch ein passendes Thema zu 433+Powersave+Protokoll gefunden:
433MHz (http://physudo.blogspot.de/search/label/433%20MHz) und jede Menge Tipps zu Sensoren (http://physudo.blogspot.de/search/label/Arduino)
@KölnSolar
ZitatEmpfang sowohl im CUL, als auch RFXTRX.
Benutze ich nicht. Das Protokoll, mit dem beide gehen, scheint aber nicht LaCrosse TX3 zu sein.
-> Umso besser, lohnt sich also mal anzuschauen ... ;)
Danke für die Tipps!
Grüße,
an alle.
Zitat von: KölnSolar am 21 November 2016, 17:05:41
@meggih: kann es sein, dass Deine Interrupt-Probleme daher kamen, dass Du in der Interrupt-Routine die komplette Verarbeitung machst ? Soll man ja eigentlich vermeiden, wie man immer wieder liest.
Weiß nicht mehr genau, woran es lag, ich meine daran, dass er nicht zuverlässig aufgewacht ist. Das Problem hatte ich irgendwie schon öfter. Leider ist das Datenblatt des Attiny85 so umfangreich, es gibt ja den PIN2 (INT0), der wohl ein "richtiger" Interrupt ist und dann noch andere Pins, die jeweils nur einen PCINT haben. Ich blick da noch nicht durch.
Ich bin aber durchaus bereit nochmal zu Testen, wär ja für nen Reed-Kontakt das effizienteste. Für n T/H-Sensor passt das ja mit dem Watchdog Timer.
LG
Ich hab PCINT genommen. Die reagieren ja auf alles, während man INT0 noch auf einen Zustand definieren muss. Im Testaufbau hat das bei mir bisher super geklappt(und Taster noch nicht einmal entprellt). Die Erklärung zu den Unterschieden find ich gut: http://www.avrfreaks.net/forum/whats-functional-difference-between-int-and-pcint
Klingt ja gut - ist Dein Attiny auch im Sleep-Mode?
Hast Du mal den Stromverbrauch bei offenem/geschlossenen Kontakt gemessen?
Und, kannst Du vllt hier mal Deinen Sketch posten? (Oder als PN)
LG
so, hab jetzt den hier https://forum.fhem.de/index.php/topic,61280.0.html für meine Antwort aufgemacht ;)
DANKE an alle denen ich mit meinen Nicht-Thermometer-Themen auf die Nerven gegangen bin :-[
Ich melde mich hier erst wieder, wenn es mir um ein Thermometer geht ;D
Grüße Markus
Hallo Ihr fleißigen Entwickler,
ich möchte mich bei Euch, aber insbesondere bei Jürgen für diese Super Idee & Lösungen bedanken.
Es hat mich zwar viel Lesezeit bei dem durcheinander in diesem Thread gekostet aber jetzt habe ich ein funktionierendes Thermometer hinbekommen. Läuft Super an der aktuellen a-culf 433 Version.
Diese kleinen Helfer sind super um die Temperaturen meiner Aquarien und Terrarien zu überwachen.
Vielen DANK dafür! :)
Ich verfolge schon gespannt auf die Drucksensor Version um eine Füllstandsanzeige für die Aquarien umzusetzen. :)
Um es weiteren Bastlern ein wenig zu vereinfachen nochmal wie ich es gemacht habe
Bauteil-Liste:
1x Attiny85-20pu
1x 18DS20 Temperatur fühler
1x Stück Lochrasterplatine
1x Batteriehalter für CR2032
1x Elko 1µF
1x Widerstand 4k7
1x Sender STX882
Alles günstig gleich für 5Stück über die Bucht in China besorgt, da ich Zeit hatte. (3-4Wochen)
Das Ganze nach Jürgens Plan Seite 2 #16 zusammengelötet.
Dann Jürgens Attiny85_Narcoleptic_LaCross_433MHz.zip Seite 2 #17 herunterladen.
Dazu noch die OneWire Bibliothek.
https://www.pjrc.com/teensy/td_libs_OneWire.html (https://www.pjrc.com/teensy/td_libs_OneWire.html)
Alles in ein Verzeichniss entpacken!
Zum flashen des Attiny85 habe ich mir die Arduino IDE 1.6.12 heruntergeladen und installiert.
ACHTUNG: Es scheint nur mit dieser Version zu gehen mit der 1.6.5 gabs Probleme beim flashen und mit der 1.8 auch.
Um den Attiny85 in die DIE einzubinden muß man wie hier beschrieben vorgehen:
http://fluuux.de/2015/08/attiny-support-unter-arduino-1-6-installieren/ (http://fluuux.de/2015/08/attiny-support-unter-arduino-1-6-installieren/)
Ich habe das ganze über den Arduino Uno (also ArduinoISP) auf einem Steckboard geflasht. Allerdings drauf achten, dass man ,, internal 8mghz clock ,, einstellt.
Beim Programm muss man dann eine eigene ID 1-127 (wenn ich das richtig verstanden habe) eintragen und schauen das die PIN fürs senden richtig belegt/programmiert sind.
Wenn alles geklappt hat und Batterie angeschlossen ist funkt das Teil sofort alle 5 Minuten (oder wie man es eingestellt hat)
Fhem legt sofort per Autocreate ein CUL_TX_(Eure ID) an und man kann einfach ein SVG Plot machen :)
Chris
Hallo Chris,
freut mich das es geklappt hat und Du Dir die Mühe gemacht hast es zusammenzufassen.
Na ja das mit dem Durcheinander ist da so eine Sache.... aber hier gibt es weitaus größere Threads ....
Es war ja etwas "agil" entstanden. :D
Allerdings mit den Arduino Versionen müsste ich noch etwas präzisieren...
Das Kompilieren sollte eigenlich auch auf den neueren Version ohne Probleme gehen.
Das Flashen über die Arduino-Ide wird da wohl eher das Problem sein....
Für Avrdude scheint gerade die Bitclock Einstellung sensibel zu sein, da die Controller auf 1MHz Taktfrequenz eingestellt sind
und die Standardeinstellung nicht verkraften. (siehe auch andere Threads...)
Ein Überblick über weitere Varianten gibt es
hier. (https://github.com/juergs?tab=repositories)
Grüße,
Jürgen
Ist ja Super der Link und die Bastelanreitze, die DHT22 Version ist schon in Planung! :)
Bodenfeuchte will ich auch mal machen, dies aber anders. Hab die Idee den DHT Sensor in ein kleines Rohr mit Sand einzubauen und dieses Rohr
an den Enden mit permeablen Membranen zu versehen. Dies dann im Balkonkasten vergraben, so sollte es möglich sein die Luftfeuchte der Erde
über das sich einstellende Gleichgewicht zu messen.
Gibt es eine Begrenzung (änlich wie bei LCD Display) wie lang die Zuleitungskabel vom Attiny zum Sensor sein dürfen?
Gruß Chris
Zitat von: Chris81 am 30 März 2017, 15:17:24
Hallo Ihr fleißigen Entwickler,
ich möchte mich bei Euch, aber insbesondere bei Jürgen für diese Super Idee & Lösungen bedanken.
Es hat mich zwar viel Lesezeit bei dem durcheinander in diesem Thread gekostet aber jetzt habe ich ein funktionierendes Thermometer hinbekommen. Läuft Super an der aktuellen a-culf 433 Version.
Diese kleinen Helfer sind super um die Temperaturen meiner Aquarien und Terrarien zu überwachen.
Vielen DANK dafür! :)
Ich verfolge schon gespannt auf die Drucksensor Version um eine Füllstandsanzeige für die Aquarien umzusetzen. :)
Um es weiteren Bastlern ein wenig zu vereinfachen nochmal wie ich es gemacht habe
Bauteil-Liste:
1x Attiny85-20pu
1x 18DS20 Temperatur fühler
1x Stück Lochrasterplatine
1x Batteriehalter für CR2032
1x Elko 1µF
1x Widerstand 4k7
1x Sender STX882
Alles günstig gleich für 5Stück über die Bucht in China besorgt, da ich Zeit hatte. (3-4Wochen)
Das Ganze nach Jürgens Plan Seite 2 #16 zusammengelötet.
Dann Jürgens Attiny85_Narcoleptic_LaCross_433MHz.zip Seite 2 #17 herunterladen.
Dazu noch die OneWire Bibliothek.
https://www.pjrc.com/teensy/td_libs_OneWire.html (https://www.pjrc.com/teensy/td_libs_OneWire.html)
Alles in ein Verzeichniss entpacken!
Zum flashen des Attiny85 habe ich mir die Arduino IDE 1.6.12 heruntergeladen und installiert.
ACHTUNG: Es scheint nur mit dieser Version zu gehen mit der 1.6.5 gabs Probleme beim flashen und mit der 1.8 auch.
Um den Attiny85 in die DIE einzubinden muß man wie hier beschrieben vorgehen:
http://fluuux.de/2015/08/attiny-support-unter-arduino-1-6-installieren/ (http://fluuux.de/2015/08/attiny-support-unter-arduino-1-6-installieren/)
Ich habe das ganze über den Arduino Uno (also ArduinoISP) auf einem Steckboard geflasht. Allerdings drauf achten, dass man ,, internal 8mghz clock ,, einstellt.
Beim Programm muss man dann eine eigene ID 1-127 (wenn ich das richtig verstanden habe) eintragen und schauen das die PIN fürs senden richtig belegt/programmiert sind.
Wenn alles geklappt hat und Batterie angeschlossen ist funkt das Teil sofort alle 5 Minuten (oder wie man es eingestellt hat)
Fhem legt sofort per Autocreate ein CUL_TX_(Eure ID) an und man kann einfach ein SVG Plot machen :)
Chris
Vielen Dank für die super Zusammenfassung. Sowas hab ich gesucht um die warmwassertemperatur im Speicher parat zu haben, ohne immer in den Keller zu laufen.
Habe mir mal den Plan aus #16 angeschaut. Jetzt muss ich leider zugeben, dass ich mich meine Kenntnisse wirklich nur aufs löten nach Anleitung beschränken. Mir fehlt jetzt noch eine Info was JP3 aus der Zeichnung ist?
Hallo giulup,
in diesem Plan hier: https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image (https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image)
ist der Jumper-1 nur dazu da, die Batterie von der Schaltung entkoppeln zu können.
Das wäre gleichbedeutend mit einem "RESET" der Schaltung, je nach dem ob man die Batterie (3V2) fest verbunden hat oder nicht.
Ist ab und zu beim Entwickeln ganz hilfreich, benötigt wird er in der Regel aber nicht und kann bei Bedarf einfach gebrückt werden.
Noch ein Hinweis: Ein Empfang aus dem Keller benötigt man etwas Augenmerk auf die Bauform der Antenne.
Hier: Crashkurs Antennen (https://forum.fhem.de/index.php/topic,55647.msg472526.html#msg472526)
PS:
ZitatZum Programmieren den Jumper von der Batterie ziehen und Sensor entfernen,
sonst meckert der Programmer ...
;)
Da mein Programmer (z.B. USBasp/avrdudess) mit 5V läuft und diese Spannung nicht die Batterie zum "Explodieren" bringen soll...
Eine bessere Lösung wäre für den ATtiny einen separaten Programmieradapter zu bauen, dann kann man die ISP-Stiftleiste ebenfalls weglassen.
Hier gibt es auch noch Infos mit dem Nano/Uno:
https://forum.fhem.de/index.php/topic,50333.msg437646.html#msg437646 (https://forum.fhem.de/index.php/topic,50333.msg437646.html#msg437646)
Grüße,
Jürgen
Danke für die ausführliche Info. Mir ging es aber um das Bauteil auf der linken Seite. :) :)
Habe jetzt durch ein bisschen suche rausgefunden, dass es der programmer für den attiny ist. Bin ich recht in der Annahme, dass das keine dauerhafte Verbindung sein muss, sondern nur einmalig damit es läuft?
Bisher habe ich keinen "avr isp prg". Hat da jemand eine Empfehlung für einen der zuverlässig und einfach in der Handhabung ist?
Grüße
Giuseppe
Hallo Guiseppe,
hängt davon ab, ob Du mehr damit machen möchtest.
Für den einmaligen Fall kannst Du einfach einen Arduino-Sketch benutzen (Google).
Ansonsten kannst Du einfach einen ISP Programmer nehmen:
Ich würde diesen hier empfehlen: avr-isp-stick (https://www.ehajo.de/baus%c3%a4tze/smd-baus%c3%a4tze/avr-isp-stick.html) oder einfacher isp-stick (https://www.ehajo.de/baus%c3%a4tze/smd-baus%c3%a4tze/%c2%b5isp-stick.html)
oder diesen hier: guloprog (https://guloshop.de/f/guloprog.pdf)
Zum Selberbauen:
fischl.de/usbasp (http://fischl.de/usbasp)
Bierdeckel (https://guloshop.de/shop/Zubehoer-und-Kleinteile/Bierdeckel::88.html?XTCsid=vmh7b5tcp5vp5cdll9ocjgt8c5)
IC-Testfassung-14-polig (https://guloshop.de/shop/IC-Fassungen/IC-Testfassung-14-polig::126.html?XTCsid=vmh7b5tcp5vp5cdll9ocjgt8c5)
Windows/Raspi(Mono) Oberfläche /Software dazu für avrdude:
AVRDUDESS (https://github.com/zkemble/AVRDUDESS)
Unten im Bild habe ich einige "Adapter" für ATtiny 85 + ATtiny 841 zusammengestellt ...
z.B. diese Platine für den ATtiny 841 lässt sich einfach für diese Projekte nutzen:
https://oshpark.com/shared_projects/fdF3wDQp (https://oshpark.com/shared_projects/fdF3wDQp)
12 Stück für knapp USD 14.80, mit Porto ...
Hi Jürgen.
Danke für den reichhaltigen Input. Damit werde ich erstmal ein wenig zu lesen und lernen haben. :)
Die Platine sieht sehr interessant aus und sieht am Ende auch sauber aus. Leider bin ich nicht kundig genug, dass sich mir die Verbindungen auf den Boards selbst erklären. Wo zB kommt der ds18b20 hin?
Die Zusammenfassung von Chris mit der Bauteilliste hat mir im ersten Moment mehr Einfachheit suggeriert.
Sorry und danke für die Mühen
Giuseppe
ZitatDanke für den reichhaltigen Input. Damit werde ich erstmal ein wenig zu lesen und lernen haben
Ja, das geht nicht von heute auf morgen ... ;)
ZitatDie Zusammenfassung von Chris mit der Bauteilliste hat mir im ersten Moment mehr Einfachheit suggeriert
Ja stimmt auch. Aber wie immer hätte man das Henne-Ei-Problem.
Einfacher wäre es, Du nimmst zuerst einen Arduino NANO als Grundlage und versuchst die Firmware etwas zu verstehen.
ZitatWo zB kommt der ds18b20 hin?
Versuche mal anhand der Google-Bilder-Suchfunktion mittels "Arduino DS18B20" Dich in das Thema einzulesen....
Bei der Programmierung der Port-Pins bist Du ja frei und kannst ja von dem Original abweichen.
Zum Einsteigen in die yC-Programmierung ist das Projekt natürlich etwas "too much" ... ???
Aber jeder fängt mal "klein" an und Fragen kostet nichts...!
Grüße und viel Spaß beim Nachbauen,
Jürgen
Danke für die Unterstützung Jürgen. Nach einem halben Tag einlesen (und teils genervten Blicken meiner Frau am Feiertag :) ) bin ich ein ganzes Stück weiter.
Ich dachte schon ich bin in einem Alter wo man sich in sowas komplexes nicht mehr einarbeiten kann.
Das mit Sketches selbst schreiben klingt auch nach Spaß. Ach hätte ich doch keinen Job und mehr Freizeit ::)
Ich glaube ich mach mich im Laufe der Woche mal an eine größere Bestellung.
Riesen Danke an Jürgen.
ZitatAch hätte ich doch keinen Job und mehr Freizeit
... kommt mir bekannt vor ... ;)
Aber vielleicht noch ein Tipp:
https://forum.fhem.de/index.php/topic,59933.msg582762.html#msg582762 (https://forum.fhem.de/index.php/topic,59933.msg582762.html#msg582762)
https://forum.fhem.de/index.php/topic,59933.msg599637.html#msg599637 (https://forum.fhem.de/index.php/topic,59933.msg599637.html#msg599637)
Bodenfeuchte-Platine einfach als Funk-Thermometer Zweck-entfremden .... :D :D :D
Du kannst die von Locutus gemachten Platine(n) zur Temperaturmessung nutzen,
indem Du einfach die Bauteile (2 Widestände + NE555) für die Bodenfeuchte weglässt und nur den DS18B20 bestückst.
Den Thermometer-Sketch kannst Du trotzdem benutzen, evtl. ist nur der Portpin dort auf diese Version
anzupassen dann sollte es ebenfalls als Thermometer lauffähig sein.
Frag doch mal bei Locutus nach, evtl. hat er noch Platinen ... ;)
Grüße,
Jürgen
Hallo zusammen,
da ich frisch von FHEM infiziert worden bin, durchstöbere ich diesbezüglch gerade alles wofür ich eine Anwendung zu Hause finde. Daher hängen jetzt zahlreiche Steckboard aufbauten am Raspberry.
Da ich jetzt hier in diesem Thread natürlich wieder einen Anwendungsfall gefunden habe und mich durch die ersten Seiten gekämpft habe, war ich jetzt froh das Chris81 auf der letzten Seite eine zusammenfassung gefunden habe. Ich finde dies ein tolles Projekt und würde dies gerne ebenfalls daheim aufbauen wollen.
"Juergs" erwähnte das man die Platinen dafür bestellen kann. Ist dies so richtig? Und wenn ja kann mir jemand sagen wo? :-\
:) :)
Beitrag #1:
ZitatNun zum Funkthermometer:
Da ich nicht gerne auf Lochstreifenplatine rumbastel, lasse ich mir immer sobald alles auf einem Breadboard erfolgreich getestet wurde, Leiterplatten anfertigen.
Diese beziehe ich aus China von der Fa. Itead https://www.itead.cc/ (https://www.itead.cc/). Da kosten 10 Leiterplatten im Format 5cm x 5cm ca. 14,50USD ink. Porto (ca. 12,80€).
Der Bestellvorgang ist recht simple. Hierzu muss man sich einmalig Registrieren, dann ein Leiterplattenformat auswählen und Bezahlen (Z.B mit Paypal).
Danach bekommt man eine Bestellnummer, diese füge ich dann als Benennung der Leiterplattendaten des entsprechenden Zip-Archives ein (Bsp. order_012345678.zip)
Das Zip-Archiv enthält dann alle relevanten Files im Gerberformat die der Leiterplattenhersteller benötigt. Das alles ist auch sehr gut auf der Webseite beschrieben.
Das Zip-Archiv muss dann noch unter der entsprechenden Bestellnummer auf die Firmenserver hochgeladen werden. Da ich die Leiterplatten ja schon mal bestellt habe und die Gerberdateien noch vorliegen habe, füge ich sie am Ende mit ein ein Archiv ein, so das nur noch die Bestellnummer aktualisiert werden muss.
Per Paypal Warenkorb bestellen (quasi Vorrauszahlung), Account anlegen, Gerber.zip (Die 2.Version von locutus nehmen) hochladen und warten bis fertig (;-)
Kein Hexenwerk ... Wenn Dir 10 Stück zuviel sind, nehme ich gerne ein paar Platinen von Dir ab....
Diese sind zwar für BF gedacht, lassen sich aber ebenfalls "nur" als Thermometer nutzen, oder ... oder ...
gerber.zip (https://forum.fhem.de/index.php?action=dlattach;topic=59933.0;attach=73617) (Vielen Dank an locutus!)
Grüße,
Jürgen
Hallo zusammen,
Ich habe mich mal rangetraut und matlens Eigenbau nachgebastelt. Alles hat super funktioniert. Der Sensor wird erkannt und automatisch angelegt. Hab die Version mit dem Ds18b20 gebastelt.
Aber ein Problem gibt es. Die Temperaturwerte die mir ausgegeben werden sind absolut nicht plausibel. Sie schwanken im Innenraum zwischen -4 bis 50 C. Habe bisher nur einen Sensor. Habe aber das ganze auf einer zweiten Platine nochmal gemacht mit dem gleichen Sensor und selben Ergebnis. Ist der Ds18b20 hin oder woran können solche Sprünge liegen? Das ganze springt im halbminutentakt. Hier noch ein Ausschnitt aus dem Log
2017.05.18 20:45:44 5: CUL/RAW: /s010
2017.05.18 20:45:44 5: CUL/RAW: s010/D880A100B; 480:
2017.05.18 20:45:44 5: CUL/RAW: s010D880A100B; 480:/ 8928
2017.05.18 20:45:44 4: CUL_Parse: RpiCul433 s010D880A100B; 480: 8928
2017.05.18 20:45:44 5: RpiCul433: dispatch s010D880A100B; 480: 8928
2017.05.18 20:45:44 4: CUL_TCM97001 using longid: 1 model: KW9010
Allen soweit noch einen schönen Abend
Hallo giulup,
mir ist nicht ganz klar, welches Programm Du eigentlich benutzt.
Zitat..matlens Eigenbau nachgebastelt
Benutzt Du das Basic-Programm von MatLen dazu?
Jürgen
Ich habe mir gerade mal die beiden Datasheets angeguckt.
Der DS18B20 gibt die Temperatur Bitmäßig halt ganz anders aus als der DS1820.
Dann muss dann wohl die Bascom routine angepasst werden. Oder einfacher nen DS1820 (DS18S20)kaufen
Auszug Datasheet DS1820
+125°C 00000000 11111010 00FAh
+0.5°C 00000000 00000001 0001h
Auszug Datasheet DS18B20
+125°C 00000111 11010000 07D0h
+ 0.5°C 0000 0000 0000 1000 0008h
Edit: Hier gits auch noch was dzu. https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377 (https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377)
Edit. Habe mal was für den DS18B20 mit eingebaut. Keine Ahnung ob es funktioniert da ich den Sensor nicht hier habe. Bitte mal testen.
Zitat von: juergs am 19 Mai 2017, 17:32:40
Hallo giulup,
mir ist nicht ganz klar, welches Programm Du eigentlich benutzt.Benutzt Du das Basic-Programm von MatLen dazu?
Jürgen
Ja genau. Matlens Anleitung aus dem ersten Post.
Zitat von: matlen67 am 20 Mai 2017, 19:57:07
Ich habe mir gerade mal die beiden Datasheets angeguckt.
Der DS18B20 gibt die Temperatur Bitmäßig halt ganz anders aus als der DS1820.
Dann muss dann wohl die Bascom routine angepasst werden. Oder einfacher nen DS1820 (DS18S20)kaufen
Auszug Datasheet DS1820
+125°C 00000000 11111010 00FAh
+0.5°C 00000000 00000001 0001h
Auszug Datasheet DS18B20
+125°C 00000111 11010000 07D0h
+ 0.5°C 0000 0000 0000 1000 0008h
Edit: Hier gits auch noch was dzu. https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377 (https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377)
Edit. Habe mal was für den DS18B20 mit eingebaut. Keine Ahnung ob es funktioniert da ich den Sensor nicht hier habe. Bitte mal testen.
Danke, ich werde es später gleich mal testen. Hatte zum DS18B20 gegriffen, weil es diesen günstiger in der wasserdichten Ausführung gibt.
Zitat von: matlen67 am 20 Mai 2017, 19:57:07
Ich habe mir gerade mal die beiden Datasheets angeguckt.
Der DS18B20 gibt die Temperatur Bitmäßig halt ganz anders aus als der DS1820.
Dann muss dann wohl die Bascom routine angepasst werden. Oder einfacher nen DS1820 (DS18S20)kaufen
Auszug Datasheet DS1820
+125°C 00000000 11111010 00FAh
+0.5°C 00000000 00000001 0001h
Auszug Datasheet DS18B20
+125°C 00000111 11010000 07D0h
+ 0.5°C 0000 0000 0000 1000 0008h
Edit: Hier gits auch noch was dzu. https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377 (https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377)
Edit. Habe mal was für den DS18B20 mit eingebaut. Keine Ahnung ob es funktioniert da ich den Sensor nicht hier habe. Bitte mal testen.
Habe beide Dateien getestet. Leider zeigen beide keine plausiblen Werte an (4°C, 88°C, 45°C...)
Ich werde mich auch mal etwas damit beschäftigen. Aber falls du schneller auf eine neue Möglichkeite kommst teste ich gerne :)
Ich habe das Programm nun mal auf meinem einzigen Sender mit DS18S20 geflasht weil ich wissen wollte ob es grundsätzlich funktioniert nach der Änderung.
Ja das tut es bei mir.
Da der DS18B20 zur Darstellung der Temperatur 12 Bit anstelle von 9 Bit verwendet schiebe ich das Ergebnis aus Scratchpad (Byte 1 & 2) einfach 3 Stellen nach rechts. Vorher lese ich den FamilyCode aus, und prüfe ob
ein DS1820 FamilyCode &h10 oder der DS18B20 FamilyCode &h28 verbaut ist. Das funktioniert jedenfalls bei mir. Nicht das du da noch irgendwo anders einen Fehler drinn hast.
Evtl. stimmt der Takt nicht? Fusebytes richtig gesetzt? dann kommt da auch immer Müll bei raus.
Hänge die bei mir funktionierende Datei nochmal an.
Gruß
Ich setze mich heute Abend nochmal dran. Kann ich den attiny einfach nochmal Flashen oder muss ich was beachten. Fusebit ist gesetzt bzw. Haken rausgenommen.
Hier nochmal der Log aus dem Sensor
2017-05-21_15:02:21 KW9010_1 T: 45.2 H: -106
2017-05-21_15:02:26 KW9010_1 temperature: 37.6
2017-05-21_15:02:26 KW9010_1 T: 37.6 H: -106
2017-05-21_15:02:29 KW9010_1 temperature: 5.6
2017-05-21_15:02:29 KW9010_1 T: 5.6 H: -106
2017-05-21_15:02:57 KW9010_1 temperature: 17.6
2017-05-21_15:02:57 KW9010_1 T: 17.6 H: -106
2017-05-21_15:03:02 KW9010_1 temperature: 33.6
2017-05-21_15:03:02 KW9010_1 T: 33.6 H: -106
2017-05-21_15:03:07 KW9010_1 temperature: 1.6
2017-05-21_15:03:07 KW9010_1 T: 1.6 H: -106
2017-05-21_15:03:17 KW9010_1 temperature: 19.2
2017-05-21_15:03:17 KW9010_1 T: 19.2 H: -106
2017-05-21_15:03:29 KW9010_1 temperature: 25.6
2017-05-21_15:03:29 KW9010_1 T: 25.6 H: -106
2017-05-21_15:03:40 KW9010_1 temperature: 12.7
2017-05-21_15:03:40 KW9010_1 T: 12.7 H: -106
2017-05-21_15:03:51 KW9010_1 temperature: 15.9
2017-05-21_15:03:51 KW9010_1 T: 15.9 H: -106
2017-05-21_15:04:02 KW9010_1 temperature: 36.7
2017-05-21_15:04:02 KW9010_1 T: 36.7 H: -106
2017-05-21_15:04:13 KW9010_1 temperature: 4.7
2017-05-21_15:04:13 KW9010_1 T: 4.7 H: -106
2017-05-21_15:04:24 KW9010_1 temperature: 39.9
2017-05-21_15:04:24 KW9010_1 T: 39.9 H: -106
2017-05-21_15:04:46 KW9010_1 temperature: 24.7
2017-05-21_15:04:46 KW9010_1 T: 24.7 H: -106
2017-05-21_15:04:57 KW9010_1 temperature: 31.1
2017-05-21_15:04:57 KW9010_1 T: 31.1 H: -106
Den Atinny kannste gaaanz oft neu beschreiben.
Teste mal folgendes Programm
Temperatur müsste 4,0 °C sein, wenn nicht stimmt was mit deiner Schaltung nicht ;)
Wo mit schreibst du die Fusebits? Nutzt du Bascom?
Was denn das fürn Log? der DS18(B)20 hat doch gar kein H (humidity)
Hier mal mein Log zum DS
2017-05-21_14:56:28 SB_FS_1 T: 21.8
2017-05-21_15:07:17 SB_FS_1 T: 21.1
2017-05-21_15:18:05 SB_FS_1 T: 20.8
2017-05-21_15:28:54 SB_FS_1 T: 21.2
2017-05-21_15:39:42 SB_FS_1 T: 20.8
2017-05-21_15:50:31 SB_FS_1 T: 20.7
2017-05-21_16:01:19 SB_FS_1 T: 20.8
2017-05-21_16:12:08 SB_FS_1 T: 21.0
2017-05-21_16:22:56 SB_FS_1 T: 21.0
2017-05-21_16:33:45 SB_FS_1 T: 20.8
Anbei das aktuelle FHEM Modul zum Funkthermometer:
Zitat von: matlen67 am 21 Mai 2017, 20:09:32
Was denn das fürn Log? der DS18(B)20 hat doch gar kein H (humidity)
Hier mal mein Log zum DS
2017-05-21_14:56:28 SB_FS_1 T: 21.8
2017-05-21_15:07:17 SB_FS_1 T: 21.1
2017-05-21_15:18:05 SB_FS_1 T: 20.8
2017-05-21_15:28:54 SB_FS_1 T: 21.2
2017-05-21_15:39:42 SB_FS_1 T: 20.8
2017-05-21_15:50:31 SB_FS_1 T: 20.7
2017-05-21_16:01:19 SB_FS_1 T: 20.8
2017-05-21_16:12:08 SB_FS_1 T: 21.0
2017-05-21_16:22:56 SB_FS_1 T: 21.0
2017-05-21_16:33:45 SB_FS_1 T: 20.8
Anbei das aktuelle FHEM Modul zum Funkthermometer:
Kam mir auch komisch vor aber dachte mir einfach, dass wär ein Standardwert der durch den Tiny ausgegeben wird wenn keine H gemessen wird, so wie die 85°C bei den DS.
Aaaaaaaber dein Rat mit dem Modul war ein Volltreffer. Nachdem ich deine 4 °C hex getestet hatte und mir 8°C angezeigt wurden war ich schon am abdrehen und dachte ich bin zu doof um das dran zu löten und war schon mit der Lupe an der Platine.
Nun habe ich dein aktuelles Modul reingeschoben und auf Anhieb kamen da die 4°C. Ganz augeregt schnell die andere hex geflasht und taadaaa....
Viiiiieeeelleeeeeen Dank. Du hast mein Wochenende am Ende doch noch gerettet. Ich find klasse, dass du dich nach so langer Zeit noch darum kümmerst.
Hallo und guten Tag,
ich muß mal eine blöde Frage stellen. Wie habt Ihr den Attiny85 programmiert? Mit einen Arduino und Arduino IDE? Ich möchte die Version mit dem DHT22 nachbauen und hab die Dateien bzw. Scripte mit IDE 1.8 geladen. Wenn ich die Scripte prüfen lasse kommen zahlreiche Fehlermeldungen. Ich bin ehrlich ich hab sowas noch nie gemacht. Ich hab Anleitungen im Netz gefunden wie man den Attiny85 mit einen Arduino flashen kann aber soweit komm ich gar nicht wegen den Fehlermeldungen im Script.
Für Hilfe wäre ich sehr dankbar weil ich die Platine schon gelötet habe und ich nur noch den Attiny programmieren muß um in Betrieb zu gehen.
Danke.
Hallo Groej,
ZitatWie habt Ihr den Attiny85 programmiert?
das ist ja das klassische Henne/Ei-Problem:
Wenn wir von einen neu gekauuften ATTiny-DIP-Baustein ausgehen, hat dieser kein Code, wie z.B. einen Bootloader etc geladen.
Deshalb lässt er sich ja nicht über USB direkt programmieren (außer die Digispark (http://digistump.com/wiki/digispark)-Varianten mit Micronucleus-Bootloader).
Da die TemperaturSensoren ja möglichst viel Power sparen sollen, wird auf die USB-Variante zum Programmieren verzichtet.
Meine Vorgehensweise unter Windows ist diese, dass ich den Chip mit einem ISP-Programmer programmiere.
Das hat den Vorteil, dass man auf einen Bootloader verzichten kann und direkt über die ISP-Schnittstelle programmieren kann
und noch einige spezifische Einstellungen wie z.B. Fuses etc. machen kann.
Dazu benötigt man aber einen ISP-Programmer, der für wenig Geld im Internet erstanden werden kann:
Gut dokumentierte Variante ist zum Beispiel diese hier avr-isp-stick (https://www.ehajo.de/baus%c3%a4tze/smd-baus%c3%a4tze/avr-isp-stick.html)
Generell kann man sich aber auch einen Programmer selbst erstellen: USBasp (http://www.fischl.de/usbasp/), guloprog (https://guloshop.de/shop/Mikrocontroller-Programmierung/guloprog-der-Programmer-von-guloshop-de::70.html?XTCsid=g14toud8i97ugo2t2rtho155s0) oder USBTinyISP (http://www.instructables.com/id/DIY-5-USBTinyISP/). Je nach Gusto und Geldbeutel.
Du kannst aber auch einen Arduino als Programmierer benutzen ... Google (https://www.google.de/search?q=arduino+isp+programmer&client=firefox-b&dcr=0&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwj9qsPHtNzWAhXiD8AKHeCZA-wQsAQIVA&biw=1600&bih=1077) dazu doch einfach mal.... Programming ATtiny45/85 vs. an Arduino Board (http://highlowtech.org/?p=1695) TinyProgrammer (http://highlowtech.org/?p=1801)
Hier (https://forum.fhem.de/index.php/topic,59933.msg611880.html#msg611880) gibt es auch noch Infos...
oder so (https://www.mikrocontroller.net/articles/Raspberry_Pi_als_Universalprogrammer#AVR-Programmer)
Aber Obacht, Fehler können den Rpi schrotten.
Grüße Markus
Ein Wrapper/GUI für avrdude auch für RASPI mit Mono: Avrdudess (https://github.com/juergs/Avrdudess)
Hallo und Danke für Eure Antworten. Aber mit welchen Programm öffnet Ihr die Datei und schiebt sie in den 85 rein? Wie gesagt mach ich die Dateien mit Ardiuno IDE auf und lasse sie prüfen kommen nur Fehlermeldungen.
Danke.
Die Standard-Vorgehensweise bei 8Bit-Flash-Atmel-Controllern ist ja immer gleich:
1.) Du hast ein Chip mit vorprogrammierten Bootloader -> Programmierung über USB + AVRdude
2.) Du hast einen Chip ohne Bootloader, dann benötigst Du einen Programmieradapter + avrdude (wenn AVRdude diesen Programmer-Typ (http://www.nongnu.org/avrdude/user-manual/avrdude_12.html) auch unterstützt!)
Dann hängt es natürlich auch vom verwendeten Betriebsystem ab, was man, wenn man nicht per Kommandozeile
avrdude parametiert aufrufen möchte.
Ich benutze z.B. einen mySmartUsb Light-Programmer, mit dessen Windows-Programmer-Anwendung zum programmieren.
Eigentlich müsste es auch aus der Arduino-IDE direkt gehen -> Google! (http://de.lmgtfy.com/?q=ATtiny85+programmieren+(mit+Arduino+Uno+oder+USB-Programmer))
Hier ist zum ATtiny841 vieles auch beschrieben: Bodenfeuchte-SpinOff-Thread (https://forum.fhem.de/index.php/topic,59933.msg607590.html#msg607590)
Hallo,
schönes Projekt!
Nachdem ich aufgegeben habe bei den Max-Thermostaten die aktuelle Temperatur auszulesen, bin auch auf der Suche nach einer Möglichkeit in mehren Räumen Temperatur (und Luftfeuchtigkeit) zu Messen.
(Mich ärgert es maßlos, das die Thermostate einen Temperatursensor haben...aber der Wert nur über blöde Umwege preisgeben...aber das gehört hier nicht hin...)
Ich bin Bastler. Daher versuche ich immer erstmal keine fertige Lösung zu nehmen. Auch wenn derzeit die TFA 30.3121 für schon 10€ (ELV) zu haben sind...bei 5 Räumen sind das aber auch schon wieder 50€...und ein paar mehr Sensoren wären hier ja nicht schlecht. Das ist aber bei der fertigen Lösung schon wieder schwierig, da die IDs sich bei jedem Batteriewechsel verändern...
Umso interessanter dieser Beitrag. Da ich noch drei digispark (die billigen rev.3), einen DHT22 und ein 433MHZ Sender (FS1000A) hier rumfliegen habe, habe ich mich gleich mal daran versucht.
Ich finde den Digispark echt klasse. Auch ohne programmer leicht zu programmieren. Zum testen hat man dann auch gleich die Stromversorgung von USB. Hier könnte man den Sender und Sensor direkt anlöten(ohne weitere Platine)..und sehr günstig ist er auch noch...
Hier meine theoretische Einkausliste:
Zitat
Digispark: 10x 8,94€ (https://de.aliexpress.com/item/Free-shipping-10pcs-CJMCU-Digispark-kickstarter-miniature-for-Arduino-ATTINY85-usb-development-board/32540165258.html?spm=a2g0s.13010208.99999999.270.u954ZO (https://de.aliexpress.com/item/Free-shipping-10pcs-CJMCU-Digispark-kickstarter-miniature-for-Arduino-ATTINY85-usb-development-board/32540165258.html?spm=a2g0s.13010208.99999999.270.u954ZO))
DHT22: 10x 22,30€ (https://de.aliexpress.com/item/Free-shipping-DHT22-digital-temperature-and-humidity-sensor-Temperature-and-humidity-module-AM2302-replace-SHT11-SHT15/632552670.html?spm=a2g0x.search0104.3.1.KkWOr8&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10068_10344_10345_10547_10342_10343_10340_10341_10548_10193_10194_10541_10304_10307_5670020_10060_10302_10155_10154_10056_10055_10539_10537_10536_10059_10534_10533_100031_10103_10102_10107_10142_10320_10321_10322_10562_10084_10083_10561_10177_5650020_10180_10312_10313_10314_10184_5660020_10319_10550_10073_10551_10552_10553_10554_10186_10557-10552,searchweb201603_30,ppcSwitch_5&btsid=4d5b6118-c3b5-47fe-8a24-829edfa72f1a&algo_expid=85639189-872a-48cc-910c-1c3eae6fe51f-0&algo_pvid=85639189-872a-48cc-910c-1c3eae6fe51f)
XY-MK-5V-XY-FST-433Mhz-Rf-Transmitter-and-Receiver: 10x 11,10€ (https://de.aliexpress.com/item/XY-MK-5V-XY-FST-433Mhz-Rf-Transmitter-and-Receiver-Link-Kit-for-Arduino-Arm-McU/32732438014.html?spm=a2g0s.13010208.99999999.263.u954ZO)
Batteriehalter 2xAA: 10x ca. 10€
Gehäuse: ca. 10€ (hab noch nichts passendes herausgesucht)
Summe ca. 65€...für 10 Stück. Also nur noch 6,50€/Stück. Macht die Sache doch schon echt interessant.
Wobei hier noch ggf. ein Step-UP mit eingeplant werden sollte...
Leider habe ich es nicht geschafft, die DHT (Sparkfun Lib) zu verwenden. Ich hatte auch auf dieser Seite einen Artikel zum DHT22 gelesen:
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/
Hier wird die DHT Lib von Rob Tillaart verwendet. (https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib)
Diese lief bei mir fast auf Anhieb.
Dann habe ich die LaCrosse Lib eingebunden und versuche nun die Daten zu senden. Gesendet wird auch irgendwas. Ich kann das mittels SDR# sehen.
In FHEM wird aber rein gar nichts empfangen. In FHEM wird kein Gerät angelegt. (Autocreate ist eingeschaltet)
Daher habe ich auch noch probiert mit der 433MHz (Intertechno) Lib zu senden. (https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home)
Auch hier wird etwas gesendet, aber ich weiß leider nicht, wie ich das prüfen kann.
Wenn ich das bisher richtig verstanden habe, sollten doch beide Protokolle von meinem Selbstbau CUL (433MHz / SlowRF) erkannt werden? Intertechno Fenstersensoren empfange ich auch problemlos...
Ich gehe mal davon aus, das entweder auf das Timing nicht stimmt (Ich habe sowohl die Standardeinstellung als auch 8MHz probiert) oder der FS1000A nicht ganz auf der richtigen Frequenz sendet. Das lässt sich ja leider nicht beeinflussen.
Hat das schon jemand mit einem Digispark am laufen? Mit welchen Einstellungen?
Mich würde auch noch generell die Batterielaufzeiten bei euch interessieren. Bei welchem Intervall mit welcher Batterie/Akku habt ihr welche Laufzeiten? Hat auch jemand eine Variante mit einem Step-UP umgesetzt? Dann könnte man die Batterien auch bis zum Ende ausreizen...
Gruß
Bismosa
Schau Dich mal hier bei mir auf Github (https://github.com/juergs/) um.
Dort sind auch einige Projekte auf ATtiny-Basis. (85 + 841)
Hier (https://forum.fhem.de/index.php/topic,52755.msg613851.html#msg613851) steht drin, was zu tun ist...
Die Verwendung von USB-ATtiny-Typen im Batterie-Betrieb rate ich, wegen dem Verlust an Batterie-Kapazität, allemal ab (Milli- zu Mikro-Ampere + Batterielaufzeit ;)).
Es sei denn, man kann die Pullups abschalten....
Der Code sollte eigentlich einfach laufen, wenn man alles in einen Ordner kopiert und über die Arduino-Ide die Ino-Datei aufruft.
Beim Timing der Bit-Zeiten hat sich etwas geändert, diese LaCrosse.cpp (https://github.com/juergs/iAQ_NANO_328_LaCrosse/blob/master/utility/LaCrosse.cpp) hier ist der aktuelle Code
mit den geänderten Pulse-Zeiten dafür zu finden. Die funktionieren bei mir ebenfalls 100%ig.
//--- Duration of pulses and delays
//--- geändertes Timing
int iLongPulse = 1200; // 975;
int iShortPulse = 400; // 250;
int iDelay = 900; // 1450;
Vielleicht sind die CPU-Freq-Fuses bei Dir nicht richtig gesetzt?
Hallo,
danke für die Antwort!
Ich habe jetzt mit der aktuellen LaCrosse Lib probiert. Aber auch hier kein Erfolg. Wenn ich das richtig sehe (auf einer Aufnahme mit SDR# analysiert mit Audacity), scheinen aber die Timings bei mir halbwegs zu stimmen. Außer ich bin ne 10er Potenz daneben...ich komme da gerne mal durcheinander...
Dann habe ich meinen CUL zum SIGNALduino umgeflasht. Nun bekomme ich auch Temperatursensoren von den Nachbarn rein. Aber meiner wird immer noch nicht erkannt.
Also liegt es entweder am Sender selbst (Der auch auf dem ganzen Frequenzband sehr streut) oder an den Timings.
Ich denke, da das Ganze wohl eh keinen Erfolg haben wird (Batterielaufzeit), gebe ich die Versuche mit dem Digispark auf. Eigentlich schade...
Vielleicht probiere ich am Wochenende mal einen Digispark mit einen Arduino umzuflashen. Müsste eigentlich möglich sein. Dann muss ich nicht zum Testen neue Attinys bestellen. Dann könnte ich auch sehen, ob es nicht wirklich am Sender liegt.
Wie lange hält denn nun bei euch eine Batterie durch?
Gruß
Bismosa
[edit]
Ich habe es jetzt direkt mal probiert. Aber ich müsste die Fuses wohl erst zurücksetzen mit einem High-Voltage Programmer. Kann man sich wohl auch selbst bauen...
Ich werde wohl jetzt erst einmal neue Hardware bestellen (Attiny; Sender; DHT22 und zum testen ein Step-up). Das wird dann also wieder ein paar Wochen dauern. Ich weiß nur noch nicht genau welchen Sender ich jetzt kaufen sollte? Ist der FS1000A ok? Oder gibt es da bessere Module?
[/edit]
Hallo nochmal,
ich konnte es jetzt doch nicht lassen. Ich habe mir den HV Programmer nachgebaut (http://www.instructables.com/id/How-to-unlock-Digispark-ATtiny85-and-convert-it-to/)
Nun habe ich einen "normalen" Attiny85 nur bereits aufgelötet :)
Nun habe ich mit der Arduino IDE den Sketch vom 4.Januar (https://github.com/juergs/_ATtiny85_DHT22_BMP180_433) geflasht. Eingestellt habe ich auf "internal 8MHz" und habe den Booloader und den Sketch erfolgreich hochgeladen.
In FHEM wird immer noch nichts erkannt.
Dann habe ich mittels SDR# gesehen, das mein FS1000A (ich glaube immer noch das der ne Macke hat) nicht auf 433,92MHz sendet sondern auf ca. 433,73MHz. Daher habe ich den SIGNALduino mal umgestellt. Jetzt wird wenigstens mal etwas erkannt. Aber das sieht nicht so ganz richtig aus:
2017.11.10 18:48:31 4 : SIGNALduino/msg READ: MU;P0=-32001;P1=364;P2=-21832;P3=1000;P4=-1509;P5=244;D=01234343454545454343454543434543454543454545434543434543454543454345454523434343454345434343434345454545434345454343454345454345454543454343454345454345434545452343434345434543434343434545454543434545434345434545434545454345434345434545434543454545234343;CP=5;R=24;O;
2017.11.10 18:48:31 4 : SIGNALduino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2017.11.10 18:48:32 4 : SIGNALduino/msg READ: MU;P0=-1517;P1=990;P2=248;P3=-21988;D=01020102010101010102020202010102020101020102020102020201020101020102020102010202023101010102010201010101010202020201010202010102010202010202020102010102010202010201020202;CP=2;R=24;
2017.11.10 18:48:32 4 : SIGNALduino: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2017.11.10 18:48:33 4 : SIGNALduino/msg READ: MU;P0=-32001;P1=978;P2=-1542;P3=234;P5=-21972;D=01212121232123212323232123232323212123232323212323232123232321232323212323232123232123235121212123212321232323212323232321212323232321232323212323232123232321232323212323212323512121212321232123232321232323232121232323232123232321232323212323232123232321;CP=3;R=21;O;
2017.11.10 18:48:33 4 : SIGNALduino/msg READ: MU;P0=-1526;P1=240;P2=995;P3=-21990;D=010102010132020202010201020101010201010101020201010101020101010201010102010101020101010201010201013202020201020102010101020101010102020101010102010101020101010201010102010101020101020101;CP=1;R=22;
Ich denke das ich entweder die Fuses nicht richtig habe (wobei ich das in der Arduino IDE wohl nicht weiter beeinflussen kann) oder stimmen die 8MHz nicht?
Gruß
Bismosa
https://forum.fhem.de/index.php/topic,59933.msg608162.html#msg608162 (https://forum.fhem.de/index.php/topic,59933.msg608162.html#msg608162)
Hallo,
danke für den Wink mit dem Zaunpfahl :)
Ich habe jetzt mit avrdude (unter Windows) die Fuses ausgelesen. (Sorry...für mich ist das alles neuland)
avrdude.exe -c stk500v1 -p attiny85 -P com4 -U lfuse:r:-:i -v -b 19200
Dabei kam heraus:
(E:FF, H:DF, L:62)
Dann habe ich mit dem fusecalc http://www.engbedded.com/fusecalc gesehen, das bei mir wirklich der "Divide clock by 8" gesetzt war. Hier sind ja die richtigen Einstellungen auch schon beschrieben (https://forum.fhem.de/index.php/topic,52755.msg517158.html#msg517158)
Also habe ich diese jetzt neu gesetzt mit
avrdude.exe -c stk500v1 -p attiny85 -P com4 -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -v -b 19200
Und die Abfrage bestätigt: (E:FF, H:DF, L:E2)
In FHEM kommt leider immer noch nichts richtiges an...
Also habe ich nochmal die LaCrosse geprüft. Natürlich hatte ich hier wieder die falsche Version. Grmpf. Also ausgetauscht und PIN_SEND auf 4. Jetzt kommt wohl endlich mal etwas an.
Internals:
CODE 121
DEF 121
LASTInputDev SIGNALduino
MSGCNT 11
NAME CUL_TX_121
NR 299
SIGNALduino_DMSG TXA0F32DD2D6
SIGNALduino_MSGCNT 11
SIGNALduino_RAWMSG MU;P0=-21493;P1=393;P2=-10356;P3=-940;P4=252;P5=1217;D=01213435353535353131313135353131353531353131353131313531353531353131353135313131053535353135313535353535313131313535313135353135313135313131353135353135313135313531313105353535313531353535353531313131353531313535313531313531313135313535313531313531353131;CP=1;R=41;O;
SIGNALduino_RSSI -53.5
SIGNALduino_TIME 2017-11-11 10:22:05
STATE T: -48.0
TYPE CUL_TX
corr 0
lastH 1510392118.01914
lastT 1510392125.91591
minsecs 0
READINGS:
2017-11-11 10:22:05 state T: -48.0
2017-11-11 10:22:05 temperature -48.0
Attributes:
room CUL_TX
Aber es wird immer die Temperatur -48° und manchmal -50° angezeigt? Auch wenn ich den Sensor ganz entferne wird nichts anderes angezeigt?
Also irgendwas mache ich wohl immer noch falsch...oder ich habe noch mehr übersehen....
Gruß
Bismsoa
Hallo bismosa,
Zitat(Sorry...für mich ist das alles Neuland)
... hast Du den Hinweis auf "avrdudess" (https://github.com/juergs/Avrdudess/tree/master/src/avrdudess/bin/Debug) gesehen? Das erleichtert das Ganze.
Außerdem gilt: Learing by doing .. ;)
Die -50 Grad deuten eher darauf hin, dass evtl. die Pins mit den Zugriffen auf die Sensoren nicht richtig gesetzt sind.
Versuche doch einfach mal mit einem Basis-Sketch der Sensoren (einfach die Werte auf die serielle Schnittstelle ausgeben) zu überprüfen, ob die Hardware der Sensoren richtig funktioniert.
Sind deren Pins richtig gesetzt?
Hast Du den "Trick" gesehen, wie man die Serielle des ATtiny nur mit einem Pin betreiben kann (Also nur TX, um Zwischenergebnisse zu sehen, wenn zu wenig Pins zur Verfügungs stehen?
Die I2C Pins könnten für NANO und ATTiny unterschiedlich sein...
Hast du die Readme.txt dazu gelesen?
ZitatBeta-Vorversion für ATtiny85 mit spezifischen I2C.
Angefangen, aber nicht fertig.
Wenn Du das LaCrosse-Senden hinbekommen hast, sollte der Rest nur ein Klacks sein ;)
Wie sieht Dein HW- Aufbau aus? Pullups für I2C?
Hier noch eine Möglichkeit, die Dir evtl. weiterhelfen könnte (möglicher Unterschied 3V3 und 5V beachten!) :
https://forum.fhem.de/index.php/topic,24651.msg419419.html#msg419419 (https://forum.fhem.de/index.php/topic,24651.msg419419.html#msg419419)
Hallo,
danke für die ausführliche Hilfe! Es hat mich zwar wieder ein Stück weiter gebracht...aber funktionieren tut es leider immer noch nicht. Langsam fange ich an zu zweifeln...
Zitat von: juergs am 11 November 2017, 10:41:45
... hast Du den Hinweis auf "avrdudess" (https://github.com/juergs/Avrdudess/tree/master/src/avrdudess/bin/Debug) gesehen? Das erleichtert das Ganze.
Natürlich nicht. Wäre ja auch zu einfach gewesen. Aber ich habe es ja nach längerer Zeit endlich geschafft :)
Zitat von: juergs am 11 November 2017, 10:41:45
Hast du die Readme.txt dazu gelesen?
Ähm...welche jetzt? Wo hast Du das Zitat gefunden? Gehört das noch zum "Trick" zur Seriellen Schnittstelle?
Also. Ich teste jetzt erstmal den DHT22. Dafür habe ich jetzt erstmal SoftwareSerial aktiviert:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(0, 3);
...
void setup()
{
...
mySerial.begin(9600);
}
Und lasse mir über meinen FTDI1232 Adapter Serielle Ausgaben ausgeben.
Klappt soweit.
Den DHT22 habe ich an Pin4. Error ist 3 also DHT_ERROR_ACK_TOO_LONG
Wenn ich den Sensor entferne bekomme ich DHT_ERROR_NOT_PRESENT
Sieht ja gar nicht so verkehrt aus.
Pullup ist drin, Spannungsversorgung (3,3V) ok...alles mehrfach geprüft. Auch andere Pins probiert...jeweils der gleich Erfolg.
Dann habe ich (wie mit dem Digispark) die DHT lib von Rob Tillaart ausprobiert. Beim ersten Versuch bekomme ich auch gleich die Werte. Allerdings nur direkt nach dem Einschalten.
Nach dem Schlafen erhalte ich auch hier den Fehler "DHTLIB_ERROR_CONNECT". [edit]
Ich denke da muss noch irgendwas wieder geweckt werden. Habe ich jetzt aber noch nicht nachgeschaut.Ich hatte noch den Sender auf dem gleichen pin im Programm. Der wurde natürlich durch "LaCrosse.setTxPinMode(OUTPUT);" falsch gesetzt. Also geht das mit der lib.[/edit]
Also ist der Sensor und die Verkabelung wohl ok.
Ich würde eigentlich lieber die hier verwendete lib von Ben Adams benutzen. Da habt ihr ja schon Erfahrungen...aber was mache ich hier wohl falsch?
Nutzt du (ihr) denn jetzt den Nano oder einen Attiny85?
Gruß
Bismosa
ZitatNutzt du (ihr) denn jetzt den Nano oder einen Attiny85?
Zum Testen nehme ich den Nano oder Leonardo, dann portiere ich auf den ATtiny.
Ich komme leider mit Deinen Aussagen nicht ganz klar.
Du schilderst nicht
genau genug, was Du eigentlich machst.
Wenn Du Dein Code in ein Zip packst und hier anhängst, wäre es möglicherweise einfacher nachzuvollziehen. ;D
Hast DU das Projekt (https://github.com/juergs/ATtiny85_BMP180_DHT_1820_433/blob/master/_ATTiny85_BMP180_DHT_1820_433.ino) mal genauer angeschaut?
Dort habe ich auch einen
Schalter zwischen Leonardo und ATtiny eingebaut .. :D
... und die DHT-Fehler-Quellen und Diagnose-Output:
case DHT_ERROR_NONE:
//---Get Data
dht_temp = myDHT22.getTemperatureC();
dht_hum = myDHT22.getHumidity();
break;
case DHT_ERROR_CHECKSUM:
//--- send erraneous data as err indicator
dht_temp = -99.99;
dht_hum = -99.99;
break;
case DHT_BUS_HUNG:
dht_temp = -88.88;
dht_hum = -88.88;
break;
case DHT_ERROR_NOT_PRESENT:
dht_temp = -77.77;
dht_hum = -77.77;
break;
case DHT_ERROR_ACK_TOO_LONG:
dht_temp = -66.66;
dht_hum = -66.66;
break;
case DHT_ERROR_SYNC_TIMEOUT:
dht_temp = -55.55;
dht_hum = -55.55;
break;
case DHT_ERROR_DATA_TIMEOUT:
dht_temp = -44.44;
dht_hum = -44.44;
break;
case DHT_ERROR_TOOQUICK:
dht_temp = -33.33;
dht_hum = -33.33;
break;
default:
dht_temp = -22.22;
dht_hum = -22.22;Dort ist eigentlich alles realisiert ... und es funktioniert (auch mit sleep). ;)
Schau auch mal in die Infos im Header!
Hallo,
Zitat von: juergs am 12 November 2017, 19:00:48
Du schilderst nicht genau genug, was Du eigentlich machst.
Sorry. Ich werde versuchen mich zu bessern.
1.) Ich habe meinen Digispark mit einem HV-Programmer zurückgesetzt. Jetzt ist es kein Digispark mehr, sondern nur noch ein normaler Attiny85, der sich auf der Platine befindet.
2.) Nachdem ich nun die Fuses richtig gesetzt habe, klappt das Senden. (Wenn auch auff 433,7MHz...aber das ist kein Problem.)
3.) Hardwareaufbau:
https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image
Statt dem DS1820 nutze ich den DHT22.
3.) Ich programmiere rein mit der Arduino Software. Nun benutze ich den Code aus deinem GitHub (unverändert) https://github.com/juergs/_ATtiny85_DHT22_BMP180_433/blob/master/_ATtiny85_DHT22_BMP180_433.ino
Hiermit schaffe ich es nicht, den DHT22 auszulesen. (DHT_ERROR_ACK_TOO_LONG)
Nutze ich jedoch die DHT lib von Rob Tillaart (https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib) funktioniert der DHT22 wie gewünscht.
Zitat von: juergs am 12 November 2017, 19:00:48
Hast DU das Projekt (https://github.com/juergs/ATtiny85_BMP180_DHT_1820_433/blob/master/_ATTiny85_BMP180_DHT_1820_433.ino) mal genauer angeschaut?
Ja...aber erst jetzt. Soweit ich das sehen konnte, ist das Handling mit dem DHT22 aber gleich. Ich werde das heute Abend aber nochmal ausprobieren.
Vielen Dank für die Hilfe!
Gruß
Bismosa
ZitatFuse-Einstellungen beim ATtiny85 für interne 20 MHz:
====================================================
LF = 0xF1 ( PLL-Clock, not internal 8 MHz)
HF = 0xDF
EF = 0xFF
LB = 0x03
Hallo!
:-[ Schande auf mein Haupt. Das habe ich wirklich übersehen.
Ich hasse es, wenn meine Tochter "aber" sagt, aber 20MHz ist für Batteriebetrieb doch ein sehr starker Stromfresser? Lt. Datenblatt bei 5V knapp 12mA und bei 8MHz kanpp 6mA...macht aber wohl bei einer Laufzeit von wenigen Sekunden vielleicht nicht zu viel aus...
Ich hatte gestern Abend noch viel rumprobiert. Nachdem ich da meinen Fehler noch nicht gefunden hatte, habe ich angefangen die Vorlage etwas zu verändern.
1.) Fuses: E:FF, H:DF, L:E2 (8 MHz, Divide clock by 8 abgewählt)
2.) Ich nutze jetzt die DHT lib von Rob Tillaart (https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib)
3.) Ich nutze noch die Platine vom Digispark, daher habe ich an Pin1 noch eine LED, die ich kurz aufblitzen lassen, wenn der DHT22 ausgelsen wird
4.) Meldet der DHT einen Fehler wird 10x ausgelsen und erst dann der Fehlerwert gesendet (wenn mein Handy in der Nähe ist habe ich öfter mal Checksum Error...beim nächsten Versuch wird aber ordnungsgemäß übermittelt. Vielleicht liegt es auch an dem dünnen Jumperdraht.
5.) Um eine Batterieanzeige zu bekommen nutze ich derzeit den "SystemStatus" (https://github.com/cano64/ArduinoSystemStatus)
6.) Wenn ich den Sendepin als Input definiere, fängt mein Sender an ein durchgehendes Signal zu senden. Das muss ich nochmal prüfen...
Noch offen:
1.) Batterieanzeige testen, Genauigkeit?
2.) Überprüfen, wie sich der Stromverbrauch verhällt und diesen optimieren
3.) Testen, ob es vielleicht auch mit 1MHz (also mit gesetztem "Divide clock by 8") noch funktioniert und ob sich das auf den Stromverbrauch auswirkt
4.) Spannungsversorgung mit 1x oder 2x AA Batterien / StepUp (Messen, was optimaler ist)
5.) Power-LED auslöten
Die noch offenen Punkte werde ich abarbeiten, wenn die Bestellte Hardware eintrifft. Das wird wohl noch etwas dauern.
Meinen aktuellen Zwischenstand habe ich mal angefügt.
Vielen Dank für die Hilfe und auch die Vorlage hier! Wenn ich soweit bin, werde ich nochmal genauere Schaltpläne und das fertige Programm hier posten.
Gruß
Bismosa
Hallo an alle,
ich versuche seit einiger Zeit das Projekt hier aus diesen Thema (siehe ZIP Datei ) auf den Attiny85 zu bekommen. Ich mache das mit Arduino IDE auf und bekomme schon beim Sketch prüfen Fehlermeldungen (siehe Bild ).
Geht das gar nicht Arduino IDE? Ich wollte es dann weiter mit einen Arduino Nano als ISP auf den Attiny85 brennen aber soweit komme ich gar nicht wegen der Fehler beim Sketch prüfen.
Bin für jeden Tipp dankbar.
Danke
Gruß
Jörg
Hallo,
das Problem hatte ich auch...
Ich habe die Kommentare alle entfernt, den gesamten Text markiert in Notepad++ die Zeilenenden in Unix konvertiert...und dann ging es :)
Gruß
Bismosa
Hallo,
danke für den Tipp werde ich die Tage testen.
Gruß
Jörg
Hallo,
so habs doch gleich probiert. Also die Kommentare zu entfernen hat gereicht. Habs auch schon hochgeladen mit dem Arduino Nano als ISP. Kanns leider nur nicht testen. Muß erst in den Garten fahren weil da der Raspi mit FHEM und dem Signalduino ist. Hoffe das Teil läuft auf anhieb.
Danke
Gruß
Jörg
Hallo,
meine Hardware ist nun endlich da. Daher konnte ich nun endlich weiter testen.
Mein Versuchsaufbau ist identisch mit dem Schaltplan https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image allerdings mit einem DHT22.
Mein grobes Ziel ist es:
- 1 Messwert pro Minute
- ca. 1 Jahr Batterielaufzeit (am liebsten mit 1xAA oder 2xAAA...realistisch wird aber eher nur 2xAA möglich werden.)
Daher habe ich jetzt erst einmal den Verbauch versucht zu messen. Leider ist mein Multimeter nicht schnell genug...aber es gibt schon mal "grobe Richtwerte".
Da beim Senden kurzzeitig mehr verbraucht wird, bilde ich einen groben Schnitt.
Hier meine Messergebnisse:
Gerechnet wurde mit https://oregonembedded.com/batterycalc.htm
Annahmen:
Laufzeit pro Mess/Sendevorgang: 3000ms
Obere Reihe: 1 Wert pro Minute
Untere Reihe: 1 Wert alle 5 Min.
Es wird bei dem Rechner mit einem Verlust von 15% durch Selbstentladung der Batterie gerechnet!
Es wurde nicht berücksichtigt, das durch eine leerer werdende Batterie der Strombedarf (insbesondere beim StepUp) ansteigt
Standby [mA] Lesen/Senden [mA] Lebensdauer Capacity rating of battery (mAh)
1,5V/StepUp 0,09 30 55,84 Tage 0,15 Jahre 2500
0,09 30 227,56 Tage 0,62 Jahre 2500
3V/StepUp 0,03 15 113,73 Tage 0,31 Jahre 2500
0,03 15 492,72 Tage 1,35 Jahre 2500
3V/StepUp CR2032 0,03 15 10,92 Tage 0,03 Jahre 240
0,03 15 47,3 Tage 0,13 Jahre 240
3V CR2032 0,023 5 31,27 Tage 0,09 Jahre 240
0,023 5 116,81 Tage 0,32 Jahre 240
3v CR2450 0,023 5 75,56 Tage 0,21 Jahre 580
0,023 5 282,28 Tage 0,77 Jahre 580
Eigentlich fast selbsterklärend. Mein erstes Fazit daraus ist:
- Das reicht für meine Anwendung noch lange nicht. Da muss noch einiges Optimiert werden
- Der Standby-Verbrauch von 0,09mA ist m.E. gering genug um hier mit einem StepUp arbeiten zu können. Nur im Standby sollte eine AA Batterie 983 Tage durchhalten.
- Wichtig ist der Verbrauch im Betrieb. Die Laufzeit zu verkürzen bringt am meisten!
- Durch den StepUp ist es möglich die Batterien komplett bis zum Ende (0,9V) zu verwenden.
Ich frage mich, wie die Billigen Baumarktthermometer es schaffen mit 2 AAA Batterien eine Laufzeit von über 1 Jahr zu realisieren und dabei auch einen Messwert pro Minute senden...
Hier ist übrigens ein ähnliches Projekt: https://crycode.de/diy-funk-wetterstation-mit-dht22-attiny85-und-radiohead
Ich werde mir jetzt die Software nochmal genauer anschauen müssen. Mal schauen, wie sich das optimieren lässt.
@juergs
Du hast in deinem Sketch
Zitat
//--- The sensor can only be read from every 1-2s, and requires a minimum
//--- 2s warm-up after power-on.
LaCrosse.sleep(2); //--- two seconds, no deep sleep
Woher kommt diese Wartezeit? Weder im Datenblatt noch in anderen Beispielen konnte ich dies finden.
Ist die Wartezeit von 1sek. zwischen dem Senden von Temperatur und Luftfeuchtigkeit wirklich nötig?
Das werde ich als nächstes testen...
Gruß
Bismosa
Zitat von: bismosa am 04 Januar 2018, 09:52:13
@juergs
Du hast in deinem Sketch Woher kommt diese Wartezeit? Weder im Datenblatt noch in anderen Beispielen konnte ich dies finden.
Ist die Wartezeit von 1sek. zwischen dem Senden von Temperatur und Luftfeuchtigkeit wirklich nötig?
Das werde ich als nächstes testen...
Gruß
Bismosa
Hallo bismosa,
Die Wartezeit ist empirisch...
Ich habe hier in meinem Umfeld ziemlich viele 433MHz-Sender. Z.B. 2 Stück, die im 10Sek-Rythmus mehr als 10 Repetitions des Telegramms senden.
Du kannst Dir vorstellen, dass sich da einige Telegramme einfach gegenseitig überlagern und durch die "Störung" nicht ankommen,
dann gilt auch das Recht des Stärkeren ...
Hatte auch versucht, die Wartezeiten random zu gestalten um eine Lücke bzw. ein Durchkommen des Sensorwertes zu ermöglichen.
Wenn Du ca. 10 Sensoren über dieses Protokoll anbindest (z.B. Bodenfeuchte für jeden Blumentopf ::) ) wird es interessant.
Um die Lebensdauer der Batterie zu schonen, kannst Du auch noch die Sendeleistung berücksichtigen, die sind von Sendemodul zu Sendemodul sehr unterschiedlich.
D.h. mit der Auswahl des Moduls beeinträchtigt man auch die Batterie-Lebensdauer kommt aber u.U. nicht so weit.
Die 9 µA waren bei mir auch realistisch während des SendeImpulses ....
Andererseits muss man nicht bei sich langsam verändernden Messwerten alle 20 Sekunden einen Wert senden,
da reichen 10 Minuten auch aus.
Hi Leutz,
nur zum Verständnis, das hier verwendete LaCrosse Protokoll wird doch auch vom SignalDuino unterstützt, richtig?
Einen Signalduino mit RXB6 433 Mhz Superheterodyne Empfänger habe ich, dann könnte ich mir dieses interessante Projekt auch mal vornehmen :)
Beste Grüße
Mike
Es schein mehere Synonyme für "LaCrosse Protokol" zu geben.
Hier ist das "CUL_TX" Protokoll auf 433MHz und OOK gemeint.
Sollte also mit der aculw normalerweise gehen, wenn es dort in die Firmware mit
compiliert worden ist ... (gilt für CUL - CC1101)
: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:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki::SD_WS07:
Schade, hätte gerne mitgespielt :(
Trotzdem ein sehr interessantes Projekt, ich sollte mir so einen 433mhz Cul basteln.
Grüße
Mike
Das hast Du falsch verstanden, der Signalduino sollte gehen ... ;)
Hallo juergs,
danke für die Info, dann werde ich mir den ATtiny 85 besorgen. :)
aber hatte ich nicht auch gelesen, dass zum Testen eine Arduino Version der Software existiert ?!?!?
Grüße
Mike
Ja, hier: @github.com (https://github.com/juergs) ;)
Hallo juergs,
danke für Link, aber ich hatte schon deinen Download auf Seite zwei (LaCrosse_Nano_Dallas_4Fach.zip) heruntergeladen und auf einen UNO losgelassen.
Funktioniert aber nicht mit meinem Signalduino (RXB6 433 Mhz Superheterodyne Empfänger)
Der Sketch scheint schon zu funktionieren, im Ser.Monitor sehe ich .....
Hello from NANO ...
SensorID: 105 First: 23.19
SensorID: 106 Second: 0.00
SensorID: 107 Third: 0.00
SensorID: 108 Fourth: 0.00
Pause-Delay (Rand): 34816
In gqrx (software defined radio receiver) kann ich sehen und hören das Daten gesendet werden.
Aber mein SingnalDuino empfängt keine Daten!
READINGS:
2017-02-26 19:50:51 cmds V i R t X F S P C G
2017-02-26 19:50:35 config MS=1;MU=1;MC=1
2018-01-03 16:31:03 ping OK
2018-01-07 15:42:21 state opened
2018-01-07 15:42:21 version V 3.3.1-dev SIGNALduino - compiled at Jan 3 2017 23:59:32
keepalive:
Grüße
Mike
Ich kenne mich mit dem Nicht-CC1101 nicht so aus, aber möglicherweise kannst Du das Protokoll noch hinzukomplieren?
Zitat2017-02-26 19:50:51 cmds V i R t X F S P C G
Hallo juergs,
ich hab mich mal in die Kommunikation zwischen Signalduino und Raspberry eingeklinkt ....
.MU;P0=102;P1=236;P2=-2192;P3=971;P6=-21542;D=01230303030103010303030303010103010303010303010101030301030103030303010101030301030303010163030303010301030303030301010301030301030301010103030103010303030301010103030103030301016303030301030103030303030101030103030103030101010303010301030303030101010303;CP=0;O;.
.MU;P0=-1483;P1=239;P2=970;P3=-21544;D=01020202010132020202010201020202020201010201020201020201010102020102010202020201010102020102020201013202020201020102020202020101020102020102020101010202010201020202020101010202010202020101;CP=1;.
.MU;P0=-168;P1=420;P2=-416;P3=968;P4=-1491;P5=242;P6=-21536;D=01234343434543454343434343454543454345434543454345434343434343434343454345434343434345454363434343454345434343434345454345434543454345434543434343434343434345434543434343434545436343434345434543434343434545434543454345434543454343434343434343434543454343;CP=3;O;.
.MU;P0=-1483;P1=969;P2=236;P3=-21542;D=01010102020131010101020102010101010102020102010201020102010201010101010101010102010201010101010202013101010102010201010101010202010201020102010201020101010101010101010201020101010101020201;CP=1;.
.MU;P0=-32001;P1=112;P2=-8408;P3=968;P4=-1490;P5=239;P6=-21542;D=01234343434543454343434343454543454345454343454345434343434343434343454345434343434345454563434343454345434343434345454345434545434345434543434343434343434345434543434343434545456343434345434543434343434545434543454543434543454343434343434343434543454343;CP=3;O;.
.MU;P0=-1483;P1=968;P2=240;P3=-21542;D=01010102020231010101020102010101010102020102010202010102010201010101010101010102010201010101010202023101010102010201010101010202010201020201010201020101010101010101010201020101010101020202;CP=1;.
.MU;P0=-32001;P1=969;P2=-1483;P3=237;P4=-21542;D=01212121232123212121212123232123232121232123212321212121212121212123212321212121232123214121212123212321212121212323212323212123212321232121212121212121212321232121212123212321412121212321232121212121232321232321212321232123212121212121212121232123212121;CP=1;O;.
.MU;P0=-1485;P1=967;P2=236;P3=-21536;D=010201020131010101020102010101010102020102020101020102010201010101010101010102010201010101020102013101010102010201010101010202010202010102010201020101010101010101010201020101010102010201;CP=1;.
Ja, empfangen wird etwas, aber scheinbar nicht weiter ausgewertet :-\
Vielleicht kann Sidey helfen, würde dem Projekt gut tun und ein größerer Benutzerkreis könnte die Anwendung nutzen.
Vielleicht ist ein cc1101 für 433Mhz doch eine gute Idee.
Grüße
Mike
Hier geschaut? https://github.com/RFD-FHEM/RFFHEM (https://github.com/RFD-FHEM/RFFHEM) da ist TX3 dabei.
Hier ebenfalls: https://wiki.fhem.de/wiki/SIGNALduino (https://wiki.fhem.de/wiki/SIGNALduino)
ZitatVielleicht ist ein cc1101 für 433Mhz doch eine gute Idee.
Schau Dir mal den
MapleCULvon
locutus oder
ranseyer an...
Ein
NanoCUL ist ebenfalls schnell aufgebaut (https://wiki.fhem.de/wiki/Selbstbau_CUL) ...
;D
Hallo juergs,
bis auf MapleCUL waren mir deine Bespiele schon bekannt.
ZitatVielleicht ist ein cc1101 für 433Mhz doch eine gute Idee.
damit meine ich schon den nanocul, für 886Hmz habe ich ihn in Betrieb (HomeMatic)
Grüße
Mike
Zitat von: CatWeazle am 07 Januar 2018, 17:09:28
.MU;P0=102;P1=236;P2=-2192;P3=971;P6=-21542;D=01230303030103010303030303010103010303010303010101030301030103030303010101030301030303010163030303010301030303030301010301030301030301010103030103010303030301010103030103030301016303030301030103030303030101030103030103030101010303010301030303030101010303;CP=0;O;.
.MU;P0=-1483;P1=239;P2=970;P3=-21544;D=01020202010132020202010201020202020201010201020201020201010102020102010202020201010102020102020201013202020201020102020202020101020102020102020101010202010201020202020101010202010202020101;CP=1;.
.MU;P0=-168;P1=420;P2=-416;P3=968;P4=-1491;P5=242;P6=-21536;D=01234343434543454343434343454543454345434543454345434343434343434343454345434343434345454363434343454345434343434345454345434543454345434543434343434343434345434543434343434545436343434345434543434343434545434543454345434543454343434343434343434543454343;CP=3;O;.
.MU;P0=-1483;P1=969;P2=236;P3=-21542;D=01010102020131010101020102010101010102020102010201020102010201010101010101010102010201010101010202013101010102010201010101010202010201020102010201020101010101010101010201020101010101020201;CP=1;.
.MU;P0=-32001;P1=112;P2=-8408;P3=968;P4=-1490;P5=239;P6=-21542;D=01234343434543454343434343454543454345454343454345434343434343434343454345434343434345454563434343454345434343434345454345434545434345434543434343434343434345434543434343434545456343434345434543434343434545434543454543434543454343434343434343434543454343;CP=3;O;.
.MU;P0=-1483;P1=968;P2=240;P3=-21542;D=01010102020231010101020102010101010102020102010202010102010201010101010101010102010201010101010202023101010102010201010101010202010201020201010201020101010101010101010201020101010101020202;CP=1;.
.MU;P0=-32001;P1=969;P2=-1483;P3=237;P4=-21542;D=01212121232123212121212123232123232121232123212321212121212121212123212321212121232123214121212123212321212121212323212323212123212321232121212121212121212321232121212123212321412121212321232121212121232321232321212321232123212121212121212121232123212121;CP=1;O;.
.MU;P0=-1485;P1=967;P2=236;P3=-21536;D=010201020131010101020102010101010102020102020101020102010201010101010101010102010201010101020102013101010102010201010101010202010202010102010201020101010101010101010201020101010102010201;CP=1;.
Ja, empfangen wird etwas, aber scheinbar nicht weiter ausgewertet :-\
Ich habe mir das angesehen.
Also nach meinen Informationen wird hier nicht so moduliert, wie es ein TX3 Sensor macht.
Die Zeiten, mit denen ein TX3 Sensor die Daten modulieren sollte, kann man hier nachsehen:
http://www.f6fbb.org/domo/sensors/tx_signals.php
Woher nun die Modulierung stammt, weiss ich nicht. Ich habe diese Modulierung in das SIGNALduino Modul unter Protokoll ID 77 eingebaut.
Installation des Moduls geht mit Folgendem Befehl:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
Das neue Protokoll lässt sich aktivieren, in dem die Attribute im Folgende Werte ergänzt werden:
attr dummyDuino development 77y
attr dummyDuino whitelist_IDs 77
Ich hatte mich vor einiger Zeit auch mal mit dem Senden von Sensoren beschäftigt.
Damals hatte ich mir ein eigenes sehr schlankes Protokoll ausgedacht mit dem sich eine Vielzahl an Sensoren realisieren lässt. Da ich möglichst kurze Sendezeiten realisieren wollte, habe ich das ganze Manchestercodiert realisiert.
Die ganzen Überlegungen sind in dieses Projekt geflossen.
https://github.com/RFD-FHEM/ArduinoSensor
Grüße Sidey
Hallo Sidey,
danke fürs drüberschauen.
Den RFD-FHEM/ArduinoSensor habe ich mir auch angeschaut.
Grüße,
Jürgen
Hallo Sidey,
vielen Dank fürs einbauen, jetzt Plappert SignalDuino aber mal so richtig los ......
2018-01-08 23:46:53 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:53 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 3
2018-01-08 23:46:53 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 1 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 1 1 0 1 0 1 0 1 0 1 0 0 0
2018-01-08 23:46:53 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5FDAAADAA8 length 44
2018-01-08 23:46:53 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5FDAAADAA8, test ungleich: disabled
2018-01-08 23:46:53 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5FDAAADAA8, dispatch
2018-01-08 23:46:55 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=969;P1=-1493;P2=240;P3=-21508;D=01010121012101010101012121012101012101012121210101210121010101012121210101210101012123010101012101210101010101212101210101210101212121010121012101010101212121010121010101212301010101210121010101010121210121010121010121212101012101210101010121212101012101;CP=2;O;
2018-01-08 23:46:55 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:55 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 0
2018-01-08 23:46:55 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 1 1 0 0 0 1 1 0 1 0 1 1 1 1 0 0 0 1 1 0 1 1 1 0 0
2018-01-08 23:46:55 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2D8D78DC length 44
2018-01-08 23:46:55 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2D8D78DC, test ungleich: disabled
2018-01-08 23:46:55 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2D8D78DC, dispatch
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=989;P1=-1459;P2=262;P3=-21492;D=010121230101010121012101010101012121012101012101012121210101210121010101012121210101210101012123010101012101210101010101212101210101210101212121010121012101010101212121010121010101212;CP=2;
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 0
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 1 1 0 0 0 1 1 0 1 0 1 1 1 1 0 0 0 1 1 0 1 1 1 0 0
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2D8D78DC length 44
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2D8D78DC, test gleich
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2D8D78DC, Dropped due to short time or equal msg
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 1 1 0 0 0 1 1 0 1 0 1 1 1 1 0 0 0 1 1 0 1 1 1 0 0
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2D8D78DC length 44
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2D8D78DC, test gleich
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2D8D78DC, Dropped due to short time or equal msg
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-380;P1=1007;P2=-1444;P3=250;P5=-21498;D=01212121212323212321232123212321232121212121212121212321232121212121232321512121212321232121212121232321232123212321232123212121212121212121232123212121212123232151212121232123212121212123232123212321232123212321212121212121212123212321212121212323215121;CP=1;O;
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 0 0
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2AAFFAF8 length 44
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2AAFFAF8, test ungleich: disabled
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2AAFFAF8, dispatch
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 0 0
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2AAFFAF8 length 44
2018-01-08 23:46:56 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2AAFFAF8, test gleich
2018-01-08 23:46:56 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2AAFFAF8, Dropped due to short time or equal msg
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1454;P1=991;P2=265;P3=-21484;D=0101020102010101010102020102010201020102010201010101010101010102010201010101010202013101010102010201010101010202010201020102010201020101010101010101010201020101010101020201;CP=1;
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 0 0
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2AAFFAF8 length 44
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2AAFFAF8, test gleich
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2AAFFAF8, Dropped due to short time or equal msg
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=496;P1=-1446;P2=1004;P3=252;P5=-21498;D=01212121212131312131213131212131213121212121212121212131213121212121213131352121212131213121212121213131213121313121213121312121212121212121213121312121212121313135212121213121312121212121313121312131312121312131212121212121212121312131212121212131313521;CP=2;O;
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 2
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 0 0
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F29AFFAF8 length 44
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F29AFFAF8, test ungleich: disabled
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F29AFFAF8, dispatch
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 0 0
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F29AFFAF8 length 44
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F29AFFAF8, test gleich
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F29AFFAF8, Dropped due to short time or equal msg
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=991;P1=-1457;P2=264;P3=-21492;D=01010121012101010101012121012101212101012101210101010101010101012101210101010101212123010101012101210101010101212101210121210101210121010101010101010101210121010101010121212;CP=0;
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 0
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 0 0
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F29AFFAF8 length 44
2018-01-08 23:46:57 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F29AFFAF8, test gleich
2018-01-08 23:46:57 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F29AFFAF8, Dropped due to short time or equal msg
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-272;P1=132;P2=1002;P3=-1463;P4=250;P6=-21504;D=01023232323234343234343232343234323432323232323232323234323432323232343234326232323234323432323232323434323434323234323432343232323232323232323432343232323234323432623232323432343232323232343432343432323432343234323232323232323232343234323232323432343262;CP=2;O;
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 3
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 0 1 1 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 0 1 0 0
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F26AFFAF4 length 44
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F26AFFAF4, test ungleich: disabled
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F26AFFAF4, dispatch
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 0 1 1 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 0 1 0 0
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F26AFFAF4 length 44
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F26AFFAF4, test gleich
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F26AFFAF4, Dropped due to short time or equal msg
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1453;P1=992;P2=265;P3=-21488;D=010101020102010101010102020102020101020102010201010101010101010102010201010101020102013101010102010201010101010202010202010102010201020101010101010101010201020101010102010201;CP=1;
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 0 1 1 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 0 1 0 0
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F26AFFAF4 length 44
2018-01-08 23:46:58 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F26AFFAF4, test gleich
2018-01-08 23:46:58 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F26AFFAF4, Dropped due to short time or equal msg
2018-01-08 23:47:01 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=744;P1=-1057;P2=452;P3=1440;P4=-17828;D=012131313121212121212121213121213131213124;CP=2;
2018-01-08 23:47:01 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-08 23:47:01 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 0
2018-01-08 23:47:04 SIGNALduino sduino sduino 4: sduino/keepalive ok, retry = 0
2018-01-08 23:47:04 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=460;P1=-3920;P2=-1972;P3=-9126;D=03020102010201010201020102020202020202020202020101020202010202010201010101;CP=0;SP=3;
2018-01-08 23:47:05 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-4100;P1=156;P2=-3080;P3=1191;P4=-1003;P6=465;P7=-25160;D=01234343434643464343434343434646434343464343464346434643434343434643464346434643434346434673434343464346434343434343464643434346434346434643464343434343464346434643464343434643467;CP=3;
2018-01-08 23:47:05 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2018-01-08 23:47:05 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 3
2018-01-08 23:47:05 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 0 1 0
2018-01-08 23:47:05 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#F5F9DABEABA length 44
2018-01-08 23:47:05 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 0 1 0
2018-01-08 23:47:05 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#F5F9DABEABA length 44
2018-01-08 23:47:11 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=532;P1=-128;P2=1349;P3=-1158;D=01232323230323032323232323232303030303232323032303230323232303030323032303230323232323032;CP=0;
2018-01-08 23:47:11 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-32001;P1=1379;P2=-1130;P3=563;D=0121212123212321212121212121232323232121212321232123212121232323212321232123212121212321;CP=3;
2018-01-08 23:47:13 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P1=502;P2=-3877;P3=-1931;P4=-9186;D=14131213121213121212131213121313131313131313131212131312121312131312121313;CP=1;SP=4;O;
2018-01-08 23:47:13 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=-1931;P1=506;P2=-3889;P3=-9142;D=13101210121210121212101210121010101010101010101212101012121012101012121010;CP=1;SP=3;O;
2018-01-08 23:47:15 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P1=421;P2=-2017;P3=-4581;P4=-9596;D=1412131313121312121212121312121212121213121312131312131312;CP=1;SP=4;O;
2018-01-08 23:47:15 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P1=468;P2=-1973;P3=-3928;P4=-9199;D=14121312131313131312131313121212121212121212121312131312131212121313121212;CP=1;SP=4;O;
2018-01-08 23:47:16 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=1466;P1=-1036;P2=483;D=0121010121010121012121210101010101012121010101210121010121212121010101212121012;CP=2;
2018-01-08 23:47:16 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-32001;P1=470;P2=-1960;P3=-3923;P4=-9076;P5=-24184;D=01213121313131313121313131212121212121212121213121313121312121213131212121415;CP=1;
2018-01-08 23:47:16 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=2066;P1=-853;P2=3539;P3=-2319;D=010101012103010123010101010101012321010301210;CP=0;
2018-01-08 23:47:16 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-2263;P1=2116;P2=-795;P4=-3804;P5=6172;P6=-6268;P7=3602;D=121212121212121212121456121270121212127210121270121212121212127072121012721;CP=1;
Ein Gerät wird übrigens nicht angelegt.
Dein RFD-FHEM/ArduinoSensor habe ich mir angesehen.
So fit bin ich nicht in c+ / Arduino.
Leider fehlt mir das Verständniss, wie ich die lib nun aus einem sketch heraus anspreche.
Gibt es einen sketch, der diese lib benutzt und wenn er nur statisch ein paar Daten sendet, könnte man darauf aufbauen.
Grüße
Mike
EDIT:
es wurde doch ein Gerät angelegt!
2018.01.08 23:36:21 2: CUL_TX Unknown device 121, please define it
2018.01.08 23:36:21 2: autocreate: define CUL_TX_121 CUL_TX 121
2018.01.08 23:37:47 2: CUL_TX 5 CUL_TX_121 121 (XF5F2C8DC8D0) unknown type
Hi Leutz,
ich habe den vier Sensoren mal eindeutige werde gegeben.
SensorID: 105 First: 7.11
SensorID: 106 Second: 13.22
SensorID: 107 Third: 19.33
SensorID: 108 Fourth: 27.44
Daraus resultiert ......
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P1=-1499;P2=237;P3=-21495;P7=965;D=12123717171712171217171717171212171217171212171217121712121217171712171217121712121217171212371717171217121717171717121217121717121217121712171212121717171217121712171212121717121237171717121712171717171712121712171712121712171217121212171717121712171217;CP=2;O;
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 0 0
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2CA8EA8C length 44
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2CA8EA8C, test ungleich: disabled
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2CA8EA8C, dispatch
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 0 0
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2CA8EA8C length 44
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2CA8EA8C, test gleich
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2CA8EA8C, Dropped due to short time or equal msg
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1451;P1=268;P2=995;P3=-22394;D=01010102020101320202020102010202020202010102010202010102010201020101010202020102010201020101010202010132020202010201020202020201010201020102010201010202020101020201020201010202020101020202023202020201020102020202020101020102010201020101020202010102020102;CP=1;O;
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 0 0
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2CA8EA8C length 44
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2CA8EA8C, test gleich
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2CA8EA8C, Dropped due to short time or equal msg
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 0 1 1 1 0 0 1 1 0 1 1 0 0 1 1 1 0 0 1 1 1 0
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2A9CD9CE length 44
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2A9CD9CE, test ungleich: disabled
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2A9CD9CE, dispatch
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1453;P1=995;P2=273;P3=-21485;D=01020201010102020101010131010101020102010101010102020102010201020102020101010202010102010102020101010202010101013101010102010201010101010202010201020102010202010101020201010201010202010101020201010101310101010201020101010101020201020102010201020201010102;CP=2;O;
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 0 1 1 1 0 0 1 1 0 1 1 0 0 1 1 1 0 0 1 1 1 0
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2A9CD9CE length 44
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2A9CD9CE, test gleich
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2A9CD9CE, Dropped due to short time or equal msg
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 0 1 1 1 0 0 1 1 0 1 1 0 0 1 1 1 0 0 1 1 1 0
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2A9CD9CE length 44
2018-01-09 00:22:09 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2A9CD9CE, test gleich
2018-01-09 00:22:09 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2A9CD9CE, Dropped due to short time or equal msg
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1458;P1=270;P2=1000;P3=-21934;D=01020201020201010202020101020202023202020201020102020202020101020102010101020101020102020102020101020101020102020101010101320202020102010202020202010102010201010102010102010202010202010102010102010202010101010132020202010201020202020201010201020101010201;CP=1;O;
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 1 0 1 1 0 1 1 0 0 1 0 0 1 0 1 1 0 0 0 0 0
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2896C960 length 44
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2896C960, test ungleich: disabled
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2896C960, dispatch
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 1 0 1 1 0 1 1 0 0 1 0 0 1 0 1 1 0 0 0 0 0
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2896C960 length 44
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2896C960, test gleich
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2896C960, Dropped due to short time or equal msg
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1464;P1=270;P2=1000;P3=-22569;D=01020102020102020101020101020102020101010101320202020102010202020202010102010201010102010102010202010202010102010102010202010101010132020202010201020202020201010201020101010201010201020201020201010201010201020201010101013202020201020102020202020101020101;CP=1;O;
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 1 0 1 1 0 1 1 0 0 1 0 0 1 0 1 1 0 0 0 0 0
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2896C960 length 44
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2896C960, test gleich
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2896C960, Dropped due to short time or equal msg
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 1 0 1 1 0 1 1 0 0 1 0 0 1 0 1 1 0 0 0 0 0
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2896C960 length 44
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2896C960, test gleich
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2896C960, Dropped due to short time or equal msg
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1448;P1=1000;P2=271;P3=-21479;D=01010201020202010202020102010101020202010202020101010131010101020102010101010102020102020101020102020201020202010201010102020201020202010101013101010102010201010101010202010202010102010202020102020201020101010202020102020201010101310101010201020101010101;CP=2;O;
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 0 1 1 0 1 0 0 0 1 0 0 0 1 0 1 1 1 0 0 0 1 0 0 0 1 1 1 0
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2688B88E length 44
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2688B88E, test ungleich: disabled
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2688B88E, dispatch
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 0 1 1 0 1 0 0 0 1 0 0 0 1 0 1 1 1 0 0 0 1 0 0 0 1 1 1 0
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2688B88E length 44
2018-01-09 00:22:10 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2688B88E, test gleich
2018-01-09 00:22:10 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2688B88E, Dropped due to short time or equal msg
2018-01-09 00:22:11 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1454;P1=268;P2=996;P3=-21480;D=01010201010202010201010102010101020102020201010102010101020202023202020201020102020202020101020101020201020101010201010102010202020101010201010102020202;CP=1;
2018-01-09 00:22:11 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-09 00:22:11 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:11 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 0 1 1 0 1 0 0 0 1 0 0 0 1 0 1 1 1 0 0 0 1 0 0 0 1 1 1 0
2018-01-09 00:22:11 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXF5F2688B88E length 44
2018-01-09 00:22:11 SIGNALduino sduino sduino 5: sduino Dispatch: TXF5F2688B88E, test gleich
2018-01-09 00:22:11 SIGNALduino sduino sduino 4: sduino Dispatch: TXF5F2688B88E, Dropped due to short time or equal msg
2018-01-09 00:22:11 SIGNALduino sduino sduino 4: sduino/msg READ: MC;LL=-1000;LH=1535;SL=-464;SH=663;D=AAAAAAAAAA8;C=610;L=42;
2018-01-09 00:22:11 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-232;P1=1416;P2=-1086;P3=614;P4=-21380;D=012121232123212121212121212323232321232123212321232121232121232123212321232121212321234;CP=3;
2018-01-09 00:22:13 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=502;P3=-1937;P4=-3877;P5=-9170;D=05030403040403040404030403040303030303030303030404030403040304030304030404;CP=0;SP=5;O;
2018-01-09 00:22:13 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=512;P1=-1924;P2=-3878;P3=-9150;D=03010201020201020202010201020101010101010101010202010201020102010102010202;CP=0;SP=3;
2018-01-09 00:22:15 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=-3932;P1=451;P2=-1986;P3=-9221;D=13121012101010101012101010121212121212121212121012101010121212121010121212;CP=1;SP=3;O;
2018-01-09 00:22:16 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=-1973;P1=464;P2=-3926;P3=-9198;P4=328;D=13401210121212121210121212101010101010101010101210121212101010101212101010;CP=1;SP=3;O;
2018-01-09 00:22:16 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-2324;P1=2058;P2=-828;P4=-3936;P5=6068;P6=-6368;P7=3536;D=012121212121212121212121456121270121212121212701270121212121212127012121270721;CP=1;
2018-01-09 00:22:16 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=6180;P1=-6260;P2=2122;P3=-801;P4=3606;P5=-2230;D=01232345232323232323452345232323232323234523232345432;CP=2;
2018-01-09 00:22:18 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-500;P1=1196;P2=-1022;P3=444;P5=-26704;D=01212121232123212121212121232321212123212123212321232121212121232123212321232121212321235121212123212321212121212123232121212321212321232123212121212123212321232123212121232123;CP=1;
2018-01-09 00:22:18 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2018-01-09 00:22:18 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-09 00:22:18 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 0 1 0
2018-01-09 00:22:18 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#F5F9DABEABA length 44
2018-01-09 00:22:18 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 0 1 0
2018-01-09 00:22:18 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#F5F9DABEABA length 44
Die 44 dispatching bits wiederholen sich bei einer Übertragung meist drei Mal.
Es gibt auch nur diese vier dispatching bits Reihen, die wiederholen sich hier ganz munter im EventMonitor.
Ich gehe davon aus, das sich darin die vier Sensor-IDs und deren Temperaturen verstecken.
1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 0 0
1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 0 1 1 1 0 0 1 1 0 1 1 0 0 1 1 1 0 0 1 1 1 0
1 1 1 1 0 1 0 1 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 1 0 1 1 0 1 1 0 0 1 0 0 1 0 1 1 0 0 0 0 0
1 1 1 1 0 1 0 1 1 1 1 1 1 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 0 1 0
Mal dran bleiben.
Grüße
Mike
Hi,
Die Daten werden an das CUL_TX Modul übergeben.
Ich hatte aus den vorherigen Posts entnommen, dass dieses Modul die Daten auswerten soll.
So wie das aber aussieht, wertet das Modul die Daten nicht aus.
Vielleicht kann das jemand bestätigen/ negieren, ob das CUL_TX Modul die Daten auswerten kann.
Gruß Sidey
Gesendet von meinem XT1650 mit Tapatalk
Hallo Sidey,
es wäre schön, wenn die Daten ausgewertet würden.
Ich habe heute gesehen, dass die 44 dispatching bits nur die Kennung und und nicht die Daten enthalten!
Nachdem ich die Werte für Temperatur geändert habe, blieben die vier dispaching bits gleich!
(Also die gleichen vier verschiedenen wie zuvor)
Sie sind demnach für mein Verständnis nur die Gerätekennung, bzw. die SensorID 105, 106, 107, 108
Aber wie schon mal erwähnt, dein RFD-FHEM/ArduinoSensor interessiert mich auch.
Ein einfacher Beispiel-Sketch, der die lib nutzt und so einen vorgegebenen Wert an SignalDuino übermittelt würde reichen.
Grüße
Mike
EDIT:
Nochmal geloggt, die dispatching bits ändern sich scheinbar doch mit anderen Werten, ich muss das nochmal prüfen ....
Hi,
In den 44 Bits stecken alle Daten, welche gesendet werden.
Soweit ich die Lacrosse Lib verstanden habe, sendet die 44 Bit je Nachricht. Jede Nachricht wird 5* mit einer Pause von 20 MS übermittelt. Entweder wird die Temperatur oder die Feuchtigkeit übermittelt.
Es werden also erst 5* 44 Bits für Temp und dann 5* 44 Bits für Feuchte übertragen.
Macht 10* 44 Bits, wenn man Feuchte und Temperatur übermitteln möchte.
In dem Sketch werden 4 Temp Sensoren abgebildet.
Also je Sensor 5*44 Bit.
Dann kommt eine Zufällige Zusatzpause von 1001-3000 uS zwischen den Sensoren.
In Summe 20*44 Bit
Gesendet von meinem XT1650 mit Tapatalk
Hallo Sidey,
das entspricht im Groben dem, was ich gerade in meinem EDIT geschrieben Habe :-)
Grüße
Mike
EDIT:
Oooops, ich hatte Firefox nicht aktualisiert als ich mein Posting von 12:24 editiert habe.
Und so nicht gesehen, dass du schon einen weiteren Beitrag geschrieben hattest.
Aber das macht ja nichts :)
ich habe es mal mit dieser Nachricht
MU;P0=-1451;P1=268;P2=995;P3=-22394;D=01010102020101320202020102010202020202010102010202010102010201020101010202020102010201020101010202010132020202010201020202020201010201020102010201010202020101020201020201010202020101020202023202020201020102020202020101020102010201020101020202010102020102;CP=1;O;
und meiner V 3.3.2r-dev Firmware getestet, es sieht recht gut aus.
Ich habe daraus ein Sendekommando gemacht:
SR;P0=-1451;P1=268;P2=995;P3=-22394;D=320202020102010202020202010102010202010102010201020101010202020102010201020101010202010132020202010201020202020201010201020102010201010202020101020201020201010202020101020202023;
Die Firmware hat dann die Nachricht an der Wiederholungspause getrennt und zwei MU-Nachrichten ausgegeben
MU;P2=-22394;P3=995;P4=-1451;P5=268;D=2343434345434543434343434545434543434545434543454345454543434345434543454345454543434545;CP=5;w1;e;
MU;P2=-22394;P3=995;P4=-1451;P5=268;D=23434343454345434343434345454345434543454345454343434545434345434345454343434545434343432;CP=5;e;
Ich habe dann in der 00_Signalduino Protokolldefinition one und zero getauscht
"77" => ## https://github.com/juergs/NANO_DS1820_4Fach
....
zero => [4,-6], #
one => [1,-6], #
Dann habe ich mit den beiden MU-Nachrichten folgendes erhalten:
2018.01.09 18:40:47.983 4 : sduinoD: decoded matched MU Protocol id 77 dmsg TXA0D3571572 length 44
2018.01.09 18:40:47.983 5 : sduinoD: dispatch TXA0D3571572
2018-01-09 18:40:47.984 CUL_TX CUL_TX_105 T: 7.1
2018.01.09 18:42:13.776 4 : sduinoD: decoded matched MU Protocol id 77 dmsg TXA0D5632630 length 44
2018.01.09 18:42:13.776 5 : sduinoD: dispatch TXA0D5632630
2018-01-09 18:42:13.777 CUL_TX CUL_TX_106 T: 13.2
Demnach sind in einer MU-Nachricht alle 4 Temperaturen enthalten.
Gruß Ralf
Hallo zusammen,
aber wird in dem sketch nicht jede Messung Einzel gesendet ?
Sensor_1 / LaCrosse.sendTemperature(); / Pause / Sensor_2 / LaCrosse.sendTemperature(); / Pause usw.
/*---------------- FESTE WERTE -------------------
//--- Sensor_1
// LaCrosse.t = 0.0;
LaCrosse.t = 7.11;
LaCrosse.bSensorId = SENSOR_ID_0;
// ReadSingleOneWireSensor(ds_00);
digitalWrite(PIN_LED, HIGH);
LaCrosse.sendTemperature();
digitalWrite(PIN_LED, LOW);
Serial.print("SensorID: ");
Serial.print((byte)LaCrosse.bSensorId);
Serial.print(" First: ");
Serial.println((double) LaCrosse.t);
randomNumber = random(2000);
delayMicroseconds(1000 + randomNumber );
//--- Sensor_2
digitalWrite(PIN_LED, HIGH);
// LaCrosse.t = 0.0;
LaCrosse.t = 13.22;
// ReadSingleOneWireSensor(ds_01);
LaCrosse.bSensorId = SENSOR_ID_1;
digitalWrite(PIN_LED, HIGH);
LaCrosse.sendTemperature();
digitalWrite(PIN_LED, LOW);
randomNumber = random(2000);
delayMicroseconds(1000 + randomNumber);
Serial.print("SensorID: ");
Serial.print((byte)LaCrosse.bSensorId);
Serial.print(" Second: ");
Serial.println((double)LaCrosse.t);
//--- Sensor_3
//LaCrosse.t = 0.0;
LaCrosse.t = 19.33;
LaCrosse.bSensorId = SENSOR_ID_2;
// ReadSingleOneWireSensor(ds_02);
digitalWrite(PIN_LED, HIGH);
LaCrosse.sendTemperature();
digitalWrite(PIN_LED, LOW);
randomNumber = random(2000);
delayMicroseconds(1000 + randomNumber);
Serial.print("SensorID: ");
Serial.print((byte)LaCrosse.bSensorId);
Serial.print(" Third: ");
Serial.println((double)LaCrosse.t);
//--- Sensor_4
//LaCrosse.t = 0.0;
LaCrosse.t = 27.44;
LaCrosse.bSensorId = SENSOR_ID_3;
//ReadSingleOneWireSensor(ds_03);
digitalWrite(PIN_LED, HIGH);
LaCrosse.sendTemperature();
digitalWrite(PIN_LED, LOW);
Serial.print("SensorID: ");
Serial.print((byte)LaCrosse.bSensorId);
Serial.print(" Fourth: ");
Serial.println((double)LaCrosse.t);
---------------- FESTE WERTE -------------------*/
Aber gut, das schon mal brauchbare Ergebnisse erzielt wurden.
By the way, womit empfangen? Signalduino mit getrenntem Sende- / Empfangsmodul oder einem 433Cul ?!?!?!
Grüße
Mike
Ich habe es damit gesendet und direkt empfangen:
https://forum.fhem.de/index.php/topic,82379.0.html
Gruß Ralf
Zitat von: CatWeazle am 09 Januar 2018, 20:34:14
aber wird in dem sketch nicht jede Messung Einzel gesendet ?
Genau so ist es. 5x die gleiche Nachricht. Dann der Nächste Sensor usw.
Zitat von: CatWeazle am 09 Januar 2018, 20:34:14
Aber gut, das schon mal brauchbare Ergebnisse erzielt wurden.
By the way, womit empfangen? Signalduino mit getrenntem Sende- / Empfangsmodul oder einem 433Cul ?!?!?!
Das hängt davon ab, was Du hast und vielleicht sonst noch empfangen möchtest.
Grüße Sidey
Zitat von: Ralf9 am 09 Januar 2018, 19:17:01
Ich habe daraus ein Sendekommando gemacht:
SR;P0=-1451;P1=268;P2=995;P3=-22394;D=320202020102010202020202010102010202010102010201020101010202020102010201020101010202010132020202010201020202020201010201020102010201010202020101020201020201010202020101020202023;
Das ist je eine Übertragung eines Sensors. Schau es dir mal genau an, dann wirst Du es sehen.
Du müsstest eigentlich jeden Sensor 5x wiederholen um es korrekt nachzustellen.
Die Zuordnung 0 / 1 habe ich tatsächlich vertauscht.
Ich habe das korrigiert.
Grüße Sidey
Der Sketch "sendet" 1x,
LaCrosse.sendTemperature();
aber in der LaCrosse-Klasse wird noch über die Anzahl Repetitions wiederholt (steht wohl bei CatWeazle auch auf 5).
Bei mir funktioniert das Ganze ganz normal ohne Probleme über aculfw / culfw und dem CC1101 oder über den MapleCUL (433MHz).
Jürgen
Hallo Sidey,
ich brauche die 433Mhz nur für IT-Steckdosen, Wetterstationen und Sender nach EV1527 / xx2622.
Ich betreibe daher einen NANO mit Signalduino einem 433Mhz Sendemodul und einem RXB6 Empfänger.
Damit wollte ich auch dieses hier besprochene Projekt empfangen.
Für 868Mhz habe ich einen NanoCul.
Dann ....
ZitatDie Zuordnung 0 / 1 habe ich tatsächlich vertauscht.
Ich habe das korrigiert.
Dann werde ich ein FHEM-Update durchführen, oder wie komme ich an die korrigierte Version?
Grüße
Mike
EDIT:
@juergs:
ja, steht auf 5x "#define REPEATMSG 5"
Zitat von: CatWeazle am 09 Januar 2018, 21:11:14
Dann werde ich ein FHEM-Update durchführen, oder wie komme ich an die korrigierte Version?
Mit dem Updatebefehl von gestern, bekommst Du die angepasste Version.
Grüße Sidey
[OT]
Zitathttps://github.com/RFD-FHEM/ArduinoSensor
auch interessant. FHEM-Modul gibt's aber keins, oder ? [OT]
Zitat von: KölnSolar am 09 Januar 2018, 21:59:13
[OT] auch interessant. FHEM-Modul gibt's aber keins, oder ? [OT]
Doch, ich verteile es nur nicht mit dem normalen FHEM Update.
https://github.com/RFD-FHEM/RFFHEM/blob/master/FHEM/14_SD_AS.pm
Hallo Sidey,
das update über den Link von gestern hatte ich schon ausgeführt, mit Erfolg übrigens :)
Vielen Dank für die Korrektur.
Bitte die 77 erst mal so lassen.
Mit der 77 und der Lacrosse Lib lässt sich doch einiges verwirklichen.
In einem ATTiny85 passt der Sketch, dazu einen DS18B20 oder HDT22 und das Sendemodul und Batteriestrom kostet keine 5EUR :)
Gefällt mir gut, Ich habe ATTiny85 bei Reichelt bestellt, die sollten die Woche kommen.
Ich werde auch mal versuchen ob die Luftfeuchtigkeitswerte sauber übertragen und gelesen werden.
Grüße
Mike
Hi Leutz,
sieht gut aus, T hatte ja schon funktioniert, H geht auch :)
T+H = Sensor-ID=106
2018-01-10 20:12:06 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=-2041;P1=394;P2=-4593;P3=-9054;D=1310121012101210101010101210101010101210121012121010121210;CP=1;SP=3;
2018-01-10 20:12:06 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P1=415;P2=-2001;P3=-4587;P4=-9602;D=1412131213121312121212121312121212121312131213131212131312;CP=1;SP=4;
2018-01-10 20:12:07 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-936;P1=411;P2=-2033;P3=-5141;P4=-9568;D=01212121312121212121312131213131212131312141213121312131212121212131212121212131213121313121213131213;CP=1;
2018-01-10 20:12:07 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-372;P1=-361;P3=959;P4=-545;P5=472;P6=1442;P7=-144;D=13131313131313131313131313131345154345154345154313134513154313451315434513131313154345131313154345131543451543451313131315434513154313131345131313131313467503131515151516151616151616151615151516161616161516151516161516151616151616161515151615161616;CP=5;
2018-01-10 20:12:08 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-188;P1=1336;P2=-995;P3=540;P5=-28214;D=01212321232121212121212121232121212321232123212323232121212121232123212323232123212151212121232123212121212121212123212121232123212321232323212121212123212321232323212321215121212123212321212121212121212321212123212321232123232321212121212321232123232321;CP=3;O;
2018-01-10 20:12:08 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2018-01-10 20:12:08 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-10 20:12:08 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 0 1 0 1 1 1 1 1 1 1 1 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 1 1 1 0 1 0 1 0 0 0 1 0 1 0 0 0
2018-01-10 20:12:08 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#D7FBAA3EA28 length 44
2018-01-10 20:12:08 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 1 1 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 1 1 1 0 1 0 1 0 0 0 1 0 1 0
2018-01-10 20:12:08 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#F5FEEA8FA8A length 44
2018-01-10 20:12:08 SIGNALduino sduino sduino 5: sduino: dispatching bits: 1 1 1 1 0 1 0 1 1 1 1 1 1 1 1 0 1 1 1 0 1 0 1 0 1 0 0 0 1 1 1 1 1 0 1 0 1 0 0 0
2018-01-10 20:12:08 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 5 dmsg p5#F5FEEA8FA8 length 40
2018-01-10 20:12:17 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=1032;P1=-991;P2=1937;P3=-4104;P4=5884;P5=-6544;P6=3397;P7=-2462;D=012121234521216721212161212721212167212121212121216121212721216;CP=2;
2018-01-10 20:12:17 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-32001;P1=2029;P2=-897;P3=-3900;P4=6072;P5=-6364;P6=3495;P7=-2363;D=01212121212121212121212134512126712121262121712121267121212121212126212121712126;CP=1;
2018-01-10 20:12:18 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P1=457;P2=-3932;P3=-1972;P4=-9213;D=14131213121312121312131213131313131313131313121312131312131313121312121212;CP=1;SP=4;O;
2018-01-10 20:12:18 SIGNALduino sduino sduino 4: sduino/msg READ: MS;P0=-3906;P1=487;P2=-1966;P3=-9110;D=13121012101210101210121012121212121212121212101210121210121212101210101010;CP=1;SP=3;O;
2018-01-10 20:12:22 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-408;P1=994;P2=-1457;P3=261;P4=-21522;D=01212123212321212121212323212321232121212323212123232321212123212323212123232321232321412121212321232121212121232321232123212121232321212323232121212321232321212323232123232141212121232123212323232123232123212321212123232121232323212121232123232121232323;CP=3;O;
2018-01-10 20:12:22 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-10 20:12:22 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
2018-01-10 20:12:22 SIGNALduino sduino sduino 5: sduino: dispatching bits: 0 0 0 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 0 0 1 1 0 0 1 1 1 0 0 0 1 0 1 1 0 0 1 1 1 0 1 1 0
2018-01-10 20:12:22 SIGNALduino sduino sduino 4: sduino: decoded matched MU Protocol id 77 dmsg TXA0D4671676 length 44
2018-01-10 20:12:22 SIGNALduino sduino sduino 5: sduino Dispatch: TXA0D4671676, test ungleich: disabled
2018-01-10 20:12:22 SIGNALduino sduino sduino 5: sduino Dispatch: TXA0D4671676, dispatch
2018-01-10 20:12:22 CUL_TX CUL_TX_106 T: 17.1 H: 67.1
2018-01-10 20:12:22 CUL_TX CUL_TX_106 temperature: 17.1
2018-01-10 20:12:22 SIGNALduino sduino sduino 4: sduino/msg READ: MU;P0=-1487;P1=230;P2=961;D=010102020101010202020102010101020101020102010202020101020201010102020201020101020201010102010202;CP=1;
2018-01-10 20:12:22 SIGNALduino sduino sduino 4: sduino: Fingerprint for MU Protocol id 77 -> NANO_DS1820_4Fach matches, trying to demodulate
2018-01-10 20:12:22 SIGNALduino sduino sduino 5: sduino: Starting demodulation at Position 1
Hier bei mir in der Gegend scheinen aber noch einige Sensoren das gleiche Protokoll zu verwenden:
Die Sensor-ID=105 - 108 sind meine.
CUL_TX_105 T: 9.3
CUL_TX_106 T: 17.1 H: 67.1
CUL_TX_107 T: 0.0
CUL_TX_108 T: 0.0
CUL_TX_13 Defined
CUL_TX_18 T: 9.4
CUL_TX_27 T: 7.8 H: 76.0
CUL_TX_49 T: 8.7
CUL_TX_52 T: 9.0
CUL_TX_8 T: 7.0
CUL_TX_9 T: 8.0
Grüße
Mike
Timings:
https://forum.fhem.de/index.php/topic,56660.msg666579.html#msg666579 (https://forum.fhem.de/index.php/topic,56660.msg666579.html#msg666579)
Hi Leutz,
danke für die Info zum Timing, kann man sicher mal brauchen, obwohl dieses Projekt mit der Protokoll ID 77 gut funktioniert.
Protokoll ID 77, ich hab an meinem RXB6 nur kurze 10cm Draht als Antenne und schon 11 fremde Außenthermometer der Nachbarschaft eingefangen!
@ Sidey:
sollte man das Protokoll 77 vielleicht ins reguläre Update aufnehmen ?
Grüße
Mike
Zitat von: CatWeazle am 11 Januar 2018, 18:28:32
Hi Leutz,
danke für die Info zum Timing, kann man sicher mal brauchen, obwohl dieses Projekt mit der Protokoll ID 77 gut funktioniert.
Protokoll ID 77, ich hab an meinem RXB6 nur kurze 10cm Draht als Antenne und schon 11 fremde Außenthermometer der Nachbarschaft eingefangen!
@ Sidey:
sollte man das Protokoll 77 vielleicht ins reguläre Update aufnehmen ?
Grüße
Mike
Hi Mike,
Es wäre durchaus von Vorteil, wenn man sich an die Timings des Originals hält. :)
Mit der ID 77 geht es vom Prinzip her auch, es wird halt unübersichtlich bei derart vielen Protokollen.
Die Übernahme ins Update erfolgt. Allerdings wollte ich doch erst noch mal abwarten.
PS:
Vom Prinzip habe ich hier einen recht ähnlichen Aufbau in der Schublade auf einem Breadboard. Attiny85, mit 1 Mhz und einen DHT11.
Ich habe vom Prinzip her alles versucht was einem so einfällt. Ich habe sogar den DHT11 und auch das Sendemodul an einen digital Pin gehangen um in an / aus zu schalten.
Wenn Du ihn mit Batterie betreiben willst, dann drücke ich dir die Daumen. Ich hatte da ernsthaft Probleme mit der Haltbarkeit der Batterien. Daher habe ich auch einige Zeit in ein sehr optimiertes Protokoll gesteckt, denn das Sendemodul verbraucht schon einiges an Energie.
Grüße Sidey
Hallo Sidey,
ich habe das Timing angepasst, nun ist es nicht mehr MU Protocol id 77 sonder MU Protocol id 8!
Du hast Recht, so ist es natürlich viel besser, jetzt passt das normale Lacrosse TX2/TX3 Sensoren Protokoll.
//--- Duration of pulses and delays
// ALT:
/*int iLongPulse = 975;
int iShortPulse = 250;
int iDelay = 1450;*/
//NEU:
int iLongPulse = 1200;
int iShortPulse = 400;
int iDelay = 900;ZitatPS:
Vom Prinzip habe ich hier einen recht ähnlichen Aufbau in der Schublade auf einem Breadboard. Attiny85, mit 1 Mhz und einen DHT11.
würde mich interessieren .... also die Dateien, nicht das komplette Breadboard. :)
Den heutigen Tag habe ich mit dem Thema EV1527 Sender zugebracht, also TX1527, .h .cpp . ino, habe es dann ans laufen gebracht, der Sketch verwendet 1426 Bytes.
Passt locker 5x in einen ATTiny85 :) Muss man auch nicht selber bauen, aber man kann !
Grüße
Mike
Zitat von: CatWeazle am 11 Januar 2018, 22:15:38
würde mich interessieren .... also die Dateien, nicht das komplette Breadboard. :)
Ist schon etwas länger her. Ich habe den Sketch gefunden.
Ob er so funktioniert weiss ich leider nicht, aber es scheint die letzte Version zu sein.
Ich hatte einen DHT11 und einen Reed Sensor angebunden. Andere Sensoren wie Licht etc. funktionieren natürlich mit Anpassungen auch.
https://github.com/RFD-FHEM/ArduinoSensor/blob/master/SensorTransmitter/Examples/attiny_demo/attiny_demo.ino
Ich habe da einiges gezaubert mit watchdog und sleep, warum weiss ich schon gar nicht mehr.
Grüße Sidey
Hallo Sidey,
jups bedankt, schau mir das mal an.
Den watchdog kann man auch zum beenden eines Kurzschlafs nutzen ......
Grüße
Mike
Hi Leutz,
ich habe mir das Lacrosse TX3 Protokoll nochmal angesehen.
Zum einen habe ich das Timing weiter verändert, nachdem ich zwei Oszilloskop Screensots gesehen habe.
So sollte es noch besser zu TX3 Passen.
Bei mir funktioniert es!
/* ALT:
int iLongPulse = 1200;
int iShortPulse = 400;
int iDelay = 900;*/
// NEU:
int iLongPulse = 1300;
int iShortPulse = 500;
int iDelay = 500;
Dann habe ich festgestellt, das Temperatur und Luftfeuchtigkeit nicht in einem übertragen werden und in den bits 9-12 der Sensortyp hinterlegt ist!
2018-01-12 16:28:51 SIGNALduino sduino sduino 5: sduino: dispatching bits: 0 0 0 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 0 0 1 1 1 0 0 0 1 0 0 1 1 0 1 1 1 0 0 0 1 1 1 1 0
2018-01-12 16:28:51 SIGNALduino sduino sduino 5: sduino Dispatch: TXA0D471371E, dispatch
2018-01-12 16:28:51 CUL_TX CUL_TX_106 T: 21.3 H: 67.1
2018-01-12 16:28:51 CUL_TX CUL_TX_106 temperature: 21.3
2018-01-12 16:28:52 SIGNALduino sduino sduino 5: sduino: dispatching bits: 0 0 0 0 1 0 1 0 1 1 1 0 1 1 0 1 0 1 0 0 0 1 1 0 0 1 1 1 0 0 0 1 0 1 1 0 0 1 1 1 0 1 0 0
2018-01-12 16:28:52 SIGNALduino sduino sduino 5: sduino Dispatch: TXAED4671674, dispatch
2018-01-12 16:28:52 CUL_TX CUL_TX_106 T: 21.3 H: 67.1
2018-01-12 16:28:52 CUL_TX CUL_TX_106 humidity: 67.1
Die ersten 8 bits sind bei TX3 immer 0000 1010.
Die nächsten vier bits sind der Sensortyp, T: 0000 / H: 1110
Danach kommen 7 Adressbits, 1 parity bit, 20 Datenbits und die letzten vier sind die Checksumme.
Bei humidity steht der Wert genau drin H: 67.1 = Dispatch: TXAED4'671'674
Bei temperature ist der Wert mit +50 angegeben, T: 21.3 = Dispatch: TXA0D4'713'71E
Die +50 sind die Reserve für Temperaturen unter Null!
Grüße
Mike
Zweckendfremdbare Bodenfeuchte-Platinen, die sich prima zum Sensor eignen, gibt es hier https://forum.fhem.de/index.php/topic,59933.90.html (https://forum.fhem.de/index.php/topic,59933.90.html)
Zitat von: Sidey am 11 Januar 2018, 21:25:10
PS:
Vom Prinzip habe ich hier einen recht ähnlichen Aufbau in der Schublade auf einem Breadboard. Attiny85, mit 1 Mhz und einen DHT11.
Ich habe vom Prinzip her alles versucht was einem so einfällt. Ich habe sogar den DHT11 und auch das Sendemodul an einen digital Pin gehangen um in an / aus zu schalten.
Wenn Du ihn mit Batterie betreiben willst, dann drücke ich dir die Daumen. Ich hatte da ernsthaft Probleme mit der Haltbarkeit der Batterien. Daher habe ich auch einige Zeit in ein sehr optimiertes Protokoll gesteckt, denn das Sendemodul verbraucht schon einiges an Energie.
Grüße Sidey
Hallo,
da muss ich mich ja unbedingt wieder einmischen. Habe jetzt auch schon viel probiert, gelesen und getestet. Nun habe ich gerade einen ersten Versuchsaufbau laufen...das sieht bisher schon vielversprechend aus!
Versuchsaufbau (Siehe angehängte Grafik)
- 1x AA Eneloop Akku. Vollgeladen um einen Verbrauch nach einiger Zeit abschätzen zu können.
(Achtung! Später keine Akkus verwenden, da kein Tiefentladeschutz!)
- Step-Up Wandler 3,3V
- Elko 10µF 25V
- Sender 433MHz FS1000A
- DHT22 mit einem Pullup-Widerstand von 4,7kOhm
- 1kOhm Widerstand zwischen 5V+Reset
Da der Strom sich mit meinen Mitteln (zu langsame Multimeter) kaum messen lässt, habe ich versucht diesen einzeln zu erfassen (ich habe meine Notiz verlegt...daher grob geschätzte Werte):
1.) Deep-Sleep ca. 0,08mA
2.) attiny85 arbeitet ca. 30mA (bei mir derzeit auf 16MHz siehe weiter unten)
3.) Senden (ist ja nur sehr kurz) ca. 80mA
Daraus resultiert, das nur im Deep-Sleep eine einzelne AA-Mignon Batterie (2500mAh) ca. 3 Jahre durchhalten sollte. (Rechner hier: https://oregonembedded.com/batterycalc.htm).
Wenn ich nun einen mittleren Verbrauch von 35mA annehme, wenn gemessen und gesendet wird...könnte die einzelne Batterie 0,54Jahre (196 Tage) durchhalten...denn ich benötige nur ca. 636ms Ausführungszeit (ohne Batteriespannung messen und diesen Wert Senden).
Ich nutze allerdings eine andere Vorlage der recht ähnlichen Software von hier: https://crycode.de/diy-funk-wetterstation-mit-dht22-attiny85-und-radiohead
Diese habe ich aber auch stark abgeändert:
1.) keine 5V sondern 3,3V von einer Batterie mit Step-Up Wandler
2.) keine LEDs
3.) Senden nicht RadioHead, sondern ich nutze hier das "Hideki" Protokoll von hier: https://bitbucket.org/fuzzillogic/433mhzforarduino/overview
Hier kann ich Temperatur und Luftfeuchte mit einem mal senden. Klappte auch auf Anhieb.
Die DHT-Fastlib ist wirklich flott und läuft bei mir (derzeit leider nur bei 16MHz) stabil. Um den Stromverbrauch im Standby zu senken musste ich den Pin vom DHT22 erst auf Low und dann pinMode auf Input setzen, damit der Verbrauch sinkt. Keine Ahnung warum.
Für den Versuch übermittel ich alle 30 Sendevorgänge den Analogwert.
Was hier noch zu erledigen ist:
1.) Code optimieren! Ausführungszeit auf ein minimum beschränken
2.) Den Attiny nur auf 1MHz laufen lassen
3.) AnalogWerte richtig lesen. Derzeit kommt da noch nichts brauchbares raus
4.) Vergleichen wie sich der Stromverbrauch mit 2 Batterien reduziert. Dann gibt es nicht so viele Verluste durch den StepUp.
5.) Den Empfang prüfen. In FHEM kommt nicht jeder Messwert an.
Ich habe den Versuchsaufbau nun seit 9 Tagen laufen. Ich sende derzeit alle 14 Sekunden neue Messwerte. D.h. im Realbetrieb (ca. 1x pro Minute...mein Wunsch) wären dies bereits 36 Tage Laufzeit. Wenn z.B. nur alle 3 Minuten ein Messwert benötigt wird, sind das schon über 100 Tage! Die Akkuspannung hat nun ca. 0,2V abgenommen. Ich werde die Tage dann mal den Akku ins Ladegerät legen und sehen, wie hoch der Verbrauch in etwa war...dann kann ich auch die Realen Werte und die Theoretischen besser abschätzen.
Gruß
Bismosa
Hallo bismosa,
das deckt sich in etwa auch mit meinen Messungen. :D
Du hast den DHT aber über den Pullup-Widerstand ständig auf VCC.
Das ließe sich noch optimieren, wenn Du diese über einen FET schaltbar machst (wenn noch ein Portpin dafür frei wäre ...)
und dem DHT genügend Zeit gibst sich aufzuwärmen, bevor eine oder mehrere Messungen gemacht werden
und dann gesendet werden. Man muss nur die Aufwärmzeit des DHT analysieren und in den Meßzyklus mit einbinden.
Das Gleiche gilt für das Sende-Modul.
Bin mir sicher, daß man da noch etwas herausholen/-quetschen kann.
Das Hideki-Protokoll ist zwar genau für diesen Anwendungszweck auch geeignet, allerdings benutze ich
das CUL_TX-Protokoll für alles Mögliche, das Hideki-Protokoll hatte aber gewisse Einschränkungen,
so dass ich auf das 433-LaCrosse-Protokoll (TX2/3) zurückgegangen bin.
Grüße,
Jürgen
Hallo,
schön, das Du ähnliche Ergebnisse erzielt hast. Dann liege ich wohl nicht ganz so falsch.
Ich habe auch probiert, den DHT erst für die Messung zu aktivieren. Pin5 und Pin6 sind bei mir ja noch frei. Allerdings verschwendet man wohl zu viel Energie, wenn man 2sek. (schneller ging es bei mir nicht) auf den DHT22 warten muss. Der DHT soll lt. Datenblatt ja nur 0,04mA verbrauchen (bei 3,3V). Das deckt sich fast mit meinen Ergebnissen. Wobei jeder meiner DHT22 hier anders ist!
Durch den 4,7kOhm Widerstand habe ich weitere 0.0007mA. Der Rest wird dann durch den StepUp "verbraten".
Meine Messungen haben gezeigt, das der FS1000A 0,nixMessbares im Standby benötigt.
Das LaCrosse Protokoll und vor allem Deine Bemühungen dies umzusetzen wollte ich nicht schlecht reden! Ich hoffe das ist auch nicht so rüber gekommen. Ich habe nicht weiter probiert/Analysiert ob es nicht sogar schneller ist. Bei Deinem Beispiel wartet der Attiny jedoch 2sek. um den anderen Wert zu senden. Dies ist Laufzeit die Stark auf die Batterie geht. Hier könnte man aber auch eine kurze Deep-Sleep Phase einlegen. Dann wäre das auch gut!
Habe gerade wieder einen Schwung Batterien aus der Weihnachtsbeleuchtung entnommen. Die Batterien sind zwar nicht mehr voll...aber dann für ein Thermometer bestimmt noch einige Wochen gut zu gebrauchen :)
Ich muss auch noch unbedingt testen wie es sich mit meinen Fenstersensoren verträgt. Diese senden ebenfalls auf 433MHz. 3x hintereinander ohne Rückkanal. Wäre doof, wenn die dann nicht mehr funktionieren. Dann versuche ich das Ganze lieber auf 868MHz. Hier sind zwar meine MAX Thermostate...aber die merken, wenn die Kommunikation gestört ist.
Gruß
Bismosa
Hallo,
ich habe frische Messergebnisse :)
Mein Versuchsaufbau lief jetzt 22 Tage mit einem Eneloop Akku.
Geladen habe ich ca. 1450mAh. Bei einem Messwert alle 14 Sekunden!
Wenn ich nur jede Minute einen Messwert senden würde und statt des Akkus eine Batterie (2500mAh) verwenden würde, müsste ich auf ein Laufzeit von ca. 150 Tagen kommen...
Bevor ich den Akku geladen habe, hatte ich noch eine Akkuspannung von 1,23V. Insgesamt ist die Akkuspannung ja geringer. Somit könnte sich die Laufzeit erhöhen, da eine Batterie anfangs eine höhere Spannung hat und somit die Verluste über den StepUp geringer ausfallen sollten.
Optimaler wäre sicherlich 2 Batterien zu verwenden. Dann sind die Verluste noch geringer und eine Laufzeit von einem Jahr vermutlich problemlos möglich.
Nur mal so als Zwischenergebnis. Ich werde die Tage mal einen Sensor zusammenbauen, den Code weiter Optimieren und dann das Ganze mit einer Batterie laufen lassen. Es wird dann allerdings lange Dauern bis ich etwas zur tatsächlichen Laufzeit sagen kann ;)
Für mich ist auch ein halbes Jahr mit einer Batterie eine gute Zeit! Bei einem Messwert jede Minute!
Gruß
Bismosa
Hallo bismosa,
das hört sich aber gut an. Respekt!
Hattest du den Code dazu schon veröffentlicht?
Würde mir gerne das Eine oder Andere abgucken, denn meine Akkulaufzeit ist deutlich, aber so was von deutlich kürzer :)
Grüße
Mike
Hallo,
nein, den Code hatte ich noch nicht veröffentlicht. Eigentlich aus 2 Gründen
1.) Alles nur geklaut :) Naja...auf jeden Fall nur zusammenkopiert.
2.) Nicht aufgeräumt...derzeit ist das noch reiner Spaghetti-Code...
Da ich die Tage nicht dazu kommen werde hier weiter zu machen...und mir denken kann, das es den einen oder anderen interessiert...im Anhang eine ZIP mit dem Projekt.
Kurz noch was dazu:
1.) Überhaupt nicht aufgeräumt
2.) Vorlage von https://crycode.de/diy-funk-wetterstation-mit-dht22-attiny85-und-radiohead
3.) "Hideki" Protokoll von hier: https://bitbucket.org/fuzzillogic/433mhzforarduino/overview
4.) Analog Read funktioniert noch nicht. Keine Ahnung warum. Hatte vor dem Test keine Zeit mehr das zu ergründen...
Es ist sehr wichtig, das die Ausführungszeit auf ein Minimum beschränkt wird. Nach Möglichkeit keine Sleeps etc. Das bringt wohl am meisten!
Für Tipps und Bugfixes bin ich immer zu haben! Ich hoffe das ich auch bald mal wieder dazu komme!
Gruß
Bismosa
Hallo, habe versucht, den Code zu kompilieren und erhielt die Fehlermeldung bezüglich der fehlenden SensorTransmitter.h. Habe dann diejenige von https://github.com/RFD-FHEM/ArduinoSensor/blob/master/SensorTransmitter/SensorTransmitter.h verwendet, was zu dem neuen Fehler Attiny85_DHT22_V0.3_FastLib_Bismosa:32: error: 'ThermoHygroTransmitter' does not name a type führt. Habe ich die falsche Library?
Danke im voraus, Deutz
Hallo,
sorry...ich habe echt kaum Zeit im Moment. Müsste es nicht die Lib von hier sein:
https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home
bzw.
https://bitbucket.org/fuzzillogic/433mhzforarduino/overview
Sonst muss ich mir das nochmal anschauen welche ich habe...das wird aber leider erst nächste Woche...
Gruß
Bismosa
Damit baut es zumindest.
Danke.
Zitat von: meggih am 21 November 2016, 10:01:31
Hey, hab grade den Thread gefunden.
Ich hab sowas auch gebaut, also Attiny, 433Mhz Funkchip, Reed/Kupfer Kontakt.
Verbrauch bei geschlossenem Fenster 4 uA, bei offenem Fenster 6uA.
Hatte erst den internen PULL-UP Widerstand verwendet, der verbraucht aber zu viel bei offenem Fenster bei mir.
Interrupt hat bei mir das Aufwachen nicht zuverlässig funktioniert, also wache ich 1x pro Sekunde auf und checke den Status. Bei Änderung wird dann gesendet.
Alles im Intertechno Protokoll, eine CR2032 sollte n paar Jahre reichen nach großben Berechnungen.
Habe im Garten sowas auch als Bewegungsmelder - funzt mittlerweile über ein Jahr ohne Probleme.
Sketch:
#include <NewRemoteTransmitter.h>
#include <avr/sleep.h>
#include <avr/wdt.h>
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
byte REED_PIN=2;
byte SEND_PIN=3;
boolean Status=false;
NewRemoteTransmitter transmitter(50630001, SEND_PIN, 290, 2); // 300us Pulslaenge an PIN 3
void setup() {
pinMode(REED_PIN, INPUT);
setup_watchdog(6); // approximately 1 seconds sleep
cbi(ADCSRA,ADEN); // switch Analog to Digitalconverter OFF
set_sleep_mode(SLEEP_MODE_PWR_DOWN); // sleep mode is set here
}
void loop() {
system_sleep();
}
void system_sleep() {
sleep_enable();
sleep_mode(); // System sleeps here
sleep_disable(); // System continues execution here when watchdog timed out
//sbi(ADCSRA,ADEN); // switch Analog to Digitalconverter ON
}
// 0=16ms, 1=32ms,2=64ms,3=128ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec
void setup_watchdog(int ii) {
byte bb;
int ww;
if (ii > 9 ) ii=9;
bb=ii & 7;
if (ii > 7) bb|= (1<<5);
bb|= (1<<WDCE);
ww=bb;
MCUSR &= ~(1<<WDRF);
// start timed sequence
WDTCR |= (1<<WDCE) | (1<<WDE);
// set new watchdog timeout value
WDTCR = bb;
WDTCR |= _BV(WDIE);
}
// Watchdog Interrupt Service / is executed when watchdog timed out
ISR(WDT_vect) {
if (digitalRead(REED_PIN)==LOW && Status==true){
Status=false;
transmitter.sendUnit(6, false);
//pinMode(REED_PIN, INPUT);
}else if (digitalRead(REED_PIN)==HIGH && Status==false) {
Status=true;
//pinMode(REED_PIN, INPUT_PULLUP);
transmitter.sendUnit(6, true);
}
}
Hallo zusammen,
sorry erst einmal, dass ich von Seite 11 was "vor" hole. Ich möchte eigentlich nur meine Fensterkontakte übermachen. Dazu gefällt mir das Beispiel, welches "meggih" aufgeführt hat sehr gut. Zunächst habe ich mir das Ganze auf einem Steckbrett aufgebaut und habe auch einen Digispark verwendet da ich gerade keinen einzelnen Attiny herum liegen habe und auch besser "herumspielen" kann. Wenn das ganze mir gefällt soll alles "Stromsparend" dann mit einem Attiny aufgebaut werde.
Jedoch habe ich nun das Problem, das wenn ich den obigen Code verwende, dieser beim Kompilieren mit einem Fehler abgebrochen wird. Ich bin absoluter "Neuling" was Arduino usw. angeht. Die ganzen Dinge wie LED aus einschalten und PWM ist soweit alles verständlich... aber jetzt will ich doch mal an "Funkübertragung" gehen und dort herum spielen.
Bei mir die Übersetzung mit diesen Fehlern abgebrochen.
Arduino: 1.8.5 (Windows 7), Board: "Digispark (Default - 16.5mhz)"
Archiving built core (caching) in: C:\Users\PC_Home\AppData\Local\Temp\arduino_cache_451814\core\core_digistump_avr_digispark-tiny_a09920091512088f4cfd8dda5c7f87b8.a
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::interruptHandler()'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_enabled'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_state'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_minRepeats'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_inCallback'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_callback'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::enable()'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::init(signed char, unsigned char, void (*)(NewRemoteCode))'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::_interrupt'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::disable()'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::deinit()'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteReceiver.cpp.o: In function `NewRemoteReceiver::interruptHandler()':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteReceiver.cpp:73: multiple definition of `NewRemoteReceiver::isReceiving(int)'
sketch\NewRemoteReceiver.cpp.o:sketch/NewRemoteReceiver.cpp:73: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::NewRemoteTransmitter(unsigned long, unsigned char, unsigned int, unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:11: multiple definition of `NewRemoteTransmitter::NewRemoteTransmitter(unsigned long, unsigned char, unsigned int, unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:11: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::NewRemoteTransmitter(unsigned long, unsigned char, unsigned int, unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendStartPulse()'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendStopPulse()'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendBit(unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendAddress()'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::_sendUnit(unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendGroup(unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendUnit(unsigned char, unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendDim(unsigned char, unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
libraries\NewRemoteSwitch\NewRemoteTransmitter.cpp.o: In function `NewRemoteTransmitter::_sendBit(unsigned char)':
C:\Program Files (x86)\Arduino\libraries\NewRemoteSwitch/NewRemoteTransmitter.cpp:141: multiple definition of `NewRemoteTransmitter::sendGroupDim(unsigned char)'
sketch\NewRemoteTransmitter.cpp.o:sketch/NewRemoteTransmitter.cpp:141: first defined here
collect2.exe: error: ld returned 1 exit status
exit status 1
Fehler beim Kompilieren für das Board Digispark (Default - 16.5mhz).
Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.
Wenn ich auf einen Arduino Uno gehe kommt nur noch die Meldung
Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Uno"
Build-Optionen wurden verändert, alles wird neu kompiliert
C:\Users\PC_Home\Documents\Arduino\433MHZ_Funk_neu\433MHZ_Funk_neu.ino: In function 'void setup_watchdog(int)':
433MHZ_Funk_neu:51: error: 'WDTCR' was not declared in this scope
WDTCR |= (1<<WDCE) | (1<<WDE);
^
exit status 1
'WDTCR' was not declared in this scope
Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.
Bin ein wenig überfordert. Vielleicht kann jemand von euch mal einen Blick drauf werfen
Besten Dank!
Steffen
Hallo Bender78,
hast Du in der Arduino-IDE auch die Umgebung für den Digispark ATtiny85 installiert und als Board-Typ im Tools-Menü ausgewählt.
Damit kann die Arduino-IDE die richtigen Anpassungen bei der Ressourcen-Auswahl z.B. " WDTCR" treffen.
Um das aber genauer beurteilen zu können, probier noch mal einen Compile und poste den Text des Ergebnisfensters als Datei in Deine Antwort.
Dann kann man besser beurteilen wo das Problem liegt.
Dein Code läuft bei mir ohne Fehler durch...
Der Output sollte so etwas in der Art enthalten:
" -mmcu=attiny85 -DF_CPU=16500000L -DARDUINO=10804 -DARDUINO_AVR_DIGISPARK -DARDUINO_ARCH_AVR"
Vielleicht ist es noch in Hinsicht auf FHEM zu erwähnen, daß Du das Hideki-Protokoll gewählt hast.
http://www.max-mg.de/Digispark_ATTiny85_einrichten.pdf (http://www.max-mg.de/Digispark_ATTiny85_einrichten.pdf)
Grüße,
Jürgen
Zitat von: juergs am 02 April 2018, 11:00:34
Hallo Bender78,
hast Du in der Arduino-IDE auch die Umgebung für den Digispark ATtiny85 installiert und als Board-Typ im Tools-Menü ausgewählt.
Damit kann die Arduino-IDE die richtigen Anpassungen bei der Ressourcen-Auswahl z.B. " WDTCR" treffen.
Um das aber genauer beurteilen zu können, probier noch mal einen Compile und poste den Text des Ergebnisfensters als Datei in Deine Antwort.
Dann kann man besser beurteilen wo das Problem liegt.
Dein Code läuft bei mir ohne Fehler durch...
Der Output sollte so etwas in der Art enthalten:
" -mmcu=attiny85 -DF_CPU=16500000L -DARDUINO=10804 -DARDUINO_AVR_DIGISPARK -DARDUINO_ARCH_AVR"
Vielleicht ist es noch in Hinsicht auf FHEM zu erwähnen, daß Du das Hideki-Protokoll gewählt hast.
http://www.max-mg.de/Digispark_ATTiny85_einrichten.pdf (http://www.max-mg.de/Digispark_ATTiny85_einrichten.pdf)
Grüße,
Jürgen
Hallo Jürgen, vielen Dank für deine Info.
Ich bin jetzt ein Stück weiter gekommen. Den Digispark habe ich in Arduino installiert und hab halt wie immer mein Blinklämpchen übertragen. Das hat auch problemlos funktioniert.
Beim obigen Code läuft die Kompilierung jetzt auch ohne Fehler durch. Ich hatte vermutlich aus verzweiflung und Unwissenheit die Funktion "NewRemoteTransmitter" in den gleichen Ordner kompiert indem der Sketch lag. Dies habe ich jetzt gelöscht und nun läuft es fehlerfrei durch...
Aber natürlich tut sich an meinem FHEM nichts. Mein Cul erkennt nicht das ich den Kontakt zu Pin 2 öffne und schließe.
Aufgebaut ist es wie folgt VCC, GND sind mit dem Digispark verbunden und Data des STX822 ist mit dem Pin3 des Digispark verbunden. Spannung messe ich. :-\
Oder kann der Nano Cul dieses Protokoll nicht? Ich meine gelesen zu haben das dieser dies ebenfalls via AutoCreate in FHEM anlegt.
ZitatAber natürlich tut sich an meinem FHEM nichts. Mein Cul erkennt nicht das ich den Kontakt zu Pin 2 öffne und schließe.
Das Protokoll, dafür ist es primär ausgelegt, überträgt ja analoge Daten, wie z.B. Temperaturen oder Drücke.
Unter Umständen sind noch zur Abhandlung von negativen Temperaturen noch ein Offset zum endgültigen Wert addiert.
Man kann aber Tricksen. Durch den Reed-Kontakt kann man ja nur 2 Zustände übertragen.
Je nach Aufbau 0 V oder 5V, wenn Du z.B.
Vcc --- 10KOhm-- Abzweig zum ATtiny-Analog-Pin---Reed-Kontakt ---- GND benutzt.
Also sollte der Sensor ca. 2 unterschiedliche Werte liefern. Diese kannst Du im Programm am AD-Wandler Abfragen
und dann in die zwei Zustände z.B. 0 und 100 (innerhalb der Protokoll-Übertragungs-Grenzen) skalieren, entstören (Redd-Kontakte prellen)
und dann übertragen.
In FHEM kannst Du dann mit Abfragen auf die zwei Zustände reagieren.
Wie das gemacht wird steht, glaube ich, hier im Thread oder bemühe einfach die FHEM-Suche nach "Fensterkontakt"
dann bekommst Du mit Sicherheit einige passende Treffer dazu ...
Fange einfach mal damit an, nur feste Daten zu übertragen um das Device in FHEM wiederzufinden...
Dann kannst Du mit den Werten jonglieren. Denke daran, nicht das Funknetz mit zu vielen Wiederholungen und keinen Zwischenpausen zu blockieren.
Üblich sind 3..5 Wiederholungen, die gehen aber auf die Batterie-Lebensdauer ... ;)
Jürgen
oder Du integrierst eine weitere Library, die eher für Schalter geeignet ist.
(Diesen (https://forum.fhem.de/index.php/topic,52755.msg525317.html#msg525317) u. Folgeposts.)
Zitat von: juergs am 02 April 2018, 12:05:30
Das Protokoll, dafür ist es primär ausgelegt, überträgt ja analoge Daten, wie z.B. Temperaturen oder Drücke.
Unter Umständen sind noch zur Abhandlung von negativen Temperaturen noch ein Offset zum endgültigen Wert addiert.
Man kann aber Tricksen. Durch den Reed-Kontakt kann man ja nur 2 Zustände übertragen.
Je nach Aufbau 0 V oder 5V, wenn Du z.B. 5V --- 10KOhm-- Abzweig zum ATtiny-Analog-Pin---Reed-Kontakt ---- GND benutzt.
Also sollte der Sensor ca. 2 unterschiedliche Werte liefern. Diese kannst Du im Programm am AD-Wandler Abfragen
und dann in die zwei Zustände z.B. 0 und 100 (innerhalb der Protokoll-Übertragungs-Grenzen) skalieren und dann übertragen.
In FHEM kannst Du dann mit Abfragen auf die zwei Zustände reagieren.
Wie das gemacht wird steht, glaube ich, hier im Thread oder bemühe einfach die FHEM-Suche nach "Fensterkontakt"
dann bekommst Du mit Sicherheit einige passende Treffer dazu ...
Fange einfach mal an, nur feste Daten zu übertragen um das Device in FHEM wiederzufinden...
Dann kannst Du mit den Werten jonglieren. Denke daran, nicht das Funknetz mit zu vielen Wiederholungen und keinen Zwischenpausen zu blockieren.
Üblich sind 3..5 Wiederholungen, die gehen aber auf die Batterie-Lebensdauer ... ;)
Jürgen
Hallo Jürgen,
danke für die Info. Das wäre ok für mich. Nur leider wir mir in FHEM nichts angezeigt. Auch im EventMonitor erinscheint nichts. Daher bin ich gerade am zweifeln ob dies überhaupt alles so funktioniert wie gewünscht. Mein Cul funktioniert auf alle Fälle. Dieser Empfängt aktuell regelmäßig meinen Temperatursensor der Wettersation vom Nachbarn und meine IT Steckdosen lassen sich bequem schalten.
Nur zeigt er mir nichts von dem Testaufbau an.. Ich habe ein Bild angefügt, welches den Aufbau zeigt. Die Antenne sollte nicht das Problem sein, da mein Cul ca. 10cm weiter weg auf dem Tisch steht.
Das Hideki-Protokoll muss in der CUL-Firmware explizit mit kompiliert werden.
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:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki:
Das LaCrosse-Protokoll "CUL_TX" ist standardmäßig aktiviert ...
Wenn Du den Aufwand der Umprogrammierung scheust ... dann benutze lieber die anderen Beispiele hier im Thread mit LaCrosse ;) ;)
Hallo,
funktioniert der Sender denn? Ich hatte mehrfach Probleme, das die Frequenz nicht ganz zum CUL gepasst hat. Entweder bandwith erhöhen oder die Frequenz anpassen.
Lässt sich super mit einem DVB-T Stick mit SDR# prüfen.
Gruß
Bismosa
Zitat von: juergs am 02 April 2018, 12:34:07
Das Hideki-Protokoll muss in der CUL-Firmware explizit mit kompiliert werden.
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:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki:
Das LaCrosse-Protokoll "CUL_TX" ist standardmäßig aktiviert ...
Wenn Du den Aufwand der Umprogrammierung scheust ... dann benutze lieber die anderen Beispiele hier im Thread mit LaCrosse ;) ;)
Hm ok dann liegt das Problem dort.. Und ich vermute das es bei dem Protokoll kompilieren nicht nur darum dreht das ich in der "board.h" ein "define HAS_Hideki" dazu füge.. ;D Dann werde ich mich nochmal durch die Seiten ackern *g*. Danke euch allen..
... und immer mal auf die maximale Größe des Flash-Speichers (Tiny mit bootloader) achten ... sowohl beim CUL, als auch beim Tiny ;)
So.. nachdem ich heute den halben Feiertag dran herum gebastelt habe,zwischenzeitlich auf lacrosse umgestiegen bin, dann aber wieder verworfen weil ich 2h vergeblich versucht habe zu kompilieren und zum Schluss den ganzen scheiss in die Tonne kloppen wollte habe ich nun mehrfach gelesen, dass der Selbstbau Nano cul Hideki empfangen soll. Auch habe ich gelesen das es der Alternative Nano cul kann. Deswegen alles neu geflasht und siehe da....es geht nicht :-\ aber sehr wahrscheinlich sendet daher mein 433Mhz Sender nicht. Kann man aus dem DVB-T heraus finden ob sich da was tut ?
LG
Steffen
ZitatKann man aus dem DVB-T heraus finden ob sich da was tut ?
Hier Beispiele:
https://forum.fhem.de/index.php/topic,51535.msg440337.html#msg440337 (https://forum.fhem.de/index.php/topic,51535.msg440337.html#msg440337)
https://forum.fhem.de/index.php/topic,55274.msg511138.html#msg511138 (https://forum.fhem.de/index.php/topic,55274.msg511138.html#msg511138)
Du hast Dir zu viele Probleme auf einmal geschaffen... Versuche die der Reihe nach zu lösen.
Schließe z.B. eine LED parallel zum TX-Pin an und prüfe ob ein Sende-Impulsmuster sichtbar ist.
Du kannst Dir Debug-Ausgaben mit der TinySerial (https://www.arduinoclub.de/2013/11/10/arduino-attiny85-serial-debug-daten-ausgeben/)-Bibliothek einbauen und die versch. Schritte ausgeben. Die funktioniert auch nur mit einem Pin (TX),
wenn man einen nicht existente PIN-Nr. auf dem ATtiny85 für RX verwendet.
Der Lacrosse-Code ist hauptsächlich für den ATtiny85
ohne Bootloader gedacht, da benötigt man ein Programmer oder weiteren Arduino (auch Digispark!) dazu ...
Man kann aber auch den NANO einsetzen und den angepassten Code dafür verwenden. Beispiele findet man auch z.B. unter dem Topic "Bodenfeuchte-Sensor".
Welche Fehlermeldungen werden denn ausgegeben?
Die Kunst besteht darin:
Zitatden ganzen Schei.. in die Tonne kloppen
genau diesen Punkt zu überwinden... (!!!) ;) :)
Vielen Dank für die aufbauende Worte :)
Aber klar gute Idee mit der LED am TX Pin. Dies habe ich auch getestet siehe da die zeigt, dass irgend ein Impulsmuster kommt wenn gegen Masse schalte.
Jetzt ist nur die Frage, ob der Sender richtig tut oder der a-Cul doch nicht kann. Leider habe ich kein Oszi aufdem ich dies darstellen kann wie in Deinen Links gezeigt.
Hast du denn zufällig noch einen DVB-T. Stick rumliegen? Dann teste dies:
https://www.google.de/url?sa=t&source=web&rct=j&url=http://darcverlag.de/media/pdf/sdr_mit_dab-stick.pdf&ved=2ahUKEwihuOnw2p7aAhWK_qQKHZraCTYQFjACegQIBRAB&usg=AOvVaw1C47GvivpY4OqigSC8ATXM
Wenn es läuft auf 433MHz stellen und sehen was passiert :)
Gruß
Bismosa
Was man nicht alles macht :D
So dank einem tollen Kollegen der einen DVB-T Stick herum liegen hatte konnte ich nach diverser Internetsuche den Treiber für den Stick doch noch Installieren.
Danke euch für den Hinweis mit SDRSharp.
Also der kleine Digispark sendet. Somit erkennt der CUL vermutlich nicht das Protokoll...
Eine kleine Abweichung in der Frequenz habe ich zu IT. Das kann es aber nicht sein oder?
Zitate kleine Abweichung in der Frequenz habe ich zu IT. Das kann es aber nicht sein oder?
:) :) :) Doch, der Sender liegt ordentlich daneben .... kannst Du aber am über FHEM über CC1101 nachstellen...
Da: https://forum.fhem.de/index.php/topic,55274.msg511138.html#msg511138 (https://forum.fhem.de/index.php/topic,55274.msg511138.html#msg511138)
und da: https://forum.fhem.de/index.php/topic,51535.msg440337.html#msg440337 (https://forum.fhem.de/index.php/topic,51535.msg440337.html#msg440337)
Hallo,
genauso hatte ich es gedacht :)
Wie viel Abweichung Du haben darfst, kannst Du selbst sehen. Es kommt darauf an, welche Frequenz im CUL eingestellt ist und welche Bandbreite eingestellt ist. Sicher sein kannst Du, wenn du die Frequenz mal anpasst.
Auf Deinen Bildern ist zu sehen, das da gerade noch etwas am (schwach) Funken ist? Bekommst Du den Sensor rein?
Jetzt kannst Du auch eine Auswertung machen. Kurzes Audiofile aufnehmen und mit Audacity prüfen. das müsstest Du aber googeln...ich weiß so auch nicht, wie man das am besten macht.
Gefühlt nach dem Bild würde ich sagen, das die Impulse etwas kurz wirken...ich habe das meist am Geräusch gehört und verglichen. :) Richtige Frequenz beim Attiny eingestellt?
Gruß
Bismosa
Zitat von: bismosa am 04 April 2018, 18:19:21
Hallo,
genauso hatte ich es gedacht :)
Wie viel Abweichung Du haben darfst, kannst Du selbst sehen. Es kommt darauf an, welche Frequenz im CUL eingestellt ist und welche Bandbreite eingestellt ist. Sicher sein kannst Du, wenn du die Frequenz mal anpasst.
Auf Deinen Bildern ist zu sehen, das da gerade noch etwas am (schwach) Funken ist? Bekommst Du den Sensor rein?
Jetzt kannst Du auch eine Auswertung machen. Kurzes Audiofile aufnehmen und mit Audacity prüfen. das müsstest Du aber googeln...ich weiß so auch nicht, wie man das am besten macht.
Gefühlt nach dem Bild würde ich sagen, das die Impulse etwas kurz wirken...ich habe das meist am Geräusch gehört und verglichen. :) Richtige Frequenz beim Attiny eingestellt?
Gruß
Bismosa
Es funktioniert!!!! ;D
Vielen vielen Dank euch allen. Hab mir super weiter geholfen. Ich hab die Pulslänge von 300 auf 260 us gestellt. Jetzt erkennt FHEM es.
Die CC1101-Einstellungen sind z.B. bei mir:
Zitatfreq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
Das bedeutet das um eine best. Frequenz (Normal: 433.920 MHz) ca. 165 KHz nach oben und 165 KHz nach unten
am CUL ein "Fenster" aufgemacht wird, welches die Sender mehr oder weniger treffen müssen um erkannt zu werden.
Zur Vorgehensweise:
Wir haben ja 2 beteiligte Geräte (Sender + Empfänger). Beim CUL kann es sein, dass er von seiner Sollfrequenz etwas mehr oder weiniger abweicht.
Genauso kann es sein dass die Sender etwas daneben liegen. Das liegt u.U. an deren Fertigungstoleranzen ....
Also müssen wir die zwei frequenztechnisch "übereinander" bringen.
Da Du SDRSharp hast, ist das Ganze wesentlich einfacher:
Wenn Du eine IT-Steckdose empfangen hast, kannst Du diese benutzen um die CUL-Frequenz zu kalibrieren.
Man sendet einfach Steckdose AN/AUS (die sollte mit den Standardwerten bei 433.920 MHz liegen) und schaut im SDR nach welche Frequenz der
CUL sendet. Der Cul sendet, da digital gesteuert, sehr genau. Kann aber mit seiner Sollfrequenz manchmal erheblich danneben liegen,
das muss man beim Senden dann berücksichten (bei mir waren es mal 40KHz oder auch 125KHz daneben)....
Du kannst die CUL-Frequenz mit dem <Set> Kommando einstellen, z.b. ein "Verbiegen" des Standards um plus 125 KHz nach oben:
433.920 MHz + 0,125 MHz = 434.045 MHz
set <cul_name> freq 434.045 Damit würde dann der CUL auf 433.920 MHz senden und empfangen, obwohl er auf 434.045 MHz eingestellt ist.
Das kannst Du super im SDRSharp beobachten (=> Bei den Frequenzen sind die allgemeinen
Vorschriften zu beachten, sonst gibt es Ärger mit der Post).
Genauso kannst Du den CUL erst mal auf Deine Sender einstellen, wenn "autocreate" etc. auch eingestellt wurde, damit der CUL
auch neue Geräte anlegt ;)
Bei Deinem Sender kannst Du eigentlich nichts drehen, außer am Timing und am Protokoll. Die von Dir verwendeten Sender sind eigentlich sehr gut.
Bismosa hatte ja erwähnt, das u.U. die Takfrequenz des Digisparks nicht für die Umsetzung des Protokolls geeignet ist.
Hier kannst Du z.B. 10 Sek an eine LED vorgeben und prüfen ob sie wirklich 10s leuchtet.
Du kannst aber auch einen NANO o.ä. als Oszilloskop benutzen:
https://hackaday.com/2011/05/21/xoscillo-turns-arduino-in-an-oscilloscope/ (https://hackaday.com/2011/05/21/xoscillo-turns-arduino-in-an-oscilloscope/)
Damit lässt sich einiges anfangen ....
So hoffe, dass es einigermaßen verständlich (... und richtig) rübergekommen ist.
Jürgen
PS: Im Bild sieht man deutlich, dass sich der Sender innerhalb der
Bandbreite (bwidth-Setting) des CUL befindet, wenn er genau auf 433.92MHz liegen würde.
Timing:
https://forum.fhem.de/index.php/topic,56660.msg666579.html#msg666579 (https://forum.fhem.de/index.php/topic,56660.msg666579.html#msg666579)
https://alexbloggt.com/funkthermometer-sdr/ (https://alexbloggt.com/funkthermometer-sdr/)
https://www.kompf.de/weather/rtlsdrsensor.html (https://www.kompf.de/weather/rtlsdrsensor.html)
Allgemeines zum Thema:
https://www.dbawdy.de/allgemein/funkdaten-mitloggen-und-simulieren/ (https://www.dbawdy.de/allgemein/funkdaten-mitloggen-und-simulieren/)
Super Vielen Dank für diese ausführliche Info. Werde den CUL noch, wie von dir beschrieben, anpassen.
Bin mega Happy das es nun funktioniert.
Besten Dank noch einmal euch allen!!
... und etwas dazugelernt ;D
Und auch ich freue mich, das ich mir die gleichen Probleme nicht nur eingebildet hatte, sondern das auch andere manchmal neben den Frequenzen liegen. :)
@juergs
Super Beschreibung! Vielen Dank! Das hätte ich so nicht zum ausdruck bringen können.
Mit dem Senden ist natürlich eine gute Idee. Dann lässt sich der CUL super kalibrieren. Allerdings gibt es auch hier zu beachten, das die DVB-T Sticks nicht unbedingt genau sind. Auch hier kann es Abweichungen geben. Aber vielleicht kann man das auch auf einer bekannten Frequenz (z.B. FM-Bereich oder DVB-T Bereich...darauf achten, das man im legalen Bereich bleibt!) prüfen bzw. nachjustieren.
Aber eigentlich dürfte es doch jetzt nicht an den veränderten Timings liegen? Vielleicht sind so ein paar andere Toleranzen ausgeglichen...aber das eigentliche Problem sollte eher bei der schlecht eingestellten Frequenz liegen?
Ich bin ja auch kein Profi und habe nur gefährliches Halbwissen :) Vielleicht mal auf den RSSI achten? Damit es auch über eine längere Distanz funktioniert.
Ich wollte meine ganzen Sensoren so auch nochmal prüfen und meinen Empfänger darauf einstellen....dieser Beitrag hat mich mal wieder daran erinnert. Danke.
Schön, das es endlich voran geht!
Gruß
Bismosa
Ich habe gestern noch einen Reichweitentest im Haus gemacht und muss sagen....perfekt. Signal kam im ganzen Haus an. Da es mich dann noch interessierte, wie weit es im Freien geht bin ich mit Funktgerät los gezogen und mein Bub saß am PC. 130m waren noch kein Problem
Vielen Dank noch an Bimosa für seine extrem schnelle Antwort und Entschuldigung für meine lange Abwesenheit. Da mein digispark zunächst nicht funktionierte, habe ich einfach den hier vorhandenen Lacrosse Code mit der Deepsleep-Routine für Wemos D1 mini (mit DHT-Shield) versehen, was super funktioniert und auch nur wenig Strom verbraucht, da das WLAN nicht genutzt wird (aber sicher mehr, als Eure optimierten Modelle). Da ich aber nur alle 15min messe (was für die Temperatur im Keller oder Dachboden i.d.R. ausreicht) läuft auch der Wemos (gefühlt) ewig mit einer Billigst-Powerbank. (Code kann ich gern einstellen, wenn gewünscht)
Gleichwohl ist natürlich die Attiny-Version interessanter. Nachdem ich einen neuen bekam (Digispark Kickstarter) ging das Beschreiben mit der richtigen Bibliothek auch auf Anhieb. Anders als in der Diskussion zuletzt (?) legte autocreate auch sofort einen Hideki-device an, zeigte aber immer nur 99 Grad C, also den Fehlerwert. Das löste ich einfach, indem ich nach der Stromzufuhr nach dem Aufwachen (bei mir hier alle 5 min) ein delay einfügte, damit liefert der DHT22 auch etwa 7 von 8 Mal. Vorher hatte ich noch einen anderen Attiny und 2 andere DHT probiert, was nichts änderte. Damit erhielt ich auch einen Plot von Temp und Humidity durch den Hideki, aber stets auch noch einen Fehlerwert (wohl die Batterie?), den Hideki nicht verarbeiten konnte (fast immer nanoCUL: Unknown Code P12#75E0BA4A77470055).
Dann warf ich Hideki (samt der zugehörigen Bibliothek) aus dem Code raus, da Bimosa dankenswerter Weise ja Lacrosse drin ließ und nur auskommentiert hatte, was sehr gut funktionierte (mit dem zusätzlichen delay) und autocreate legte einen CUL_TX_100 mit Plot von Humidity und Temp an.
Einziges Problem derzeit: Der digispark (sowohl Kickstarter USB als auch mit micro-USB) ist sehr wählerisch in der Stromversorgung: Er funktioniert nur an einem USB-Netzteil von mir und direkt am USB von verschiedenen Rechnern. Weder 3 Powerbanks, noch USB-Hubs mit Stromversorgung (aber am selben Hub am Rechner) funktionieren. Spannungsmessungen von mir haben keine Unterschiede gezeigt.
So jetzt bin ich es wieder...
Nun habe ich mir eine tolle Platine aus China bestellt. Voller vorfreude meine Attiny85 geflasht alles zusammen gebaut und......nichts geht. Ich bin nun ein wenig Ratlos. Auf dem Funkmodul mit dem Digispark funktioniert alles wunderbar. Gleicher Code auf den Attiny und neuer Platine geht nichts.. Ich hab vor lauter verzweiflung nun schon den "funktionierenden" STX882 von meiner Testplatine gelötet und auf die neue drauf weil ich dachte das der Frequenzbereich der anderen eventuell nicht passt. Aber der CUL empfängt nichts. Nicht mal im Sniffer Modus. Auch habe ich eine LED an den Sendepin angeschlossen. Die "flackert" wunderbar. Sprich der Attiny schreibt auch etwas zum Sendemodul.
Kann mir jemand auf die sprünge helfen? Was der unterschied sein könnte? der Interne Takt des Attiny?
Hallo Bender78,
wenn Du uns verrätst, in welche Glaskugel wir schauen sollen? 8)
Schaltplan, Platine, Bilder?
Zitatder Interne Takt des Attiny
Fuses?
Jürgen
Zitat von: juergs am 13 Juni 2018, 19:41:37
Hallo Bender78,
wenn Du uns verrätst, in welche Glaskugel wir schauen sollen? 8)
Schaltplan, Platine, Bilder?
Fuses?
Jürgen
Sorry ich dachte das Ihr das nicht benötigt, da ich nur von der "funktionieren" Lochrasterplatine alles übertragen habe. Bitte mich wegen des Schaltplans nicht verreißen. Ich habe den "quick & dirty" gezeichnet. Der Pullup R3 geht auf den Pin X1.1... sieht man ein wenig schlecht... wie gesagt nur schnell gezeichnet... An den Fuses habe ich nichts verstellt.
Zitat von: Bender78 am 13 Juni 2018, 20:01:21
Ich habe den "quick & dirty" gezeichnet.
Kein Widerspruch von meiner Seite 8) 8) 8)
Die Verdrahtung ist ja für den ATtiny85 hier angegeben:
https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image (https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image)
@Bender78
Sind die Masseleitungen auf dem "Programmieradapter" (?) wirklich so verdrahtet?
Wenn Du den Blink-Sketch mit einder Sekunde Blinkdauer programmierst, blink die Led auch im Sekundenrythmus?
Welchen Controller nutzt Du, wirklich den ATtiny13?
Wenn Du die Fuses nicht veränderst hast, läuft der Controller mit 1MHz ....
fusecalc => attiny85 (http://eleccelerator.com/fusecalc/fusecalc.php?chip=attiny85)
Setting Fuses and uploading to ATTINY85 Chip (https://www.youtube.com/watch?v=Va2-4HYGK0Y)
http://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/ (http://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/)
Hallo Leute,
ich bin relativ neu im Forum oder immer nur lesendes Mitglied gewesen, jetzt möchte ich auch mal eine Frage stellen.
Ich weiß das der Thread schon etwas älter ist, für mich allerdings sehr Interesant.
Ich habe diese Sender selbst nachgebaut und die funktionieren einwandfrei allerdings habe ich auch einige handelsübliche Wetterstationen mit Lacrosse Protokoll die teilweise nicht oder nur ungenügend mit dem Protokoll zurecht kommen.
Kann mir da jemand von euch Experten weiterhelfen?
Zitathandelsübliche Wetterstationen mit Lacrosse Protokoll
Die laufen meist unter 868MHz und fallen in eine ganz andere Kategorie.
Danke für die schnelle Antwort aber ich habe tatsächlich welche von TFA, die meines Wissens das gleiche Protokoll nutzen, und von Lacrosse
Schaue mal dort:
https://forum.fhem.de/index.php/topic,36565.0.html (https://forum.fhem.de/index.php/topic,36565.0.html)
Vielen Dank :)
Zitat von: bismosa am 14 November 2017, 15:14:15
Noch offen:
1.) DHT-22, Genauigkeit?
Also ich will einen hydraulischen Abgleich machen und habe daher neun DHT-22 unmittelbar nebeneinander gestellt (kein Batteriebetrieb, sondern via USB-Stromversorgung). Dann habe ich gegen 22:00 die gemessenen Temperaturen so eingestellt, dass mir gleiche Werte gemeldet werden (,,Kalibrierung").
Ich hatte gehofft, dass dann im Laufe der Nacht die Funktionskurven nahe beeinander bleiben. Der Treffpunkt morgens erfolgte nur durch eine erneute händische Kalibrierung. Also die Dinger sind schon ziemlich ungenau.
Zum Thema Genauigkeit des DHT22 kannst Du hier im Forum viele Meinungen dazu finden:
https://forum.fhem.de/index.php/topic,83241.msg754792.html#msg754792 (https://forum.fhem.de/index.php/topic,83241.msg754792.html#msg754792)
Zitat... Dann habe ich gegen 22:00 die gemessenen Temperaturen so eingestellt ...
Was hast Du genau gemacht? Offsetverschiebung für einen oder für alle Sensoren?
Hängen alle an einem Controller?
DHT22:
Low cost
3 to 5V power and I/O
2.5mA max current use during conversion (while requesting data)
Good for 0-100% humidity readings with 2-5% accuracy
Good for -40 to 80°C temperature readings ±0.5°C accuracy
No more than 0.5 Hz sampling rate (once every 2 seconds)=> -40 to 80°C sind ja absolut 120 °C mit ±0.5°C sind das 1,2 °C Toleranz proSensor. (Best case!)
Das sehe ich auch in Deiner Aufzeichnung....
Das Thema Temperatur genau messen ist eine Wissenschaft für sich und ein Billig-Sensor
bleibt ein Billigsensor ;-)
"Genauere" Messungen gehen nur über "bessere" Meßtechnik und Sensoren:
z.B. Thermoelemente z.B. NiCrNi oder PT100/PT1000.
https://www.adafruit.com/product/269 (https://www.adafruit.com/product/269)
Zitat-200°C to +1350°C output in 0.25 degree increments - note that K thermocouples have about ±2°C to ±6°C accuracy
Zitat von: juergs am 26 November 2018, 19:48:45
Was hast Du genau gemacht? Offsetverschiebung für einen oder für alle Sensoren?
Hängen alle an einem Controller?
Ja, ich habe neun identische Konstruktionen, jeweils ein ESP8266 und eine kleine Leiterplatte dazu. Die steckten nebeneinander in einer Mehrfachsteckdose für eine Nacht und haben an FHEM gesendet. Jede Konstruktion hat ein eigenes device, dem ich dann ein userreading hinzugefügt habe. Diese userreading errechnet sich aus der gemessenen Temperatur minus/plus Offset und diesen Offset habe ich eingestellt.
Klar, das sind absolute Billigsensoren und ich habe die aus China. An sich muss ich sagen, dass eine Toleranz von 1,5°C schon richtig gut ist - ich scheitere momentan eher daran, dass ich in den Räumen (für den hydraulischen Abgleich) keine verlässlichen Temperaturen messen kann. Ist nämlich schon die Frage, wo genau ich messe: Innenraum, Mitte, am Fußboden etc. pp. Ich habe jetzt so eine Behelfslösung, mit der messe ich ausreichend genug und dann schaffe ich den Abgleich schon so, dass es am Ende irgendwie reichen wird. Ich habe nicht erwartet, an diesen Stellen Probleme zu haben.
Vielleicht ist ein BME280 für Dich die bessere Wahl:
BME280 (https://cdn-reichelt.de/documents/datenblatt/B400/BST-BME280_DS001-10.pdf)
Bist Du sicher, dass 1..2 °C "Ungenauigkeit" für Deine Messung/Prozess Relevanz hat?
http://nerdralph.blogspot.com/2015/11/ (http://nerdralph.blogspot.com/2015/11/)
Test and Calibrate DHT22 Hygrometers (http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_dht22.html)
ZitatThe newer much improved data sheet now specifies that the quoted accuracy of ±2% is tested at a constant 25°C
Wide range of Hygrometers:DHT22, AM2302, AM2320, AM2321, SHT71, HTU21D, Si7021, BME280 (http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html)
Nicht lineares Mapping:
http://interface.khm.de/index.php/lab/interfaces-advanced/nonlinear-mapping/ (http://interface.khm.de/index.php/lab/interfaces-advanced/nonlinear-mapping/)
Zitat von: andies am 26 November 2018, 07:33:41
Also ich will einen hydraulischen Abgleich machen...
Ist jetzt etwas OT.
Würde den Abgleich so machen.
Vor und Rücklauf voll aufdrehen.
Nen halben oder ganzen Tag warten bis der Raum sich aufgeheizt hat.
Dann den Rücklauf zu drehen. Soweit bis du die richtige Temperatur erreicht hat.
Wichtig. Alle Kreisläufe müssen die gleiche Temperatur haben. Kannst du mit nem IR Thermometer messen oder mit den Füßen.
[emoji12]
Mit den Füßen kann man angeblich bis zu einem halben Grad Differenz fühlen.
Dann warten bis die gewünschte temperature sich eingestellt hat.
Rücklauf dann wieder ne viertel Umdrehung aufmachen und dann kannst du über den Vorlauf regeln.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Danke, im Grunde mache ich das so. Die Temperaturfühlung will ich aber mehr ,,objektivieren" und bin jetzt auf messbare Unterschiede von Raum zu Raum auf 2 Grad C runter. Mein Ziel ist 1 Grad Unterschied, ich habe ja Zeit und Geduld und X Messinstrumente (zuzüglich IR-Thermometer, habe es mal krachen lassen).
Aber warum soll ich dann wieder aufdrehen? Ich würde das dann so lassen und die abgeglichenen Räume wären alle gleich warm, dachte ich.
Gesendet von iPhone mit Tapatalk Pro
Du musst mit den kleinsten Raum anfangen den einzustellen. Wenn du mir den größten anfängst und dann den kleinsten, muss du bei dem kleinsten weißt aufdrehen damit du die Wärme menge hin bekommst. Dann hast du unter Umständen einen thermischen Kurzschluss bzw. Ben hydraulischen Kurzschluss. Dann würde zuviel Wärme über den kleinsten Raum geben und der Rest bricht zusammen.
Wieder etwas aufdrehen, damit du etwas zu regeln hast.
Oder willst du einmal einstellen und gut ist?
Die Heizung sind ja Wetter geführt sein.
Dann musst du noch die Heizkurve einstellen.
Du wirst aber nie alle räume gleich bin bekommen.
Habe angefangen meine FBH über Stellantriebe und das pwm und pwmr Modul zu regeln. Habe in den entsprechenden Zimmer nur einen LaCrosse Sensor drin.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Hi Sascha, danke für die Hilfe. Ich will schon das hier
Zitat von: sash.sc am 26 November 2018, 21:47:50
Oder willst du einmal einstellen und gut ist?
und das Ding ist wettergeführt. Bisher waren zwei kleine Räume einfach zu warm und einer zu kalt, das mit der zu hohen Wärme habe ich inzwischen im Griff. Jetzt ist Feineinstellung dran, danach Heizkurve. Aber nun habe ich doch noch eine Frage, weil ich (zu?) viele Daten habe. Wonach richte ich mich denn bei der Einstellung des Ventils, was soll in den Räumen identisch sein:
- Die Raumtemperatur (die ich derzeit mit einem oder zwei Sensoren im Raum verteilt messe)?
- Die Zulauftemperaturen am Heizkörper (sind zwischen 39 und 41 Grad)?
- Die Rücklauftemperaturen am Heizkörper (die schwanken sehr stark, beim runtergeregelten Raum mit viel zu großen Heizkörper sind das 25 Grad, ich komme bis zu 33 Grad in einem eher kälteren Raum)?
Ich würde immer die Raumtemperatur nehmen, bei voll aufgedrehten Thermostaten, und dann versuchen, in etwa eine festgelegte Temperatur zu erreichen. Oder bin ich da auf dem Holzweg?
Am besten schaust du mal hier nach.
https://www.co2online.de/energie-sparen/heizenergie-sparen/hydraulischer-abgleich/wie-funktioniert-der-hydraulische-abgleich/
https://www.intelligent-heizen.info/heizung-optimieren/hydraulischer-abgleich/
https://www.hydraulischer-abgleich.de/start/
(https://www.co2online.de/energie-sparen/heizenergie-sparen/hydraulischer-abgleich/wie-funktioniert-der-hydraulische-abgleich/)
Denke das wird sonst zu offtopic.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Hallo in die Experten Runde
hatte den Sketch von Juergs in topic,52755.15.html auf einen Attiny 85 geflasht jetzt wo der Winter kommt werden bei mir keine - Temperaturen angezeigt angezeigt hat dafür einer von euch ne Lösung? Bin für jede Hilfe dankbar.
MfG hbulf
Hallo hbulf,
sorry, aber anhand Deinen Infos kann man leider wirklich nicht viel diagnostizieren.
1. Annahme: Sensor im Außenbereich + niedrige Temperaturen?
2. Annahme: Akku oder Batteriebetrieb, welcher Typ?
3. Annahme: Batterie leer? Schon getauscht? Nochmal kurz resettet? Nicht lange genug gewartet, bis ein Daten-Paket gesended wird?
Ansonsten Bild etc. .. ;)
Ggf. kommt noch ein Timing Problem in Frage.
Hier über die FHEM-Suche kannst Du evtl. die "optimierten" Timingdaten (https://forum.fhem.de/index.php/topic,52755.msg790478.html#msg790478) herausfinden...
Hier, die wohl besseren Einstellungen: https://forum.fhem.de/index.php/topic,52755.msg747406.html#msg747406 (https://forum.fhem.de/index.php/topic,52755.msg747406.html#msg747406)
Grüße,
Jürgen
Hallo Juergs
vielen Dank für deine schnelle Antwort.
Also der Sender läuft auf Akku Betrieb mit einem DHT 22 und ist im Aussenbereich angebracht Akku ist voll aufgeladen.
Solange plus Grade sind ist alles schick nur wenn die Temperatur unter Null Grad geht zeigt er nichts mehr an, um genau zu sein bis -0,9 zeigt er Null Grad ab 1,0 nichts mehr
Hallo hbulf,
Ich vermute, dass negative Temperaturen im Moment nicht angezeigt werden können. Das bedingt einen positiven Offset von z.B. +20 Grad, die in fhem wieder subtrahiert werden müssen. Das wird ähnlich auch bei anderen Messgrößen so gemacht.
/edit: Aber hier (http://www.f6fbb.org/domo/sensors/tx3_th.php):
ZitatFor temperature, an offset of 50 deg has to be substracted from the measure
Ich schau mir das Mal am WoE in Ruhe an. Geht ja auch nur im Gefrierfach 😄
Vielen Lieben Dank :)
Hallo zusammen,
die Tageszeiten werden wieder kürzer und ich sitze wieder vor FHEM..
Ich habe eine Frage an die spezialisten unter Euch.
Ich möchte wieder an das Projekt meiner Raumtemperatur und Raumfeuchte Sensoren gehen.
Mit Hilfe dem auf GitHub veröffentlichten Programm von Matthias Kleine (https://github.com/klein0r/arduino-tx3 (https://github.com/klein0r/arduino-tx3))funktioniert das mit einem Arduino Nano und einem STX882 wunderbar. Alle 10sek werden ohne Probleme die Werte auf FHEM empfangen. Da ich aber einen Nano nicht wirklich zum Stromsparen bewegen kann (Sleep bei ca. 1,6mA) dachte ich mir, brenne ich alles auf einen Attiny85. Gesagt getan. Nun ist es so dass ich immer nur sporadisch die Werte empfange (alle 3-5) Minuten. Eigentlich ist es ja kein Problem, da mir diese Auflösung komplett reicht. Aber der Attiny wird eigentlich alle 8Sek. aus seinem Tiefschlaf geholt (0,015mA).
Zuerst dachte ich das es an der Spannung liegt (3,3V) deswegen habe ich mit 5V getestet. Den Deep Sleep ebenfalls ausgeschaltet. Aber immer das gleiche Problem. Der Attiny macht seinen Job nicht so "regelmäßig" wie der Nano. Ich betreibe den Attiny allerdings mit 1Mhz und nicht mit 16Mhz. könnte dass das Problem sein? Normal nicht oder?
Hallo Bender78,
Das liegt eher an der Auflösung des Timers, da dessen Überläufe gezählt werden müssen!
Der Nano hat noch Spannungsregler auf dem Board.
Deren Leerlauf-Stromverbrauch ist sehr hoch...
Dein angegebener Stromverbrauch erscheint mir ok...
Ich gehe davon aus, dass Du noch den Code von Programm von Matthias Kleine benutzt?
Wie sieht es aus, wenn Du diesen hier aus diesem Thread mal flashst?
Jürgen
Zitat von: juergs am 04 Dezember 2018, 15:37:10
Hallo Bender78,
Das liegt eher an der Auflösung des Timers, da dessen Überläufe gezählt werden müssen!
Ich gehe davon aus, dass Du noch den Code von Programm von Matthias Kleine benutzt?
Wie sieht es aus, wenn Du diesen hier aus diesem Thread mal flashst?
Jürgen
Hallo Jürgen,
danke für deine Antwort. Leider komme ich erst jetzt dazu weitere Fragen zu stellen :D ...Vorweihnachtsstress...
Kannst du mir vielleicht genauer erläutern was es mit der Auflösung des Timers zu tun hat? Ich würde es gerne verstehen wollen, bin aber in der Thematik absoluter Anfänger.
Ja ich verwende den Code von Matthias Kleine. Es hat mich so gefreut, das ich es auf anhieb geschafft habe und hab daher keinen weiteren Code mehr getestet. Im Grunde reicht es mir ja auch, dass nur alle paar Minuten ein Wert bei FHEM ankommt. Aber natürlich ist es ja nicht Sinn und Zweck, wenn der kleine Kerl alle 8 Sek aus seinem schlaf geholt wird und dann nichts empfangen wird.
Die Antwort ist eigentlich ganz einfach:
Du hattest es eigentlich schon selbst erwähnt:
Zitat... dass nur alle paar Minuten.
Vereinfachtes Rechenbeispiel: 1 Minute = 60 Sekunden = 60 * (1/8 Millionen Takte = geschätzte Taktrate ATtiny ggf. abzüglich Prescaler-Einstellungen)
Näheres:https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR (https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR)
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Power_Management#Sleep_Modi (https://www.mikrocontroller.net/articles/AVR-Tutorial:_Power_Management#Sleep_Modi)
Zitat... Das alleine wäre noch nicht allzu nützlich, wenn nicht dieses Hardwareregister bei bestimmten Zählerständen einen Interrupt auslösen könnte.
Ein solches Ereignis ist der Overflow (Überlauf): Da die Bitbreite des Registers beschränkt ist, kommt es natürlich auch vor, dass der Zähler so hoch zählt, dass der nächste Zählerstand mit dieser Bitbreite nicht mehr darstellbar ist und der Zähler wieder auf 0 zurückgesetzt wird.
Deshalb muss der Controller früher aufwachen und prüfen, ob die Anzahl der Überläufe den gewünschten Minuten-Zählerwert erreicht hat.
Wenn nicht geht er wieder einen Timer-Overflow-Zyklus schlafen ...
Sagen wir mal so: das muss System-bedingt so sein ;-)
Zitat von: juergs am 08 Dezember 2018, 12:02:11
Deshalb muss der Controller früher aufwachen und prüfen, ob die Anzahl der Überläufe den gewünschten Minuten-Zählerwert erreicht hat.
Wenn nicht geht er wieder einen Timer-Overflow-Zyklus schlafen ...
Sagen wir mal so: das muss System-bedingt so sein ;-)
Dank Jürgen. OK. Aber wenn ich den Sleep deaktiviere habe ich ja das selbe problem, dass er nicht regelmäßig sendet. Ich dachte ja zunächst auch das es daran liegt. Aber das habe ich ja dann auch getestet ohne Sleep des Attiny
So.. nun habe ich alles noch einmal auf das Wesentliche reduziert.
Es bleibt dabei. Alle 20sek. - 5 Minuten kommt ein Wert an. Komplett unterschiedlich. Habe eine LED ziwschen SendePin und GND gesteckt. Diese pollt regelmäsig alle 5sek.
Würde nur gerne verstehen, warum das so ist..
#include <TX3.h>
///#include <avr/sleep.h>
///#include <avr/wdt.h>
#include "DHT.h"
#define PIN_SEND PB3
#define SENSORID 101
#define DHT22PIN PB4
TX3 tx3(PIN_SEND, SENSORID);
//DHT dht22(DHT22PIN, DHT22);
void setup() {
//dht22.begin();
}
void loop() {
//float humidity = dht22.readHumidity();
//float temp = dht22.readTemperature();
tx3.sendHumidity(55.5);
tx3.sendTemperature(23.3);
delay(5000);
}
... schaue doch mal da rein: https://github.com/juergs/_ATtiny85_DHT22_BMP180_433 (https://github.com/juergs/_ATtiny85_DHT22_BMP180_433)
bzw. packe mal den gesamten Code zusammen und poste diesen ...
Bei dem delay(500) scheint das Timing es ja korrekt zu funktionieren ...
Könntest Du auch mal negative Temperaturen testen?
Jürgen
Hallo Jürgen,
vielen Dank für deine Hilfe. Ich denke ich werde morgen mal dein Programm testen. Bin gerade ein wenig enttäuscht von dem Dallas 18b20 mit dem habe ich alles getestet. Der lag bei Zimmertemperatur nur 0,2 Grad unter meinem Temperaturmessgerät. Nun aber unser Tiefkühle komplett daneben. Dort sind ca -20°C und angezeigt hat er -49°C 🤔
Hallo Jürgen,
gibt es schon neue Erkenntnisse warum das mit den Minus Temperaturen nicht funktioniert?
VG
Ulf
http://nerdralph.blogspot.com/2015/11/ds18b20-temperature-sensor-calibration.html (http://nerdralph.blogspot.com/2015/11/ds18b20-temperature-sensor-calibration.html)
https://wp.josh.com/2014/06/23/no-external-pull-up-needed-for-ds18b20-temp-sensor/ (https://wp.josh.com/2014/06/23/no-external-pull-up-needed-for-ds18b20-temp-sensor/)
Hallo hbulf,
sorry, "Zeitproblem" + musste erst wieder Testsystem aufbauen ...
Ich habe den Code hier für den ATtiny85_1820_433 (https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp) nochmal nur für den 18B20 zusammengestellt.
Die ID im Code lautet 80. Die von anderen vorgeschlagenen Timings habe ich mal mit im Code angegeben.
Heute könnte es auch mit den negativen Temperaturen klappen, deshalb habe ich den Sensor mal Außen positioniert. ;)
2018-12-15_16:33:06 CUL_TX_80 T: 21.4
2018-12-15_16:33:06 CUL_TX_80 temperature: 21.4
2018-12-15_16:36:20 CUL_TX_80 T: 21.4
2018-12-15_16:36:20 CUL_TX_80 temperature: 21.4
2018-12-15_16:39:34 CUL_TX_80 T: 22.0
2018-12-15_16:39:34 CUL_TX_80 temperature: 22.0
2018-12-15_16:42:48 CUL_TX_80 T: 21.6
2018-12-15_16:42:48 CUL_TX_80 temperature: 21.6
2018-12-15_16:46:03 CUL_TX_80 T: 21.
2018-12-15_16:46:03 CUL_TX_80 temperature: 21.6
2018-12-15_16:49:17 CUL_TX_80 T: 21.5
2018-12-15_16:49:17 CUL_TX_80 temperature: 21.5
2018-12-15_16:52:31 CUL_TX_80 T: 21.5
2018-12-15_16:52:31 CUL_TX_80 temperature: 21.5
2018-12-15_16:55:45 CUL_TX_80 T: 21.5
2018-12-15_16:55:45 CUL_TX_80 temperature: 21.5
2018-12-15_16:58:59 CUL_TX_80 T: 21.5
2018-12-15_16:58:59 CUL_TX_80 temperature: 21.5
2018-12-15_17:02:14 CUL_TX_80 T: 21.4
2018-12-15_17:02:14 CUL_TX_80 temperature: 21.4
2018-12-15_17:05:28 CUL_TX_80 T: 21.4
2018-12-15_17:05:28 CUL_TX_80 temperature: 21.4
2018-12-15_17:10:02 CUL_TX_80 T: 11.1
2018-12-15_17:10:02 CUL_TX_80 temperature: 11.1
2018-12-15_17:13:15 CUL_TX_80 T: 4.1
2018-12-15_17:13:15 CUL_TX_80 temperature: 4.1
2018-12-15_17:16:28 CUL_TX_80 T: 2.8
2018-12-15_17:16:28 CUL_TX_80 temperature: 2.8
2018-12-15_17:19:41 CUL_TX_80 T: 1.5
2018-12-15_17:19:41 CUL_TX_80 temperature: 1.5
2018-12-15_17:26:06 CUL_TX_80 T: 1.4
2018-12-15_17:26:06 CUL_TX_80 temperature: 1.4
2018-12-15_17:29:18 CUL_TX_80 T: 1.1
2018-12-15_17:29:18 CUL_TX_80 temperature: 1.1
2018-12-15_17:32:31 CUL_TX_80 T: 0.6
2018-12-15_17:32:31 CUL_TX_80 temperature: 0.6
2018-12-15_17:38:56 CUL_TX_80 T: 0.5
2018-12-15_17:38:56 CUL_TX_80 temperature: 0.5
2018-12-15_17:45:21 CUL_TX_80 T: 0.6
2018-12-15_17:45:21 CUL_TX_80 temperature: 0.6
2018-12-15_17:48:34 CUL_TX_80 T: 0.7
2018-12-15_17:48:34 CUL_TX_80 temperature: 0.7
2018-12-15_17:54:59 CUL_TX_80 T: 1.3
2018-12-15_17:54:59 CUL_TX_80 temperature: 1.3
2018-12-15_17:58:11 CUL_TX_80 T: 0.7
2018-12-15_17:58:11 CUL_TX_80 temperature: 0.7
2018-12-15_18:01:24 CUL_TX_80 T: 0.5
2018-12-15_18:01:24 CUL_TX_80 temperature: 0.5
2018-12-15_18:04:36 CUL_TX_80 T: 1.4
2018-12-15_18:04:36 CUL_TX_80 temperature: 1.4
2018-12-15_18:11:02 CUL_TX_80 T: 0.6
2018-12-15_18:11:02 CUL_TX_80 temperature: 0.6
2018-12-15_18:17:27 CUL_TX_80 T: 0.9
2018-12-15_18:17:27 CUL_TX_80 temperature: 0.9
2018-12-15_18:20:39 CUL_TX_80 T: 0.7
2018-12-15_18:20:39 CUL_TX_80 temperature: 0.7
2018-12-15_18:23:52 CUL2018-12-16_04:27:06 CUL_TX_80 temperature: 0.3
2018-12-16_04:30:19 CUL_TX_80 T: 0.0
2018-12-16_04:30:19 CUL_TX_80 temperature: 0.0
2018-12-16_04:33:31 CUL_TX_80 T: 0.0
2018-12-16_04:33:31 CUL_TX_80 temperature: 0.0
2018-12-16_04:36:44 CUL_TX_80 T: 0.0
2018-12-16_04:36:44 CUL_TX_80 temperature: 0.0
2018-12-16_04:39:56 CUL_TX_80 T: 0.0
2018-12-16_04:39:56 CUL_TX_80 temperature: 0.0
2018-12-16_04:43:09 CUL_TX_80 T: 0.0
2018-12-16_04:43:09 CUL_TX_80 temperature: 0.0
2018-12-16_04:46:21 CUL_TX_80 T: 0.9
2018-12-16_04:46:21 CUL_TX_80 temperature: 0.9
2018-12-16_04:49:34 CUL_TX_80 T: 0.0
2018-12-16_04:49:34 CUL_TX_80 temperature: 0.0
2018-12-16_04:55:58 CUL_TX_80 T: 0.0
2018-12-16_04:55:58 CUL_TX_80 temperature: 0.0
2018-12-16_05:12:01 CUL_TX_80 T: 0.0
2018-12-16_05:12:01 CUL_TX_80 temperature: 0.0
2018-12-16_05:15:13 CUL_TX_80 T: -45.0
2018-12-16_05:15:13 CUL_TX_80 temperature: -45.0
2018-12-16_05:44:05 CUL_TX_80 T: -45.0
2018-12-16_05:44:05 CUL_TX_80 temperature: -45.0
2018-12-16_05:47:17 CUL_TX_80 T: -45.0
2018-12-16_05:47:17 CUL_TX_80 temperature: -45.0
2018-12-16_05:50:30 CUL_TX_80 T: -45.0
2018-12-16_05:50:30 CUL_TX_80 temperature: -45.0
2018-12-16_05:53:42 CUL_TX_80 T: -45.0
Dann müssen wir die negativen Temperaturen noch Mal genauer anschauen.
Ach ja, die Schaltung wurde eingeschneit und muss erst Mal trocknen ;D
Zum Ausprobieren:
https://www.tutorialspoint.com/online_c_compiler.php (https://www.tutorialspoint.com/online_c_compiler.php)
In
SendTemperature werden 50 °C zu den Zehner-Stellen der gemessenen Temperatur hinzugefügt!
#include <stdio.h>
#define TX3_MODELID 0x0A
#define sensorId 110
void sendNibbles(int type, int tens, int ones, int tenths);
void sendNibble(int i);
void sendTemperature(float t);
void O();
void I();
int main()
{
float t = -10.5;
printf("Hello, World. Testing temperatures below zero!\n");
sendTemperature(t);
printf("\n");
printf("Float: %2.1f\n",t);
int tens = ((int)t / 10) + 5;
int ones= ((int)t % 10);
int tenths = ((int)t * 10) % 10;
printf("Tens: %d ones: %d tenths: %d\n",tens,ones,tenths);
return 0;
}
void sendTemperature(float t)
{
sendNibbles(
0,
((int)t / 10) + 5,
((int)t % 10),
((int)t * 10) % 10
);
}
void sendNibbles(int type, int tens, int ones, int tenths)
{
int idr, checksum, parity;
int nibble1, nibble2, nibble3, nibble4, nibble5, nibble6, nibble7, nibble8, nibble9, nibble10;
// left nibble of Model
nibble1 = TX3_MODELID / 0x10;
// right nibble of Model
nibble2 = TX3_MODELID & 0xF;
nibble3 = type;
// Nibble 4 is the left part of the Id
// 1101 111?
// 0110 1111
nibble4 = sensorId / 0x08;
nibble6 = tens;
nibble7 = ones;
nibble8 = tenths;
nibble9 = tens;
nibble10 = ones;
// For Parity we need the last 3 bits of the Sensor ID
idr = sensorId & 0x7;
// Parity bit makes even parity for sum
parity = (nibble4 + idr + nibble6 + nibble7 + nibble8 + nibble9 + nibble10) & 0x1;
// nibble 5 is last 3 digits of Sensor and parity bit
nibble5 = ((idr * 0x2) + parity) & 0xF;
// Checksum nibble of all nibbles
checksum = (nibble1 + nibble2 + nibble3 + nibble4 + nibble5 + nibble6 + nibble7 + nibble8 + nibble9 + nibble10) & 0xF;
for (int r = 0; r < 1; r++) {
//if(r > 0) delay(20);
sendNibble(nibble1);
sendNibble(nibble2);
sendNibble(nibble3);
sendNibble(nibble4);
sendNibble(nibble5);
sendNibble(nibble6);
sendNibble(nibble7);
sendNibble(nibble8);
sendNibble(nibble9);
sendNibble(nibble10);
sendNibble(checksum);
}
}
void sendNibble(int i)
{
if (i & 8) I(); else O();
if (i & 4) I(); else O();
if (i & 2) I(); else O();
if (i & 1) I(); else O();
}
void O()
{
// sends zero
printf("0");
}
void I()
{
printf("1");
}Zitat
sh-4.4$ gcc -o main *.c
sh-4.4$ main
Hello, World. Testing temperatures below zero!
00001010000011011101010000000000010000001100
Float: -10.5
Tens: 4 ones: 0 tenths: 0
1 10 20 30 40 44
12345678901234567890123456789012345678901234567890
00001010000011011101010000000000010000001100
http://www.f6fbb.org/domo/sensors/tx3_th.php (http://www.f6fbb.org/domo/sensors/tx3_th.php)
https://github.com/guillier/433mhz_receiver/blob/master/tx_433mhz_digispark.ino (https://github.com/guillier/433mhz_receiver/blob/master/tx_433mhz_digispark.ino)
Hier das Problem (Beispiel: -12.5 °C):
Hello, World. Testing temperatures below zero!
00001010000011011101010011100000010011101000
Float: -12.5
Tens: 4 ones: -2 tenths: 0
und SendNibbles erwartet positive Zahlen !
void TX3::sendTemperature(float t)
{
int tens = ((int)t / 10) + 5; //with + 50 degrees offset
int ones= ((int)t % 10);
int tenths = ((int)t * 10) % 10;
//--- Erster Workaround: negatives hier verbieten
if (ones < 0) ones = abs(ones);
if (tenths < 0) tenths = abs(tenths);
sendNibbles(
TX3_COM_TEMP,
tens, //+ 50 degrees offset
ones,
tenths
);
}
-12.5 °C liefert fhem:
state T: -8.0 2018-12-16 15:09:48
temperature -8.0 2018-12-16 15:09:48
Aber:
Hello, World. Testing temperatures below zero!
00001010000011011101010000100000010000100000
Float: -12.5
Tens: 4 ones: -2 tenths: 0
Tens: 4 einer: 2 dezimale: 0
50 -40 + 2 = -8 °C
Stimmt zwar in der fhem, aber kann das TX3 Protokoll negative Einer-Stellen?.
Also müssen wir das anders angehen...
Ok, hier der Trick für negative Temperaturen:
=> negative Temperaturen müssen aufbereitet werden (Offset von +50 °C, werden im Protokoll bzw. fhem weggerechnet!).
void TX3::sendTemperature(float t)
{
int tens, ones, tenths ;
if (t >= 0)
{
tens = ((int)t / 10) + 5; //with + 50 degrees offset
ones= ((int)t % 10);
tenths = ((int)t * 10) % 10;
}
else
{
//-- Beispiel: 50 + (- 12.5) = 37,5
t = 50 + t;
tens = ((int)t / 10); //with + 50 degrees offset
ones= ((int)t % 10);
tenths = ((int)t * 10) % 10;
}
sendNibbles(
TX3_COM_TEMP,
tens, //+ 50 degrees offset
ones,
tenths
);
}
Zum nachprüfen: (https://www.tutorialspoint.com/online_c_compiler.php)
#include <stdio.h>
#include <stdlib.h>
#define TX3_MODELID 0x0A
#define sensorId 110
void sendNibbles(int type, int tens, int ones, int tenths);
void sendNibble(int i);
void sendTemperature(float t);
void O();
void I();
int main()
{
int tens, ones, tenths, einer , zehner, dezimale ;
float t = -12.5;
printf("Hello, World. Testing temperatures below zero!\n");
sendTemperature(t);
printf("\n");
printf("Float: %2.1f\n",t);
if (t> 0)
{
tens = ((int)t / 10) + 5;
ones = ((int)t % 10);
tenths = ((int)t * 10) % 10;
printf("Tens: %d ones: %d tenths: %d\n",tens, ones, tenths);
}
else
{
t = 50 + t;
printf("Float: %2.1f\n",t);
tens = ((int)t / 10);
ones = ((int)t % 10);
tenths = ((int)t * 10) % 10;
printf("Zehner: %d Einer: %d Dezimale: %d\n",tens, ones , tenths );
}
return 0;
}
void sendTemperature(float t)
{
sendNibbles(
0,
((int)t / 10) + 5,
abs(((int)t % 10)),
abs(((int)t * 10) % 10)
);
}
void sendNibbles(int type, int tens, int ones, int tenths)
{
int idr, checksum, parity;
int nibble1, nibble2, nibble3, nibble4, nibble5, nibble6, nibble7, nibble8, nibble9, nibble10;
// left nibble of Model
nibble1 = TX3_MODELID / 0x10;
// right nibble of Model
nibble2 = TX3_MODELID & 0xF;
nibble3 = type;
// Nibble 4 is the left part of the Id
// 1101 111?
// 0110 1111
nibble4 = sensorId / 0x08;
nibble6 = tens;
nibble7 = ones;
nibble8 = tenths;
nibble9 = tens;
nibble10 = ones;
// For Parity we need the last 3 bits of the Sensor ID
idr = sensorId & 0x7;
// Parity bit makes even parity for sum
parity = (nibble4 + idr + nibble6 + nibble7 + nibble8 + nibble9 + nibble10) & 0x1;
// nibble 5 is last 3 digits of Sensor and parity bit
nibble5 = ((idr * 0x2) + parity) & 0xF;
// Checksum nibble of all nibbles
checksum = (nibble1 + nibble2 + nibble3 + nibble4 + nibble5 + nibble6 + nibble7 + nibble8 + nibble9 + nibble10) & 0xF;
for (int r = 0; r < 1; r++) {
//if(r > 0) delay(20);
sendNibble(nibble1);
sendNibble(nibble2);
sendNibble(nibble3);
sendNibble(nibble4);
sendNibble(nibble5);
sendNibble(nibble6);
sendNibble(nibble7);
sendNibble(nibble8);
sendNibble(nibble9);
sendNibble(nibble10);
sendNibble(checksum);
}
}
void sendNibble(int i)
{
if (i & 8) I(); else O();
if (i & 4) I(); else O();
if (i & 2) I(); else O();
if (i & 1) I(); else O();
}
void O()
{
// sends zero
printf("0");
}
void I()
{
printf("1");
}
Fazit:
Immer nur Copy&Paste .... werden auch Fehler mitkopiert ;D :D ;)
Ich passe meinen Code im LaCrosse-Code auch noch an, dann können wir auch negative Temperaturen messen.
Grüße,
Jürgen
Nach Analyse des Timings, hier die Einstellungen für PLL-Takt (Nicht 8MHz, ohne Divider):
Fuses:
LF=0xF1 HF= 0xDF EF=0xFF Lock= 0x03Zitat// NEU:
int iLongPulse = 1300;
int iShortPulse = 500;
int iDelay = 1100;
Enspricht dem Timing von http://www.f6fbb.org/domo/sensors/tx_signals.php (http://www.f6fbb.org/domo/sensors/tx_signals.php)
Bit_0: 1,3ms HIGH + 1,0ms LOW => Gesamt: 2,3 ms |
| Bit_1: 0,5ms HIGH + 1,1ms LOW => Gesamt: 1,6ms |
|
Code ATtiny85_433MHz_LaCrosse_Temp (https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp)
Je nach c-Compiler (https://www.tutorialspoint.com/compile_c_online.php) (!) scheint das hier der richtige cast von float auf int zu sein:
if (t> 0)
{
tens = ((int)t / 10) + 5;
ones = ((int)t % 10);
tenths = (int)(t * 10) % 10;
printf("Tens: %d ones: %d tenths: %d\n", tens, ones, tenths);
}
else
{
t = 50 + t;
printf("Float: %2.1f\n",t);
tens = ((int)t / 10);
ones = ((int)t % 10);
tenths = (int) (t * 10) % 10;
//tenths = abs(tenths);
printf("Zehner: %d Einer: %d Dezimale: %d\n",tens, ones, tenths);
}Positive temperaturen 32,5 °C:
ZitatHello, World. Testing temperatures below zero!
00001010000011011101100000100000100000101000
Float: 32.5
Tens: 8 ones: 2 tenths: 5
Negative Temperaturen -32,5°C:
ZitatHello, World. Testing temperatures below zero!
00001010000011011101001000100000001000101100
Float: -32.5
Float: 17.5
Zehner: 1 Einer: 7 Dezimale: 5
Ergibt in LaCrosse.cpp diese korrekte/funktionierende Methode CalcTemp:
//-----------------------------------
void LaCrosseClass::CalcTemp()
{
if (t>= 0)
{
tens = ((int)t / 10) + 5;
ones = ((int)t % 10);
tenths = (int)(t * 10) % 10;
}
else
{
//--- negative temperatures
t = 50 + t;
tens = ((int)t / 10);
ones = ((int)t % 10);
tenths = (int) (t * 10) % 10;
}
//--- we send a temperature id
nible3 = COM_TEMP;
}
//-----------------------------------Angehängtes Hex-File ist auf ID 80 compiliert.
Hallo Jürgen,
vielen lieben Dank für deine Mühe.
Leider hat mich die Grippe gepackt so das ich erst die nächsten Tage testen kann.
Super Forum hier da wirdeinen sofort geholfen.
:D
MfG Ulf
Hallo Jürgen,
hab da mal einen Scetch an gehangen der bei mir mit einer Lacrosse Wetterstation perfekt funktioniert hat (keine Ausfälle nichts)
Allerdings wird hier keine Feuchte gesendet und meine Programmier Kenntnisse reichen leider nicht aus um auch die Feuchte mit senden zu lassen.
Vielleicht hilft das auch anderen bei der Problemlösung ;)
Für den DHT22 hatte ich schon mal ein Lösung gepostet: _ATtiny85_DHT22_BMP180_433.ino (https://github.com/juergs/_ATtiny85_DHT22_BMP180_433/blob/master/_ATtiny85_DHT22_BMP180_433.ino)
Hallo Jürgen,
wow.. vielen Dank für die überarbeitete Version. Ich möchte das auch alles können :'( *g* Respekt...
Soweit funktioniert alles. Komischerweise am Anfang gar nicht. Es kam nur unbekanntes Protokoll im Event Monitor. Aber auf einmal ging es dann. Lediglich habe ich noch nicht heraus gefunden wie du die Batterie Spannung ebenfalls überträgst. Ich habe schon "#define USE_SEPARATE_BATTERIE_ID " auskommentiert. Aber es kommt weiterhin nur die Temperatur.
Mittlerweile habe ich auch das andere Problem von mir gelöst. Es war der interne Takt von 1Mhz. Habe diesen nun auf 8 Mhz gestellt und siehe da, FHEM empfängt "fast" alle 8 Sek. die Daten des Attiny.
Soweit tut es das für mich nun. Ich denke ich werde das ganze nun auf eine Platine aus China brutzeln und dann in eine Schalterdose packen. Davor ein schönes Gehäuse eines Jung Raumthermostat. und dann habe ich tolle und günstige Funk Temperatur Sensoren.
Zitat von: juergs am 20 Dezember 2018, 20:00:29
Für den DHT22 hatte ich schon mal ein Lösung gepostet: _ATtiny85_DHT22_BMP180_433.ino (https://github.com/juergs/_ATtiny85_DHT22_BMP180_433/blob/master/_ATtiny85_DHT22_BMP180_433.ino)
Hallo Jürgen,
Dein Programm für den onewire Dallas funktioniert super. Bekomme nun regelmäßig die Info wie kühl es in meinem Bierkühler im Garten ist. Danke dafür noch einmal.
Da ich nun auch mit dem Dht22 spielen wollte Bzw mir Außentemperatur + Luftfeuchtigkeit an fhem senden möchte habe ich den obigen Link von Dir mit dem Programm für den DHT22 auf den Attiny geflashed. Leider tut sich dieses Mal gar nichts. Spannung liegt an, habe auch eine LED am sende Pin angesteckt um zu sehen ob etwas gesendet wird. Aber es tut sich nichts. Der attiny funktioniert (stink normales Blink-Programm läuft).
Vielleicht hast du ja eine Idee nach was ich schauen kann
Besten Dank
Hallo Bender78,
prüfe nochmal, ob die ID in der LaCrosse.cpp mit der der Sketches übereinstimmt.
Dann auch noch mal auf die verbesserten LaCrosse-Timings prüfen.
Zum testen lässt sich über "SoftSerial" ein Pin als Debugport (http://www.ernstc.dk/arduino/tinycom.html) definieren.
Der erfordeliche RX-Pin einfach auf einen nicht im ATtiny84 vorhanden pin legen.
Dann kannst Du einfach nachprüfen, ob der Chip läuft oder nicht.
Ist der DHT mit 4K7 Pullup versehen?
Am richtigen im Sketch geforderten Pin angeschlossen?
Meiner funktioniert, sogar auch mit akzeptabler Luftfeuchte und ebenfalls sehr zuverlässig.
Zitat von: juergs am 02 Februar 2019, 11:31:19
Hallo Bender78,
prüfe nochmal, ob die ID in der LaCrosse.cpp mit der der Sketches übereinstimmt.
Dann auch noch mal auf die verbesserten LaCrosse-Timings prüfen.
Zum testen lässt sich über "SoftSerial" ein Pin als Debugport (http://www.ernstc.dk/arduino/tinycom.html) definieren.
Der erfordeliche RX-Pin einfach auf einen nicht im ATtiny84 vorhanden pin legen.
Dann kannst Du einfach nachprüfen, ob der Chip läuft oder nicht.
Ist der DHT mit 4K7 Pullup versehen?
Am richtigen im Sketch geforderten Pin angeschlossen?
Meiner funktioniert, sogar auch mit akzeptabler Luftfeuchte und ebenfalls sehr zuverlässig.
Hallo Jürgen,
danke für deine Antwort.
Für das Debugging über SoftSerial bin ich glaub ich zu blöd. Im Programm ist dies so wie ich das gesehen habe auch nicht programmiert. Dafür ist mein Programmier-Kung-Fu einfach zu schwach *g*
Den Pullup habe ich an dem DHT
Was ich jedoch jetzt bemerkt habe ist, folgendes
Am Pin2 (PB3) flackert die LED immer wie ich es gewohnt bin (Telegramm1/Pause/Telegramm2) wenn der Arduino "sendet" beim Anschließen der Versorgungsspannung. Allerdings nur mit einer geringen Helligkeit (1,4V gemessen). Und egal auf welchem Ausgang ich das Senden lege flackert immer dieser Ausgang. Habe es auch mit einem anderen Attiny85 versucht. Aber ging ebenfalls nicht.
Jetzt bin ich Ratlos :-[
Ich finde so langsam, dass nur Temperaturen ohne Feuchtigkeit auch eine tolle Variante ist ;D
Edit:
Es scheint zu gehen *freu* aber ich kann ehrlich gesagt nicht sagen an was es jetzt gelegen hat. Ich habe den sketch noch einmal hunter geladen. Alles in die Arduino IDE via Zip Importieren eingelesen noch einmal drauf geflasht und siehe da.. die LED "pollt"wie sie es soll und in FHEM erscheint mein neuer Sensor.
Vielen Dank für das tolle Projekt!
It's a kind of magic ... 8) ::) :D :)
Viel Spaß.
PS: auch mal den output der Arduino IDE anschauen.
Leider flutschen Fehler eher unbemerkt durch.
Evtl. nützt es auch, den Compiler- und Upload-Output etwas zu erhöhen...
Hallo Juergs,
Ich hab dein Code erfolgreich compiliert und auch übertragen aber trotzdem zeigt FHEM nichts an.
Nutze den NanoCul mit der acuw.
Wenn ich an den PIN zum Senden eine LED anklemme dann blinkt sie ab und zu.... sollte also eigentlich passen....hast du eine Idee?
Danke im Voraus.
Hast Du die geänderten (https://forum.fhem.de/index.php/topic,52755.msg747406.html#msg747406) Timing-Zeiten berücksichtigt?
Mit welchem CUL empfängst Du?
Ist was in den Logs zu sehen?
Zeig mal ein "list" von Deinem CUL.
Ist das fhem-Setting "autocreate" gesetzt?
Zitatdefine autocreate autocreate
Ist die gleiche ID auch in der LaCrosse.cpp gesetzt?
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:Ist das
CUL_TX-Protokoll mit in der CUL-FW kompiliert?
Das Blinken sollte zum Sende-Intervall passen.
Sind die AVR-Fuses richtig gesetzt? Chip-Timing?
Super für deine schnelle Antwort.
Hatte gerade noch den selbstgebauten nanocul auf freq 868 gestellt und schwups ist der Sensor drin....klasse.
Ein Fehler habe ich aber noch, es werden bei mir nur T:88,8 und H:88,8 angezeigt und der Plot macht gar nichts. Hast du dazu eine Idee?
Was benuzt Du als Sensor?
DS18B20 oder DHT22?
Im Code sind solche "Magic Numbers" für die Fehler-Übermittlung vorgesehen.
Wenn Du im Code nachschaust müsstest Du die Ursache herausfinden ...
Welchen Code nutzt Du?
switch (errorCode)
{
case DHT_ERROR_NONE:
//---Get Data
dht_temp = myDHT22.getTemperatureC();
dht_hum = myDHT22.getHumidity();
break;
case DHT_ERROR_CHECKSUM:
//--- send erraneous data as err indicator
dht_temp = -99.99;
dht_hum = -99.99;
break;
case DHT_BUS_HUNG:
dht_temp = -88.88;
dht_hum = -88.88;
break;
case DHT_ERROR_NOT_PRESENT:
dht_temp = -77.77;
dht_hum = -77.77;
break;
case DHT_ERROR_ACK_TOO_LONG:
dht_temp = -66.66;
dht_hum = -66.66;
break;
case DHT_ERROR_SYNC_TIMEOUT:
dht_temp = -55.55;
dht_hum = -55.55;
break;
case DHT_ERROR_DATA_TIMEOUT:
dht_temp = -44.44;
dht_hum = -44.44;
break;
case DHT_ERROR_TOOQUICK:
dht_temp = -33.33;
dht_hum = -33.33;
break;
default:
dht_temp = -22.22;
dht_hum = -22.22;
}
Nutze den DHT22
Was kann ich jetzt mit BUS HUNG anfangen?
By the was: der Code ist gut :)
DHT-Prinzipschaltung?
Wie sieht es mit dem Pullup an der Datenleitung aus? 4,7 KiloOhm, gemesssen?
https://github.com/nethoncho/Arduino-DHT22/issues/8
DHT22 Sensor - Auslesen mit 3.3v uC klappt nicht (https://www.mikrocontroller.net/topic/334672)
Ja 4,7kohm
Pin1: vcc
Pin2: Data + 4,7k auf VCC
Pin 4: GND
Hatte das DATA statt auf Pin2 auf 3....nachdem ich jetzt umgesteckt habe zeigt er mir T= -48 und H= 88,8
Kontrolliere die Verkabelung einfach noch mal genauer.
Am Besten eine Nacht drüber schlafen, dann sieht man den Fehler meist sofort ::) ;) :)
Der richtige Port-Pin definiert/benutzt?
Ja Verkabelung passt ja soweit, PIN 2 hab ich gelassen.
Merkwürdig, dass er jetzt -50grad und H=88,8 angibt...
Deshalb: Antwort #345 ;D
Mach ich.
Kann das vielleicht auch an den FuseBits liegen bzw. An den Takt? Da bin ich mir nicht sicher
Hallo R2D2,
überlege Dir einfach wie Du den Sachverhalt prüfen kannst...
So als Hilfestellung:
... ich würde einfach den simplesten Arduino Sample Sketch nehmen, der ein PortPin eine Sekunde lang toggled.
Wenn wirklich eine Sekunde (LED!) rauskommt, sind die Fuses richtig. ;-)
Falls Du tiefer in die Elektronik eintauchen möchtest und noch ein Arduino übrig hast:
https://hackaday.com/2011/05/21/xoscillo-turns-arduino-in-an-oscilloscope/ (https://hackaday.com/2011/05/21/xoscillo-turns-arduino-in-an-oscilloscope/)
bzw. hier (https://code.google.com/archive/p/xoscillo/downloads) mit wiki (https://code.google.com/archive/p/xoscillo/wikis/arduino.wiki) oder auf github (https://github.com/valkuc/xoscillo)
Also FUSE sind i.O.
Aber der Rest funktioniert immer noch nicht 🙈vielleicht ist auch der DHT22 defekt? Hatte ihn eigentlich neu gekauft.
Was noch merkwürdig ist, das ich in FHEM nicht immer Signale bekomme. Sprich mal
Sind es 4minuten, mal erkennt er ihn gar nicht. Dann hab ich gestern alles Geräte in FHEM gelöscht und seit dem empfange ich gar nichts mehr :/
Hallo R2Dzwo,
leider kann ich nicht hellsehen.
Du lieferst mir leider nur Aussagen wie zB. "geht nicht".
Damit kann ich Dir nicht helfen ... :-\ :'( :(
Ausserdem kann ich Deine Anordnung nicht überprüfen.
Da du offensichtlich mehrere Fehler produziert hast, must Du die Funktionalität Komponente für Komponente durchprüfen ...
Also nochmal:
Nimm einfach einen DemoSketch, der z.B. die DHT22 Werte über die serielle Schnittstelle ausgibt.
Damit kannst Du die Funktion des DHT prüfen....
Falls dieser korrekte Werte liefern sollte, nehmen wir den nächsten Schritt... ;) :)
Ja Sensor ist okay.
Ich finde einfach nicht den Fehler. Vielleicht liegt es auch am nanoCUL... mir gehen echt die Ideen aus...
Zitat von: R2Dzwo am 22 Juni 2019, 20:46:20
Ja Sensor ist okay.
Ich finde einfach nicht den Fehler. Vielleicht liegt es auch am nanoCUL... mir gehen echt die Ideen aus...
Ok, dann pack einfach Dein Arduino-Projekt in ein Zip-File und hänge es hier an .... ;)
ggf. ein, zwei Bilder Deines Aufbaus ...
Hallo
habe da mal ne kurze Zwichenfrage, würde das ganze auch relativ einfach mit 868 MHZ funktionieren?
Wenn ja wie?
Da meine 433 MHZ Variante Dank des perfekten Support in diesem Forum perfekt funktioniert würde mich auch eine 868 MHZ Variante interreseieren.
Vielen Dank schonmal im vorraus
hbulf
Hallo hbulf,
der Vorteil des Sensors dieses Threads ist es mit relativ günstigen Komponenten
auszukommen und auf dem 433Mhz "LaCrosse"-Protokol aufzusetzen, welches einfach als CUL_TX-Device in FHEM über den ASK-Modus empfangen werden kann.
Die gängisten Sensor-Typen sind da schon automatisch in FHEM mit erfasst, ohne ein extra Modul dafür erstellen zu müssen ...
Für die 868MHz benötigt man natürlich auch mindestens einen 868MHz-CUL aber auch einen 868MHz Sender wie z.B. den CC1101.
Nachteil: statt einem (Sende)-Port benötigt man mehr Steuerleitungen für die Anbindung. Damit fallen soche Controller mit wenig Pins natürlich
von vorneherein heraus. Das müsste man mit einigen Maßnahmen kompensieren, die widerum kaum einen "Stromsparmodus" erlauben würden...
Es gibt ja hier im Forum ja auch schon den "Dirk's Universalsensor (https://wiki.fhem.de/wiki/Universalsensor)" der mit einem 328er (Firmware (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1), Beispiel_AskSinPP (https://github.com/jp112sdl/Beispiel_AskSinPP)) und auf 868MHz mit dem ASKSin-Protokoll Daten funken kann.
Der wäre für Deine Anforderung eher geeignet, als diese Variante hier, die eher auf "Einfachheit" im Nachbau und niedrige Kosten ausgelegt ist.
Die 433er Sensoren funktionieren bei mir allerdings sehr zuverlässig, innerhalb eines bestimmten Wirkungskreises ...
Hier sehe ich für die 868er kaum Vorteile.
Grüße,
Jürgen
Hallo Jürgen,
vielen Dank für die schnelle Antwort.
Hintergrund der frage war weil ich noch eine Lacrosse Wettwerstation habe wo sich so langsam der Sender verabschiedet (extremer Reichweitenverlust).
Da dachte ich läge es nahe ob man das ganze von 433 MHZ relativ easy auf 868 MHZ portieren kann zumal ich noch so ein cc1101 Modul da habe.
Hatte aber schon damit gerechnet das es nicht ganz so einfach werden würde da ja der cc1101 komplett anders in der Anschlussbelegung ist als die 433 MHZ Module.
Trotzdem vielen Dank für die schnellen Ratschläge.
Grüße Ulf
Hallo Ulf,
Das Protokoll nennt sich zwar ,,LaCrosse" aber die 433er und die 868er haben ein vollkommen anderes Protokoll. Die 868er können eigentlich auch physikalisch nur mit einem Rfm69 Baustein (jeelink) empfangen werden.
Es gibt auch eine Umsetzung mit dem CC1101 (Stichwort: Nr 1) mit dem CUL.
Lesestoff: https://forum.fhem.de/index.php/topic,36565.0.html (https://forum.fhem.de/index.php/topic,36565.0.html)
Hallo Jürgen,
ich bin immer wieder begeistert wie schnell man hier geholfen bekommt.
Hoffentlich hatte ich mich verständlich genug ausgedrückt ich wollte den Sender mit 868 MHZ nachbauen da ich noch so eine alte Wetterstation habe, ist auch kein +IT Sender.
War nur ein Gedanke um die alte WS weiternutzen zu können der Sender sollte nicht mit in FHEM eingebunden werden.
viele Grüße Ulf
Hallo Ulf,
dann viel Spaß beim Reengineering (https://www.kompf.de/tech/rftemp.html) des Protokolls (Tool (https://github.com/jopohl/urh)) ;)
Jürgen
Hallo Jürgen,
vielen Dank für deine Mühe :-) werde auf alle Fälle weiter berichten.
Gruß und Dank
Ulf
Hallo Jürgen,
jetzt hast du meinen Ehrgeiz angestachelt und ich muss dich nochmal fragen.
Auf der verlingten Seite ist ein anderes Funkmodul angegeben würde das auch mit dem CC1101 funktionieren und wenn ja wie währe da die Anschlussbelegung zum Arduino?
Vielen Dank schonmal im vorraus
Ulf
Hallo Ulf,
es ist das hier: HF-Sendemodul TX868-75, 868 MHz (https://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=12789)
Es ist das Modul TX868 (https://www.kompf.de/tech/images/rftemp_schem.png)
Ob es aber "kompatibel" mit Deiner Wetterstation (Typ=?) ist kann ich leider nicht beantworten ...
Hallo Jürgen,
vielen Dank ich werde testen und berichten.
Grüße
Ulf
update Post 1
Hallo matlen67,
ich habe mich mit ATtiny85 und 433 MHz-Sender FS1000A eingedeckt (noch im Zulauf) und auch Beispiel-Sketche gefunden, bin allerdings ansonsten noch ahnungslos, wenn es um die Umsetzung geht.
Den Sketch (wie auch immer er werden wird) habe ich vor mithilfe eines Arduino Uno R3 auf den ATtiny85 drauf zu bekommen, in etwa so, wie hier (https://wolles-elektronikkiste.de/attiny85-84-45-44-25-24-programmieren) beschrieben - ich hoffe, dass ich das hinbekomme.
Den Sketch im Beitrag #1, kann ich diesen auch für einen ATtiny85 benutzen?
Gibt es ansonsten lesbare Anleitungen, an die ich mich evtl. halten kann?
Viele Grüße Gisbert
*/edit: Rechtschreibfehler korrigiert
ich antworte mal. ;)
ZitatDen Sketch im Beitrag #1, kann ich diesen auch für einen ATtiny85 benutzen?
Im Grundsatz ist das völlig egal. Du musst nur auf die Pins der unterschiedlichen attiny-Typen achten. Hier (https://wolles-elektronikkiste.de/attiny85-84-45-44-25-24-programmieren) ist der Unterschied recht verständlich beschrieben
ZitatGibt es ansonsten lesbare Anleitungen, an die ich mich evtl. halten kann?
Folge mal meinem Post (https://forum.fhem.de/index.php/topic,52755.msg501310.html#msg501310) Ich war damals in derselben Situation. Von nix ne Ahnung, aber davon viel. ;D Und wenn Du dort folgst, findest Du ne Menge Attachements incl. der stromsparenden Varianten mit narcoleptics.
Hallo Gisbert,
hätte dich gern unterstütz, aber wenn ich Attinys oder PIC´s programmiert habe nutze ich immer die Proton IDE und einen externen "Brenner".
Ich hab das nie über die Arduino IDE gemacht. War mir zu umständlich und das andere kannte/konnte ich schon.
LG
Papa Romeo
Hi Gisbert,
ich hatte auch mal attinys als Temperatursensoren mit Knopfzelle versucht.
Mir war das leider zu instabil :-(
Für die Sensoren habe ich mir damals auch ein Sendeprotokoll entworfen, welches ich in FHEM integriert habe:
https://github.com/RFD-FHEM/ArduinoSensor
Vielleicht ist das für dich ja irgendwie nützlich.
Grüße Sidey
Hallo zusammen,
wie schon erwähnt kommen die Bauteile die nächsten Wochen rein.
Ich hoffe oder befürchte (je nach Sichtweise), dass der Thread ein revival erleben wird.
Da hab ich mir aber auch schon wieder ein dickes Brett rausgesucht, stellt euch auf Bitten für Unterstützung ein ;).
@Markus, Strom sparen ist eines der Kernmerkmale, die ich verfolge, deshalb ist das Stichwort "narcoleptics" notiert.
Die Seite https://wolles-elektronikkiste.de/attiny85-84-45-44-25-24-programmieren (https://wolles-elektronikkiste.de/attiny85-84-45-44-25-24-programmieren) hatte ich schon ausgegraben und demzufolge habe ich mir das Flashen des ATtiny85 mithilfe eines Arduino Uno zugetraut. Aber damit ist es ja anscheinend bei weitem nicht getan.
Mein use case sieht im Moment wie folgt aus:
- Dallas DS18B20
- DHT22
- Kontrolle der Batteriespannung
- ausgelegt auf sparsamsten Verbrauch, so dass eine AA-Zelle deutlich länger als ein Jahr hält
- nicht alles zusammen, sondern schön getrennt
- eventuell - und nur, wenn ich dadurch nicht in den Wahnsinn getrieben werde - eine Tasterfunktion (z.B. für den Briefkasten oder andere Dinge, die sich auf und zu machen lassen) - und eventuell ein BME680, und das mit dem Wahnsinn gilt auch für den BME680.
Viele Grüße Gisbert
Hallo Markus, Jürgen und Sidey,
ich war erfolgreich mit der Inbetreibnahme meines ersten ATtiny85 - ein kleiner Schritt für mich, ein großer Schritt für die Menschheit (Notiz an mich: nicht übertreiben, wir starten hier keine Rakete 8)). Ich bin dennoch sehr begeistert, dass es mir auf Anhieb gelang anhand dieser Vorgabe https://wolles-elektronikkiste.de/attiny85-84-45-44-25-24-programmieren (https://wolles-elektronikkiste.de/attiny85-84-45-44-25-24-programmieren) einen Arduino UNO dazuzubringen einen einfachen Blink-Sketch auf den ATtiny85 zu flashen. (Nur am Rande: warum wird in der obigen Anleitung ein Kondensator auf RESET am Arduino UNO geschaltet?) Auch das Brennen des Bootloaders lief in der Arduino-Software glatt durch. Ich hab die Clock "Internal 8 MHz" ausgewählt und die Blinkfolge scheint mit der Erwartung aus dem Sketch übereinzustimmen. Da die Taktfrequenz des ATtiny85 häufig angesprochen wurde, möchte ich fragen, ob ich hier noch etwas zu beachten habe.
Der erste Schritt ist demnach getan, d.h. ich kann Sketche auf den ATtiny85 laden. Ich hab den gesamten Thread durchgelesen, nicht Wort für Wort, aber deutlich intensiver als nur überflogen. Eindeutig klar ist mir noch nicht, wie es komkret weitergehen kann.
Mein Anliegen sieht im Moment wie folgt aus:
- Dallas DS18B20 oder DHT22 - nicht gleichzeitig, nur einer auf einmal
- Kontrolle der Batteriespannung
- ausgelegt auf sparsamsten Verbrauch
Mit welchem Sketch aus diesem Thread sollte ich starten?
Wie geht es auf der Fhem-Seite weiter?
Ich hab einen SIGNALduino (dank Papaloewe) und SignalESP (dank RaspiLED, dem ich noch eine Pizza schulde) am Start, allerdings weiß ich nicht, wie aktuell der Stand der Firmware ist, und was ich da noch alles einstellen muss, deshalb ein list an dieser Stelle:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 11
FUUID 5c92818b-f33f-e986-6d47-fb7aae3a694cebbe
LASTDMSG nothing
LASTDMSGID nothing
NAME mySIGNALduino
NR 34
PARTIAL
STATE opened
TIME 1642240205
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.1-RC-nightly SIGNALduino - compiled at Feb 3 2019 21:35:11
versionProtocols 1.21
versionmodul v3.4.4
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2020-06-28 10:04:13 cc1101_config Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
2020-06-28 10:04:13 cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
2020-06-28 10:04:13 cc1101_patable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2019-03-20 21:19:01 config MS=1;MU=1;MC=1
2019-03-20 21:50:09 freeram 769
2022-01-18 15:56:35 ping OK
2022-01-15 10:50:39 state opened
2019-06-27 17:53:40 uptime 1 03:21:35
2020-01-05 18:11:49 version V 3.3.1-RC-nightly SIGNALduino cc1101 (chip CC1101) - compiled at Feb 3 2019 21:35:11
additionalSets:
helper:
bm:
CODE(0x564bc170a4b8):
cnt 2322
dmx -1000
dtot 0
dtotcnt 0
mTS 16.01. 15:00:06
max 0.00449204444885254
tot 1.47822761535645
mAr:
HASH(0x564bc16d86a0)
mySIGNALduino
?
CODE(0x564bc1710e58):
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 18.01. 15:50:21
max 0.00546908378601074
tot 0.00595283508300781
mAr:
HASH(0x564bc16d86a0)
mySIGNALduino
?
CODE(0x564bc1b8df80):
cnt 3487
dmx -1000
dtot 0
dtotcnt 0
mTS 18.01. 07:01:21
max 0.0930979251861572
tot 86.3730680942535
mAr:
HASH(0x564bc16d86a0)
keepalive:
ok 0
retry 0
mcIdList:
msIdList:
13
13.2
muIdList:
13.1
Attributes:
WS09_CRCAUS 2
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
group SIGNALduino
hardware nanoCC1101
icon cul
updateChannelFW stable
verbose 1
whitelist_IDs 13,13.1,13.2
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
DEF 192.168.2.30:23
DMSG nothing
DevState initialized
DeviceName 192.168.2.30:23
FD 12
FUUID 5cb0c675-f33f-e986-cd77-96ab3dc3df6ec830
LASTDMSG nothing
LASTDMSGID nothing
NAME mySignalESPHelicalAntenna
NR 36
PARTIAL
STATE opened<br/><div style="vertical-align: middle; font-size: 100%"><a href="http://192.168.2.30" style="color: green; text-decoration: underline;" target="_blank" rel="noopener noreferrer">http://192.168.2.30</a></div>
TIME 1642240205
TYPE SIGNALduino
cc1101_available 1
sendworking 0
unknownmessages
version V 3.3.1-RC-nightly SIGNALESP cc1101 (chip CC110 unknown) - compiled at Feb 3 2019 21:37:16
versionProtocols 1.21
versionmodul v3.4.4
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2022-01-15 10:50:52 IPaddress <a href="http://192.168.2.30" style="color: green; text-decoration: underline;" target="_blank" rel="noopener noreferrer">http://192.168.2.30</a>
2022-01-15 10:50:50 cc1101_config Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
2022-01-15 10:50:50 cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
2022-01-15 10:50:52 cc1101_patable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2021-02-14 20:32:22 config MS=1;MU=1;MC=1;Mred=1
2022-01-11 20:14:31 ping OK
2022-01-15 10:50:46 state opened
2021-02-14 20:41:17 uptime 0 00:13:50
2020-01-05 18:11:53 version V 3.3.1-RC-nightly SIGNALESP cc1101 (chip CC110 unknown) - compiled at Feb 3 2019 21:37:16
additionalSets:
helper:
bm:
CODE(0x564bc170a4b8):
cnt 10
dmx -1000
dtot 0
dtotcnt 0
mTS 18.01. 15:49:17
max 0.00107002258300781
tot 0.00432610511779785
mAr:
HASH(0x564bc1e0ec78)
mySignalESPHelicalAntenna
?
CODE(0x564bc1710e58):
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 18.01. 15:51:53
max 0.00024104118347168
tot 0.000457048416137695
mAr:
HASH(0x564bc1e0ec78)
mySignalESPHelicalAntenna
?
CODE(0x564bc1b8df80):
cnt 48556
dmx -1000
dtot 0
dtotcnt 0
mTS 15.01. 22:43:14
max 0.022784948348999
tot 75.1966507434845
mAr:
HASH(0x564bc1e0ec78)
keepalive:
ok 0
retry 0
mcIdList:
msIdList:
13
13.2
muIdList:
13.1
Attributes:
WS09_CRCAUS 2
alias mySignalESPHelical
group SIGNALduino
hardware ESP8266
icon cul
stateFormat state<br/><div style="vertical-align: middle; font-size: 100%">IPaddress</div>
userReadings IPaddress {"<a href=\"http://192.168.2.30\" style=\"color: green; text-decoration: underline;\" target=\"_blank\" rel=\"noopener noreferrer\">http://192.168.2.30</a>"}
verbose 1
whitelist_IDs 13,13.1,13.2
So, genug für den Moment.
Viele Grüße
Gisbert
Hallo Gisbert,
Du kannst bei mir (https://github.com/search?q=user%3Ajuergs+ATtiny) und hier (https://forum.fhem.de/index.php/topic,59933.msg611880.html#msg611880) noch einige ATtiny-Beispiele finden.
In punkto Stromverbrauch wirst Du Deine Erfahrungen, bezüglich Laufzeit, hierzu wohl selbst machen bzw. messen müssen. ;)
Die erforderlichen Pullup-Widerstände ziehen kontinuierlich Strom aus der Batterie. Eine technische Abschaltung während des Tiefschlafs wäre evtl. nützlich.
Der DHT22 ist wohl am instabilsten in meiner Langzeitbeobachtung. Der DS18S20 ist eher unkompliziert einzusetzen (auf die BetriebsspannungMin bei Betrieb mit 3V3 achten).
Weiterhin viel Spaß mit den Funkern.
Grüße,
Jürgen
Hallo Jürgen,
hallo Markus,
ich hab diesen Sketch (https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp (https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp)) aus Github verwendet, ohne jeglich Änderung, d.h. SENSOR_ID ist 80 und SENSORID_BATTERIE ist 81.
Den Aufbau habe ich provisorisch auf einem Breadboard durchgeführt; d.h. erst den Sketch hochgeladen, von der Spannung getrennt, dann den Sender FS1000A und den DS18B20 angestöpselt, und schließlich mit 5V (vom Arduino Uno) versorgt.
Mit Lacrosse TX2/TX3 Sensoren CUL_TX 8 (whitelist_IDs) bekomme ich doch tatsächlich ein Signal in Fhem - ich hätte nicht gedacht, dass ich dies auf Anhieb schaffen könnte.
Es werden 2 Devices, 1 Plot und 2 Räume angelegt:
- CUL_TX_80 in Raum CUL_TX
- CUL_TX_80-2022.log in Raum CUL_TX
- SVG_CUL_TX_80 in Raum Plots
Alle ca. 3 Minuten und 20 Skeunden wird die Temperatur übertragen.
Prinzipiell finde ich es ja schön, dass automatisch alles angelegt wird, aber woher kommt dieses Verhalten? Die überwiegende Anzahl meiner Devices habe ich selbst angelegt, deshalb wundert es mich ein bißchen.
Ich dachte, dass auch die Spannung gemessen und übertragen wird, das scheint aber nicht der Fall zu sein, denn es kommt hierzu nichts in Fhem an.
Viele Grüße Gisbert
Hi Gisbert,
prima, dass es auf Anhieb geklappt hat. Ich hatte bei Deiner ESP-Erfahrung nichts anderes erwartet. :)
ZitatPrinzipiell finde ich es ja schön, dass automatisch alles angelegt wird, aber woher kommt dieses Verhalten?
Die Frage wundert mich etwas. Die Antwort dürfte autocreate sein.
ZitatIch dachte, dass auch die Spannung gemessen und übertragen wird
Beim Überfliegen des Sketchs ist mir nur das Messen, nicht aber ein send... aufgefallen. Guck Dir mal die loop an.
Grüße Markus
Hallo Gisbert,
wenn Du Dir den Code genauer angeschaut hättest: das Senden von "controller_VCC" ist auskommentiert!
LaCrosse.h = controller_VCC;
LaCrosse.sendHumidity();
LaCrosse.sleep(1);
Sollte das "Problem" beheben... ;-)
//LaCrosse.h = bodenfeuchte/1000; // controller_VCC;
//LaCrosse.sendHumidity();
//LaCrosse.sleep(1); /* 1 second, no power-reduction! */Das hatte damals natürlich auch seinen Grund, da ich am Herumexperimentieren mit der Batterielaufzeit war.
Aber mal ehrlich, sollte man sich nicht dessen bewusst sein, was man so "programmiert" ?
Copy & Paste von vorgefertigten Sachen ist immer einfacher, als sich einem Problem stellen, oder ?
Außerdem macht es wesentlich mehr Spaß das Problem selbst zu lösen ... ;D
Asche auf mein Haupt. :(
Weiterhin viel Spaß mit den CUL_TX-Sensoren,
Grüße,
Jürgen
PS:
Zitatautomatisch alles angelegt wird, aber woher kommt dieses Verhalten?
Welches "Verhalten" meinst Du?
ZitatIch dachte, dass auch die Spannung gemessen und übertragen wird, das scheint aber nicht der Fall zu sein, denn es kommt hierzu nichts in Fhem an
Hast Du gesehen, dass im Code auch eine Serielle Ausgabe in Form einer Leitung (=Pin des ATtinys, Schalter: "USE_SOFT_SERIAL_FOR_DEBUG") integriert ist? Nutze die Möglichkeiten zur Analyse!
ZitatBeim Überfliegen des Sketchs ist mir nur das Messen, nicht aber ein send... aufgefallen. Guck Dir mal die loop an.
Hallo Markus,
hast Recht, ist mir natürlich aufgefallen - ich dachte, dass sich jemand erbarmt und einen Vorschlag macht. Getreu dem Motto, man kann sich ja mal dumm stellen - umgekehrt ist schwieriger ;D.
Dann muss ich wohl oder übel selbst nachdenken und auf die Suche gehen.
Viele Grüße Gisbert
;D ;D ;D
Du weißt doch(und ich zitiere einfach Jürgen):
ZitatAber mal ehrlich, sollte man sich nicht dessen bewusst sein, was man so "programmiert" ?
Die Wertermittlung ist ja bereits drin. Nun must Du Dir nur das send von T u. das Lacrosse-Protokoll ansehen. Eine neue Id vergeben und die send-function kopieren/anpassen u. schon hast Du die Spannung in FHEM.
wobei Jürgen geschrieben hatte
LaCrosse.h = controller_VCC;
LaCrosse.sendHumidity();
LaCrosse.sleep(1);
Grüße Markus
Hallo Jürgen,
meine Antwort an Markus muss dir sicher merkwürdig vorgekommen sein. Ich hatte schlicht auf dem Handy deine Antwort übersehen.
Ich werde mich näher mit deinem Sketch beschäftigen und versuchen ihn nach meinen Bedürnissen anzupassen.
Fhem legt anscheinend per autocreate ein Device an, sowie einen Logfile und einen Plot in 2 neuen Räumen. Das ist ja nicht weiter schlimm, ich kann es ja nach meinem Bedarf ändern.
Viele Grüße Gisbert
Hallo Jürgen,
vielen Dank nochmals für den Hinweis auf deinen Code in Github.
Im Code auf der Seite https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp (https://github.com/juergs/ATtiny85_433MHz_LaCrosse_Temp) steht zu Beginn:
OneWire ds(DALLAS_SENSOR_PIN);
OneWire dallas(DALLAS_SENSOR_PIN);
float ReadSingleOneWireSensor(OneWire ds);
Im Loop wird jedoch nur dies benutzt:
float theta = ReadSingleOneWireSensor(dallas);
Wozu wird zu Beginn des Sketches:
OneWire ds(DALLAS_SENSOR_PIN);
float ReadSingleOneWireSensor(OneWire ds);
benutzt - oder kann das weg?
Viele Grüße Gisbert
Edit:
Im Loop steht auch:
float ReadSingleOneWireSensor(OneWire ds)
Bleibt die Frage, warum die ds und dallas definiert wird.
Hallo Gisbert,
ja da ist wohl eine Instanziierung zu viel.
Vermutlich optimiert der Compiler das weg, wenn nicht verwendet.
Für solche Verbesserungen sind die Issues in Github gedacht.
Das wäre dann für alle ein Hinweis und hilfreich :)
Grüße
Jürgen
Hallo Jürgen,
vielen Dank für deine Antwort auf Github. Mit dem Sketch werde ich später mal weitermachen.
Hallo Papa Romeo,
was mich im Moment umtreibt, ist die mobile Spannungsversorgung. 2x oder 3x AA wären ideal, aber mein Ziel ist es einige von den 9V-Blocks einzusetzen, die ich mal bei Rauchmeldern mit geliefert bekommen habe. Da diese aber vglw. schwach sind, hatte ich Li-Batterien von Varta dort eingesetzt. Jetzt habe ich etliche von den anderen übrig.
Wie bekomme ich aus 9V-Blocks 3.3 oder 5V zustande (3.3V reicht für den ATtiny85, den FS1000A und Dallas DS18B20 aus), ohne dadurch zuviel vom kostbaren Saft zu verlieren? Bei Aliexpress gibt es dazu kleine Module, aber wie effizient die wirklich sind, kann ich nicht beurteilen.
Hast du einen Vorschlag für mich? Es darf auch eine kleine Schaltung aus Einzelteilen sein, falls dadurch eine effiziente Lösung entsteht.
Viele Grüße Gisbert
Noch ein Tip zum ATtiny85:
https://sites.google.com/site/wayneholder/debugwire3 (https://sites.google.com/site/wayneholder/debugwire3)
https://www.codeproject.com/Articles/5321801/Debugging-an-Arduino-project-with-GDB-on-Classic-A (https://www.codeproject.com/Articles/5321801/Debugging-an-Arduino-project-with-GDB-on-Classic-A)
Stepdown-Wandler: Umwandlungseffizienz max. 96%
https://www.reichelt.de/de/de/entwicklerboards-spannungsregler-dc-dc-wandler-debo-dcdc-down-4-p291460.html?PROVID=2788&gclid=Cj0KCQiAosmPBhCPARIsAHOen-OQeyYormImK1x9g3YfRJS69mswSZPg7ZFa9cEe5LEVQiyZ3QgNCQIaAqdPEALw_wcB&&r=1 (https://www.reichelt.de/de/de/entwicklerboards-spannungsregler-dc-dc-wandler-debo-dcdc-down-4-p291460.html?PROVID=2788&gclid=Cj0KCQiAosmPBhCPARIsAHOen-OQeyYormImK1x9g3YfRJS69mswSZPg7ZFa9cEe5LEVQiyZ3QgNCQIaAqdPEALw_wcB&&r=1)
Hallo Jürgen,
ich hab den Stepdown-Wandler aus China bekommen. Äußerlich sehen die Teile völlig identisch zu den Teilen von Reichelt aus und funktionieren bzgl. Spannung sehr gut, d.h. die eingestellte Spannung wird bis zur 3. Nachkommastelle konstant bereit gestellt.
Leider gibt es ein Problem in Zusammenhang mit den vorhandenen 9V-Blöcken (zugegeben nicht die stärksten) und dem Stepdown-Wandler, denn nach 2 Tagen ist ein Block von 9 auf 4 V abgefallen. Bei dieser niedrigen Spannung findet die Regelung auf 3.30V nicht mehr statt.
Ich werde dann mein Glück mit 3x1.5V-Batterien versuchen.
Viele Grüße Gisbert
Zitat von: Gisbert am 13 Februar 2022, 09:41:16
Leider gibt es ein Problem in Zusammenhang mit den vorhandenen 9V-Blöcken (zugegeben nicht die stärksten) und dem Stepdown-Wandler, denn nach 2 Tagen ist ein Block von 9 auf 4 V abgefallen. Bei dieser niedrigen Spannung findet die Regelung auf 3.30V nicht mehr statt.
Hallo Gisbert,
was nutzt du für 9 V Blöcke.
LG
Papa Romeo
Ich habe mal überschlägig die die Akkukapazität laut einem Onlinerechner (https://www.online-batterien.de/shop/Kapazitaetsrechner) bemüht
Prämisse: 0.1 Watt mal 6000h (ja, W ist ca 10..100fach zu hoch ;) ):
Zitat0.1 Watt / 3V3 Volt = 0.03 Ampere
0.03 Ampere * 6000 Stunden = 180 Ah Kapazität
180 Ah * 1.7 Puffer = 306 Ah empfohlene Kapazität (bei 3V3 Volt)
ZitatAA-Primär-Mignonzellen haben meist eine Nennspannung von 1,5 V und eine typische Kapazität von 1200 bis 2300 mAh,
wiederaufladbare Mignon AA Akkus hingegen eine Nennspannung von 1,2 V und eine Kapazität von 1000 bis 2500 mAh.
Also 2,5 Ah im Gegensatz zu den benötigten 306Ah/100.
Um eine lange Batterielebensdauert zu erreichen muss man wirklich an allen "Stellschrauben" drehen.
Stepdown wäre da schon mal am wenigsten dafür geeignet. :-\
Hast Du mal den Stromverbrauch Deiner Schaltung gemessen und gemittelt?
https://forum.fhem.de/index.php/topic,104466.0.html (https://forum.fhem.de/index.php/topic,104466.0.html)
https://github.com/pemue-git/uAmp_meter (https://github.com/pemue-git/uAmp_meter)
Jürgen
PS: Meine Sensoren werden mit einem 18650 betrieben und halten dann ca. 1/2 Jahr.
Verbesserungspotential ist wohl aber auch nicht zu 100% ausgeschöpft.
Und der verwendete Sensor trägt naturgemäß auch zum Stromverbrauch bei!
Siehe auch mal hier:
Einige Code-Korrekturen und Stomverbrauch im Deep_Sleep-Modus wieder unter 10 MikroAmpere (WDTCSR-Register):
https://forum.fhem.de/index.php/topic,59933.msg611880.html#msg611880 (https://forum.fhem.de/index.php/topic,59933.msg611880.html#msg611880)
Zitat von: juergs am 13 Februar 2022, 12:16:13
Stepdown wäre da schon mal am wenigsten dafür geeignet. :-\
... deswegen eigentlich meine Frage.
LG
Papa Romeo
Hallo Jürgen und Papa Romeo,
ich hatte nur den Stepdown-Wandler am 9V-Block dran, nicht den ATtiny85.
Der 9V-Block ist zugegebenermaßen Schrott (Zhongyin (Ningbo) Battery Co., Ltd., PAIRDEER Super Heavy Duty). Er kam mit Flamingo Rauchmeldern mit. Ich hab dann bei den Rauchmeldern Varta Li-Batterien eingesetzt, so dass ich noch etliche unbenutzte, in Folie eingepackte Batterien übrig hatte.
Viele Grüße Gisbert
Hallo, bin ich mit Frage zur aktuellen Software hier auch richtig?
Zuerst hierzu:
void calc_checksum(){
// n0 n1 n2 n3 n4 n5 n6 n7 n8
// 1 5 4 14 8 0 0 4 8
// 154E800480 = 0001 0101 0100 1110 1000 0000 0000 0100 1000
// reverse all = 1000 1010 0010 0111 0001 0000 0000 0010 0001
Was hat es denn mit der 154E800480 auf sich, oder ist das nur ein Beispiel?
Was ist denn das für ein reverse? Sollte "1" nicht eigentlich "E" werden, wenn "5" => "A"?
Eigentlicher Grund für mich den Code zu studieren war die Beschreibung des W044 Protokolls hier https://github.com/merbanan/rtl_433/blob/master/src/devices/alecto.c (https://github.com/merbanan/rtl_433/blob/master/src/devices/alecto.c), bei dem ich nicht klar kam wie er gebildet wird. Laut Code hier ist es aber einfach (0xf - n0 - n1 - n2 - n3 - n4 - n5 - n6 - n7) & 0xF.
Zum Thema Energiesparen gibt es übrigens auch tatsächlich eine Norm: ISO/IEC DIS 14543-3-10 (Wireless Short-Packet protocol optimized for energy harvesting). Ich kenne deren Inhalt zwar nicht, bin aber im Rahmen meiner Suche zum Thema Prüfsummen darauf gestoßen, weil im EnOcean protokoll verwendet.
Bei reverse wird die Reihenfolge der Bits umgedreht
z.B.
aus
3210
1000
wird
0123
0001
Das W044/W155 Protokoll ist bereits im 14_CUL_TCM97001.pm eingebaut
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/14_CUL_TCM97001.pm#L982
Hallo Jürgen, Markus und Papa Romeo,
ich hatte Anfang diesen Jahres (2022) einen ATtiny85 mit einem Dallas DS18B20 erfolgreich zum Laufen gebracht. Auch der Datenempfang in Fhem funktioniert super.
Ich möchte dieses System um eine batteriebetriebene Empfängerseite mit einem 2. ATtiny85 erweitern, bei der ich den Temperaturwert vom 1. ATtiny85 empfangen möchte und dann ein Relais schalten will. Das ganze soll eine Frostschutzschaltung ergeben, wenn kein Netzstrom vorhanden ist. Auf der Empfängerseite sitzt eine 12V-Autobatterie mit einem kleinen Wechselrichter, mit dem eine Pumpe betrieben werden soll, um bei gleichzeitigem Frost und Stromausfall das Frieren von Leitungen zu verhindern.
Gibt es für diese Anforderung für die Empfangsseite (ATtiny85 mit 433 MHz-Empfänger und Relais) bereits etwas, was ich übernehmen könnte? Der Empfang über Fhem funktioniert bei Stromausfall leider nicht.
Viele Grüße Gisbert
Hi Gisbert,
ich hab da nix "out of the box".
Guten Rutsch und besseres 2023
Markus
Hallo Gisbert,
im Moment muss ich leider auch passen...
auch nen Guten Rutsch und wie Markus sagt ... besseres 2023.
Hallo Gisbert,
es gibt doch die 433MHz-Empfänger, die Du dazu verwenden könntest:
Beispielhaft: https://bit.ly/3Ij2OFc (https://bit.ly/3Ij2OFc)
Dann kannst du das Senden einfach in RX "umdrehen" ;-) arduino-tutorial-433mhz-sender-empfaenger/# (https://draeger-it.blog/arduino-tutorial-433mhz-sender-empfaenger/#) 433mhz-funkverbindung (https://funduino.de/nr-03-433mhz-funkverbindung)
Nun das große ABER:
Es gibt ja unterschiedliche Empfangsmodul-Qualitäten, evtl. müsste man das Modell auf Zuverlässigkeit ausprobieren.
Allerdings würde ich mich eher nicht auf diesen Übertragungsweg verlassen. (ISM-Band!)
Wenn, dann muss alles perfekt abgestimmt sein, damit es sicher funktioniert. (Was die Module nicht so können, wie z.B. der CC1101).
Die Hand-Sender buttern einfach mit "maximaler" Breitbandigkeit ihr Signal in den Äther.
Bei mir ist es manchmal so, dass das aus FHEM (MapleCUL) heraus ab- und zu Mal einfach nicht geht. Trotz 1 m Abstand!
Grund: Der CC1101 liefert eher ein schmalbandiges Signal auf der definierten Frequenz.
In der Normaleinstellung des CUL ist die Sendeleistung auch stark gedrosselt. Hier muss man also wirklich Frequenz und Power optimieren, das das sicher klappt.
Ganz zu schweigen von den Temperatur + Feuchtigkeits-Einflüssen etc.
Ich würde Dir da eher eine eigene CC1101/ (https://www.14core.com/wiring-the-cc1101-1ghz-lss-low-power-spi-interface-spring-coil-transceiver-3052-2/)-Lösung empfehlen. Ich schaue mal, ob ich das was Passendes bei mir finde ...)
Hier noch ein Tipp zur Weiterverfolgung: STM8 (https://www.youtube.com/watch?v=mBwTsFBVuQo) -> sduino (https://tenbaht.github.io/sduino/) --> Arduino_Core_STM8 (https://github.com/stm32duino/Arduino_Core_STM8)
Grüße,
Jürgen
... einen guten Rutsch in 2023 für Alle!
Anbei eine etwas ältere Lib, mit der man Senden + Empfangen (Examples, alternativ: SmartRC-CC1101-Driver-Lib (https://github.com/LSatan/SmartRC-CC1101-Driver-Lib)) kann.
Allerdings mit dem CC1101. Für Attiny: in den Beispielen gibt es eine Minimal-Pin-Version: "
gdo0 and gdo2 pins are not required" .
ZitatA note on pin labels. SPI functionality for the ATtiny MCUs is provided by the USI hardware, whose input and output pins are labeled DI and DO, respectively. The labels MISO and MOSI are used only in the context of serial programming for the ATtinies. Some confusion may be caused by the fact that MOSI and DI share the same pin (PB0) and MISO and DO share the same pin (PB1), the pairing being opposite to what might be expected. In the datasheet, see the pin configurations (Fig. 1-1) and section 10.3.1.
attiny85-pinout-specs-guide/ (https://www.etechnophiles.com/attiny85-pinout-specs-guide/)
Vielleicht macht es Sinn da noch etwas fürs Stromsparen zu tun (FET An- und Abschaltung?)
Als Ausgangsbasis für eigene Experimente (Nano_CC1101 (https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/blob/master/img/Nano_CC1101.png?raw=true) + CC1101-Debug-Service-Tool (https://github.com/LSatan/CC1101-Debug-Service-Tool)) ?
ESP8266_433MHz-Receiver_sending_MQTT (https://github.com/andreaslink-de/ESP8266_433MHz-Receiver_sending_MQTT)
WebServerIR433MHz_ENC28J60 (https://github.com/fwehrle/WebServerIR433MHz_ENC28J60)
https://www.14core.com/wiring-the-cc1101-1ghz-lss-low-power-spi-interface-spring-coil-transceiver-3052-2/ (https://www.14core.com/wiring-the-cc1101-1ghz-lss-low-power-spi-interface-spring-coil-transceiver-3052-2/)
https://www.elechouse.com/elechouse/images/product/CC1101%20Wirless%20Data%20Transmittion%20Module/CC1101%20Module%20Manual.pdf (https://www.elechouse.com/elechouse/images/product/CC1101%20Wirless%20Data%20Transmittion%20Module/CC1101%20Module%20Manual.pdf)
Ich hatte mal mit diversen Sendern/Empfängern auf 433MHz an Nanos rumgespielt, über Arduino IDE. Speziell als Empfänger kann ich aus der Erinnerung nur das CC1101 empfehlen, Die restlichen waren irgendwie nie zuverlässig.
Hallo Jürgen und DerD,
vielen Dank für eure Infos und Unterstützung. Ich werde die Informationen durchackern und melde mich dann wieder, wenn ich damit durch bin oder Fragen habe.
Für den C1101, kann ich sowas bestellen: https://a.aliexpress.com/_Ex2zQWL (https://a.aliexpress.com/_Ex2zQWL)?
Ist das dann für Senden und Empfangen geeignet?
Wichtig ist, dass das Senden zuverlässig ist. Auf der Empfängerseite kann ich mit Fehlern leben, d.h. die Frostschutzfunktion ist als Standard definiert und wird durch den Sendevorgang unterbrochen, wenn sie nicht notwendig ist. Wenn ich da ab und zu eine Fehlfunktion hab, wäre das noch akzeptabel. Besser ist natürlich eine hohe Zuverlässigkeit, deshalb werde ich die Variante C1101 mit Priorität verfolgen.
Viele Grüße und einen Guten Rutsch
Gisbert
ZitatFür den C1101, kann ich sowas bestellen: https://a.aliexpress.com/_Ex2zQWL?
Zu den CC1101 (https://www.we-online.com/en/components/icref/texas-instruments/CC1101-Buck) würde ich noch mal diesen Thread durchkämpfen:
https://forum.fhem.de/index.php/topic,91740.0.html (https://forum.fhem.de/index.php/topic,91740.0.html)
Mit Empfehlungen beim Chinesen ist das so ein Sache.
Im Moment versuche ich, dort so wenig wie möglich zu bestellen ...
ZitatIst das dann für Senden und Empfangen geeignet?
Ja, falls Du einen eigenen Handshake programmieren möchtest ...
Es gibt ja auch Module die eine Seriellle Schnittstelle emulieren und mit AT-Befehlen beaufschlagt werden....
Meist sind die schlecht dokumentiert und bei der Programmierung wirst Du irre ... ;-)
Falls die Entfernung (https://www.researchgate.net/publication/340658210_Design_and_Implementation_of_Wireless_Communication_System_Based_on_CC1100/fulltext/5e991e68a6fdcca789201b23/Design-and-Implementation-of-Wireless-Communication-System-Based-on-CC1100.pdf) doch eine Rolle spielen sollte, wäre vielleicht eine Lora-Hardware die bessere Wahl (https://www.youtube.com/watch?v=vxF1N9asjts)?
Theoretisch kann der CC1101 2.4 km ;-)
Jürgen
ZitatIst das dann für Senden und Empfangen geeignet?
Ja, falls Du einen eigenen Handshake programmieren möchtest ...
Hallo Jürgen,
zum Programmieren reicht es bei mir bei weitem nicht aus. Ich bin schon froh, wenn ich Vorgaben und Turorials umsetzen kann, und ggf. kleinere Anpassungen vornehmen kann. Ich verfolge deshalb zunächst den Ansatz, mit bereits vorhandener Hardware (diese: https://www.ebay.de/itm/263822063831 (https://www.ebay.de/itm/263822063831)) etwas unzusetzen, und dann muss ich mir überlegen, wie ich die Ausfallrate ermittele.
In der Zwischenzeit habe ich diese Seite (https://funduino.de/nr-03-433mhz-funkverbindung (https://funduino.de/nr-03-433mhz-funkverbindung)) gefunden, bei dem Senden und Empfangen mit 433 MHz beschrieben werden, und auch eine Library dazu ist vorhanden. Zuversichtlich macht mich, dass die dort abgebildeten Sender/Empfänger genau die sind, die ich auch schon habe.
Die Entfernung ist nicht sonderlich groß, leider zu groß oder zu umständlich, als dass ich auf Funk verzichten könnte. Die Entfernung ist ein Treppenhaus mit Betontreppe und Betondecke und dann eine weitere Geschossdecke aus Holz, die Entfernung in Metern dürften ca. insgesamt 7~8 Meter in gerader Verbindung betragen. Auf diese Entfernung sollte Senden und Empfangen mit 433 MHz funktionieren, jedenfalls tut es dies mit anderen Geräten im Haus.
Viele Grüße Gisbert
Zitatmit bereits vorhandener Hardware (diese: https://www.ebay.de/itm/263822063831) etwas unzusetzen, und dann muss ich mir überlegen, wie ich die Ausfallrate ermittele.
Na ja, Deine Wahl ist auf einen Empfängertyp der wohl schlechteren Art gefallen ... :(
Mehr wie 5..10m bei freier Sicht ist da nicht drin ... (bei 5V oder 3V3 Versorgung des Senders)
Wenn Du in der Lage bist, den Ablauf zu durchdenken und zu formulieren
sollte es mit Hilfe der vorhandenen Beispiele eigentlich "einfach" zu programmieren sein ...
Jürgen
Hallo Jürgen,
ZitatWenn Du in der Lage bist, den Ablauf zu durchdenken und zu formulieren
sollte es mit Hilfe der vorhandenen Beispiele eigentlich "einfach" zu programmieren sein ...
Das werde ich wohl schaffen - aber bezieht es sich allgemein auf das "Projekt" Senden&Empfangen oder im Speziellen auf den C1101?
ZitatNa ja, Deine Wahl ist auf einen Empfängertyp der wohl schlechteren Art gefallen ... :(
Verstehe, die waren auch sehr günstig.
Was ist mit diesem Typ: https://a.aliexpress.com/_EuPUkAx (https://a.aliexpress.com/_EuPUkAx)? Kostet immerhin ca. das 10fache der obigen Teile.
Viele Grüße Gisbert
Obiges Modell war so eines, mit dem ich keine guten Erfahrungen habe, Das von Ali kenne ich nicht.
Deswegen CC1101, meines lief unter "NRF905", erhältlich ab 1,50€. Zum reinen testen reichen die mit Fixantene. Je Nach Einbausituation ist eine mit Konnektor, Antenne und ggfalls Kabel dazwischen aber flexibler.
Und ja, du brauchst zwei davon.
Im Zweifelsfall kann ich auch noch meines sketches von damals schauen
Hallo DerD,
vielen Dank für deine Antwort.
Ich bestelle dann mal diese: https://www.ebay.de/itm/155141668345?mkcid=16&mkevt=1&mkrid=707-127634-2357-0&ssspo=u0kh3fkyrju&sssrc=2349624&ssuid=X-v0QxFWQqu&var=455322561130&widget_ver=artemis&media=COPY (https://www.ebay.de/itm/155141668345?mkcid=16&mkevt=1&mkrid=707-127634-2357-0&ssspo=u0kh3fkyrju&sssrc=2349624&ssuid=X-v0QxFWQqu&var=455322561130&widget_ver=artemis&media=COPY)
Ich hoffe auf deine Unterstützung für einen Sketch, der Temperatursensor wird ein (oder besser mehrere) Dallas DS18B20 sein. Beim Empfänger werden 2 Relais geschaltet werden, das 2. mit einer gewissen Verzögerung zum 1. Relais.
Viele Grüße Gisbert
@ DerD: Vielen Dank für den Hinweis, den nRF905 (https://infocenter.nordicsemi.com/pdf/nRF905_PS_v1.5.pdf) mit 433 MHz hatte ich noch nicht so im Fokus. Ist aber kein CC1101, dafür Tri-Bandfähig. ;-)
ZitatFeatures:
One tri-band transceiver operating frequency is internationally accepted ISM band 433/868/915MHz GMSK modulation, anti-interference ability , especially suitable for industrial control applications using DSS + PLL frequency synthesizer technology, high frequency stability excellent sensitivity , to - 100dBm low operating voltage (2.7V), low power consumption, standby only 1uA, low-power devices to meet the requirements of the maximum transmit power of +10 dBm with multiple channels ( up to 170 or more ) , especially to meet the needs of multi-channel work special occasions up to 76.8Kbps work rate
Minimum of external components (only 10 ) , the basic need to debug. As a result of low transmitting power and high receiver sensitivity design, without a permit , the use of open ground distances of up to 1000 m ** specific use of the environment and component parameters.
@Gisbert: Mir wäre jetzt aber nicht klar, wie Du die NRF-Daten in FHEM einbringen möchtest.
Gibt es dafür schon ein passendes FHEM-Modul/-Anbindung?
Hardware/Gateway gäbe es mit der LaCrosse-Gateway nur für den NRF24 auf 2.4GHz.
Die Herausforderung, aus meiner Sicht, bestünde darin, ein Protokoll mit dem NRF905 zu erzeugen, welches auch FHEM verstehen kann..
So wäre nur eine Point-to-Point-Verbindung möglich. Soweit ich aus dem Datenblatt ersehen konnte, wird ja ein Manchaster-codiertes Signal mit 50Khz Datenrate erzeugt.
Alternativ kannst Du eine P2P-Verbindung aufbauen und mit dem CUL-TX-Protokoll und einem 433MHz-Sendemdul an FHEM weiterleiten ...
ZitatSensor(en) + NRF905 ---> [Payload] --> NRF905-Repeater mit ASK Transmitter Module STX882 (https://www.nicerf.com/products/detail/433mhz-ask-transmitter-module-stx882.html) +-> [CUL_TX] --> FHEM
Meine Sender/Empfänger (https://de.aliexpress.com/item/32735811163.html?gatewayAdapt=glo2deu)-Empfehlung, oder diese (https://de.aliexpress.com/item/32980820915.html?spm=a2g0o.detail.1000014.3.396072bdywVmGI&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.281175.0&scm_id=1007.40050.281175.0&scm-url=1007.40050.281175.0&pvid=a8d874c5-f5ce-4eaa-94fd-3a6d050d4803&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.40050.281175.0,pvid:a8d874c5-f5ce-4eaa-94fd-3a6d050d4803,tpp_buckets:668%232846%238114%231999&pdp_ext_f=%7B%22sku_id%22%3A%2266843000020%22%2C%22sceneId%22%3A%2230050%22%7D&pdp_npi=2%40dis%21EUR%211.65%210.66%21%21%21%21%21%40211b58eb16729083983463339e88a5%2166843000020%21rec)
Hallo Jürgen,
ich hab deine beiden Empfehlungen jetzt je 2mal bestellt. Bis spätestens Ende Februar sollten sie hier sein, dann geht es weiter mit einem Sketch. Ich melde mich dann wieder und hoffe, dass ich Unterstützung beim Sketch schreiben bekomme.
Viele Grüße Gisbert
Oh weia.
Musste gerade noch mal die Bestellung suchen und das Modul dazu unter der Lupe anschauen. Chinesisch variabel heißt meines tatsächlich wie dieses hier "https://de.aliexpress.com/item/32821911314.html?spm=a2g0o.productlist.main.1.492035dbfohcUX&algo_pvid=784a51f6-e161-4d52-849b-90eb58f80ba8&algo_exp_id=784a51f6-e161-4d52-849b-90eb58f80ba8-0&pdp_ext_f=%7B%22sku_id%22%3A%2264750335853%22%7D&pdp_npi=2%40dis%21EUR%212.34%212.08%21%21%21%21%21%402100bbf516729416714064031d06fd%2164750335853%21sea&curPageLogUid=oWm5r5iz9YM0 (https://de.aliexpress.com/item/32821911314.html?spm=a2g0o.productlist.main.1.492035dbfohcUX&algo_pvid=784a51f6-e161-4d52-849b-90eb58f80ba8&algo_exp_id=784a51f6-e161-4d52-849b-90eb58f80ba8-0&pdp_ext_f=%7B%22sku_id%22%3A%2264750335853%22%7D&pdp_npi=2%40dis%21EUR%212.34%212.08%21%21%21%21%21%402100bbf516729416714064031d06fd%2164750335853%21sea&curPageLogUid=oWm5r5iz9YM0), ist also ein CC1101 bei dem nur zusätzlich im Angebot NRF905 drauf steht. Ich war der Meinung, das Modul heißt einfach so. Auf dem Chip steht ganz sicher 1101, dass es einen Chip mit dem Namen NRF905 gibt, wusste ich bisher nicht.
Ich war mir auch sicher einen Sketch zum CC1101 verwendet zu haben. Soweit ich mich erinnere, kann der CC1101 aber auch Triband (wenn man das so nennen wil), eigentlich sogar 4 Bänder weil auch 315). Für uns relevant aber 433 und 868 MHz. Nur die Antenne und HF Teil ist je nach board auf ein Band abgestimmt.
Gisbert, ich bin jetzt in deiner Schuld das zum laufen zu bringen.
PS: hast du ein RTL-SDR? Das war mir damals eine Hilfe weil ich damit sehen konnte, sobald Wellen im Äther waren.
Edit: habe meine Sketches von vor einem Jahr gefunden, und habe ihn tatsächlich auf 433 und 858MHz betrieben. Natürlich nur im nahes Umkreis, senden und empfangen. Mal sehen was ich zum NRF finde.
Hallo DerD,
ZitatGisbert, ich bin jetzt in deiner Schuld das zum laufen zu bringen.
Keine Panik, ich hatte dann doch noch nicht bestellt, aber die, die Jürgen mir heute empfohlen hat (er ist jetzt in meiner Schuld ;D, nicht). Wie dem auch sei, die Kosten halten sich ja alle im sehr überschaubaren Rahmen.
Viele Grüße Gisbert
Da hatte ich ja nochmal Glück ;D
aber so unterscheiden sich die Geister, mit genau solchen mit dem runden Metallgehäuse wurde ich nicht glücklich. Einfache 1:1 Verbindung zwischen Sender-Empfänger ging mit entsprechend Abstand, habe aber auch das Problem des Superhets bemerkt, was den eigenen Oszillator und damit Sender angeht.
Aber ja, der CC1101 ist etwas anspruchsvoller was die Ansteuerung angeht weil deutlich intelligenter, er kann zB Manchester selber de-/kodieren. Er kann aber auch eine Art Rawdata Modus, bei dem man nur Daten reinpumpt bzw rausliest.
Eine Anbindung an FHEM habe ich nie gemacht. Aber ein CUL ist ja auch nichs anderes als CC1101 am Nano.
Hier ein Vorschlag für den Empfang (https://www.hackster.io/JoeTio/capture-of-wireless-lacrosse-433mhz-tx7u-weather-sensor-data-17e6db) des LaCrosse TX-Protokolls:
https://github.com/Joetgithub/TX7U/blob/master/TX7UReceiver.ino (https://github.com/Joetgithub/TX7U/blob/master/TX7UReceiver.ino)
Damit sollte sich eine Repeater-Funktionalität einfach aufbauen lassen.
Hallo Jürgen und der DerD,
ich wollte mich kurz zurückmelden mit der Information, dass die vorgeschlagenen Platinchen mittlerweile eingetroffen sind. Leider komme ich im Moment nicht dazu die für mich sehr aufwendige Programmierung und Testung umzusetzen. Das wird auch leider im Februar noch so sein.
Da die Sache für mich sehr wichtig ist (Teil einer Frostschutzschaltung für eine Monoblock-Wärmepumpe bei einem Blackout oder einer Gerätestörung), werde ich auf jeden Fall dran bleiben. Da die Wärmepumpe erst ab Mai aufgebaut wird, muss die Schaltung und die Funkstrecke erst im nächsten Winter einsatzreif sein.
Ich melde mich mit Fragen, die ich bestimmt haben werde, demnächst wieder.
Viele Grüße Gisbert