Temperatursender von Wetterstation in CUL

[Joker2002]

sind bei der test Hex dann die anderen Funktionen noch vorhanden ? Wäre für mich blöd wenn plötzlich der Rollo nicht mehr funktionieren würde 

[Joker2002]

Ich habe ein Cul V3 von Busware

[Sidey]

Hi,

bezüglich Namensgebung für das Modul habe ich jetzt folgenden Vorschlag:


SD_WS07    -> SensorDevice_WeatherSenser_07

Mittlerweile sind drei verschiedene Hersteller bekannt, die mit dem Modul laufen.


Grüße Sidey

[meggih]

Lieber Björn,

kannst Du kurz erläutern, wie das TCM-Protokoll aus dem ersten Post genau abläuft?

Bits:
1 = 0,5ms height + 4ms low h llll llll
0 = 0,5ms height + 2ms low h llll
jeweils 500 us

komplettes Paket.

             A      B       C      D       E      F
25,9° = 1111 0000 0000 0100 0000 1100

Wie säh das ganze noch mit Luftfeuchtigkeit aus? -> geklärt
Wird alles wie bei z.B. IT zwei mal gesendet? -> geklärt
Gibt es ein Start/Stop-Bit?

Ich hab mit nem externen Sender an meinen CUL-Stick mal das obige Paket mit den von Dir definierten Bit-Timings gesendet - ist aber nichts angekommen.

Edit: Ok, es müssen also zwei gleiche Nachrichten sein - mit bestimmtem Abstand?
/*
* Check for repeted message.
* When Package is for e.g. IT or TCM, than there must be received two packages
* with the same message. Otherwise the package are ignored.
*/

Edit: Konnte dem Thread noch entnehmen, dass es eine alternative TCM Kodierung gibt für Sensoren mit Luftfeuchtigkeit.
Das ist das, was ich wollte.
Jetzt bleibt nur noch die Frage nach etwaigen Start/Stopp/Sync Bits? Und wie oft diese wiederholt werden müssen, damit der CUL das als "richtiges" Signal erkennt. Und der andere TCM hat wohl auch ein Checksummen-Bit drin? Wird das überprüft im CUL?
Ansonsten entnahm ich den Ausführungen folgende Zusammensetzung (für meinen Sender):

Code Auswählen Erweitern

_sendAddress();  // z. B. 1111 0000
_sendChan(Chan); // 01
_sendBit(false);  // 0
_sendBit(false);  // 0
_sendBat(Bat);   // 0 - voll, 1 - leer
_sendBit(false);  // 0
_sendBit(false);  // 0
_sendBit(false);  // 0 - TX-Taster
_sendTemp(Temp); // 1011 1010 1010
_sendHum(Hum);   // 1010 1010

[meggih]

Danke für die Antwort.

Ich bin auch schon weiter - mein Eigenbausensor funkt schon mit ordentlicher Reichweite und einer 3,7V Li Zelle
Die Batteriespannung wird als zweite Sende-ID mitübertragen, dann hat man nicht nur normal/low.

Jetzt muss ich noch schauen, wie ich die verschiedenen Readings von Sensoren und Batterien ordentlich auf einer Seite zusammengefasst darstellen kann...

Ich schaue dann noch mal im 14_TCM97001-Modul nach bezüglich der Protokolle.

Danke für deine Arbeit an dem Modul!

Ich bin grade dabei, dass GT-WT-02-Protokoll zu implementieren in meinen Sender.
Jedoch verstehe ich folgendes bei CRC noch nicht:

Code Auswählen Erweitern

sub checkCRC_GTWT02 {
  my $msg = shift;
  my @a = split("", $msg);

  my $CRC = (hex($a[0])+hex($a[1])+hex($a[2])+hex($a[3])
            +hex($a[4])+hex($a[5])+hex($a[6])+hex($a[7])) -1;
  my $CRCCHECKVAL= (hex($a[7].$a[8].$a[9]) & 0x1F8) >> 3;
  if ($CRC == $CRCCHECKVAL) {
      return TRUE;
  }
  return FALSE;
}

Ist das "hex($a[0])" das erste Zeichen der Nachricht in Hex-Darstellung, also die ersten 4 Bit? Kann ja eigentlicht nicht stimmen, da sowohl Bezug auf 0 als auch auf 9 genommen wird - es also 10 Nibbles geben müsste, gibt aber nur 9x4= 36 Bit?
Also bei: 1111 1111 0000 0000 1111 1001 0101 0101 1111
my $CRC = F+F+0+0+F+9+5+5-1 = 3F (Die ersten 8 der 9 Nibbles)

und bei $CRCCHECKVAL= (hex($a[7].$a[8].$a[9]) & 0x1F8) >> 3;
$a[7].$a[8].$a[9] = 5FF, 5FF  & 1F8 (Also logisch UND) -> 0101 1111 1111 & 1 1111 1000 = 1 1111 1000 =   1F8
Das dann 3 Bits nach links/rechts?? Wie gehts jetzt weiter?

Aber was soll das für ein CRC sein, der berechnet sich aus allen Nibbles, inkl. Adresse, Temp, etc. Das klingt ja noch logisch. Aber das sollten dann die letzten 4 oder 5 Bits sein? Oder muss das ausgerechnete $CRC = F+F+0+0+F+9+5+5-1 = 3F im letzten Nibble stehen, damit es passt? D.h. es bleibt als Checksumme maximal 1F = 11111 übrig?

[Sidey]

Hi meggih

Ich bin auch schon weiter - mein Eigenbausensor funkt schon mit ordentlicher Reichweite und einer 3,7V Li Zelle
Die Batteriespannung wird als zweite Sende-ID mitübertragen, dann hat man nicht nur normal/low.

Jetzt muss ich noch schauen, wie ich die verschiedenen Readings von Sensoren und Batterien ordentlich auf einer Seite zusammengefasst darstellen kann...

Ich habe dafür mal ein eigenes Protokoll und library mit entwickelt:
https://github.com/RFD-FHEM/ArduinoSensor

Ein passendes Modul zum Einbinden in FHEM gibt es auch. Läuft halt bislang nur im SIGNALduino.
Vielleicht hilft dir das ja ein wenig weiter.

Grüße Sidey

[meggih]

Ja danke, guck ich mir an!

Im Moment hänge ich bei der CRC Berechnung, ich bin leider mit PERL so gar nicht vertraut, C++, VB alles kein Problem, aber Assembler, Perl ist mir zu unleserlich irgendwie

Es klappt ja alles sonst.

[pejonp]

...
Ich bin grade dabei, dass GT-WT-02-Protokoll zu implementieren in meinen Sender.
...

Hallo meggih,

hast du schon einmal im Forum nach diesem Sensor gesucht bzw. nach einen ähnlichem. Dazu gab es schon mal eine Anfrage, ich glaube im JeeLink/LaCross Umfeld. Schau mal hier und hangele dich durch http://forum.fhem.de/index.php/topic,35064.msg282689.html#msg282689.

Jörg

[meggih]

@Sidey Habe mir den Link mal angeguckt und das ist ja im Prinzip genau das, was ich machen will. Jedoch bekomme ich mit der Lib von Dir kein einfach Beispiel zum Laufen.

Die "normalen" Libraries von Randy Simons kenn ich auch schon - ich habe mir damit super funktionierende kleine Bausteine gebastelt und meine "alten" Bewegungsmelder/Lampen per IT-Protokoll in FHEM eingebunden (Hab den 433 Stick).

@pejonp Danke für den Link. Dort steht die CRC Berechnung ja sogar im Klartext. Jedoch klappt das bei mir trotzdem nicht Ich bin auch etwas verwirrt, wie viel Nibbles ich denn nun senden soll. Bislang dachte ich 9x4 Bits reichen aus. Laut dem CRC wird aber noch 1Bit/Nibble mehr gesendet. Sobald ich das tue, erkennt FHEM gar nichts mehr. Wenn ich nur 9 Nibbles sende mit falschem CRC wird Auriol erkannt.

[Sidey]

Hallo meggih,

@Sidey Habe mir den Link mal angeguckt und das ist ja im Prinzip genau das, was ich machen will. Jedoch bekomme ich mit der Lib von Dir kein einfach Beispiel zum Laufen.

Woran scheitert es?

Grüße Sidey

[meggih]

Ich hab einfach mal die Codeschnipsel aus der Dokumentation zusammengepackt in ein Arduino Projekt.

Code Auswählen Erweitern

    #define TRANSMITTER             2   // 433Mhz Transmitter DATA PIN
  #include <SensorTransmitter.h>

  asTransmitter voltage(8,10,TRANSMITTER);// (DeviceType, DeviceID, OutputPin)
  asTransmitter temp(6,11,TRANSMITTER);// (DeviceType, DeviceID, OutputPin)
  asTransmitter hum(9,12,TRANSMITTER);// (DeviceType, DeviceID, OutputPin)

void setup() {
  // put your setup code here, to run once:
}

void loop() {
  // put your main code here, to run repeatedly:
  int tempVal=50;
  int humVal=50;
  int vcc=3700;
  tempVal=(uint16_t)(tempVal+0x8000);
  humVal=(uint16_t)(humVal+0x8000);
  vcc=(uint16_t)(vcc+0x8000);

  temp.send(tempVal, 0b00, 0);//(value[16bit], battery[2bit], trigger[1bit])
  hum.send(humVal, 0b00, 0);//(value[16bit], battery[2bit], trigger[1bit])
  voltage.send(vcc, 0b00, 0);//(value[16bit], battery[2bit], trigger[1bit])
  while(1);
}
}

Das sollte doch schon so funktionieren? Es werden in FHEM aber keine neuen Sensoren erkannt.

[Sidey]

Wie geschrieben, die Integration in FHEM ist derzeit nur über den Signalduino möglich.


Grüße Sidey

[meggih]

Okay dann werde ich weiter den Ansatz "Bekanntes-Protokoll nachbauen" verfolgen. Es werden ja Sensoren erkannt - ich brauche jetzt nur 1 Protokoll, dass Temp/Hum beinhaltet und bei dem selbst ich den CRC Wert berechnen kann GT-WT-02 schien ja ideal, leider scheint der CRC zu schwer für mich...

Kurzes Update: Hab jetzt das EAS800 also Eurochron Protokoll aus dem neuen 14_TCM Modul genommen und jetzt klappts. Dort gibt es kein wirkliches CRC, sondern nur Nibble G muss immer auf 1111 stehen.
Verstehe noch nicht ganz, warum in FHEM aber Trend: rising steht, wenn das doch gar nicht mit übermittelt wird.

@Björn Was mir noch aufgefallen ist im EAS800 Protokoll: Dort steht im Modul, dass das erste Bit von Nibble C die Batteriewarnung sein soll. Aber egal ob 0 oder 1, in FHEM steht immer Battery: normal

[Sidey]

Verstehe noch nicht ganz, warum in FHEM aber Trend: rising steht, wenn das doch gar nicht mit übermittelt wird.

Für den eas800  sowie andere Sensoren, welche die gleiche Signalcodierung verwenden gibt es das Modul SD_WS07. Dort gibt es nur Readings, welche von den Sensoren unterstützt werden.

Grüße Sidey

[bjoernh]

Für den eas800  sowie andere Sensoren, welche die gleiche Signalcodierung verwenden gibt es das Modul SD_WS07. Dort gibt es nur Readings, welche von den Sensoren unterstützt werden.

Grüße Sidey

Ist im TCM Modul auch schon behoben ich habs blos noch nicht eingecheckt. Kommt also mit dem nächsten Update.
@Sidey Gibt es dein Modul auch im offiziellen fhem? Wenn nein, sollten wir wenn möglich Konflikte vermeiden. Hört dein Modul auch auf den Prefix "s"?