FHEMduino

[JoWiemann]

Hallo Jörg,

mit dem neuen Modul fehlen die on off Befehle.

Hast du diese Routine implementiert?
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/SetExtensions.pm

Edit 3: So, ich habe nun, wie beim 01_IT.pm on-till mit SetExtensions implementiert. Auf Basis des Codes war dann ein on-for-timer nicht mehr so schwer. Anbei also nun das aktuelle Modul.

Grüße Jörg

[JoWiemann]

Hi,
Wie lange halte denn die Batterien in den Sensoren? Gibt es da schon Erfahrungswerte?

Grüße Sidey

Hallp Sidey,

die Sensoren sind nicht hungriger als andere Sensoren. Das Problem ist eher die LogiLink Wetterstation. Da waren bei mir die mitgelieferten Batterien schon nach 2 Wochen leer. Aber die habe ich ausgeschlachtet und verwende jetzt den Empfänger für meinen FhemDuino und für den DCF77-Empfänger bin ich gerade dabei ein Modul zu schreiben.

Grüße Jörg

[digital.arts]

Hallo,

kurze Infos zum WS0002 (aus dem Pollin-Set WS0001)...
habe bis gestern mit einem FHEMduino den Sender als KW9010 eingebunden gehabt, hat ohne Probleme funktioniert. Empfang von Temperatur, Luftfeuchtigkeit, Batterie und Trend.
Habe heute den Arduino mit dem neuen Sketch geflasht und die neuen/geänderten Module in FHEM eingefügt.
Jetzt wird der Sender als WS0002 erkannt, mit Temp, Hum., Battery und einem Unknown...
Könnte das nicht das "Trend-Byte" sein ??

@Jörg: super Arbeit !!
den Empfänger hab ich auch schon ausgebaut, muss nur noch an den Arduino dran...
Kannst Du vielleicht auch ein paar Fotos vom DCF77 machen, was ich da alles wegbauen soll ?
Bin schon gespannt auf interessante Anwendungen mit Deinem dazu passenden Modul

[JoWiemann]

Hallo digital.arts,

ich habe über ein Poti als Ersatztemperaturfühler alles Mögliche beim WS0002 ausprobiert. Dieses Bit ist immer 0 geblieben. Jetzt habe ich auf unknown ein Event definiert und warte einfach ab, ob es irgendwann einmal ausgelöst wird.

Ich habe gestern auch noch den PEARL-Sensor bekommen. Der verhält sich im Bereich Temperatur / Batterie / Forced send genauso wie der WS0002. Der Kanalschalter wird als 0..2 und nicht wie beim WS0002 als 1..3 dekodiert. Bei den Hummidity-Bits beim Pearl-Sensor, der ja keine Luftfeuchte misst, passieren interessante Sachen, die nach Trend aussehen. Muss ich aber noch analysieren.

Edit: Ich habe den PEARL geöffnet und siehe da, es ist alles für eine Luftfeuchtemessung auf der Platine vorhanden, nur leider nicht bestückt. Somit vermute ich, das die Firmware Luftfeuchte beinhaltet, aber nicht auswerten kann, da ja nicht bestückt, und somit irgendwelche Bits setzt, je nachdem welche Temperatur erfasst wird. Scheint auch plausibel zu sein, da ja die relative Luftfeuchte ermittelt wird.

Der PEARL entspricht also dem LogiLink, halt ohne Luftfeuchte, bis auf das die Kanalnummerierung 0..2 und nicht 1..3 ist. (Sieht die LogiLink Wetterstation genauso)

Grüße Jörg

[SpenZerX]

Hallo,

es besteht ja die Möglichkeit den Sender mit 12 Volt (statt 5V) zu betreiben - gemäß Spezifikation.

Also bei Bedarf natürlich.

Mir ist aufgefallen das schon mal ein gesendetes Signal vom Empfänger nicht richtig interpretiert wird. Insbesondere dann wenn die Bits ähnlich sind.  Das liegt wohl am einfachen Tristate-Protokoll ohne Checksumme. Könnte man natürlich vermeiden wenn sich mehrere Bits in der Adresse unterscheiden - also mit cleverer Wahl von Hauscode und Gerätecode.

Darf man nun aus technischer sicht einfach den Sender an eine 12 V Batterie hängen (zum Testen) oder mit einem Step-up Board versorgen? Oder darf man 2 Stromquellen in einer Schaltung nicht vermischen?


Gruß,

SpenZerX

[JoWiemann]

Hallo SpenZerX,

natürlich kannst Du den Sender mit separater 12V betreiben.

A    D11 -------------------------- Data   S
R                                                       E
D                                                       N
U                                                       D
I                                                        E    VCC ------------------ + 12V -\
N   GND --------------------------- GND  R    GND ------------------ ---------\
O

Grüße Jörg

[mick6300]

Hallo,

ich hatte mir in der vergangenen  Woche die Wetterstation bei Aldi zugelegt. Es handelt sich um die Technoline WS 6750 mit dem TX70DTH Aussenmodul. Nach anfänglichen Schierigkeiten ist es mir gelungen auch diesen Exoten nach FHEMDUINO als KW9010-Gerät einzubinden. Hierzu einfach das Unterprogramm  receiveProtocolTX70DTH an das Ende der fhemduino.ino kopieren und die folgenden Änderungen (in fett) am besthenden Quellcode vornehmen. Die Änderungen sind meiner Meinug nach notwendig, weil der Funkverkehr mit einer doppelt so hohen Baudrate arbeitet wie die anderen Sender.

1.

long NC7159_bitsequence, NC7159_bitseqsave, EuroChron_bitsequence, EuroChron_bitseqsave, LIFETEC_bitsequence, LIFETEC_bitseqsave, TX70DTH_bitsequence, TX70DTH_bitseqsave, KW9010_bitsequence, KW9010_bitseqsave;

2.

  if (duration > 5000 && duration > timings[0] - 200 && duration < timings[0] + 200) {

ersetzen durch

  if (duration > 2500 && duration > timings[0] - 100 && duration < timings[0] + 100) {

3.
  else if (duration > 5000) {

ersetzen durch

  else if (duration > 2500) {


4.
Funktion anhängen

bool receiveProtocolTX70DTH(unsigned int changeCount) {

#define TX70DTH_SYNC   4000
#define TX70DTH_ONE    2030
#define TX70DTH_ZERO   1020
#define TX70DTH_GLITCH  250
#define TX70DTH_MESSAGELENGTH 36

  bool bitmessage[36];
  byte i;
  if (changeCount < TX70DTH_MESSAGELENGTH * 2) {
    return false;
  }
  if ((timings[0] < TX70DTH_SYNC - TX70DTH_GLITCH) || (timings[0] > TX70DTH_SYNC + TX70DTH_GLITCH)) {
    return false;
  }
  for (i = 0; i < (TX70DTH_MESSAGELENGTH * 2); i = i + 2)
  {
    if ((timings[i + 2] > TX70DTH_ZERO - TX70DTH_GLITCH) && (timings[i + 2] < TX70DTH_ZERO + TX70DTH_GLITCH))    {
      bitmessage[i >> 1] = false;
    }
    else if ((timings[i + 2] > TX70DTH_ONE - TX70DTH_GLITCH) && (timings[i + 2] < TX70DTH_ONE + TX70DTH_GLITCH)) {
      bitmessage[i >> 1] = true;
    }
    else {
      return false;
    }
  }
  // Sensor ID & Channel
  byte unsigned id = bitmessage[3] | bitmessage[2] << 1 | bitmessage[1] << 2 | bitmessage[0] << 3 ;
  id = 0; // unterdruecke Bit 4+5, jetzt erst einmal nur 6 Bit
  for (i = 6; i < 12; i++)  if (bitmessage) id +=  1 << (13 - i);

  // Bit 9 : immer 1 oder doch Battery State ?
  bool battery = bitmessage[9];

  // Bit 11 + 12 = Kanal  0 - 2 , id nun bis auf 8 Bit fuellen
  id = id | bitmessage[11] << 1 | bitmessage[12] ;

  // Trigger
  bool forcedSend = bitmessage[13];

  int temperature = 0;
  for (i = 15; i < 24; i++) if (bitmessage) temperature +=  1 << (23 - i);
  //if (bitmessage[16]) temperature -= 0x1000; // negative Temp

  // die restlichen 8 Bits sind z.Z unbekannt vllt. eine Pruefsumme ?
  byte feuchte = 0;
  for (i = 29; i < 36; i++) if (bitmessage) feuchte +=  1 << (35 - i);

  byte rest = 0;
  for (i = 25; i < 28; i++) if (bitmessage) rest +=  1 << (27 - i);

  char tmp[11];
  sprintf(tmp, "K%02x%01d%01d%01d%+04d%02d", id, battery, 0, forcedSend, temperature, feuchte);
  message = tmp;
  available = true;
  return true;
}

[JoWiemann]

Hallo,

ich hatte mir in der vergangenen  Woche die Wetterstation bei Aldi zugelegt.

  int temperature = 0;
  for (i = 15; i < 24; i++) if (bitmessage) temperature +=  1 << (23 - i);
  //if (bitmessage[16]) temperature -= 0x1000; // negative Temp

Hallo,

bei den bisherigen Sensoren musste 2048 und nicht 4096 von der Temperatur abgezogen werden, wenn das bit 16 gesetzt ist. Kannst Du das mal nachprüfen.

Grüße Jörg

[digital.arts]

Hallo Jörg,

zum WS0002 nochmal ... ich versteh noch nicht ganz, warum mein Sender mit dem älteren .ino und den Modulen als KW9010 erkannt wurde, incl. Trend...
und nun als WS0002, ohne Trend, dafür mit unknown-bit ? Oder war die Trendanzeige vorher auch nur eine "Fake-Anzeige" ?

VG
Karl

[JoWiemann]

Oder war die Trendanzeige vorher auch nur eine "Fake-Anzeige" ?

Hallo Karl,

es sah zunächst so aus, als wenn der WS0002 sich wie ein PEARL NC7159 verhält, der im INO auf die Rückgabe eines KW9010 gemappt wurde. Auf Grund einer Fehlermeldung hier im Thread bezgl. negativer Temperatur habe ich für den WS0002 einen eigenen Rückgabewert im INO hinterlegt und dafür dann auch, da ich nicht wusste, ob meine Änderungen PEARL NC7159-Kompatibel sind, ein eigenes Modul geschrieben. Nachdem ich den WS zerlegt habe und einige Test durchgeführt habe, stellte sich heraus, dass die Dekodierung der Temperatur nicht ganz kompatibel ist und das das Trend-Bit sich nicht rührt.

Ich habe mir dann noch einen PEARL NC7159 bestellt, zerlegt und die Dekodierung geprüft. Ergebnis, siehe meine Antwort etwas weiter oben im Thread.

Mein Vorschlag wäre nun entweder den Code für den PEARL NC7159 aus dem INO herauszunehmen und die Sub, sowie das Modul so umzubenennen, dass es irgendwie auf bei Hersteller (PEARL und LogiLink) passt. Z.B. NCxxWSxx

Einen KW9010 werde ich mir nun nicht auch noch kaufen. Ich denke mal, dass der richtig dekodiert ist.

Grüße Jörg

[mick6300]

Hallo,

bei den bisherigen Sensoren musste 2048 und nicht 4096 von der Temperatur abgezogen werden, wenn das bit 16 gesetzt ist. Kannst Du das mal nachprüfen.

Grüße Jörg

Hallo Jörg,
ich hatte in der Eile ganz die negativen Temperaturen vernachlässigt. Also Sender ab in die Tiefkühlung und ...

Bei negativen Temperaturen sind die bytes 13 bis 15 auf 1 gesetzt und es müssen 512 abgezogen werden. Hier die Korrektur und danke für den Hinweis.

  int temperature = 0;
  for (i = 15; i < 24; i++) if (bitmessage) temperature +=  1 << (23 - i);
  if (bitmessage[14]) temperature -= 0x200; // negative Temp

[JoWiemann]

Hallo,

anbei nun der Sketch mit DCF77 Unterstützung ( TX70DTH mit korrigierter neg Temp ist auch mit drin). Die Codeimplementierung basiert auf folgendem Artikel: http://www.arduinoclub.de/2013/11/15/dcf77-dcf1-arduino-pollin/. Anders als im Artikel angeben liegt der Data-Pin des DCF auf D3 des Arduino, da ja D2 durch den 433MHz-Empfänger belegt ist.

Grüße Jörg

[Sidey]

Hi,

das ist ja klasse. Hier wird ja derzeit richtig viel implementiert.

Nur so ne Frage am Rande. Wozu könnte macht das DCF77 Signal nun sinnvoll verwenden.
Ich weiss, dass der Arduino die Zeit an FHEM überträgt. Wird dann damit die Uhr des FHEM System gestellt?

Grüße Sidey

[Bennemannc]

Hallo,

ich hatte früher schon mal gefragt, ob es jemanden gibt, der das Oregon Protokoll (Wttersensoren) einpflegt. Nachdem ich selber viel im Netz gelesen habe, sind mir einige Teile des jetzt eingeführten Codes doch sehr an die Codierung der Oregon Sensoren, die ich gefunden habe, erinnern, habe ich Hoffnung, das eventuell doch jemand sich bereiterklärt den Code zu implementieren. Ich habe selber leider nicht so viel KowHow um das zu machen, stehe aber gerne zum Testen zur Verfügung.

Gruß Christoph

[Sidey]

Hallo,

ich hatte früher schon mal gefragt, ob es jemanden gibt, der das Oregon Protokoll (Wttersensoren) einpflegt.

Hallo,
ich hatte mich mit dem Protokoll schon vor einiger Zeit, ganz unabhängig von FHEM auseinander gesetzt.
Nur leider habe ich es nicht geschafft meine Sensoren auswerten zu können.

Probier doch mal den Code auf folgender Seite, ob er die Daten von deinem Sensor empfängt.
http://connectingstuff.net/blog/decodage-protocole-oregon-arduino-1/

Grüße Sidey